CISA added two Linux kernel flaws to the Known Exploited Vulnerabilities catalog on September 18, 2026, in catalog version 2026.09.18: CVE-2025-39964, a race condition in the AF_ALG crypto socket interface, and CVE-2026-53266, an out-of-bounds write in the ebtables SNAT target. Both carry a remediation due date of September 21 — three days — and both are flagged for forensic triage, as 57 of the catalog's 1,715 entries are. The vendor field on both reads Linux and the product field reads Kernel — not a vendor you can call, and not a product with a version. The notes field carries fifteen git.kernel.org stable-commit URLs and nothing you can hand to a package manager.
Why the version table returns the wrong answer
NVD's CPE data for CVE-2026-53266 lists nine upstream ranges, 5.4.73 through 7.0.13, covering every live LTS branch. Matching uname -r against those ranges is the obvious move, and on any enterprise distribution it answers wrong in both directions.
Red Hat shipped the fix for CVE-2026-53266 in RHEL 9 as kernel-5.14.0-687.23.1.el9_8 (RHSA-2026:36645, July 8) and in RHEL 8 as kernel-4.18.0-553.143.1.el8_10 (RHSA-2026:39083, July 14). The patched RHEL 9 kernel still reports 5.14.0, which sits inside the 5.11 to 5.15.210 range and will match it permanently. The patched RHEL 8 kernel reports 4.18.0, which falls below every range in the table — so upstream matching calls a machine clean that Red Hat itself shipped an advisory for. A backport does not move the version string; that is what it is for. It is the same trap as a vendor's fixed version sitting inside a later affected range, from the opposite direction.
The severity numbers do not settle it either. For CVE-2025-39964 the Linux CNA scores 7.8 with full confidentiality, integrity and availability impact, NVD's primary metric is 3.3 with C:N/I:N/A:L, and Red Hat rates it Moderate at 5.5 — "crash the system or corrupt cryptographic operation results." For CVE-2026-53266 the CNA scores 8.8 at AV:L, NVD publishes no primary score at all, and Red Hat scores it 7.5 at AV:N — network, not local. CISA's SSVC decision points on both read exploitation active, technical impact total, automatable no. The three-day clock comes from none of those scores: BOD 26-04 sets it from exposure, KEV status, automatability and technical impact, and CVSS is not one of the four.
The practice: resolve the fix through your distribution, per boot boundary
The required action on both entries is "apply mitigations in accordance with vendor instructions." The vendor is not kernel.org — it is whoever built the kernel you are running, and theirs is the only tracker mapping these commits onto an installable package version.
That resolution is not uniform. Ubuntu marks CVE-2026-53266 fixed in 26.04 at 7.0.0-31.31 and both 24.04 LTS and 22.04 LTS as "Vulnerable, work in progress" — no fix for the two most-deployed LTS releases on the day the clock started. Red Hat lists RHEL 10 as Affected and RHEL for NVIDIA 26 as Will not fix. For CVE-2025-39964, Ubuntu has shipped fixes across every supported release, while Red Hat records Fix deferred on RHEL 7 through 10 and offers a mitigation instead: prevent the af_alg module from loading. One CVE, opposite instructions.
Collect the running kernel per boot boundary, not per asset record and not per container image. Containers share the host kernel, so a base image has no kernel of its own and scanning images tells you nothing here. Then check installed against running: a kernel package updated but not booted is not remediated, and needs-restarting -r on RHEL or /var/run/reboot-required on Debian and Ubuntu decides it.
The cost is the reason this gets deferred: every kernel fix is a reboot on every host, which is a maintenance window per machine rather than a push. Live patching — kpatch, Ubuntu Livepatch, KernelCare — converts that window into a licence line item, and it does not cover appliance firmware or a kernel your vendor has not patched yet. Where you cannot reboot this week, both bugs have a precondition you can remove instead — the same move as resolving an advisory's precondition against your own running configuration before triaging on severity.
What to check this week
uname -ron every bare-metal host, VM, hypervisor and Kubernetes node, and separately for each microVM runtime (Kata, Firecracker, gVisor). If that list does not exist, producing it is the deliverable, not the patch.- For each distinct kernel, the status in your distribution's tracker for both CVE IDs — Red Hat's CVE pages, the Ubuntu CVE tracker, SUSE's — not the NVD range.
needs-restarting -ror/var/run/reboot-required, separating hosts that are patched from hosts that have only downloaded a patch.lsmod | grep af_algfor the CVE-2025-39964 precondition, andebtables -t nat -Lfor SNAT rules that rewrite the ARP sender hardware address, which is the CVE-2026-53266 precondition Red Hat names in its mitigation.- Which appliances will not give you a kernel version at all. For those the answer comes from the vendor's advisory, and the interim control is network placement and who holds a local account on the box.
Both entries are marked for forensic triage, so where a host in scope was reachable by a local account you do not control, the question is not only which kernel it runs but what ran on it before the reboot.
North InfoSec runs AI-assisted penetration testing and security assessments, including the host inventory and configuration review described above. northinfosec.com