@blamejs/exceptd-skills 0.21.0 → 0.21.1

package/data/cve-catalog.json

@@ -93,6 +93,598 @@
     },
     "last_threat_review": "2026-05-30"
   },
+  "CVE-2026-53266": {
+    "name": "Linux Kernel Out-of-Bounds Write Vulnerability (CVE-2026-53266)",
+    "cvss_score": 8.8,
+    "cvss_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
+    "cwe_refs": [
+      "CWE-787"
+    ],
+    "cisa_kev": true,
+    "cisa_kev_date": "2026-09-18",
+    "cisa_kev_due_date": "2026-09-21",
+    "known_ransomware_use": false,
+    "active_exploitation": "confirmed",
+    "complexity": "low",
+    "vector": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: bridge: make ebt_snat ARP rewrite writable\n\nThe ebtables SNAT target keeps the Ethernet source address rewrite\nbehind skb_ensure_writable(skb, 0).  This is intentional: at the bridge\nebtables hooks the Ethernet header is addressed through\nskb_mac_header()/eth_hdr(), while skb->data points at the Ethernet\npayload.  Asking skb_ensure_writable() for ETH_HLEN bytes would check\nthe payload, not the Ethernet header, and would reintroduce the small\npacket regression fixed by commit 63137bc5882a.\n\nHowever, the optional ARP sender hardware address rewrite is different.\nIt writes through skb_store_bits() at an offset relative to skb->data:\n\n        skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN)\n\nskb_header_pointer() only safely reads the ARP header; it does not make\nthe later sender hardware address range writable.  If that range is\nstill held in a nonlinear skb fragment backed by a splice-imported file\npage, skb_store_bits() maps the frag page and copies the new MAC address\ndirectly into it.\n\nEnsure the ARP SHA range is writable before reading the ARP header and\nbefore calling skb_store_bits().",
+    "epss_score": 0.00276,
+    "epss_percentile": 0.20229,
+    "epss_date": "2026-09-22",
+    "epss_source": "https://api.first.org/data/v1/epss?cve=CVE-2026-53266",
+    "vendor_advisories": [
+      {
+        "vendor": "Linux kernel",
+        "id": "67ba971ae025",
+        "url": "https://github.com/gregkh/linux/commit/67ba971ae02514d85818fe0c32549ab4bfa3bf49",
+        "published": "2026-06-01"
+      },
+      {
+        "vendor": "Red Hat",
+        "id": "CVE-2026-53266",
+        "url": "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-53266.json",
+        "published": "2026-06-01"
+      },
+      {
+        "vendor": "Red Hat",
+        "id": "RHSA-2026:36645",
+        "url": "https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_36645.json",
+        "published": "2026-07-08"
+      },
+      {
+        "vendor": "Red Hat",
+        "id": "RHSA-2026:70797",
+        "url": "https://access.redhat.com/errata/RHSA-2026:70797",
+        "published": "2026-09-23"
+      },
+      {
+        "vendor": "Canonical",
+        "id": "CVE-2026-53266",
+        "url": "https://ubuntu.com/security/CVE-2026-53266",
+        "published": "2026-06-25"
+      }
+    ],
+    "verification_sources": [
+      "https://nvd.nist.gov/vuln/detail/CVE-2026-53266",
+      "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
+    ],
+    "source_verified": "2026-09-23",
+    "last_updated": "2026-09-23",
+    "_kev_short_description": "Linux Kernel contains an out-of-bounds write vulnerability in the ebtables SNAT target which allows an ARP sender hardware address rewrite to write directly into a nonlinear socket-buffer fragment backed by a splice-imported file page. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.",
+    "type": "splice-file-page-write-kernel-lpe",
+    "blast_radius": 26,
+    "poc_available": false,
+    "poc_description": "No public exploit code was found. The NVD record carries no reference tagged Exploit: its eight kernel.org references are tagged Patch and the ninth is the CISA KEV listing. CISA's 18 September 2026 alert, the CVE record, Red Hat's security data and the Ubuntu, SUSE and Debian CVE pages do not point to exploit code, and searches for an Exploit-DB, Metasploit or nuclei listing for this CVE returned none. The public technical material is the fix commit, whose message describes the flaw and whose three-line diff adds a writability check, and the kernel CNA's scoring rationale, which describes the conditions for reaching the write; neither contains a reproducer. Since the KEV listing, Red Hat marks the CVE as having a known exploit. Its VEX file at https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53266.json gives the basis as an exploit_status entry that cites the CISA KEV catalog, and names no repository, Exploit-DB id, Metasploit module or nuclei template, so the mark is a vendor statement of exploitation rather than published exploit code.",
+    "iocs": {
+      "behavioral": [
+        "A non-root account creating a user and network namespace, a bridge device inside it and ebtables nat-table rules with the snat target, for example through unshare or a rootless container runtime.",
+        "A container or service that holds CAP_NET_ADMIN in its own network namespace, for example a privileged container or one started with the NET_ADMIN capability, creating a bridge device and ebtables nat-table rules with the snat target inside that namespace. This path does not create a user namespace, so a watch on user namespace creation does not record it.",
+        "A local process moving pages of a file it cannot write, such as a setuid-root binary or a file under /etc, into a pipe or socket with splice(), vmsplice() or sendfile() on a host where ebtables nat rules with the ARP rewrite option are loaded in any network namespace.",
+        "A process running as root whose parent chain leads back to an unprivileged login or service account with no sudo, su or polkit authorization event in between."
+      ],
+      "network": [],
+      "host": [
+        "A running kernel (uname -r) on an affected upstream line below its fixed release: 5.10.x below 5.10.259, 5.15.x below 5.15.210, 6.1.x below 6.1.176, 6.6.x below 6.6.143, 6.12.x below 6.12.94, 6.18.x below 6.18.36, 7.0.x below 7.0.13, or a 7.1 release candidate from rc1 to rc6. Kernels on the other lines from 5.11 through 6.19, which have no fixed release listed, are affected at every version, and 5.4.73 and later, 5.8.17 and later and 5.9.2 and later kernels are affected with no fixed release listed on those lines.",
+        "A distribution kernel package below its fixed build: RHEL 9 kernel, or RHEL 9 Real Time or Real Time for NFV kernel-rt, below 5.14.0-687.23.1.el9_8; RHEL 8.10 kernel below 4.18.0-553.143.1.el8_10 or kernel-rt below 4.18.0-553.143.1.rt7.484.el8_10; RHEL 8.6 Advanced Mission Critical Update Support or 8.6 Extended Update Support Long-Life kernel below 4.18.0-372.217.1.el8_6; SLES 15 SP7 or SLES for SAP Applications 15 SP7 kernel-default below 6.4.0-150700.53.66.1; SLE Real Time 15 SP7 kernel-rt below 6.4.0-150700.7.62.1; SLES 16.0, openSUSE Leap 16.0 or SUSE Linux Micro 6.2 kernel-default below 6.12.0-160000.36.1; SUSE Linux Micro 6.0 or 6.1 kernel-default below 6.4.0-49.1; SUSE Liberty Linux 8 kernel below 4.18.0-553.143.1.el8_10 or SUSE Liberty Linux 9 kernel below 5.14.0-687.23.1.el9_8; Debian bullseye linux below 5.10.259-1 or linux-6.1 below 6.1.176-1~deb11u1 (bullseye reached the end of Debian Long Term Support on 31 August 2026), bookworm linux below 6.1.176-1, or trixie linux below 6.12.94-1; Ubuntu 26.04 linux below 7.0.0-31.31, or a 26.04 flavor kernel below its own fixed build (for example linux-aws below 7.0.0-1012.12, linux-azure below 7.0.0-1014.14 or linux-gcp below 7.0.0-1011.11); or Ubuntu 24.04 linux-hwe-7.0 below 7.0.0-31.31~24.04.1. Compare each Ubuntu flavor kernel against its own row on Ubuntu's page. Most 26.04 flavor builds carry ABI numbers of 1006 or higher (linux-gke 7.0.0-1006.7 through linux-nvidia-bos 7.0.0-2018.18), which sort above 31, so a check against the linux package boundary 7.0.0-31.31 can mark an unfixed flavor kernel as fixed. Kernels listed as affected with no fixed package: RHEL 10 and RHEL for NVIDIA 26; the RHEL 7 kernel and kernel-rt and the RHEL 6 kernel, which Red Hat's VEX file lists as affected with no fix while Red Hat's CVE data lists them as not affected; SLES 15 SP4, SP5 and SP6 LTSS, SLES for SAP Applications 15 SP4, SP5 and SP6, SLE HPC 15 SP4 and SP5 LTSS, and SLE Micro 5.3, 5.4 and 5.5; SUSE Manager Server, Proxy and Retail Branch Server 4.3 and LTS 4.3, SLE Real Time 15 SP4 and SP5, SLE Desktop 15 SP4 to SP6 and openSUSE Leap 15.4 to 15.6, which SUSE groups with products past their end of life; the Ubuntu 26.04 linux-azure-fde kernel; the Ubuntu 24.04 linux package and the other 24.04 kernel flavors Ubuntu lists as vulnerable; the Ubuntu 22.04 and 20.04 kernels; and the Ubuntu 18.04 5.4-based kernels (linux-hwe-5.4, linux-aws-5.4, linux-azure-5.4, linux-gcp-5.4, linux-ibm-5.4, linux-oracle-5.4 and linux-raspi-5.4).",
+        "A rule in the nat table that uses the snat target with the --snat-arp option, found by running both ebtables-legacy -t nat -L and ebtables-nft -t nat -L in the initial network namespace and in every other network namespace on the host. ebtables-nft adds and lists rules through the nf_tables kernel subsystem, while ebtables-legacy uses the legacy get/setsockopt interface, so a listing with one tool does not show a rule loaded through the other interface; where only one tool is installed, rules held by the other interface are not listed. Read every chain the nat table listing prints, including user-defined chains that POSTROUTING jumps to, not only POSTROUTING itself. List the namespaces with lsns -t net and run both listings inside each one, for example with nsenter --net=/proc/<pid>/ns/net ebtables-legacy -t nat -L. Red Hat's mitigation is to disable this ARP hardware address rewriting or remove such rules, so each hit marks a namespace where the vulnerable path is configured. A listing in the initial namespace alone does not show a rule created inside an unprivileged user's own network namespace or inside a container's network namespace, and a namespace that has already exited leaves no rule to list.",
+        "The ebt_snat module listed by lsmod on a host whose administrators have configured no ebtables NAT rules, which can mean that a rule was created inside another network namespace or through the ebtables interface the administrators do not use.",
+        "Kernel log entries (dmesg or journalctl -k) with an oops, warning or stack trace that names ebt_snat_tg or skb_store_bits.",
+        "Package verification (rpm -Va or debsums) reporting a changed checksum on a setuid binary or a file under /etc that no administrator changed. These tools read files through the page cache, so they detect a change held only in memory while the modified page stays cached."
+      ],
+      "_ioc_source_note": "The upstream kernel version boundaries come from the NVD record for CVE-2026-53266. The distribution package boundaries come from Red Hat's security data at https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-53266.json, Red Hat's advisory data for RHSA-2026:36645 at https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_36645.json (the RHEL 9 Real Time and Real Time for NFV kernel-rt builds) and its VEX file at https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53266.json, Ubuntu's page at https://ubuntu.com/security/CVE-2026-53266 (including the per-flavor 26.04 builds and the 26.04 linux-azure-fde status), SUSE's page at https://www.suse.com/security/cve/CVE-2026-53266.html and Debian's tracker at https://security-tracker.debian.org/tracker/CVE-2026-53266. The end of Debian 11 bullseye Long Term Support on 31 August 2026 comes from Debian's release page at https://www.debian.org/releases/bullseye/. The RHEL 6 and RHEL 7 status comes from both Red Hat sources, which disagree: as of 23 September 2026 the VEX file lists the RHEL 6 kernel and the RHEL 7 kernel and kernel-rt as affected with no fix, and the security data lists them as not affected. The ebtables rule indicator is built from Red Hat's mitigation text and from two man pages. The ebtables man page at https://manpages.debian.org/bookworm/ebtables/ebtables-legacy.8.en.html documents that the snat target can only be used in the POSTROUTING chain of the nat table, that --snat-arp also changes the hardware source address inside the ARP header, and that a rule can jump to a user-defined chain. The xtables-nft man page at https://manpages.debian.org/bookworm/iptables/xtables-nft.8.en.html states that ebtables-nft adds and lists rules through the nf_tables kernel subsystem and contrasts that with the legacy get/setsockopt interface, so one tool's listing does not show rules loaded through the other interface. The rule indicator covers every network namespace for two reasons. The kernel CNA's scoring rationale in the CVE record at https://cveawg.mitre.org/api/cve/CVE-2026-53266 states that the rule path is reachable with namespace-local privileges through user and network namespaces. The kernel's ebtables rule-set handler in net/bridge/netfilter/ebtables.c, at https://raw.githubusercontent.com/gregkh/linux/master/net/bridge/netfilter/ebtables.c, checks CAP_NET_ADMIN against the user namespace that owns the network namespace, so a container or service granted CAP_NET_ADMIN in its own network namespace passes the same check. A listing in the initial namespace alone does not show a rule created inside another namespace. The function names ebt_snat_tg and skb_store_bits and the file net/bridge/netfilter/ebt_snat.c come from the fix commit at https://github.com/gregkh/linux/commit/67ba971ae02514d85818fe0c32549ab4bfa3bf49. The following items are general hunting heuristics rather than artifacts read from a source: all four behavioral items, the ebtables rule item (its two-tool, all-chain and per-namespace enumeration with lsns and nsenter), the loaded ebt_snat module item, the kernel log item and the package-verification item. The network group is empty because the flaw is local and no source consulted documents a network artifact for it. No published Sigma, nuclei, Elastic, Splunk or Microsoft detection rule for this CVE was found. No actor infrastructure, file hash or C2 address is listed, because no source consulted attributes this CVE to a named campaign or operator."
+    },
+    "ai_discovered": false,
+    "ai_discovery_notes": "The fix commit names Yiming Qian as reporter and author, with sign-offs from Florian Westphal and Pablo Neira Ayuso, who committed it. No source consulted says AI tooling was used to find the flaw.",
+    "ai_discovery_source": "human_researcher",
+    "discovery_attribution_note": "Sourced from NVD CVE-2026-53266 (CWE-787, CVSS 8.8) plus the CISA KEV entry (added 2026-09-18) and the upstream Linux fix commit 67ba971ae025, \"netfilter: bridge: make ebt_snat ARP rewrite writable\", which names Yiming Qian as reporter and author, with the kernel CNA's scoring rationale from the CVE record and distribution fix status from Red Hat, SUSE, Debian and Ubuntu.",
+    "ai_assisted_weaponization": false,
+    "active_exploitation_notes": "CISA added CVE-2026-53266 to the KEV catalog on 2026-09-18 together with the Linux kernel race condition CVE-2025-39964, stating that the two were added based on evidence of active exploitation, and set a due date of 2026-09-21. KEV records known ransomware campaign use as Unknown, marks forensic triage as required, and its required action directs agencies to CISA's BOD 26-04 and its Forensics Triage Requirements. The CISA coordinator SSVC entry in the NVD record marks exploitation as active, automatable as no and technical impact as total. None of the sources consulted names a campaign, actor or incident report for this CVE.",
+    "attack_refs": [
+      "T1068"
+    ],
+    "atlas_refs": [],
+    "framework_control_gaps": {
+      "NIST-800-53-SI-2": "SI-2 requires flaws to be identified, reported and corrected, and security-relevant updates installed within organization-defined time periods. For this flaw the start of that period differs by distribution and by kernel package. The upstream fix was committed on 2026-06-01 and Red Hat shipped fixed RHEL 9 and RHEL 8.10 kernels in July 2026 and a fixed RHEL 8.6 Advanced Mission Critical Update Support and 8.6 Extended Update Support Long-Life kernel (RHSA-2026:70797) on 23 September 2026, after the 21 September KEV due date, but as of 22 September 2026 Ubuntu listed its 26.04 linux-azure-fde kernel, its 24.04 linux package, its 22.04 and 20.04 kernels and its 18.04 5.4-based kernels as vulnerable with no fixed package, Red Hat's data lists RHEL 10 and RHEL for NVIDIA 26 as affected with no fix, and SUSE lists SLES 15 SP4, SP5 and SP6 LTSS, SLES for SAP Applications 15 SP4 to SP6, SLE HPC 15 SP4 and SP5 LTSS and SLE Micro 5.3 to 5.5 as affected with no fix, together with SUSE Manager 4.3 and LTS 4.3, SLE Real Time 15 SP4 and SP5, SLE Desktop 15 SP4 to SP6 and openSUSE Leap 15.4 to 15.6, which it groups with products past their end of life. A period measured from vendor release has not started for those packages, and NVD lists no fixed release at all for the 5.4, 5.8 and 5.9 upstream lines, so an SI-2 report shows nothing overdue on the hosts that remain exposed after the KEV listing. For RHEL 6 and 7 the identification step depends on which Red Hat source is read: as of 23 September 2026 Red Hat's VEX file lists the RHEL 6 kernel and the RHEL 7 kernel and kernel-rt as affected with no fix, while its CVE data lists them as not affected, so a flaw report built from the CVE data does not list those hosts at all. On Ubuntu 24.04 the fixed build ships in a different kernel series, linux-hwe-7.0, so a report that tracks the installed package does not show that changing kernels would close the flaw.",
+      "NIST-800-53-CM-7": "CM-7 requires a system to provide only essential capabilities and to prohibit or restrict functions and services that are not needed. The vulnerable code is the optional ARP rewrite in the ebtables snat target (net/bridge/netfilter/ebt_snat.c). Red Hat describes the bridge netfilter rules it depends on as a specialized network configuration, but the kernel CNA states that the rule path is reachable with namespace-local privileges through user and network namespaces, and the kernel's ebtables rule-set handler checks CAP_NET_ADMIN against the user namespace that owns the network namespace. Exposure therefore also depends on whether unprivileged users can create those namespaces, on which containers and services hold CAP_NET_ADMIN in their own network namespaces and on whether the snat target can be loaded, not only on the rules the administrator wrote. CM-7 reviews are usually written against listening ports and installed services, so a loadable bridge netfilter target, unprivileged user namespace creation and a container's CAP_NET_ADMIN grant are not enumerated on a general-purpose host, and a port-and-service review does not prompt removing the --snat-arp option from ebtables SNAT rules (Red Hat's mitigation), blocking the ebt_snat module, restricting user namespaces where no workload uses them or removing CAP_NET_ADMIN from containers that do not need it.",
+      "NIST-800-53-SI-4": "SI-4 requires monitoring the system to detect attacks and indicators of potential attacks. In this flaw the kernel's bridge netfilter code copies the six-byte MAC address from the ebtables rule into a socket-buffer fragment backed by a file page imported with splice(). Because the kernel makes that copy itself rather than through a write() call on the file, monitoring built on file write events records no event for the change. A scheduled hash scan that reads files through the page cache, such as package verification, can detect the altered page while it stays cached, but the change itself does not trigger a scan, and no source publishes a detection rule for this CVE.",
+      "NIS2-Art21-patch-management": "Article 21(2)(e) requires essential and important entities to take measures for security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. It sets no timeframe, so an entity can show a documented handling process while its RHEL 10, SLES 15 SP4 to SP6 LTSS, SLE Micro 5.3 to 5.5, SUSE Manager 4.3 and LTS 4.3 and Ubuntu 22.04 hosts, its Ubuntu 24.04 hosts on the linux package, and its RHEL 7 hosts, which Red Hat's VEX file lists as affected with no fix, run kernels with no fixed package. For entities within the scope of Commission Implementing Regulation (EU) 2024/2690, Annex point 6.6.1 requires security patches to be applied within a reasonable time after they become available, and additional measures, with the residual risk accepted, where a patch is not available, but it does not say which measures. Red Hat's published step for this flaw, disabling ARP hardware address rewriting in ebtables SNAT rules, covers only rules the administrator configured. The kernel CNA states that the rule path is reachable through user and network namespaces, and a container or service granted CAP_NET_ADMIN in its own network namespace passes the same capability check in the kernel's ebtables handler, so on those hosts exposure also depends on keeping the ebt_snat module from loading. Restricting unprivileged user namespaces closes only the first of those paths and removing unneeded CAP_NET_ADMIN grants closes only the second, so neither replaces the module block. An entity can therefore meet the requirement with Red Hat's ebtables rule change alone while the namespace paths stay open, because nothing in it calls for blocking the ebt_snat module.",
+      "UK-CAF-B4": "Principle B4 expects systems supporting essential functions to be securely configured and their vulnerabilities managed. Red Hat states that this flaw requires specific bridge netfilter rules to be configured, and the kernel CNA states that the rule path, which needs CAP_NET_ADMIN, is reachable with namespace-local privileges through user and network namespaces rather than requiring init-namespace root. The kernel's ebtables rule-set handler checks that capability against the user namespace that owns the network namespace, so a container or service granted CAP_NET_ADMIN in its own network namespace also reaches the rule path. A host's exposure therefore depends on its kernel version, on the ebtables nat rules in each of its network namespaces, on whether unprivileged users can create user and network namespaces and on which containers or services hold CAP_NET_ADMIN. A B4 assessment that matches kernel versions against advisories marks Ubuntu 22.04 hosts and Ubuntu 24.04 hosts on the linux package as vulnerable with no fix, without noting that 24.04 hosts can move to the fixed linux-hwe-7.0 kernel, and names no interim posture for the hosts that have no fixed package. It does not check for rules using the snat target with --snat-arp, which Red Hat's mitigation removes. It does not prompt blocking the ebt_snat module, which covers both namespace paths, or restricting unprivileged user namespaces and removing unneeded container CAP_NET_ADMIN grants, which each close one of them.",
+      "AU-Essential-8-Patch": "The Essential Eight patch operating systems control covers the Linux kernel. Its ISM controls apply to patches, updates or other vendor mitigations, so each window starts when the vendor publishes a fix or a mitigation, whichever comes first. At every maturity level, operating systems of internet-facing servers are patched within 48 hours of release when the vendor rates a flaw critical or a working exploit exists (ISM-1877), and within two weeks when the vendor rates it non-critical and no working exploit exists (ISM-1694). Workstations and non-internet-facing servers are patched within one month at Maturity Levels One and Two (ISM-1695); at Maturity Level Three, within 48 hours when the vendor rates the flaw critical or a working exploit exists (ISM-1696), and within one month when the vendor rates it non-critical and no working exploit exists (ISM-1902). Before the KEV listing an operator saw only non-critical vendor ratings (Red Hat Important, SUSE moderate) and no public exploit, so the slower windows applied; on RHEL 9 and RHEL 8.10, where Red Hat released fixed kernels on 8 and 14 July 2026, those windows closed before the listing. On RHEL 8.6 Advanced Mission Critical Update Support and 8.6 Extended Update Support Long-Life, Red Hat released the fixed kernel 4.18.0-372.217.1.el8_6 (RHSA-2026:70797) on 23 September 2026, after the KEV listing, so a working exploit already existed when the window opened: internet-facing servers have 48 hours at every maturity level (ISM-1877), and other servers have one month at Maturity Levels One and Two (ISM-1695) and 48 hours at Maturity Level Three (ISM-1696). The KEV listing on 2026-09-18 means a working exploit exists. RHEL 10 and RHEL for NVIDIA 26 have no fixed kernel, but Red Hat has published a mitigation for them (disable ARP hardware address rewriting in ebtables SNAT rules, or remove ebtables SNAT rules that operate on ARP traffic on bridge interfaces), so the window for applying it is running. As of 23 September 2026 Red Hat's VEX file also lists the RHEL 6 kernel and the RHEL 7 kernel and kernel-rt as affected with no fix and applies the same mitigation to them, so the window for applying it is running there too; Red Hat's CVE data lists those kernels as not affected, and an operator who reads only that source starts no window for them. Meeting that window leaves the namespace paths open: the mitigation covers only rules the administrator configured, the kernel CNA states that the rule path is reachable with namespace-local privileges through user and network namespaces, a container or service granted CAP_NET_ADMIN in its own network namespace passes the same capability check in the kernel's ebtables handler, and the control does not require steps the vendor did not publish, such as keeping the ebt_snat module from loading. As of 22 September 2026 Ubuntu listed its 26.04 linux-azure-fde kernel, its 24.04 linux package, its 22.04 and 20.04 kernels and its 18.04 5.4-based kernels as vulnerable with no fixed package. SUSE lists SLES 15 SP4, SP5 and SP6 LTSS, SLES for SAP Applications 15 SP4 to SP6, SLE HPC 15 SP4 and SP5 LTSS and SLE Micro 5.3 to 5.5 as affected with no fix. Neither vendor's CVE page gives a mitigation, so no window has started for those kernels; an Ubuntu 24.04 host can instead move to the fixed linux-hwe-7.0 kernel. Upstream 5.4.73 and later, 5.8.17 and later and 5.9.2 and later kernels have no fixed release listed; where such a kernel line is no longer supported, ISM-1501 requires the operating system to be replaced at every maturity level. The same requirement applies to hosts on SUSE Manager 4.3 and LTS 4.3, SLE Real Time 15 SP4 and SP5, SLE Desktop 15 SP4 to SP6 and openSUSE Leap 15.4 to 15.6, which SUSE lists as affected with no fix and groups with products past their end of life, and to Debian 11 bullseye hosts without paid third-party support: bullseye has fixed kernels (DLA-4664-1 and DLA-4671-1) but reached the end of Debian Long Term Support on 31 August 2026.",
+      "ISO-27001-2022-A.8.8": "A.8.8 requires information about technical vulnerabilities to be obtained, the organization's exposure evaluated and appropriate measures taken. Exposure evaluation for this CVE depends on inputs a typical vulnerability register does not hold. The published scores disagree: the kernel CNA gives 8.8 with a local vector, Red Hat gives 7.5 with a network vector and high complexity, and SUSE gives 6.8 with an adjacent-network vector. Red Hat's own sources also disagree on scope: its CVE data lists the RHEL 6 kernel and the RHEL 7 kernel and kernel-rt as not affected, while its VEX file, as of 23 September 2026, lists them as affected with no fix, so the register's answer for those hosts depends on which feed it reads. Red Hat states that the flaw requires specific bridge netfilter rules, while the kernel CNA states that the rule path is reachable with namespace-local privileges through user and network namespaces, and the kernel's ebtables handler also accepts CAP_NET_ADMIN held by a container in its own network namespace. A register that records kernel package versions can match the fixed builds (RHEL 9 5.14.0-687.23.1.el9_8, SLES 15 SP7 6.4.0-150700.53.66.1, Debian bookworm 6.1.176-1, Ubuntu 26.04 7.0.0-31.31) but cannot show whether a host carries an ebtables nat rule with ARP rewrite, allows unprivileged user namespaces or runs containers granted CAP_NET_ADMIN, and each of these affects exposure."
+    },
+    "patch_available": true,
+    "patch_required_reboot": true,
+    "live_patch_available": false,
+    "live_patch_tools": [],
+    "live_patch_notes": "None of the vendor pages consulted (Red Hat, Ubuntu, SUSE, Debian) lists a live patch package for this fix. SUSE's page lists kernel-default for its Live Patching 15 SP7 product as released but names no kernel-livepatch package for this CVE. A fixed kernel therefore takes effect only after the host reboots into it. The steps that apply without a reboot are interim. Red Hat's configuration mitigation (disable ARP hardware address rewriting in ebtables SNAT rules, or remove ebtables SNAT rules that operate on ARP traffic on bridge interfaces) covers only rules the administrator configures: the kernel CNA states that the rule path is reachable with namespace-local privileges through user and network namespaces, and a container or service granted CAP_NET_ADMIN in its own network namespace passes the same capability check in the kernel's ebtables handler. Blocking the ebt_snat module from loading is a general hardening step that applies to both paths; restricting user namespaces applies only to the first, and removing CAP_NET_ADMIN from containers that do not need it applies only to the second. NVD lists upstream 5.4.73 and later, 5.8.17 and later and 5.9.2 and later kernels as affected with no fixed release on those lines, Ubuntu 25.10 is end of life and was not fixed, SUSE groups the affected SUSE Manager 4.3 and LTS 4.3, SLE Real Time 15 SP4 and SP5, SLE Desktop 15 SP4 to SP6 and openSUSE Leap 15.4 to 15.6 products with products past their end of life, and CISA notes that the affected products could be end of life and advises moving to a supported version. Debian 11 bullseye has fixed kernels (DLA-4664-1 and DLA-4671-1) but reached the end of Debian Long Term Support on 31 August 2026 and receives no further Debian security updates.",
+    "affected": "The Linux kernel's bridge netfilter ebtables SNAT target (net/bridge/netfilter/ebt_snat.c). When an ebtables nat rule uses the snat target with the ARP rewrite option, the target writes the rule's MAC address over the ARP sender hardware address without first making that range of the socket buffer writable. If the range sits in a socket-buffer fragment backed by a file page imported with splice(), the six bytes are written into that file page. Red Hat rates the result as possible memory corruption, denial of service or local privilege escalation, and states that the flaw requires specific bridge netfilter rules to be configured. The kernel CNA states that the rule path requires CAP_NET_ADMIN but is reachable with namespace-local privileges through user and network namespaces, so a local user who can create those namespaces can set up the bridge and rule without init-namespace root. The kernel's ebtables rule-set handler checks CAP_NET_ADMIN against the user namespace that owns the network namespace, so a container or service granted CAP_NET_ADMIN in its own network namespace passes the same check without creating a user namespace. Distribution kernels are affected as well: RHEL 8, 9 and 10 and RHEL for NVIDIA 26; SLES and SLES for SAP Applications 15 SP4 through SP7, SLE HPC 15 SP4 and SP5 LTSS, SLE Real Time 15 SP7, SLES 16.0 and 16.1, openSUSE Leap 16.0, SUSE Liberty Linux 8 and 9, SLE Micro 5.3 through 5.5 and SUSE Linux Micro 6.0 through 6.2; Debian bullseye, bookworm and trixie; and Ubuntu 18.04 through 26.04. SUSE also lists SUSE Manager Server, Proxy and Retail Branch Server 4.3 and LTS 4.3, SLE Real Time 15 SP4 and SP5, SLE Desktop 15 SP4 through SP6 and openSUSE Leap 15.4 through 15.6 as affected with no fix, and its CVE page groups these with products past their end of life and not receiving proactive updates. Red Hat's two data sources disagree on RHEL 6 and 7: its CVE data lists the RHEL 6 kernel and the RHEL 7 kernel and kernel-rt as not affected, while its VEX file, as of 23 September 2026, lists the same kernels as affected with no fix available and applies its ebtables workaround to them. SUSE lists SLES 12 SP5 as not affected. Ubuntu lists the linux package on 18.04, 16.04 and 14.04 as not affected, but lists the 18.04 5.4-based HWE and cloud kernels (linux-hwe-5.4, linux-aws-5.4, linux-azure-5.4, linux-gcp-5.4, linux-ibm-5.4, linux-oracle-5.4 and linux-raspi-5.4) as vulnerable with no fix.",
+    "affected_versions": [
+      "Linux 5.4.73 and later 5.4.x (NVD lists no fixed release on this line)",
+      "Linux 5.8.17 and later 5.8.x, and 5.9.2 and later 5.9.x (no fixed release listed on either line)",
+      "Linux 5.10.x before 5.10.259 (5.10.259 is fixed)",
+      "Linux 5.11 up to but not including 5.15.210 (5.15.210 is fixed)",
+      "Linux 5.16 up to but not including 6.1.176 (6.1.176 is fixed)",
+      "Linux 6.2 up to but not including 6.6.143 (6.6.143 is fixed)",
+      "Linux 6.7 up to but not including 6.12.94 (6.12.94 is fixed)",
+      "Linux 6.13 up to but not including 6.18.36 (6.18.36 is fixed)",
+      "Linux 6.19 up to but not including 7.0.13 (7.0.13 is fixed)",
+      "Linux 7.1-rc1 through 7.1-rc6 (the 7.1 release is fixed)",
+      "Red Hat Enterprise Linux 9 kernel before 5.14.0-687.23.1.el9_8, and RHEL 9 Real Time and Real Time for NFV kernel-rt before 5.14.0-687.23.1.el9_8 (both fixed by RHSA-2026:36645). Red Hat's CVE data also lists a RHEL 9 kernel-rt source package as affected with no fix; RHSA-2026:36645 builds its fixed kernel-rt packages from the main kernel source package.",
+      "Red Hat Enterprise Linux 8.10 kernel before 4.18.0-553.143.1.el8_10 (fixed by RHSA-2026:39083) and kernel-rt before 4.18.0-553.143.1.rt7.484.el8_10 (fixed by RHSA-2026:39082)",
+      "Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support and 8.6 Extended Update Support Long-Life Add-On kernel before 4.18.0-372.217.1.el8_6 (fixed by RHSA-2026:70797, issued 2026-09-23)",
+      "Red Hat Enterprise Linux 10 kernel and Red Hat Enterprise Linux for NVIDIA 26 kernel: listed as affected with no fix; Red Hat's ebtables configuration mitigation applies to both",
+      "Red Hat Enterprise Linux 7 kernel and kernel-rt, and Red Hat Enterprise Linux 6 kernel: as of 23 September 2026 Red Hat's VEX file lists them as affected with no fix available and applies its ebtables configuration mitigation to them, while Red Hat's CVE data lists them as not affected",
+      "SUSE Linux Enterprise Server 15 SP7 and SLES for SAP Applications 15 SP7 kernel-default before 6.4.0-150700.53.66.1, and SLE Real Time 15 SP7 kernel-rt before 6.4.0-150700.7.62.1; the SLES 15 SP4, SP5 and SP6 LTSS, SLES for SAP Applications 15 SP4 to SP6 and SLE HPC 15 SP4 and SP5 LTSS kernels are listed as affected with no fix",
+      "SUSE Linux Enterprise Server 16.0, openSUSE Leap 16.0 and SUSE Linux Micro 6.2 kernel-default before 6.12.0-160000.36.1; SUSE lists the SLES 16.1 kernel-default as released without giving a version on its CVE page",
+      "SUSE Linux Micro 6.0 and 6.1 kernel-default before 6.4.0-49.1; SLE Micro 5.3, 5.4 and 5.5 kernels are listed as affected with no fix",
+      "SUSE Liberty Linux 8 kernel before 4.18.0-553.143.1.el8_10 (RHSA-2026:39083) and SUSE Liberty Linux 9 kernel before 5.14.0-687.23.1.el9_8 (RHSA-2026:36645), the same builds that fix RHEL 8.10 and RHEL 9",
+      "SUSE Manager Server, Proxy and Retail Branch Server 4.3 and LTS 4.3, SLE Real Time 15 SP4 and SP5, SLE Desktop 15 SP4 to SP6 and openSUSE Leap 15.4 to 15.6 kernels: listed as affected with no fix, in the group SUSE's CVE page describes as products past their end of life and not receiving proactive updates. The same page lists further affected modules and editions of the 15 SP4 to SP6 service packs.",
+      "Debian bullseye linux before 5.10.259-1 (DLA-4664-1) and linux-6.1 before 6.1.176-1~deb11u1 (DLA-4671-1); bookworm linux before 6.1.176-1 (DLA-4665-1); trixie linux before 6.12.94-1. Debian 11 bullseye reached the end of Debian Long Term Support on 31 August 2026, so DLA-4664-1 and DLA-4671-1 close this CVE, but bullseye receives no further Debian security updates.",
+      "Ubuntu 26.04 LTS linux before 7.0.0-31.31. The 26.04 kernel flavors are fixed at their own builds: linux-aws 7.0.0-1012.12, linux-azure 7.0.0-1014.14, linux-gcp 7.0.0-1011.11, linux-gke 7.0.0-1006.7, linux-ibm 7.0.0-1013.13, linux-nvidia 7.0.0-1018.18, linux-nvidia-bos 7.0.0-2018.18, linux-oem-7.0 7.0.0-1013.13, linux-oracle 7.0.0-1011.11, linux-raspi 7.0.0-1019.19, linux-realtime 7.0.0-31.31.1 and linux-riscv 7.0.0-31.31.1. The 26.04 linux-azure-fde kernel is vulnerable with no fix as of 22 September 2026. Ubuntu 25.10 is end of life and was not fixed.",
+      "Ubuntu 24.04 LTS linux package vulnerable with a fix in progress as of 22 September 2026, as are the other 24.04 kernel flavors Ubuntu lists as vulnerable; on 24.04 Ubuntu has fixed linux-hwe-7.0 in 7.0.0-31.31~24.04.1, linux-aws-7.0 in 7.0.0-1012.12~24.04.1, linux-azure-7.0 in 7.0.0-1014.14~24.04.1, linux-gcp-7.0 in 7.0.0-1011.11~24.04.1, linux-nvidia-7.0 in 7.0.0-1018.18~24.04.1, linux-riscv-7.0 in 7.0.0-31.31.1~24.04.1 and linux-nvidia-tegra in 6.8.0-1035.38",
+      "Ubuntu 22.04 LTS and 20.04 LTS kernels, and the Ubuntu 18.04 LTS 5.4-based kernels (linux-hwe-5.4, linux-aws-5.4, linux-azure-5.4, linux-gcp-5.4, linux-ibm-5.4, linux-oracle-5.4 and linux-raspi-5.4), vulnerable with no fix as of 22 September 2026; the 18.04 linux package is listed as not affected"
+    ],
+    "vendor_update_paths": [
+      "Upgrade to a kernel that contains the upstream fix, commit 67ba971ae025 (\"netfilter: bridge: make ebt_snat ARP rewrite writable\"): 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36, 7.0.13 or 7.1, then reboot into it.",
+      "On Red Hat Enterprise Linux 9, install kernel 5.14.0-687.23.1.el9_8 (RHSA-2026:36645); on RHEL 9 for Real Time or Real Time for NFV, install kernel-rt 5.14.0-687.23.1.el9_8 from the same advisory; on RHEL 8.10, install kernel 4.18.0-553.143.1.el8_10 (RHSA-2026:39083) or kernel-rt 4.18.0-553.143.1.rt7.484.el8_10 (RHSA-2026:39082); on RHEL 8.6 Advanced Mission Critical Update Support or 8.6 Extended Update Support Long-Life Add-On, install kernel 4.18.0-372.217.1.el8_6 (RHSA-2026:70797). Reboot after installing; Red Hat states that the system must be rebooted for the update to take effect.",
+      "On SUSE Linux Enterprise Server 15 SP7 and SLES for SAP Applications 15 SP7, install kernel-default 6.4.0-150700.53.66.1 or later; on SLE Real Time 15 SP7, kernel-rt 6.4.0-150700.7.62.1 or later; on SLES 16.0, openSUSE Leap 16.0 and SUSE Linux Micro 6.2, kernel-default 6.12.0-160000.36.1 or later; on SUSE Linux Micro 6.0 and 6.1, kernel-default 6.4.0-49.1 or later; and on SUSE Liberty Linux 8 and 9, kernel 4.18.0-553.143.1.el8_10 (RHSA-2026:39083) or 5.14.0-687.23.1.el9_8 (RHSA-2026:36645) or later. SUSE lists the SLES 16.1 kernel-default as released without giving a version on its CVE page. Reboot after installing.",
+      "On Debian bullseye, install linux 5.10.259-1 (DLA-4664-1) or linux-6.1 6.1.176-1~deb11u1 (DLA-4671-1); on bookworm, linux 6.1.176-1 (DLA-4665-1); on trixie, linux 6.12.94-1. Reboot after installing. Debian 11 bullseye reached the end of Debian Long Term Support on 31 August 2026 and receives no further Debian security updates, so move bullseye hosts to bookworm or trixie.",
+      "On Ubuntu 26.04 LTS, install linux 7.0.0-31.31 or later, or on a flavor kernel its own fixed build or later (linux-aws 7.0.0-1012.12, linux-azure 7.0.0-1014.14, linux-gcp 7.0.0-1011.11, linux-gke 7.0.0-1006.7, linux-ibm 7.0.0-1013.13, linux-nvidia 7.0.0-1018.18, linux-nvidia-bos 7.0.0-2018.18, linux-oem-7.0 7.0.0-1013.13, linux-oracle 7.0.0-1011.11, linux-raspi 7.0.0-1019.19, or linux-realtime and linux-riscv 7.0.0-31.31.1), and reboot. The 26.04 linux-azure-fde kernel had no fix as of 22 September 2026. On Ubuntu 24.04 LTS the linux package had no fix as of that date; move to the HWE 7.0 kernel (linux-hwe-7.0 7.0.0-31.31~24.04.1 or later, or on cloud images linux-aws-7.0 7.0.0-1012.12~24.04.1, linux-azure-7.0 7.0.0-1014.14~24.04.1 or linux-gcp-7.0 7.0.0-1011.11~24.04.1), or on Tegra hosts install linux-nvidia-tegra 6.8.0-1035.38, and reboot. The Ubuntu 22.04 and 20.04 kernels and the 18.04 5.4-based kernels had no fixed package as of that date.",
+      "Where no fixed kernel is available (RHEL 10, RHEL for NVIDIA 26, the RHEL 7 kernel and kernel-rt and the RHEL 6 kernel that Red Hat's VEX file lists as affected with no fix, SLES 15 SP4 to SP6 LTSS, SLES for SAP Applications 15 SP4 to SP6, SLE HPC 15 SP4 and SP5 LTSS, SLE Micro 5.3 to 5.5, the end-of-life SUSE Manager 4.3 and LTS 4.3, SLE Real Time 15 SP4 and SP5, SLE Desktop 15 SP4 to SP6 and openSUSE Leap 15.4 to 15.6, the Ubuntu 26.04 linux-azure-fde kernel, Ubuntu 24.04 hosts that stay on the linux package or another unfixed flavor, and the Ubuntu 22.04, 20.04 and 18.04 5.4-based kernels), apply Red Hat's mitigation: disable ARP hardware address rewriting in ebtables SNAT rules (the --snat-arp option of the snat target), or remove ebtables SNAT rules that operate on ARP traffic on bridge interfaces. That change covers only rules the administrator configures. The kernel CNA states that the rule path is reachable with namespace-local privileges through user and network namespaces, and the kernel's ebtables rule-set handler checks CAP_NET_ADMIN against the user namespace that owns the network namespace, so a container or service granted CAP_NET_ADMIN in its own network namespace can also load such a rule. On hosts that do not use ebtables NAT, also add the line install ebt_snat /bin/false to a file under /etc/modprobe.d, so that modprobe runs that command instead of inserting the module, and unload the module with modprobe -r ebt_snat if it is loaded and unused. Where ebt_snat is built as a module, the block applies to both paths. In addition, where no workload on the host creates user namespaces, set the user.max_user_namespaces sysctl to 0, and remove CAP_NET_ADMIN from the containers and services that do not need it; the namespace limit does not affect a container or service that already holds CAP_NET_ADMIN. The rule change, the module block and the namespace limit take effect without a reboot, and namespaces that already exist are not removed. The module block, the namespace limit and the capability removal are general hardening steps, not vendor-published mitigations for this CVE.",
+      "Move hosts on upstream 5.4, 5.8 or 5.9 kernels to a supported kernel line that contains the fix, since NVD lists no fixed release on those lines. Move hosts on the SUSE products that SUSE groups as past their end of life to a supported SUSE release with a fixed kernel; for openSUSE Leap 15.4 to 15.6 that release is openSUSE Leap 16.0 with kernel-default 6.12.0-160000.36.1 or later."
+    ],
+    "_auto_imported": false,
+    "_intake_method": "batch-curated",
+    "rwep_factors": {
+      "cisa_kev": 25,
+      "poc_available": 0,
+      "ai_factor": 0,
+      "active_exploitation": 20,
+      "blast_radius": 26,
+      "patch_available": -15,
+      "live_patch_available": 0,
+      "reboot_required": 5
+    },
+    "rwep_score": 61,
+    "rwep_notes": "RWEP 61. cisa_kev +25, active_exploitation +20, blast_radius +26, patch_available -15, reboot_required +5. Σ factors === rwep_score."
+  },
+  "CVE-2025-39964": {
+    "name": "Linux Kernel Race Condition Vulnerability (CVE-2025-39964)",
+    "cvss_score": 5.5,
+    "cvss_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
+    "cwe_refs": [
+      "CWE-362"
+    ],
+    "cisa_kev": true,
+    "cisa_kev_date": "2026-09-18",
+    "cisa_kev_due_date": "2026-09-21",
+    "known_ransomware_use": false,
+    "active_exploitation": "confirmed",
+    "complexity": "low",
+    "vector": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Disallow concurrent writes in af_alg_sendmsg\n\nIssuing two writes to the same af_alg socket is bogus as the\ndata will be interleaved in an unpredictable fashion.  Furthermore,\nconcurrent writes may create inconsistencies in the internal\nsocket state.\n\nDisallow this by adding a new ctx->write field that indiciates\nexclusive ownership for writing.",
+    "epss_score": 0.0079,
+    "epss_percentile": 0.54744,
+    "epss_date": "2026-09-22",
+    "epss_source": "https://api.first.org/data/v1/epss?cve=CVE-2025-39964",
+    "vendor_advisories": [
+      {
+        "vendor": "Siemens",
+        "id": "SSA-019113",
+        "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html",
+        "published": "2026-07-14"
+      },
+      {
+        "vendor": "Google Cloud",
+        "id": "GCP-2026-003",
+        "url": "https://docs.cloud.google.com/kubernetes-engine/security-bulletins",
+        "published": "2026-01-09"
+      },
+      {
+        "vendor": "Red Hat",
+        "id": "CVE-2025-39964",
+        "url": "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-39964.json",
+        "published": "2025-10-13"
+      }
+    ],
+    "verification_sources": [
+      "https://nvd.nist.gov/vuln/detail/CVE-2025-39964",
+      "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
+    ],
+    "source_verified": "2026-09-23",
+    "last_updated": "2026-09-23",
+    "_kev_short_description": "Linux Kernel contains a race condition vulnerability which allows concurrent writes to the same AF_ALG socket causing data to be unpredictably interleaved and creating inconsistencies in the socket's internal state.",
+    "type": "race-condition-kernel-lpe",
+    "blast_radius": 26,
+    "poc_available": true,
+    "poc_description": "Google's kernelCTF repository publishes an exploit at https://github.com/google/security-research/tree/master/pocs/linux/kernelctf/CVE-2025-39964_lts_cos_mitigation (submissions exp413 and exp415), with separate exploit builds for the lts-6.12.44, mitigation-v4-6.6 and cos-121-18867.199.28 kernelCTF targets. Its metadata records a 99% success rate on each target with no separate KASLR leak, lists no required capabilities and names CONFIG_CRYPTO_USER_API as the only kernel configuration requirement. The kernelCTF vulnerability description in the same directory states that user namespaces are not required.",
+    "iocs": {
+      "behavioral": [
+        "An unprivileged process, or a process inside a container, creating an AF_ALG socket (address family 38) on a host whose baseline shows no such use. The kernelCTF submission needs only a kernel built with the AF_ALG user API, with no capabilities and no user namespace, so the process that opens the socket can be any local account or container workload. A rule that matches the socket() system call with domain 38 does not record a socket created through io_uring's IORING_OP_SOCKET operation, which kernels 5.19 and later provide. On those kernels, also alert on io_uring_setup() from processes that do not normally use io_uring, or place a kernel probe on alg_create, the AF_ALG family's create function, which runs for a socket created through either path.",
+        "Two tasks writing to the same AF_ALG socket at the same time, whether they are threads of one process or processes that share the descriptor after fork() or descriptor passing. The upstream fix sets one exclusive-write flag on the socket and rejects any second writer. Writes reach af_alg_sendmsg through sendmsg(), sendmmsg(), send(), sendto(), write() and writev(); through io_uring's IORING_OP_SENDMSG (from 5.3), IORING_OP_SEND and IORING_OP_WRITE (from 5.6) and IORING_OP_WRITEV operations; and, on kernels 6.5 and later, through splice(), sendfile() and IORING_OP_SPLICE into the socket. A system-call tracer such as auditd or Falco records the direct calls but not a write submitted through io_uring, for which it sees at most the io_uring system calls. A kernel probe on af_alg_sendmsg records writes from every one of these paths. A legitimate program that shares one AF_ALG socket between threads or processes produces the same pattern, so baseline the programs that do before alerting on it.",
+        "On a fixed kernel, writes to an AF_ALG socket failing with EBUSY. The fixed af_alg_sendmsg returns -EBUSY when another writer already holds the socket, so the error shows a second concurrent writer on that socket. A write submitted through io_uring reports the error in its completion entry rather than as a system-call return, so a system-call tracer does not record it. A legitimate program whose threads or processes share one AF_ALG socket gets the same error, so treat a burst of EBUSY failures as a lead to investigate alongside the other indicators.",
+        "A process whose effective UID changes to 0 without executing a setuid binary, su, sudo or pkexec, shortly after it opened AF_ALG sockets, or a container process reading host paths or node credentials outside its pod after the same activity."
+      ],
+      "network": [],
+      "host": [
+        "A running kernel (uname -r) inside one of the NVD affected ranges without a distribution backport of the fix: 2.6.38 up to but not including 5.10.245, 5.11 up to but not including 5.15.194, 5.16 up to but not including 6.1.154, 6.2 up to but not including 6.6.108, 6.7 up to but not including 6.12.49, 6.13 up to but not including 6.16.9, or 6.17-rc1 through 6.17-rc6. The kernel CVE record lists no fixed release for any line older than 5.10 or for the lines 5.11 to 5.14, 5.16 to 5.19, 6.0, 6.2 to 6.5, 6.7 to 6.11 and 6.13 to 6.15, so a kernel on one of those lines is affected unless its distribution backported the fix. Check the running kernel rather than the installed package, because the fix takes effect only after a reboot.",
+        "CONFIG_CRYPTO_USER_API enabled in the running kernel's configuration (/boot/config-$(uname -r) or /proc/config.gz). The kernelCTF metadata lists it as the only kernel configuration the exploit requires.",
+        "The af_alg module or algif_* modules loaded (lsmod) on a host that runs no software using the kernel crypto user API.",
+        "Kernel log entries (dmesg, journalctl -k) with a KASAN report, general protection fault or oops whose call trace names af_alg_sendmsg or another function from crypto/af_alg.c.",
+        "On Red Hat Enterprise Linux, a kernel package on RHEL 7, 8, 9 or 10, a kernel-rt package on RHEL 7 or 9, or the Red Hat Enterprise Linux for NVIDIA 26 kernel, all of which Red Hat's record lists as affected with no released fix, or a RHEL 8 kernel-rt package older than 4.18.0-553.166.1.rt7.507.el8_10, the build RHSA-2026:70403 ships.",
+        "GKE Container-Optimized OS or Ubuntu node pools below the patch versions in Google Cloud bulletin GCP-2026-003, or a GDC software for VMware, GKE on AWS or GKE on Azure cluster, for which the bulletin lists patch versions as in progress.",
+        "A Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP or SIPLUS S7-1500 CPU 1518-4 PN/DP MFP on firmware V3.1.6 or later, for which Siemens lists no fix.",
+        "A kernel.core_pattern value (sysctl kernel.core_pattern, /proc/sys/kernel/core_pattern) that the host's crash handler and configuration management did not set, especially a pipe to a program under /proc or to an executable outside the distribution's crash-handler path, and a root process started by the kernel's core-dump helper from an unexpected executable after another process crashed. The public kernelCTF exploit sources reference the kernel's core_pattern setting and /proc/self/exe. A change made through kernel memory does not pass through a write to /proc/sys/kernel/core_pattern, so compare the current value against the expected one rather than relying only on a file-write watch."
+      ],
+      "_ioc_source_note": "The AF_ALG socket-creation indicator follows the Falco rule at https://raw.githubusercontent.com/mc493/linux-kernel-zero-day-mitigation-zero-downtime-kernel-defense-/HEAD/helm/falco-rules-kernel-cve.yaml, whose condition is evt.type = socket and evt.rawarg.domain = 38. An independent repository publishes that rule, not a vendor, and it fires on every AF_ALG socket, including legitimate ones, so baseline which binaries open AF_ALG sockets before alerting on it. That rule matches only the socket() system call. The io_uring operations and the kernel versions that provide them come from the io_uring_enter(2) manual page at https://man7.org/linux/man-pages/man2/io_uring_enter.2.html, which also states that an operation's error is returned in its completion entry. The io_uring socket operation calls the same socket-creation function as socket() in the kernel source at https://raw.githubusercontent.com/torvalds/linux/v6.5/io_uring/net.c and https://raw.githubusercontent.com/torvalds/linux/v6.5/net/socket.c. Sysdig's analysis at https://www.sysdig.com/blog/detecting-and-mitigating-io-uring-abuse-for-malware-evasion states that operations issued through io_uring bypass the system calls that syscall-based security tools match, and that Falco can detect io_uring use through the io_uring_setup system call. The concurrent-write and EBUSY indicators are hunting heuristics derived from the upstream fix at https://github.com/torvalds/linux/commit/1b34cbbf4f011a121ef7b2d7d6e6920a036d5285, which adds an exclusive write flag and returns -EBUSY from af_alg_sendmsg when another writer holds the socket. The commit gives no detection guidance, and no source consulted describes EBUSY failures as an exploitation signal. The splice() and sendfile() path on 6.5 and later kernels comes from the kernel source at the v6.5 tag (https://raw.githubusercontent.com/torvalds/linux/v6.5/crypto/af_alg.c and https://raw.githubusercontent.com/torvalds/linux/v6.5/fs/splice.c), where af_alg_sendmsg handles MSG_SPLICE_PAGES and the socket splice path used by sendfile() sends spliced pages through sock_sendmsg, and from the v6.4 tag (https://raw.githubusercontent.com/torvalds/linux/v6.4/crypto/af_alg.c), where a separate af_alg_sendpage function handles them. The route from sendmsg(), sendmmsg(), send(), sendto(), write(), writev() and the io_uring send and write operations into af_alg_sendmsg follows general Linux socket behavior rather than a statement in a source, and the kernel probes on alg_create and af_alg_sendmsg are general hunting heuristics. The capability list and the CONFIG_CRYPTO_USER_API requirement come from the kernelCTF metadata at https://raw.githubusercontent.com/google/security-research/master/pocs/linux/kernelctf/CVE-2025-39964_lts_cos_mitigation/metadata.json, and the statement that user namespaces are not required comes from the kernelCTF vulnerability description at https://raw.githubusercontent.com/google/security-research/master/pocs/linux/kernelctf/CVE-2025-39964_lts_cos_mitigation/docs/vulnerability.md. The exploit sources for the three kernelCTF targets, the exploit.c files under https://github.com/google/security-research/tree/master/pocs/linux/kernelctf/CVE-2025-39964_lts_cos_mitigation/exploit, were searched for kernel interfaces and file paths rather than read in full. Each contains one socket() call, the AF_ALG and SOL_ALG constants, setsockopt() with ALG_SET_KEY, bind() and accept(), sendmsg() with ALG_SET_OP and ALG_SET_IV, one pthread_create() call and sched_setaffinity(), and references to the kernel's core_pattern setting, /proc/sys/kernel/core_pattern and /proc/self/exe; none contains io_uring, unshare() or a user or network namespace flag. The exploitation write-up in that directory was not read. The advice to compare core_pattern against its expected value, and the note on changes made through kernel memory, are general hunting heuristics. The version ranges come from the NVD record at https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2025-39964 and the fixed stable releases per line from the kernel CVE record at https://cveawg.mitre.org/api/cve/CVE-2025-39964. The RHEL package states and fixed build come from https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-39964.json, the GKE and GDC status from https://docs.cloud.google.com/kubernetes-engine/security-bulletins and the Siemens firmware scope from https://cert-portal.siemens.com/productcert/html/ssa-019113.html. The UID-change indicator, the loaded-module check and the kernel-log check are general hunting heuristics rather than artifacts read from a source. The network group is empty because the flaw is reached through local system calls and no source gives a network artifact for it. No actor infrastructure, file hash or C2 address is listed, because no source consulted attributes this CVE to a named campaign or operator."
+    },
+    "ai_discovered": false,
+    "ai_discovery_notes": "The upstream fix, signed off by crypto maintainer Herbert Xu, credits Muhammad Alifa Ramdhan and Bing-Jhong Billy Jheng, both with starlabs.sg addresses, as reporters. No source consulted says AI tooling found or exploited the flaw.",
+    "ai_discovery_source": "human_researcher",
+    "discovery_attribution_note": "Sourced from NVD CVE-2025-39964 (CWE-362, CVSS 5.5) plus the CISA KEV entry (added 2026-09-18), Google Cloud bulletin GCP-2026-003, Siemens advisory SSA-019113 and the Red Hat CVE record. The upstream fix credits Muhammad Alifa Ramdhan and Bing-Jhong Billy Jheng as reporters.",
+    "ai_assisted_weaponization": false,
+    "active_exploitation_notes": "CISA added CVE-2025-39964 to the KEV catalog on 2026-09-18 with a due date of 2026-09-21, states that the addition is based on evidence of active exploitation, and records known ransomware campaign use as Unknown. The KEV entry marks forensic triage as required for this CVE, and its required action tells agencies to comply with BOD 26-04 and with CISA's Forensics Triage Requirements, both of which the entry links to. CISA's SSVC assessment in the NVD record marks exploitation as active, automatable as no and technical impact as total. CISA announced it in the same alert as CVE-2026-53266, an out-of-bounds write in the Linux kernel. No source consulted names an actor, a campaign, a targeted sector or an incident report. A public exploit is available in Google's kernelCTF repository, and its metadata records a 99% success rate on the kernelCTF LTS 6.12.44, mitigation-v4-6.6 and Container-Optimized OS 121-18867.199.28 targets.",
+    "attack_refs": [
+      "T1068",
+      "T1611",
+      "T1499.004"
+    ],
+    "atlas_refs": [],
+    "framework_control_gaps": {
+      "NIST-800-53-SI-2": "SI-2 requires the organization to identify, report and correct system flaws and to install security-relevant updates within an organization-defined time period of their release. Programs usually set that period from severity, and the severity labels for this CVE disagree: NVD scores it 5.5 with availability impact only and Red Hat rates it Moderate, while the kernel CNA scores it 7.8 and Google's bulletin GCP-2026-003 rates it High as a privilege escalation on Container-Optimized OS nodes. Red Hat's CVE page also flags the CVE as having known public exploits and tells customers to address it with high priority, a flag recorded separately from its Moderate rating. A time period keyed only to the NVD base score or to a vendor severity label puts the AF_ALG fix in a medium-severity queue although CISA lists it as exploited and a public kernelCTF exploit reports a 99% success rate.",
+      "NIST-800-53-SC-39": "SC-39 requires a separate execution domain for each executing process, and on a container host the kernel's namespaces and cgroups provide those domains. This flaw is in the kernel that enforces them: the kernelCTF metadata lists no required capabilities and only CONFIG_CRYPTO_USER_API as kernel configuration, the kernelCTF vulnerability description states that user namespaces are not required, and Google lists both GKE Standard and Autopilot clusters as impacted and exempts only clusters using GKE Sandbox. SC-39 evidence based on per-container namespaces stays compliant while any workload on an unpatched node can open an AF_ALG socket and attack the host kernel.",
+      "NIS2-Art21-patch-management": "Article 21(2)(e) requires essential and important entities to include vulnerability handling in the maintenance of their network and information systems. An entity running Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP or SIPLUS S7-1500 CPU 1518-4 PN/DP MFP controllers has no fix to apply for this CVE: Siemens SSA-019113 lists every firmware version from V3.1.6 as affected with no fix available, and its V3.1.7 update covers other CVEs only. Handling is limited to the two mitigations Siemens publishes, and Article 21 does not define a handling state for an exploited flaw that stays unfixed with only compensating measures in place.",
+      "UK-CAF-B4": "Principle B4 expects the systems that support an essential function to be securely configured and their known vulnerabilities to be managed. For the RHEL kernels Red Hat still lists as affected, Red Hat states that no mitigation meets its criteria, and the kernelCTF description leaves its syscall-to-disable field empty, so no vendor-published interim configuration exists for a B4 assessment to check. The factors that decide exposure are whether the kernel is built with the AF_ALG user API and whether untrusted local users or containers run on the host, and B4 does not name either as a vulnerability-management question.",
+      "AU-Essential-8-Patch": "The Essential Eight treats the Linux kernel as an operating system. On internet-facing servers, ISM-1877 requires the fix within 48 hours of release at every maturity level when the vendor rates the flaw critical or a working exploit exists, and ISM-1694 allows two weeks when the vendor rates it non-critical and no working exploit exists. A working exploit exists here, because CISA lists the flaw in KEV and the kernelCTF repository publishes one. On workstations and non-internet-facing servers, such as internal Kubernetes nodes and shared build hosts, ISM-1695 allows one month at Maturity Levels One and Two, and only at Maturity Level Three does ISM-1696 require 48 hours when the vendor rates the flaw critical or a working exploit exists. The flaw needs local code execution rather than network reach, so the internet-facing split does not follow the exposure: a container tenant on an internal node has the access the exploit needs. Every window starts at the vendor's release, and Red Hat's record lists only a RHEL 8 kernel-rt fix, so for the other RHEL kernels no window has started.",
+      "ISO-27001-2022-A.8.8": "A.8.8 requires that information about technical vulnerabilities of systems in use be obtained, the organization's exposure evaluated and appropriate measures taken. For this CVE the exposure evaluation depends on which kernel build carries the fix: upstream fixed it in 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9 and 6.17, Red Hat's RHEL 8 kernel-rt fix is 4.18.0-553.166.1.rt7.507.el8_10, and GKE fixes it only at specific node versions. On Siemens S7-1500 MFP CPUs the affected kernel is part of the firmware's additional GNU/Linux subsystem, so an asset register that records only the controller firmware version does not show that the controller contains an exploited Linux kernel flaw."
+    },
+    "patch_available": true,
+    "patch_required_reboot": true,
+    "live_patch_available": false,
+    "live_patch_tools": [],
+    "live_patch_notes": "No source consulted documents a live patch for this fix, so remediation is a kernel update followed by a host reboot into the fixed kernel. A fix exists upstream and for some downstream builds, but not for all of them: Red Hat's record lists RHSA-2026:70403 for RHEL 8 kernel-rt as its only released fix, and Siemens lists no fix for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP and SIPLUS S7-1500 CPU 1518-4 PN/DP MFP firmware.",
+    "affected": "The Linux kernel's AF_ALG user-space crypto interface (crypto/af_alg.c) in kernels built with CONFIG_CRYPTO_USER_API, from 2.6.38 until the stable fixes. A local unprivileged process can use it to crash the host, and Google's GKE bulletin and the kernelCTF exploits show privilege escalation to the kernel, which on a shared container node crosses the container boundary. Affected downstream builds include the RHEL 7, 8, 9 and 10 kernels, GKE Container-Optimized OS and Ubuntu node images, and the additional GNU/Linux subsystem of the Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP and its SIPLUS variant. Google's bulletin lists patch versions and a severity assessment for GDC software for VMware, GKE on AWS and GKE on Azure as in progress, and lists GDC software for bare metal as not affected because it does not bundle an operating system.",
+    "affected_versions": [
+      "Linux kernel 2.6.38 up to but not including 5.10.245 (5.10.245 is fixed). This range includes every stable line older than 5.10, for which the kernel CVE record lists no fixed release.",
+      "Linux kernel 5.11 up to but not including 5.15.194 (5.15.194 is fixed). The kernel CVE record lists no fixed release for the 5.11 to 5.14 lines in this range.",
+      "Linux kernel 5.16 up to but not including 6.1.154 (6.1.154 is fixed). The kernel CVE record lists no fixed release for the 5.16 to 5.19 and 6.0 lines in this range.",
+      "Linux kernel 6.2 up to but not including 6.6.108 (6.6.108 is fixed). The kernel CVE record lists no fixed release for the 6.2 to 6.5 lines in this range.",
+      "Linux kernel 6.7 up to but not including 6.12.49 (6.12.49 is fixed). The kernel CVE record lists no fixed release for the 6.7 to 6.11 lines in this range.",
+      "Linux kernel 6.13 up to but not including 6.16.9 (6.16.9 is fixed). The kernel CVE record lists no fixed release for the 6.13 to 6.15 lines in this range.",
+      "Linux kernel 6.17-rc1 through 6.17-rc6 (6.17 is fixed)",
+      "Red Hat Enterprise Linux 8 kernel-rt before 4.18.0-553.166.1.rt7.507.el8_10 (fixed by RHSA-2026:70403, released 2026-09-22). Red Hat's record lists the RHEL 7, 8, 9 and 10 kernel packages, the RHEL 7 and 9 kernel-rt packages and Red Hat Enterprise Linux for NVIDIA 26 as affected with no released fix, and RHEL 6 as not affected.",
+      "GKE Container-Optimized OS node pools below 1.34.1-gke.3556000, 1.33.5-gke.1862000, 1.32.9-gke.1239000, 1.31.13-gke.1139000, 1.30.14-gke.1719000, 1.29.15-gke.2467000 or 1.28.15-gke.3163000 on the matching minor version (each listed version is fixed). Clusters using GKE Sandbox are not impacted.",
+      "GKE Ubuntu node pools below 1.35.1-gke.1396000, 1.34.4-gke.1047000, 1.33.8-gke.1026000, 1.32.12-gke.1026000, 1.31.14-gke.1336000 or 1.30.14-gke.1991000 on the matching minor version (each listed version is fixed).",
+      "GDC software for VMware, GKE on AWS and GKE on Azure: Google Cloud bulletin GCP-2026-003 lists patch versions and a severity assessment for each as in progress, with the status Pending. The same bulletin lists GDC software for bare metal as not affected because it does not bundle an operating system.",
+      "Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (6ES7518-4AX00-1AB0, 6ES7518-4AX00-1AC0), SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP (6ES7518-4FX00-1AB0, 6ES7518-4FX00-1AC0) and SIPLUS S7-1500 CPU 1518-4 PN/DP MFP (6AG1518-4AX00-4AC0): all firmware versions from V3.1.6, in the additional GNU/Linux subsystem. Siemens lists no fix for this CVE; the V3.1.7 update in the same advisory fixes other CVEs and does not fix this one."
+    ],
+    "vendor_update_paths": [
+      "Upgrade to a kernel that carries upstream commit 1b34cbbf4f01, which disallows concurrent writes in af_alg_sendmsg, or its stable backport: 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9, 6.17 or later on the matching stable line. A kernel on a line for which the kernel CVE record lists no fixed release (every line older than 5.10, and lines such as 5.14, 6.0 or 6.8) has no fixed build on its own line: move it to a fixed stable line, or install a distribution kernel that backports commit 1b34cbbf4f01. On a host in scope for forensic triage (under BOD 26-04, a federal agency's publicly exposed asset), or on any host where untrusted local users or containers ran code on a vulnerable kernel, capture memory, running processes and kernel logs before installing the update, because the reboot clears memory and CISA's triage guidance says patching may jeopardize the availability of artifacts. Reboot into the new kernel, because the fix takes effect only in the running kernel.",
+      "On Red Hat Enterprise Linux 8 with kernel-rt, capture memory, running processes and kernel logs first on a host in scope for forensic triage, then install kernel-rt 4.18.0-553.166.1.rt7.507.el8_10 or later from RHSA-2026:70403 and reboot. For the other RHEL kernel packages, Red Hat's record lists no released fix and states that no mitigation meets its criteria, so follow the Red Hat CVE record for the erratum.",
+      "On GKE, capture memory, running processes and kernel logs first from any node in scope for forensic triage, then upgrade Container-Optimized OS and Ubuntu node pools to the patch versions listed in Google Cloud bulletin GCP-2026-003 or later. Clusters using GKE Sandbox are listed as not impacted. For GDC software for VMware, GKE on AWS and GKE on Azure, the bulletin lists patch versions as in progress, so follow the bulletin for the fixed versions. GDC software for bare metal is listed as not affected, and the bulletin states that no action is required for it.",
+      "On Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP and SIPLUS S7-1500 CPU 1518-4 PN/DP MFP controllers, SSA-019113 lists no fix for this CVE. Apply the Siemens mitigations: build and run applications only from trusted sources, and limit access to the interactive shell of the additional GNU/Linux subsystem to trusted personnel.",
+      "On other distributions, capture memory, running processes and kernel logs first on a host in scope for forensic triage or on any host where untrusted local users or containers ran code on a vulnerable kernel, then install the vendor kernel update that backports the upstream fix, reboot, and confirm with uname -r that the fixed kernel is the one running."
+    ],
+    "_auto_imported": false,
+    "_intake_method": "batch-curated",
+    "rwep_factors": {
+      "cisa_kev": 25,
+      "poc_available": 20,
+      "ai_factor": 0,
+      "active_exploitation": 20,
+      "blast_radius": 26,
+      "patch_available": -15,
+      "live_patch_available": 0,
+      "reboot_required": 5
+    },
+    "rwep_score": 81,
+    "rwep_notes": "RWEP 81. cisa_kev +25, poc_available +20, active_exploitation +20, blast_radius +26, patch_available -15, reboot_required +5. Σ factors === rwep_score."
+  },
+  "CVE-2026-7273": {
+    "name": "Zyxel GS1900 Series Switches Stack-Based Buffer Overflow Vulnerability",
+    "cvss_score": 8.8,
+    "cvss_vector": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+    "cwe_refs": [
+      "CWE-121"
+    ],
+    "cisa_kev": true,
+    "cisa_kev_date": "2026-09-21",
+    "cisa_kev_due_date": "2026-09-24",
+    "known_ransomware_use": false,
+    "active_exploitation": "confirmed",
+    "complexity": "low",
+    "vector": "A stack-based buffer overflow vulnerability in the CGI program of Zyxel GS1900-48HPv2 firmware versions through 2.90(ABTQ.1)C0 could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request.",
+    "epss_score": 0.01987,
+    "epss_percentile": 0.7972,
+    "epss_date": "2026-09-22",
+    "epss_source": "https://api.first.org/data/v1/epss?cve=CVE-2026-7273",
+    "vendor_advisories": [
+      {
+        "vendor": "Zyxel",
+        "advisory_id": "zyxel-security-advisory-for-stack-based-buffer-overflow-vulnerability-in-gs1900-series-switches-06-16-2026",
+        "url": "https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-stack-based-buffer-overflow-vulnerability-in-gs1900-series-switches-06-16-2026",
+        "severity": "unknown",
+        "published_date": null
+      }
+    ],
+    "verification_sources": [
+      "https://nvd.nist.gov/vuln/detail/CVE-2026-7273",
+      "https://www.cisa.gov/known-exploited-vulnerabilities-catalog",
+      "https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-stack-based-buffer-overflow-vulnerability-in-gs1900-series-switches-06-16-2026"
+    ],
+    "source_verified": "2026-09-23",
+    "last_updated": "2026-09-23",
+    "_kev_short_description": "Zyxel GS1900 series switches contain a stack-based buffer overflow vulnerability in the CGI program which could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request.",
+    "type": "stack-buffer-overflow-to-os-command-execution",
+    "blast_radius": 16,
+    "poc_available": false,
+    "poc_description": "No working exploit code is obtainable at a nameable public location. The GreyNoise report quotes fragments of the attacker's command-line interface for CVE-2026-7273 (its description string 'Zyxel GS1900 Pre-Auth RCE', usage examples issued over http:// and https://, and its GOT and stack mode options) but does not host runnable code. NVD tags the GreyNoise reference 'Exploit', but the linked page is a summary rather than a hosted exploit. The 0xMarcio pocindex aggregator records 'No PoCs found on GitHub currently.' for this CVE. The campaign's own exploit was a private, PyArmor-obfuscated Python script that GreyNoise did not publish, so no Exploit-DB id, Metasploit module, nuclei template or public repository hosts a working exploit.",
+    "iocs": {
+      "behavioral": [
+        "After a crafted request to the switch web management CGI, the switch fetches a file over TFTP and runs it with the shell: GreyNoise documents the exploit issuing a TFTP get of a file named c saved as /1, then executing /bin/sh /1.",
+        "The switch stages collected data for retrieval by copying /tmp/info to the web-reachable path /home/web/tmp/info.txt, the collector step GreyNoise documents.",
+        "Hunting heuristic: the switch web management CGI process starting a shell that runs tftp against a host that is not an approved TFTP server, or that runs a fetched script such as /1; the exploit commands GreyNoise documents follow this pattern. Administrators also upgrade firmware from a TFTP server and upload configuration backups to one through the web interface, so a rule compares each shell and transfer against those functions and the approved TFTP servers instead of alerting on every process the web interface starts.",
+        "The switch opening an unexpected listening service, for example a busybox telnet daemon on port 2323 bound to /bin/sh, which appears as a usage example in the exploit's command-line interface."
+      ],
+      "network": [
+        "Crafted requests to the switch web management CGI over HTTP or HTTPS from any host outside the management network; the exploit's usage examples target the interface at 192.168.1.1 over both HTTP and HTTPS, and its GOT mode succeeds with a single request while its stack mode sends many.",
+        "A burst of requests to the web management CGI from one source, on the order of hundreds to thousands, matching the exploit's stack mode (ASLR brute force, about 2,048 requests on average).",
+        "Outbound TFTP from the switch to a host that is not an approved TFTP server, on any port including the 6969 the campaign used; the switch supports TFTP only for firmware upgrade and configuration backup or restore, so a transfer to an unknown host is anomalous."
+      ],
+      "host": [
+        "GS1900 firmware at or below the affected build for the model (for example GS1900-24 at or below 2.90(AAHL.1)C0, or GS1900-48HPv2 at or below 2.90(ABTQ.1)C0), the vulnerable state per the Zyxel advisory.",
+        "Staging files the observed collector leaves: /tmp/info and its web-reachable copy /home/web/tmp/info.txt, and a fetched script written as /1 and executed by /bin/sh.",
+        "The switch carrying factory-default administrator credentials, an exposure condition present on 564 of the 996 compromised switches rather than a compromise artifact."
+      ],
+      "campaign_actor_wide": [
+        "Backdoor file SHA-256 hashes GreyNoise lists for the actor's broader operation: 0e81d80b40eaacbf6cb1e817fb1824c30a824af5cb4faca4aa9b03fd506d480f, 0f6e757e82c4d91df5bd249f775b9970b59dee42cc0dfe40f879d77fc16821c6 and 2ff2945b13a4cd0e9a65c85af29ea1539e162a516466c0de682dbf9f8a4000b1. GreyNoise reports that the last was delivered to targets in the actor's first round of Ubiquiti exploitation, and it does not tie any of the three to the switch intrusions.",
+        "Actor infrastructure from GreyNoise's indicator table: the command-and-control domain pattern *.981666.xyz, staging host 74.48.66.73, command-and-control host 104.225.153.141, and two exploitation hosts, 172.245.247.21 and a second host the report redacts. GreyNoise does not say which direction traffic to the two exploitation hosts ran, and it redacts the host the switches fetched the collector script from, so match every listed actor address as both a source and a destination.",
+        "Account names kapibala and kapibala2, which GreyNoise's indicator table lists as accounts. The report shows both in the actor's WordPress and Windows activity and does not tie either to the switch intrusions. kapibala2 is a local Windows administrator account that the actor's PowerShell script created through the .NET System.DirectoryServices.AccountManagement API; the script was written to C:\\Windows\\Temp\\imp.ps1 and run with powershell.exe -NoProfile -ep bypass -File, and the actor then checked the account with net user kapibala2. The account was not created with a net user /add command, so a hunt for that command misses it. The string kapibala also names the actor's WordPress plugin directory, /wp-content/plugins/kapibala_plugin/, whose kapibala_index.php the actor's scripts address as the webshell."
+      ],
+      "_ioc_source_note": "The switch-specific artifacts (the TFTP fetch of a file named c run as /bin/sh /1, the /tmp/info and /home/web/tmp/info.txt staging paths, and the theft of configurations, hashed root-level credentials and networking information from 996 switches in 48 countries with 564 on factory-default credentials) come from the GreyNoise report at https://www.greynoise.io/blog/open-season-on-kapibala-attacker-steals-government-records-wordpress-exploitation. GreyNoise attributes the campaign to an unnamed malicious cyber actor it assesses as the same as or related to the actor Acronis reported as Red Heron. The report redacts the TFTP host used against the switches and does not tie any published hash, domain, IP or account name to the switch intrusions; those indicators, listed under campaign_actor_wide, belong to the actor's broader operation, and the report does not give the traffic direction for the two exploitation hosts. The affected firmware builds come from the Zyxel advisory at https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-stack-based-buffer-overflow-vulnerability-in-gs1900-series-switches-06-16-2026, which carries no indicators of compromise. The HTTP and HTTPS request pattern, the stack-mode request volume and the TFTP-to-unapproved-host entries are read from the exploit behavior GreyNoise documents; the shell-from-CGI and unexpected-telnet-listener behaviors and the factory-default-credential condition are hunting heuristics or an exposure condition rather than per-switch artifacts the report lists. The administrator TFTP firmware-upgrade and configuration-backup functions, which a rule compares the shell heuristic against, come from ManualsLib copies of Zyxel's GS1900 Series User's Guide at https://www.manualslib.com/manual/1116578/Zyxel-Communications-Gs1900-Series.html?page=214 and https://www.manualslib.com/manual/2489138/Zyxel-Communications-Gs1900-Series.html?page=234."
+    },
+    "ai_discovered": false,
+    "ai_discovery_notes": "The Zyxel advisory credits Lei Gu, Jun Cao, Zhiqing Rui, Jingzheng Wu and Tianyue Luo from ISCAS for reporting the flaw. No source says AI tooling was used to find it. Separately, GreyNoise states it did not identify any specific AI tools in the attacking operation but suspects a large language model helped generate the actor's custom tooling; that is an unconfirmed suspicion about weaponization, not about discovery.",
+    "ai_discovery_source": "human_researcher",
+    "discovery_attribution_note": "Compiled from NVD CVE-2026-7273 (CWE-121, CVSS 8.8) + CISA KEV (added 2026-09-21) + Zyxel security advisory for the GS1900 series stack-based buffer overflow (06-16-2026), which credits Lei Gu, Jun Cao, Zhiqing Rui, Jingzheng Wu and Tianyue Luo from ISCAS for reporting the issue.",
+    "ai_assisted_weaponization": false,
+    "active_exploitation_notes": "CISA added CVE-2026-7273 to the KEV catalog on 2026-09-21 with a 2026-09-24 due date and records known ransomware use as Unknown; the required action cites CISA's BOD 26-04 and its forensics triage requirements. NVD's SSVC decision records exploitation as active with total technical impact. GreyNoise reported on 2026-09-21 that on or about 17 August 2026 an unnamed malicious cyber actor, which it assesses as the same as or related to the actor Acronis reported as Red Heron, exploited the flaw and exfiltrated configurations, hashed root-level credentials and networking information from 996 GS1900 switches across 48 countries, and that 564 of those switches carried factory-default credentials. As of 17 September 2026 GreyNoise called this the first publicly documented in-the-wild exploitation. The exploit was a private PyArmor-obfuscated Python script; GreyNoise suspected but did not confirm large-language-model assistance in building the actor's tooling.",
+    "attack_refs": [
+      "T1190",
+      "T1059.004",
+      "T1105",
+      "T1602.002",
+      "T1552.001"
+    ],
+    "atlas_refs": [],
+    "framework_control_gaps": {
+      "NIST-800-53-SI-2": "SI-2 requires installing security-relevant firmware updates within an organization-defined time period of their release, which for this CVE means upgrading each GS1900 model to its fixed build (for example GS1900-24 to 2.90(AAHL.2)C0 and GS1900-48HPv2 to 2.90(ABTQ.2)C0). SI-2 sets no maximum for that period. Zyxel released the fix on 2026-06-16, so an organization that set a period of 62 days or more, such as a 90-day cycle ending about 2026-09-14, could still have been running vulnerable firmware when the exploitation began on or about 2026-08-17. The SI-2 discussion allows the period to vary with the threat environment but does not require a shorter period once exploitation is confirmed; for this CVE that matters only for a switch still unpatched when CISA listed the flaw on 2026-09-21, because the campaign came before the listing.",
+      "NIS2-Art21-network-security": "Article 21(2) requires appropriate and proportionate technical measures for the security of network and information systems, but it sets no accelerated response tier tied to CISA KEV status or confirmed exploitation for a pre-authentication operating-system-command-execution flaw on a managed switch, and it does not require that the switch web management interface be unreachable from the internet or from the user segments the switch serves. An operator can attest Article 21 compliance while a GS1900 management interface is reachable from the internet, which is the exposure the campaign used to exploit 996 switches across 48 countries.",
+      "UK-CAF-B4": "CAF principle B4 requires that announced vulnerabilities be tracked and prioritized and that externally exposed ones be mitigated promptly, and its guidance names both a separate management layer on dedicated equipment and the removal or credential change of default and built-in accounts. B4 does not define promptly, and its partially-achieved tier lets vulnerabilities that are not externally exposed carry temporary mitigations for an extended period. Zyxel rated CVE-2026-7273 a LAN-based flaw (CVSS AV:A), which invites classifying a switch management interface as not externally exposed and applying that slower tier, even though GreyNoise showed the interface accessible from the internet and exploited remotely on 996 switches.",
+      "AU-Essential-8-Patch": "The Essential Eight patches the operating systems of network devices within timeframes set by exposure and maturity level. For an internet-facing network device, its operating system is patched within 48 hours of release when the vendor rates the flaw critical or a working exploit exists (ISM-1877), and within two weeks when the vendor rates it non-critical and no working exploit exists (ISM-1694), at every maturity level. For a network device that is not internet-facing, its operating system is patched within one month at Maturity Levels One and Two (ISM-1695); at Maturity Level Three it is patched within 48 hours when the vendor rates the flaw critical or a working exploit exists (ISM-1696) and within one month when the vendor rates it non-critical and no working exploit exists (ISM-1902). Zyxel released the fix on 2026-06-16 and rated CVE-2026-7273 8.8 High, and CISA's SSVC assessment on that date recorded exploitation as none, so the slower windows applied: two weeks, to 2026-06-30, for an internet-facing switch, and one month, to 2026-07-16, for an internal one. At every maturity level the applicable window closed four and a half to seven weeks before the exploitation that began on or about 2026-08-17, so meeting it would have put the fixed firmware on each switch before the campaign began. The remaining limit applies to a switch that missed its window: for a switch still unpatched on 2026-08-17, the patch controls are met once the update is installed and do not require a compromise assessment, evidence collection, or rotation of the configuration secrets and hashed credentials the campaign exfiltrated. For a GS1900 model past Zyxel's end of vulnerability support, such as the version 1 GS1900-24HP or GS1900-48HP, Zyxel's advisory lists no fixed build, and at every maturity level the Essential Eight requires an operating system that its vendor no longer supports to be replaced (ISM-1501), which removes such a unit rather than leaving it exposed without a fix.",
+      "ISO-27001-2022-A.8.8": "A.8.8 technical vulnerability management depends on the asset register recording that each GS1900 switch is present and carrying its firmware build. Where these access switches appear as generic network hardware without a firmware build, the affected-build boundary for each model (for example GS1900-48HPv2 at or below 2.90(ABTQ.1)C0) cannot be evaluated, and A.8.8's undefined appropriate timescales default to a routine cycle rather than the hours-scale response a KEV-listed, actively exploited pre-authentication flaw warrants."
+    },
+    "patch_available": true,
+    "patch_required_reboot": true,
+    "live_patch_available": false,
+    "live_patch_tools": [],
+    "live_patch_notes": "There is no reload-free path for this fix. Remediation is flashing the fixed firmware build for the model, which restarts the switch. No source documents a live-patch or hotpatch mechanism for GS1900 firmware. For CVE-2026-7273, Zyxel released fixed builds only for models within their vulnerability support period. The version 1 GS1900-24HP and GS1900-48HP are end of life: Zyxel's archived end-of-life table gives 2021-01-30 as the end of vulnerability support for both, and this advisory neither patches them nor lists them as unaffected. The advisory lists no fix for those units, so their remediation is restricting the management interface and replacing the switch.",
+    "affected": "Zyxel GS1900 series smart managed switches. A stack-based buffer overflow in the web management CGI program allows an unauthenticated attacker who can reach the switch web management interface over HTTP or HTTPS to run operating-system commands on the switch through a crafted request, exposing the device configuration, the local hashed credential store and networking information. The CVSS vector rates the attack vector as adjacent (AV:A), but the observed campaign exploited internet-exposed management interfaces on 996 switches across 48 countries, so any host that can reach the interface, including one on the internet where it is exposed, can exploit the flaw. Zyxel released patches only for the affected models still within their vulnerability support period, and its statement that products not listed in its advisory are unaffected covers only on-market products. The version 1 GS1900-24HP and GS1900-48HP, which Zyxel's 2021 GS1900 advisory for CVE-2021-35030 listed alongside the GS1900-24HPv2 and GS1900-48HPv2, are past Zyxel's end of vulnerability support and are neither patched nor declared unaffected by this advisory. Whether they are vulnerable to CVE-2026-7273 is undetermined, the advisory lists no fix for them, and an owner should treat them as potentially vulnerable.",
+    "affected_versions": [
+      "GS1900-8 firmware through 2.90(AAHH.1)C0 (fixed in 2.90(AAHH.2)C0)",
+      "GS1900-8HP firmware through 2.90(AAHI.1)C0 (fixed in 2.90(AAHI.2)C0)",
+      "GS1900-10HP firmware through 2.90(AAZI.1)C0 (fixed in 2.90(AAZI.2)C0)",
+      "GS1900-16 firmware through 2.90(AAHJ.1)C0 (fixed in 2.90(AAHJ.2)C0)",
+      "GS1900-24 firmware through 2.90(AAHL.1)C0 (fixed in 2.90(AAHL.2)C0)",
+      "GS1900-24E firmware through 2.90(AAHK.1)C0 (fixed in 2.90(AAHK.2)C0)",
+      "GS1900-24EP firmware through 2.90(ABTO.1)C0 (fixed in 2.90(ABTO.2)C0)",
+      "GS1900-24HPv2 firmware through 2.90(ABTP.1)C0 (fixed in 2.90(ABTP.2)C0)",
+      "GS1900-48 firmware through 2.90(AAHN.1)C0 (fixed in 2.90(AAHN.2)C0)",
+      "GS1900-48HPv2 firmware through 2.90(ABTQ.1)C0 (fixed in 2.90(ABTQ.2)C0)"
+    ],
+    "vendor_update_paths": [
+      "Before changing an exploited or suspect switch, collect evidence: export the running, startup and backup configurations and the flash and buffer logs through Maintenance > Configuration > Backup (the switch erases logs held in its memory buffer when it reboots), preserve the staging files (/tmp/info, /home/web/tmp/info.txt and any fetched /1) and check for compromise, because CISA's BOD 26-04 forensics triage guidance at https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk states to collect all required evidence before patching, as patching may jeopardize the availability of artifacts.",
+      "Update each affected switch to the fixed firmware build for its model per the Zyxel advisory (for example GS1900-24 to 2.90(AAHL.2)C0 and GS1900-48HPv2 to 2.90(ABTQ.2)C0): upload the fixed image, set it as the active image, reboot the switch, and confirm the running version on the System Info screen. Then upload the same fixed build to the other image partition, because the switch boots the backup image when the active partition has problems during boot, and a backup partition that still holds an affected build would return the switch to vulnerable firmware.",
+      "For a GS1900 model outside Zyxel's vulnerability support period, such as the version 1 GS1900-24HP or GS1900-48HP, Zyxel's advisory for this CVE lists no fixed build and does not state that the model is unaffected: restrict its web management interface to a dedicated management network, then replace the switch with a supported model.",
+      "Remove the switch web management interface from the internet and restrict it to a dedicated management network, using the switch's Remote Access Control profiles or a management VLAN that user and adjacent segments cannot reach, since any host that can reach the interface can exploit the flaw without authentication.",
+      "Change factory-default administrator credentials and rotate the local credentials and any shared secrets held on the switch (SNMP, and any RADIUS, TACACS+ or shared keys), because the observed campaign exfiltrated the switch configuration and hashed credentials and 564 victim switches were on factory-default credentials.",
+      "For a switch that was exploited or may have been, compare its startup and backup configurations against a known-good copy made before the compromise, or reset the switch to factory defaults and rebuild its configuration, before returning it to service. The firmware update writes a new firmware image to a flash partition and leaves the startup and backup configurations on the switch, so an account, SNMP community, access rule or other setting an attacker saved to them remains after the update."
+    ],
+    "_auto_imported": false,
+    "_intake_method": "batch-curated",
+    "rwep_factors": {
+      "cisa_kev": 25,
+      "poc_available": 0,
+      "ai_factor": 0,
+      "active_exploitation": 20,
+      "blast_radius": 16,
+      "patch_available": -15,
+      "live_patch_available": 0,
+      "reboot_required": 5
+    },
+    "rwep_score": 51,
+    "rwep_notes": "RWEP 51. cisa_kev +25, active_exploitation +20, blast_radius +16, patch_available -15, reboot_required +5. Σ factors === rwep_score."
+  },
+  "CVE-2025-39682": {
+    "name": "Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability",
+    "cvss_score": 9.8,
+    "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+    "cwe_refs": [
+      "CWE-754"
+    ],
+    "cisa_kev": true,
+    "cisa_kev_date": "2026-09-18",
+    "cisa_kev_due_date": "2026-09-21",
+    "known_ransomware_use": false,
+    "active_exploitation": "confirmed",
+    "complexity": "low",
+    "vector": "In the Linux kernel, the following vulnerability has been resolved:\n\ntls: fix handling of zero-length records on the rx_list\n\nEach recvmsg() call must process either\n - only contiguous DATA records (any number of them)\n - one non-DATA record\n\nIf the next record has different type than what has already been\nprocessed we break out of the main processing loop. If the record\nhas already been decrypted (which may be the case for TLS 1.3 where\nwe don't know type until decryption) we queue the pending record\nto the rx_list. Next recvmsg() will pick it up from there.\n\nQueuing the skb to rx_list after zero-copy decrypt is not possible,\nsince in that case we decrypted directly to the user space buffer,\nand we don't have an skb to queue (darg.skb points to the ciphertext\nskb for access to metadata like length).\n\nOnly data records are allowed zero-copy, and we break the processing\nloop after each non-data record. So we should never zero-copy and\nthen find out that the record type has changed. The corner case\nwe missed is when the initial record comes from rx_list, and it's\nzero length.",
+    "epss_score": 0.0203,
+    "epss_percentile": 0.80179,
+    "epss_date": "2026-09-22",
+    "epss_source": "https://api.first.org/data/v1/epss?cve=CVE-2025-39682",
+    "vendor_advisories": [
+      {
+        "vendor": "Red Hat",
+        "id": "CVE-2025-39682",
+        "url": "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-39682.json",
+        "published": "2025-09-05"
+      },
+      {
+        "vendor": "Debian",
+        "id": "DSA-6008-1",
+        "url": "https://security-tracker.debian.org/tracker/DSA-6008-1",
+        "published": "2025-09-22"
+      },
+      {
+        "vendor": "Debian",
+        "id": "DSA-6009-1",
+        "url": "https://security-tracker.debian.org/tracker/DSA-6009-1",
+        "published": "2025-09-22"
+      },
+      {
+        "vendor": "Debian",
+        "id": "DLA-4328-1",
+        "url": "https://security-tracker.debian.org/tracker/DLA-4328-1",
+        "published": "2025-10-13"
+      },
+      {
+        "vendor": "SUSE",
+        "id": "SUSE-SU-2026:0202-1",
+        "url": "https://www.suse.com/support/update/announcement/2026/suse-su-20260202-1/",
+        "published": "2026-01-21"
+      },
+      {
+        "vendor": "SUSE",
+        "id": "SUSE-SU-2026:0283-1",
+        "url": "https://www.suse.com/support/update/announcement/2026/suse-su-20260283-1/",
+        "published": "2026-01-23"
+      },
+      {
+        "vendor": "Siemens",
+        "id": "SSA-032379",
+        "url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html",
+        "published": "2026-05-12"
+      }
+    ],
+    "verification_sources": [
+      "https://nvd.nist.gov/vuln/detail/CVE-2025-39682",
+      "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
+    ],
+    "source_verified": "2026-09-23",
+    "last_updated": "2026-09-23",
+    "_kev_short_description": "Linux Kernel contains an improper check for unusual or exceptional conditions vulnerability in the TLS receive path which allows a zero-length record retrieved from the rx_list to bypass the intended recvmsg() record-type handling, potentially causing subsequent TLS records to be processed using incorrect zero-copy and queuing assumptions. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.",
+    "type": "ktls-record-type-check-bypass-kernel",
+    "blast_radius": 22,
+    "poc_available": true,
+    "poc_description": "Google's google/security-research repository on GitHub publishes kernelCTF exploits for this CVE at https://github.com/google/security-research/tree/master/pocs/linux/kernelctf/CVE-2025-39682_lts_cos_mitigation. The directory's metadata file lists exploits for three kernelCTF targets, lts-6.12.40, mitigation-v4-6.6 and cos-121-18867.90.97 (a Container-Optimized OS build), each with a stated 99% success rate. It names CONFIG_TLS as the only kernel configuration the exploits need and lists no required capabilities and no required attack surface. kernelCTF's rules describe its exploit test as local privilege escalation and flag retrieval. The exploit code was added in pull request #251, which was opened on 2025-09-22 and merged into the master branch on 2026-02-25. The three exploit.c sources were searched for the kernel interfaces and file paths they use, which the indicators record, rather than read in full. The NVD record carries no reference tagged Exploit.",
+    "iocs": {
+      "behavioral": [
+        "A process, including one started by an unprivileged local user, that does not normally use kernel TLS attaching the tls upper-layer protocol to a TCP socket (setsockopt with SOL_TCP and the TCP_ULP option set to tls) and then installing a receive key with the TLS_RX socket option, whether on a socket it accepted as a server or on one it opened as a client. Few processes on a typical host do this, so an unfamiliar process, or one running inside a container, is worth review on an unpatched kernel.",
+        "Kernel warnings, oops reports, panics, KASAN use-after-free or double-free reports, and slab or list-corruption reports whose call trace runs through the kernel TLS code (net/tls), on a host running a kernel in an affected range, whether the trace is in the recvmsg() path (process_rx_list, skb_copy_datagram_msg), in the TLS strparser as data arrives (tls_strp_load_anchor_with_queue, skb_fill_page_desc) or at socket teardown. The Linux kernel CNA's record describes the flaw's effect as a use-after-free and double free of the strparser's anchor buffer and of TCP receive-queue buffers: incoming data is written into the freed buffer, socket teardown frees the anchor and its frag_list buffers twice, and the slab corruption produces oopses, panics and list corruption.",
+        "A process that recently set up kernel TLS receive sockets gaining root privileges or changing credentials shortly afterward, or repeated crashes and restarts of a process that uses kernel TLS, on an unpatched host.",
+        "A process that opens a TCP connection to itself over the loopback interface, attaches the tls upper-layer protocol with a TLS 1.2 receive key on one end, and uses splice() with pipes on that connection. The public kernelCTF exploit sources contain INADDR_LOOPBACK, listen(), connect() and accept() alongside the TCP_ULP and TLS_RX socket options and splice() and pipe() calls, which indicates a connection the exploit opens to itself, so a network sensor records nothing and the host-side setsockopt, splice and /proc/net/tls_stat signals are the ones that apply."
+      ],
+      "network": [
+        "Inbound TLS connections from untrusted or internet clients to a server process that enables kernel TLS receive on the accepted socket, on an unpatched host. The Linux kernel CNA's record states that an anonymous client completing a server-authenticated TLS handshake with a kTLS server is enough to reach the flaw.",
+        "Outbound TLS connections from an unpatched host to untrusted or unexpected servers where the client side enables kernel TLS receive, such as OpenSSL with kTLS, NFS-over-TLS, or SMB/RPC over TLS through the kernel's net/handshake interface, the consumers the Linux kernel CNA's record names. The record states that a malicious server that a kTLS client connects to is enough, and Red Hat's only condition for remote triggering is that kernel TLS is in use, so hosts that use kernel TLS only as clients are exposed as well as servers.",
+        "Where a sensor can read TLS record headers: a peer sending a zero-length record of a type other than application data (an alert or handshake record, for example) between two application-data records on a connection to or from a kernel TLS host, the data, zero-length non-data, data sequence the Linux kernel CNA's record describes. On TLS 1.2 the record type and length travel in the clear, so a passive sensor without the session keys can see a non-data record of the smallest ciphertext size the cipher suite produces, and RFC 5246 does not allow a legitimate peer to send zero-length alert, handshake or ChangeCipherSpec records. On TLS 1.3 every record carries the outer type application data and the real type is known only after decryption, so the sequence is visible only to a sensor that holds the session keys or terminates the connection."
+      ],
+      "host": [
+        "On upstream stable and mainline builds only, a running kernel (uname -r) inside NVD's affected ranges: 6.0 up to but not including 6.1.149, 6.2 up to but not including 6.6.103, 6.7 up to but not including 6.12.44, 6.13 up to but not including 6.16.4, or the 6.17-rc1 and 6.17-rc2 release candidates. Distribution kernels are checked by installed package version, or on Container-Optimized OS by image build, against the distributor's fixed build, as in the items below, because their uname -r string can fall inside these ranges after the fix. Debian releases before Debian 13 set the third component of the kernel's ABI name to 0, so a patched Debian 12 kernel still reports 6.1.0 in uname -r.",
+        "Red Hat Enterprise Linux 9 or 10, or SUSE Liberty Linux 9, running a kernel older than the build Red Hat lists as fixed for its stream (kernel-0:5.14.0-570.49.1.el9_6, kernel-0:5.14.0-427.96.1.el9_4, kernel-0:5.14.0-284.144.1.el9_2, kernel-rt-0:5.14.0-284.144.1.rt14.429.el9_2 or kernel-0:6.12.0-55.37.1.el10_0), including hosts that installed the fixed package but have not rebooted into it. A version check against NVD's 6.0 lower bound misses these RHEL 9 and Liberty Linux 9 kernels, which report 5.14.0.",
+        "SUSE hosts running a kernel older than the fixed build SUSE lists for the host's product and kernel flavor, compared by installed package version rather than by uname -r: kernel-default 6.4.0-150600.23.73.1 on SUSE Linux Enterprise Server 15 SP6, SUSE Linux Enterprise Server for SAP Applications 15 SP6, SUSE Linux Enterprise Desktop 15 SP6 and openSUSE Leap 15.6; kernel-default 6.4.0-150700.53.19.1 on SUSE Linux Enterprise Server 15 SP7, SUSE Linux Enterprise Server for SAP Applications 15 SP7 and SUSE Linux Enterprise Desktop 15 SP7; kernel-rt 6.4.0-150600.10.55.1 on SUSE Linux Enterprise Real Time 15 SP6 and openSUSE Leap 15.6, and kernel-rt 6.4.0-150700.7.19.1 on SUSE Linux Enterprise Real Time 15 SP7; kernel-azure 6.4.0-150600.8.52.1 on 15 SP6 and openSUSE Leap 15.6, and kernel-azure 6.4.0-150700.20.15.2 on 15 SP7; kernel-coco 6.4.0-15061.32.coco15sp6.1 from the SUSE Linux Enterprise Module for Confidential Computing Technical Preview 15 SP6; kernel-default 6.12.0-160000.6.1 on SUSE Linux Enterprise Server 16.0, SUSE Linux Enterprise Server for SAP applications 16.0, openSUSE Leap 16.0 and SUSE Linux Micro 6.2, with kernel-rt at the same version on openSUSE Leap 16.0 and SUSE Linux Micro 6.2; and kernel-default 6.4.0-35.1 or kernel-rt 6.4.0-37.1 on SUSE Linux Micro 6.0 and 6.1. SUSE's status table marks the kernel-source-azure package on SUSE Linux Enterprise Server 16.0, SUSE Linux Enterprise Server for SAP applications 16.0 and openSUSE Leap 16.0 as Affected and lists no fixed kernel-azure build for those releases, so a 16.0 host running kernel-azure counts as unfixed until SUSE lists one. SUSE lists the SUSE Linux Enterprise Server 16.1 GA kernels, kernel-default and kernel-azure 6.12.0-160099.45.1, as fixed. SUSE numbers its kernel-rt, kernel-azure and kernel-coco builds separately from kernel-default, so each host is compared with the build for the flavor it runs. SUSE's 6.4.0 and 6.12.0 kernels fall inside NVD's 6.2 to 6.6.103 and 6.7 to 6.12.44 ranges whether or not they are patched. A host counts as fixed only after it has rebooted into the fixed kernel, or when the kernel-livepatch package SUSE lists for this CVE for its running kernel is installed, for example kernel-livepatch-6_4_0-150700_53_11-default 5-150700.2.1 or later on kernel 6.4.0-150700.53.11 (SUSE-SU-2026:0202-1) or kernel-livepatch-6_4_0-150600_23_60-default 9-150600.2.1 or later on kernel 6.4.0-150600.23.60 (SUSE-SU-2026:0283-1).",
+        "Debian 12 bookworm hosts with the linux package below 6.1.153-1 (DSA-6009-1), Debian 13 trixie hosts with the linux package below 6.12.48-1 (DSA-6008-1), and Debian 11 bullseye hosts running the linux-6.1 kernel below 6.1.153-1~deb11u1 (DLA 4328-1), compared by installed package version and followed by a check that the host has rebooted into the fixed kernel. Debian records Debian 11's default linux package as not affected.",
+        "Siemens SIMATIC CN 4100 firmware below V5.0 (SSA-032379).",
+        "Google Container-Optimized OS milestone 121 instances on a build older than cos-121-18867-199-52, that is, cos-121-18867-0-94 (kernel COS-6.6.74) through cos-121-18867-199-43 (kernel COS-6.6.97), which includes the kernelCTF target cos-121-18867-90-97 (COS-6.6.93). The m121 release notes first list the fix, as KCTF-62708b9 (the abbreviated hash of upstream fix commit 62708b9452f8), for cos-121-18867-199-52, which still runs COS-6.6.97, so comparing the COS kernel version with the upstream 6.6.103 boundary wrongly flags cos-121-18867-199-52 and cos-121-18867-199-56 as affected. Milestones 109, 113 and 117 list the same fix in cos-109-17800-570-40 (COS-6.1.143), cos-113-18244-448-36 (COS-6.1.144) and cos-117-18613-339-52 (COS-6.6.97), which also run kernels below the upstream 6.1.149 and 6.6.103 boundaries, so instances on older m109, m113 or m117 builds are affected and are checked by image build in the same way.",
+        "The tls module listed by lsmod or in /proc/modules on a host where no application needs kernel TLS, a kernel built with CONFIG_TLS=y, where the tls code is part of the kernel image and there is no module to block, or the absence of a modprobe rule that stops the module from loading on hosts where Red Hat's mitigation was meant to be applied. While the tls code is loaded or built in, any local process can attach the tls upper-layer protocol to its own socket; only automatic loading of the module requires CAP_NET_ADMIN.",
+        "An increase in the TlsRxSw or TlsRxDevice counter in /proc/net/tls_stat, in any network namespace, on a host expected to have no kernel TLS receive sessions. These counters count the receive sessions opened in that namespace and are not decreased when the sessions close. TlsCurrRxSw and TlsCurrRxDevice count only the receive sessions installed when the file is read and fall when the sockets close, so they give a point-in-time view. The kernel keeps these counters per network namespace and frees a namespace's counters when the namespace is deleted, so sessions opened in a namespace that no longer exists are not counted. A rise in TlsDecryptError (record decryption failures) on a kernel TLS connection with no matching fault at the peer is a weaker signal.",
+        "A kernel.core_pattern value (sysctl kernel.core_pattern, /proc/sys/kernel/core_pattern) that the host's crash handler and configuration management did not set, especially a pipe to a program under /proc or to an executable outside the distribution's crash-handler path, and a root process started by the kernel's core-dump helper from an unexpected executable after another process crashed. The public kernelCTF exploit sources reference the kernel's core_pattern setting, /proc/self/exe and SIGSEGV. A change made through kernel memory does not pass through a write to /proc/sys/kernel/core_pattern, so compare the current value against the expected one rather than relying only on a file-write watch."
+      ],
+      "_ioc_source_note": "The socket calls that turn on kernel TLS (setsockopt with TCP_ULP set to tls, then TLS_RX), the statement that recv calls on such a socket are decrypted by the kernel, the /proc/net/tls_stat counters (TlsRxSw, TlsRxDevice, TlsCurrRxSw, TlsCurrRxDevice, TlsDecryptError) and the alert and handshake record types come from the kernel's TLS documentation at https://docs.kernel.org/networking/tls.html. That the kernel decreases only the TlsCurr counters when a socket closes and frees a namespace's counters when the namespace is deleted comes from net/tls/tls_main.c at https://raw.githubusercontent.com/gregkh/linux/master/net/tls/tls_main.c. The rule that only automatic loading of an upper-layer protocol module requires CAP_NET_ADMIN comes from net/ipv4/tcp_ulp.c at https://raw.githubusercontent.com/gregkh/linux/master/net/ipv4/tcp_ulp.c. The statements that an anonymous client of a kTLS server, or a malicious server that a kTLS client connects to, can trigger the flaw, the named kTLS consumers (OpenSSL with kTLS, NFS-over-TLS, SMB/RPC over TLS through net/handshake), the data, zero-length non-data, data record sequence, and the use-after-free and double-free effects (the functions process_rx_list, skb_copy_datagram_msg, tls_strp_load_anchor_with_queue and skb_fill_page_desc, the double free at socket teardown, and the oops, panic and list-corruption symptoms) come from the Linux kernel CNA's record at https://cveawg.mitre.org/api/cve/CVE-2025-39682. The cleartext TLS 1.2 record header and the rule against zero-length alert, handshake and ChangeCipherSpec records come from RFC 5246 at https://www.rfc-editor.org/rfc/rfc5246.txt, and the TLS 1.3 outer record type from RFC 8446 at https://www.rfc-editor.org/rfc/rfc8446.txt. The remote-trigger condition, the tls module mitigation and the fixed RHEL builds come from Red Hat's security data at https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-39682.json. The fixed SUSE kernel-default, kernel-rt, kernel-azure and kernel-coco builds for SUSE Linux Enterprise Server 15 SP6, 15 SP7 and 16.0, SUSE Linux Enterprise Server for SAP Applications 15 SP6 and SP7, SUSE Linux Enterprise Server for SAP applications 16.0, SUSE Linux Enterprise Desktop 15 SP6 and SP7, SUSE Linux Enterprise Real Time 15 SP6 and SP7, the SUSE Linux Enterprise Module for Public Cloud, the SUSE Linux Enterprise Module for Confidential Computing Technical Preview 15 SP6, SUSE Linux Micro 6.0, 6.1 and 6.2 and openSUSE Leap 15.6 and 16.0, the Affected state of the kernel-source-azure package on the 16.0 releases, and the fixed SUSE Linux Enterprise Server 16.1 GA kernels come from https://www.suse.com/security/cve/CVE-2025-39682.html, and the SUSE live patch packages and the kernels they are built for come from https://www.suse.com/support/update/announcement/2026/suse-su-20260202-1/ and https://www.suse.com/support/update/announcement/2026/suse-su-20260283-1/. The upstream version ranges and the Siemens SIMATIC CN 4100 range come from the NVD record at https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2025-39682. The Debian 12 and Debian 13 fixed versions, the Debian 11 linux-6.1 fixed version and the unaffected Debian 11 default kernel come from https://security-tracker.debian.org/tracker/CVE-2025-39682, and the Debian ABI-name format that makes uname -r misleading from the Debian Linux Kernel Handbook at https://kernel-team.pages.debian.net/kernel-handbook/ch-versions.html. The CN 4100 fixed firmware comes from https://cert-portal.siemens.com/productcert/html/ssa-032379.html. The kernelCTF targets, the empty capability and attack-surface requirements and the CONFIG_TLS requirement come from the exploit directory's metadata file at https://raw.githubusercontent.com/google/security-research/master/pocs/linux/kernelctf/CVE-2025-39682_lts_cos_mitigation/metadata.json. The exploit sources for the three kernelCTF targets, the exploit.c files under https://github.com/google/security-research/tree/master/pocs/linux/kernelctf/CVE-2025-39682_lts_cos_mitigation/exploit, were searched for kernel interfaces and file paths rather than read in full. Each contains the AF_INET, SOCK_STREAM and INADDR_LOOPBACK constants, listen(), connect() and accept(), setsockopt() with TCP_ULP set to tls and with SOL_TLS and TLS_RX, a TLS 1.2 crypto-info structure, recvmsg(), splice() and pipe() calls, sched_setaffinity(), and references to the kernel's core_pattern setting, /proc/self/exe and SIGSEGV; none contains io_uring, unshare() or a user or network namespace flag. The exploitation write-up in that directory was not read. The Container-Optimized OS builds, their kernel versions and the builds whose notes list the fix as KCTF-62708b9 come from the milestone 109, 113, 117 and 121 release notes at https://cloud.google.com/container-optimized-os/docs/release-notes/m109, https://cloud.google.com/container-optimized-os/docs/release-notes/m113, https://cloud.google.com/container-optimized-os/docs/release-notes/m117 and https://cloud.google.com/container-optimized-os/docs/release-notes/m121; those notes do not name CVE-2025-39682, so the fixed build is identified by the fix commit's abbreviated hash. The following are general hunting heuristics rather than artifacts read from a source: treating an unfamiliar process that enables kernel TLS as suspicious, treating kernel warnings, oopses, panics, KASAN reports and slab or list-corruption reports with call traces in net/tls as possible exploitation attempts (the CNA's record gives the effects and function names, not a crash signature), privilege changes after kernel TLS setup, treating inbound connections from untrusted clients to a kernel TLS server and outbound kernel TLS connections to untrusted servers as exposure, reading a TLS 1.2 non-data record of the smallest ciphertext size the cipher suite produces as an empty record, treating a loaded or built-in tls module on a host where no application needs kernel TLS as exposure, and a rise in TlsDecryptError. The loopback reading of the exploit's connection, the advice to compare core_pattern against its expected value and the note on changes made through kernel memory are also hunting heuristics, built on the interfaces the exploit sources contain. Web searches for a Sigma, nuclei, Elastic or Splunk rule naming this CVE returned none. No actor infrastructure, file hash or C2 address is listed, because no source consulted attributes this CVE to a named campaign or operator."
+    },
+    "ai_discovered": false,
+    "ai_discovery_notes": "The upstream fix, commit 62708b9452f8, credits Muhammad Alifa Ramdhan and Billy Jheng Bing-Jhong, both with addresses at the Singapore security firm STAR Labs, as reporters. No source consulted says how they found the flaw or that AI tooling was involved.",
+    "ai_discovery_source": "human_researcher",
+    "discovery_attribution_note": "Sourced from NVD CVE-2025-39682 (CWE-754, CVSS 9.8) plus the CISA KEV entry (added 2026-09-18), the Linux kernel CNA record, the Red Hat CVE record, SUSE's CVE page and live patch advisories SUSE-SU-2026:0202-1 and SUSE-SU-2026:0283-1, Debian advisories DSA-6008-1, DSA-6009-1 and DLA 4328-1, Google's Container-Optimized OS milestone 121 release notes, Siemens advisory SSA-032379 for the SIMATIC CN 4100, and upstream fix commit 62708b9452f8, which credits Muhammad Alifa Ramdhan and Billy Jheng Bing-Jhong of STAR Labs as reporters.",
+    "ai_assisted_weaponization": false,
+    "active_exploitation_notes": "CISA added CVE-2025-39682 to the KEV catalog on 2026-09-18 with a due date of 2026-09-21 and records known ransomware campaign use as Unknown. The KEV entry also marks forensic triage as required under BOD 26-04, and its required action directs agencies to CISA's Forensics Triage Requirements, which call for an adequate forensic triage analysis to assess whether systems or network infrastructure have been impacted or compromised. The CISA Coordinator SSVC entry in the NVD record, dated 2026-09-18, marks exploitation as active, automatable as yes and technical impact as total. No source consulted names an actor, campaign, targeted sector or incident report for this CVE. Working exploit code for three kernelCTF targets has been public since 2025-09-22, when pull request #251 adding it to Google's google/security-research repository on GitHub was opened; the pull request was merged into the master branch on 2026-02-25.",
+    "attack_refs": [
+      "T1210",
+      "T1068",
+      "T1499.004"
+    ],
+    "atlas_refs": [],
+    "framework_control_gaps": {
+      "NIST-800-53-SI-2": "SI-2 requires flaws to be identified, reported and corrected, with security-relevant updates installed within organization-defined periods of their release. When Debian released fixes on 2025-09-22 and Red Hat released the main RHEL 9 and RHEL 10 fixes on 2025-09-29, NVD had not scored the flaw, and Red Hat rated it Moderate at CVSS 7.0 with high attack complexity. NVD still had no score when Red Hat released the RHEL 9.4 Extended Update Support fix on 2025-10-27 and the RHEL 9.2 Update Services for SAP Solutions fixes on 2025-10-29. NVD's first analysis, on 2026-01-27, scored it 7.1 as a local flaw (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H). The Linux kernel CNA added a network 9.8 vector on 2026-07-30, and NVD replaced its 7.1 with 9.8 on 2026-09-21, three days after CISA listed the CVE in KEV on 2026-09-18. In these sources, the only sign of urgency while the fixes shipped was the exploit code for three kernelCTF targets, public in a GitHub pull request since 2025-09-22. SI-2 leaves the period to the organization and does not tie it to exploit publication, so a schedule keyed to Red Hat's rating or to NVD's score set no critical deadline while the fixes shipped. Evidence that reads installed kernel packages also reports the fix before it is running, because a new kernel package takes effect only after the host reboots into it; SUSE's kernel-livepatch packages for this CVE are the documented exception, and they apply only to the running kernel builds they are made for.",
+      "NIST-800-53-CM-7": "CM-7 requires a system to provide only essential capabilities and to prohibit or restrict functions, protocols and services that are not needed. The code at fault is the kernel TLS module, which applications turn on per socket with the TCP_ULP option rather than by starting a listening service, and Red Hat's mitigation is to prevent that module from loading. A least-functionality baseline written as permitted packages, ports and daemons does not list loadable kernel protocol modules, so hosts where no application uses kernel TLS keep the module loadable and nothing in the baseline shows whether it is loaded.",
+      "NIST-800-53-SC-8": "SC-8 requires the confidentiality and integrity of transmitted information to be protected, which organizations usually meet with TLS. With kernel TLS, the application sets the receive key with the TLS_RX socket option and the kernel then decrypts the records for every recv call on that socket, on connections the host accepted and on connections it opened. This CVE is in that receive path, and the exposure is not limited to TLS 1.3: NVD's description names TLS 1.3, where the record type is known only after decryption, as a case that queues records on the rx_list, while the Linux kernel CNA's record describes the trigger on a TLS 1.2 session and states that TLS 1.2 is zero-copy capable by default, so no unusual kernel configuration or socket option is needed. SC-8 evidence records protocol versions and cipher suites but not whether decryption runs in the kernel, so a system that meets SC-8 with TLS 1.2 or TLS 1.3 over kernel TLS relies on the vulnerable code without that appearing in the evidence.",
+      "NIS2-Art21-patch-management": "Article 21(2)(e) requires essential and important entities to take measures for security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure, and it sets no timeframe for applying a fix. For this CVE the fixes were announced for downstream products on very different dates: Debian 12 and Debian 13 on 2025-09-22 (DSA-6009-1 and DSA-6008-1), Red Hat's main RHEL 9 and RHEL 10 streams on 2025-09-29, Debian LTS for Debian 11's linux-6.1 kernel on 2025-10-13 (DLA 4328-1), and, for the SIMATIC CN 4100 process-control communication node, Siemens advisory SSA-032379 on 2026-05-12, which names firmware V5.0 as the fix. The Siemens advisory appeared eight months after NVD published the CVE on 2025-09-05 and more than seven months after exploit code for the kernel flaw became public on 2025-09-22, and it does not give the date V5.0 was released. An entity running the CN 4100 depends on the manufacturer to ship and announce fixed firmware, and the measure does not say how the entity handles a kernel flaw inside an embedded product before the manufacturer names a fix.",
+      "UK-CAF-B4": "CAF principle B4 (system security) expects systems that support essential functions to be securely configured and their known vulnerabilities managed. Exposure to this CVE depends on the kernel build and on how applications use kernel TLS. A remote peer can reach the flaw on any connection where the host has enabled kernel TLS receive, whether the host accepted the connection as a server or opened it as a client: Red Hat states the flaw can be triggered remotely only when kernel TLS is in use, and the Linux kernel CNA's record names OpenSSL with kTLS, NFS-over-TLS and SMB/RPC over TLS through net/handshake as reachable consumers, including a kTLS client that connects to a malicious server. A local user needs no capabilities, as the public exploits' metadata records, and can attach the tls upper-layer protocol to a socket of their own wherever the tls code is built into the kernel or the tls module is already loaded; only automatic loading of the module requires CAP_NET_ADMIN. A B4 review of installed packages, listening ports and kernel version shows none of these conditions, and a port review misses hosts that use kernel TLS only for outbound connections, while the kernel configuration (CONFIG_TLS), the lsmod output and the TlsRxSw and TlsRxDevice counters in /proc/net/tls_stat for each network namespace do show them. Those two counters count kernel TLS receive sessions opened and do not fall when the sockets close, unlike TlsCurrRxSw and TlsCurrRxDevice, and a namespace's counters are lost when the namespace is deleted. For the SIMATIC CN 4100, Siemens' remediation is an update to firmware V5.0 or later.",
+      "AU-Essential-8-Patch": "The Essential Eight treats the Linux kernel as an operating system. For internet-facing servers it requires the fix within 48 hours of release when the vendor rates the flaw critical or a working exploit exists (ISM-1877), and within two weeks when the vendor rates it non-critical and no working exploit exists (ISM-1694), at every maturity level. For workstations and non-internet-facing servers it allows one month at Maturity Levels One and Two (ISM-1695); at Maturity Level Three it requires 48 hours when the vendor rates the flaw critical or a working exploit exists (ISM-1696) and one month otherwise (ISM-1902). Red Hat rated the flaw Moderate, but exploit code for three kernelCTF targets had been public in a GitHub pull request since 2025-09-22, a week before Red Hat released the main RHEL 9 and RHEL 10 fixes on 2025-09-29. A working exploit therefore existed at release, and the 48-hour window for internet-facing servers ended on 2025-10-01 on the main streams, on 2025-10-29 on RHEL 9.4 Extended Update Support (fixed 2025-10-27) and on 2025-10-31 on RHEL 9.2 Update Services for SAP Solutions (fixed 2025-10-29). On those RHEL streams, meeting the window would have fixed hosts more than ten months before CISA listed the CVE in KEV on 2026-09-18. The shortfall this CVE exposes is the time before a fix existed. Every window runs from the vendor's release, and while the exploit was public, Red Hat had no fix until 2025-09-29, SUSE listed the Liberty Linux 9 fix (RHSA-2025:16880) on 2025-09-30, and SUSE published its first SUSE Linux Enterprise update, SUSE-SU-2025:03600-1, on 2025-10-15. Red Hat's record gives no date for its one mitigation, blocking the tls module, and a host whose applications need kernel TLS cannot use it. The Essential Eight also does not require a compromise assessment of a host that ran an exploitable kernel before it was patched.",
+      "ISO-27001-2022-A.8.8": "A.8.8 requires information about technical vulnerabilities to be obtained, the organization's exposure evaluated and appropriate measures taken. Evaluating exposure to this CVE from NVD's upstream ranges alone gives the wrong answer on Red Hat systems: NVD lists kernels from 6.0 onward, yet Red Hat fixed the flaw in RHEL 9's 5.14.0-based kernels (kernel-0:5.14.0-570.49.1.el9_6 in RHSA-2025:16880, with separate 9.2 and 9.4 update-stream builds) and records RHEL 6, 7 and 8 as not affected. A register that compares the running kernel version with 6.0 marks every RHEL 9 host as out of scope. On Container-Optimized OS the same comparison errs the other way, since builds cos-121-18867-199-52 and cos-121-18867-199-56 run COS-6.6.97, below the upstream 6.6.103 boundary, yet their release notes list the fix. No version comparison shows whether the host uses kernel TLS on any connection, inbound or outbound, which is what makes it remotely exposed."
+    },
+    "patch_available": true,
+    "patch_required_reboot": true,
+    "live_patch_available": true,
+    "live_patch_tools": [
+      "SUSE Linux Enterprise Live Patching (kernel-livepatch packages)"
+    ],
+    "live_patch_notes": "SUSE ships live patches for this fix. SUSE-SU-2026:0202-1 (released 2026-01-21) and SUSE-SU-2026:0283-1 (released 2026-01-23) list CVE-2025-39682 and install through the SUSE Linux Enterprise Live Patching 15-SP6 and 15-SP7 modules as kernel-livepatch packages, each built for one running kernel (for example kernel-livepatch-6_4_0-150700_53_11-default for kernel 6.4.0-150700.53.11), and both advisories list their SP6 live patch packages for openSUSE Leap 15.6 as well. SUSE's CVE page lists further kernel-livepatch packages for SUSE Linux Enterprise Server 16.0, SUSE Linux Enterprise Server for SAP applications 16.0, openSUSE Leap 16.0 and SUSE Linux Micro 6.0, 6.1 and 6.2. A SUSE host whose running kernel has no listed live patch, and any host that takes the fix as a kernel package, runs the fixed code only after rebooting into the new kernel. The Red Hat, Debian and Siemens sources consulted document no live patch, and the Container-Optimized OS fix ships as a new m121 image build. The step that applies without a new kernel is Red Hat's mitigation of preventing the tls module from loading, which suits hosts that do not use kernel TLS; a modprobe rule stops future loads and does not unload a tls module that is already loaded, and a kernel built with CONFIG_TLS=y has no tls module to block. The SIMATIC CN 4100 fix is a firmware update to V5.0. NVD's ranges include kernel lines with no fixed build of their own (6.0, 6.2 to 6.5, 6.7 to 6.11 and 6.13 to 6.15), and CISA notes that the affected products could be end of life and advises moving to a supported version.",
+    "affected": "The Linux kernel's TLS (kTLS) receive path. A remote peer reaches it on any TCP connection where the host has enabled kernel TLS receive, whether the host accepted the connection as a server or opened it as a client, and Red Hat states the flaw can then be triggered remotely. A local user with no capabilities reaches it by enabling kernel TLS on a socket of their own wherever the tls code is built into the kernel or the tls module is loaded, and the public exploits are local privilege escalations written for Google's kernelCTF targets lts-6.12.40, mitigation-v4-6.6 and Container-Optimized OS build cos-121-18867.90.97. The Linux kernel CNA's record describes the result as a use-after-free and double free of the TLS strparser's anchor buffer and of TCP receive-queue buffers, which copies freed kernel memory into the receiving process's buffer, lets incoming data be written into freed memory and corrupts slab state. NVD scores the impact as high for confidentiality, integrity and availability, and CISA's SSVC entry records technical impact as total. Downstream builds that carry the flaw include Red Hat Enterprise Linux 9 and 10 kernels; the SUSE Liberty Linux 9 kernel, which SUSE fixes at the same build and advisory as RHEL 9; SUSE Linux Enterprise Server 15 SP6 and SP7, SUSE Linux Enterprise Server for SAP Applications 15 SP6 and SP7 and SUSE Linux Enterprise Desktop 15 SP6 and SP7 kernels, including the 15 SP6 and SP7 kernel-azure builds; the kernel-coco build in the SUSE Linux Enterprise Module for Confidential Computing Technical Preview 15 SP6; SUSE Linux Enterprise Real Time 15 SP6 and SP7 kernel-rt builds; SUSE Linux Enterprise Server 16.0, SUSE Linux Enterprise Server for SAP applications 16.0, openSUSE Leap 16.0 and SUSE Linux Micro 6.0, 6.1 and 6.2 kernels; openSUSE Leap 15.6 kernels; the Debian 12 and Debian 13 linux packages; Debian 11's linux-6.1 kernel; Google Container-Optimized OS builds older than the first fixed build of their milestone (cos-109-17800-570-40 on milestone 109, cos-113-18244-448-36 on milestone 113, cos-117-18613-339-52 on milestone 117 and cos-121-18867-199-52 on milestone 121); and Siemens SIMATIC CN 4100 firmware before V5.0. Red Hat records RHEL 6, 7 and 8 as not affected, and Debian records Debian 11's default linux package as not affected.",
+    "affected_versions": [
+      "Linux kernel 6.0 up to but not including 6.1.149 (6.1.149 is fixed); this range covers the whole 6.0 line, which has no fixed build of its own",
+      "Linux kernel 6.2 up to but not including 6.6.103 (6.6.103 is fixed); the 6.2 to 6.5 lines have no fixed build of their own",
+      "Linux kernel 6.7 up to but not including 6.12.44 (6.12.44 is fixed); the 6.7 to 6.11 lines have no fixed build of their own",
+      "Linux kernel 6.13 up to but not including 6.16.4 (6.16.4 is fixed); the 6.13 to 6.15 lines have no fixed build of their own",
+      "Linux kernel 6.17-rc1 and 6.17-rc2 (NVD lists no other 6.17 build as affected)",
+      "Red Hat Enterprise Linux 9 kernel (5.14.0 based): fixed in kernel-0:5.14.0-570.49.1.el9_6 (RHSA-2025:16880); RHEL 9.4 Extended Update Support fixed in kernel-0:5.14.0-427.96.1.el9_4 (RHSA-2025:19104); RHEL 9.2 Update Services for SAP Solutions fixed in kernel-0:5.14.0-284.144.1.el9_2 (RHSA-2025:19224) and kernel-rt-0:5.14.0-284.144.1.rt14.429.el9_2 (RHSA-2025:19223)",
+      "Red Hat Enterprise Linux 10 kernel: fixed in kernel-0:6.12.0-55.37.1.el10_0 (RHSA-2025:16904)",
+      "SUSE Liberty Linux 9 kernel before 5.14.0-570.49.1.el9_6, the build and advisory (RHSA-2025:16880) that fix RHEL 9",
+      "SUSE Linux Enterprise Server 15 SP6, SUSE Linux Enterprise Server for SAP Applications 15 SP6 and SUSE Linux Enterprise Desktop 15 SP6: kernel-default before 6.4.0-150600.23.73.1 (6.4.0-150600.23.73.1 is fixed); on SUSE Linux Enterprise Server 15 SP6 and its SAP Applications edition, kernel-azure before 6.4.0-150600.8.52.1, the kernel-azure build SUSE also lists for the SUSE Linux Enterprise Module for Public Cloud 15 SP6",
+      "SUSE Linux Enterprise Server 15 SP7, SUSE Linux Enterprise Server for SAP Applications 15 SP7 and SUSE Linux Enterprise Desktop 15 SP7: kernel-default before 6.4.0-150700.53.19.1 (6.4.0-150700.53.19.1 is fixed); on SUSE Linux Enterprise Server 15 SP7 and its SAP Applications edition, kernel-azure before 6.4.0-150700.20.15.2, the kernel-azure build SUSE also lists for the SUSE Linux Enterprise Module for Public Cloud 15 SP7",
+      "SUSE Linux Enterprise Module for Confidential Computing Technical Preview 15 SP6: kernel-coco before 6.4.0-15061.32.coco15sp6.1 (6.4.0-15061.32.coco15sp6.1 is fixed)",
+      "SUSE Linux Enterprise Real Time 15 SP6 kernel-rt before 6.4.0-150600.10.55.1 and SUSE Linux Enterprise Real Time 15 SP7 kernel-rt before 6.4.0-150700.7.19.1; SUSE numbers kernel-rt builds separately from kernel-default, so a Real Time host is compared with the kernel-rt build",
+      "SUSE Linux Enterprise Server 16.0, SUSE Linux Enterprise Server for SAP applications 16.0, openSUSE Leap 16.0 and SUSE Linux Micro 6.2: kernel-default before 6.12.0-160000.6.1 (6.12.0-160000.6.1 is fixed); on openSUSE Leap 16.0 and SUSE Linux Micro 6.2, kernel-rt is fixed at the same version. SUSE's status table marks kernel-source-azure on SUSE Linux Enterprise Server 16.0, its SAP applications edition and openSUSE Leap 16.0 as Affected and lists no fixed kernel-azure build for them. SUSE lists the SUSE Linux Enterprise Server 16.1 GA kernels, kernel-default and kernel-azure 6.12.0-160099.45.1, as fixed",
+      "SUSE Linux Micro 6.0 and 6.1 kernel-default before 6.4.0-35.1 and kernel-rt before 6.4.0-37.1",
+      "openSUSE Leap 15.6 kernel-default before 6.4.0-150600.23.73.1, kernel-rt before 6.4.0-150600.10.55.1 and kernel-azure before 6.4.0-150600.8.52.1",
+      "SUSE's kernel-livepatch packages for this CVE, including those from SUSE-SU-2026:0202-1 and SUSE-SU-2026:0283-1, close the flaw without a reboot on the specific running kernels they are built for",
+      "Debian 12 bookworm linux packages before 6.1.153-1 (6.1.153-1 is fixed, DSA-6009-1)",
+      "Debian 13 trixie linux packages before 6.12.48-1 (6.12.48-1 is fixed, DSA-6008-1)",
+      "Debian 11 bullseye linux-6.1 packages: fixed in 6.1.153-1~deb11u1 (DLA 4328-1); Debian 11's default linux package is not affected",
+      "Google Container-Optimized OS milestone 121 builds older than cos-121-18867-199-52: cos-121-18867-0-94 (kernel COS-6.6.74) through cos-121-18867-199-43 (kernel COS-6.6.97), including the kernelCTF target cos-121-18867-90-97 (COS-6.6.93). cos-121-18867-199-52, released September 02, 2025 on COS-6.6.97, is the first m121 build whose release notes list the fix, as KCTF-62708b9",
+      "Google Container-Optimized OS milestone 109 builds older than cos-109-17800-570-40, milestone 113 builds older than cos-113-18244-448-36 and milestone 117 builds older than cos-117-18613-339-52. All three fixed builds were released September 02, 2025 and list the fix as KCTF-62708b9, and they run kernels COS-6.1.143, COS-6.1.144 and COS-6.6.97, below the upstream 6.1.149 and 6.6.103 boundaries, so these milestones are checked by image build",
+      "Siemens SIMATIC CN 4100 firmware before V5.0 (V5.0 is fixed, SSA-032379)"
+    ],
+    "vendor_update_paths": [
+      "Upgrade to an upstream stable kernel at or above 6.1.149, 6.6.103, 6.12.44 or 6.16.4, or to a 6.17 build other than the 6.17-rc1 and 6.17-rc2 release candidates, and reboot into it. Hosts on the 6.0, 6.2 to 6.5, 6.7 to 6.11 or 6.13 to 6.15 lines have no fixed build on their own line and must move to a line that carries the fix.",
+      "Red Hat Enterprise Linux 10: install kernel-0:6.12.0-55.37.1.el10_0 (RHSA-2025:16904) and reboot into it.",
+      "Red Hat Enterprise Linux 9: install kernel-0:5.14.0-570.49.1.el9_6 (RHSA-2025:16880); on 9.4 Extended Update Support install kernel-0:5.14.0-427.96.1.el9_4 (RHSA-2025:19104); on 9.2 Update Services for SAP Solutions install kernel-0:5.14.0-284.144.1.el9_2 (RHSA-2025:19224) or kernel-rt-0:5.14.0-284.144.1.rt14.429.el9_2 (RHSA-2025:19223). SUSE Liberty Linux 9 takes the same fixed build, kernel 5.14.0-570.49.1.el9_6 from RHSA-2025:16880. Reboot into the new kernel.",
+      "SUSE Linux Enterprise Server 15 SP6, SUSE Linux Enterprise Server for SAP Applications 15 SP6, SUSE Linux Enterprise Desktop 15 SP6 and openSUSE Leap 15.6: install kernel-default 6.4.0-150600.23.73.1 or later, or kernel-azure 6.4.0-150600.8.52.1 or later on hosts running the kernel-azure flavor, and reboot into it. SUSE Linux Enterprise Server 15 SP7, SUSE Linux Enterprise Server for SAP Applications 15 SP7 and SUSE Linux Enterprise Desktop 15 SP7: install kernel-default 6.4.0-150700.53.19.1 or later, or kernel-azure 6.4.0-150700.20.15.2 or later on kernel-azure hosts, and reboot into it.",
+      "SUSE Linux Enterprise Module for Confidential Computing Technical Preview 15 SP6: install kernel-coco 6.4.0-15061.32.coco15sp6.1 or later and reboot into it.",
+      "SUSE Linux Enterprise Real Time 15 SP6 and openSUSE Leap 15.6 hosts running kernel-rt: install kernel-rt 6.4.0-150600.10.55.1 or later. SUSE Linux Enterprise Real Time 15 SP7: install kernel-rt 6.4.0-150700.7.19.1 or later. Reboot into the new kernel.",
+      "SUSE Linux Enterprise Server 16.0, SUSE Linux Enterprise Server for SAP applications 16.0, openSUSE Leap 16.0 and SUSE Linux Micro 6.2: update kernel-default to 6.12.0-160000.6.1 or later (on openSUSE Leap 16.0 and SUSE Linux Micro 6.2, kernel-rt to 6.12.0-160000.6.1 or later on real-time hosts). SUSE lists no fixed kernel-azure build for SUSE Linux Enterprise Server 16.0, its SAP applications edition or openSUSE Leap 16.0, and it lists kernel-azure 6.12.0-160099.45.1 in the SUSE Linux Enterprise Server 16.1 GA packages as fixed. SUSE Linux Micro 6.0 and 6.1: update kernel-default to 6.4.0-35.1 or later, or kernel-rt to 6.4.0-37.1 or later on real-time hosts. Reboot into the new kernel.",
+      "SUSE live patches: where SUSE lists a live patch for the running kernel, installing that kernel-livepatch package through the SUSE Linux Enterprise Live Patching module applies the fix without a reboot. SUSE-SU-2026:0202-1 carries kernel-livepatch-6_4_0-150700_53_11-default for SP7 kernel 6.4.0-150700.53.11 (zypper in -t patch SUSE-SLE-Module-Live-Patching-15-SP7-2026-205=1) and kernel-livepatch-6_4_0-150600_23_65-default for SP6 kernel 6.4.0-150600.23.65 (zypper in -t patch SUSE-SLE-Module-Live-Patching-15-SP6-2026-202=1). SUSE-SU-2026:0283-1 carries kernel-livepatch-6_4_0-150700_51-default for SP7 kernel 6.4.0-150700.51 (zypper in -t patch SUSE-SLE-Module-Live-Patching-15-SP7-2026-282=1) and kernel-livepatch-6_4_0-150600_23_60-default for SP6 kernel 6.4.0-150600.23.60 (zypper in -t patch SUSE-SLE-Module-Live-Patching-15-SP6-2026-283=1).",
+      "Debian 12 bookworm: upgrade the linux packages to 6.1.153-1 or later (DSA-6009-1) and reboot into the new kernel.",
+      "Debian 13 trixie: upgrade the linux packages to 6.12.48-1 or later (DSA-6008-1) and reboot into the new kernel.",
+      "Debian 11 bullseye: upgrade the linux-6.1 packages to 6.1.153-1~deb11u1 or later (DLA 4328-1) and reboot into the new kernel.",
+      "Google Container-Optimized OS: move instances to the first fixed build of their milestone or later (cos-109-17800-570-40 on milestone 109, cos-113-18244-448-36 on milestone 113, cos-117-18613-339-52 on milestone 117, cos-121-18867-199-52 on milestone 121), each of which lists the fix as KCTF-62708b9 in its release notes, and boot them on the new image. For another milestone, find KCTF-62708b9 in that milestone's release notes.",
+      "Siemens SIMATIC CN 4100: update the firmware to V5.0 or later, per SSA-032379.",
+      "Until the fixed kernel is running, Red Hat's mitigation is to prevent the tls module from loading. This removes the remote and local attack paths only on hosts where no application needs kernel TLS and tls is built as a module, and a modprobe rule does not unload a tls module that is already loaded."
+    ],
+    "_auto_imported": false,
+    "_intake_method": "batch-curated",
+    "rwep_factors": {
+      "cisa_kev": 25,
+      "poc_available": 20,
+      "ai_factor": 0,
+      "active_exploitation": 20,
+      "blast_radius": 22,
+      "patch_available": -15,
+      "live_patch_available": -10,
+      "reboot_required": 5
+    },
+    "rwep_score": 67,
+    "rwep_notes": "RWEP 67. cisa_kev +25, poc_available +20, active_exploitation +20, blast_radius +22, patch_available -15, live_patch_available -10, reboot_required +5. Σ factors === rwep_score."
+  },
   "CVE-2026-19490": {
     "name": "Citrix NetScaler Authentication Bypass Using an Alternate Path or Channel Vulnerability",
     "cvss_score": 9.3,
@@ -84805,7 +85397,7 @@
     "rwep_notes": "RWEP 64. cisa_kev +25, poc_available +20, active_exploitation +20, blast_radius +14, patch_available -15. Σ factors === rwep_score."
   },
   "CVE-2014-0196": {
-    "name": "Linux Kernel Race Condition Vulnerability",
+    "name": "Linux Kernel Race Condition Vulnerability (CVE-2014-0196)",
     "cvss_score": 5.5,
     "cvss_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
     "cwe_refs": [
@@ -110041,7 +110633,7 @@
     "rwep_notes": "RWEP 58. cisa_kev +25, active_exploitation +20, blast_radius +23, patch_available -15, reboot_required +5. Σ factors === rwep_score."
   },
   "CVE-2024-53104": {
-    "name": "Linux Kernel Out-of-Bounds Write Vulnerability",
+    "name": "Linux Kernel Out-of-Bounds Write Vulnerability (CVE-2024-53104)",
     "cvss_score": 7.8,
     "cvss_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
     "cwe_refs": [