PHP2Shell: what changed overnight and what to do now

Somewhere between a screenshot on Hacker News and a prime minister's post on X, a bug in the language that serves about seven in ten websites became the biggest security story of the year so far. Two flaws, nicknamed PHP2Shell (CVE-2026-109618, CVE-2026-109619), let a stranger run code on a PHP web server without logging in. Here is what happened between 17 and 22 October, told from the sources.

Data as of 2026-10-22live record →

The night, hour by hour

Who said what

The posts themselves (read from X's public embed data on Oct 22; X shows only the opening of long posts, so only that opening is quoted):

• Sanae Takaichi, Prime Minister of Japan (@takaichi_sanae), Oct 21, 12:55 UTC — account carries X's Government label: 「皆様に、今夜に対応して頂きたい大至急のお願いです。」 ("We have an urgent request for everyone to take action tonight.") 「多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。」 ("Regarding PHP, used by many websites, the PHP security team has issued a warning about two serious vulnerabilities.") About 329,000 likes at the time we read it.
• FBI Cyber Division (@FBICyberDiv), Oct 21, 14:59 UTC — Government-labelled account: "Two critical vulnerabilities have been identified in PHP, a widely used programming language that powers websites and web applications. These vulnerabilities (CVE-2026-109618 and CVE-2026-109619) could allow malicious cyber actors to remotely execute code in PHP core, potentially…"
• Dane Knecht, CTO of Cloudflare (@dok2001), Oct 21, 14:57 UTC: "Credit to @OpenAI @wiz_io @ThePHPF for finding php2shell and running a responsible, coordinated disclosure. This won't be the last one. Models will keep finding bugs like this in software everyone runs. Maintainers, researchers, providers and governments need a new shared…"

Inside the PHP team

The most human part of the story is in the PHP Foundation's own postmortem, as reported by The Record and Socket. CVE-2026-109618 has a history that goes back to 2024: the Foundation links its first signs to PHP's 2024 external security audit (details below), engineers could not agree on a fix, and it stalled. The Foundation says the team worried about "backward compatibility breaks, new denial-of-service potential" and "struggled to choose between these and feared the repercussions of shipping the wrong choice". With no known remote-code-execution path and a small core team with deep engine knowledge, the fix stalled and restarted for months.

The 2024 audit, and what is and is not connected. Per the Foundation's Oct 21 post, PHP's first external security audit in years was organised by the PHP Foundation with OSTIF, funded by the Sovereign Tech Agency and carried out by Quarkslab in 2024. "While fixing one of the issues Quarkslab reported, a PHP core developer contracted by the PHP Foundation found the first signs of the OOM problem behind CVE-2026-109618. In 2024, a potential exploit for the OOM problem was theorized, but no concrete vectors were found and other concrete issues with clear impact overshadowed these concerns." The Foundation's announcement of the audit plan (Nov 2023) and its summary of the results (Apr 2025) are bylined Roman Pronskiy; that summary thanks him among the Foundation team and maintainers who supported the audit.

• What the sources say: the out-of-memory problem was first noticed during remediation work that followed the audit, not reported as a finding by Quarkslab (Foundation post above). We did not find an out-of-memory item among the findings in Quarkslab's published report (reference 24-07-1730-REP, v1.4, Mar 2025), and could not tell from the sources which finding the developer was fixing.
• Scope of the audit: per the report, the agreed components included PHP-FPM, RFC 1867 (multipart upload parsing) and OPcache/JIT "especially in a multi worker pool environment". The report says parse_url/parse_str-style functions, streams and xp_ssl could not be investigated in the time available, and suggests a further assessment of those and of OPcache/JIT use in shared multi-worker setups. Wiz's write-up lists an OPcache bug and a multipart-related bug among its four; the report does not mention them, and we found no source that links those bugs to the audit.
• What no source says: PHP's advisories, Wiz and Sansec do not mention the audit. Nobody we found states that the audit's authors or organisers knew of an exploitable path in 2024; the Foundation says none had been found.
• Quarkslab also wrote about the audit on its blog.

• What changed the picture. Reports from Calif, OpenAI, Wiz and others "made the full impact of the … problem clear", and from Aug 11 fixing it became the top security priority. The Foundation says it has since made dozens of internal changes so a serious bug stuck on hard trade-offs reaches its leadership sooner.
• Who built the fix. The GitHub advisory credits four reporters (GitHub handles lcfr-hax, sagitzadik-wiz, tomash-areion, amyb-oai) and four remediation developers: arnaud-lb, iluuu1994, bukka and ndossche. It was published by bukka.
• What the fix does. PHP used longjmp() to bail out of an out-of-memory error, leaving half-initialised request memory behind. The patch removes that jump: a soft out-of-memory error at the next safe point of the VM, plus an immediate hard exit (_exit()) at a second, higher threshold (per the advisory).
• The embargo that didn't hold. The Foundation said disclosure ran smoothly until rumours surfaced on social media. Then came the leak of the CVE numbers, the video, and — at 07:41 UTC — Chainguard's early images. The Foundation: "Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release." Chainguard CEO Dan Lorenc answered: "I made the call to get these out early when exploits hit in the wild." Later he said, "It's not us versus them here."
• What the team found when it looked. The PHP security team "inspected PoCs that appeared after the leak" and "did not identify any functional exploits at the time of release/public disclosure" (PHP Foundation, via Tenable).

How loud it got

• Hacker News. Wiz's write-up reached 440 points and 173 comments (HN); we counted 28 PHP2Shell stories there by Oct 22 (HN Algolia search). The threads argued about a two-month gap between report and disclosure, whether AI labs coordinated ("What a coincidence," wrote one commenter about OpenAI and Calif reporting the same root cause on the same day), the line that PHP runs "approximately 70%" of the web, and whether C is fit for purpose.
• Three labs, one bug. Calif credits an exploit found with a frontier model; OpenAI and Wiz found the same bugs independently, and Wiz names Gemini 4 Argon, GPT-5.6 Sol and its own Atlas as the tools (Wiz). Amazon argues exploitation is getting faster because AI-assisted analysis lowers the cost of turning a patch or advisory into a working exploit (AWS, paraphrased).
• Outages. Pinboard and parts of Wikipedia were temporarily down, and 4chan and Something Awful went offline; Japanese sites, including daycare and video-game systems, were voluntarily offline, per ITmedia (NBC News). The National reports that the Netherlands, Finland, France and Australia took some government services offline for the patch; The Record counts "hundreds of websites" offline.
• Is it being exploited? Depends on who you ask. Amazon says PHP2Shell "is now being broadly exploited in the wild" and logged its first attempt on Oct 17. Cloudflare and watchTowr report attempts; Fastly's Kelly Shortridge sees "clear evidence attackers are actively probing". Huntress had not confirmed successful exploitation; CISA had not observed any; neither CVE is in KEV.

And what about Bitrix, WordPress and the rest?

The flaw is in PHP, so every PHP platform shares it. Shares below are W3Techs estimates for 22 October 2026 (share of all sites / share of sites with a known CMS): WordPress 39.6% / 58.3%, Joomla 1.1% / 1.6%, Drupal 0.6% / 0.9%, 1C-Bitrix 0.4% / 0.6%. The researchers' demos covered WordPress, Drupal, Joomla, Magento, Laravel and Symfony (Sansec, citing Calif).

Frameworks are not CMSs, so W3Techs has no share for them; Packagist (the Composer package registry) gives a different yardstick. Downloads count installs, including CI builds and dependency pulls, not running sites, and Symfony components are also used inside Laravel and Drupal — read them as a sense of scale, not a site count. As of 22 October 2026 (Packagist API, estimate): laravel/framework has been downloaded 601 million times in total and about 872,000 times a day; symfony/console 1.24 billion and 1.47 million a day; symfony/http-kernel 945 million and 1.31 million a day; drupal/core 71 million and about 84,000 a day. None of these packages contain the bug — it is in the PHP runtime they run on.

Bitrix: small worldwide, big in Russia

Among .ru sites with a known CMS, Bitrix is 15.9%, behind WordPress at 33.4% and Tilda at 27.4% (estimate, W3Techs, 22 Oct). Bitrix sites are exposed through the server PHP like any other. A Habr guide for Bitrix owners (part 1, part 2, author Cyber1CBitrix) stresses that the product's own SiteUpdate does not update PHP; that cloud Bitrix24 is managed by Bitrix24, while boxed Bitrix24 and "Site Management" need the server PHP updated by the owner, partner or host; and that BitrixVM needs a PHP update too. Bitrix24's help centre limits support for PHP below 8.2 and recommends 8.3+. We found no statement from 1C-Bitrix themselves, NKTsKI or FSTEC, and have written none.

RoadRunner, FrankenPHP and other application servers

A natural guess is that PHP application servers are safer, because a Go program (RoadRunner) or the server itself, not classic PHP request parsing, takes the HTTP request. We checked the primary sources. The guess is not confirmed, and part of the evidence points the other way.

What Wiz adds. Wiz's write-up (Wiz, Oct 21) does not name RoadRunner, FrankenPHP, Swoole or any SAPI; it describes the mechanism in general terms. All its bugs come from a fatal error (mostly out-of-memory) leaving state behind, and "a later request or worker can reuse that stale state"; one bug is about a request being aborted before the session pointer is cleaned up, another about OPcache's shared memory, where a failed allocation in one worker corrupts state that other workers then use. That is the same pattern as in the "persistent workers" paragraph of PHP's advisory, so it does not support the idea that long-lived workers are safe — but it does not show they are hit either. Wiz's own demos ran on the official WordPress, Drupal and Joomla container images, i.e. a classic web stack, not an application server.

• Whatever you run, update the PHP that the workers use (or the FrankenPHP build), then restart the processes so they start from the patched binary — an application reload only reloads your code.
• Inventory them separately. They are easy to miss: PHP inside a container image, a static FrankenPHP binary, or a php binary named in .rr.yaml is not covered by your distribution's updates.
• The interim settings in the guide apply to workers too; PHP's advisory adds that restarting workers often (pm.max_requests=1 on FPM) only lowers the odds, it does not remove the bug.

What this means: the impact

Short version: the flaw is in the language runtime, not in any one site. A stranger on the internet can send a crafted request and, on an unpatched server, run code as the web server's user without logging in — or read memory that belongs to other visitors. Patching is public, so the question for most owners is no longer "is it real" but "how fast".

What an attacker gets

• Code execution without a login. PHP's advisory says both flaws "can allow unauthenticated remote code execution" (php.net). The code runs with the rights of the web server user: it can read the site's files and configuration, change pages, add a backdoor or a card skimmer, and reach whatever that server can reach.
• Secrets from memory, without any shell. Wiz showed that one of the bugs lets an unauthenticated attacker read live worker memory, including data from other people's requests — passwords, tokens, API keys, certificates (Wiz, Oct 21). So a site can leak even if nothing was installed on it.
• Denial of service and data exposure. Cloudflare lists, besides code execution, "denial of service" and "data exposure" (Cloudflare).
• It runs before your app does. PHP says its demonstrated exploit fires "before any application code runs", so app-level logins, plugins and firewalls do not stand in the way (php.net).

How big it is

• Share of the web. PHP runs on 69.3% of sites with a known server language (estimate, W3Techs, 22 Oct 2026); Wiz and Cloudflare say "70%" and "almost 70%" (Wiz, Cloudflare). Cloudflare says all PHP from 5.4 on is affected.
• Absolute numbers. Censys counted nearly 55 million web properties running PHP on Oct 21 (NBC News). That counts sites that run PHP, not sites proven exploitable: a patched or protected site is in the number too.
• The long tail. Cisco Talos estimated that roughly half of vulnerable PHP systems may never be patched (The Record); forensics expert Hal Pomeranz expects many embedded installations to stay unpatched (via Help Net Security). This is an estimate and an opinion, not a count.
• Not just a CMS problem. The demos used WordPress, Drupal and Joomla, but Wiz says even a "Hello World" app on an affected PHP can be vulnerable.

What has been confirmed so far

• Attacks started before the patch. Amazon's honeypot logged the first exploitation attempt on Oct 17, four days before disclosure, then more from several different actors on Oct 21; after the release Amazon says PHP2Shell "is now being broadly exploited in the wild" (AWS). Amazon also says it is unclear whether those attempts would have worked on real systems.
• Others see attempts too. Cloudflare saw attack traffic and attackers changing payloads to get past its rules; Patchstack reported "active exploitation" (NBC News).
• What is not confirmed. CISA had not observed exploitation when it published and neither CVE is in its KEV catalog (as of Oct 22); Huntress had no confirmed successful compromise among its customers; PHP's security team saw no functional exploit at release. We found no public count of hacked sites. Outages were reported (Pinboard, parts of Wikipedia, some Japanese systems), but the sources describe patching and precaution, not a confirmed attack, as the reason for the Japanese and government cases.

Who is hit harder

• Servers that are internet-facing and not yet updated — the NSA advises being ready to update immediately, CERT-EU advises isolating such applications, and the UK NCSC mentions taking a system offline until it is mitigated (quotes above).
• Apache with mod_php. PHP rates it the highest risk, because the attack can run before any application code.
• PHP 8.1 and older. The PHP project released fixes only for 8.2–8.5; older branches depend on a vendor backport or source patch, so they stay open longest.
• Forgotten and embedded systems, and hosts you do not control. PHP inside container images, appliances or a shared hosting plan is patched only when someone notices it. This is where Talos's "half may never be patched" and Pomeranz's "long tail" apply.
• Targets with valuable secrets. Because memory can be read, stores, admin panels and anything holding API keys or payment credentials lose more if hit. This is our reading of the Wiz finding, not a ranking from a source.

What to do now

1. Update PHP to a fixed version (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) or your vendor's patched package, then restart every PHP worker. Updating WordPress, Bitrix or plugins does not patch PHP.
2. On PHP 8.1 or older, use a vendor backport, build the source backport, or move to a supported branch.
3. Can't update today? Apply PHP's interim settings and keep a WAF in front — stopgaps only; take the site offline if you must, as the NSA, NCSC and CERT-EU advise.
4. Look back to October 17, not to the release day, for crashes, new .php files and shells started by the web user.
5. Wiz's hunting hints: multipart requests followed by memory-limit errors or repeated HTTP 500s, oversized or malformed PHPSESSID response cookies, and unexplained worker churn. One bug leaks memory without code execution, so rotate secrets if an unpatched server was exposed.
6. Commands for nginx, Apache, Docker, cPanel and the rest: the full defence guide.

Sources: PHP security release notice, GitHub advisory GHSA-w8hw-w9fx-j79w, The Record (PHP Foundation statement), Socket (postmortem timeline), AWS Security Blog, Cloudflare, Wiz, NBC News, The National, OfficeChai, Help Net Security, BleepingComputer, CyberScoop, Tenable, Hacker News, Sansec, W3Techs pages linked above, Habr 1, Habr 2, Bitrix24 help centre.