The last few weeks have been busy for anyone who runs Linux servers for a living. Between late April and mid-May, security researchers disclosed five serious kernel vulnerabilities, each one giving any logged-in user a path to full root access on the machine. Several of them came with working exploit code published on day one.
SiteGround applied fixes for every single one of them on our hosting infrastructure without rebooting a single server and without interrupting a single customer’s service.
What this would have meant for your sites
In plain terms: if any one of these vulnerabilities had been exploited on a server before being patched, an attacker who already had even the smallest foothold (a compromised WordPress plugin, a leaked FTP password, a vulnerable script) could have escalated from a single low-privilege account inside one site to full control of the underlying host. From there, the usual playbook: read other tenants’ files, plant persistent backdoors, harvest credentials, pivot deeper into the network.
These aren’t theoretical risks. Public exploit code existed for every single one of these flaws. Copy Fail in particular was being actively used in the wild within days of disclosure.
What actually happened
In rough order, here’s what hit the Linux world:
April 29, Copy Fail (CVE-2026-31431) Disclosed – A single 732-byte Python script could turn any normal user into root on essentially every Linux distribution shipped since 2017. No timing tricks, no guesswork, just a logic bug in the kernel’s crypto subsystem. CISA added it to their actively-exploited list within days.
May 7, Dirty Frag – xfrm/ESP flaw (CVE-2026-43284) Disclosed – A flaw in the kernel’s IPsec ESP networking code that lets an attacker write arbitrary data into the memory copy of read-only system files. Often referred to as “Copy Fail 2.”
May 7, Dirty Frag – RxRPC flaw (the second half of the chain) – A companion bug in the kernel’s RxRPC networking module. Chained with the xfrm/ESP flaw above, it gives a normal user full root.
May 13, Fragnesia / Copy Fail 3.0 (CVE-2026-46300) Disclosed – The third bug in three weeks, same family as Dirty Frag, also in the kernel’s IPsec subsystem. A working proof-of-concept was published the same day.
May 14, ssh-keysign / chage pidfd flaw Disclosed and patched by Linus Torvalds – A different kind of bug – not root escalation, but it let any unprivileged user read root-owned files like /etc/shadow (the password hashes) and SSH host keys.
How we fixed it without downtime
Four choices we’ve made about how SiteGround operates made this manageable, and given what’s coming, all four are going to matter even more, not less.
We watch the threat landscape constantly. Our security team monitors kernel mailing lists, CVE feeds, and disclosure channels around the clock. We knew about Copy Fail the day it was disclosed, Dirty Frag the day it dropped, and Fragnesia within hours of the proof-of-concept being posted. There’s no substitute for having eyes on this in real time. By the time these stories hit mainstream tech news, the exploit code has usually already been out for days. As AI-driven discovery accelerates the disclosure cadence, this kind of constant monitoring becomes essential rather than optional.
We have engineers on call 24/7. Critical kernel patches don’t wait for business hours, and neither do we. For every one of these vulnerabilities, we had patches built, tested, and rolled out across our fleet within 48 hours of public disclosure, which is usually well before most distributions had even released their official packages.
We use live kernel patching. This is the part that matters most for you. Traditional kernel patching requires a reboot, which means downtime for every service running on the machine. Live patching applies the fix to the running kernel in memory, so the vulnerability is closed without restarting anything. Your websites, databases, mail, and SSH sessions all kept running through every single one of these patch cycles. When patch frequency goes up, the cost of “just reboot the server” goes up with it — live patching is what keeps that cost at zero for you.
We keep our kernels lean. A big part of why these bugs are dangerous is that the vulnerable code ships enabled by default on most distributions. Copy Fail lived in the AF_ALG kernel crypto interface. Dirty Frag and Fragnesia lived in the esp4, esp6, and rxrpc modules — IPsec and AFS networking code that the vast majority of web servers will never use in their lifetime. We don’t load kernel modules we don’t need. That means a chunk of the attack surface for these exploits simply didn’t exist on our machines in the first place, giving us extra breathing room to apply the proper fix.
The AI factor, and why this is only the beginning
One detail in the Copy Fail disclosure deserves special attention. The bug wasn’t found by a human researcher staring at code for weeks. It was surfaced by an AI-powered code auditing tool (Xint Code) in roughly one hour of scan time against the Linux kernel’s crypto subsystem. The same scan also surfaced “other high-severity bugs, still in coordinated disclosure,” meaning more disclosures are already in the pipeline.
This is a major shift in how vulnerabilities get found. For years, the bottleneck on discovering critical kernel bugs was the limited number of expert humans willing to spend months reading kernel source code. That bottleneck is gone. AI auditing tools can now scan entire subsystems at machine speed, and they’re finding things that have been sitting in stable kernels for nearly a decade.
What this means practically: the rate of serious vulnerability disclosures is going to keep climbing. Three universal local-root exploits in three weeks isn’t a fluke; it’s a preview. The reactive patching cycles that worked when one critical kernel bug landed every six months are not going to work when one lands every two weeks. The ability to detect, react, and patch within hours rather than days is no longer a nice-to-have. Instead it’s the baseline for staying safe.
The takeaway
Linux is going through an unusually rough stretch for kernel security: three universal local-root exploits in three weeks is not normal, and it’s not slowing down. With AI-powered auditing tools now scanning the kernel at speeds no human team could match, we expect the discovery rate of serious vulnerabilities to keep accelerating. The bugs that have been sitting quietly in stable kernels for years are getting found, one subsystem at a time.
What we can promise is that the way we handled these is the way we handle every serious vulnerability: monitor early, patch fast, fix live, and keep the attack surface as small as possible in the first place. Your sites stay up. The exploits don’t. And as the cadence picks up, that’s only going to matter more.