PHP-Touch3LL: the day the web went dark

Yesterday, October 21, 2026, I saw something I thought only happened in movies. The French tax website, the prefectures, Météo-France, the CNIL, the Finnish government, the Port of Rotterdam… all switched off on purpose. Not because of a massive hack, but as a precaution. And the cause fits in three letters: PHP.

Here's what happened, in simple terms, and above all what I take away from it as a dev student and builder.

PHP, the hidden engine of the web

PHP is a language born in 1994. Rasmus Lerdorf hacked it together to count visits on his online resume. Thirty years later, it runs about 69% of websites whose server language is known: WordPress, Wikipedia, PrestaShop, and lots of public-sector sites.

The best image I've found: websites are the bodywork. WordPress, Wikipedia, impots.gouv all look different. But under the hood, it's the same engine. If the engine fails, every car stops, no matter how good-looking or well built it is.

In France, ANSSI (the national cybersecurity agency) counts more than 600,000 exposed PHP servers. Worldwide, Palo Alto Networks counts 22.6 million. In other words, PHP is a single point of failure for a huge part of the Internet.

The flaw, without the jargon

The flaw is called PHP-Touch3LL, rated 9.2/10 in severity. It's actually two bugs combined.

The first (CVE-2026-109618): PHP gives each request a limited amount of memory. If a request goes over, it gets cut off. The problem is that if the cut happens at the wrong moment, for example while reading a file uploaded through a form, the data is left half-prepared. And during cleanup, PHP can treat it as if it were valid.

The second (CVE-2026-109619): a PHP server uses "workers" that serve visitors one after another. Normally, each worker cleans up between two visitors. Here, a piece of the previous request can survive in memory.

Picture a hotel housekeeper interrupted mid-cleaning. She still marks the room as ready, and the next guest finds the previous guest's keys and papers. Worse: an attacker who picks the moment of the interruption can pick what's left in the room.

Possible result: running code remotely on the server without a password, or stealing other users' passwords, keys and data.

And the nastiest part: all of this happens inside the PHP engine, before the site itself even runs. Putting your WordPress in maintenance mode does nothing, the malicious request has already been read. Researchers showed that even a "Hello World" page was vulnerable.

A flaw known since… 2004

What shocks me most is that this isn't really a surprise:

• 2004: Stefan Esser already spots a memory management problem in request handling.
• 2012: PHP 5.4 ships, and the oldest attack path goes back to this version.
• 2019: a "harmless" bug about overly long requests is reported. No follow-up.
• 2024: a Quarkslab audit again points to the memory fragility, but without a concrete exploit, the fix is postponed.
• 2024 to 2026: the PHP security team, which works by consensus, can't agree on the right fix.

More than twenty years of technical debt. And that's where AI comes in.

AI sped everything up

This summer, the startup Chalif took part in OpenAI's "Patch the Planet" program. A single researcher picked up Esser's work, asked an AI how to trigger a memory overflow at a precise spot… and within a few days, took control of a WordPress site. With consumer models.

At the end of August, Wiz found the same flaw on its own. Their conclusion: one researcher, with the right models, did in a week what would have taken an elite team months.

A timeline of cascading leaks

The plan was a clean fix on Thursday, October 22. It didn't go as planned:

• Oct 20, 5pm: an anonymous post on Hacker News, picked up on X with a false 10/10 score. The secret is out.
• Oct 20, 9:30pm: PHP moves the fix up to the 21st.
• Oct 21, 5am: Cloudflare deploys emergency filters, even for free accounts.
• Oct 21, 9:41am: the vendor Changard publishes its patched packages too early. By comparing the old and new code, anyone (and any AI) can locate the flaw in minutes.
• Oct 21, ~3:30pm: official release of the patched versions.
• Oct 21, 3:45pm: the NSA publishes a crystal-clear message: if you can't update, shut it down.
• Oct 21, ~4pm: Chalif accidentally leaks a demo video.
• Oct 21, 4:19pm: WatchTower detects the first real attacks.

That same evening, the PHP Foundation acknowledged a "structural failure": too few resources, a decision process that's too slow, and the security of the entire PHP web resting on a handful of devs and a few volunteers.

The great shutdown

Every agency (ANSSI, NSA, NCSC, CERT-EU…) said the same thing: no tested update right away, so pull the plug. The locksmith analogy sums it up: if the manufacturer announces your lock opens in two seconds and the locksmith hasn't come by yet, you close the shop.

In France: Météo-France closed at 4:40pm, every prefecture in maintenance, impots.gouv, several ministries, the CNIL, Les Échos. Internationally: Finland, the Dutch Parliament, Rotterdam, Munich, European hospitals, part of Wikimedia, and even Steam for a few hours. In Japan, the Prime Minister publicly asked every organization to check their PHP.

What about Node.js?

I mostly build in JavaScript and TypeScript. So my first reaction was obviously: "phew, not my stack". Except that on the same day, October 21, Node.js published its own wave of security fixes.

It has nothing to do with PHP-Touch3LL, it's a separate security release. But it's not trivial either:

• 10 vulnerabilities fixed, 4 of them rated "high" severity, across every supported line (26.x, 24.x and 22.x).
• The most serious one (CVE-2026-111497): an out-of-bounds write in the Brotli decoder, the compression format used all over the web. Node.js says it can allow remote code execution. Same family of problem as PHP: memory written where it shouldn't be.
• Three flaws let attackers bypass TLS certificate hostname checks when an IP address is written in an "odd" way (fullwidth digits, non-canonical IPv4 forms…). Put simply: one server could pass itself off as another.
• A less flashy but sneaky one: crypto.randomUUID() and randomInt() could return the same values on every startup for apps built from a startup snapshot or as a single executable (SEA). "Random" identifiers that aren't random anymore.
• The rest affects DNS, HTTP keep-alive, the ZIP reader and the Permission Model, plus dependency updates (OpenSSL, Undici, c-ares, SQLite, root certificates).

The patched versions: v26.12.1, v24.22.1 and v22.23.4. And as always, end-of-life versions are affected and won't be fixed.

The big difference with PHP: nobody had to pull the plug on anything. The process worked as intended: report, fix, coordinated release. But it reminded me that my stack isn't a fortress either. It also rests on building blocks maintained by a small team, and it also needs updating.

No, the Orange outage had nothing to do with it

The same day, the Orange mobile network (and Sosh) went down from 11:20am, for almost 10 hours, with emergency calls disrupted. On social media, people quickly started talking about cyberwar.

Except no. Orange confirmed a hardware failure on a core network device. Zero link to PHP. Just a coincidence, in an already busy week (the day before, a Google datacenter in London had taken down Revolut and several British banks). A small lesson along the way: two outages at the same time doesn't mean a single cause. Neither do two security announcements on the same day (PHP and Node.js).

What I take away

Experts compare this to Heartbleed (2014) and Log4Shell (2021). The difference here is that the flaw was found by defenders, handled in secret, and a series of leaks forced everything forward. But it's also the first big crisis of the AI era.

Three things stick with me:

1. The digital commons are fragile. The web generates hundreds of billions, and it rests on open source building blocks maintained by a few underfunded people. PHP and Node.js alike. That hits home, because I build on open source every day too.
2. AI shifts the balance of power. Finding a flaw and turning it into a real attack now takes days, not months. It works both ways, but attackers only need to succeed once.
3. Forgotten sites are the real problem. Big organizations shut down and patched within the day. But millions of small sites that never get updated will stay vulnerable for months. Their owners are in the race without even knowing it.

So, concretely, what do you do?

• If you have a PHP site (WordPress included, even an old blog): update PHP now, not just your CMS. On shared hosting, check that your host did it.
• If you run a Node.js server: move to v26.12.1, v24.22.1 or v22.23.4 depending on your line. Don't forget your Docker images and your CI, which often pin a fixed version. And if you're still on an end-of-life version, now's the time to migrate.
• If you can, put a WAF like Cloudflare in front, it served as the first line of defense.
• Take inventory of what's actually running on your servers. You can't protect what you don't know you have.
• And if your company lives off open source, think about funding the projects you depend on. Yesterday showed what it costs not to.

As I write this, no successful intrusion through PHP-Touch3LL has been publicly confirmed, and services are coming back little by little. But I'm convinced of one thing: this wasn't the last crisis of its kind. With AI, the next one will come faster.

Sources

1. 01Node.js Security Releases: October 21, 2026Node.js / October 21, 2026