PHP2Shell: Exploitation Before Disclosure a Technical Reference

1. Background

PHP runs most of the web. W3Techs puts it at 69.2 percent of websites whose server-side language it can identify [18]. That figure misses everything that is not publicly indexed: admin consoles, intranet apps, monitoring tools, the management planes of commercial appliances. The appliance category in particular tends to trail upstream PHP by years.

Three groups reported the underlying issues to PHP, and AI models played a part in the research. Calif researcher Ryan Austin reported an unconditional remote code execution on August 11 [2][19]. Calif began its audit on July 30 under OpenAI's Patch the Planet program [2]. Wiz Research reported further attack vectors on August 24. OpenAI Codex Security (the PHP Foundation credits Amy Burnett) independently reported the same root cause on September 18 [2]. Wiz says it used its Wiz Atlas platform with Gemini 4 Argon and GPT-5.6 Sol, and credits Gemini 4 Argon with contributions to discovery, exploit development and patch validation [3].

The out-of-memory weakness was not new. A PHP core developer noticed it in 2024 during an audit by OSTIF and Quarkslab, but the fix stalled and restarted for months, which the PHP Foundation calls "a structural failure" [2]. A narrower out-of-memory bug in multipart parsing, reported in 2019 as PHP bug #78876, was fixed in 2020 as CVE-2019-11048 [32]. That fix closed one trigger, not the cleanup paths that assume an allocation cannot fail partway through. As Steve Gibson put it on Security Now, the problem was known and tolerated because nobody had shown it was exploitable [33].

The bugs are in the PHP engine, below WordPress, Drupal or whatever else runs on top. Input validation, application-specific WAF rules and CMS hardening guides do nothing about a flaw in the runtime. If the PHP binary is affected, the endpoint is affected, whatever application it serves.

Wiz got pre-authentication RCE against the stock wordpress, drupal and joomla container images at their latest tags [3]. A CMS is not required, though. Wiz notes that a bare "Hello World" script on an affected version can be vulnerable. No special feature, configuration option or uploaded file is needed. PHP rates Apache mod_php as the highest-risk deployment because a demonstrated exploit there fires before any application code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also in scope [1][6].

2. Vulnerability analysis

2.1 CVE-2026-109618: Out-of-memory bailout leaves memory uninitialized

PHP hands out per-request memory through the Zend memory manager, which enforces memory_limit. When a request hits that limit, PHP bails out with longjmp(). The bailout is supposed to unwind the stack and release request resources cleanly. Multipart form-data parsing happens during request startup, before normal module initialization and before any application code. It gives an attacker one easy way to push a request into that condition [1][3].

The flaw sits in code that never expected an allocation to fail halfway through an operation. Those paths leave request memory uninitialized or half-built, and the cleanup routine then reads or branches on it [7][21]. PHP's mitigation list for this CVE includes post_max_size limits, which cap how large a multipart body can get [1].

An attacker who controls the size and structure of a request gets some say over when the bailout fires and what sits in memory when it does. On October 24 a researcher recorded 35 successful shell executions against honeypots running PHP 8.4.26 under mod_php. The attacks used memory exhaustion and disclosure, and the activity was consistent with this CVE, with no sign the second flaw was involved [20].

CVSS 4.0: 9.2 (Critical). Attack Complexity High and Attack Requirements Present reflect the memory pressure and heap shaping an exploit needs. Under CVSS 3.1 the same flaw scores 9.8 [7][21].

2.2 CVE-2026-109619: Stale global state across requests

PHP keeps several pieces of global state that briefly point into per-request memory. The session ID is one. The fatal-error backtrace added in PHP 8.5 is another. When a fatal error triggers the bailout, some of that state is not reset, or gets repopulated after the reset, and keeps pointing at memory that has already been freed [7][21].

PHP-FPM and mod_php workers serve many requests over their lifetime. So the next request that lands on the same worker can read that stale pointer. One request poisons the worker and a later one triggers the use-after-free [3][8]. If the attacker can shape what gets allocated into the freed region, PHP ends up treating attacker-influenced bytes as a trusted internal object.

Wiz used the fatal-error backtrace path to get unauthenticated RCE on Drupal. It also built a separate WordPress chain from an OPcache type confusion, where an allocation failure during script persistence knocks a process-local pointer out of sync with shared memory [3]. Only Wiz ties the OPcache variant to these CVEs. PHP's advisory for CVE-2026-109619 does not mention OPcache [21].

Worker reuse is a precondition, but not much of a barrier. PHP's advisory says that running more workers, or recycling them often, lowers the success rate per request without removing the condition [21].

CVSS 4.0: 9.2 (Critical). Same vector as CVE-2026-109618. Under CVSS 3.1 this flaw scores 8.1. The 3.1 score is lower because attack complexity is rated High [7].

2.3 Which CVE covers the session bugs

Sources disagree on which CVE covers the session upload-progress use-after-free and the PHPSESSID memory leak. Wiz's write-up files both under CVE-2026-109618 [3]. PHP's own advisory for CVE-2026-109619 names the session upload-progress path, and PHP lists session.upload_progress.enabled = 0 as the mitigation for that CVE [1][21]. This brief follows PHP's mapping. Operationally it changes nothing, because both fixes ship in the same release.

A fatal allocation failure leaves the session ID pointing at freed memory. A later multipart request then gets whatever heap contents landed there URL-encoded into the PHPSESSID cookie of the response. It works even when the application never calls session_start(). Wiz paired that leak with the unserializer use-after-free to remove the address guesswork, and got RCE on WordPress, Drupal and Joomla [3].

Expect more variants. Wiz says further bugs of the same pattern will be folded under these two IDs [3]. Two days after the release, PHP published an informational advisory on another upload-progress variant, CVE-2026-115560, which the same configuration change covers [1].

3. Affected versions

The vulnerable code dates to PHP 5.4, released in 2012. Nearly every release since carries at least one of the issues, and which variants apply depends on version and configuration [3][5]. On October 21 PHP shipped fixed releases for all four supported branches: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 [1].

There is no official release for 8.1 or older. PHP's security team did publish minimal source backports for 7.4, 8.0 and 8.1, and distributions and long-term-support vendors received patches ahead of disclosure [1][2]. Ubuntu shipped fixed php8.1 packages for 22.04 LTS. Under Expanded Security Maintenance it also covered php7.4 on 20.04, php7.2 on 18.04, php7.0 on 16.04 and php5 on 14.04 [16]. Red Hat issued RHSA-2026:87151 and RHSA-2026:87080 for the EL8 php:7.4 stream and EL9 PHP 8.0. cPanel, CloudLinux and Ondřej Surý's repositories also carry backports [22]. PHP 7.3 and older get nothing from the PHP project.

Table 1. PHP branch status and fix availability [1][16][17]

Upstream releases only help the supported branches, which make up well under a third of the PHP installations Qualys can see [9]. Everything else depends on a distribution or vendor backport, an upgrade or a compensating control.

3.1 Vendor-bundled PHP and appliances

Commercial products that bundle PHP run on their own patch clock. That includes CMS and e-commerce platforms, network management tools and security appliances. A vendor may ship fixed PHP before or after upstream, and may carry changes that alter exploitability. Read the vendor advisory. Do not assume the upstream patch maps onto the vendor build.

Several network and security vendors have confirmed affected products (Section 3.2), and at least one appliance campaign is on record. The security firm Dream reported on October 26 that attackers chained a private PHP2Shell exploit with the Linux kernel privilege-escalation CVE-2026-46300 ("Fragnesia") to obtain root on 24 perimeter firewalls and one internal firewall management server in the United States, Japan, Taiwan and South Korea. Dream initially left the vendor unnamed. Its October 29 update identifies the devices as running Palo Alto Networks PAN-OS, and says Unit 42 tracks the activity as CL-UNK-1280 [24]. Tenable reports that Unit 42 independently verified the tooling, though Tenable has not verified the findings itself. CISA added Fragnesia to the KEV catalog on October 28 [34].

Hosting control panels belong in the same category, and they can hide a second PHP on a host that looks patched. Plesk runs its own interface on a separate built-in PHP engine (sw-engine on Linux, plesk-engine on Windows). That engine stayed vulnerable until Plesk Obsidian 18.0.80 Update 11 or 18.0.81 Update 4, whatever PHP version the hosted sites used [35]. Plesk's patched builds for the EOL branches (7.4.33, 8.0.30 and 8.1.34) keep their old version numbers. Only a build date of October 21, 2026 or later shows the fix [35].

3.2 Appliance vendor advisories

Table 2 reflects each vendor's own advisory as of October 29. Advisories change often, so check the current version before acting, and ask any vendor not listed here.

Table 2. Network and security vendor product impact, as of October 29, 2026

Where vendors say how the bug is reached, it is through a management or portal web interface. Treat every appliance web UI that connects to the internet as in scope until its vendor says otherwise, and restrict management access to trusted internal addresses regardless.

4. Scope and scale of exposure

Exposure counts swing by an order of magnitude depending on who is counting and what they count. Palo Alto Networks Cortex Xpanse found more than 22.6 million exposed instances potentially vulnerable when Unit 42 published its threat brief [10]. TechTarget's "22M" headline is the same number [11]. Censys counted more than 4.18 million hosts and 67.5 million web properties running PHP, and assessed more than 34.4 million PHP services as still vulnerable on October 23 [14]. By October 29 Censys still counted about 30.3 million PHP services on an affected version [34]. Estimates quoted by Tenable put internet-facing hosts between 1.3 million and 1.9 million [6]. VulnCheck found PHP on about 2.6 million internet-facing hosts, rated 99.998 percent of them vulnerable or likely vulnerable, and put about 42 percent on EOL branches [36]. These figures measure different things. Use the one that matches your question.

Qualys counts from its customers' internal and external asset inventories. It sees about 167 million PHP package installations, 156 million with a known version and 73 percent of those are internet-facing [9]. About 110 million (71 percent of known versions) run end-of-life branches 5.4 through 8.1. About 44 million (28 percent) run the supported 8.2-8.5 branches. The EOL majority has no official upstream release available for installation.

Patching started slowly. Qualys counted roughly 199,000 installations patched in the first 12 hours, a rounding error against its install base [9]. It picked up over the following week. Wiz reported an approximate 67 percent drop in the daily count of distinct internet-exposed vulnerable machines. Wiz also said fewer than 53 percent of initially affected organizations were still vulnerable one week after disclosure [4]. Put another way, close to half of affected organizations still had something exposed a week in. What remains is most likely weighted toward EOL branches and vendor-bundled PHP.

Bitsight's rescans, published October 29, show where the remainder sits. Of 9.47 million hosts it saw on a vulnerable version before the release and scanned again afterward, 33.5 percent ran a patched build by October 27. On the supported 8.2 to 8.5 branches, 68.6 percent of 4.13 million hosts patched within a week (77 percent on 8.5 and 8.4, 66 percent on 8.3, 62 percent on 8.2). On EOL branches, only 6.4 percent of 5.34 million hosts were patched, and 91 percent of the 1.73 million PHP 7.4 hosts were still on 7.4 at the end of the week [37].

The default WordPress, Drupal and Joomla images were all exploitable at the time of disclosure [3]. Treat every unpatched instance as an entry point, including the staging site nobody watches.

Internal PHP counts too. The exploit only needs a network path to the server, so dev servers, admin panels and old intranet apps are all reachable once an attacker is inside. Plan for lateral movement from a compromised internet-facing PHP host to internal PHP on the same segment.

5. Exploitation timeline

Table 3 lists the sequence. Times are UTC unless noted.

Table 3. PHP2Shell chronology, 2026

Between October 17 and October 21, a team that waited for CVE publication to start work had no public signal to act on. The only protections in place before the release came from security vendors inside the embargo, delivered as WAF rules and intrusion prevention signatures [10][12].

Attempts have far outpaced confirmed compromise. The CVSS 4.0 vector rates attack complexity as High. The PHP Foundation found no functional exploits at the time of release [2], and reliable exploitation appears to need memory-layout knowledge specific to version and configuration [6]. The researcher behind the 35 honeypot shells warns that his favorable setup does not reflect how reliably the exploit works against production servers [20]. Attempt volume is not compromise volume, though the gap is likely to narrow as working exploits spread.

A commercial exploit already covers much of that version spread for mod_php. VulnCheck had a working exploit for CVE-2026-109618 by early October 22. By October 26 it worked with ASLR enabled, default settings and display_errors off under mod_php on PHP 8.2.28 to 8.2.34, 8.3.22 to 8.3.35, 8.4.10 to 8.4.26 and 8.5.10 to 8.5.11, on x86-64 and, for 8.4 and 8.5, ARM64 [36]. It is sold to VulnCheck's Initial Access Intelligence customers and is not public. The public ASLR-bypass proof of concept VulnCheck tested worked only on 8.4.26 [36]. Tenable's testing shows the limit for everyone else: each working exploit it built had to be fitted to the target's PHP build, SAPI, extensions and configuration, and offsets change with every patch release. Network appliances are the exception, because one tuned exploit reaches every device running the same build [34].

6. Detection and remediation guidance

6.1 Inventory

Start with an inventory, and expect it to be incomplete. PHP hides in vendor software, admin interfaces and legacy boxes that never made it into the CMDB.

• Pull PHP version banners from internet-facing HTTP(S) endpoints. If your attack surface management platform has published a PHP2Shell rule, make sure it is enabled.
• Query internal asset inventories and software composition analysis tools by PHP version range.
• Check container registries and deployment manifests for PHP base image versions.
• Cross-reference vendor products that bundle PHP against their advisories, starting with firewall and appliance management planes.
• List every PHP binary and handler on each host, not just the one serving the main site. Control panels such as Plesk and cPanel, webmail such as Roundcube and handlers left over from older PHP versions often sit side by side. Remove the handlers nothing uses [33][35].
• Check the PHP version actually running. Updated packages do not patch PHP processes that are already in memory [6]. Backported EOL builds often keep their old version string, so a version banner can mark a patched host as vulnerable. Confirm by package release or build date [35].
• Do not use public proof-of-concept code to test exposure. Hundreds of PoC repositories appeared after disclosure and very few are legitimate exploits [36]. Use vendor scanners or authenticated version checks.

6.2 Prioritization

Exploitation began before disclosure, and CISA gave federal agencies until October 29. Anything internet-facing needs attention now, whether a patch exists or not. Systems with a clean patch path should go first.

Table 4. Remediation priority by exposure

If a host may already be compromised, capture PHP worker memory before you restart it, and hunt back to October 17, the earliest known attempt [6].

6.3 Compensating controls

PHP's own line is blunt: "There are no complete mitigations, updating is the only safe choice" [1]. The controls below reduce exposure while patches go in.

Inline prevention

Inline inspection that parses application-layer traffic can catch and drop the malformed multipart requests this exploit class depends on. Confirm your tooling has signatures for both CVEs and that they are enabled on the traffic paths that actually reach PHP.

PHP configuration

PHP published interim settings that reduce exposure without removing it [1]:

• For CVE-2026-109618, set memory_limit = -1 in a way applications cannot override (php_admin_value or equivalent), and enforce memory with a container or cgroup limit instead. Do not use RLIMIT_AS or RLIMIT_DATA, which hit the same failure paths. Set post_max_size = 8M where uploads are not needed, or 32M where they are, and keep upload_max_filesize below post_max_size.
• For CVE-2026-109619, set session.upload_progress.enabled = 0 and, on PHP 8.5, fatal_error_backtraces = 0. PHP says this blocks the confirmed session paths but not other variants.
• Set all of these in server configuration. Do not rely on ini_set() or .user.ini. Restart every worker afterward.

watchTowr goes further and says .ini mitigations "should be understood to be ineffective" [8]. Treat them as a stopgap until the patch is in.

Web application firewalls

WAFs help on internet-facing endpoints, within limits. They match known request patterns. They will not see direct PHP-FPM connections, unusual request routing or private variants that miss the published rules. Cloudflare pushed rules to every plan including Free, describes them as an additional layer and still tells customers to patch [12]. Check WAF coverage against your actual topology before you count it as a fix.

Segmentation

Review segmentation around PHP hosts, EOL ones above all. A PHP web process has no business talking directly to credential stores or internal databases unless it truly has to. Tighten the rules that allow it today.

Temporary disconnection

When a system cannot be patched quickly, taking it off the network is the most complete control available. The NSA's October 21 advisory told organizations that could not update immediately to take systems offline until fully mitigated [38]. CERT-EU advised isolating internet-facing applications until the fix was installed and verified [39]. Many organizations did so as a precaution, including the Port of Rotterdam, the Dutch government portal Overheid.nl, several German federal agencies and the French Interior Ministry's prefecture sites [39][40].

Steve Gibson argues for making this a planned option rather than an improvised one [33]. Decide in advance who can authorize a temporary disconnect, which services it covers and how it will be communicated, so the call takes minutes instead of a meeting when the next embargoed disclosure lands (Section 7).

6.4 Detection indicators

Web server and PHP logs

• Oversized or deeply nested multipart request bodies, especially ones built to maximize allocation during parsing [8].
• PHP memory-limit errors ("Allowed memory size of N bytes exhausted") that line up with specific inbound requests. Repeated hits from one source suggest deliberate triggering [3][8].
• Large or malformed PHPSESSID cookies in responses, or repeated HTTP 500 responses after multipart requests. Both point to the memory disclosure step [3].
• PHP-FPM workers crashing or restarting more often than traffic explains [3][8].

Host

• The web server account (www-data, apache, nginx or equivalent) spawning shells or system utilities [8][10].
• Outbound connections from PHP processes, including attempts through PHP, curl or wget, or connections to internal segments the web server never normally touches [8][20].
• New files in the webroot or other directories the web server account can write to, including web shells [8].
• New cron jobs or local accounts [8].

6.5 End-of-life PHP

If you run 8.1 or older, treat the upgrade as security remediation, on the same clock as a patch. Apply a backport today if one exists. Then plan the migration anyway. EOL branches will not get the next fix, and the next variant has already arrived: PHP published CVE-2026-115560 two days after the release [1]. Migration often means compatibility testing and some code changes. Staying put means waiting for the next one of these with no patch path at all.

Where the migration cannot move fast enough, write the compensating controls down as a formal risk acceptance with an owner and a review date. Undocumented EOL servers that rely on the perimeter tend to fall outside vulnerability management entirely.

7. Implications for response planning

Plenty of CVEs score above 9. PHP2Shell's bug sits in the runtime under most of the web, and most of that installed base cannot take the official fix. Seventy-one percent of the PHP that Qualys can see runs a branch the PHP project no longer patches [9].

Response processes that start at CVE publication were already behind on October 17. Teams that were protected before the release got that protection from vendors inside the embargo. Ask your vendors whether they were inside this one, and how many hours it took their protections to reach your traffic.

The underlying weakness was known before anyone showed it was exploitable. The out-of-memory problem surfaced in a 2024 audit, and the fix stalled for months (Section 1) [2]. AI-assisted research has shortened the time between a known weakness and a working exploit. Findings that have sat open because nobody demonstrated an exploit, in your own code or in your vendors', deserve a second look.

Expect more of these. OpenAI says the PHP bugs are among several significant vulnerabilities it has already found and expects such findings to increase sharply [41]. Cloudflare CEO Matthew Prince told The Atlantic, as quoted on Security Now, that he knows of more vulnerabilities that will be announced soon [33]. The PHP Foundation expects the number of reports to keep growing [2]. Plan for the next embargoed disclosure now, including the disconnect decision in Section 6.3.

References

[1] The PHP Group. News archive 2026: advance notice (Oct 20), security release for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (Oct 21), informational advisory on session upload progress (Oct 23). https://www.php.net/archive/2026.php

[2] The PHP Foundation. "Today's PHP Security Release and How We're Strengthening PHP Security," October 21, 2026. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

[3] Wiz Research. "PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet," October 21, 2026. https://www.wiz.io/blog/php2shell-php-rce

[4] Wiz Research. "PHP2Shell: Exploitation Attempts and Remediation Trends," October 27, 2026. https://www.wiz.io/blog/php2shell-exploitation-so-far

[5] Calif and Wiz. PHP2Shell vulnerability information site. https://www.php2shell.com/

[6] Tenable Research. "php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions," updated October 28, 2026. https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote

[7] Tenable. CVE records for CVE-2026-109618 and CVE-2026-109619. https://www.tenable.com/cve/CVE-2026-109618 and https://www.tenable.com/cve/CVE-2026-109619

[8] watchTowr Labs. "PHP2Shell RCE Exploited: CVE-2026-109618 and CVE-2026-109619." https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/

[9] Qualys Threat Research Unit. "PHP2Shell: Find, Mitigate, and Patch Now," updated October 28, 2026. https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities

[10] Palo Alto Networks Unit 42. Threat brief: CVE-2026-109618 and CVE-2026-109619, first posted October 21, 2026, with later updates. https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/

[11] TechTarget. "PHP2Shell: 22M Exposed Servers at Risk as Emergency Patches Released," October 21, 2026. https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released

[12] Cloudflare. "Cloudflare Deploys Protections Against php2shell Vulnerability," October 21, 2026. https://blog.cloudflare.com/php-vulnerabilities-waf-protection/

[13] The Hacker News. "Someone Tried to Exploit PHP2Shell 4 Days Before the Vulnerabilities Were Publicly Disclosed," October 22, 2026. https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html

[14] The Hacker News. "PHP2Shell Exploit Attempts Hit Millions as Attackers Try to Deploy Mirai Malware," October 23, 2026. https://thehackernews.com/2026/10/php2shell-exploit-attempts-hit-millions.html

[15] CISA. Known Exploited Vulnerabilities Catalog, CVE-2026-109618 and CVE-2026-109619, added October 26, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

[16] Canonical. "php2shell (CVE-2026-109618 and CVE-2026-109619): Fixes Available," October 2026. https://ubuntu.com/blog/php2shell-vulnerability-fixes-available

[17] The PHP Group. "Supported Versions" and "Unsupported Branches." https://www.php.net/supported-versions.php and https://www.php.net/eol.php

[18] W3Techs. "Usage Statistics and Market Share of PHP for Websites," accessed October 29, 2026. https://w3techs.com/technologies/details/pl-php

[19] Calif. PHP2Shell technical write-up. https://calif.io/php2shell.x/

[20] The Register. "CISA Confirms PHP2Shell Under Attack as Researchers Clock Successful Exploits," October 27, 2026. https://www.theregister.com/cyber-crime/2026/10/27/cisa-confirms-php2shell-under-attack-as-researchers-clock-successful-exploits/5305681

[21] PHP security advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). https://github.com/php/php-src/security/advisories

[22] ComputingForGeeks. PHP2Shell backports for end-of-life PHP. https://computingforgeeks.com/php2shell-end-of-life-php-backport/

[23] Palo Alto Networks. Security Advisory CVE-2026-109618 and CVE-2026-109619 (PAN-OS), published October 21, 2026, updated October 29, 2026. https://security.paloaltonetworks.com/CVE-2026-109618

[24] Dream. "Chained PHP2Shell Exploit Roots 25 Servers," October 26, 2026, updated October 29, 2026. https://dreamgroup.com/blog/chained-php2shell-exploit-roots-25-servers

[25] Cisco PSIRT. cisco-sa-php-october26-Jj384Daq, October 21, 2026, updated October 28, 2026. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-php-october26-Jj384Daq

[26] Check Point. sk1000302, October 21, 2026, updated October 28, 2026. https://support.checkpoint.com/results/sk/sk1000302

[27] Citrix. CTX697263, October 22, 2026, updated October 27, 2026. https://support.citrix.com/external/article/CTX697263

[28] Fortinet PSIRT. FG-IR-26-186, October 21, 2026, updated October 28, 2026. https://fortiguard.fortinet.com/psirt/FG-IR-26-186

[29] SonicWall. Product notice: SonicWall products and PHP vulnerabilities, October 22, 2026, updated October 27, 2026. https://www.sonicwall.com/support/notices/product-notice-sonicwall-products-and-php-vulnerabilities-cve-2026-109618-and-cve-2026-109619/kA1VN000002YKw10AG

[30] Sophos. sophos-sa-20261021-php2shell, October 21, 2026. https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell

[31] Broadcom. KB 459989. https://knowledge.broadcom.com/external/article/459989

[32] PHP bug #78876, "Long variables in multipart/form-data cause OOM and temp files are not cleaned" (CVE-2019-11048), closed May 2020. https://bugs.php.net/78876

[33] Steve Gibson. Security Now! episode 1102, "A Strategic Plug Pull," show notes, October 27, 2026. https://www.grc.com/sn/sn-1102-notes.pdf

[34] Tenable Research. "php2shell: Why One Exploit Doesn't Work Everywhere," October 29, 2026. https://www.tenable.com/blog/php2shell-one-week-later-why-one-exploit-doesnt-work-everywhere

[35] Plesk. "Plesk PHP Security Update: CVE-2026-109618 & CVE-2026-109619," October 27, 2026. https://www.plesk.com/blog/security-alerts/blog-plesk-php-security-update-cve-2026-109618-109619/

[36] VulnCheck. "PHP2Shell Vulnerabilities: CVE-2026-109618 and CVE-2026-109619," October 21, 2026, updated through October 26. https://www.vulncheck.com/blog/php2shell-vulnerabilities

[37] Bitsight. "PHP2Shell: What Scanning and Patching Data Reveal," October 29, 2026. https://www.bitsight.com/blog/php2shell-scanning-exploitation-patching

[38] NSA. Advisory on PHP updates, October 21, 2026. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4630238/nsa-advisory-php-updates/ Reported in SecureWorld, "Patch PHP Vulnerability Now or Take It Offline, NSA Warns," October 22, 2026. https://www.secureworld.io/industry-news/patch-php-now-php2shell

[39] Security Today. "PHP Flaws: Security Agencies Advise Taking Sites Offline," October 22, 2026. https://www.securitytoday.de/en/2026/10/22/php-flaws-security-agencies-advise-shutdowns/

[40] eBuilder Security. "PHP2Shell Forces Government Websites Offline Across Europe," October 22, 2026. https://ebuildersecurity.se/en/cyber-news/php2shell-government-websites-offline-europe/

[41] OpenAI. "Patch the Planet: Global Response Coordination as Agents Uncover Critical Vulnerabilities," October 2026. https://openai.com/index/coo