PHP2Shell: Incident Report on the October 2026 PHP Emergency

Abstract. On 20 and 21 October 2026, two critical memory-safety vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619 (collectively "PHP2Shell"), went from embargoed research to public knowledge within about one day. Both are rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution on servers that run PHP, independent of the application code on top. The CVE identifiers leaked before the coordinated disclosure date, the PHP project moved its release forward by one day, and public bodies in several European countries took websites offline as a precaution. This report reconstructs the timeline, summarises the technical root causes, describes the observed impact and response, and discusses what the incident means for operators of PHP-based systems. It reflects public sources available on 22 October 2026, about 06:00 UTC.

1. Introduction

PHP is the server-side language behind a large share of the web: content management systems such as WordPress, Drupal, TYPO3 and Joomla, shop systems such as Magento, Shopware and WooCommerce, and countless custom applications. W3Techs currently reports PHP for 69.3 % of the websites whose server-side language it can detect; much of the coverage of this incident rounds this to about 70 % [22, 19]. PHP is also embedded in third-party products such as hosting control panels, firewall distributions and appliances; NCSC-NL maintains a public list of affected products [13, 27].

Most PHP security issues affect a single extension or a single application. PHP2Shell is different: the flaws sit in the interpreter's request lifecycle and memory handling. A vulnerable PHP version is therefore exposed even if the application itself has no bug. Wiz reports that even a "Hello World" script can be vulnerable [7]. This combination of reach and pre-authentication impact explains the scale of the reaction.

2. Method and sources

This is a desk study based on public sources. We give priority to primary sources: the PHP project's advisories and release announcements [1, 2], the GitHub security advisories of php-src [3, 4], the PHP Foundation's post-incident statement [5] and the write-ups of the discoverers [6, 7]. Next come cloud and security vendors [8, 9, 10, 11, 12], national authorities [13, 14, 15, 16] and established news reporting [17, 18, 19, 23, 24]. Where sources disagree, we say so instead of choosing one. Statements about exploitation in the wild are reported with their source and time, because they changed during the day. We have not reproduced the exploits.

3. Timeline

All times are UTC. Times marked "approx." are approximate in the cited source.

4. Technical analysis

4.1 The two CVEs

The PHP project describes the vulnerabilities as follows [1, 3, 4]:

• CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partly initialised. Request cleanup may then treat the invalid data as valid. Historically, PHP leaves the current context with longjmp() when it runs out of memory. An attacker can trigger the memory error on purpose, for example with crafted multipart (file-upload) requests.
• CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp): request-owned internal state, for example error, session, object or extension state, can survive after its memory has been freed. A later request handled by the same worker process may use this stale state before normal initialisation resets it. The result is a use-after-free.

Both advisories use the CVSS v4.0 vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (base score 9.2). The flaws can be reached over the network without privileges or user interaction. The attack is rated as high complexity and depends on preconditions, but impact on confidentiality, integrity and availability of the vulnerable system is high. Both advisories list CWE-416 (use after free), CWE-755, CWE-824, CWE-1325 and CWE-1419 [3, 4].

4.2 Exploitation primitives reported by researchers

Wiz describes four concrete bugs behind the two CVEs [7]:

1. a use-after-free in the session upload progress unserializer, after a fatal allocation failure;
2. a remote memory disclosure via a stale session-ID pointer returned in a PHPSESSID cookie. According to Wiz, it can expose worker memory containing data from outside the attacker's request, such as passwords, tokens, API keys or certificates, and works even if the application never calls session_start();
3. a use-after-free in the fatal-error backtrace (fatal_error_backtraces, new in PHP 8.5);
4. an OPcache type confusion after a failed script persistence.

The assignment of these bugs to the two CVE numbers is not consistent across sources. Wiz assigns the upload-progress and memory-disclosure bugs to CVE-2026-109618 and the backtrace and OPcache bugs to CVE-2026-109619 [7]. The PHP project, by contrast, lists both the session upload-progress path and the fatal-backtrace path as confirmed paths of CVE-2026-109619 and gives the corresponding mitigations under that CVE [1, 4]. Chained together, the primitives gave the researchers unauthenticated RCE against current WordPress, Drupal and Joomla images [7]. Calif reports pre-authentication RCE also against Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS [6, 9].

4.3 Affected configurations and versions

• Server APIs: according to the PHP project, all PHP installations that serve web requests are at risk: 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 [1]. For the OOM path, the advisory notes that no complete FPM exploit has been shown, while the session upload-progress path was validated against both mod_php and FPM [3, 4].
• Versions: patched are 8.2.35, 8.3.36, 8.4.27 and 8.5.12 [1, 3, 4]. The vulnerable code paths are reported to go back to PHP 5.4 (2012) [6, 8, 9].
• End-of-life branches: PHP 8.1 and older receive no official releases. The PHP project published minimal source backports for 7.4, 8.0 and 8.1. There is no patch for PHP 5 [1, 11].
• Distributions: distributions and LTS vendors received the patches in advance [1]. Their packages may contain backported fixes without the upstream version number. The PHP project itself warned that the widely used volunteer-maintained Remi repository (rpms.remirepo.net) would have no update on 21 October [1, 9, 10].

4.4 The fix

The patch removes the longjmp() exit for out-of-memory situations. Instead, PHP signals a delayed "soft" OOM at the next safe point of the virtual machine and terminates hard with _exit() if memory use reaches a second, higher threshold [3]. For CVE-2026-109619, the releases add a reset of the wider request state before it can be reused [4]. The OOM change alters a long-standing design decision of the engine. The PHP Foundation states that competing fixes with different trade-offs (compatibility, denial of service, changes to third-party extensions) were among the reasons the problem stayed unfixed after 2024 [5].

5. Observed impact

5.1 Exploitation in the wild

The evidence was contradictory on 21 October and should be read with its time stamps:

• According to Sansec, Cloudflare's CTO reported first attacks at 07:43 UTC, before the release [9]. Cloudflare states that its default WAF protections had been active since 03:02 UTC and that it observed attack traffic and payload modifications aimed at evading its rules [12].
• watchTowr lists exploitation "in the wild", observed in its honeypot network from 21 October [11].
• The PHP Foundation states that the PoCs circulating after the leak that it inspected were not functional exploits at the time of release [5]. The BSI reported no confirmed exploitation in its update of 21 October [13].
• Huntress had not seen exploitation on partner systems as of 21 October, 16:30 ET (20:30 UTC) [10]. According to NBC News, CISA had "not observed exploitation" at the time of its advisory; according to Safeguard's compilation of Reuters reporting, the Australian Cyber Security Centre was not aware of active exploitation [19, 20].
• Neither CVE was listed in CISA's Known Exploited Vulnerabilities catalogue (catalogue version of 21 October 2026, checked on 22 October) [16].

We found no confirmed public report of a compromise attributed to PHP2Shell as of the cut-off time. Given published technical details and the number of exposed systems, this can change quickly.

5.2 Precautionary shutdowns

The most visible consequence was not compromises but deliberate outages. According to Reuters reporting [17, 18]:

• Netherlands: NCSC-NL took its own website offline as a precaution. Many organisations followed, including the government portal Overheid.nl, the Port of Rotterdam, the football association KNVB, the websites of the five largest political parties and several hospitals.
• Finland: the state IT provider Valtori took the government's public network services offline as a precaution. It said it had found no attempt to exploit the flaws.
• Denmark: the municipal IT company Kombit took several services offline, including the national school communication platform.
• France: the Interior Ministry temporarily took prefecture and local administration websites offline pending the fix.
• Germany, Belgium and the Czech Republic: ITZBund took several federal websites offline as a preventive step; a ministry spokesperson said no security incidents were known. The Belgian foreign ministry temporarily did the same. The Czech government took its website offline on the recommendation of the national cyber security authority.
• Beyond government: the Wikimedia Foundation took several PHP-based systems down as a precaution [17]. In Japan, media reported voluntary shutdowns of some sites, including daycare systems and video games, and Sakura Internet suspended a database appliance function [18, 19].

5.3 Advice from authorities

Advice ranged from "patch now" to "consider going offline":

• The German BSI issued an IT security notice at criticality level 3/orange (BITS-H 2026-297981-1132, version 1.1 of 21 October 2026). It recommended considering a temporary disconnection from the internet for systems that cannot be patched immediately, because the workarounds do not provide complete protection [13].
• CERT-EU advised patching immediately and, where this is not feasible, isolating internet-facing applications from public networks until the fix is applied and verified [14]. The UK NCSC advised updating, applying the temporary mitigations and, if they cannot be applied quickly, considering taking systems offline. It also asked organisations that cannot update immediately to check for evidence of compromise and backdoors [15].
• CISA recommended patching; NBC News did not report a CISA recommendation to take systems offline [19]. According to NBC News, the US NSA recommended potentially taking sites offline until they are fixed [19].

6. Response by the ecosystem

• Cloud and CDN providers: Google patched App Engine standard (PHP 8.2 and newer) automatically, as well as Cloud Run services and functions with automatic base image updates, and published Cloud Armor guidance. App Engine flexible, GKE and self-built containers must be rebuilt or redeployed by the customer [8]. Wiz thanks Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft and Vercel for guidance and default protections [7].
• Interim mitigations from the PHP project [1]: memory_limit=-1, preferably enforced so that applications cannot override it (for example with php_admin_value), low post_max_size, container or cgroup memory limits (not RLIMIT_AS/RLIMIT_DATA), session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0. The session and backtrace settings must be applied before request parsing, for example in php.ini or the FPM pool, not with ini_set() or .user.ini, and all workers must be restarted. The PHP project is explicit: "There are no complete mitigations, updating is the only safe choice." [2]. Some of these measures have side effects: an unlimited memory limit lets a single request use up server memory [9].
• Detection guidance: watch for PHP workers that start shells or network tools, unusual multipart requests followed by memory errors, repeated HTTP 500 responses, unusually large or malformed PHPSESSID cookies, unexplained worker churn and new files in the web root [7, 10].

7. Discussion

Embargo failure. The planned disclosure on 22 October did not hold. The leak of the CVE identifiers on 20 October led to a release one day early, on 21 October [5]. In addition, Chainguard published built images with the fix more than six hours before the coordinated release; according to the PHP Foundation, this allowed attackers to study the fix in binary form. Chainguard rejects the description as a leak [5, 23]. The incident is consistent with a known lesson: the more parties a coordinated disclosure involves, the higher the risk of early exposure. Operators should treat the announcement of a security release, not the release itself, as the start of their response.

AI-assisted discovery. All three reporting parties (Calif, OpenAI and Wiz) worked with large language models [5, 6, 7]. Wiz names Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol and credits AI with contributions to discovery, exploit development and patch validation [7]; Calif describes an "LLM companion" and agents [6]. Chainguard says it independently found the same bugs with an AI model after learning that a disclosure was coming [23]. The underlying problem class is old: an exploitable memory_limit flaw was documented in 2004 [25], and the 2024 finding was deprioritised because no concrete exploitation vector had been found [5]. If AI tools make such "theoretical" bugs practical faster, assumptions about exploitability will need to be reviewed more often.

Engine-level risk. Application security and plugin updates do not help against a flaw that triggers during request parsing, and WAF rules are at best a stopgap [12, 13]. Sansec points out that maintenance modes of CMS do not help either, because PHP parses the request before the application checks the flag [9]. The interpreter version is a security dependency in its own right and must be part of every inventory.

End-of-life versions. Servers on PHP 8.1 or older depend on distribution backports, community patches or an unscheduled upgrade. PHP 8.2 itself reaches end of life on 31 December 2026 [2].

8. Limitations

This report is based on information that was in part preliminary and contradictory. Some details, especially exploitation status, shutdown lists and early timeline events, come from secondary reporting that we could not check against a primary statement in every case. We did not test the vulnerabilities ourselves. We will update this report if important corrections become known.

9. Recommendations for operators

1. Inventory every place PHP runs: web servers, hosting accounts, control panels (cPanel, Plesk), containers, appliances and vendor software.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a distribution package that lists CVE-2026-109618 and CVE-2026-109619 in its changelog. Restart all PHP workers afterwards.
3. Bridge systems that cannot be updated right away with the PHP project's interim settings, a WAF or provider protection, or isolation, and treat them as at risk until they are patched.
4. Check for compromise on systems that were exposed between 20 October and the update: new files in the web root, unknown cron jobs or accounts, outgoing connections from PHP processes. Consider rotating secrets that a memory disclosure could have exposed.
5. Plan the move away from PHP 8.1 and older now, and from PHP 8.2 before the end of 2026.

10. Conclusion

PHP2Shell is arguably among the most serious vulnerabilities in the history of PHP: pre-authentication, in the interpreter itself, in versions going back more than a decade, and published under time pressure after a leak. The fixes were available on the day of disclosure. Whether the incident ends with precautionary outages or with widespread compromises depends on how fast operators update.

If you are unsure whether your website, shop or hosting is affected, we are happy to help with an assessment.

Contact us

References

1. PHP project: Security advisory, critical remote code execution vulnerabilities, update now (21 Oct 2026); Upcoming critical PHP security release (advance notice, 20 Oct 2026)
2. PHP project: PHP 8.2.35 released (21 Oct 2026); identical notes for 8.3.36, 8.4.27 and 8.5.12
3. php-src GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618), published 21 Oct 2026, 13:34 UTC
4. php-src GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619), published 21 Oct 2026, 13:34 UTC
5. The PHP Foundation: Today's PHP security release and how we're strengthening PHP security (21 Oct 2026)
6. Calif (Ryan Austin): PHP2Shell (21 Oct 2026)
7. Wiz Research: PHP2Shell (21 Oct 2026)
8. Google Cloud: Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (21 Oct 2026)
9. Sansec: PHP2Shell, critical PHP RCE (CVE-2026-109618, CVE-2026-109619)
10. Huntress: Rapid Response, php2shell, leaked critical PHP vulnerabilities
11. watchTowr: PHP Remote Code Execution FAQ, CVE-2026-109618
12. Cloudflare: Cloudflare deploys protections against php2shell vulnerability (21 Oct 2026)
13. BSI: IT-Sicherheitshinweis BITS-H 2026-297981-1132, Version 1.1 (21 Oct 2026), PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit
14. CERT-EU: Security Advisory 2026-018, Critical vulnerabilities in PHP (21 Oct 2026)
15. UK NCSC: Critical security issue affecting PHP (21 Oct 2026)
16. CISA: Known Exploited Vulnerabilities Catalog (version 2026.10.21, accessed 22 Oct 2026)
17. Reuters (via Euronext): Factbox, websites taken offline over PHP risks (21 Oct 2026)
18. Reuters (via RTÉ): Websites go dark as AI exposes critical security flaws (21 Oct 2026)
19. NBC News: Critical vulnerabilities in PHP spark rush to update systems (21 Oct 2026)
20. Safeguard: Why governments took websites offline on 21 October (secondary compilation of Reuters, NBC News and other reporting)
21. Decrypt: Who found the PHP bug that made governments unplug their websites? (21 Oct 2026)
22. W3Techs: Usage statistics of PHP for websites (accessed 22 Oct 2026)
23. The Register: PHP blames supply chain security biz Chainguard for putting huge chunks of the web at risk (22 Oct 2026)
24. SecurityWeek: PHP2Shell, mass exploitation looms for leaked critical PHP flaws (21 Oct 2026)
25. Stefan Esser (e-matters), Bugtraq, 14 Jul 2004: Advisory 11/2004, PHP memory_limit remote vulnerability
26. php-src: NEWS file at tag php-8.6.0RC4 (21 Oct 2026)
27. NCSC-NL: php2shell, operational information and list of affected products (GitHub)

Status: 22 October 2026, about 06:00 UTC. This report will be updated as new verified information becomes available.