Back-to-back Linux kernel CVEs, and why a small shop still needs a patch cadence

If you run any always-on Linux box (a website on a VPS, an app server, a local AI machine, a NAS in the back office) the last few weeks were a reminder. “Copy Fail,” a logic bug in a kernel cryptographic component, got patched across the distributions in late April. “Dirty Frag,” a cluster of kernel networking flaws, got patched on May 8, with reports of active exploitation within days. Last year it was sudo, twice, one of the bugs having sat in the codebase for over a decade. None of this is a crisis. All of it is a nudge to make sure you have an actual patching routine rather than an “I’ll get to it” attitude.

First, ignore the scary number

You may have seen that the Linux kernel logged something like 3,500 CVEs in 2024, roughly ten times prior years. That number is mostly an artifact: the kernel team became its own CVE-assigning authority in early 2024 and now files a CVE for nearly every bugfix that could conceivably have a security angle. Most of those don’t apply to your configuration, aren’t reachable, or aren’t exploitable in any practical sense. The raw count is noise.

The signal underneath is the part to internalise: there is a steady, predictable drip of real local-privilege-escalation bugs, and that’s been true for years and will keep being true.

”Local” is not the comfort it sounds like

A local-privilege-escalation (LPE) bug means an unprivileged user, or a process running as one, can become root. People hear “local” and relax: nobody untrusted has a shell on the box, right?

Think about how breaches actually go. The attacker gets a foothold first: a webshell dropped through a vulnerability in your application, a leaked SSH key, a compromised dependency running inside your CI, a container that escapes onto the host. That foothold is usually unprivileged. The LPE is the second move, the one that turns “we found a way in” into “we own the machine.” That’s why these bugs matter even though they need “local” access. “Local” means “anyone who already got one toe in the door,” and getting one toe in the door is the easy part.

Recent examples make the point. Copy Fail reportedly let a 700-odd-byte script get root on essentially every Linux distribution shipped since 2017. Dirty Frag was being exploited in the wild within days of disclosure. The 2025 sudo bugs let a local user escape the policy that was supposed to constrain them. These aren’t exotic. They’re the normal weather.

What a “patch cadence” actually means for a small shop

You don’t need a security team. You need a routine that closes the window between “patch exists” and “patch applied” without anyone having to remember to do it.

1. Turn on automatic security updates. unattended-upgrades on Debian and Ubuntu, dnf-automatic on Fedora and RHEL. This alone closes most of the gap, because the real failure isn’t “we didn’t know,” it’s “we knew and didn’t get around to it.”
2. Enable kernel livepatching where you can. Ubuntu Livepatch, RHEL kpatch, or a third-party service like KernelCare applies kernel fixes without a reboot. The reason kernels sit unpatched is almost always “we didn’t want to reboot the box.” Livepatching removes the excuse.
3. Schedule the reboots you can’t livepatch. A standing monthly maintenance window beats “whenever something finally breaks.” Put it on the calendar.
4. Subscribe to one good feed. Your distro’s security advisories (Ubuntu USN, Debian DSA, Red Hat RHSA) or CISA’s Known Exploited Vulnerabilities catalog. You want to hear within a day when something is being exploited in the wild, not read about it in a post-mortem.
5. Patch the userland, not just the kernel. sudo, OpenSSH, glibc, your web server, your language runtime. The kernel gets the headlines; the boring packages get exploited just as often.
6. Shrink the attack surface so LPE has less to chain off. Don’t run your app as root. Use a dedicated low-privilege service account. Keep build tools and compilers off production. Install less.
7. Outsourcing is a legitimate answer. If “we maintain a patch cadence” is a sentence nobody at your company can honestly say, that’s an argument for managed hosting (a PaaS, a managed database, a managed Kubernetes service) where someone else owns the kernel, or for hiring someone to own it. Self-hosting is cheaper than managed right up until the day it isn’t, and that day is usually the day a box gets popped.

The local-AI angle

We do local AI deployments for clients who can’t send data to a third party. If that’s you, here’s the uncomfortable symmetry: the moment you stood up an on-prem box to run an open-weight model “for privacy,” you also stood up a Linux server, and the privacy win evaporates the day that server gets compromised because nobody patched it. The threat model that made you self-host (don’t trust outsiders with the data) is the same threat model that obligates you to patch (don’t leave the data sitting on an unpatched machine). One without the other isn’t a posture, it’s a liability with a nicer story attached.

Bottom line

The CVE count is noise. The pattern is the signal: kernels and core userland leak privilege-escalation bugs on a regular schedule, “local” doesn’t mean “safe,” and the fix is unglamorous. Automatic updates, livepatching, scheduled reboots, one feed to watch, and the honesty to hand it to someone else if you’re not going to do it yourself. None of that is hard. Not doing it is the part that costs money.

If you self-host anything and want a second opinion on whether it’s being kept current, or whether it should be self-hosted at all, send us a note.