Linux Kernel CVE-2025-39964 and CVE-2026-53266: Patch, Then Reboot — Both Now Confirmed Exploited

On 18 September 2026 CISA added two Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog: CVE-2025-39964 (a race condition in AF_ALG sockets) and CVE-2026-53266 (an out-of-bounds write in the ebtables SNAT target).

Both were fixed upstream a long time ago. The news here is not a new hole — it is that holes which were already patched are now confirmed to be used in real attacks.

There are two things to do: update your distribution's kernel and reboot, and confirm that a fixed package actually exists for your release. Skip the second and you can mistake "updated" for "fixed".

What to do right now

• ✓First check whether your release is fixed. In the distribution trackers linked below, find the row for your release and kernel flavour (generic, aws, azure and so on). `Fixed` means an update closes it. `Vulnerable` or `work in progress` means no fixed package exists yet.
• ✓Reboot. This is the part people skip. Installing a kernel does not switch to it — the old kernel keeps running until the machine restarts.
• ✓Confirm the reboot took. `uname -r` shows the kernel actually running. Compare it with the installed package version; on Debian/Ubuntu, `ls /boot/vmlinuz-*` makes it obvious when a newer kernel is installed but not booted.
• ✓Check mechanically whether a reboot is pending. Debian/Ubuntu create `/var/run/reboot-required`. On RHEL-family systems `needs-restarting -r` does the same, but it is not installed by default — Red Hat's documentation names the `yum-utils` package as its provider, so install that first.
• ✓If you cannot reboot yet, ask your vendor about live patching — and confirm that these two CVEs are actually covered by it, rather than assuming.
• ✓Check whether your kernel is still supported. CISA notes for CVE-2026-53266 that affected products may be end-of-life or end-of-service, in which case the advice is to stop using them or move to a supported version.

Updating may not fix it yet

"I ran apt upgrade and rebooted" does not necessarily mean fixed. If the distribution has not shipped a patched package, the update changes nothing for this CVE.

As of 18 September 2026, Ubuntu's security tracker still lists the main LTS kernels as unfixed for CVE-2026-53266. On the rows for the main `linux` package, 24.04 LTS (noble) and 22.04 LTS (jammy) read "Vulnerable, work in progress" and 20.04 LTS (focal) reads "Vulnerable". 26.04 (resolute) is fixed in `7.0.0-31.31`, and 18.04 (bionic) and earlier are listed as "Not affected".

Those are the `linux` package rows. Flavours such as `linux-aws` and `linux-azure` carry their own statuses, so check the row for the flavour you actually run.

On those systems, updating and rebooting leaves this one open.

There is not much to do while you wait, and this article will not invent workarounds. Publishing unofficial kernel tweaks or module blacklists causes outages of its own.

What you can act on is the precondition: both flaws are local-vector, so reducing who can run code locally is the real mitigation.

• ✓Inventory who can execute code on the box. Ordinary users on shared hosts, externally supplied containers, CI build runners.
• ✓Re-check the tracker periodically. "Work in progress" means it is being worked on; it becomes `Fixed` later. Update and reboot again at that point.
• ✓Ask your vendor whether live patching covers these CVEs. Where it does, you can close them without a reboot.
• ✓If your release is out of support, plan a migration rather than waiting for a fix. CISA raises the same EoL/EoS point.

The same CVE carries both 3.3 and 7.8

Where these scores come from. CVE-2025-39964 has two different CVSS v3.1 assessments published on NVD:

・NIST (Primary): 3.3 LOW — `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L`
・kernel.org (the CNA, Secondary): 7.8 HIGH — `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`

The box above carries NIST's 3.3, because that is the primary assessment on NVD. But "3.3 LOW, so it can wait" does not follow.

The disagreement is entirely about impact. NIST rates it as a slight availability impact only (`A:L`), with no confidentiality or integrity impact. kernel.org rates all three as High. One reads the bug as "things may get unstable"; the other reads it as "this can be taken over."

And CISA has listed it as confirmed exploited. A severity score estimates how bad it would be if exploited; whether it is being exploited is separate information — and in this case the second question was answered first.

CVE-2026-53266 has no such split. The only CVSS on NVD is kernel.org's 8.8 HIGH, with no separate NIST assessment. Its vector is `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H` — note `S:C`, scope changed, meaning the impact is judged able to reach beyond the originally affected privilege boundary.

What each flaw actually is

CVE-2025-39964 — AF_ALG race condition (CWE-362)

AF_ALG exposes the kernel's crypto functions through a socket interface. Issuing two writes to the same socket concurrently interleaves the data unpredictably and leaves the socket's internal state inconsistent. The fix adds a field marking exclusive write ownership so that concurrent writes are refused.

CVE-2026-53266 — ebtables SNAT out-of-bounds write (CWE-787)

ebtables is the packet filter for bridged traffic. Its SNAT target can optionally rewrite the ARP sender hardware address, and that rewrite was performed without first ensuring the target was writable. CISA's KEV catalog entry describes the result as writing directly into a nonlinear socket-buffer fragment backed by a splice-imported file page.

Both are `AV:L` — local. Neither is the kind of flaw where an untouched server is taken over from across the internet.

That is not the same as safe. Anywhere untrusted users can execute code — shared hosts, container and virtualisation hosts, multi-user development boxes — the local precondition is already met. And after an initial foothold from some other bug or a phishing email, this is exactly the class of flaw used to widen privileges.

What a KEV listing establishes, though, is only that the flaw was exploited in the wild. It does not tell you what the attacker was after or how far they got. Treat "it has been used" as the confirmed part.

Fixed versions: you need one that covers both

These are the upstream (kernel.org) stable-series fixed versions recorded on NVD. Within the same series, CVE-2026-53266 is fixed in a later release, so a kernel that only satisfies one of the two is not enough.

• ▸5.10 series: CVE-2025-39964 in 5.10.245, CVE-2026-53266 in 5.10.259
• ▸5.15 series: 5.15.194 and 5.15.210
• ▸6.1 series: 6.1.154 and 6.1.176
• ▸6.6 series: 6.6.108 and 6.6.143
• ▸6.12 series: 6.12.49 and 6.12.94
• ▸6.16 / 6.18 / 7.0: CVE-2025-39964 in 6.16.9; CVE-2026-53266 in 6.18.36 and 7.0.13

This is where people go wrong: you cannot compare `uname -r` against that list directly.

Major distributions backport fixes into older series rather than shipping the newest upstream release. Ubuntu's `5.15.0-xxx` and RHEL's `4.18.0-xxx` will never match upstream 5.15.210 or the latest 4.18, yet they may well contain the fix.

Decide using your distribution's data, not the upstream numbers. The Ubuntu, Debian and Red Hat trackers linked below answer the question per CVE for the packages you actually run.

The deadline is 21 September 2026

CISA set a remediation deadline of 21 September 2026. That is binding on US federal agencies, not on you.

But the length of it tells you how CISA reads these two: added on the 18th, due on the 21st — three days. As a gauge for how to schedule your own kernel maintenance, that number is useful.