Today feels like a Katertag. For our non-German-speaking friends: that’s the day after a long night, when your head is heavy, the coffee is strong and everyone moves a little slower. Except we didn’t spend last night celebrating. We spent it patching – three times. In the morning it was compromised certificates, in the afternoon PHP, and later that night GitLab.

Morning: compromised certificate authorities

Every time you see the lock icon in your browser, a certificate authority (CA) is vouching that the website really is who it claims to be. If an attacker gets hold of a CA’s keys, they can impersonate any website.

That’s what happened with eMudhra. According to Google, a security researcher reported that the private keys of eight eMudhra intermediate CA certificates had been generated with insufficient randomness – which made it possible for anyone to forge trusted HTTPS certificates for any website. Chrome blocked the affected CAs within hours of the report, and Google is removing the root certificate behind them from the Chrome Root Store on October 27th.

Browsers could fix this quickly. Everything else could not. As Cloudflare explains, lots of software checks certificates against its own trust store – in the operating system, in language runtimes, in container base images. All of those need updating, rebuilding and restarting. That’s exactly the kind of work that lands on a platform team, and on the morning of October 21st, the whole VSHN team was working on the CA fix.

Afternoon: PHP2Shell

Our engineers were already pretty busy when the next one arrived. On October 21st, the PHP developers released emergency security updates for two critical vulnerabilities in the PHP core interpreter, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 and allowing an unauthenticated attacker to run code remotely on an affected web server. To make things worse, details leaked online on October 20th, before the coordinated disclosure and before patches were available. The flaws now go by the name “PHP2Shell”, and the advice from security authorities was blunt: patch immediately or consider taking exposed applications offline. The PHP Foundation has its own write-up on the release and what they’re doing to strengthen PHP security going forward.

This was not a theoretical risk. One hosting provider reported that attackers started sending requests to the WordPress sites they host from 08:44 UTC that morning, using a public proof-of-concept exploit.

What PHP is and what runs on it

PHP is a programming language made for the web. It runs on the server and builds pages on the fly – pulls content from a database, checks if you’re logged in, renders the HTML and sends it to your browser. It powers around 70% of all websites. Some of the best-known software built on it:

• WordPress, including WooCommerce online shops
• MediaWiki, the software behind Wikipedia
• Drupal
• Joomla
• TYPO3
• Magento and Shopware
• Nextcloud

The bug sits in PHP itself, not in any of these applications or their plugins, so keeping WordPress, TYPO3 or Nextcloud updated didn’t protect you. Every PHP version released in the last decade is affected, going back to version 5.4.

How we and our customers reacted to PHP2Shell

Plenty of posts out there explain what broke in PHP. What we find more interesting is what happens on the ground when something like this hits – so here’s how yesterday looked for us.

Our team started monitoring on the evening of October 20th, as soon as the PHP project announced the upcoming release. The Kubernetes and OpenShift platforms we run for our customers don’t run on PHP themselves, but PHP shows up in plenty of places on and around them, which is why we treated this as a major incident across our managed services.

Shortly before lunchtime on October 21st, one customer called us and asked us to take their website offline until the fix was out.

Our own website vshn.ch went offline too, from 4 pm on October 21st to 4 am on October 22nd – 12 (!) hours of downtime. vshn.ch is hosted at cyon.ch, one of the biggest Swiss web hosters, and they proactively turned off all PHP websites they host to protect them until PHP was patched. That’s something you don’t see every day – an entire hosting provider pulling the plug on every PHP site at once as a precaution. But it’s something we all might see more often in the future, when the next deep-down bug in a shared foundation turns up and patching fast is the only real defense.

Once the fix was public, we updated everything else. On virtual machines running PHP, we updated as soon as Ubuntu and Red Hat shipped patched packages. The Docker images we maintain are being redeployed as patched base images become available. And where customers run their own PHP apps in containers on our clusters, those images also needed patching, so we asked those customers to rebuild on a patched PHP version and redeploy. All the details are on our status page.

mod_php vs. PHP-FPM: not every setup carried the same risk

All common ways of running PHP for web requests were affected: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. But how you run PHP still mattered. According to the PHP developers, the risk was highest for setups using Apache with mod_php, where they demonstrated an exploit that triggers before any application code runs. In our setups, we use PHP-FPM. PHP-FPM was affected too, though, and patching was the only complete fix.

Night: GitLab

As if that day wasn’t already “spannend” enough: later that night, GitLab released fixes for a critical flaw – CVE-2026-110264, rated 10.0, the maximum – that lets an attacker run code on a self-managed GitLab server without logging in. It affects every version back to 7.0 from 2014, because the bug sits in the regular-expression engine GitLab has shipped all along. Our VSHNeers fixed that one too.

What we take away from it

Three very different problems, one common thread: none of them were in the applications people use every day. They were in the layers underneath – the certificates that make HTTPS trustworthy, the language that runs most of the web, the regex engine inside a developer platform. Every piece of software we run sits on layers of code that someone wrote years ago and most of us never look at. It’s easy to point fingers at eMudhra, PHP or GitLab now. Please don’t. Heartbleed hit OpenSSL in 2014, Log4Shell hit the Java world in 2021. This can happen to any foundation we all build on.

The AI angle

What makes PHP2Shell stand out is how it was found. The vulnerable code had been present for more than a decade, but exploiting it required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier. According to the researchers at Wiz, a single researcher completed in a week what previously would have taken a world-class team months of work.

That’s both scary and good news. Scary, because “too complicated to exploit” is no longer a safety net – attackers have the same tools. Good, because defenders can now find these deeply buried bugs faster too, and fix them before someone else uses them. We’re pretty sure days like yesterday won’t stay rare. Expect more of these, in more languages, more often. Which means one thing matters more than ever: how fast you can patch.

And this is where we want to say thank you. Our VSHNeers were quick to patch, and some of them could really use some sleep today. If one of them looks a bit tired in your next call, now you know why.

What you should do

For the certificates: if your website uses a certificate chaining to emSign ECC Root CA – G3, Google says to replace it with one from another CA right away, before the root is removed from Chrome on October 27th. Beyond browsers, update the trust stores in your operating systems, runtimes and container base images, then rebuild and restart. And if certificate errors show up after patching, don’t fix them by turning off certificate verification.

For PHP: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you’re on an older version, PHP 8.1 and older may not receive a fix – check with your vendor and plan the upgrade now. If your server is managed through a hosting panel like cPanel, the patched PHP versions come through the panel’s own updates – so update the panel, not just your application. If you run PHP in containers, rebuild your images on a patched base and redeploy. And remember that a patch does not remove an existing compromise, so have a look at your logs too.

For GitLab: if you run a self-managed instance, upgrade to the fixed version for your release branch.

If you’re not sure whether something in your stack is affected, talk to us. We’re a bit tired today, but we’re here.

Now, more coffee.