Last week, PHP2Shell was a serious warning: two critical flaws in the software that runs most of the world's websites, with attackers probing for them before a fix even existed. This week, it is an active threat. On October 26, the US Cybersecurity and Infrastructure Security Agency (CISA) formally confirmed that the flaws are being exploited in real attacks and ordered federal agencies to fix them by October 29. Independent researchers have recorded attackers successfully taking control of test servers set up to lure them, attack tools have become markedly more reliable, and security firms have tracked hundreds of separate attack sources, at least one of them assessed as linked to a North Korean hacking group. The disruption is already visible: the UK government took 32 of its online services fully offline and four more partially offline, alongside local councils and government sites across Europe and Australia. Any organisation still running unpatched PHP on an internet-facing server should now assume it is a target, and any organisation that was unpatched for any period since October 17 should check whether it was already hit.
There is also new work to do even for teams that patched promptly. PHP has disclosed a third flaw, CVE-2026-115560, which has no fix yet; it affects only an unusual setup, and a single configuration change blocks it. And on Windows, PHP has reissued its official builds to fix CVE-2026-111497, a separate code execution flaw in a bundled compression library, which means Windows servers that installed last week's emergency release need updating again. This article covers what has changed since our first report, what the confirmed attacks look like, how to hunt for them, and what to do in what order.
What has changed since last week
| Last week (October 21 to 22) | Now (October 28) | |
|---|---|---|
| Exploitation | Attempts reported by many vendors, starting October 17; no confirmed success | Successful remote code execution recorded in the wild; CISA confirms active exploitation |
| CISA KEV | Not listed | Both CVEs added October 26; federal deadline October 29 |
| Exploit quality | Hundreds of proof-of-concept repositories, almost none working | Working exploits that defeat memory randomisation (ASLR) on standard production settings |
| Attackers | Unknown, anonymised infrastructure | Hundreds of attack sources, Mirai botnet operators, a financially motivated crew targeting crypto platforms, and a suspected North Korea-linked operation |
| Public sector impact | Precautionary outages in the Netherlands | 32 UK government services fully and 4 partially offline; councils and government sites across Europe and Australia taken down |
| Other PHP flaws | None | CVE-2026-115560 (unpatched, mitigated by configuration); CVE-2026-111497 (Windows builds reissued) |
Exploitation is now confirmed
The first successful attacks
On October 24, Adel Karimi, detection and response lead at Perplexity, published evidence of successful exploitation against honeypots, decoy servers set up to attract attackers. Across three honeypots running PHP 8.4.26 under Apache mod_php, he recorded 35 successful shell executions from two IP addresses. The attacks used memory exhaustion and memory disclosure to achieve code execution, consistent with CVE-2026-109618; Karimi found no evidence of CVE-2026-109619 being used.
What made the report persuasive was the detail. The server's response contained an 800 KiB dump of process memory, and a function address worked out from that dump appeared in the attacker's next payload. In Karimi's words, it is "confirmed RCE with usable memory disclosure, not just a crash followed by a suspicious process." Once inside, the attackers ran wget, curl, or the PHP command-line binary to fetch further payloads from a remote server. No second-stage malware had been observed at the time of the report. Marcus Hutchins of Expel called it "by far the highest quality confirmation" of in-the-wild exploitation he had seen.
Karimi was careful to note the limits: his honeypots used a deliberately favourable single-worker mod_php setup, so the results do not show how reliably the exploit works against busier servers, other PHP builds, or other applications. That caveat matters, but it cuts both ways. It means not every attack attempt will succeed; it does not mean production servers are safe.
CISA's KEV listing
On October 26, CISA added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog. Under Binding Operational Directive 26-04, US federal civilian agencies must remediate them by October 29, 2026. The deadline is binding only on those agencies, but KEV is the most widely used public signal that a vulnerability has crossed from theoretical to actively abused, and many organisations use it to set their own patch priorities. CISA has not said which organisations were compromised or released details of the attacks behind the listing. It did publish a SIGMA detection rule for exploitation attempts on October 23.
The scale of the activity
- Delft University's Threat Intelligence Lab tracked more than 50,000 exploitation requests from over 600 IP addresses in 70 countries. Of those addresses, 171 went beyond probing and sent exploit code or malware droppers.
- Cloudflare saw attempts grow from tens of thousands within 45 minutes of disclosure to millions by early October 22.
- Hunt.io watched a single actor target 123 servers, around 57 of them running PHP, many on unsupported 5.x to 7.x releases.
- Cisco Talos describes most activity as scanning, with uncoordinated attempts to deliver payloads.
Who is attacking
Several distinct groups are now visible:
- Botnet operators. Sophos and Arctic Wolf report attempts to install Potassium, an updated variant of the Mirai botnet, through PHP2Shell. Potassium can download further malware and launch network floods; its operators' stated goal is sustained denial-of-service attacks against hosts in a Ukrainian network. These installation attempts had not succeeded at the time of reporting.
- A financially motivated crew. SOCRadar found exploit tooling built for PHP 8.4.26 under mod_php on an attacker's server, including a WordPress attack script and fingerprinting tools run against about 20 sites. It assesses the actor as financially motivated, targeting cryptocurrency and Web3 platforms for API keys.
- A suspected North Korea-linked operation. CYFIRMA attributes, with moderate confidence, a campaign to a Korean-speaking operator in the Lazarus Group ecosystem. It used 21 compromised machines to scan 216 unpatched or partially mitigated hosts across the US, Japan, South Korea, Australia, the EU, the Gulf, and Southeast Asia, focusing on government, finance, logistics, aviation, manufacturing, and online payment platforms.
- Opportunistic scanners probing anything that answers, including Palo Alto GlobalProtect honeypots probed with a
p2s-ridermarker, and a China-based address seen by VulnCheck trying to plant a web shell through a server-side session file.
What has been walked back
Two early claims have been withdrawn, and it is worth knowing which. Palo Alto Networks Unit 42 retracted its assessment linking PHP2Shell to an intrusion at a European government agency, saying it is "unable to confirm that initial access is associated with the specific PHP2Shell CVEs." Sophos revised its initial assessment and now describes the activity it observed as scanning and failed attempts. Neither retraction changes the overall picture, which CISA's listing and Karimi's evidence now establish, but they are a reminder that early reporting on fast-moving incidents is often revised.
Exploits are getting better
Last week, one of the strongest practical barriers to exploitation was ASLR, a standard operating system defence that places code at unpredictable memory addresses so attackers cannot easily aim at it. VulnCheck's director of exploit development, Spencer McIntyre, said very few of the "hundreds" of proof-of-concept repositories on GitHub contained working exploits, largely because of ASLR.
That barrier has fallen. VulnCheck built an exploit overnight that chains a memory leak into code execution for CVE-2026-109618 on PHP 8.4.26, working on x86-64 systems with ASLR enabled and with PHP's recommended production setting of display_errors=off. It has released the exploit only to its own customers, and says it has not identified another public or commercial exploit that works under the same conditions. Karimi's honeypot results show attackers achieving a similar memory-disclosure-then-execution chain in the wild.
McIntyre's warning is the one to pass on to anyone hoping hardening will be enough: "the technical difficulty of exploiting a vulnerability shouldn't be confused with protection against it." And, on attacker interest: "Adversaries are clearly spending time (and tokens) on this bug."
The public sector impact
On October 22, UK technology minister Baroness Lloyd told the House of Lords that "32 government services are unavailable and four are partially unavailable" while security updates and mitigations were applied. The Office for Budget Responsibility took its websites offline ahead of the Budget, and peers reported disruption affecting the DVLA and police services. Edinburgh, Oxford, Bristol, Lambeth, and Barnet councils reportedly took services offline too. Lloyd said there was no confirmed compromise of central government or wider public sector systems, and that the outages were precautionary.
The UK was not alone. Germany, France, Belgium, Finland, and the Netherlands took government websites offline as a precaution, as did Australia's national cyber security agency, and school and hospital sites went offline across Asia, Europe, and North America. The UK's NCSC sent around 50,000 warnings to organisations, and the US NSA urged organisations to patch or disconnect vulnerable systems.
These outages show the real cost of a flaw like this even where no attacker gets in: taking a public service offline is safer than leaving it exposed, but it still means citizens cannot renew licences, pay bills, or reach information. Organisations that could patch quickly avoided that choice entirely.
A third flaw: CVE-2026-115560
On October 23, the PHP security team published an informational advisory for CVE-2026-115560, another remote code execution flaw. It is not fixed by last week's releases (8.5.12, 8.4.27, 8.3.36, and 8.2.35), and it will be fixed in the next regular release rather than through another emergency update. PHP has not given a severity score or a list of affected versions.
The reason for the calmer handling is that exploitation requires an unusual combination. All of the following must be true:
- The PHP configuration sets
session.serialize_handlertophp_binaryorphp_serialize. - The application switches it to
phpat runtime usingini_set(), before callingsession_start(). - Session upload progress is enabled, which it is by default.
The PHP Foundation's Elizabeth Barron called it a "very unlikely combination of configuration and specific PHP application code." Applications that never change the serialize handler at runtime are not exposed through this path, and no exploitation has been reported.
The mitigation is one you may already have in place: set session.upload_progress.enabled=0. This was already one of PHP's recommended interim measures for CVE-2026-109619, and PHP says it fully protects against this flaw. If you applied it last week, keep it in place; no further action is needed. If you patched last week and removed it, or never set it, it is worth adding now unless an application depends on upload progress bars.
Windows servers need updating again: CVE-2026-111497
On October 26, PHP reissued its official Windows packages for 8.2 through 8.5 to fix CVE-2026-111497, a memory corruption flaw in the bundled Brotli compression library that can lead to code execution. It has been nicknamed "Broccoli2Shell," and it also affects Node.js, Bun, Envoy, Istio, .NET, Python, and other software that bundles Brotli. Google rates it 9.2 (Critical, CVSS 4.0); Red Hat rates it 8.1 (Important, CVSS 3.1). OpenAI researchers found it.
The Windows builds released last week for PHP2Shell shipped Brotli 1.2.0, which is affected. The rebuilt packages contain Brotli 1.2.1 and keep the PHP2Shell fixes. Two practical points:
- The version number has not changed, so
php -vwill look the same. Identify the new builds by the-1suffix (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) and by the SHA-256 hashes on PHP's downloads page. - The flaw is reachable only when PHP's cURL extension automatically decompresses HTTP responses, so an attacker would need the application to fetch a crafted compressed response from a server they control or can influence. Automatic decompression is off by default in cURL, but setting
CURLOPT_ENCODINGturns it on, and the popular Guzzle HTTP library sets it by default.
PHP's notice offers no workaround. Until you can update, avoid setting CURLOPT_ENCODING, or set Guzzle's decode_content option to false (which also stops automatic gzip decoding). Removing br from the Accept-Encoding header is not enough on its own, because it does not stop a server from sending Brotli data anyway. No exploitation through PHP has been reported, and the flaw was not in CISA's KEV catalog as of October 23.
On Linux, Brotli usually comes from the distribution's own package, so update it through your normal channel and check its changelog for the CVE.
Your vendors are patching too
PHP is embedded in a great deal of commercial software, and around 34 vendors and agencies have now published their own PHP2Shell advisories, including ABB, Broadcom, Citrix, Dell, F5, HPE, IBM, Okta, QNAP, Salesforce, Siemens, Splunk, Synology, and WordPress. Upgrading the PHP you installed yourself does not fix the PHP inside an appliance, a NAS, or a vendor product. Check each vendor's advisory and apply their update; as Dataminr notes, many applications will stay vulnerable until their vendors ship fixes.
What you should do
1. Confirm every internet-facing PHP runtime is patched and restarted
If anything is still unpatched, this is now the top priority. Update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or apply your distribution's or LTS vendor's backport, then restart Apache, PHP-FPM, and every long-running PHP worker. For PHP 7.4, 8.0, and 8.1, move to a supported branch or use a vendor backport. Anything that cannot be patched should be isolated or taken offline. Remember that the honeypots attacked successfully were running 8.4.26, the release immediately before the fix; being one version behind is enough.
2. Close the vendor and appliance gap
Inventory products that bundle PHP (appliances, storage devices, control panels, commercial applications) and work through their vendors' advisories. These are the systems most likely to be missed.
3. Apply the CVE-2026-115560 mitigation
Set session.upload_progress.enabled=0 in php.ini, an FPM pool, or the server configuration (not with ini_set() or an FPM .user.ini file), and restart every worker. Leave it in place until the next regular PHP release.
4. Update Windows PHP builds to the -1 packages
Replace Windows installations with 8.5.12-1, 8.4.27-1, 8.3.36-1, or 8.2.35-1, verify the SHA-256 hash, and restart. Until then, check whether your applications enable automatic response decompression in cURL or Guzzle.
5. Hunt for compromise back to October 17
With exploitation confirmed, a server patched on October 21 or later may already have been compromised before then. Successful attacks can return a normal response and leave application logs empty, so look at the web server, the host, and the network:
- A POST request returning HTTP 500 alongside PHP memory exhaustion and heap corruption errors, and a crashing Apache worker (ReliaQuest's lab reproduction); a single isolated "Allowed memory size ... exhausted" error can be the only trace
- PHP processes (
php-fpm,php-cgi,httpd,apache2) starting shells or runningwget,curl, or the PHP command-line binary to fetch files - Outbound connections from web servers to unfamiliar addresses
- Unusually large
PHPSESSIDcookies in responses, and new or modified files in the web root or session directories - New cron jobs, scheduled tasks, or user accounts
CISA's published SIGMA rule is a good starting point for SIEM detections.
Selected network indicators from the reporting are below. Treat them as useful leads for log searches, not proof of compromise: many belong to VPNs and anonymising services and will change quickly.
| Indicator | Context | Source |
|---|---|---|
| 162.35.99.94 (ports 80, 8080) | Payload server contacted after successful honeypot exploitation | Karimi |
| 92.118.112.100 | Potassium (Mirai variant) loader | Sophos, Arctic Wolf |
134.199.154.64, TCP 50792 (thunder.godofthunder.st) |
Potassium command and control | Sophos, Arctic Wolf |
| 85.11.167.243, 45.198.224.169, 217.60.242.76 | Attack sources associated with Potassium delivery and honeypot scanning | Compiled by The Hacker News |
| 206.188.197.105 (port 9999) | Exploit tooling server for a crypto-focused actor | SOCRadar |
| 204.76.203.7 | Scanner using the p2s-rider marker |
Defused Cyber |
User agent php2shell-scan/109618 |
Automated scanning | VulnCheck |
If you find signs of compromise, isolate the server, preserve logs and memory where possible, and treat it as an incident rather than simply patching over it. Rotate any credentials, API keys, and session secrets the server handled, since the confirmed attacks rely on leaking process memory.
6. Do not rely on hardening or a WAF in place of patching
The ASLR bypass shows that exploitation is harder on some systems, not impossible. Web application firewall rules have been actively evaded, and Bitsight's guidance is blunt: only updating PHP on the host closes the gap. Application updates, plugin updates, and WAF rules do not.
A note on the pattern
The arc of PHP2Shell over one week is a compressed version of how major vulnerabilities now play out. Attempts started before disclosure, attempts turned into millions within hours, proof-of-concept code flooded GitHub but mostly did not work, and then within days, capable researchers and attackers closed the gap to reliable exploitation. Government confirmation followed. The window in which "it's hard to exploit" offered any real comfort lasted about three days.
Two other lessons stand out. First, early incident reporting is provisional. Two high-profile claims were withdrawn this week, and defenders are best served by acting on the established facts (patch, mitigate, hunt) rather than waiting for a definitive account of who was breached. Second, fixing the main problem does not end the work. A third flaw in the same area of PHP, a supply chain issue in a bundled library, and dozens of vendor advisories have all followed the original patch. Organisations that can quickly see where a component runs, including inside the products they buy, will spend these weeks fixing things; those that cannot will spend them searching.
Summary
| Name | PHP2Shell |
| Primary CVEs | CVE-2026-109618 (RCE via out-of-memory corruption), CVE-2026-109619 (RCE via stale global state), both CVSS 9.2 |
| Exploitation status | Confirmed in the wild; successful RCE recorded against PHP 8.4.26 on mod_php (October 24) |
| CISA KEV | Added October 26, 2026; federal civilian deadline October 29, 2026 |
| Known activity | 600+ attacking IPs in 70 countries; Potassium (Mirai variant) delivery attempts; crypto-focused financially motivated actor; suspected North Korea-linked scanning campaign |
| Exploit maturity | ASLR bypass on x86-64 with production settings (VulnCheck, private); working memory-disclosure chains seen in the wild |
| Full fix | PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or a vendor backport), then restart every PHP worker |
| New flaw | CVE-2026-115560: unpatched, requires runtime change of session.serialize_handler plus session upload progress; mitigated by session.upload_progress.enabled=0; fix in next regular release |
| Windows | CVE-2026-111497 (Brotli, "Broccoli2Shell"): install rebuilt packages 8.5.12-1, 8.4.27-1, 8.3.36-1, or 8.2.35-1 |
| Vendor products | 34+ vendor advisories, including Citrix, F5, IBM, Okta, QNAP, Siemens, Splunk, and Synology |
| Look-back window | Investigate from at least October 17, 2026 |
| Detection | POST requests returning HTTP 500 with memory exhaustion and heap corruption errors, worker crashes, PHP processes spawning shells or wget/curl, outbound connections from web servers, CISA SIGMA rule |
PHP2Shell is no longer a race to patch before attackers arrive; for many organisations, they have already arrived. Finish patching, including the PHP hidden inside vendor products and the Windows rebuilds, apply the one-line mitigation for the new flaw, and look carefully at every server that was exposed from October 17 onward.
If you need help confirming your PHP estate is fully patched, hunting for signs that attackers got in before you closed the door, or responding to a server that shows signs of compromise, get in touch. When exploitation is confirmed, knowing you were not hit is worth as much as the patch itself.