Security
PHP2Shell Explained: How a 14-Year-Old Bug Put Most of the Web at Risk
PHP2Shell: two critical PHP flaws hidden for 14 years, found with AI and patched on 21 October 2026. What happened, why it is so big and what it means.
· By the Letzscale team · 9 min read ·
On this page
PHP2Shell is a pair of critical flaws in PHP, the language behind roughly 70% of websites, that sat in its code for about 14 years until AI-assisted researchers turned them into working attacks. The fix shipped on 21 October 2026, a day earlier than planned after news of the flaws leaked. As of 22 October, researchers say the attack code circulating so far mostly fails against standard setups, but every PHP website still needs the update. This article explains how it happened and why. For what to do, see our action list.
What happened
On 21 October 2026, the PHP project released emergency updates for two flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both are rated 9.2 out of 10 for severity (Sansec).
The flaws let an attacker run their own code on a web server, or read data from its memory, without logging in. That memory can hold passwords, login tokens and API keys (Wiz).
| Key fact | Detail |
|---|---|
| Affected | Every PHP version since 5.4, released in 2012 (about 14 years of releases) |
| Fixed in | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 |
| PHP 8.1 and older | No official release. Backported fixes exist and some Linux distributions and support vendors have built them in; other sites need to upgrade to 8.2 or later (Help Net Security) |
| Potentially exposed servers | About 22.6 million, per an initial count by Palo Alto Networks (Fortune) |
| Discovered by | Calif, Wiz and OpenAI, using AI models |
Timeline
PHP and the researchers kept the flaws under wraps for about ten weeks while a fix was built. The secret broke two days before the planned release.
| Date | What happened |
|---|---|
| 2024 | An external audit of PHP by Quarkslab turns up the first signs of the problem; a fix stalls (PHP Foundation) |
| 1 August 2026 | Calif finds the first flaw using OpenAI's GPT-5.6 Sol (Fortune) |
| 11 August | Calif and OpenAI each report the same root cause to PHP (PHP Foundation) |
| 19 August | Wiz independently finds the flaws using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol (Wiz) |
| 24 August | Wiz reports to PHP |
| 17 October | Amazon sees the first attack attempt on its decoy servers, four days before disclosure (AWS) |
| 20 October | CERT-EU issues an advisory naming both flaws (SecurityWeek) |
| 20 October, about 15:00 UTC | The CVE numbers leak on forums and social media, without technical details; PHP pre-announces the release and moves it forward a day (PHP Foundation) |
| 20 October, about 20:00 UTC | Calif mistakenly publishes a demo video of its attack, later deleted |
| 21 October, 07:41 UTC | Chainguard publishes patched builds early, breaking the embargo |
| 21 October, 07:43 UTC | Cloudflare reports early attacks (Sansec) |
| 21 October, 14:00 UTC | PHP releases the fixed versions; researchers publish their findings |
| 22 October | Sansec reports that mass break-ins look less likely than first feared |
How it was found: AI did what humans couldn't scale
The flawed code had been in PHP for about 14 years, and a limited version was spotted in a 2024 audit but judged minor at the time (Fortune). What changed in 2026 was AI.
Three groups found parts of the problem independently in August, all using AI models:
- Calif, an AI red-teaming firm, was hunting for flaws in critical software as part of OpenAI's "Patch the Planet" initiative. It found the first issue with GPT-5.6 Sol.
- OpenAI investigated Calif's finding and uncovered further parts of the flaw, showing it was more serious than first thought.
- Wiz, the cloud security company owned by Google, found the flaws separately using its Wiz Atlas tool, Google's Gemini 4 Argon and GPT-5.6 Sol.
OpenAI then brought the groups together with PHP, Cloudflare, Quarkslab and US government agencies to build and verify a fix.
Wiz says turning these flaws into a working attack used to need a world-class team working for months, because each server lays out its memory differently. With frontier AI models, a single researcher did it in about a week, adapting the attack to different setups in hours (Wiz). Wiz compares the moment to Heartbleed in 2014 and Log4Shell in 2021, two flaws that changed how the industry thought about shared software.
Why this one is so big
Most website security flaws live in one plugin or one app. PHP2Shell lives in the engine underneath all of them, so a site can be exposed even if its own code is perfectly secure.
- Reach. PHP has grown up with the web since 1994. It runs WordPress, which alone powers around 40% of websites, plus Drupal, Joomla, Magento and Wikipedia's software (Fortune).
- No login needed. The attack works on visitors' requests before the website's own code even runs. Even a one-line "Hello World" page on an affected server can be vulnerable (Wiz).
- Memory leaks. One of the flaws can leak chunks of server memory on its own, similar to the 2014 Heartbleed bug (Sansec).
- Old servers. Many websites run PHP versions that no longer get official releases. Some hosts have applied the fix to older versions; others will need a bigger upgrade to 8.2 or later (SecurityWeek).
In plain terms: the bugs sit in how PHP cleans up after a request crashes from running out of memory. A crashed request can leave behind stale data that the next visitor's request reuses, and an attacker can shape that leftover data to take control.
Why it wasn't fixed sooner. The PHP Foundation says its developers first saw signs of the problem in 2024, during an external audit by Quarkslab funded by Germany's Sovereign Tech Agency. Every possible fix had trade-offs, the security team couldn't agree on one, and only a handful of developers know the engine well enough to decide, so the work stalled for months. The Foundation calls the delay a structural failure and is changing how its security team makes decisions. It also notes the pressure AI puts on maintainers: the team has published 15 security fixes since July and worked through more than 100 reports that turned out invalid or duplicates (PHP Foundation).
The leak: why attacks started before the fix
Security flaws like this are normally kept under embargo until the fix is ready, so defenders and attackers learn about them at the same moment. That window collapsed for PHP2Shell.
According to the PHP Foundation, the CVE numbers began circulating on forums and social media around 15:00 UTC on 20 October, with a wrong release time and an exaggerated severity score, but no technical details. PHP brought its announcement forward and moved the release up a day, to 21 October. That evening, Calif mistakenly published a video of its attack working, which revealed some extra details and sped up copycat attack code. Then at 07:41 UTC on 21 October, the software supplier Chainguard published patched builds more than six hours before the agreed time, letting anyone study the fix early (PHP Foundation).
Someone may have known even earlier. Amazon recorded an attack attempt on its decoy servers on 17 October from an anonymised network, and it is unclear how that attacker got the information. Amazon advises investigators to check their logs from 17 October, not just from the disclosure date (AWS).
Once word spread, attempts climbed fast. Cloudflare saw tens of thousands within 45 minutes and millions by the evening of 21 October, according to its CEO (Fortune).
Who was hit and how the internet responded
The visible damage so far is precautionary downtime, not confirmed mass break-ins.
- Sites taken offline as a precaution: the Dutch House of Representatives, the Dutch cybersecurity authority (NCSC), tech site Tweakers and Security.NL in the Netherlands (Sansec), Finnish government services (The Register), and the Internet Archive (Fortune).
- Government warnings: the EU's computer emergency team, the US FBI, NSA and CISA, and Japan's prime minister all urged organisations to update (Fortune, SecurityWeek).
- Infrastructure protection: Cloudflare, AWS, Google Cloud, Microsoft, Fastly, Akamai, Vercel and Automattic (WordPress.com) prepared filters for customers who can't update right away (Wiz). These buy time but don't replace the update.
The picture on day two is calmer. On 22 October, Sansec reported that a real attack needs specific knowledge of the target server, that the public attack code doesn't work on a default PHP setup, and that online shops don't need to go offline, though they should still update (Sansec). watchTowr likewise found that none of the attack code circulating publicly achieves a full takeover (SecurityWeek). Skilled attackers with their own tools remain the real risk.
What it means in Luxembourg
As of 22 October, we found no PHP2Shell-specific notice from GOVCERT.LU, which covers the public sector, or from CIRCL, which covers private companies and communes. CERT-EU, the response team for the EU institutions, several of which are based in Luxembourg, issued its advisory on 20 October (SecurityWeek).
As elsewhere, many Luxembourg business websites run on WordPress, often built by small agencies on shared hosting. Many also publish in French, German and English, which means more pages where an attacker could hide spam after a break-in. If you think your site was attacked, CIRCL is the national contact for private-sector incidents.
What it means for businesses
PHP2Shell is unlikely to be the last crisis of this kind. Three things follow for anyone who runs a business website.
1. Expect more emergency updates. AI makes it far cheaper to find and exploit old flaws, for defenders and attackers alike. PHP2Shell came three months after wp2shell, a separate takeover flaw in WordPress itself disclosed in July 2026 (Elastic). A website that "just works" and hasn't been touched in years is now a real risk. Know who updates yours, and how fast.
2. Expect scam emails riding the panic. Fraudsters pose as hosting companies and domain registrars during security scares, with urgent notices and fake login pages. Our action list explains how to spot them.
3. Your visibility can take a hit long after the fix. Long downtime can get pages dropped from Google, and hacked sites often get hidden spam pages that cost rankings and mentions in AI assistants weeks later. The action list covers how to go offline safely and what to check afterwards.
What to do next
If your website runs on WordPress, Drupal, Joomla, Magento or shared hosting, ask your hosting company or web agency today whether PHP has been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On PHP 8.1 or older there is no official release, so ask whether they applied the fix or need to upgrade to 8.2 or later.
Step-by-step help: What to Do About PHP2Shell has the questions to send your agency, how to go offline without losing your Google ranking, and a checklist for after the update.
Check your visibility: Letzscale checks how your business appears in Google and in AI assistants such as ChatGPT, Gemini and Google AI Overviews. If your site went offline this week, or you're not sure it came through clean, get a free report in English or French.
More from Letzscale: Insights · Guides
Sources
- PHP Foundation: Today's PHP security release
- Wiz Research: PHP2Shell, AI uncovers critical RCE vulnerabilities
- OpenAI: Coordinated disclosure of critical vulnerabilities
- Fortune: AI tools discovered the PHP vulnerability
- Sansec: PHP2Shell, with 22 October update
- AWS Security Blog: PHP2Shell exploitation prior to public disclosure
- SecurityWeek: PHP2Shell exploitation started days before patches
- SecurityWeek: Mass exploitation looms for leaked critical PHP flaws
- Help Net Security: PHP2Shell patched, update now
- The Register: PHP devs publish critical bug fix
- Elastic Security Labs: wp2shell
This article is general information based on public reporting as of 22 October 2026. The situation is still developing. For the security fix itself, follow your hosting provider and the official PHP advisory.