It's Been a Rough Year for Linux Security - Here's Everything We Patched

If you work in hosting or server admin, you've probably felt it too: 2026 has been relentless. We lost count of how many times someone on the team said, "another one?" between April and August. Fifteen serious vulnerabilities landed across the Linux kernel, CloudLinux, cPanel/WHM, and CSF in about seventeen weeks, and a few of them had worked exploits floating around before most of us had even finished reading the advisory.

We wanted to put all of it in one place. Partly so our customers can see exactly what happened and what we did about it, and partly because honestly, keeping track of all this ourselves got hard enough that writing it down felt necessary. If you run your own servers, treat the second half of this post as a checklist.

Everything That Happened, in Order

Worth calling out: Dirty Frag, Fragnesia, and pedit COW are close enough in the kernel that patching the first one did not automatically cover you for the next. We saw a few teams find that out the hard way.

What SupportSages Actually Did

We run KernelCare on our fleet, which is basically the whole reason this year didn't turn into a string of 2am emergency reboots for us. For every single one of these:

• Kernel bugs (that's most of the list - Copy Fail through RtabRace) got livepatched fleet-wide the same day, no reboot; no downtime customers would notice.
• cPanel/WHM issues (auth bypass, Exim, database escalation, request smuggling) got the vendor patch applied the same day each advisory dropped.
• CSF got bumped to 16.30-1 as soon as it was out.

Nobody had to open a ticket. Nobody had to do anything. If you were with us during any of this, your server was already fixed before you'd have even heard about the problem.

Why This Is Worse on Shared Hosting Than It Sounds

Almost every bug on that list boils down to the same thing: some ordinary, low-privilege process - a hacked plugin, an old CMS install; a shell account nobody remembered to lock down turns into full root on the box. If it's your own dedicated server, that's bad, but it's contained. If it's shared or reseller hosting, one compromised site on the server can end up taking the whole thing down - everyone else's files, mail, databases, SSL keys, all of it, because they're all sitting on the same kernel.

The KVM bugs make this worse for anyone running virtualization. Januscape and Zapscape mean a guest VM; even one attacker spun up specifically to do this, could reach out and touch the host, and from there, every other guest on it.

And the cPanel auth bypass didn't even need a foothold to begin with. No compromised account, no malicious plugin, just a direct, unauthenticated path to admin. It was being actively exploited in the wild within days.

What Happens If You Just... Don't Patch

If you're managing your own infrastructure and this list feels overwhelming, here's the honest version of why it matters, not the scary-sounding vendor version.

Exploits showed up fast this year, faster than a lot of people were prepared for. For GhostLock, OVSwrap, Bad Epoll, pedit COW, and the cPanel bypass, working exploit code was public within a day or two, in some cases the same day the advisory went out. A few of this even had solid reason to believe someone was using them before the advisory was even published, which is about as bad as the timeline gets. There's no longer a comfortable "we'll get to it next week" window you can plan around. That window is measured in hours now, sometimes less, and it's not really something you can negotiate with by having a good excuse.

Patching one bug in a family doesn't mean you're safe from the next one, either, or this year made that painfully clear. This is the Dirty Frag / Fragnesia lesson again; some teams patched the first, marked the ticket done, moved on, and got hit by the second one three weeks later because it lived in a slightly different corner of the same subsystem. RtabRace made a similar point from another angle: it's yet another race condition reachable through an unprivileged user namespace, in a completely different part of the kernel (traffic control this time, not XFRM). If your team's mitigation strategy has been "patch the specific CVE and move on" rather than "unprivileged user namespaces keep producing these, maybe we should look harder at whether we need them enabled at all," you're going to keep having this exact conversation every few weeks. From the outside, "we already patched the kernel for this" sounds like a complete answer. It wasn't, and there was no obvious way to know that without someone specifically flagging it. That's the part that stings; you can do everything right and still get caught by something that looks like it should already be covered.

And the actual fallout, if any of this gets exploited, isn't some hypothetical worst-case scenario a vendor invented to scare you into buying something. It's very ordinary, very real consequences: breach notifications you're legally obligated to send out, unplanned downtime while you're figuring out how deep the compromise goes, your IPs getting blacklisted by mail providers and reputation services, and customers who start quietly moving their business elsewhere because they don't trust you got it handled. And if you're reselling hosting yourself, none of that stops with you; all of it lands on your customers too, and then on their customers, and you're the one fielding the angry emails from three layers down.

Proactive Just... Works Out Better

Honestly, this isn't complicated, even though it gets talked about like it's some deep strategic tradeoff. A same day livepatch that nobody even notices cost you basically nothing, no downtime, no angry tickets, no 2am phone calls. It's a non-event. That's kind of the whole point of doing it that way.

Falling behind on any one of these sixteen costs you a lot more than the patch itself would have, and it costs you in ways that are hard to fully plan ahead of time. You're looking at incident response hours, breach notifications, actual cleanup and forensic work to make sure the compromise didn't spread further than you think, and then the slower, harder-to-measure cost of rebuilding whatever trust you lost with customers who found out about it. That last one doesn't show up on an invoice, but it's usually the most expensive part.

And you're doing all of that against attackers who, this year specifically, kept beating most people's normal patch cycles, sometimes by day, sometimes by hours. Waiting for the "next maintenance window" isn't a neutral choice anymore. It's a bet that nothing bad happens in the meantime, and this year, that bet didn't pay off for a lot of people.

If You're Running Your Own Server, Check These Now

• cPanel/WHM: make sure you're on 11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32, or WP2 138.1.6+. That covers both the July 30 batch and the April auth bypass.
• CSF - should be 16.30-1 or newer.
• Kernel, if you're on KernelCare: run kcarectl --patch-info | grep <CVE-ID> for whichever CVE you're checking. Heads up: kcarectl --info | grep CVE-... will come back empty even when you're already patched, so don't use that one to verify.
• Kernel, without KernelCare: check uname -r against your distro's advisory for each CVE individually. A few of these looks related but needed completely separate patches.
• RtabRace specifically: if a kernel update isn't rolled out to your platform yet, CloudLinux's advisory has a sysctl-based mitigation you can apply in the meantime without a reboot. Worth checking whether unprivileged user namespaces are something you need enabled at all - that's the common thread across RtabRace and a couple of the others on this list.
   
• Note: This mitigation blocks rootless containers (rootless Docker, Podman) and breaks sandboxing used by Flatpack and Bubblewrap. Standard hosting workloads like PHP-FPM, MySQL, and Nginx are completely unaffected.

If keeping up with this manually every few weeks sounds exhausting, that's basically the whole pitch for managed hosting with livepatching - it's one less thing you have to think about.

We're Still Watching

We keep an eye on CloudLinux, cPanel, and kernel security advisories as they come out, and we'll update this post or write a new one whenever something else lands. If you want to know how any of these affects your specific setup, just reach out to support.