Studio Botez - Digital products for humans

The latest PHP security vulnerabilities have prompted organisations worldwide to take urgent action, highlighting a wider question about technology choices, software dependencies and the responsibility that comes with maintaining digital services.

On 21st October 2026, the release of critical security updates for PHP triggered an international response. Government websites and other online services were taken offline while organisations assessed their exposure and worked to apply the necessary fixes.

The UK National Cyber Security Centre and European cybersecurity authorities urged organisations to identify affected systems, prioritise internet-facing services and apply the available updates. Where immediate remediation was not feasible, organisations were advised to consider isolating affected systems from public networks until they could be adequately protected.

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, could allow unauthenticated remote code execution on affected servers. Their severity, combined with PHP's widespread use, made the response particularly urgent. But the incident also illustrates a broader point, the consequences of a technology decision can extend far beyond the original development project.

When a shared dependency becomes a shared risk

Modern websites rarely operate as isolated pieces of software, they rely on a combination of programming languages, frameworks, databases, libraries, hosting infrastructure and third-party components. This approach makes it possible to develop and maintain digital services efficiently, but it also means that a vulnerability in a widely used component can affect a large number of systems at once.

PHP is a clear example, as an organisation may know which content management system it uses without knowing which PHP version supports it, whether that version is still receiving security updates or how quickly a fix can be deployed. PHP may also be included within third-party products or hosting arrangements in ways that are not immediately obvious to the organisation using them.

And this is not only unique to PHP - any widely adopted technology can become a point of shared exposure if a critical weakness emerges, and neither does the discovery of a vulnerability mean that every affected system has been compromised. What matters is whether organisations understand their dependencies and have the means to respond when a problem is identified.

Popularity is not an architectural decision

The web offers an enormous choice of platforms and development approaches. Established content management systems make publishing accessible, while frameworks and custom-developed applications offer different levels of control over how a service operates.

WordPress, originally developed as a blogging platform, is now used for a wide variety of websites. Its adoption is understandable because it is familiar, has an extensive ecosystem and can be relatively straightforward to manage. However, widespread adoption should not be the only reason for choosing a technology, particularly where a website supports public services or handles sensitive information.

A platform must be assessed in the context of its intended purpose, its security requirements, its dependencies and the organisation's ability to maintain it. A solution that is appropriate for a straightforward publishing website may not be the best choice for every service, and the addition of plugins and extensions does not remove the need to assess the overall architecture. Equally, custom software is not automatically more secure, it requires the same disciplined approach to vulnerability management, testing, maintenance and operational oversight.

The question is not whether a technology is fashionable, familiar or widely used; it is whether it is appropriate for the job and can be responsibly maintained throughout its working life.

The technology is only part of the equation

PHP is a widely used programming language and there is nothing inherently insecure about developing with it, as a properly engineered PHP application, running on a correctly configured and supported environment with appropriate security controls, can be secure. The same principle applies to other programming languages, frameworks and platforms. Security is the result of multiple factors working together, including: sound application design, secure configuration, access controls, dependency management, timely patching, monitoring and a clear process for responding to incidents. No single measure guarantees security, and even well-maintained systems can be affected by newly discovered vulnerabilities.

The distinction matters when assessing content management systems such as WordPress, as its origins as a blogging platform do not automatically disqualify it from other uses. However, its suitability should be assessed against the requirements of the service, the complexity of its dependencies and the organisation's ability to maintain the complete environment.

The latest vulnerabilities are in PHP itself, rather than WordPress specifically. WordPress has confirmed that no WordPress core update is required to address them. Organisations running WordPress must nevertheless establish whether their PHP environment is affected and ensure the appropriate updates are applied.

The question is not whether PHP, WordPress or any other technology is universally good or bad, it is whether the technology has been chosen for the right reasons, engineered and configured appropriately, and supported by the resources and processes needed to keep it secure over time.

Security does not end at launch

A website launch is a milestone, not the end of the engineering responsibility. Software needs to be monitored, dependencies need to be maintained, and security updates need to be assessed and applied. Organisations also need to understand who is responsible for each part of that process, particularly where hosting, development and ongoing support are provided by different parties.

When a critical vulnerability is announced, the practical challenge can be considerable. Teams need to quickly establish which systems are affected, determine the appropriate fix, apply it without creating further disruption and consider whether there are signs that a system was compromised before the update became available. Applying a patch is essential, but it may not be sufficient if an attacker has already gained access, the response may also require investigation, recovery and further security measures. These responsibilities need to be considered when a service is commissioned, not improvised when an urgent advisory appears.

For organisations procuring digital services, this means asking how security updates are managed, what happens when a supplier's software reaches the end of its supported life, how incidents are handled and whether the technical arrangement provides enough visibility and accountability.

Choosing technology with the longer term in mind

Cost and speed matter in software development and so do usability, reliability and the ability to maintain a service without unnecessary complexity. The difficulty comes when decisions are made around the immediate requirements of a project without sufficient consideration of the years that follow.

A technology that is inexpensive to introduce can carry ongoing costs through maintenance, extensions, compatibility issues and the work required to keep it secure, and those costs are not always apparent at the procurement stage. This is especially important for public bodies and other organisations whose digital services must remain dependable and accessible, as they need to understand not only what they are buying, but also what will be required to operate it responsibly.

That does not mean avoiding established technologies or assuming that bespoke software is always the better answer, it means making deliberate choices, understanding the trade-offs and ensuring that the people responsible for a system have the knowledge and resources to maintain it.

Good software engineering involves considering the full life of a product,including how it is designed, deployed, monitored, updated and eventually replaced.

A reminder, not an exception

The PHP vulnerabilities are a serious and immediate security concern. Organisations responsible for affected systems should follow official guidance, apply the relevant fixes and investigate any signs of compromise.

Beyond the immediate response, however, this incident reinforces something that should already be central to software development: security is not an optional layer added after the main work is complete, it is part of the design, delivery and ongoing operation of a digital service.

No architecture can guarantee that vulnerabilities will never emerge. What organisations can do is choose technologies for sound reasons, understand what those technologies depend on and establish clear arrangements for keeping their systems secure.

The most important technology decisions are often made well before a problem becomes visible and their value becomes particularly clear when the web faces an incident of this scale.