PHP2Shell Explained: The AI-Found Bug in 70% of Websites — and What to Do About It

In brief

• On October 21, 2026, the PHP project released emergency security updates for two critical vulnerabilities in the PHP language itself, collectively called PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Both allow unauthenticated remote code execution — an attacker with no account can run code on the server.
• The flaws sit in PHP’s core engine, not in any website’s code. Your WordPress plugins can be perfect and your site is still exposed. Even a “Hello World” page on a vulnerable PHP version can be attacked, per the researchers.
• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. Only updating fully protects a server. Servers running Apache’s mod_php face the highest risk — the demonstrated exploit fires before any application code runs.
• The bugs were found with heavy AI assistance — and AI is what makes them exploitable at scale. One researcher did in about a week what the discoverers say would previously have taken a world-class team months. Disclosure was pulled forward a day after details leaked on Hacker News.

What PHP2Shell actually is

PHP2Shell is two bugs grouped under one name, and understanding the pairing matters because they hit differently.

CVE-2026-109618 is an upload-progress unserializer use-after-free combined with remote process-memory disclosure. CVE-2026-109619 is a fatal-error backtrace use-after-free plus an OPcache type confusion. Both are memory-safety issues, and both trace back to the same root: how PHP handles fatal errors — particularly out-of-memory errors — while processing a request.

Here is the mechanism in plain terms. When a PHP request dies unexpectedly (say it runs out of memory), PHP can leave corrupted internal state behind. The next request handled by the same worker process can then pick up that stale state and treat attacker-controlled memory as its own bookkeeping. From there, the attacker either reads live worker memory — which can hold passwords, authentication tokens, API keys, and certificates belonging to other people’s requests — or corrupts memory far enough to execute code.

The PHP project rates both flaws 9.2 out of 10 under CVSS v4.0. (The leaked pre-disclosure chatter claimed a perfect 10.0; that number was not PHP’s. Security firm watchTowr, which reproduced the first flaw, rated it a full 10.0 independently.) PHP security engineer Volker Dusch compared the severity to Heartbleed — the 2014 OpenSSL bug that forced a global patch race — calling it the most severe security issue PHP has faced in more than a decade.

Scope is what makes this one different from a bad WordPress plugin week. PHP powers WordPress, Drupal, Joomla, and Wikipedia’s MediaWiki — by one widely cited estimate, up to 70% of the world’s websites. Every PHP version from 5.4 (released 2012) through the current 8.x line is affected by at least one of the two flaws. The vulnerable code, per Wiz, had been sitting in the codebase for more than a decade.

Who is actually at risk

The PHP security advisory lists every common way PHP serves web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. All are at risk. But they are not equally at risk, and the distinction decides your urgency:

• Apache mod_php — highest risk. The demonstrated exploit triggers with a single unauthenticated request before any application code runs. Your firewall rules inside the app, your login protections, your plugin security — none of it gets a say. If you run mod_php, patch first and ask questions later.
• PHP-FPM — at risk, harder to exploit. FPM shuts the worker down when a request fails early in setup, which breaks the simplest attack path. PHP’s own analysis says FPM is susceptible to one of the two flaws but no complete FPM exploit has been demonstrated; the second flaw was shown reaching code execution on both mod_php and PHP-FPM, though the FPM path depends on an operation inside the running application.
• Shared hosting customers — you do not control the PHP runtime; your host does. Your job is to check what your host has done, not to patch anything yourself. More on that below.

One more uncomfortable detail from the researchers: the memory-disclosure variant was demonstrated against applications the researchers did not control, and it works even when the application never calls session_start(). It is application-agnostic. There is no plugin to update your way out of this one — it is the floor, not the furniture.

What to install

Update the PHP runtime that serves web requests, then restart Apache, PHP-FPM, and any long-running PHP workers. Note the trap: updating WordPress or Laravel does not update PHP. The runtime comes from your server package, your host, or your container image — it is a separate layer, and plenty of site owners patch their CMS religiously while running a five-year-old PHP underneath it.

PHP branch	Vulnerable	First fixed version
8.5	below 8.5.12	8.5.12
8.4	below 8.4.27	8.4.27
8.3	below 8.3.36	8.3.36
8.2	below 8.2.35	8.2.35

Two end-of-life notes: PHP 8.1 and older no longer receive updates from the PHP project at all, and PHP 8.2 reaches end of life on December 31, 2026. For the older branches, the PHP security team published source backports for 7.4, 8.0, and 8.1 — useful if you build from source or are waiting on a vendor. If your server runs a Linux distribution package, the fix may arrive under an old-looking version number; check the package changelog for the CVE identifiers, not the version string.

After updating, review your memory settings. The fix adds a new hard memory limit, and hitting it ends the process and stops shutdown handlers from running — so check memory_limit and post_max_size against what your application actually needs before you discover the difference in production.

If you cannot update yet

Be honest about what these are: exposure reducers, not fixes. The PHP advisory and the researchers are explicit — only updating fully protects a server. But if patching has to wait for a maintenance window, these narrow specific attack paths:

• For CVE-2026-109618: set memory_limit=-1 so applications cannot override it, keep post_max_size low, and enforce request-size limits at the web server or proxy. Do not use RLIMIT_AS or RLIMIT_DATA as substitutes — PHP warns they can trigger the same vulnerable path.
• For CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker; on PHP 8.5 also set fatal_error_backtraces=0. This blocks the confirmed session paths but not other variants.

A setting that circulated as a workaround before the patch — disabling session upload progress — was confirmed by the release to be a partial measure at best. PHP core developer Gina Peter Banyard put it bluntly before the release: “The only thing I can say is that the only mitigation is patching/upgrading PHP.”

If you sit behind Cloudflare, you got a head start you did not ask for: Cloudflare deployed WAF protections for its customers about nine hours ahead of public disclosure, and has been updating its mitigations as attackers mutate payloads. Cloudflare’s CTO called those firewall rules a stopgap and urged administrators to patch anyway. Other large providers — AWS, Google Cloud, Fastly, Akamai, Microsoft, Vercel — worked with the PHP team on guidance and out-of-the-box mitigations ahead of disclosure.

How to tell if you were already hit

No confirmed successful break-in had been reported as of October 21 — watchTowr, which reproduced the flaw, reported no exploitation in the wild as of 11:26 UTC that day, and neither CVE was in CISA’s Known Exploited Vulnerabilities catalog. But “no confirmed break-ins” is not “no attempts”: Cloudflare said it was seeing early exploit attempts before the patch shipped, with attackers already mutating payloads to dodge firewall rules.

Late on October 21, CISA issued an emergency alert urging organizations to patch immediately, naming the same fixed versions (8.5.12, 8.4.27, 8.3.36, 8.2.35) and telling organizations that cannot patch to take PHP-based systems offline. The agency said it had not observed exploitation as of publication — still no confirmed break-ins, still no KEV listing. The alert’s subtext matches the researchers’ warning: with AI-assisted exploit development in the wild, the window between disclosure and weaponization is measured in days, not months.

If you patched late, or you suspect exposure during the window, the researchers suggest watching for:

• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses
• Oddly large or malformed PHPSESSID response cookies (the memory-disclosure path stuffs stolen memory into the session cookie)
• Unexplained restarts of PHP workers

Note the forensic wrinkle: these issues execute below the application layer, so application logs may contain little context. Server-level request logs are where the evidence lives.

Some organizations did not wait to find out. BambooHR took its service offline across the United States, Canada, and Ireland as a precaution, warning that payroll would be interrupted. In the Netherlands, MijnOverheid, DigiD, the lower house of parliament’s website, the national cyber-security center, and several education systems went offline; the center said it had not seen the flaw abused but urged everyone to patch. Taking services down preemptively is the new normal for internet-scale flaws — the cost of a wrong guess about exploitability keeps rising.

The leak that moved the timeline

The disclosure was supposed to happen October 22. On October 20, a post on Hacker News — citing no more than a trusted tip — announced that two PHP remote code execution flaws, with both CVE identifiers, were set for disclosure on the 22nd. The PHP team posted an advance notice that evening and moved the release to October 21, publishing around 14:00 UTC.

The compressed timeline is worth noting because it is becoming the pattern. Coordinated disclosure depends on secrecy holding for weeks; with AI-assisted exploit development in the wild, every leaked hour is an hour attackers can use the same tooling the defenders used. The PHP team, to its credit, moved fast once the secret was out.

The AI inflection point

This is the part of the story that will outlive the patching. Wiz is explicit: the vulnerable code had been present for more than a decade, and turning the flaws into working exploits required chaining multiple bugs while adapting to each target’s memory layout — “at the edge of what human researchers could practically achieve.” Frontier AI models, Wiz says, “substantially reduced that barrier, turning a longstanding flaw into an exploit.” Their bottom line: “With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work.”

That cuts both ways, and both edges showed up in this story. The discovery side: Wiz used its Atlas platform with Gemini 4 Argon and GPT-5.6 Sol; Calif found one of the flaws with GPT-5.6 Sol as part of OpenAI’s “Patch the Planet” program; OpenAI coordinated the disclosure across maintainers, researchers, and security companies. The exploitation side: the same class of models that found the bug can adapt an exploit to new targets in hours, which is why “complexity” no longer counts as a defense. As Wiz puts it: “complexity may no longer provide a meaningful barrier, changing how we define what is vulnerable in practice.”

There is an honest footnote on the discovery credit. Wiz, Calif, and OpenAI give somewhat different accounts of who found what first and with which tools — Calif traces the bug’s lineage to PHP research from 2004 and notes that knowing the target’s history still mattered, arguing current models do not reliably start from obscure twenty-year-old primitives on their own. The dispute is a preview of coming arguments: when AI does the finding, “who discovered it” gets blurry. For everyone patching this week, the credit question is trivia. For the industry, it is the shape of every future disclosure fight.

What to watch next

Update, October 22: exploitation is now being reported in the wild. NetSPI says exploitation has been confirmed since at least October 21; Aikido and Patchstack both report active exploitation incidents (neither has published technical details). CISA has still not added either CVE to its Known Exploited Vulnerabilities catalog, and its October 21 alert says the agency had not observed exploitation itself as of publication — the confirmed-exploitation claims come from vendors, not the government. The NSA’s Cybersecurity Collaboration Center has advised organizations that cannot patch immediately to take PHP-based systems offline. Cloudflare reports exploit attempts numbering in the thousands, with attackers already changing tactics to bypass protections. Even underground forums are reacting: BreachForums and Dread both went offline as a precaution until PHP is patched globally.

Three things, in order. First, exploitation is now confirmed in the wild by multiple vendors (NetSPI, Aikido, Patchstack) — the race between defenders patching and attackers weaponizing is now measured in hours, and AI tooling compresses both sides. The open question is when CISA adds the CVEs to KEV, which would force US federal agencies onto a binding patch deadline. Second, whether CISA adds the CVEs to its Known Exploited Vulnerabilities catalog, which would force US federal agencies onto a binding patch deadline. Third, the variant question: Wiz reported four exploitable bugs grouped under the two CVEs but believes other variants exist in the codebase — the patch fixes the issue at its core, but the audit of a decade of memory-handling code has only just begun.

The practical takeaway has not changed since the first paragraph: check your PHP version, update to the fixed release for your branch, restart your workers. Everything else in this article is context for why that one unglamorous step matters more this week than most.

Sources

• Wiz Research, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet,” October 21, 2026 (primary — discoverer). https://www.wiz.io/blog/php2shell-php-rce
• The Hacker News, “PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge,” October 21, 2026 (read in full). http://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html
• Help Net Security, “PHP2Shell: Critical PHP vulnerabilities patched, update now!” October 21, 2026. https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
• Cloudflare Blog, “Cloudflare deploys protections against php2shell vulnerability,” October 21, 2026. https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
• Wall Street Journal, “AI Just Found a Bug That Puts Up to 70% of the World’s Websites at Risk,” October 21, 2026. https://www.wsj.com/tech/cybersecurity/ai-just-found-a-bug-that-puts-up-to-70-of-the-worlds-websites-at-risk-fd0902ea
• PHP News, “php2shell: How OpenAI Coordinated the PHP RCE Disclosure,” October 21, 2026. https://phpnews.net/php2shell-openai-disclosure
• Goldenera, “PHP2Shell: AI models helped find critical PHP flaws behind 70% of websites,” October 21, 2026. https://goldenera.si/news/php2shell-php-rce-ai-vulnerabilities/
• CISA, “Critical Vulnerabilities in PHP Require Immediate Patching,” October 21, 2026 (emergency alert; no observed exploitation as of publication). https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• NetSPI, “PHP2Shell Unauthenticated RCE on PHP: CVE-2026-109618 & CVE-2026-109619,” October 2026 — reports exploitation confirmed in the wild since at least October 21. https://www.netspi.com/blog/executive-blog/critical-vulnerability/php2shell-unauthenticated-rce-on-php-cve-2026-109618-cve-2026-109619/
• SOCRadar, “PHP2Shell: CVE-2026-109618 & CVE-2026-109619,” October 2026 — Aikido and Patchstack active-exploitation reports; BreachForums and Dread offline as precaution. https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/
• USA Today, “Critical security flaw puts most websites at risk as NSA issues warning,” October 21, 2026 — NSA offline advice; Cloudflare exploit-attempt volume. https://www.usatoday.com/story/news/nation/2026/10/21/php-vulnerability-php2shell-updates–live/92362348007/

Sources

• Tenable — PHP2Shell (CVE-2026-109618, CVE-2026-109619) FAQ
• Datadog Security Labs — PHP2Shell critical vulnerabilities in PHP

Related reading: Stolen UpdraftCentral Keys Are Backdooring WordPress Sites · OpenAI’s Agents Disabled Their Own Safety Monitoring — Then Denied It · How One Hacker Used AI Agents to Breach 100+ Company Sites

Sources: Wiz Research (2026-10-21 — primary discoverer: CVE-2026-109618/109619, CVSS 9.2, fixed versions 8.5.12/8.4.27/8.3.36/8.2.35, AI-assisted discovery account; read in full); The Hacker News (2026-10-21 — emergency patches, exploit attempts emerging; read in full); Help Net Security (2026-10-21 — patch coverage); Cloudflare Blog (2026-10-21 — WAF protections live ~9h before disclosure, early exploit attempts observed); Wall Street Journal (2026-10-21 — 70% of websites framing); PHP News (2026-10-21 — OpenAI-coordinated disclosure account); Goldenera (2026-10-21 — AI-model discovery analysis); CISA (2026-10-21 — emergency patching alert; no observed exploitation as of publication).