PHP2Shell: AI-Found PHP Flaws and Your AI Keys

What it is: a set of four memory-safety bugs in the PHP engine, grouped by Wiz under two CVEs and nicknamed PHP2Shell. According to Wiz, they are triggered by mishandled fatal errors, especially running out of memory, which leave stale state behind for later requests or workers.

• Severity: up to 9.2 on the CVSS scale. Wiz calls the findings "among the most severe vulnerabilities discovered in PHP, and arguably in software history".
• Reach: nearly every PHP version back to 5.4. PHP runs on roughly 70% of identified websites, according to the Associated Press, though outlets differ on the exact share.
• Proven impact: unauthenticated remote code execution on default container images of WordPress, Drupal and Joomla, and a process-memory disclosure that can expose passwords, tokens, API keys and certificates.
• Discovery: found using Wiz Atlas with Gemini 4 Argon and GPT-5.6 Sol; fixes were co-ordinated over about two months.
• Fix: patched PHP releases published on 21/10/2026. Updating is the only complete remedy.
• Not confirmed: whether the flaws are being exploited in the wild at scale. Cloudflare said it was seeing early attacks, but Wiz's own write-up does not claim observed exploitation.

Our view: the bugs matter, but the lesson is bigger. Defenders can now use AI to find flaws before attackers do, and attackers can do the same. The gap between the two is how fast you patch, and how little a stolen credential can do when you have scoped it properly.

On 21/10/2026, the PHP project released patches for two critical vulnerabilities and Wiz Research published its analysis under the name PHP2Shell. Within hours, news outlets reported that some government websites had been taken offline as a precaution. In the UK, the Associated Press reported that a limited number of government services were temporarily unavailable, while the prime minister's office said no large public-facing critical services were affected. In Finland a government site's disruption was resolved, though some content was still being restored, and in Japan parts of some government sites were taken offline as a precaution.

Official warnings were unusually blunt. The FBI's cyber division warned of remote code execution risk and, according to the AP, advised taking sites offline if they could not be updated immediately. Japan's prime minister, Sanae Takaichi, urged administrators to check for PHP use and install the patch straight away, and the EU's cybersecurity agency ENISA told organisations to act immediately.

The PHP Foundation said the delay in fixing the problem was its own: "The delay was a structural failure, caused by both the security team's decision process and its lack of resources." That frank admission points to a second story, which is how much of the internet depends on under-resourced open-source maintainers.

Wiz describes four separate bugs. The common thread is that when PHP hits a fatal error, particularly running out of memory, it can leave pointers or state behind that a later request or another worker then trusts. In security jargon, these are use-after-free and type-confusion bugs. In plain English, PHP keeps using something after it has been thrown away, and an attacker can arrange for that space to hold data they control.

1. Upload-progress unserializer use-after-free. When PHP decodes a session during an upload-progress request and a memory allocation fails, leftover state from the unserializer stays published. A later request can reuse that stale state.
2. Remote process-memory disclosure. A stale session ID pointer is trusted after a request's memory has been destroyed, so the reclaimed memory's contents can leak out in a response cookie. Wiz notes this one is application-agnostic and can reveal passwords, tokens, API keys and certificates.
3. Fatal-error backtrace use-after-free. A global variable holding the last fatal error's backtrace survives into the next request, leaving a dangling pointer.
4. OPcache type confusion. A mismatch between process-local and shared state allows one worker to put a pointer of the wrong type into a slot that another worker then reuses.

Wiz says even a simple "Hello World" application on an affected PHP version can be vulnerable, because the flaws sit in the engine and not in application code. It also expects further variants to exist and says they fall under the same two CVEs. We could not reliably map each of the four bugs to a single CVE from the public write-up, so we do not attempt to here.

The most striking claim is about method. Wiz says the work used its Wiz Atlas system together with Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol, and credits Gemini 4 Argon with contributions to discovery, exploit development, attack detection and patch validation. Its summary line: a single researcher completed in a week what previously would have taken a world-class team months. Raluca Ada Popa, head of Gemini Security at Google DeepMind, is quoted saying the work "has shown why frontier AI is a game-changer for cyber defense".

We have covered the models involved: see our reviews of Gemini 4 Argon and GPT-5.6. The relevant context is how vendors now rate such capabilities. OpenAI's own framework treats cyber capability as a hazard category, which we examined in our Astra critical-threshold analysis, and Anthropic has made similar judgements about its most capable models; see Anthropic Mythos 1. PHP2Shell shows what that capability looks like when pointed at a real, widely deployed codebase.

The AP reports that OpenAI led a coalition of researchers and security firms working on the fixes over about two months, and called the flaws "one of the most impactful security issues in recent memory", adding that AI appeared to find them before attackers did. That framing matters. It is the best-case version of the AI-and-security story: defenders got there first, and there was a window to patch. It is also a one-off; nobody should assume the next discovery will go as well.

Wiz's own timeline is useful because it shows how slowly the human parts of disclosure move compared with the machine parts:

• 19/08/2026: first PHP vulnerability discovered.
• 20/08/2026: unauthenticated remote code execution confirmed on Drupal.
• 21/08/2026: unauthenticated remote code execution confirmed on WordPress.
• 24/08/2026: reported to the PHP security team.
• 21/09/2026: PHP acknowledged the reports and began a co-ordinated fix.
• 21/10/2026: patched releases and public disclosure.

Two days from first bug to a working exploit on a major content management system, then a month to acknowledgement and a second month to patches. The AP also reports the PHP Foundation saying the vulnerability had been known since at least 2024, which, if accurate, suggests the human process had known about the underlying weakness for far longer than the AI-assisted work took to demonstrate it. We could not verify that claim independently and report it as the AP's.

PHP powers WordPress, Drupal, Joomla and a long tail of bespoke sites. The Associated Press quoted Charl van der Walt of Orange Cyberdefense saying the impact could be "enormous" and that the worst may be ahead, noting that PHP may be embedded in devices such as connected cameras. James Sullivan of the Royal United Services Institute urged calm, advising organisations to identify vulnerable systems, install updates promptly and use two-factor authentication, and cautioned against treating the situation as a doomsday. Both agree on one thing: the most intense fixing will take weeks, and full remediation of stragglers could take months or years.

The practical risk groups are:

• Self-managed PHP servers and virtual machines, where you own the update.
• Container images built on old PHP bases, which stay vulnerable until rebuilt, however well the host is patched.
• Shared hosting, where you depend on the provider to patch; ask them in writing.
• Forgotten sites: old marketing microsites, intranets, staging servers and plugins nobody maintains.
• Embedded and appliance software that bundles PHP and updates on the vendor's schedule.

The video embedded above, from Nate B Jones, makes a point that connects the PHP news to everyday AI use. His argument, per the free preview of his accompanying newsletter post, is that agents are now central to both cyber offence and defence because they work natively on computers: they can read unfamiliar software, test it and correct themselves. Decades of accumulated weaknesses now face machines that can investigate them at a scale human teams cannot afford.

His specific warning is that an AI service key has direct financial value to an attacker. Whoever holds it can buy machine work on your bill, even if they have no interest in your conversations. A key stored in a vulnerable web server, a build job or a gateway becomes a way to spend your money. That is where PHP2Shell comes in: the process-memory disclosure Wiz describes is exactly the kind of bug that can expose credentials held in a running application.

Nate cites several other incidents from the same week, as summarised in the post's preview: a LiteLLM release that carried credential-stealing malware, a certificate authority's private keys reportedly including the number 4, and Microsoft documenting AI-assisted attacks on hundreds of organisations. We have not independently verified those items and report them as his. Separately, some creator coverage this week discussed a reported breach of a legacy OpenCode Console system potentially exposing provider keys stored server-side. We found only a single unverified source for that claim, so treat it as unconfirmed; for background on the tool, see our OpenCode 2.0 article.

One note on the title: the video uses the phrase "Black October". We could not find that label used by Wiz, the PHP project or the news agencies, so treat it as the creator's shorthand for the month's run of incidents rather than an official name.

These steps follow Wiz's guidance, official advice quoted by the AP, and standard credential hygiene. They are ordered by urgency.

Today

1. Find your PHP. List every site, server, container image and plugin that runs PHP, including ones you forgot. Content management systems are the usual suspects.
2. Patch. Install the patched PHP release from your distribution, host or container base image. Rebuild and redeploy containers, do not just patch the host.
3. If you cannot patch, reduce exposure. The FBI cyber division's advice, as reported by the AP, is to take the site offline until it can be updated. Vendor protections from Cloudflare, Fastly, Google and Vercel are interim cover only.

This week

1. Rotate secrets held in PHP processes: database passwords, session secrets, API keys and certificates, starting with anything internet-facing.
2. Audit your AI keys. If you have pasted an AI service key into any application, check what that key can reach, and shut off any you do not use. Create separate keys per app so one leak does not expose everything.
3. Set spending limits and alerts with each AI provider, and a monthly budget cap, so a stolen key hits a ceiling quickly.
4. Keep keys out of code and shared notes. Use a secrets manager or environment variables with restricted access; do not leave keys in agent memory files or shared notes (see our piece on agent memory and Obsidian for how easily notes spread).
5. Turn on two-factor authentication for hosting, registrar, source-control and AI provider accounts.

Ongoing

1. Automate updates for runtimes and base images, and test that they work.
2. Keep a dated inventory of what you run and what it can reach, and check what changed since the last review. Nate recommends this approach, though the full prompts are behind his paywall and we have not seen them.
3. Know your incident plan so a credible notice, such as a vendor advisory, triggers rotation immediately.

Wiz lists several indicators worth watching in logs while you patch:

• Unusual multipart upload requests followed by memory-limit errors or repeated HTTP 500 responses.
• Unexpectedly large or malformed PHPSESSID cookies.
• Unexplained PHP worker churn, meaning workers crashing and restarting.

Absence of these signs is not proof of safety, particularly for the memory-disclosure bug, which may leave little trace. If a vulnerable server was internet-facing before patching, rotating its secrets is the cautious course.

Three lessons stand out beyond the immediate patch.

First, discovery is now cheap. If one researcher with frontier models can find critical bugs in one of the most scrutinised codebases on the web in a week, the number of latent flaws that become findable has jumped. Every maintainer of widely used software should assume similar work is under way against their code, by defenders and attackers alike.

Second, patching is the bottleneck. The AI-assisted part of PHP2Shell took days; the human disclosure process took two months, and real-world remediation will take longer. Organisations that can ship updates in hours will have a decisive advantage over those that need a change-board cycle.

Third, open-source funding is a security issue. The PHP Foundation's own statement blamed its decision process and lack of resources. If AI makes finding bugs easy, projects need the people and money to triage and fix them. That is a policy question as much as a technical one.

There is an optimistic reading, which Nate shares in the video summary: the same persistent, machine-driven investigation that finds weaknesses could, if the repairs are finished, lead to a more secure internet. Getting there will be a rough transition.

• Exploitation in the wild. Wiz's write-up does not report observed exploitation, while other reports mention early attacks. The picture will change quickly.
• Exact fixed version numbers. The Wiz article does not list them. Check the PHP project's release notes for your branch.
• CVE-to-bug mapping. Which of the four bugs sits under which CVE is not clear from the public write-up.
• Share of the web. The AP says about 70%; other outlets say closer to 75% of identified sites. Neither is a precise measure of exposed servers.
• The OpenCode key incident. Single-source and unverified.
• Vendor framing. Wiz sells security products and OpenAI and Google sell the models credited with the discovery, so enthusiasm about AI-assisted defence should be read with that in mind.

PHP2Shell is a rare case where the headline, AI found a critical flaw in the web's most common server language, is accurate and the story is still bigger than the headline. If you run anything on PHP, patch today and rotate secrets this week. If you only use AI tools, take ten minutes to check which keys you have created, scope each one, set a spending cap and delete the ones you do not use. The attackers do not need your data to profit from you; they only need your key.

• Wiz Research: PHP2Shell, AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (21/10/2026): CVEs, bug descriptions, timeline, detection indicators and mitigations.
• Associated Press (Barbara Ortutay), via News4JAX: Some websites go dark as operators address an AI-detected flaw: government impact, official warnings, PHP Foundation statement and expert quotes.
• Nate B Jones: AI Agents and Cybersecurity, What Changed and What to Do (24/10/2026): free preview only; most of the post is paywalled.
• Nate B Jones on YouTube: video embedded above.

Image: Wiz Research, from the PHP2Shell announcement, compressed and used for review and commentary with credit.