Patch this before you finish reading the credit dispute

Start with the operator's version, because it has a deadline attached. The two flaws sit in how PHP handles fatal errors, especially out-of-memory errors, while processing requests. A request that dies at the wrong moment can leave corrupted or stale internal state behind, and a later request handled by the same worker can reuse that state, first to read process memory and then to run code. None of this requires a flaw in the website's own code. Wiz's line is worth repeating without decoration: even a simple "Hello World" application on an affected PHP version can be vulnerable.

That is why the usual advice to update your application does nothing here. Updating WordPress, Drupal or Joomla without updating the PHP runtime underneath them leaves the engine flaw in place. PHP's own advisory identifies the setups in scope — PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed — describes mod_php as particularly exposed because a demonstrated exploit fires before application code runs, and is unusually blunt about stopgaps: the settings changes it documents block specific confirmed paths, other variants may remain, and an unpatched installation is not safe. If you serve web requests through PHP, the work today is to inventory the runtime and the deployment configuration, install the appropriate upstream security release or a verified vendor backport, and restart every affected worker, in that order. Exposure varies by configuration, which is a reason to check the advisory against your own build, not a reason to assume you are out of scope.

Secondary reporting says details of the flaws leaked on 20 October, before the fix was available. PHP's advance notice, published that same day, had already scheduled this release for 14:00 UTC on 21 October and said it reserved the right to release earlier if details became public or exploitation appeared. Read the leak as reported, not settled, and read the schedule from PHP itself.

Three tools, two press releases, no scoreboard

The AI part of this story is real, and it is also where the accounts start to compete. OpenAI's post leads with its own model and its own programme: Calif identified a critical flaw using GPT-5.6 Sol as part of Patch the Planet, OpenAI led the coalition, and OpenAI is now proposing a general framework for responding to critical vulnerabilities in widely used software, plus $1 billion in subsidised access for defenders generally — a commitment the announcement does not present as PHP-specific spending, and does not establish as money already distributed. Wiz's post leads with Wiz: Wiz Research uncovered the vulnerabilities, used three tools throughout, and singles out Google's Gemini 4 Argon, not GPT-5.6 Sol, for a particularly significant contribution to finding and remediating the flaw. It carries a quote from the head of Gemini Security at Google DeepMind saying so.

Both accounts can be true at once. Calif and Wiz may each have found flaws the other also found; OpenAI says Wiz independently discovered and reported both. What neither account supplies is a breakdown: how much of the discovery, the exploit construction, the detection work and the patch validation came from which model, how many attempts failed, or how the same researchers would have fared with conventional fuzzing and manual review on the same code. Wiz used Atlas, Argon and Sol together, in one workflow, with human researchers directing it. "AI helped" describes that workflow accurately. It does not rank the models inside it, and readers should not let either press release rank them by placement.

The timing claim inside Wiz's account is the one to keep, at the strength Wiz offers it. Wiz says a single researcher completed in about a week work that would previously have taken a skilled team months, because the models could adapt a complex exploit chain across PHP versions, configurations and memory layouts, testing and debugging as they went. That is a claim about labour, offered by the team that did the work. It is a self-report: Wiz has published no controlled comparison showing how much time each model saved, and no comparison run alongside it.

The part that should change behaviour

Strip the branding away and the remaining fact is uncomfortable for anyone who maintains old software. These flaws were present for more than a decade. They survived, on Wiz's account, because turning them into a working exploit required chaining several memory bugs and adapting to each target, work that was difficult enough to act as a practical barrier. Frontier models helped the researchers who found the flaws this time develop and adapt working exploits across different PHP environments. That suggests AI-assisted research can make some previously difficult exploit-development work more practical. It does not mean every model user can immediately reproduce what Wiz's researchers did; their expertise, tooling and iteration were part of the result.

The coordination was essential for more ordinary reasons: the severity and reach of the flaws, the complexity of developing and testing fixes across old releases, and the need for hosting providers and security firms to prepare protections before they could talk about why. That preparation is also why the disclosure took the shape it did, with patches, provider mitigations and guidance landing on the same day as the public details.

OpenAI calls the head start the Defender's Window: the period between defensive discovery and potential attacker exploitation. In this case, researchers, maintainers and security providers coordinated fixes and guidance before public disclosure. That is a meaningful defensive outcome. It does not prove that no attacker had independently found either flaw, and none of the primary accounts read for this piece states that either flaw was exploited in the wild before disclosure; OpenAI's own claim stays narrower, that to its knowledge frontier AI found the vulnerabilities before attackers did. Whether the same coordination works next time depends on the unglamorous parts of this story: small maintainer teams with time to test a fix across old releases, providers willing to prepare before they can talk about why, and operators who actually apply an emergency release on the day it ships. The models are the headline. The coordination is the defence.

Sources

  1. [1] PHP, "Security advisory: Critical remote code execution vulnerabilities, update now", php.net, 21 October 2026 — affected setups, both CVEs, fixed versions 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, backports for 7.4 / 8.0 / 8.1, and the partial mitigations with their stated limitsRead source
  2. [2] PHP, "Upcoming Critical PHP Security Release", php.net, 20 October 2026 — scheduled release at 14:00 UTC on 21 October, both flaws rated CVSS v4.0 9.2, and the right reserved to release earlier if details became public or exploitation appeared
  3. [3] Wiz, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet", Wiz Research blog, 21 October 2026 — the four bugs grouped under two CVEs, demonstrations against WordPress / Drupal / Joomla, the August–October disclosure timeline, and the statement that Wiz used Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout, with Argon making a particularly significant contributionRead source
  4. [4] OpenAI, "Patch the Planet: global response coordination as agents uncover critical vulnerabilities", OpenAI, 21 October 2026 — Calif's identification of a critical flaw using GPT-5.6 Sol, Wiz's independent discovery of both vulnerabilities, the two-month coalition, the PHP version checker OpenAI says it is sharing and the accompanying Codex skill it plans to launch, and the $1 billion Daybreak commitmentRead source
  5. [5] Prior alfw.ai coverage: 'OpenAI's Agents Weakened the Watchdog. One Then Said It Hadn't.', 20 October 2026Read source