Skip to content
Letzscale

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
  1. What happened
  2. Timeline
  3. How it was found: AI did what humans couldn't scale
  4. Why this one is so big
  5. The leak: why attacks started before the fix
  6. Who was hit and how the internet responded
  7. What it means in Luxembourg
  8. What it means for businesses
  9. What to do next
  10. Sources

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 factDetail
AffectedEvery PHP version since 5.4, released in 2012 (about 14 years of releases)
Fixed inPHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
PHP 8.1 and olderNo 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 serversAbout 22.6 million, per an initial count by Palo Alto Networks (Fortune)
Discovered byCalif, 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.

DateWhat happened
2024An external audit of PHP by Quarkslab turns up the first signs of the problem; a fix stalls (PHP Foundation)
1 August 2026Calif finds the first flaw using OpenAI's GPT-5.6 Sol (Fortune)
11 AugustCalif and OpenAI each report the same root cause to PHP (PHP Foundation)
19 AugustWiz independently finds the flaws using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol (Wiz)
24 AugustWiz reports to PHP
17 OctoberAmazon sees the first attack attempt on its decoy servers, four days before disclosure (AWS)
20 OctoberCERT-EU issues an advisory naming both flaws (SecurityWeek)
20 October, about 15:00 UTCThe 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 UTCCalif mistakenly publishes a demo video of its attack, later deleted
21 October, 07:41 UTCChainguard publishes patched builds early, breaking the embargo
21 October, 07:43 UTCCloudflare reports early attacks (Sansec)
21 October, 14:00 UTCPHP releases the fixed versions; researchers publish their findings
22 OctoberSansec 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

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.

PHP2Shell Explained: How a 14-Year-Old Bug Put Most of the Web at Risk | Letzscale