CISA put three Linux kernel flaws on the exploited list on Thursday. On Ubuntu 24.04 and 22.04, one of them still has no patch to install.
On September 18 CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog in a single day, all three with a September 21 deadline and a forensic triage requirement. Three in one day has happened once before in the catalog's history. We checked the actual package archives rather than the coverage, and the finding is this: for CVE-2026-53266, the ebtables flaw, Ubuntu has not published a fixed kernel for 24.04 LTS or 22.04 LTS. The Launchpad publishing API shows 6.8.0-139.139 on 24.04 and 5.15.0-191.201 on 22.04; the fix needs 6.8.0-146.146 and 5.15.0-198.208, and Ubuntu's own tracker lists both as pending. Debian shipped it across every release. Red Hat shipped it on July 8 and July 14, over two months before CISA confirmed exploitation. The only Ubuntu security notices carrying this CVE on 24.04 cover the HWE 7.0, NVIDIA and NVIDIA Tegra kernels, none of which a normal VPS runs. Also: why the three authorities scoring these flaws disagree about whether the worst one is even remotely reachable, why uname -r will never match the version in a CVE record, and the four commands that tell you in two minutes whether any of this reaches you.
If your website, your app, or your internal tooling runs on a server you rent, it runs on a Linux kernel. You did not choose the version. You have probably never looked at it. It updates when your package manager says there is an update, and the rest of the time you are entitled to assume that somebody competent is on the other end of that pipe.
On Thursday, CISA said three flaws in that kernel are being exploited right now and gave federal agencies until Sunday to deal with them.
For two of the three, the update is sitting in your package manager. For the third, on the two most widely deployed versions of the most widely deployed server Linux, there is nothing to install.
Everything below was checked against primary sources on September 19, 2026, and every version number is from a publishing API or a security tracker rather than from an article. Sources are CISA’s Known Exploited Vulnerabilities JSON feed pulled directly, the three CVE records from MITRE’s CVE Services API, the NVD API, Canonical’s Ubuntu security API and Launchpad’s package publishing API, the Debian security tracker’s JSON export, and Red Hat’s security data API. The comparisons in the middle of this article are ours, and the commands are included so you can repeat them.
What happened
CISA added three entries to the Known Exploited Vulnerabilities catalog on September 18, 2026, catalog version 2026.09.18. All three name Linux, product Kernel. All three carry a remediation deadline of September 21, three days. All three have forensicTriage set to Yes, which under BOD 26-04 tells federal agencies to look for evidence of compromise rather than simply patch and close the ticket.
| CVE | What it is | Published | Days to KEV |
|---|---|---|---|
| CVE-2025-39682 | Zero-length record mishandling in the kernel TLS receive path | September 5, 2025 | 378 |
| CVE-2025-39964 | Concurrent writes to the same AF_ALG crypto socket | October 13, 2025 | 340 |
| CVE-2026-53266 | Out-of-bounds write in the ebtables SNAT ARP rewrite | June 25, 2026 | 85 |
Two of the three are more than a year old. None of them is new. What changed on Thursday is that CISA says somebody is now using them.
They arrived through two separate alerts on the same day, one headed “CISA Adds One Known Exploited Vulnerability to Catalog” and one headed “CISA Adds Two,” which is why some coverage on Friday describes this as one kernel flaw and some describes it as three. The feed settles it: three entries, same date added, same due date.
Some context on how unusual that is. The catalog holds 1,716 entries in total, going back to 2021. Exactly 31 of them ever have named the Linux kernel, and 8 of those 31 arrived in 2026 alone, against 4 in 2024 and 6 in 2025. Three landing on a single day has happened once before, on September 15, 2022, when CISA added three kernel bugs from 2013 in one batch. So Thursday is the second time in the catalog’s history.
That also quietly changes a count we published last month. In our audit of which products keep turning up on this list, the Linux kernel had five 2026 entries and was tied with Langflow for the most-listed non-Microsoft product. Counting by product at catalog 2026.09.18, the kernel is now at eight for the year, behind only Microsoft Windows at thirteen and ahead of every other product in the catalog.
The finding: on Ubuntu LTS, one of the three has no fix to install
Update, September 20, 2026. We re-ran the Launchpad publishing query and the Ubuntu security API this morning, one day before the CISA deadline. Nothing has changed. Ubuntu 24.04 LTS still publishes
6.8.0-139.139in the security pocket and 22.04 LTS still publishes5.15.0-191.201, both dated September 4. Canonical’s tracker entry for CVE-2026-53266 was last updated September 18 and still readspendingfor jammy (target5.15.0-198.208) and noble (target6.8.0-146.146),neededfor focal, andreleasedonly for resolute at7.0.0-31.31. So the gap described below is forty-eight hours old and current: the deadline arrives tomorrow and the package does not exist. If you found bridge SNAT rules in step 3 of the action list,pro fix CVE-2026-53266and removing the rule remain the only two levers.
Here is the part that sent us to package archives instead of news sites.
CVE-2026-53266 is an out-of-bounds write in the bridge netfilter code. In the kernel’s own words, from the commit message that the CVE record quotes:
The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). […] However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data […] If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it.
In plainer terms: a rule that is supposed to rewrite a MAC address inside a network packet can end up writing those bytes into a page of memory that belongs to a file instead. CISA’s catalog entry describes the same thing and adds a sentence you do not usually see on a kernel entry: “The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS).”
Canonical’s own security tracker, pulled from its JSON API this morning, gives the status of the fix for the generic linux kernel package as follows.
| Ubuntu release | Status | Fixed version |
|---|---|---|
| 20.04 LTS (focal) | needed | none assigned |
| 22.04 LTS (jammy) | pending | 5.15.0-198.208 |
| 24.04 LTS (noble) | pending | 6.8.0-146.146 |
| 26.04 LTS (resolute) | released | 7.0.0-31.31 |
In Canonical’s vocabulary, pending means the fix is in a build that has not been published yet. needed means nobody has started. released means you can install it.
We did not want to rely on a status field, so we asked the archive directly. Launchpad’s publishing API reports what is actually sitting in the security and updates pockets right now:
curl -s "https://api.launchpad.net/1.0/ubuntu/+archive/primary?ws.op=getPublishedSources\
&source_name=linux&exact_match=true\
&distro_series=https://api.launchpad.net/1.0/ubuntu/noble&pocket=Security&status=Published Re-checked September 20, one day before the deadline: Ubuntu has still published nothing for 24.04 or 22.04, and Canonical's tracker still reads pending for both."
# source_package_version: 6.8.0-139.139 date_published: 2026-09-04# same query, distro_series=.../jammy
# source_package_version: 5.15.0-191.201 date_published: 2026-09-04So on Ubuntu 24.04 LTS, the newest published kernel is 6.8.0-139.139 and the fix requires 6.8.0-146.146. On Ubuntu 22.04 LTS, the newest published kernel is 5.15.0-191.201 and the fix requires 5.15.0-198.208. Neither exists in the archive. apt update && apt upgrade on either of those machines today will install everything available and leave this flaw in place.
The cloud kernel variants are in the same position or worse:
| Package | Ubuntu 24.04 LTS | Published now | Fix needs |
|---|---|---|---|
linux-aws |
needed | 6.8.0-1063.66 | not assigned |
linux-azure |
pending | 6.8.0-1067.75 | 6.8.0-1069.77 |
linux-gcp |
pending | 6.8.0-1067.75 | 6.8.0-1070.78 |
linux-oracle |
needed | n/a | not assigned |
linux-hwe-6.8 (on 22.04) |
pending | 6.8.0-138.138~22.04.1 | 6.8.0-146.146~22.04.1 |
linux-aws on 24.04 is the one to sit with for a second, because it is the default kernel on an Ubuntu 24.04 instance in AWS, and its status is needed with no target version assigned at all.
The security notices exist, but not for the kernel you are running
The confusing part, and the reason we nearly got this wrong ourselves, is that Ubuntu has published security notices carrying this CVE. Six of them are linked from the tracker. We pulled each one and checked which releases and which source packages they actually cover:
| Notice | Published | Releases and packages covered |
|---|---|---|
| USN-8726-1 | September 7 | 24.04: linux-aws-7.0, linux-hwe-7.0. 26.04: linux, linux-aws, linux-gcp, linux-gke, linux-realtime |
| USN-8727-1 | September 7 | 26.04: linux-oem-7.0 |
| USN-8728-1 | September 7 | 24.04: linux-gcp-7.0 |
| USN-8760-1 | September 15 | 24.04: NVIDIA kernel |
| USN-8781-1 | September 18 | 24.04: NVIDIA Tegra kernel |
| USN-8726-2 | September 18 | 26.04: linux-raspi |
Every 24.04 entry in that table is either a 7.0 hardware enablement kernel or an NVIDIA-specific kernel. Not one of them is the 6.8 generic or cloud kernel that a stock Ubuntu 24.04 server image boots. There is no 22.04 entry at all.
This is how a genuine gap hides in plain sight. A scanner that checks “has the distribution issued an advisory for this CVE” gets a yes. A human reading the tracker page sees five green-looking notices. The machine in front of you is still unpatched, because the notice was for a kernel flavour you do not run.
Debian and Red Hat shipped it months ago
The same flaw, on the other two distribution families that small businesses actually use:
| Distribution | Status | Fixed in | When |
|---|---|---|---|
| Debian 11 (bullseye) | resolved | 5.10.259-1 | |
| Debian 12 (bookworm) | resolved | 6.1.176-1 | |
| Debian 13 (trixie) | resolved | 6.12.94-1 | |
| Debian forky / sid | resolved | 7.0.13-1 | |
| RHEL 8 | fixed | 4.18.0-553.143.1.el8_10 | July 14, 2026 |
| RHEL 9 | fixed | 5.14.0-687.23.1.el9_8 | July 8, 2026 |
| RHEL 10 | Affected, unfixed | ||
| Ubuntu 24.04 / 22.04 LTS | pending |
Red Hat shipped the fix to RHEL 9 on July 8 and to RHEL 8 on July 14, which is 72 and 66 days before CISA confirmed the flaw was under attack. Debian has it resolved in every tracked release. If you run Debian, AlmaLinux, Rocky, or RHEL proper on a supported branch, this is already behind you or it is one dnf update away. RHEL 10 is the one exception in that family and is still listed as Affected.
If you run Ubuntu LTS, which is what the overwhelming majority of small business VPS instances, DigitalOcean droplets, Lightsail boxes and Hetzner servers run, the honest answer today is that there is nothing to install and the only thing you can do is understand your exposure. Which brings us to the part that actually matters.
Which of the three reaches you, honestly
All three of these are real. Not all three reach a normal web server. Working out which is which took us longer than writing about them, so here is the short version first and the reasoning after.
| CVE | Reaches a typical small business Linux server? | Why |
|---|---|---|
| CVE-2025-39682 (kTLS) | Almost certainly not, and it is already patched on Ubuntu LTS anyway | Requires kernel TLS on the receive path, which is off unless somebody turned it on |
| CVE-2025-39964 (AF_ALG) | Only after somebody already has a shell, and it is patched | Local only, needs an unprivileged process on the box |
| CVE-2026-53266 (ebtables) | Only if you run bridge ebtables SNAT rules, and it is not patched on Ubuntu LTS | Needs CAP_NET_ADMIN and a specific bridge rule |
CVE-2025-39682, the one with the scariest number
This is the one carrying a CVSS of 9.8 in headlines. It is a logic bug in net/tls/tls_sw.c, the kernel’s TLS implementation, on the receiving side. When an application hands a TCP socket to the kernel with TCP_ULP set to tls, the kernel takes over decrypting incoming TLS records. A remote peer sending a three-record sequence of data, zero-length non-data, data can push the receive path into processing subsequent records with the wrong assumptions.
The precondition is the whole story: something on your server has to be using kernel TLS on the receive path. Kernel TLS is opt-in. On nginx it requires OpenSSL 3.0 built with enable-ktls and an explicit ssl_conf_command Options KTLS directive or a system-wide Options = KTLS in the OpenSSL configuration, plus sendfile on. Nobody sets that by accident. The other consumers are NFS over TLS and SMB or RPC over TLS through the kernel handshake helper, none of which is common on a small business web server.
You can check in ten seconds:
# Is the TLS module even loaded?
lsmod | grep '^tls '
# If it is, how many sessions are actually using the receive path?
cat /proc/net/tls_stat 2>/dev/null
# TlsCurrRxSw is the count of receive sessions the kernel is handling right now.
# Zero, or no such file, means this bug has nothing to work with.And on Ubuntu 24.04 and 22.04 this one is fixed regardless: the fix landed in 6.8.0-86.87 for 24.04, and the 5.15 kernel on 22.04 was never affected. If your kernel is newer than that, and it is, you are done here.
CVE-2025-39964, the AF_ALG one
Two threads writing to the same AF_ALG socket at once interleave their data and leave the socket’s internal state inconsistent. AF_ALG is the userspace interface to the kernel’s crypto API. Opening one requires no capability check at all, so any unprivileged local process can reach it, including a process inside a container.
That is the correct way to read “local” on a web server. It does not mean nobody can get there. It means the attacker needs a foothold first: a webshell dropped through a vulnerable plugin, a leaked deploy key, a compromised dependency running in CI. This is the second move, the one that turns access into ownership. We have written about why that makes local privilege escalation more worrying rather than less, and nothing about this one changes that argument.
It is also already fixed on Ubuntu: 6.8.0-90.91 on 24.04, 5.15.0-164.174 on 22.04, both well behind what is published now.
CVE-2026-53266, the one you cannot patch on Ubuntu LTS
The one with no fix available is, fortunately, also the one with the narrowest precondition. Reaching it needs two things at once: CAP_NET_ADMIN, so you can install bridge netfilter rules, and an actual ebtables SNAT rule with the optional ARP sender hardware address rewrite enabled. Red Hat’s own statement on the flaw says exactly this:
This vulnerability requires specific bridge netfilter rules to be configured, limiting its impact to systems with such specialized network configurations.
Most servers do not have those rules. Docker’s default networking uses a bridge, but it programs iptables, not ebtables, and it does not install SNAT ARP rewrites. Where you do find ebtables rules is virtualization hosts, Proxmox and libvirt setups with bridged guest networking, some Kubernetes CNI configurations, and hand-rolled bridging on a box that is acting as a router.
Check whether that is you:
# Classic ebtables
sudo ebtables -t nat -L 2>/dev/null | grep -i snat
# nftables equivalent, which is what modern distributions actually use
sudo nft list ruleset bridge 2>/dev/null | grep -i snat
# Is the module even loaded?
lsmod | grep -E 'ebtable|ebt_nat|br_netfilter'If all three come back empty, this flaw has nothing to act on and the missing Ubuntu patch is an item for your notes rather than your evening.
The second precondition, CAP_NET_ADMIN, is worth one more paragraph because it is where containers come in. A default Docker container does not have it. --privileged or --cap-add=NET_ADMIN grants it. An unprivileged user namespace also grants it inside that namespace, which is the path the CVE record’s own scoring justification calls out. Ubuntu 24.04 mitigates that specific path by default: it ships kernel.apparmor_restrict_unprivileged_userns set to 1, so unprivileged processes cannot create user namespaces unless an AppArmor profile permits it. Check yours:
sysctl kernel.apparmor_restrict_unprivileged_userns
# 1 = restricted, the default on 24.04 and later
# 0 = anybody can create a user namespace, which widens this considerablyThat value is a default that people turn off, because it breaks some sandboxing tools and some CI runners, and the internet is full of instructions to set it to 0. If somebody set it to 0 on your machine and you also have bridge SNAT rules, you are the configuration this CVE is about, on a distribution with no patch available.
Why uname -r will never match the version in the CVE
This part is evergreen and it is the reason most people either panic or ignore these stories, so it is worth twelve lines.
The CVE record for CVE-2026-53266 says the fix is in kernel 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36 and 7.0.13. Your Ubuntu 24.04 server says:
uname -r
# 6.8.0-79-generic6.8.0 is not in that list. It is not even close to any of them. This is not a bug and it does not mean you are safe or unsafe. Distributions do not ship upstream kernels. They pick a base version, freeze it, and then backport individual security fixes into it for years, bumping only the number after the dash. Ubuntu’s 6.8.0-139 contains thousands of patches that upstream 6.8.0 never had. Red Hat’s RHEL 9 kernel is branded 5.14.0 and contains fixes from kernels that did not exist when 5.14 shipped.
The practical consequence: the only authority on whether your machine is patched is your distribution’s security tracker, not the CVE record. The upstream version numbers in a CVE are useful if you compile your own kernel and useless otherwise.
The commands that give you a real answer:
# Ubuntu, with or without Pro. This checks the actual package state.
pro fix CVE-2026-53266
# Debian, Ubuntu: what is installed vs what is available
apt list --upgradable | grep linux-image
dpkg -l 'linux-image*' | grep ^ii
# RHEL, Alma, Rocky, Fedora
dnf updateinfo info --cve CVE-2026-53266
# Anywhere: is the running kernel the newest installed one?
# If these differ, a fixed kernel may already be on disk waiting for a reboot.
uname -r
ls -t /boot/vmlinuz-* | head -1That last pair catches the single most common real-world failure we see. The fix was installed weeks ago. Nobody rebooted. The machine is running the old kernel out of memory and every scanner that checks package versions reports it as patched.
The three authorities scoring these flaws do not agree with each other
While checking severity we found something worth publishing on its own, because it explains why you will see wildly different numbers for the same bug this week.
| CVE | Linux kernel CNA | NVD primary | Red Hat |
|---|---|---|---|
| CVE-2025-39682 | 9.8 Critical, AV:N/AC:L/PR:N |
7.1 High, AV:L/AC:L/PR:L |
7.0 Moderate, AV:N/AC:H, C:L/I:L |
| CVE-2025-39964 | 7.8 High, AV:L |
5.5 Medium, AV:L, A:H only |
5.5 Moderate, A:H only |
| CVE-2026-53266 | 8.8 High, AV:L/S:C |
no primary score | 7.5 Important, AV:N/AC:H/PR:L |
Look at the first row. The kernel project, which owns the code, says the attack vector is Network with low complexity and no privileges: 9.8. NVD says the attack vector is Local: 7.1. Red Hat agrees it is Network but calls the complexity High and the confidentiality and integrity impact Low: 7.0. Those are not shades of the same opinion. They disagree about whether a remote attacker can reach this at all.
We are not going to adjudicate that, and neither should you. The point is the practical one: a CVSS number sourced from one authority and quoted without its vector is worthless for deciding what to do on Monday. The vector is the part that tells you whether the bug reaches you. Two of the three rows above become undramatic the moment you read AV:L and ask who has local access to the box.
CISA’s own structured assessment, added to all three records on September 18, is more useful than any of the scores:
| CVE | Exploitation | Automatable | Technical impact |
|---|---|---|---|
| CVE-2025-39682 | active | yes | total |
| CVE-2025-39964 | active | no | total |
| CVE-2026-53266 | active | no | total |
Automatable: yes on only one of the three, and it is the kTLS one. That is CISA saying this is the one an attacker can point at the whole internet and let run, while the other two need a human who is already inside deciding to use them. It is also, conveniently, the one Ubuntu patched a year ago.
What to actually do, in order
If you run your own Linux server, this is about fifteen minutes:
- Run the update.
sudo apt update && sudo apt upgradeorsudo dnf update. Two of the three are fixed on every supported distribution and this closes them. - Check whether you are running the kernel you installed. Compare
uname -ragainst the newest file in/boot. If they differ, schedule the reboot. This is the step people skip and it is the one that matters most. - Run the three exposure checks above:
lsmod | grep '^tls ',nft list ruleset bridge | grep -i snat, andsysctl kernel.apparmor_restrict_unprivileged_userns. Ninety seconds, and in most cases all three come back reassuring. - If you are on Ubuntu 24.04 or 22.04 and step 3 found bridge SNAT rules, you have a real gap with no patch. Your options are to remove the rule if it is not load-bearing, to check whether Ubuntu Pro’s Livepatch service covers it with
pro fix CVE-2026-53266, or to accept the exposure knowingly and set a reminder to re-runapt upgradedaily until the kernel appears. - Turn on
unattended-upgradesif it is not on. It would not have helped with this specific one, because you cannot auto-install a package that does not exist, but it handles the ninety-five percent of cases that are not this.
If your site is on shared hosting or a managed platform, you cannot run any of these commands and you should not try. Vercel, Netlify, Cloudflare Pages, a managed WordPress host, a Shopify store: the kernel is the provider’s problem and their patch cadence is not yours to set. This is the same structural situation we wrote about in the Acronis backup plugin post, and the only lever is a question rather than a command. One question is enough here:
CISA added three Linux kernel vulnerabilities to its exploited list on September 18 with a September 21 deadline. What is your kernel patch and reboot status for the hosts my sites are on, and does it include CVE-2026-53266?
A host that can answer that in a day is a host worth keeping.
If you have a VPS you forgot about, and a lot of businesses do, this is the week to find it. The old staging server, the box that runs one cron job, the machine somebody spun up for a client project in 2022. Those are the hosts that make four-year-old kernel bugs worth an attacker’s tooling budget, and it is why a kernel flaw from 2022 was still earning a place on this list last month.
What we could not verify
- Who is exploiting these, at what scale, and how. CISA’s catalog asserts active exploitation and publishes no evidence, no attribution and no indicators. That is normal for KEV and it is the main limitation of using it as your only feed. Nothing in this article is based on a claim about a specific campaign, because we found none that we could source.
- Whether the exploitation is against servers at all. The kernel is in Android phones, routers, NAS boxes, cars and industrial controllers. An entry that says “Linux Kernel” says nothing about which of those is being attacked, and the CISA entries for two of the three carry the standard end-of-life wording, which often points at embedded and vendor-forked kernels rather than current distributions.
- When Ubuntu will publish the fixed kernels. Canonical’s tracker names target versions for 22.04 and 24.04 and gives no date. We found no public build schedule that would let us say more. The versions listed as
pendingmay be published the day after we post this, which is the ordinary outcome, and if you are reading this later than September 19 you should re-run the Launchpad query above rather than trusting this paragraph. - Whether Ubuntu Pro’s Livepatch service covers CVE-2026-53266. Ubuntu rates the flaw priority High and Livepatch covers high and critical kernel CVEs, so it is plausible. We could not reach a public API listing Livepatch coverage per CVE and we are not going to assert it from an inference.
pro fix CVE-2026-53266on the machine itself is the authoritative answer. - Why CISA published these across two alerts on the same day. The feed is unambiguous that all three were added September 18. We do not know why the alerts were split, and it matters only because it is why the coverage disagrees about the count.
- Whether a small business is actually more likely to be running the vulnerable configuration than a large one. Our read is the opposite, since ebtables SNAT rules are a virtualization and networking artefact, but we have no data on deployment share and we are not going to invent any.
The short version
Three Linux kernel flaws went on CISA’s actively exploited list on Thursday with a Sunday deadline. It is the second time in the catalog’s history that three kernel entries landed on one day.
Two of them are already fixed everywhere and your normal update installs them. The third, CVE-2026-53266, is fixed in Debian, fixed in RHEL 8 and 9 since July, and not published for Ubuntu 24.04 LTS or 22.04 LTS as of this morning. The security notices that carry the CVE on 24.04 are for the hardware enablement and NVIDIA kernels, not the one a normal server boots, which is exactly the shape of gap that automated checking misses.
The saving grace is that the unpatchable one is also the narrowest. It needs bridge ebtables SNAT rules and CAP_NET_ADMIN, and most web servers have neither. Three commands tell you in ninety seconds whether you are the exception.
The broader habit is the thing worth keeping after this specific week passes. Run the update. Then check whether you actually rebooted into it. Then ask, once, what your host’s answer would be if you asked them the same question. Those three steps close more real exposure than any amount of reading about CVSS scores that three different authorities cannot agree on.
If you want a second pair of eyes on a server nobody has logged into for a while, or a straight answer about whether something you are running needs self-hosting at all, get in touch. We are in Toronto, we do this for clients regularly, and the version of this conversation that happens beforehand is a great deal shorter than the one that happens after.
Sources
- Known Exploited Vulnerabilities Catalog JSON feed, CISA, downloaded September 19, 2026 at catalog version 2026.09.18, released September 18 at 19:00 UTC, for the three Linux kernel entries added September 18, their quoted short descriptions, the September 21 due dates, the
forensicTriagevalues of Yes, and the 1,716 total entries. The count of 31 Linux kernel entries in the catalog’s history, the identification of September 15, 2022 as the only other date with three, and the per-vendor tallies are our own analysis of that file. - CISA Adds One Known Exploited Vulnerability to Catalog, CISA, September 18, 2026, for the alert naming CVE-2025-39682 alone, alongside the separate “CISA Adds Two” alert of the same date
- CVE records retrieved from the MITRE CVE Services API on September 19, 2026: CVE-2025-39682, CVE-2025-39964 and CVE-2026-53266, for the quoted commit messages, the Linux kernel CNA’s CVSS scores and vectors, the upstream fixed version lists, the publication dates of September 5 2025, October 13 2025 and June 25 2026, and the CISA-ADP SSVC assessments timestamped September 18, 2026
- NVD records for the same three CVEs, queried through the NVD API on September 19, 2026, for the NVD primary CVSS scores of 7.1 and 5.5, the absence of an NVD primary score on CVE-2026-53266, and the vulnerability statuses of Undergoing Analysis, Analyzed and Analyzed
- Ubuntu security tracker record for CVE-2026-53266, retrieved through Canonical’s JSON API on September 19, 2026 with a record
updated_atof September 18 at 10:52 UTC, for the per-release statuses of needed, pending, pending and released, the target versions 5.15.0-198.208 and 6.8.0-146.146, the priority of high, and the list of associated security notices. The equivalent records for CVE-2025-39682 and CVE-2025-39964 are cited for the fixed versions 6.8.0-86.87 and 6.8.0-90.91 on 24.04, 5.15.0-164.174 on 22.04, and the not-affected status of the 5.15 kernel for the kTLS flaw - Ubuntu security notices USN-8726-1, USN-8727-1, USN-8728-1, USN-8760-1, USN-8781-1 and USN-8726-2, each retrieved through Canonical’s JSON API on September 19, 2026, for their publication dates and for the release and source package lists in the table above. The observation that no notice covers the 6.8 generic or cloud kernel on 24.04, and that none covers 22.04 at all, is ours.
- Launchpad publishing API, queried September 19, 2026 for
linux,linux-aws,linux-azure,linux-gcpandlinux-hwe-6.8in the Security pocket of noble, jammy and resolute, for the published versions 6.8.0-139.139, 5.15.0-191.201, 6.8.0-1063.66, 6.8.0-1067.75, 6.8.0-138.138~22.04.1 and 7.0.0-31.31 and their publication dates. The comparison against the required fixed versions is ours. - Debian security tracker JSON export, downloaded September 19, 2026, for the resolved status and fixed versions of all three CVEs in bullseye, bookworm, trixie, forky and sid
- Red Hat security data API records for CVE-2025-39682, CVE-2025-39964 and CVE-2026-53266, retrieved September 19, 2026, for Red Hat’s severity ratings and CVSS vectors, the quoted statement on CVE-2026-53266 requiring specific bridge netfilter rules, the RHEL 8 and RHEL 9 fixed packages with release dates of July 14 and July 8, 2026 under advisories RHSA-2026:39082, RHSA-2026:39083 and RHSA-2026:36645, and the RHEL 10 status of Affected
- Kernel TLS, Linux kernel documentation, for the
TCP_ULPsocket option, the/proc/net/tls_statinterface and the meaning of theTlsCurrRxSwcounter - Improving NGINX Performance with Kernel TLS and SSL_sendfile(), F5, for kernel TLS in nginx requiring OpenSSL 3.0 built with
enable-ktlsplus an explicitssl_conf_command Options KTLSdirective, which is the basis for the claim that kTLS is opt-in rather than default - Restricted unprivileged user namespaces are coming to Ubuntu 23.10, Canonical, and the Ubuntu 24.04 LTS release notes, for
kernel.apparmor_restrict_unprivileged_usernsbeing enabled by default from 24.04 onward - Ubuntu 20.04 LTS Standard Support has ended, Canonical, for 20.04 leaving standard support on May 31, 2025 and continuing under Ubuntu Pro ESM, which is why its status on this CVE is
neededrather than pending - BOD 26-04: Prioritizing Security Updates Based on Risk, CISA, for the risk-based deadline framework and the forensic triage requirement referenced in all three catalog entries