PHP2Shell: Critical PHP Vulnerabilities and What Organisations Must Do

On 21 October 2026, the PHP Security Team released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell.

Both vulnerabilities carry a CVSS v4.0 severity score of 9.2 and could allow an unauthenticated attacker to execute malicious code on vulnerable servers.

The potential reach is significant. According to W3Techs, PHP is used by approximately 69% of websites whose server-side programming language is known.

That does not mean 69% of websites remain vulnerable. It does, however, demonstrate why vulnerabilities in such widely deployed technology require an immediate response.

The UK's National Cyber Security Centre (NCSC) and the European Union Agency for Cybersecurity (ENISA) have both urged organisations to identify affected systems and prioritise updates.

For security teams, the challenge is not simply knowing that a vulnerability exists.

It is knowing exactly where the vulnerable technology exists across the organisation.

What is PHP2Shell?

PHP2Shell refers to two vulnerabilities discovered in the core PHP engine, the technology responsible for processing server-side code in many websites and web applications.

The vulnerabilities are:

CVE-2026-109618: Remote code execution through out-of-memory corruption

This vulnerability involves how PHP handles memory allocation failures and cleans up requests. Under certain conditions, an attacker can trigger memory corruption that may lead to remote code execution.

CVE-2026-109619: Remote code execution through stale global state

This vulnerability involves internal PHP state referencing memory that has already been released. Under certain circumstances, subsequent requests can interact with this invalid state, potentially allowing an attacker to execute malicious code.

Both vulnerabilities affect the underlying PHP runtime rather than being limited to a particular content management system or plugin.

That distinction is important.

An organisation could have fully updated WordPress plugins and application code but still be running an affected version of PHP underneath.

The vulnerabilities were disclosed following research by Wiz and collaborators, with AI-assisted analysis playing a role in identifying and demonstrating the weaknesses.

Read the original Wiz technical research.

Which PHP versions are affected?

The PHP Security Team released four patched versions on 21 October 2026.

PHP branchFixed versionPHP 8.58.5.12 or laterPHP 8.48.4.27 or laterPHP 8.38.3.36 or laterPHP 8.28.2.35 or later

Earlier releases within these branches are affected.

PHP 8.1 and older versions are no longer supported by the PHP project. Organisations using these versions should move to a supported release or obtain an appropriate security backport from their operating system or long-term support vendor.

The exposure extends beyond conventional website hosting.

Affected PHP runtimes can be used through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP may also be embedded within third-party applications, management interfaces and commercial software.

The PHP Security Team considers Apache mod_php configurations particularly concerning because a demonstrated attack can be triggered before application code executes.

Important: A website using PHP is not automatically confirmed to be vulnerable. Exposure depends on the installed version, vendor patches and deployment configuration. Organisations should verify their systems rather than relying on technology detection alone.

The authoritative guidance is available in the official PHP security advisory.

What should organisations do now? A practical PHP2Shell response checklist

The immediate priority is to identify vulnerable installations, patch them and investigate potential malicious activity.

These six actions provide a practical starting point.

1. Identify every internet-facing PHP application

Begin with an inventory of public-facing websites and services that may use PHP.

This should include production websites, customer portals, subdomains, legacy applications, cloud-hosted services, staging environments and internet-accessible management interfaces.

Do not assume that your existing asset register contains everything.

Applications introduced by development teams, contractors or third-party suppliers may have been deployed outside normal IT processes.

Use authorised asset discovery and infrastructure inventory tools to locate these systems, then confirm the PHP version through internal configuration records, host-level inspection or your hosting provider.

The immediate objective is to establish which systems are exposed, what version they run and who is responsible for updating them.

2. Prioritise vulnerable systems by exposure and business impact

Not every system presents the same level of operational risk.

Prioritise systems that are directly accessible from the internet, run affected PHP versions and support critical business functions or handle sensitive information.

Consider whether the application provides authentication, payment processing, customer access or connections to other important systems.

A forgotten development application may also warrant urgent attention if it is publicly accessible and poorly maintained.

The NCSC specifically advises organisations to prioritise internet-facing PHP systems.

3. Apply the official PHP security updates

Update affected installations to a fixed PHP release, or apply an appropriate vendor-supplied security package containing the relevant fixes.

The PHP project confirms that updating is the only complete remediation for these vulnerabilities.

Before deployment, assess application compatibility and prepare a controlled change process. For critical systems, coordinate the update with application owners and hosting providers.

After patching, verify the PHP version actually used by the running web application. Updating a package or command-line installation does not necessarily prove that every web-serving process has been updated.

Where PHP is bundled inside another product, follow the relevant vendor's security advisory and patching instructions.

4. Restrict exposure if immediate patching is impossible

If a vulnerable internet-facing application cannot be updated immediately, carry out an urgent risk assessment.

Where appropriate, temporarily take the system offline or isolate it from public networks until remediation can be completed.

The PHP Security Team has published specific temporary configuration measures that may reduce exposure to certain exploitation paths. These include changes relating to request memory handling and session upload progress.

However, these measures are not complete fixes and must not be treated as equivalent to patching.

Web application firewall protections may help block some known attack patterns, but they do not eliminate the underlying vulnerability.

Follow the official PHP guidance before applying temporary mitigations, as configuration changes can have operational consequences.

5. Monitor for suspicious activity and investigate potential compromise

Patching addresses the vulnerability going forward, but it does not establish whether a system was previously compromised.

Review available web server, PHP, application and security monitoring logs for suspicious requests, unexpected file changes, anomalous processes or other indicators of compromise.

Where malicious activity is suspected, involve your incident response team, preserve relevant evidence and investigate before returning affected systems to normal operation.

Continue monitoring official advisories for updated detection guidance and emerging information.

6. Check third-party software and suppliers

The risk is not confined to applications developed or hosted directly by your organisation.

Third-party software, network appliances and managed services may incorporate PHP without exposing that dependency to customers.

Contact relevant suppliers and hosting providers to establish whether their products are affected, whether patches have been applied and whether any customer action is required.

The Dutch National Cyber Security Centre maintains a PHP2Shell information repository containing operational guidance and information about potentially affected third-party software.

Its inventory is evolving, so absence from the list should not be treated as confirmation that a product is unaffected.

Why PHP2Shell highlights the importance of External Attack Surface Management

PHP2Shell demonstrates a broader cybersecurity challenge.

When a critical vulnerability becomes public, security teams need to answer several questions quickly:

Which of our internet-facing assets use the affected technology? Are any systems missing from our inventory? Which assets are publicly accessible? Who owns them? Which require immediate attention?

Without an accurate view of the organisation's external environment, answering those questions can become a time-consuming investigation.

This is where External Attack Surface Management (EASM) becomes valuable.

EASM provides continuous visibility into internet-facing assets, helping organisations identify unknown or unmanaged infrastructure and understand how their external exposure changes over time.

For example, an organisation may maintain its primary website carefully while overlooking an older customer portal, a development subdomain or a service introduced by a supplier.

These systems still contribute to its external attack surface, whether or not they appear in its official inventory.

Continuous asset discovery can help security teams identify those blind spots before an emergency vulnerability disclosure.

It is important to distinguish asset discovery from vulnerability confirmation. Discovering a website or identifying its apparent technology does not, by itself, establish whether its underlying PHP runtime is vulnerable.

A reliable response requires both comprehensive asset visibility and appropriate technical verification.

How DarkInvader helps organisations understand their external exposure

DarkInvader is an External Attack Surface Management platform designed to help organisations discover, monitor and understand their internet-facing assets.

Through continuous Asset Discovery, DarkInvader helps security teams identify domains, subdomains, IP addresses, exposed services and previously unknown infrastructure associated with their organisation.

Its Vulnerability Scanning capabilities support the wider process of identifying and assessing external security weaknesses.

Together with ongoing asset monitoring and external threat intelligence, these capabilities help organisations develop a clearer understanding of their attack surface and prioritise security investigations.

In an incident such as PHP2Shell, this visibility can help teams establish which internet-facing systems require further investigation and coordinate checks with the relevant technical owners.

Specific PHP version checks and CVE-level detection should be verified independently. DarkInvader's asset visibility does not replace applying security patches, examining server configurations or conducting incident response.

The value of continuous EASM extends beyond a single vulnerability.

New applications are deployed, infrastructure changes, suppliers introduce services and forgotten systems remain accessible long after their original purpose has disappeared.

An attack surface is not static. Your visibility cannot afford to be either.

PHP2Shell: Frequently asked questions

Is my WordPress website affected by PHP2Shell?

WordPress uses PHP, so a WordPress website may be affected if its underlying server runs a vulnerable PHP version.

Updating WordPress, themes and plugins does not automatically update the PHP runtime. Check your hosting environment and confirm that the relevant PHP security patch has been applied.

Can PHP2Shell be exploited without a login?

Yes. Both vulnerabilities can potentially allow unauthenticated remote code execution. The practical exploitability of a particular system depends on its runtime version and configuration.

Is a web application firewall enough to protect against PHP2Shell?

No. A web application firewall may reduce exposure to some attack techniques, but the PHP Security Team states that updating is the only complete fix.

How can organisations find vulnerable PHP servers?

Start by identifying systems running PHP across the organisation, prioritising internet-facing applications. Confirm runtime versions using internal inventories, server inspection, vulnerability management tools and hosting provider information.

External attack surface discovery can help identify unknown websites and services that should be included in the investigation, but external technology fingerprinting alone may not confirm the installed PHP version.

The key takeaway: Know what is exposed before the next vulnerability emerges

PHP2Shell is an urgent reminder that widespread technology vulnerabilities can quickly become an organisation-wide security problem.

The immediate actions are clear: identify affected PHP installations, update to fixed releases, review potential exploitation and coordinate with third-party providers.

But the longer-term lesson goes beyond PHP.

Organisations need a continuously maintained understanding of their internet-facing systems, including the assets that traditional inventories can miss.

Because when the next critical vulnerability emerges, the organisations best prepared to respond will be those that already know what they have exposed.

See what attackers see.

Explore DarkInvader's External Attack Surface Management platform and discover how continuous visibility can help you understand and reduce your external exposure.

Sources and further reading

This article was prepared using information available on 22 October 2026. Vulnerability guidance may change as further research and vendor updates become available.

‍