PHP2Shell Patch Is Out. The Internet Didn’t Go Dark, but Europe Unplugged Its Own Sites.

For about 36 hours this week, a programming language most people never think about turned into front-page news. Government portals in the Netherlands, France, Germany and Belgium went dark on purpose. Cloudflare pushed emergency firewall rules to every customer, including free accounts. And social feeds filled up with a scary line: 75% of the internet could go dark.

The trigger was a pair of critical bugs in PHP, the server-side language behind WordPress, Drupal, Joomla, Magento and millions of homegrown sites. As UNILAD Tech reports, EU cybersecurity officials warned organizations that a mass of websites might have to be taken offline, while PHP’s developers lined up patches for October 21. Reuters put the release window at 1400 GMT (0900 EST), and the fixes landed on schedule.

So did the internet go dark? No. But this was not a false alarm either. Here is what actually happened, what was hype, and what you need to do if you run a PHP site.

What PHP2Shell actually is

Both bugs live in PHP’s core interpreter, not in any plugin or framework. That is why they are so broad. According to the CERT-EU advisory and write-ups from Datadog Security Labs and Help Net Security, CVE-2026-109618 is a memory corruption problem in out-of-memory handling: PHP can be interrupted while internal request data is only partly initialized, and cleanup then treats that garbage as valid. CVE-2026-109619 is a stale-state bug, where request-owned state survives after its memory is freed and a later request on the same worker can use it.

In plain terms, a remote attacker with no login can send crafted requests and end up running code as the web server user. One of the flaws can also leak PHP worker memory. Security researchers who tested it say the session upload progress feature, which is switched on by default in stock php.ini, is one confirmed path to trigger the second bug.

Every web-facing setup is in scope: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Datadog and The Hacker News single out Apache with mod_php as the worst case, because the bug can fire before any application code runs. The vulnerable code path reportedly dates back to PHP 5.4, released in 2012.

Found with AI, then leaked

The backstory is as interesting as the bug. PHP’s advisory credits researchers from Calif, Wiz and OpenAI. According to The Next Web, Calif found one flaw in August using an OpenAI model under OpenAI’s “Patch the Planet” program and reported it to PHP on August 11. Wiz found its own bug on August 19 and says it confirmed unauthenticated code execution against Drupal and WordPress within two days. OpenAI president Greg Brockman described the effort on X as a coalition to mitigate “one of the most severe bugs in open source software found in recent memory.”

The plan was a coordinated disclosure on October 22. Then the CVE IDs started circulating on forums and social media on October 20, and PHP pulled the release forward a day. If AI-assisted bug hunting sounds familiar, it is the same trend that pushed regulators to start thinking about autonomous tooling, as in India’s CERT-In warning about rogue AI agents.

Why European governments pulled the plug

CERT-EU, the cybersecurity service for EU institutions, published its advisory on the evening of Tuesday, October 20. Its advice was blunt: organizations that cannot patch quickly should isolate internet-facing PHP applications or consider taking them offline. Agencies in Australia, Japan and the UK urged immediate updates too, and the US National Security Agency said systems that cannot be updated right away should come offline until the issue is mitigated.

A lot of public bodies took that literally. Reuters compiled a list on October 21:

• Netherlands: the Port of Rotterdam, the government portal Overheid.nl, football association KNVB, the five largest political parties and numerous hospital sites went offline.
• Germany: federal IT provider ITZBund took several sites down, calling it purely preventive with no known incidents.
• France: the Interior Ministry took prefecture websites offline while waiting for the fix.
• Belgium: the foreign ministry temporarily removed its websites, though the national cybersecurity center said it had recorded no attacks on Belgian sites.
• Wikimedia Foundation: shut down a number of systems as a precaution until they could be patched.

That is the real story behind the “internet goes dark” headlines: the outages were mostly deliberate, trading a few hours of downtime for not being an easy target.

Cloudflare’s stopgap, and the first attacks

Cloudflare says it switched on new managed WAF rules at 03:02 UTC on October 21, roughly nine hours before public disclosure, for free and paid customers alike. It logged the first attacks against PHP sites at 07:43 UTC, well before the patch window opened. CTO Dane Knecht said the company was “seeing early attacks emerging” and updating mitigations as new vectors showed up, according to Reuters and other reports. He was equally clear about the limits: “This is a STOPGAP only,” he wrote on X. “Patch as soon as PHP releases the update.”

That caveat matters. A WAF filters known request shapes. It cannot fix the interpreter, and it does nothing if an attacker can reach your origin server directly and skip Cloudflare entirely.

Other telemetry backs up the threat. Amazon Threat Intelligence says its MadPot honeypots caught a PHP2Shell exploit attempt on October 17, four days before disclosure, and saw more attempts from multiple actors after the patch shipped, though it said it was unclear whether those attempts would have worked against real systems. watchTowr reported exploitation attempts hitting its sensors around patch time but no successful compromises. As of this writing, we have not seen a confirmed, publicly documented breach of a specific production server. A successful exploit may not crash anything, so “no visible problem” is not proof of safety.

The 75% claim: hype versus facts

The viral number comes from W3Techs, which tracks server-side languages. Its October 2026 figures put PHP at 69.3% of websites whose server-side language it can detect, far ahead of JavaScript at 8.1% and Ruby at 7.1%. “Over 75%” is an older or rounded figure, and either way it describes sites that use PHP, not sites that were about to vanish.

The more useful number is the second one. About 34.6% of PHP sites still run version 7 or 5, per W3Techs, and those branches have no official PHP2Shell release at all. Internet scanner Censys estimated, per Reuters, that about 1.5 million of 2.6 million PHP hosts it sees report a version with no fix. Those are the sites that are genuinely in trouble, and they are where the warning UNILAD quotes from an engineer, that some sites could go dark for weeks, is most plausible: a site stuck on PHP 7.2 cannot simply install a patch, it needs a migration.

The big-name examples in the viral posts also deserve a footnote. Facebook runs on Hack and HHVM, its own runtime, not the standard PHP interpreter that was patched. Automattic said its hosted WordPress.com services and Tumblr were safe from the bug, according to Reuters.

Which versions are fixed

CERT-EU notes the PHP security team published minimal source backports for 7.4, 8.0 and 8.1, which matters mostly to Linux distributions and long-term support vendors that build their own packages. Several distributions received patches before the public release, so check your vendor’s security notices as well as php.net.

What site owners should do today

First, the WordPress question, since that is where most PHP sites live. WordPress.org says no WordPress update is required or planned for this, and Wordfence’s Alex Thomas warned that “WordPress automatic updates will not apply this fix.” The bug is in PHP itself, so a fully updated WordPress site can still be exposed. Unlike a plugin hole such as the one fixed in the AMP for WP plugin, this one is your host’s job, or yours if you manage the server.

If you run your own VPS or cloud box, check what is actually serving web traffic. The CLI version and the FPM or Apache module version can differ.

# 1. Check the CLI version (should be 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later)
php -v

# 2. Check the version the web server really uses
#    (drop a temporary file, load it once, then DELETE it)
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/v.php
curl -s https://your-site.example/v.php && sudo rm /var/www/html/v.php

# 3. Debian / Ubuntu: pull the patched packages and restart workers
sudo apt update && sudo apt install --only-upgrade 'php8.*'
sudo systemctl restart php8.3-fpm   # match your version
sudo systemctl restart apache2      # if you use mod_php

# 4. RHEL / Alma / Rocky
sudo dnf upgrade 'php*' && sudo systemctl restart php-fpm

# 5. Docker: rebuild on the refreshed official image
docker pull php:8.4-fpm && docker compose up -d --build

Restarting matters. Patched files on disk do nothing while old PHP workers keep running in memory. Note too that distribution packages often keep their own version string with backported fixes, so on Ubuntu or Debian compare against the vendor’s security notice rather than the upstream number alone.

On shared or managed hosting, open a ticket and ask a direct question: has PHP been updated to a fixed build for CVE-2026-109618 and CVE-2026-109619, and have the workers been restarted? Laravel Forge, for example, says its automatic security updates do not patch PHP, so Forge servers need a manual update. If your host only patched the newest branches, switch to 8.2 or newer in cPanel’s MultiPHP Manager or your panel’s equivalent. Teams running frameworks on their own infrastructure, like the setup in our guide to running CakePHP on cloud hosting, should rebuild images and redeploy rather than patch live containers.

Finally, if a server was exposed and unpatched between October 17 and your update, look for signs of compromise: unfamiliar PHP files in upload or cache directories, new cron jobs, unexpected outbound connections from the web user. Armis advises preserving evidence before restarting if you suspect a break-in.

The takeaway

The internet did not go dark. What did happen is more telling: a bug that sat in PHP for over a decade was found with AI help, leaked before the fix, drew attack traffic within hours, and pushed governments to unplug their own websites. The patch is out. The long tail of sites stuck on PHP 7 and 5 is the part that will take weeks, and some of those sites will not make it.

Sources and further reading

• UNILAD Tech: PHP outage warning (Tom Chapman, Oct 21, 2026)
• The PHP Foundation: Today’s PHP Security Release
• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Reuters via US News: Government websites go dark after flaw sparks security scramble
• Reuters factbox: Websites taken offline over PHP risks
• Datadog Security Labs: PHP2Shell analysis and remediation
• The Hacker News: PHP issues emergency patches as exploit attempts emerge
• AWS Security Blog: PHP2Shell exploitation prior to public disclosure
• SecurityWeek: PHP2Shell patches land as first exploitation attempts hit sensors
• Help Net Security: PHP2Shell vulnerabilities patched
• The Next Web: PHP rushes out patches for bugs AI found first
• W3Techs: Usage statistics of PHP, October 2026
• Laravel Forge: PHP security advisory
• Tenable: PHP2Shell FAQ

About this article: GeekBlog covers U.S. technology news, AI, phones, smartwatches and gaming. Every story is written and checked under our Editorial Policy. Spotted a mistake or have a story tip? Contact our editors.