Today, many websites in Germany went offline. Universities, public services, hospitals. And a lot of development teams, including ours, spent the day doing emergency updates.
If you saw the news, you probably saw something like “critical PHP vulnerability” and a few numbers which do not explain much unless you work with this every day.
So what actually happened? Why would somebody turn off a website before it was even attacked? And why can't we just update WordPress and continue with our lives?
Basically, the problem was found in the software that runs underneath many websites. An attacker could use it to make a vulnerable server execute their own code, without logging in. The PHP project released fixes on 21 October 2026 for two vulnerabilities: CVE-2026-109618 and CVE-2026-109619. You may also see the name PHP2Shell. Official PHP announcement.
Now let's go through what that means.
What is PHP, and is your website affected?
PHP is both the programming language and the backend server runtime behind a massive chunk of the web. Magento uses it to power heavy commerce stores. WordPress (with WooCommerce) and TYPO3 (with Aimeos or custom setups) run massive online shops, content portals, and corporate platforms alike. Customers browse the catalog and place orders; PHP does the heavy lifting on the server.
Today's vulnerabilities are in that underlying runtime. Updating your shop, theme, or CMS plugins alone does not fix them: the PHP installation on the server needs the correction. For Magento, Sansec explicitly pointed out the infrastructure-level fix.
So the useful question to ask your team or hosting provider isn't “did we update the CMS?”. The useful question is: Has the PHP server running our website received both security fixes?
What Shodan's numbers tell us: millions of servers, mostly outdated
If you wonder how widespread this is, internet-wide scanners like Shodan paint a pretty wild picture: between 1.5 million and 2.2 million internet-facing hosts publicly expose PHP on the web.
And here is the kicker: of the hosts disclosing their version, around 59% (roughly 884,000 servers) are running PHP 8.1 or older. In other words, versions that are already End-of-Life (EOL) and haven't received official security updates from the PHP core team for years.
But here is the even bigger problem: every single recent, supported PHP version was vulnerable too. Read that again: prior to today's patch, every active PHP version running on the internet—8.2, 8.3, 8.4, and the brand-new 8.5—carried this critical remote code execution flaw. Nobody on unpatched PHP was safe just because they were running the newest release.
The countries with the highest number of exposed PHP servers on Shodan are the United States, China, Japan, and Germany. But there is a crucial distinction to keep in mind: Shodan counts visible IP addresses and open ports, not individual websites. Since a single cloud server or shared hosting node can easily host dozens or hundreds of websites and client shops, the real number of websites affected across the globe is vastly higher than those host counts.
How can a request “eat” the server's memory?
A request is what your browser sends whenever you open a page, click a button, or submit a form. PHP uses working memory to unpack and process that data. But the received data and its representation inside PHP's memory do not take up the same amount of space.
An attacker can exploit that asymmetry. The PHP advisory describes specially crafted upload requests whose headers and form fields force PHP to allocate vastly more internal memory structures than the raw network traffic would suggest. PHP's technical advisory explains how this works under the hood.
With Apache's mod_php configuration, researchers demonstrated that the attack can execute before the website's own application code even begins. Your custom login form and firewall plugins don't even get a chance to run. CVE-2026-109618 advisory.
The second vulnerability involves leftovers between requests: a worker process could retain references to memory that was already freed, and then reuse it while serving a subsequent visitor's request. Under the right conditions, this also allows remote code execution across both mod_php and PHP-FPM. CVE-2026-109619 advisory.
Does this mean every PHP site is instantly compromised? No. The server configuration, web server module, and application structure determine whether the specific exploit path works. But it does mean that having clean application code is no reason to skip the patch.
If code execution succeeds, the attacker gets the permissions of the web server process. In the context of an online shop or business platform, that isn't just 'bad'—that is an absolute nightmare. An attacker can expose your clients' private data: order history, personal preferences, email addresses, and home addresses. Imagine an evil attacker armed with modern AI agent tools getting access to that kind of structured dataset—what they could orchestrate in minutes with targeted phishing and identity fraud. And I'm not even talking about GDPR fines or government compliance here. This is fundamentally about your responsibility to the customer who trusted you.
Why did so many German websites go offline?
Because taking a service offline voluntarily for a few hours is much easier to explain to your board than having customer data leaked or servers hijacked.
Germany's Federal Office for Information Security (BSI) issued an urgent warning, pointing out that once security patches are published, attackers immediately reverse-engineer the diffs to build working exploits against unpatched systems. (And honestly, what else could you do? Release the patch silently? Release an update and say “please don't tell the hackers”? Shit, we are really in a bad position here: the moment the fix drops, the clock starts ticking.)
German media reported precautionary shutdowns across public authorities, universities, and healthcare facilities. RBB's report on the warnings and affected institutions.
The University of Leipzig, for instance, cut public internet access to its website, student portals, and examination platforms, keeping them reachable only via university VPN while awaiting patched packages. University announcement.
So when you saw an error page today, it didn't mean hackers had stormed the gates. In most cases, it meant administrators hit the emergency brakes to keep the doors locked until the mechanic arrived.
What did Austria and Switzerland advise?
Austria's national CERT (CERT.at) warned operators early to schedule an emergency maintenance window for 16:00 local time and urged taking critical systems offline where possible. They accurately anticipated a frustrating lag between the official PHP source release and the availability of pre-compiled distribution packages in Linux repositories. That lag ended up defining the afternoon for almost every sysadmin. CERT.at advisory.
Switzerland's Federal Office for Cybersecurity (BACS) pushed for immediate patching and reminded organizations to look beyond their public websites: internal portals, admin panels, and backend appliances often run PHP under the hood too. BACS made another crucial point: relying purely on a Web Application Firewall (WAF) is not enough to stop this attack. Swiss BACS advisory.
And the prize for practical irony goes to the Dutch NCSC: they took their own primary website offline as a precaution and had to direct citizens to their community discussion forum for status updates. Dutch NCSC notice.
Yes, the national cybersecurity agency explaining why websites should temporarily shut down needed a second website to explain why their first website was shut down. You have to appreciate the commitment to following your own advice.
MaxCluster: “temporary” became most of the afternoon
German managed hosting specialist MaxCluster announced that customer shops would be set to maintenance mode as a precaution, initially estimating about an hour of downtime. Their public incident log quickly documented what every ops team feared: upstream packaging delays, dependency conflicts across different Linux distributions, and rolling availability across PHP versions. Late into the evening, they noted that some extended-support legacy versions could take another 24 to 48 hours. MaxCluster incident timeline.
IONOS, Infomaniak and Hetzner: different ways to reduce exposure
IONOS initiated rolling updates across their shared fleet, predicting a 24-hour maintenance window with temporary performance dips, while defensively disabling managed Nextcloud instances. Crucially, their alert reminded customers on root VPS and unmanaged servers that managed updates don't apply to them—they had to patch their own stacks. IONOS hosting status; Nextcloud notice.
Infomaniak deployed patches spanning PHP 7.4 through 8.5 (telling anyone on sub-7.4 to urgently get with the times). As an interim shield, they temporarily restricted file uploads and upload progress meters across kSuite, SwissTransfer, and ticketing systems, and placed phpMyAdmin into maintenance. Infomaniak incident report.
This illustrates an important operational reality: “the website works” means something completely different to a visitor browsing a catalog, an editor trying to upload assets, and an API transferring order feeds.
Hetzner confirmed the vulnerability across relevant PHP versions and published patch availability on their status tracker. Hetzner incident notice.
Easiest was with cloud servers we manage directly: we were able to roll out updates nearly invisibly for end-clients.
Wait... actually, that's not true. Easiest was for the systems which have no PHP at all! All our clients running on Node.js and Go backends didn't even notice anything happened—except maybe the ones who tried to register for university exams at Leipzig or RWTH Aachen, or access local government citizen portals during their lunch break!
What actually filled our day? (Spoiler: a crazy amount of work)
Let's be clear: we spent the entire day in the trenches. Full day we were checking the shops and services statuses, updating cloud servers, and rebuilding Kubernetes PHP containers—that was a crazy day.
Can you name all your clients, on which technologies they are, and which services they run fast? It would be a nightmare problem for almost every company, hunting through old spreadsheets and panicked chats. Fortunately for us, at least we were using Kernote (with RAG)—our centralized knowledge database for AI agents. Our agents immediately pulled up exact architecture profiles, server environments, and repository links from documented facts instead of guessing.
It was relatively easy for us to find everything, but anyway—today was a fucking hard day. I can't even tell you how many AI tokens we burned today for non-trivial tasks and adjusting our automatic tests for this update.
(We will write a separate article about how we use Kernote and autonomous agents soon. Stay tuned.)
What should you do with this information?
First: ask whoever is responsible for your web infrastructure whether the PHP servers actively handling web traffic have received the emergency updates. Be specific: ask about your Magento shop, your TYPO3 website, your WordPress portals, internal CRM, and customer staging sites.
The official patched PHP releases are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Linux distributions and hosting vendors also backport patches to their own version strings, so ask for explicit confirmation of the patch rather than relying solely on the version number. Temporary WAF rules are helpful band-aids, not permanent replacements. Official PHP release details.
Second: test your business-critical user journeys. Check customer checkout, user account login, checkout webhooks, and contact forms. If a provider has your site in maintenance mode, demand clear progress milestones so your customer support team can set expectations.
Finally, once the dust settles, look at what gave you agility today. In our case, having already tested an upgrade from PHP 8.2 to 8.3 meant we could turn a roadblock into an immediate solution.
You can't predict when the next zero-day will drop. But you can make sure that when it does, you aren't fighting your own technical debt while your hosting provider's status page is the most visited site in your company.
Written on 21 October 2026. Provider incident responses reflect status at the time of writing and may evolve. Our MaxCluster observations reflect our specific client hosting stacks.
