The short version: update PHP, today
In October 2026, researchers revealed two critical flaws inside PHP itself (CVE-2026-109618 and CVE-2026-109619), nicknamed PHP2Shell. An attacker who can reach a vulnerable web server over the internet can run their own commands on it, with no username, no password and no help from a victim. PHP runs roughly 70% of sites whose server language is known, so the blast radius is enormous.
- It is not a plugin bug. The flaw is in the PHP engine under WordPress, Laravel, Drupal and everything else.
- Fixes exist: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches have no official release.
- It is being exploited. CISA added both flaws to its Known Exploited Vulnerabilities catalog on 26 October.
- No php.ini trick fully fixes it. PHP says updating is the only safe choice.
The week the internet went quiet
On 21 October 2026, government portals, school platforms, forums and even the Internet Archive disappeared from the web. Nobody had hacked them yet. Their owners had switched them off on purpose, because a flaw in PHP was about to be fixed and attackers already knew where to look.
According to reporting summarised on Wikipedia, sites taken offline as a precaution included the Dutch government portal Overheid.nl, all Finnish government public-facing web services and all websites of the French Interior Ministry, after advice from CERT-EU and the UK NCSC. The US NSA said sites that could not update should consider going offline.
This post explains PHP2Shell in plain English: what broke, why so many sites were exposed, what the numbers say a week later, and a checklist you can finish in an afternoon.
What happened, in 60 seconds
Here is the sequence of events that turned a quiet code audit into a global scramble.
Researchers find the bugs
Calif, working under OpenAI’s “Patch the Planet” initiative, found the flaws on 1 August and reported them to PHP on 11 August, according to Varonis. Wiz Research found them independently. AI models helped both teams.
First attack seen — four days early
Amazon Threat Intelligence later traced a PHP2Shell exploitation attempt in its MadPot honeypot telemetry back to 17 October, before anyone had published a fix.
The embargo leaks
Details leaked on Hacker News and social media. PHP pre-announced an emergency release, and watchTowr confirmed the rumours were real. Attackers did not wait for the patch.
Patches ship, sites go dark
PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The UK NCSC and NSA urged immediate updates, and many organisations took sites offline. watchTowr’s honeypots recorded exploitation the same day.
CISA confirms active exploitation
CISA added both CVEs to its Known Exploited Vulnerabilities catalog. TechCrunch reported that US civilian agencies were given three days to fix their systems.
A week on, the patch gap is huge
Censys counted 32.5 million internet-facing PHP services still showing a vulnerable version. OX Security found 93.6% of measurable PHP hosts still unpatched on day five.
Sources: PHP and watchTowr timelines, Varonis, Wikipedia (citing Reuters and BBC), AWS Security Blog, TechCrunch, Censys via Cybernews, OX Security. Dates are 2026.
Why “70% of websites” is not hype
PHP is a server-side language created in 1994. When you open a page, PHP often runs on the server behind it to assemble what you see. watchTowr puts PHP at 70.8% of sites whose server-side language is known, and W3Techs figures cited by Wikipedia are around 69%. That is more than ten times the next-closest language.
Sites that do not reveal their language are not in that number, so treat it as “most of the web”, not an exact census.
Where PHP is hiding
Content management systems
WordPress (over 43% of all websites, per watchTowr), Drupal, Joomla and Moodle all run on PHP.
Frameworks and online shops
Laravel apps, custom business portals and many e-commerce stores.
Hosting control panels
Tools such as cPanel and Plesk, plus some vendor appliances and Windows applications.
Cheap shared hosting
Old plans set up years ago and rarely touched, often on end-of-life PHP.
How a crash turns into a takeover
Forget the jargon for a moment. Think of a coat-check desk.
Normal day
You hand over a coat and get a numbered ticket. When you leave, the clerk tears the ticket up and the shelf is free for the next person.
PHP2Shell day
The desk is overloaded and the clerk walks away without tearing the ticket. A stranger now owns that shelf, but the old ticket still points at it, and the clerk trusts the ticket.
In real terms: PHP’s “session upload progress” feature, on by default since PHP 5.4, tracks file uploads. If a request is made to run out of memory while that is happening, PHP aborts the request and skips some cleanup. The leftover pointers survive into the next request handled by the same worker, which is the opening for a use-after-free bug.
Two CVEs, one nickname
| CVE | What PHP says it is | Severity | Exploited |
|---|---|---|---|
CVE-2026-109618 | Remote code execution via out-of-memory corruption during request cleanup | CVSS v4.0 9.2 | Yes (watchTowr; CISA KEV) |
CVE-2026-109619 | Remote code execution via stale request-owned global state reused by a later request on the same worker | CVSS v4.0 9.2 | Yes (watchTowr; CISA KEV) |
Some vendors scored it differently: Wikipedia reports watchTowr rated it 10.0, while PHP’s own rating is 9.2. PHP says every installation that serves web requests is in scope (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed), with the highest risk on Apache mod_php, where an attack can succeed before any application code runs.
The ripple effect: who switched off, and who got hit
Security teams expected attacks within minutes of the patch, so many organisations chose downtime over risk. Here is what reporting from Reuters, the BBC and others, as summarised on Wikipedia, says went offline or was disrupted.
Governments
Dutch portal Overheid.nl, Finnish public-facing web services, French Interior Ministry sites and some Canadian government sites went offline as a precaution.
Knowledge and community sites
The Internet Archive briefly shut down, Wikimedia turned off many supporting services, and forums such as 4chan and Something Awful went dark.
Games and shops
Several Japanese games and numerous e-commerce sites paused for emergency maintenance.
Banks and agencies
The Daily Star reported that some banks and government agencies in Bangladesh took sites offline, disrupting digital services.
Was it really exploited?
Yes, and earlier than most people expected.
- Before the patch: AWS saw an attempt on 17 October. Cloudflare reported signs of early exploitation and shipped temporary WAF rules, available to all customers including free plans.
- Day one: watchTowr’s honeypot network observed exploitation of both flaws on 21 October.
- Official confirmation: CISA added both CVEs to its KEV catalog on 26 October.
- Noise warning: Arctic Wolf saw many PHP2Shell-themed requests that actually reused older session-poisoning tricks. They show intent, not proof that these CVEs worked.
The patch gap, in charts
Patching is not instant. Four independent scans after disclosure tell the same story: most of the internet was still running vulnerable PHP days later. Treat each number as an estimate, because scanners mostly read the version a server announces about itself.
Patch gap one week in
Most PHP services still run vulnerable versions
Millions of PHP services, about a week after disclosure (Censys)
Source: Censys data reported by Cybernews. About 61 million more services hide their version. Distributions often backport fixes without changing the version number, so some “vulnerable” services may be patched.
The panic did not turn into patching
Unpatched PHP hosts after 24 hours vs 5 days
Share of measurable PHP hosts still unpatched (OX Security, via Shodan)
Source: OX Security. Hosts that hide their PHP version are excluded from these percentages.
Old PHP is the real problem
Which PHP versions are out there?
Hosts advertising each PHP branch, 20 October (thousands)
Source: Shodan counts published by Mallory and broken down by CybelAngel, via Notebookcheck. About 884,000 hosts (59% of those showing a version) were on branches with no official fix. About 740,000 more hide their version. These are banner counts, not confirmed vulnerable sites.
The servers that will never get an official patch
Here is the uncomfortable part. PHP’s fixes cover only 8.2 to 8.5. Branches 8.1 and older are end of life, so PHP published no release for them.
| Your PHP branch | Status | What to do |
|---|---|---|
| 8.5.x, 8.4.x, 8.3.x, 8.2.x | Fixed in 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Update and restart workers. |
| 7.4, 8.0, 8.1 | Affected, no official release | Use a distro or LTS vendor package, PHP’s minimal source backports, or move to a supported branch. |
| 7.3 and older (including 5.x) | Affected, no fix at all | Upgrade to a supported branch. Isolate the host until you do. |
Volunteers and hosting vendors stepped in. cPanel and CloudLinux shipped backports, and volunteer maintainer Ondřej Surý built installable packages for older versions so admins did not have to compile PHP themselves. The BBC profiled him as “the unsung hero of the internet”.
A bug that waited years
- Wikipedia, citing The Next Web, reports that a PHP core developer spotted the out-of-memory problem in a 2024 audit, but the team could not agree on a fix and no exploit existed, so it was not prioritised.
- TechCrunch says flaws like these, once judged impractical to exploit, are now being found and chained with help from AI models.
- The PHP Foundation, which maintains the language, is small and under-funded according to reporting in The Guardian and Reuters, even though the web leans on it heavily.
Six things people get wrong
The fastest way to stay safe is to avoid the half-truths that spread on social media.
Setting a php.ini flag fixes it.
PHP says there are no complete mitigations and updating is the only safe choice. watchTowr calls ini-only changes ineffective. Treat them as a stopgap at most.
It is a WordPress or plugin problem.
The flaw lives in the PHP runtime, not in your CMS or plugins. Clean application code does not protect you.
Only Apache mod_php is affected.
mod_php carries the highest demonstrated risk, but PHP says every installation serving web requests is in scope, including PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.
I run PHP 8.1, so I am not on the patch list.
You are on the no-official-patch list. 7.4, 8.0 and 8.1 are affected and need a backport or an upgrade.
php -v says I am fine.
The command-line PHP can differ from the one serving web traffic. Check the web-serving version with phpinfo() or your package manager.
Every “PHP2Shell” hit in my logs is a breach.
Some scans reuse older session-poisoning techniques. They show attackers are probing, not that these CVEs succeeded.
Am I affected? A 60-second self-test
Answer two quick questions. Use the version that actually serves web requests, not just the command-line one.
| Branch | Fixed release |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 (8.2 reaches end of life on 31 December 2026) |
Your patch plan, step by step
Tick items off as you go. Progress stays on this page only, and nothing is stored or sent.
Do now (first hour)
Patch (today)
Hunt (this week)
Stay safe (this month)
How to tell if you were hit
If a server was reachable and unpatched, assume someone may have looked at it. The NCSC advises checking for backdoors before you upgrade systems you could not patch straight away.
In your logs
Unusually large or deeply nested multipart requests, workers hitting the memory limit, and bursts of HTTP 500 responses.
On the server
PHP processes spawning shells, new files in web roots, unexpected cron jobs or accounts.
On the network
Outbound connections from PHP processes that you cannot explain.
In your secrets
If memory could have leaked before patching, treat tokens, keys and credentials in that memory as exposed and rotate them.
The takeaway
PHP2Shell is a reminder that the web’s foundations are shared, aging and often under-resourced. A bug that waited years became a global emergency in a single week, and a week later most exposed servers were still not fixed.
You do not need to be a security expert to act. Find your PHP, update it to a fixed release or a vendor backport, restart the workers, and look for signs of compromise. If you manage a site for a client, send them this page and ask one question: which PHP version is serving traffic right now?
Where this information comes from
Editorial note: facts are as reported on 1 November 2026 and the situation is still evolving, so check the PHP advisories and CISA for updates. Exposure figures are third-party scan estimates that depend on servers announcing their PHP version. This article is general guidance, not a substitute for an incident response.
Discussion