high

CVE

CVE-2025-39682, CVE-2026-53266, CVE-2025-39964

CWE

CWE-754, CWE-787, CWE-362

Affected Surface

  • Linux kernels still in the affected upstream ranges for `CVE-2025-39682`, including `6.0.x` through `6.1.148`, `6.2.x` through `6.6.102`, `6.7.x` through `6.12.43`, `6.13.x` through `6.16.3`, and `6.17-rc1` through `6.17-rc2`, subject to vendor backports
  • Linux kernels still in the affected upstream ranges for `CVE-2026-53266`, including `5.4.73` through `5.4.x`, `5.8.17` through `5.8.x`, `5.9.2` through `5.10.258`, `5.11.x` through `5.15.209`, `5.16.x` through `6.1.175`, `6.2.x` through `6.6.142`, `6.7.x` through `6.12.93`, `6.13.x` through `6.18.35`, and `6.19.x` through `7.0.12`, plus `7.1-rc1` through `7.1-rc6`, subject to vendor backports
  • Linux kernels still in the affected upstream ranges for `CVE-2025-39964`, including `2.6.38` through `5.10.244`, `5.11.x` through `5.15.193`, `5.16.x` through `6.1.153`, `6.2.x` through `6.6.107`, `6.7.x` through `6.12.48`, `6.13.x` through `6.16.8`, and `6.17-rc1` through `6.17-rc6`, subject to vendor backports
  • Developer workstations, self-hosted CI runners, build containers, and shared Linux hosts where a first-stage compromise can already execute low-privilege code

The most important Linux story from the last three days is not a newly assigned CVE. It is CISA moving three Linux kernel bugs into KEV on 18 September 2026 and telling defenders to do forensic triage, not only routine patching.

For AppSec teams, that changes the job. These are not three identical “root bugs,” and the public writeups do not support treating all of them as universal one-shot host escapes. What they do support is a more useful conclusion: once hostile code already lands on a Linux workstation, runner, or shared host, the kernel still decides whether that foothold stays local.

That is why this KEV burst belongs in the same operational bucket as Dirty Frag, SCTPhantom, and CVE-2026-53362. The package compromise, CI compromise, or low-privilege service bug is often stage one. Linux kernel state handling, buffer ownership, and concurrency bugs are what can turn stage one into a host-level problem.

What changed this week

The code defects were public before this week. The new fact is that CISA now says all three are being exploited in the wild:

CVESubsystemCISA date addedCore bug classFirst fixed upstream versions
CVE-2025-39682kTLS receive path2026-09-18exceptional-state handling failure6.1.149, 6.6.103, 6.12.44, 6.16.4, 6.17-rc3
CVE-2026-53266bridge ebtables SNAT ARP rewrite2026-09-18out-of-bounds or cross-boundary write into writable assumptions5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36, 7.0.13, 7.1
CVE-2025-39964AF_ALG crypto socket API2026-09-18race condition on concurrent writes5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9, 6.17

The three bugs are not identical in exploit mechanics, but they share the same response lesson. If you scope a supply-chain or CI incident as “the attacker only got user-level code execution,” that conclusion stops being reliable when the kernel below that process is now in KEV.

Why AppSec teams should care

The host-side chain is short:

malicious npm or PyPI dependency
  -> attacker code runs in CI or on a developer host
  -> attacker reaches local Linux primitives as an ordinary user
  -> vulnerable kernel path upgrades impact from process-level to host-level

That is why these Linux items belong in a research feed that usually covers package ecosystems. They are the second-stage bugs that decide whether a poisoned dependency stays inside one process or turns into something much worse.

CVE-2026-53266: the clearest privilege-boundary problem in the set

Of the three KEV additions, CVE-2026-53266 is the easiest one to map to a real host-boundary failure.

The vulnerable path sits in the Linux bridge netfilter code for the ebtables SNAT target. Public NVD and Red Hat descriptions agree on the important detail: the ARP sender hardware address rewrite uses skb_store_bits() to write through an offset relative to skb->data, but the code only proved that an earlier read was safe, not that the later write target was writable.

The vulnerable write looks like this:

skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN)

The missing guarantee is what matters. skb_header_pointer() can safely read the ARP header, but it does not ensure that the later sender-hardware-address bytes sit in writable memory. If those bytes still live in a nonlinear socket-buffer fragment backed by a splice-imported file page, skb_store_bits() can write directly into memory that crosses the intended isolation boundary.

Reduced to the behavior defenders need to understand, the path looks like this:

bridge packet with ARP payload
  -> ebtables SNAT rule with ARP SHA rewrite
  -> skb_header_pointer() reads header safely
  -> skb_store_bits() writes new MAC through skb->data-relative offset
  -> target bytes still backed by splice-imported or shared page
  -> write lands in shared or file-backed memory

Red Hat’s bug record is more explicit than the short CVE text, and that is useful. It calls out file-backed page-cache corruption, cross-process memory corruption through vmsplice()-style sharing, and kernel-crash potential. It also explains why this bug matters on virtualized and containerized bridge setups where an attacker with CAP_NET_ADMIN in the relevant namespace can shape the rule path.

That does not make every affected Linux host instantly rootable. It does make this a high-value post-foothold primitive on Linux hosts that combine:

  • bridge networking,
  • ebtables SNAT rules,
  • ARP sender-hardware-address rewriting,
  • and environments where lower-trust code can still reach namespace or network-control features.

CVE-2025-39682: zero-length rx_list state broke the kTLS receive-path assumptions

CVE-2025-39682 sits in net/tls/tls_sw.c, and the public Linux CVE announcement is precise enough to reason from without inventing an exploit chain.

The kTLS receive path is supposed to keep a simple invariant for each recvmsg() call:

either process only contiguous DATA records
or process one non-DATA record

The corner case that broke the invariant was a zero-length record already sitting on rx_list. The receive logic assumes that only data records use the zero-copy path and that a change in record type will break the loop before the state becomes inconsistent. That assumption failed when the initial record came from rx_list and had zero length.

Public kernel documentation describes the logic like this:

recvmsg()
  -> process records
  -> if type changes after decryption, queue pending skb to rx_list
  -> next recvmsg() resumes from rx_list

The problem is that zero-copy decryption and later queue handling are supposed to stay mutually consistent. A zero-length initial record coming from rx_list let subsequent records move through the receive path under the wrong assumptions about whether zero-copy and queuing state had already been settled.

This is the one article section where precision matters most. The public writeups do not describe a neat “local root in three syscalls” story. They describe a state-handling flaw in the kTLS receive path that CISA nevertheless says is exploited in the wild. That is enough for defenders to take it seriously without pretending we have a public privilege-escalation proof for every environment.

In practice, treat it as a signal that Linux hosts terminating or accelerating TLS in kernel space need the same urgency you would give any other KEV item, even if the exploit chain details are not fully public.

CVE-2025-39964: AF_ALG let concurrent writers trample shared socket state

CVE-2025-39964 is simpler to explain and easier to miss because it does not start from a classic buffer-overflow shape.

The AF_ALG user-space crypto API exposes kernel cryptographic operations through sockets. The bug was that two writers could use the same AF_ALG socket at the same time. Public kernel notes are blunt about the result: data can interleave unpredictably, and the socket’s internal state can become inconsistent.

The upstream fix summary is short enough to quote almost directly in reduced form:

two writes to same af_alg socket
  -> interleaved data
  -> inconsistent internal socket state
  -> add ctx->write to enforce exclusive writer ownership

That is not just a correctness bug for edge-case crypto consumers. In shared Linux environments, incorrect kernel crypto state can become a denial-of-service problem or a data-integrity problem. NVD’s scoring disagreement is worth noticing here too: NIST currently scores it medium, while the kernel CNA score is higher because corrupted socket state is more dangerous than a routine application race.

From an AppSec perspective, the operational question is whether hostile code can reach AF_ALG on a system that handles secrets or signs artifacts. If yes, a concurrency flaw in the kernel crypto API is not somebody else’s problem.

Scoping the affected estate

Start with the running kernel, not just what your package manager says is installed:

uname -r

Then map the host to the vulnerable subsystem:

# kTLS exposure
rg -n "CONFIG_TLS|CONFIG_TLS_DEVICE" "/boot/config-$(uname -r)"

# Bridge netfilter and ebtables exposure
rg -n "CONFIG_BRIDGE_NETFILTER|CONFIG_BRIDGE_NF_EBTABLES" "/boot/config-$(uname -r)"

# AF_ALG exposure
rg -n "CONFIG_CRYPTO_USER_API|CONFIG_CRYPTO_USER_API_SKCIPHER|CONFIG_CRYPTO_USER_API_AEAD" "/boot/config-$(uname -r)"

Vendor backports complicate simple version checks, so changelogs and errata are higher-signal than branch numbers alone:

rpm -q --changelog kernel | rg 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'

apt changelog "linux-image-$(uname -r)" 2>/dev/null | \
  rg 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'

For CVE-2026-53266, scoping should also include the actual bridge rules:

sudo ebtables -t nat -L --Lc 2>/dev/null

Look specifically for SNAT rules that rewrite ARP sender hardware addresses. That is the dangerous path the public writeups keep returning to.

What to do now

  1. Patch to vendor kernels that carry fixes for all three CVEs, not just one of them.
  2. Reboot into those kernels. Installed-but-not-running fixes do not help.
  3. Treat recently compromised Linux runners, workstations, and shared hosts as triage cases, not only patch cases, because CISA explicitly asks for forensic follow-up.
  4. Review whether lower-trust CI jobs, package-install steps, and container workloads can still reach host features that make these bugs more usable.

If you need a prioritization shortcut, start with CVE-2026-53266 for host-boundary review, but do not ignore the other two just because their public writeups sound less dramatic. CISA did not add three Linux kernel CVEs to KEV on the same day by accident.

The broader lesson is the same one we keep seeing in package-security incidents. Supply-chain attacks do not end at npm install or pip install. On Linux, they often continue downward into the kernel. When that kernel now carries KEV-listed bugs in kTLS, ebtables, or AF_ALG, the right model is not “application issue plus separate infrastructure issue.” It is one attack surface with two stages.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Get Demo

References