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.

Update, September 18, 2026: the version of this where the cadence is not yours to set. Everything in this post assumes you can run the update. The awkward case, and the one that covers more small businesses than the one above, is a local privilege escalation on a machine you rent a slice of.

CVE-2026-87886, added to CISA’s exploited list on September 16, is a privilege escalation flaw in the Acronis Backup plugin that hosting companies install into cPanel, Plesk and DirectAdmin. The vector reads AV:L and PR:L, attack vector local and privileges required low, exactly the profile this section is about. On shared hosting that profile collapses entirely, because every customer on the box already has a Linux account and, on cPanel, PHP runs as that account’s own user. The toe in the door does not have to be yours. It can be an out-of-date plugin on a stranger’s website on the same server.

So the section title holds and gets one amendment. “Local” means anyone who already got one toe in the door, and on multi-tenant hosting the door is held open for several hundred strangers by design. The patch cadence that decides your exposure there belongs to your host, which makes the only available action an email rather than an update. We wrote up what to ask and what we found checking the vendor’s own download servers in the Acronis backup plugin post.

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. Put the network appliances on the same calendar, because none of the above reaches them. unattended-upgrades does not patch your firewall, your VPN concentrator, or the NAS somebody port-forwarded. Those update only when a person decides to update them, which is why edge devices keep turning up in CISA’s exploited-vulnerability catalog. We went through a live example of this in the August 2026 Cisco ASA and FTD VPN flaw, where the vendor shipped a fix and offered no workaround at all. Once a month, read the advisories for every internet-facing appliance you own.
  8. 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.

Update, August 29, 2026: a four-year-old kernel bug just landed on the exploited list

The argument above is that a local privilege escalation is the attacker’s second move, not their first, and that this makes it more dangerous rather than less. On August 26, CISA added CVE-2022-0995 to its Known Exploited Vulnerabilities catalog, with a remediation deadline of September 9.

It is an out-of-bounds write in the kernel’s watch_queue event notification subsystem. A local user sends a malformed filter, corrupts kernel heap objects next to the watch buffer, and escalates to root. It was disclosed and patched in March 2022. Every mainstream distribution shipped the fix years ago. Reporting on the current campaign ties it, along with two 2015 Red Hat flaws and a 2021 deserialization bug in Ajax.NET Professional, to a single crew working through education, media, technology and gaming targets.

Four years is a long time for a patched bug to still be worth an attacker’s tooling budget. It is only worth it because enough machines never got rebooted into the fixed kernel. That is the entire thesis of this post arriving as a dated example: nothing about this bug got more dangerous in 2026. The population of unpatched hosts just got old enough to be reliable.

If you run any long-lived Linux box, this is the week to check uname -r against what your package manager has actually installed, and to find out whether anything is waiting on a reboot. See also the risk-based patching questions for how CISA now sets those deadlines, and why this one got a fortnight while a NetScaler bug in the same batch got three days.

Update, September 19, 2026: three kernel flaws in one day, and the case where the update does not exist

Everything in this post assumes two things: that a fix exists, and that applying it is your decision. The August update above covered the case where you can patch and do not. The September 18 update covered the case where somebody else owns the patch. This one is the third case, and it is the one this post did not have an answer for.

On September 18, CISA added three Linux kernel vulnerabilities to the Known Exploited Vulnerabilities catalog on the same day, all with a September 21 deadline and the forensic triage flag set. Across the catalog’s entire history only 31 entries have ever named the Linux kernel, and three arriving together has happened once before, in September 2022.

Two of the three are ordinary in the sense this post means. CVE-2025-39682 is a flaw in the kernel TLS receive path, and it is patched on every current distribution; on Ubuntu 24.04 the fix landed in 6.8.0-86.87 and the 5.15 kernel on 22.04 was never affected. CVE-2025-39964 is a local privilege escalation through the AF_ALG crypto socket interface, which any unprivileged process can open, including one inside a container, and it is patched too. Step one of the routine above handles both.

The third does not work that way. CVE-2026-53266 is an out-of-bounds write in the ebtables SNAT target. Debian has it resolved in every tracked release. Red Hat shipped it to RHEL 9 on July 8 and RHEL 8 on July 14, over two months before CISA said it was under attack. Ubuntu has not published a fixed kernel for 24.04 LTS or 22.04 LTS. We checked the Launchpad publishing API rather than the tracker’s status field: the newest published kernels are 6.8.0-139.139 and 5.15.0-191.201, and the fix needs 6.8.0-146.146 and 5.15.0-198.208.

So there is a fourth item to add to the routine above, and it sits between steps one and four:

Know the difference between “we have not patched” and “there is no patch.” They look identical from inside a scanner and they call for completely different responses. The first is a scheduling problem. The second is a decision about whether to keep running the exposed configuration at all.

The saving grace in this particular case is that the unpatchable flaw is the narrowest of the three. It needs bridge ebtables SNAT rules and CAP_NET_ADMIN, which most web servers do not have. Three commands settle it in ninety seconds, and they are in the full write-up, along with why uname -r will never match the version printed in a CVE record and what to check instead.

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, a monthly look at the appliances that never auto-update, 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.