On 21 October 2026 the software underneath most of the web turned out to have holes in it. Millions of break-in attempts followed within days. Every site and app we build or host was patched and checked.
- Two flaws in PHP, rated 9.2 out of 10, exposed roughly 7 in 10 websites with no login needed
- Next.js and Node.js patched critical flaws of their own in the same 48 hours
- Six European governments took public websites offline while they caught up
- We worked through a 105-point checklist across 35 apps and 44 hosted sites
On Wednesday 21 October 2026, a large part of the internet found out at the same time that the software underneath it had holes in it. Governments took websites offline. Hosting companies worked through the night. Within days, websites around the world were being hit by millions of break-in attempts.
If you run a business website or an app, you may not have noticed a thing. That is how it should be. But it is worth knowing what happened, because it touched almost every kind of website, and because “we will deal with it when something breaks” is not a plan.
Here is the plain-English version: what went wrong, how big it got, and exactly what we did about it.
What actually went wrong
Three separate problems landed in the same 48 hours. Any one of them would have been a busy week on its own.
- PHP2Shell, the big one PHP is the language behind roughly 7 in 10 websites, including WordPress, Joomla, Drupal, WooCommerce and most shared hosting. Researchers found two flaws deep inside PHP itself. In plain terms: if a request crashed PHP in a certain way, it left scraps behind in memory, and the next visitor could pick those scraps up or use them to make the server run their own commands. Both were rated 9.2 out of 10 for severity.
- Next.js Next.js is the framework behind many modern web apps, including a lot of ours. On 20 October, two flaws were announced that could let an outsider run code on the server without logging in. Both were rated 9.5 out of 10.
- Node.js On the same day as PHP, Node.js, the engine that runs JavaScript on servers, fixed ten flaws. Four were rated high, including one that allowed remote code execution.
The nasty part of the PHP flaws is that a website did not have to be badly built to be at risk. A perfectly written site on an unpatched version of PHP was exposed, and nobody had to log in first.
These were flaws in the building blocks, not in anyone’s website. That is why it hit so many people at once.
How big it got
The news leaked a day before the planned announcement, and attackers moved faster than the fixes. Cloudflare saw the first attacks on the morning of 21 October, before PHP had released its patches that afternoon.
- 7 in 10Websites built on PHPWordPress, Joomla, WooCommerce and most shared hosting
- 9.2 / 10Severity rating of both PHP flawsNo login needed, and no badly built website required
- 5,000+Affected websites in Luxembourg aloneOne small country’s estimate in the first week
Governments in the Netherlands, Finland, France, Denmark, Germany and Luxembourg took public websites offline as a precaution. The organisation behind Wikipedia shut down several systems. The week it happened in was a busy one elsewhere too: a popular AI tool was poisoned with password-stealing code, and a certificate authority had its keys stolen.
- 19 August Researchers find the first of the two PHP flaws, with help from AI tools.
- 20 October Next.js announces two critical flaws. News of the PHP flaws leaks early.
- 21 October First attacks are seen hours before PHP releases its fixes that afternoon. Node.js fixes ten flaws the same day, and the US National Security Agency tells organisations to update or go offline.
- 22 October Websites worldwide are hit by millions of attempts to exploit the PHP flaws.
- 23 October The Dutch national cyber security centre starts looking into the first signs that attacks are succeeding.
Then there is the long tail. About half of all PHP websites run a version so old that it no longer gets security fixes at all.
A site on PHP 7 or older cannot be patched for this. It has to be upgraded, and old plugins and themes usually have to be sorted out at the same time. That is a project, not an afternoon, which is exactly why it keeps getting put off.
A few days later, PHP warned of a third, smaller flaw in the same area, with a fix due in its next routine update.
What we did about it
We did not wait to see whether anything broke. We checked every app and website we build or host, about 35 apps and 44 hosted sites, and worked through a 105-point checklist until every item was closed.
- Patched PHP everywhere. Every site on our hosting runs PHP 8.3.36, the fixed release from 21 October.
- Closed the follow-up flaw too. We checked the settings the newer session flaw needs, confirmed that none of our sites use that setup, and switched the feature off anyway.
- Upgraded every web app. Next.js, React and Node.js were moved to the fixed versions on every app, then tested and put live.
- Changed the keys. Where a password, key or secret could have been exposed, we replaced it. Old test accounts and leftover passwords in code were removed.
- Tightened the doors. We reviewed who and what is allowed to read each database and closed anything more open than it needed to be. Server functions now ask for a proper login, and form uploads have limits so they cannot be flooded.
- Stricter browser protection. Several sites now tell the browser exactly which scripts may run, which blocks a whole class of attacks.
- Cleared the clutter. Old features and connections nobody used any more were switched off. Every unused door is one less door to guard.
- Backed everything up. Every project now has a private, off-site copy of its code.
- Updated the libraries. The smaller building blocks inside each app got their security updates too.
We used AI-assisted tools to work through every codebase quickly, and a person reviewed every change before it went live. As far as we can tell, no client site was broken into and no client data was taken.
That is the point of having a studio that looks after your software, rather than a website that was built once and left alone.
What you should do
If we build or host your website or app, you do not need to do anything. It is done. If someone else looks after your site, ask them three questions this week.
- Which version of PHP is my site on? It should be 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer.
- Are my plugins, themes and frameworks up to date? WordPress, Joomla and Next.js sites all needed updates this month.
- When did you last check my site for security? If the answer is “when we built it”, that is your answer.
Anything on PHP 7 or older is out of support and needs an upgrade, not a patch. And if you do not know who looks after your site, or you ask and get a shrug, that is worth sorting out before the next bad week.
Not sure your site is safe?
We will check it and give you a straight answer, usually within one working day.
- Wiz Research, PHP2Shell, October 2026.
- TechCrunch, The internet is having a very bad cybersecurity day, 21 October 2026.
- The Guardian, Websites hit by millions of attempts to exploit PHP flaw, 22 October 2026.
- NL Times, Dutch cybersecurity centre investigating first signs of abuse, 23 October 2026.
- ITdaily, Actively exploited ahead of patch, October 2026.
- Paperjam, Thousands of websites exposed in Luxembourg, October 2026.
- Island, Nearly half of PHP sites on unsupported versions, October 2026.
- Cyber Security Agency of Singapore, Critical vulnerabilities in Next.js, 20 October 2026.
- The Hacker News, PHP warns of another unpatched flaw, October 2026.