SURIQ
On August 26, 2026, CISA added a four-year-old Linux kernel flaw, CVE-2022-0995, to its Known Exploited Vulnerabilities catalog, the list of bugs the agency has evidence attackers are using right now. The flaw lets a local user on an affected system escalate to root. It carries a CVSS score of 7.8, and federal agencies have until September 9, 2026 to fix it. The patch has existed since 2022.
The interesting part is not the bug. It is the company it keeps. Three of the six flaws CISA listed that day are Linux local privilege escalation: the kernel bug plus two older Red Hat issues, CVE-2015-5287 in the Automatic Bug Reporting Tool and CVE-2015-3246 in the libuser library. Half the batch is about turning a foothold on a Linux box into full control of it. That is worth a server operator's attention more than any single CVE number.
What CVE-2022-0995 actually is
CVE-2022-0995 is an out-of-bounds memory write in a Linux kernel component called watch_queue, the piece that lets a program subscribe to kernel events. An incorrect bounds check lets an unprivileged local user write past the end of a kernel allocation and corrupt adjacent kernel state. Per the Red Hat and Ubuntu advisories, the result is either privilege escalation to root or a denial of service through a kernel crash.
This is not theoretical. A working exploit was published years ago, and CISA only adds a CVE to KEV once it sees real-world abuse. The distributions shipped fixes back in 2022: Ubuntu resolved it in kernel 5.15.0-138.148 and equivalents, and current releases such as Ubuntu 24.04 were never affected. So the code fix is old and available everywhere. The exposure is entirely about which machines are actually running it.
Why a patched 2022 bug is on the exploited list in 2026
A local privilege escalation flaw does not get an attacker onto your server. It is what they reach for once they are already there, with the limited rights of a web application, a compromised service account, or a container process. CVE-2022-0995 is the step that turns that low-value foothold into root, and root on the host is the whole game. We have written before about how a single foothold becomes host root and how a years-old kernel bug still hands out root on default systems. This is the same shape.
That explains the timing. CISA's own guidance around this batch, as reported by The Hacker News, points to attackers exploiting simple, known flaws that linger in exposed assets, with automation lowering the cost of doing it at scale. Old escalation bugs are cheap and reliable, and there is no shortage of Linux servers still running kernels from the last several years. The bug did not become dangerous again. The unpatched hosts were always there.
Patched is not the same as running the patch
Here is the trap that the wire coverage skips, and the one that matters most for a self-hosting operator. For a kernel flaw, installing the fix and running the fix are two different things. When your package manager pulls a new kernel, the fixed image lands on disk, but the machine keeps running the old kernel that is already loaded in memory. Until you reboot, a server can report a fully patched kernel package and still be exploitable through the running one.
Your vulnerability scanner may not catch this either, because a package-version check sees the fixed kernel installed and marks the host clean. The only honest answer comes from the running kernel. Compare uname -r against the fixed version, not your package list. On Debian and Ubuntu, needrestart tells you when a reboot is required for a kernel update; on Red Hat family systems, needs-restarting -r does the same. If you cannot take the reboot on schedule, live patching (Ubuntu Livepatch, kpatch, or a commercial equivalent) closes the window without one, for the hosts where it is available.
What to do before September 9
The federal deadline is a useful forcing function even if you are not a federal agency. Treat CVE-2022-0995 as a fleet-wide kernel currency check, not a one-host patch.
-
Inventory the running kernel across every Linux host, not the installed package. Flag anything older than your distribution's fixed build, and prioritize internet-facing and multi-tenant machines where an attacker is most likely to already have an unprivileged process.
-
Reboot the stale hosts, or apply live patching where a reboot has to wait. This is the actual fix; everything else is bookkeeping.
-
Tighten who can run local code. An escalation bug is only reachable by something already executing on the box. Review service-account permissions, container isolation, and any surface that lets an outsider get a shell in the first place.
-
Watch for the post-foothold signal. Because this is a local flaw, the tell is an unprivileged process suddenly acting with root: a service account spawning a shell, an unexpected setuid execution, a container process reaching the host. That behavior, not the exploit itself, is what a detection pipeline can catch.
A managed detection setup earns its keep on the last two points: keeping an accurate picture of which hosts run outdated software across a growing fleet, and alerting on the privilege changes that follow a compromise. Suriq's vulnerability detection is built around that fleet-wide visibility. The reboot is still yours to schedule.
The lesson outlives this CVE. When CISA's exploited list starts filling with old Linux escalation bugs, it is telling you where attackers are spending their time once they get in. The fix for most of them already shipped. The work is making sure your servers are actually running it.