CISA listed CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964 as exploited. Red Hat refreshed the advisories Saturday. Federal due date is September 21. The reboot is the work.
Saturday's named clock was already on the board: Cisco ISE, the Acronis hosting-panel plugin, and the Pixel modem. We wrote those earlier this week. What showed up overnight is a second list, and it is the kernel.
CISA added three Linux kernel flaws to the Known Exploited Vulnerabilities catalog on Friday. Federal civilian agencies have until Sunday, September 21. Red Hat refreshed the advisories at 02:00 UTC this morning and used the same sentence on all three: high risk, known public exploits, treat it as a priority. The names are CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964. They sit in three different corners of the kernel. Nobody has published a single campaign that ties them together. CISA listed them anyway because someone is already using each one.
CVE-2025-39682 is in the kernel TLS receive path. When a server turns on kTLS, the kernel decrypts TLS records instead of leaving that work to OpenSSL. CDNs, reverse proxies, and a few database stacks do this for throughput. The bug is a corner case around a zero-length record. Some write-ups score it a 9.8. Others sit lower. Ignore the argument. Red Hat says there is a public exploit and CISA says it is in use.
CVE-2026-53266 is an out-of-bounds write in ebtables SNAT when it rewrites ARP. You see that pattern on some bridges, containers, and virtual networks. A local attacker who can load the right netfilter rules can corrupt kernel memory. Privilege needed is not "anyone on the internet." It is still a local-to-root class of finding, which is enough once someone is already on the box.
CVE-2025-39964 is a race on AF_ALG, the socket interface that lets userspace ask the kernel to do crypto. Two writers on the same socket can leave the context a mess. Outcomes range from bad crypto output to a panic. NVD, Red Hat, and the CNA do not even agree on the score. CISA's listing is the signal that matters: it is exploited.
Binding Operational Directive 26-04 is a US civilian-agency rule. Private shops in Alberta are not under that clock. The catalog is still the shortest honest priority list we have, because CISA only adds a CVE when someone has used it. Verizon's 2026 DBIR said only about a quarter of KEV items were fully closed in 2025, and the median close time ran past a month. A three-day federal window is not a private-sector law. It is a hint that waiting for the next maintenance Sunday is how these stay open.
All three fixes are kernel updates. That means a reboot, unless your vendor's live-patch channel has already shipped these exact CVEs. Do not assume kpatch or Ubuntu Livepatch covered Friday's trio because it covered last month's. Check the catalog for your build. If it is not there, schedule the reboot.
Start with an inventory of running kernels, not the package that was last approved in a ticket. Then ask three questions. Which hosts use kTLS. Which hosts load ebtables SNAT for ARP. Which hosts expose AF_ALG to untrusted local users. Multi-tenant Linux (hosting, CI runners, shared jump boxes) goes first. A workstation that never enabled kTLS is not the same problem as an edge proxy that did.
BOD 26-04 also asks federal teams to look for compromise before they call the host done. That is the part civilian shops skip. If a box has been on a vulnerable kernel for months, a clean package install does not prove nobody used the public exploit last Tuesday. Review panic logs, unexpected module loads, and any local account that should not have been able to become root. We will not walk through the exploits. The operational fact is enough: patching is necessary and it is not the whole job.
Same week, researcher Asim Manizada disclosed four more local privilege-escalation bugs in the kernel (DirtyAH6, TUNderflow, PPPoEject, DiagSpill). Those are not on KEV. They are a reminder that networking and crypto in the kernel are getting a lot of attention. Do not let the extra names displace the three that are already being used.
uname -r after the reboot. The ticket is not evidence. The running kernel is.Three kernel subsystems, three exploited bugs, one weekend. Forensic Five reviews what is actually running, including the kernel you have not rebooted since the last quiet Friday. From St. Albert, Alberta. Apply the vendor kernel. Then look at the logs like someone may already have.
Security Analyst
Mathew leads assessments and consulting at Forensic Five from St. Albert, Alberta. His background is Linux systems, networks, and application infrastructure.
Tell us your name to start chatting.