The Big Bug Backlog: How AI is digging up decades of overlooked security flaws

What you need to know:

• AI now helps researchers find serious software flaws far faster and more cheaply.
• Two such flaws, PwnEscape and php2shell, hit core hosting infrastructure in October 2026.
• We patched every VPS and VDS host, which required a fleet-wide reboot.
• No Contabo system or customer server showed any sign of compromise.
• If you run PHP on your own server, update it now.

If it feels like critical security warnings have been arriving more often this year, you’re not imagining it. Over the past year, AI has become dramatically better at finding security flaws, and many of the flaws it’s turning up have been around a lot longer than you might think.

In April, Anthropic announced that its Mythos model had found thousands of vulnerabilities across every major operating system and web browser. One of them had gone unnoticed in OpenBSD for 27 years. Mozilla used it to find and fix 271 bugs in Firefox. Within weeks, the UK’s AI Security Institute reported that OpenAI’s GPT-5.5, which anyone can use, was about as capable. Smaller research teams have been reproducing the same kind of results with cheaper models ever since.

Like all security-conscious companies, we welcome the responsible disclosure of vulnerabilities. Finding and patching flaws can only make our technology ecosystem stronger. However, what we have seen in recent weeks is that the gap between discovery, disclosure, and active exploitation has gotten a lot smaller – in some cases, down to a matter of hours.

In October, that trend reached our own infrastructure (together with all hosting providers) twice in one week. A flaw in the Linux kernel known as PwnEscape required patching that meant rebooting every VPS and VDS host we run. Six days later, a pair of PHP flaws known as php2shell forced emergency updates across a large part of the web. Both were found by researchers working with AI.

We think this is the new normal for anyone running software on the internet, and we want to explain why, because the reasons may be a bit more reassuring than the headlines suggest.

Why is this happening now?

For most of the history of software, a great deal of code has been safe for a fairly unflattering reason: nobody skilled enough ever had the time to look at it closely.

Finding a serious vulnerability takes rare expertise and a lot of patience. The people who have both are few. They’ve tended to spend their time on the biggest targets, such as web browsers and phone operating systems, where a working exploit is worth the most. Plenty of widely used software has simply never had that kind of attention. Security researcher Thomas Ptacek put it well earlier this year when he wrote that we’ve been protected not only by good engineering, but by “a scarcity of elite attention.” The flaws were always there. We just didn’t know about them yet.

AI has removed that scarcity. A language model doesn’t get tired or bored, and it already knows the common patterns that vulnerabilities follow. It can be pointed at any codebase out there. The team at pwn.ai who found PwnEscape say it took them just three days and under $700 in computing costs. The PHP flaws had been in the language for more than a decade. Wiz Research, who found them, said that turning them into a working attack would once have taken an expert team months. With AI assistance, it took one researcher a week.

So the code didn’t suddenly get worse. It just started getting more attention, and that’s when the cracks began to show.

Mostly good news, with a catch

Attackers can use the same AI models the researchers used to find these vulnerabilities, and nobody serious pretends otherwise. Bruce Schneier, one of the most respected voices in IT security, expects the next few years to be rough: more flaws discovered, more attacks, and much more frequent updates for nearly everything we all use.

But both of October’s flaws were found by people whose aim was to get them fixed before attackers could use them. pwn.ai reported PwnEscape privately to the Linux kernel maintainers with suggested patches, then waited about six weeks for the fix to be reviewed before saying anything in public. Wiz held the PHP flaws for two months while a fix was built, working with Cloudflare, AWS, Google and Microsoft so that guidance was ready the day the details came out. Every flaw found that way is a flaw that can’t be quietly used against you later.

Over the longer term, Schneier thinks the same technology tips the balance towards defenders, as AI gets better at writing secure code in the first place. We think he’s probably right.

There is a catch, though, and it’s in the word “fixed.” A flaw that has been found and patched only protects you once the patch is actually installed, and that’s where October got disruptive for us, and for much of the internet.

What happened in October, from our side

PwnEscape was a flaw in the Linux kernel’s networking code that could let a virtual machine read memory from the physical server underneath it. On shared hosting hardware, that means memory belonging to other customers, so for us it was about as serious as these things get.

Our threat monitoring picked up early details about this vulnerability on October 4, when they leaked on social media, but no fix existed until the flaw was officially disclosed on October 15. In the meantime we tracked it closely and tested the proof-of-concept code that started circulating against our own systems. None of it achieved a full exploit. Once the patch was out and our platforms team had tested it, we began rolling it out on Saturday, October 17, and had 99% of the VPS and VDS fleet done by Monday.

A kernel patch can’t be applied without restarting the physical host, which is why your servers rebooted with so little warning. A small number of hosts didn’t come back up gracefully, and our engineers had to recover them by hand. For those customers, it meant a longer outage at short notice, and we’d like to apologize once again for that.

php2shell moved much faster. On October 21, the PHP project released fixes for two flaws that let an attacker run code on a server without logging in. We applied the recommended mitigations within hours, but by late morning there were credible reports that they weren’t enough. So we took several exposed systems offline, including the legacy Customer Control Panel and our remaining legacy webhosting servers, and kept them down until the full patches arrived that afternoon. The PHP project later confirmed that there were no complete mitigations and that updating was the only real fix.

We saw no sign of attempted or successful exploitation on our systems during either incident.

The part of your server only you can patch

October’s two flaws fell on opposite sides of an important line.

PwnEscape was in software we run: the host systems underneath your server. You didn’t have to do anything.

php2shell is different for most customers. On a VPS, VDS or Dedicated Server, you control the operating system and everything installed on it. We don’t have access to it, and you wouldn’t want a hosting provider that did. We patched every PHP installation we manage, but if you run PHP on your own server, including through your own cPanel installation, that update is still yours to make.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you’re on PHP 8.1 or older, the PHP project no longer releases updates for it, so check whether your Linux distribution provides a backported fix. PHP 8.2 also reaches end of life on December 31, 2026, so this is a good moment to plan an upgrade.

This line of responsibility is going to matter more over the coming years. If Schneier and others are right, there will be a steady stream of security updates for the software on your server. The flaws will be found either way. Whether they hurt you mostly comes down to how quickly the fixes get installed, and for most customers, switching on automatic security updates for the operating system is the simplest protection available.

More of this is coming

We can expect more critical vulnerabilities to be discovered almost overnight, as these were. Some flaws will show up in our infrastructure, and we’ll patch them, occasionally at short notice when the risk justifies it. Some will be in software you run.

Our security team monitors vendor advisories, security mailing lists, social media and alerts from bodies such as Germany’s BSI and the UK’s NCSC around the clock, and scores every critical issue as it comes in. The gap between a flaw going public and someone trying to exploit it can now be a matter of hours, so our response has to be measured in hours too. When the picture is unclear, we lean towards acting early and putting safety first. On October 21, that meant making the decision to take systems offline before anyone could confirm it was necessary. As it turned out, it was.

With each incident like this, we’ll learn how to handle them better. That said, it’s highly possible that we’ll need to make similar decisions again, which may lead to unexpected downtime in the interest of security. We’ll keep a close eye on these situations and work hard to minimize any disruption. Above all, we’ll tell you what’s happening as early as we can and keep you updated until it’s resolved. During an incident, live updates go to our status page, with fuller guidance in our help center.

Thank you for trusting us with your infrastructure.

FAQ