PHP2Shell: What It Is and What to Do Now
Critical bugs in PHP itself let attackers take over servers without a login. AI found them first. Here’s what to do.
Contents6 sections
PHP2Shell is a pair of critical bugs in PHP itself, the language behind a large share of the web, that can let an attacker run code on a server without logging in. The fixes shipped on October 21. If anything you run touches PHP, update it now: the PHP team says there are no complete mitigations, and updating is the only safe choice.
It matters well beyond WordPress. An always-on agent lives on a server, holds your keys and remembers what you tell it. If that server, or anything sharing its secrets, runs PHP, this is a way in.
What PHP2Shell is
Two memory bugs in the PHP engine that chain into a full takeover. They are tracked as CVE-2026-109618 and CVE-2026-109619, and PHP rates both critical. They live in the core engine, not in any one app, so every version from PHP 5.4 through 8.5 that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP says the risk is highest with mod_php.
In plain words, PHP mishandles fatal errors, especially running out of memory, partway through a request:
- The first bug lets an out-of-memory error interrupt PHP while request data is only half set up. Cleanup then treats the broken data as valid.
- The second bug lets state from one request outlive the memory it lived in, so the next request on the same worker can use what was left behind.
Chained together, they let an attacker run code on the server without a login. The disclosure is blunt: “even a simple ‘Hello World’ application running on an affected PHP version can be vulnerable.” Even short of a takeover, the bugs can leak what sits in a worker’s memory: passwords, tokens, API keys and certificates.
Wiz, one of the teams that found the bugs, showed working takeovers of WordPress, Drupal and Joomla using their official container images. Wiz’s write-up has the research; PHP’s advisory is the official word.
Why it matters if you run an always-on agent
A personal agent that runs around the clock is a server holding the keys to your accounts, and PHP2Shell is a server problem. Open-source agents like OpenClaw, Hermes Agent, NanoClaw and ZeroClaw often run on a home machine or a rented server, with API keys, chat logins and long-term memory on the same disk.
None of those agents needs PHP to run. The risk is what runs next to them:
- A shared server. A WordPress blog, a hosting control panel or an old admin page on the same machine is enough. Once an attacker can run code on a server, whatever else lives there, including your agent’s keys and memory, is within reach.
- Keys in memory. The memory leak alone can expose passwords, tokens and API keys that a PHP app holds. If a PHP app on your server used the same AI provider key as your agent, that key was at risk while you were unpatched.
- PHP you forgot about. PHP often ships inside other software and control panels such as cPanel and Plesk, so “I don’t use PHP” is worth checking, not assuming.
How AI helped defenders get there first
This time, AI found the hole before attackers did, and the people fixing it got a head start. The flaw class was old and long thought impractical to exploit. A PHP core developer had found one of the out-of-memory bugs in an earlier audit, but it was never fixed: there was no agreement on how, and no known exploit.
In August, Ryan Austin of the security firm Calif found a critical flaw using OpenAI’s GPT-5.6 Sol during an audit of PHP’s source code, as part of OpenAI’s Patch the Planet initiative. Wiz Research independently found and reported both bugs, using its own Wiz Atlas alongside Google’s Gemini 4 Argon and GPT-5.6 Sol. Wiz says proving the bugs could be exploited “required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier.”
Over the following weeks, OpenAI led a coalition of maintainers, researchers and security providers, including Wiz and Cloudflare, working with CISA, the US Office of the National Cyber Director and international partners. OpenAI’s summary: “To our knowledge, frontier AI found these vulnerabilities before attackers did, opening a Defender’s Window.”
The same tools cut both ways. OpenAI warns that “the same capabilities can also help attackers rapidly develop offensive tools and exploits,” and Amazon, speaking generally, says AI-assisted analysis makes it cheaper to turn a patch into a working exploit, so more attackers can move within hours or even minutes. No source shows the PHP2Shell attackers used AI.
What happened when it went public
Attempts started before the patch, and the biggest visible damage so far has been sites switched off as a precaution.
- October 17: Amazon’s decoy servers caught the first known attempt, days before disclosure, coming from a commercial anonymization network. Amazon says it is unclear how the attacker got the details.
- October 20: PHP announced a security release for the next day, and word of the bugs started spreading online the same day.
- October 21, early: Cloudflare’s firewall began blocking the attack by default for free and paid customers, hours before disclosure, while attackers reworked their payloads to slip past.
- October 21: PHP shipped the fixes and the bugs went public. Attempts climbed fast. CISA told organizations to patch immediately, or take systems offline if they can’t.
- October 21–22: as a precaution, government sites in Finland, the Netherlands, France and the UK, Japanese banks and airlines, and services like Wikipedia’s tools and the Internet Archive went offline while they patched.
Who is behind the attacks is unknown. No source ties them to any country or named group. Amazon saw unnamed actors hiding behind anonymization networks, and Sophos saw a criminal botnet, a Mirai variant, trying to plant itself on servers.
Whether anyone actually got in is still an open question. Amazon and watchTowr report exploitation in the wild, though Amazon says it is unclear whether any attempt would have worked on real systems. As of October 22, CISA, Germany’s BSI, the Dutch cyber agency and Japan’s government had not confirmed a successful break-in.
What to do now: a checklist
Patch first. Everything else only buys time.
- Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer. Linux distributions and long-term support vendors got the fixes in advance, so check your vendor’s packages too.
- On PHP 8.1 or older, there are no official updates. Use your distribution’s or support vendor’s backport, PHP’s minimal source backports for 7.4, 8.0 and 8.1, or upgrade.
- Find the PHP you forgot. Hosting control panels like cPanel and Plesk, old WordPress installs, and any server your agent shares.
- Can’t patch today? CISA says take PHP systems offline until you can. It adds that a web application firewall “may provide some protection,” and Cloudflare calls one defence in depth, not a fix.
- Stopgaps only if you must wait. PHP’s advisory lists a few settings that reduce exposure. Use its exact values and restart every PHP worker afterwards. They are not safe on their own.
- Look for a break-in from October 17, not from the disclosure date. Watch for PHP workers launching shells or downloading tools.
- Protect your agent’s keys. If an unpatched PHP app shared a server or secrets with your agent, rotate those API keys and chat logins.
- On WordPress.com? Automattic says its sites are protected. A self-hosted site is yours to patch.
AI opened the defenders’ window this time. It only helps the people who use it: update today.
Sources
Every agent card on this page comes from the live AIcensus directory and updates on its own. Listings were last checked on October 22, 2026. Each fact is checked against the maker's own site.
