Two Critical PHP Vulnerabilities Expose a Familiar Challenge: Organisations Cannot Secure Technology They Cannot See.
Media warnings of a “wider wave of attacks” after a critical flaw affected websites worldwide capture the scale of concern around PHP2Shell. The issue extends beyond a single website platform or isolated software product because the weaknesses lie in PHP itself, a foundational technology used across a significant share of the public web.
The research behind PHP2Shell describes a family of memory-safety vulnerabilities in core PHP, with severity reaching CVSS 9.2. The researchers say the flaws can let unauthenticated attackers execute code or expose sensitive process memory under certain conditions. The research also estimates that PHP powers approximately 70% of websites, which explains why a weakness in its core engine commands attention far beyond technical teams.
That figure does not mean 70% of the internet is immediately vulnerable. Exposure depends on the PHP version, configuration and the specific flaw. Even so, PHP2Shell raises a strategic question for leaders: how confidently can the organisation identify the hidden technologies supporting its digital services?
PHP2Shell covers two related vulnerability classes in core PHP, tracked as CVE-2026-109618 and CVE-2026-109619. One concerns corruption caused by out-of-memory handling. The other involves stale global state surviving across requests. According to the researchers, these conditions can lead to remote code execution or disclosure of PHP process memory.
The distinction between PHP and the applications running on top of it is critical. Researchers demonstrated pre-authentication remote code execution against WordPress, Drupal and Joomla using controlled test environments. Those platforms were representative targets, not the source of the problem. The vulnerable code resides in PHP, so other applications and custom-built services may also require investigation.
This makes PHP2Shell a particularly useful illustration of modern technology risk. Business owners may know that an organisation operates WordPress, Drupal, Joomla, Magento or another content-management system. Security and infrastructure teams must look further down the stack by identifying the runtime version, deployment configuration, hosting model and services supporting each application.
A seemingly secure application can still inherit risk from the technology beneath it. The flaw therefore matters to every leader responsible for website availability, customer data, digital commerce, or operational continuity.
Organisations have become used to managing technology through recognisable products and services. Applications have names, owners and budgets. The underlying components are less visible, particularly where services are externally hosted, inherited through acquisition or maintained by different suppliers.
PHP2Shell exposes the weakness in that model. An organisation may update WordPress plugins, Drupal modules, or Joomla extensions while overlooking the PHP runtime that supports the site. The researchers make it clear that an application update does not update the runtime beneath it. A website can therefore appear properly maintained at the application layer while remaining exposed through an outdated PHP installation.
This is where Log4Shell provides useful historical context. Although technically different from PHP2Shell, it also forced organisations to look beneath their visible applications for a widely used component. In both cases, the strategic challenge is identifying where foundational technology exists, which services depend on it and who owns the decision to remediate it.
The recurring lesson is uncomfortable but valuable. Many organisations have an application inventory yet lack an equally dependable view of the dependencies, libraries and runtimes that keep those applications working.
For executives, the immediate concern is the potential business impact. The PHP2Shell research states that successful exploitation could let an attacker execute code as the PHP web worker and access sensitive data or disclose process memory containing passwords, authentication tokens, API keys, or certificates. The specific outcome depends on the flaw and affected environment.
A compromised public-facing website can affect customer access, digital transactions and trust. Where the same infrastructure connects to other systems, the consequences may extend further into the organisation. The risk also includes internally developed PHP applications that receive less public attention than well-known platforms but may process commercially sensitive information.
The board-level issue is one of assurance. Leaders need confidence that the organisation can locate affected runtimes, establish which services depend on them and assign responsibility for action. When those answers take days to assemble, technical uncertainty becomes operational risk.
The immediate priority is to identify every affected PHP runtime and apply the security update. Organisations should review public websites, internal applications and supplier-managed services, then compare each runtime with the official affected-version guidance. This review should include familiar PHP-based platforms such as WordPress, Drupal and Joomla as well as Magento installations and custom applications. However, those platforms should not be treated as the limit of possible exposure because the weaknesses reside within PHP itself.
The research identifies PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as the first fixed releases in their respective supported branches. Organisations should install a fixed release on every affected runtime, then restart Apache, PHP-FPM and any long-running PHP workers to ensure the updated runtime is active. Updating WordPress, Drupal, Joomla or another application does not update the PHP runtime beneath it.
Where an upgrade cannot be completed immediately, temporary configuration changes and protective controls may reduce exposure to particular attack paths. These measures carry operational trade-offs and do not address every variant. The researchers identify upgrading PHP as the only complete remediation, while application updates, web application firewall rules and hosting-provider protections should not be treated as substitutes for the PHP security update.
The short-term response should therefore follow a clear sequence:
Leadership teams should confirm who owns remediation for each environment. Where hosting providers or external developers manage the underlying infrastructure, organisations should seek evidence that the PHP update has been applied rather than assuming an application update resolved the issue.
Patching PHP2Shell addresses the immediate exposure. The longer-term challenge is ensuring the organisation can recognise and respond to the next serious flaw without rebuilding its understanding of the technology estate during a crisis.
That requires an ongoing vulnerability-management capability covering discovery, assessment, prioritisation, ownership, remediation and verification. CyberOne’s guidance on managed vulnerability management explains why scanning alone does not reduce risk. Findings need business context, accountable owners, and follow-through to verified remediation. The current CyberOne catalogue confirms this internal article destination.
Businesses should also stay aware of emerging vulnerabilities through vendor advisories, trusted threat intelligence, and defined internal escalation routes. The aim is to create a repeatable process that quickly gets relevant warnings to the right technical and business owners.
A mature programme should enable the organisation to answer:
Continuous vulnerability scanning can support this operating model by improving visibility between periodic assessments. However, scanning needs to sit within a wider process that connects findings to ownership, business impact and action.
This distinction is important between vulnerability management and broader cyber resilience. Vulnerability management helps organisations identify and reduce weaknesses. Cyber resilience also encompasses the governance, authority, monitoring, response and recovery capabilities needed to maintain critical services when preventive controls can't eliminate every risk.
PHP2Shell should prompt two distinct responses. The first is urgent and technical: identify affected PHP runtimes, update them to fixed releases and validate that remediation has taken effect. The second is strategic: build an operating model that keeps the organisation alert to emerging vulnerabilities and turns new intelligence into prioritised action.
CyberOne can help organisations evaluate whether these foundations are in place through Cyber Security Gap Analysis & Maturity Assessment Services. This provides a verified route to identify capability gaps and inform a prioritised security improvement path.
PHP2Shell will eventually leave the headlines, but the dependency problem it exposes will remain. The next significant flaw may affect another runtime, library, framework, or managed service that business leaders rarely hear about by name.
The lasting lesson is that technology's importancegisn'tot always reflected in how visible it is to leadership. Organisations that understand the components beneath their critical services can assess exposure faster, make better decisions and reduce the chance that a software flaw becomes a business interruption.