PHP2Shell: critical flaws in PHP's core found by AI affect WordPress, Drupal, and Joomla

Two different security organizations, using different AI models, arrived at the same alarming discovery during the same period: PHP's interpreter, the language that underpins most of the CMS platforms used in Brazil (WordPress, Drupal, Joomla, and much of the country's e-commerce), had two serious flaws hidden in how it handles fatal errors and out-of-memory conditions. Not in a plugin, not in the authentication logic of a specific application: in the very engine that interprets PHP code. That detail is what makes the case, dubbed PHP2Shell, different from the usual flood of WordPress CVEs.

The discovery was reported by Latent Space, in the AINews newsletter, gathering posts from researchers, OpenAI, and Cloudflare between October 20 and 21, 2026. The picture that emerges already has a published patch (the fixed version was released yesterday, October 21), but it still carries important gaps worth knowing before treating the case as just another log4shell.

What PHP2Shell Actually Is

The flaws received the identifiers CVE-2026-109618 and CVE-2026-109619. According to the technical description reported by the researchers, the bugs lie in how PHP internally handles fatal errors and out-of-memory conditions, not in application code. That means the problem isn't "a badly written plugin": it's the ground on which WordPress, Drupal, Joomla, and any other PHP application are built.

The researchers demonstrated two exploitation scenarios:

• Pre-authentication RCE (remote code execution without needing to log in) against WordPress, Drupal, and Joomla, the three most widely used CMS platforms on PHP sites worldwide.
• Remote memory leak, in the style of the historic Heartbleed, potentially affecting any PHP application, not just the three CMS platforms mentioned.

It's worth separating what was demonstrated from what was generalized: the remote code execution was shown against the three specific CMS platforms. The memory leak is a broader claim by the researchers, about any PHP app, but that's not the same as saying every deployment has exactly the same exploitation path, ready to be used.

Two Teams, Two Paths, the Same Flaw

The most interesting part of the case, for anyone following AI-applied security, is that two organizations found the same bugs independently, within the same time window:

OpenAI describes Patch the Planet as a large-scale hardening initiative, made possible by the Daybreak for Frontline Defenders program, a US$1 billion subsidy in access to models and cyberdefense products announced about two months earlier. It's important not to confuse the two names: Daybreak is the mechanism for accessing the models; Patch the Planet is the remediation initiative that used that access.

On Google's side, the company disclosed that, in Wiz's tests, Gemini 4 Argon found more than twice as many vulnerabilities compared to baseline models. That's a marketing number: the material consulted doesn't disclose the dataset, the computational budget limits, or the false-positive accounting behind that comparison, so it can't be treated as an independent evaluation.

The Two Months to the Patch

According to accounts from OpenAI researchers, including Eric Wallace and Greg Brockman, the remediation work took about two months, with confidential advance notice to governments and outside agencies before public disclosure. One researcher involved says he worked directly with the PHP Foundation to reinforce the patch, which required a significant change to PHP's own engine, not a cosmetic adjustment.

Cloudflare deployed mitigations in its WAF even before the official release of the patch, covering the already-known exploitation vectors and making that available to all customers, including the free plan. The company's CTO was explicit in classifying these rules as a stopgap, not a solution, and advised operators to apply the definitive patch by 2 p.m. UTC on October 21 (11 p.m. Japan time, the same window cited in Japanese-language advisories for operators to prepare).

The NSA, in turn, recommended immediate updating and, for those unable to mitigate in time, considering taking systems offline temporarily. That's conditional advice: before shutting anything down, what matters is checking the affected version, actual exposure, and available mitigations, not the alarmist tone of any one post about the case.

Advanced models finding a flaw before attackers, giving defenders time to prepare.

OpenAI, statement on the concept of the "Defender's Window"

OpenAI itself qualified that statement with the caveat "to our knowledge," which is relevant: there's no way to prove that no attacker knew about the flaw before disclosure.

What's Still Not Known

Before treating the case as a confirmed log4shell, it's worth listing what the material consulted doesn't establish:

• The exact matrix of affected and fixed PHP versions.
• The CVSS vectors (official technical severity) for each CVE.
• Whether details leaked before the scheduled patch, and exactly what leaked.
• The difference between successful exploitation and simple network scanning for vulnerable targets.
• The real cause of each reported instability (a viral compilation, not confirmed by an official source, mentions about 1.5 million servers still vulnerable according to Censys, plus instabilities in services like Wikipedia and Archive.org, with no confirmation that PHP2Shell was the cause in each case).

That's the central point for anyone reading this in a technical newsroom: high-profile security disclosures always carry a bit of marketing, and the original source material itself acknowledges that the degree of alarm (comparable to log4shell or Heartbleed) is still under debate.

What Changes for Those Who Maintain PHP in Brazil

PHP remains the foundation of much of the web built in the country, via shared hosting, corporate WordPress, e-commerce sites on Magento or custom solutions, and legacy systems at municipal governments and public agencies. For that audience, the case brings three practical lessons, regardless of how much of the alarm is justified:

1. A WAF doesn't replace a patch. Cloudflare's rules cover known vectors, but the vendor itself called that a stopgap. Alternative entry paths and direct exposure of the origin still exist.
2. Inventorying where PHP runs is the real work. Containers, background workers, appliances, forgotten old applications: the difficulty reported by operators in the material consulted wasn't finding the patch, it was finding all the places where PHP is running.
3. Verification tools exist, but they don't replace the process. OpenAI published a repository with a skill for Codex that helps check whether a site was affected. That's a diagnostic aid, not proof that the specific runtime has already been fixed.

The defensible sequence, according to the material's own reconstruction, is: obtain the official advisory from PHP and the distribution used, inventory exposed runtimes, apply temporary protections when justified, install the fixed package from an authenticated source, verify the process actually running in production, and investigate signs of compromise separately from the fix itself.

The Backdrop: More CVEs, More Patch Fatigue

The case isn't isolated. According to data cited in the material (not independently verified here), the monthly volume of published CVEs reportedly jumped from about 4,000 to 15,000 since April 2026, coinciding with the increasingly common use of AI both to find and to exploit flaws. That fuels a real debate among researchers: updating more frequently exposes teams to supply-chain risk (compromised packages slipping in during the patching process), while updating slowly leaves known vulnerabilities open for longer.

There's also a dispute over access policy among the major labs: OpenAI granted broad access to vetted researchers via Daybreak, while Anthropic reportedly restricted broad access to equivalent-class models for four months in order to strengthen cybersecurity safeguards before releasing it. The material consulted doesn't settle which approach produced more net defensive value; it only shows that the debate is open, and that, at least in this episode, the more permissive access reached the finding first.

For those who develop and maintain PHP applications, the lesson that remains isn't alarmism, it's operational: the attack surface of code that already exists is being audited by AI at an unprecedented scale, and that tends to continue for at least a year, according to the source's own reading. The work of patching, inventorying, and verifying will come up more often, whether or not one likes the degree of drama surrounding each disclosure.