PHP2Shell flaw exposes PHP core used by 70% of the web

Two flaws in the PHP core, found through two different paths

In August 2026, researchers at security firm Calif, working within OpenAI's Patch the Planet program, identified two vulnerabilities in the PHP engine: CVE-2026-109618 and CVE-2026-109619, dubbed PHP2Shell. According to coverage by Latent Space, published on October 22, 2026, the flaws lie in PHP's internal handling of out-of-memory conditions and fatal errors, not in a WordPress plugin or an application authentication flaw. This means the problem is in the interpreter, not in the code developers write on top of it.

The demonstrations released by researcher Ryan Austin show unauthenticated remote code execution (RCE) against WordPress, Drupal, and Joomla, as well as a remote memory leak described as "Heartbleed-style," capable of affecting any PHP application. These are results reported by the researchers themselves, and Latent Space stresses that this should not automatically become the assumption that every installation has the same exploitation path immediately available.

GPT-5.6 Sol and Gemini 4 Argon joined the bug hunt, each on its own

The discovery has two independent origins, according to the report. On one side, Calif used OpenAI's GPT-5.6 Sol, with access enabled by the Daybreak for Frontline Defenders program, a $1 billion grant for security researchers to use OpenAI's cyber models, announced about two months before the case became public. On the other, Wiz, recently incorporated into Google Cloud, arrived at the same flaws using Gemini 4 Argon combined with a proprietary tool, Wiz Atlas.

• Calif / OpenAI: GPT-5.6 Sol, access via Daybreak, Patch the Planet project.
• Wiz / Google Cloud: Gemini 4 Argon, Wiz Atlas, independently found.

OpenAI calls this type of scenario a "defender's window": the model finds the flaw before the attacker, which gives time to prepare a response. The caution that Latent Space itself points out is worth noting: the company's phrasing is "to our knowledge," not proof that no attacker already knew about the vulnerability before that.

Google, for its part, disclosed that in Wiz's internal tests, Gemini 4 Argon found more than twice as many vulnerabilities compared to baseline models, but without publishing the dataset, testing budget, or false-positive rate, which prevents any independent comparison between the two models in this specific episode.

Two months behind the scenes before the patch shipped

Once the severity of the finding was confirmed, the PHP Foundation, researchers, and security providers entered a coordination cycle that lasted about two months before public disclosure, according to reports from OpenAI itself (including researcher Eric Wallace and president Greg Brockman). The fix required a significant change in the PHP engine, not a one-off adjustment, and went through detection and validation testing before going live.

While that was in the works, Cloudflare published WAF (web application firewall) rules covering the already-known exploitation vectors, released even to customers on the free plan. The company's own CTO was explicit: it was a stopgap, not a substitute for the patch, which had its release window set for 14:00 UTC on October 21, 2026 (11 p.m. Japan time). The NSA, in turn, recommended that operators prepare to update immediately and, if they could not mitigate in time, take systems offline.

What leaked early, and what still can't be confirmed

Cloudflare reported, even before the patch's official release, "early attacks" exploiting the already-known vectors, which indicates that information about the flaw circulated ahead of time. Reports cited by Latent Space say details leaked early, but the available material does not make clear exactly what leaked, when, or whether this changed the release schedule.

A compilation that went viral afterward brings together numbers and incidents that need to be read with caution: about 1.5 million servers without the fix, attributed to Censys; outages at Dutch institutions, government sites in other European countries, Wikipedia, Archive.org, Asana, and GOG; and a 5:55 a.m. alert from Japan's prime minister. Latent Space itself points out that none of these individual claims is backed, in the available material, by an official advisory, an independent measurement, or a status page confirming the cause of each outage.

Still missing from the set of information gathered by the coverage is the most basic layer any incident response team needs: the official PHP Foundation advisory, the exact matrix of affected and fixed versions, the package identifiers by distribution, and the patch commit. Without that, an instruction like "update to version X" cannot be safely given based on the available coverage, and it is up to each team to seek that information directly from official PHP channels.

What changes for those running PHP in production in Brazil

PHP continues to underpin much of the shared hosting, agency, and online store market in Brazil, typically via WordPress, but also Drupal, Joomla, and legacy internal applications. A bug in the engine, rather than in an application layer, hits that entire footprint at once, including sites that no one has touched in years and that rarely show up in an up-to-date asset inventory.

The first practical problem is finding where PHP is actually running: managed hosting, containers, background workers, appliances, and old applications nobody remembers exist. An operator cited in Latent Space's coverage describes the exhaustion of testing and updating dozens of WordPress/PHP sites at once; another concludes that patch distribution across the ecosystem is poorly coordinated, which sounds familiar to anyone who has tried to update a large fleet of client sites at once.

The second problem is the false sense of security from the WAF. Cloudflare's rule covers known vectors and was being updated as new attacks appeared, but the vendor itself called it a stopgap. Proxy enabled, alternative entry routes, and direct origin exposure need to be checked, not assumed to be resolved just because the site sits behind a WAF.

OpenAI published a repository with a Codex skill designed to help operators check whether their sites were vulnerable. It is a support tool, useful as a first filter, but it does not replace verifying the actually installed package version or an official vendor advisory.

The debate that remains: using AI to hunt bugs in critical infrastructure changes the baseline

The episode reinforces a discussion that had already been growing in the security sector: giving access to frontier models to vetted researchers changes the volume of vulnerabilities found. Another researcher cited in the coverage credits access to OpenAI's Daybreak for a portfolio of findings spanning PHP, GitLab, Chrome, and WordPress. By contrast, Anthropic reportedly delayed broad access to Mythos-class models by four months to strengthen cybersecurity safeguards, according to another account in the coverage, though the available material does not say whether that caution helped or hurt in this specific case.

A number that deserves skepticism also came up in the discussion: investor Sarah Guo reported a rise in CVE registrations, from about 4,000 per month to 15,000 since April, questioning whether formal code verification and more secure distributions should be on the radar. That volume is not independently verified in the available material, and not every additional CVE means successful exploitation: it can also reflect more people (and more AI) hunting for bugs.

Finally, a radical idea emerged, so far only a proposal: using PHP2Shell's own RCE to automatically patch vulnerable servers without owners' authorization. The suggestion appeared in discussions cited by Latent Space, including the idea of a pardon for anyone who tried it. None of this has legal backing, and exploiting systems without authorization carries the risk of unauthorized access, evidence tampering, and civil and criminal liability across multiple jurisdictions, even with good intentions.

The checklist left for the infrastructure team

Without the official advisory and version matrix in hand, the defensible sequence cited by the coverage is:

1. Find the official advisory from the PHP Foundation and from the Linux distribution used in production.
2. Inventory where PHP is actually running (hosting, containers, workers, appliances).
3. Apply temporary protection (WAF) only as a bridge, never as a final solution.
4. Install the authenticated, fixed package and restart the affected processes.
5. Verify the version actually running, not just what the package manager reports.
6. Investigate signs of prior exploitation separately, since updating closes the flaw but does not prove nothing leaked before.

That's the part that stays the same, with or without frontier AI hunting bugs: a patch without inventory and without verification is a patch done halfway.