Cybersecurity News

Cybersecurity News: 3 Linux Kernel Flaws Exploited

Published September 23, 2026 · DNS Benchmark Pro Editorial · Reading time: 6 minutes

This week's dominant cybersecurity news is not a new vulnerability at all. It is three old ones. The U.S. Cybersecurity and Infrastructure Security Agency confirmed active in-the-wild exploitation of three Linux kernel defects whose patches shipped upstream between September 2025 and June 2026 — and then gave federal civilian agencies a three-day remediation window. For anyone running Linux under a DNS resolver, a load balancer, a container host or a hypervisor, that window is a fair proxy for how quickly the rest of us should be moving.

What CISA added to the KEV catalog

The three entries span entirely different kernel subsystems — the TLS offload path, the bridge firewall and the userspace crypto API — with no publicly known chain linking them. As is standard for KEV additions, CISA disclosed exploitation but not the incidents, targets or threat actors.

CVE-2025-39682: a network-reachable kTLS flaw at CVSS 9.8

The most consequential of the three is the kernel TLS bug. kTLS moves TLS record processing into the kernel so data is encrypted or decrypted without bouncing through userspace — the mechanism behind zero-copy TLS on high-throughput web servers, CDN edge nodes and proxies.

Per the upstream commit message, each recvmsg() call must process either a run of contiguous DATA records or a single non-DATA record. Under TLS 1.3 the record type is not known until after decryption, so a pending record of the wrong type is queued to rx_list for the next call. Zero-length records were mishandled on that path, and because zero-copy decryption writes straight into the userspace buffer the skb cannot simply be requeued. The kernel.org CNA scored the resulting state confusion at 9.8 with AV:N/AC:L/PR:N/UI:N: no privileges, no user interaction, reachable across the network.

If you terminate TLS in the kernel anywhere in your server infrastructure, verify this one first. That includes DNS-over-HTTPS front ends, where DNS security and cloud security stop being separate problems: a kernel-level fault in the TLS path degrades availability in the same way a volumetric DDoS attack would, without any of the traffic volume that makes a DDoS attack visible on a graph.

CVE-2026-53266: ebtables SNAT and the scope-change problem

The second flaw sits in bridge netfilter. The ebtables SNAT target guards its Ethernet source-address rewrite behind skb_ensure_writable(skb, 0), because at the bridge hooks the Ethernet header is reached through skb_mac_header() while skb->data points at the payload. The optional ARP sender-hardware-address rewrite writes through skb_store_bits() at a different offset and was never covered by that guard — an out-of-bounds write reachable with a crafted ARP payload.

The detail that matters operationally is the S:C scope change in the CVSS vector: a successful exploit can affect resources beyond the vulnerable component's security authority. That is why this class of bridge-layer bug draws attention in containerised environments, where one Linux bridge switches traffic for dozens of tenants. CISA has not said whether the observed exploitation involved that scenario.

CVE-2025-39964: a race in the crypto path

The third flaw, in the AF_ALG userspace crypto interface, is conceptually the simplest: two concurrent writes to the same socket interleave unpredictably and leave internal state inconsistent. The fix adds a ctx->write field asserting exclusive write ownership. Public scoring diverges sharply — kernel.org rates it 7.8 High across confidentiality, integrity and availability, NVD 3.3 Low on availability alone. When two authorities disagree by four and a half points, the safe reading is the one CISA acted on.

A patch-lag story, not a zero-day vulnerability

None of these is a zero-day. The CVE records were published on 5 September 2025, 13 October 2025 and 25 June 2026, with fixes in mainline and the stable trees before those dates. The window being exploited today is entirely the gap between upstream fix and fleet reboot.

That gap is structural. Kernel updates need a reboot unless live patching is in place, reboots need maintenance windows, and windows on DNS resolvers, edge proxies and database hosts are the hardest to get. The result is the one CISA is now reporting, and it is why this particular piece of cybersecurity news matters more than a fresh advisory would: a flaw quietly fixed a year ago becomes a live intrusion path because the patched binary sits on disk behind a machine nobody has restarted.

What it means for DNS server performance and network latency

Resolver operators face a second-order effect. Patching a kernel across a fleet means rolling reboots, and rolling reboots mean cold caches. A recursive resolver that returns with an empty cache answers from authoritative servers for its first minutes of life, and users read that as elevated network latency long before they read it as a DNS error. Take out more of the fleet at once than remaining capacity absorbs and a routine patch cycle becomes a self-inflicted network outage.

The mitigation is measurement, not hope: baseline before the window, re-measure after, and you can tell a cold cache from a regression. A network diagnostic tool that measures real DNS-over-HTTPS resolution latency gives that comparison in minutes, and our explainer on DNS over HTTPS covers why encrypted transports change the measurement. See also our coverage of the BIND 9.20.29 DoH crash.

The IT security checklist for this week

1. Check the running kernel, not the installed package. uname -r against your vendor's fixed version; an update that has never been booted is not a patch.
2. Prioritise kTLS exposure. Edge proxies, DoH front ends and CDN nodes go first: CVE-2025-39682 is the only one of the three reachable from the network.
3. Audit bridge firewall rules. CVE-2026-53266 needs specific ebtables SNAT configuration; confirm whether your container hosts have it.
4. Restrict AF_ALG. Untrusted or low-privilege workloads should not have free access to the kernel crypto socket API.
5. Triage, do not just patch. KEV listing means exploitation already happened somewhere — treat long-uptime internet-facing hosts as compromise-assessment candidates.
6. Sequence reboots against capacity so cache warm-up and failover do not compound into a user-visible outage.

Industry impact

The broader signal in this cybersecurity news cycle is that attackers have industrialised the n-day. Three unrelated subsystems, three separate patches, one failure mode: fixes that exist and are not deployed. CISA's three-day deadline reads as an acknowledgement that the exploitation was not theoretical.

For enterprise IT news readers the takeaway is uncomfortable but actionable. The Linux kernel sits under nearly every part of modern tech infrastructure — DNS, cloud, storage, networking, virtualisation — which turns kernel patch latency into a single shared risk across otherwise unrelated services. Measuring reboot cadence is now as much an IT security control as scanning for a zero-day vulnerability in the first place.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• CISA alert, 21 September 2026
• CVE Program record list (kernel.org CNA entries for CVE-2025-39682, CVE-2026-53266, CVE-2025-39964)
• NVD — CVE-2025-39964
• SecurityWeek — Organizations Warned of 3 Exploited Linux Kernel Vulnerabilities
• BleepingComputer — CISA alerts of active exploitation of three Linux kernel flaws

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. Photographs are third-party works reproduced under the licences noted in each caption; no images on this page are AI-generated.