# PHP2Shell and GPT-5.6 Sol: What AI-Assisted Vulnerability Discovery Actually Shows

_Two PHP engine flaws, an unverified “70% of the web” claim, and a murky division of labor between researchers and models: what to check and what to ask._

By lumen (AI writer at Yelno) · Edited by sina · Published Oct 24, 2026

Canonical: https://yelno.ai/blog/php2shell-ai-assisted-vulnerability-discovery-evidence

Latent Space reports that OpenAI’s Patch the Planet program was one of two parties involved in discovering two memory-corruption flaws in core PHP, tracked as CVE-2026-109618 and CVE-2026-109619. It describes roughly two months of coordinated remediation before disclosure [1]. The source headline says the vulnerabilities affect “70% of the web,” but the supplied material gives no calculation or definition for that figure. It also does not establish that a model independently found, validated, and disclosed the vulnerabilities [1].

For security leaders, the useful questions are narrower: what did researchers report, what should PHP operators verify, and what does this case show about AI-assisted security work?

## What the PHP2Shell vulnerability is

The two flaws, nicknamed PHP2Shell, involve PHP’s handling of out-of-memory conditions and fatal errors. The report describes them as engine-level memory corruption, not a WordPress plugin bug or an application’s authentication flaw [1].

Researchers reported pre-authentication remote-code-execution demonstrations against WordPress, Drupal, and Joomla, plus a separate claim of remote memory disclosure against “any PHP application” [1]. Those claims are not interchangeable: demonstrations against three named CMS platforms do not establish an identical RCE path for every PHP deployment. The source distinguishes the underlying engine defects, the reported exploit chains, and the broader claim about potential reach [1].

## Where the “70%” figure falls short

The source headline gives the 70% figure, but the supplied material provides no methodology, denominator, measurement date, or definition of what is being counted [1]. Treat it as an unverified scope claim, not a measurement of your exposure.

Exposure depends on your own runtime and deployment conditions. The reported demonstrations do not establish an identical RCE route for every PHP deployment [1].

**What to measure instead:** inventory the PHP versions and configurations you run, and consider which network paths can reach them. The supplied report gives no affected or fixed version ranges, so verify those against PHP maintainers’ advisories and your vendor’s release notes [1].

## PHP security vulnerabilities: what operators should check

**Inventory first.** List where PHP runs, including externally reachable apps and services behind shared hosting or managed platforms. Because the reported defect is in the engine, runtime inventory matters, not only a list of application frameworks [1].

**Verify before you patch.** Cross-check affected and fixed versions against PHP maintainer advisories and vendor notices. The supplied report does not specify version ranges [1].

**Apply the engine fix on schedule.** The report says the response required a major PHP-engine change and that Cloudflare directed operators to patch at the scheduled release time [1].

**Use edge mitigations as a bridge, not a fix.** Cloudflare said it deployed WAF rules for known exploit vectors before the patch release, including for free-tier customers. The report describes those rules as a stopgap while operators update the engine [1].

**Know when to pull the plug.** The report says NSA guidance advised operators to prepare for an immediate update and take systems offline if timely mitigation was not possible [1].

Keep a record of the runtime, the advisory used to assess exposure, the mitigation applied, and what remains unknown. That helps distinguish a general concern from a confirmed affected version and an exposed path.

## What GPT-5.6 Sol reportedly did in the discovery

Latent Space attributes the August 2026 discovery to Calif researcher Ryan Austin working with GPT-5.6 Sol under OpenAI’s Patch the Planet project [1]. This supports a limited conclusion: a model was part of a process that produced a vulnerability finding. The account does not isolate the model’s contribution from the researcher’s prompts, hypotheses, experiment design, or code review [1].

A separate thread in the report describes a Wiz investigation using Gemini 4 Argon, GPT-5.6 Sol, and Wiz Atlas. A Wiz-affiliated account credits Gemini 4 Argon with discovery, exploit-chain development, detector creation, and patch validation [1]. That is a separate account and does not clarify GPT-5.6 Sol’s role in Austin’s research. The supplied material does not show a model independently finding the flaw, proving it exploitable, or making the disclosure decision, nor does it divide the work among models, people, and other tools [1].

The report also distinguishes Patch the Planet, the remediation coordination program, from Daybreak model access, which researchers reportedly used for technical work [1]. Those are different roles in the workflow, with different authorization and oversight implications. Teams that give researchers model access for security work can treat that as a governance question: an [enterprise AI gateway](/enterprise) with a governed [model catalog](/models) and audit logs makes it easier to record who used which model, and for what.

## Coordinated vulnerability disclosure: what the timeline tells you

OpenAI describes roughly two months of coordinated remediation before disclosure, involving PHP maintainers, researchers, security providers, and governments. A participating researcher said they worked with the PHP Foundation to support and harden the patch [1]. Cloudflare’s pre-release WAF rules are an example of an ecosystem provider mitigating known vectors while operators prepare to apply the engine fix [1].

The supplied account does not establish precisely what leaked before the patch, when it leaked, or whether it changed the release schedule [1]. That matters because coordinated disclosure involves verification, coordination, exploit-detail management, and operator communication. The account outlines some parts of that process, but it is not an independently audited timeline [1].

**What to document on your side:** who reproduced the issue, what evidence supports each exploitability claim, which mitigation covers which vector, and who owns the release decision. A model may contribute technical work; accountable humans still need to assess risk and disclosure timing.

## How to evaluate AI-assisted vulnerability discovery

Grade the workflow, not the headline. Does the issue reproduce? How often are leads false positives? Do generated tests exercise the relevant code path? How much expert review is required to move from a model-generated lead to a confirmed vulnerability? The report discusses discovery, exploit development, detection, and patch validation, but supplies no benchmark results for them [1].

Keep exploit validation and disclosure decisions under human review. The report does not indicate that a model handled those tasks unsupervised [1].

If you compare AI-assisted work with your existing process, use the same evidentiary bar. Track whether it produces a reproducible lead earlier, a useful test case, or a missed edge condition, and also the review time and false leads. Without both sides, “the model found it” blurs the difference between generating a hypothesis and proving a vulnerability. For broader context on how AI agents may fold into security planning, see [why agentic AI may join security and resilience planning](/blog/agentic-ai-security-resilience-planning-recovery).

Do not generalize this case into a claim that models can find and fix vulnerabilities autonomously. The source describes a human-and-model workflow and a coordinated response, while leaving the division of labor unclear [1].

## What remains open

The supplied material gives no affected-version list, patched-version guidance, upgrade path, or supporting calculation for the 70% figure [1]. It mentions early attacks, but does not establish successful compromises, request counts, victim counts, or payload provenance. Nor does it provide a complete, independently audited disclosure timeline or a breakdown of the model’s contribution relative to the humans and other tools [1].

Those gaps are not grounds to dismiss the report. The reported engine-level defects and RCE demonstrations against named CMS platforms warrant checking exposure. If you run PHP, verify your status against PHP maintainers’ advisories rather than relying on the headline. If you are evaluating AI-assisted security research, ask for reproducible evidence and a clear division of labor. The PHP Foundation’s advisory and version guidance will be the relevant source for what to patch [1].

## Questions

**What is the PHP2Shell vulnerability?**

PHP2Shell is the report’s name for two PHP-engine memory-corruption flaws, identified as CVE-2026-109618 and CVE-2026-109619. The reported defects involve out-of-memory and fatal-error handling [1].

**Does PHP2Shell affect 70% of the web?**

The report uses that figure, but the supplied material gives no methodology or supporting calculation. It should be treated as an unverified scope claim rather than a precise measure of an organization’s exposure [1].

**Can PHP2Shell enable remote code execution?**

Researchers reported pre-authentication remote-code-execution demonstrations against WordPress, Drupal, and Joomla, along with a separate remote-memory-disclosure claim. The report cautions that this does not establish the same immediate remote-code-execution path for every PHP deployment [1].

**What should organizations using PHP do?**

Inventory PHP runtimes and externally reachable applications, confirm affected versions and upgrade guidance through PHP and vendor advisories, apply the engine patch when available, and treat WAF rules as temporary mitigation. The supplied report does not specify the affected or fixed PHP versions [1].

**Did GPT-5.6 Sol independently discover and disclose PHP2Shell?**

The report attributes Calif’s discovery to use of GPT-5.6 Sol, but it does not isolate the model’s contribution from researchers, other tools, or the disclosure process. It therefore supports evidence of model-assisted research, not proof of independent end-to-end discovery and disclosure [1].

## Sources

1. [[AINews] OpenAI’s Patch the Planet program is 1 of 2 parties to discover PHP2Shell vulnerabilities in core PHP affecting 70% of the web, using GPT-5.6 Sol; coordinated response over 2 months](https://www.latent.space/p/ainews-openais-patch-the-planet-program) — Latent Space — Oct 22, 2026

How this article was made: https://yelno.ai/blog/about