@blamejs/exceptd-skills 0.20.1 → 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,
@@ -15183,7 +15775,7 @@
       "NIST-800-53-IA-2": "Identification and authentication of organizational users is anchored on the assumption that the authentication surface - login forms, API token exchange - is where identity is established. This flaw exists beside that surface rather than in it. No credential is guessed, no token is forged and no session is stolen; the request simply reaches a route that does not ask. An IA-2 control assessed on password policy, session handling and token issuance is fully satisfied by an affected build.",
       "NIS2-Art21-identity-management": "Article 21(2)(d) targets identity-management posture at the application boundary - access policies, MFA, privileged-access management, joiner-mover-leaver flows. Every one of those measures can be in place on an affected ServiceDesk Plus instance and none of them is consulted on the bypassed path. The directive's fourteen-day-equivalent urgency is carried here by CISA's 2021-12-15 due date rather than by anything in the identity measure itself, which has no way to express 'the identity layer is correct and is not on the request path'.",
       "UK-CAF-B2": "Identity and access control is about restricting access to authorised users, devices and systems, and its assessment evidence is the access model: who holds which role, how access is granted and reviewed. That evidence is unaffected by this flaw and remains accurate after it. A B2 outcome judged achieved on a documented, reviewed, least-privilege ITSM access model sits on top of an instance that answers REST routes to nobody in particular, because B2 assesses the authorisation model rather than whether every route consults it.",
-      "AU-ISM-1546": "Patch operating systems and applications sets its timeframes against the Essential Eight maturity model - ML2 and ML3 requiring 48 hours for internet-facing or exploited applications, which is the tier this CVE falls into on both counts. The control is capable of closing the flaw and its weakness here is the same one the Australian model has generally: the window anchors on advisory date, and this CVE's advisory surface is thin - NVD records no references at all and the vendor's readme entry for the fixed build is no longer on the live page. An entity working from vendor advisory feeds may never receive the trigger the timeframe is measured from.",
+      "AU-Essential-8-Patch": "A ServiceDesk Plus instance reachable from the internet is an online service, patched within 48 hours of release at every maturity level when a working exploit exists (ISM-1876), and a public Nuclei template sends the single unauthenticated request that exploits it. An internal instance falls under other applications, patched within one month from Maturity Level Two (ISM-1693), with no timeframe at Level One. ManageEngine's live readme no longer lists build 11302, so the start of the window is hard to evidence. CVE-2021-44077 on the same product needs a higher build, and an upgrade that stops at 11302 leaves that remote code execution flaw open.",
       "ISO-27001-2022-A.5.15": "Access control is about establishing and implementing rules to control logical access based on business and information security requirements, anchored on the rules themselves being the thing that governs access. Here the rules are correct and are not asked. An A.5.15 audit reviewing the ITSM access-control policy, the role definitions and the access-review records finds a conformant control set on a build where a route answers without consulting any of it - the certification evidence and the exposure are describing different parts of the system."
     },
     "patch_available": true,
@@ -15790,7 +16382,7 @@
       "NIST-800-53-SI-2": "SI-2's organisationally-defined remediation period is the wrong unit for this CVE twice over. CISA gave federal agencies fourteen days (listed 2021-11-17, due 2021-12-01) against Microsoft's own 'Exploitation Detected' status, which no common SI-2 interpretation of 'critical' matches; and SI-2 closes on the update being deployed, while Microsoft's record marks the fix as reboot-required on all four builds, so an Exchange server that took KB5007409 and deferred its restart satisfies SI-2 while still running the vulnerable code.",
       "NIS2-Art21-incident-handling": "Article 21(2)(b) governs incident handling, and its reporting clocks start when an entity becomes aware of a significant incident. The exploitation route here leaves no failed-authentication signal — the attacker holds a valid mailbox credential and the malicious request rides an already-authenticated session — so an entity relying on authentication telemetry to become aware has no trigger, and the 24-hour early-warning obligation never starts running on an intrusion that has already occurred.",
       "UK-CAF-B2": "B2 asks that access to systems and data be restricted to authorised users. Every actor in this attack is an authorised user by B2's definition: the credential is valid and the session is legitimate. The failure is a privilege boundary inside the Exchange application, between an ordinary mailbox holder and the server process, and no strengthening of identity and access control — including multi-factor authentication on mailbox logon — removes it once the attacker is inside a session.",
-      "AU-ISM-1546": "The ISM patch-operating-systems-and-applications control inherits the Essential Eight maturity windows, whose tightest rung is 48 hours for internet-facing services with a known exploit. Applied here that is closer to reality than a 30-day reading, but the control measures 'patch applied', and on Exchange the reboot is a separate, deferrable act that the control does not require anyone to evidence.",
+      "AU-Essential-8-Patch": "An Exchange server reachable from the internet is an online service, so the Essential Eight requires KB5007409 within 48 hours of its 2021-11-09 release at every maturity level when a working exploit exists (ISM-1876), and Microsoft records exploitation as detected. An Exchange server reachable only internally falls under other applications, with one month from Maturity Level Two (ISM-1693) and no timeframe at Level One. The update requires a reboot on all four affected builds, and a server that installed it without restarting runs the vulnerable code while reporting a fixed build; none of these windows plans for that restart.",
       "ISO-27001-2022-A.8.15": "A.8.15 requires logs of activities and exceptions, and an Exchange deployment logging authentication events satisfies a literal reading. Those events show the attacker's logon as an ordinary successful mailbox authentication. The record that would distinguish this attack — per-request access logging across the OWA, ECP and PowerShell surfaces, held outside the mail server and retained long enough to look back across the exploitation window — is not something A.8.15 obliges an operator to produce."
     },
     "patch_available": true,
@@ -18085,7 +18677,7 @@
       "NIST-800-53-IA-2": "IA-2 requires identification and authentication of organisational users. Solr does not authenticate by default: the Config API POST that the public exploit sends first is accepted unless security.json has been configured, so the CVSS PR:L on this CVE describes a boundary many deployments never erected. An IA-2 assessment scoped to the application front end does not test the search backend that front end proxies to.",
       "NIS2-Art21-vulnerability-management": "NIS2 vulnerability handling is proportionate and unclocked, and the dates show what that permits. A working exploit was circulating publicly before the 2019-11-28 fix, 8.4.0 followed, and CISA did not list the CVE until 2021-11-03 with a 2022-05-03 due date. An entity meeting Article 21 through an annual review of backend middleware versions could carry a Solr 5.x node through that entire period without generating a finding.",
       "UK-CAF-B4": "CAF B4 expects secure configuration to be maintained, and on Solr 5.0.0 through 8.3.1 it cannot be. The Config API is the mechanism an assessor would use to verify that params.resource.loader.enabled is false, and it is the same mechanism the attacker uses to set it true. Verification and exploitation share an interface, so a point-in-time B4 configuration check is not evidence of the state at request time.",
-      "AU-ISM-1546": "The ISM control on authenticating users to systems presumes an authentication decision exists to assess. Solr ships without authentication and the Config API sits on the same unauthenticated surface as the query API, so assessing the application's authentication says nothing about the search tier behind it. The estate-level question this CVE demands - which internal services accept unauthenticated administrative writes - is not one the control asks.",
+      "AU-ISM-1546": "ISM-1546 requires that users are authenticated before they are granted access to a system and its resources. Apache Solr presents its Config API without authentication unless security.json is configured, so a caller who can reach a default node can define a VelocityResponseWriter with params.resource.loader.enabled set to true and then run a template through the query API. An assessment of authentication on the application in front of Solr does not examine the search tier behind it. On affected builds the Config API can turn the loader back on after an operator disables it, and the fix is Solr 8.4.0, or 7.7.3 on the 7.7 branch.",
       "ISO-27001-2022-A.8.9": "A.8.9 requires configurations to be established, documented and monitored. Monitoring is the half that fails: on an affected build the attacker's first request is itself a configuration change - update-queryresponsewriter with params.resource.loader.enabled true - so a documented baseline is accurate right up to exploitation, and drift detection that runs on a schedule observes a change that has already been used. The control would need the write to be alertable at the moment it happens, which it does not require."
     },
     "patch_available": true,
@@ -19100,7 +19692,7 @@
       "NIST-800-53-AC-6": "Least privilege is the control most likely to be cited as covering this and is the one it defeats. The attacker starts inside an ordinary application sandbox with no elevated grant, and the escalation happens inside the kernel through IOMobileFrameBuffer's user client. Every privilege assignment AC-6 governs can be correct while the flaw remains fully exploitable, so an AC-6 attestation is not evidence of containment here.",
       "NIS2-Art21-patch-management": "Article 21(2)(e) sets no clock, and the clock this CVE actually ran on was fourteen days (KEV 2021-11-03 to 2021-11-17). It also has nothing to say about the property that decides whether an entity can meet such a window on mobile: whether OS updates on corporate-managed Apple devices can be enforced without user deferral, which is a device-management capability rather than a patch-management policy.",
       "UK-CAF-B4": "B4 covers secure configuration of systems supporting essential functions, and on iOS and iPadOS the operator's configuration surface stops well short of the kernel — there is no setting that hardens or disables the IOMobileFrameBuffer user client. The only operator-side variable that changes exposure is how quickly the OS update is enforced, which B4 does not express as an outcome.",
-      "AU-ISM-1546": "The ISM patch-operating-systems-and-applications control inherits Essential Eight windows measured from patch availability, and the KEV window here was fourteen days from listing. The larger gap is what the control counts as done: on Apple platforms the update requires a device restart, and a device that has downloaded 14.7.1 but not restarted is still running the vulnerable kernel while the management console reports the update as delivered.",
+      "AU-Essential-8-Patch": "macOS Big Sur is a workstation operating system: ISM-1695 allows one month from release at Maturity Levels One and Two despite a public working exploit, and the 48-hour window for a working exploit (ISM-1696) applies only at Maturity Level Three. iOS, iPadOS and watchOS devices are IT equipment other than workstations, servers and network devices: ISM-1878 requires 48 hours when a working exploit exists, ISM-1751 allows one month otherwise, and neither is in an Essential Eight profile. Each fix takes effect only at a restart, so a device that has downloaded 14.7.1 or 11.5.1 but not restarted still runs the vulnerable kernel while the management console reports the update as delivered.",
       "ISO-27001-2022-A.8.8": "A.8.8's 'appropriate timescales' remain undefined against a fourteen-day federal deadline, and its inventory precondition is weak on this asset class: an enrolled Apple device reports its OS version to the management system, but an A.8.8 process that treats 'update available' as the remediation event rather than 'update installed and device restarted' closes the finding a restart too early."
     },
     "patch_available": true,
@@ -21898,7 +22490,7 @@
       "NIST-800-53-AC-6": "Least privilege is the obvious mapping for an escalation and it does not apply. The precondition is PR:L — code running as an ordinary unprivileged application — and the reachable surface is the GPU device node, which every rendering application opens legitimately. There is no privilege to remove without removing graphics, and the escalation lands in the kernel, above anything AC-6 can scope.",
       "NIS2-Art21-patch-management": "The obligation attaches to the entity, and the release it must consume is a device manufacturer's firmware image carrying an Android security patch level — a bundle of many unrelated fixes, produced on a schedule the entity does not influence and, for older handsets, never produced at all. Article 21(2)(e) has no expression for a vulnerability whose fix exists upstream and cannot be delivered downstream, which is the normal condition of the Android fleet rather than an edge case.",
       "UK-CAF-B4": "B4 asks for hardened, well-maintained systems, and the maintenance path for this component is outside the operator's control entirely. The assessable evidence — an enrolled device meeting a build standard — says nothing about the Mali driver revision, because a handset reports a security patch level and not a driver version, and the mapping between the two is knowledge the manufacturer holds.",
-      "AU-ISM-1546": "The ISM control on authenticating to systems governs who reaches the device and what they may do once there, and this flaw is reached by code the user has already installed, running with the privileges any application holds. Access authentication is correct, enforced and irrelevant: the boundary being crossed is the application sandbox to the kernel, on a device where the user's own authentication was never in question.",
+      "AU-Essential-8-Patch": "The Mali GPU kernel driver falls under drivers, for which the Essential Eight sets patch windows only at Maturity Level Three: 48 hours from release when the vendor rates a vulnerability critical or a working exploit exists (ISM-1879), and one month otherwise (ISM-1697). The May 2021 Android bulletin that carried the fix reported indications of limited, targeted exploitation. Android devices receive the fixed driver only in a manufacturer build at patch level 2021-05-05 or later, which reboots the device. The fix also differs by product line: r29p0 fixes Bifrost and Valhall, while Midgard r30p0 is still affected, so a single driver-version threshold readmits vulnerable devices.",
       "ISO-27001-2022-A.8.8": "A.8.8 requires vulnerabilities to be identified and acted on, and the identification step fails at the version comparison. NVD gives three product lines with different boundaries — Bifrost and Valhall fixed at r29p0, Midgard affected through r30p0 with no fixed version stated — so a single-threshold rule produces a wrong answer for one of the three lines. And the artefact an operator can actually read from a device is a security patch level, not a driver revision, so the control's identification step depends on a mapping the estate does not hold."
     },
     "patch_available": true,
@@ -22602,7 +23194,7 @@
       "NIST-800-53-SI-2": "SI-2's remediation period is customarily set by severity band, and a CVSS 7.5 confidentiality-only finding lands in the tier that gets weeks. What the band cannot see is that Cisco confirmed public exploit code and active exploitation, that the request is two fixed URLs automated in the most widely deployed public scanning template set, and that ASA releases earlier than 9.6 and 9.7 have no fixed release at all — for those, SI-2's remediation action does not exist and the control offers no other state.",
       "NIS2-Art21-network-security": "Article 21(2)(a) covers the security of network and information systems, and this is a defect in the device the entity relies on to enforce that security. NIS2 sets no distinct expectation for a remote-access concentrator versus an ordinary server, and it has nothing to say about the specific consequence here — that the files an attacker reads are session cookies and WebVPN configuration, which feed a follow-on authentication attempt rather than causing damage of their own.",
       "UK-CAF-C1": "C1 asks that events indicating an incident be detected and analysed on the operator's essential function. The exploitation of this flaw is a small number of GET requests to /+CSCOT+/ paths that return HTTP 200 and leave no failed-authentication record, and the appliance's own logs are the ones the operator is least likely to be forwarding at request level. An entity can achieve C1 across its server estate and be entirely blind to the perimeter device that terminates its remote access.",
-      "AU-ISM-1546": "The ISM patch control inherits Essential Eight windows keyed to whether a working exploit exists, and one demonstrably does here by the vendor's own statement. The gap is downstream of the window: the fix is a software upgrade that reloads the appliance, so it needs a maintenance window on the device that is often the only path in for remote users, and the control counts the patch as applied without asking whether the reload happened.",
+      "AU-Essential-8-Patch": "Cisco ASA and FTD software is the operating system of an internet-facing network device. Cisco confirms public exploit code and active exploitation, which meets the ISM-1877 condition for applying the fix within 48 hours of release at every maturity level. The upgrade reloads an appliance that is usually the only remote-access path, and on the FTD 6.3.0 and 6.5.0 trains the numbered release needs its hot fix as well. ASA releases before 9.6 and the 9.7 release have no fixed build, so ISM-1501 requires replacing them, and Cisco lists no workaround for the interval.",
       "ISO-27001-2022-A.8.22": "Segregation of networks is the control that would ordinarily limit what an internet-facing service can expose, and it cannot apply here: the vulnerable web services interface is the internet-facing service, and the files it discloses live on the same device. A.8.22 also assumes the segregation boundary is trustworthy, and the boundary in this case is the appliance with the defect."
     },
     "patch_available": true,
@@ -23064,7 +23656,7 @@
       "NIST-800-53-CM-7": "CM-7 least functionality is precisely the control that would have closed this, and the default defeats it. Smart Install client functionality is enabled by default on switches running releases not updated for Cisco bug ID CSCvd36820, so a CM-7 baseline that disables unneeded services by exception leaves it running - the service was never turned on by anyone, and so appears on no list of services to justify.",
       "NIS2-Art21-network-security": "Article 21 network-security obligations are written for the network an entity operates, treating the switching fabric as the thing being protected rather than as the thing being attacked. Here the switch is the target and the outcome, per Talos, includes GRE tunnels redirecting traffic and altered access lists - the controls the obligation relies on to segment the network are enforced by the device the attacker now controls.",
       "UK-CAF-C1": "CAF principle C1 (security monitoring) depends on the monitoring reaching the asset. Static Tundra modified TACACS+ logging on the devices it took, so the audit trail for privileged access to the switch was being written by the compromised switch. Monitoring that terminates on the network device itself cannot survive a compromise of that device.",
-      "AU-ISM-1546": "ISM-1546 is patch application, measured against Essential Eight timeframes, so the question it asks of a switch is whether the running image is the fixed release for its train. Exposure here is not set by the image. `show vstack config` reporting Role: Client with Oper Mode: Enabled is what makes a device reachable on TCP 4786, and Cisco's advisory states there is no workaround for customers who require Smart Install while directing those who do not to `no vstack`. A switch carrying that configuration change is out of reach of this flaw and still scores as overdue against the patch timeframe; a switch on a train with no fixed release can never satisfy the timeframe at all. The control has no state for either case, because it carries no requirement to record a compensating configuration deployed while the patch cycle runs.",
+      "AU-Essential-8-Patch": "An internet-facing switch falls under ISM-1877, which requires the fixed release or a vendor mitigation within 48 hours of release at every maturity level when a working exploit exists. An internal switch gets one month under ISM-1695 at Maturity Levels One and Two and 48 hours under ISM-1696 at Maturity Level Three, although Cisco is aware of continued exploitation. The fixed release needs a device reload. Applying `no vstack` meets the window on a switch that does not use Smart Install, but no control requires it before the window ends, and a switch that needs Smart Install has no workaround and must be reloaded onto the fixed release.",
       "ISO-27001-2022-A.8.22": "A.8.22 segregation of networks is enforced by the switch. When the switch is the compromised asset, the segregation the control certifies is being applied by attacker-controlled code, and Talos records exactly that outcome - altered access lists and GRE tunnels redirecting traffic. The control's evidence and the control's failure are produced by the same device."
     },
     "patch_available": true,
@@ -23759,7 +24351,7 @@
       "NIST-800-53-SI-4": "SI-4 system monitoring is satisfied by collecting host telemetry, and the events this attack generates are individually unremarkable: a user running userhelper, a process setting its own RLIMIT_FSIZE, a user signalling processes it owns. None of them is an authentication failure or a privileged command, so a monitoring baseline built on those categories records the escalation as ordinary activity. The one signal that is specific — /etc/passwd left truncated and disagreeing with /etc/passwd- — is a file-integrity observation on a file that legitimately changes, which SI-4 does not require anyone to reconcile.",
       "NIS2-Art21-patch-management": "Article 21(2)(e) obliges vulnerability handling and disclosure against a documented process, and a process fed by vendor advisories has already consumed RHSA-2015:1482 and RHSA-2015:1483 and marked them done. The trigger that matters here — CISA's 2026-08-26 listing of an eleven-year-old flaw — is not a vendor advisory and does not enter the pipeline the Article assumes, so an entity can be fully compliant while carrying a build that predates the 2015 errata and never re-examine it.",
       "UK-CAF-B4": "B4 system security asks for hardened, minimised builds, and the minimisation that closes this path is concrete and available: userhelper is setuid-root and is the entry point through which libuser's write to /etc/passwd is reached, so removing the setuid bit or the usermode package on hosts that do not need its chfn / age-warning interface removes the escalation without touching libuser at all. A B4 assessment records default distribution packaging as the hardened state, and default packaging on Red Hat-derived distributions is exactly what installs the setuid consumer.",
-      "AU-ISM-1546": "ISM-1546 requires operating-system and application patches to be applied within a window measured from vendor release. That window closed in 2015. The control gives an assessor nothing to say about a host whose libuser is older than 0.56.13-8 today, because the finding it would raise was raised and closed a decade ago, and it has no concept of a vendor release whose exploitation evidence arrives afterwards — which is precisely what a 2026-08-26 KEV addition against a 2015 erratum is.",
+      "AU-Essential-8-Patch": "The libuser library is installed by default on Red Hat-derived Linux distributions, so the operating system controls apply. With a working exploit, ISM-1877 requires the fix within 48 hours of release on internet-facing servers at every maturity level; workstations and internal servers get one month at Maturity Levels One and Two (ISM-1695) and 48 hours at Maturity Level Three (ISM-1696). Qualys disclosed the flaw with a working exploit on 2015-07-23 and Red Hat shipped fixes that month, so every window closed in 2015 and the 2026-08-26 KEV listing starts no new one. The fix spans libuser under RHSA-2015:1482 and usermode under RHSA-2015:1483, and unsupported releases fall under ISM-1501.",
       "ISO-27001-2022-A.8.8": "A.8.8 prioritises technical vulnerabilities by risk, and every risk input available before 2026-08-26 argued for deprioritising this one: CVSS 5.1, confidentiality and integrity scored none, availability the only impact, and a local-only vector. The prioritisation the control asks for cannot see that CVE-2015-3246 is half of a documented root chain with CVE-2015-3245 and a public Metasploit module, because chained impact is not an input A.8.8 defines — the risk it scores is the risk of one CVE in isolation."
     },
     "patch_available": true,
@@ -26052,7 +26644,7 @@
       "NIST-800-53-IA-2": "Identification and authentication is enforced on the ColdFusion Administrator, and that enforcement is correct and irrelevant. The credential that mattered belongs to a different component - RDS - which authenticates on an empty default password and then hands out a session the Administrator accepts. IA-2 governs authenticating users to the system; it does not require an inventory of every component that can mint a session the management interface will honour, which is precisely the object here. An IA-2 assessment that verifies the Administrator password is set and strong records a pass on a fully exploitable installation.",
       "NIS2-Art21-identity-management": "The Article 21 identity and access-management obligation is satisfied by having credential policy and access control in place, and this installation has both. What defeats it is that the vulnerable credential is a development-time default on a component that is not thought of as an identity surface at all - Adobe's own remedy, per the hotfix and the advisory's interim guidance, is to set the RDS password, meaning the fix is to stop using the default. The control gives no handling for a shipped-empty credential on a secondary component whose only function in production is to be unused.",
       "UK-CAF-B2": "The identity and access-control outcome expects access to be granted only to authenticated and authorised parties. Two things break here that a B2 assessment does not test. First, the authorisation decision is transitive: an RDS session is accepted as an Administrator session, so authenticating against the weaker of two doors admits you through the stronger. Second, the exploitable state is a configuration default rather than a granted access, so a review of accounts, roles and privileges finds nothing wrong - there is no account to review, only an empty password on a component nobody enumerated.",
-      "AU-ISM-1546": "The ISM requirement that users are authenticated before being granted access to a system and its resources was met, and the attacker authenticated - to RDS, with the empty password the product shipped. The control does not distinguish between authenticating and authenticating against something worth authenticating against, and it has no requirement that a session issued by one component be scoped to that component rather than accepted by another. That transitivity, not the strength of any password, is the defect.",
+      "AU-ISM-1546": "ISM-1546 requires that users are authenticated before they are granted access to a system and its resources, and it sits outside the Essential Eight profiles. On ColdFusion 9.0, 9.0.1, 9.0.2 and 10, administrator.cfc accepts an RDS login on the default empty password, and the Administrator web interface honors that session although its own password is different. An assessment that sees the Administrator prompt for a password records the control as met while RDS accepts a login with no password. The control does not require that RDS carries a password or is disabled, or that a session one component issues is refused by another.",
       "ISO-27001-2022-A.8.8": "Management of technical vulnerabilities requires exposure to be evaluated and acted on, and here the evaluation has been correct and unactionable for over a decade. Adobe hotfixed this on 2013-01-15; ColdFusion 9.x went end-of-life on 2014-12-31 and ColdFusion 10 on 2017-05-16. For any installation still carrying this CVE, the control's remedy - obtain the vendor fix - has been unavailable since 2017, and the control offers no state between 'patched' and 'accept the risk' for software whose vendor has stopped shipping fixes entirely."
     },
     "patch_available": true,
@@ -30351,7 +30943,7 @@
       "NIST-800-53-SI-2": "SI-2 measures remediation from vendor release, and Jenkins released 2.154 and LTS 2.138.4 / 2.150.1 on 2018-12-05 — more than three years before CISA's 2022-02-10 listing, which itself carried an unusually long six-month due date to 2022-08-10. The control therefore reports this remediated on any controller that follows the LTS train and is silent on the ones that do not, which is the population that matters: a Jenkins controller is frequently pinned to an old core because a plugin set was validated against it, and SI-2 has no state for 'patch exists, upgrade blocked by dependency' beyond an overdue ticket.",
       "NIS2-Art21-supply-chain": "Article 21(2)(d) supply-chain measures are directed at the security of relationships with suppliers, and the compromise here runs the other way: the entity's own build controller is the supplier to everything downstream of it. Code execution as the Jenkins account reaches the credentials store, signing material and deploy tokens, so the immediate consequence is that artefacts the entity itself publishes become untrustworthy. Nothing in the Article's supplier-assessment framing asks an entity to treat its own CI controller as a supply-chain component whose compromise contaminates its outputs.",
       "UK-CAF-D1": "D1 response and recovery planning for a build server is normally written around availability — restore the controller, restart the pipelines. This incident is not an availability event. The decision the plan has to have pre-agreed is that every credential the controller held is exposed and every artefact built during the exposure window is suspect, and that upgrading to 2.154 changes neither of those. Watchbog's 2019 campaign made the point concretely: the payload persists through scheduled tasks, so a controller restored without rebuild comes back with the miner attached.",
-      "AU-ISM-1808": "ISM-1808 software supply chain risk management is written around evaluating and monitoring the software an organisation consumes. Jenkins here is both consumed software and the machine that produces the organisation's own software, and the control only reaches the first half. It gives an assessor no requirement to establish which artefacts a controller signed or published while it was running weekly 2.153 or LTS 2.138.3, which is the question that determines whether the incident stops at the controller.",
+      "AU-ISM-1452": "ISM-1452 requires a supply chain risk assessment for suppliers of applications and services, and it sits outside the Essential Eight profiles. It treats Jenkins as an application the organization consumes, but a Jenkins controller also builds, signs and publishes the organization's own software. This flaw gives a crafted HTTP request code execution as the Jenkins service account, with the credentials store, signing keys and deploy tokens it holds. The control sets no requirement to establish which artifacts a controller published while it ran weekly 2.153 or earlier or LTS 2.138.3 or earlier and was reachable, which decides whether downstream consumers are affected.",
       "ISO-27001-2022-A.5.21": "A.5.21 requires managing information security in the ICT supply chain, and its instruments are supplier agreements, assurance and monitoring. None of them applies to the controller the organisation operates itself, which is where the credentials for the whole downstream chain are concentrated. The gap is a scoping one: the control assumes the supply chain runs from external suppliers inward, so a single unauthenticated GET that takes over the machine holding every deploy token falls outside the surface the clause examines."
     },
     "patch_available": true,
@@ -33591,7 +34183,7 @@
       "NIST-800-53-AC-6": "AC-6 least privilege is satisfied by giving monitoring staff read-only Nagios XI accounts, and this CVE makes that assignment meaningless: PR:L means any authenticated account reaches command execution on the server through the configuration wizard, so the privilege level recorded in the application is not the privilege level the account actually holds. AC-6 assesses the role assignment and has no mechanism to establish whether the application enforces it — which is the difference between a read-only user and a shell on the monitoring server.",
       "NIS2-Art21-vulnerability-management": "Article 21(2)(e) obliges vulnerability handling and disclosure, and this CVE defeats it at the input: the Nagios advisory trail is thin enough that the fixed version cannot be established from the vendor at all — the GitHub advisory records both affected and patched versions as unknown, and the affected range in general circulation (5.5.6 to 5.7.5) comes from Fastly's research and the Metasploit module rather than from Nagios. A vulnerability-handling process that closes findings against a vendor-stated fixed version has nothing to close this against.",
       "UK-CAF-B4": "B4 system security assesses whether the system is configured to minimise exposure, and on a monitoring server the exposure that matters is inbound reachability of the web interface plus the number of accounts that can authenticate to it. Both are configuration decisions the operator controls and neither is what B4 examines on an application server — the assessment looks at the platform build, while the lever here is that a read-only monitoring login on an internet-reachable Nagios XI is an unauthenticated-equivalent path once the credential leaks.",
-      "AU-ISM-1546": "ISM-1546 requires operating systems and applications to be patched within the Essential Eight Maturity Model timeframes, and those timeframes are anchored on the vendor advisory date — but this CVE has no clearly published vendor release to anchor to. The Metasploit module carries a 2021-02-13 disclosure date and CISA listed the CVE on 2022-01-18, but no Nagios advisory reviewed names the fixed build — so an assessor applying ISM-1546 cannot state when the clock started, and an operator cannot demonstrate compliance by naming the version they upgraded to.",
+      "AU-Essential-8-Patch": "A Nagios XI server reachable from the internet is an online service, patched within 48 hours of release at every maturity level when a working exploit exists (ISM-1876), and a public Metasploit module lets any authenticated account run commands on it. An internal instance falls under other applications, patched within one month of release from Maturity Level Two (ISM-1693), with no timeframe at Level One. Both windows start at the vendor's release, and no Nagios advisory reviewed names the fixed build, so an assessor cannot show when the clock started or which upgrade closed this CVE and its sibling wizards, CVE-2021-25296 and CVE-2021-25298.",
       "ISO-27001-2022-A.8.8": "A.8.8 prioritises technical vulnerabilities by risk, and treats each CVE as an item. Here that framing hides the shape of the problem: CVE-2021-25296, CVE-2021-25297 and CVE-2021-25298 are the same injection defect in three sibling configuration wizards, and the public Metasploit module exploits whichever one is reachable. A programme that remediates by CVE can close this entry, report the vulnerability handled, and leave the instance exploitable through the windowswmi or cloud-vm wizard with the same credential and the same tool."
     },
     "patch_available": true,
@@ -37040,7 +37632,7 @@
       "NIST-800-53-SI-2": "SI-2 flaw remediation was met by the APSB13-03 hotfix in 2013, but ColdFusion 9.x is end-of-life since 2014-12-31 with no current patch; SI-2's patch focus offers no path for the auth-bypass-to-RCE on a dead runtime other than migration.",
       "NIS2-Art21-identity-management": "Art21 identity management assumes administrative access is authenticated; here the password-less ColdFusion state means there is no identity to manage on the admin path, and the control does not force the password-setting step that is the only interim closure on un-hotfixable installs.",
       "UK-CAF-B2": "CAF B2 identity and access control presumes credentials gate privileged functions, but a ColdFusion 9.x install without a configured Administrator password grants admin — and then RCE via the scheduler — to anyone reaching it, a state B2's access-control attestation does not surface.",
-      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before accessing a system, yet the unconfigured-password ColdFusion state admits an unauthenticated attacker to the Administrator; the control is nominally in place while the product accepts access with no authentication event at all.",
+      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before they are granted access to a system and its resources. ColdFusion 9.0, 9.0.1 and 9.0.2 allow a remote attacker to bypass authentication to the Administrator when a password is not configured, and the public exploit schedules a task that runs attacker code. An assessment that records a login on the Administrator does not show whether both the Administrator and RDS passwords are set. The control sets no response to Adobe's disclosure, so the exposure closes only when both passwords are set as Adobe directs, the APSB13-03 hotfix is applied, or the install is migrated off 9.x, which Adobe has not supported since 2014-12-31.",
       "ISO-27001-2022-A.5.15": "A.5.15 access control is defeated by the missing-password condition on ColdFusion 9.x: the flaw is precisely the absence of the access control A.5.15 assumes exists, so an ISMS attestation that access is restricted does not catch a runtime that grants admin without a credential.",
       "AU-Essential-8-Patch": "Patch Applications expects the ColdFusion install patched, but 9.x is past support so no compliant patch exists; the control also does not capture that the bypass is conditional on the Administrator password being unset."
     },
@@ -37548,7 +38140,7 @@
       "NIST-800-53-AC-3": "AC-3 access enforcement is exactly the control this CVE defeats: the RV-series web interface does not enforce authorization on privileged functions, so an AC-3 attestation that every administrator authenticates at login is irrelevant — the attacker never authenticates, and the missing enforcement is in the device firmware, which no account policy can repair before 1.0.01.07 / 1.0.03.26.",
       "NIS2-Art21-network-security": "Art.21 network-security controls that assume the router mediates access cannot help when the router's own management plane fails open to an unauthenticated caller; with CVSS 9.8 and EPSS 0.05655 (92.366th percentile) on 2026-08-20, the only interim network measure is removing reachability of the management interface until firmware lands.",
       "UK-CAF-B2": "CAF B2 identity and access control presumes the device authenticates callers before granting privileged actions; CVE-2022-20700 shows the RV-series firmware granting those actions without any authentication, so a B2 posture built on strong administrator credentials leaves the bypass fully open because credentials are never checked.",
-      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before being granted access to a system; the defect is that the web interface performs privileged operations for a caller who was never authenticated, so an ISM-1546 control implemented at the login page does not cover the unauthenticated management path this CVE reaches.",
+      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before they are granted access to a system, and it sits outside the Essential Eight maturity profiles. The web management interface of these RV-series routers runs privileged functions for a caller who never authenticated, so a router with administrator authentication configured at the login page meets the control while the flaw is open. The control sets no response when the vendor discloses the flaw. For these internet-facing network devices ISM-1877 governs the response, requiring firmware 1.0.01.07 or 1.0.03.26, or the vendor's interim restriction of web management to trusted sources, within 48 hours of release at every maturity level once a working exploit exists.",
       "ISO-27001-2022-A.8.22": "A.8.22 segregation of networks is the compensating control that actually bounds this flaw, because the defect grants privileged management functions to any caller that can reach the interface at all — AV:N/PR:N, with no credential step to fail. That makes the assessable question narrow and specific for CVE-2022-20700: from which networks does the RV160/RV260/RV340/RV345 management interface answer, the WAN side included. Where it answers a client network or the internet, the control can be recorded as implemented while the unauthenticated escalation stays available until firmware 1.0.01.07 / 1.0.03.26 lands; where it does not, segregation is the entire mitigation."
     },
     "patch_available": true,
@@ -54018,7 +54610,7 @@
       "NIST-800-53-IA-5-Federated": "IA-5 federated-identity management assumes the SAML relying party cryptographically verifies IdP assertions. With 'Validate Identity Provider Certificate' unchecked, PAN-OS 8.1<8.1.15/9.0<9.0.9/9.1<9.1.3 accepts an unverified signature, so an IA-5 attestation that federated auth is 'in place' is nullified. The vendor advisory's own workaround makes the toggle conditional: \"If the identity provider (IdP) certificate is a certificate authority (CA) signed certificate, then ensure that the 'Validate Identity Provider Certificate' option is enabled in the SAML Identity Provider Server Profile. Many popular IdPs generate self-signed IdP certificates by default and the 'Validate Identity Provider Certificate' option cannot be enabled.\"",
       "NIS2-Art-21-Federated-Identity": "Art 21 identity controls for federated SSO presume signature validation is enforced end-to-end. Here the enforcement point is a per-profile option in the SAML Identity Provider Server Profile; a NIS2 operator can run federated GlobalProtect SSO believing assertions are validated while CVE-2020-2021 lets an unauthenticated attacker mint an accepted assertion.",
       "UK-CAF-B2": "CAF B2 (identity and access control) is defeated at its foundation: the firewall that enforces access to VPN and management resources authenticates a forged SAML message as a real user, including administrator on the web interface. No downstream access policy compensates once the authentication decision itself is bypassed.",
-      "AU-ISM-1559-IdP": "ISM control 1559 governs identity-provider integration and trust of federated assertions. On an affected PAN-OS with IdP-certificate validation off, the trust anchor is absent — the gateway will honour any assertion — so an ISM assessment of the SSO integration must verify the validation toggle, not merely that SAML is configured.",
+      "AU-ISM-1546": "ISM-1546 requires that users are authenticated before they are granted access to a system and its resources. A PAN-OS firewall, Panorama or Prisma Access deployment that protects GlobalProtect, Captive Portal or its web interface with SAML single sign-on meets the control by configuration. With 'Validate Identity Provider Certificate' unchecked, the device accepts a crafted SAML assertion from an unauthenticated attacker as a legitimate user, or as an administrator on the web interface. Evidence for the control records that SAML is configured, not whether the device validates the identity provider certificate or runs 8.1.15, 9.0.9, 9.1.3 or later. PAN-OS 8.0 has no fix and needs migration to a supported release.",
       "ISO-27001-2022-A.5.16-Federated": "A.5.16 identity management across federated trust expects the relying party to reject unsigned or unverified identities. The CVSS 10.0 rating reflects that PAN-OS instead accepts them when the certificate-validation option is disabled; the control is nominally met by 'SAML enabled' yet materially absent until validation is enforced or the 8.1.15/9.0.9/9.1.3 fix is applied.",
       "NIST-800-53-SI-2": "SI-2 flaw remediation must account for the PAN-OS 8.0 line being end-of-life with no fix: a remediation program that treats all affected branches as patchable will leave 8.0 devices exposed indefinitely, because the terminal state for 8.0 is migration to a supported release, not a patch."
     },
@@ -66078,8 +66670,7 @@
       "NIS2-Art21-network-security": "The Article 21 network-security measure is directed at securing networks and information systems, and an entity implementing it will point at exactly this appliance as the control. That inverts here: the Firebox is not the mitigation for this CVE, it is the target, and its compromise gives a state actor a position on the trust boundary of every network it fronts. The measure gives no instruction that the security appliance's own management plane must be treated as a protected asset with its own reachability restrictions, which is the specific configuration AA22-054A names as the infection precondition.",
       "NIS2-Art21-incident-handling": "Incident handling under Article 21 is built for a bounded event with detection, containment and recovery steps, and it fits an implant that persists as firmware badly. Cyclops Blink has been deployed since at least June 2019 per AA22-054A, so the containment question is not what happened this week but whether an appliance has been under GRU control for years, and recovery means the vendor's full diagnostic path rather than a reboot. Nothing in the measure escalates a confirmed nation-state foothold on a perimeter device above the handling any malware infection receives.",
       "UK-CAF-D1": "D1 requires response and recovery planning, and a plan written against ransomware and commodity malware will not carry the steps this incident needs. Recovering a Firebox that a state actor implanted through a firmware update means treating every credential, certificate and VPN secret the device held as disclosed, and treating the device itself as untrustworthy until rebuilt to the vendor's procedure. A response plan that ends at 'upgrade Fireware to 12.7.2_U1' meets the principle and leaves the implant in place.",
-      "AU-ISM-1546": "The ISM control requiring users to be authenticated before being granted access to systems is met here in the most literal way — the attacker does authenticate, with a real if unprivileged Firebox account. What fails afterwards is the appliance's own mapping from that authenticated identity to session privilege, which no authentication control examines. An entity can demonstrate that every Firebox account authenticates correctly and still be handing privileged management sessions to accounts that hold no administrative role.",
-      "AU-Essential-8-Patch": "The Essential Eight patching control drives the Fireware upgrade and reports completion by installed version, and for this CVE the version alone is an incomplete answer twice over. A unit that has taken 12.7.2_U1 but not restarted onto it is still running the vulnerable build and still reads as patched in a firmware inventory. And for a unit that was externally reachable before the upgrade, the version records remediation of the flaw while saying nothing about a firmware-resident implant the upgrade may not remove.",
+      "AU-Essential-8-Patch": "Fireware OS is the operating system of internet-facing network devices, so ISM-1877 requires the fix within 48 hours of release at every maturity level once a working exploit exists, and ISM-1694 allows two weeks otherwise. The attacker signs in with a real unprivileged account, so authentication evidence does not show the flaw. The fix is split across four branches, down to 12.1.3_Update3 for legacy XTM units that an inventory of current hardware misses. A unit that has not restarted onto the update reports the fixed version while running the vulnerable build, and the upgrade does not evict a firmware-resident implant from a unit whose management was externally reachable.",
       "ISO-27001-2022-A.8.22": "Segregation of networks is the clause that would have removed the exploit precondition, and it is normally implemented as segregation the Firebox enforces between other networks. The segregation this CVE needed is around the appliance's own management interface — which segments may reach it — and that is rarely in scope when the device under discussion is the thing doing the segregating. AA22-054A's finding that only externally reachable management interfaces were infected makes this the highest-value control on the entry and the one least likely to be applied to the appliance itself."
     },
     "patch_available": true,
@@ -76778,7 +77369,7 @@
       "NIST-800-53-IA-2": "IA-2 authentication is precisely what is spoofed: the DC's machine-account NTLM authentication is coerced and relayed to obtain a certificate, so IA-2's assurance that authenticated identity is genuine collapses when the authentication can be forced and replayed to a different service.",
       "NIS2-Art21-network-security": "Art.21 network security would need to block the outbound coercion and NTLM relay paths and require channel binding, but as commonly implemented it does not mandate the SMB/NTLM egress restrictions and AD CS EPA hardening that actually break the chain — patching the DC alone is insufficient.",
       "UK-CAF-B2": "CAF B2 identity and access control assumes machine and service identities cannot be impersonated, yet coercion-plus-relay turns the DC's own identity into the attacker's certificate; B2 as assessed rarely tests for forced-authentication and relay resistance.",
-      "AU-ISM-1546": "ISM-1546 (authenticating to systems) governs credential use, but a coerced NTLM authentication is a legitimate credential exchange steered to the wrong endpoint; the control does not inherently require the relay mitigations (SMB signing, EPA, NTLM restriction) that defeat this specific abuse.",
+      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before they are granted access to a system, and it sits outside the Essential Eight maturity profiles. On an estate that meets it, the LSARPC methods on a domain controller still accept an unauthenticated call that makes the controller authenticate over NTLM to an attacker's host. The relayed machine-account authentication is a genuine credential, so AD CS web enrollment accepts it while the control is met. ISM-1546 does not require Extended Protection for Authentication, HTTPS on AD CS enrollment or NTLM restriction, and the May 2022 update alone is not a complete defense against the relay.",
       "ISO-27001-2022-A.8.8": "A.8.8 technical-vulnerability management schedules the May 2022 update, but the DC deployment caveat (PIV/CAC breakage) means naive patching risks an outage while incomplete patching leaves the relay open — A.8.8's assessment does not capture the patch-plus-configuration nature of the real fix."
     },
     "patch_available": true,
@@ -84806,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": [
@@ -92582,7 +93173,7 @@
       "NIST-800-53-AC-6": "Least-privilege is meaningless when the sole administrative account uses a universally known default credential reachable from the network.",
       "NIS2-Art21-network-security": "Exposing an OT management protocol (PCOM/20256) to the internet is the enabling condition; network-security baselines frequently omit OT/ICS segmentation for small PLC estates.",
       "UK-CAF-B2": "Identity and access control for OT devices seldom enforces mandatory default-credential change on commissioning, leaving critical-service PLCs trivially accessible.",
-      "AU-ISM-1546": "Privileged/default-account controls are inconsistently applied to embedded OT devices, so the factory password persists on safety-relevant equipment.",
+      "AU-ISM-1546": "ISM-1546 requires that users are authenticated before they are granted access to a system and its resources. Unitronics Vision and Samba PLCs and HMIs running VisiLogic before 9.9.00 authenticate administrators with a password, so the device meets the control on paper while that password is still the factory default. CyberAv3ngers logged in with the publicly known default on internet-exposed units in late 2023, including U.S. water-utility systems. ISM-1546 does not test whether the credential is still the default or whether the device accepts logins from the internet, and the fixed release needs a reboot of the controller.",
       "ISO-27001-2022-A.5.15": "Access-control controls that permit a shared factory-default administrative password to persist provide no assurance; with the credential publicly documented, an unauthenticated network attacker simply logs into the PLC/HMI, and A.5.16 mandates no forced default-credential change at commissioning."
     },
     "patch_available": true,
@@ -92872,7 +93463,7 @@
       "NIST-800-53-CM-7": "Least-functionality does not constrain a legitimate GPU IOCTL surface (kgsl) that any installed app can reach; the privileged driver interface is exposed by design.",
       "ISO-27001-2022-A.8.8": "Vulnerability management for mobile fleets depends on OEM update availability the organization does not control, so a known-exploited kernel LPE stays open on unpatched handsets.",
       "NIS2-Art21-patch-management": "Patch-management cadence cannot force firmware/driver updates onto devices whose vendor has not yet shipped the OEM build, undermining timely remediation of a KEV kernel flaw.",
-      "AU-ISM-1546": "Mobile-device hardening controls rarely account for a GPU-driver LPE that undoes app-sandbox isolation once a malicious app is already present.",
+      "AU-Essential-8-Patch": "The Adreno kgsl flaw is in a GPU driver, and the Essential Eight covers drivers only at Maturity Level Three, where ISM-1879 requires the fix within 48 hours of release when the vendor rates the flaw critical or a working exploit exists. The mobile device operating system updates that carry the fix fall under ISM-1878, which sets the same 48 hours outside the Essential Eight profiles. Qualcomm reported limited, targeted exploitation, yet below Maturity Level Three no Essential Eight window applies. The fix ships at the December 2023 security patch level with a separate build for each device model, and it needs a reboot.",
       "UK-CAF-B4": "System-security for mobile fleets assumes the app sandbox holds, but a GPU-driver (kgsl) integer-overflow LPE reachable by any installed app undoes that isolation, and the fix depends on an OEM/carrier build the operator cannot compel."
     },
     "patch_available": true,
@@ -93994,7 +94585,7 @@
       "NIST-800-53-AC-6": "Least privilege limits what an initial foothold can do, but a DWM-to-SYSTEM LPE by design defeats the privilege boundary; AC-6 alone does not stop kernel/graphics-subsystem token theft.",
       "NIST-800-53-SI-4": "System monitoring is the realistic control for a post-foothold LPE, yet default logging rarely captures the integrity-level jump; without EDR tuned for token manipulation the escalation is invisible.",
       "ISO-27001-2022-A.8.8": "Technical-vulnerability management scheduled on patch cadence cannot address an actively-exploited zero-day LPE; it needs behavioral detection of privilege escalation as a compensating layer.",
-      "AU-ISM-1546": "Applying vendor patches within the ISM timeframe still leaves the zero-day window uncovered; the control does not mandate the EDR/exploit-guard telemetry that would catch DWM token abuse.",
+      "AU-Essential-8-Patch": "Windows 10 and 11 workstations and internal Windows Server 2019 and 2022 hosts fall under ISM-1695, one month from release at Maturity Levels One and Two, and ISM-1696, 48 hours at Maturity Level Three when the flaw is critical or a working exploit exists. This DWM Core Library flaw was exploited as a zero-day before the November 2023 cumulative update, so every window opened after attacks were under way. Below Maturity Level Three a host can keep the vulnerable dwmcore.dll for a month while the flaw is exploited, and an installed update takes effect only after the host restarts.",
       "NIS2-Art21-patch-management": "Timely-patching obligations offer no coverage for the pre-disclosure window this DWM-to-SYSTEM elevation was exploited in — it was a zero-day used before any Patch-Tuesday fix existed, so calendar-based patching leaves the exposure entirely uncovered.",
       "UK-CAF-B4": "System-security assurance assumes the privilege boundary holds, but a graphics-subsystem LPE that jumps a foothold straight to SYSTEM defeats it by design, and default logging rarely captures the integrity-level transition needed to detect it."
     },
@@ -94372,7 +94963,7 @@
       "NIST-800-53-SC-7": "Boundary protection that exposes J-Web to untrusted networks is the exploitation precondition; the durable mitigation is disabling/restricting J-Web, which patch-only remediation ignores.",
       "NIST-800-53-CM-7": "Least functionality would disable the J-Web management interface where feasible, blunting the whole chain, but CM-7 is rarely applied to appliance management planes left internet-reachable.",
       "NIS2-Art21-network-security": "Network-security obligations do not specifically require isolating device management planes; leaving J-Web exposed keeps this chain viable despite general compliance.",
-      "AU-ISM-1546": "Patching within the ISM window helps, but the control does not mandate restricting the J-Web management interface that is the actual attack surface.",
+      "AU-Essential-8-Patch": "A Junos EX switch whose J-Web interface is reachable from the internet is an internet-facing network device, and 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. An internal EX switch falls under ISM-1695, one month at Maturity Levels One and Two. Exploitation attempts began on August 25, 2023, about a week after Juniper's fix and watchTowr's proof of concept, so a switch scheduled on the two-week ISM-1694 window because of its 5.3 base score, or on the one-month window, was still exposed. Each Junos train has its own fixed release, which needs a reboot.",
       "UK-CAF-B4": "System-security for an internet-facing EX-Series appliance assumes management-plane input validation, but an unauthenticated PHP-environment-variable modification that links into a public J-Web RCE chain shows that assurance is absent unless J-Web itself is restricted.",
       "ISO-27001-2022-A.8.8": "Technical-vulnerability management keyed to the CVSS-medium base score under-prioritizes a preauth link in a documented, watchTowr-published RCE chain, so periodic remediation leaves internet-facing devices exploitable despite an existing patch."
     },
@@ -94784,7 +95375,7 @@
       "NIST-800-53-SC-7": "Boundary protection that exposes J-Web is the precondition; segmenting/disabling the management interface is the durable mitigation patch-only remediation ignores.",
       "NIS2-Art21-network-security": "Network-security duties do not mandate management-plane isolation, so an exposed J-Web keeps the unauthenticated upload/download reachable.",
       "UK-CAF-B4": "System-security outcomes assume management interfaces enforce authentication; an unauthenticated file upload/download endpoint defeats that assumption without dedicated management-plane isolation.",
-      "AU-ISM-1546": "Patching within the ISM window does not mandate restricting the exposed webauth_operation.php endpoint whose missing authentication is the unauthenticated upload/download primitive feeding the public SRX RCE chain.",
+      "AU-Essential-8-Patch": "An SRX Series firewall is an internet-facing network device. ISM-1877 requires the fixed Junos release 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 otherwise. With a 5.3 base score this flaw can be scheduled on the two-week window, although a public proof of concept and confirmed exploitation of the unauthenticated webauth_operation.php upload and download meet the working-exploit condition. The fixed build differs per train, such as 21.2R3-S8, 22.2R3-S3 and 22.4R3, and each needs a reboot. No patching control requires J-Web to be restricted until then.",
       "ISO-27001-2022-A.8.8": "Technical-vulnerability management under CVSS-medium scoring deprioritizes an unauthenticated file upload/download endpoint that feeds a public PHPRC-execution chain, delaying remediation of an actively-exploited preauth flaw."
     },
     "patch_available": true,
@@ -95173,7 +95764,7 @@
       "NIST-800-53-SC-7": "The load-bearing mitigation is restricting the management port / self-IP to trusted admin networks; where boundary protection permits broad reach to TMUI, an authenticated SQLi becomes command execution on a critical appliance.",
       "NIST-800-53-AC-6": "Least-privilege on the Configuration utility is undermined because the SQLi escalates any low-privileged authenticated context to system-command execution, breaking the privilege boundary the control assumes.",
       "NIS2-Art21-patch-management": "Patch-management SLAs for network appliances typically lag the F5 hotfix cadence, and this flaw is most dangerous chained with a preauth bypass — a slow patch leaves both halves exploitable.",
-      "AU-ISM-1546": "ISM management-interface segregation guidance is frequently unmet for BIG-IP, leaving the Configuration utility reachable where the SQLi can be exercised.",
+      "AU-Essential-8-Patch": "BIG-IP is an internet-facing network device, so its operating system falls under ISM-1877 at every maturity level: when a working exploit exists, as it does for this KEV-listed SQL injection in the Configuration utility, the fix is applied within 48 hours of release. The fix is split across five branches (17.1.0.3, 16.1.4.1, 15.1.10.2, 14.1.5.6 and 13.1.5.1), and a unit with the fixed release installed but not rebooted still runs the vulnerable code. Units on versions past End of Technical Support have no evaluated fix, and ISM-1501 requires their unsupported software to be replaced with a supported branch, without setting a timeframe.",
       "ISO-27001-2022-A.8.8": "Technical-vulnerability-management closes on the CVE ticket without verifying the management-plane exposure that makes exploitation trivial was actually removed.",
       "UK-CAF-B2": "Identity and access control treats an authenticated Configuration-utility session as low-risk, but this SQLi escalates any authenticated context to system-command execution and, chained with the CVE-2023-46747 auth bypass, needs no legitimate credential at all."
     },
@@ -95662,7 +96253,7 @@
       "NIST-800-53-SC-7": "Boundary protection should keep the device management web UI off the internet; the mass compromise was driven precisely by internet-exposed web UIs.",
       "NIST-800-53-AC-2": "Account-management controls assume accounts are provisioned through governed processes, but the flaw lets an unauthenticated attacker mint a privilege-15 account outside any IAM workflow.",
       "NIS2-Art21-network-security": "Essential-service network-security obligations rarely require disabling/segmenting router management planes, leaving the web UI reachable for exploitation.",
-      "AU-ISM-1546": "ISM management-traffic-segregation guidance is widely unmet for edge routers, so the web UI remains internet-facing and abusable.",
+      "AU-Essential-8-Patch": "Cisco IOS XE on an internet-facing router or switch is the operating system of an internet-facing network device. ISM-1877 requires its fix within 48 hours of release at every maturity level when the vendor rates the flaw critical or a working exploit exists, as one does here. Cisco states the actors exploited previously unknown issues, so devices were compromised before the window opened, and the October 2023 campaign affected tens of thousands of devices. The fix is split across per-train releases such as 17.9.4a, 17.6.6a, 17.3.8a and 16.12.10a, and each one needs a reboot. Patching also leaves in place any privilege 15 account an attacker already created.",
       "UK-CAF-B2": "Identity-and-access-control assumes accounts originate from governed provisioning, but this flaw lets a remote unauthenticated attacker mint a privilege-15 account directly through the web UI, defeating the control outside any IAM workflow.",
       "ISO-27001-2022-A.5.15": "Access-control lifecycle controls govern legitimately-issued accounts; they do not anticipate an unauthenticated attacker fabricating a privilege-15 local account that the mass-exploitation campaign then used as the initial-access half of the 20198+20273 chain."
     },
@@ -95850,7 +96441,7 @@
       "NIST-800-53-AC-6": "Least-privilege on the control plane does not help — the attack presupposes an attacker who already holds legitimate administrative control of a key server or group member, so a compromised-but-authorized KS/GM still weaponizes the OOB write.",
       "NIS2-Art21-network-security": "Network-security baseline controls treat the GET VPN trust domain as internal; they do not validate the integrity of GDOI/G-IKEv2 group-policy attributes exchanged between KS and GM, which is exactly the trust this flaw abuses.",
       "ISO-27001-2022-A.8.8": "Technical-vulnerability management that scans hosts and web apps rarely enumerates IOS/IOS XE feature-level CVEs on GET VPN routers, leaving this class of appliance-firmware flaw untracked.",
-      "AU-ISM-1546": "Patch-application timeframes for network appliances are routinely exceeded because of change-freeze and maintenance-window constraints on core routing gear.",
+      "AU-Essential-8-Patch": "A Cisco IOS or IOS XE router running GET VPN is an internet-facing network device, so ISM-1877 requires the fix within 48 hours of Cisco's release at every maturity level when the vendor rates the flaw critical or a working exploit exists, and ISM-1694 requires it within two weeks otherwise. Cisco PSIRT found this flaw while investigating attempted exploitation of the GET VPN feature, so those attempts came before the release that starts both windows. Fixed releases differ by train, and the fixed image runs only after a reload, which change freezes on core routing gear routinely push past the window.",
       "UK-CAF-B4": "System-security treats the GET VPN group as an internal trust domain, but this out-of-bounds write is reached from a compromised-yet-authorized key server or group member, so integrity of the GDOI/G-IKEv2 group attributes — not perimeter defense — is what the control must actually assure."
     },
     "patch_available": true,
@@ -97161,7 +97752,7 @@
       "NIST-800-53-SC-7": "Boundary protection is the practical mitigation (restrict the console to trusted networks), but SC-7 as commonly implemented still exposes the console to a broad internal segment a compromised admin can reach.",
       "ISO-27001-2022-A.8.8": "Vulnerability management assumes a patch is applied promptly, yet this was a zero-day exploited before the hotfix, so the control lagged the exploitation window.",
       "NIS2-Art21-patch-management": "Patch-management timelines for the security product's own console did not pre-empt the zero-day; the control is insufficient without console network isolation.",
-      "AU-ISM-1546": "Restricting privileged access reduces who can reach the console but does not remove the code-injection sink in the uninstaller module for those who legitimately have access.",
+      "AU-Essential-8-Patch": "Apex One and Worry-Free Business Security are security products. ISM-1691 allows two weeks from release at Maturity Levels One and Two, and ISM-1692 requires 48 hours at Maturity Level Three when the flaw is critical or a working exploit exists. This flaw was exploited as a zero-day before Trend Micro's fix, so every window opened after attacks began, and below Maturity Level Three a console can stay unpatched for two weeks under active exploitation. The fix is split across Apex One 2019 SP1 Patch 1 (B12380), Apex One as a Service agent 14.0.12637, Worry-Free Business Security 10.0 SP1 Patch 2495 and a Worry-Free Business Security Services maintenance release.",
       "UK-CAF-B4": "System-security assurance treats the endpoint-security console as trusted infrastructure, so no compensating monitoring covers the third-party-uninstaller command-execution sink that this zero-day turned a legitimate admin session into RCE through."
     },
     "patch_available": true,
@@ -97903,7 +98494,7 @@
       "NIST-800-53-IA-2": "Identification and authentication is defeated when RA VPN lacks MFA; without phishing-resistant MFA the AAA-separation flaw turns password guessing into valid-account access.",
       "NIST-800-63B-rev4": "Single-factor VPN authentication is below the assurance this flaw demands; the brute-force path is only meaningful because a second factor was not enforced on the default tunnel group.",
       "NIS2-Art21-network-security": "Network-security measures do not by themselves mandate MFA on the RA VPN or lockout on the default group, so the AAA-separation weakness stays exploitable on a compliant deployment.",
-      "AU-ISM-1546": "Requires MFA for remote access but does not force removal/lockdown of the default connection profile that the brute force targets.",
+      "AU-Essential-8-Patch": "An ASA or FTD remote-access VPN gateway is an internet-facing network device. ISM-1877 requires its fixed release within 48 hours of release at every maturity level when the vendor rates the flaw critical or a working exploit exists. Akira and other ransomware operators exploited this flaw as a zero-day, so gateways were under attack before the window opened. No public proof of concept is recorded, and an operator who reads the working-exploit condition as a published exploit applies the two-week ISM-1694 window instead. The fix also needs a reload, and it leaves valid any credentials already found by brute force against the default tunnel group.",
       "UK-CAF-B2": "Identity and access control expects strong authentication yet does not compel the tunnel-group hardening (no-MFA default group disabled, rate-limiting) needed to stop credential brute forcing on the appliance.",
       "ISO-27001-2022-A.5.15": "Access-control does not by itself enforce phishing-resistant MFA or disable the default connection profile the brute force targets, so the AAA-separation flaw turns password guessing into valid RA-VPN access on an otherwise compliant appliance."
     },
@@ -98467,7 +99058,7 @@
       "NIST-800-53-SC-7": "Boundary protection is the crux — RocketMQ's NameServer/Broker/Controller were never meant to face the extranet, so exposing them (no permission verification) turns a config API into preauth RCE that SC-7 segmentation should have prevented.",
       "NIST-800-53-CM-7": "Least functionality is violated when the update-configuration remoting function is reachable unauthenticated; CM-7 does not by default disable/lock down the broker management interface.",
       "NIS2-Art21-network-security": "Network-security measures do not inherently mandate isolating message-broker management ports from untrusted networks, leaving the unauthenticated config path exploitable on a compliant deployment.",
-      "AU-ISM-1546": "Access-control guidance for services does not force authentication on the RocketMQ remoting interface, so the missing permission check remains the exploited gap.",
+      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before they are granted access to a system and its resources. RocketMQ 5.1.0 and below and 4.9.5 and below run the update-configuration function, or a forged RocketMQ protocol message, for any caller that can connect to the NameServer, Broker or Controller, with no permission check. An organization can record authentication for its messaging users while that remoting interface accepts unauthenticated commands, which the DreamBus botnet used to run commands as the RocketMQ service user. ISM-1546 sets no timeframe for this exposure, and the upgrade to 5.1.1 or 4.9.6 falls under the patching controls.",
       "ISO-27001-2022-A.8.8": "Technical-vulnerability management cadence trails an internet-facing preauth RCE with a public Metasploit module and active botnet use.",
       "UK-CAF-B4": "System-security assurance doesn't specifically require isolating RocketMQ's NameServer/Broker/Controller from the extranet, so the unauthenticated updateBrokerConfig command-injection path stays reachable on a nominally compliant deployment and is actively swept by botnets."
     },
@@ -99319,7 +99910,7 @@
       "NIST-800-53-SI-2": "Standard patch-SLA windows exceed the sub-72h due date CISA set under BOD 26-04; the appliance is exposed for the entire remediation lag.",
       "NIS2-Art21-network-security": "Network-security obligations assume the DMZ appliance is a boundary, not a pivot; SSRF collapses that assumption without any perimeter alert.",
       "UK-CAF-B4": "System-security expectations for remote-access gateways do not require egress filtering from the appliance management plane, so metadata/internal SSRF targets stay reachable.",
-      "AU-ISM-1546": "Gateway hardening guidance covers inbound authentication but not appliance-initiated outbound requests, leaving the SSRF egress path uncontrolled.",
+      "AU-Essential-8-Patch": "An SMA1000 remote-access appliance is an internet-facing network device. 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 otherwise. CISA records in-the-wild abuse of this pre-authentication flaw in the Work Place interface, including known ransomware use, so a working exploit exists and the 48-hour window applies at every maturity level although no public proof of concept exists. The vendor update requires a reboot and no live patch exists, so meeting the 48 hours means taking the remote-access gateway down within that window.",
       "ISO-27001-2022-A.8.16": "A.8.16 monitoring will not flag this unauthenticated SMA1000 SSRF because the malicious requests originate from a trusted appliance making outwardly ordinary outbound calls, and there is no baseline of appliance egress to alert against for a CVSS-10 pre-auth flaw."
     },
     "patch_available": true,
@@ -101386,7 +101977,7 @@
       "NIST-800-53-SC-7": "Boundary protection is insufficient when the management interface is deliberately Internet-exposed; SC-7 does not by itself force the management plane off the public Internet.",
       "ISO-27001-2022-A.8.8": "Technical vulnerability management did not prioritize a management-software LFI; A.8.8 lacks a management-plane exposure control.",
       "NIS2-Art21-network-security": "Network-security measures do not mandate isolating device-management portals from untrusted networks, which is the decisive control here.",
-      "AU-ISM-1546": "Internet-facing service hardening guidance is not enforced strongly enough to keep an unauthenticated file-read endpoint off the public edge.",
+      "AU-Essential-8-Patch": "A VigorConnect server reachable from the internet is an online service. A working exploit exists and the flaw is under active exploitation, so ISM-1876 requires the vendor update within 48 hours of release at every maturity level. A server reachable only internally is an other application under ISM-1693, which allows one month from Maturity Level Two. In VigorConnect 1.6.0-B3 and earlier, DownloadFileServlet serves files as root without authentication, and a global campaign reads credentials from exposed servers. The update fixes the servlet but does not change credentials the campaign has already read, and the patch controls do not require rotating them.",
       "UK-CAF-B4": "The system-security principle does not require keeping the VigorConnect management portal off untrusted networks, yet the observed campaign exploited internet-facing appliances where the unauthenticated DownloadFileServlet reads arbitrary files as root."
     },
     "patch_available": true,
@@ -101763,7 +102354,7 @@
       "NIST-800-53-SC-7": "Versa's own guidance was to firewall management ports 4566/4570, but many operators left them internet-reachable; the boundary control was available yet not enforced, enabling the initial upload.",
       "ISO-27001-2022-A.8.9": "Configuration management did not restrict management-plane exposure of the Director appliance, leaving a high-privilege admin function reachable from untrusted networks.",
       "UK-CAF-B4": "System-security hardening for an SD-WAN orchestrator failed to lock down the privileged Change-Favicon upload path, and a memory-resident web shell evades file-integrity monitoring the principle relies on.",
-      "AU-ISM-1546": "The ISM control for restricting web-application file uploads was not applied to the appliance's admin UI, so a dangerous file type masqueraded as a .png and executed.",
+      "AU-Essential-8-Patch": "A Versa Director whose management ports 4566 and 4570 are reachable from the internet is an internet-facing server, so ISM-1877 requires the update within 48 hours of release at every maturity level because a working exploit exists. A Director reachable only from internal networks falls under ISM-1695, with one month at Maturity Levels One and Two, and under ISM-1696 at Maturity Level Three, with 48 hours because a working exploit exists. Attackers exploited the flaw as a zero-day from at least June 2024, before any window began. The update requires a reboot and no live-patching option exists, so each Director stays exposed until it restarts on the fixed build.",
       "NIS2-Art21-network-security": "Network-security controls do not compel firewalling the Versa Director management plane (ports 4566/4570), whose privileged Change-Favicon upload RCE was a nation-state zero-day against telco and ISP SD-WAN orchestrators."
     },
     "patch_available": true,
@@ -102054,7 +102645,7 @@
       "NIST-800-53-SC-7": "Boundary protection is routinely absent for cameras placed directly on the internet or in flat networks; the auth bypass reaches the device's login service with no perimeter mediation.",
       "NIST-800-53-SI-2": "Firmware flaw-remediation is chronically slow for IoT fleets, and many affected Dahua/OEM cameras are end-of-support, so the patch SLA effectively never closes on a large installed base.",
       "NIS2-Art21-network-security": "Network-security obligations rarely enumerate embedded camera firmware, leaving a large unmanaged attack surface exploitable pre-auth.",
-      "AU-ISM-1546": "Multi-factor / strong authentication controls are moot when the device firmware can be tricked into skipping authentication entirely via a spoofed loopback client.",
+      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before they are granted access to a system and its resources, and evidence for it records that each device has an authentication mechanism. The firmware on affected Dahua cameras, NVRs and OEM-rebranded units skips identity authentication for a login packet that names the loopback device as its client, so a remote attacker who claims to be local needs no credentials. Strong or multi-factor credentials configured on the device do not stop it. Internet-exposed units have been recruited into IoT botnets, and only the per-model firmware fix, which requires a reboot, closes the bypass.",
       "UK-CAF-B2": "Identity and access control assumes the device enforces authentication; this flaw removes enforcement below the level any external IAM control can reach.",
       "ISO-27001-2022-A.8.8": "Technical vulnerability management under A.8.8 has no remediation path for end-of-support Dahua/OEM camera firmware, so the loopback-spoof authentication bypass persists on a large installed base the control cannot compel operators to patch or retire."
     },
@@ -102148,7 +102739,7 @@
       "NIST-800-53-IA-2": "The authentication mechanism itself is bypassable via the NetKeyboard packet type, so an identification/authentication control that assumes credentials are checked provides no protection.",
       "NIST-800-53-SC-7": "IoT cameras are routinely exposed directly to the internet; boundary controls are frequently absent for these devices, leaving the preauth bypass reachable at scale.",
       "NIS2-Art21-network-security": "Network-security duties rarely segment CCTV/IoT VLANs from the corporate network, so a bypassed camera becomes a foothold.",
-      "AU-ISM-1546": "Gateway/authentication hardening guidance does not account for firmware that ships an alternate auth path bypassing the primary check.",
+      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before they are granted access to a system and its resources. A Dahua camera, NVR or OEM-rebranded unit with strong credentials configured meets that requirement, yet its firmware lets a login through without identity authentication when the client names the NetKeyboard type. The control governs how the organization configures authentication and does not test the vendor's login code, so a device can pass an assessment while mass scanning and botnets exploit it. ISM-1546 sets no response to the bypass; only the reboot-bearing firmware fix listed in Dahua advisory 957 closes it, under the patching controls.",
       "ISO-27001-2022-A.8.8": "Technical-vulnerability management often excludes long-lived IP-camera firmware from the patch scope, so the flaw persists for years.",
       "UK-CAF-B2": "CAF access-management assurance assumes device authentication is enforced uniformly, but the NetKeyboard alternate-path bypass defeats it across an entire fleet of internet-exposed Dahua cameras that B2 controls seldom inventory as identity endpoints."
     },
@@ -105058,7 +105649,7 @@
     "framework_control_gaps": {
       "NIST-800-53-SI-2": "Mobile-fleet patch rollout depends on OEM/carrier delivery; the targeted zero-day exploitation preceded the June bulletin reaching many devices, leaving the escalation window open.",
       "NIST-800-53-AC-6": "Least-privilege on the device is defeated by the logic error, so an unprivileged app gains system privileges regardless of app-sandbox intent.",
-      "AU-ISM-1546": "Mobile-device patching guidance cannot close a firmware logic flaw until the OEM update lands, so the control is insufficient against active zero-day use.",
+      "AU-Essential-8-Patch": "A Pixel handset is IT equipment other than a workstation, server or network device, so its operating system falls under ISM-1878, which requires the fix within 48 hours of release when a working exploit exists and sits outside the Essential Eight maturity profiles; the firmware falls under ISM-1903 at Maturity Level Three only. Google reported this logic flaw as a zero-day under targeted exploitation, so exploitation began before the June 2024 patch level was released and before any window started. The update also takes effect only after a reboot, which the device user controls unless enrollment enforces it, and no timeframe requires the restart to be complete.",
       "ISO-27001-2022-A.8.8": "Technical-vulnerability management for managed mobiles lacks a compensating control for a firmware-level escalation that no MDM policy can block pre-patch.",
       "UK-CAF-B4": "System-security expectations for endpoint hardening are undermined when a privilege-boundary logic error lets local code escalate to system.",
       "NIS2-Art21-patch-management": "NIS2 patch-management obligations cannot compel the OEM and carrier delivery chain that gates Pixel firmware, so this targeted-zero-day privilege-escalation logic error stayed exploitable until the bulletin reached each device."
@@ -105630,7 +106221,7 @@
       "NIST-800-53-CM-7": "Least-functionality controls did not prevent an unexpected binary (fffmpeg.exe) executing from a trusted installer; CM-7 lacks binary-provenance enforcement.",
       "ISO-27001-2022-A.8.7": "Protection against malware assumes malicious code is externally sourced; A.8.7 does not cover a trusted vendor's own compromised build.",
       "NIS2-Art21-vulnerability-handling": "Supply-chain risk handling under NIS2 does not require verifying installer provenance/authenticode continuity, which is exactly the failure here.",
-      "AU-ISM-1546": "Application-control guidance did not flag an unexpectedly-signed binary within an allowlisted vendor installer, so the implant executed.",
+      "AU-ISM-1452": "ISM-1452 requires a supply chain risk assessment for suppliers of applications, and ISM-1567 excludes suppliers that the assessment rates high risk; both sit outside the Essential Eight profiles. An assessment rates Justice AV Solutions as a supplier rather than each build, so it does not detect a trojanized release such as the JAVS Viewer Setup 8.3.7.250-1 installer, which came through the vendor's software supply chain with a fffmpeg.exe backdoor and an unexpected Authenticode signature. Neither control requires checking an installer's signer against the vendor's established certificate, and a host that ran the installer needs a full reimage because the vendor's update alone does not remove the backdoor.",
       "UK-CAF-B4": "CAF system-security assumes a code-signed vendor installer is trustworthy, but this JAVS Viewer build shipped a backdoored fffmpeg.exe under an unexpected authenticode signature, so assurance that verifies 'signed' without checking signing-provenance continuity let the C2 implant execute."
     },
     "patch_available": true,
@@ -106942,7 +107533,7 @@
       "NIST-800-53-SI-2": "The compressed 2024-05-01 KEV due date reflected active espionage use; SI-2 firmware-patch cycles for perimeter devices are slow relative to a persistent implant that survives reboots.",
       "ISO-27001-2022-A.8.8": "Technical vulnerability management cannot see a root implant that persists across reloads unless image-integrity verification is part of A.8.8, which it usually is not for network appliances.",
       "NIS2-Art21-vulnerability-management": "Vulnerability handling does not detect the persistence mechanism; NIS2 measures assume patching removes the threat, but a pre-existing implant survives the update.",
-      "AU-ISM-1546": "Privileged-access management controls do not prevent a compromised administrator from writing a malicious file to flash, so the ISM control leaves the escalation-to-root path open.",
+      "AU-Essential-8-Patch": "Cisco ASA and FTD appliances are internet-facing network devices, so at every maturity level ISM-1877 requires patches, updates or other vendor mitigations within 48 hours of release when the vendor rates the flaw critical or a working exploit exists. ArcaneDoor's exploitation of this flaw meets the working-exploit condition despite its CVSS score of 6.0. The update needs a reboot the window does not plan for, and the patching controls require no check of disk0: for a crafted file that an administrator account already wrote there, which runs as root on reload and persists across reboots as the Line Runner implant.",
       "UK-CAF-C1": "Security-monitoring and detection-evasion controls do not catch the persistent root implant this ASA/FTD flaw writes to flash during the admin-to-root escalation, so the ArcaneDoor-style implant survives reboots and evades the monitoring CAF-C1 assumes would surface it."
     },
     "patch_available": true,
@@ -107035,7 +107626,7 @@
       "NIST-800-53-SC-7": "SC-7 relies on the firewall as the boundary control, yet the vulnerable web service is exposed on that same boundary device; the control cannot defend the appliance protecting it.",
       "ISO-27001-2022-A.8.8": "Technical vulnerability management under-prioritized management-plane exposure on the edge appliance whose compromise undermines all downstream controls.",
       "NIS2-Art21-network-security": "Network-security measures do not compel restricting ASA/FTD HTTP management and WebVPN exposure, leaving the DoS/implant surface reachable from the Internet.",
-      "AU-ISM-1546": "Gateway-hardening guidance did not force the ASA/FTD management interface off untrusted networks, keeping the crafted-header trigger reachable.",
+      "AU-Essential-8-Patch": "Cisco ASA and FTD appliances are internet-facing network devices, so at every maturity level ISM-1877 requires patches, updates or other vendor mitigations within 48 hours of release when the vendor rates the flaw critical or a working exploit exists, and ISM-1694 allows two weeks otherwise. ArcaneDoor's exploitation of this flaw, chained with CVE-2024-20359, meets the working-exploit condition. The fixed image takes effect only after a reload, which the 48-hour window does not plan for, so a unit staged with the fix but not reloaded still runs the vulnerable HTTP header parser. The patching controls do not require taking the management web server off untrusted networks until then.",
       "UK-CAF-B4": "System-security hardening did not force the ASA/FTD web management and WebVPN interfaces off untrusted networks, leaving the crafted-header infinite-loop DoS (and the ArcaneDoor implant surface) reachable on the very device meant to be the boundary."
     },
     "patch_available": true,
@@ -107786,7 +108377,7 @@
       "NIST-800-53-SC-7": "eMerge E3 access-control panels are frequently exposed directly to the internet; boundary controls that would block the CGI endpoints are commonly absent for physical-security appliances.",
       "NIST-800-53-SI-2": "The device firmware is rarely patched and the flaw has been exploitable for years; standard vulnerability-remediation cadence does not reach unmanaged OT/physical-security gear.",
       "NIS2-Art21-network-security": "Network-security obligations rarely segment physical-access-control systems from IT networks, so a compromised panel pivots into the enterprise.",
-      "AU-ISM-1546": "Gateway/appliance hardening guidance does not cover embedded PHP web stacks on access-control panels that pass input to shell commands.",
+      "AU-Essential-8-Patch": "An eMerge E3-Series panel whose web interface is directly accessible over the internet is an online service. A working exploit exists, so ISM-1876 requires the firmware update within 48 hours of release at every maturity level. A panel reachable only internally is IT equipment other than a workstation, server or network device: its firmware falls under ISM-1903, with 48 hours at Maturity Level Three only, and ISM-1878 is in no Essential Eight profile. Firmware 1.00-06 and earlier is affected. The update needs a reboot that neither window plans for, and IoT botnets including Mirai variants exploit exposed panels without authentication.",
       "ISO-27001-2022-A.8.9": "Configuration-management controls seldom inventory OT/physical-security devices, so the vulnerable panels are neither tracked nor patched.",
       "UK-CAF-B4": "CAF system-security governance seldom extends to OT physical-access-control panels, leaving the eMerge E3's unauthenticated command injection unpatched and unhardened on gear that has been botnet-exploited for years."
     },
@@ -108440,7 +109031,7 @@
       "NIST-800-53-SI-2": "JoomShaper's 6.6.2 patch was reported by a follow-up forum thread as still incomplete (IconsTrait.php not fully patched), meaning flaw-remediation verification needs to go beyond 'version >= 6.6.2'.",
       "NIS2-Art21-vulnerability-management": "Vulnerability-management processes assume a patch fully closes the flaw; community reports of an incomplete fix mean re-verification is required after applying it.",
       "UK-CAF-B4": "Secure-by-default configuration doesn't cover a page-builder task (asset.uploadCustomIcon) that was reachable without authentication or a CSRF token by design.",
-      "AU-ISM-1546": "Application patching guidance is undermined when the vendor's own patch may not fully remediate the flagged code path, per subsequent community reports.",
+      "AU-Essential-8-Patch": "Attackers upload and run PHP files through SP Page Builder, part of a Joomla site's web application, without authentication. An internet-accessible site is an online service, and because CISA listed the flaw as known exploited on 2026-07-07, ISM-1876 requires the fix within 48 hours of release at every maturity level instead of the two weeks in ISM-1690. An internal-only site is an other application under ISM-1693, which allows one month at Maturity Levels Two and Three only. Community reports say the IconsTrait.php code path may remain exploitable after 6.6.2, so recording 6.6.2 meets these controls without showing the upload task is closed. No patching control requires a search for planted PHP files or rogue Super User accounts.",
       "ISO-27001-2022-A.8.8": "Technical vulnerability management requires confirming remediation efficacy, not just patch application — relevant here given the reported incomplete fix."
     },
     "patch_available": true,
@@ -109002,7 +109593,7 @@
       "NIST-800-53-AC-3": "Access enforcement for a locked device assumed the USB Restricted Mode state machine was sound; the authorization flaw let a physical attacker force the device back into an accessible state without credentials.",
       "NIS2-Art21-vulnerability-handling": "Applies to essential-entity endpoint fleets, but personal/BYOD devices used by high-risk individuals (journalists, dissidents, executives) usually sit outside an organization's MDM enforcement entirely.",
       "UK-CAF-B4": "Patch-management objective assumes rapid emergency updates reach the device; a targeted individual whose device is physically seized before they can patch remains exposed regardless of update cadence.",
-      "AU-ISM-1546": "Mobile device hardening guidance (USB Restricted Mode enablement) is itself the control that was bypassed — it provides no defense once the underlying state-management flaw exists.",
+      "AU-Essential-8-Patch": "iPhones and iPads are IT equipment other than workstations, servers and network devices, so ISM-1878 requires the fixed iOS or iPadOS build within 48 hours of release when a working exploit exists, and ISM-1751 allows one month otherwise; neither control is in an Essential Eight maturity profile. Apple split the fix across 15.8.4, 16.7.11, 17.7.5 and 18.3.1, each needing a restart, and its fix notice already cites a report that the flaw may have been exploited against targeted individuals. Enabling USB Restricted Mode does not protect a vulnerable build, because the flaw disables it, and the attack needs physical possession, so network controls do not compensate.",
       "ISO-27001-2022-A.5.7": "Threat intelligence processes rarely track spyware/forensic-tool capability against specific high-risk individuals, so this class of narrowly-targeted exploitation goes unmodeled in most risk assessments."
     },
     "patch_available": true,
@@ -109269,7 +109860,7 @@
       "NIST-800-53-AU-9": "Protection-of-audit-information control is directly undermined — the observed exploitation pattern deletes security logs via link-following, defeating log-integrity assumptions.",
       "NIS2-Art21-incident-handling": "Incident-handling capability depends on intact audit trails; a privilege-escalation bug that lets an attacker delete logs as part of exploitation degrades the evidence NIS2 incident reporting relies on.",
       "UK-CAF-D1": "Response and recovery capability assumes forensic logs survive an intrusion; this flaw was used to delete exactly that evidence.",
-      "AU-ISM-1546": "Endpoint hardening guidance doesn't specifically address symbolic-link-following weaknesses in built-in storage-management components, leaving this class of flaw uncovered.",
+      "AU-Essential-8-Patch": "Windows Storage is part of the operating system. For workstations and non-internet-facing servers, ISM-1695 allows one month at Maturity Levels One and Two, and ISM-1696 requires 48 hours at Maturity Level Three when a working exploit exists; internet-facing servers get 48 hours at every level under ISM-1877. Microsoft and CISA confirm exploitation that deletes security logs, yet below Maturity Level Three workstations can wait a month. No public proof of concept is recorded, so a program that reads working exploit as public code applies the one-month ISM-1902 window at Maturity Level Three as well. Each update also needs a restart.",
       "ISO-27001-2022-A.8.8": "Technical vulnerability management is inherently reactive to zero-days; this flaw was exploited in the wild before a patch existed, so compensating log-integrity controls were needed."
     },
     "patch_available": true,
@@ -109926,7 +110517,7 @@
       "NIST-800-53-AC-3": "Unauthenticated SQL injection against the WebAdmin login endpoint bypasses access enforcement entirely at the authentication layer itself, before any access-control policy is evaluated.",
       "NIS2-Art21-vulnerability-management": "EOL firewall/UTM appliances providing NIS2-regulated network-boundary functions have no vendor remediation path going forward; operators must isolate or replace the appliance, which standard patch-SLA language doesn't capture.",
       "UK-CAF-B4": "Secure-configuration expectations are violated when an internet-exposed WebAdmin management interface remains reachable on an EOL firewall appliance.",
-      "AU-ISM-1546": "ISM patching guidance assumes an available vendor patch exists; for EOL security appliances like this one, the control needs an explicit decommission/replace escalation path, which this flaw exemplifies.",
+      "AU-Essential-8-Patch": "CyberoamOS is the operating system of Cyberoam UTM and NGFW appliances, which are internet-facing network devices. ISM-1877 requires a 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 otherwise. The December 4, 2020 hotfix also covered EOL versions 10.6.2 and later. CyberoamOS is now end-of-life with no further updates, so ISM-1501 requires the operating system to be replaced, and it sets no deadline for doing so. Applying the hotfix does not remove an administrator account that an attacker already created through the injection.",
       "ISO-27001-2022-A.8.28": "Secure-coding practice would have parameterized the CyberoamOS WebAdmin query, but the appliance is end-of-life with no forthcoming fix, so the unauthenticated SQL-injection remains unremediated on any surviving deployment."
     },
     "patch_available": true,
@@ -110042,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": [
@@ -111630,7 +112221,7 @@
       "NIST-800-53-SI-2": "The patch window between disclosure (December 2024) and KEV addition (2025-01-07) was days, far shorter than typical enterprise patch-SLA cycles for UC platforms.",
       "NIS2-Art21-vulnerability-management": "EU operators of MiCollab as unified-communications infrastructure need emergency out-of-cycle patch processes for unauthenticated critical flaws, not standard change-management timelines.",
       "UK-CAF-B4": "Internet exposure of the NuPoint Unified Messaging component to unauthenticated traffic is itself the root cause; network segmentation should have limited exposure regardless of patch status.",
-      "AU-ISM-1546": "Timely patching of internet-facing applications is required, but this flaw was exploited within days of disclosure — faster than most organizations' patch-application SLAs.",
+      "AU-Essential-8-Patch": "A MiCollab deployment whose NuPoint Unified Messaging component is reachable from the internet is an online service, so ISM-1876 requires the fix within 48 hours of release at every maturity level because a working exploit exists. A deployment not reachable from the internet falls under ISM-1693 as another application, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One, although the flaw is actively exploited, listed in CISA KEV with a ransomware association, and frequently chained with CVE-2024-55550. The affected range runs through 9.8 SP1 FP2 (9.8.1.201) and names no fixed build, so the target build has to come from the vendor advisory.",
       "ISO-27001-2022-A.8.8": "A.8.8's periodic technical-vulnerability review cannot close the days-long gap between MiCollab disclosure and KEV addition; because the traversal chains with CVE-2024-55550 for arbitrary file read, the ISMS assessment cycle leaves a ransomware-linked unauth flaw exploitable on the UC platform."
     },
     "patch_available": true,
@@ -111910,7 +112501,7 @@
       "NIST-800-53-SI-2": "There is no patch that changes a hardcoded key baked into shipped code — remediation requires vendor code changes plus per-instance key rotation, which standard flaw-remediation SLAs do not model well.",
       "NIS2-Art21-vulnerability-management": "EU-equivalent public-sector operators of niche vertical software need vendor attestation that cryptographic key material is unique per deployment, which standard vulnerability management processes rarely verify.",
       "UK-CAF-B4": "Third-party/niche software supply-chain assurance failed to catch a hardcoded-key design flaw before deployment across multiple government customers.",
-      "AU-ISM-1546": "Patch-application guidance alone does not address a design-level hardcoded-credential flaw; affected organizations needed vendor-issued unique MachineKey regeneration, not just a version bump.",
+      "AU-Essential-8-Patch": "Where USAHERDS is reachable from the internet it is an online service, and Patch applications requires the fix within 48 hours of release at every maturity level when a working exploit exists (ISM-1876); otherwise it is one of the other applications, patched within one month from Maturity Level Two (ISM-1693). APT41 exploited the shipped ASP.NET keys as a zero-day, so the flaw was open before any window started. The fix also needs a unique MachineKey on each instance. A version check records compliance without showing that the shipped keys were replaced, and an instance that still holds them accepts a forged ViewState.",
       "ISO-27001-2022-A.5.15": "A static, product-wide ASP.NET MachineKey means A.5.15 access-control policy is undermined identically across every USAHERDS deployment, since the shared key lets an attacker forge authenticated ViewState for remote code execution regardless of each organisation's access rules."
     },
     "patch_available": true,
@@ -115009,7 +115600,7 @@
       "ISO-27001-2022-A.8.9": "A.8.9 configuration management didn't extend to the OS-level content-provider path filter this CVE bypassed via Unicode normalization.",
       "NIS2-Art21-vulnerability-management": "Mobile device fleets used by staff at EU essential/important entities are in scope for Art.21 vulnerability management even though patch delivery depends on OEM/carrier cooperation outside the operator's direct control.",
       "UK-CAF-B4": "CAF B4 secure configuration for mobile endpoints; targeted spyware use against civil-society figures raises this above a routine LPE for any organization protecting at-risk personnel.",
-      "AU-ISM-1546": "The ISM's patch-timeframe control for extreme-risk vulnerabilities is difficult to meet given fragmented Android OEM patch-distribution timelines."
+      "AU-Essential-8-Patch": "An Android handset's operating system is IT equipment other than a workstation, server or network device. ISM-1878 requires the fix within 48 hours of release when a working exploit exists, as it does for this KEV-listed flaw exploited in targeted spyware campaigns, and ISM-1751 requires it within one month otherwise; neither control is in an Essential Eight maturity profile. The shouldHideDocument() fix spans Android 12, 12L, 13, 14 and 15 and needs a device restart, and each handset's window starts only when a build carrying it is released for that device."
     },
     "patch_available": true,
     "patch_required_reboot": true,
@@ -115480,7 +116071,7 @@
       "NIST-800-53-SI-4": "Anomaly detection tuned for failed-login counting didn't catch resource-exhaustion-style mass authentication traffic from anonymizing infrastructure before service impact.",
       "NIS2-Art21-network-security": "Network resilience requirements for essential-entity VPN gateways don't universally mandate RAVPN-specific resource-exhaustion protections.",
       "UK-CAF-D1": "Resilience planning for remote-access availability was undermined by a DoS vector requiring only unauthenticated bulk requests.",
-      "AU-ISM-1546": "Patch/mitigation timeframes for network device software assume bounded availability impact; this flaw enabled a full RAVPN outage requiring a device reload.",
+      "AU-Essential-8-Patch": "Cisco ASA and FTD appliances that terminate remote-access VPN are internet-facing network devices, so at every maturity level ISM-1877 requires patches, updates or other vendor mitigations within 48 hours of release when the vendor rates the flaw critical or a working exploit exists. The brute-force campaign Cisco Talos reported in March and April 2024 meets the working-exploit condition for this CVSS 5.8 flaw. The update requires a reboot the window does not plan for, and until it is applied a flood of unauthenticated VPN authentication requests can exhaust RAVPN resources and may leave a device reload as the only way to restore the service.",
       "ISO-27001-2022-A.8.13": "Redundancy provisioning assumes a paired RAVPN gateway preserves availability, but this resource-exhaustion flaw forces a device reload from unauthenticated bulk auth requests, taking down redundant ASA/FTD units alike under distributed flooding."
     },
     "patch_available": true,
@@ -116161,7 +116752,7 @@
       "NIST-800-53-AC-2": "Account-management review processes never surface a hardcoded developer account because it was never provisioned through normal account lifecycle tooling.",
       "NIST-800-63B-rev4": "Authenticator-management guidance assumes operator-issued credentials that can be rotated; a compiled-in credential cannot be rotated by the operator at all.",
       "NIS2-Art21-vulnerability-management": "Vulnerability-management SLAs measured from public disclosure understate exposure — the flaw was exploitable the moment the product shipped.",
-      "AU-ISM-1546": "Application-hardening guidance for internet-facing systems doesn't cover vendor-embedded backdoor-equivalent credentials discoverable only via binary/code review.",
+      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before they are granted access to a system and its resources, and a Web Help Desk server with authentication configured meets it. WHD before 12.8.3 Hotfix 2 contains a hardcoded internal credential, so a remote attacker holding it accesses internal functionality and can read or modify ticket data on a compliant server. Evidence for ISM-1546 records that authentication is in place and does not test for credentials embedded by the vendor. The patching controls set how quickly this closes; CISA added it to the Known Exploited Vulnerabilities catalog on 2024-10-15, about a month after a working proof of concept was published.",
       "UK-CAF-B2": "The CAF's identity-and-access objective governs operator-managed credentials, but a vendor-compiled-in hardcoded credential sits outside any operator identity control — no access policy, rotation, or review the B2 objective mandates can reach a secret baked into the shipped binary.",
       "ISO-27001-2022-A.8.8": "A.8.8 would slot a 9.1 into the normal remediation queue, but a KEV-listed hardcoded-credential auth bypass on a SolarWinds product — a vendor with prior mass-compromise history — is actively exploited and needs emergency out-of-band patching the standard's routine timescale doesn't force."
     },
@@ -117384,7 +117975,7 @@
       "NIST-800-53-SC-7": "SC-7 boundary protection assumes the appliance correctly parses and enforces path restrictions at its network edge; the URL-decoding-order bug let attackers smuggle traversal past the boundary parser entirely.",
       "NIS2-Art21-vulnerability-handling": "NIS2 vulnerability-handling expects prompt remediation, but Ivanti CSA 4.6 was already flagged End-of-Life when the flaw was disclosed, leaving organizations with no vendor-supported patch path other than full migration.",
       "UK-CAF-B4": "CAF B4 (system security) expects hardened, supported system configurations; running an EOL CSA 4.6 branch in production is itself a CAF B4 gap independent of this specific CVE.",
-      "AU-ISM-1546": "ISM control 1546 (patching within timeframes based on severity) cannot be satisfied for a product the vendor states will receive no further security updates.",
+      "AU-Essential-8-Patch": "The Cloud Services Appliance is an internet-facing network device, so ISM-1877 requires the fix within 48 hours of release at every Essential Eight maturity level when a working exploit exists, as it does for this KEV-listed flaw. Patch 519 needs a reboot that the window does not plan for, and the 4.6 branch is End-of-Life with no further security updates, so ISM-1501 then requires the appliance's unsupported operating system to be replaced, with no deadline. Patching also leaves in place any webshell deployed through the chain with CVE-2024-8190.",
       "ISO-27001-2022-A.8.8": "A.8.8 requires tracking and remediating known technical vulnerabilities, but an EOL appliance falls outside normal patch-remediation SLAs, requiring a decommission/migration control instead of a patch cycle."
     },
     "patch_available": true,
@@ -120128,7 +120719,7 @@
       "NIS2-Art21-network-security": "EU NIS2 treats this class as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA; operators typically learn of the flaw via vendor advisory, not a regulatory channel.",
       "DORA-Art-9": "ICT incident management presumes vendor-patch cadence; the appliance/server exposure window opened hours after disclosure, far inside the financial-entity remediation SLA.",
       "UK-CAF-B4": "System security principle is silent on the operational reality that a patched device can still carry attacker persistence seeded before the patch; cleanup/rebuild verification is required, not just patch application.",
-      "AU-ISM-1546": "Essential 8 patch-applications ML3 (48h) is closer to reality than NIST SI-2 but still misses the mass-scanning window for this internet-facing class.",
+      "AU-Essential-8-Patch": "Connect Secure appliances, Policy Secure appliances and Neurons for ZTA gateways exposed to the internet are internet-facing network devices, and ISM-1877 sets 48 hours from release at every maturity level when a working exploit exists. A Policy Secure appliance or ZTA gateway on an internal network falls under ISM-1695 (one month at Maturity Levels One and Two) and ISM-1696 (48 hours at Maturity Level Three when a working exploit exists). Exploitation began by mid-December 2024, before the 2025-01-08 advisory, so it preceded every timeframe. The fixed builds 22.7R2.5, 22.7R1.2 and 22.7R2.3 require a reboot, and an Integrity Checker Tool compromise finding adds a factory reset, rebuild and credential rotation the timeframes do not plan for.",
       "PCI-DSS-4.0-6.3.3": "30-day critical-patch window is exploitation acceptance for an unauthenticated preauth flaw on a perimeter device/server in or adjacent to the CDE."
     },
     "atlas_refs": [],
@@ -120239,7 +120830,7 @@
       "NIS2-Art21-network-security": "EU NIS2 treats this class as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA; operators typically learn of the flaw via vendor advisory, not a regulatory channel.",
       "DORA-Art-9": "ICT incident management presumes vendor-patch cadence; the appliance/server exposure window opened hours after disclosure, far inside the financial-entity remediation SLA.",
       "UK-CAF-B4": "System security principle is silent on the operational reality that a patched device can still carry attacker persistence seeded before the patch; cleanup/rebuild verification is required, not just patch application.",
-      "AU-ISM-1546": "Essential 8 patch-applications ML3 (48h) is closer to reality than NIST SI-2 but still misses the mass-scanning window for this internet-facing class.",
+      "AU-Essential-8-Patch": "Ivanti Connect Secure is a VPN gateway, an internet-facing network device. At every maturity level, ISM-1877 requires its patches within 48 hours of release when the vendor rates a vulnerability critical or a working exploit exists, and ISM-1694 requires them within two weeks otherwise. Ivanti released Connect Secure 22.7R2.6 on 2025-02-11 and rated the flaw a low-risk denial of service, so the two-week window applied, and it ended before the exploitation recorded from mid-March 2025. Policy Secure and ZTA Gateways need their own builds, 22.7R1.4 and 22.8R2.2, and neither control requires the factory reset and rebuild that a gateway with compromise indicators needs.",
       "PCI-DSS-4.0-6.3.3": "30-day critical-patch window is exploitation acceptance for an unauthenticated preauth flaw on a perimeter device/server in or adjacent to the CDE."
     },
     "atlas_refs": [],
@@ -120345,7 +120936,7 @@
       "NIS2-Art21-network-security": "EU NIS2 treats this class as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA; operators typically learn of the flaw via vendor advisory, not a regulatory channel.",
       "DORA-Art-9": "ICT incident management presumes vendor-patch cadence; the appliance/server exposure window opened hours after disclosure, far inside the financial-entity remediation SLA.",
       "UK-CAF-B4": "System security principle is silent on the operational reality that a patched device can still carry attacker persistence seeded before the patch; cleanup/rebuild verification is required, not just patch application.",
-      "AU-ISM-1546": "Essential 8 patch-applications ML3 (48h) is closer to reality than NIST SI-2 but still misses the mass-scanning window for this internet-facing class.",
+      "AU-Essential-8-Patch": "A NetWeaver application server that exposes Visual Composer to the internet is an online service. Because a working exploit exists, ISM-1876 requires SAP Security Note 3594142 within 48 hours of release at every maturity level. An instance reachable only internally is an other application, patched within one month from Maturity Level Two (ISM-1693). No control requires blocking /developmentserver/metadatauploader at the proxy while the window runs, although SAP lists that mitigation. The note closes the upload path but does not remove a JSP webshell written before it was applied, and no patching control requires the webshell hunt or the credential rotation SAP advises.",
       "PCI-DSS-4.0-6.3.3": "30-day critical-patch window is exploitation acceptance for an unauthenticated preauth flaw on a perimeter device/server in or adjacent to the CDE."
     },
     "atlas_refs": [],
@@ -120455,7 +121046,7 @@
       "NIS2-Art21-network-security": "EU NIS2 treats this class as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA; operators typically learn of the flaw via vendor advisory, not a regulatory channel.",
       "DORA-Art-9": "ICT incident management presumes vendor-patch cadence; the appliance/server exposure window opened hours after disclosure, far inside the financial-entity remediation SLA.",
       "UK-CAF-B4": "System security principle is silent on the operational reality that a patched device can still carry attacker persistence seeded before the patch; cleanup/rebuild verification is required, not just patch application.",
-      "AU-ISM-1546": "Essential 8 patch-applications ML3 (48h) is closer to reality than NIST SI-2 but still misses the mass-scanning window for this internet-facing class.",
+      "AU-Essential-8-Patch": "A CrushFTP instance that answers HTTP directly from the internet is an online service. Because a working exploit exists, ISM-1876 requires CrushFTP 10.8.4 or 11.3.1 within 48 hours of release at every maturity level. An instance reachable only internally is an other application, patched within one month from Maturity Level Two (ISM-1693). The vendor offers a DMZ proxy instance as an interim mitigation, and instances behind one are not affected, but no control requires it while the window runs. The upgrade leaves any crushadmin session or account created through the bypass in place, and no patching control requires the audit and credential rotation the vendor lists.",
       "PCI-DSS-4.0-6.3.3": "30-day critical-patch window is exploitation acceptance for an unauthenticated preauth flaw on a perimeter device/server in or adjacent to the CDE."
     },
     "atlas_refs": [],
@@ -121022,7 +121613,7 @@
     },
     "atlas_refs": [
       "AML.T0010",
-      "AML.T0016",
+      "AML.T0110",
       "AML.T0051",
       "AML.T0096"
     ],
@@ -121829,8 +122420,7 @@
     },
     "atlas_refs": [
       "AML.T0010",
-      "AML.T0018",
-      "AML.T0048"
+      "AML.T0018"
     ],
     "attack_refs": [
       "T1195.002",
@@ -122163,7 +122753,7 @@
       "NIS2-Art21-patch-management": "Art. 21(2)(c) patch-management measures are undefined for fast-cycle kernel LPEs with public PoC. No guidance on module-blacklist as an interim measure.",
       "DORA-Art-9": "ICT incident management presumes vendor-patch cadence; module-unload as immediate mitigation has no place in the typical DORA evidence pack.",
       "UK-CAF-B4": "System security principle is silent on subsystem module disable as a compensating control for unpatched kernel LPE.",
-      "AU-ISM-1546": "Essential 8 patch-applications maturity ladder anchors on advisory date, not on PoC availability. ML3 48h is still long for a deterministic public exploit.",
+      "AU-Essential-8-Patch": "The Linux kernel is an operating system, and a proof of concept for Fragnesia exists. On internet-facing servers ISM-1877 requires the fix within 48 hours of release at every maturity level when a working exploit exists. On workstations and internal servers ISM-1695 allows one month at Maturity Levels One and Two, and ISM-1696 requires 48 hours only at Level Three, so an unprivileged local user can overwrite page-cached setuid binaries on a compliant host for a month. Each window starts at the distribution's own kernel release, and no control requires the reboot-free esp4, esp6 and rxrpc module unload in the meantime.",
       "ISO-27001-2022-A.5.7": "Threat-intelligence control collects feeds but does not require the operational pivot (module unload) when intel shows a same-family sequel to a previously-patched bug."
     },
     "atlas_refs": [],
@@ -122597,10 +123187,10 @@
       "ISO-27001-2022-A.8.28": "Secure coding control does not anchor on ML-runtime web-surface review.",
       "NIS2-Art21-network-security": "Network-security measures don't require isolating an internal ML tracking server whose unauthenticated artifact endpoint resolves ../ traversal to read arbitrary host files; MLflow is routinely deployed with no auth on a flat data-science network.",
       "UK-CAF-B4": "Secure-configuration hardening doesn't cover ML tooling stood up by data-science teams outside IT change control, leaving MLflow's unauthenticated get-artifact endpoint reachable to read /etc/passwd and adjacent secrets.",
-      "AU-ISM-1546": "The ISM's web-application hardening guidance isn't applied to self-hosted ML infrastructure, so the tracking server's directory-traversal artifact path stays exposed with no input normalization on the user-controlled path parameter."
+      "AU-Essential-8-Patch": "An internet-accessible MLflow tracking server is an online service. A public proof of concept exists, so ISM-1876 requires mlflow 2.9.0 or later within 48 hours of release at every maturity level, rather than the two weeks ISM-1690 allows when the vendor rates a flaw non-critical and no working exploit exists. A tracking server reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. Until the upgrade, a GET request to /model-versions/get-artifact with a ../ path returns arbitrary host files, such as /etc/passwd, and an internal server can stay exposed for a month, or with no deadline at Maturity Level One."
     },
     "atlas_refs": [
-      "AML.T0016"
+      "AML.T0035"
     ],
     "attack_refs": [
       "T1592"
@@ -123230,7 +123820,7 @@
       "AU-Essential-8-App-Hardening": "Application hardening does not extend to the MCP subprocess-spawn path, where the SDK launches operator-named commands through a shell; the child processes escape the allowlisting premise, giving an attacker who controls the server-spawn string command execution on the host."
     },
     "atlas_refs": [
-      "AML.T0040"
+      "AML.T0050"
     ],
     "attack_refs": [
       "T1059"
@@ -123755,9 +124345,7 @@
       "UK-CAF-B4": "CAF system-security expectations frame remediation as vendor patching, but the real exposure filter for this nginx heap overflow is whether a rewrite directive with unnamed captures is configured, and the config-side live-patch mitigation is not captured.",
       "AU-Essential-8-Patch": "Essential-Eight patch maturity has no urgency trigger for this not-yet-weaponized pre-auth heap RCE, yet its ubiquity on long-deployed web fabric means the real risk turns on rewrite-directive configuration the patch model never inventories."
     },
-    "atlas_refs": [
-      "AML.T0040"
-    ],
+    "atlas_refs": [],
     "attack_refs": [
       "T1190"
     ],
@@ -124688,7 +125276,7 @@
       "NIS2-Art21-patch-management": "Art. 21(2)(c) patch-management measures undefined for fast-cycle kernel LPEs with public PoC. No guidance on sysctl or SUID-removal as interim measures.",
       "DORA-Art-9": "ICT incident management presumes vendor-patch cadence; reboot-required class breaks the standard SLA.",
       "UK-CAF-B4": "System security principle silent on sysctl-based mitigation OR SUID-removal as compensating controls.",
-      "AU-ISM-1546": "Essential 8 patch-applications maturity ML3 = 48h is still long for a deterministic-with-loop kernel LPE; reboot-required nature compounds the maintenance-window cost.",
+      "AU-Essential-8-Patch": "The Linux kernel is an operating system, and two public proofs of concept count as working exploits. ISM-1877 requires the fix on internet-facing servers within 48 hours of release at every maturity level; on workstations and internal servers ISM-1695 allows one month at Maturity Levels One and Two, and ISM-1696 requires 48 hours only at Level Three. The fix needs a reboot and has no live patch, which a 48-hour window does not plan for. It shipped as seven upstream point releases on 2026-05-15 and as distribution backports, AlmaLinux's on 2026-05-16, so each host's window starts on a different day.",
       "ISO-27001-2022-A.5.7": "Threat-intelligence control collects feeds but does not require the operational pivot (sysctl kernel.user_ptrace=0) when intel shows a same-family CVE with public PoC."
     },
     "atlas_refs": [],
@@ -124772,7 +125360,7 @@
       "NIS2-Art21-supply-chain": "Art. 21(2)(d) supply-chain risk measures undefined for self-replicating worm distribution. No guidance on maintainer-credential isolation or registry-side authentication monitoring.",
       "DORA-Art28": "ICT third-party risk management presumes vendor due-diligence; OSS maintainer compromise is outside the vendor-contract framing.",
       "UK-CAF-B4": "System security principle silent on registry-side authentication monitoring for downstream consumers.",
-      "AU-ISM-1808": "Software-supply-chain controls assume vendor-side SBOM truth; Shai-Hulud invalidates by publishing under legitimate maintainer identity.",
+      "AU-ISM-1452": "ISM-1452 requires a supply chain risk assessment for suppliers of applications, and ISM-1567 excludes suppliers rated high risk; both are outside the Essential Eight profiles. Shai-Hulud steals a maintainer's npm token and cloud credentials and publishes infected versions of that maintainer's other packages under the legitimate account, so an assessment of the maintainer still rates them trustworthy. The Mini Shai-Hulud wave that Microsoft reported on 2026-05-11 comprised 404 malicious versions across 170+ npm and 2 PyPI packages. The controls require no post-publish cooldown, no check of the vendor's SBOM against the installed package and no lockfile audit against known-malicious versions such as lightning and pytorch-lightning 2.6.2 and 2.6.3.",
       "SLSA-v1.0-Build-L3": "SLSA L3 build provenance is technically valid for Shai-Hulud-poisoned packages — the malicious build IS provenance-attested under the compromised maintainer's legitimate identity. L3 catches tampered upstream; it does NOT catch legitimately-authenticated malicious upstream.",
       "ISO-27001-2022-A.5.21": "ICT-supply-chain assurance assumes a compromised dependency is upstream tampering, but Shai-Hulud publishes under the legitimate maintainer's authenticated identity after stealing their credentials, so supplier-integrity checks see a valid signed release and the self-replicating worm propagates through the trusted update channel."
     },
@@ -124914,7 +125502,7 @@
       "NIS2-Art21-network-security": "EU NIS2 treats VPN concentrators as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA. Operators in NIS2 sectors typically discovered the vulnerability via vendor advisory, not via the regulatory channel.",
       "DORA-Art-9": "ICT incident management presumes vendor-patch cadence; the appliance-reboot requirement breaks the standard SLA assumption for financial-entity SSL-VPN concentrators.",
       "UK-CAF-B4": "System security principle is silent on the operational reality that fully patched FortiGates can carry attacker persistence (symlink-based filesystem read access) seeded before the patch was applied. Patch alone is insufficient; cleanup verification is required.",
-      "AU-ISM-1546": "Essential 8 patch-applications ML3 (48h) is closer to the operational reality than NIST SI-2 but still misses the mass-scanning window. Internet-facing-appliance class deserves a tighter SLA than general application patching.",
+      "AU-Essential-8-Patch": "FortiOS and FortiProxy appliances with SSL-VPN enabled are internet-facing network devices, so at every maturity level ISM-1877 requires patches, updates or other vendor mitigations within 48 hours of release when the vendor rates the flaw critical or a working exploit exists. Fortinet's 2024-02-08 advisory already stated the flaw was potentially being exploited in the wild. The fix ships as a separate build on each FortiOS branch and needs a reboot the window does not plan for. A device compromised before patching can keep read-only symlinks in the SSL-VPN language-file directory that grant file access on patched builds, and the patching controls require no compromise check.",
       "PCI-DSS-4.0-6.3.3": "30-day critical patch window is exploitation acceptance for an unauthenticated preauth RCE on a perimeter SSL-VPN appliance carrying CDE traffic."
     },
     "atlas_refs": [],
@@ -125674,7 +126262,7 @@
       "PCI-DSS-4.0-10.5": "Logs containing authentication secrets violate scope-isolation assumptions.",
       "NIS2-Art21-vulnerability-management": "Patching Duo Authentication Proxy stops future cleartext-credential emissions but NIS2 vulnerability handling does not compel rotating the AD/LDAP passwords already written to authproxy.log, leaving harvested secrets valid after the fix.",
       "UK-CAF-B2": "CAF B2 assumes credentials are protected in store and transit, but here plaintext AD credentials from password-change operations land in a proxy log any post-compromise lateral mover can read, defeating the identity boundary B2 relies on.",
-      "AU-ISM-1546": "ISM event-logging guidance calls for excluding sensitive data from logs yet does not enforce it on third-party identity middleware, so Duo Proxy's authproxy.log retains recoverable cleartext credentials by default."
+      "AU-Essential-8-Patch": "The Duo Authentication Proxy is a security product, so ISM-1691 requires the fix in 6.5.3 within two weeks of release at Maturity Levels One and Two. At Maturity Level Three, ISM-1692 requires 48 hours when Cisco rates the flaw critical or a working exploit exists, and a proof of concept is public; otherwise ISM-1901 requires two weeks. Upgrading does not remove the cleartext LDAP or AD passwords that debug-level logging already wrote to authproxy.log, and no patching control requires purging that log or resetting the exposed passwords."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -126002,7 +126590,7 @@
       "OWASP-API-Security-Top-10-API4:2023": "Rate-limiting at HTTP layer ineffective against per-connection HTTP/2 stream amplification.",
       "NIS2-Art21-availability": "Availability-class threat under-specified for protocol-implementation bugs.",
       "UK-CAF-D1": "Resilience planning assumes application-layer rate limiting absorbs floods, but MadeYouReset keeps backend work in flight while emitting stream resets, bypassing HTTP/2 concurrency caps to exhaust the server from a single connection.",
-      "AU-ISM-1546": "ISM online-service hardening offers no signature to block this protocol-implementation DoS, and the fix depends on patching each embedded HTTP/2 stack rather than applying a perimeter rule."
+      "AU-Essential-8-Patch": "The affected HTTP/2 stacks run in online services and in the operating systems of internet-facing servers and internet-facing network devices, so ISM-1876 and ISM-1877 require the fix within 48 hours of release when the vendor rates the flaw critical or a working exploit exists, and ISM-1690 and ISM-1694 require it within two weeks otherwise, at every maturity level. A proof of concept exists. Each window starts at a separate release from Netty, Tomcat, Varnish, F5, SUSE or Wind River, and an application that embeds Netty stays exposed until it is rebuilt against 4.1.124.Final or later."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -126160,13 +126748,12 @@
       "NIST-800-53-SI-3": "Inference-server input validation not enumerated; multimodal-input surface novel to most AppSec programs.",
       "EU-AI-Act-Art15": "AI-system robustness controls reference adversarial inputs but not host RCE via multimodal decoder.",
       "ISO-IEC-42001-AIMS": "AI Management System standard lacks specific multimodal-input validation requirement.",
-      "ATLAS-AML.T0048": "ML supply chain — bundled-codec attack surface inside inference servers.",
+      "ATLAS-AML.T0010": "AI supply chain: the bundled-codec attack surface inside inference servers.",
       "UK-CAF-B4": "System-security hardening of the inference host doesn't reach a bundled FFmpeg JPEG2000 decoder reachable from an unauthenticated multimodal API, so a single malicious video URL yields heap-overflow RCE as the GPU-privileged service user.",
       "AU-Essential-8-App-Hardening": "Essential Eight application hardening targets office macros and browsers, not the third-party media codecs shipped inside an LLM inference server, leaving the unauthenticated multimodal decode path that carries this overflow unhardened.",
       "ISO-27001-2022-A.8.28": "Secure-coding controls stop at first-party code, but the heap write is in a bundled decoder; without a memory-safety requirement over vendored codecs the control leaves the RCE surface an unauthenticated request reaches."
     },
     "atlas_refs": [
-      "AML.T0048",
       "AML.T0010"
     ],
     "attack_refs": [
@@ -126333,7 +126920,7 @@
     },
     "atlas_refs": [
       "AML.T0051",
-      "AML.T0040"
+      "AML.T0055"
     ],
     "attack_refs": [
       "T1059",
@@ -126666,7 +127253,7 @@
       "EU-AI-Act-Art10": "Data governance — compromised AI library is in-scope but framework lacks supply-chain control prescription.",
       "OpenSSF-Scorecard-PinnedDependenciesID": "Float-version installs propagate compromise instantly across consumer base.",
       "UK-CAF-B4": "Secure-development and system-security practice does not cover a compromised upstream PyPI wheel injecting a post-install cryptominer, because the trust failure lives in a third-party GitHub Actions build pipeline the operator never runs.",
-      "AU-ISM-1546": "The ISM's software-supply-chain and approved-package guidance does not prevent a float-versioned install pulling a hijacked wheel the instant a maintainer's CI is compromised, propagating across a 60M-download consumer base."
+      "AU-ISM-1452": "ISM-1452 requires a supply chain risk assessment for suppliers of applications, and ISM-1567 excludes suppliers rated high risk; both are outside the Essential Eight profiles. An assessment can rate the Ultralytics project low risk and still miss this compromise: a GitHub Actions script injection added a post-install downloader after code review, and the resulting PyPI wheels downloaded XMRig from attacker infrastructure. The controls do not require version pinning, a post-publish cooldown or a lockfile check, so an unpinned install of this library, which has about 60 million monthly downloads, pulled the miner whenever it resolved to 8.3.41 or 8.3.42; 8.3.43 is a clean release."
     },
     "atlas_refs": [
       "AML.T0010",
@@ -127171,12 +127758,12 @@
       "OWASP-Top-10-2021-A10": "SSRF — directly applicable.",
       "ISO-IEC-42001-AIMS": "AI Management System silent on managed-AI-service supply chain risk.",
       "UK-CAF-B2": "Identity-and-access management assumes the cloud tenant boundary confines a low-privilege user, but this SSRF crosses that boundary into an administrative or cross-tenant context in the Azure OpenAI control plane, escalating without any credential B2 could scope.",
-      "AU-ISM-1546": "ISM control expectations presume the operator can remediate; this AI-discovered SSRF lives in Microsoft's managed Azure OpenAI control plane, so no on-premises hardening or patch action available to an Australian operator addresses a cross-tenant escalation only the provider can fix.",
+      "AU-Essential-8-Patch": "Azure OpenAI is an online service, so ISM-1876 and ISM-1690 apply at every maturity level: vendor mitigations are applied within 48 hours of release when the vendor rates a flaw critical or a working exploit exists, and within two weeks otherwise. Microsoft fixed this SSRF in its managed control plane, which was affected before 2025-08-19, so the tenant has nothing to apply, and the daily scan ISM-1698 requires cannot see the provider-side build. Meeting these controls produces no evidence for the tenant of whether the cross-tenant escalation was used against its resources before the fix.",
       "ISO-27001-2022-A.8.22": "Segregation-of-networks controls assume the cloud provider isolates tenant traffic east-west, yet this SSRF traverses the tenant boundary inside the managed AI control plane, so the segregation A.8.22 credits is enforced by the provider and silently absent here."
     },
     "atlas_refs": [
       "AML.T0024",
-      "AML.T0047"
+      "AML.T0049"
     ],
     "attack_refs": [
       "T1190",
@@ -127253,7 +127840,7 @@
       "EU-AI-Act-Art15": "AI-platform deployment surface not enumerated in robustness controls.",
       "ISO-IEC-42001-AIMS-A.6.2.5": "AI lifecycle controls don't address managed-AI-platform tenant isolation.",
       "UK-CAF-B2": "Identity-and-access control assumes RBAC role boundaries cannot be leveraged to exceed themselves, but a low-privilege tenant abuses a standard RBAC primitive to cross the OpenShift AI control-plane boundary — an escalation the access-management principle treats as prevented rather than as the exploit vector.",
-      "AU-ISM-1546": "Privileged-access controls assume the platform's RBAC enforces the tenant boundary, yet the escalation abuses a legitimate RBAC primitive to reach the AI control plane; restricting who is nominally privileged does not stop a low-privilege tenant from acquiring control-plane rights.",
+      "AU-Essential-8-Patch": "A Red Hat OpenShift AI instance directly accessible from the internet is an online service, and one reachable only from inside the organization is an other application under ISM-1693, which allows one month at Maturity Levels Two and Three only. With no proof of concept and no CISA KEV listing, the internet-accessible instance has two weeks of release under ISM-1690 at every maturity level, or 48 hours under ISM-1876 if Red Hat assesses the flaw as critical. Until the fix is applied, any authenticated low-privilege tenant user can use the RBAC primitive to escalate privileges across the AI control-plane boundary, which restricting privileged accounts does not prevent.",
       "ISO-27001-2022-A.5.15": "Access-control policy assumes role definitions bound the holder, but here a routine low-privilege RBAC primitive is itself the escalation path across the managed OpenShift AI control plane, which policy-level access control does not enumerate or detect."
     },
     "atlas_refs": [
@@ -127656,7 +128243,7 @@
       "NIST-800-53-PE-3": "Physical access control assumes the boundary between 'untrusted hands on the device' and 'unauthorized data access' is the BitLocker encryption layer. YellowKey collapses the boundary at WinRE entry on default-config Windows.",
       "ISO-27001-2022-A.7.1": "Physical security perimeters assume encryption-at-rest holds against opportunistic-physical-access threat actors. The WinRE bypass invalidates that assumption for default-config BitLocker.",
       "UK-CAF-B4": "CAF system-security data-at-rest assurance assumes full-disk encryption defeats a device thief, but the WinRE bypass shows the default TPM-only BitLocker protector unseals the volume key with no user secret, so the encrypted-at-rest control silently fails on the shipped configuration.",
-      "AU-ISM-1546": "The Essential Eight contains no full-disk-encryption or physical-access control at all, and the broader ISM's at-rest-encryption guidance presumes the TPM-sealed key cannot be recovered pre-authentication — an assumption the default TPM-only BitLocker WinRE unseal path violates.",
+      "AU-ISM-1546": "ISM-1546 requires users to be authenticated before they are granted access to a system and its resources. It is outside the Essential Eight profiles and sets no timeframe. A Windows 11, Server 2022 or Server 2025 device with a TPM-only BitLocker protector meets it at sign-in, yet an attacker with physical access who boots it into WinRE and attaches prepared USB media gets a SYSTEM shell in a WinRE session with access to the unsealed volume master key, without authenticating. No vendor fix is available, so the operating system patching windows (ISM-1695, ISM-1696) have not started. Enforcing a TPM and PIN protector adds a pre-boot PIN the bypass cannot inherit.",
       "NIS2-Art21-network-security": "NIS2 Article 21 cryptography and access-control measures are satisfied on paper by enabling BitLocker, but a TPM-only volume that WinRE unseals without a PIN is readable to any physical-access attacker who boots recovery media, so the regime records at-rest-encryption compliance while the master key is released to an untrusted boot path."
     },
     "atlas_refs": [],
@@ -130226,7 +130813,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "The CLFS driver is a serially re-exploited kernel LPE surface; patch-management cycles that batch monthly driver fixes leave a KEV-listed privilege escalation live for weeks after in-the-wild use begins.",
       "UK-CAF-B4": "System-security hardening assumes a current kernel, but this out-of-bounds read in a core Windows logging driver is reachable by any local process, so the principle offers no compensating control until the driver is actually patched.",
-      "AU-Essential-8-Patch": "The Essential-Eight two-week OS-patch target is slower than observed exploitation of this actively-abused CLFS privilege escalation, and macro/application hardening does nothing against a kernel-driver flaw."
+      "AU-Essential-8-Patch": "The CLFS driver is part of Windows and is fixed through Windows operating system updates. For workstations and internal servers, ISM-1695 allows one month from release at Maturity Levels One and Two, and ISM-1696 requires 48 hours at Maturity Level Three, where the public proof of concept meets the working-exploit condition. ISM-1877 applies that 48-hour window to internet-facing Windows servers at every maturity level. Below Maturity Level Three, a workstation or internal server with this CISA-listed, exploited flaw can run the vulnerable driver for a month after release, and the fix needs a reboot before it takes effect. User application hardening does not address a kernel driver flaw."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -131456,7 +132043,7 @@
       "NIS2-Art21-patch-management": "Article 21 risk-management measures mandate timely patching but set no AI-platform-specific origin-policy / session-boundary control; an essential/important entity running Langflow <= 1.6.9 can be Art-21-conformant on paper yet exposed to this drive-by RCE.",
       "DORA-Art-9": "ICT protection/prevention measures require access controls but do not reach application-layer CORS origin policy or SameSite cookie posture on self-hosted AI tooling — the exact boundary this chain abuses.",
       "UK-CAF-B4": "CAF principle B4 (System Security) expects vulnerability remediation but provides no objective for auditing the origin-policy / token-endpoint configuration of code-executing AI-agent platforms.",
-      "AU-ISM-1546": "ISM patch-application control is timeframe-based and product-agnostic; it does not require the CORS allow-list / CSRF posture review that would have closed this chain on Langflow <= 1.6.9.",
+      "AU-Essential-8-Patch": "Langflow is server software. An instance directly accessible over the internet is an online service, and because CISA lists this chain as known exploited, ISM-1876 requires the fix within 48 hours of release at every maturity level. An instance reachable only internally is an other application, and ISM-1693 allows it one month, from Maturity Level Two only, although CrowdSec observed exploitation from 2026-01-23. The upgrade to Langflow 1.7 needs a service restart. The interim CORS allow-list and guarded code-validation endpoint for 1.6.9 and earlier count as vendor mitigations under the same windows, and no patch control requires a review of the CORS and CSRF settings that allowed the chain.",
       "ALL-AI-PIPELINE-INTEGRITY": "No major framework treats the AI-orchestration / agent platform itself as an RCE-bearing trust boundary whose compromise grants control of every downstream flow, credential, and model the platform brokers — nor does any audit the application-layer origin policy (CORS) and session-cookie configuration that this chain abuses."
     },
     "atlas_refs": [],
@@ -131581,7 +132168,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not specifically reach the agent framework's tool-execution sandbox as a control plane.",
       "DORA-Art-9": "ICT protection measures do not treat the AI agent's tool boundary as an attacker-reachable code-execution surface via prompt injection.",
       "UK-CAF-B4": "System Security objective has no objective for sandboxing/auditing the code-execution plugins an AI agent can invoke.",
-      "AU-ISM-1546": "Patch-application control is product-agnostic and does not single out AI-agent SDK dependencies.",
+      "AU-Essential-8-Patch": "Semantic Kernel is an SDK that runs inside the agent application's process, so it is an other application under ISM-1693: patches, updates or other vendor mitigations are applied within one month of release, at Maturity Levels Two and Three only. The fix for this 9.9 path traversal (CWE-22) is split across two packages, Microsoft.SemanticKernel.Plugins.Core 1.71.0 on NuGet and semantic-kernel 1.39.3 on PyPI, and each takes effect only after the dependent application is rebuilt and redeployed. While that month runs, the prompt-injection route to host code execution is publicly documented, and no patching control requires disabling or sandboxing the SessionsPythonPlugin.",
       "ALL-PROMPT-INJECTION-ACCESS-CONTROL": "No compliance framework treats LLM prompt injection as an access-control / code-execution primitive: once an agent can reach a tool that writes files or runs code, injected content crosses from a content-safety problem to host RCE, and no framework requires the tool boundary to be hardened against it."
     },
     "atlas_refs": [
@@ -131696,7 +132283,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach developer-workstation AI tooling whose loopback services are browser-reachable.",
       "DORA-Art-9": "ICT protection measures seldom model a developer's locally-bound MCP tooling as an attacker-reachable RCE surface via the browser.",
       "UK-CAF-B4": "System Security objective has no objective for hardening locally-bound developer AI services against cross-origin / DNS-rebinding access.",
-      "AU-ISM-1546": "Patch-application control does not single out AI/MCP developer tooling, whose RCE flaws compromise the developer's machine and credentials.",
+      "AU-Essential-8-Patch": "MCP Inspector runs a network proxy. A proxy directly accessible over the internet is an online service, and because a proof of concept exists, ISM-1876 requires the upgrade to 0.14.1 within 48 hours of release at every maturity level. A proxy reachable only internally is an other application, and ISM-1693 allows it one month, from Maturity Level Two only, although a malicious web page the developer visits can drive the unauthenticated proxy to run commands on the host. No patching control requires the interim steps of binding Inspector to loopback behind a firewall and not running it where the browser may visit untrusted pages.",
       "ALL-AI-PIPELINE-INTEGRITY": "MCP — the connective tissue of the agent ecosystem — concentrates RCE risk in its tooling; no framework treats the MCP toolchain (inspector, proxy, servers) as a supply-chain control plane whose compromise reaches every connected agent and credential."
     },
     "atlas_refs": [],
@@ -131803,7 +132390,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the trust-on-first-use model of an AI IDE's MCP configuration.",
       "DORA-Art-9": "ICT protection measures do not model an approved-once-then-mutated tool config as a persistent code-execution channel.",
       "UK-CAF-B4": "System Security objective has no objective for re-validating AI-tool configurations after first approval.",
-      "AU-ISM-1546": "Patch-application control does not address the AI-IDE tool-trust class.",
+      "AU-Essential-8-Patch": "Cursor is an AI code editor in the ISM's other applications class, so ISM-1693 requires Cursor 1.3 within one month of release from Maturity Level Two, and Maturity Level One sets no timeframe. A proof of concept exists, and the control still allows the full month. During that month a commit to a shared repository can change an already-approved entry in .cursor/mcp.json to commands that Cursor runs silently on every project open. No control requires the recommended interim review of MCP entries on each pull or a ban on auto-approving MCP servers.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an AI agent's tool-approval state as a control plane requiring re-validation on change; trust-on-first-use turns a shared-repo config edit into silent persistent RCE across every developer who pulls it."
     },
     "atlas_refs": [
@@ -131911,7 +132498,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the MCP stdio transport as a privileged command-execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model 'any authenticated user can run commands as container root via the AI tool transport'.",
       "UK-CAF-B4": "System Security objective has no objective for authorizing and validating commands handed to an AI platform's MCP transport.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-platform MCP transports, whose flaws are container-root RCE.",
+      "AU-Essential-8-Patch": "LibreChat is one of the Essential Eight's other applications, covered from Maturity Level Two by ISM-1693, which requires the upgrade to 0.8.2-rc2 or later within one month of release; ISM-1693 is not part of Maturity Level One. ISM-1876 and its 48 hours for a critical vulnerability or a working exploit apply at every maturity level, but only where the organization runs LibreChat as an internet-facing online service. A proof of concept is public, and until the upgrade is deployed any authenticated user can run shell commands as root in the LibreChat container. The patching controls do not require the vendor's interim measures: limiting who configures MCP servers and running the container as a non-root user.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the MCP stdio transport — which by design launches commands — as a boundary that must enforce authorization and command validation; without it, ordinary user auth becomes container-root RCE."
     },
     "atlas_refs": [],
@@ -132016,7 +132603,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the MCP stdio settings as a privileged command-execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model authenticated command injection via an AI platform's MCP configuration.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing command input handed to an AI platform's MCP transport.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-platform MCP transports.",
+      "AU-Essential-8-Patch": "Tencent WeKnora, an open-source RAG and knowledge-base platform, is one of the Essential Eight's other applications. ISM-1693 requires the upgrade to 0.2.5 within one month of release at Maturity Levels Two and Three, and Maturity Level One does not include that control; ISM-1876 sets 48 hours for a working exploit only where the organization runs WeKnora as an internet-facing online service. A proof of concept is public, and on an internal instance any authenticated user can set the MCP stdio command and run code on the WeKnora host for the month, while the patching controls do not require the vendor's interim limit on who edits those settings.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats user-supplied MCP stdio command/args as untrusted input requiring neutralization; the MCP transport's by-design command execution makes injection a direct RCE."
     },
     "atlas_refs": [],
@@ -132118,7 +132705,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach MCP command configuration as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model command injection via an AI framework's MCP configuration.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing command input handed to an AI framework's MCP transport.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-framework MCP command surfaces.",
+      "AU-Essential-8-Patch": "A Flowise instance directly accessible over the internet is an online service. A proof of concept exists for this 9.9 command injection, so ISM-1876 requires 3.1.0 within 48 hours of release at every maturity level. An instance reachable only from inside the organization is an other application under ISM-1693, so a compliant host can keep a build before 3.1.0 for a month at Maturity Levels Two and Three, and Maturity Level One sets no timeframe. Neither control requires the interim measures for unpatched instances: restricting who can author Custom MCP configurations and running Flowise as a least-privilege container user.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats user-supplied MCP command/args as untrusted input requiring neutralization; the transport's by-design command execution turns injection into direct RCE."
     },
     "atlas_refs": [],
@@ -132219,7 +132806,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach MCP command configuration as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model command injection via an AI framework's MCP configuration.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing command input handed to an AI framework's MCP transport.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-framework MCP command surfaces.",
+      "AU-Essential-8-Patch": "Agent Zero, an autonomous agent framework, runs as a service, and anyone who can supply or influence an MCP server configuration gets remote code execution on its host. An instance directly accessible over the internet is an online service: because a proof of concept exists, ISM-1876 requires its fix within 48 hours of release at every maturity level, and the two-week window in ISM-1690 does not apply. An internal-only instance is an other application, and ISM-1693 allows it one month at Maturity Levels Two and Three only. Version 0.9.8 has no fixed release, so neither window has opened, and no patching control requires restricting who can edit MCP server configurations.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats user-supplied MCP command/args as untrusted input requiring neutralization; the transport's by-design command execution turns injection into direct RCE."
     },
     "atlas_refs": [],
@@ -132314,7 +132901,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach MCP command configuration as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model command injection via an AI framework's MCP configuration.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing command input handed to an AI framework's MCP transport.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-framework MCP command surfaces.",
+      "AU-Essential-8-Patch": "Jaaz runs as a service, and anyone able to set its MCP stdio command gets code execution on the host (CWE-77). An internet-accessible instance is an online service: because a proof of concept exists, ISM-1876 requires its fix within 48 hours of release at every maturity level, and ISM-1690's two-week window does not apply. An internal-only instance is an other application, and ISM-1693 requires its fix within one month of release at Maturity Levels Two and Three only. Version 1.0.30 has no confirmed fixed release, so neither window has started. Until one ships, no patching control requires the interim measures: restricting who configures MCP stdio servers and running Jaaz as a least-privilege user.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats user-supplied MCP command/args as untrusted input requiring neutralization; the transport's by-design command execution turns injection into direct RCE."
     },
     "atlas_refs": [],
@@ -132409,7 +132996,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach MCP command configuration as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model command injection via an AI framework's MCP configuration.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing command input handed to an AI framework's MCP transport.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-framework MCP command surfaces.",
+      "AU-Essential-8-Patch": "Langchain-Chatchat runs as a server whose MCP management interface lets a caller configure a stdio command that the server executes. An instance directly accessible over the internet is an online service: because a proof of concept exists, ISM-1876 requires its fix within 48 hours of release at every maturity level, and the two-week window in ISM-1690 does not apply. An internal-only instance is an other application, and ISM-1693 requires its fix within one month at Maturity Levels Two and Three only. Version 0.3.1 has no fixed release, so neither window has started, and no patching control requires keeping that interface off untrusted networks or running the service as a least-privilege user.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats user-supplied MCP command/args as untrusted input requiring neutralization; the transport's by-design command execution turns injection into direct RCE."
     },
     "atlas_refs": [],
@@ -132504,7 +133091,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach MCP command configuration as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model command injection via an AI framework's MCP configuration.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing command input handed to an AI framework's MCP transport.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-framework MCP command surfaces.",
+      "AU-Essential-8-Patch": "Upsonic falls in the Essential Eight's other-applications class, so ISM-1693 requires vendor updates within one month of release at Maturity Levels Two and Three, with no timeframe at Maturity Level One. Version 0.72.0 adds a warning rather than a confirmed fix, so an organization can apply it inside the month and record the control as met while anyone able to create an MCP task may still abuse the allowed npm and npx arguments to run OS commands on the host. The control does not test whether an applied update closes the vulnerability.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats user-supplied MCP command/args as untrusted input requiring neutralization; the transport's by-design command execution turns injection into direct RCE."
     },
     "atlas_refs": [],
@@ -132599,7 +133186,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the MCP stdio configuration as a privileged, unauthenticated execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model unauthenticated command injection via an AI assistant's MCP configuration.",
       "UK-CAF-B4": "System Security objective has no objective for authenticating and neutralizing command input handed to an AI assistant's MCP transport.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-assistant MCP transports.",
+      "AU-Essential-8-Patch": "DocsGPT accepts requests over the network, so an instance directly accessible over the internet is an online service. A crafted payload bypasses its MCP validation step and runs a stdio transport's shell command (CWE-77, 9.8), giving an unauthenticated attacker code execution on the host. Because a proof of concept exists, ISM-1876 requires 0.16.0 within 48 hours of release at every maturity level for such an instance. For an internal instance, ISM-1693 requires it within one month at Maturity Levels Two and Three and does not apply at Maturity Level One. No control requires the vendor's interim steps: keeping DocsGPT off untrusted networks, restricting MCP configuration and running a least-privilege container user.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework requires the MCP transport to authenticate callers and neutralize the stdio command; a bypassable validation step is not an authorization boundary."
     },
     "atlas_refs": [],
@@ -132709,7 +133296,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not enforce the sub-week remediation cadence an actively-exploited unauthenticated CMS SQLi demands.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated SQL injection in a third-party CMS core as an ICT-risk event with a regulator clock.",
       "UK-CAF-B4": "System Security objective has no objective for verifying parameterization in the CMS database abstraction layer.",
-      "AU-ISM-1546": "Patch-application control does not single out actively-exploited CMS-core injection for accelerated remediation."
+      "AU-Essential-8-Patch": "A Drupal site reachable from the internet is an online service, so ISM-1876 requires the SA-CORE-2026-004 release within 48 hours at every maturity level because a working exploit exists; an internal instance is another application, with one month under ISM-1693 only from Maturity Level Two. Exploitation of PostgreSQL-backed sites followed within days of disclosure, well inside that month. The fix is split across six branch releases, and sites on 8.9 through 10.3 or on 11.0 have no fixed release on their own branch and must move up to one."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -132811,7 +133398,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach AI-inference IPC deserialization as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model insecure deserialization in an AI inference engine as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating data deserialized from an inference engine's socket.",
-      "AU-ISM-1546": "Patch-application control does not single out AI inference engines, nor the code-reuse propagation of one flaw across many.",
+      "AU-Essential-8-Patch": "TensorRT-LLM runs as an inference server. An instance directly accessible over the internet is an online service under ISM-1876 and ISM-1690 at every maturity level; a proof of concept exists, so ISM-1876 requires the upgrade to 0.18.2 within 48 hours of release. An instance reachable only internally is an other application, and ISM-1693 sets one month at Maturity Levels Two and Three, with no shorter window for a working exploit. The proof of concept lets an attacker with local access to the server run code by sending pickle data to the Python executor's ZeroMQ socket, and no control requires NVIDIA's interim measures of restricting local access and isolating the socket.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an inference engine's socket serialization as untrusted input requiring a safe serializer; code reuse spread the same CWE-502 across vLLM, TensorRT-LLM, Llama Stack and Modular Max."
     },
     "atlas_refs": [
@@ -132914,7 +133501,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach AI-inference IPC deserialization as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model insecure deserialization in an AI inference engine as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating data deserialized from an inference engine's socket.",
-      "AU-ISM-1546": "Patch-application control does not single out AI inference engines, nor the code-reuse propagation of one flaw across many.",
+      "AU-Essential-8-Patch": "A vLLM instance directly accessible over the internet is an online service. Because a proof of concept exists, ISM-1876 requires patches or other vendor mitigations within 48 hours of release at every maturity level, in place of ISM-1690's two weeks. An internal-only instance is an other application under ISM-1693, with one month at Maturity Levels Two and Three. The maintainers shipped no code fix; the V0-off default since 0.8.0 is the mitigation. A multi-node deployment that still needs V0 meets ISM-1876 or ISM-1693 only by isolating the ZeroMQ socket on a trusted network segment within the same window. With no code fix, the control is then met while any host on that segment, including a compromised node, can still run code on the worker.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an inference engine's socket serialization as untrusted input requiring a safe serializer; code reuse spread the same CWE-502 across vLLM, TensorRT-LLM, Llama Stack and Modular Max."
     },
     "atlas_refs": [
@@ -133018,7 +133605,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach AI-inference IPC deserialization as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model insecure deserialization in an AI inference engine as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating data deserialized from an inference engine's socket.",
-      "AU-ISM-1546": "Patch-application control does not single out AI inference engines, nor the code-reuse propagation of one flaw across many.",
+      "AU-Essential-8-Patch": "A Meta Llama Stack server with an internet-accessible inference socket is an online service. Because a proof of concept exists, ISM-1876 requires the fix within 48 hours of release at every maturity level. An instance reachable only from inside the organization is an other application under ISM-1693, which requires the fix within one month at Maturity Levels Two and Three only. Releases before 0.0.41 deserialize pickle data from the socket without validation, so any network client that connects can run code. Release 0.0.41 replaces pickle with JSON, and no control requires isolating the socket on a trusted segment until it is deployed.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an inference engine's socket serialization as untrusted input requiring a safe serializer; code reuse spread the same CWE-502 across vLLM, TensorRT-LLM, Llama Stack and Modular Max."
     },
     "atlas_refs": [
@@ -133122,7 +133709,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach AI-inference IPC deserialization as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model insecure deserialization in an AI inference engine as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating data deserialized from an inference engine's socket.",
-      "AU-ISM-1546": "Patch-application control does not single out AI inference engines, nor the code-reuse propagation of one flaw across many.",
+      "AU-Essential-8-Patch": "Modular Max Server is an AI inference server. An instance directly accessible over the internet is an online service, and because a proof of concept exists for the pickle deserialization in the KVCache agent, ISM-1876 requires version 25.6.0 within 48 hours of release at every maturity level. An instance reachable only internally is an other application, and ISM-1693 allows it one month from Maturity Level Two, with no timeframe at Maturity Level One. No patch control requires the recommended interim step of running without --experimental-enable-kvcache-agent. The fix is an application redeploy, so ISM-1877, the window for internet-facing server operating systems, does not apply to it.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an inference engine's socket serialization as untrusted input requiring a safe serializer; code reuse spread the same CWE-502 across vLLM, TensorRT-LLM, Llama Stack and Modular Max."
     },
     "atlas_refs": [
@@ -133224,7 +133811,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the AI inference server's authentication layer as a privileged control plane.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated bypass of an AI inference server's control plane as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for proving authentication covers every path into the inference server.",
-      "AU-ISM-1546": "Patch-application control does not single out network-exposed AI inference servers.",
+      "AU-Essential-8-Patch": "NVIDIA Triton Inference Server listens on HTTP and gRPC endpoints, and this 9.8 CWE-288 flaw lets an unauthenticated attacker gain privileged access through an alternate path. An instance directly accessible over the internet is an online service, and because a proof of concept exists, ISM-1876 requires the r26.03 upgrade within 48 hours of release at every maturity level. An instance reachable only internally is an other application: ISM-1693 requires the upgrade within one month at Maturity Levels Two and Three, with no shorter window for a critical flaw, and does not apply at Maturity Level One. No control requires the vendor's interim authenticating reverse proxy.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework requires the AI inference server's authentication to be proven complete across all request paths; an alternate-path bypass exposes the model control plane unauthenticated."
     },
     "atlas_refs": [
@@ -133326,7 +133913,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the AI inference server's authentication layer as a privileged control plane.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated bypass of an AI inference server's control plane as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for proving authentication covers every path into the inference server.",
-      "AU-ISM-1546": "Patch-application control does not single out network-exposed AI inference servers.",
+      "AU-Essential-8-Patch": "NVIDIA Triton Inference Server is one of the Essential Eight's other applications, so ISM-1693 requires the upgrade to r26.03 within one month of release at Maturity Levels Two and Three, and Maturity Level One does not include that control. ISM-1876 requires 48 hours for a critical vulnerability or a working exploit only where Triton runs as an internet-facing online service. A proof of concept is public. On an internal deployment, anyone who can reach the HTTP or gRPC endpoints can use the alternate path to privileged functionality without credentials for the whole month, and the patching controls do not require the vendor's interim authenticating reverse proxy.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework requires the AI inference server's authentication to be proven complete across all request paths; an alternate-path bypass exposes the model control plane unauthenticated."
     },
     "atlas_refs": [
@@ -133430,7 +134017,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not address a disputed, no-patch vulnerability whose only remediation is configuration and network control.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated, actively-exploited AI compute control plane as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to authenticate the AI compute framework's job submission API.",
-      "AU-ISM-1546": "Patch-application control offers nothing for a disputed, no-patch flaw remediated only by configuration.",
+      "AU-Essential-8-Patch": "Anyscale disputes the flaw and ships no code patch, but Ray 2.52.0 adds token authentication, which operators must enable. If that release counts as the vendor mitigation, ISM-1876 requires token authentication within 48 hours of its release on an internet-accessible cluster, an online service, at every maturity level, because the flaw is mass exploited. ISM-1693 requires it within one month on a cluster reachable only from inside the organization, an other application, at Maturity Levels Two and Three only. The ShadowRay 2.0 campaign has exploited the unauthenticated Job Submission API since September 2024, and reporting counts about 230,000 internet-exposed Ray environments. Neither control requires the network restriction the vendor directs.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework rejects the 'controlled network is the security control' assumption for AI compute; an exposed, unauthenticated Job API is RCE plus AI-artifact and credential theft."
     },
     "atlas_refs": [
@@ -133540,7 +134127,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the AI chat app's dynamic-code paths as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model code injection via an AI front end's tool or model-connection features.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing strings the AI app executes as code.",
-      "AU-ISM-1546": "Patch-application control does not single out self-hosted AI chat front ends.",
+      "AU-Essential-8-Patch": "Where an Open WebUI server is directly reachable from the internet, it is an online service: ISM-1876 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-1690 allows two weeks otherwise. A public proof of concept exists, so an exposed server must be patched within 48 hours. An internal-only deployment falls under ISM-1693 for other applications, which allows one month and applies only at Maturity Levels Two and Three. An authenticated attacker can run Python on the host through load_tool_module_by_id, and no patching control requires restricting who can configure tools while the window runs.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats tool-module strings or external-model-server content as untrusted input the AI app must not execute as code."
     },
     "atlas_refs": [
@@ -133643,7 +134230,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the AI chat app's dynamic-code paths as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model code injection via an AI front end's tool or model-connection features.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing strings the AI app executes as code.",
-      "AU-ISM-1546": "Patch-application control does not single out self-hosted AI chat front ends.",
+      "AU-Essential-8-Patch": "An Open WebUI instance that users access over the internet is an online service, so ISM-1876 requires the 0.6.35 fix within 48 hours of release when the vendor rates the flaw critical or a working exploit exists, and ISM-1690 requires it within two weeks otherwise, at every maturity level. An internal deployment is an other application under ISM-1693, with one month from Maturity Level Two and no timeframe at Maturity Level One. A proof of concept exists, and none of these controls requires turning off Direct Connections, the feature the attack depends on, while the window runs.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats tool-module strings or external-model-server content as untrusted input the AI app must not execute as code."
     },
     "atlas_refs": [
@@ -133750,7 +134337,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the GPU container runtime as a privileged isolation boundary requiring rapid patching.",
       "DORA-Art-9": "ICT protection measures do not model a GPU-runtime container escape as an ICT-risk event crossing tenant boundaries.",
       "UK-CAF-B4": "System Security objective has no objective for the GPU container runtime as an isolation boundary.",
-      "AU-ISM-1546": "Patch-application control does not single out the GPU container runtime that underpins AI workloads.",
+      "AU-Essential-8-Patch": "NVIDIA Container Toolkit and the NVIDIA GPU Operator are applications outside the named office, browser, email, PDF and security product classes, so ISM-1693 covers them from Maturity Level Two with patches applied within one month of release; no patching control applies at Maturity Level One. The fix is split across two products, Container Toolkit 1.16.2 and GPU Operator 24.6.2, and the runtime has to be restarted after the upgrade. ISM-1693 keeps the one-month window for this container escape to the host although a proof of concept exists, and it does not require the interim step of running no untrusted container images on GPU nodes.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the GPU container runtime as an AI-pipeline trust boundary; an escape exposes co-tenant models, data and credentials on shared GPU hosts."
     },
     "atlas_refs": [],
@@ -133852,7 +134439,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the GPU container runtime as a privileged isolation boundary requiring rapid patching.",
       "DORA-Art-9": "ICT protection measures do not model a GPU-runtime container escape as an ICT-risk event crossing tenant boundaries.",
       "UK-CAF-B4": "System Security objective has no objective for the GPU container runtime as an isolation boundary.",
-      "AU-ISM-1546": "Patch-application control does not single out the GPU container runtime that underpins AI workloads.",
+      "AU-Essential-8-Patch": "The NVIDIA Container Toolkit and GPU Operator are other applications, so ISM-1693 requires their fix within one month of release, and only at Maturity Levels Two and Three. The fix is split across Container Toolkit 1.17.8 and GPU Operator 25.3.1, and applying it means restarting the container runtime. A three-line Dockerfile is enough to make the root-privileged hook load an attacker's library through LD_PRELOAD, yet ISM-1693 still allows one month, and no control requires keeping untrusted images off GPU nodes or limiting who can schedule GPU workloads before the upgrade.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the GPU container runtime as an AI-pipeline trust boundary; an escape exposes co-tenant models, data and credentials on shared GPU hosts."
     },
     "atlas_refs": [],
@@ -133953,7 +134540,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach ML model loading as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model untrusted-model-artifact loading as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating model artifacts as untrusted code.",
-      "AU-ISM-1546": "Patch-application control does not single out ML frameworks' model-loading paths.",
+      "AU-Essential-8-Patch": "Keras belongs to the other applications class, so ISM-1693 requires its fix to be applied within one month of release at Maturity Levels Two and Three, and Maturity Level One sets no patching requirement for it. The class has no 48-hour tier, so a CVSS 9.8 flaw with a public proof of concept keeps the full month. Keras 3.8.0 adds the safe_mode mitigation, but the remediation guidance notes that safe_mode alone is insufficient (CVE-2025-8747) and that untrusted .keras models must not be loaded, which no patching control requires.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model file as untrusted executable input; loading one from an untrusted source is RCE, and safe_mode proved necessary-but-insufficient."
     },
     "atlas_refs": [
@@ -134061,7 +134648,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach ML model loading as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model untrusted-model-artifact loading as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating model artifacts as untrusted code.",
-      "AU-ISM-1546": "Patch-application control does not single out ML frameworks' model-loading paths.",
+      "AU-Essential-8-Patch": "Keras is in the ISM's other-applications class, so ISM-1693 requires patches, updates or vendor mitigations for it within one month of release, at Maturity Levels Two and Three only; Maturity Level One sets no timeframe for it. ISM-1693 has no shorter window when a working exploit exists, and a proof of concept for this flaw is public. The safe_mode mitigation that Keras 3.8.0 added for CVE-2025-1550 is bypassable through 3.10.0, so an environment that applied that update on time stayed exposed. The upgrade guidance still says never to load .keras models from untrusted sources, and no patching control governs where models come from.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model file as untrusted executable input; loading one from an untrusted source is RCE, and safe_mode proved necessary-but-insufficient."
     },
     "atlas_refs": [
@@ -134167,7 +134754,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the inference RPC backend as a privileged, unauthenticated control plane.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated inference-RPC memory-corruption RCE as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating deserialized tensor bounds in the inference RPC backend.",
-      "AU-ISM-1546": "Patch-application control does not single out the local-LLM runtime's RPC backend.",
+      "AU-Essential-8-Patch": "An internet-accessible llama.cpp RPC server is an online service. A proof of concept exists, so ISM-1876 requires the fix within 48 hours of release at every maturity level. A server reachable only from inside the organization is an other application under ISM-1693, which requires the fix within one month at Maturity Levels Two and Three only. Before build b3561, a SET_TENSOR message to the unauthenticated RPC server, by default on port 50052, gives any client with TCP access an arbitrary-address write and code execution. No control requires taking the server off untrusted networks while it is rebuilt and redeployed on b3561 or later.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the inference RPC backend's deserialized tensors as untrusted input requiring bounds validation on every command path; per-command patching left GRAPH_COMPUTE exploitable."
     },
     "atlas_refs": [
@@ -134272,7 +134859,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the inference RPC backend as a privileged, unauthenticated control plane.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated inference-RPC memory-corruption RCE as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating deserialized tensor bounds in the inference RPC backend.",
-      "AU-ISM-1546": "Patch-application control does not single out the local-LLM runtime's RPC backend.",
+      "AU-Essential-8-Patch": "The llama.cpp RPC server on port 50052 has no authentication, so any client with TCP access can send a GET_TENSOR message that reads an arbitrary address, leaking pointers that defeat ASLR for the companion write flaw, and a proof of concept exists. An internet-accessible server is an online service, so ISM-1876 requires build b3561 within 48 hours of release at every maturity level rather than the two weeks in ISM-1690. An internal-only server is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. No patching control requires binding the server to localhost or a trusted segment while the window runs.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the inference RPC backend's deserialized tensors as untrusted input requiring bounds validation on every command path; per-command patching left GRAPH_COMPUTE exploitable."
     },
     "atlas_refs": [
@@ -134375,7 +134962,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the inference RPC backend as a privileged, unauthenticated control plane.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated inference-RPC memory-corruption RCE as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating deserialized tensor bounds in the inference RPC backend.",
-      "AU-ISM-1546": "Patch-application control does not single out the local-LLM runtime's RPC backend.",
+      "AU-Essential-8-Patch": "A llama.cpp RPC server directly accessible over the internet is an online service. A proof of concept exists, so ISM-1876 requires build b8492 within 48 hours of release at every maturity level. An RPC server reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. Build b3561 hardened only the GET_TENSOR and SET_TENSOR handlers, so a deployment updated for CVE-2024-42478 and CVE-2024-42479 met either control while GRAPH_COMPUTE messages still reached the unvalidated path. Remediation requires rebuilding and redeploying, and no patching control requires keeping the unauthenticated RPC server, on default port 50052, off untrusted networks.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the inference RPC backend's deserialized tensors as untrusted input requiring bounds validation on every command path; per-command patching left GRAPH_COMPUTE exploitable."
     },
     "atlas_refs": [
@@ -134479,7 +135066,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the AI model server's management plane as a privileged, unauthenticated control plane.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated model-server takeover as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to authenticate the AI model server's management API.",
-      "AU-ISM-1546": "Patch-application control does not single out AI model servers and their bundled deserialization libraries.",
+      "AU-Essential-8-Patch": "An internet-accessible TorchServe server is an online service. A public proof of concept exists, so ISM-1876 requires the 0.8.2 upgrade within 48 hours of release at every maturity level, rather than the two weeks ISM-1690 allows when the vendor rates a flaw non-critical and no working exploit exists. A server reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. Before 0.8.2, an unauthenticated attacker who reaches the management API, which binds to all interfaces by default, runs code through a malicious model configuration. Oligo found thousands of exposed instances. No patching control requires the vendor's other steps: binding that API to loopback, enabling a token and restricting allowed_urls.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the model server's management API + config deserialization as an untrusted, RCE-bearing surface; default-open management plus unsafe YAML turns config upload into full takeover."
     },
     "atlas_refs": [
@@ -134584,7 +135171,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the AI model server's management plane as a privileged, unauthenticated control plane.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated model-server takeover as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to authenticate the AI model server's management API.",
-      "AU-ISM-1546": "Patch-application control does not single out AI model servers and their bundled deserialization libraries.",
+      "AU-Essential-8-Patch": "SnakeYAML is bundled into applications, so the timeframe depends on the application that bundles it. Where TorchServe or another application that bundles SnakeYAML is directly reachable from the internet, such as the thousands of exposed TorchServe instances Oligo found, it is an online service. Because a public proof of concept exists, ISM-1876 requires the fix within 48 hours at every level, where ISM-1690 would otherwise allow two weeks. An internal deployment is an other application under ISM-1693: one month from Maturity Level Two, with no Maturity Level One timeframe. Each bundled copy needs its own upgrade to SnakeYAML 2.0, and TorchServe also needs the CVE-2023-43654 mitigations to keep untrusted model configurations away from the parser.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the model server's management API + config deserialization as an untrusted, RCE-bearing surface; default-open management plus unsafe YAML turns config upload into full takeover."
     },
     "atlas_refs": [
@@ -134689,7 +135276,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the local-LLM runtime API as a privileged surface.",
       "DORA-Art-9": "ICT protection measures do not model path traversal in an AI runtime API as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating paths/digests in the model-runtime API.",
-      "AU-ISM-1546": "Patch-application control does not single out local-LLM runtimes.",
+      "AU-Essential-8-Patch": "An Ollama API directly accessible over the internet is an online service, so ISM-1876 requires the 0.1.34 fix within 48 hours of release at every maturity level because a public Metasploit module exists, rather than the two weeks in ISM-1690. An internal-only instance is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One, yet a model pull from a rogue registry still writes attacker-controlled content to an arbitrary path on it. Until the upgrade, port 11434 has to stay off untrusted networks and models have to come only from trusted registries.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the model-runtime API's path/digest handling as untrusted input; a rogue registry or crafted request reaches the filesystem."
     },
     "atlas_refs": [
@@ -134794,7 +135381,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the local-LLM runtime API as a privileged surface.",
       "DORA-Art-9": "ICT protection measures do not model path traversal in an AI runtime API as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating paths/digests in the model-runtime API.",
-      "AU-ISM-1546": "Patch-application control does not single out local-LLM runtimes.",
+      "AU-Essential-8-Patch": "Every Ollama build before 0.1.46 lets an unauthenticated request to the api/push route learn whether a path exists on the server, which aids further exploitation, and a proof of concept exists. An internet-accessible instance is an online service, so ISM-1876 requires 0.1.46 within 48 hours of release at every maturity level, where ISM-1690 would allow two weeks for a flaw the vendor rates non-critical with no working exploit. An internal-only instance is an other application under ISM-1693, which gives the full month at Maturity Levels Two and Three despite the proof of concept and sets no timeframe at Maturity Level One. Until the upgrade, keeping port 11434 off untrusted networks is the only protection.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the model-runtime API's path/digest handling as untrusted input; a rogue registry or crafted request reaches the filesystem."
     },
     "atlas_refs": [
@@ -134898,7 +135485,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the ML demo framework as a privileged, internet-exposed surface.",
       "DORA-Art-9": "ICT protection measures do not model file-read / SSRF in an ML demo framework leaking host secrets as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for directory containment on the ML framework's file routes.",
-      "AU-ISM-1546": "Patch-application control does not single out ML demo/UI frameworks.",
+      "AU-Essential-8-Patch": "A crafted unauthenticated request to /component_server on Gradio 4.12.0 up to but excluding 4.13.0 copies a host file into the served cache and reads it. A Gradio app reachable from the internet, such as a Hugging Face Space, is an online service: ISM-1876 requires the patch within 48 hours of release at every maturity level when the vendor rates the flaw critical or a working exploit exists, and ISM-1690 requires it within two weeks otherwise. An app not reachable from the internet falls under ISM-1693, one month at Maturity Levels Two and Three and no timeframe at Maturity Level One, although a proof of concept exists. Upgrading to 4.13.0 does not revoke secrets or tokens already read from a Hugging Face Spaces host, and no patch control requires rotating them.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the ML demo framework's file-serving / component routes as an untrusted-input access-control surface; a public Gradio app leaks host secrets (HF Spaces tokens)."
     },
     "atlas_refs": [
@@ -135004,7 +135591,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the ML demo framework as a privileged, internet-exposed surface.",
       "DORA-Art-9": "ICT protection measures do not model file-read / SSRF in an ML demo framework leaking host secrets as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for directory containment on the ML framework's file routes.",
-      "AU-ISM-1546": "Patch-application control does not single out ML demo/UI frameworks.",
+      "AU-Essential-8-Patch": "Before 4.11.0, a flawed containment check on the /file route lets anyone who reaches a public Gradio app read arbitrary host files, and in 3.47 through 3.50.2 the same route also allows full-read SSRF. A Gradio app reachable from the internet is an online service, so ISM-1876 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-1690 requires it within two weeks otherwise. A proof of concept exists. An install that cannot be reached from the internet falls under ISM-1693, one month at Maturity Levels Two and Three. The fix is a library upgrade that takes effect only when each app is redeployed.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the ML demo framework's file-serving / component routes as an untrusted-input access-control surface; a public Gradio app leaks host secrets (HF Spaces tokens)."
     },
     "atlas_refs": [
@@ -135111,7 +135698,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach ML-library model loading as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model untrusted-model-artifact loading in the core ML library as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating model artifacts as untrusted code.",
-      "AU-ISM-1546": "Patch-application control does not single out the foundational ML library's model loaders.",
+      "AU-Essential-8-Patch": "Hugging Face Transformers is a library in the other applications class, so ISM-1693 requires the fix within one month of release from Maturity Level Two, and no patching control applies to it at Maturity Level One. The MobileViTV2 loader in versions before 4.48.0 deserializes configuration files without validation, so loading a malicious MobileViTV2 configuration from a model hub runs attacker code in the user's process. A proof of concept exists, and ISM-1693 keeps its one-month window regardless. The control also does not require loading untrusted configurations in a sandbox, which the remediation calls for alongside the upgrade.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model artifact as untrusted executable input; loading one from an untrusted source through Transformers is RCE."
     },
     "atlas_refs": [
@@ -135218,7 +135805,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach ML-library model loading as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model untrusted-model-artifact loading in the core ML library as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating model artifacts as untrusted code.",
-      "AU-ISM-1546": "Patch-application control does not single out the foundational ML library's model loaders.",
+      "AU-Essential-8-Patch": "Under the Essential Eight, Hugging Face Transformers is one of the other applications, patched within one month of release under ISM-1693 at Maturity Levels Two and Three, with no patching requirement at Maturity Level One. In versions before 4.48.0 the MaskFormer loader deserializes model files without validation, and a user who loads a malicious MaskFormer model runs attacker-controlled code. The exposure also depends on where models come from, and ISM-1693 does not require verifying model provenance or loading untrusted models in a least-privilege sandbox. A public proof-of-concept exists, and the one-month window does not shorten for it.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model artifact as untrusted executable input; loading one from an untrusted source through Transformers is RCE."
     },
     "atlas_refs": [
@@ -135325,7 +135912,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach ML-library model loading as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model untrusted-model-artifact loading in the core ML library as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating model artifacts as untrusted code.",
-      "AU-ISM-1546": "Patch-application control does not single out the foundational ML library's model loaders.",
+      "AU-Essential-8-Patch": "Hugging Face Transformers before 4.48.0 deserializes Trax model files without validation, so a user who loads a malicious Trax model from an untrusted source runs attacker code in their own process. The library is an other application under the Essential Eight: ISM-1693 requires the upgrade to 4.48.0 within one month of release at Maturity Levels Two and Three, and no patching control applies at Maturity Level One. A public proof-of-concept exists and ISM-1693 has no shorter window for a working exploit. The remediation also calls for sandboxed, least-privilege loading of untrusted models, which the patching control does not require.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model artifact as untrusted executable input; loading one from an untrusted source through Transformers is RCE."
     },
     "atlas_refs": [
@@ -135432,7 +136019,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the inference backend as a network-exposed processing surface.",
       "DORA-Art-9": "ICT protection measures do not model memory-safety / DoS in an AI inference backend as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for bounding the inference backend's processing of untrusted input.",
-      "AU-ISM-1546": "Patch-application control does not single out AI inference servers' media backends.",
+      "AU-Essential-8-Patch": "NVIDIA Triton Inference Server takes inference input over the network, and its DALI backend reads out of bounds while processing it (CWE-125, 9.8), which can lead to code execution, data tampering, denial of service or information disclosure. An instance directly accessible over the internet is an online service: ISM-1876 requires r26.03 within 48 hours of release at every maturity level if NVIDIA assesses the flaw as critical, and ISM-1690 requires two weeks otherwise, since no proof of concept is reported. An internal instance gets one month under ISM-1693 at Maturity Levels Two and Three, as a minor flaw would, and no timeframe at Maturity Level One. No control requires the interim limit on DALI input size and shape.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the inference data-augmentation backend's handling of untrusted input as a memory-safety / availability surface requiring bounds and resource limits."
     },
     "atlas_refs": [
@@ -135535,7 +136122,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the inference backend as a network-exposed processing surface.",
       "DORA-Art-9": "ICT protection measures do not model memory-safety / DoS in an AI inference backend as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for bounding the inference backend's processing of untrusted input.",
-      "AU-ISM-1546": "Patch-application control does not single out AI inference servers' media backends.",
+      "AU-Essential-8-Patch": "The DALI backend in NVIDIA Triton Inference Server overflows an integer computation on attacker-controlled input sizes (CWE-190, 9.8), which can corrupt memory and lead to code execution, data tampering or denial of service. Triton serves inference over the network, so an instance directly accessible over the internet is an online service. If NVIDIA assesses the flaw as critical, ISM-1876 requires r26.03 within 48 hours of release at every maturity level; otherwise, with no proof of concept reported, ISM-1690 requires two weeks. ISM-1693 gives an internal instance one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. No control requires the vendor's interim input validation.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the inference data-augmentation backend's handling of untrusted input as a memory-safety / availability surface requiring bounds and resource limits."
     },
     "atlas_refs": [
@@ -135638,7 +136225,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the inference backend as a network-exposed processing surface.",
       "DORA-Art-9": "ICT protection measures do not model memory-safety / DoS in an AI inference backend as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for bounding the inference backend's processing of untrusted input.",
-      "AU-ISM-1546": "Patch-application control does not single out AI inference servers' media backends.",
+      "AU-Essential-8-Patch": "Crafted input to the network inference endpoints of NVIDIA Triton Inference Server makes its DALI backend consume resources without limit (CWE-400, 7.5), letting an unauthenticated attacker deny service. An instance directly accessible over the internet is an online service. With no proof of concept reported, ISM-1690 requires r26.03 within two weeks of release at every maturity level, or 48 hours under ISM-1876 if NVIDIA assesses the flaw as critical or a working exploit appears. For an internal instance, ISM-1693 allows one month at Maturity Levels Two and Three and sets no timeframe at Maturity Level One. No control requires keeping the endpoints off untrusted networks or limiting DALI input meanwhile.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the inference data-augmentation backend's handling of untrusted input as a memory-safety / availability surface requiring bounds and resource limits."
     },
     "atlas_refs": [
@@ -135742,7 +136329,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the inference engine's distributed transport as a privileged control plane.",
       "DORA-Art-9": "ICT protection measures do not model insecure deserialization / socket exposure in an LLM serving engine as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for securing the inference engine's IPC sockets.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM serving engines' distributed transports.",
+      "AU-Essential-8-Patch": "vLLM is model-serving software, and with the Mooncake integration enabled, versions 0.6.5 through 0.8.4 run code that any unauthenticated peer able to connect to the Mooncake ZeroMQ sockets sends as pickle-serialized data. An instance directly accessible over the internet is an online service under ISM-1876 and ISM-1690 at every maturity level; a proof of concept exists, so ISM-1876 requires the upgrade to 0.8.5 within 48 hours of release. An instance reachable only internally is an other application, and ISM-1693 sets one month at Maturity Levels Two and Three. No control requires binding those sockets to a trusted segment until the upgrade, and the fix takes effect only when each serving deployment is redeployed.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the inference engine's IPC sockets as untrusted surfaces requiring a safe serializer, peer authentication, and network isolation."
     },
     "atlas_refs": [
@@ -135845,7 +136432,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the inference engine's distributed transport as a privileged control plane.",
       "DORA-Art-9": "ICT protection measures do not model insecure deserialization / socket exposure in an LLM serving engine as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for securing the inference engine's IPC sockets.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM serving engines' distributed transports.",
+      "AU-Essential-8-Patch": "vLLM multi-node deployments bind the primary host's XPUB ZeroMQ socket to all interfaces without access control. An instance directly accessible over the internet is an online service under ISM-1876 and ISM-1690 at every maturity level; a proof of concept exists, so ISM-1876 requires the upgrade to 0.8.5 within 48 hours of release. An instance reachable only internally is an other application, and ISM-1693 sets one month at Maturity Levels Two and Three. Until the upgrade, any network client that can connect to the socket can read the broadcast stream and flood it to deny service, and no control requires binding the distributed-serving ZeroMQ sockets to a trusted segment and authenticating peers.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the inference engine's IPC sockets as untrusted surfaces requiring a safe serializer, peer authentication, and network isolation."
     },
     "atlas_refs": [
@@ -135949,7 +136536,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the MLOps platform UI as a privileged control surface.",
       "DORA-Art-9": "ICT protection measures do not model XSS-to-RCE in an MLOps platform as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for output-encoding untrusted content in the MLOps UI.",
-      "AU-ISM-1546": "Patch-application control does not single out MLOps experiment-tracking platforms.",
+      "AU-Essential-8-Patch": "MLflow's recipe code runs inside the user's own process and has no network listener, so it is an other application under ISM-1693, even when the recipe comes from an untrusted source. ISM-1693 requires the 2.10.0 fix within one month of release at Maturity Levels Two and Three, and no patching timeframe applies at Maturity Level One. ISM-1693 has no 48-hour tier for a critical vulnerability or a working exploit, so this 9.6 flaw with a proof of concept gets the same month as a low-severity one. Until the upgrade, running an untrusted recipe executes script injected through its template variables and can lead to client-side code execution.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an untrusted MLflow recipe's template content as untrusted input requiring sanitization before rendering; the MLOps UI is a privileged surface."
     },
     "atlas_refs": [
@@ -136053,7 +136640,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach third-party AI-tool plugins as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model custom-node RCE in an AI image-generation tool as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating AI-tool custom nodes / plugins as code requiring review.",
-      "AU-ISM-1546": "Patch-application control does not single out third-party AI-tool extensions.",
+      "AU-Essential-8-Patch": "The ComfyUI server runs ComfyUI-Impact-Pack's /upload/temp handler, which accepts unauthenticated POST requests. A ComfyUI instance directly accessible over the internet is an online service, and because a proof of concept exists, ISM-1876 requires the fix within 48 hours of release at every maturity level rather than the two weeks of ISM-1690. An internal-only instance is an other application, patched within one month under ISM-1693 from Maturity Level Two. The fix is a commit pulled into the custom node and takes effect after ComfyUI restarts. That restart also auto-loads any .py file an /upload/temp request already wrote into ./custom_nodes, and the patching controls do not require checking that directory first.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an AI tool's auto-loaded custom nodes / plugins as an untrusted-code supply-chain and execution surface; a single vulnerable node is unauthenticated RCE."
     },
     "atlas_refs": [
@@ -136156,7 +136743,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach third-party AI-tool plugins as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model custom-node RCE in an AI image-generation tool as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating AI-tool custom nodes / plugins as code requiring review.",
-      "AU-ISM-1546": "Patch-application control does not single out third-party AI-tool extensions.",
+      "AU-Essential-8-Patch": "ComfyUI-Bmad-Nodes runs inside the ComfyUI server. A ComfyUI instance directly accessible over the internet is an online service, and because a proof of concept exists for this CVSS 10.0 flaw, ISM-1876 requires the patched version within 48 hours of release at every maturity level; ISM-1690's two weeks apply only when the vendor rates a flaw non-critical and no working exploit exists. An internal-only instance is an other application, and ISM-1693 has no critical-or-exploit condition, so it still gets the full month from Maturity Level Two, during which a crafted workflow sent to the BuildColorRangeHSVAdvanced, FilterContour or FindContour node runs arbitrary Python on the host without authentication. The patching controls do not require removing those nodes until the patched version is pulled.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an AI tool's auto-loaded custom nodes / plugins as an untrusted-code supply-chain and execution surface; a single vulnerable node is unauthenticated RCE."
     },
     "atlas_refs": [
@@ -136259,7 +136846,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach LLM-orchestration code-execution chains as a privileged surface.",
       "DORA-Art-9": "ICT protection measures do not model prompt-injection-to-code-execution in an LLM app as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for sandboxing code an LLM chain generates or evaluates.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM-orchestration libraries.",
+      "AU-Essential-8-Patch": "langchain-experimental is a Python library that runs inside the process of the application that configures VectorSQLDatabaseChain and has no listener of its own, so the library is an other application. The Essential Eight includes ISM-1693 for that class from Maturity Level Two, requiring patches, updates or other vendor mitigations within one month of release, and sets no requirement at Maturity Level One. The month does not shorten for the available proof of concept. Until each application that configures VectorSQLDatabaseChain is upgraded to 0.0.21 or later and redeployed, an attacker who controls the prompt runs arbitrary Python in it, and the patching controls do not require disabling code-executing chains for untrusted prompts meanwhile.",
       "ALL-PROMPT-INJECTION-ACCESS-CONTROL": "No framework treats prompt-influenced input to a code-executing LLM chain as untrusted code; prompt injection becomes arbitrary code execution."
     },
     "atlas_refs": [
@@ -136364,7 +136951,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach LLM-orchestration code-execution chains as a privileged surface.",
       "DORA-Art-9": "ICT protection measures do not model prompt-injection-to-code-execution in an LLM app as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for sandboxing code an LLM chain generates or evaluates.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM-orchestration libraries.",
+      "AU-Essential-8-Patch": "The langchain_experimental library runs inside applications that ISM-1693 covers, with one month from release at Maturity Levels Two and Three and no timeframe at Maturity Level One. This flaw bypasses the CVE-2023-36258 fix, so an application that took that earlier update still runs arbitrary code from a prompt-injection payload that uses the dunder-import builtin in PALChain until it moves to langchain-experimental 0.0.306. The patch control does not require the steps the vendor pairs with the upgrade: keeping code-executing chains away from untrusted prompts, and sandboxing or disabling generated code.",
       "ALL-PROMPT-INJECTION-ACCESS-CONTROL": "No framework treats prompt-influenced input to a code-executing LLM chain as untrusted code; prompt injection becomes arbitrary code execution."
     },
     "atlas_refs": [
@@ -136469,7 +137056,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the self-hosted AI app as a privileged surface.",
       "DORA-Art-9": "ICT protection measures do not model path-traversal file write in a RAG application as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating upload filenames in the AI app.",
-      "AU-ISM-1546": "Patch-application control does not single out self-hosted RAG / AI chat applications.",
+      "AU-Essential-8-Patch": "Where an AnythingLLM instance is directly accessible over the internet, it is an online service, and because a proof of concept exists, ISM-1876 requires the upgrade to 1.3.1 within 48 hours of release at every maturity level; without a working exploit, ISM-1690 would allow two weeks. An instance reachable only internally is an other application, patched within one month under ISM-1693 from Maturity Level Two. Until 1.3.1 is deployed, a manager or admin account can upload a file whose non-ASCII name decodes to a ../ path, write it into a system-executed directory and run code on the host, and the patching controls do not require restricting those roles meanwhile.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the AI app's document-upload filename as untrusted input reaching the filesystem; a manager-role upload becomes host RCE."
     },
     "atlas_refs": [
@@ -136572,7 +137159,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach LLM-framework tooling as a managed surface.",
       "DORA-Art-9": "ICT protection measures do not model command injection in an LLM data-framework CLI as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for neutralizing shell input in AI-framework CLIs.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM data-framework tooling.",
+      "AU-Essential-8-Patch": "The LlamaIndex CLI is an application outside the office suite, browser, email client, PDF and security product classes, so ISM-1693 requires the shlex-escaping fix within one month of its release at Maturity Levels Two and Three, and Maturity Level One has no patching requirement for it. A proof of concept is public and the class has no 48-hour tier, so at Maturity Levels Two and Three any wrapper, script or automation that forwards untrusted input into --files can let an attacker run arbitrary OS commands for up to a month after the fix ships. No patching control requires the argv-array invocation that the remediation guidance recommends for those wrappers.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an AI tool's CLI arguments as untrusted input that must be neutralized before shell execution; building shell strings from arguments is command injection."
     },
     "atlas_refs": [],
@@ -136674,7 +137261,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the LLM gateway as a privileged credential-holding control plane.",
       "DORA-Art-9": "ICT protection measures do not model API-key exfiltration / code execution in an LLM gateway as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to isolate the LLM gateway's provider credentials from request-controlled flows.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM proxy/gateway software.",
+      "AU-Essential-8-Patch": "LiteLLM is an online service when a proxy instance is directly accessible from the internet, and because a proof of concept exists, ISM-1876 requires the fix within 48 hours of release at every maturity level. An instance reachable only from inside the organization is an other application under ISM-1693, which allows one month at Maturity Levels Two and Three only. Before 1.44.8, any user who can call POST /chat/completions can set api_base and have the proxy send its provider API key to a domain of their choosing. Upgrading stops further leaks, but no patching control requires rotating a key that may already have been sent.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the LLM gateway as a high-value credential store whose request/config plane must be isolated; SSRF or config code-injection there yields mass key theft or proxy RCE."
     },
     "atlas_refs": [
@@ -136778,7 +137365,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the LLM gateway as a privileged credential-holding control plane.",
       "DORA-Art-9": "ICT protection measures do not model API-key exfiltration / code execution in an LLM gateway as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to isolate the LLM gateway's provider credentials from request-controlled flows.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM proxy/gateway software.",
+      "AU-Essential-8-Patch": "An internet-accessible LiteLLM proxy instance is an online service, and because a proof of concept exists, ISM-1876 requires the fix within 48 hours of release at every maturity level instead of ISM-1690's two weeks. An instance reachable only internally is an other application, and ISM-1693 requires the fix within one month of release at Maturity Levels Two and Three, with no timeframe at Maturity Level One. With Google KMS and SAVE_CONFIG_TO_DB configured, an administrator-set UI_LOGO_PATH pointing at a remote server runs code on the proxy holding the deployment's provider credentials. The windows cover only the upgrade to 1.44.16, and no patching control requires limiting who can set configuration or isolating the credential store while they run.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the LLM gateway as a high-value credential store whose request/config plane must be isolated; SSRF or config code-injection there yields mass key theft or proxy RCE."
     },
     "atlas_refs": [
@@ -136884,7 +137471,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the vector DB as a privileged data store.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated vector-DB takeover (RAG data / embeddings) as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to authenticate the vector database storing RAG data.",
-      "AU-ISM-1546": "Patch-application control does not single out vector databases.",
+      "AU-ISM-1546": "ISM-1546 requires that users are authenticated before they are granted access to a system and its resources, and a Milvus deployment with authentication enabled and default tokens replaced meets it. The flaw is in the Proxy component's own check, which trusts forged HTTP headers, so an unauthenticated request gains full access to collections and operations on a configuration that satisfies the control. Evidence for the control records that authentication is enabled and does not test whether the Proxy enforces it. The control sets no response to the disclosure, so only the patching controls set a timeframe for the fix on each branch: 2.4.24, 2.5.21 or 2.6.5.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the vector database as a sensitive RAG data store whose API/management ports must authenticate; an auth bypass exposes embeddings, source documents, and enables RAG poisoning."
     },
     "atlas_refs": [
@@ -136989,7 +137576,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the vector DB as a privileged data store.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated vector-DB takeover (RAG data / embeddings) as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to authenticate the vector database storing RAG data.",
-      "AU-ISM-1546": "Patch-application control does not single out vector databases.",
+      "AU-Essential-8-Patch": "Milvus listens on TCP port 9091, where weak default tokens and missing authentication (CWE-306, 9.8) let an unauthenticated attacker run every business operation and trigger arbitrary expression evaluation. An instance directly accessible over the internet is an online service, and because a proof of concept exists, ISM-1876 requires the fix within 48 hours of release at every maturity level. ISM-1693 gives an internal instance one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. The fix is split across the 2.5.27 and 2.6.10 branches. The patching controls do not require the vendor's paired steps: enabling authentication, replacing default tokens and keeping port 9091 off untrusted networks.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the vector database as a sensitive RAG data store whose API/management ports must authenticate; an auth bypass exposes embeddings, source documents, and enables RAG poisoning."
     },
     "atlas_refs": [
@@ -137093,7 +137680,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the AI compute framework's dashboard as a privileged control plane.",
       "DORA-Art-9": "ICT protection measures do not model dashboard RCE / LFI in an AI compute framework as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to authenticate the AI compute dashboard.",
-      "AU-ISM-1546": "Patch-application control does not single out AI compute frameworks' dashboards.",
+      "AU-Essential-8-Patch": "A Ray dashboard directly accessible over the internet is an online service, and because a proof of concept exists, ISM-1876 requires Ray 2.8.1 within 48 hours of its release at every maturity level. An instance reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three. Before 2.8.1, an unauthenticated request to the cpu_profile endpoint runs operating system commands on the host. Upgrading on time does not close CVE-2023-48022, the disputed Job API flaw on the same dashboard, which stays open until token authentication or network controls are applied, and neither control requires the vendor's direction to keep the dashboard off untrusted networks.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the AI compute dashboard as an unauthenticated control plane requiring auth, input neutralization, and path containment."
     },
     "atlas_refs": [
@@ -137197,7 +137784,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the AI compute framework's dashboard as a privileged control plane.",
       "DORA-Art-9": "ICT protection measures do not model dashboard RCE / LFI in an AI compute framework as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no requirement to authenticate the AI compute dashboard.",
-      "AU-ISM-1546": "Patch-application control does not single out AI compute frameworks' dashboards.",
+      "AU-Essential-8-Patch": "In Ray before 2.8.1, an unauthenticated request to the dashboard log API reads arbitrary files on the host, and a proof of concept exists. An instance whose dashboard is directly accessible over the internet is an online service, and with that proof of concept, ISM-1876 requires the 2.8.1 fix within 48 hours of release at every maturity level. An instance reachable only internally is an other application under ISM-1693, which applies at Maturity Levels Two and Three and keeps its one-month window despite the proof of concept. The remediation calls for keeping the dashboard off untrusted networks, bound to loopback or behind an authenticating proxy, and neither control requires that step.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the AI compute dashboard as an unauthenticated control plane requiring auth, input neutralization, and path containment."
     },
     "atlas_refs": [
@@ -137301,7 +137888,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach LLM-framework model loading as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model untrusted-model-artifact loading in an LLM framework as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating NeMo model artifacts as untrusted code.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM training/customization frameworks.",
+      "AU-Essential-8-Patch": "NVIDIA NeMo Framework falls in the ISM's other-applications class, so ISM-1693 requires its patches to be applied within one month of release, and only from Maturity Level Two; at Maturity Level One no patching timeframe applies to it. A public proof of concept exists for this model-import code injection, but the class has no 48-hour tier, so NeMo earlier than 2.6.1 can remain installed for a month at the levels that cover it. The vendor also advises loading only models of verified provenance and sandboxing untrusted ones, and no patch control requires that restriction while the window runs.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model artifact as untrusted executable input; loading an untrusted NeMo model is RCE."
     },
     "atlas_refs": [
@@ -137407,7 +137994,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach LLM-framework model loading as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model untrusted-model-artifact loading in an LLM framework as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating NeMo model artifacts as untrusted code.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM training/customization frameworks.",
+      "AU-Essential-8-Patch": "NVIDIA NeMo is an application outside the office suite, browser, email client, PDF and security product classes, so ISM-1693 covers it from Maturity Level Two with a one-month window from release; no patching control applies at Maturity Level One. NVIDIA advisory 5580 names r2.0.0rc0, a release candidate, as the fixed version, so an organization that deploys only final releases has no clear date for the month to start. Loading a crafted .nemo archive writes files outside the target directory and can lead to code execution, and the control does not require the model provenance checks or sandboxed loading that the remediation calls for.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model artifact as untrusted executable input; loading an untrusted NeMo model is RCE."
     },
     "atlas_refs": [
@@ -137513,7 +138100,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach DL-framework model loading as a privileged execution control plane.",
       "DORA-Art-9": "ICT protection measures do not model untrusted-checkpoint loading in PyTorch as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating model checkpoints as untrusted code.",
-      "AU-ISM-1546": "Patch-application control does not single out the foundational DL framework's model loaders.",
+      "AU-Essential-8-Patch": "PyTorch is a machine learning framework and falls in the Essential Eight class of other applications: ISM-1693 requires the fix, PyTorch 2.6.0, within one month of release at Maturity Levels Two and Three, and Maturity Level One sets no timeframe for it. On 2.5.1 and earlier, torch.load runs attacker code from a malicious checkpoint even with weights_only=True, the setting the ecosystem recommended for untrusted models, and a proof of concept exists. The control requires no interim measure during that month, such as loading only trusted checkpoints or sandboxing untrusted ones.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model checkpoint as untrusted executable input; loading one with torch.load (even weights_only=True on <= 2.5.1) is RCE, and a 'safe' flag proved necessary-but-insufficient."
     },
     "atlas_refs": [
@@ -137620,7 +138207,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the vector DB as a privileged RAG data store.",
       "DORA-Art-9": "ICT protection measures do not model vector-DB takeover (RAG data / host files) as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for input validation / path containment on the vector database.",
-      "AU-ISM-1546": "Patch-application control does not single out vector databases.",
+      "AU-Essential-8-Patch": "An internet-accessible instance of ChromaDB's Python FastAPI server is an online service, which ISM-1876 and ISM-1690 cover at every maturity level. ISM-1690's two weeks applies only when the vendor rates a flaw non-critical and no working exploit exists; because a proof of concept exists, ISM-1876's 48 hours from release applies. An internal-only instance is an other application under ISM-1693: one month, at Maturity Levels Two and Three. No fixed Python release has been published for this unauthenticated remote code execution flaw, so no patch has started either window. If ChromaDB published the workarounds (keeping the FastAPI port off untrusted networks, moving to the Rust chroma run deployment or official Docker images, disabling trust_remote_code model loading), they are vendor mitigations and each window runs from their publication; otherwise no patching control requires them.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the vector database as a sensitive RAG store whose request/backup paths must validate untrusted input before code execution or file write."
     },
     "atlas_refs": [
@@ -137728,7 +138315,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures do not reach the vector DB as a privileged RAG data store.",
       "DORA-Art-9": "ICT protection measures do not model vector-DB takeover (RAG data / host files) as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for input validation / path containment on the vector database.",
-      "AU-ISM-1546": "Patch-application control does not single out vector databases.",
+      "AU-Essential-8-Patch": "Weaviate is a vector database server. An instance directly accessible over the internet is an online service: because a proof of concept exists, ISM-1876 requires its fix within 48 hours of release at every maturity level, and the two-week window in ISM-1690 does not apply. An internal-only instance is an other application, and ISM-1693 requires its fix within one month at Maturity Levels Two and Three only. The restore traversal lets a user with insert access overwrite files anywhere on the host. The fix ships separately on each maintained branch as 1.30.20, 1.31.19, 1.32.16 and 1.33.4, and no patching control requires restricting who can insert data or trigger restores until the upgrade.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the vector database as a sensitive RAG store whose request/backup paths must validate untrusted input before code execution or file write."
     },
     "atlas_refs": [
@@ -137832,7 +138419,7 @@
       "NIS2-Art21-vulnerability-management": "Vulnerability-management measures do not enumerate NL-to-code/SQL agents as an unauthenticated RCE surface.",
       "DORA-Art-9": "ICT protection measures do not model an AI data-analysis agent's codegen path as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for sandboxing LLM-generated code or validating prompt-injectable input.",
-      "AU-ISM-1546": "Application-control / patch guidance does not single out LLM agents that execute generated code.",
+      "AU-Essential-8-Patch": "Vanna is an application other than an office suite, web browser, email client, PDF application or security product, so ISM-1693 requires a fix within one month of release at Maturity Levels Two and Three, and Maturity Level One sets no timeframe. No fixed release is published for Vanna 0.5.5 and earlier, so that window has not started, while a public proof of concept turns an injected question into arbitrary Python through the default visualization path. No control requires the mitigations that remain: sandboxing that code path or disabling visualization for untrusted questions.",
       "ALL-PROMPT-INJECTION-ACCESS-CONTROL": "No framework requires that prompt-injectable natural-language input be denied a path to code execution in NL-to-code/SQL agents.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM data-analysis agent's generate-and-execute-code design as a privileged execution surface that must be sandboxed."
     },
@@ -137941,7 +138528,7 @@
       "NIS2-Art21-vulnerability-management": "Vulnerability-management measures do not enumerate NL-to-code/SQL agents as an unauthenticated RCE surface.",
       "DORA-Art-9": "ICT protection measures do not model an AI data-analysis agent's codegen path as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for sandboxing LLM-generated code or validating prompt-injectable input.",
-      "AU-ISM-1546": "Application-control / patch guidance does not single out LLM agents that execute generated code.",
+      "AU-Essential-8-Patch": "PandasAI is in the other applications class, where ISM-1693 requires patches, updates or other vendor mitigations within one month of release from Maturity Level Two; no patching control applies at Maturity Level One. No fixed release exists for 2.4.2 and earlier. The only vendor measure is the v3 advanced security agent, a mitigation rather than a backported fix, and the remediation adds running PandasAI in a sandbox with no host or network privileges, which the control does not require. A public proof-of-concept shows prompt injection making PandasAI generate and run arbitrary Python.",
       "ALL-PROMPT-INJECTION-ACCESS-CONTROL": "No framework requires that prompt-injectable natural-language input be denied a path to code execution in NL-to-code/SQL agents.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM data-analysis agent's generate-and-execute-code design as a privileged execution surface that must be sandboxed."
     },
@@ -138052,7 +138639,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control measures do not reach the LLM app builder's unauthenticated execution endpoints.",
       "DORA-Art-9": "ICT protection measures do not model an LLM app builder's public code endpoint as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for authenticating and sandboxing LLM app-builder execution endpoints.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app builders.",
+      "AU-Essential-8-Patch": "A Langflow instance reachable from the internet is an online service. VulnCheck's public proof of concept is a working exploit, so ISM-1876 requires 1.3.0 or later within 48 hours of release at every maturity level; an internal-only instance is an other application, patched within one month from Maturity Level Two (ISM-1693). Mass scanning followed the proof of concept, Sysdig documented the compromise of an exposed instance within hours, and CISA listed the flaw on 2025-05-05. No control requires authenticated reverse-proxy access in front of the unauthenticated /api/v1/validate/code route while the window runs. Version 1.3.0 closes only that route, and the sibling flow-build route (CVE-2026-33017) needs 1.9.0 or later.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats a visual LLM app/agent builder's flow validate/build endpoints as privileged execution surfaces that must authenticate and sandbox submitted code."
     },
     "atlas_refs": [
@@ -138165,7 +138752,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control measures do not reach the LLM app builder's unauthenticated execution endpoints.",
       "DORA-Art-9": "ICT protection measures do not model an LLM app builder's public code endpoint as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for authenticating and sandboxing LLM app-builder execution endpoints.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app builders.",
+      "AU-Essential-8-Patch": "A Langflow instance directly accessible over the internet is an online service. CISA lists this unauthenticated code execution flaw as known exploited, so ISM-1876 requires the 1.9.0 fix within 48 hours of release at every maturity level. An instance reachable only from inside the organization is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One, although CISA listed the flaw on 2026-03-25 with a due date of 2026-04-08. Applying 1.3.0 for CVE-2025-3248 met either control for that flaw while the public flow-build endpoint remained exploitable.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats a visual LLM app/agent builder's flow validate/build endpoints as privileged execution surfaces that must authenticate and sandbox submitted code."
     },
     "atlas_refs": [
@@ -138275,7 +138862,7 @@
       "NIS2-Art21-supply-chain": "Supply-chain-security measures do not reach the MLOps platform as a channel that delivers executable artifacts between data scientists.",
       "DORA-Art-9": "ICT protection measures do not model MLOps-artifact retrieval as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating MLOps artifacts/datasets before deserialization or extraction.",
-      "AU-ISM-1546": "Patch-application control does not single out MLOps client SDKs.",
+      "AU-Essential-8-Patch": "ISM-1693 governs the ClearML client SDK as one of the ISM's other applications, requiring patches, updates or other vendor mitigations within one month of release from Maturity Level Two, with no requirement at Maturity Level One. The advisory names no fixed SDK version for 0.17.0 through 1.14.2, so the month has no release to start from, and an SDK that retrieves a malicious artifact from a shared project still deserializes it and runs attacker code on the user's machine. HiddenLayer reports that the issues were resolved with the vendor, but no build is identified for an organization to apply or verify.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an MLOps / experiment-tracking platform's uploaded artifacts and datasets as an untrusted code/file-delivery surface."
     },
     "atlas_refs": [
@@ -138383,7 +138970,7 @@
       "NIS2-Art21-supply-chain": "Supply-chain-security measures do not reach the MLOps platform as a channel that delivers executable artifacts between data scientists.",
       "DORA-Art-9": "ICT protection measures do not model MLOps-artifact retrieval as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating MLOps artifacts/datasets before deserialization or extraction.",
-      "AU-ISM-1546": "Patch-application control does not single out MLOps client SDKs.",
+      "AU-Essential-8-Patch": "The ClearML client SDK falls in the other-applications class, so ISM-1693 requires patches, updates or other vendor mitigations for it to be applied within one month of release at Maturity Levels Two and Three, and Maturity Level One sets no patching timeframe. The GitHub advisory for the affected range, 1.4.0 through 1.14.1, lists no fixed SDK version. A dependency scanner that reads that advisory reports no available fix, and an operator who works from it cannot tell which version meets the requirement or when the month began, while HiddenLayer's disclosure documents an attack chain in which a malicious dataset writes files to arbitrary locations on the retrieving user's system.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an MLOps / experiment-tracking platform's uploaded artifacts and datasets as an untrusted code/file-delivery surface."
     },
     "atlas_refs": [
@@ -138490,7 +139077,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control measures do not reach the ML platform's unauthenticated model-import endpoint.",
       "DORA-Art-9": "ICT protection measures do not model an ML platform's model-import RCE as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for authenticating and sandboxing ML-platform model import.",
-      "AU-ISM-1546": "Patch-application control does not single out ML/AutoML platforms.",
+      "AU-Essential-8-Patch": "An H2O-3 instance whose dashboard and REST API are directly accessible over the internet is an online service, and because a public proof of concept exists, ISM-1876 sets 48 hours from release at every maturity level. An instance reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three. H2O.ai publishes no fixed version and documents H2O-3 as a product for trusted environments, so neither window starts. Meanwhile the POJO model import, which requires no authentication, compiles and runs attacker-supplied model code on the host. The mitigation is network isolation and authenticated access control in front of the dashboard and REST API, which neither control requires.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML platform's model-import feature as a privileged code-execution surface that must authenticate and reject untrusted model code."
     },
     "atlas_refs": [
@@ -138596,7 +139183,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control measures do not reach the ML platform's unauthenticated REST API.",
       "DORA-Art-9": "ICT protection measures do not model unauthenticated file read from an ML platform as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for authenticating the ML platform's REST API.",
-      "AU-ISM-1546": "Patch-application control does not single out ML/AutoML platforms.",
+      "AU-Essential-8-Patch": "Because a public proof of concept for the unauthenticated file read exists, ISM-1876 gives an internet-accessible H2O-3 instance, an online service, 48 hours from a fix's release at every maturity level. An internal instance is an other application under ISM-1693, with one month at Maturity Levels Two and Three only. No fixed version is published, so neither window starts. If the vendor stops supporting H2O-3, ISM-1905 requires removal of an internet-accessible instance at every maturity level, and ISM-0304 requires removal of an internal one at Maturity Level Three. H2O.ai documents H2O-3 as a trusted-environment product, and the patching controls do not require network isolation, authenticated access or a least-privilege account.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML platform's REST API authorization as an integrity control whose absence exposes arbitrary file read."
     },
     "atlas_refs": [
@@ -138702,7 +139289,7 @@
       "NIS2-Art21-vulnerability-management": "Vulnerability-management measures do not enumerate model-serving frameworks' deserialization paths as unauthenticated RCE surfaces.",
       "DORA-Art-9": "ICT protection measures do not model model-serving deserialization RCE as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for safe deserialization in model-serving frameworks.",
-      "AU-ISM-1546": "Patch-application control does not single out model-serving frameworks.",
+      "AU-Essential-8-Patch": "An internet-accessible BentoML serving API is an online service, so ISM-1876 requires the 1.2.5 fix within 48 hours of release at every maturity level, because the attack is documented and a proof of concept exists; ISM-1690's two weeks apply only when the vendor rates a flaw non-critical and no working exploit exists. A model server reachable only internally is an other application under ISM-1693, which allows one month at Maturity Levels Two and Three and sets no timeframe at Maturity Level One, although this CVSS 10 deserialization lets any unauthenticated caller that reaches the API run code on it. Each serving deployment must be upgraded and redeployed, and until then its API has to stay off untrusted networks.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats a model-serving framework's request-deserialization path as a privileged execution surface that must never reconstruct untrusted serialized objects."
     },
     "atlas_refs": [
@@ -138806,7 +139393,7 @@
       "NIS2-Art21-vulnerability-management": "Vulnerability-management measures do not enumerate model-serving frameworks' deserialization paths as unauthenticated RCE surfaces.",
       "DORA-Art-9": "ICT protection measures do not model model-serving deserialization RCE as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for safe deserialization in model-serving frameworks.",
-      "AU-ISM-1546": "Patch-application control does not single out model-serving frameworks.",
+      "AU-Essential-8-Patch": "BentoML serves models behind an HTTP API, and in 1.3.4 through 1.4.2 any unauthenticated client that can connect to that API can run code on the model server through insecure deserialization in serde.py, the same class as CVE-2024-2912, which 1.2.5 fixed. An instance directly accessible over the internet is an online service under ISM-1876 and ISM-1690 at every maturity level; a proof of concept exists, so ISM-1876 requires the upgrade to 1.4.3 within 48 hours of release. An instance reachable only internally is an other application, and ISM-1693 sets one month at Maturity Levels Two and Three. No control requires keeping the serving API off untrusted networks until 1.4.3 is installed.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats a model-serving framework's request-deserialization path as a privileged execution surface that must never reconstruct untrusted serialized objects."
     },
     "atlas_refs": [
@@ -138909,7 +139496,7 @@
       "NIS2-Art21-supply-chain": "Supply-chain-security measures do not reach the MLflow model registry as a channel that delivers executable model artifacts.",
       "DORA-Art-9": "ICT protection measures do not model untrusted model-artifact loading as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for verifying model-artifact provenance before loading.",
-      "AU-ISM-1546": "Patch-application control does not address a flaw with no patch - the model format is inherently executable.",
+      "AU-Essential-8-Patch": "MLflow falls in the Essential Eight's other applications class, so ISM-1693 requires vendor patches within one month of release at Maturity Levels Two and Three. The GitHub advisory records no patched version for the scikit-learn model flavor, and every release from 1.1.0 through 2.14.1 is affected, so no timeframe starts and an MLflow host meets ISM-1693 while the flaw remains. Loading a scikit-learn model runs its embedded code through unsafe deserialization, and the exposure stays open unless models come only from verified sources and load in a sandboxed, least-privilege environment.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an MLflow model artifact / Recipe as untrusted executable code requiring provenance verification and sandboxed loading."
     },
     "atlas_refs": [
@@ -139015,7 +139602,7 @@
       "NIS2-Art21-supply-chain": "Supply-chain-security measures do not reach the MLflow model registry as a channel that delivers executable model artifacts.",
       "DORA-Art-9": "ICT protection measures do not model untrusted model-artifact loading as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for verifying model-artifact provenance before loading.",
-      "AU-ISM-1546": "Patch-application control does not address a flaw with no patch - the model format is inherently executable.",
+      "AU-Essential-8-Patch": "MLflow falls in the Essential Eight's other applications class, where ISM-1693 requires vendor patches within one month of release at Maturity Levels Two and Three only. The advisory for the Recipe deserialization flaw in 1.27.0 through 2.14.1 records 'Patched versions: None', so ISM-1693 sets no deadline. Loading an untrusted Recipe is inherently code execution on the user's system, so the exposure lasts for as long as Recipes from outside sources are run. Restricting Recipes to verified sources and running them in a sandboxed, least-privilege environment are the only protections, and no Essential Eight patching control requires either.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an MLflow model artifact / Recipe as untrusted executable code requiring provenance verification and sandboxed loading."
     },
     "atlas_refs": [
@@ -139121,7 +139708,7 @@
       "NIS2-Art21-network-security": "Network-security measures do not enumerate ML data-platform SSRF as an internal-pivot surface.",
       "DORA-Art-9": "ICT protection measures do not model server-side request forgery from an ML data platform as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating server-side fetch destinations in ML data platforms.",
-      "AU-ISM-1546": "Patch-application control does not single out ML data-labeling platforms.",
+      "AU-Essential-8-Patch": "Label Studio is a web application. An instance directly accessible over the internet is an online service under ISM-1876 and ISM-1690 at every maturity level; a proof of concept exists, so ISM-1876 requires the upgrade to 1.16.0 within 48 hours of release. An instance reachable only internally is an other application, and ISM-1693 sets one month at Maturity Levels Two and Three. An attacker using the proof of concept sets the S3 storage endpoint to an internal address or the cloud metadata service and reads the responses through the server, bypassing network segmentation. No control requires the vendor's interim measures: allowlisting endpoint destinations, blocking private, link-local and metadata addresses and file:// schemes, and disabling self-registration.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML data-pipeline platform's import/storage URL fetch as an egress that must validate and allowlist destinations."
     },
     "atlas_refs": [
@@ -139224,7 +139811,7 @@
       "NIS2-Art21-network-security": "Network-security measures do not enumerate ML data-platform SSRF as an internal-pivot surface.",
       "DORA-Art-9": "ICT protection measures do not model server-side request forgery from an ML data platform as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating server-side fetch destinations in ML data platforms.",
-      "AU-ISM-1546": "Patch-application control does not single out ML data-labeling platforms.",
+      "AU-Essential-8-Patch": "An internet-accessible Label Studio server is an online service. A public proof of concept exists, so ISM-1876 requires the 1.6.0 upgrade within 48 hours of release at every maturity level, rather than the two weeks ISM-1690 allows when the vendor rates a flaw non-critical and no working exploit exists. A server reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. Self-registration is on by default, so until the upgrade anyone who can reach the server can register the account the Data Import fetch requires, then read local files through file:// URLs and send requests to internal services.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML data-pipeline platform's import/storage URL fetch as an egress that must validate and allowlist destinations."
     },
     "atlas_refs": [
@@ -139327,7 +139914,7 @@
       "DORA-Art-9": "ICT protection measures do not model API sensitive-field exposure / account takeover of an ML platform as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for object-level authorization on AI data-platform APIs.",
       "UK-CAF-B4": "System Security objective has no objective for serializer field allowlisting / ORM-filter restriction in ML platforms.",
-      "AU-ISM-1546": "Patch-application control does not single out ML data-labeling platforms.",
+      "AU-Essential-8-Patch": "An internet-accessible Label Studio instance is an online service, and because a proof of concept exists, ISM-1876 requires the fix within 48 hours of release at every maturity level. An instance reachable only from inside the organization is an other application under ISM-1693, which requires the fix within one month at Maturity Levels Two and Three only. Before 1.9.2post0, a crafted task filter reads password hashes and auth tokens for every user account through the Django ORM. Upgrading ends the leak but does not invalidate what was already read, and neither control requires the credential and session-secret rotation the vendor directs.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML data-platform API's object-level authorization and sensitive-field exposure as integrity controls whose failure yields account takeover."
     },
     "atlas_refs": [
@@ -139430,7 +140017,7 @@
       "DORA-Art-9": "ICT protection measures do not model API sensitive-field exposure / account takeover of an ML platform as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for object-level authorization on AI data-platform APIs.",
       "UK-CAF-B4": "System Security objective has no objective for serializer field allowlisting / ORM-filter restriction in ML platforms.",
-      "AU-ISM-1546": "Patch-application control does not single out ML data-labeling platforms.",
+      "AU-Essential-8-Patch": "An internet-accessible Label Studio instance is an online service. A proof of concept exists, so ISM-1876 requires the fix within 48 hours of release at every maturity level instead of the two weeks ISM-1690 allows when the vendor rates a flaw non-critical and no working exploit exists. An instance reachable only internally is an other application under ISM-1693, patched within one month from Maturity Level Two. Before 1.8.2, a low-privilege user can chain this flaw with the ORM field leak CVE-2023-47117 to impersonate any account and escalate to Django super administrator. The vendor pairs the upgrade with rotating exposed session-signing secrets and credentials, which the patch controls do not require, so secrets leaked before the upgrade stay usable.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML data-platform API's object-level authorization and sensitive-field exposure as integrity controls whose failure yields account takeover."
     },
     "atlas_refs": [
@@ -139534,7 +140121,7 @@
       "NIS2-Art21-supply-chain": "Supply-chain-security measures do not treat the defensive-ML library (ART) as a channel that delivers executable model artifacts.",
       "DORA-Art-9": "ICT protection measures do not model code execution via an ML security library as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for model-artifact provenance / sandboxed loading in ML libraries.",
-      "AU-ISM-1546": "Patch-application control does not address a flaw with no published patch.",
+      "AU-Essential-8-Patch": "The Adversarial Robustness Toolbox (ART) is a library in the Essential Eight's other-applications class, so ISM-1693 requires vendor patches or mitigations within one month of release at Maturity Levels Two and Three, and Level One sets no timeframe. ART is affected through 1.20.1 and the advisory records its patched versions as unknown, so the month has no release to run from while a crafted model file loaded through the Kubeflow component's torch.load() call runs arbitrary code. No patching control requires the loader-side measures available now: weights_only=True or safetensors, trusted model sources and sandboxed loading.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the adversarial-robustness library's model-loading path as a privileged code-execution surface."
     },
     "atlas_refs": [
@@ -139633,7 +140220,7 @@
       "NIS2-Art21-supply-chain": "Supply-chain-security measures do not treat the defensive-ML library (ART) as a channel that executes attacker-influenced arguments.",
       "DORA-Art-9": "ICT protection measures do not model code execution via an ML security library as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for safe CLI argument parsing in ML libraries.",
-      "AU-ISM-1546": "Patch-application control does not address a flaw with no published patch.",
+      "AU-Essential-8-Patch": "Adversarial Robustness Toolbox (ART) is in the other applications class. ISM-1693 requires patches, updates or other vendor mitigations to be applied within one month of release, at Maturity Levels Two and Three only, with no shorter window when a working exploit exists. ART is affected through 1.20.1 and has no fixed release, so no patch has started that window while this CVSS 9.8 flaw with a documented attack stays open. If the advisory's guidance to keep untrusted values out of the clip_values and input_shape arguments counts as a vendor mitigation, ISM-1693 required it within one month of the May 2026 advisory. No patching control requires changing ART's Kubeflow component to use a safe literal parser.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats the adversarial-robustness library's CLI argument parsing as a privileged code-execution surface."
     },
     "atlas_refs": [
@@ -139728,7 +140315,7 @@
       "NIS2-Art21-vulnerability-management": "Vulnerability-management measures do not enumerate MLOps-console XSS as a session-hijack surface.",
       "DORA-Art-9": "ICT protection measures do not model MLOps-console XSS / session hijack as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for output encoding / CSP on AI-platform consoles.",
-      "AU-ISM-1546": "Patch-application control does not single out MLOps consoles.",
+      "AU-Essential-8-Patch": "A Kubeflow Pipelines console directly accessible from the internet is an online service. Because a proof of concept exists, ISM-1876 gives it 48 hours from release at every maturity level. A console reachable only from inside the organization is an other application under ISM-1693, which allows one month at Maturity Levels Two and Three only. The fix is upstream commit 930c35f1 rather than a numbered release, so an operator must first find which deployed builds predate 2023-12-13. Until the console is redeployed, anyone who can edit a pipeline description can store script that runs in the browser of every user who views it.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an MLOps console's rendering of user-controlled fields as an integrity control whose failure hijacks operators' sessions."
     },
     "atlas_refs": [
@@ -139831,7 +140418,7 @@
       "NIS2-Art21-vulnerability-management": "Vulnerability-management measures do not enumerate MLOps-console XSS as a session-hijack surface.",
       "DORA-Art-9": "ICT protection measures do not model MLOps-console XSS / session hijack as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for output encoding / CSP on AI-platform consoles.",
-      "AU-ISM-1546": "Patch-application control does not single out MLOps consoles.",
+      "AU-Essential-8-Patch": "An internet-accessible Kubeflow console is an online service, and because a proof of concept exists, ISM-1876 requires the fix within 48 hours of release at every maturity level. A console reachable only from inside the organization is an other application under ISM-1693, with one month at Maturity Levels Two and Three only. In Kubeflow 1.7.0, a victim who follows a crafted link runs attacker script in their authenticated MLOps console session. The fix is described only as an upstream build after 1.7.0, so an operator must identify the release that carries it to know when either window began. Neither control requires the strict Content-Security-Policy or HttpOnly session cookies the remediation also calls for.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an MLOps console's rendering of user-controlled fields as an integrity control whose failure hijacks operators' sessions."
     },
     "atlas_refs": [
@@ -139936,7 +140523,7 @@
       "NIS2-Art21-vulnerability-management": "Vulnerability-management measures do not enumerate LLM-app-builder code nodes as RCE surfaces.",
       "DORA-Art-9": "ICT protection measures do not model an LLM app builder's code-node sandbox escape as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for robust sandboxing of app-builder code nodes.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app builders.",
+      "AU-Essential-8-Patch": "Dify is server software. An instance directly accessible over the internet is an online service, and because a proof of concept exists for this code-node sandbox escape, ISM-1876 requires the upgrade of Dify 1.1.0 through 1.1.2 to 1.1.3 within 48 hours of release at every maturity level. An instance reachable only internally is an other application, and ISM-1693 allows it one month from Maturity Level Two, with no deadline at Maturity Level One, although the escape runs code with root-level privileges on the host. No patch control requires restricting who can author code nodes, which the vendor advises with the upgrade, any sooner than the upgrade itself.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM app builder's code node as a privileged execution surface whose sandbox must be escape-resistant."
     },
     "atlas_refs": [
@@ -140041,7 +140628,7 @@
       "NIS2-Art21-network-security": "Network-security measures do not enumerate LLM-platform SSRF as an internal-pivot surface.",
       "DORA-Art-9": "ICT protection measures do not model server-side request forgery from an LLM platform as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for validating server-side fetch destinations in LLM platforms.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app platforms.",
+      "AU-Essential-8-Patch": "Dify is server software. An instance directly accessible over the internet is an online service, and because a proof of concept exists, ISM-1876 requires a fix within 48 hours of release at every maturity level. An instance reachable only internally is an other application, and ISM-1693 allows it one month from Maturity Level Two only. Both windows run from the vendor's release, and no fixed Dify release is published, so an organization that meets both can keep running 1.6.0 while an unauthenticated request can make the server fetch internal and cloud-metadata addresses. No patching control requires the interim steps of allowlisting upload fetch destinations and isolating Dify on the network.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM platform's remote-file fetch as an egress that must validate and allowlist destinations."
     },
     "atlas_refs": [
@@ -140143,7 +140730,7 @@
       "NIS2-Art21-identity-management": "Article 21 identity/access measures do not cover weak password-recovery in AI apps.",
       "DORA-Art-9": "ICT protection measures do not model AI-app account takeover via password recovery as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for secure password-recovery in AI app platforms.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app platforms.",
+      "AU-Essential-8-Patch": "Dify is a web-based LLM application platform. An instance directly accessible over the internet is an online service under ISM-1876 and ISM-1690 at every maturity level; a proof of concept exists, so ISM-1876 requires the fix within 48 hours of release. An instance reachable only internally is an other application, and ISM-1693 sets one month at Maturity Levels Two and Three. No fixed Dify release is published, so neither window has started, and the proof of concept lets an attacker predict the password-reset code for any account, including administrators. No patching control requires generating reset tokens with a cryptographically secure generator or rate-limiting reset attempts.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM app platform's password-recovery flow as an authentication-integrity control whose failure yields full (admin) account takeover."
     },
     "atlas_refs": [
@@ -140247,7 +140834,7 @@
       "NIS2-Art21-identity-management": "Article 21 identity/access measures do not cover weak password-recovery in AI apps.",
       "DORA-Art-9": "ICT protection measures do not model AI-app account takeover via password recovery as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for secure password-recovery in AI app platforms.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app platforms.",
+      "AU-Essential-8-Patch": "A Dify instance directly accessible over the internet is an online service, and because a proof of concept exists, ISM-1876 requires a fix within 48 hours of release at every maturity level, where ISM-1690 would otherwise allow two weeks. An internal-only instance is an other application, and ISM-1693 requires its patches within one month from Maturity Level Two. No fixed release is published for Dify 0.10.1, so neither window starts, while the /forgot-password/resets endpoint lets an attacker reset any user's password, administrators included, without a valid reset code. The only remediation on record is a server-side check of the reset code, a change the operator makes that the patching controls do not require.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM app platform's password-recovery flow as an authentication-integrity control whose failure yields full (admin) account takeover."
     },
     "atlas_refs": [
@@ -140352,7 +140939,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control measures do not prevent object-level authorization bypass in AI apps.",
       "DORA-Art-9": "ICT protection measures do not model cross-tenant config tampering in an AI app as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for object-level authorization on AI app-platform APIs.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app platforms.",
+      "AU-Essential-8-Patch": "A Dify deployment directly accessible over the internet is an online service. A proof of concept exists, so ISM-1876 requires 1.14.2 within 48 hours of release at every maturity level. A deployment reachable only from inside the organization is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. Every release through 1.14.1 lets an editor-level user redirect another tenant's trace data to a provider the attacker controls, so an internal deployment that meets ISM-1693 can leak that data for a month. No patching control requires a review of trace settings changed before the upgrade to 1.14.2.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM app platform's object-level authorization (ownership checks on user-controlled keys) as an integrity control."
     },
     "atlas_refs": [
@@ -140456,7 +141043,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control measures do not prevent object-level authorization bypass in AI apps.",
       "DORA-Art-9": "ICT protection measures do not model cross-user data disclosure in an AI app as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for object-level authorization on AI app-platform APIs.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app platforms.",
+      "AU-Essential-8-Patch": "An internet-accessible Dify deployment is an online service. Although the CVSS score is 6.5, a proof of concept exists, so ISM-1876 requires 1.14.0 within 48 hours of release at every maturity level instead of the two weeks ISM-1690 allows. On a deployment reachable only internally, Dify is an other application, and ISM-1693 gives one month at Maturity Levels Two and Three with no timeframe at Maturity Level One. Before 1.14.0, an authenticated user can read files other users in the same tenant uploaded by placing their UUIDs in a chat-messages request, and no patching control requires a check of which files were read before the upgrade.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM app platform's object-level authorization (ownership checks on user-controlled keys) as an integrity control."
     },
     "atlas_refs": [
@@ -140563,7 +141150,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures mandate timely patching but assume the EDR/AV agent is part of the defense, not itself the LPE vector; engine-version currency is rarely a tracked control.",
       "DORA-Art-9": "ICT protection measures presume the endpoint-protection tool is trustworthy; a privileged confused-deputy in that tool is outside the typical control narrative.",
       "UK-CAF-B4": "System Security objective expects vulnerability remediation but does not call out keeping the security agent's engine build patched as a distinct, audited control.",
-      "AU-ISM-1546": "Patch-application timeframe control is product-agnostic and does not single out the AV/EDR engine, whose SYSTEM privilege makes its flaws maximally severe."
+      "AU-Essential-8-Patch": "Microsoft Defender is a security product: ISM-1691 requires its patches within two weeks of release at Maturity Levels One and Two, and ISM-1692 requires them within 48 hours at Maturity Level Three when the vendor rates the flaw critical or a working exploit exists. Microsoft reported exploitation and CISA listed this elevation to SYSTEM on 2026-05-20, yet below Level Three a compliant host can keep the vulnerable engine for two weeks. Engine 1.1.26040.8 installs by auto-update without a restart, so exposure remains where a managed-update policy pins or delays engine updates, and evidence has to show the deployed engine build on each host."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -140676,7 +141263,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures mandate patching but do not treat the EDR/endpoint-management server's agent-deployment channel as a high-blast-radius supply-chain control plane that must be hardened and monitored.",
       "DORA-Art-9": "ICT protection measures assume the endpoint-management platform is trustworthy; abuse of its own deployment channel to push code to agents is outside the typical control narrative.",
       "UK-CAF-B4": "System Security objective expects remediation but does not call out the management-server → agent deployment path as a privileged trust boundary requiring integrity controls.",
-      "AU-ISM-1546": "Patch-application timeframe control is product-agnostic; it does not address the fleet-wide propagation risk of a compromised endpoint-management server."
+      "AU-Essential-8-Patch": "Apex One is a security product, so ISM-1691 requires its fix within two weeks of release at Maturity Levels One and Two, and ISM-1692 requires 48 hours at Level Three when a working exploit exists, as CISA's KEV listing on 2026-05-21 confirms. Below Level Three, an on-premise management server can stay on a build before 14.0.0.17079 for two weeks under confirmed exploitation. During that time an attacker holding administrative credentials on the server can use the traversal to inject code that the server deploys to its managed agents."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -140790,7 +141377,7 @@
       "NIS2-Art21-patch-management": "Article 21 measures treat the AV/EDR as a protective control but do not require detecting when that control is remotely disabled — a precondition this DoS creates.",
       "DORA-Art-9": "ICT protection measures assume endpoint protection is present; remote loss of that protection is outside the typical availability-monitoring narrative for security tooling.",
       "UK-CAF-B4": "System Security objective expects remediation but does not call out resilience/availability monitoring of the endpoint-protection agent itself.",
-      "AU-ISM-1546": "Patch-application timeframe control is product-agnostic; it does not address remote denial of the security agent as a defense-evasion enabler."
+      "AU-Essential-8-Patch": "Microsoft Defender is a security product. ISM-1691 requires its patches within two weeks of release at Maturity Levels One and Two, and at Maturity Level Three ISM-1692 requires them within 48 hours for a vendor-rated critical flaw or a working exploit. Microsoft reports exploitation detected and CISA listed the flaw on 2026-05-20, yet at Maturity Level One or Two a compliant host can leave Defender open to a remote unauthenticated crash for two weeks after release. Automatic update delivers platform 4.18.26040.7 by default without a restart, so the exposed hosts are those that pin or delay platform updates, and evidence has to show the deployed platform build."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -141843,7 +142430,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "Routine patch scheduling does not match the in-the-wild web-content exploitation of this WebKit buffer overflow across the Apple ecosystem, where a single malicious page triggers memory corruption before the update cycle reaches managed devices.",
       "UK-CAF-B4": "Secure-configuration baselines for Apple endpoints cannot mitigate a drive-by memory-corruption flaw reachable purely by rendering crafted web content, so only emergency patching closes the exposure.",
-      "AU-Essential-8-Patch": "Essential-Eight application/OS patch windows exceed the exploitation window for a KEV-listed browser-engine overflow that fires on maliciously crafted web content with no user action beyond viewing."
+      "AU-Essential-8-Patch": "Because a proof-of-concept exploit exists, each 48-hour control below applies. Safari is a web browser, updated within two weeks at Maturity Levels One and Two (ISM-1691) and 48 hours at Level Three (ISM-1692). macOS is a workstation operating system, patched within one month at Levels One and Two (ISM-1695) and 48 hours at Level Three (ISM-1696). iOS, iPadOS, watchOS, visionOS and tvOS fall under ISM-1878 (48 hours) and ISM-1751, which are in no Essential Eight profile. CISA listed the flaw as exploited on 2026-03-20, and Levels One and Two still allow two weeks or a month. Each product's fixed release must be confirmed separately, and the update needs a restart."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -143299,7 +143886,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "Patch cadence doesn't account for Apple's coupled OS/Safari update model, where a KEV-listed crafted-web-content use-after-free is exploited on-visit before fleet-wide macOS/iOS updates roll out.",
       "UK-CAF-B4": "Secure-configuration guidance for managed Apple devices doesn't gate the WebKit content-processing path this UAF abuses, so hardening alone leaves the on-visit memory-corruption primitive open until the OS is patched.",
-      "AU-Essential-8-Patch": "Essential-Eight patch timelines are framed around desktop/server OS updates and under-cover the fast browser-engine rollout needed to close an actively-exploited on-visit UAF across mixed Apple mobile and desktop fleets."
+      "AU-Essential-8-Patch": "Safari is a web browser under ISM-1691, patched within two weeks of release at Maturity Levels One and Two, and macOS is a workstation operating system under ISM-1695, patched within one month. Only Maturity Level Three applies 48 hours (ISM-1692, ISM-1696) when a working exploit exists, as it does for this KEV-listed use-after-free in web content processing. The fix requires a restart and spans Safari, macOS, iOS and iPadOS, and every window runs from Apple's release of each fixed build rather than from the 2026-03-05 KEV listing."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -143752,7 +144339,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "Chipset firmware fixes traverse an OEM-and-carrier distribution chain, so NIS2 patch-management timelines cannot be met for this actively-exploited Qualcomm memory-corruption flaw on devices whose vendors gate the update.",
       "UK-CAF-B4": "System-security patching assumes the operator controls the update, but this chipset-level memory corruption depends on downstream OEM firmware builds, leaving no operator-side remediation the principle can invoke.",
-      "AU-Essential-8-Patch": "Essential-Eight application and OS patch maturity has no lever over silicon-level firmware; a KEV-listed Qualcomm chipset flaw stays exploitable until the device maker ships an integrated build."
+      "AU-Essential-8-Patch": "Qualcomm chipset software falls in the driver and firmware classes, which the Essential Eight covers only at Maturity Level Three: ISM-1879 and ISM-1903 require the fix within 48 hours of release when the vendor rates the flaw critical or a working exploit exists, and ISM-1697 and ISM-1904 allow one month otherwise. Maturity Levels One and Two set no timeframe for drivers or firmware. CISA lists this memory corruption as exploited and a proof of concept is public, so the 48-hour window applies at Maturity Level Three. The fix needs a reboot, and the flaw stays exploitable until the device maker ships a build carrying the fix."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -147232,7 +147819,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-vulnerability-management": "NIS2 vulnerability handling prioritises by remote reachability and under-weights a reliable local root like this create_elf_tables() integer overflow, which upgrades any low-privileged foothold on a Linux server to full compromise via a SUID binary.",
       "UK-CAF-B4": "CAF B4 config baselines cannot block a SUID-binary integer overflow that overwrites the stack to gain root, and kernel patching across the Linux estate lags behind the reboot windows B4 assumes available.",
-      "AU-Essential-8-Patch": "The Essential Eight patch model prioritises internet-facing services, so a local kernel privilege escalation on internal Linux hosts falls outside its cadence despite being the reliable pivot to root."
+      "AU-Essential-8-Patch": "The Linux kernel is an operating system. On an internet-facing server, ISM-1877 requires a patch or other vendor mitigation within 48 hours of release at every maturity level when a working exploit exists, and ISM-1696 sets the same 48 hours for workstations and internal servers at Maturity Level Three. At Maturity Levels One and Two, ISM-1695 allows those hosts one month, although CISA lists this create_elf_tables() integer overflow, which lets a local user with access to a SUID binary escalate privileges, as exploited. The fixed kernel needs a reboot, and no live patch is recorded for this flaw."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -148470,7 +149057,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "Patch scheduling deprioritises a 5.5 local information-disclosure, but its KEV listing reflects use as the memory-leak stage that defeats ASLR for a paired DWM elevation, so routine cadence ignores its real role in an exploitation chain.",
       "UK-CAF-B4": "System-security controls treat low-severity info-disclosure as non-urgent, yet this DWM leak actively supplies the address-layout knowledge an attacker needs to weaponise a companion privilege-escalation on the same host.",
-      "AU-Essential-8-Patch": "Essential-Eight patch prioritisation by CVSS would defer this 5.5 leak, but its confirmed exploitation as a chain component means the low score understates a patch window that must close at incident speed."
+      "AU-Essential-8-Patch": "This Desktop Window Manager flaw lets an authorized local attacker disclose information. On Windows workstations and internal servers, ISM-1695 allows one month at Maturity Levels One and Two, and ISM-1696 requires the fix within 48 hours only at Maturity Level Three, when the vendor rates the flaw critical or a working exploit exists. CISA lists the flaw as exploited and a proof of concept is public, so below Maturity Level Three it can stay open for a month while attackers use it. The fix takes effect only after a reboot. An internet-facing Windows server falls under ISM-1877, which requires the fix within 48 hours at every maturity level."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -150149,7 +150736,7 @@
       "NIST-800-53-AC-6": "Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
       "NIS2-Art21-network-security": "Network-security duties assume a vendor patch path, but these D-Link routers are end-of-life with no fix, so the only real control is isolating or replacing the device — which the measure does not compel.",
       "UK-CAF-B4": "The system-security principle lacks a lifecycle-retirement control for end-of-life edge routers, leaving a KEV-listed buffer-overflow RCE reachable on hardware the vendor will never patch.",
-      "AU-ISM-1546": "ISM patching guidance presumes an available vendor patch; for these EoL D-Link routers there is none, so the control needs the explicit decommission/replace escalation this KEV entry demands."
+      "AU-Essential-8-Patch": "A D-Link router is an internet-facing network device, so where D-Link still supports the model, ISM-1877 requires the firmware fix within 48 hours of release at every maturity level, since CISA lists the flaw as exploited. Installing it needs a reboot, which takes down the router the site's traffic passes through and has to be scheduled. CISA warns that the affected models may be end-of-life. For a model D-Link no longer supports, the requirement is replacement: ISM-1501 requires an unsupported operating system to be replaced at every maturity level, and ISM-1753, outside the Essential Eight profiles, requires an unsupported internet-facing network device to be replaced."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -150709,7 +151296,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-vulnerability-management": "Mobile-fleet vulnerability-management rarely tracks Android Framework patch levels against KEV, and OEM/carrier patch-delivery lag widens an exposure window the framework's SLAs never accounted for.",
       "UK-CAF-B4": "Device-hardening baselines cannot remediate an Android Framework privilege-escalation whose fix depends on OEM and carrier delivery outside the operator's control.",
-      "AU-Essential-8-Patch": "OS-patch maturity assumes the operator can deploy a fix, but a KEV-listed Android Framework LPE is gated by fragmented OEM patch pipelines, so the target is unachievable in practice."
+      "AU-Essential-8-Patch": "ISM-1878 requires this Android Framework privilege escalation, listed in KEV on 2025-12-02 with a working exploit, to be patched within 48 hours of the manufacturer's update release. That control is outside the Essential Eight profiles: an Android handset is IT equipment other than a workstation, server or network device, and the Essential Eight operating system patch timeframes (ISM-1877, ISM-1695, ISM-1696) name only those. Each manufacturer releases the update on its own schedule, so the window opens at a different time on each handset model, and the update needs a reboot. ISM-1501 requires handsets whose operating system the manufacturer no longer supports to be replaced at every maturity level."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -151488,7 +152075,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "NIS2 patch-management prioritises internet-facing exposure, but this kernel race is a local SYSTEM-privilege step used after initial access, so deprioritising a 7.8 local EoP leaves attackers the escalation primitive to complete an intrusion.",
       "UK-CAF-B4": "CAF system-security assurance weighted toward perimeter patching underrates a kernel race that hands a low-privilege foothold full SYSTEM; the control set does not treat local privilege-escalation as a boundary event.",
-      "AU-Essential-8-Patch": "Essential-Eight's patch-operating-systems tier keys off vendor severity, so a 7.8 local kernel EoP rides the routine cadence while it is actively used in the wild to reach SYSTEM."
+      "AU-Essential-8-Patch": "Windows kernel fixes fall under the Essential Eight patch operating systems controls. ISM-1695 allows workstations and non-internet-facing servers one month at Maturity Levels One and Two, so this 7.8 local kernel race condition, which CISA lists as exploited and which gives a low-privileged local attacker SYSTEM access, can wait a month at those levels. Because a working exploit exists, ISM-1696 applies 48 hours at Maturity Level Three, and ISM-1877 applies 48 hours on internet-facing servers at every level. The fix requires a reboot and no live patch is available, and the controls set the same deadlines whether or not a restart is needed."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -152827,7 +153414,7 @@
       "NIST-800-53-AC-6": "Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
       "NIS2-Art21-patch-management": "This JavaScriptCore web-content RCE affects Apple products that may be end-of-life; NIS2 patch-management presumes a vendor fix exists, but for end-of-service devices the only remediation is decommissioning, which cadence-based patch policy doesn't mandate.",
       "UK-CAF-B4": "System-security asset-lifecycle controls must force retirement of end-of-life Apple hardware, because a drive-by JavaScriptCore RCE on an unsupported device has no patch and stays exploitable until the device is removed from service.",
-      "AU-Essential-8-Patch": "Essential-Eight patch targets are unachievable where the affected Apple products are end-of-service; the strategy assumes a patch to apply, whereas here only device replacement closes the web-content RCE."
+      "AU-Essential-8-Patch": "On Apple devices that have reached end of service, only replacing the device or taking it out of use removes this JavaScriptCore web-content code-execution flaw. ISM-1501 requires an unsupported operating system to be replaced and ISM-1704 requires an unsupported browser to be removed, both at every maturity level. On supported devices below Maturity Level Three, ISM-1691 allows two weeks to patch Safari and ISM-1695 allows one month to patch macOS, even though this flaw is in CISA's Known Exploited Vulnerabilities catalog. ISM-1692 and ISM-1696 require the patch within 48 hours of release only at Maturity Level Three."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -153612,7 +154199,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "Microsoft remediated this by removing the third-party Agere modem driver outright rather than fixing it, so NIS2 patch-management framed as 'apply the update' does not capture that the compliant action is deleting a bundled legacy component.",
       "UK-CAF-B4": "CAF system-security assumes a maintainable component, but the untrusted-pointer-deref privesc lives in an abandoned in-box modem driver, so hardening means removing the driver, not patching it.",
-      "AU-Essential-8-Patch": "Essential-Eight patch-OS guidance presumes a fix ships; here the vulnerable Agere driver was withdrawn entirely, so estates that only 'apply patches' without removing the legacy driver retain the admin-privilege escalation."
+      "AU-Essential-8-Patch": "The Agere modem driver is a component of Microsoft Windows, so its fix falls under the operating system patching controls. On workstations and non-internet-facing servers, ISM-1695 allows one month from release at Maturity Levels One and Two. At Maturity Level Three, ISM-1696 and, for drivers, ISM-1879 require the patch within 48 hours of release when a working exploit exists. CISA added this privilege escalation to the Known Exploited Vulnerabilities catalog on 2025-10-14 with a proof of concept available, so the lower levels allow a month for a flaw under active exploitation, and the update requires a restart that the patch windows do not plan for."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -154282,7 +154869,7 @@
       "NIST-800-53-AC-6": "Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
       "NIS2-Art21-patch-management": "Patch management presumes a vendor fix exists; this KEV-listed IE RCE affects end-of-life software CISA says to discontinue, so the compliant action is removal, a case Art. 21's patch focus does not frame.",
       "UK-CAF-B4": "System-security outcomes assume a patch path, but for an EoL Internet Explorer RCE the only mitigation is retiring the browser, a decommissioning action the principle does not compel.",
-      "AU-Essential-8-Patch": "Essential-Eight patch maturity is unattainable for an EoL IE with no vendor fix; the effective control is removing the legacy browser, which the patch-timeline model does not force."
+      "AU-Essential-8-Patch": "Internet Explorer is a web browser, so its vendor fix is due within two weeks of release at Maturity Levels One and Two (ISM-1691) and, because a working exploit exists, within 48 hours at Maturity Level Three (ISM-1692). Neither timeframe provides for the restart the fix requires, and no live patch exists. At Maturity Levels One and Two, the two-week window still applies although CISA lists the flaw in its Known Exploited Vulnerabilities catalog. ISM-1704 requires an unsupported browser to be removed at every maturity level, and where Internet Explorer is end-of-life, as the vulnerability description says it may be, removal is the effective remediation."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -154392,7 +154979,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "Patch-management duties deprioritize a local CLFS-driver privilege escalation, but this KEV-listed bug is a recurring ransomware-chain escalation primitive and needs the accelerated cadence its active exploitation warrants.",
       "UK-CAF-B4": "The system-security principle does not mandate hardening or rapid patching of the Common Log File System kernel driver, the exact component this actively-exploited LPE abuses to bypass security mechanisms.",
-      "AU-Essential-8-Patch": "Essential-Eight OS-patch prioritization treats a local-only CLFS-driver LPE as lower-tier, yet reboot-dependent kernel fixes routinely slip past the window while this KEV-listed flaw is exploited."
+      "AU-Essential-8-Patch": "Windows is an operating system, so its patch window depends on where it runs. On workstations and internal servers, ISM-1695 allows one month at Maturity Levels One and Two, and ISM-1696 requires 48 hours at Maturity Level Three when the vendor rates a flaw critical or a working exploit exists. On internet-facing servers, ISM-1877 requires 48 hours at every level under the same condition. CISA listed this CLFS driver flaw as exploited on 2025-10-06 and a public proof of concept exists, yet a compliant Maturity Level Two fleet of workstations and internal servers can leave it unpatched for a month. The fix also needs a reboot, which none of these windows plans for."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -156415,7 +157002,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "Android fleet patching is carrier- and OEM-gated, so an Android Runtime use-after-free enabling a browser-sandbox escape to local privilege escalation cannot be closed on the enterprise's own schedule — a control gap patch-management obligations do not account for.",
       "UK-CAF-B4": "CAF's device secure-configuration and update-enforcement objective does not account for OEM-controlled Android patch latency, leaving a KEV-listed sandbox-escape-to-LPE open on devices the operator cannot directly update.",
-      "AU-Essential-8-Patch": "The Essential Eight patch-OS 48-hour maturity is unreachable on Android where the update path is OEM- and carrier-controlled, leaving this ART use-after-free sandbox escape exploitable well past the target window."
+      "AU-Essential-8-Patch": "An Android handset is IT equipment other than a workstation, server or network device, so the Essential Eight operating system patch timeframes (ISM-1877, ISM-1695, ISM-1696) do not include it. ISM-1878, outside the Essential Eight profiles, requires this KEV-listed Android Runtime use-after-free, which can allow a Chrome sandbox escape and has a working exploit, to be patched within 48 hours of release. The window does not start until an update for that handset is released, and the update needs a reboot. A handset whose manufacturer no longer supports its operating system receives no fix, and ISM-1501 requires it to be replaced at every maturity level."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -156638,7 +157225,7 @@
       "NIST-800-53-AC-6": "Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
       "NIS2-Art21-network-security": "Network-security measures do not compel retiring an end-of-life SOHO router, yet this TP-Link httpd auth-bypass leaks stored credentials over port 80 with no vendor fix forthcoming.",
       "UK-CAF-B2": "Identity-and-access-control assurance is defeated at the root because the spoofing bypass in the TL-WR841N httpd service discloses the stored credentials themselves, handing over the identity material the principle is meant to protect.",
-      "AU-ISM-1546": "ISM patch/hardening guidance assumes a supported device; this EoL TP-Link router has no patch path, so the control must escalate to decommission rather than remediate the credential-disclosing bypass."
+      "AU-Essential-8-Patch": "The TL-WR841N is a router, an internet-facing network device, so ISM-1877 requires vendor fixes within 48 hours of release at every maturity level when a working exploit exists, which CISA's 2025-09-03 listing confirms. The published description also warns that affected units may be end-of-life or end-of-service and tells users to stop using them. For any unit with no fixed firmware, the window has nothing to apply, and replacement falls to ISM-1501, which sets no timeframe, and ISM-1753, which is outside the Essential Eight. Until then, a spoofed request to the httpd service on TCP port 80 discloses stored credentials."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -156975,7 +157562,7 @@
       "NIST-800-53-AC-6": "Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
       "NIS2-Art21-incident-handling": "Incident-handling processes assume attacker interaction, but this WhatsApp linked-device authorization flaw enables zero-click processing of attacker-controlled URLs — chained with an Apple zero-day for mercenary spyware — leaving responders reacting to compromise with no user-triggerable indicator.",
       "UK-CAF-B4": "System-security controls cannot remediate an incorrect-authorization flaw in a third-party consumer messenger; the operator can neither patch WhatsApp's device-sync logic nor prevent the zero-click content fetch it enables.",
-      "AU-Essential-8-Patch": "Essential-Eight patch cadence assumes managed applications, but a zero-click authorization bug in a consumer messaging app is remediated only on Meta's release schedule, outside any patch window the control can set."
+      "AU-Essential-8-Patch": "WhatsApp is a consumer messaging app in the ISM's other applications class. In this flaw, incomplete authorization of linked device synchronization messages lets an unrelated user make the target's device process content from an arbitrary URL. ISM-1693 requires Meta's fix to be applied within one month of release at Maturity Levels Two and Three and sets no timeframe at Maturity Level One. CISA lists the flaw as known exploited, and ISM-1693 still allows the full month. The window starts only when Meta releases the fix, and no control requires forcing the app to update automatically on the devices that run it."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -162463,7 +163050,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-patch-management": "This Adreno GPU use-after-free is triggered from web content in Chrome on mobile, but the fix lives in chipset firmware whose delivery is OEM/carrier-gated, so NIS2 patch-management cannot bind a cadence to devices whose update path it does not control.",
       "UK-CAF-B4": "CAF system-security baselines address OS and app configuration, not GPU-driver firmware; a browser-reachable UAF in the Qualcomm graphics stack stays exploitable until an OEM ships firmware, outside the tracked patch surface.",
-      "AU-Essential-8-Patch": "Essential-Eight patch timelines are unenforceable against Qualcomm chipset firmware, which reaches devices months after the vendor bulletin, leaving this browser-triggered memory corruption exploitable across the gap."
+      "AU-Essential-8-Patch": "The use-after-free in the Adreno GPU driver on Qualcomm chipsets corrupts memory when Chrome renders graphics. Drivers fall under ISM-1879, which requires patches within 48 hours of release when a working exploit exists, and ISM-1697, which allows one month otherwise, both at Maturity Level Three only. CISA added the flaw to the Known Exploited Vulnerabilities catalog on 2025-06-03 with a proof of concept available, yet Maturity Levels One and Two set no timeframe for it, and the fix requires a restart. On handsets the operating system update that carries the driver falls under ISM-1878, which is outside the Essential Eight profiles."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -163245,7 +163832,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-network-security": "Network-security measures do not treat a biometric time-attendance appliance as an exposed asset, yet ZKTeco BioTime's iclock API allows an unauthenticated attacker to read arbitrary files over the network.",
       "UK-CAF-B4": "Secure-configuration expectations do not force the BioTime iclock API off untrusted networks, which is the decisive control against this unauthenticated path-traversal file read.",
-      "AU-ISM-1546": "ISM internet-facing service hardening is not enforced strongly enough to keep an unauthenticated arbitrary-file-read endpoint like BioTime's iclock API off the public edge, where it is being exploited."
+      "AU-Essential-8-Patch": "A BioTime deployment whose iclock API is reachable from the internet is an online service, so ISM-1876 requires the fix within 48 hours of release at every maturity level when the vendor rates the flaw critical or a working exploit exists, as the public proof of concept shows. A deployment reachable only from the internal network falls under ISM-1693, which allows one month from release and applies from Maturity Level Two. The fix takes effect only after a service restart or reboot. Patching does not undo the disclosure of files already read, so credentials the service could read stay exposed until they are rotated."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -164477,7 +165064,7 @@
       "NIST-800-53-AC-6": "Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
       "NIS2-Art21-patch-management": "CLFS heap-overflow privesc is a staple ransomware-affiliate SYSTEM-escalation primitive; NIS2 patch-management framed for perimeter urgency underweights a local EoP crews chain immediately after initial access to enable encryption at scale.",
       "UK-CAF-B4": "CAF system-security assurance treats local privilege-escalation as lower priority than remote flaws, yet this CLFS overflow is precisely the post-foothold SYSTEM step ransomware operators need, inverting the assumed risk order.",
-      "AU-Essential-8-Patch": "Essential-Eight's patch-OS tier processes a CLFS privesc as routine, but its real-world role as a ransomware escalation primitive demands the accelerated cadence the maturity model reserves for internet-facing critical flaws."
+      "AU-Essential-8-Patch": "CISA listed this heap-based buffer overflow in the Windows CLFS driver, which lets an authorized attacker elevate privileges locally, as exploited on 2025-05-13, and a proof-of-concept exploit exists. The driver is part of Windows, so the operating system controls apply. ISM-1695 allows one month for workstations and non-internet-facing servers at Maturity Levels One and Two, ISM-1696 requires 48 hours for them at Maturity Level Three, and ISM-1877 requires 48 hours for internet-facing servers at every level. Below Level Three, a workstation can therefore wait a month for the fix to an exploited flaw. No live patch exists, so applying the fix within any window includes rebooting each host."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -164587,7 +165174,7 @@
       "ISO-27001-2022-A.8.8": "Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses 'patch-cycle response' to 'incident-speed response'.",
       "NIS2-Art21-vulnerability-management": "CLFS driver use-after-frees are a recurring ransomware-affiliate escalation primitive, and NIS2 handling that prioritises remote CVEs under-weights this local UAF that intrusions chain to SYSTEM immediately before encryption.",
       "UK-CAF-B4": "Patch-Tuesday cadence leaves the KEV-listed CLFS use-after-free exploitable in the interval, and CAF B4 config baselines cannot disable the kernel Common Log File System driver the exploit abuses.",
-      "AU-Essential-8-Patch": "The Essential Eight patch model ranks this non-internet-facing driver flaw low, yet the CLFS UAF is the exact local escalation step observed in active ransomware intrusions, so the maturity model mis-prioritises it."
+      "AU-Essential-8-Patch": "The CLFS driver is a component of Microsoft Windows, so the operating system controls govern this use-after-free, which lets an authorized attacker elevate privileges locally. On workstations and non-internet-facing servers, ISM-1695 allows one month at Maturity Levels One and Two, and ISM-1696 requires 48 hours at Maturity Level Three because a proof-of-concept exploit exists. ISM-1877 requires 48 hours at every level on internet-facing servers. CISA listed the flaw as exploited on 2025-05-13, and below Level Three a workstation or internal server may still wait a month. The update needs a reboot and no live patch exists, so meeting any window means restarting each host within it."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -164697,7 +165284,7 @@
       "NIS2-Art21-network-security": "Article 21 network-security measures do not model an AI ingestion crawler as an SSRF pivot into the internal network.",
       "DORA-Art-9": "ICT protection measures do not model a RAG engine's server-side fetch as an ICT-risk egress.",
       "UK-CAF-B4": "System security objective has no objective for destination validation on AI-pipeline server-side fetches.",
-      "AU-ISM-1546": "Patch-application control does not single out RAG / AI-pipeline platforms.",
+      "AU-Essential-8-Patch": "A RAGFlow instance directly accessible over the internet is an online service, and because a public proof of concept exists, ISM-1876 requires the upgrade to 0.14.0 within 48 hours of release at every maturity level, instead of ISM-1690's two weeks. An internal-only instance is an other application, patched within one month under ISM-1693 from Maturity Level Two. The remediation also calls for rejecting private, link-local, cloud-metadata and file:// targets and sandboxing the headless browser, which the patching controls do not require. The crawler drives an outdated headless Chromium with its sandbox disabled and exposed to known V8 exploits, and a RAGFlow patch record does not show whether that browser is current.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an AI data-pipeline's server-side fetch as an egress that must validate and allowlist destinations."
     },
     "atlas_refs": [
@@ -164810,7 +165397,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control measures do not prevent predictable-token account takeover in AI apps.",
       "DORA-Art-9": "ICT protection measures do not model predictable token generation in an AI app as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective has no objective for token-generation entropy on AI app-platform APIs.",
-      "AU-ISM-1546": "Patch-application control does not single out RAG / AI-pipeline platforms.",
+      "AU-Essential-8-Patch": "RAGFlow deployed for internal use is an other application under ISM-1693, which requires the 0.22.0 fix within one month of release from Maturity Level Two and sets no timeframe at Maturity Level One. An instance reachable over the internet is an online service, patched at every maturity level within 48 hours under ISM-1876 when the vendor rates the flaw critical or a working exploit exists and within two weeks under ISM-1690 otherwise. Upgrading satisfies the control, but API keys and share tokens issued by the vulnerable version stay valid and derivable from shared URLs until they are rotated, and no patching control requires that rotation.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an AI app platform's API-key / share-token generation (CSPRNG + unpredictable secret) as an authentication-integrity control."
     },
     "atlas_refs": [
@@ -164914,7 +165501,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model an LLM app framework's file-bearing API as a path-traversal surface.",
       "DORA-Art-9": "ICT protection measures do not model arbitrary file read in an AI app as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for path canonicalization on AI app-framework file APIs.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app frameworks.",
+      "AU-Essential-8-Patch": "Chainlit is a framework inside an organization's own LLM application, which makes it one of the Essential Eight's other applications: ISM-1693 requires the upgrade to 2.9.4 within one month of its release on 2025-12-24 at Maturity Levels Two and Three, and Maturity Level One does not include that control. An application run as an internet-facing online service falls under ISM-1876 instead, with 48 hours once a working exploit exists, and a proof of concept is public. The fix takes effect only as each application that bundles Chainlit is upgraded and redeployed, and until then any authenticated client can read arbitrary files on the server host.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM app framework's path-bearing input as an integrity boundary requiring canonicalization."
     },
     "atlas_refs": [
@@ -165019,7 +165606,7 @@
       "NIS2-Art21-network-security": "Article 21 network-security measures do not model an LLM app framework's server-side fetch as an SSRF pivot.",
       "DORA-Art-9": "ICT protection measures do not model an AI app framework's server-side fetch as an ICT-risk egress.",
       "UK-CAF-B4": "System security objective has no objective for destination validation on AI-app-framework server-side fetches.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM app frameworks.",
+      "AU-Essential-8-Patch": "For an organization's own Chainlit application, ISM-1693 requires the 2.9.4 fix, released on 2025-12-24, within one month at Maturity Levels Two and Three, since Chainlit is one of the Essential Eight's other applications; Maturity Level One does not include that control. ISM-1876 sets 48 hours for a working exploit, and a proof of concept is public, but only where the application runs as an internet-facing online service. On an internal deployment using the SQLAlchemy data layer, any authenticated client can make the server request internal services and cloud-metadata endpoints for the whole month, and the patching controls do not require blocking those requests while the window runs.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM app framework's server-side fetch as an egress that must validate and allowlist destinations."
     },
     "atlas_refs": [
@@ -165130,7 +165717,7 @@
     },
     "atlas_refs": [
       "AML.T0051",
-      "AML.T0040"
+      "AML.T0055"
     ],
     "attack_refs": [
       "T1059",
@@ -165229,7 +165816,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model an ML model-interchange library as a path-traversal / supply-chain surface.",
       "DORA-Art-9": "ICT protection measures do not model arbitrary file overwrite via a crafted ML model as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for path canonicalization in ML model-serialization libraries.",
-      "AU-ISM-1546": "Patch-application control does not single out ML model-format libraries.",
+      "AU-Essential-8-Patch": "ONNX is a library that ships inside applications of the ISM's other applications class, so ISM-1693 requires ONNX 1.18.0 within one month of release from Maturity Level Two, and Maturity Level One sets no timeframe. A proof of concept exists for the save_external_data path traversal, but the control allows the full month. Each environment that bundles the library has to be redeployed, and no control requires the recommended interim steps of confining the external_data location to the model directory and loading third-party models in a sandbox.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an ML model file's embedded paths as an integrity boundary requiring canonicalization on load/save."
     },
     "atlas_refs": [
@@ -165336,7 +165923,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model an LLM serving framework's weight-update endpoint as an RCE surface.",
       "DORA-Art-9": "ICT protection measures do not model deserialization RCE in an AI serving framework as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for safe deserialization in ML serving frameworks.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM serving frameworks.",
+      "AU-Essential-8-Patch": "An SGLang serving endpoint directly accessible from the internet is an online service. A public proof of concept exists, so ISM-1876 requires the fix within 48 hours of release at every maturity level. An instance reachable only from inside the organization is an other application under ISM-1693, which allows one month at Maturity Levels Two and Three only. In SGLang 0.4.6, update_weights_from_tensor deserializes serialized-object tensor data without validation, so a deployment that exposes it to untrusted input runs attacker code. The remediation guidance pairs the upgrade past 0.4.6 with restricting that path to trusted callers, and no patching control requires the restriction.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM serving framework's weight-update input as an integrity boundary requiring a safe (non-deserializing) tensor format."
     },
     "atlas_refs": [
@@ -165442,7 +166029,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model an LLM serving framework's template rendering as an RCE surface.",
       "DORA-Art-9": "ICT protection measures do not model template-injection RCE in an AI serving framework as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for sandboxed template rendering in ML serving frameworks.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM serving frameworks.",
+      "AU-Essential-8-Patch": "SGLang falls in the other applications class, so ISM-1693 requires the fixed SGLang version within one month of its release at Maturity Levels Two and Three, and Maturity Level One sets no timeframe for it; a rerank endpoint offered to the internet as an online service gets 48 hours under ISM-1876 instead. A public proof of concept exists for this CVSS 9.8 template-injection flaw, yet the 48-hour windows for a working exploit do not apply to other applications. The upgrade takes effect only after the serving process is redeployed, and a server that loads third-party model files stays exposed until then.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats a model-supplied chat template as untrusted code requiring a sandboxed renderer."
     },
     "atlas_refs": [
@@ -165554,7 +166141,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model a workflow-automation platform's form actions as an unauthenticated file-access surface.",
       "DORA-Art-9": "ICT protection measures do not model unauthenticated file access in an AI-workflow platform as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for authentication + path confinement on workflow-platform form actions.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-workflow / automation platforms.",
+      "AU-Essential-8-Patch": "A self-hosted n8n instance is one of the Essential Eight's other applications, so ISM-1693 requires the upgrade to n8n 1.121.0 within one month of release at Maturity Levels Two and Three, and Maturity Level One does not include that control. ISM-1876 requires 48 hours for a critical vulnerability or a working exploit only where the organization runs the instance as an internet-facing online service. An internal instance therefore has a month despite a CVSS score of 10 and a public exploit that turns this unauthenticated file access into host code execution when the local database or configuration is readable.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats a workflow-automation platform's form-action file path as an integrity boundary requiring auth + confinement."
     },
     "atlas_refs": [
@@ -165662,7 +166249,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model a workflow builder's code node as a sandbox-escape RCE surface.",
       "DORA-Art-9": "ICT protection measures do not model code-node sandbox escape in an AI-workflow platform as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for non-bypassable code-node sandboxing in workflow platforms.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-workflow / automation platforms.",
+      "AU-Essential-8-Patch": "On internal networks, n8n falls under other applications: ISM-1693 requires the fix within one month at Maturity Levels Two and Three, and no timeframe applies at Maturity Level One, although a proof of concept is public and a user with workflow-edit permission can escape the sandbox and run code as the n8n process. An instance reachable from the internet is an online service, and the public proof of concept meets the working-exploit condition of ISM-1876, which applies 48 hours at every level. No 1.x release contains the fix, which first ships in 2.0.0, so every 1.x instance needs a major-version upgrade inside either window.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats a visual workflow builder's code node as a code-execution sink requiring a non-bypassable sandbox."
     },
     "atlas_refs": [
@@ -165765,7 +166352,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model an image-generation web UI's backup feature as a file-write surface.",
       "DORA-Art-9": "ICT protection measures do not model limited file write in an AI image-gen UI as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for path confinement on AI web-UI file features.",
-      "AU-ISM-1546": "Patch-application control does not single out AI image-generation web UIs.",
+      "AU-Essential-8-Patch": "An internet-accessible stable-diffusion-webui instance is an online service, so ISM-1876 requires the fix within 48 hours of release at every maturity level because a proof of concept exists, where ISM-1690 would otherwise allow two weeks. An internal-only instance is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. The fix is commit d9708c92b444894bce8070e4dcfaa093f8eb8d43, and 1.8.0 is still affected, so an upgrade from 1.7.0 to 1.8.0 looks complete while the Backup/Restore tab still writes a JSON file to any path a user supplies on a Windows host. Either control is met only by a build containing that commit.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an AI web UI's user-supplied file path as an integrity boundary requiring confinement."
     },
     "atlas_refs": [
@@ -165881,7 +166468,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model an LLM serving framework's IPC channel as an unauthenticated RCE surface.",
       "DORA-Art-9": "ICT protection measures do not model unauthenticated IPC-deserialization RCE in an AI serving framework as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for authenticated, safe-serialized IPC in ML serving frameworks.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM serving frameworks.",
+      "AU-Essential-8-Patch": "SGLang's multimodal generation module runs a ZMQ broker in scheduler_client.py that deserializes objects from unauthenticated peers (CWE-502), so anyone who can reach the channel can execute code on the serving host. A serving instance directly accessible over the internet is an online service, and because a proof of concept exists, ISM-1876 requires 0.5.10 (PR #20904) within 48 hours of release at every maturity level. ISM-1693 gives an internal instance one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. The upgrade also requires redeploying the serving process. No control requires authenticating ZMQ peers or isolating the channel on a trusted segment meanwhile.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM serving framework's IPC channel as an integrity boundary requiring a safe serializer + peer authentication."
     },
     "name": "SGLang Multimodal-Generation ZMQ Broker Unauthenticated Deserialization RCE",
@@ -165984,7 +166571,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model an LLM serving framework's IPC channel as an unauthenticated RCE surface.",
       "DORA-Art-9": "ICT protection measures do not model unauthenticated IPC-deserialization RCE in an AI serving framework as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for authenticated, safe-serialized IPC in ML serving frameworks.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM serving frameworks.",
+      "AU-Essential-8-Patch": "In SGLang's encoder parallel disaggregation system, encode_receiver.py deserializes objects from unauthenticated peers (CWE-502), so a crafted object from anyone who can reach the disaggregation channel executes code on the serving host. A serving instance directly accessible over the internet is an online service; because a proof of concept exists, ISM-1876 requires 0.5.10 within 48 hours of release at every maturity level. For an internal instance, ISM-1693 requires the upgrade within one month at Maturity Levels Two and Three and does not apply at Maturity Level One. Applying the fix includes redeploying the serving process. No control requires authenticating peers or isolating the channel while the window runs.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM serving framework's IPC channel as an integrity boundary requiring a safe serializer + peer authentication."
     },
     "name": "SGLang Encoder-Parallel Disaggregation Unauthenticated Deserialization RCE",
@@ -166074,7 +166661,7 @@
       "NIS2-Art21-network-security": "Article 21 measures do not model a workflow builder's Git node as an arbitrary-file-write-to-RCE surface.",
       "DORA-Art-9": "ICT protection measures do not model file-write RCE in an AI-workflow platform as an ICT-risk event.",
       "UK-CAF-B4": "System security objective has no objective for constraining file-writing workflow nodes.",
-      "AU-ISM-1546": "Patch-application control does not single out AI-workflow / automation platforms.",
+      "AU-Essential-8-Patch": "A self-hosted n8n instance is one of the Essential Eight's other applications, covered from Maturity Level Two by ISM-1693, which requires the upgrade to 1.121.3 within one month of release; ISM-1693 is not part of Maturity Level One. ISM-1876 and its 48 hours for a critical vulnerability or a working exploit apply at every maturity level, but only where the organization runs the instance as an internet-facing online service. An internal instance has the full month to upgrade although a proof of concept is public, and the patching controls do not require the vendor's restrictions on the file types and paths the Git node can write or on workflow-edit permission.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats a workflow builder's file-writing node as a code-execution sink requiring type/path constraint."
     },
     "atlas_refs": [
@@ -166408,7 +166995,7 @@
       "ISO-27001-2022-A.8.8": "Standard 30-day reading is unsafe for a flaw that lets an on-path attacker inject authenticated mail commands; cryptographic controls (A.8.24) are present but defeated by the buffering defect, not the cipher.",
       "UK-CAF-B4": "System security principle treats TLS as the boundary; the STARTTLS receive-buffer defect means the boundary is crossed before TLS applies, which the principle does not model.",
       "NIS2-Art21-network-security": "Network-security duties treat TLS as securing mail transport, but this Exim STARTTLS buffering defect lets an on-path attacker inject commands consumed after the handshake, so the negotiated cipher never protects the session.",
-      "AU-ISM-1546": "ISM internet-facing service hardening does not force MTAs onto implicit TLS over opportunistic STARTTLS, the decisive mitigation here since the flaw lives in the pre-handshake buffer, not the cipher."
+      "AU-Essential-8-Patch": "An Exim server that exchanges mail with the internet is an online service, patched at every maturity level within 48 hours of release when a working exploit exists (ISM-1876) and within two weeks otherwise (ISM-1690). Because tooling for the flaw is public, the 48-hour window applies, although exploitation needs an on-path attacker and no in-the-wild campaign is confirmed. The window falls short on scope: upgrading to Exim 4.95 closes the pre-handshake buffer flaw in Exim alone, and the patch record does not show whether other MTAs and submission agents in the estate carry the same STARTTLS injection class."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -166895,7 +167482,7 @@
       "NIS2-Art21-vulnerability-handling": "Article 21 vulnerability-handling measures do not enforce accelerated kernel patching/live-patching for a KEV-listed container-escape primitive across the container fleet.",
       "DORA-Art-9": "ICT protection measures do not model an unprivileged-container-to-host kernel escape as an ICT-risk event crossing the workload isolation boundary.",
       "UK-CAF-B4": "System Security objective lacks an objective for hardening container hosts (AppArmor/SELinux/seccomp, disabling unprivileged user namespaces) so a single kernel cgroups flaw cannot become host root.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "The Linux kernel is an operating system. Because CISA lists the flaw as exploited, internet-facing container hosts must be patched within 48 hours of release at every maturity level (ISM-1877), while internal hosts get one month at Maturity Levels One and Two (ISM-1695) and 48 hours only at Maturity Level Three (ISM-1696). Affected NetApp HCI and SolidFire firmware is covered only at Maturity Level Three (ISM-1903). The fix spans several kernel series and needs a reboot unless a vendor live patch exists, and no patching control requires disabling unprivileged user namespaces or confining containers with AppArmor, SELinux or seccomp while the window runs."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -167004,7 +167591,7 @@
       "ISO-27001-2022-A.8.9": "Configuration management does not flag devices whose supported-firmware lifecycle has ended, leaving them in service past the point any fix is possible.",
       "NIS2-Art21-supply-chain": "Article 21 risk-management measures do not require enumerating and retiring unsupported network-attached devices whose vendor has ended security maintenance.",
       "UK-CAF-B4": "System Security has no objective for identifying and removing internet-exposed unsupported devices that can never be patched.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "GeoVision GV-VS12, GV-VS11, GV-DSP_LPR and GVLX_4 are end-of-life IP devices, and GeoVision will release no fix for this unauthenticated command injection. Whether their software is patched as firmware under ISM-1903 (Maturity Level Three only) or as the operating system of an internet-facing network device under ISM-1877 (every level), the 48-hour window for a working exploit counts from a release that GeoVision will not issue. ISM-1501 requires unsupported operating systems to be replaced at every maturity level but sets no deadline. Akamai confirmed in April 2025 that an LZRD Mirai variant was recruiting exposed devices, and CISA set a KEV due date of 2025-05-28."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -167112,7 +167699,7 @@
       "NIS2-Art21-vulnerability-handling": "Article 21 vulnerability-handling measures do not enforce accelerated patching of a KEV-listed unauthenticated data-access flaw on exposed middleware.",
       "DORA-Art-9": "ICT protection measures do not model unauthenticated T3/IIOP data exposure on an internet-reachable application server as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective lacks an objective for restricting and authenticating application-server remoting protocols (T3/IIOP) at the network boundary.",
-      "AU-ISM-1546": "Patch-application control does not single out middleware/application-server critical patch updates (Oracle CPU) for accelerated application when KEV-listed."
+      "AU-Essential-8-Patch": "A WebLogic Server instance directly accessible over the internet is an online service. Because CISA lists the flaw as known exploited, ISM-1876 applies at every maturity level and requires the July 2024 Critical Patch Update within 48 hours of release, instead of ISM-1690's two weeks; either window ended long before the 2026-06-01 listing. An internal-only instance is an other application: ISM-1693 requires the update within one month from Maturity Level Two and sets no timeframe at Maturity Level One, although any host that reaches its port can use the unauthenticated T3/IIOP path. The fix also needs an admin and managed server restart, which the windows do not plan for."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -167235,7 +167822,7 @@
       "ISO-27001-2022-A.8.9": "Configuration management does not flag devices whose supported-firmware lifecycle has ended, leaving them in service past the point any fix is possible.",
       "NIS2-Art21-supply-chain": "Article 21 risk-management measures do not require enumerating and retiring unsupported network-attached devices whose vendor has ended security maintenance.",
       "UK-CAF-B4": "System Security has no objective for identifying and removing internet-exposed unsupported devices that can never be patched.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "These end-of-life GeoVision devices are IT equipment other than workstations, servers and network devices. ISM-1878 (48 hours for a critical vulnerability or a working exploit) and ISM-1751 (one month otherwise) set their patching timeframes, and neither is in an Essential Eight profile. GeoVision will issue no firmware fix, so neither timeframe can start and patching cannot meet the KEV due date of 2025-05-28. ISM-1501 requires unsupported operating systems to be replaced at every maturity level but sets no deadline. Akamai SIRT confirmed in April 2025 that an LZRD Mirai variant exploits the unauthenticated command injection, so an exposed device remains exploitable until it is replaced or isolated from untrusted networks."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -167342,7 +167929,7 @@
       "NIS2-Art21-vulnerability-handling": "Article 21 vulnerability-handling measures do not reach embedded third-party media-parsing libraries shipped inside applications.",
       "DORA-Art-9": "ICT protection measures do not model an embedded font-parsing library as an ICT-risk code-execution surface.",
       "UK-CAF-B4": "System Security objective has no requirement to inventory and patch embedded media-parsing libraries across the software estate.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "FreeType is a library, so the patching timeframe follows the product that embeds it. At Maturity Levels One and Two, ISM-1691 allows two weeks for a browser or PDF application and ISM-1695 allows one month for a workstation operating system, and the 48-hour windows for a working exploit (ISM-1692, ISM-1696) apply only at Maturity Level Three, although CISA listed the flaw as exploited on 2025-05-06. Each embedding product ships its own fixed build, such as the Debian bullseye backport or the May 2025 Android patch level, and every application that links FreeType must be restarted before the fix takes effect."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -167456,7 +168043,7 @@
       "NIS2-Art21-vulnerability-handling": "Article 21 vulnerability-handling measures do not enforce timely monthly OS patch application to close an actively-exploited LPE.",
       "DORA-Art-9": "ICT protection measures do not model an OS desktop-compositor use-after-free as an ICT-risk privilege-escalation event.",
       "UK-CAF-B4": "System Security objective has no requirement to apply monthly OS security rollups within the KEV remediation window.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "The DWM Core Library is part of the Windows operating system. For workstations and non-internet-facing servers, ISM-1695 allows one month at Maturity Levels One and Two, and ISM-1696 requires 48 hours at Maturity Level Three when a working exploit exists; internet-facing servers get 48 hours at every level under ISM-1877. Microsoft reported the flaw exploited in the wild in the May 2025 release that fixed it, which means exploitation began before any window opened. A Level One or Two fleet can then stay exposed for a further month. The fix is a cumulative update that needs a reboot, and Microsoft offers no hotpatch."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -167559,7 +168146,7 @@
       "ALL-AI-PIPELINE-INTEGRITY": "No framework requires verifying that a product's actual data-handling behavior matches its documented/marketed security properties, so undocumented cleartext retention (hidden functionality) in a backend goes unchecked.",
       "NIS2-Art21-vulnerability-management": "NIS2 Article 21 vulnerability-handling does not bind the remediation window to the KEV due-date; a known-exploited vulnerability must be remediated on the KEV clock, not a generic risk-based schedule.",
       "UK-CAF-B4": "The CAF System Security objective does not single out actively-exploited (KEV-listed) vulnerabilities on the exposed surface for accelerated, due-date-bound remediation.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "The TeleMessage archiving backend that held TM SGNL messages is an online service, so ISM-1876 requires a vendor patch or mitigation within 48 hours of its release at every maturity level when a working exploit exists, and NVD records exploitation in the wild in May 2025. The cleartext retention is a design property with no fixed version, so no timeframe starts. ISM-1905 requires removal only of online services their vendor no longer supports, while CISA's guidance, absent an adequate vendor mitigation, is to discontinue use. No patch control addresses messages the backend held in cleartext through 2025-05-05."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -167664,7 +168251,7 @@
       "NIS2-Art21-vulnerability-handling": "Article 21 vulnerability-handling measures do not enforce timely mobile-OS patch-level compliance for a KEV-listed local-privilege-escalation flaw.",
       "DORA-Art-9": "ICT protection measures do not model an unpatched mobile-OS privilege escalation on the managed fleet as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective lacks an objective for enforcing minimum mobile-OS patch levels and constraining untrusted-app installation on managed devices.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "Android devices are IT equipment other than workstations, servers and network devices, so ISM-1878 governs this Framework privilege escalation: because it is exploited in the wild, a working exploit exists and the fix is applied within 48 hours of release. ISM-1878 is outside the Essential Eight maturity profiles, so meeting any maturity level does not require it. Each device receives the 2026-06-01 patch level through its OEM or carrier OTA on that maker's schedule, and the update takes effect only after a reboot. No control requires the recommended interim restriction on untrusted apps and side-loading while a device waits for the update."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -167771,7 +168358,7 @@
       "NIS2-Art21-network-security": "EU NIS2 network-security and access-control measures treat the VPN gateway as a trusted enforcement point; they carry no CISA-KEV-tied 24h remediation SLA for an actively exploited perimeter auth bypass.",
       "DORA-Art-9": "ICT protection measures do not model a remote-access VPN authentication bypass on a perimeter firewall as an ICT-risk event requiring expedited containment.",
       "UK-CAF-B2": "Identity and Access Control objective does not require validating that a VPN gateway cannot be authenticated past without credentials.",
-      "AU-ISM-1546": "Patch-application timeframes for internet-facing infrastructure are insufficient for a confirmed-exploited perimeter authentication bypass.",
+      "AU-Essential-8-Patch": "A PAN-OS firewall serving GlobalProtect is an internet-facing network device, so ISM-1877 requires a patch or vendor mitigation within 48 hours of release at every maturity level when the vendor rates the flaw critical or a working exploit exists. CISA lists the flaw as exploited and Palo Alto Networks marks its exploit maturity ATTACKED, so the 48-hour condition applies. The fix is spread across seventeen maintenance releases on four PAN-OS branches, and each upgrade reboots the firewall that carries the remote-access VPN. Applying the vendor's temporary mitigations meets the 48-hour requirement, and the control sets no later date for the upgrade itself.",
       "ISO-27001-2022-A.8.8": "A.8.8 technical vulnerability management defines 'timely' loosely; a CISA KEV-listed exploited vulnerability needs the KEV due-date as the binding timescale."
     },
     "atlas_refs": [],
@@ -167885,7 +168472,7 @@
       "NIST-800-53-SC-7": "Boundary protection fails: the MDM gateway sitting at the perimeter is itself remotely compromised to root, inverting its trust position.",
       "ISO-27001-2022-A.8.28": "Secure-coding expectations do not address neutralizing OS-command input on an unauthenticated appliance config endpoint.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated root RCE on a perimeter MDM gateway as an ICT-risk event requiring expedited containment and forensic triage.",
-      "AU-ISM-1546": "Patch-application timeframes for internet-facing infrastructure are insufficient for a confirmed-exploited, public-PoC unauthenticated root RCE.",
+      "AU-Essential-8-Patch": "An Ivanti Standalone Sentry appliance with externally reachable endpoints is an internet-facing network device, so ISM-1877 requires a patch or vendor mitigation within 48 hours of release at every maturity level when the vendor rates the flaw critical or a working exploit exists; watchTowr released a public proof of concept on 2026-06-10. The fix is three builds, 10.5.2, 10.6.2 and 10.7.1, and each upgrade restarts the appliance. Shadowserver found two exposed instances already backdoored. An upgrade applied inside the window does not remove an implant placed earlier, and the patching controls do not require a compromise check.",
       "UK-CAF-B4": "The CAF System Security objective does not single out actively-exploited (KEV-listed) vulnerabilities on the exposed surface for accelerated, due-date-bound remediation."
     },
     "atlas_refs": [],
@@ -167998,7 +168585,7 @@
       "NIS2-Art21-vulnerability-handling": "Article 21 vulnerability-handling measures do not enforce an expedited patch window for actively exploited client-side browser-engine RCEs.",
       "DORA-Art-9": "ICT protection measures do not model a KEV-listed browser-engine RCE on every employee endpoint as an ICT-risk event requiring prompt patching.",
       "UK-CAF-B4": "System Security objective lacks an objective for keeping browser engines current against actively exploited memory-corruption bugs across all Chromium-based browsers in use.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "Chrome and the other Chromium-based browsers are in the web-browser class. At Maturity Levels One and Two, ISM-1691 allows two weeks from release even for this actively exploited flaw; only Maturity Level Three requires 48 hours when a working exploit exists (ISM-1692). Chrome is fixed in 149.0.7827.103, and each window starts at that browser vendor's own release, so Edge, Opera and Brave remain exposed until each ships a build on the fixed V8. The fix also takes effect only after the browser relaunches, so an update installed inside the window can leave the vulnerable V8 running."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -168106,7 +168693,7 @@
       "ISO-27001-2022-A.8.28": "Secure-coding expectations do not address proper output encoding/escaping on a privileged management CLI that processes uploaded files.",
       "DORA-Art-9": "ICT protection measures do not model an SD-WAN management-plane privilege escalation - whose blast radius is fleet-wide config push - as an ICT-risk event.",
       "UK-CAF-B2": "Identity and Access Control objective lacks an objective for preventing administrative roles on network controllers from escalating to host root via injection flaws.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "Where Cisco Catalyst SD-WAN Manager is reachable from the internet, it is an internet-facing network device, and 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. On an internal management network, ISM-1695 allows one month at Maturity Levels One and Two, and only Maturity Level Three requires 48 hours (ISM-1696). Cisco lists no workarounds, and the netadmin access the flaw needs can come from CVE-2026-20182 or CVE-2026-20127, so the upgrade guidance also directs patching those. Patching does not reverse configuration that exploitation has already pushed to edge devices."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -168210,7 +168797,7 @@
       "NIS2-Art21-patch-management": "Article 21 patch-management measures do not enforce emergency timelines for an actively exploited DoS on a managed file-transfer surface.",
       "DORA-Art-9": "ICT protection measures do not model an unauthenticated crash of a partner-facing file-transfer service as an ICT availability-risk event for financial entities.",
       "UK-CAF-B4": "System Security objective has no objective for hardening internet-exposed file-transfer services against unauthenticated resource-exhaustion crashes.",
-      "AU-ISM-1546": "Patch-application control does not single out internet-facing managed file-transfer servers for emergency patch timelines on an actively exploited DoS."
+      "AU-Essential-8-Patch": "SolarWinds Serv-U is a file-transfer server, so an instance directly accessible over the internet is an online service. A crafted unauthenticated POST request crashes it through resource exhaustion (CWE-400). CISA lists the flaw as known exploited (added 2026-06-05, due 2026-06-19), so ISM-1876 requires 15.5.4 Hotfix 1 within 48 hours of release at every maturity level, and applying it includes restarting the Serv-U service. For an internal instance, ISM-1693 allows one month at Maturity Levels Two and Three, longer than CISA's two weeks, and does not apply at Maturity Level One. ISM-1877 still covers an internet-facing host's operating system. Because 15.5.4 itself is affected, a version-only scan may not tell fixed servers from vulnerable ones."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -168321,7 +168908,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control and identity measures do not reach the ERP platform's unauthenticated critical-function surface.",
       "DORA-Art-9": "ICT protection measures do not model an ERP management-plane takeover as an ICT-risk event for financial entities running PeopleSoft.",
       "UK-CAF-B4": "System Security objective has no objective for authenticating the ERP platform's critical management functions.",
-      "AU-ISM-1546": "Patch-application control does not single out enterprise ERP platforms for emergency patch timelines when a vendor ships an out-of-cycle alert."
+      "AU-Essential-8-Patch": "A PeopleSoft Enterprise PeopleTools 8.61 or 8.62 environment directly accessible over the internet is an online service. CISA lists this missing-authentication flaw as known exploited, so ISM-1876 requires the fix from Oracle's out-of-cycle Security Alert within 48 hours of its release at every maturity level. An environment reachable only from inside the organization is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. CISA listed the flaw on 2026-06-12 with a due date of 2026-06-15, yet on an internal environment that meets ISM-1693, an unauthenticated attacker with HTTP access can take over PeopleTools for a month."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -168434,7 +169021,7 @@
       "NIS2-Art21-identity-management": "Article 21 access-control measures do not gate the LLM gateway's MCP subprocess-spawn endpoints behind the privilege level the action requires.",
       "DORA-Art-9": "ICT protection measures do not model an LLM gateway's MCP test endpoints as an ICT-risk command-execution event.",
       "UK-CAF-B4": "System Security objective has no requirement to authenticate to admin level and sandbox an LLM gateway's MCP server-config execution endpoints.",
-      "AU-ISM-1546": "Patch-application control does not single out LLM gateways and their MCP integrations.",
+      "AU-Essential-8-Patch": "A LiteLLM proxy directly accessible over the internet is an online service. CISA lists this command injection as known exploited, so ISM-1876 requires 1.83.7 within 48 hours of release at every maturity level. An internal-only proxy is an other application under ISM-1693, which allows one month at Maturity Levels Two and Three and sets no timeframe at Maturity Level One, while CISA set a due date two weeks after its 2026-06-08 listing. From 1.74.2 until 1.83.7, any authenticated key, including a low-privilege internal-user key, runs commands on the host, and no control requires blocking the MCP REST test endpoints or placing them behind the PROXY_ADMIN gate before the upgrade.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework treats an LLM gateway's MCP test/connection endpoints as privileged execution surfaces that must authenticate to admin level and must not spawn subprocesses from a request-supplied server config."
     },
     "atlas_refs": [
@@ -168543,7 +169130,7 @@
       "NIS2-Art21-patch-management": "Article 21 patch-management measures do not enforce emergency timelines for an actively exploited RCE in a third-party e-commerce extension.",
       "DORA-Art-9": "ICT protection measures do not model a deserialization RCE in a payment-adjacent e-commerce extension as an ICT-risk event.",
       "UK-CAF-B4": "System Security objective has no objective for treating third-party e-commerce extensions' deserialization paths as code-execution surfaces.",
-      "AU-ISM-1546": "Patch-application control does not single out third-party e-commerce platform extensions for emergency patch timelines on an actively exploited RCE."
+      "AU-Essential-8-Patch": "A Magento store running the Mirasvit Full Page Cache Warmer and directly accessible over the internet is an online service. CISA lists this deserialization flaw as known exploited, so ISM-1876 requires extension 1.11.12 within 48 hours of release at every maturity level; CISA's due date was three days after its 2026-06-03 listing. An internal-only store is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. Any unauthenticated storefront request with a crafted CacheWarmer cookie runs code on a store before 1.11.12, and no control requires rejecting malicious CacheWarmer cookie values until the Composer update is deployed."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -168654,7 +169241,7 @@
       "NIST-800-53-SI-10": "Input/parameter handling for the redisAble function does not adequately constrain what the user-end call can cause to run as root.",
       "DORA-Art-9": "ICT protection measures do not model a multi-tenant hosting control plane's privilege-escalation surface as an ICT-risk event.",
       "UK-CAF-B4": "The CAF System Security objective does not single out actively-exploited (KEV-listed) vulnerabilities on the exposed surface for accelerated, due-date-bound remediation.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle.",
+      "AU-Essential-8-Patch": "Where cPanel is directly accessible over the internet, the LiteSpeed user-end cPanel plugin is part of an online service, which ISM-1876 and ISM-1690 cover at every maturity level. ISM-1690's two weeks applies only when the vendor rates a flaw non-critical and no working exploit exists; because CISA listed this one as known exploited on 2026-05-26 with a three-day due date, ISM-1876 requires the fix within 48 hours of release. Where cPanel is reachable only internally, ISM-1693 for other applications allows one month at Maturity Levels Two and Three, so a compliant server running v2.3 through v2.4.4 can leave any cPanel user able to run scripts as root for that month while the vendor reports active exploitation. No patching control requires running the vendor's detection grep on cPanel logs, so meeting either window does not show whether a user already gained root.",
       "ISO-27001-2022-A.8.8": "A.8.8 technical vulnerability management defines 'timely' loosely; a CISA KEV-listed exploited vulnerability needs the KEV due-date as the binding timescale."
     },
     "atlas_refs": [],
@@ -168770,7 +169357,7 @@
       "NIS2-Art21-network-security": "EU NIS2 network-security and access-control measures treat the VPN gateway as a trusted enforcement point and carry no CISA-KEV-tied 24h remediation SLA for an actively exploited, ransomware-linked perimeter auth bypass.",
       "DORA-Art-9": "ICT protection measures do not model a remote-access VPN authentication bypass on a perimeter gateway, with confirmed ransomware-affiliate post-compromise activity, as an ICT-risk event requiring expedited containment.",
       "UK-CAF-B2": "Identity and Access Control objective does not require validating that a VPN gateway cannot be authenticated past via a deprecated key-exchange protocol.",
-      "AU-ISM-1546": "Patch-application timeframes for internet-facing VPN infrastructure are insufficient for a confirmed-exploited perimeter authentication bypass.",
+      "AU-Essential-8-Patch": "Check Point Security Gateways are internet-facing network devices, so ISM-1877 requires the sk185033 hotfix or another vendor mitigation on Gaia OS within 48 hours of release at every maturity level, because a working exploit exists and Check Point reports exploitation in the wild. The fix is split across Jumbo Hotfix Takes for R81.20, R82 and R82.10 and takes effect only after a gateway reboot, which the window does not plan for. R80.40, R81 and R81.10 are out of support and get no fix, so ISM-1501 requires replacing them with a supported release. Disabling IKEv1 or requiring a machine certificate is the vendor mitigation that can be applied within the window.",
       "ISO-27001-2022-A.8.8": "A.8.8 technical vulnerability management defines 'timely' loosely; a CISA KEV-listed exploited vulnerability needs the KEV due-date as the binding timescale."
     },
     "atlas_refs": [],
@@ -168882,7 +169469,7 @@
       "NIS2-Art21-network-security": "Article 21 network-security measures do not require validating that network-fabric decapsulation logic checks tunnel type, leaving a fabric-level access-control bypass unaddressed - acute given no vendor patch.",
       "DORA-Art-9": "ICT protection measures do not model a fabric switch's tunnel-decapsulation logic flaw, for which no patch exists, as an ICT-risk event requiring compensating network controls.",
       "UK-CAF-B4": "System Security objective lacks an objective for verifying that network devices enforce tunnel-type filtering on decapsulation, and for compensating controls when the vendor ships no fix.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "Arista EOS is a network device operating system. An internet-facing switch gets 48 hours under ISM-1877 at every maturity level because the flaw is exploited in the wild, and an internal switch gets one month under ISM-1695 at Maturity Levels One and Two and 48 hours under ISM-1696 only at Maturity Level Three. Arista plans no software fix, so the windows can only be met with the access-control lists from Arista Security Advisory 0137, which may need a TCAM-profile change on decapsulation hardware. ISM-1501 applies only to operating systems their vendors no longer support, so the patching controls do not require replacing a switch Arista will not fix."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -168986,7 +169573,7 @@
       "NIS2-Art21-supply-chain": "Article 21 supply-chain security measures do not model a trusted software vendor's compromised build pipeline shipping signed malware as an in-scope ICT supply-chain risk.",
       "ALL-AI-PIPELINE-INTEGRITY": "No framework requires treating every signed third-party installer as a potential build-pipeline-compromise vector requiring independent integrity verification, not signature trust alone.",
       "UK-CAF-B4": "The CAF System Security objective does not single out actively-exploited (KEV-listed) vulnerabilities on the exposed surface for accelerated, due-date-bound remediation.",
-      "AU-ISM-1546": "The ISM patch-application control sets vendor-defined timeframes; a CISA KEV-listed, actively-exploited vulnerability requires applying the vendor fix within the KEV due-date, not a default monthly cycle."
+      "AU-Essential-8-Patch": "DAEMON Tools Lite is in the other applications class, so ISM-1693 requires vendor updates within one month of release at Maturity Levels Two and Three, and Maturity Level One sets no timeframe for it. The vendor's own signed installers from daemon-tools.cc carried the trojan between about 2026-04-08 and 2026-05-05, so an organization that updated from the official site in that period installed it. Remediation is an uninstall, a full antivirus scan and a clean 12.6 install, with every host that ran the trojanized installer treated as potentially compromised and investigated. The one-month window plans for neither the reinstall nor the investigation."
     },
     "atlas_refs": [],
     "attack_refs": [
@@ -174313,7 +174900,7 @@
       "NIST-800-53-AC-2": "AC-2 account management requires identifying account types, assigning managers, reviewing accounts for compliance and removing accounts that are no longer required — all executed over the accounts the operator can enumerate. The FMC static account exists inside the vendor's appliance image, below the operator's account-management plane: it does not appear in an FMC user review, cannot be disabled, and cannot be rotated. A perfect AC-2 account recertification of the firewall management platform would have enumerated zero of the accounts that mattered.",
       "DORA-Art28": "A financial entity's DORA register of information would correctly list Cisco as an ICT third-party provider supporting a critical function, with contractual terms, exit strategy and monitoring obligations all in place. Art.28 monitoring operates on service performance, concentration risk and contractual assurance — it has no mechanism that detects a static credential compiled into an appliance image. The register would be complete and audit-clean while the firewall management plane accepted unauthenticated logins, and the entity's DORA incident-classification clock (4 hours from classification for major incidents) starts only once someone finds the /var/tmp/license.tmp artifact.",
       "UK-CAF-B2": "CAF B2 identity and access control expects that access to systems is granted only to verified, authorised identities and that privileged access is managed. This is a direct B2 failure the operator cannot remediate: the identity is vendor-embedded, authenticates over the standard web interface, and no B2 activity — joiners/movers/leavers, privilege review, credential rotation policy — reaches it. B2 outcomes are assessed against what the organisation controls, and this account is definitionally outside that.",
-      "AU-ISM-1546": "ISM-1546 requires patching applications, and the control implicitly assumes a patch exists for the release the organisation runs. Cisco published hotfixes for the 7.0, 7.2, 7.4, 7.6, 7.7 and 10.0 trains but none for 7.3, even though 7.3.0 through 7.3.1.2 appear in Cisco's own affected list — so an ISM-1546-conformant Australian government entity on FMC 7.3 had nothing to apply and had to plan a train migration instead, with the exposure persisting for the whole migration window while the KEV due date was three days out.",
+      "AU-Essential-8-Patch": "Where the web interface of Cisco Secure Firewall Management Center is internet-facing, 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 otherwise; on an internal network, ISM-1695 allows one month below Maturity Level Three. Cisco published hotfixes for the 7.0, 7.2, 7.4, 7.6, 7.7 and 10.0 trains but none for 7.3, although 7.3.0 through 7.3.1.2 are affected. The static credential cannot be disabled or rotated and Cisco lists no workaround, so a 7.3 deployment cannot meet any window except by migrating trains.",
       "ISO-27001-2022-A.5.21": "A.5.21 requires managing information security risks in the ICT supply chain through supplier requirements, agreements and verification of what suppliers deliver. Nothing in a supplier-assurance questionnaire, a security addendum or a vendor attestation would surface a hard-coded low-privileged account inside a firewall management appliance, and the operator has no practical means to test for it without reverse-engineering the image — the control's verification step has no reachable evidence, so A.5.21 conformance and this vulnerability coexist without contradiction."
     },
     "atlas_refs": [],
@@ -174604,7 +175191,7 @@
       "NIST-800-53-SI-10": "SI-10 information-input validation is precisely the missing control: the doAs username is concatenated into a Unix shell command with no validation, so a CVSS 8.8 command injection reaches os-level execution — SI-10 is advisory guidance the shipped HttpSecurityFilter did not implement.",
       "NIS2-Art21-vulnerability-management": "NIS2 Art.21 vulnerability handling assumes a score-driven patch cadence, but fixed releases existed from July 2022 while the CVE only reached KEV in March 2023; a public Metasploit module and Nuclei template made exploitation point-and-shoot for any internet-exposed Spark UI with ACLs on, well ahead of a compliance-scheduled upgrade.",
       "UK-CAF-B4": "CAF B4 (system security) treats spark.acls.enable as a hardening step, yet enabling that ACL is exactly what opens the impersonation-to-shell-injection code path — the secure-configuration advice and the vulnerable feature are the same toggle, which B4 does not disambiguate.",
-      "AU-ISM-1546": "ISM-1546 anchors patch-application timeframes on advisory date, not on public-exploit availability; the Spark maintenance releases were out in July 2022 but the trivially-usable Metasploit module and Nuclei template are what made this operationally exploitable, a dimension the timeframe control does not weigh.",
+      "AU-Essential-8-Patch": "An internet-accessible Spark UI is an online service. CISA lists this flaw as known exploited, and a Metasploit module and a Nuclei template are public, so ISM-1876 requires the fix within 48 hours of release at every maturity level, rather than the two weeks ISM-1690 allows when the vendor rates a flaw non-critical and no working exploit exists. A UI reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. The fix is split across 3.1.3, 3.2.2 and 3.3.0, so a cluster on 3.0.3 or earlier must change release lines. No patching control requires disabling ACLs or restricting access to the UI in the interim.",
       "ISO-27001-2022-A.8.28": "A.8.28 secure coding targets injection defects like this one — a Unix shell command built from an unvalidated impersonation username — but the control is advisory, and the shipped Spark UI concatenated attacker input straight into the shell invocation."
     },
     "atlas_refs": [],
@@ -174900,7 +175487,7 @@
       "NIST-800-53-CM-7": "CM-7 least functionality is the control that would actually have removed this exposure, because the vulnerable route was an obsolete API that IBM deleted outright in 4.4.2 PL2 rather than repairing. CM-7 implementations inventory installed packages, services and open ports — not the dormant Rails routes an application still serves — so an organisation fully conformant with CM-7 was still publishing /aspera/faspex/package_relay/relay_package to the internet with no authentication in front of a YAML.load sink.",
       "NIS2-Art21-vulnerability-handling": "NIS2 Art.21 vulnerability handling is evidenced by having a documented procedure, and here the procedure had every input it needed — IBM's bulletin, then Assetnote's 2023-02-02 writeup with a working PoC. The gap is classification: Faspex is a managed-file-transfer hub, so one unauthenticated deserialization is simultaneously a breach of every counterparty whose files transit it, yet a conforming procedure that rates it as an ordinary internal application schedules it behind genuinely lower-impact hosts. IceFire monetised exactly that lag on 2023-03-09.",
       "UK-CAF-B4": "CAF B4 (system security) is assessed on how the deployed system is hardened and configured, but no operator-side configuration of Faspex 4.4.2 PL1 closed this path: the gadget chain executes inside the application's own YAML.load on the user-supplied external_emails field before any authentication or authorisation decision is reached. B4 offered no lever short of taking the appliance off the internet, which means a strong B4 assessment and total exposure to this CVE were fully compatible.",
-      "AU-ISM-1546": "ISM 1546 requires applications to be patched, and for an internet-facing application with a working public exploit the ISM window is 48 hours. That clock started on 2023-02-02 when Assetnote published; CISA's KEV due date was 2023-03-14; IceFire was encrypting Faspex hosts on 2023-03-09 — inside the compliance window. A 48-hour rule cannot compress an appliance upgrade that requires a scheduled file-transfer outage and partner notification, so the control's timeframe is unachievable for precisely the asset class it matters most on.",
+      "AU-Essential-8-Patch": "An internet-accessible Faspex server is an online service. Assetnote published a working exploit on 2023-02-02, and CISA lists this unauthenticated remote code execution as known exploited, so ISM-1876 requires Faspex 4.4.2 Patch Level 2 within 48 hours of release at every maturity level, rather than the two weeks ISM-1690 allows when the vendor rates a flaw non-critical and no working exploit exists. A server reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. IceFire was encrypting Faspex hosts by 2023-03-09. The upgrade takes the file-transfer service down and has to be scheduled with the partners who depend on it, which the 48-hour window does not plan for.",
       "ISO-27001-2022-A.8.8": "A.8.8 prioritises technical vulnerabilities by rating, and this one carried the maximum available signal on every axis — CVSS 9.8, EPSS 0.99968 (99.977th percentile), KEV-listed with ransomware status Known. The gap is asset scope rather than scoring: a Faspex instance is typically owned by a business unit that ships large media, legal or clinical files, so it sits outside the server estate the ISMS treats as critical infrastructure and the risk-rated schedule reaches it only after the recognised internet-facing list."
     },
     "atlas_refs": [],
@@ -175111,7 +175698,7 @@
       "NIST-800-53-SC-7": "SC-7 boundary protection treats the Edge Gateway as part of the boundary that enforces the policy, but this command injection executes OS commands in the context of the system on that boundary device itself. Once the gateway is the attacker's shell, every SC-7 assumption — that remote-phone traffic is mediated, that the internal voice network is separated from external endpoints — is being enforced by a host under attacker control, and SC-7 carries no requirement to monitor the enforcement device for its own compromise.",
       "NIS2-Art21-network-security": "NIS2 Art.21 network security is assessed on the presence of segmentation, and it assumes the segmentation devices are themselves trustworthy. The Mitel Edge Gateway is precisely the component that terminates remote phones and bridges them into the internal voice network, so command execution on it collapses the separation an Art.21 assessment credits. And because the vector is AV:A, any entity that leaves its voice VLAN reachable from ordinary user VLANs has already supplied the adjacency the exploit needs.",
       "UK-CAF-B4": "CAF B4 (system security) evidence for a UC estate usually reduces to 'vendor-supported appliance, patched per vendor guidance'. Mitel's public advisory 22-0007 names no fixed build number — the remediation lives only in the login-gated Security Bulletin 22-0007-001 — so a B4 assessor cannot verify the patched state of the Edge Gateway against any published version string, and the control's evidence collapses to the operator's own assertion that the bulletin was applied.",
-      "AU-ISM-1546": "ISM 1546 requires operating systems and applications to be patched within a defined timeframe, and its verification model assumes a published fixed version to reconcile the patch register against. Because Mitel disclosed the fix only through customer-portal bulletin 22-0007-001, an ISM-aligned register for MiVoice Connect 19.3 (22.22.6100.0) and earlier cannot be reconciled against a public build at all. With the platform now in lifecycle wind-down toward End of Technical Support on 2029-12-31, the ISM-satisfying answer is migration rather than a patch cadence.",
+      "AU-Essential-8-Patch": "The Edge Gateway is the MiVoice Connect appliance at the network edge, an internet-facing network device under the ISM, so ISM-1877 requires its 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 requires it within two weeks otherwise. Mitel delivers the fix only through customer-portal Security Bulletin 22-0007-001 and names no fixed release publicly. An operator without portal access cannot tell when either window began, and the patch register has no public fixed build to reconcile MiVoice Connect 19.3 (22.22.6100.0) and earlier against.",
       "ISO-27001-2022-A.8.22": "A.8.22 segregation of networks is the control this CVE genuinely tests, because AV:A means the attacker must already be adjacent to the Edge Gateway. Voice networks are commonly segregated in the design document and then bridged in practice by softphones, provisioning VLANs and management jump paths. Where that is true — which is the normal case for a MiVoice Connect deployment — the A.8.22 conformance statement describes a boundary that does not exist, and the gateway is reachable by anyone on the user VLAN holding MiVoice Connect administrator credentials."
     },
     "atlas_refs": [],
@@ -175209,7 +175796,7 @@
       "NIST-800-53-SI-10": "SI-10 information input validation failed twice inside a single request: get_client_addr() accepted an attacker-controlled HTTP header as the authoritative client identity for an authorization decision, and get_nfilter_request_var() then handed poller_id to proc_open() unfiltered. SI-10 is normally evidenced at the perimeter through a WAF or API gateway, which cannot help here — a spoofed X-Forwarded-For is indistinguishable from a legitimate reverse-proxy header, and the injected poller_id looks like an ordinary integer parameter right up until it reaches the shell.",
       "NIS2-Art21-vulnerability-management": "Cacti 1.2.23 shipped on 2022-12-05 and MooBot and ShellBot were mass-exploiting unpatched instances from January 2023. The NIS2 gap is scope rather than speed: Cacti is the tool essential entities use to monitor the very network and information systems Art.21 exists to protect, so it is catalogued as a management or support utility rather than an in-scope service — even though its database holds SNMP community strings and device credentials for the entire estate, which is what an attacker actually collects after landing this RCE.",
       "UK-CAF-C1": "CAF C1 (security monitoring) is undermined at its source here, because Cacti is the monitoring platform: an unauthenticated RCE hands the attacker the collector, its poller definitions and its stored device credentials in one step. C1 evidence assumes the monitoring infrastructure is a trusted observer, and nothing in the principle requires monitoring of the monitoring host — so the perl bots masquerading as /usr/sbin/sshd run on the one server least likely to be watched by the capability C1 assesses.",
-      "AU-ISM-1546": "ISM 1546 covers patching operating systems and applications, but Cacti is characteristically installed from a distribution package by a network or NOC team and never enters the application register the control is assessed against. The fix was available through entirely ordinary channels — Debian DSA-5298-1 and DLA-3252-1 — yet an unregistered package on a NOC server does not appear in the patch-compliance report at all, so the control reports green while the exposed host is out of its field of view.",
+      "AU-Essential-8-Patch": "An internet-accessible Cacti server is an online service. CISA lists this unauthenticated remote code execution as known exploited, so ISM-1876 requires the fix within 48 hours of release at every maturity level, rather than the two weeks ISM-1690 allows when the vendor rates a flaw non-critical and no working exploit exists. A server reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. The fix was released on 2022-12-05, and MooBot and ShellBot were exploiting it from January 2023. Installations on PHP before 7.0 need commit a8d59e8 on top of 1.2.23, and a host installed from a distribution package often sits outside the application register used as patching evidence.",
       "ISO-27001-2022-A.8.9": "A.8.9 configuration management derives secure baselines from the vendor default, and here the vendor default is the exploit primitive: the pre-existing poller-table row naming the Cacti server's own hostname is exactly what makes a spoofed X-Forwarded-For resolve to an authorised client. A baseline built from the shipped configuration therefore encodes the bypass rather than removing it, and no A.8.9 hardening step short of the 1.2.23 code change closes it."
     },
     "atlas_refs": [],
@@ -175644,7 +176231,7 @@
       "NIST-800-53-SI-2": "SI-2 flaw remediation is normally operationalised through a single enterprise update channel — WSUS, SCCM or Intune. This one CVE requires three: the Windows KBs, plus Microsoft Store delivery for Office for Universal, plus the App Store and Google Play for Office for iOS and Android. An SI-2 programme reporting 100% Windows-KB compliance is genuinely unremediated for the same CVE on the application side, and MSRC states the Store will not install the fix at all where Store auto-update is disabled by policy — so the SI-2 evidence and the actual exposure diverge silently.",
       "NIS2-Art21-vulnerability-handling": "NIS2 Art.21 vulnerability handling is asserted per entity against an asset register. Store-delivered Microsoft Office variants and Office for Android and iOS rarely appear in that register as separately patchable assets with their own version floors (16.0.14326.21330, 16.0.16130.20156, 2.70.23021003). The entity's vulnerability-handling evidence for CVE-2023-21823 therefore records the operating-system remediation and silently omits three affected products Microsoft lists in the same advisory as still requiring customer action.",
       "UK-CAF-B4": "CAF B4 system security asks for secure configuration and disciplined updating on in-scope systems, and blocking the Microsoft Store is standard secure-baseline advice that a B4 assessment would score favourably. That hardening decision is precisely what prevents this fix from arriving for the affected Office components — MSRC confirms the Store will not automatically install the update where auto-updates are disabled. The control and the remediation are in direct conflict, so a stronger B4 posture can leave the CVE open longer.",
-      "AU-ISM-1546": "ISM control 1546 requires patches for security vulnerabilities in operating systems and applications to be applied within defined timeframes. Applied here the timeframe is measurable and enforceable for the Windows KBs, but unenforceable for the app-store-delivered Office builds, because the organisation controls neither the release cadence nor the install trigger on Microsoft Store, Google Play or the App Store. ISM-1546 evidence for this CVE therefore cannot be made complete across the full affected product set Microsoft published.",
+      "AU-Essential-8-Patch": "Windows 10 workstations and internal Windows Server 2016 and 2019 hosts fall under ISM-1695, one month from release at Maturity Levels One and Two, and ISM-1696, 48 hours at Maturity Level Three when the flaw is critical or a working exploit exists. CISA lists this flaw as exploited, yet a Maturity Level One or Two estate still has a month. The Windows fix is a separate February 2023 cumulative update for each Windows 10 version and needs a restart. The Office builds delivered through Microsoft Store, Google Play and the App Store are fixed separately under ISM-1691 and ISM-1692, and a Windows patch record does not show them.",
       "ISO-27001-2022-A.8.8": "A.8.8's technical-vulnerability process depends on the A.5.9 asset inventory correctly identifying every instance of vulnerable software. Windows-only inventories miss the Office for Universal, Android and iOS components entirely, so A.8.8 closes out the vulnerability record on OS-patch evidence alone — while Microsoft's own temporal metric rates exploit-code maturity High (E:H), meaning functional in-the-wild code still has reachable targets in the estate the inventory never listed."
     },
     "atlas_refs": [],
@@ -176055,7 +176642,7 @@
       "NIST-800-53-AC-3": "AC-3 access enforcement was never invoked. The four BneAbstractXMLServlet endpoints accept a multipart upload with no session, so there is no authenticated subject for the policy decision point to evaluate — an EBS deployment with fully modelled responsibilities, segregation of duties and role-based access still hands an anonymous HTTP client an arbitrary file write on the application tier. AC-3 evidence for this system is entirely about what authenticated users may do, and this CVE never produces an authenticated user.",
       "NIS2-Art21-patch-management": "NIS2 Art.21 patch management assumes a defender-favourable disclosure-to-exploit window. Oracle's fix shipped 2022-10-18 inside a quarterly CPU, public root-cause analysis landed 2023-01-16 and a PoC on 2023-02-06 — but EBS CPUs are large, downtime-bearing adop patches that ERP change boards schedule quarter to quarter against a business calendar. A patch cadence that is fully conformant with Art.21 for a quarterly-CPU vendor still left roughly four months of exposure on an unauthenticated file-write endpoint, ending in a KEV listing rather than a patch.",
       "UK-CAF-B4": "CAF B4 system security does not reach the failure: BneUnZip concatenates the staging path with an attacker-controlled ZIP entry name, so ../../../.. escapes to the Perl CGI directory and the forms directory. This is a path-traversal defect inside closed-source vendor extraction code. No configuration setting, host hardening measure, or B4 evidence artefact available to the EBS operator constrains where the extracted file lands — only the vendor patch or a proxy-level block on the upload parameter does.",
-      "AU-ISM-1546": "ISM control 1546 (patch operating systems and applications) keys off vendor patch availability and treats an internet-facing ERP servlet the same as an internal batch component. The four /OA_HTML/Bne*Service endpoints needed either the October 2022 CPU or a reverse-proxy block on bne:uueupload; an ISM 1546 compliance record would legitimately show the patch as scheduled for the next quarterly maintenance window while an unauthenticated arbitrary file write to the application tier stayed live and, by February 2023, was being exploited.",
+      "AU-Essential-8-Patch": "An internet-facing E-Business Suite web tier is an online service, so ISM-1876 requires the October 2022 Critical Patch Update (CPU) or another vendor mitigation within 48 hours of release at every level when the vendor rates the flaw critical or a working exploit exists; this CVSS 9.8 flaw has a public proof of concept. An internal instance is an other application under ISM-1693, with one month from Maturity Level Two and no Maturity Level One timeframe, so at Maturity Level One it could still be unpatched at the 2023-02-02 KEV listing without breaching the profile. Applying the CPU through adop needs a cutover and application-tier restart that the 48-hour window does not plan for.",
       "ISO-27001-2022-A.8.28": "A.8.28 secure coding sits with the software supplier, and an EBS operator has no way to evidence it against a closed-source Oracle servlet. The defect — an unauthenticated multipart upload combined with unvalidated ZIP entry-name concatenation — is precisely the class A.8.28 exists to prevent, which makes it a control the certified organization carries in its statement of applicability, cannot test, and cannot exercise against this CVE. The certification therefore attests to a coding practice that the exploited component demonstrably did not follow."
     },
     "atlas_refs": [],
@@ -178216,7 +178803,7 @@
       "NIST-800-53-AC-6": "AC-6 least privilege is enforced against the token, and the token was correct throughout: the attacker held only standard-user rights and printfilterpipelinesvc.exe held SYSTEM. What AC-6 does not model is the namespace — during impersonation the privileged service resolves manifest paths through the *user's* DOS device map, so a standard user decides which files a SYSTEM process reads without ever holding a privilege. An AC-6 assessment that confirms users are non-administrators and services run under scoped identities evidences a compliant control on a host where a standard account can substitute the OS's side-by-side manifest store at load time.",
       "NIS2-Art21-vulnerability-handling": "NIS2 Art.21 vulnerability handling is downstream of vendor classification, and the vendor classification here was misleading. Microsoft titled it 'Windows Print Spooler Elevation of Privilege'; Project Zero states plainly that the print spooler 'was simply how this vulnerability was exploited, not the root vulnerability', which is the impersonated DOS device map. An entity triaging on the advisory title would have reached for the post-PrintNightmare reflex of disabling the Print Spooler service, which does not close the device-map flaw and leaves it reachable through any other privileged process that loads a DLL under impersonation. The article assumes accurate vendor classification and provides no test for the case where it is wrong.",
       "UK-CAF-B2": "CAF B2 identity and access control assumes that when a privileged process acts, it acts under one coherent identity. This bug is precisely the divergence: printfilterpipelinesvc.exe holds SYSTEM authority but adopts the caller's identity for file resolution, so authority and identity split inside a single operation and the lower-privileged half wins. No B2 evidence artefact — account inventories, privileged-access reviews, impersonation policy — records which identity governs namespace resolution inside CSRSS, so a B2 outcome can be fully achieved while a standard user redirects what a SYSTEM service loads.",
-      "AU-ISM-1546": "ISM control 1546 (patch operating systems and applications) is satisfied by evidence that the November 2022 update was applied within the required window, and that evidence would be true and still insufficient. Microsoft shipped this in three stages: November 2022 patched winspool.drv to revert impersonation around LoadLibraryExW (breaking the exploit), December 2022 added the broader CSRSS mitigation without enabling it for this path, and January 2023 enabled it for printfilterpipelinesvc.exe. An agency that patched inside the ISM timeframe in November and closed the record was not exposed to this exploit but still carried the root cause for two more months, and no ISM patching control distinguishes a symptom fix from a root-cause fix.",
+      "AU-Essential-8-Patch": "Windows is an operating system, so on workstations and internal servers ISM-1695 requires the fix within one month at Maturity Levels One and Two, and ISM-1696 requires it within 48 hours only at Maturity Level Three; internet-facing servers get 48 hours under ISM-1877 at every level. CISA listed the flaw as exploited on 2022-11-08, the day Microsoft released the fix, so below Maturity Level Three a host can remain unpatched for a month and still be compliant. The fix came in three stages, and the CSRSS root-cause mitigation was enabled for printfilterpipelinesvc.exe only in January 2023, so hosts recorded as patched in November still carried the root cause.",
       "ISO-27001-2022-A.8.9": "A.8.9 configuration management treats the OS's trusted baseline as immutable to non-administrators, and C:\\Windows\\WinSxS genuinely is — file permissions on the manifest store were never bypassed. The substitution happens one layer down, at path resolution: CSRSS reads the manifest through a drive root the standard user controls, so the correct baseline is silently swapped for an attacker copy at load time. A.8.9 evidence built from baseline hashing, drift detection or CIS-benchmark scanning inspects the files on disk and will not observe that a different file was the one actually read."
     },
     "atlas_refs": [],
@@ -178536,7 +179123,7 @@
       "NIST-800-53-AC-3": "AC-3 access enforcement assumes the platform's reference monitor decides access according to approved authorisations, and on these devices it did exactly that — Android's ContentProvider permission model worked correctly and correctly permitted everyone, because Samsung declared SemClipboardProvider with android:exported='true' and no android:permission in framework-res.apk. SELinux was enforcing throughout; the writes were legitimately performed by system_server on the attacker's behalf. AC-3 evidence for a mobile fleet consists of MDM policy, screen-lock and encryption state, and never includes reading the handset vendor's framework manifest, so the authorisation defect sits in a layer AC-3 assessment does not reach.",
       "NIS2-Art21-supply-chain": "NIS2 Art.21(2)(d) requires entities to address security in relationships with direct suppliers, and the vulnerable component here is not AOSP but OEM code injected into system_server — com.android.server.semclipboard.SemClipboardProvider is Samsung's addition, shipped inside services.jar with its manifest in framework-res.apk. No enterprise mobility programme obtains visibility into a handset vendor's framework-level additions, no supplier questionnaire enumerates them, and the remediation arrives only through a carrier-staggered SMR the entity does not control. An organisation can execute the Art.21 supplier-assurance process completely and still carry an exported system_server provider it has never been told exists.",
       "UK-CAF-B4": "CAF B4 system security rests on the device platform enforcing separation between applications, and the notable thing about this chain is that separation never broke — a single missing caller check let one untrusted app use system_server as a file-writing proxy four times over, walking untrusted_app to system_app to kernel without defeating SELinux, Linux file permissions or app sandboxing at any point. A B4 assessment that verifies platform hardening features are enabled will find every one of them enabled and enforcing. The only B4 test that would have surfaced this is inspecting exported provider declarations in the OEM framework for missing permission attributes, which is firmware analysis rather than configuration review.",
-      "AU-ISM-1808": "ISM control 1808 (software supply chain risk management) is written around the software an entity procures and deploys, with expectations about provenance, vendor assurance and update channels. Handset firmware inverts that model: the entity procures a device, the OEM injects privileged code into the OS framework, and the fix reaches the device through a carrier-gated monthly SMR that stops entirely at end of support. Devices past their SMR window — including the S10, A50 and A51 class the sample targeted — retain the exported provider permanently with no remediation path, so the 1808 outcome cannot be achieved for the affected population at all, only accepted or the fleet replaced.",
+      "AU-Essential-8-Patch": "A Samsung handset is IT equipment other than a workstation, server or network device, so its operating system is patched under ISM-1878, within 48 hours of release when the vendor rates a vulnerability critical or a working exploit exists, and ISM-1751, within one month otherwise; neither control is in an Essential Eight maturity profile. The recovered sample targeted Galaxy S10, A50 and A51 devices in late 2020, and both windows start only at the SMR Mar-2021 Release 1 fix. The fix needs a carrier-staggered build and a reboot, and a handset Samsung no longer updates cannot receive it, so ISM-1501 requires its operating system to be replaced.",
       "ISO-27001-2022-A.5.15": "A.5.15 access control requires rules for physical and logical access to be established based on business and information-security requirements, documented in policy. The rule that failed was a single missing android:permission attribute on an exported ContentProvider running as the system UID, authored by the handset vendor and shipped in firmware. A Statement of Applicability can record A.5.15 as implemented with a full access-control policy, mobile-device management standard and role model, while the decision that actually governed this access was made by Samsung and was invisible to every artefact the ISMS holds. Note also that Samsung's own CVSS scoring called it 4.4 with only low confidentiality and integrity impact where NVD scored 7.1 with C:H/I:H — a risk register that inherited the vendor score would have deprioritised a primitive that a commercial surveillance vendor used to reach the kernel."
     },
     "atlas_refs": [],
@@ -178754,7 +179341,7 @@
       "NIST-800-53-SC-39": "SC-39 requires the system to maintain a separate execution domain for each executing process — on Android that is the kernel plus SELinux. This defect broke the enforcement point itself: a struct file freed while the DPU driver still dereferenced it let the attacker place a controlled object in its slot and overwrite addr_limit, after which USER_DS/KERNEL_DS toggling gave read/write over all kernel memory and let the exploit patch sys_call_table. Once addr_limit is attacker-controlled there is no process isolation left to configure, so no SC-39 implementation on the handset could have contained it.",
       "NIS2-Art21-patch-management": "NIS2 Art.21 patch management presumes a defect the entity can rank and schedule. Samsung rated SVE-2021-19925 'Moderate' and NVD's text stops at 'memory corruption leading to kernel panic' with a CVSS of 4.4 (PR:H, availability-only), so any risk-ranked patch queue read it as a local denial of service on a phone. The reality — arbitrary kernel read/write as root, the escalation stage of a commercial surveillance chain — was not public until November 2022, and the KEV listing followed on 2022-11-08, twenty months after the fix shipped.",
       "UK-CAF-B4": "CAF B4 system security expects proportionate protection of the technology supporting essential functions, but there is no operator-side hardening for a use-after-free in an OEM display driver. The vulnerable path is the ordinary DECON window-configuration ioctl the display stack calls in normal operation, and the fix was Samsung moving fd_install() later inside decon_set_win_config. Short of taking the vendor build, B4 gives an operator no lever — no setting to disable, no interface to restrict, no compensating control on the device.",
-      "AU-ISM-1546": "ISM control 1546 (patch operating systems and applications) keys its timeframes to vendor advisory severity. Samsung published this as a Moderate-severity memory-corruption-leading-to-kernel-panic issue, so a 1546-conformant programme would have applied it on the routine monthly schedule rather than the accelerated one — while the same defect was already serving as the kernel read/write stage of an in-the-wild chain that TAG had captured in late 2020. Severity-keyed patch scheduling inherits the vendor's under-rating.",
+      "AU-Essential-8-Patch": "The flaw is in the Exynos display driver, and the Essential Eight sets driver patch windows only at Maturity Level Three: 48 hours from release when the vendor rates a vulnerability critical or a working exploit exists (ISM-1879), and one month otherwise (ISM-1697). Samsung rated it Moderate and described memory corruption leading to a kernel panic, and no public proof of concept exists, so an organization following the vendor rating would take the one-month window. An in-the-wild chain captured in late 2020 already used the flaw for kernel read and write. Levels One and Two set no driver window, and the SMR Mar-2021 Release 1 fix needs a reboot.",
       "ISO-27001-2022-A.8.28": "A.8.28 secure coding maps directly onto this defect — installing a file descriptor into the userspace table before the driver has finished using the struct file is precisely the lifetime error a secure-coding review exists to catch — but the code belongs to Samsung's Exynos display driver, not to the certified organisation. An ISMS scoped to the operator's own development lifecycle cannot reach an OEM kernel driver, so A.8.28 conformity provides zero assurance about the handsets attached to the network, and the operator has no mechanism to require it of the OEM."
     },
     "atlas_refs": [],
@@ -179067,7 +179654,7 @@
       "NIST-800-53-AC-6": "AC-6 least privilege was satisfied on paper and defeated in practice. The attacker is an ordinary authenticated local user with no administrative rights — the only precondition Cisco states — while the Cisco AnyConnect Secure Mobility Agent runs as SYSTEM and exposes an unauthenticated IPC listener on 127.0.0.1:62522 that any logged-on user can drive. AC-6 governs the privileges assigned to accounts and roles, not the privilege a SYSTEM service is willing to lend to a local caller it never authenticates, so a rigorously least-privileged workstation still handed SYSTEM to any user for as long as AnyConnect below 4.9.00086 was installed.",
       "NIS2-Art21-network-security": "NIS2 Art.21 treats the VPN client as part of the secure-remote-access control set, and here that control was itself the escalation path: every remote worker required to run AnyConnect in order to reach the entity's network carried a local-to-SYSTEM primitive with public exploit code. Hardening the perimeter therefore increased endpoint attack surface rather than reducing it, and CISA records this CVE with knownRansomwareCampaignUse=Known — meaning the primitive was used in practice to convert an initial foothold into privileged, lateral-movement-capable access on the very hosts the VPN control was protecting.",
       "UK-CAF-B2": "CAF B2 identity and access control rests on distinguishing standard users from privileged ones and on governing privileged access through approvals and separate admin accounts. That distinction was void on any host running AnyConnect below 4.9.00086: valid standard-user credentials were sufficient to obtain NT AUTHORITY\\SYSTEM by sending one crafted localhost IPC message, and the public PoC delivers it as a single executable. Privileged-access management controlled nothing the attacker actually needed.",
-      "AU-ISM-1546": "ISM control 1546 (patch operating systems and applications) is the control that would have closed this, and it failed on dwell time rather than on design: Cisco published the fixed release 4.9.00086 and the advisory on 2020-08-05, public proof-of-concept code was acknowledged in advisory revision 1.1 on 2020-08-13, and CISA still had to add the CVE to KEV on 2022-10-24 after observing exploitation. That is more than two years of 1546 non-conformance on a security product deployed across the entire remote-access estate — the gap is that patch programmes routinely exempt the VPN client because upgrading it disconnects users.",
+      "AU-Essential-8-Patch": "AnyConnect Secure Mobility Client for Windows is a security product. ISM-1691 requires the upgrade to 4.9.00086 within two weeks of release at Maturity Levels One and Two, and ISM-1692 requires it within 48 hours at Maturity Level Three because a working exploit exists. Below Maturity Level Three the two weeks still apply although a public proof of concept targets builds 4.5.02036 through 4.8.03052. Cisco lists no workaround. The upgrade restarts the Secure Mobility Agent, drops the VPN session and needs a reboot that neither window plans for.",
       "ISO-27001-2022-A.8.9": "A.8.9 configuration management assumes a hardened baseline can reduce exposure while a patch is scheduled. Cisco's advisory states plainly that there are no workarounds: the IPC listener is how the AnyConnect agent performs privileged installs, it cannot be disabled or firewalled off without breaking the client, and the vulnerable behaviour is the shipped default. A conformant A.8.9 baseline therefore delivered exactly zero risk reduction between 2020-08-05 and the day each organisation actually upgraded to 4.9.00086."
     },
     "atlas_refs": [],
@@ -179364,7 +179951,7 @@
       "NIST-800-53-CM-7": "CM-7 least functionality tells organisations to disable unnecessary functions and services, but the unnecessary function here is inside a signed third-party kernel driver: raw x86 IN/OUT port access exposed through an IOCTL with no access-control check. CM-7 baselines enumerate installed applications and open ports, not the IOCTL surface a loaded driver publishes, so the exact capability the control exists to remove is invisible to every CM-7 configuration review.",
       "NIS2-Art21-patch-management": "NIS2 Art.21 patch management presumes an advisory-to-fix pipeline. GIGABYTE had no security contact, told SecureAuth it was 'a hardware company', and denied the report outright on 2018-07-12, so between the 2018-12-18 user release and the vendor's later quiet update an essential entity had no advisory, no severity rating and no fixed build to schedule. NVD still names no fixed APP Center version for this CVE, so 'apply the vendor patch' is not a complete instruction even today.",
       "UK-CAF-B4": "CAF B4 (system security) expects protective measures on the platform, but port-mapped I/O access operates below the operating system entirely — reads and writes go to PCI configuration space, the SMBus and platform controllers, where no OS-level hardening, no privilege boundary and no file-integrity control applies. B4's measures cannot mediate a hardware bus that a user-mode process reaches through a legitimate signed driver.",
-      "AU-ISM-1546": "ISM control 1546 requires operating systems and applications to be patched, yet the exposure survives patching in both directions: a host with no GIGABYTE software at all is exploitable once the attacker copies in the signed driver, and a host that patched to AORUS GRAPHICS ENGINE 1.57 has no listed fixed APP Center build. The ISM's patch-centric framing gives no instruction for the actual control needed, which is a signed-driver deny rule.",
+      "AU-Essential-8-Patch": "CISA lists this flaw as known exploited, so at Maturity Level Three ISM-1879 requires the fix for the GDrv and GPCIDrv drivers within 48 hours of release, rather than the one month ISM-1697 allows when the vendor rates a flaw non-critical and no working exploit exists. Maturity Levels One and Two set no driver timeframe. The installing GIGABYTE utilities are other applications, patched within one month from Maturity Level Two under ISM-1693. NVD names fixed builds only for AORUS GRAPHICS ENGINE 1.57 and XTREME GAMING ENGINE 1.26, but none for APP Center or OC GURU II 2.08. An attacker can also copy the signed driver onto a host with no GIGABYTE software, and no patch timeframe prevents it from loading.",
       "ISO-27001-2022-A.8.9": "A.8.9 configuration management establishes and monitors secure baselines for hardware and software, but a Windows secure baseline records installed products and settings — not which kernel driver device objects exist or what DACL they carry. The insecure configuration here is that a default GIGABYTE install leaves \\\\.\\GPCIDrv64 and \\\\.\\GIO openable by LOW INTEGRITY processes, a state no A.8.9 baseline definition captures or drifts against."
     },
     "atlas_refs": [],
@@ -179883,7 +180470,7 @@
       "NIST-800-53-IA-2": "IA-2 requires the system to uniquely identify and authenticate users before granting access, but the FortiOS API decided a request was a trusted internal process from two attacker-supplied fields — a Forwarded header claiming 127.0.0.1 and a User-Agent of Report Runner or Node.js. No IA-2 implementation is even consulted on a request that never enters the authentication path, so admin MFA, password policy and account lockout are all bypassed rather than defeated.",
       "NIS2-Art21-network-security": "NIS2 Art.21 network-security obligations treat the perimeter firewall as a control providing assurance, not as an asset with its own internet-exposed management plane. Here the FortiGate/FortiProxy administrative HTTPS interface was itself the preauth entry point, and CISA records ransomware use against it — the device enforcing segmentation for everything behind it was the first thing taken over.",
       "UK-CAF-B2": "CAF B2 identity and access control is evidenced through privileged-account management: named admins, MFA coverage, session logging, periodic review. All of that stays green while the attacker creates a new super_admin called fortigate-tech-support and pushes an SSH public key into the admin's ssh-public-key1 field — the account inventory B2 asks for is exactly the artefact the attack modifies, and nothing in the objective requires reconciling it against the device's own configuration history.",
-      "AU-ISM-1546": "ISM-1546's patch clock starts at vendor release, and Fortinet shipped 7.0.7 / 7.2.2 on 2022-10-03 but published FG-IR-22-377 only on 2022-10-10, after a confidential customer notice. An operator following ISM-1546 against public advisories lost the first week outright; Horizon3's PoC arrived 2022-10-13, with a Nuclei template and Metasploit module immediately after, so the compliant patch window opened after mass scanning had already begun.",
+      "AU-Essential-8-Patch": "Fortinet's FortiOS and FortiProxy devices are internet-facing network devices, so ISM-1877 requires the fixed firmware within 48 hours of release at every maturity level when the vendor rates the flaw critical or a working exploit exists, and ISM-1694 requires it within two weeks otherwise. Fortinet released fixed builds on 2022-10-03 but published FG-IR-22-377 only on 2022-10-10, after a confidential customer notice, so an operator relying on the public advisory started either clock a week late. Horizon3's proof of concept followed on 2022-10-13, and each upgrade needs a device reboot.",
       "ISO-27001-2022-A.8.22": "A.8.22 segregation of networks is precisely what Fortinet's own workaround asks for — disable the HTTP/HTTPS admin interface or restrict it with a local-in policy — but the control is written for segregating user, service and system networks, not for confining the management plane of the segmentation device itself. An A.8.22-conformant design routinely leaves the FortiGate administrative interface reachable from the untrusted side, which is the exposure this CVE monetises."
     },
     "atlas_refs": [],
@@ -180314,7 +180901,7 @@
       "NIST-800-53-SI-10": "SI-10 information-input validation is the precise control that was absent: request parameters were concatenated into a git argv with no rejection of NUL, and Atlassian's fix is literally a null-byte filter on command arguments. SI-10 binds federal information systems the operator builds, not the argv construction inside a purchased SCM, so an SI-10-assessed environment gained no coverage for the one defect class that mattered here.",
       "NIS2-Art21-supply-chain": "NIS2 Art.21 supply-chain measures are written around assessing third-party suppliers, but Bitbucket is the source of truth for the operator's own build inputs. Code execution as atlbitbucket yields write access to every repository, hook and CI credential on the host, so the in-house SCM becomes the supply-chain choke point — a direction of risk (inward from the internet, outward into every downstream build) that supplier questionnaires and contractual clauses do not test.",
       "UK-CAF-B4": "CAF B4 system security would credit keeping repositories private as hardening, but the exposure threshold here is read access to a single repository — anonymous where any public repository exists, and one low-privilege account otherwise (CVSS PR:L). The archive endpoint is core Bitbucket function and cannot be removed, so the configuration levers B4 prescribes narrow the attacker pool without closing the path.",
-      "AU-ISM-1546": "ISM-1546 sets patch timeframes from advisory publication and scales them by whether the system is internet-facing. Atlassian's advisory landed 2022-08-24; a working public exploit, a Metasploit module and in-the-wild attempts (GreyNoise and BinaryEdge, 2022-09-20 and 2022-09-23) arrived roughly four weeks later. Many Bitbucket Server deployments sit on the corporate network and are therefore assigned the longer ISM window, which the exploit-availability curve outran — the control keys on exposure classification, not on whether point-and-shoot tooling exists.",
+      "AU-Essential-8-Patch": "An internet-accessible Bitbucket Server or Data Center instance is an online service. CISA lists this flaw as known exploited, so ISM-1876 requires the fix within 48 hours of release at every maturity level, rather than the two weeks ISM-1690 allows when the vendor rates a flaw non-critical and no working exploit exists. An instance reachable only internally is an other application under ISM-1693, with one month at Maturity Levels Two and Three and no timeframe at Maturity Level One. Atlassian released the fixed builds with its 2022-08-24 advisory, and in-the-wild attempts recorded on 2022-09-20 and 2022-09-23 fell inside that month. Each of the seven release lines needs its own fixed build, and Bitbucket Mesh nodes must move to the matching version.",
       "ISO-27001-2022-A.8.28": "A.8.28 secure coding governs the certified organisation's own development lifecycle. The defect here — an external command's argument vector built from unvalidated HTTP parameters — is exactly what A.8.28 exists to prevent, but it was shipped by Atlassian, so an ISO-certified operator running Bitbucket gets an audited secure-coding programme and zero assurance over the code that actually executed the attacker's git flags."
     },
     "atlas_refs": [],
@@ -180611,7 +181198,7 @@
       "NIST-800-53-SR-11": "SR-11 component authenticity requires anti-counterfeit measures and authenticity verification for acquired components, but the component that went unverified here is one the operator never touches: the rollback package the Apex One agent downloads on its own server's instruction. NVD records no CWE while KEV maps CWE-353, missing support for an integrity check — a control the operator cannot add to a closed endpoint agent's update path, so SR-11 assessment work on procurement produces no coverage for the integrity gap that actually mattered.",
       "NIS2-Art21-supply-chain": "NIS2 Art.21 supply-chain security is built around assessing suppliers and the security of their products, but the failure mode here sits inside a trusted supplier's own distribution channel and arrives through the console the operator legitimately uses. A supplier assessment that confirms Trend Micro's development practices, SBOM provenance and support commitments would not surface that the agent accepts a rollback package without verifying it, because that is an internal design property of the product rather than a property of the supply relationship NIS2 asks about.",
       "UK-CAF-B2": "CAF B2 identity and access control would classify the Apex One console as an administrative interface needing privileged-account separation and strong authentication, and many deployments run it as a shared operations console instead. CVE-2022-40139 makes the consequence concrete in a way B2 does not: console access is not merely administrative access to a security tool, it is arbitrary code execution on every managed endpoint via the rollback channel, so the account-tiering decision for the EDR console has to be made against endpoint-wide blast radius, not console-scoped risk.",
-      "AU-ISM-1808": "ISM-1808 software supply chain risk management directs organisations to assess the supply-chain risk of the software they deploy — questionnaires, provenance, vendor attestation. That assessment sees the product as an artefact received; it has no test that asks whether the product's own agent verifies the integrity of packages its management server instructs it to install. The downgrade path that accepts unverified components is precisely the property ISM-1808's evidence model cannot reach, so a fully compliant supply-chain assessment would have rated Apex One as low risk.",
+      "AU-ISM-1452": "ISM-1452 requires a supply chain risk assessment of the suppliers of applications and services, and ISM-1567 excludes suppliers the assessment rates high risk. The assessment rates Trend Micro as a supplier and does not test whether the Apex One client verifies a rollback package before installing it. This flaw lets an Apex One server administrator instruct clients to download an unverified rollback package, so an attacker who first gains access to the management console can run code on the managed endpoints. An assessment that meets ISM-1452 can rate Trend Micro low risk while that path exists.",
       "ISO-27001-2022-A.8.7": "A.8.7 protection against malware is evidenced during certification by showing that centrally managed anti-malware is deployed, updated and monitored — which is exactly the deployment CVE-2022-40139 turns into a code-execution channel to every endpoint. The artefact that satisfies the control is the artefact that carries the risk, and no step in the A.8.7 test asks whether the agent authenticates what its own server tells it to install, or whether a rollback to an older build is an integrity-checked operation."
     },
     "atlas_refs": [],
@@ -180806,7 +181393,7 @@
       "NIST-800-53-AC-6": "AC-6 least privilege was satisfied on paper — /dev/msm_acdb is owned by the audio/system group, not world-writable — yet any ordinary app granted RECORD_AUDIO lands in that group, so the 'least' privilege needed to smash acdb_ioctl's stack and take the kernel is a microphone permission. AC-6 reasons about privilege assignment, never about what an ioctl handler does with a user-supplied length.",
       "NIS2-Art21-supply-chain": "The defective driver is Qualcomm/Code Aurora board-support code inherited unmodified into every MSM-based OEM Android build, so NIS2 Art.21(2)(d) supplier-risk measures were pointed at the handset vendor while the vulnerable code came from the silicon vendor two tiers upstream. Supplier assurance questionnaires do not reach a kernel driver the OEM neither wrote nor audited, and the transitive-dependency language in Art.21 has no equivalent of an SBOM for a flashed boot image.",
       "UK-CAF-B4": "CAF B4 system-security outcomes assume attack surface can be reduced by configuration, but /dev/msm_acdb is the device node the audio calibration subsystem needs to function — removing it breaks audio on every MSM handset. B4 offers no compensating control for an unbounded copy_from_user into a stack buffer inside a driver the operator cannot rebuild.",
-      "AU-ISM-1808": "ISM-1808 software supply-chain risk management assumes the operator can assess vendor trustworthiness and validate software integrity. For a Code Aurora kernel driver baked into a device image there is no component inventory, no version string to compare against QCIR-2013-00002-1, and no way to determine whether a given handset build carries the 2013-06-21 fix — the control's evidence requirements simply cannot be met on this asset class.",
+      "AU-ISM-1452": "ISM-1452 requires a supply chain risk assessment for suppliers of operating systems, applications and IT equipment, and it sits outside the Essential Eight profiles. The acdb driver is Qualcomm and Code Aurora board-support code that MSM-based Android builds inherit, upstream of the handset vendor an assessment examines. Code Aurora fixed it on 2013-06-21 under QCIR-2013-00002-1, but a handset received the fix only when its OEM rebased the board-support package, and some handsets never received a fixed image. The control requires no component record below the direct supplier, so an assessment cannot show whether a given boot image carries the fix.",
       "ISO-27001-2022-A.8.8": "A.8.8 schedules remediation by risk classification, and the two signals available here disagree: EPSS sits around 0.015 (72nd percentile) because exploitation is local, silent and device-resident, while CISA has the CVE on the KEV list as actively exploited. An A.8.8 process that prioritizes on exploit-probability scoring alone deprioritizes a confirmed-exploited kernel takeover reachable by any installed app."
     },
     "atlas_refs": [],
@@ -180999,7 +181586,7 @@
       "NIST-800-53-CM-7": "CM-7 least functionality never treated perf_event_open() as optional functionality, yet that syscall is reachable by any unprivileged local user by default and is the entire attack surface here — a 64-bit attr.config truncated to int, indexing perf_swevent_enabled out of bounds and decrementing attacker-chosen kernel memory. Gating the syscall with seccomp, or raising perf_event_paranoid to 3 where the distro supports it, was the one configuration change that blocked it, and no CM-7 baseline of that era enumerated it.",
       "DORA-Art-9": "DORA Art.9 protection-and-prevention measures are written around ICT systems supporting critical or important functions and assume privilege boundaries hold inside a host. This flaw voids that boundary on every 2.6.37-3.8.8 Linux host: one unprivileged account on a shared batch, jump or web tier reaches root, and on a container host the same primitive reaches the host kernel because containers share it. Art.9's governance-level framing produces no test that would surface that condition on a financial entity's Linux estate.",
       "UK-CAF-B4": "CAF B4 system-security outcomes are evidenced through hardening baselines and patch state, but the introducing commit b0a873ebbf87 sat unnoticed for three years and the bug was ultimately found by Trinity syscall fuzzing, not by any assurance activity B4 contemplates. B4 has no outcome that asks whether the syscall surface exposed to unprivileged users has been fuzzed, so a fully-evidenced B4 posture told the operator nothing about this exposure between 2011 and 2013.",
-      "AU-ISM-1546": "ISM-1546 starts its patch clock at advisory publication, but a working public exploit — semtex.c — circulated at the same time the fix landed in 3.8.9, so even ML3's 48-hour window is a window in which every unprivileged shell account on the host already owned root. The control's clock and the exploit's clock started together, which is the failure mode a timeframe-based control cannot express.",
+      "AU-Essential-8-Patch": "The Linux kernel is patched as an operating system, so on an internet-facing server ISM-1877 requires the fix within 48 hours of release at every maturity level once a working exploit exists. Workstations and internal servers get one month at Maturity Levels One and Two (ISM-1695) and 48 hours only at Maturity Level Three (ISM-1696). The semtex.c exploit circulated as the fix landed in 3.8.9, so any unprivileged local user could gain root throughout the window. Every vendor fix, from RHSA-2013:0830, 0832, 0840 and 0841 and RHSA-2013:0829 for MRG 2 to USN-1825-1 through USN-1838-1, is a kernel upgrade that needs a reboot, and no live patch is available.",
       "ISO-27001-2022-A.8.8": "A.8.8 evaluates exposure asset by asset, and every distro-managed host here was in scope and remediated (RHSA-2013:0830, USN-1825-1 and siblings). What A.8.8 misses is the long tail the KEV listing targets: appliances and embedded Linux images that vendored a 2.6.37-3.8 kernel and never rebased, where the technical vulnerability is real but no asset record names a kernel version to evaluate."
     },
     "atlas_refs": [],
@@ -181741,7 +182328,7 @@
       "NIST-800-53-AC-3": "AC-3 access enforcement assumes the reference monitor's policy store is beyond the subject's reach. On affected macOS the monitor is tccd and its policy store is a SQLite file whose path tccd derives by expanding `$HOME` — a variable any logged-in, non-administrative user can set in their own launchd domain. A standard account therefore rewrites the policy the enforcement point consults and grants itself camera, microphone, screen-capture and Full Disk Access without escalating privilege at all, so AC-3 is satisfied on paper by an enforcement mechanism faithfully enforcing attacker-authored policy.",
       "NIS2-Art21-vulnerability-handling": "Art.21(2)(e) vulnerability handling drives remediation from severity signal and threat feeds. Apple fixed this on 2020-07-15 but CISA did not list it until 2022-09-08, and NVD scores it 5.5 (local, confidentiality-only) with no CWE assigned — so for two years a NIS2 vulnerability-handling process had no severity or feed trigger to force macOS endpoints off 10.15.x, while a maintained Metasploit post module turned any low-privilege macOS foothold into camera, microphone, screen and full-disk access on demand.",
       "UK-CAF-B2": "CAF B2 asks whether access to sensitive data is granted only to authorised identities and whether privileged access is minimised. Here the attacker needs no privilege at all: the identity performing the bypass is the ordinary interactive user, and the boundary crossed is macOS TCC consent, which is not an identity or directory construct a B2 assessment enumerates. An estate scoring well on B2 through MDM-enforced accounts and non-admin local users still lets any of those users read every file the account can reach and switch on the camera silently.",
-      "AU-ISM-1546": "ISM-1546's operating-system and application patch windows are driven by vendor-assessed severity and internet exposure. This is a local, confidentiality-only flaw on macOS, so it lands in the slowest band under any reading of the control, and the ISM's operating-system guidance is written around a Windows SOE rather than a Catalina fleet. The one action that closes it — moving endpoints to 10.15.6 / iOS 13.6 — therefore never receives an accelerated window, even though the exploit is four shell commands with a maintained Metasploit module behind it.",
+      "AU-Essential-8-Patch": "macOS Catalina is a workstation operating system. ISM-1695 allows one month from release at Maturity Levels One and Two, and ISM-1696 requires 48 hours at Maturity Level Three when a working exploit exists. A maintained Metasploit post module uses this flaw to turn a low-privilege foothold into camera, microphone and Full Disk Access, which meets the working-exploit condition. Below Maturity Level Three a Mac can still stay on 10.15.5 for a month after Apple released 10.15.6 on 2020-07-15. The update needs a restart, and iOS and iPadOS devices receive the same fix in 13.6.",
       "ISO-27001-2022-A.8.8": "A.8.8 prioritises technical vulnerabilities by risk rating, and every input to that rating understates this one: CVSS 5.5, AV:L, no NVD CWE, no ransomware association in KEV. What the rating cannot express is that the flaw's value is post-exploitation reach rather than initial access — it converts a foothold into the user's entire protected-data set plus their camera and microphone — and that it is fully reversible with `launchctl unsetenv HOME`, so an A.8.8 programme both deprioritises it and loses the on-host evidence that it was ever used."
     },
     "atlas_refs": [],
@@ -182076,7 +182663,7 @@
       "NIST-800-53-SI-2": "SI-2 is measured by whether the vendor patch was installed, and for this CVE that measurement produced a false negative at scale. Oracle's April 2018 CPU was applied widely and closed nothing durable: it blacklisted `sun.rmi.server.UnicastRef` inside `resolveProxyClass` rather than fixing pre-authentication deserialization of T3 traffic, and public bypasses using `java.rmi.activation.Activator` and `StreamMessageImpl` followed within days, eventually tracked as CVE-2018-2893 in the July CPU. For three months, an SI-2 attestation showing cpuapr2018 installed was evidence of a still-exploitable, internet-reachable T3 listener.",
       "NIS2-Art21-patch-management": "Art.21(2)(e) expresses vulnerability handling as a cadence measured against vendor releases, and Oracle ships WebLogic fixes on a fixed quarterly Critical Patch Update schedule. A NIS2 programme perfectly synchronised to that cadence had no mechanism to act between April and July 2018 — exactly the window in which the April blacklist was known to be bypassable and internet-facing port 7001 was being mass-scanned. Cadence-based patch management cannot respond to an incomplete vendor fix, because there is nothing to apply until the vendor's next scheduled window opens.",
       "UK-CAF-B4": "CAF B4 expects unnecessary services and interfaces to be removed and remaining ones to be secured. T3 is not removable in the way B4 imagines: it is WebLogic's own administration and clustering protocol and it shares port 7001 with the HTTP listener, so the work that hardens the visible tier — TLS, WAF, application authentication — leaves the same socket deserializing untrusted Java objects before authentication. The control that would have contained this is a T3 connection filter, and nothing in a B4 review prompts an assessor to distinguish two protocols multiplexed on one port.",
-      "AU-ISM-1546": "ISM-1546 covers patching operating systems and applications on a severity- and exposure-driven clock, and this CVE is the maximum case on both axes: an internet-facing application, CVSS 9.8, with a working public exploit four days after the vendor fix. The control still fails, because it has no expression for a vendor patch that is itself incomplete — 'patched' is a binary state in the assessment, so a WebLogic host recorded as remediated on the April 2018 CPU dropped out of the ISM remediation queue while the bypass route stayed open until July.",
+      "AU-Essential-8-Patch": "A WebLogic server whose T3 listener is reachable from the internet is an online service. Oracle scored this flaw 9.8 and a working exploit exists, so ISM-1876 requires the fix within 48 hours of release at every maturity level; ISM-1690 allows two weeks only for a non-critical flaw with no working exploit. A server reachable only internally is an other application under ISM-1693, which allows one month from Maturity Level Two. The April 2018 Critical Patch Update added only a resolveProxyClass blacklist, and public bypasses followed within days. A host patched on the April update met either control while it stayed exploitable until Oracle released the July fix.",
       "ISO-27001-2022-A.8.8": "A.8.8 would have prioritised this correctly — CVSS 9.8, top-percentile EPSS, KEV-listed — and would still have closed the finding on the wrong evidence, because A.8.8's remediation step is to apply the vendor's patch and the vendor's April patch was a class blacklist rather than a fix to the deserialization path. The action that genuinely removes the exposure is architectural: restrict the T3 listener with WebLogic connection filters or network ACLs so untrusted hosts never reach it. A.8.8 does not require an organisation to verify that a patch addresses the mechanism rather than one known instance of it, so the register reads closed while the attack surface persists."
     },
     "atlas_refs": [],
@@ -182294,7 +182881,7 @@
       "NIST-800-53-IA-2": "IA-2 governs how organizational users are identified and authenticated at the login exchange, but /passwordrecovered.cgi returns the router's admin username and password to a request that has made no authentication attempt at all — there is no authenticator to strengthen, rotate or multi-factor, because the device discloses the credential before any IA-2 decision point is reached. IA-2 also presumes the authenticating system is inside the authorization boundary, and the affected NETGEAR units are branch and home-office CPE that typically sit outside the SSP entirely.",
       "EU-CRA-Art13": "CRA Art.13 places essential cybersecurity requirements and a vulnerability-handling duty on manufacturers placing products with digital elements on the EU market, including shipping security updates for a declared support period. CVE-2017-5521 predates the Regulation by seven years and is the exact failure mode it was written against: NETGEAR fixed 19 routers plus the C6300 but left 8 routers and 4 DSL gateways with no firmware at all, so owners of those twelve devices have only a manual UI workaround and no manufacturer remedy to invoke.",
       "UK-CAF-B2": "CAF B2 identity and access control is written around restricting access to authorised users and devices, and assumes the authentication decision is made by a system the operator can govern. Here the device itself hands the admin credential to an unauthenticated caller over LAN, WLAN, or the WAN interface when remote management is on — no entitlement review, joiner-mover-leaver process or credential-strength policy touches a CGI endpoint that answers before authorisation is evaluated, and CAF's identity scope stops at enterprise IdM rather than the router terminating the circuit.",
-      "AU-ISM-1546": "ISM-1546 sets patch timeframes measured from vendor release, down to 48 hours at ML3 for internet-facing or exploited flaws — but that clock only runs if a patch exists. For the twelve NETGEAR devices that never received fixed firmware there is no release date to measure from, so an operator running an AC1450 or a DGN2200v4 cannot reach any maturity level through patching; the compliant position is NETGEAR's configuration workaround (enable password recovery, disable remote management), which ISM-1546 has no way to express or evidence.",
+      "AU-Essential-8-Patch": "A NETGEAR router is an internet-facing network device, so once a working exploit exists ISM-1877 requires fixed firmware or another vendor mitigation within 48 hours of release at every maturity level. The fixed firmware for nineteen models needs a reboot. For the twelve models with no fixed build, including the AC1450, NETGEAR's workaround is the vendor mitigation ISM-1877 requires. The workaround needs password recovery enabled and remote management disabled together, because either setting alone leaves the router exposed, and an assessment that checks firmware versions does not show either setting. ISM-1501 and ISM-1753 require an unsupported unit to be replaced, and ISM-1753 is outside the Essential Eight profiles.",
       "ISO-27001-2022-A.8.9": "A.8.9 configuration management works by defining a baseline and detecting drift from it, but the exploitable state here IS the shipped baseline: password recovery is disabled out of the box, and the exploit only fails once the operator turns that feature on. A device whose running configuration exactly matches the as-delivered baseline is fully exposed, so drift monitoring raises nothing, and hardening requires enabling a usability feature that no configuration standard enumerates as a security control."
     },
     "atlas_refs": [],
@@ -182686,7 +183273,7 @@
       "NIST-800-53-CM-7": "CM-7 least functionality requires restricting ports, protocols and services to those the business function needs, and is implemented through a port-and-service baseline. CouchDB's packaging opened two services the operator never chose: epmd on 4369/tcp and an Erlang distribution listener bound to all interfaces on a port assigned at start-up, both present on a single-node install purely in anticipation of clustering. A baseline written as a list of fixed port numbers cannot even name the second one, so CM-7 evidence showing 'only 5984 authorised' was accurate about intent and blind to the actual listening surface.",
       "NIS2-Art21-network-security": "Art.21 network-security measures assume the entity can enumerate what it exposes. Here the exploited listener's port is chosen at process start and advertised by epmd rather than fixed in configuration, so a NIS2-compliant segmentation review built from a static port inventory reported the database as 'API on 5984 only' while the distribution port sat open and authenticated by a cookie the packaging had set to a publicly known string. The control's assurance and the actual exposure diverged without any operator error.",
       "UK-CAF-B2": "CAF B2 identity and access control assumes authentication decisions are made against managed identities subject to entitlement review and credential lifecycle. The Erlang distribution port authenticates peers with a single shared secret, and CouchDB's packaging set that secret to 'monster' for every installation worldwide — a credential outside any joiner-mover-leaver process, rotation policy or privileged-access review B2 describes, and one whose value was published in the project's own packaging. B2 assessments looking at CouchDB admin accounts and HTTP auth would have found nothing wrong.",
-      "AU-ISM-1546": "ISM-1546 measures patch timeframes from vendor release, with a 48-hour ML3 target for internet-facing or actively exploited flaws. The advisory landed 2022-04-26 and the working public exploit followed on 2022-05-11, after which CounterCraft observed attackers moving from first reconnaissance to command execution in under half a second against exposed nodes, then installing Kinsing. A 48-hour window is orders of magnitude slower than that tempo, and it is measured against an exposure the operator could not see by port number in the first place — the honest control statement is that the distribution port had to be firewalled before the advisory, not patched within two days after it.",
+      "AU-Essential-8-Patch": "An internet-exposed CouchDB node is an online service, so ISM-1876 requires a fix or vendor mitigation within 48 hours of release at every level when the vendor rates the flaw critical or a working exploit exists, a condition the public exploit and KEV listing meet. An internal node is an other application under ISM-1693: one month from Maturity Level Two, with no Maturity Level One timeframe. CounterCraft observed attackers reach command execution in under half a second from first reconnaissance against exposed nodes, far faster than a 48-hour window. Upgrading to 3.2.2 also requires a unique Erlang cookie, and a node whose epmd and distribution port are unreachable from outside the host is not vulnerable.",
       "ISO-27001-2022-A.8.22": "A.8.22 segregation of networks is the control the vendor's own guidance invokes — 'we recommend a firewall in front of all CouchDB installations' — and it is exactly where the failure sits. Operators segregated on the documented, registered API port 5984/tcp, because that is the only port the product's public interface documentation requires, and left epmd on 4369 plus a dynamically-assigned distribution port on the wrong side of the boundary. A.8.22 assumes the firewall-zone rule set can be written from a known service inventory; a service whose port is assigned at start-up defeats that assumption, so the segmentation was complete against the documented surface and open against the real one."
     },
     "atlas_refs": [],
@@ -183430,7 +184017,7 @@
       "NIST-800-53-SR-3": "SR-3 supply chain controls govern relationships with identified suppliers, but Archive_Tar reaches virtually every victim as a transitive component — vendored inside Drupal core, or bundled in a distro php-pear package. There is no supplier relationship to control. An organisation running a fully conformant SR-3 programme against its named vendor list still had no line of sight to a 1.4.11 copy of Tar.php sitting several levels down in composer.lock or inside an OS package it never selected.",
       "NIS2-Art21-supply-chain": "NIS2 Art.21(2)(d) supply-chain security is written around direct suppliers and service providers and the security of their products. The exposure here is a bundled third-party PHP library inside a CMS distribution and inside distro packages — nobody signed a contract for Archive_Tar, and it appears on no supplier register. An entity fully meeting its Art.21 supply-chain obligations against that register would still ship 1.4.11 and still extract attacker-supplied archives through it.",
       "UK-CAF-B4": "CAF B4 system security expects vulnerable functionality to be disabled where it is not required. The vulnerable function here is ordinary archive extraction, which the CMS uses for legitimate module and theme installation — which is precisely why Drupal's own advisory offers 'disable uploads of .tar, .tar.gz, .bz2, or .tlz' as a mitigation rather than as a hardening default. B4 gives an operator no framework for a control whose cost is the platform's core administrative workflow.",
-      "AU-ISM-1546": "ISM-1546 drives patching of applications with known exploited vulnerabilities, but a PHP library inside a CMS tarball is not an application any inventory tool enumerates. Worse, the naive control action — bump pear/archive_tar to 1.4.12, the version the advisory names — satisfies ISM-1546 while shipping the release that broke relative-symlink extraction (pear/Archive_Tar issue #35), so operators who then reverted to restore functionality reopened the traversal. Only 1.4.13 is both fixed and functional, a distinction 'apply the vendor patch' does not carry.",
+      "AU-Essential-8-Patch": "The CISA KEV listing of 2022-08-25 records exploitation, so a working exploit exists. A Drupal site directly accessible over the internet, and the php-pear Archive_Tar it uses to extract archives, is an online service, so ISM-1876 requires the fix within 48 hours of release at every maturity level. An install reachable only internally is an other application under ISM-1693, which requires the fix within one month from Maturity Level Two. Archive_Tar 1.4.12 closes the traversal but rejects legitimate relative symlinks (pear/Archive_Tar issue #35), and 1.4.13 is the first release without that regression. An estate that reverted from 1.4.12 to 1.4.11 reopened the flaw while the control was recorded as met.",
       "ISO-27001-2022-A.8.28": "A.8.28 secure coding is exactly what the upstream fix implements: canonicalising a symlink's target against the extraction root before writing through it, which the pre-fix Tar.php never did. But A.8.28 binds the organisation's own development activity, and virtually every affected party consumed Archive_Tar as a dependency of Drupal or php-pear. The control had no purchase on source the organisation did not write, did not review and in most cases did not know it shipped."
     },
     "atlas_refs": [],
@@ -183634,7 +184221,7 @@
       "NIST-800-53-SC-5": "SC-5 denial-of-service protection is written to protect the organisation from DoS directed at it. Here the organisation's firewall is the weapon rather than the target — Palo Alto states explicitly that exploitation does not affect the confidentiality, integrity or availability of the firewall itself. An SC-5 control set sized entirely around inbound protection produces no finding, no alert and no remediation pressure while the appliance amplifies spoofed TCP at somebody else's link.",
       "NIS2-Art21-network-security": "NIS2 Art.21 network-security measures are assessed against continuity of the entity's own essential service. This defect costs the entity nothing measurable — no downtime, no data loss, no degraded service — so it never surfaces in an Art.21 risk assessment, while the entity materially contributes to a denial-of-service incident at a third party. Art.21 has no mechanism holding an essential entity accountable for operating an open reflector when its own essential function is demonstrably unaffected.",
       "UK-CAF-B5": "CAF B5 asks whether networks and systems are resilient to disruption of the essential function. The essential function stays up throughout — that is the substance of Palo Alto's own severity FAQ. A B5 assessment framed as 'can we keep operating' returns green with the misconfiguration in place, because the outcome B5 measures is not the outcome actually at risk here.",
-      "AU-ISM-1546": "ISM-1546 drives patching of applications and operating systems carrying known exploited vulnerabilities, and a PAN-OS upgrade is maintenance-window work on the device carrying all site traffic, so realistic time-to-patch runs to weeks. The gap is that the vendor's own no-reboot workarounds — removing the URL-filtering profile from external-facing source zones, or enabling zone protection — neutralise the reflection in a single configuration commit, and ISM-1546's patch-centric framing gives an assessor neither credit for nor a prompt toward taking that immediate mitigation while the upgrade is queued.",
+      "AU-Essential-8-Patch": "PAN-OS is the operating system of internet-facing firewalls, so ISM-1877 requires a patch or other vendor mitigation within 48 hours of release at every level when the vendor rates a flaw critical or a working exploit exists. The 2022-08-22 KEV listing shows a working exploit exists. The fix is split across six branches, and the upgrade on any of them reboots the firewall carrying all site traffic, which the window does not plan for. Meeting the window depends on the vendor's no-reboot workaround, which ISM-1877 accepts as a vendor mitigation: one configuration commit that removes the URL filtering profile from rules whose source zone has an external-facing interface, or enables zone protection that drops TCP SYN with data and strips the TCP Fast Open option.",
       "ISO-27001-2022-A.8.9": "A.8.9 configuration management is the control that actually governs this, and it is the one that would not have caught it. The trigger is not a code defect an operator patches in isolation but a specific configuration — a URL-filtering profile with blocked categories bound to a security rule whose source zone faces the internet — that Palo Alto itself describes as atypical and likely unintended. A.8.9 requires defined and monitored secure configurations, but no baseline in general circulation flagged that combination as dangerous before August 2022, so a fully conformant configuration-management programme still shipped and monitored the misconfiguration as compliant."
     },
     "atlas_refs": [],
@@ -184066,7 +184653,7 @@
       "NIST-800-53-SI-10": "SI-10 requires the system to check the validity of information inputs — and CWE-20 in Chrome's Intent handling is precisely a failure of that check, executed inside a vendor binary the operator cannot inspect, configure or instrument. SI-10 is written for systems the organisation develops or configures; when the failing validation lives in a third-party browser's scheme dispatcher, the control has no implementation the assessor can test and no setting the operator can correct. The compliant answer for a commodity browser is \"inherited from the vendor\", which is exactly the position that offers no protection between 2022-07-19 and 2022-08-16.",
       "NIS2-Art21-network-security": "Art.21 measures apply to the network and information systems the entity uses in its operations, and the affected population here is largely outside that boundary: NVD scopes the flaw to Chrome including Android builds, which in most essential entities means personally-owned handsets reaching corporate services through a browser. The entity carries the consequence of a forced navigation into a second-stage host while the vulnerable component sits on a device it does not own, cannot inventory and cannot force to 104.0.5112.101 — the Art.21 obligation and the remediation authority are held by different parties.",
       "UK-CAF-B4": "CAF B4 (System security) treats the browser as a hardened client, but the security boundary this CVE breaks is not one B4 assessment questions reach: Chrome's Intent dispatcher is the arbiter between a web origin and an OS-level navigation or app launch, and insufficient validation there lets a crafted page make that decision on the user's behalf. No B4 configuration control — managed policy baseline, extension allowlist, download restriction, enterprise proxy — changes the dispatcher's input validation, so a B4 outcome rated \"achieved\" describes hardening that this attack path never had to pass through.",
-      "AU-ISM-1546": "ISM control 1546 requires patches for applications to be applied within defined timeframes, and it is scoped to the applications in the organisation's Standard Operating Environment. Chrome on a personally-owned Android handset is not in the SOE, so the control neither measures nor compels the update that fixes this; and for the desktop estate the two-day window applicable to an exploited vulnerability starts at CISA's 2022-08-18 KEV listing while Google had already been aware of in-the-wild exploitation since at least 2022-07-19. Compliance with 1546 was achievable throughout the exposure window without shortening it by a day.",
+      "AU-Essential-8-Patch": "Chrome is a web browser, so Patch applications requires the fix within two weeks of release at Maturity Levels One and Two (ISM-1691) and within 48 hours at Maturity Level Three once a working exploit exists (ISM-1692). Google TAG reported the flaw on 2022-07-19 with an exploit already in the wild, and the fix shipped on 2022-08-16, so an exploit was in the wild four weeks before any window started. The update takes effect only after every browser window closes, and Edge 104.0.1293.47, Opera and other Chromium-derived browsers receive the fix on their own release lines, which a check of the Chrome version does not cover.",
       "ISO-27001-2022-A.8.9": "A.8.9 requires configurations of hardware, software and services to be established, documented and enforced. This CVE has no configuration expression at all: Intent handling cannot be disabled, restricted or policy-gated by an administrator, so a fully enforced hardened-Chrome baseline — managed policies applied, drift monitored, deviations remediated — leaves the vulnerable code path identically reachable. The control's entire mechanism is settings management, and the defect is in code that ships the same way at every setting."
     },
     "atlas_refs": [],