If your website runs on PHP, update it today. Two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed php2shell, let an attacker with no login run code on a web server. PHP shipped fixes on 21 October 2026, a day earlier than planned, after the vulnerability identifiers leaked online. Amazon says the bugs are now being broadly exploited in the wild.
The scale is what makes this serious. PHP powers about 69% of websites whose server-side language is known, according to W3Techs, including WordPress, Drupal, Joomla and Magento sites. Researchers have confirmed pre-authentication remote code execution against specific versions of all four.
Two memory bugs in the engine, not in any app
Both flaws sit in PHP’s core request handling, so they fire before a site’s own code gets a say. The PHP security team rates each at 9.2 on the CVSS v4 scale. The leaked pre-release identifiers carried a 10.0 score, which the PHP Foundation says was wrong.
CVE-2026-109618 is memory corruption during out-of-memory handling (PHP advisory). When a memory allocation fails, PHP abandons the request mid-flight. If request data was only half set up, the cleanup routine treats it as valid. Crafted multipart requests, the kind browsers send for forms and file uploads, can exhaust memory while appearing to stay inside PHP’s configured limits.
CVE-2026-109619 is a use-after-free. One PHP worker process handles many requests in turn. A fatal error such as a timeout can interrupt cleanup at the end of one request, leaving internal state that points at freed memory. The next request on the same worker can then use that stale pointer. PHP also lists memory disclosure as a confirmed impact (PHP advisory).
The research team at Calif traced the earliest affected code path back to PHP 5.4.0, released in 2012. Calif and Wiz both said they used AI models in the research, and the PHP Foundation also credited OpenAI.
Who is exposed: practically every PHP web server
Every installation that serves web requests is affected, whether it runs PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed. Rapid7’s analysis of PHP’s advisory notes that mod_php carries the highest risk, because the demonstrated exploit works before any application code runs. Researcher Silas Cutler estimates more than 1.3 million internet-facing hosts are potentially vulnerable.
| PHP branch | Status | Fixed in |
|---|---|---|
| 8.5 | Supported | 8.5.12 |
| 8.4 | Supported | 8.4.27 |
| 8.3 | Supported | 8.3.36 |
| 8.2 | Supported | 8.2.35 |
| 7.4 to 8.1 | End of life | No official release; source backports only |
| 5.4 to 7.3 | End of life | No fix from the PHP project |
Linux distributions and long-term support vendors got the patches in advance, so servers running distribution packages should take their vendor’s update. Sites stuck on old PHP versions, common on cheap shared hosting, are the ones with no clean way out.
A leak forced the patch out early, and attacks came first
The exploitation clock started before the public knew anything. Amazon Threat Intelligence caught an exploitation attempt on its MadPot honeypots on 17 October, four days before disclosure, and it is unclear how that attacker got the details. Amazon advises investigators to look back to 17 October, not 21 October.
| Date (2026) | What happened |
|---|---|
| 21 Oct, evening | Calif and Wiz publish technical write-ups; Wiz demonstrates unauthenticated RCE on WordPress, Drupal and Joomla. Amazon reports attempts from multiple actors; Cloudflare’s CTO reports “early attacks emerging” |
| 21 Oct, 14:00 UTC | PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with its advisory, a day ahead of the original 22 October plan |
| 20 Oct | A Hacker News user posts the confidential CVE identifiers, a 10.0 score and a 22 October date. PHP issues an advance notice; CERT-EU and the UK NCSC issue emergency advisories |
| 17 Oct | Amazon’s honeypots record the first known exploitation attempt |
The PHP team said it found no working exploit among the proof-of-concept code circulating at release. Security firm watchTowr has since reproduced both bugs and reports exploitation attempts against each. Treat any “exploit” posted online with suspicion: unverified code may itself be malware.
What to do now
Updating is the only complete fix, according to PHP. Everything else buys time.
- Patch. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from php.net/downloads, or install your Linux distribution’s updated package. Restart every PHP worker afterwards.
- If you cannot patch today, cut exposure. In php.ini or server config that applications cannot override, set
memory_limit=-1for CVE-2026-109618 andsession.upload_progress.enabled=0for CVE-2026-109619. On PHP 8.5, also setfatal_error_backtraces=0. Setting these throughini_set()or.user.inicomes too late. - Block what you don’t need. If the site takes no uploads, drop multipart requests before they reach PHP, and cap request sizes at the web server or proxy.
- Isolate stragglers. CERT-EU recommends taking internet-facing apps off public networks until a fix is applied and verified. Cloudflare has pushed WAF rules to all customers, free plans included, but calls them a stopgap.
- Hunt from 17 October. Huntress advises alerting when php-fpm, php-cgi, httpd or apache2 spawn shells or network tools, and checking for webshells, new files in the web root, new cron jobs and new accounts. Missing log entries do not prove a server is clean.
Shared hosting customers can’t change server config themselves. Ask your host, in writing, which PHP version your account runs and when it was patched.
