Two Linux kernel vulnerabilities were confirmed exploited in the same window in late August 2026 — one from a networking subsystem disclosed just weeks earlier, the other a four-year-old bug in an entirely different subsystem that only now received confirmation of active exploitation.
CVE-2026-53362, CVSS 7.8, added to KEV 27 August, is a fragmentation-accounting bug in the IPv6 stack — per the kernel's own fix description, __ip6_append_data() fails to correctly account for fragment gaps on the paged-allocation path, an out-of-bounds condition in code that handles reassembling fragmented IPv6 packets. CVE-2022-0995, also CVSS 7.8 and added to KEV the same day, is an out-of-bounds memory write in the kernel's watch_queue event notification subsystem, originally disclosed in March 2022 — over four years before its KEV confirmation.
Two different subsystems, the same underlying category
Both bugs are memory-safety issues — an out-of-bounds condition, one in packet reassembly, one in event notification — which is the category of vulnerability the kernel's C codebase has always been most exposed to, and the category most consistently targeted by both academic fuzzing research and real attackers, because a kernel memory-corruption bug reliably converts into local privilege escalation or, in the networking case, into remote-triggerable conditions with less predictable but potentially serious outcomes.
CVE-2026-53362's specific location — packet reassembly in the IPv6 stack — deserves particular attention because reassembly code processes network input by definition, often before any higher-layer filtering or access control has had a chance to apply. A bug reachable through ordinary IPv6 traffic reassembly is a bug reachable by anything capable of sending IPv6 packets to the affected system, which for most modern networks is a very large population of potential sources.
Why the four-year gap on CVE-2022-0995 matters practically
A kernel bug from 2022 receiving KEV confirmation in 2026 means the vulnerable code path has likely been present, unexploited or unconfirmed, across several years of kernel point releases and long-term-support branches. Organisations running older, long-term-support kernel branches specifically for stability reasons are the population most likely to still carry code from 2022 unpatched — the same operational caution that makes LTS kernels attractive for production stability is what leaves a four-year-old vulnerability quietly present.
Why kernel memory-safety bugs are a permanent category, not a solvable backlog
Neither of these two CVEs is evidence of unusual carelessness in kernel development — the Linux kernel is one of the most heavily reviewed, fuzzed, and audited codebases in existence, and memory-safety bugs still surface in it regularly precisely because C's manual memory management makes this class of error structurally possible in ways a memory-safe language would prevent by construction. That reality is a reasonable argument for prioritising memory-safe languages in new kernel subsystems where feasible, and it's also a practical argument for organisations to accept that kernel patching is not a one-time project to complete but an ongoing operational discipline, indefinitely, for as long as the kernel remains written substantially in C.
What to check this week
Patch both, and verify against your specific kernel branch and version, not a general sense of "we keep the kernel reasonably current." Long-term-support branches receive backported security fixes on their own schedule, separate from mainline.
Check whether IPv6 is actually in use, and if not, whether it can be disabled at the interface level as an additional mitigation for CVE-2026-53362 independent of the kernel patch itself.
Review kernel patch management specifically for LTS or "stable" branches your infrastructure runs, given how directly CVE-2022-0995's four-year gap illustrates the risk of assuming an older, stable branch is a safer choice than a more actively patched one.
A brief note on why both landed in KEV the same day
CVE-2026-53362 and CVE-2022-0995 sharing a KEV addition date despite a four-year gap in original disclosure is itself informative: it suggests CISA's confirmation process, or the underlying threat intelligence driving it, evaluated both around the same time rather than reacting to two independent, unrelated incidents that happened to coincide. Whether that reflects one campaign probing multiple known kernel bugs, or simply administrative timing on CISA's side, is not something either record states — and this post claims neither.
How Safeguard helps
Safeguard's continuous inventory tracks kernel versions with the same precision applied to application dependencies, which is what makes a four-year-old CVE like CVE-2022-0995 discoverable against current infrastructure rather than requiring someone to remember a bug from 2022 specifically. Reachability analysis on networking-layer bugs like CVE-2026-53362 identifies whether the affected protocol stack is actually in active use, turning a kernel-wide CVE into a concrete, checkable exposure.
