Three Linux kernel flaws in CISA's KEV: privilege escalation is the quiet half of every intrusion
Local kernel vulnerabilities rarely make headlines, but they are what turn a foothold into root. CISA's addition of three Linux kernel issues, with Red Hat confirming public exploits, is a prompt to look at how servers are patched and monitored.
Between 18 and 19 September 2026 CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalogue, with a federal remediation deadline of 21 September under Binding Operational Directive 26-04. Red Hat acknowledged active exploitation and public exploits, describing the risk as high and advising remediation with high priority.
The three vulnerabilities
- CVE-2025-39682, CVSS 9.8: an improper check for unusual or exceptional conditions in the TLS receive path, leading to memory disclosure or denial of service for local authenticated users.
- CVE-2026-53266, CVSS 8.8: an out-of-bounds write in the ebtables SNAT ARP rewrite path, which can cause unintended behaviour, denial of service or local privilege escalation.
- CVE-2025-39964, CVSS 7.8: a race condition in AF_ALG socket operations, with outcomes ranging from system crash to corruption of cryptographic operations and data integrity issues.
None of these is remotely exploitable on its own. Each requires a local foothold. That is precisely why they matter.
Why local kernel bugs end up in ransomware chains
Every intrusion that starts with a web application exploit, a stolen SSH key, a container escape or a malicious package lands with limited privileges. The next step is always the same: become root. Kernel privilege escalation vulnerabilities are the most reliable way to do it, because they do not depend on misconfiguration and they work on fully hardened application stacks.
Linux servers also tend to be patched less frequently than Windows estates, particularly in environments where uptime is prized and reboots are avoided. Kernel updates in particular are deferred because they require a reboot or live-patching infrastructure. The result is that a server fleet can be fully patched at the application layer and still offer an attacker a short path to root.
What to do now
- Patch the kernel across RHEL and derivatives, Ubuntu, Debian, SUSE and container host images, and reboot or live-patch to activate the fix. A patched package that is not running is not a patch.
- Prioritise exposed and shared systems: internet-facing application servers, container hosts, CI/CD runners, jump hosts and any system where untrusted users or workloads have local access.
- Reduce the attack surface where features are unused. Modules such as ebtables and algorithms exposed through AF_ALG can be disabled or restricted on systems that do not need them.
- Monitor for exploitation behaviour: unexpected kernel crashes, sudden privilege changes for service accounts, new SUID binaries, modifications to authorized_keys files and processes spawned by web server users. Endpoint detection with Linux coverage should be present on servers, not just on laptops.
- Inventory containers and images. Container hosts share the kernel with every container they run. A kernel privilege escalation inside a container is a host compromise.
The assurance point
Linux patch compliance is a frequent blind spot in insurer questionnaires and in internal reporting, because the metrics are usually built around Windows. If your organisation cannot state its kernel patch status by host within a day, that is a finding in itself, and it is one that this KEV update makes urgent.
Sources
- The Hacker News: CISA flags three Linux kernel vulnerabilities exploited in the wild
- CISA: Known Exploited Vulnerabilities Catalog
