PHP2Shell: Critical flaws in PHP itself put web servers at risk

On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, which the project says "can allow unauthenticated remote code execution". The pair, widely called PHP2Shell, sits in the language runtime rather than in any application, so it reaches PHP installations that serve web requests whatever runs on top of them: WordPress and Drupal sites, customer portals, admin panels and hosting control panels. According to W3Techs, PHP runs 69.3% of the websites whose server-side language it can identify.

The release came a day early. The CVE identifiers leaked on October 20, honeypots were already recording exploitation attempts, and several European governments took public websites offline as a precaution until they could patch. The NSA and CISA advised organisations that cannot update immediately to take affected systems offline, and the UK's National Cyber Security Centre (NCSC) told those that cannot quickly update or apply interim mitigations to consider doing so. For most companies, the hard part is not installing the update but finding every place where PHP runs.

What happened

According to the PHP Foundation, researcher Ryan Austin of Calif, who was auditing PHP under OpenAI's Patch the Planet programme, reported an unconditional remote code execution on August 11, 2026. OpenAI independently reported the same root cause that day, and Wiz followed on August 24. The Foundation says the first signs of the underlying out-of-memory problem had already surfaced in a 2024 security audit funded by Germany's Sovereign Tech Agency, but work on a fix stalled and restarted repeatedly. It does not soften this: "the delay was a structural failure".

The coordinated release was planned for October 22 at 14:00 UTC. On the afternoon of October 20, both CVE identifiers began circulating on forums and social media with a wrong CVSS score of 10.0, and that evening the PHP project brought the release forward by a day. Calif then mistakenly published, and later deleted, a video of its proof of concept. On the morning of October 21, Chainguard published patched images several hours before the coordinated release, which the PHP Foundation describes as breaking the embargo; Chainguard's CEO said he shipped early because exploits had appeared in the wild. The GitHub security advisories went public at 13:34 UTC, shortly before the scheduled release.

What the two flaws do

Both vulnerabilities are memory safety bugs in how PHP sets up and cleans up requests. CVE-2026-109618, "RCE via OOM corruption", occurs when out-of-memory handling interrupts PHP while internal request data is only partially initialised, and request cleanup then treats the invalid data as valid. An attacker can push a request into that state with crafted multipart form data, for example a part with a very large number of headers, which uses more memory inside PHP than on the wire. CVE-2026-109619, "RCE via stale global state", lets request-owned state survive after its memory has been freed, so a later request handled by the same worker may use it: a classic use after free. One confirmed path runs through session upload progress, which the advisory notes "is enabled by default, and no application call to session_start() is required".

The PHP project rates both flaws 9.2 on CVSS v4.0 and marks attack complexity as high: reliable exploitation depends on the PHP build, its extensions and the memory layout, and the stale state attack needs at least two requests to reach the same worker. NIST's National Vulnerability Database scores both 9.8 on CVSS v3.1. A successful exploit runs code with the privileges of the web worker account, and the NSA notes that these vulnerabilities "often provide a direct path to the server's file system or database".

Who is affected

The PHP project says "all PHP installations serving web requests" are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, where a demonstrated exploit runs "before any application code runs". PHP-FPM is not immune: the advisory for CVE-2026-109619 describes a validated FPM attack path that depends on what the application does, and the PHP Foundation says remote code execution was also confirmed on PHP-FPM through application-level code paths. Updating WordPress, Drupal or any other application does not help, because the flaws are in the runtime underneath. WordPress.org said on October 21: "No WordPress update is required or planned for these issues."

Older versions are the harder problem. PHP 8.1 and earlier no longer receive releases from the PHP project, which published only minimal source backports for 7.4, 8.0 and 8.1; some Linux distributions and long-term support vendors ship their own fixed packages. Two of the discoverers, Calif and Wiz, say affected code paths go back to PHP 5.4, released in 2012; the PHP project's advisories name no earliest affected version, and its fixed releases cover the supported 8.2 to 8.5 branches. PHP 8.2 itself reaches end of life on December 31, 2026.

PHP also runs inside products that few teams think of as PHP servers. Palo Alto Networks lists every version of PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2, and Panorama, as affected, with the highest risk when the management interface is reachable from the internet; it rates the impact on its products as availability only and had no fixed release yet when it published its advisory on October 21. Plesk says all PHP versions it ships are affected and has released fixes. The Dutch National Cyber Security Centre (NCSC-NL) maintains a public list of products that embed PHP, which CERT-EU, ENISA and the UK NCSC all point to.

How attacks like this unfold

Amazon Threat Intelligence says its MadPot honeypots recorded a PHP2Shell exploitation attempt on October 17, four days before public disclosure, and more attempts in the hours before the release, though it was unclear whether any of them would have succeeded against real-world systems. After the release, Amazon wrote that PHP2Shell "is now being broadly exploited in the wild" and advised investigating activity from at least October 17. Cloudflare switched on web application firewall (WAF) rules for its free and paid WAF customers at 03:02 UTC on October 21, and its CEO Matthew Prince said on October 22 that attempts had reached "millions".

Attempts are not the same as successful compromises. CISA said on October 21 that it had "not observed exploitation of these vulnerabilities as of the time of publication", and on October 22 neither CVE was in its Known Exploited Vulnerabilities catalogue. The PHP Foundation said its security team found no functional exploits among the proofs of concept that appeared after the leak, at the time of release. VulnCheck counted hundreds of proof-of-concept repositories, none of which independently bypasses ASLR, a standard memory protection, on x86-64 systems, and Sansec reported that public exploits do not work against a default PHP installation. Some of the code in circulation is fake: JFrog found prank proofs of concept, and Tenable warns that unverified exploit code is sometimes laced with malware.

That is no reason to wait. Exploits that work with ASLR enabled already exist: VulnCheck has built one for its customers, and Wiz describes chaining a memory disclosure to remove the guesswork. VulnCheck also saw at least one attacker try, unsuccessfully, to drop a web shell through a session file, and CISA advises monitoring for PHP worker processes that launch shells or download tools. History points the same way: three earlier PHP vulnerabilities are in CISA's exploited catalogue, and CISA marks two of them, including CVE-2024-4577, as used in ransomware campaigns.

Why leaders should care

Several European governments treated PHP2Shell as an emergency. On October 21, the Dutch government took websites including Overheid.nl, MijnOverheid.nl and DigiD offline as a precaution. Finland's government ICT centre, Valtori, shut down central government public internet services by closing incoming traffic. Kombit closed Denmark's Aula school platform until the next morning, and the French Interior Ministry placed its exposed websites, including the prefectures, into preventive maintenance.

On October 21, the European Commission, ENISA, CERT-EU, Europol's cybercrime centre and the EU CSIRTs Network issued a joint statement. It tells organisations to identify their PHP-based applications, coordinate with hosting and service providers, apply the updates with internet-facing systems first and, where they cannot fix quickly, consider isolating exposed applications from public networks. It also reminds manufacturers that since September 11, 2026, the Cyber Resilience Act requires them to report actively exploited vulnerabilities in their products, the 24-hour reporting duty we covered in September. Neither CISA's catalogue nor the EU Vulnerability Database flagged PHP2Shell as exploited on October 22, but any company that ships PHP inside a product should be ready to assess it.

The exposure is wide because PHP is widespread and often invisible. Veridion counted more than 7 million companies whose websites show an affected PHP version, 92% of them with fewer than 50 employees. Censys saw 2.58 million internet-facing PHP hosts on October 21, and about 1.57 million of the roughly 1.58 million that showed a version were unpatched, according to SecurityWeek. Both counts rely on version strings, so they are estimates. A compromised marketing site, customer portal or admin panel can still expose customer data and credentials, and the GDPR, NIS2 and DORA obligations that follow a breach do not change because the flaw sat in the runtime rather than in your code. A supplier's unpatched PHP server is your exposure too, and the EU statement tells organisations to coordinate with hosting and service providers.

What to do now

1. Find every PHP runtime, not just your PHP applications

   List web servers, containers, content management systems, admin tools, hosting control panels and vendor appliances, including those run for you by suppliers. The UK NCSC warns: "As all versions may be affected, do not limit discovery to outdated PHP versions". Check the NCSC-NL product list and your vendors' advisories for appliances that embed PHP.

2. Update the runtime and restart every worker

   Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's fixed package, and rebuild container images from patched bases. Then restart Apache with mod_php or every PHP-FPM pool, because running workers keep the vulnerable code in memory. Internet-facing systems come first.

3. Do not trust the version number alone

   Some distributions, including Ubuntu and Red Hat, backport fixes without changing the upstream version: Ubuntu 24.04's fixed package still reports PHP 8.3.6, and Red Hat's fix for the PHP 7.4 module on RHEL 8 still reports 7.4.33. Confirm the fix in your vendor's advisory or package changelog by CVE ID. External scans have the opposite blind spot: VirusTotal found that roughly four out of five PHP servers hide their version.

4. Use the interim mitigations only as a bridge

   If you cannot update today, the PHP project lists measures that "reduce exposure to specific attack paths but do not make an installation safe": session.upload_progress.enabled=0, a low post_max_size, a memory_limit=-1 that applications cannot override and, on PHP 8.5, fatal_error_backtraces=0, each followed by a restart of every worker. Removing the memory limit has its own denial-of-service risk, and Cloudflare's CTO calls its WAF rules a stopgap. The NSA and CISA go further: if you cannot update immediately, take the system offline until it is patched, and CISA says the same for PHP 8.1 or earlier without a fix.

5. Look for signs of compromise since October 17

   Amazon recommends looking for POST requests that carry the PHP_SESSION_UPLOAD_PROGRESS string in form uploads. Wiz points to unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, and to unexplained PHP worker churn. Check for new PHP files, unexpected outbound connections and worker processes that spawn shells. For systems that were not updated immediately, the UK NCSC advises looking for backdoors before you treat them as clean.

6. Retire end-of-life PHP and test what attackers can reach

   Plan the move off PHP 8.1 and older now, and off 8.2 before its December 31 end of life. Then check your exposure from the outside. Autonomous Penetration Testing runs a full penetration test of the scope you authorise, such as your internet-facing URLs, and reports verified findings within hours. Because our pricing is per test, you can run it again after every significant change, not once a year.

Pressing questions

• We do not develop in PHP. Can we still be affected?

  Yes. PHP powers many off-the-shelf tools, such as content management systems, webmail, database admin tools and hosting control panels, and it is embedded in some network and storage appliances. Ask your hosting provider and every vendor whose product exposes a web interface whether it runs PHP and when they patched.

• Is PHP2Shell being exploited?

  Attempts are widespread: Amazon calls it broadly exploited, and Cloudflare counts millions of attempts. As of October 22, however, CISA had not added either CVE to its exploited catalogue, and researchers reported that public exploits fail against default installations. Private exploits that work exist, so treat every unpatched internet-facing server as at risk.

• Are the mitigations or a WAF enough?

  No. The PHP project says only an update is a complete solution and that its mitigations "do not make an installation safe". CISA says a WAF "may provide some protection" until systems are updated. Use both to buy hours, not weeks.

• Should we take systems offline like the governments did?

  Where you cannot update immediately, the NSA and CISA advise it until the systems are patched; the UK NCSC and the joint EU statement present taking systems offline or isolating them as an option to consider. For most systems, patching and restarting workers is faster than an outage.

• Is it safe to test our servers with a public exploit?

  No. Some public proofs of concept are fake, unverified exploit code can be laced with malware, and watchTowr says the exploits being sprayed either do not work, only test for timing differences, or crash the target. Verify patches through package data. For an outside view of what attackers can reach, use authorised testing built for production: Cyberware's Autonomous Penetration Testing uses non-destructive techniques, avoids denial-of-service payloads and reports only findings with verified proof of exploit. It complements patch verification rather than replacing it.

Key takeaways

PHP2Shell is a pair of flaws in the runtime beneath much of the web, not in a single application, which is why governments took sites offline and agencies on both sides of the Atlantic told organisations to patch immediately. Exploitation attempts are widespread, public exploits are still unreliable, and working private exploits exist. The window for a calm, complete response is short.

Update the runtime, restart every worker, confirm fixes by CVE rather than by version string, look for compromise back to October 17, and press your suppliers for the same answers. Then verify from an attacker's point of view: Autonomous Penetration Testing shows what is reachable and exploitable on your internet-facing systems, so the next runtime flaw finds fewer forgotten doors.