@blamejs/exceptd-skills 0.21.8 → 0.21.9

package/data/zeroday-lessons.json

@@ -3446,7 +3446,7 @@
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
         "description": "4h KEV-listing mitigation SLA applies; reboot-required does not extend the SLA.",
-        "evidence": "CVE-2025-14174 — KEV-listed 2025-12-15 with confirmed targeted in-wild exploitation.",
+        "evidence": "CVE-2025-14174 was KEV-listed on 2025-12-12 with confirmed targeted in-wild exploitation.",
         "gap_closes": [
           "NIST-800-53-SI-2"
         ]
@@ -3597,7 +3597,7 @@
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
         "description": "4h KEV-listing mitigation SLA applies to the mobile estate.",
-        "evidence": "CVE-2025-24201 — KEV-listed 2025-03-12 with public Glass Cage chain.",
+        "evidence": "CVE-2025-24201 was KEV-listed on 2025-03-13 with a public Glass Cage chain.",
         "gap_closes": [
           "NIST-800-53-SI-2"
         ]
@@ -4742,7 +4742,7 @@
       {
         "id": "NEW-CTRL-091",
         "name": "UNTRUSTED-MODEL-ARTIFACT-LOADING",
-        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. Upgrade Keras to the fixed release (>= 3.8.0 for CVE-2025-1550; past 3.10.0 for the CVE-2025-8747 safe_mode bypass) and do not rely on safe_mode alone — it was bypassable. The distinguishing test: load an attacker-crafted .keras archive with safe_mode enabled on a sandboxed instance and confirm no code executes.",
+        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. The distinguishing test: load an attacker-crafted model artifact on a sandboxed instance and confirm no code executes.",
         "evidence": "https://nvd.nist.gov/vuln/detail/CVE-2025-1550",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -4842,7 +4842,7 @@
       {
         "id": "NEW-CTRL-091",
         "name": "UNTRUSTED-MODEL-ARTIFACT-LOADING",
-        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. Upgrade Keras to the fixed release (>= 3.8.0 for CVE-2025-1550; past 3.10.0 for the CVE-2025-8747 safe_mode bypass) and do not rely on safe_mode alone — it was bypassable. The distinguishing test: load an attacker-crafted .keras archive with safe_mode enabled on a sandboxed instance and confirm no code executes.",
+        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. The distinguishing test: load an attacker-crafted model artifact on a sandboxed instance and confirm no code executes.",
         "evidence": "https://nvd.nist.gov/vuln/detail/CVE-2025-1550",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -4992,7 +4992,7 @@
       {
         "id": "NEW-CTRL-091",
         "name": "UNTRUSTED-MODEL-ARTIFACT-LOADING",
-        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. Upgrade Keras to the fixed release (>= 3.8.0 for CVE-2025-1550; past 3.10.0 for the CVE-2025-8747 safe_mode bypass) and do not rely on safe_mode alone — it was bypassable. The distinguishing test: load an attacker-crafted .keras archive with safe_mode enabled on a sandboxed instance and confirm no code executes.",
+        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. The distinguishing test: load an attacker-crafted model artifact on a sandboxed instance and confirm no code executes.",
         "evidence": "https://nvd.nist.gov/vuln/detail/CVE-2025-1550",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -5442,7 +5442,7 @@
       {
         "id": "NEW-CTRL-100",
         "name": "AI-FRAMEWORK-CLI-SHELL-INPUT-NEUTRALIZATION",
-        "description": "AI-framework CLIs and tools that invoke external commands must never build a shell string from user-supplied arguments or config: use argv-array execution (no shell), or neutralize input with shlex/equivalent. Upgrade llama-index-cli past 0.12.20 to the shlex-escaped release, and in any wrapper/automation pass arguments as a list rather than a shell string. The distinguishing test: pass a --files value containing shell metacharacters to a staging CLI and confirm no subcommand executes.",
+        "description": "AI-framework CLIs and tools that invoke external commands must never build a shell string from user-supplied arguments or config: use argv-array execution (no shell), or neutralize input with shlex/equivalent. In any wrapper/automation, pass arguments as a list rather than a shell string. The distinguishing test: pass an argument value containing shell metacharacters to a staging CLI and confirm no subcommand executes.",
         "evidence": "https://huntr.com/bounties/19e1c67e-1d77-451d-b10b-acbe99900b22",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -5592,7 +5592,7 @@
       {
         "id": "NEW-CTRL-091",
         "name": "UNTRUSTED-MODEL-ARTIFACT-LOADING",
-        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. Upgrade Keras to the fixed release (>= 3.8.0 for CVE-2025-1550; past 3.10.0 for the CVE-2025-8747 safe_mode bypass) and do not rely on safe_mode alone — it was bypassable. The distinguishing test: load an attacker-crafted .keras archive with safe_mode enabled on a sandboxed instance and confirm no code executes.",
+        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. The distinguishing test: load an attacker-crafted model artifact on a sandboxed instance and confirm no code executes.",
         "evidence": "https://nvd.nist.gov/vuln/detail/CVE-2025-1550",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -5692,7 +5692,7 @@
       {
         "id": "NEW-CTRL-088",
         "name": "AI-COMPUTE-CONTROL-PLANE-AUTHENTICATION",
-        "description": "An AI compute framework's job/control API must authenticate every caller; 'deploy only on a trusted network' is an assumption, not a control, and must not substitute for authentication. Enable Ray token authentication (2.52.0+), never expose the dashboard / Job Submission API to untrusted networks, front it with an authenticating proxy, and treat any internet-exposed cluster as compromised (rotate model artifacts and cloud credentials). The distinguishing test: from the public internet, attempt to reach the Ray dashboard (default 8265) and submit a job unauthenticated on a staging cluster; it must be refused.",
+        "description": "An AI compute framework's job/control API must authenticate every caller; 'deploy only on a trusted network' is an assumption, not a control, and must not substitute for authentication. Never expose the framework's REST or job API to untrusted networks, front it with an authenticating proxy, and treat any internet-exposed cluster as compromised (rotate model artifacts and cloud credentials). The distinguishing test: from the public internet, attempt to reach the framework's REST API unauthenticated on a staging cluster; it must be refused.",
         "evidence": "https://atlas.mitre.org/studies/AML.CS0023",
         "gap_closes": [
           "NIST-800-53-IA-2",
@@ -8474,7 +8474,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "Packet attack vector: an attacker-controlled document reaching Microsoft Office's parser for code execution in the Office process (CWE-94). poc_available true and CISA-confirmed in-the-wild exploitation at the 2026-04-14 KEV listing. AU-Essential-8-App-Hardening (user application hardening) and NIST-800-53-AC-6 (least privilege) are both already recorded as insufficient controls citing this CVE.",
         "gap_closes": [
           "AU-Essential-8-App-Hardening",
@@ -15315,7 +15315,7 @@
       {
         "id": "NEW-CTRL-085",
         "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
-        "description": "The injectable path on Configuration Manager is reached without credentials — the packet describes crafted requests processed in an unsafe manner by the server — so the two assumptions operators normally lean on for this product ('the site server is on the internal network' and 'a WAF fronts the client-facing endpoints') are both untested inferences, and neither is evidence that a query is bound rather than concatenated. The control requires parameterization to be proven at the query layer for every request handler that accepts client-originated content, and re-proven after each site-server update, rather than inferred from upstream input validation. The distinguishing test: from an unauthenticated host that can reach the site server's request-handling endpoints on a staging hierarchy, submit request fields carrying SQL metacharacters and confirm the value is passed as a bound parameter rather than becoming part of the statement — a hierarchy that passes an application-firewall audit while a handler concatenates client-supplied content still yields command execution on the server and the database behind it.",
+        "description": "The injectable path on Configuration Manager is reached without credentials: CISA's KEV entry describes crafted requests processed in an unsafe manner by the server. The two assumptions operators normally lean on for this product ('the site server is on the internal network' and 'a WAF fronts the client-facing endpoints') are therefore both untested inferences, and neither is evidence that a query is bound rather than concatenated. The control requires parameterization to be proven at the query layer for every request handler that accepts client-originated content, and re-proven after each site-server update, rather than inferred from upstream input validation. The distinguishing test is run from an unauthenticated host that can reach the site server's request-handling endpoints on a staging hierarchy: submit request fields carrying SQL metacharacters and confirm the value is passed as a bound parameter rather than becoming part of the statement. A hierarchy that passes an application-firewall audit while a handler concatenates client-supplied content still yields command execution on the server and the database behind it.",
         "evidence": "CVE-2024-43468 is classified as CWE-89, an SQL injection on Microsoft Configuration Manager that escalates to unauthenticated remote code execution. CISA's KEV entry describes an unauthenticated attacker sending specially crafted requests that are processed in an unsafe manner, enabling execution of commands on the server and/or underlying database. The CVSS score is 9.8, active exploitation is confirmed, and a proof of concept is available.",
         "gap_closes": [
           "UK-CAF-B4"
@@ -22800,7 +22800,7 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "A Meteobridge is a small weather-station data-logger appliance that no endpoint-management console enrols and no software-inventory agent reports, so the KEV clock this control imposes lands on a device class that typically has no owner inside the patch program at all — the first work the SLA forces is enumerating where these units are before any of them can be counted as remediated. Meeting it means each unit is taken through the vendor update and the restart the packet's live_patch_notes describe, with no live-patch path available to avoid that interruption. The SLA is unusually load-bearing on this product because the flaw needs no credential and yields root: there is no partial state where an unpatched unit is merely degraded, and there is no account lockout, session expiry or credential rotation that buys time while the update is scheduled — an enumerated-but-unpatched Meteobridge past the clock is fully exposed to a publicly available exploit.",
+        "description": "A Meteobridge is a small weather-station data-logger appliance that no endpoint-management console enrolls and no software-inventory agent reports, so the KEV clock this control imposes lands on a device class that typically has no owner inside the patch program at all. The first work the SLA forces is enumerating where these units are before any of them can be counted as remediated. Meeting it means each unit is taken through the vendor update and the restart that update requires, with no live-patch path available to avoid that interruption. The SLA is unusually load-bearing on this product because the flaw needs no credential and yields root: there is no partial state where an unpatched unit is merely degraded, and there is no account lockout, session expiry or credential rotation that buys time while the update is scheduled. An enumerated-but-unpatched Meteobridge past the clock is fully exposed to a publicly available exploit.",
         "evidence": "Packet records cisa_kev true with kev_date 2025-10-02 and active_exploitation confirmed, RWEP 77 / CVSS 9.8, poc_available true. patch_available is true, live_patch_available is false, and live_patch_notes read: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are recorded among the citing gaps.",
         "gap_closes": [
           "AU-Essential-8-Patch",
@@ -23663,7 +23663,7 @@
         "id": "NEW-CTRL-018",
         "name": "SCANNER-PAPER-COMPLIANCE-TEST",
         "description": "A version-based verdict is the specific way remediation goes wrong on this CVE. The exploitation path is a known/static ASP.NET machine key abused through ViewState, so a Sitecore instance can sit at the vendor's fixed release and stay fully exploitable if the default machine key was never replaced. A scanner reads the product version, and the product version is not where this vulnerability lives. The operational test that separates paper compliance from remediation, run per instance of XM, XP, XC and Managed Cloud, is to produce the machineKey in effect at runtime and show that it is not a product-default or template-inherited value, that it differs between instances built from the same deployment template, and that it was generated after that instance's exposure window rather than carried across the update unchanged. A vulnerability-management report listing the instance as patched on version evidence alone has recorded the update and not the fix, and the same report will keep reading clean on every instance the deployment pipeline recreates from the pre-rotation template. Precondition: this is a verification control. It tells the operator whether the exposure is actually gone, it does not remove it, and neither the version check nor the key check speaks to whether the instance was already exploited. Because in-the-wild exploitation is confirmed and a public PoC exists, an instance that fails this test on first run has to be treated as having been reachable with a known key, which is an incident-triage question rather than a scan-and-close one.",
-        "evidence": "Packet vector: the flaw \"involv[es] the use of default machine keys\" and \"allows attackers to exploit exposed ASP.NET machine keys to achieve remote code execution\" across Sitecore XM, XP, XC and Managed Cloud. Attack vector: CWE-502 deserialization \"abusing a known/static ASP.NET machine key via ViewState, enabling unauthenticated remote code execution.\" CISA KEV-listed 2025-09-04 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 77. patch_available true, live_patch_available false.",
+        "evidence": "CISA's KEV entry states that the flaw involves \"the use of default machine keys\" and \"allows attackers to exploit exposed ASP.NET machine keys to achieve remote code execution\" across Sitecore XM, XP, XC and Managed Cloud. The flaw is a CWE-502 deserialization issue that works by abusing a known/static ASP.NET machine key via ViewState, enabling unauthenticated remote code execution. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-09-04. Active exploitation is confirmed, and a proof-of-concept exploit is available. It has a CVSS score of 9.8 and an RWEP score of 77. A fixed release is available, and no live patch is available.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIS2-Art21-patch-management",
@@ -24871,7 +24871,7 @@
         "id": "NEW-CTRL-122",
         "name": "EOL-ASSET-DECOMMISSION",
         "description": "This applies to one slice of the exposed population and has to be scoped to it. The patch-management gap cited for this entry records that this Excel RCE persists wherever unpatched or end-of-life Office builds still open attachments, and the fact that a fixed release is available means a fix exists for this CVE, not that every install carrying the flaw can still receive one. The determination is therefore per install rather than per product: for each affected Microsoft Office install, establish from the vendor advisory whether that version can still be driven to the build carrying this fix. Installs that can are remediation items on the KEV clock that opened 2025-08-12, and because there is a reboot requirement with no live-patch path, they are not complete until that restart is taken. Installs on an Office version past end-of-support cannot reach a fixed build at all; for those the terminal state is removal or replacement on a dated schedule, because such a copy is exposed not only to this parser flaw but to everything found in Office since its last servicing, and it will keep opening mailed spreadsheets in the meantime. The failure this prevents is a compliance record that reads clean while the exposure stands: an estate whose supported installs all report the fixed build closes the flaw-remediation ticket, while the out-of-support copies (precisely where this legacy CVE lives) are carried as an accepted risk with no removal date. Scope this to the affected Microsoft Office installs; a crafted spreadsheet opened in some other vendor's application is not this CVE, and treating every out-of-support office suite in the estate as an instance of it manufactures replacement work that no evidence for this entry supports. Precondition: this reaches only the installs an inventory can see, and an unmanaged per-user copy is remediated by removing it, not by recording it as accepted.",
-        "evidence": "Packet fields for CVE-2007-0671: patch_available true; patch_required_reboot true; live_patch_available false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction; affected 'Microsoft Office — see vendor advisory linked in verification_sources for affected version ranges'; affected_versions 'Microsoft Office — versions per vendor advisory'; kev_date 2025-08-12; active_exploitation confirmed; poc_available true. The NIS2-Art21-patch-management gap states: 'Patch-management duties assume the Office fleet is current, but this legacy Excel RCE persists wherever unpatched or end-of-life Office builds still open attachments.' The vector records delivery as an email attachment or a malicious website, with code execution when the crafted Excel file is opened.",
+        "evidence": "A vendor patch for CVE-2007-0671 is available and typically requires a service restart or system reboot; no live patch exists. The affected Office versions are listed in the vendor advisory. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2025-08-12, exploitation is confirmed, and a public proof of concept exists. The NIS2-Art21-patch-management gap states: 'Patch-management duties assume the Office fleet is current, but this legacy Excel RCE persists wherever unpatched or end-of-life Office builds still open attachments.' CISA's KEV entry describes delivery as an email attachment or a malicious website, with code execution when the crafted Excel file is opened.",
         "gap_closes": [
           "NIS2-Art21-patch-management"
         ]
@@ -27861,7 +27861,7 @@
       {
         "id": "NEW-CTRL-021",
         "name": "TIER-3-DEPENDENCY-INVENTORY",
-        "description": "This flaw affects various products implementing the Erlang/OTP SSH server, including but not limited to Cisco, NetApp and SUSE. For most operators that means the vulnerable code is not something they installed but something a vendor embedded, and no host in the estate reports 'Erlang/OTP' anywhere an administrator would look. Bound to this CVE the control means the component inventory has to be able to answer 'which products in service contain an Erlang/OTP SSH server' from vendor SBOM and advisory data rather than from installed-package lists, with the three vendors the packet names enumerated first and the enumeration extended by vendor response rather than stopped there — the packet's own wording is explicitly non-exhaustive, so treating those three as the affected set is a decision to leave the rest unknown. The distinguishing test is deliberately an absence test done properly: take an appliance whose vendor is not one of the three named and show the answer to 'does this product embed an Erlang/OTP SSH server?' comes from that vendor's SBOM or advisory, not from the absence of an Erlang package on the host — for an embedded runtime, absence from an installed-software list and true absence look identical. Precondition: the inventory remediates nothing on its own; it determines which vendor updates apply. There is a vendor patch, no live-patch path, and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so each identified product carries its own update and its own restart, and a product identified and updated but not restarted is still running the vulnerable listener. The packet names no fixed Erlang/OTP release, so the fixed version is whatever each product's vendor publishes for that product.",
+        "description": "CISA's KEV entry states that the flaw could affect various products that implement the Erlang/OTP SSH server, including but not limited to Cisco, NetApp and SUSE. For most operators that means the vulnerable code is not something they installed but something a vendor embedded, and no host in the estate reports 'Erlang/OTP' anywhere an administrator would look. Bound to this CVE the control means the component inventory has to be able to answer 'which products in service contain an Erlang/OTP SSH server' from vendor SBOM and advisory data rather than from installed-package lists, with those three vendors enumerated first and the enumeration extended by vendor response rather than stopped there. CISA's wording is explicitly non-exhaustive, so treating those three as the affected set is a decision to leave the rest unknown. The distinguishing test is deliberately an absence test done properly: take an appliance whose vendor is not one of the three named and show the answer to 'does this product embed an Erlang/OTP SSH server?' comes from that vendor's SBOM or advisory, not from the absence of an Erlang package on the host. For an embedded runtime, absence from an installed-software list and true absence look identical. Precondition: the inventory remediates nothing on its own; it determines which vendor updates apply. There is a vendor patch, no live-patch path, and a fix that typically requires a service restart or system reboot, so each identified product carries its own update and its own restart, and a product identified and updated but not restarted is still running the vulnerable listener. For an embedded runtime, the fixed version is whatever each product's vendor publishes for that product.",
         "evidence": "CISA's KEV entry states that this vulnerability could affect various products that implement Erlang/OTP SSH server, including but not limited to Cisco, NetApp, and SUSE. The weakness is CWE-306, and the CVE carries a CVSS score of 9.8 and an RWEP score of 77. A proof of concept is available, active exploitation is confirmed, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2025-06-09. A fixed release is available, but no live patch is available: no live-patch tool was registered for this entry when it was added to the catalog, and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
         "gap_closes": [
           "AU-Essential-8-Patch",
@@ -29416,7 +29416,7 @@
       {
         "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
-        "description": "The Essential-Eight gap on this entry states where this starts: SOHO-grade Vigor routers are seldom in the patch inventory at all, so the first requirement is an inventory naming every DrayTek Vigor unit in service with its model, hardware revision and running firmware version. Affected versions are given only as 'DrayTek Vigor Routers — versions per vendor advisory', so both the affected-model list and the fixed firmware level have to be read from that advisory per model rather than inferred from the three models the vector names, and each unit's end-of-support status must be obtained from the vendor rather than assumed in either direction — patch_available true says a fix exists for this CVE, not that every Vigor model in service can still receive one. Units whose model and revision have fixed firmware are remediation items on the clock that opened with the 2025-05-15 KEV listing; because the packet registers no live-patch path and a fix that typically requires a service restart or system reboot, a unit that has taken firmware but not restarted onto it still executes the vulnerable code and counts as exposed. Units whose model has no fixed firmware per the advisory cannot be patched at all and are replacement items needing a dated schedule — closing this entry at 'every unit reports the fixed build' leaves an unsupported Vigor with a public PoC and confirmed exploitation in service indefinitely, which is precisely what this entry's ISO A.8.8 coverage records when it notes that unmanaged and end-of-life devices fall outside most patch programs entirely and that such devices can only be replaced, not patched. Precondition: an inventory reaches only units the operator knows about, and home-office and small-branch Vigor units bought outside procurement are the population this class is mass-exploited through — they are remediated by being found and then updated or removed, not by being absent from the report.",
+        "description": "The Essential-Eight gap on this entry states where this starts: SOHO-grade Vigor routers are seldom in the patch inventory at all, so the first requirement is an inventory naming every DrayTek Vigor unit in service with its model, hardware revision and running firmware version. The affected versions are stated only as the DrayTek Vigor router versions listed in the vendor advisory, so both the affected-model list and the fixed firmware level have to be read from that advisory per model rather than inferred from the three models CISA's KEV entry names, and each unit's end-of-support status must be obtained from the vendor rather than assumed in either direction. A fixed release is available for this CVE, but that does not mean every Vigor model in service can still receive one. Units whose model and revision have fixed firmware are remediation items on the clock that opened with the 2025-05-15 KEV listing. Because no live-patch path is available and the fix typically requires a service restart or system reboot, a unit that has taken firmware but not restarted onto it still executes the vulnerable code and counts as exposed. Units whose model has no fixed firmware per the advisory cannot be patched at all and are replacement items needing a dated schedule. Closing this entry at 'every unit reports the fixed build' leaves an unsupported Vigor with a public PoC and confirmed exploitation in service indefinitely, which is precisely what this entry's ISO A.8.8 coverage records when it notes that unmanaged and end-of-life devices fall outside most patch programs entirely and that such devices can only be replaced, not patched. Precondition: an inventory reaches only units the operator knows about, and home-office and small-branch Vigor units bought outside procurement are the population this class is mass-exploited through. They are remediated by being found and then updated or removed, not by being absent from the report.",
         "evidence": "The affected products are given as DrayTek Vigor Routers, with the affected version ranges in the vendor advisory and the affected versions given only as 'versions per vendor advisory'. A fixed release is available, the patch requires a reboot, and no live patch is available; the vendor patch typically requires a service restart or system reboot per the required action in CISA's KEV entry. CISA added this vulnerability to its Known Exploited Vulnerabilities catalog on 2025-05-15, active exploitation is confirmed, and a proof of concept is available. The AU-Essential-8-Patch gap states SOHO-grade Vigor routers are seldom in the patch inventory, leaving this KEV-listed edge-device RCE exposed on the internet. This entry's framework coverage records for ISO-27001-2022-A.8.8 that unmanaged/EOL devices fall outside most patch programs entirely, for NIST-800-53-SI-2 that many such devices run end-of-life firmware with no available fix, and for NIS2 that end-of-life devices can only be replaced, not patched.",
         "gap_closes": [
           "AU-Essential-8-Patch",
@@ -29498,7 +29498,7 @@
       {
         "id": "NEW-CTRL-030",
         "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
-        "description": "Remote code or command execution sits behind a crafted HTTP request to four named Fortinet appliances — FortiFone, FortiVoice, FortiNDR and FortiMail — with no credential and no user interaction anywhere in the path, so the appliance's own request-handling surface is what fails. That is the tier's premise, and it is why the standard 14/30-day appliance-patch window does not apply here: the fixed firmware has to be driven across every affected unit of those four product families on the clock that opened with the 2025-05-14 KEV listing. The packet registers no live-patch path and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so completion is measured per unit as 'running the fixed build and restarted since', not as 'image pushed' or 'update approved' in a management console — a unit that has staged the firmware without restarting is still executing the vulnerable code. The tier's alternative branch, isolating the vulnerable interface, carries a precondition that must be stated rather than assumed: the vector is 'crafted HTTP requests' without distinguishing an administrative interface from a user-facing web surface, so any reachability restriction has to cover every HTTP listener each unit exposes, and on a unit that must answer HTTP from untrusted networks to perform its function isolation is not available at all — for those, the update plus the restart is the only path and no interim control substitutes for it. Distinguishing test: query each affected unit directly for its running firmware and its uptime since the update, rather than accepting a fleet report that lists the four product families as patched to policy.",
+        "description": "Remote code or command execution sits behind a crafted HTTP request to four named Fortinet appliances (FortiFone, FortiVoice, FortiNDR and FortiMail) with no credential and no user interaction anywhere in the path, so the appliance's own request-handling surface is what fails. That is the tier's premise, and it is why the standard 14/30-day appliance-patch window does not apply here: the fixed firmware has to be driven across every affected unit of those four product families on the clock that opened with the 2025-05-14 KEV listing. There is no live-patch path, and the vendor patch typically requires a service restart or system reboot, so completion is measured per unit as 'running the fixed build and restarted since', not as 'image pushed' or 'update approved' in a management console. A unit that has staged the firmware without restarting is still executing the vulnerable code. The tier's alternative branch, isolating the vulnerable interface, carries a precondition that must be stated rather than assumed: the vector is 'crafted HTTP requests' without distinguishing an administrative interface from a user-facing web surface, so any reachability restriction has to cover every HTTP listener each unit exposes, and on a unit that must answer HTTP from untrusted networks to perform its function isolation is not available at all. For those units, the update plus the restart is the only path and no interim control substitutes for it. Distinguishing test: query each affected unit directly for its running firmware and its uptime since the update, rather than accepting a fleet report that lists the four product families as patched to policy.",
         "evidence": "CISA's KEV entry states: 'Fortinet FortiFone, FortiVoice, FortiNDR and FortiMail contain a stack-based overflow vulnerability that may allow a remote unauthenticated attacker to execute arbitrary code or commands via crafted HTTP requests.' The weakness is CWE-124. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-05-14, active exploitation is confirmed, and a proof of concept is available. It carries a CVSS score of 9.8 and an RWEP score of 77. A fixed release is available and no live patch is available. No live-patch tool is registered for this entry, and the vendor patch typically requires a service restart or system reboot per the required action in CISA's KEV entry.",
         "gap_closes": [
           "AU-Essential-8-Patch",
@@ -32955,7 +32955,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "https://source.android.com/docs/security/bulletin/2026/2026-06-01",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -35712,7 +35712,7 @@
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
         "description": "This CVE's exposure is configuration-determined, and each lever is nameable: the path needs the default servlet's write support enabled (off by default) and partial PUT supported (on by default), and the escalation from file-write to code execution additionally needs Tomcat's file-based session persistence at the default storage location plus a deserialization-exploitable library on the classpath. Every one of those is a Tomcat configuration setting the operator can change without waiting for the vendor upgrade, which is exactly what this control requires be inventoried, tested and deployable on its own clock: know per instance whether default-servlet write support is on, turn it off wherever nothing depends on HTTP writes through that servlet, and move file-based session persistence off the default storage location where write support must stay. That matters here because the remediation is a vendor update with no live-patch path, so an instance keeps running the vulnerable partial-PUT implementation until the fixed build is the one actually executing. Distinguishing test: on a staging instance carrying the production configuration, issue an unauthenticated partial PUT whose target path exercises the separator-to-dot equivalence, and confirm no attacker-controlled bytes land at a predictable location outside the intended upload target — an inventory row asserting 'write support is off by default' describes the shipped default, not the configuration this instance is running. Preconditions, both load-bearing: disabling write support is not available to an application that genuinely serves HTTP writes through the default servlet, and there the remaining levers are the session-persistence location and the upgrade. Moving session persistence off the default location removes the stated route to code execution but not the write primitive itself — absent the deserialization preconditions the same primitive still yields read or injection of security-sensitive uploaded files, so the instance stays exposed to disclosure and content tampering. And neither change evicts anything already written through the path before it was made; with exploitation confirmed in the wild and a public PoC, an instance reachable during the exposure window needs its session-persistence directory and its served content compared against a known-good state, not just a configuration diff.",
-        "evidence": "Packet: write support on Tomcat's default servlet is 'enabled (off by default)' and 'partial PUT is supported (on by default)'; the original partial-PUT implementation 'wrote the request body to a temporary file whose name was derived from the user-supplied path with the path separator replaced by a dot (\"internal dot\" path equivalence, CWE-706/CWE-44), letting an attacker place attacker-controlled bytes at a predictable filesystem location outside the intended upload target.' The RCE step requires that 'the application uses Tomcat's file-based session persistence at the default storage location and ships a deserialization-exploitable library on the classpath', staged via partial PUT then triggered 'with a crafted JSESSIONID request (CWE-502)'; 'absent the deserialization preconditions the same primitive yields read/inject of security-sensitive uploaded files'. CISA KEV-listed 2025-04-01, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 76. patch_available true; live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "evidence": "The flaw is reachable when write support on Tomcat's default servlet is enabled (off by default) and partial PUT is supported (on by default). The original partial-PUT implementation wrote the request body to a temporary file whose name was derived from the user-supplied path with the path separator replaced by a dot (\"internal dot\" path equivalence, CWE-706/CWE-44), letting an attacker place attacker-controlled bytes at a predictable filesystem location outside the intended upload target. The RCE step requires that the application uses Tomcat's file-based session persistence at the default storage location and ships a deserialization-exploitable library on the classpath, and it is staged via partial PUT, then triggered with a crafted JSESSIONID request (CWE-502). Absent the deserialization preconditions, the same primitive yields read/inject of security-sensitive uploaded files. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-04-01. Active exploitation is confirmed, and a proof-of-concept exploit is available. It has a CVSS score of 9.8 and an RWEP score of 76. A fixed release is available. There is no live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -35724,7 +35724,7 @@
         "id": "NEW-CTRL-018",
         "name": "SCANNER-PAPER-COMPLIANCE-TEST",
         "description": "A scan that reads the Tomcat version banner and stops cannot tell an operator which of this CVE's two documented outcomes each instance faces, and the packet makes that difference the entire triage question: with default-servlet write support enabled, partial PUT available, file-based session persistence at the default storage location and a deserialization-exploitable library on the classpath, the result is remote code execution; without the deserialization preconditions the same primitive yields read or injection of security-sensitive uploaded files. The operational test for this CVE is therefore whether the assessment reports, per Tomcat instance, (a) whether write support on the default servlet is enabled, (b) whether partial PUT is available, (c) where file-based session persistence stores its files, and (d) whether the build actually running carries the fix — or whether it emits one CVSS 9.8 row per version banner. A version-only result is paper compliance in both directions at once: it raises instances that cannot reach the code-execution chain, and it marks compliant an instance whose configuration does reach it as soon as the banner reports a fixed build, even though there is no live-patch path and the process may still be executing the previous one. Precondition: this control changes what the assessment reports; it changes nothing about the instance. An accurate inventory that finds write support enabled on a Tomcat still leaves that instance fully exposed until the configuration is changed or the fixed build is running.",
-        "evidence": "Packet: the code-execution path is conditional on write support being 'enabled (off by default)', partial PUT being 'supported (on by default)', 'file-based session persistence at the default storage location' and 'a deserialization-exploitable library on the classpath'; 'absent the deserialization preconditions the same primitive yields read/inject of security-sensitive uploaded files (information disclosure / content tampering).' CWE-44, CWE-502, CWE-706. CISA KEV-listed 2025-04-01, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 76. live_patch_available false.",
+        "evidence": "The code-execution path is conditional on write support being enabled (off by default), partial PUT being supported (on by default), file-based session persistence at the default storage location, and a deserialization-exploitable library on the classpath. Absent the deserialization preconditions, the same primitive yields read/inject of security-sensitive uploaded files (information disclosure / content tampering). The weaknesses are CWE-44, CWE-502 and CWE-706. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-04-01. Active exploitation is confirmed, and a proof-of-concept exploit is available. It has a CVSS score of 9.8 and an RWEP score of 76. No live patch is available.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIST-800-53-SI-2",
@@ -35735,7 +35735,7 @@
         "id": "NEW-CTRL-021",
         "name": "TIER-3-DEPENDENCY-INVENTORY",
         "description": "The packet makes a transitive dependency the switch between information disclosure and remote code execution on this CVE: the code-execution path requires that the application 'ships a deserialization-exploitable library on the classpath', alongside file-based session persistence at the default storage location. A gadget-capable library is almost never something an application declares directly — it arrives underneath a framework, a connector or a driver — so a dependency inventory that stops at declared dependencies cannot answer whether a given Tomcat-hosted application belongs to the RCE population or the disclosure population, which is the question that decides how urgently each instance is handled. Applied here: the inventory for every application deployed on an affected Tomcat must resolve the full transitive classpath, and the triage decision for this CVE must be taken from that resolved classpath rather than from the application's declared dependency list. Preconditions: resolving the classpath does not change it — an application found to carry a gadget-capable library on a Tomcat that also has write support and default-location session persistence is in the code-execution population and still needs the configuration lever or the fixed build; the inventory only identifies which instances those are. And the classpath is a property of what is deployed, so it has to be re-resolved on each application deployment rather than captured once, or the answer goes stale the next time a dependency is added underneath.",
-        "evidence": "Packet: the escalation to RCE requires that the application 'uses Tomcat's file-based session persistence at the default storage location and ships a deserialization-exploitable library on the classpath', after which the attacker 'stages a malicious serialized session object via partial PUT, then forces Tomcat to deserialize it with a crafted JSESSIONID request (CWE-502)'. Without those preconditions the outcome is read/inject of security-sensitive uploaded files. CISA KEV-listed 2025-04-01, active_exploitation confirmed, poc_available true, RWEP 76.",
+        "evidence": "The escalation to RCE requires that the application uses Tomcat's file-based session persistence at the default storage location and ships a deserialization-exploitable library on the classpath, after which the attacker stages a malicious serialized session object via partial PUT, then forces Tomcat to deserialize it with a crafted JSESSIONID request (CWE-502). Without those preconditions the outcome is read/inject of security-sensitive uploaded files. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-04-01. Active exploitation is confirmed, a proof-of-concept exploit is available, and it has an RWEP score of 76.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIS2-Art21-vulnerability-management"
@@ -35802,7 +35802,7 @@
         "id": "NEW-CTRL-124",
         "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
         "description": "Cisco Smart Licensing Utility ships an undocumented static administrative account whose credential is compiled into the binary, so the secret an attacker needs is a property of the product, identical on every install, and not something the operator provisioned or can rotate. That inverts the usual form of this control: there is no per-instance key to make unique, so the deployment gate has to be presence-of-the-shipped-credential rather than uniqueness-of-the-operator's. For CSLU that means treating any host carrying an affected 2.0.0-2.2.0 build as holding a published administrative credential until the vendor update is applied, and verifying after the update that presenting the shipped Basic-auth credential to the CSLU REST API on TCP/8182 is refused rather than accepted. Re-run that check after any workstation or server rebuild, image restore or CSLU reinstall, since those are the operations that silently put an affected build back on a host that was previously remediated, and the utility carries no operator-visible account listing that would make the regression obvious. The distinguishing test is to authenticate against a staging instance with the shipped credential and confirm refusal — an estate that passes a password-policy and privileged-account-review audit still hands full administrative control of the CSLU API to any unauthenticated caller who can reach the port, because the account was never in the directory the audit examined.",
-        "evidence": "Packet vector: 'Cisco Smart Licensing Utility ships an undocumented static administrative account (CWE-798 / CWE-912) whose credentials (cslu-windows-client:Library4C$LU) are hardcoded in the binary', its REST API 'listens on TCP/8182' when running, and 'an unauthenticated, remote attacker who reaches the host over the network can present the static Basic-auth credentials to authenticate as administrator with no prior access', yielding 'full administrative control over the CSLU application API'. Affected range given as 2.0.0-2.2.0. CVSS 9.8, RWEP 70, poc_available true.",
+        "evidence": "Cisco Smart Licensing Utility ships an undocumented static administrative account (CWE-798 / CWE-912) whose credentials (cslu-windows-client:Library4C$LU) are hardcoded in the binary. Its REST API listens on TCP/8182 when it is running, and an unauthenticated, remote attacker who reaches the host over the network can present the static Basic-auth credentials to authenticate as administrator with no prior access, yielding full administrative control over the CSLU application API. The affected range is given as 2.0.0-2.2.0. It has a CVSS score of 9.8 and an RWEP score of 70, and a proof-of-concept exploit is available.",
         "gap_closes": [
           "UK-CAF-B4",
           "ISO-27001-2022-A.8.8"
@@ -35812,7 +35812,7 @@
         "id": "NEW-CTRL-018",
         "name": "SCANNER-PAPER-COMPLIANCE-TEST",
         "description": "CSLU only listens while actively invoked, which makes this vulnerability structurally invisible to the two techniques most estates rely on for evidence: a network scan of TCP/8182 finds the port closed whenever the utility happens not to be running, and a service inventory finds nothing listening to attribute a version to. For this CVE the operational test has to be installed-software inventory across the Windows estate — does any host carry a Smart Licensing Utility build in the 2.0.0-2.2.0 range, regardless of whether the service answered at scan time — because that, not port reachability, is the condition the packet ties exposure to. The distinguishing test is to scan a staging host with an affected CSLU installed but not currently invoked, and confirm the tooling still reports it as affected; a scanner that returns clean because nothing answered on 8182 has measured the sampling moment rather than the exposure, and every subsequent invocation of the utility reopens an unauthenticated administrative API with a credential published in the advisory.",
-        "evidence": "Packet vector: 'Because CSLU only listens while actively invoked, exposure is intermittent, but any reachable, running 2.0.0-2.2.0 instance is trivially compromisable', with the REST API on TCP/8182 reachable by an unauthenticated remote attacker while the service runs. cisa_kev true, kev_date 2025-03-31, active_exploitation 'confirmed'.",
+        "evidence": "Because CSLU only listens while actively invoked, exposure is intermittent, but any reachable, running 2.0.0-2.2.0 instance is trivially compromisable, with the REST API on TCP/8182 reachable by an unauthenticated remote attacker while the service runs. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-31, and active exploitation is confirmed.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIS2-Art21-vulnerability-management",
@@ -35823,7 +35823,7 @@
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
         "description": "KEV listing on 2025-03-31 with confirmed exploitation, a public PoC and unauthenticated administrative access at CVSS 9.8 puts this above any routine patch cadence, and there is no live-patch path, so the mitigation that satisfies the clock is either upgrading past the affected 2.0.0-2.2.0 range or removing/stopping the utility on hosts that do not need it. For this CVE the SLA should treat 'CSLU not installed' as a first-class satisfying outcome rather than only counting upgrades, because Smart Licensing Utility is a support tool rather than a production dependency on most of the hosts that carry it, and uninstalling is faster than scheduling a software update across a Windows estate. The distinguishing test is whether the KEV record for this CVE resolves every affected host to upgraded, uninstalled, or explicitly risk-accepted at the deadline; an SLA measured only on upgrade completion will show hosts as pending indefinitely while an unauthenticated caller with the published credential can take administrative control of the API the next time the utility runs.",
-        "evidence": "cisa_kev true, kev_date 2025-03-31, active_exploitation 'confirmed'. CVSS 9.8, RWEP 70, poc_available true. patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Packet vector states the attacker gains 'full administrative control over the CSLU application API', which is chained with CVE-2024-20440 to harvest further credentials and tokens.",
+        "evidence": "CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-31, and active exploitation is confirmed. It has a CVSS score of 9.8 and an RWEP score of 70, and a proof-of-concept exploit is available. A fixed release is available. There is no live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands. The attacker gains full administrative control over the CSLU application API, which is chained with CVE-2024-20440 to harvest further credentials and tokens.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "AU-Essential-8-Patch",
@@ -35890,8 +35890,8 @@
       {
         "id": "NEW-CTRL-057",
         "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
-        "description": "The packet's delivery is a spear-phished link to an attacker-controlled page, so every Chrome/Chromium install in the estate is in scope the moment a user can open a link — there is no server-side surface to isolate, and the packet names no configuration-side mitigation, recording remediation as the vendor update plus the named compensating controls until it lands. For this CVE the control means the managed update ring for Chrome/Chromium carries no deferral: the fixed build is driven out on the KEV clock that opened 2025-03-27 rather than held for a ring's soak period, and completion is measured by the build the browser is actually running on each host, not by the update being approved or downloaded in the management console, because the packet registers no live-patch path. Enumerate the Windows population first — the packet's primitive is the Windows sentinel handle (the -2 pseudo-handle) being supplied and used without validation while the broker duplicates handles across the renderer-to-broker boundary. Precondition, and it is the important one on this entry: the update removes the escape primitive, it does not evict an attacker who already used it. The packet has ForumTroll operators staging the Dante spyware loader through this chain into the medium-integrity browser/broker context with no user interaction beyond opening the link, so a host whose user opened the lure during the exposure window needs host-level triage; updating that host closes the door behind whatever is already inside it, and an estate that reports 100% on the fixed build has evidence about the primitive, not about residency.",
-        "evidence": "Packet: CWE-501 sandbox escape in Chrome/Chromium on Windows. 'A victim ... visits an attacker-controlled page (delivered via spear-phishing), giving the compromised renderer a reachable path to the Mojo IPC layer. A logic error causes an incorrect/sentinel OS handle (the -2 pseudo-handle) to be supplied and used without validation when the broker process duplicates handles across the renderer-to-broker boundary ... escalates the constrained, sandboxed renderer to arbitrary code execution in the medium-integrity browser/broker context, from which the ForumTroll operators staged the Dante spyware loader — all with no user interaction beyond opening the link.' CISA KEV 2025-03-27, active_exploitation confirmed, CVSS 8.3, RWEP 56, poc_available false. patch_available true, live_patch_available false; live-patch note: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Cited gaps include AU-Essential-8-Patch, NIST-800-53-SI-2, ISO-27001-2022-A.8.8 and UK-CAF-B4.",
+        "description": "Delivery is a spear-phished link to an attacker-controlled page, so every Chrome/Chromium install in the estate is in scope the moment a user can open a link. There is no server-side surface to isolate, and this entry names no configuration-side mitigation; remediation is the vendor update plus the named compensating controls until it lands. For this CVE the control means the managed update ring for Chrome/Chromium carries no deferral: the fixed build is driven out on the KEV clock that opened 2025-03-27 rather than held for a ring's soak period, and completion is measured by the build the browser is actually running on each host, not by the update being approved or downloaded in the management console, because no live-patch path is available. Enumerate the Windows population first, because the primitive is the Windows sentinel handle (the -2 pseudo-handle) being supplied and used without validation while the broker duplicates handles across the renderer-to-broker boundary. Precondition, and it is the important one on this entry: the update removes the escape primitive; it does not evict an attacker who already used it. ForumTroll operators staged the Dante spyware loader through this chain into the medium-integrity browser/broker context with no user interaction beyond opening the link, so a host whose user opened the lure during the exposure window needs host-level triage. Updating that host closes the door behind whatever is already inside it, and an estate that reports 100% on the fixed build has evidence about the primitive, not about residency.",
+        "evidence": "The flaw is a CWE-501 sandbox escape in Chrome/Chromium on Windows. A victim visits an attacker-controlled page (delivered via spear-phishing), giving the compromised renderer a reachable path to the Mojo IPC layer. A logic error causes an incorrect/sentinel OS handle (the -2 pseudo-handle) to be supplied and used without validation when the broker process duplicates handles across the renderer-to-broker boundary. The chain escalates the constrained, sandboxed renderer to arbitrary code execution in the medium-integrity browser/broker context, from which the ForumTroll operators staged the Dante spyware loader, all with no user interaction beyond opening the link. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-27, and active exploitation is confirmed. It has a CVSS score of 8.3 and an RWEP score of 56, and no proof-of-concept exploit is available. A fixed release is available. There is no live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands. Cited gaps include AU-Essential-8-Patch, NIST-800-53-SI-2, ISO-27001-2022-A.8.8 and UK-CAF-B4.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "NIST-800-53-SI-2",
@@ -35902,8 +35902,8 @@
       {
         "id": "NEW-CTRL-038",
         "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
-        "description": "The packet's remediation note defines the interval this control governs in its own words — remediation is the vendor update plus the named compensating controls until it lands, with no live-patch path for this product class. On this entry that interval is unusually exposed, because the trigger is a user opening a link and the chain completes with no user interaction beyond that: a Chrome/Chromium host waiting on the fixed build is not carrying a reduced-probability version of the risk, it is carrying the full one behind measures that never touch the Mojo handle-duplication path. The requirement here is that such a host be recorded as a distinct, time-bound compensating-control state with an owner and a date — not folded into a 'patched per SLA' percentage — and that the evidence for the remediated state be the build the browser is actually running, since a console reporting the update approved, downloaded or pushed is reporting a deployment step rather than a remediation. Precondition: this control is bookkeeping. It makes the exposure visible and removes none of it, and it is worth attaching precisely because this exposure is the one most likely to be closed on paper: CVSS 8.3 on a browser reads as endpoint hygiene, while in-the-wild exploitation is confirmed, delivering a spyware loader. It also says nothing about a host that was already exploited during the window — that host belongs on the incident path regardless of which state the register shows.",
-        "evidence": "Packet: live_patch_available false with the note 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands'; patch_available true. Exploitation requires only that the victim open the attacker-controlled page — 'no user interaction beyond opening the link' — with active_exploitation confirmed and a CISA KEV listing of 2025-03-27. CVSS 8.3 against RWEP 56; poc_available false. Cited gaps include ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling).",
+        "description": "The interval this control governs is the one in which remediation is the vendor update plus the named compensating controls until it lands, with no live-patch path for this product class. On this entry that interval is unusually exposed, because the trigger is a user opening a link and the chain completes with no user interaction beyond that: a Chrome/Chromium host waiting on the fixed build is not carrying a reduced-probability version of the risk; it is carrying the full one behind measures that never touch the Mojo handle-duplication path. The requirement here is that such a host be recorded as a distinct, time-bound compensating-control state with an owner and a date, rather than folded into a 'patched per SLA' percentage, and that the evidence for the remediated state be the build the browser is actually running, since a console reporting the update approved, downloaded or pushed is reporting a deployment step rather than a remediation. Precondition: this control is bookkeeping. It makes the exposure visible and removes none of it, and it is worth attaching precisely because this exposure is the one most likely to be closed on paper: CVSS 8.3 on a browser reads as endpoint hygiene, while in-the-wild exploitation is confirmed, delivering a spyware loader. It also says nothing about a host that was already exploited during the window. That host belongs on the incident path regardless of which state the register shows.",
+        "evidence": "There is no live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands. A fixed release is available. Exploitation requires only that the victim open the attacker-controlled page, with no user interaction beyond opening the link. Active exploitation is confirmed, and CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-27. It has a CVSS score of 8.3 against an RWEP score of 56, and no proof-of-concept exploit is available. Cited gaps include ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling).",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIS2-Art21-vulnerability-management"
@@ -35969,8 +35969,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "Sitecore CMS and Experience Platform (XP) is a content-management web tier, and the packet's path into it is one HTTP POST: a ysoserial.net TypeConfuseDelegate gadget supplied as the __CSRFTOKEN parameter to any page the Sitecore.Security.AntiCsrf module guards, executing inside ObjectStateFormatter before the module ever compares that value to __CSRFCOOKIE. With a public PoC and confirmed exploitation there is no attack complexity buying time, so the clock runs from the 2025-03-26 KEV listing rather than from the next CMS release train. There is a vendor patch with no live-patch path, and until it lands the remaining measures are this entry's named compensating controls — so remediation means getting every Sitecore instance onto the vendor's fixed build, with completion measured by reading the running build off each instance rather than from a deployment ticket. Two preconditions bound what meeting this SLA actually buys. First, this is the 9.x post-authentication variant: exploitation requires a valid authenticated session, so restricting who can reach the CMS narrows the caller population during the window before the fix but closes nothing against anyone already holding a Sitecore credential, including a low-privilege content account — network restriction is a holding measure, not a substitute for the build. Second, an SLA met from the listing forward settles nothing about instances that were already reachable on an affected build, and the packet's chain ends in a reverse shell, which is a triage question rather than a patching one.",
-        "evidence": "Packet fields for CVE-2019-9875 ('Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (post-authentication)'): cwe_refs CWE-502; cisa_kev true; kev_date 2025-03-26; active_exploitation 'confirmed'; cvss 8.8; rwep_score 68; poc_available true; patch_available true; live_patch_available false; live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'; ai_discovered false. Packet attack_vector: the Sitecore.Security.AntiCsrf module 'deserializes the attacker-supplied __CSRFTOKEN HTTP POST parameter via ASP.NET's ObjectStateFormatter BEFORE comparing it to the __CSRFCOOKIE value', the formatter 'is instantiated with a null _page' so 'it performs no MAC/signature validation on the LOSFormatter stream', an attacker 'supplies a ysoserial.net TypeConfuseDelegate gadget encoded for the ObjectStateFormatter', and 'For the 9.x branch this CVE requires a valid authenticated session (PR:L)'. Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8 'Management of technical vulnerabilities', UK NCSC CAF B4 'System security'.",
+        "description": "Sitecore CMS and Experience Platform (XP) is a content-management web tier, and the attack path into it is one HTTP POST: a ysoserial.net TypeConfuseDelegate gadget supplied as the __CSRFTOKEN parameter to any page the Sitecore.Security.AntiCsrf module guards, executing inside ObjectStateFormatter before the module ever compares that value to __CSRFCOOKIE. With a public PoC and confirmed exploitation there is no attack complexity buying time, so the clock runs from the 2025-03-26 KEV listing rather than from the next CMS release train. There is a vendor patch with no live-patch path, and until it lands the remaining measures are this entry's named compensating controls, so remediation means getting every Sitecore instance onto the vendor's fixed build, with completion measured by reading the running build off each instance rather than from a deployment ticket. Two preconditions bound what meeting this SLA actually buys. First, this is the 9.x post-authentication variant: exploitation requires a valid authenticated session, so restricting who can reach the CMS narrows the caller population during the window before the fix but closes nothing against anyone already holding a Sitecore credential, including a low-privilege content account. Network restriction is a holding measure, not a substitute for the build. Second, an SLA met from the listing forward settles nothing about instances that were already reachable on an affected build, and the exploitation chain ends in a reverse shell, which is a triage question rather than a patching one.",
+        "evidence": "CVE-2019-9875 (Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (post-authentication)) is classified as CWE-502. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-26. Active exploitation is confirmed, it has a CVSS score of 8.8 and an RWEP score of 68, and a proof of concept is available. A fixed release is available. There is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands. The vulnerability was not AI-discovered. The Sitecore.Security.AntiCsrf module deserializes the attacker-supplied __CSRFTOKEN HTTP POST parameter via ASP.NET's ObjectStateFormatter before comparing it to the __CSRFCOOKIE value. The formatter is instantiated with a null _page, so it performs no MAC/signature validation on the LOSFormatter stream. An attacker supplies a ysoserial.net TypeConfuseDelegate gadget encoded for the ObjectStateFormatter, and for the 9.x branch this CVE requires a valid authenticated session (PR:L). This entry cites ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8 'Management of technical vulnerabilities' and UK NCSC CAF B4 'System security' as insufficient.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -35980,8 +35980,8 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "The packet's path does not stop at deserialization: code runs in-process as the IIS application-pool identity, the gadget's PowerShell stager pulls a second stage and opens a reverse shell, giving arbitrary command execution on the web server and access to the underlying filesystem. Sitecore is an application tier rather than an appliance, but it occupies the position this control governs, and with exploitation confirmed a Sitecore instance that was reachable by a credential holder on an affected build during the exposure window is a triage subject rather than a patch ticket. The vendor build removes the deserialization sink and removes nothing the second stage wrote, and it revokes nothing the application-pool identity could read — connection strings and configuration secrets held by that instance stay valid across the upgrade. The requirement for this CVE is therefore: export configuration and content for review, rebuild the web tier from a known-good image on the fixed build instead of upgrading the live instance, and rotate every secret reachable from the application-pool identity. The packet supplies one triage anchor directly, and it is the one most likely to be misread: because the gadget executes 'regardless of the subsequent cookie-mismatch error', a successful exploitation leaves a CSRF cookie-versus-parameter mismatch entry in the application's own logs — a line that reads as the security control working, written after the code has already run. Precondition and honest limit: the end state is a reverse shell, with no implant, tooling or artifact named, so the trigger for this runbook is reachability during the window, not an observed indicator; and if the triage is deferred, a later rebuild taken from a baseline captured after the exposure reproduces whatever was written rather than removing it.",
-        "evidence": "Packet attack_vector for CVE-2019-9875: the gadget 'executes during deserialization regardless of the subsequent cookie-mismatch error'; 'code runs in-process as the IIS app-pool identity, after which the gadget's PowerShell stager pulls a second stage and opens a reverse shell, giving arbitrary command execution on the web server and access to the underlying filesystem'; an attacker must 'reach a guarded Sitecore endpoint (e.g. CreateNewUser.aspx)'. active_exploitation 'confirmed'; cisa_kev true with kev_date 2025-03-26; poc_available true; patch_available true — the fix exists, which is what makes 'patched' the compliance verdict this control has to override; live_patch_available false. Cited as insufficient on this entry: NIST SP 800-53 Rev 5 SI-2 'Flaw Remediation' and EU NIS2 Directive (2022/2555) 'Vulnerability handling'.",
+        "description": "The attack path does not stop at deserialization: code runs in-process as the IIS application-pool identity, the gadget's PowerShell stager pulls a second stage and opens a reverse shell, giving arbitrary command execution on the web server and access to the underlying filesystem. Sitecore is an application tier rather than an appliance, but it occupies the position this control governs, and with exploitation confirmed a Sitecore instance that was reachable by a credential holder on an affected build during the exposure window is a triage subject rather than a patch ticket. The vendor build removes the deserialization sink and removes nothing the second stage wrote, and it revokes nothing the application-pool identity could read: connection strings and configuration secrets held by that instance stay valid across the upgrade. The requirement for this CVE is therefore: export configuration and content for review, rebuild the web tier from a known-good image on the fixed build instead of upgrading the live instance, and rotate every secret reachable from the application-pool identity. The exploitation mechanics supply one triage anchor directly, and it is the one most likely to be misread: because the gadget executes regardless of the subsequent cookie-mismatch error, a successful exploitation leaves a CSRF cookie-versus-parameter mismatch entry in the application's own logs, a line that reads as the security control working, written after the code has already run. Precondition and honest limit: the end state is a reverse shell, with no implant, tooling or artifact named, so the trigger for this runbook is reachability during the window, not an observed indicator; and if the triage is deferred, a later rebuild taken from a baseline captured after the exposure reproduces whatever was written rather than removing it.",
+        "evidence": "For CVE-2019-9875, the gadget executes during deserialization regardless of the subsequent cookie-mismatch error. Code runs in-process as the IIS app-pool identity, after which the gadget's PowerShell stager pulls a second stage and opens a reverse shell, giving arbitrary command execution on the web server and access to the underlying filesystem. An attacker must reach a guarded Sitecore endpoint (e.g. CreateNewUser.aspx). Active exploitation is confirmed, CISA added CVE-2019-9875 to its Known Exploited Vulnerabilities catalog on 2025-03-26, and a proof of concept is available. A fixed release is available; the fix exists, which is what makes 'patched' the compliance verdict this control has to override. No live patch is available. This entry cites NIST SP 800-53 Rev 5 SI-2 'Flaw Remediation' and EU NIS2 Directive (2022/2555) 'Vulnerability handling' as insufficient.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "NIS2-Art21-vulnerability-management"
@@ -36048,7 +36048,7 @@
         "id": "NEW-CTRL-125",
         "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
         "description": "For Sitecore the trust boundary is inside the AntiCSRF module's own request handling: the packet has Sitecore.Security.AntiCSRF taking the value of the __CSRFTOKEN HTTP POST parameter and deserializing it with .NET BinaryFormatter without type restriction, and on affected 8.x and earlier builds doing so before authentication is enforced — so an anonymous request rebuilds an arbitrary object graph in the IIS worker process. Two properties have to hold for this product. The parameter is a CSRF token, so what arrives in it must be constrained to the concrete, primitive shape that flow legitimately carries and must never be permitted to instantiate types the module does not need — an unrestricted formatter is not a deserializer with a weak filter, it is no filter at all, which is why a published gadget chain is sufficient. And the authentication decision must precede the deserialization, because ordering is the second half of the defect: reversing it removes the anonymous reach even where the sink remains. Both are properties the vendor update establishes; this control states what to verify, it does not implement it. Precondition, and this is where the control is normally over-claimed: its network-restriction half is largely unavailable here. The sink is reachable 'on any AntiCSRF-protected page', so binding the surface to a management segment only helps an instance whose AntiCSRF-protected pages are all administrative — where such a page is part of the publicly served site, no segmentation removes the path and the update is the only closure. Constraining the IIS application-pool identity's rights and what it can reach bounds what a successful gadget chain does next, but it does not stop the deserialization, and the outcome is command execution in that identity's context with no separate privilege-escalation step needed.",
-        "evidence": "Packet: 'Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (unauthenticated)', CWE-502. Vector: 'The Sitecore.Security.AntiCSRF module accepts the value of the HTTP POST parameter __CSRFTOKEN and deserializes it with .NET BinaryFormatter without type restriction, reachable over the network on any AntiCSRF-protected page. On affected 8.x and earlier builds the deserialization occurs before authentication is enforced, so an unauthenticated remote attacker (CVSS 9.8, AV:N/PR:N) can submit a crafted serialized object... arbitrary command execution in the context of the IIS application pool identity hosting Sitecore, yielding full server compromise without needing a separate privilege-escalation step.' CISA KEV-listed 2025-03-26; active_exploitation 'confirmed'; cvss 9.8; rwep_score 68; poc_available true; patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "evidence": "CVE-2019-9874 (Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (unauthenticated)) is classified as CWE-502. The Sitecore.Security.AntiCSRF module accepts the value of the HTTP POST parameter __CSRFTOKEN and deserializes it with .NET BinaryFormatter without type restriction, reachable over the network on any AntiCSRF-protected page. On affected 8.x and earlier builds the deserialization occurs before authentication is enforced, so an unauthenticated remote attacker (CVSS 9.8, AV:N/PR:N) can submit a crafted serialized object. The result is arbitrary command execution in the context of the IIS application pool identity hosting Sitecore, yielding full server compromise without needing a separate privilege-escalation step. CISA added CVE-2019-9874 to its Known Exploited Vulnerabilities catalog on 2025-03-26. Active exploitation is confirmed, it has a CVSS score of 9.8 and an RWEP score of 68, and a proof of concept is available. A fixed release is available. There is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "UK-CAF-B4"
@@ -36058,7 +36058,7 @@
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
         "description": "A Sitecore instance that served AntiCSRF-protected pages to an untrusted network on an affected 8.x-or-earlier build has to be dispositioned as compromised rather than upgraded in place. Two facts from the packet make patch-in-place the wrong default. First, the deserialization occurs before authentication is enforced, so a successful exploit generates no authentication event to find afterwards — the site's login records will look clean for the intrusion. Second, the outcome is arbitrary command execution as the IIS application-pool identity with access to the underlying filesystem, and an .aspx web shell or scheduled task placed through that primitive survives the vendor upgrade untouched and keeps answering after it. The response default is therefore to treat the deployed web root and every writable media and upload directory as attacker-modifiable: diff the live tree against the known-good deployment artefact, rebuild the server from source of truth at the fixed version instead of upgrading in place, and rotate what the box held — the application-pool and service accounts, the Sitecore administrator accounts, the database connection strings in the instance configuration, and any key or certificate material stored on it. The distinguishing test is whether the remediation record carries a file-integrity comparison of the deployed tree alongside the version change; an upgrade ticket on its own cannot show that a file written through this path was removed, and a version scan reporting the fixed build is exactly the evidence that passes while an implant stays resident. Scope the exposure window honestly: the packet pairs a public PoC and confirmed exploitation with a 2019 CVE identifier carried into a 2025 KEV listing, so an instance left on an affected build was reachable across that whole interval — 'we upgraded when it reached KEV' bounds the remediation date, not the intrusion window.",
-        "evidence": "Packet: unauthenticated CWE-502 deserialization where 'the deserialization occurs before authentication is enforced', giving 'arbitrary command execution in the context of the IIS application pool identity hosting Sitecore, yielding full server compromise without needing a separate privilege-escalation step', with the 9.x-branch companion entry noting access to the underlying filesystem. active_exploitation 'confirmed'; poc_available true; CISA KEV-listed 2025-03-26 against a CVE identifier dated 2019; cvss 9.8; rwep_score 68; patch_available true, and live_patch_available false — remediation is the vendor update, which is precisely the patch-in-place action this control constrains.",
+        "evidence": "CVE-2019-9874 is an unauthenticated CWE-502 deserialization in which the deserialization occurs before authentication is enforced, giving arbitrary command execution in the context of the IIS application pool identity hosting Sitecore and yielding full server compromise without needing a separate privilege-escalation step. The 9.x-branch companion entry notes access to the underlying filesystem. Active exploitation is confirmed and a proof of concept is available. CISA added CVE-2019-9874, a CVE identifier dated 2019, to its Known Exploited Vulnerabilities catalog on 2025-03-26. It has a CVSS score of 9.8 and an RWEP score of 68. A fixed release is available and no live patch is available: remediation is the vendor update, which is precisely the patch-in-place action this control constrains.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "NIST-800-53-SI-2",
@@ -36069,7 +36069,7 @@
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
         "description": "This entry is the case where a cadence-driven vulnerability programme has no event to fire on at all: the vendor fix long predates the listing, so nothing in a monthly or quarterly cycle distinguishes this from any other aged advisory, and the 2025-03-26 KEV listing is the only trigger that reflects the real risk state. The requirement for this product is that Sitecore instances on affected 8.x-and-earlier builds move to the vendor-fixed release on a clock started by that listing rather than on a CMS-upgrade roadmap, and that the SLA is measured by the instance actually serving requests on the fixed build — not by an approved change ticket or a scheduled upgrade window, which for a major Sitecore version step is where the delay accumulates. Precondition, stated plainly because this is where the SLA is usually reported as met: there is no live-patch path, so there is no in-product interim fix that removes the sink — the compensating controls named on the entry are what hold until the upgrade lands, and where the upgrade cannot be completed inside the clock, the only remaining lever is removing the affected instance's AntiCSRF-protected pages from untrusted network reach. That lever is unavailable for an instance whose AntiCSRF-protected pages are part of the public site, and for those an unmet clock is exposure to an unauthenticated, publicly-exploited pre-auth RCE rather than an accepted risk with a compensating control behind it.",
-        "evidence": "Packet: CISA KEV-listed 2025-03-26 with active_exploitation 'confirmed' and poc_available true on a CVE identifier dated 2019; cvss 9.8, rwep_score 68; privileges required none — 'an unauthenticated remote attacker (CVSS 9.8, AV:N/PR:N) can submit a crafted serialized object'. patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' The entry cites AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management — all cadence-based — as insufficient.",
+        "evidence": "CISA added CVE-2019-9874, a CVE identifier dated 2019, to its Known Exploited Vulnerabilities catalog on 2025-03-26. Active exploitation is confirmed and a proof of concept is available. It has a CVSS score of 9.8 and an RWEP score of 68. No privileges are required: an unauthenticated remote attacker (CVSS 9.8, AV:N/PR:N) can submit a crafted serialized object. A fixed release is available. There is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands. The entry cites AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management, all of which are cadence-based, as insufficient.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -36137,8 +36137,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "SAP NetWeaver AS Java is the population this clock runs against, and for this entry the clock starts late relative to the flaw: original in-the-wild exploitation dates to August 2017 and the CISA listing came only on 2025-03-19 with a 2025-04-09 due date, so an estate treating the KEV listing as first notice is starting years behind an exploited path. Bound to this product, the control means every AS Java 7.5 instance carrying ENGINEAPI 7.50 SP02 through SP05, and every SAP Central Process Scheduling (CPS) by Redwood 8.0 install, is driven to the level set by SAP Note 3476549 on the KEV clock rather than folded into the next SAP maintenance window, with completion measured on the component patch level the running instance reports rather than on a change ticket. The scope has to include the CPS/Redwood installs: the packet names them at all versions under that note, so an inventory built only from 'NetWeaver AS Java' asset names reports clean while the scheduler product carrying the same handler stays exposed. Precondition on remediation: live_patch_available is false and there is no live-patch path for this product class, so the vendor note is the only thing that removes the flaw, and the named compensating controls are all an operator holds until it lands. And because exploitation is confirmed and the packet's escalation is exfiltrating the SAP Secure Store and decrypting the credentials inside it with publicly available tooling, an instance that was reachable during the exposure window is not closed by applying the note — the attacker's subsequent logins to SAP applications use legitimate credentials, leave no exploit artifact, and survive the patch, so credentials held in that Secure Store must be treated as attacker-held and rotated.",
-        "evidence": "Packet: KEV-listed 2025-03-19, due 2025-04-09; active_exploitation confirmed; poc_available true; RWEP 70; CVSS 7.5; patch_available true; live_patch_available false; live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' affected_versions: SAP NetWeaver Application Server (AS) Java 7.5; component ENGINEAPI 7.50 SP02 through SP05; SAP Central Process Scheduling (CPS) by Redwood 8.0 (and all versions per SAP Note 3476549). active_exploitation_notes: per NVD, originally exploited in the wild in August 2017 (SAP Security Note 2486657); Onapsis Research Labs reported renewed active exploitation in 2025, with attackers exfiltrating SAP system files including the SAP Secure Store binary to decrypt stored credentials and pivot into full SAP-application compromise; no public named threat-actor/ransomware attribution.",
+        "description": "SAP NetWeaver AS Java is the population this clock runs against, and for this entry the clock starts late relative to the flaw: original in-the-wild exploitation dates to August 2017 and the CISA listing came only on 2025-03-19 with a 2025-04-09 due date, so an estate treating the KEV listing as first notice is starting years behind an exploited path. Bound to this product, the control means every AS Java 7.5 instance carrying ENGINEAPI 7.50 SP02 through SP05, and every SAP Central Process Scheduling (CPS) by Redwood 8.0 install, is driven to the level set by SAP Note 3476549 on the KEV clock rather than folded into the next SAP maintenance window, with completion measured on the component patch level the running instance reports rather than on a change ticket. The scope has to include the CPS/Redwood installs: they are affected at all versions under that note, so an inventory built only from 'NetWeaver AS Java' asset names reports clean while the scheduler product carrying the same handler stays exposed. Precondition on remediation: no live patch is available and there is no live-patch path for this product class, so the vendor note is the only thing that removes the flaw, and the named compensating controls are all an operator holds until it lands. And because exploitation is confirmed and the escalation path is exfiltrating the SAP Secure Store and decrypting the credentials inside it with publicly available tooling, an instance that was reachable during the exposure window is not closed by applying the note: the attacker's subsequent logins to SAP applications use legitimate credentials, leave no exploit artifact, and survive the patch, so credentials held in that Secure Store must be treated as attacker-held and rotated.",
+        "evidence": "CISA added CVE-2017-12637 to its Known Exploited Vulnerabilities catalog on 2025-03-19 with a due date of 2025-04-09. Active exploitation is confirmed, and a proof of concept is available. The CVE has an RWEP score of 70 and a CVSS score of 7.5. A fixed release is available, but no live patch is available: there is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands. Affected versions are SAP NetWeaver Application Server (AS) Java 7.5; component ENGINEAPI 7.50 SP02 through SP05; and SAP Central Process Scheduling (CPS) by Redwood 8.0 (and all versions per SAP Note 3476549). The flaw was originally exploited in the wild in August 2017 (SAP Security Note 2486657). Onapsis Research Labs reported renewed active exploitation in 2025, with attackers exfiltrating SAP system files including the SAP Secure Store binary to decrypt stored credentials and pivot into full SAP-application compromise. There is no public named threat-actor/ransomware attribution.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "ISO-27001-2022-A.8.8",
@@ -36150,7 +36150,7 @@
         "id": "NEW-CTRL-018",
         "name": "SCANNER-PAPER-COMPLIANCE-TEST",
         "description": "For this entry a version-alone verdict is demonstrably wrong: systems can remain exposed even above the original SAP Note 2486657 patch level, because the flaw was re-addressed by SAP Note 3476549. A scan result or patch register that marks a NetWeaver AS Java instance remediated because its ENGINEAPI component is newer than the 2017 fix is paper compliance; the operational test is whether the running instance sits at the 3476549 level specifically, and whether the SAP Central Process Scheduling by Redwood installs were enumerated at all, since the packet places them in scope at every version under that note. The second half of the test is reachability rather than version, and it is the half a credentialed SAP scan never performs: the vulnerable handler is scheduler/ui/js/ffffffffbca41eb4/UIUtilJavaScriptJS, answering pre-authentication over HTTP, so issue that request with dot-dot traversal in the query string against a staging instance and confirm the path is normalized and the read refused. An authenticated scan of the SAP stack never presents that unauthenticated request and returns nothing about the primitive. Precondition: this control verifies remediation, it does not deliver it — an instance this test finds still exposed needs the vendor note, and nothing in the test reduces its exposure in the meantime.",
-        "evidence": "Packet affected_versions: 'Older/earlier NetWeaver AS Java releases may also be affected; systems can remain exposed even above the original 2486657 patch level (re-addressed by SAP Note 3476549)' and 'SAP Central Process Scheduling (CPS) by Redwood 8.0 (and all versions per SAP Note 3476549)'. Vector: the scheduler/ui/js/ffffffffbca41eb4/UIUtilJavaScriptJS handler in SAP NetWeaver AS Java 7.5 is reachable pre-authentication over HTTP and fails to normalize `..` sequences in its query string, giving an unauthenticated remote attacker arbitrary file read (CWE-22). poc_available true. ISO-27001-2022-A.8.8 gap as recorded: 'appropriate timescales' is undefined for this actively-exploited directory-traversal arbitrary file disclosure.",
+        "evidence": "Older or earlier NetWeaver AS Java releases may also be affected, and systems can remain exposed even above the original 2486657 patch level (re-addressed by SAP Note 3476549). SAP Central Process Scheduling (CPS) by Redwood 8.0 is also affected (and all versions per SAP Note 3476549). The scheduler/ui/js/ffffffffbca41eb4/UIUtilJavaScriptJS handler in SAP NetWeaver AS Java 7.5 is reachable pre-authentication over HTTP and fails to normalize `..` sequences in its query string, giving an unauthenticated remote attacker arbitrary file read (CWE-22). A proof of concept is available. Under ISO-27001-2022-A.8.8, 'appropriate timescales' is undefined for this actively-exploited directory-traversal arbitrary file disclosure.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIST-800-53-SI-2"
@@ -36159,8 +36159,8 @@
       {
         "id": "NEW-CTRL-129",
         "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
-        "description": "SAP NetWeaver AS Java is the enterprise ERP platform this control governs, and the failing surface is one of its management functions: the job-scheduler UI handler answers over HTTP before any authentication decision is taken and returns files selected by the caller's query string. Bound to this deployment, the control means the AS Java scheduler and Central Process Scheduling UI paths make their own authorization decision before serving anything, and that the AS Java HTTP surface carrying them is reachable only from segments with an operational need to reach the scheduler — not from a general user VLAN and not from an untrusted network. What makes this more than a patch-timing issue is where the pre-auth position leads: the packet's escalation is reading the SAP Secure Store and decrypting the credentials in it, after which the attacker's next action is an ordinary authenticated SAP login that no ERP account-model or privilege-scoping attestation distinguishes from a legitimate one. Precondition, and this is where the control is usually over-claimed: the endpoint-side path normalization and the authorization decision are properties the SAP notes establish — this control states what to verify and where to restrict, it does not implement them. Restricting reachability bounds who can send the traversal request but leaves the handler fully exploitable to anything inside the permitted segment, including a compromised workstation or contractor host, and it is unavailable where the scheduler UI must stay reachable by its normal user population.",
-        "evidence": "Packet vector: the handler is reachable pre-authentication over HTTP and fails to normalize `..` sequences; escalation comes from targeting SAP-specific files — chiefly the SAP Secure Store — and decrypting the recovered credentials with publicly available tooling, after which the attacker logs in to SAP applications and pivots to full compromise of the SAP environment despite the flaw itself yielding only confidentiality impact. UK-CAF-B4 gap as recorded: CAF B4 (system security) is treated as met by 'patches applied in a managed cycle', and the managed cycle is itself the gap because SAP NetWeaver was exploited before a normal cycle would have reached it. active_exploitation confirmed; KEV-listed 2025-03-19.",
+        "description": "SAP NetWeaver AS Java is the enterprise ERP platform this control governs, and the failing surface is one of its management functions: the job-scheduler UI handler answers over HTTP before any authentication decision is taken and returns files selected by the caller's query string. Bound to this deployment, the control means the AS Java scheduler and Central Process Scheduling UI paths make their own authorization decision before serving anything, and that the AS Java HTTP surface carrying them is reachable only from segments with an operational need to reach the scheduler, not from a general user VLAN and not from an untrusted network. What makes this more than a patch-timing issue is where the pre-auth position leads: the escalation path is reading the SAP Secure Store and decrypting the credentials in it, after which the attacker's next action is an ordinary authenticated SAP login that no ERP account-model or privilege-scoping attestation distinguishes from a legitimate one. Precondition, and this is where the control is usually over-claimed: the endpoint-side path normalization and the authorization decision are properties the SAP notes establish. This control states what to verify and where to restrict; it does not implement them. Restricting reachability bounds who can send the traversal request but leaves the handler fully exploitable to anything inside the permitted segment, including a compromised workstation or contractor host, and it is unavailable where the scheduler UI must stay reachable by its normal user population.",
+        "evidence": "The handler is reachable pre-authentication over HTTP and fails to normalize `..` sequences. Escalation comes from targeting SAP-specific files, chiefly the SAP Secure Store, and decrypting the recovered credentials with publicly available tooling, after which the attacker logs in to SAP applications and pivots to full compromise of the SAP environment despite the flaw itself yielding only confidentiality impact. Under UK-CAF-B4, CAF B4 (system security) is treated as met by 'patches applied in a managed cycle', and the managed cycle is itself the gap because SAP NetWeaver was exploited before a normal cycle would have reached it. Active exploitation is confirmed, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2025-03-19.",
         "gap_closes": [
           "UK-CAF-B4"
         ]
@@ -36303,8 +36303,8 @@
       {
         "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
-        "description": "This packet leaves no interim state to reach. patch_available is false, and affected_versions records every firmware version of the Edimax IC-7100 as affected with no fixed version existing, because the product is end-of-life / end-of-service and will not receive a security patch; the vector states the same conclusion directly — the only durable remediation is network isolation or hardware replacement. So unlike a device where reaching the fixed build is an interim step, here there is no build any unit can be driven to, and the requirement is an inventory naming every IC-7100 in service with its location and its network reachability, with each unit placed on a dated replacement schedule. A risk acceptance carrying no removal date leaves a KEV-listed camera with a PoC public since June 2023 and confirmed enrollment into DDoS botnets in service indefinitely, which is the outcome this control exists to prevent. Scope the sweep to the model the packet names — the IC-7100 — and widen it only where a verified source identifies another product carrying the same /camera-cgi/admin/param.cgi handling. Precondition on the isolation that bridges the gap until replacement: the injection sits in the camera's own web management interface, so removing internet reachability — typically a router port-forward or a UPnP mapping, which is how these cameras acquire exposure — bounds who can send the request from outside, but the camera exists to be viewed from the network attached to it, and every host on that segment still reaches the CGI. Isolation therefore means placing the camera in a segment that can reach nothing else, not removing the path. And because exploitation is confirmed and the injected command stages and runs an architecture-matched Mirai ELF binary on the device, a unit that was internet-reachable is not returned to service by a configuration change: it is a removal item, and the segment and credentials it sat on belong on the incident path.",
-        "evidence": "Packet fields for CVE-2025-1316 (Edimax IC-7100 IP Camera OS Command Injection Vulnerability): cwe_refs CWE-78; cisa_kev true, kev_date 2025-03-19, active_exploitation confirmed; rwep_score 85, cvss 9.8; poc_available true; patch_available false; live_patch_available false. affected_versions records 'Edimax IC-7100 IP camera — all firmware versions (no fixed version exists; product is end-of-life / end-of-service and will not receive a security patch)'. The vector names the /camera-cgi/admin/param.cgi endpoint of the web management interface, the failure to neutralize OS shell metacharacters in the NTP_serverName field of the ipcamSource option, cameras commonly internet-exposed, an injected command that downloads a curl.sh/wget.sh stager pulling architecture-matched Mirai ELF payloads into a world-writable directory and running them to enroll the camera into a DDoS botnet, and states that because the device is end-of-life with no patch the only durable remediation is network isolation or hardware replacement. active_exploitation_notes record a public PoC available since June 2023 and Akamai SIRT honeypot activity from May 2024.",
+        "description": "This CVE leaves no interim state to reach. No fixed release is available, and every firmware version of the Edimax IC-7100 is affected with no fixed version existing, because the product is end-of-life / end-of-service and will not receive a security patch. The only durable remediation is network isolation or hardware replacement. So unlike a device where reaching the fixed build is an interim step, here there is no build any unit can be driven to, and the requirement is an inventory naming every IC-7100 in service with its location and its network reachability, with each unit placed on a dated replacement schedule. A risk acceptance carrying no removal date leaves a KEV-listed camera with a PoC public since June 2023 and confirmed enrollment into DDoS botnets in service indefinitely, which is the outcome this control exists to prevent. Scope the sweep to the affected model, the IC-7100, and widen it only where a verified source identifies another product carrying the same /camera-cgi/admin/param.cgi handling. Precondition on the isolation that bridges the gap until replacement: the injection sits in the camera's own web management interface, so removing internet reachability (typically a router port-forward or a UPnP mapping, which is how these cameras acquire exposure) bounds who can send the request from outside, but the camera exists to be viewed from the network attached to it, and every host on that segment still reaches the CGI. Isolation therefore means placing the camera in a segment that can reach nothing else, not removing the path. And because exploitation is confirmed and the injected command stages and runs an architecture-matched Mirai ELF binary on the device, a unit that was internet-reachable is not returned to service by a configuration change: it is a removal item, and the segment and credentials it sat on belong on the incident path.",
+        "evidence": "CVE-2025-1316 (Edimax IC-7100 IP Camera OS Command Injection Vulnerability) is a CWE-78 weakness. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-19, and active exploitation is confirmed. It has an RWEP score of 85 and a CVSS score of 9.8. A proof of concept is available. No fixed release is available, and no live patch is available. All firmware versions of the Edimax IC-7100 IP camera are affected: no fixed version exists, and the product is end-of-life / end-of-service and will not receive a security patch. The flaw is in the /camera-cgi/admin/param.cgi endpoint of the web management interface, which fails to neutralize OS shell metacharacters in the NTP_serverName field of the ipcamSource option. The cameras are commonly internet-exposed. The injected command downloads a curl.sh/wget.sh stager that pulls architecture-matched Mirai ELF payloads into a world-writable directory and runs them to enroll the camera into a DDoS botnet. Because the device is end-of-life with no patch, the only durable remediation is network isolation or hardware replacement. A public PoC has been available since June 2023, and Akamai SIRT honeypot activity dates from May 2024.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -36314,8 +36314,8 @@
       {
         "id": "NEW-CTRL-118",
         "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
-        "description": "This entry's own citing gaps place the camera inside a zone-and-conduit model — IEC 62443-3-3 segmentation as the compensating control, and NIST SP 800-82r3 treating the device as a trusted endpoint inside a segmented cell — so both halves of this control have purchase here, but they carry different weight. The credential half is a lever the operator genuinely holds, unlike cases where the key is discoverable from the vendor's own software: the packet names unchanged default credentials admin:1234 as the route by which attackers commonly reach /camera-cgi/admin/param.cgi, so every IC-7100 in service should have that vendor default rotated. It must not be recorded as closing the path, because this entry's framework gaps describe the flaw as an unauthenticated OS command injection — rotating the password removes the commonly-observed access route without demonstrating that the endpoint requires a credential at all. The segmentation half is therefore load-bearing. Applied to this camera it means the IC-7100's web management interface answers only from the operator segment that legitimately views and administers it, not from the internet through a port-forward or UPnP mapping and not from a general user VLAN, and that the camera's outbound path is constrained as well — the packet's exploitation path is outbound by design, since the injected command fetches a curl.sh/wget.sh stager, pulls architecture-matched Mirai ELF payloads, and then beacons to C2 (angela.spklove.com:3093 for the strain Akamai labels 'Unstable Mirai'; merisprivate.net / ziparchive.xyz for the second, anti-debugging variant). An egress policy permitting the camera only the destinations its operation requires — including the NTP server named by the very field that carries the injection — breaks the stager fetch and the beacon. Distinguishing test: from a general user VLAN and from an external address, request /camera-cgi/admin/param.cgi on an IC-7100; anything that answers is within reach of a PoC public since June 2023, and 'the cameras are on the internal network' is a statement about topology rather than a demonstration that the CGI is unreachable. Preconditions: segmentation bounds who can send the request and egress control bounds what an injected command can retrieve; neither repairs the missing metacharacter neutralization, and any compromised host inside the permitted segment reaches the CGI in full. Because patch_available is false these are permanent compensating measures rather than a holding action before a fix, which is why the dated replacement schedule has to run alongside them.",
-        "evidence": "Packet fields for CVE-2025-1316: the vector states that an attacker who reaches /camera-cgi/admin/param.cgi — commonly via unchanged default credentials admin:1234, often on internet-exposed cameras — injects a shell command string executed as the CGI's privileged context, and that in observed campaigns the injected command downloads a curl.sh/wget.sh stager pulling architecture-matched Mirai ELF payloads into a world-writable directory. The endpoint's vulnerable field is NTP_serverName of the ipcamSource option. active_exploitation_notes name the Akamai-labelled 'Unstable Mirai' strain beaconing to angela.spklove.com:3093 and a second anti-debugging variant using merisprivate.net / ziparchive.xyz C2, with a public PoC since June 2023. Cited gaps: IEC-62443-3-3 ('zone-and-conduit segmentation is the compensating control, but an internet-reachable device ... bridges the IT and OT zones it is supposed to keep apart'), NIST-800-82r3 ('treats the device as a trusted endpoint inside a segmented cell; compromise ... turns it into an OT pivot'), NIS2-Art21-network-security ('perimeter and segmentation controls that assume the appliance is trustworthy'). patch_available is false and affected_versions records no fixed version because the product is end-of-life.",
+        "description": "This entry's framework gaps place the camera inside a zone-and-conduit model (IEC 62443-3-3 segmentation as the compensating control, and NIST SP 800-82r3 treating the device as a trusted endpoint inside a segmented cell), so both halves of this control have purchase here, but they carry different weight. The credential half is a lever the operator genuinely holds, unlike cases where the key is discoverable from the vendor's own software: unchanged default credentials admin:1234 are the route by which attackers commonly reach /camera-cgi/admin/param.cgi, so every IC-7100 in service should have that vendor default rotated. It must not be recorded as closing the path, because this entry's framework gaps describe the flaw as an unauthenticated OS command injection. Rotating the password removes the commonly-observed access route without demonstrating that the endpoint requires a credential at all. The segmentation half is therefore load-bearing. Applied to this camera it means the IC-7100's web management interface answers only from the operator segment that legitimately views and administers it, not from the internet through a port-forward or UPnP mapping and not from a general user VLAN, and that the camera's outbound path is constrained as well. The exploitation path is outbound by design, since the injected command fetches a curl.sh/wget.sh stager, pulls architecture-matched Mirai ELF payloads, and then beacons to C2 (angela.spklove.com:3093 for the strain Akamai labels 'Unstable Mirai'; merisprivate.net / ziparchive.xyz for the second, anti-debugging variant). An egress policy permitting the camera only the destinations its operation requires, including the NTP server named by the very field that carries the injection, breaks the stager fetch and the beacon. Distinguishing test: from a general user VLAN and from an external address, request /camera-cgi/admin/param.cgi on an IC-7100; anything that answers is within reach of a PoC public since June 2023, and 'the cameras are on the internal network' is a statement about topology rather than a demonstration that the CGI is unreachable. Preconditions: segmentation bounds who can send the request and egress control bounds what an injected command can retrieve; neither repairs the missing metacharacter neutralization, and any compromised host inside the permitted segment reaches the CGI in full. Because no fixed release is available, these are permanent compensating measures rather than a holding action before a fix, which is why the dated replacement schedule has to run alongside them.",
+        "evidence": "For CVE-2025-1316, an attacker who reaches /camera-cgi/admin/param.cgi (commonly via unchanged default credentials admin:1234, often on internet-exposed cameras) injects a shell command string executed as the CGI's privileged context, and in observed campaigns the injected command downloads a curl.sh/wget.sh stager pulling architecture-matched Mirai ELF payloads into a world-writable directory. The endpoint's vulnerable field is NTP_serverName of the ipcamSource option. Active exploitation involves the Akamai-labeled 'Unstable Mirai' strain beaconing to angela.spklove.com:3093 and a second anti-debugging variant using merisprivate.net / ziparchive.xyz C2, and a public PoC has been available since June 2023. The framework gaps are IEC-62443-3-3 ('zone-and-conduit segmentation is the compensating control, but an internet-reachable device ... bridges the IT and OT zones it is supposed to keep apart'), NIST-800-82r3 ('treats the device as a trusted endpoint inside a segmented cell; compromise ... turns it into an OT pivot'), and NIS2-Art21-network-security ('perimeter and segmentation controls that assume the appliance is trustworthy'). No fixed release is available, and no fixed version exists because the product is end-of-life.",
         "gap_closes": [
           "IEC-62443-3-3",
           "NIST-800-82r3",
@@ -36325,8 +36325,8 @@
       {
         "id": "NEW-CTRL-038",
         "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
-        "description": "This control's three-state distinction is what an IC-7100 estate needs, because the first state — binary patch deployed, vulnerability eliminated — is unreachable for this CVE and always will be: patch_available is false, every firmware version is affected, and affected_versions records that no fixed version exists because the product is end-of-life and will not receive a security patch. A camera whose management CGI has been isolated therefore sits permanently in the compensating-control state, and the audit record must show it as that, with the dated replacement action attached, rather than as remediated or as a closed flaw-remediation ticket. The failure this prevents is specific to a device with no patch path: a vulnerability-management report keyed on patched-versus-unpatched has no true state to move an IC-7100 into, so the finding either stays open forever and is eventually suppressed as stale noise, or it is closed on the isolation change — at which point the camera leaves the estate's exposure view while still running a CGI with a PoC public since June 2023 and confirmed exploitation into Mirai botnets. The same record must also distinguish the isolated units from the third state the control names, full exposure, since the packet's exploitation set is internet-reachable cameras and an unisolated unit is in that state today. Precondition: this is a reporting requirement, not a mitigation. It changes nothing on the device, and it is only meaningful if the compensating-control entry carries the removal date — an isolation record with no expiry is the same permanent open exposure written in different words, which is exactly the outcome a KEV due date of 2025-04-09 was meant to force.",
-        "evidence": "Packet fields for CVE-2025-1316: patch_available false; live_patch_available false; affected_versions 'all firmware versions (no fixed version exists; product is end-of-life / end-of-service and will not receive a security patch)'; cisa_kev true with kev_date 2025-03-19; active_exploitation confirmed; poc_available true, with active_exploitation_notes recording a public PoC since June 2023 and exploitation by at least two Mirai-variant botnets. The NIST-800-53-SI-2 gap records that the routine 30-day flaw-remediation SLA is far longer than the in-the-wild exploitation window for this KEV-listed unauthenticated OS command injection and that CISA set a 2025-04-09 due date. The vector records the device as end-of-life with no patch, leaving network isolation or hardware replacement as the only durable remediation.",
+        "description": "This control's three-state distinction is what an IC-7100 estate needs, because the first state (binary patch deployed, vulnerability eliminated) is unreachable for this CVE and always will be: no fixed release is available, every firmware version is affected, and no fixed version exists because the product is end-of-life and will not receive a security patch. A camera whose management CGI has been isolated therefore sits permanently in the compensating-control state, and the audit record must show it as that, with the dated replacement action attached, rather than as remediated or as a closed flaw-remediation ticket. The failure this prevents is specific to a device with no patch path: a vulnerability-management report keyed on patched-versus-unpatched has no true state to move an IC-7100 into, so the finding either stays open forever and is eventually suppressed as stale noise, or it is closed on the isolation change, at which point the camera leaves the estate's exposure view while still running a CGI with a PoC public since June 2023 and confirmed exploitation into Mirai botnets. The same record must also distinguish the isolated units from the third state the control names, full exposure, since the exploitation set is internet-reachable cameras and an unisolated unit is in that state today. Precondition: this is a reporting requirement, not a mitigation. It changes nothing on the device, and it is only meaningful if the compensating-control entry carries the removal date. An isolation record with no expiry is the same permanent open exposure written in different words, which is exactly the outcome a KEV due date of 2025-04-09 was meant to force.",
+        "evidence": "For CVE-2025-1316, no fixed release is available and no live patch is available. All firmware versions are affected: no fixed version exists, and the product is end-of-life / end-of-service and will not receive a security patch. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-19, and active exploitation is confirmed. A public PoC has been available since June 2023, and at least two Mirai-variant botnets have exploited the flaw. Under NIST-800-53-SI-2, the routine 30-day flaw-remediation SLA is far longer than the in-the-wild exploitation window for this KEV-listed unauthenticated OS command injection. CISA set a 2025-04-09 due date. The device is end-of-life with no patch, which leaves network isolation or hardware replacement as the only durable remediation.",
         "gap_closes": [
           "NIST-800-53-SI-2"
         ]
@@ -36392,7 +36392,7 @@
         "id": "NEW-CTRL-131",
         "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
         "description": "FortiOS and FortiProxy are the authentication enforcement point for the perimeter, and this defect is that enforcement failing open on a second channel: authentication is enforced on the primary path but not consistently on the Security Fabric (CSF) proxy path served by the Node.js websocket and CSF request handler, so a crafted CSF proxy request is processed with downstream-device super-admin authority. For this CVE the expedited clock runs from the KEV listing of 2025-03-18 through the completed vendor update of every affected FortiGate and FortiProxy unit. A vendor patch is available with no live-patch path, and remediation is the vendor update plus the named compensating controls until it lands, so a unit not yet taken through that update is exposed regardless of how well its administrator accounts are governed. Precondition on the interim measure, stated plainly because it is the part that gets recorded as the mitigation: the packet makes reachability conditional on the Security Fabric being enabled and the HTTP/HTTPS admin interface (or the CSF proxy) being exposed, so the window can be bounded — bounded, not closed — by enumerating which units have Security Fabric enabled and restricting which sources can reach their administrative surfaces. It does not remove the path. A unit that must keep Security Fabric enabled to do its job, and any source already able to route to the admin interface or CSF proxy, still reaches the alternate channel; the packet's only other stated requirement is that the attacker know the upstream and downstream CSF device serial numbers. Distinguishing test: from a segment with no fabric role and no administrative role, attempt to reach the CSF proxy and the HTTP/HTTPS admin interface of a staging unit and confirm both are refused before any request is processed — a patch-compliance report showing the fleet on a supported release says nothing about which of those units still accept CSF proxy requests from arbitrary sources.",
-        "evidence": "Packet: CWE-288, authentication bypass using an alternate path or channel, on Fortinet FortiOS and FortiProxy. A remote, unauthenticated attacker who can reach the FortiGate/FortiProxy management plane and who knows the serial numbers of the upstream and downstream Security Fabric (CSF) devices sends crafted CSF proxy requests over the Node.js websocket and CSF request handler; because authentication is enforced on the primary path but not consistently on this alternate channel, the request is processed with downstream-device super-admin authority. Reachability requires the Security Fabric to be enabled and the HTTP/HTTPS admin interface (or CSF proxy) to be exposed. CISA KEV-listed 2025-03-18, active_exploitation confirmed, CVSS 8.1, RWEP 59. patch_available true; live_patch_available false; live_patch_notes: \"No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.\"",
+        "evidence": "The flaw is CWE-288, authentication bypass using an alternate path or channel, in Fortinet FortiOS and FortiProxy. A remote, unauthenticated attacker who can reach the FortiGate/FortiProxy management plane and who knows the serial numbers of the upstream and downstream Security Fabric (CSF) devices sends crafted CSF proxy requests over the Node.js websocket and CSF request handler; because authentication is enforced on the primary path but not consistently on this alternate channel, the request is processed with downstream-device super-admin authority. Reachability requires the Security Fabric to be enabled and the HTTP/HTTPS admin interface (or CSF proxy) to be exposed. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-18, and active exploitation is confirmed. It carries a CVSS score of 8.1 and an RWEP score of 59. A fixed release is available, and no live patch is available: there is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -36403,8 +36403,8 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "The impact does not stop at the bypass — with the super-admin authority it grants, the operator creates persistent admin and SSL-VPN accounts, alters firewall policy, and pivots into the internal network, with exploitation confirmed in the wild. The vendor update undoes none of that. Applied to this device, the control means any FortiGate or FortiProxy unit that met the packet's reachability conditions during the exposure window — Security Fabric enabled and the admin interface or CSF proxy exposed — is handled as a compromised device rather than an unpatched one: export the configuration and diff it against a known-good baseline for administrator and SSL-VPN accounts and policy entries that no change record accounts for, rotate every credential the device holds or terminates, and restore from a verified baseline rather than patching in place. The flaw is an authentication bypass rather than code execution, so the persistence the packet documents is configuration-resident — accounts and policy — which is precisely what a configuration diff and credential rotation address and what a firmware upgrade preserves. Scope limit: this is the response for units whose stated reachability conditions held; a unit where the Security Fabric was never enabled does not meet the packet's precondition for the attack and belongs on the update path, not the rebuild path. The distinguishing test runs against account and policy state, not build number: on a unit already taken through the update, enumerate the administrator and SSL-VPN accounts and the policy table and confirm every entry maps to an authorized change — a fleet reporting the fixed build while carrying an attacker-created super-admin or SSL-VPN account is still under attacker control, and the flaw-remediation attestation reads clean the whole time.",
-        "evidence": "Packet: \"The bypass yields full super-admin on the downstream device, from which the operator creates persistent admin and SSL-VPN accounts, alters firewall policy, and pivots into the internal network.\" Reachability requires the Security Fabric to be enabled and the HTTP/HTTPS admin interface (or CSF proxy) to be exposed. active_exploitation confirmed; CISA KEV-listed 2025-03-18. patch_available true, live_patch_available false — remediation is the vendor update, which changes device code and not device configuration state.",
+        "description": "The impact does not stop at the bypass. With the super-admin authority it grants, the operator creates persistent admin and SSL-VPN accounts, alters firewall policy, and pivots into the internal network, with exploitation confirmed in the wild. The vendor update undoes none of that. Applied to this device, the control means any FortiGate or FortiProxy unit that met the attack's reachability conditions during the exposure window (Security Fabric enabled and the admin interface or CSF proxy exposed) is handled as a compromised device rather than an unpatched one: export the configuration and diff it against a known-good baseline for administrator and SSL-VPN accounts and policy entries that no change record accounts for, rotate every credential the device holds or terminates, and restore from a verified baseline rather than patching in place. The flaw is an authentication bypass rather than code execution, so the persistence described above is configuration-resident (accounts and policy), which is precisely what a configuration diff and credential rotation address and what a firmware upgrade preserves. Scope limit: this is the response for units whose stated reachability conditions held; a unit where the Security Fabric was never enabled does not meet the precondition for the attack and belongs on the update path, not the rebuild path. The distinguishing test runs against account and policy state, not build number: on a unit already taken through the update, enumerate the administrator and SSL-VPN accounts and the policy table and confirm every entry maps to an authorized change. A fleet reporting the fixed build while carrying an attacker-created super-admin or SSL-VPN account is still under attacker control, and the flaw-remediation attestation reads clean the whole time.",
+        "evidence": "The bypass yields full super-admin on the downstream device, from which the operator creates persistent admin and SSL-VPN accounts, alters firewall policy, and pivots into the internal network. Reachability requires the Security Fabric to be enabled and the HTTP/HTTPS admin interface (or CSF proxy) to be exposed. Active exploitation is confirmed, and CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-18. A fixed release is available and no live patch is available, so remediation is the vendor update, which changes device code and not device configuration state.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "UK-CAF-B4",
@@ -36471,8 +36471,8 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "The Junos update repairs the isolation defect and removes nothing that ran through it. What this CVE produces, per the packet, is unsigned code executing inside the memory of a legitimate process on the router while Veriexec — the device's own verified-execution integrity protection — is circumvented, so the artifact a post-incident check normally looks for is precisely what the technique avoids leaving: PIC TINYSHELL backdoors running despite file-integrity controls. Applied to this device, the control means any Junos router where unauthorized root/shell access during the window opened by the 2025-03-13 KEV listing cannot be excluded is dispositioned as compromised rather than upgraded in place — running configuration captured and diffed against the last known-good, the device rebuilt from vendor image at the fixed release, and the credentials the router held or authenticated against rotated. This differs from the pre-authentication perimeter cases in one way that changes scoping and only that: the packet's reachability requirement is an attacker who already holds root/shell and can drop from the Junos CLI into the underlying FreeBSD shell, so the population to disposition is the set of devices where that access cannot be ruled out, not every device on an affected release. The reason for rebuilding is unchanged — the implant predates the update and survives it. Distinguishing test: state what evidence would separate a clean router from one carrying this implant. If the answer is that Veriexec reports no integrity violation or that the on-box file hashes match, the estate's remediation record rests on exactly the assurance this technique defeats. Precondition: rebuilding removes what is resident on the device and nothing else. It does not address how root/shell was obtained — which is not established for any given device — so a rebuilt router re-entered through the same credential, jump host or chained flaw returns to the same state, and the rebuild has to be paired with answering that question rather than substituted for it.",
-        "evidence": "Juniper Junos OS improper isolation or compartmentalization (CWE-653). Packet: CISA KEV-listed 2025-03-13, active_exploitation confirmed, RWEP 57 / CVSS 4.4, poc_available false, patch_available true, live_patch_available false (\"No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands\"). Vector: the attacker must already hold high (root/shell) privileges and drop from the Junos CLI into the underlying FreeBSD shell — explicitly not exploitable from the Junos CLI itself — then writes attacker-controlled shellcode into the memory of a legitimate hung process via /proc/<pid>/mem and overwrites the GOT entry for fclose, so triggering EOF executes the loader. This circumvents Junos OS Veriexec verified-execution integrity protection, allowing arbitrary unsigned code (PIC TINYSHELL backdoors) to run despite file-integrity controls, converting existing root shell access into persistent, signature-evading implant execution on the router.",
+        "description": "The Junos update repairs the isolation defect and removes nothing that ran through it. What this CVE produces is unsigned code executing inside the memory of a legitimate process on the router while Veriexec, the device's own verified-execution integrity protection, is circumvented, so the artifact a post-incident check normally looks for is precisely what the technique avoids leaving: PIC TINYSHELL backdoors running despite file-integrity controls. Applied to this device, the control means any Junos router where unauthorized root/shell access during the window opened by the 2025-03-13 KEV listing cannot be excluded is dispositioned as compromised rather than upgraded in place, with the running configuration captured and diffed against the last known-good, the device rebuilt from vendor image at the fixed release, and the credentials the router held or authenticated against rotated. This differs from the pre-authentication perimeter cases in one way that changes scoping and only that: the reachability requirement is an attacker who already holds root/shell and can drop from the Junos CLI into the underlying FreeBSD shell, so the population to disposition is the set of devices where that access cannot be ruled out, not every device on an affected release. The reason for rebuilding is unchanged: the implant predates the update and survives it. Distinguishing test: state what evidence would separate a clean router from one carrying this implant. If the answer is that Veriexec reports no integrity violation or that the on-box file hashes match, the estate's remediation record rests on exactly the assurance this technique defeats. Precondition: rebuilding removes what is resident on the device and nothing else. It does not address how root/shell was obtained, which is not established for any given device, so a rebuilt router re-entered through the same credential, jump host or chained flaw returns to the same state, and the rebuild has to be paired with answering that question rather than substituted for it.",
+        "evidence": "The flaw is an improper isolation or compartmentalization vulnerability (CWE-653) in Juniper Junos OS. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-13, and active exploitation is confirmed. It carries an RWEP score of 57 and a CVSS score of 4.4. No proof-of-concept exploit is available. A fixed release is available, and no live patch is available: there is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands. The attacker must already hold high (root/shell) privileges and drop from the Junos CLI into the underlying FreeBSD shell (the flaw is explicitly not exploitable from the Junos CLI itself). The attacker then writes attacker-controlled shellcode into the memory of a legitimate hung process via /proc/<pid>/mem and overwrites the GOT entry for fclose, so triggering EOF executes the loader. This circumvents Junos OS Veriexec verified-execution integrity protection, allowing arbitrary unsigned code (PIC TINYSHELL backdoors) to run despite file-integrity controls, converting existing root shell access into persistent, signature-evading implant execution on the router.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIST-800-53-SI-2"
@@ -36481,8 +36481,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "CVSS 4.4 is low here for a reason that does not reduce the consequence: the packet discounts the score for the precondition — an attacker who already holds root/shell — while the outcome it records is unsigned code running on a production router despite Veriexec. A severity-band remediation queue therefore sorts this Junos defect beneath routine medium findings, which is the specific mechanism by which it goes unremediated on core routing infrastructure. The control's requirement for this entry is that the clock runs from the 2025-03-13 KEV listing and the confirmed in-the-wild exploitation rather than from the CVSS band, and that it runs against devices rather than against tickets: there is a vendor patch and no live-patch path for this product class, so the fixed Junos release must actually be carried onto each affected router, and completion is measured by the release the device is running — not by an image staged or a change request raised. Distinguishing test: sort the vulnerability register by severity and find where this CVE lands against the program's SLA tiers. If a 4.4 that CISA lists as exploited inherits a medium-severity window, the program is scoring the exploit's precondition instead of its exposure, and it will do the same to the next low-base-score KEV entry. Precondition: this control governs scheduling only. It gives nothing to a router already carrying the implant the packet describes — that device is dispositioned under the rebuild path, because applying the update to it changes the running release and leaves the resident code in place.",
-        "evidence": "Packet: CISA KEV-listed 2025-03-13 with active_exploitation confirmed; RWEP 57 against CVSS 4.4; poc_available false; patch_available true; live_patch_available false with the note that remediation is the vendor update plus the named compensating controls until it lands. The vector states the low reachability bar is the requirement for pre-existing root/shell and the ability to drop from the Junos CLI into the FreeBSD shell, while the recorded outcome is arbitrary unsigned code executing despite Junos OS Veriexec.",
+        "description": "CVSS 4.4 is low here for a reason that does not reduce the consequence: the score is discounted for the precondition (an attacker who already holds root/shell), while the outcome is unsigned code running on a production router despite Veriexec. A severity-band remediation queue therefore sorts this Junos defect beneath routine medium findings, which is the specific mechanism by which it goes unremediated on core routing infrastructure. The control's requirement for this entry is that the clock runs from the 2025-03-13 KEV listing and the confirmed in-the-wild exploitation rather than from the CVSS band, and that it runs against devices rather than against tickets: there is a vendor patch and no live-patch path for this product class, so the fixed Junos release must actually be carried onto each affected router, and completion is measured by the release the device is running, not by an image staged or a change request raised. Distinguishing test: sort the vulnerability register by severity and find where this CVE lands against the program's SLA tiers. If a 4.4 that CISA lists as exploited inherits a medium-severity window, the program is scoring the exploit's precondition instead of its exposure, and it will do the same to the next low-base-score KEV entry. Precondition: this control governs scheduling only. It gives nothing to a router already carrying the implant from this exploit. That device is dispositioned under the rebuild path, because applying the update to it changes the running release and leaves the resident code in place.",
+        "evidence": "CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-13, and active exploitation is confirmed. It carries an RWEP score of 57 against a CVSS score of 4.4. No proof-of-concept exploit is available. A fixed release is available, and no live patch is available; remediation is the vendor update plus the named compensating controls until it lands. The low reachability bar is the requirement for pre-existing root/shell and the ability to drop from the Junos CLI into the FreeBSD shell, while the outcome is arbitrary unsigned code executing despite Junos OS Veriexec.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "NIST-800-53-SI-2"
@@ -36491,8 +36491,8 @@
       {
         "id": "NEW-CTRL-031",
         "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
-        "description": "This exploit has a required step that is not the memory corruption and that the device records: the attacker must leave the Junos CLI for the underlying FreeBSD shell, because the flaw is explicitly not exploitable from the Junos CLI itself. Everything after that — the write into a hung process via /proc/<pid>/mem, the fclose GOT overwrite, the unsigned loader — happens on a platform the attacker holds root on, which is also the platform holding the record of the shell transition that preceded it. Bound to this device, the control means Junos syslog and authentication events leave the router for a collector in a separate trust zone with its own credentials and its own authentication path, and that entry into the FreeBSD shell on a production router is an alerting condition there rather than a line read on-box during an investigation. This is the signal that survives the primitive the packet describes: the Veriexec verdict, the on-disk hashes and the local logs are all produced by the compromised platform, whereas a record already shipped off it is not. Distinguishing test: take the FreeBSD shell on a lab router, clear the local log, and confirm the event is still present and alertable on the off-device collector. Precondition: this preserves and surfaces evidence, it prevents nothing, and it covers only the window in which forwarding was already configured and reaching the collector — an attacker at root can stop the device shipping logs from the moment of compromise, so what survives is what shipped before that point, and a router's feed going quiet is itself an event to treat as a signal rather than as a collector fault. It also gives nothing on an estate where administrators enter the FreeBSD shell routinely and the event carries no alert, which is the condition to check before recording this as a detection.",
-        "evidence": "Packet vector: reachability requires a local attacker who already holds root/shell and can drop from the Junos CLI into the underlying FreeBSD shell, and the flaw is explicitly not exploitable from the Junos CLI itself; the subsequent steps are a /proc/<pid>/mem write into a legitimate hung process and a GOT overwrite of fclose, circumventing Junos OS Veriexec so unsigned code runs despite file-integrity controls. CISA KEV-listed 2025-03-13, active_exploitation confirmed, RWEP 57 / CVSS 4.4.",
+        "description": "This exploit has a required step that is not the memory corruption and that the device records: the attacker must leave the Junos CLI for the underlying FreeBSD shell, because the flaw is explicitly not exploitable from the Junos CLI itself. Everything after that (the write into a hung process via /proc/<pid>/mem, the fclose GOT overwrite, the unsigned loader) happens on a platform the attacker holds root on, which is also the platform holding the record of the shell transition that preceded it. Bound to this device, the control means Junos syslog and authentication events leave the router for a collector in a separate trust zone with its own credentials and its own authentication path, and that entry into the FreeBSD shell on a production router is an alerting condition there rather than a line read on-box during an investigation. This is the signal that survives the primitive described above: the Veriexec verdict, the on-disk hashes and the local logs are all produced by the compromised platform, whereas a record already shipped off it is not. Distinguishing test: take the FreeBSD shell on a lab router, clear the local log, and confirm the event is still present and alertable on the off-device collector. Precondition: this preserves and surfaces evidence, it prevents nothing, and it covers only the window in which forwarding was already configured and reaching the collector. An attacker at root can stop the device shipping logs from the moment of compromise, so what survives is what shipped before that point, and a router's feed going quiet is itself an event to treat as a signal rather than as a collector fault. It also gives nothing on an estate where administrators enter the FreeBSD shell routinely and the event carries no alert, which is the condition to check before recording this as a detection.",
+        "evidence": "Reachability requires a local attacker who already holds root/shell and can drop from the Junos CLI into the underlying FreeBSD shell, and the flaw is explicitly not exploitable from the Junos CLI itself; the subsequent steps are a /proc/<pid>/mem write into a legitimate hung process and a GOT overwrite of fclose, circumventing Junos OS Veriexec so unsigned code runs despite file-integrity controls. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-13, and active exploitation is confirmed. It carries an RWEP score of 57 and a CVSS score of 4.4.",
         "gap_closes": [
           "NIST-800-53-SC-7",
           "UK-CAF-B4"
@@ -36558,8 +36558,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "This NTFS heap overflow reads low on every routine triage input — CVSS 7.8, local vector, user interaction required, and no public PoC — which is exactly the profile a 30-day OS-patch SLA absorbs without comment. The KEV listing plus confirmed in-the-wild use is what should actually set the clock: the packet's own path needs only a delivered disk image and one double-click, and the parsing happens in the file-system driver, so a successful run is an ordinary user to SYSTEM on the host — a ransomware staging position, not a local nuisance. The SLA must therefore be driven off the KEV listing date rather than the CVSS band, and it must run to the reboot that makes the update effective, not to the moment the update is approved. The packet's remediation note is explicit that there is no live-patch path for this product class and that remediation is the vendor update plus compensating controls until it lands; for this delivery path those compensating controls are blocking internet- and mail-sourced disk-image files from reaching users and denying mount of untrusted images, and they are what carries hosts whose reboot cannot be pulled inside the KEV clock.",
-        "evidence": "Packet: cwe_refs CWE-122; cisa_kev true, kev_date 2025-03-11, active_exploitation confirmed; poc_available false; CVSS 7.8 against RWEP 61. vector states an attacker 'crafts a malicious VHD/VHDX (or other disk image) and induces a local user to mount it — Windows auto-mounts a double-clicked VHD through Explorer, so this needs only file delivery plus a single user action (UI:R)', that the parsing happens 'in the file-system driver running with high privilege', and that a successful exploit 'escalates from an ordinary user to SYSTEM, giving full host compromise that can stage ransomware or further implants'. patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "description": "This NTFS heap overflow reads low on every routine triage input (CVSS 7.8, local vector, user interaction required, and no public PoC), which is exactly the profile a 30-day OS-patch SLA absorbs without comment. The KEV listing plus confirmed in-the-wild use is what should actually set the clock: the exploit path needs only a delivered disk image and one double-click, and the parsing happens in the file-system driver, so a successful run is an ordinary user to SYSTEM on the host, which is a ransomware staging position and not a local nuisance. The SLA must therefore be driven off the KEV listing date rather than the CVSS band, and it must run to the reboot that makes the update effective, not to the moment the update is approved. There is no live-patch path for this product class, and remediation is the vendor update plus compensating controls until it lands; for this delivery path those compensating controls are blocking internet- and mail-sourced disk-image files from reaching users and denying mount of untrusted images, and they are what carries hosts whose reboot cannot be pulled inside the KEV clock.",
+        "evidence": "The weakness is CWE-122. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-11, and active exploitation is confirmed. No public proof of concept is available. The CVSS score is 7.8 against an RWEP score of 61. An attacker crafts a malicious VHD/VHDX (or other disk image) and induces a local user to mount it. Windows auto-mounts a double-clicked VHD through Explorer, so this needs only file delivery plus a single user action (UI:R). The parsing happens in the file-system driver running with high privilege, and a successful exploit escalates from an ordinary user to SYSTEM, giving full host compromise that can stage ransomware or further implants. A fixed release is available, but no live patch is available: there is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -36571,7 +36571,7 @@
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
         "description": "The entire exploit precondition is file delivery: a crafted VHD/VHDX has to reach a user's disk and be double-clicked, at which point Explorer auto-mounts it and hands the attacker's on-disk NTFS metadata straight to a high-privilege kernel parser. Provenance enforcement is the control that breaks that step ahead of the reboot. Internet- and mail-sourced files in the mountable-container class (.vhd, .vhdx, .iso and equivalents) must carry Mark-of-the-Web from the gateway through to the endpoint, and the mount action on a provenance-marked image must be blocked outright rather than warned about — a warning dialog is the same single user action the exploit already assumes. A reputation verdict is no substitute here and the control's 'regardless of a reputation service verdict' clause is load-bearing: the malicious bytes are inert file-system metadata, not executable content, so a reputation or detonation service has little to score and the image will look clean right up to the moment it is mounted. This is the only control in the set that works on hosts that cannot be rebooted inside the KEV window.",
-        "evidence": "Packet: vector describes the attacker crafting 'a malicious VHD/VHDX (or other disk image)' and inducing 'a local user to mount it', notes 'Windows auto-mounts a double-clicked VHD through Explorer, so this needs only file delivery plus a single user action (UI:R)', and that 'the malformed NTFS structure causes improper bounds checking in the driver to overflow a heap buffer (CWE-122)'. poc_available false while active_exploitation is confirmed and cisa_kev is true (kev_date 2025-03-11). patch_available true but live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "evidence": "The attacker crafts a malicious VHD/VHDX (or other disk image) and induces a local user to mount it. Windows auto-mounts a double-clicked VHD through Explorer, so this needs only file delivery plus a single user action (UI:R). The malformed NTFS structure causes improper bounds checking in the driver to overflow a heap buffer (CWE-122). No public proof of concept is available, while active exploitation is confirmed and CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-11. A fixed release is available, but no live patch is available: there is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands.",
         "gap_closes": [
           "UK-CAF-B4"
         ]
@@ -36579,8 +36579,8 @@
       {
         "id": "NEW-CTRL-038",
         "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
-        "description": "The packet's own remediation note puts this CVE in the state most audit reports cannot express. The vendor update exists, but there is no live-patch path for this product class, so between the KEV listing and the reboot every affected host is running on compensating controls alone. An audit that records 'patched per SLA' the moment the update is approved, downloaded or installed is describing a host whose vulnerable file-system driver is still the loaded, running one — the driver is not replaced until reboot, and this exploit path executes inside that driver. The verdict taxonomy for this entry must separate: rebooted onto the fixed driver; update installed but pre-reboot, with disk-image provenance blocking as the named active compensating control and a time-bound reboot action item; and neither. For estates with long-uptime workstations or servers on quarterly reboot windows, the middle state is where most of the fleet actually lives after a Patch Tuesday, and it is a distinct residual-risk position rather than a pass.",
-        "evidence": "Packet: live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands', alongside patch_available true. vector states the flaw is reached 'via the NTFS driver (ntfs.sys) parsing attacker-controlled on-disk metadata' and that 'the parsing happens in the file-system driver running with high privilege'. cisa_kev true, kev_date 2025-03-11, active_exploitation confirmed.",
+        "description": "The remediation for this CVE puts it in a state most audit reports cannot express. The vendor update exists, but there is no live-patch path for this product class, so between the KEV listing and the reboot every affected host is running on compensating controls alone. An audit that records 'patched per SLA' the moment the update is approved, downloaded or installed is describing a host whose vulnerable file-system driver is still the loaded, running one. The driver is not replaced until reboot, and this exploit path executes inside that driver. The verdict taxonomy for this entry must separate: rebooted onto the fixed driver; update installed but pre-reboot, with disk-image provenance blocking as the named active compensating control and a time-bound reboot action item; and neither. For estates with long-uptime workstations or servers on quarterly reboot windows, the middle state is where most of the fleet actually lives after a Patch Tuesday, and it is a distinct residual-risk position rather than a pass.",
+        "evidence": "No live patch is available: there is no live-patch path for this product class, and remediation is the vendor update plus the named compensating controls until it lands. A fixed release is available. The flaw is reached via the NTFS driver (ntfs.sys) parsing attacker-controlled on-disk metadata, and the parsing happens in the file-system driver running with high privilege. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-03-11, and active exploitation is confirmed.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIS2-Art21-vulnerability-management"
@@ -44677,7 +44677,7 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "The execution path runs at the opening user's own privilege inside mmc.exe — a crafted .msc console file references the apds.dll ActiveX control through the file's StringTable section and runs attacker JScript when the victim opens it — so the population to drive the Windows update across is the general workstation estate where users open files, not a server tier, and the estate's own inventory of who opens files is the enumeration that matters. Run that update on the clock that opened with the 2024-10-08 KEV listing rather than folding it into the next monthly rollup, and measure completion by each host's installed build rather than by 'approved' or 'downloaded' in the management console. The packet registers a vendor patch, live_patch_available false, and no live-patch note at all, so there is no vendor-mitigation state to fall back into and no rule to deploy while the rollout runs: every host either takes the update or is exposed, and the only other lever is the delivery-path control recorded alongside this one, which is the 'documented compensating controls' branch this SLA allows and must be recorded with a dated end rather than as a patched outcome. Priority follows the packet rather than the 7.8 base — a public PoC, confirmed in-the-wild exploitation and RWEP 81 put this above other 7.8-band Windows items in the same cycle, because the vulnerability-management and flaw-remediation controls cited as insufficient here are the ones that set the cadence, and a monthly-rollup cadence is exactly what leaves a KEV-listed, publicly-exploited file-open RCE reachable for weeks after the fix ships.",
+        "description": "The execution path runs at the opening user's own privilege inside mmc.exe: a crafted .msc console file references the apds.dll ActiveX control through the file's StringTable section and runs attacker JScript when the victim opens it. The population to drive the Windows update across is therefore the general workstation estate where users open files, not a server tier, and the estate's own inventory of who opens files is the enumeration that matters. Run that update on the clock that opened with the 2024-10-08 KEV listing rather than folding it into the next monthly rollup, and measure completion by each host's installed build rather than by 'approved' or 'downloaded' in the management console. A vendor patch is available and no live patch is available, so there is no vendor-mitigation state to fall back into and no rule to deploy while the rollout runs: every host either takes the update or is exposed, and the only other lever is the delivery-path control recorded alongside this one, which is the 'documented compensating controls' branch this SLA allows and must be recorded with a dated end rather than as a patched outcome. Priority does not follow the 7.8 base: a public PoC, confirmed in-the-wild exploitation and an RWEP score of 81 put this above other 7.8-band Windows items in the same cycle, because the vulnerability-management and flaw-remediation controls cited as insufficient here are the ones that set the cadence, and a monthly-rollup cadence is exactly what leaves a KEV-listed, publicly-exploited file-open RCE reachable for weeks after the fix ships.",
         "evidence": "Packet entry 'Microsoft Windows Management Console Remote Code Execution Vulnerability' (CWE-707): cisa_kev true with kev_date 2024-10-08, active_exploitation 'confirmed', cvss 7.8, rwep_score 81, poc_available true, patch_available true, live_patch_available false, live_patch_notes null. Attack vector as recorded: \"An attacker crafts a malicious .msc console file referencing a vulnerable ActiveX control (apds.dll) via the file's StringTable section, smuggling in an old XSS flaw that executes arbitrary JScript inside mmc.exe when the victim opens the file — the 'GrimResource' technique.\" Framework gaps citing this CVE include NIST-800-53-SI-2 (Flaw Remediation), ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) and EU NIS2 Art. 21 vulnerability handling.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -44738,8 +44738,8 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "The gaps on this entry reduce to one operational fact: the fix is in Qualcomm chipset firmware and reaches a handset only when its OEM and carrier ship it, which the SI-2 gap records as routinely lagging the Qualcomm bulletin by months and the Essential-Eight gap records as making a 48-hour patch target unenforceable. No management console can install a build the OEM has not released, so the enforceable half of this control is the access-condition half: enumerate the issued Android fleet by SoC and by the security-patch level each device actually reports, and make the October 2024 bulletin level a condition of access to mail, VPN and document stores rather than a column on a compliance dashboard. A handset below the line keeps working as a phone and loses the organisation's data — that is the only lever the operator holds while the OEM queue runs. Scope the enumeration from the affected fields rather than from one handset vendor: the scope is multiple Qualcomm chipsets' DSP Services component, with affected versions given only as the chipsets covered by the October 2024 security bulletin and the full SoC and DSP-driver list in the vendor advisory, so a scan keyed on a single OEM's handsets reports clean across a fleet built by another OEM on the same SoC. Distinguishing test: enrol a device whose reported patch level is below the bulletin and confirm policy actually denies it access to protected resources — an estate that surfaces the stale patch level on a report while the device keeps its mailbox has recorded the exposure rather than removed it. Preconditions: patch_required_reboot is true with no live-patch path, so a handset that downloaded the OEM update but has not restarted onto it is still executing the vulnerable DSP code and must be counted below the line; and this control does not touch the exploitation path the packet describes — a handset physically seized and unlocked with forensic tooling is outside the operator's control at the moment of attack, so the access condition limits what a returned device can reach, it does not prevent the escalation.",
-        "evidence": "Packet fields: cwe_refs CWE-416; affected records multiple Qualcomm chipsets' DSP Services component mismanaging memory maps of HLOS memory, causing a use-after-free exploitable for local privilege escalation; affected_versions 'Qualcomm chipsets covered by the October 2024 security bulletin — see vendor advisory for the full SoC/DSP-driver list'; cisa_kev true, kev_date 2024-10-08; active_exploitation confirmed; poc_available false; cvss 7.8, rwep_score 55; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. The NIST-800-53-SI-2 gap states OEM/carrier patch propagation for Android chipset firmware routinely lags the Qualcomm bulletin by months; the AU-Essential-8-Patch gap states the 48-hour guidance is unenforceable for OEM-gated chipset firmware shipping on a multi-month cadence; the ISO-27001-2022-A.8.8 gap states this DSP-Services use-after-free escalates below the MDM and OS layer inside the Qualcomm chipset.",
+        "description": "The gaps on this entry reduce to one operational fact: the fix is in Qualcomm chipset firmware and reaches a handset only when its OEM and carrier ship it, which the SI-2 gap records as routinely lagging the Qualcomm bulletin by months and the Essential-Eight gap records as making a 48-hour patch target unenforceable. No management console can install a build the OEM has not released, so the enforceable half of this control is the access-condition half: enumerate the issued Android fleet by SoC and by the security-patch level each device actually reports, and make the October 2024 bulletin level a condition of access to mail, VPN and document stores rather than a column on a compliance dashboard. A handset below the line keeps working as a phone and loses the organization's data, and that is the only lever the operator holds while the OEM queue runs. Scope the enumeration from the affected chipsets rather than from one handset vendor: the scope is multiple Qualcomm chipsets' DSP Services component, with affected versions given only as the chipsets covered by the October 2024 security bulletin and the full SoC and DSP-driver list in the vendor advisory, so a scan keyed on a single OEM's handsets reports clean across a fleet built by another OEM on the same SoC. Distinguishing test: enroll a device whose reported patch level is below the bulletin and confirm policy actually denies it access to protected resources. An estate that surfaces the stale patch level on a report while the device keeps its mailbox has recorded the exposure rather than removed it. Preconditions: the patch requires a reboot and no live patch is available, so a handset that downloaded the OEM update but has not restarted onto it is still executing the vulnerable DSP code and must be counted below the line. This control also does not touch the known exploitation path. A handset physically seized and unlocked with forensic tooling is outside the operator's control at the moment of attack, so the access condition limits what a returned device can reach; it does not prevent the escalation.",
+        "evidence": "The weakness is CWE-416. The DSP Services component of multiple Qualcomm chipsets mismanages memory maps of HLOS memory, causing a use-after-free exploitable for local privilege escalation. The affected versions are the Qualcomm chipsets covered by the October 2024 security bulletin, and the vendor advisory gives the full SoC/DSP-driver list. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-10-08. Active exploitation is confirmed, and no proof-of-concept exploit is publicly available. It has a CVSS score of 7.8 and an RWEP score of 55. A fixed release is available, the patch requires a reboot, and no live patch is available. The NIST-800-53-SI-2 gap states OEM/carrier patch propagation for Android chipset firmware routinely lags the Qualcomm bulletin by months; the AU-Essential-8-Patch gap states the 48-hour guidance is unenforceable for OEM-gated chipset firmware shipping on a multi-month cadence; the ISO-27001-2022-A.8.8 gap states this DSP-Services use-after-free escalates below the MDM and OS layer inside the Qualcomm chipset.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "AU-Essential-8-Patch",
@@ -44749,8 +44749,8 @@
       {
         "id": "NEW-CTRL-037",
         "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
-        "description": "The packet's exploitation notes give this entry a trigger most mobile incident plans do not carry: the escalation was chained after physical access — Cellebrite forensic-extraction tooling used to unlock seized Android devices, then this Qualcomm DSP use-after-free used to escalate privilege and install NoviSpy spyware on journalists' and activists' handsets, per the Amnesty International Security Lab reporting the packet cites. The NIS2 gap names the missing control outright: entities issuing Qualcomm-based devices to at-risk personnel had no compensating control once a device left custody. This playbook is what fills it — loss of custody (seizure, border inspection, repair, or any interval the holder cannot account for) is declared a compromise event for that handset, with its device-trust state invalidated, its certificates and enrolment revoked, every credential it held or that authenticated through it rotated, and the handset quarantined from the fleet rather than silently re-enrolled. The handset itself goes to off-device forensic examination and is replaced rather than returned on the strength of looking normal, which is also the honest answer to the malicious-code-protection gap recorded here: on-device protection does not observe DSP-level memory-map corruption, so no scan clears the handset and the trust decision has to be made off it. It is likewise the answer to the device-hardening gap, whose configuration baselines assume the attacker never holds the hardware. Preconditions: this is a pre-arranged playbook or it is nothing — the cohort it protects must be identified and briefed on what to report before a seizure, not after; and it is a response control, bounding what a compromised handset reaches once custody is lost rather than preventing an escalation that happens on hardware the operator no longer holds.",
-        "evidence": "Packet fields: active_exploitation confirmed, with active_exploitation_notes recording exploitation as part of a targeted spyware chain in which Serbian authorities used Cellebrite forensic-extraction tooling to unlock seized Android devices, then chained this Qualcomm DSP use-after-free for privilege escalation to install the 'NoviSpy' spyware against journalists and activists (Amnesty International Security Lab, Dec 2024), not flagged as ransomware; poc_available false; cisa_kev true, kev_date 2024-10-08. The NIS2-Art21-vulnerability-management gap states entities issuing Qualcomm-based devices to at-risk personnel had no compensating control once a device left custody (e.g. lawful seizure) pending OEM patch rollout; the UK-CAF-B4 gap states device configuration/hardening baselines do not address firmware-level chipset flaws exploited during physical forensic-extraction access; the NIST-800-53-SI-3 gap states mobile endpoint protection rarely inspects DSP/kernel-level memory-map handling, so this class of use-after-free is invisible to conventional malware detection.",
+        "description": "The way this CVE was exploited gives this entry a trigger most mobile incident plans do not carry: the escalation was chained after physical access. Cellebrite forensic-extraction tooling was used to unlock seized Android devices, and this Qualcomm DSP use-after-free was then used to escalate privilege and install NoviSpy spyware on journalists' and activists' handsets, per Amnesty International Security Lab reporting. The NIS2 gap names the missing control outright: entities issuing Qualcomm-based devices to at-risk personnel had no compensating control once a device left custody. This playbook is what fills it. Loss of custody (seizure, border inspection, repair, or any interval the holder cannot account for) is declared a compromise event for that handset, with its device-trust state invalidated, its certificates and enrollment revoked, every credential it held or that authenticated through it rotated, and the handset quarantined from the fleet rather than silently re-enrolled. The handset itself goes to off-device forensic examination and is replaced rather than returned on the strength of looking normal, which is also the honest answer to the malicious-code-protection gap recorded here: on-device protection does not observe DSP-level memory-map corruption, so no scan clears the handset and the trust decision has to be made off it. It is likewise the answer to the device-hardening gap, whose configuration baselines assume the attacker never holds the hardware. Preconditions: this is a pre-arranged playbook or it is nothing. The cohort it protects must be identified and briefed on what to report before a seizure, not after. It is also a response control, bounding what a compromised handset reaches once custody is lost rather than preventing an escalation that happens on hardware the operator no longer holds.",
+        "evidence": "Active exploitation is confirmed as part of a targeted spyware chain in which Serbian authorities used Cellebrite forensic-extraction tooling to unlock seized Android devices, then chained this Qualcomm DSP use-after-free for privilege escalation to install the 'NoviSpy' spyware against journalists and activists (Amnesty International Security Lab, Dec 2024). The exploitation is not flagged as ransomware. No proof-of-concept exploit is publicly available. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-10-08. The NIS2-Art21-vulnerability-management gap states entities issuing Qualcomm-based devices to at-risk personnel had no compensating control once a device left custody (e.g. lawful seizure) pending OEM patch rollout; the UK-CAF-B4 gap states device configuration/hardening baselines do not address firmware-level chipset flaws exploited during physical forensic-extraction access; the NIST-800-53-SI-3 gap states mobile endpoint protection rarely inspects DSP/kernel-level memory-map handling, so this class of use-after-free is invisible to conventional malware detection.",
         "gap_closes": [
           "NIS2-Art21-vulnerability-management",
           "UK-CAF-B4",
@@ -44800,8 +44800,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "For this CVE the clock has to start at the vendor fix, not at the KEV listing. Zimbra's fix shipped 2024-09-04, mass exploitation began 2024-09-28, and the KEV listing followed on 2024-10-03 — so an operator whose SLA is keyed to KEV began responding five days after the exploitation wave was already running against the install base. Scope from the affected versions rather than from the product name: ZCS ships four release branches here and each has its own fixed level (8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9, 10.1.1), so an estate standardized on one branch that reports itself current still leaves the other branches on vulnerable code. patch_available is true and no live-patch path is recorded, so driving each install to its branch's fixed level is the remediation; measure completion on the version the running ZCS services report rather than on a package record, because postjournal keeps executing pre-fix code until the service it runs under restarts onto the new build. The packet describes the flaw as one postjournal 'sometimes' exposes without stating the condition that decides it, so no install can be written off as unaffected on configuration grounds — its patch level is the only fact that settles the question. Self-hosted mail is the population this bites hardest: the packet's vulnerability-handling gap records that these operators have no vendor-driven forced-upgrade mechanism, so nothing closes the window if the operator's own clock does not.",
-        "evidence": "Packet: cisa_kev true with kev_date 2024-10-03; active_exploitation confirmed; CVSS 10, RWEP 74; poc_available true; patch_available true, live_patch_available false, live_patch_notes null, patch_required_reboot false. The flaw-remediation gap records the fix shipping 2024-09-04 against mass exploitation beginning 2024-09-28, a roughly 3.5-week window. active_exploitation_notes: mass-exploited beginning 2024-09-28, days after ProjectDiscovery published technical details and PoC code. affected_versions: ZCS 8.8.15 before Patch 46, 9.0.0 before Patch 41, 10.0 before 10.0.9, 10.1 before 10.1.1. The vector states postjournal 'sometimes' allows unauthenticated users to execute commands. The NIS2 gap records that self-hosted mail operators had no vendor-driven forced-upgrade mechanism, unlike SaaS email.",
+        "description": "For this CVE the clock has to start at the vendor fix, not at the KEV listing. Zimbra's fix shipped 2024-09-04, mass exploitation began 2024-09-28, and the KEV listing followed on 2024-10-03, so an operator whose SLA is keyed to KEV began responding five days after the exploitation wave was already running against the install base. Scope from the affected versions rather than from the product name: ZCS ships four release branches here and each has its own fixed level (8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9, 10.1.1), so an estate standardized on one branch that reports itself current still leaves the other branches on vulnerable code. A fixed release is available and no live-patch path is recorded, so driving each install to its branch's fixed level is the remediation; measure completion on the version the running ZCS services report rather than on a package record, because postjournal keeps executing pre-fix code until the service it runs under restarts onto the new build. The flaw is described as one postjournal 'sometimes' exposes, with no stated condition that decides it, so no install can be written off as unaffected on configuration grounds; its patch level is the only fact that settles the question. Self-hosted mail is the population this bites hardest: the vulnerability-handling gap records that these operators have no vendor-driven forced-upgrade mechanism, so nothing closes the window if the operator's own clock does not.",
+        "evidence": "CISA added it to its Known Exploited Vulnerabilities catalog on 2024-10-03. Active exploitation is confirmed. It has a CVSS score of 10 and an RWEP score of 74. A public proof-of-concept exploit is available. A fixed release is available, no live patch is available, and the patch does not require a reboot. The flaw-remediation gap records the fix shipping 2024-09-04 against mass exploitation beginning 2024-09-28, a roughly 3.5-week window. The CVE was mass-exploited beginning 2024-09-28, days after ProjectDiscovery published technical details and PoC code. The affected versions are ZCS 8.8.15 before Patch 46, 9.0.0 before Patch 41, 10.0 before 10.0.9, and 10.1 before 10.1.1. The flaw is described as postjournal 'sometimes' allowing unauthenticated users to execute commands. The NIS2 gap records that self-hosted mail operators had no vendor-driven forced-upgrade mechanism, unlike SaaS email.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "AU-Essential-8-Patch",
@@ -44811,8 +44811,8 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "What matters is not just that Zimbra was exploited but what the attackers did with it: spoofed emails carrying base64-encoded shell commands in the CC field, dropping webshells on internet-facing Zimbra servers throughout the wave that began 2024-09-28. Applied to this product, the requirement is that any ZCS server sitting below its branch's fixed level during that wave is handled as an incident, not as a patch ticket. Upgrading to 8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9 or 10.1.1 closes the injection path and removes nothing already written through it — a webshell placed before the upgrade survives it, and the commands ran with whatever privilege the postjournal path holds on the mail server the packet names as the drop location. The default response is therefore preserve and export the configuration and logs first, rebuild the server from a known-good image already at the fixed level rather than upgrading the exposed one in place, and rotate the credentials that server held or that authenticated through it during the exposure window. The absence of an anti-malware alert is specifically not evidence of a clean server here: the packet's own malware-protection gap records that mail controls scan attachment and body content for signatures and pass shell metacharacters in the CC header as clean, so the delivery that dropped the webshell is exactly the event those controls did not see, and 'nothing was flagged' cannot be the basis for choosing patch-in-place.",
-        "evidence": "Packet: active_exploitation confirmed; active_exploitation_notes state attackers sent spoofed emails with base64-encoded shell commands in the CC field to drop webshells on internet-facing Zimbra servers, mass-exploited beginning 2024-09-28, used for broad opportunistic RCE and not flagged as ransomware by CISA. attack_vector: postjournal parses SMTP CC-header content and executes base64-decoded shell commands via sh without authentication, letting attackers send a crafted email to drop a webshell on the mail server. patch_available true with fixed levels 8.8.15 Patch 46 / 9.0.0 Patch 41 / 10.0.9 / 10.1.1; live_patch_available false. The ISO-27001-2022-A.8.7 gap states email malware protections scan attachment and body content for signatures, not shell metacharacters in the CC header, so the unauthenticated command execution rides in on mail those controls pass as clean. The Essential Eight gap records the mass-exploitation wave documented by Proofpoint across the Zimbra install base.",
+        "description": "What matters is not just that Zimbra was exploited but what the attackers did with it: spoofed emails carrying base64-encoded shell commands in the CC field, dropping webshells on internet-facing Zimbra servers throughout the wave that began 2024-09-28. Applied to this product, the requirement is that any ZCS server sitting below its branch's fixed level during that wave is handled as an incident, not as a patch ticket. Upgrading to 8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9 or 10.1.1 closes the injection path and removes nothing already written through it: a webshell placed before the upgrade survives it, and the commands ran with whatever privilege the postjournal path holds on the mail server where the webshell was dropped. The default response is therefore preserve and export the configuration and logs first, rebuild the server from a known-good image already at the fixed level rather than upgrading the exposed one in place, and rotate the credentials that server held or that authenticated through it during the exposure window. The absence of an anti-malware alert is specifically not evidence of a clean server here: the malware-protection gap records that mail controls scan attachment and body content for signatures and pass shell metacharacters in the CC header as clean, so the delivery that dropped the webshell is exactly the event those controls did not see, and 'nothing was flagged' cannot be the basis for choosing patch-in-place.",
+        "evidence": "Active exploitation is confirmed. Attackers sent spoofed emails with base64-encoded shell commands in the CC field to drop webshells on internet-facing Zimbra servers. The CVE was mass-exploited beginning 2024-09-28, was used for broad opportunistic RCE, and is not flagged as ransomware by CISA. Postjournal parses SMTP CC-header content and executes base64-decoded shell commands via sh without authentication, letting attackers send a crafted email to drop a webshell on the mail server. Fixed releases are available at 8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9 and 10.1.1, and no live patch is available. The ISO-27001-2022-A.8.7 gap states email malware protections scan attachment and body content for signatures, not shell metacharacters in the CC header, so the unauthenticated command execution rides in on mail those controls pass as clean. The Essential Eight gap records the mass-exploitation wave documented by Proofpoint across the Zimbra install base.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "AU-Essential-8-Patch",
@@ -44823,7 +44823,7 @@
         "id": "NEW-CTRL-125",
         "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
         "description": "postjournal is the internal service channel this control governs. The packet has it receiving SMTP CC-header content from the mail pipeline and executing base64-decoded shell commands through sh with no authentication — an internal component evaluating the content it is handed rather than merely parsing it, on the inherited assumption that anything arriving from the MTA is already trusted. Bound to ZCS, the requirement is that a component reached over an internal service channel constrain or authenticate what that channel delivers, so mail-header content cannot reach a shell-evaluation sink; that is a property to verify on the fixed builds (8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9, 10.1.1), not something an operator can add to an unpatched install. The precondition has to be stated plainly because this is where the control is most easily over-claimed: the documented delivery path is an ordinary inbound email, so restricting network reachability is not available as a compensating control here — an internet-facing mail server must accept mail from arbitrary senders, and that acceptance is the exploit path. This is exactly why the boundary-protection gap is recorded against this entry: perimeter filtering sits in front of the SMTP listener, not between the MTA and postjournal, and inspects neither CC-header content for command injection nor the internal hand-off. The distinguishing test is a per-node build check against the fixed level for that node's branch; an attestation that the mail perimeter filters inbound traffic passes cleanly while this path stays open.",
-        "evidence": "Packet: attack_vector states postjournal parses SMTP CC-header content and executes base64-decoded shell commands via sh without authentication. affected: the postjournal service, which sometimes allows unauthenticated users to execute OS commands via crafted SMTP header content. cwe_refs CWE-78. The NIST-800-53-SC-7 gap states postjournal listens for SMTP-adjacent input with no boundary filtering on CC-header content and that typical perimeter controls do not inspect mail-header command-injection patterns. The UK-CAF-B4 gap states secure configuration guidance for on-prem mail servers does not typically address internal service-to-service trust boundaries like postjournal's unauthenticated command execution. patch_available true with the branch-specific fixed levels in affected_versions; live_patch_available false, live_patch_notes null.",
+        "evidence": "Postjournal parses SMTP CC-header content and executes base64-decoded shell commands via sh without authentication. The affected component is the postjournal service, which sometimes allows unauthenticated users to execute OS commands via crafted SMTP header content. The weakness is CWE-78. The NIST-800-53-SC-7 gap states postjournal listens for SMTP-adjacent input with no boundary filtering on CC-header content and that typical perimeter controls do not inspect mail-header command-injection patterns. The UK-CAF-B4 gap states secure configuration guidance for on-prem mail servers does not typically address internal service-to-service trust boundaries like postjournal's unauthenticated command execution. Fixed releases are available at branch-specific fixed levels, and no live patch is available.",
         "gap_closes": [
           "NIST-800-53-SC-7",
           "UK-CAF-B4"
@@ -44872,8 +44872,8 @@
       {
         "id": "NEW-CTRL-085",
         "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
-        "description": "The injection sink the packet names sits inside a shipped Ivanti binary — SQL injection in RecordGoodApp (PatchBiz.dll) on the Ivanti Endpoint Manager Core server, reached by a crafted goodApp.md5 value sent to /WSStatusEvents/EventHandler — so the parameterization this control requires is a property of the vendor's query construction, not of anything the operator writes. That makes the operator-side expression a verification duty: require the fixed Ivanti release on any Core server running EPM 2022 SU5 or prior, and prove the injection path is closed by exercising it rather than by reading a version. Distinguishing test, taken straight from the packet's own path: on a staging Core server, send a goodApp.md5 value carrying a SQL metacharacter to /WSStatusEvents/EventHandler and confirm it is parameterized rather than concatenated into a query. The control's second premise is the load-bearing one here — the packet's attacker is unauthenticated and on the same network, so a perimeter WAF and an assumption that the Core server is internal never see the request, leaving the query layer as the only place the input is neutralized. Precondition: this control states the property to verify, it does not implement it; the repair is the vendor's. There is no live-patch path, so each Core server has to be taken through the vendor update, and until that update lands the only operator-side lever is restricting which network segments can reach /WSStatusEvents/EventHandler — which bounds who can send the request but leaves the endpoint fully exploitable to anything inside a permitted segment, and is unavailable where managed endpoints must keep reaching that service for normal operation.",
-        "evidence": "Packet vector: 'An unspecified SQL Injection vulnerability in Core server of Ivanti EPM 2022 SU5 and prior allows an unauthenticated attacker within the same network to execute arbitrary code.' Packet attack_vector: 'An unauthenticated attacker on the same network sends a crafted goodApp.md5 value to the EPM Core server's /WSStatusEvents/EventHandler endpoint, exploiting SQL injection in RecordGoodApp (PatchBiz.dll) to reach xp_cmdshell and execute arbitrary commands.' CWE-89; cisa_kev true, kev_date 2024-10-02, active_exploitation confirmed; poc_available true; CVSS 8.8, RWEP 70; patch_available true; live_patch_available false, live_patch_notes null.",
+        "description": "The injection sink for this CVE sits inside a shipped Ivanti binary: SQL injection in RecordGoodApp (PatchBiz.dll) on the Ivanti Endpoint Manager Core server, reached by a crafted goodApp.md5 value sent to /WSStatusEvents/EventHandler. The parameterization this control requires is therefore a property of the vendor's query construction, not of anything the operator writes. That makes the operator-side expression a verification duty: require the fixed Ivanti release on any Core server running EPM 2022 SU5 or prior, and prove the injection path is closed by exercising it rather than by reading a version. Distinguishing test, taken straight from the attack path: on a staging Core server, send a goodApp.md5 value carrying a SQL metacharacter to /WSStatusEvents/EventHandler and confirm it is parameterized rather than concatenated into a query. The control's second premise is the load-bearing one here: the attacker is unauthenticated and on the same network, so a perimeter WAF and an assumption that the Core server is internal never see the request, leaving the query layer as the only place the input is neutralized. Precondition: this control states the property to verify, it does not implement it; the repair is the vendor's. There is no live-patch path, so each Core server has to be taken through the vendor update, and until that update lands the only operator-side lever is restricting which network segments can reach /WSStatusEvents/EventHandler. That restriction bounds who can send the request but leaves the endpoint fully exploitable to anything inside a permitted segment, and it is unavailable where managed endpoints must keep reaching that service for normal operation.",
+        "evidence": "An unspecified SQL Injection vulnerability in Core server of Ivanti EPM 2022 SU5 and prior allows an unauthenticated attacker within the same network to execute arbitrary code. In the attack path, an unauthenticated attacker on the same network sends a crafted goodApp.md5 value to the EPM Core server's /WSStatusEvents/EventHandler endpoint, exploiting SQL injection in RecordGoodApp (PatchBiz.dll) to reach xp_cmdshell and execute arbitrary commands. The weakness is CWE-89. CISA lists it in its Known Exploited Vulnerabilities catalog, added on 2024-10-02, and active exploitation is confirmed. A proof of concept is available. It carries CVSS 8.8 and an RWEP score of 70. A fixed release is available, and no live patch is available.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "NIST-800-53-SI-2",
@@ -44883,8 +44883,8 @@
       {
         "id": "NEW-CTRL-060",
         "name": "DATABASE-SERVER-SIDE-SCRIPTING-DEFAULT-DENY",
-        "description": "The packet's chain does not stop at data access: the injection in RecordGoodApp reaches xp_cmdshell and from there executes arbitrary commands on the EPM Core server. That final step is a database-engine feature that runs operating-system commands, and it is what converts an injection into the arbitrary code execution the packet's vector describes. Bound to this deployment, the control means the database instance behind the Ivanti EPM Core server carries no enabled OS-command path, and the login the Core server authenticates with cannot invoke one — with any enabled state carrying a documented, dated threat-model acceptance that names the function requiring it, rather than being inherited from an installation choice or a troubleshooting session nobody reverted. Distinguishing test: on a staging Core server, attempt an operating-system command through the database engine using the login the EPM Core server itself uses, and confirm it is refused — an application patch-level attestation says nothing about whether that path is open. Precondition, and it decides whether the control is available at all: denying the command path does not repair the injection. An unauthenticated attacker on the same network still reaches the vulnerable query through /WSStatusEvents/EventHandler and still reads and writes the EPM database, and there is no basis for treating that as harmless. If the Ivanti deployment genuinely requires the privilege for a product function, this lever is unavailable and the vendor update is the only closure — establish which of those two states each Core server is in rather than assuming a default.",
-        "evidence": "Packet attack_vector: the crafted goodApp.md5 value sent to '/WSStatusEvents/EventHandler' exploits 'SQL injection in RecordGoodApp (PatchBiz.dll) to reach xp_cmdshell and execute arbitrary commands.' Packet vector: the flaw 'allows an unauthenticated attacker within the same network to execute arbitrary code' against 'Core server of Ivanti EPM 2022 SU5 and prior.' CWE-89; CVSS 8.8, RWEP 70; poc_available true; patch_available true; live_patch_available false, live_patch_notes null.",
+        "description": "The attack chain does not stop at data access: the injection in RecordGoodApp reaches xp_cmdshell and from there executes arbitrary commands on the EPM Core server. That final step is a database-engine feature that runs operating-system commands, and it is what converts an injection into the arbitrary code execution described for this CVE. Bound to this deployment, the control means that the database instance behind the Ivanti EPM Core server carries no enabled OS-command path, that the login the Core server authenticates with cannot invoke one, and that any enabled state carries a documented, dated threat-model acceptance that names the function requiring it, rather than being inherited from an installation choice or a troubleshooting session nobody reverted. Distinguishing test: on a staging Core server, attempt an operating-system command through the database engine using the login the EPM Core server itself uses, and confirm it is refused. An application patch-level attestation says nothing about whether that path is open. Precondition, and it decides whether the control is available at all: denying the command path does not repair the injection. An unauthenticated attacker on the same network still reaches the vulnerable query through /WSStatusEvents/EventHandler and still reads and writes the EPM database, and there is no basis for treating that as harmless. If the Ivanti deployment genuinely requires the privilege for a product function, this lever is unavailable and the vendor update is the only closure. Establish which of those two states each Core server is in rather than assuming a default.",
+        "evidence": "The crafted goodApp.md5 value sent to /WSStatusEvents/EventHandler exploits SQL injection in RecordGoodApp (PatchBiz.dll) to reach xp_cmdshell and execute arbitrary commands. The flaw allows an unauthenticated attacker within the same network to execute arbitrary code against the Core server of Ivanti EPM 2022 SU5 and prior. The weakness is CWE-89, and it carries CVSS 8.8 and an RWEP score of 70. A proof of concept is available, a fixed release is available, and no live patch is available.",
         "gap_closes": [
           "ISO-27001-2022-A.5.15",
           "UK-CAF-B4"
@@ -44894,7 +44894,7 @@
         "id": "NEW-CTRL-037",
         "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
         "description": "The packet's end state is arbitrary command execution on the Core server of Ivanti Endpoint Manager — the management server of an endpoint-management product — so the exposure is the estate of endpoints that server administers, not the one host, and the response has to be scoped that way. The window matters here more than on most entries: KEV listing is 2024-10-02, active_exploitation is confirmed, and poc_available is true, so a working exploit was in circulation across whatever interval separated the listing from each operator's update. Applied to this product, the playbook covers what the Core server distributed or instructed to managed endpoints during that window, a defined quarantine criterion for endpoints that acted on those instructions, and rotation of credentials that were used or authenticated through the Core server while it was exposed. Precondition: this is response, not prevention. It stops no injection, and it applies specifically to Core servers that were reachable by an unauthenticated party on the same network during the exposure window — which, given the packet places the attacker on the same network rather than across the perimeter, includes instances an operator considers internal-only. Applying the vendor update to a Core server that already executed attacker commands neither removes what was left behind nor re-validates what it pushed downstream, and closing the finding on the patch is exactly the failure this control exists to prevent.",
-        "evidence": "Packet: CWE-89 SQL injection in 'Core server of Ivanti EPM 2022 SU5 and prior' allowing 'an unauthenticated attacker within the same network to execute arbitrary code'; attack_vector ends in 'xp_cmdshell and execute arbitrary commands.' cisa_kev true, kev_date 2024-10-02; active_exploitation confirmed; poc_available true; CVSS 8.8, RWEP 70; patch_available true; live_patch_available false, live_patch_notes null.",
+        "evidence": "A CWE-89 SQL injection in the Core server of Ivanti EPM 2022 SU5 and prior allows an unauthenticated attacker within the same network to execute arbitrary code, and the attack path ends by reaching xp_cmdshell to execute arbitrary commands. CISA lists it in its Known Exploited Vulnerabilities catalog, added on 2024-10-02, and active exploitation is confirmed. A proof of concept is available. It carries CVSS 8.8 and an RWEP score of 70. A fixed release is available, and no live patch is available.",
         "gap_closes": [
           "NIS2-Art21-vulnerability-management"
         ]
@@ -44942,8 +44942,8 @@
       {
         "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
-        "description": "This packet offers no interim state: patch_available is false, no live-patch path is recorded, the vendor no longer supports the product, and CISA's listed required action is to discontinue use rather than remediate. So for the DIR-820 the control reduces to its retirement half, and there is no fixed firmware level that would ever close the ticket. Produce an inventory naming every D-Link DIR-820 in service with its hardware revision and running firmware — the packet names DIR820LA1_FW105B03 explicitly and describes later end-of-life firmware only as likely affected, so per-unit status has to be obtained from the vendor or the KEV entry rather than asserted in either direction — and put every unit on a dated replacement schedule running from the 2024-09-30 KEV listing. A risk acceptance with no removal date leaves a device carrying an unauthenticated root command-execution path, with a public PoC and confirmed exploitation, in service indefinitely. Keep the programme scoped to what the packet establishes: it ties the ping.ccp injection to the DIR-820 and gives no mapping into other D-Link models, so a replacement sweep aimed at every D-Link router in the estate manufactures removal work against devices no evidence implicates. Precondition on the interim reachability measure, which is where this is most often over-claimed: the injection sits in the ping.ccp CGI handler on the router's web administration surface, so where the firmware offers a remote-administration toggle, disabling it bounds who can reach that surface from the internet — but a router of this class exists to serve the client network attached to it, and every client on that network still reaches the administration surface. For a unit serving a general user network there is no segment that removes the path, only isolation of that network from anything that matters until the replacement lands.",
-        "evidence": "Packet: patch_available false; live_patch_available false; live_patch_notes null. affected_versions: 'DIR820LA1_FW105B03 and likely later EoL firmware — vendor no longer supports the product.' active_exploitation_notes: 'Actively exploited against end-of-life D-Link DIR-820 routers; CISA added it to KEV noting the product is EoL/EoS with no vendor patch forthcoming, and the required action is to discontinue use rather than remediate.' kev_date 2024-09-30; poc_available true; cvss 9.8; rwep_score 80. attack_vector: 'A remote, unauthenticated attacker sends a crafted request to the router's ping.ccp CGI handler with shell metacharacters embedded in the ping_addr parameter, achieving root command execution.' NIST-800-53-SI-2 gap: 'flaw remediation as a control is structurally unavailable, and CISA's required action is decommissioning rather than patching.' ISO-27001-2022-A.8.9 gap: 'on this EoL DIR-820 the hardened baseline A.8.9 expects can't be applied, forcing replacement over configuration.'",
+        "description": "This CVE offers no interim state: no fixed release is available, no live-patch path is recorded, the vendor no longer supports the product, and CISA's listed required action is to discontinue use rather than remediate. So for the DIR-820 the control reduces to its retirement half, and there is no fixed firmware level that would ever close the ticket. Produce an inventory naming every D-Link DIR-820 in service with its hardware revision and running firmware, and put every unit on a dated replacement schedule running from the 2024-09-30 KEV listing. DIR820LA1_FW105B03 is named explicitly as affected and later end-of-life firmware is described only as likely affected, so per-unit status has to be obtained from the vendor or the KEV entry rather than asserted in either direction. A risk acceptance with no removal date leaves a device carrying an unauthenticated root command-execution path, with a public PoC and confirmed exploitation, in service indefinitely. Keep the program scoped to what is established: the ping.ccp injection is tied to the DIR-820 and no mapping into other D-Link models is given, so a replacement sweep aimed at every D-Link router in the estate manufactures removal work against devices no evidence implicates. Precondition on the interim reachability measure, which is where this is most often over-claimed: the injection sits in the ping.ccp CGI handler on the router's web administration surface, so where the firmware offers a remote-administration toggle, disabling it bounds who can reach that surface from the internet. But a router of this class exists to serve the client network attached to it, and every client on that network still reaches the administration surface. For a unit serving a general user network there is no segment that removes the path, only isolation of that network from anything that matters until the replacement lands.",
+        "evidence": "No fixed release is available and no live patch is available. The affected versions are DIR820LA1_FW105B03 and likely later EoL firmware, and the vendor no longer supports the product. The flaw is actively exploited against end-of-life D-Link DIR-820 routers. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-09-30, noting the product is EoL/EoS with no vendor patch forthcoming, and the required action is to discontinue use rather than remediate. A proof of concept is available, the CVSS score is 9.8, and it carries an RWEP score of 80. A remote, unauthenticated attacker sends a crafted request to the router's ping.ccp CGI handler with shell metacharacters embedded in the ping_addr parameter, achieving root command execution. The NIST-800-53-SI-2 gap states that 'flaw remediation as a control is structurally unavailable, and CISA's required action is decommissioning rather than patching.' The ISO-27001-2022-A.8.9 gap states that 'on this EoL DIR-820 the hardened baseline A.8.9 expects can't be applied, forcing replacement over configuration.'",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "AU-Essential-8-Patch",
@@ -44956,8 +44956,8 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "A DIR-820 is the network edge for whatever sits behind it, and the packet's path is unauthenticated root command execution on that edge, with a public PoC and confirmed exploitation. The patch-in-place branch this control warns against does not even exist here, which makes its response default the only one available: for a unit that was reachable while in service, treat the device as compromised rather than recoverable. A factory reset returns it to DIR820LA1_FW105B03 — the firmware the packet names as vulnerable — so resetting restores the exploit path instead of removing what an attacker left, and the administrative password and any wireless key held in the device's configuration are within reach of an attacker who reached root, so they are reissued on the replacement rather than carried across from a configuration backup. Precondition: this governs units that were reachable during the exposure window, and a consumer-class router of this kind generally produces no telemetry that would establish whether a given unit was reached, so for an internet-reachable DIR-820 the operating assumption has to be that it was. This control decides how a unit is retired, not whether — the packet's stated action is discontinuing use, and nothing here substitutes for that.",
-        "evidence": "Packet vector: 'OS Command injection vulnerability in D-Link DIR820LA1_FW105B03 allows attackers to escalate privileges to root via a crafted payload with the ping_addr parameter to ping.ccp.' active_exploitation confirmed; poc_available true; rwep_score 80; cvss 9.8. patch_available false and live_patch_notes null, so no fixed firmware exists to apply in place. affected_versions records that the vendor no longer supports the product, and active_exploitation_notes records CISA's required action as discontinuing use rather than remediating. AU-Essential-8-Patch gap: 'Patch-management maturity is unachievable for EoL hardware — the only compensating action is replacement.'",
+        "description": "A DIR-820 is the network edge for whatever sits behind it, and the attack path is unauthenticated root command execution on that edge, with a public PoC and confirmed exploitation. The patch-in-place branch this control warns against does not even exist here, which makes its response default the only one available: for a unit that was reachable while in service, treat the device as compromised rather than recoverable. A factory reset returns it to DIR820LA1_FW105B03, the firmware named as vulnerable, so resetting restores the exploit path instead of removing what an attacker left. The administrative password and any wireless key held in the device's configuration are within reach of an attacker who reached root, so they are reissued on the replacement rather than carried across from a configuration backup. Precondition: this governs units that were reachable during the exposure window, and a consumer-class router of this kind generally produces no telemetry that would establish whether a given unit was reached, so for an internet-reachable DIR-820 the operating assumption has to be that it was. This control decides how a unit is retired, not whether. CISA's required action is to discontinue use, and nothing here substitutes for that.",
+        "evidence": "An OS Command injection vulnerability in D-Link DIR820LA1_FW105B03 allows attackers to escalate privileges to root via a crafted payload with the ping_addr parameter to ping.ccp. Active exploitation is confirmed and a proof of concept is available; it carries an RWEP score of 80 and CVSS 9.8. No fixed release is available and no live patch is described, so no fixed firmware exists to apply in place. The vendor no longer supports the product, and CISA's required action is discontinuing use rather than remediating. The AU-Essential-8-Patch gap states that patch-management maturity is unachievable for EoL hardware and that the only compensating action is replacement.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "AU-Essential-8-Patch"
@@ -45006,8 +45006,8 @@
       {
         "id": "NEW-CTRL-030",
         "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
-        "description": "The Vigor3900, Vigor2960 and Vigor300B are WAN edge devices, and this is an unauthenticated remote command execution running as root on them — the trust boundary itself executing an attacker's commands, which is the case this SLA tier exists for and which a standard 14/30-day appliance window does not fit. The fact that makes this entry different from a normal KEV item is the age of the fix: firmware 1.5.1 has existed since 2020 and CISA listed the flaw on 2024-09-30, so the tier's clock must restart at the KEV listing rather than be treated as long expired. A vulnerability process that ingests advisories only at publication never re-opens a four-year-old fix, which is exactly how the packet's actively-targeted unpatched population stays in service. Operationally: enumerate every Vigor3900, Vigor2960 and Vigor300B in the estate and record each unit's running firmware against 1.5.1. Scope the sweep to those three models — the packet names them in both affected and affected_versions and ties the cvmcfgupload defect to that firmware line, so widening it to DrayTek's range generally manufactures work against models no evidence implicates. The tier's second branch is the one that matters when the window cannot be met: patch_required_reboot is true and live_patch_available is false, so there is no way to fix a unit without taking its reboot, and a unit whose reboot cannot be scheduled inside the window must have the vulnerable interface isolated — the WAN-facing management and CGI surface — rather than being carried as an accepted risk. Completion is measured on the firmware the device reports after that reboot; a unit with 1.5.1 staged but not yet restarted onto it is still running the vulnerable code and counts as exposed.",
-        "evidence": "Packet: affected is 'DrayTek Vigor3900, Vigor2960, and Vigor300B devices before firmware 1.5.1', with affected_versions listing 'Vigor3900 before 1.5.1', 'Vigor2960 before 1.5.1', 'Vigor300B before 1.5.1'. cisa_kev true, kev_date 2024-09-30, active_exploitation confirmed, with active_exploitation_notes recording exploitation of internet-facing management interfaces and KEV addition in September 2024 'despite the flaw and vendor fix dating to 2020, indicating a long tail of unpatched exposed devices continuing to be targeted'. The NIST-800-53-SI-2 gap states 'patch-management enforcement, not availability, is the gap'; the NIST-800-53-SC-7 gap states the configuration-upload CGI endpoint 'is commonly left reachable from the WAN interface with no boundary restriction to trusted management networks'. attack_vector has command execution as root. patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes null; poc_available true; cvss 9.8; rwep_score 73.",
+        "description": "The Vigor3900, Vigor2960 and Vigor300B are WAN edge devices, and this is an unauthenticated remote command execution running as root on them: the trust boundary itself executes an attacker's commands, which is the case this SLA tier exists for and which a standard 14/30-day appliance window does not fit. The fact that makes this entry different from a normal KEV item is the age of the fix: firmware 1.5.1 has existed since 2020 and CISA listed the flaw on 2024-09-30, so the tier's clock must restart at the KEV listing rather than be treated as long expired. A vulnerability process that ingests advisories only at publication never re-opens a four-year-old fix, which is exactly how the actively targeted unpatched population stays in service. Operationally: enumerate every Vigor3900, Vigor2960 and Vigor300B in the estate and record each unit's running firmware against 1.5.1. Scope the sweep to those three models. They are the models named as affected, both by product and by version, and the cvmcfgupload defect is tied to that firmware line, so widening it to DrayTek's range generally manufactures work against models no evidence implicates. The tier's second branch is the one that matters when the window cannot be met: the fix requires a reboot and no live patch is available, so there is no way to fix a unit without taking its reboot. A unit whose reboot cannot be scheduled inside the window must have the vulnerable interface (the WAN-facing management and CGI surface) isolated rather than being carried as an accepted risk. Completion is measured on the firmware the device reports after that reboot; a unit with 1.5.1 staged but not yet restarted onto it is still running the vulnerable code and counts as exposed.",
+        "evidence": "The affected products are DrayTek Vigor3900, Vigor2960, and Vigor300B devices before firmware 1.5.1, listed per model as Vigor3900 before 1.5.1, Vigor2960 before 1.5.1, and Vigor300B before 1.5.1. CISA lists it in its Known Exploited Vulnerabilities catalog, added on 2024-09-30, and active exploitation is confirmed. Attackers exploited internet-facing management interfaces, and the KEV addition in September 2024 came despite the flaw and vendor fix dating to 2020, indicating a long tail of unpatched exposed devices continuing to be targeted. The NIST-800-53-SI-2 gap states 'patch-management enforcement, not availability, is the gap'; the NIST-800-53-SC-7 gap states the configuration-upload CGI endpoint 'is commonly left reachable from the WAN interface with no boundary restriction to trusted management networks'. The attack achieves command execution as root. A fixed release is available and the fix requires a reboot; no live patch is available. A proof of concept is available, the CVSS score is 9.8, and it carries an RWEP score of 73.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "AU-Essential-8-Patch",
@@ -45019,7 +45019,7 @@
         "id": "NEW-CTRL-134",
         "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
         "description": "The sink here is a configuration-upload endpoint on the router's own management CGI — cgi-bin/mainfunction.cgi/cvmcfgupload — and the attacker input is the uploaded file's name rather than its contents: shell metacharacters in the filename, sent with a text/x-python-script content type, reach an OS command that runs as root, with no credential presented. Bound to this device, the control is both halves at once. The endpoint authorizes its caller before the upload is processed at all, so an unauthenticated request never reaches the handler; and the caller-supplied filename is neutralized before any command is constructed from it, which for a filename means it is never allowed to become part of a shell string. Treating the upload's content type or body as the untrusted part and the filename as metadata is the specific mistake this CVE punishes. The third requirement is reachability: no Vigor unit leaves that CGI answering on the WAN interface or from any segment with no operational need to administer it, which is what the cited configuration-management and system-security gaps record as absent — a WAN-reachable cvmcfgupload and edge-device baselines that do not disable remote administrative CGI endpoints by default. Distinguishing test: from an untrusted network against a staging Vigor, POST to cgi-bin/mainfunction.cgi/cvmcfgupload with shell metacharacters in the filename and the text/x-python-script content type, and confirm the request is refused before any command executes — a unit that passes an administrative-password audit while answering that request is still fully exploitable, because the attacker never authenticates. Precondition: the endpoint-side authorization and filename neutralization are properties the 1.5.1 firmware establishes; this control states what to verify, it does not implement it. Until 1.5.1 and its reboot land, disabling WAN-side administration bounds who can reach the CGI from the internet but leaves it exploitable from anything inside a permitted segment, and it is unavailable where the unit must be administered remotely.",
-        "evidence": "Packet vector: 'On DrayTek Vigor3900, Vigor2960, and Vigor300B devices before 1.5.1, cgi-bin/mainfunction.cgi/cvmcfgupload allows remote command execution via shell metacharacters in a filename when the text/x-python-script content type is used'. attack_vector: 'An unauthenticated remote attacker uploads a crafted configuration file with shell metacharacters in the filename to cgi-bin/mainfunction.cgi/cvmcfgupload using a text/x-python-script content type, achieving command execution as root.' The ISO-27001-2022-A.8.9 gap states secure-configuration management 'doesn't disable the WAN-reachable cvmcfgupload CGI on DrayTek Vigor edge devices, so the filename-metacharacter OS command injection stays exploitable years after the fix shipped'; the UK-CAF-B4 gap states baselines 'should disable remote administrative CGI endpoints by default; many deployments leave them exposed'; the NIST-800-53-SC-7 gap records the endpoint left reachable from the WAN with no boundary restriction. cwe_refs CWE-78; patch_available true with the fix at firmware 1.5.1; patch_required_reboot true; live_patch_available false; poc_available true.",
+        "evidence": "On DrayTek Vigor3900, Vigor2960, and Vigor300B devices before 1.5.1, cgi-bin/mainfunction.cgi/cvmcfgupload allows remote command execution via shell metacharacters in a filename when the text/x-python-script content type is used. An unauthenticated remote attacker uploads a crafted configuration file with shell metacharacters in the filename to cgi-bin/mainfunction.cgi/cvmcfgupload using a text/x-python-script content type, achieving command execution as root. The ISO-27001-2022-A.8.9 gap states secure-configuration management 'doesn't disable the WAN-reachable cvmcfgupload CGI on DrayTek Vigor edge devices, so the filename-metacharacter OS command injection stays exploitable years after the fix shipped'; the UK-CAF-B4 gap states baselines 'should disable remote administrative CGI endpoints by default; many deployments leave them exposed'; the NIST-800-53-SC-7 gap records the endpoint left reachable from the WAN with no boundary restriction. The weakness is CWE-78. A fixed release is available, with the fix at firmware 1.5.1, and the fix requires a reboot; no live patch is available. A proof of concept is available.",
         "gap_closes": [
           "NIST-800-53-SC-7",
           "ISO-27001-2022-A.8.9",
@@ -45079,8 +45079,8 @@
       {
         "id": "NEW-CTRL-128",
         "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
-        "description": "The packet's attack vector puts this CVE squarely in the binary remoting-protocol class this control governs: the virtualjdbc extension exposes Java serialization over HTTP, RMI and JMXMP, the listener answers a caller that never authenticates, and the deserializer behind it is the vulnerable code — so a storefront WAF, TLS termination and web-tier hardening, which is what a Commerce Cloud deployment is usually audited against, never sit in front of the path that gets exploited. For this deployment the requirement is that the virtualjdbc and mediaconversion listeners accept connections only from the hosts that legitimately speak those protocols — the application-tier nodes and the administrative or integration hosts that actually use them — enforced by network ACL or host firewall rather than inferred from 'the Hybris cluster is internal', and that where an extension is not required by the deployment it is removed from the enabled extension set rather than left listening. Distinguishing test for this product: from a general user VLAN or an internet-facing segment against a staging node, open a connection to each RMI/JMXMP/HTTP serialization endpoint the two extensions expose and confirm the peer is dropped before the node reads any serialized content — an estate that passes storefront penetration tests and Commerce Cloud role audits while leaving the serialization listener reachable from any internal segment is still exposed to the unauthenticated gadget-chain path. Precondition, which is where this control is most often over-claimed: restricting reachability bounds who can send the payload, it does not remove the deserialization sink. Any host inside the permitted set still reaches it, so this is interim to applying the SAP fix on the affected release — and it is unavailable where an integration genuinely requires the listener to answer, in which case the permitted set is the named integration hosts and nothing else.",
-        "evidence": "Packet attack_vector: 'SAP Commerce Cloud's virtualjdbc extension exposes Java serialization over HTTP/RMI/JMXMP; an attacker sends a crafted gadget-chain serialized payload directly to the exposed listener to achieve remote code execution as the \"Hybris\" OS user.' The vector text records the flaw as 'unsafe deserialization used in SAP Commerce Cloud (virtualjdbc extension), versions 6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905', and affected additionally names the mediaconversion extension. The NIST-800-53-SC-7 gap records that 'The virtualjdbc/JMXMP listener should never be reachable from untrusted networks, yet exploitation presumes direct network access to it — boundary protection was not enforced'; the UK-CAF-B4 gap records that 'Secure configuration guidance should have disabled or firewalled the legacy virtualjdbc extension where unused; long-tail exposure suggests this was not audited.' cvss 9.8, poc_available true, active_exploitation confirmed, patch_available true.",
+        "description": "The attack path puts this CVE squarely in the binary remoting-protocol class this control governs: the virtualjdbc extension exposes Java serialization over HTTP, RMI and JMXMP, the listener answers a caller that never authenticates, and the deserializer behind it is the vulnerable code. A storefront WAF, TLS termination and web-tier hardening, which is what a Commerce Cloud deployment is usually audited against, therefore never sit in front of the path that gets exploited. For this deployment the requirement is that the virtualjdbc and mediaconversion listeners accept connections only from the hosts that legitimately speak those protocols (the application-tier nodes and the administrative or integration hosts that actually use them), enforced by network ACL or host firewall rather than inferred from 'the Hybris cluster is internal', and that where an extension is not required by the deployment it is removed from the enabled extension set rather than left listening. Distinguishing test for this product: from a general user VLAN or an internet-facing segment against a staging node, open a connection to each RMI/JMXMP/HTTP serialization endpoint the two extensions expose and confirm the peer is dropped before the node reads any serialized content. An estate that passes storefront penetration tests and Commerce Cloud role audits while leaving the serialization listener reachable from any internal segment is still exposed to the unauthenticated gadget-chain path. Precondition, which is where this control is most often over-claimed: restricting reachability bounds who can send the payload, it does not remove the deserialization sink. Any host inside the permitted set still reaches it, so this is interim to applying the SAP fix on the affected release. It is also unavailable where an integration genuinely requires the listener to answer, in which case the permitted set is the named integration hosts and nothing else.",
+        "evidence": "SAP Commerce Cloud's virtualjdbc extension exposes Java serialization over HTTP/RMI/JMXMP; an attacker sends a crafted gadget-chain serialized payload directly to the exposed listener to achieve remote code execution as the \"Hybris\" OS user. The flaw is unsafe deserialization used in SAP Commerce Cloud (virtualjdbc extension), versions 6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905, and the mediaconversion extension is also named as affected. The NIST-800-53-SC-7 gap records that the virtualjdbc/JMXMP listener should never be reachable from untrusted networks, yet exploitation presumes direct network access to it; boundary protection was not enforced. The UK-CAF-B4 gap records that 'Secure configuration guidance should have disabled or firewalled the legacy virtualjdbc extension where unused; long-tail exposure suggests this was not audited.' The CVSS score is 9.8, a proof of concept is available, active exploitation is confirmed, and a fixed release is available.",
         "gap_closes": [
           "NIST-800-53-SC-7",
           "UK-CAF-B4"
@@ -45089,8 +45089,8 @@
       {
         "id": "NEW-CTRL-018",
         "name": "SCANNER-PAPER-COMPLIANCE-TEST",
-        "description": "What the packet documents is not a patch decision that went wrong but five years in which nobody's tooling reported the exposure: SAP shipped the fix in 2019 and the entry reached KEV in September 2024 against internet-facing Commerce Cloud instances that were never patched. For this CVE the control means a scan result of 'patched' derived from the Commerce Cloud platform release banner is paper compliance, because the vulnerable code lives in the virtualjdbc and mediaconversion extensions and exposure is decided by two facts a banner cannot carry — whether those extensions are in the node's enabled extension set, and whether their Java serialization listener answers from a segment the node should not be answering. The operational test has both parts: an authenticated inventory of the enabled extension set on every Commerce Cloud node, compared against the affected releases the packet names (6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905) and against the version of the extension code the running platform process is actually serving rather than the artifact sitting on disk; and an unauthenticated reachability probe of the HTTP/RMI/JMXMP serialization listener from outside the application tier. A node that passes on its release string while the extension is loaded and the listener answers counts as unverified, not as compliant. This is also the test that distinguishes an asset register from an inventory: the packet's own gap describes long-lived deployments that no patch-verification process ever saw, and a scanner that cannot reach or authenticate to the Hybris node will report the same clean result for a node that does not exist, a node that is patched, and a node that has been exploitable since 2019.",
-        "evidence": "Packet active_exploitation_notes: 'An aged (2019) flaw added to CISA KEV in September 2024, indicating renewed/ongoing active exploitation against internet-facing SAP Commerce Cloud (Hybris) instances that were never patched — likely opportunistic scanning against long-lived unpatched deployments rather than a fresh campaign. Not flagged as ransomware.' kev_date 2024-09-30; cisa_kev true; active_exploitation confirmed; poc_available true; patch_available true; patch_required_reboot false; live_patch_notes null. The NIST-800-53-SI-2 gap records that 'SAP shipped a fix in 2019, but KEV addition in 2024 shows five years of unpatched exposure among internet-facing instances — patch-SLA enforcement failed long-term, not just at disclosure'; the NIS2-Art21-vulnerability-management gap records that 'A five-year-old known-fixed flaw remaining exploitable at scale indicates an absent asset-inventory/patch-verification process for SAP e-commerce infrastructure.' Extension scope from affected (mediaconversion and virtualjdbc) and affected_versions.",
+        "description": "What this entry documents is not a patch decision that went wrong but five years in which nobody's tooling reported the exposure: SAP shipped the fix in 2019 and the entry reached KEV in September 2024 against internet-facing Commerce Cloud instances that were never patched. For this CVE the control means a scan result of 'patched' derived from the Commerce Cloud platform release banner is paper compliance, because the vulnerable code lives in the virtualjdbc and mediaconversion extensions and exposure is decided by two facts a banner cannot carry: whether those extensions are in the node's enabled extension set, and whether their Java serialization listener answers from a segment the node should not be answering. The operational test has both parts: an authenticated inventory of the enabled extension set on every Commerce Cloud node, compared against the affected releases (6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905) and against the version of the extension code the running platform process is actually serving rather than the artifact sitting on disk; and an unauthenticated reachability probe of the HTTP/RMI/JMXMP serialization listener from outside the application tier. A node that passes on its release string while the extension is loaded and the listener answers counts as unverified, not as compliant. This is also the test that distinguishes an asset register from an inventory: the framework gap recorded on this entry describes long-lived deployments that no patch-verification process ever saw, and a scanner that cannot reach or authenticate to the Hybris node will report the same clean result for a node that does not exist, a node that is patched, and a node that has been exploitable since 2019.",
+        "evidence": "This aged (2019) flaw was added to CISA KEV in September 2024, indicating renewed/ongoing active exploitation against internet-facing SAP Commerce Cloud (Hybris) instances that were never patched. The activity is likely opportunistic scanning against long-lived unpatched deployments rather than a fresh campaign, and it is not flagged as ransomware. CISA lists it in its Known Exploited Vulnerabilities catalog, added on 2024-09-30, and active exploitation is confirmed. A proof of concept is available. A fixed release is available, and the fix does not require a reboot. The NIST-800-53-SI-2 gap records that SAP shipped a fix in 2019, but KEV addition in 2024 shows five years of unpatched exposure among internet-facing instances; patch-SLA enforcement failed long-term, not just at disclosure. The NIS2-Art21-vulnerability-management gap records that 'A five-year-old known-fixed flaw remaining exploitable at scale indicates an absent asset-inventory/patch-verification process for SAP e-commerce infrastructure.' The extension scope is mediaconversion and virtualjdbc, across the affected versions.",
         "gap_closes": [
           "NIS2-Art21-vulnerability-management",
           "NIST-800-53-SI-2"
@@ -45139,8 +45139,8 @@
       {
         "id": "NEW-CTRL-131",
         "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
-        "description": "Ivanti vTM is a traffic manager rather than a VPN concentrator, but the reason this control applies is unchanged: its admin panel is the authentication enforcement point for an internet-facing appliance, and the packet describes that enforcement failing open — an incorrect implementation of the authentication algorithm that lets a remote unauthenticated attacker past the admin-panel login entirely. That is not an appliance-patch-window item. Scope from the packet's version list rather than its headline: the fix is per release branch — before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2 — so every branch in service has its own fixed build, and an estate standardised on the 22.5 or 22.6 line is not covered by knowing that 22.2R1 and 22.7R2 exist. The expedited clock runs from the 2024-09-24 KEV listing, against the 2024-10-15 CISA due date, through the reboot of each unit: live_patch_available is false and patch_required_reboot is true, so a unit that has taken its branch fix but has not restarted is still running the broken authentication path and is not remediated. Precondition on the interim half: Ivanti's mitigation guidance shipped ahead of a full patch, so during the mitigation-only period exposure is bounded, not removed — restricting which networks can reach the admin panel limits who can send the bypass but leaves it fully exploitable from every permitted source, and that bound is unavailable wherever the admin panel is reached over the internet, which is the deployment that was mass-scanned.",
-        "evidence": "Packet vector: 'Incorrect implementation of an authentication algorithm in Ivanti vTM other than versions 22.2R1 or 22.7R2 allows a remote unauthenticated attacker to bypass authentication of the admin panel' (CWE-287, CWE-303, CVSS 9.8, RWEP 79, poc_available true). affected_versions lists five branch boundaries: before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2. active_exploitation_notes: 'CISA KEV added 2024-09-24 (due 2024-10-15) after mass scanning and exploitation of internet-exposed vTM admin panels.' patch_available true, patch_required_reboot true, live_patch_available false. The NIS2-Art21-vulnerability-management gap records that 'Ivanti's mitigation guidance shipped ahead of a full patch', and the AU-Essential-8-Patch gap that 'Ivanti initially published mitigations only, leaving a window where patch promptly had no patch to apply'.",
+        "description": "Ivanti vTM is a traffic manager rather than a VPN concentrator, but the reason this control applies is unchanged: its admin panel is the authentication enforcement point for an internet-facing appliance, and that enforcement fails open. An incorrect implementation of the authentication algorithm lets a remote unauthenticated attacker past the admin-panel login entirely. That is not an appliance-patch-window item. Scope from the full list of affected versions rather than from the headline description: the fix is per release branch (before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2), so every branch in service has its own fixed build, and an estate standardized on the 22.5 or 22.6 line is not covered by knowing that 22.2R1 and 22.7R2 exist. The expedited clock runs from the 2024-09-24 KEV listing, against the 2024-10-15 CISA due date, through the reboot of each unit: no live patch is available and the fix requires a reboot, so a unit that has taken its branch fix but has not restarted is still running the broken authentication path and is not remediated. Precondition on the interim half: Ivanti's mitigation guidance shipped ahead of a full patch, so during the mitigation-only period exposure is bounded, not removed. Restricting which networks can reach the admin panel limits who can send the bypass but leaves it fully exploitable from every permitted source, and that bound is unavailable wherever the admin panel is reached over the internet, which is the deployment that was mass-scanned.",
+        "evidence": "Incorrect implementation of an authentication algorithm in Ivanti vTM other than versions 22.2R1 or 22.7R2 allows a remote unauthenticated attacker to bypass authentication of the admin panel. The weaknesses are CWE-287 and CWE-303; it carries CVSS 9.8 and an RWEP score of 79, and a proof of concept is available. The affected versions fall at five branch boundaries: before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-09-24 (due 2024-10-15) after mass scanning and exploitation of internet-exposed vTM admin panels. A fixed release is available, the fix requires a reboot, and no live patch is available. The NIS2-Art21-vulnerability-management gap records that 'Ivanti's mitigation guidance shipped ahead of a full patch', and the AU-Essential-8-Patch gap records that 'Ivanti initially published mitigations only, leaving a window where patch promptly had no patch to apply'.",
         "gap_closes": [
           "NIST-800-53-IA-2",
           "NIS2-Art21-vulnerability-management",
@@ -45150,8 +45150,8 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "The packet names the post-exploitation artifact precisely, and it is one no patch can reach: attackers bypassed the admin-panel login, POSTed a crafted user-creation request, and planted a rogue administrator account they then used to log in with full admin privileges. Upgrading a vTM unit to its branch fix repairs the authentication algorithm and leaves that account in place — afterwards it authenticates legitimately, which is exactly why an identity attestation and a least-privilege review both pass cleanly on an appliance the attacker still administers, and why the account survives the reboot the fix requires. So for every vTM that was reachable from an untrusted network between public disclosure and the moment its branch fix was running, the disposition is: enumerate the appliance's administrator accounts against a known-good roster and the change record, treat any account not accounted for as confirmation rather than as an oddity, and rebuild from vendor media with the configuration reviewed rather than restored wholesale — a wholesale restore carries the planted account back onto the rebuilt unit. Rotate the administrator credentials and the secrets the unit held, since the packet has the attacker operating the panel with full admin privileges. Precondition: this is scoped to units exposed during that window, and account enumeration is confirmation, not exclusion — an attacker holding admin can delete the account they added, so a clean roster on an exposed unit is weak evidence and does not on its own downgrade the disposition. Detection must key on what the packet describes: an administrator account appearing on the appliance outside a change window and an admin-panel session for it — not on failed-login volume, which this bypass never generates because authentication is never evaluated.",
-        "evidence": "Packet attack_vector: 'An unauthenticated attacker exploits a flaw in vTM's authentication algorithm to bypass the admin-panel login entirely and POST a crafted user-creation request, planting a rogue administrator account they then use to log in with full admin privileges.' active_exploitation_notes: KEV added 2024-09-24 'after mass scanning and exploitation of internet-exposed vTM admin panels to plant rogue administrator accounts within days of public disclosure. Ransomware use is unknown/unconfirmed.' patch_required_reboot true; live_patch_available false. The UK-CAF-B2 gap records that CAF B2 'assumes access decisions are enforceable once presented'.",
+        "description": "The post-exploitation artifact is documented precisely, and it is one no patch can reach: attackers bypassed the admin-panel login, POSTed a crafted user-creation request, and planted a rogue administrator account they then used to log in with full admin privileges. Upgrading a vTM unit to its branch fix repairs the authentication algorithm and leaves that account in place. Afterwards the account authenticates legitimately, which is exactly why an identity attestation and a least-privilege review both pass cleanly on an appliance the attacker still administers, and why the account survives the reboot the fix requires. So for every vTM that was reachable from an untrusted network between public disclosure and the moment its branch fix was running, the disposition is: enumerate the appliance's administrator accounts against a known-good roster and the change record, treat any account not accounted for as confirmation rather than as an oddity, and rebuild from vendor media with the configuration reviewed rather than restored wholesale, because a wholesale restore carries the planted account back onto the rebuilt unit. Rotate the administrator credentials and the secrets the unit held, since the attacker operated the panel with full admin privileges. Precondition: this is scoped to units exposed during that window, and account enumeration is confirmation, not exclusion. An attacker holding admin can delete the account they added, so a clean roster on an exposed unit is weak evidence and does not on its own downgrade the disposition. Detection must key on the documented activity: an administrator account appearing on the appliance outside a change window and an admin-panel session for it. It must not key on failed-login volume, which this bypass never generates because authentication is never evaluated.",
+        "evidence": "An unauthenticated attacker exploits a flaw in vTM's authentication algorithm to bypass the admin-panel login entirely and POST a crafted user-creation request, planting a rogue administrator account they then use to log in with full admin privileges. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-09-24 after mass scanning and exploitation of internet-exposed vTM admin panels to plant rogue administrator accounts within days of public disclosure. Ransomware use is unknown/unconfirmed. The fix requires a reboot, and no live patch is available. The UK-CAF-B2 gap records that CAF B2 'assumes access decisions are enforceable once presented'.",
         "gap_closes": [
           "UK-CAF-B2"
         ]
@@ -45160,7 +45160,7 @@
         "id": "NEW-CTRL-018",
         "name": "SCANNER-PAPER-COMPLIANCE-TEST",
         "description": "The version data in this entry is the trap this control exists to catch. The vector states the flaw affects vTM 'other than versions 22.2R1 or 22.7R2', and affected_versions expands that into five separate branch boundaries — before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2. A scanner or attestation that compares an installed version against a single fixed version marks a unit on the 22.3, 22.5 or 22.6 branch clean because it is numerically newer than 22.2R1, while that unit has not reached its own branch's fixed build. The operational test is therefore branch-aware: for each vTM instance, resolve its release branch first, then compare against that branch's fixed build, and require the value to be read from the running appliance after its last restart — patch_required_reboot is true and live_patch_available is false, so a unit that has staged the fix without rebooting reports an installed version its running authentication code does not reflect. Precondition: this is a verification control. It finds the false-clean report; it does not shorten the exposure, and it says nothing about whether a unit that was exposed already carries an attacker-created administrator — that question is answered by enumerating the appliance's admin accounts and rebuilding, never by a version comparison.",
-        "evidence": "Packet affected_versions: 'versions before 22.2R1', 'versions before 22.3R3', 'versions before 22.5R2', 'versions before 22.6R2', 'versions before 22.7R2'. The vector states the flaw is present in vTM 'other than versions 22.2R1 or 22.7R2', and affected records it as present on 'all release branches except the already-fixed 22.2R1 and 22.7R2 lines'. patch_required_reboot true; live_patch_available false; CISA KEV 2024-09-24 with a 2024-10-15 due date. The ISO-27001-2022-A.8.8 gap records that this unauthenticated CVSS 9.8 flaw 'was mass-exploited within the CISA-mandated remediation window'.",
+        "evidence": "The affected versions are versions before 22.2R1, versions before 22.3R3, versions before 22.5R2, versions before 22.6R2, and versions before 22.7R2. The flaw is present in vTM other than versions 22.2R1 or 22.7R2, and it is present on all release branches except the already-fixed 22.2R1 and 22.7R2 lines. The fix requires a reboot, and no live patch is available. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-09-24 with a 2024-10-15 due date. The ISO-27001-2022-A.8.8 gap records that this unauthenticated CVSS 9.8 flaw 'was mass-exploited within the CISA-mandated remediation window'.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "AU-Essential-8-Patch"
@@ -45226,7 +45226,7 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "Every trigger condition this control names is present in the packet: an internet-facing appliance, a remote unauthenticated path into restricted administrative functionality, confirmed exploitation, and — the part that makes patch-in-place the wrong default — attacker persistence already established, with webshells and reverse-shell implants deployed after the traversal was chained with CVE-2024-8190 for command execution. Applied to the Ivanti CSA, that means any appliance internet-reachable while below Patch 519 defaults to configuration export for forensics, rebuild, and rotation of every credential and secret the appliance held or that transited it during the exposure window, rather than to installing Patch 519 and closing the ticket. Patch 519 repairs the inconsistent URL-decoding between the broker web server and PHP CGI; it evicts nothing an implant established through it, and neither does the restart the fix requires. Two things specific to this entry make the rebuild step sharper than usual. First, the disposition is not rebuild-onto-the-same-branch: restoring the 4.6 configuration onto a fresh 4.6 unit carries forward both the End-of-Life status and any attacker-modified configuration, so the rebuild is the moment the migration off the branch happens. Second, the packet attributes the activity to suspected nation-state actors, so implants should be assumed to be bespoke rather than expected to match a signature. Precondition: this control is a disposition rule, not a detection method — it does not tell an operator whether a given appliance was reached. Where the exposure window cannot be bounded from evidence held off the appliance, an appliance that was internet-reachable while unpatched has to be treated as compromised rather than cleared, because the artefacts that would show otherwise sit on the device the attacker controlled.",
+        "description": "Every trigger condition this control names is present for this CVE: an internet-facing appliance, a remote unauthenticated path into restricted administrative functionality, confirmed exploitation, and attacker persistence already established, with webshells and reverse-shell implants deployed after the traversal was chained with CVE-2024-8190 for command execution. The established persistence is the part that makes patch-in-place the wrong default. Applied to the Ivanti CSA, that means any appliance internet-reachable while below Patch 519 defaults to configuration export for forensics, rebuild, and rotation of every credential and secret the appliance held or that transited it during the exposure window, rather than to installing Patch 519 and closing the ticket. Patch 519 repairs the inconsistent URL-decoding between the broker web server and PHP CGI; it evicts nothing an implant established through it, and neither does the restart the fix requires. Two things specific to this entry make the rebuild step sharper than usual. First, the disposition is not rebuild-onto-the-same-branch: restoring the 4.6 configuration onto a fresh 4.6 unit carries forward both the End-of-Life status and any attacker-modified configuration, so the rebuild is the moment the migration off the branch happens. Second, the activity is attributed to suspected nation-state actors, so implants should be assumed to be bespoke rather than expected to match a signature. Precondition: this control is a disposition rule, not a detection method, and it does not tell an operator whether a given appliance was reached. Where the exposure window cannot be bounded from evidence held off the appliance, an appliance that was internet-reachable while unpatched has to be treated as compromised rather than cleared, because the artifacts that would show otherwise sit on the device the attacker controlled.",
         "evidence": "active_exploitation_notes: 'Suspected nation-state actors chained this path traversal with CVE-2024-8190 (OS command injection) to bypass authentication and execute arbitrary commands on internet-facing CSA appliances, deploying webshells and reverse-shell implants'; attack_vector: an unauthenticated attacker sends a %3F-encoded path segment against the CSA broker web server, exploiting inconsistent URL-decoding order between the broker and PHP CGI, yielding authenticated command execution and webshell deployment when chained; vector: 'Path Traversal in the Ivanti CSA before 4.6 Patch 519 allows a remote unauthenticated attacker to access restricted functionality'; cisa_kev true (2024-09-19, due 2024-10-10), active_exploitation 'confirmed', poc_available true, rwep_score 76, cvss 9.4; patch_available true with patch_required_reboot true and live_patch_available false; affected_versions record the 4.6 branch as End-of-Life; NIS2-Art21-vulnerability-handling and ISO-27001-2022-A.8.8 gaps both record that a patch cycle is not the available remediation for this appliance.",
         "gap_closes": [
           "NIS2-Art21-vulnerability-handling",
@@ -45297,8 +45297,8 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "The packet's attack path for this CVE ends in code execution as the SharePoint service account, typically followed by a web-shell drop, with exploitation confirmed and a 3-day KEV due date — so for any SharePoint Server that was internet-reachable and below the fixed build during the exposure window, compromise is the default working assumption and the update is not the end of the response. The update closes the deserialization path; it removes nothing an attacker already wrote through it and it does not invalidate credentials or session material taken from the box. Applied here that means: preserve configuration and content for evidence, rebuild the server from a known-good baseline rather than patching in place, and rotate the SharePoint service account credential along with anything else that account could reach. The hunt keys on what the packet actually documents rather than on assumed signals — a web shell placed in the content the server serves, and code running under the SharePoint service identity — so look for files newly written into the server's web-serving directories during the window and for child processes spawned by the SharePoint service identity, not for exploit-tool signatures or process crashes. The exploit is a single crafted serialized request that the server processes through its normal request path: it produces no crash to alert on, and because the attacker never authenticates, it produces no authentication event either, so an estate whose logging is sign-in-centric has no record that it happened. Preconditions, and they are the ones this control is most often over-claimed past: rebuild-not-patch presumes a known-good baseline and a content restore point predating the exposure window — where the earliest backup falls inside that window, restoring reinstates whatever was planted and the artifact hunt is the only remaining check; and it presumes the estate can say which servers were reachable, and on which build, during the window. Where that record does not exist, the scope is every internet-facing instance, not the ones someone remembers.",
-        "evidence": "Packet attack_vector: \"An unauthenticated attacker sends a crafted serialized .NET payload to an internet-facing SharePoint endpoint; unsafe deserialization triggers a gadget chain that executes attacker code as the SharePoint service account, typically followed by a web-shell drop.\" active_exploitation_notes: \"Added to CISA KEV 2026-07-16 with a 3-day due date, indicating confirmed active exploitation of internet-facing SharePoint servers. Ransomware use is not yet confirmed but deserialization RCE on SharePoint has historically been chained into web-shell drops and hands-on-keyboard intrusion.\" UK-CAF-B4 gap: \"System-security assurance based on scheduled hardening reviews will not detect exploitation of an unauthenticated code-execution path in real time.\" AU-Essential-8-Patch gap: \"...patch maturity alone leaves the pre-auth deserialization path on ports 80/443 open through the deploy-and-reboot interval.\" active_exploitation confirmed; cvss 9.8; patch_available true; live_patch_available false.",
+        "description": "The attack path for this CVE ends in code execution as the SharePoint service account, typically followed by a web-shell drop, with exploitation confirmed and a 3-day KEV due date. For any SharePoint Server that was internet-reachable and below the fixed build during the exposure window, compromise is therefore the default working assumption and the update is not the end of the response. The update closes the deserialization path; it removes nothing an attacker already wrote through it and it does not invalidate credentials or session material taken from the box. Applied here that means: preserve configuration and content for evidence, rebuild the server from a known-good baseline rather than patching in place, and rotate the SharePoint service account credential along with anything else that account could reach. The hunt keys on what is actually documented for this CVE rather than on assumed signals: a web shell placed in the content the server serves, and code running under the SharePoint service identity. Look for files newly written into the server's web-serving directories during the window and for child processes spawned by the SharePoint service identity, not for exploit-tool signatures or process crashes. The exploit is a single crafted serialized request that the server processes through its normal request path: it produces no crash to alert on, and because the attacker never authenticates, it produces no authentication event either, so an estate whose logging is sign-in-centric has no record that it happened. Preconditions, and they are the ones this control is most often over-claimed past: rebuild-not-patch presumes a known-good baseline and a content restore point predating the exposure window, and where the earliest backup falls inside that window, restoring reinstates whatever was planted and the artifact hunt is the only remaining check. Rebuild-not-patch also presumes the estate can say which servers were reachable, and on which build, during the window. Where that record does not exist, the scope is every internet-facing instance, not the ones someone remembers.",
+        "evidence": "An unauthenticated attacker sends a crafted serialized .NET payload to an internet-facing SharePoint endpoint; unsafe deserialization triggers a gadget chain that executes attacker code as the SharePoint service account, typically followed by a web-shell drop. CISA added it to its Known Exploited Vulnerabilities catalog on 2026-07-16 with a 3-day due date, indicating confirmed active exploitation of internet-facing SharePoint servers. Ransomware use is not yet confirmed, but deserialization RCE on SharePoint has historically been chained into web-shell drops and hands-on-keyboard intrusion. The UK-CAF-B4 gap states: \"System-security assurance based on scheduled hardening reviews will not detect exploitation of an unauthenticated code-execution path in real time.\" The AU-Essential-8-Patch gap states: \"...patch maturity alone leaves the pre-auth deserialization path on ports 80/443 open through the deploy-and-reboot interval.\" Active exploitation is confirmed, the CVSS score is 9.8, a fixed release is available, and no live patch is available.",
         "gap_closes": [
           "UK-CAF-B4",
           "AU-Essential-8-Patch"
@@ -47301,8 +47301,8 @@
       {
         "id": "NEW-CTRL-129",
         "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
-        "description": "OFBiz takes its authorization decision against the requestUri but renders the screen named by overrideViewUri, so the function that actually runs — ProgramExport, which evaluates a Base64-encoded Groovy program as the OFBiz process user — never authorizes its own caller. Bound to this product, the control means every OFBiz screen and export/scripting endpoint authorizes the caller at the point of execution rather than inheriting a verdict taken on the routing key, and the views that can reach a code-evaluation path are refused for any request whose entry point was an unauthenticated public endpoint. The cited access-enforcement control is precisely what fails here: the attacker prefixes a public endpoint (the packet names forgotPassword) so the request never reaches OFBiz's user/role permission model at all — a deployment can pass an access-enforcement review of its permission matrix while this path stays fully open, which is why AC-3 is recorded against this entry rather than credited. The second half of the control, keeping the OFBiz admin/scripting surface off untrusted networks, carries a precondition that must be stated: it bounds exposure only for instances that have no business serving untrusted users, so an internet-facing OFBiz storefront or partner portal cannot rely on it and must take the vendor update; and neither measure evicts a Groovy payload already executed as the process user on an instance that was reachable during the exposure window. Distinguishing test: on a staging instance, request a public endpoint with the view overridden to ProgramExport and confirm the request is refused before the screen renders.",
-        "evidence": "Packet: CWE-863; attack_vector — \"OFBiz checks authorization against the requestUri but renders the screen named by overrideViewUri. An unauthenticated attacker prefixes a public endpoint (e.g. forgotPassword) and overrides the view to ProgramExport, then posts a Base64-encoded Groovy program that executes as the OFBiz process user.\" CVSS 9.8, RWEP 67, poc_available true; CISA KEV-listed 2024-08-27 with active_exploitation confirmed. citing_gaps record NIST-800-53-AC-3 (Access Enforcement) and UK-CAF-B4 (System security) as insufficient for this entry.",
+        "description": "OFBiz takes its authorization decision against the requestUri but renders the screen named by overrideViewUri, so the function that actually runs (ProgramExport, which evaluates a Base64-encoded Groovy program as the OFBiz process user) never authorizes its own caller. Bound to this product, the control means every OFBiz screen and export/scripting endpoint authorizes the caller at the point of execution rather than inheriting a verdict taken on the routing key, and the views that can reach a code-evaluation path are refused for any request whose entry point was an unauthenticated public endpoint. The cited access-enforcement control is precisely what fails here: the attacker prefixes a public endpoint (forgotPassword, for example) so the request never reaches OFBiz's user/role permission model at all. A deployment can pass an access-enforcement review of its permission matrix while this path stays fully open, which is why AC-3 is recorded against this entry rather than credited. The second half of the control, keeping the OFBiz admin/scripting surface off untrusted networks, carries a precondition that must be stated: it bounds exposure only for instances that have no business serving untrusted users, so an internet-facing OFBiz storefront or partner portal cannot rely on it and must take the vendor update. Neither measure evicts a Groovy payload already executed as the process user on an instance that was reachable during the exposure window. Distinguishing test: on a staging instance, request a public endpoint with the view overridden to ProgramExport and confirm the request is refused before the screen renders.",
+        "evidence": "The weakness is CWE-863. OFBiz checks authorization against the requestUri but renders the screen named by overrideViewUri. An unauthenticated attacker prefixes a public endpoint (e.g. forgotPassword) and overrides the view to ProgramExport, then posts a Base64-encoded Groovy program that executes as the OFBiz process user. It carries CVSS 9.8 and an RWEP score of 67, and a proof of concept is available. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-08-27, and active exploitation is confirmed. This entry records NIST-800-53-AC-3 (Access Enforcement) and UK-CAF-B4 (System security) as insufficient.",
         "gap_closes": [
           "NIST-800-53-AC-3",
           "UK-CAF-B4"
@@ -47312,7 +47312,7 @@
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
         "description": "There is a vendor fix, a public PoC and confirmed in-the-wild exploitation on an unauthenticated code-execution path, so the OFBiz upgrade off the affected 18.12.14-and-earlier line to 18.12.15 runs on the clock that opened with the 2024-08-27 KEV listing, not in the next ERP change window. The usual deferral argument does not exist on this entry: there is no live-patching primitive for this product and the vendor update requires no reboot, so the only remaining constraint is the application's own restart/change process — an ERP change-freeze is a scheduling preference here, not a technical blocker, and recording one as a compensating control leaves an unauthenticated Groovy-execution path open. Measure completion from the deployed webapp's reported version rather than from a patch-management row saying \"OFBiz updated\": these deployments are commonly customized builds where the inventory record and the running instance diverge. Precondition on the closure claim: applying the update ends new exploitation of this path but does nothing about an instance that was reachable while unpatched — anything already executed as the OFBiz process user survives the upgrade, so an instance exposed during the window needs forensic triage rather than a patch-and-close.",
-        "evidence": "Packet: patch_available true; vector — \"This issue affects Apache OFBiz: through 18.12.14. Users are recommended to upgrade to version 18.12.15, which fixes the issue.\" live_patch_available false, live_patch_notes \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" CISA KEV-listed 2024-08-27, active_exploitation confirmed, poc_available true, RWEP 67, CVSS 9.8. citing_gaps: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, NIS2-Art21-vulnerability-handling.",
+        "evidence": "A fixed release is available. This issue affects Apache OFBiz through 18.12.14, and users are recommended to upgrade to version 18.12.15, which fixes the issue. No live patch is available: there is no live-patching primitive for this product, and the vendor update (no reboot required) is the remediation. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-08-27, active exploitation is confirmed, and a proof of concept is available. It carries an RWEP score of 67 and CVSS 9.8. The framework gaps cited for this entry are AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, and NIS2-Art21-vulnerability-handling.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -47364,7 +47364,7 @@
         "id": "NEW-CTRL-057",
         "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
         "description": "The remediation is clean and the boundary precise: the vendor update, no reboot required, no live-patching primitive, with builds prior to 128.0.6613.84 affected. The control for this CVE is therefore that the browser's security channel is not held behind an enterprise update ring's validation cycle, and that completion is measured per host against the installed browser build rather than against 'auto-update is enabled in policy' — the latter is the state a managed fleet is usually attested on, and it is satisfied while version-pinned, kiosk, and long-uptime roaming hosts sit behind the fixed build. The urgency here is not carried by exploit availability, which is the second half of why this needs enforcing: poc_available is false alongside a 2024-08-26 KEV listing with confirmed in-the-wild exploitation, so a prioritization pipeline that ranks on public-PoC presence will under-rank a bug a named actor was already running in a full chain. The precondition to state is a measurement one: the fleet number has to be the build each host is actually running, not the build the management console reports as approved or downloaded, because an approved-but-not-running update leaves the host exposed on the same terms as one that never received it.",
-        "evidence": "Packet vector: 'Type confusion in V8 in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to exploit heap corruption via a crafted HTML page. (Chromium security severity: High)'. CWE-843; CISA KEV-listed 2024-08-26 with active_exploitation confirmed; CVSS 9.6, RWEP 56; poc_available false. patch_available true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' Citing gaps AU-Essential-8-App-Hardening, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and UK-CAF-B4.",
+        "evidence": "Type confusion in V8 in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to exploit heap corruption via a crafted HTML page (Chromium security severity: High). The weakness is CWE-843. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-08-26, and active exploitation is confirmed. It carries CVSS 9.6 and an RWEP score of 56, and no proof of concept is available. A fixed release is available and no live patch is available: there is no live-patching primitive for this product, and the vendor update (no reboot required) is the remediation. The framework gaps cited for this entry are AU-Essential-8-App-Hardening, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and UK-CAF-B4.",
         "gap_closes": [
           "AU-Essential-8-App-Hardening",
           "ISO-27001-2022-A.8.8",
@@ -47375,8 +47375,8 @@
       {
         "id": "NEW-CTRL-043",
         "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
-        "description": "The packet describes this bug as the opening stage of a chain rather than as a standalone browser fault: a victim visits an attacker-controlled page, crafted JavaScript triggers the V8 type confusion, the resulting heap corruption yields renderer code execution, and Citrine Sleet chained that with a Windows sandbox escape to deploy the FudModule rootkit. Commodity incident response handles only the visible half — a browser anomaly on a user's workstation — and resolves it with a browser reset or a decision scoped to the browser, which is exactly the under-escalation this control exists to stop, because the terminal state of the chain is kernel-level persistence that outlives anything done to the browser. For this CVE the runbook needs a trigger a responder can act on in the moment: renderer-level compromise indicators on a host that browsed externally during the exposure window escalate to full host triage and to the explicit question of whether the second-stage escape ran, rather than being closed out by confirming the browser has since been updated — the update closes the entry point and says nothing about a host already through it. The precondition worth naming is that the actor attribution in this packet was available only after the fact, so the escalation criterion has to be the chain shape (browser renderer execution followed by evidence of privilege escalation or kernel-level persistence), not an actor name the responder will not hold on day one.",
-        "evidence": "Packet attack_vector: 'A victim visits an attacker-controlled page that runs crafted JavaScript triggering a V8 type confusion; the resulting heap corruption yields renderer RCE, which Citrine Sleet chained with a Windows sandbox escape to deploy the FudModule rootkit.' CISA KEV-listed 2024-08-26 with active_exploitation confirmed; poc_available false. NIS2-Art21-incident-handling is recorded as a citing gap on this entry.",
+        "description": "This bug is the opening stage of a chain rather than a standalone browser fault: a victim visits an attacker-controlled page, crafted JavaScript triggers the V8 type confusion, the resulting heap corruption yields renderer code execution, and Citrine Sleet chained that with a Windows sandbox escape to deploy the FudModule rootkit. Commodity incident response handles only the visible half (a browser anomaly on a user's workstation) and resolves it with a browser reset or a decision scoped to the browser. That is exactly the under-escalation this control exists to stop, because the terminal state of the chain is kernel-level persistence that outlives anything done to the browser. For this CVE the runbook needs a trigger a responder can act on in the moment: renderer-level compromise indicators on a host that browsed externally during the exposure window escalate to full host triage and to the explicit question of whether the second-stage escape ran, rather than being closed out by confirming the browser has since been updated. The update closes the entry point and says nothing about a host already through it. The precondition worth naming is that the actor attribution for this chain was available only after the fact, so the escalation criterion has to be the chain shape (browser renderer execution followed by evidence of privilege escalation or kernel-level persistence), not an actor name the responder will not hold on day one.",
+        "evidence": "A victim visits an attacker-controlled page that runs crafted JavaScript triggering a V8 type confusion; the resulting heap corruption yields renderer RCE, which Citrine Sleet chained with a Windows sandbox escape to deploy the FudModule rootkit. CISA added it to its Known Exploited Vulnerabilities catalog on 2024-08-26, and active exploitation is confirmed. No proof of concept is available. NIS2-Art21-incident-handling is recorded as a framework gap cited on this entry.",
         "gap_closes": [
           "NIS2-Art21-incident-handling"
         ]
@@ -47424,7 +47424,7 @@
       {
         "id": "NEW-CTRL-134",
         "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
-        "description": "Versa Director is an SD-WAN orchestrator and this defect sits on a file-accepting function of its management GUI: the packet's vector places it in the 'Change Favicon' option, where a malicious file ending in .png is accepted as an image and executed, enabling web-shell deployment (CWE-434). Bound to this product the control means the Change Favicon path — and every other upload endpoint on the Director GUI — decides what a file actually is before storing it anywhere the server will execute from, rather than treating the extension as a content claim; and that no Director instance is left with its management interface reachable from a network with no operational need to reach it. The packet is specific on that second half: Versa's own guidance was to firewall management ports 4566 and 4570, many operators left them internet-reachable, and observed intrusions reached those exposed management ports before the upload. Note which half of this control is load-bearing here, because it differs from the unauthenticated cases in this class: the packet's stated precondition is a successfully authenticated Provider-Data-Center-Admin or Provider-Data-Center-System-Admin session, and tenant-level users do not hold the privilege — so the endpoint's authorization decision is present and functioning, and it is the content validation that fails. Distinguishing test: on a staging Director, upload a file whose contents are a JSP payload and whose name ends in .png through Change Favicon and confirm it is rejected on content rather than accepted on extension; then, from a general corporate segment and from an external address, attempt to reach ports 4566 and 4570 and confirm nothing answers. Precondition: the content-validation repair is what the vendor update delivers — that update is the remediation, with a reboot required and no live-patching primitive for this product — so until each Director has been taken through it and restarted, firewalling the management ports bounds who can present the upload but leaves the path fully usable to anything inside a permitted segment and to any account that legitimately administers the Director. Scope the version check from the affected list rather than from the current release train: it names builds below 22.1.4 together with 21.2.3, 22.1.2 and 22.1.3, so a 21.2.x Director is in scope alongside the 22.1.x fleet and an estate that inventories only its 22.1 line will report clean while an older orchestrator stays exposed.",
+        "description": "Versa Director is an SD-WAN orchestrator and this defect sits on a file-accepting function of its management GUI: the 'Change Favicon' option, where a malicious file ending in .png is accepted as an image and executed, enabling web-shell deployment (CWE-434). Bound to this product the control means that the Change Favicon path, and every other upload endpoint on the Director GUI, decides what a file actually is before storing it anywhere the server will execute from, rather than treating the extension as a content claim; and that no Director instance is left with its management interface reachable from a network with no operational need to reach it. The facts behind that second half are specific: Versa's own guidance was to firewall management ports 4566 and 4570, many operators left them internet-reachable, and observed intrusions reached those exposed management ports before the upload. Note which half of this control is load-bearing here, because it differs from the unauthenticated cases in this class: the stated precondition is a successfully authenticated Provider-Data-Center-Admin or Provider-Data-Center-System-Admin session, and tenant-level users do not hold the privilege. The endpoint's authorization decision is therefore present and functioning, and it is the content validation that fails. Distinguishing test: on a staging Director, upload a file whose contents are a JSP payload and whose name ends in .png through Change Favicon and confirm it is rejected on content rather than accepted on extension; then, from a general corporate segment and from an external address, attempt to reach ports 4566 and 4570 and confirm nothing answers. Precondition: the content-validation repair is what the vendor update delivers, and that update is the remediation, with a reboot required and no live-patching primitive for this product. Until each Director has been taken through it and restarted, firewalling the management ports bounds who can present the upload but leaves the path fully usable to anything inside a permitted segment and to any account that legitimately administers the Director. Scope the version check from the full list of affected versions rather than from the current release train: that list names builds below 22.1.4 together with 21.2.3, 22.1.2 and 22.1.3, so a 21.2.x Director is in scope alongside the 22.1.x fleet and an estate that inventories only its 22.1 line will report clean while an older orchestrator stays exposed.",
         "evidence": "Catalog facts only: CWE-434; vector describing the Change Favicon option available only to Provider-Data-Center-Admin or Provider-Data-Center-System-Admin, tenant-level users excluded, with a malicious file 'ending with .png extension to masquerade as image file' and exploitation 'possible only after a user with Provider-Data-Center-Admin or Provider-Data-Center-System-Admin has successfully authenticated and logged in'; affected naming the Change Favicon upload where a malicious .png can be 'uploaded and executed, enabling web-shell deployment'; affected_versions '< 22.1.4', '21.2.3', '22.1.2', '22.1.3'; the SC-7 gap \"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\"; the ISO A.8.9 gap 'Configuration management did not restrict management-plane exposure of the Director appliance'; the AU-Essential-8-Patch gap 'The update requires a reboot and no live-patching option exists, so each Director stays exposed until it restarts on the fixed build'; the SI-2 gap 'Zero-day exploitation preceded any patch by months ... so compensating network controls were the only defense'; attack_vector 'in observed intrusions attackers reached the exposed management ports'; patch_available true, patch_required_reboot true, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation'.",
         "gap_closes": [
           "NIST-800-53-SC-7",
@@ -47446,7 +47446,7 @@
       {
         "id": "NEW-CTRL-043",
         "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
-        "description": "The packet supplies this control's trigger directly for Versa Director: exploitation as a zero-day since at least June 2024, attributed with moderate confidence to Chinese state-sponsored actors (Volt Typhoon / Bronze Silhouette), deploying a memory-resident VersaMem web shell against ISPs and MSPs to steal credentials. For a Director that was running an affected build, that combination means the response cannot be 'apply the update and close the ticket': the system-security gap on this entry states that a memory-resident web shell evades the file-integrity monitoring the hardening principle relies on, so the absence of an on-disk artifact is not evidence the appliance was clean, and the vendor update — which requires a reboot — restarts the appliance without ever producing a compromise assessment. For this product the escalation path should require, before the Director is declared recovered: a review of Change Favicon uploads and of provider-level admin authentications back through the packet's June 2024 exposure window; a determination of whether management ports 4566 and 4570 were reachable from untrusted networks during it; rotation of the credentials the Director holds or brokers, since credential theft is the packet's recorded objective rather than a hypothetical outcome; and, because the named victims are ISPs and MSPs, a review extending into the customer networks the Director orchestrates rather than treating the appliance as the boundary of the incident. Detection has to key on the behaviour the packet describes rather than on tooling signatures: a favicon upload and a provider-admin login are both legitimate operations that generate no error and crash nothing, so the signal is a Change Favicon upload or a provider-level admin session arriving from an unexpected source or outside a change window, followed by use of credentials the Director holds — an alert built around malware artifacts or service crashes would miss an intrusion doing exactly what this packet records. Precondition: this is a response control and it prevents nothing; it also depends on GUI upload records and management-plane authentication logs having been retained back to June 2024 and shipped off the appliance, which on a Director whose management ports were internet-reachable is precisely the telemetry least likely to be intact.",
+        "description": "This CVE supplies this control's trigger directly for Versa Director: exploitation as a zero-day since at least June 2024, attributed with moderate confidence to Chinese state-sponsored actors (Volt Typhoon / Bronze Silhouette), deploying a memory-resident VersaMem web shell against ISPs and MSPs to steal credentials. For a Director that was running an affected build, that combination means the response cannot be 'apply the update and close the ticket'. The system-security gap on this entry states that a memory-resident web shell evades the file-integrity monitoring the hardening principle relies on, so the absence of an on-disk artifact is not evidence the appliance was clean, and the vendor update, which requires a reboot, restarts the appliance without ever producing a compromise assessment. For this product the escalation path should require, before the Director is declared recovered: a review of Change Favicon uploads and of provider-level admin authentications back through the June 2024 exposure window; a determination of whether management ports 4566 and 4570 were reachable from untrusted networks during it; rotation of the credentials the Director holds or brokers, since credential theft is the documented objective rather than a hypothetical outcome; and, because the named victims are ISPs and MSPs, a review extending into the customer networks the Director orchestrates rather than treating the appliance as the boundary of the incident. Detection has to key on the documented behavior rather than on tooling signatures: a favicon upload and a provider-admin login are both legitimate operations that generate no error and crash nothing, so the signal is a Change Favicon upload or a provider-level admin session arriving from an unexpected source or outside a change window, followed by use of credentials the Director holds. An alert built around malware artifacts or service crashes would miss an intrusion doing exactly what is documented here. Precondition: this is a response control and it prevents nothing; it also depends on GUI upload records and management-plane authentication logs having been retained back to June 2024 and shipped off the appliance, which on a Director whose management ports were internet-reachable is precisely the telemetry least likely to be intact.",
         "evidence": "Catalog facts only: active_exploitation_notes 'Exploited as a zero-day since at least June 2024, attributed with moderate confidence to Chinese state-sponsored actors (Volt Typhoon / Bronze Silhouette) who deployed a memory-resident VersaMem web shell against ISPs and MSPs. CISA KEV ransomware status: Unknown.'; attack_vector 'in observed intrusions attackers reached the exposed management ports and then loaded the memory-resident VersaMem web shell to steal credentials'; the UK-CAF-B4 gap 'a memory-resident web shell evades file-integrity monitoring the principle relies on'; the SC-7 gap naming management ports 4566/4570 left internet-reachable; patch_available true with patch_required_reboot true and live_patch_notes 'the vendor update requires a reboot and is the remediation'; cisa_kev true with kev_date 2024-08-23 and active_exploitation confirmed.",
         "gap_closes": [
           "UK-CAF-B4"
@@ -47495,7 +47495,7 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "For this Exchange flaw the two events this control chooses between are far apart: the vendor fix shipped in the July 2021 security updates (KB5004778 for Exchange Server 2013, KB5004779 for 2016, KB5004780 for 2019) and CISA listed it on 2024-08-21, so the clock is the KEV listing, the later of the two. Bound to this product that means every on-premises Exchange server carrying OWA/ECP is driven to a build at or above the July 2021 update on the KEV clock, not folded into the cumulative-update cadence and change-freeze windows the packet's flaw-remediation gap names as the reason servers stayed exposed. Completion has to be measured on the running build: live_patch_available is false and the vendor update requires a reboot, so a server that has staged or installed the update but not rebooted still executes the vulnerable code and counts as exposed — and on a production mail server the reboot is precisely the step deferred out of the change window, so a deferral recorded as 'patched' is the specific way this remediation goes wrong. Preconditions and limits. There is no segmentation step that buys time: the packet's boundary-protection gap records that OWA/ECP must be internet-reachable for mail flow, so until the fixed build is running the vulnerable endpoint is reachable and the mitigation state is binary. And the SLA closes the flaw, not the incident — exploitation is confirmed and operators have dropped ASPX web shells into Exchange virtual directories, which a cumulative update does not remove, so a server that was reachable and unpatched during the exposure window belongs on the incident path rather than being closed on the patch record.",
+        "description": "For this Exchange flaw the two events this control chooses between are far apart: the vendor fix shipped in the July 2021 security updates (KB5004778 for Exchange Server 2013, KB5004779 for 2016, KB5004780 for 2019) and CISA listed it on 2024-08-21, so the clock is the KEV listing, the later of the two. Bound to this product that means every on-premises Exchange server carrying OWA/ECP is driven to a build at or above the July 2021 update on the KEV clock, not folded into the cumulative-update cadence and change-freeze windows that the flaw-remediation gap on this entry names as the reason servers stayed exposed. Completion has to be measured on the running build: no live patch is available and the vendor update requires a reboot, so a server that has staged or installed the update but not rebooted still executes the vulnerable code and counts as exposed. On a production mail server the reboot is precisely the step deferred out of the change window, so a deferral recorded as 'patched' is the specific way this remediation goes wrong. Two limits apply. There is no segmentation step that buys time: the boundary-protection gap on this entry records that OWA/ECP must be internet-reachable for mail flow, so until the fixed build is running the vulnerable endpoint is reachable and the mitigation state is binary. And the SLA closes the flaw, not the incident: exploitation is confirmed and operators have dropped ASPX web shells into Exchange virtual directories, which a cumulative update does not remove, so a server that was reachable and unpatched during the exposure window belongs on the incident path rather than being closed on the patch record.",
         "evidence": "patch_available true, patch_required_reboot true, live_patch_available false, and live_patch_notes stating there is no live-patching primitive for this product and that the vendor update requires a reboot and is the remediation. affected_versions lists Exchange Server 2013 (pre-KB5004778), 2016 (pre-KB5004779) and 2019 (pre-KB5004780), with `affected` describing on-premises Exchange prior to the July 2021 security updates. CISA KEV added 2024-08-21, active_exploitation confirmed, RWEP 77, CVSS 7.2, poc_available true, CWE-502. active_exploitation_notes record operators running code on internet-facing Exchange and dropping web shells, with ransomware association unconfirmed. The NIST-800-53-SI-2 gap names Exchange cumulative-update cadence and change-freeze windows as keeping servers exposed past the observed exploitation window; the NIST-800-53-SC-7 gap records that OWA/ECP must be internet-reachable for mail flow.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -47509,7 +47509,7 @@
         "id": "NEW-CTRL-040",
         "name": "OWA-PER-REQUEST-SIEM-INGESTION",
         "description": "This Exchange flaw is post-authentication, and that is exactly the property that makes authentication-event logging blind to it: the attacker arrives holding valid Exchange credentials, so the logon preceding the exploit is a successful and unremarkable one, and the identity controls the estate is audited against have already been satisfied before the request that matters is sent. Ask what an exploit doing this actually emits and it is a request pattern, not an authentication anomaly — a request from an already-authenticated session to an internet-facing OWA/ECP back-end endpoint, followed by requests to a .aspx path under an Exchange virtual directory that did not exist before it, since persistence runs through an ASPX web shell placed there. Only per-request access logs carry either half, so IIS/OWA per-request access logs — not just authentication events — must be forwarded off the Exchange server to an external SIEM, with retention long enough to cover the exposure window this entry implies: the fix shipped with the July 2021 updates and the KEV listing came on 2024-08-21, so a retention period that ages out that span turns 'was this server used' into an unanswerable question, and 90 days is a floor rather than a comfortable margin. The second reason the destination must be external is the same one that makes this control the complement of the unavoidable exposure: an attacker who reached code execution on the server can reach logs stored on it. Preconditions. This detects, it does not prevent — it does not stop the deserialization from executing and it does not remove a web shell already written; it bounds the window to alert-and-response time. And it only works if the forwarding was in place before the request arrived, which on an on-premises Exchange server whose logging was scoped to logon events is precisely the assumption that fails.",
-        "evidence": "The packet's NIST-800-53-IA-2 gap states the flaw is post-authentication, so identification and authentication controls are already satisfied by the attacker and MFA on OWA does not stop a valid-account or credential-replay path into the RCE. The NIST-800-53-SC-7 gap states perimeter controls do not block the attack because Exchange OWA/ECP must be internet-reachable for mail flow, so the vulnerable endpoints stay exposed. attack_vector records an attacker with valid Exchange authentication reaching an internet-facing OWA/ECP back-end endpoint, triggering server-side code execution, then persisting via an ASPX web shell in an Exchange virtual directory; active_exploitation_notes record web-shell drops on internet-facing Exchange. CISA KEV 2024-08-21 against a fix shipped in the July 2021 security updates; active_exploitation confirmed; poc_available true.",
+        "evidence": "The NIST-800-53-IA-2 gap on this entry states the flaw is post-authentication, so identification and authentication controls are already satisfied by the attacker and MFA on OWA does not stop a valid-account or credential-replay path into the RCE. The NIST-800-53-SC-7 gap states perimeter controls do not block the attack because Exchange OWA/ECP must be internet-reachable for mail flow, so the vulnerable endpoints stay exposed. In the attack, an attacker with valid Exchange authentication reaches an internet-facing OWA/ECP back-end endpoint, triggers server-side code execution, then persists via an ASPX web shell in an Exchange virtual directory. Exploitation has included web-shell drops on internet-facing Exchange. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-08-21, against a fix shipped in the July 2021 security updates. Active exploitation is confirmed, and a proof of concept is available.",
         "gap_closes": [
           "NIST-800-53-IA-2",
           "NIST-800-53-SC-7"
@@ -47558,7 +47558,7 @@
       {
         "id": "NEW-CTRL-130",
         "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
-        "description": "This flaw is the case the control is written for: the packet's own reachability precondition is that unprivileged user namespaces are enabled (otherwise namespaced CAP_SYS_ADMIN is required), and the escalation is stated to include breaking out of a container — so the namespace boundary provides no containment and the host kernel is the only thing between a tenant workload and root. The two compensating controls named here map one-to-one onto that precondition: disabling unprivileged user namespaces on hosts whose workloads do not need them, and dropping CAP_SYS_ADMIN from container specs, each removes reachability without touching the kernel, which matters for nodes waiting on a change window. Confining every workload with an AppArmor or SELinux profile plus seccomp additionally constrains which filesystem types a confined process can ask the kernel to mount, and mounting a filesystem that falls back to legacy handling is the step that reaches the overflowing parser. On this entry the live-kernel-patch branch of the control is real rather than aspirational, so host remediation and namespace hardening can land on the same day.",
+        "description": "This flaw is the case the control is written for: the reachability precondition is that unprivileged user namespaces are enabled (otherwise namespaced CAP_SYS_ADMIN is required), and the escalation is stated to include breaking out of a container, so the namespace boundary provides no containment and the host kernel is the only thing between a tenant workload and root. The two compensating controls named here map one-to-one onto that precondition: disabling unprivileged user namespaces on hosts whose workloads do not need them, and dropping CAP_SYS_ADMIN from container specs, each removes reachability without touching the kernel, which matters for nodes waiting on a change window. Confining every workload with an AppArmor or SELinux profile plus seccomp additionally constrains which filesystem types a confined process can ask the kernel to mount, and mounting a filesystem that falls back to legacy handling is the step that reaches the overflowing parser. On this entry the live-kernel-patch branch of the control is real rather than aspirational, so host remediation and namespace hardening can land on the same day.",
         "evidence": "vector: heap-based buffer overflow in legacy_parse_param in the Filesystem Context functionality, reachable by 'An unprivileged (in case of unprivileged user namespaces enabled, otherwise needs namespaced CAP_SYS_ADMIN privilege) local user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to legacy handling)'. attack_vector: the local user escalates to root 'including breaking out of a container'. cisa_kev true with kev_date 2024-08-21, active_exploitation 'confirmed', poc_available true, RWEP 65, CVSS 8.4. live_patch_available true, live_patch_notes: 'Distros shipped livepatchable fixes for the legacy_parse_param overflow, allowing remediation without an immediate reboot on supported kernels.'",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -47631,7 +47631,7 @@
         "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
         "description": "This packet carries both halves that this control exists to separate. A vendor fix exists and the entry records that there is no live-patching primitive for this product, that the vendor update requires a reboot, and that it is the remediation — while the A.8.8 and SI-2 gaps state that a large part of the affected fleet is end-of-support with no remediation path at all. So the first requirement is a per-unit inventory naming every Dahua IP camera, NVR and related product in service, and every OEM-rebranded Dahua-based device affected_versions calls out, each recorded with its model, its running firmware baseline, and a supported-or-end-of-support answer obtained from the Dahua PSIRT advisory for that exact model rather than assumed in either direction — affected versions are given only as firmware baselines prior to the vendor's 2021 fix, with per-model builds left to that advisory. Units whose model has fixed firmware are remediation items on the clock that opened with the 2024-08-21 KEV listing, and because the update requires a reboot with no live-patch path, a unit that has taken firmware but has not rebooted onto it is still running the bypassable login path and counts as exposed. Units whose model has no fixed firmware — the end-of-support population the A.8.8 gap names, which on an OEM rebrand may mean no vendor is shipping firmware at all — cannot be patched and belong on a dated replacement schedule; a risk acceptance with no removal date leaves a device with a public PoC, confirmed exploitation and 99.9th-percentile EPSS in service indefinitely, exposed not only to this bypass but to everything found in that firmware line since. And because exploitation is confirmed and units are recruited into IoT botnets, a unit that was internet-exposed before remediation is not closed by firmware alone: its configuration and administrative credential must be rebuilt from a known-good baseline rather than inherited through the update, and credentials that transited it rotated.",
-        "evidence": "Packet: affected names Dahua IP cameras, NVRs and related products; affected_versions name multiple Dahua IPC/SD/NVR firmware baselines prior to the vendor's 2021 fix (per-model builds per the Dahua PSIRT advisory) and numerous OEM-rebranded Dahua-based devices. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' CISA KEV 2024-08-21, active_exploitation confirmed, poc_available true, RWEP 73, CVSS 9.8; active_exploitation_notes record broad exploitation of internet-exposed Dahua cameras and NVRs including recruitment into IoT botnets, with EPSS at the 99.9th percentile. The ISO-27001-2022-A.8.8 gap states there is no remediation path for end-of-support Dahua/OEM camera firmware and that the control cannot compel operators to patch or retire; the NIST-800-53-SI-2 gap states many affected Dahua/OEM cameras are end-of-support so the patch SLA effectively never closes on a large installed base.",
+        "evidence": "The affected products are Dahua IP cameras, NVRs and related products. The affected versions are multiple Dahua IPC/SD/NVR firmware baselines prior to the vendor's 2021 fix (per-model builds per the Dahua PSIRT advisory) and numerous OEM-rebranded Dahua-based devices. A fixed release is available and requires a reboot, and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-08-21. Active exploitation is confirmed, a proof of concept is available, and the flaw carries an RWEP score of 73 and a CVSS score of 9.8. Exploitation has been broad against internet-exposed Dahua cameras and NVRs, including recruitment into IoT botnets, with EPSS at the 99.9th percentile. The ISO-27001-2022-A.8.8 gap states there is no remediation path for end-of-support Dahua/OEM camera firmware and that the control cannot compel operators to patch or retire; the NIST-800-53-SI-2 gap states many affected Dahua/OEM cameras are end-of-support so the patch SLA effectively never closes on a large installed base.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "NIST-800-53-SI-2"
@@ -47640,8 +47640,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "For the Dahua units that do have fixed firmware, this is the clock the SI-2 gap says never closes on this fleet: firmware flashed and the device rebooted onto it, measured from the 2024-08-21 KEV listing rather than from a camera-refresh or building-maintenance cycle, with completion recorded per unit against the running firmware baseline. Two limits have to be stated rather than assumed for this product. The packet registers no live-patching primitive, so there is no mitigation that lands ahead of the reboot — a unit scheduled for firmware is exposed until it restarts. And for units with no fixed firmware, the SLA's compensating-control branch is the only branch available, which here means removing the device from any internet-reachable path — a holding measure with a hard precondition: the bypass sits inside the login process itself, triggered by a packet that names the loopback device as the client, so any caller that can open a session to the device still reaches it. Taking a camera off a port-forward or UPnP mapping does nothing about a caller already on the network segment that reaches it, so those units belong on the replacement schedule with a date, not on an indefinite compensating-control record.",
-        "evidence": "Packet: CISA KEV 2024-08-21, active_exploitation confirmed, EPSS at the 99.9th percentile, poc_available true, RWEP 73, CVSS 9.8. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes state the vendor update requires a reboot and is the remediation. vector and affected describe the login process being bypassed by constructing a packet that specifies the loopback device as the client, skipping identity authentication. The NIST-800-53-SI-2 gap states firmware flaw-remediation is chronically slow for IoT fleets and that many affected devices are end-of-support, so the patch SLA effectively never closes.",
+        "description": "For the Dahua units that do have fixed firmware, this is the clock the SI-2 gap says never closes on this fleet: firmware flashed and the device rebooted onto it, measured from the 2024-08-21 KEV listing rather than from a camera-refresh or building-maintenance cycle, with completion recorded per unit against the running firmware baseline. Two limits have to be stated rather than assumed for this product. There is no live-patching primitive for this product, so there is no mitigation that lands ahead of the reboot: a unit scheduled for firmware is exposed until it restarts. And for units with no fixed firmware, the SLA's compensating-control branch is the only branch available, which here means removing the device from any internet-reachable path. That is a holding measure with a hard precondition: the bypass sits inside the login process itself, triggered by a packet that names the loopback device as the client, so any caller that can open a session to the device still reaches it. Taking a camera off a port-forward or UPnP mapping does nothing about a caller already on the network segment that reaches it, so those units belong on the replacement schedule with a date, not on an indefinite compensating-control record.",
+        "evidence": "CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-08-21. Active exploitation is confirmed, EPSS is at the 99.9th percentile, a proof of concept is available, and the flaw carries an RWEP score of 73 and a CVSS score of 9.8. A fixed release is available and requires a reboot, and no live patch is available; the vendor update requires a reboot and is the remediation. The login process is bypassed by constructing a packet that specifies the loopback device as the client, skipping identity authentication. The NIST-800-53-SI-2 gap states firmware flaw-remediation is chronically slow for IoT fleets and that many affected devices are end-of-support, so the patch SLA effectively never closes.",
         "gap_closes": [
           "NIST-800-53-SI-2"
         ]
@@ -47689,7 +47689,7 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "The remediation for this entry is the Dahua firmware fix, and the packet is explicit that it cannot be applied live: live_patch_available is false and live_patch_notes record that the vendor update requires a reboot and is the remediation. A camera or NVR that has received firmware but has not restarted onto it is still running the bypassable login path and is counted as exposed, not as patched — on camera fleets that restart is the step most often skipped, because taking it drops recording and live view, and a deferral recorded as patched is the specific way this remediation goes wrong. Scope comes from the affected field rather than the CVE's headline product: Dahua IP cameras, NVRs and OEM-rebranded devices are all in scope, so an inventory keyed on the vendor name reports clean across an estate standardised on a rebrand, and the recorders are as much in scope as the cameras they hold. The fixed level is per-model — affected versions are the builds prior to the fixes listed in Dahua advisory 957 — so each model, and each rebranded equivalent, is checked against the fixed build for that model rather than against one estate-wide firmware number, and for a rebranded unit the fixed build has to be obtained from whoever ships that unit's firmware rather than assumed from the Dahua model it derives from. The clock is the 2024-08-21 KEV listing, and the packet's exposure note is why this cannot ride the normal cadence: EPSS near 0.999 with mass scanning and botnet exploitation of internet-exposed units, against a flaw whose fix has been available since well before the listing. The patch requirement is also the only closure for the authentication side: an alternate login path built into the firmware is not something gateway or authentication hardening guidance can compensate for, so reaching the fixed build is the control, not a supplement to it.",
+        "description": "The remediation for this entry is the Dahua firmware fix, and it cannot be applied live: no live patch is available, and the vendor update requires a reboot and is the remediation. A camera or NVR that has received firmware but has not restarted onto it is still running the bypassable login path and is counted as exposed, not as patched. On camera fleets that restart is the step most often skipped, because taking it drops recording and live view, and a deferral recorded as patched is the specific way this remediation goes wrong. Scope covers every affected device rather than the CVE's headline product: Dahua IP cameras, NVRs and OEM-rebranded devices are all in scope, so an inventory keyed on the vendor name reports clean across an estate standardized on a rebrand, and the recorders are as much in scope as the cameras they hold. The fixed level is per-model (affected versions are the builds prior to the fixes listed in Dahua advisory 957), so each model, and each rebranded equivalent, is checked against the fixed build for that model rather than against one estate-wide firmware number, and for a rebranded unit the fixed build has to be obtained from whoever ships that unit's firmware rather than assumed from the Dahua model it derives from. The clock is the 2024-08-21 KEV listing, and the exploitation record is why this cannot ride the normal cadence: EPSS near 0.999 with mass scanning and botnet exploitation of internet-exposed units, against a flaw whose fix has been available since well before the listing. The patch requirement is also the only closure for the authentication side: an alternate login path built into the firmware is not something gateway or authentication hardening guidance can compensate for, so reaching the fixed build is the control, not a supplement to it.",
         "evidence": "Dahua's vendor update requires a reboot and is the remediation; no live patch exists. The flaw affects Dahua IP cameras, NVRs and OEM-rebranded devices: login skips authentication when the client specifies the NetKeyboard type argument, in firmware builds before the fixes listed in Dahua advisory 957. CISA listed it as known exploited on 2024-08-21, exploitation is confirmed, a proof of concept exists, and it scores CVSS 9.8 and RWEP 77. An EPSS score near 0.999 reflects mass scanning and botnet exploitation of internet-exposed devices. Technical vulnerability management often leaves long-lived camera firmware out of the patch scope. ISM-1546, which requires users to be authenticated before they are granted access to a system and its resources, governs how the organization configures authentication rather than the vendor's login code, so a device can pass an assessment while botnets exploit it.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
@@ -47699,8 +47699,8 @@
       {
         "id": "NEW-CTRL-129",
         "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
-        "description": "The login handler is where a Dahua camera or NVR makes its authentication decision, and this CVE is that decision failing open: the packet has an attacker constructing a login packet that specifies the NetKeyboard type argument, which bypasses the credential check and returns an authenticated session to the device. Bound to this product the control means the device's functions do not inherit their authorization from that single login verdict, and — the half an operator holds today — that the camera and NVR login and management surfaces answer only from the segment that operates them, because a caller who cannot present the crafted packet cannot use the bypass. This is the specific reason the identity controls cited against this entry give nothing: no credential is ever presented, so no password policy, rotation schedule or account model is consulted, and an attestation that every camera carries a unique administrator password passes cleanly while the whole fleet is open. It also means the cameras, the recorders and the rebranded units belong in an identity-endpoint inventory rather than being carried as fixtures, since the packet's framing is that a bypassed camera becomes a foothold onto whatever network it shares. Distinguishing test: from a general corporate VLAN and from an external address, attempt to open a session to a staging camera and to a staging NVR; anything that answers is within reach of the published bypass, and 'the cameras are on the internal network' is a statement about topology rather than a demonstration that the login surface is unreachable from untrusted segments. Precondition: segmentation bounds who can send the packet, it does not repair the login path. Any host already inside the permitted segment — the video-management server that legitimately talks to the fleet, an operator workstation, a maintenance contractor's laptop — still reaches it, and the lever is unavailable entirely for a unit deliberately published for remote viewing. Those units stay exposed until the firmware fix and its reboot land, and because exploitation is confirmed and mass-scale, a unit that was internet-reachable while unpatched needs its configuration and credentials rebuilt from a known-good baseline rather than inherited through the firmware update.",
-        "evidence": "vector: 'The identity authentication bypass vulnerability found in some Dahua products during the login process. Attackers can bypass device identity authentication by constructing malicious data packets.' affected: 'authentication bypass during login when the client specifies the NetKeyboard type argument', covering 'Dahua IP cameras, NVRs and OEM-rebranded devices'. attack_vector: 'An unauthenticated remote attacker sends a crafted login packet specifying the NetKeyboard authentication type, which bypasses the credential check and grants an authenticated session to the camera or NVR.' The packet's NIST-800-53-IA-2 gap: 'The authentication mechanism itself is bypassable via the NetKeyboard packet type, so an identification/authentication control that assumes credentials are checked provides no protection.' The NIST-800-53-SC-7 gap: 'IoT cameras are routinely exposed directly to the internet; boundary controls are frequently absent for these devices, leaving the preauth bypass reachable at scale.' The NIS2-Art21-network-security gap: 'Network-security duties rarely segment CCTV/IoT VLANs from the corporate network, so a bypassed camera becomes a foothold.' The UK-CAF-B2 gap: the bypass 'defeats it across an entire fleet of internet-exposed Dahua cameras that B2 controls seldom inventory as identity endpoints.' active_exploitation confirmed; patch_available true with a reboot required per live_patch_notes.",
+        "description": "The login handler is where a Dahua camera or NVR makes its authentication decision, and this CVE is that decision failing open: an attacker constructs a login packet that specifies the NetKeyboard type argument, which bypasses the credential check and returns an authenticated session to the device. Bound to this product the control means the device's functions do not inherit their authorization from that single login verdict, and (the half an operator holds today) that the camera and NVR login and management surfaces answer only from the segment that operates them, because a caller who cannot present the crafted packet cannot use the bypass. This is the specific reason the identity controls cited against this entry give nothing: no credential is ever presented, so no password policy, rotation schedule or account model is consulted, and an attestation that every camera carries a unique administrator password passes cleanly while the whole fleet is open. It also means the cameras, the recorders and the rebranded units belong in an identity-endpoint inventory rather than being carried as fixtures, since a bypassed camera becomes a foothold onto whatever network it shares. Distinguishing test: from a general corporate VLAN and from an external address, attempt to open a session to a staging camera and to a staging NVR; anything that answers is within reach of the published bypass, and 'the cameras are on the internal network' is a statement about topology rather than a demonstration that the login surface is unreachable from untrusted segments. Precondition: segmentation bounds who can send the packet; it does not repair the login path. Any host already inside the permitted segment (the video-management server that legitimately talks to the fleet, an operator workstation, a maintenance contractor's laptop) still reaches it, and the lever is unavailable entirely for a unit deliberately published for remote viewing. Those units stay exposed until the firmware fix and its reboot land, and because exploitation is confirmed and mass-scale, a unit that was internet-reachable while unpatched needs its configuration and credentials rebuilt from a known-good baseline rather than inherited through the firmware update.",
+        "evidence": "The identity authentication bypass vulnerability is found in some Dahua products during the login process: attackers can bypass device identity authentication by constructing malicious data packets. The bypass occurs during login when the client specifies the NetKeyboard type argument, and it covers Dahua IP cameras, NVRs and OEM-rebranded devices. An unauthenticated remote attacker sends a crafted login packet specifying the NetKeyboard authentication type, which bypasses the credential check and grants an authenticated session to the camera or NVR. The NIST-800-53-IA-2 gap on this entry states that the authentication mechanism itself is bypassable via the NetKeyboard packet type, so an identification/authentication control that assumes credentials are checked provides no protection. The NIST-800-53-SC-7 gap states that IoT cameras are routinely exposed directly to the internet; boundary controls are frequently absent for these devices, leaving the preauth bypass reachable at scale. The NIS2-Art21-network-security gap states that network-security duties rarely segment CCTV/IoT VLANs from the corporate network, so a bypassed camera becomes a foothold. The UK-CAF-B2 gap states that the bypass 'defeats it across an entire fleet of internet-exposed Dahua cameras that B2 controls seldom inventory as identity endpoints.' Active exploitation is confirmed, and a fixed release is available that requires a reboot.",
         "gap_closes": [
           "NIST-800-53-IA-2",
           "UK-CAF-B2",
@@ -47763,7 +47763,7 @@
         "id": "NEW-CTRL-128",
         "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
         "description": "The vulnerable code here is the Jenkins controller's own CLI command parser — the args4j feature that expands an argument beginning with '@' into the contents of the named file, left enabled — and it answers before the caller authenticates, which is exactly the protocol-endpoint class this control governs. Applied to Jenkins it means the controller's CLI accepts connections only from the hosts that legitimately drive it (build agents, operator jump hosts, the CI automation that invokes it), enforced by network ACL or host firewall rather than inferred from the controller sitting on an internal network, and that a KEV-listed defect in that parser moves on an accelerated clock with the controller restarted onto the fixed build rather than folded into the next platform window. Distinguishing test for this product: from a general user or workstation segment against a staging controller, issue an unauthenticated CLI command whose argument is '@' followed by a path on the controller filesystem, and confirm the connection is refused before the parser sees it — 'the controller is internal' is an assertion about topology, not a demonstration that the CLI is unreachable from untrusted segments. Precondition: restricting reachability bounds who can send the command, it does not repair the parser. Every host inside the permitted segment still reaches it with no credential, and on a controller that exists to serve a broad engineering population there is no segment that removes the path — only one that narrows it until the upgrade lands.",
-        "evidence": "The packet's vector places the defect in the CLI command parser: Jenkins does not disable the feature that replaces an '@' character followed by a file path in an argument with that file's contents, allowing unauthenticated attackers to read arbitrary files on the Jenkins controller file system. The affected summary names the args4j expandAtFiles feature as the unfixed behaviour. The cited boundary-protection gap states that boundary protection still exposing the Jenkins CLI/HTTP endpoint to untrusted networks leaves the unauthenticated file read directly reachable, and the flaw-remediation gap records public PoCs landing within hours of disclosure.",
+        "evidence": "The defect is in the CLI command parser: Jenkins does not disable the feature that replaces an '@' character followed by a file path in an argument with that file's contents, allowing unauthenticated attackers to read arbitrary files on the Jenkins controller file system. The unfixed behavior is the args4j expandAtFiles feature. The cited boundary-protection gap states that boundary protection still exposing the Jenkins CLI/HTTP endpoint to untrusted networks leaves the unauthenticated file read directly reachable, and the flaw-remediation gap records public PoCs landing within hours of disclosure.",
         "gap_closes": [
           "NIST-800-53-SC-7",
           "NIST-800-53-SI-2"
@@ -47772,7 +47772,7 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "This CVE's primitive is disclosure, so the upgrade closes the read and removes nothing that was already read. The packet has the attacker recovering secrets from the controller filesystem — it names the Jenkins master key — and chaining them into remote code execution, and it records that a caller without Overall/Read still obtains the first lines of any file, so an unauthenticated scanner reaching an exposed controller gets at least partial content of every credential-bearing file on it. For a Jenkins controller that was reachable by untrusted callers during the exposure window, the requirement is therefore to treat the instance as compromised rather than patched: capture the configuration and the job and plugin state for review, rebuild the controller from a known-good baseline instead of upgrading in place, and rotate everything the controller held — the master key and the credentials store it protects, agent and SSH keys, API tokens, and any signing or registry credential the pipelines used. Preconditions: rotation only helps for material the operator can enumerate and revoke, so a credential the controller held that is also in use elsewhere stays valid until it is rotated at every consumer, and a controller rebuilt onto the fixed build with the old key material restored is back where it started. Scope this to controllers that were actually reachable during the window — the packet's exploitation evidence is mass scanning of internet-exposed controllers, not a claim that every install was reached.",
+        "description": "This CVE's primitive is disclosure, so the upgrade closes the read and removes nothing that was already read. The attacker recovers secrets from the controller filesystem, including the Jenkins master key, and chains them into remote code execution, and a caller without Overall/Read still obtains the first lines of any file, so an unauthenticated scanner reaching an exposed controller gets at least partial content of every credential-bearing file on it. For a Jenkins controller that was reachable by untrusted callers during the exposure window, the requirement is therefore to treat the instance as compromised rather than patched: capture the configuration and the job and plugin state for review, rebuild the controller from a known-good baseline instead of upgrading in place, and rotate everything the controller held (the master key and the credentials store it protects, agent and SSH keys, API tokens, and any signing or registry credential the pipelines used). Preconditions: rotation only helps for material the operator can enumerate and revoke, so a credential the controller held that is also in use elsewhere stays valid until it is rotated at every consumer, and a controller rebuilt onto the fixed build with the old key material restored is back where it started. Scope this to controllers that were actually reachable during the window: the exploitation evidence is mass scanning of internet-exposed controllers, not a claim that every install was reached.",
         "evidence": "The affected summary states the flaw lets an attacker read arbitrary files — full contents with Overall/Read, first lines without — and chain leaked secrets into remote code execution. The attack_vector names the Jenkins master key as the disclosed secret then used to achieve remote code execution. active_exploitation is confirmed, with mass scanning of internet-exposed Jenkins controllers and a Known ransomware association at the 2024-08-19 KEV listing. The cited DORA gap states that ICT protection for a financial-sector build pipeline is undermined when signing keys and credentials can be exfiltrated through an unauthenticated CLI read, and the Essential Eight gap records the controllers and the build secrets they hold as readable well before any patch window closed.",
         "gap_closes": [
           "DORA-Art-9",
@@ -47822,7 +47822,7 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "For Web Help Desk the packet sets the clock and the frameworks cited on this entry both miss it: CISA listed the CVE on 2024-08-15 on evidence of active exploitation against internet-facing instances, the flaw-remediation gap records a three-week KEV due window as slow against a CVSS 9.8 deserialization RCE already being exploited, and the Essential Eight gap records the 48-hour internet-facing target as trailing exploitation of an already-reachable server. Applied to this product, the requirement is that every Web Help Desk instance in the 12.4 through 12.8 range is driven to 12.8.3 Hotfix 1 on the KEV clock rather than on the ITSM's own change cadence, and that the internet-reachable instances are enumerated first, because reachability is what turned this from a patch item into an exploited one. Completion is measured by the version the running WHD service reports: no host reboot is recorded for this fix, but the defect is in the Java application, so a server where the hotfix has been applied while the old WHD/Tomcat service process is still serving requests is still executing the vulnerable code and is not remediated. Preconditions and limits: the packet registers no live-patch primitive, so there is no vendor mechanism that holds the gap while the hotfix is scheduled — until it lands and the service is running the fixed build, the only operator-side lever is reachability, covered by the boundary control on this entry. And a KEV-clock patch is not evidence of cleanliness: exploitation is confirmed in the wild, so an internet-reachable instance that was exposed before the hotfix needs forensic triage and rotation of the credentials that ITSM holds, which applying 12.8.3 Hotfix 1 does nothing to undo.",
+        "description": "For Web Help Desk the KEV listing sets the clock, and the frameworks cited on this entry both miss it: CISA listed the CVE on 2024-08-15 on evidence of active exploitation against internet-facing instances, the flaw-remediation gap records a three-week KEV due window as slow against a CVSS 9.8 deserialization RCE already being exploited, and the Essential Eight gap records the 48-hour internet-facing target as trailing exploitation of an already-reachable server. Applied to this product, the requirement is that every Web Help Desk instance in the 12.4 through 12.8 range is driven to 12.8.3 Hotfix 1 on the KEV clock rather than on the ITSM's own change cadence, and that the internet-reachable instances are enumerated first, because reachability is what turned this from a patch item into an exploited one. Completion is measured by the version the running WHD service reports: no host reboot is recorded for this fix, but the defect is in the Java application, so a server where the hotfix has been applied while the old WHD/Tomcat service process is still serving requests is still executing the vulnerable code and is not remediated. Preconditions and limits: no live-patch primitive exists, so there is no vendor mechanism that holds the gap while the hotfix is scheduled. Until it lands and the service is running the fixed build, the only operator-side lever is reachability, covered by the boundary control on this entry. And a KEV-clock patch is not evidence of cleanliness: exploitation is confirmed in the wild, so an internet-reachable instance that was exposed before the hotfix needs forensic triage and rotation of the credentials that ITSM holds, which applying 12.8.3 Hotfix 1 does nothing to undo.",
         "evidence": "cisa_kev true with kev_date 2024-08-15; active_exploitation confirmed, with active_exploitation_notes stating it is exploited in the wild against internet-facing Web Help Desk. cvss 9.8, poc_available true. affected_versions: 'Web Help Desk 12.4 through 12.8 (fixed in 12.8.3 Hotfix 1)'. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes stating 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The NIST-800-53-SI-2 gap states flaw remediation via WHD 12.8.3 Hotfix 1 is correct but the 3-week KEV due window is slow against a CVSS 9.8 deserialization RCE already being exploited on internet-facing help-desk servers; the AU-Essential-8-Patch gap states the 48-hour internet-facing target trails exploitation of an already-reachable WHD deserialization RCE; the NIS2-Art21-vulnerability-handling gap states vulnerability-handling obligations do not compel rapid mitigation of a single-exploit-away RCE on an ITSM asset that holds broad credentials. The UK-CAF-B2 gap records that a Web Help Desk RCE hands an attacker the privileged service and integrated-AD credentials the ITSM stores.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -47833,7 +47833,7 @@
       {
         "id": "NEW-CTRL-125",
         "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
-        "description": "For Web Help Desk the control means treating the request path that accepts serialized Java objects as a trust boundary rather than an internal convenience. The packet's attack vector is a crafted serialized Java object whose gadget chain runs arbitrary OS commands as the WHD service account, so the governing question is what arriving content the application is permitted to reconstruct — not whether the caller looks legitimate. SolarWinds could only reproduce the flaw authenticated, which is precisely why an authentication check sitting in front of the sink is not the thing that stops the gadget chain: a caller who does authenticate reaches it anyway. Bound to this deployment the requirement is that deserialization is constrained to the object types WHD legitimately exchanges instead of accepting arbitrary object graphs, and that the WHD listener answers only from the segment its help-desk users actually come from rather than being internet-reachable, which the packet's boundary-protection gap records as the state of the exploited instances. That gap also notes a WAF without deserialization-aware rules will not stop the gadget chain, so 'there is a WAF in front of it' is an assertion about topology, not a demonstration that the sink is unreachable. This is the same point the technical-vulnerability-management gap makes about the class rather than the instance: closing the ticket at 12.8.3 Hotfix 1 removes this sink, and later WHD deserialization CVEs followed, so the requirement has to be a property of the next release too. Distinguishing test: from an unauthenticated host that can route to a staging WHD, and again from an authenticated low-privilege session, submit a serialized object carrying a type WHD never legitimately receives and confirm it is refused before deserialization runs — an instance that passes a patch-level audit while reconstructing arbitrary object graphs from request content still exposes the path the moment the next parsing defect lands. Precondition: type constraint inside the application is a property of the vendor's fixed release — this control states what to verify and what to require of subsequent releases, it does not implement it. The reachability half is what the operator holds in the interim, and it bounds who can send the object without repairing the sink, so any caller inside the permitted segment still reaches it; it is also unavailable where the help desk must stay reachable to remote or external users.",
+        "description": "For Web Help Desk the control means treating the request path that accepts serialized Java objects as a trust boundary rather than an internal convenience. The attack uses a crafted serialized Java object whose gadget chain runs arbitrary OS commands as the WHD service account, so the governing question is what arriving content the application is permitted to reconstruct, not whether the caller looks legitimate. SolarWinds could only reproduce the flaw authenticated, which is precisely why an authentication check sitting in front of the sink is not the thing that stops the gadget chain: a caller who does authenticate reaches it anyway. Bound to this deployment the requirement is that deserialization is constrained to the object types WHD legitimately exchanges instead of accepting arbitrary object graphs, and that the WHD listener answers only from the segment its help-desk users actually come from rather than being internet-reachable, which the boundary-protection gap on this entry records as the state of the exploited instances. That gap also notes a WAF without deserialization-aware rules will not stop the gadget chain, so 'there is a WAF in front of it' is an assertion about topology, not a demonstration that the sink is unreachable. This is the same point the technical-vulnerability-management gap makes about the class rather than the instance: closing the ticket at 12.8.3 Hotfix 1 removes this sink, and later WHD deserialization CVEs followed, so the requirement has to be a property of the next release too. Distinguishing test: from an unauthenticated host that can route to a staging WHD, and again from an authenticated low-privilege session, submit a serialized object carrying a type WHD never legitimately receives and confirm it is refused before deserialization runs. An instance that passes a patch-level audit while reconstructing arbitrary object graphs from request content still exposes the path the moment the next parsing defect lands. Precondition: type constraint inside the application is a property of the vendor's fixed release. This control states what to verify and what to require of subsequent releases; it does not implement it. The reachability half is what the operator holds in the interim, and it bounds who can send the object without repairing the sink, so any caller inside the permitted segment still reaches it; it is also unavailable where the help desk must stay reachable to remote or external users.",
         "evidence": "affected: 'SolarWinds Web Help Desk (WHD) Java application; the deserialization sink allows OS command execution on the host running the WHD/Tomcat service.' attack_vector: 'An attacker sends a crafted serialized Java object to Web Help Desk; unsafe deserialization instantiates a gadget chain that runs arbitrary OS commands as the WHD service account.' vector: 'While it was reported as an unauthenticated vulnerability, SolarWinds has been unable to reproduce it without authentication after thorough testing.' cwe_refs lists CWE-502. The NIST-800-53-SC-7 gap states boundary protection assumes WHD is not directly exposed, yet exploited instances are internet-reachable, and a WAF without deserialization-aware rules will not stop the gadget chain; the ISO-27001-2022-A.8.8 gap states technical vulnerability management does not enforce removing untrusted Java deserialization sinks, so the class of bug recurs (later WHD deserialization CVEs followed). patch_available true with affected_versions 'Web Help Desk 12.4 through 12.8 (fixed in 12.8.3 Hotfix 1)', live_patch_available false.",
         "gap_closes": [
           "NIST-800-53-SC-7",
@@ -47883,8 +47883,8 @@
       {
         "id": "NEW-CTRL-145",
         "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
-        "description": "The packet places this in the Windows Power Dependency Coordinator (pdc.sys) kernel component and describes a local authenticated attacker driving a use-after-free from standard user to SYSTEM — the account is already legitimate, so no account model is being abused; a kernel privilege boundary is failing. For this CVE the control means the August 2024 Windows security update is driven across every affected host on the KEV clock that opened 2024-08-13 rather than riding the staged monthly ring rollout that leaves endpoints exposed for weeks, with completion measured by each host's installed build against the fixed build for its SKU. Enumerate the whole population the packet names — Windows 10 and Windows 11 clients alongside Windows Server 2016, 2019 and 2022 — and do not let the server fleet go first: this is a post-foothold escalation step, so the machines where an attacker lands initially are ordinary user workstations, and an estate that patches servers first leaves the primitive available exactly where initial access happens. patch_required_reboot is true with no live-patch path, and the vendor update requires a reboot and is the remediation, so a host that has installed the update but not rebooted is still executing the vulnerable driver and must be counted as exposed; measure on the running build rather than on 'installed' in the management console. What is not available here matters as much: this is an in-box driver that system-security hardening cannot remove or disable, so unlike an optional service or a third-party signed driver there is no disable, unload or blocklist interim measure — the update is the removal, which is why compressing its rollout is the whole control.",
-        "evidence": "Packet: CISA KEV-listed 2024-08-13, active_exploitation confirmed, CVSS 7.8, RWEP 61, poc_available false, CWE-416. affected: Windows Power Dependency Coordinator (pdc.sys) kernel component, local authenticated attacker exploits a use-after-free to elevate from standard user to SYSTEM, fixed in the August 2024 security updates across supported Windows client and server builds. affected_versions: Windows 10 (all supported builds pre-Aug 2024 update), Windows 11 (pre-Aug 2024 update), Windows Server 2016/2019/2022 (pre-Aug 2024 update). patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: no live-patching primitive for this product, the vendor update requires a reboot and is the remediation. NIST-800-53-SI-2 gap: monthly cadence plus staged enterprise ring rollout means the August 2024 fix reaches many endpoints weeks after the KEV add while the LPE is already weaponized. UK-CAF-B4 gap: an in-box driver B4 hardening cannot remove or disable. active_exploitation_notes: used as a post-exploitation escalation step; ransomware use unconfirmed but SYSTEM-grade LPEs are common in ransomware and hands-on-keyboard intrusions.",
+        "description": "The flaw is in the Windows Power Dependency Coordinator (pdc.sys) kernel component: a local authenticated attacker drives a use-after-free from standard user to SYSTEM. The account is already legitimate, so no account model is being abused; a kernel privilege boundary is failing. For this CVE the control means the August 2024 Windows security update is driven across every affected host on the KEV clock that opened 2024-08-13 rather than riding the staged monthly ring rollout that leaves endpoints exposed for weeks, with completion measured by each host's installed build against the fixed build for its SKU. Enumerate the whole affected population (Windows 10 and Windows 11 clients alongside Windows Server 2016, 2019 and 2022) and do not let the server fleet go first: this is a post-foothold escalation step, so the machines where an attacker lands initially are ordinary user workstations, and an estate that patches servers first leaves the primitive available exactly where initial access happens. There is no live-patch path, and the vendor update requires a reboot and is the remediation, so a host that has installed the update but not rebooted is still executing the vulnerable driver and must be counted as exposed; measure on the running build rather than on 'installed' in the management console. What is not available here matters as much: this is an in-box driver that system-security hardening cannot remove or disable, so unlike an optional service or a third-party signed driver there is no disable, unload or blocklist interim measure. The update is the removal, which is why compressing its rollout is the whole control.",
+        "evidence": "CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-08-13. Active exploitation is confirmed, the flaw is CWE-416 with a CVSS score of 7.8 and an RWEP score of 61, and no proof of concept is available. The flaw is in the Windows Power Dependency Coordinator (pdc.sys) kernel component: a local authenticated attacker exploits a use-after-free to elevate from standard user to SYSTEM. It is fixed in the August 2024 security updates across supported Windows client and server builds. The affected versions are Windows 10 (all supported builds pre-Aug 2024 update), Windows 11 (pre-Aug 2024 update), and Windows Server 2016/2019/2022 (pre-Aug 2024 update). A fixed release is available and requires a reboot, and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. The NIST-800-53-SI-2 gap states that monthly cadence plus staged enterprise ring rollout means the August 2024 fix reaches many endpoints weeks after the KEV add while the LPE is already weaponized. The UK-CAF-B4 gap states that this is an in-box driver B4 hardening cannot remove or disable. The flaw has been used as a post-exploitation escalation step; ransomware use is unconfirmed, but SYSTEM-grade LPEs are common in ransomware and hands-on-keyboard intrusions.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -47896,7 +47896,7 @@
       {
         "id": "NEW-CTRL-003",
         "name": "KERNEL-EXPLOITATION-DETECTION",
-        "description": "pdc.sys is a Windows kernel driver, so for this CVE the control is Windows privilege-transition telemetry rather than the auditd/eBPF form it takes on Linux hosts — and the packet describes the behaviour precisely enough to key on it. The exploit is a local authenticated user's process corrupting kernel memory through the Power Dependency Coordinator and emerging as SYSTEM, run after an initial foothold. The rule therefore keys on that transition in that direction: a process running under a standard user account, inside an interactive user session, that acquires a SYSTEM-integrity token or spawns a SYSTEM-context child without having passed through a legitimate elevation path — no service-control-manager start, no scheduled task registered to run as SYSTEM, no consent prompt, no management-agent installer. Pair it with the driver-interaction half the packet names, a non-elevated user process opening a handle to the Power Dependency Coordinator driver, which ordinary user code has no reason to do; either signal alone is noisy, and it is the pairing inside a short window that separates this exploit from a benign elevation. Note what will not see it, because this is exactly where the anomaly-detection gap bites: there is no public PoC, so there is no tool signature to match; nothing is written to disk for a file-integrity monitor to catch; and the component being exercised is a signed in-box Microsoft driver, so driver-load and code-signing telemetry stay clean by construction — a rule keyed on process crashes, unsigned drivers or named exploit tooling would miss an attempt behaving exactly as described here. Preconditions: this needs privilege-transition telemetry already collected and shipped off-host before the attempt, and a rule authored afterwards against telemetry nobody was collecting produces nothing. And detection prevents nothing — it bounds dwell time during the weeks the staged rollout takes; a host on which SYSTEM was reached is a rebuild-and-credential-rotation case, not one closed by the August 2024 update landing later.",
+        "description": "pdc.sys is a Windows kernel driver, so for this CVE the control is Windows privilege-transition telemetry rather than the auditd/eBPF form it takes on Linux hosts, and the exploit behavior is described precisely enough to key on it. The exploit is a local authenticated user's process corrupting kernel memory through the Power Dependency Coordinator and emerging as SYSTEM, run after an initial foothold. The rule therefore keys on that transition in that direction: a process running under a standard user account, inside an interactive user session, that acquires a SYSTEM-integrity token or spawns a SYSTEM-context child without having passed through a legitimate elevation path (no service-control-manager start, no scheduled task registered to run as SYSTEM, no consent prompt, no management-agent installer). Pair it with the driver-interaction half, a non-elevated user process opening a handle to the Power Dependency Coordinator driver, which ordinary user code has no reason to do; either signal alone is noisy, and it is the pairing inside a short window that separates this exploit from a benign elevation. Note what will not see it, because this is exactly where the anomaly-detection gap bites: there is no public PoC, so there is no tool signature to match; nothing is written to disk for a file-integrity monitor to catch; and the component being exercised is a signed in-box Microsoft driver, so driver-load and code-signing telemetry stay clean by construction. A rule keyed on process crashes, unsigned drivers or named exploit tooling would miss an attempt behaving exactly as described here. Preconditions: this needs privilege-transition telemetry already collected and shipped off-host before the attempt, and a rule authored afterwards against telemetry nobody was collecting produces nothing. And detection prevents nothing: it bounds dwell time during the weeks the staged rollout takes, and a host on which SYSTEM was reached is a rebuild-and-credential-rotation case, not one closed by the August 2024 update landing later.",
         "evidence": "Packet SOC2-CC7-anomaly-detection gap: anomaly-detection controls rarely flag a same-host token-elevation from a legitimate driver interaction, so the escalation is easily missed without EDR tuned to privilege-transition events. attack_vector: a local, authenticated attacker triggers a use-after-free in the Windows Power Dependency Coordinator driver to corrupt kernel memory and elevate to SYSTEM, chaining it after an initial foothold to gain full host control. ISO-27001-2022-A.8.8 gap describes local exploitation of a signed in-box driver between assessment cycles. poc_available false. NIST-800-53-SI-2 gap records the weeks-long staged-rollout exposure window. active_exploitation confirmed, KEV 2024-08-13.",
         "gap_closes": [
           "SOC2-CC7-anomaly-detection"
@@ -49225,8 +49225,8 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation starts with a file the user opens: the packet's lure is a crafted .url internet shortcut whose content is the URL it points at, using the 'mhtml:' scheme and an '!x-usc:' directive so Windows hands the target to the retired Internet Explorer/MSHTML engine and the perceived file type is not what actually renders. Because the endpoint's decision is made from what the shortcut says, the enforceable control on an estate that has not completed the update is the ingress boundary: the mail gateway and file-share boundary apply the untrusted-origin marking themselves rather than leaving the endpoint to infer it, internet shortcut files arriving from outside the organization are held rather than delivered, and the marking survives the container — a shortcut extracted from an archive, mounted from an image, or renamed inherits the tag instead of losing it. Precondition: this narrows the delivery path, it does not close the flaw. A .url reaching the user through any path the boundary does not mark — removable media, an unmanaged share, a link followed directly in a browser — still resolves the mhtml:/!x-usc: handler chain into MSHTML, and per the packet only the vendor update, on a host that has since been restarted, removes that. Distinguishing test: deliver a .url whose displayed name and invoked handler disagree through each ingress path onto a managed workstation and confirm it arrives marked untrusted or is held; the user-application-hardening attestation cited on this entry covers macro and ActiveX settings and guidance to check file extensions, which is precisely what a file-type-spoofing lure defeats.",
-        "evidence": "Packet attack_vector: 'A victim opens a crafted .url internet-shortcut whose URL uses the \"mhtml:\" scheme and an \"!x-usc:\" directive; Windows invokes the retired Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA, spoofing the perceived file type and executing code (Void Banshee delivered the Atlantida stealer this way).' CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gap names ASD Essential Eight 'User application hardening' as insufficient.",
+        "description": "Exploitation starts with a file the user opens: the lure is a crafted .url internet shortcut whose content is the URL it points at, using the 'mhtml:' scheme and an '!x-usc:' directive so Windows hands the target to the retired Internet Explorer/MSHTML engine and the perceived file type is not what actually renders. Because the endpoint's decision is made from what the shortcut says, the enforceable control on an estate that has not completed the update is the ingress boundary: the mail gateway and file-share boundary apply the untrusted-origin marking themselves rather than leaving the endpoint to infer it, internet shortcut files arriving from outside the organization are held rather than delivered, and the marking survives the container. A shortcut extracted from an archive, mounted from an image, or renamed inherits the tag instead of losing it. Precondition: this narrows the delivery path; it does not close the flaw. A .url reaching the user through any path the boundary does not mark (removable media, an unmanaged share, a link followed directly in a browser) still resolves the mhtml:/!x-usc: handler chain into MSHTML, and only the vendor update, on a host that has since been restarted, removes that. Distinguishing test: deliver a .url whose displayed name and invoked handler disagree through each ingress path onto a managed workstation and confirm it arrives marked untrusted or is held; the user-application-hardening attestation cited on this entry covers macro and ActiveX settings and guidance to check file extensions, which is precisely what a file-type-spoofing lure defeats.",
+        "evidence": "A victim opens a crafted .url internet-shortcut whose URL uses the \"mhtml:\" scheme and an \"!x-usc:\" directive; Windows invokes the retired Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA, spoofing the perceived file type and executing code (Void Banshee delivered the Atlantida stealer this way). The weakness is CWE-451. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-07-09, and active exploitation is confirmed. The flaw carries an RWEP score of 79 and a CVSS score of 7.5, and a proof of concept is available. A fixed release is available, but no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. The citing gap names ASD Essential Eight 'User application hardening' as insufficient.",
         "gap_closes": [
           "AU-Essential-8-App-Hardening"
         ]
@@ -49234,8 +49234,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "Per the packet this is a vendor update with no live-patch path and a fix that requires a reboot, so the clock opened by the 2024-07-09 KEV listing runs to the completed restart of every affected Windows endpoint, not to update-deployment counts. An endpoint that has taken the update but not restarted still resolves the packet's mhtml:/!x-usc: shortcut into the retired engine, and user-workstation restarts are exactly what deployment reporting conceals — 'installed, pending restart' is the state in which this remediation is recorded as complete while the path stays live. Urgency comes from the packet's own fields rather than the 7.5 base score: poc_available is true, active_exploitation is confirmed, and the packet ties the technique to the Void Banshee delivery of the Atlantida stealer, so every hour of the window on a user endpoint is an hour of potential credential loss rather than only of exposure. Distinguishing test: measure elapsed time from the KEV listing to each endpoint's post-update restart and report the tail rather than the mean; a fleet reported compliant on installed-update counts while endpoints await restart has not closed the window.",
-        "evidence": "Packet: CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Packet attack_vector records that 'Void Banshee delivered the Atlantida stealer this way'. Citing gaps name NIST SP 800-53 SI-2 (Flaw Remediation), EU NIS2 Art.21 vulnerability handling and disclosure, and ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) as insufficient.",
+        "description": "The fix is a vendor update with no live-patch path, and it requires a reboot, so the clock opened by the 2024-07-09 KEV listing runs to the completed restart of every affected Windows endpoint, not to update-deployment counts. An endpoint that has taken the update but not restarted still resolves the mhtml:/!x-usc: shortcut into the retired engine, and user-workstation restarts are exactly what deployment reporting conceals: 'installed, pending restart' is the state in which this remediation is recorded as complete while the path stays live. Urgency comes from the exploitation record rather than the 7.5 base score: a proof of concept is available, active exploitation is confirmed, and the technique is tied to the Void Banshee delivery of the Atlantida stealer, so every hour of the window on a user endpoint is an hour of potential credential loss rather than only of exposure. Distinguishing test: measure elapsed time from the KEV listing to each endpoint's post-update restart and report the tail rather than the mean; a fleet reported compliant on installed-update counts while endpoints await restart has not closed the window.",
+        "evidence": "The weakness is CWE-451. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-07-09, and active exploitation is confirmed. The flaw carries an RWEP score of 79 and a CVSS score of 7.5, a proof of concept is available, and the flaw was not AI-discovered. A fixed release is available, but no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. Void Banshee delivered the Atlantida stealer by exploiting this flaw. The citing gaps name NIST SP 800-53 SI-2 (Flaw Remediation), EU NIS2 Art.21 vulnerability handling and disclosure, and ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) as insufficient.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "NIS2-Art21-patch-management",
@@ -49245,8 +49245,8 @@
       {
         "id": "NEW-CTRL-017",
         "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
-        "description": "The component this flaw executes through is a retired one the OS still carries: the packet has Windows invoking the Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA because a shortcut asked for it by scheme. The vendor update fixes this defect; it does not take the engine off the host, and the invocation path that reached it is a handler the OS still resolves. The requirement here is that the compensating control an operator stands up before the update lands — an application-control policy that blocks the retired rendering path, and the HTA execution the packet describes, from being invoked out of an internet shortcut — is retained after the update with a stated review period, rather than rolled back as redundant once the fix is deployed. That is the cited least-functionality gap in operational form: least functionality reads as met because Internet Explorer is retired, while the engine behind it stays reachable to anything that names it. Preconditions: application control binds only where it is deployed and running in enforce rather than audit mode, and it governs the invocation, not the parsing — a host without that policy is carried by the update and its restart alone, and on a host where the policy is in audit mode the invocation still succeeds and is merely logged. Distinguishing test: on a fully updated managed workstation, open a test .url that uses the mhtml: scheme and confirm the policy refuses the invocation rather than the engine rendering the content; a least-functionality attestation recording that Internet Explorer is not installed passes cleanly while this path resolves.",
-        "evidence": "Packet attack_vector: 'A victim opens a crafted .url internet-shortcut whose URL uses the \"mhtml:\" scheme and an \"!x-usc:\" directive; Windows invokes the retired Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA, spoofing the perceived file type and executing code.' CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gap names NIST SP 800-53 CM-7 (Least Functionality) as insufficient.",
+        "description": "The component this flaw executes through is a retired one the OS still carries: Windows invokes the Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA because a shortcut asked for it by scheme. The vendor update fixes this defect; it does not take the engine off the host, and the invocation path that reached it is a handler the OS still resolves. The requirement here is that the compensating control an operator stands up before the update lands (an application-control policy that blocks the retired rendering path, and the HTA execution described above, from being invoked out of an internet shortcut) is retained after the update with a stated review period, rather than rolled back as redundant once the fix is deployed. That is the cited least-functionality gap in operational form: least functionality reads as met because Internet Explorer is retired, while the engine behind it stays reachable to anything that names it. Preconditions: application control binds only where it is deployed and running in enforce rather than audit mode, and it governs the invocation, not the parsing. A host without that policy is carried by the update and its restart alone, and on a host where the policy is in audit mode the invocation still succeeds and is merely logged. Distinguishing test: on a fully updated managed workstation, open a test .url that uses the mhtml: scheme and confirm the policy refuses the invocation rather than the engine rendering the content; a least-functionality attestation recording that Internet Explorer is not installed passes cleanly while this path resolves.",
+        "evidence": "A victim opens a crafted .url internet-shortcut whose URL uses the \"mhtml:\" scheme and an \"!x-usc:\" directive; Windows invokes the retired Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA, spoofing the perceived file type and executing code. The weakness is CWE-451. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-07-09, and active exploitation is confirmed. The flaw carries an RWEP score of 79 and a CVSS score of 7.5, and a proof of concept is available. A fixed release is available, but no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. The citing gap names NIST SP 800-53 CM-7 (Least Functionality) as insufficient.",
         "gap_closes": [
           "NIST-800-53-CM-7"
         ]
@@ -49294,8 +49294,8 @@
       {
         "id": "NEW-CTRL-135",
         "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
-        "description": "The NX-OS configuration CLI is the constrained user surface this control governs, and the packet describes it failing in exactly the forbidden shape: insufficient validation of arguments passed to specific configuration CLI commands lets an authenticated Administrator's crafted argument execute as an arbitrary root command on the underlying operating system. Bound to this product, the control means the values NX-OS configuration commands hand to underlying OS operations are validated at that boundary, so a command argument cannot select what the underlying OS runs and the CLI's own argument handling is not the single thing standing between an NX-OS Administrator account and root. Scope from affected_versions rather than from one headline platform: MDS 9000 Series and the Nexus 3000, 5500 platform, 5600 platform, 6000, 7000 and 9000 Series, each at the fixed release named in cisco-sa-nxos-cmd-injection-xD9OhyOP. The packet's own vector carves part of that population out and it matters for prioritisation: on Nexus 3000, on Nexus 7000 running 8.1(1) and later, and on Nexus 9000 in standalone NX-OS mode, administrative users already reach the underlying operating system through the bash-shell feature, so the flaw grants no additional privileges there — the boundary this control asserts is load-bearing on the remaining platforms, where the restricted CLI is supposed to be the privilege boundary. Precondition: the vendor update is what repairs the validation; this control states the property to verify and does not implement it. patch_required_reboot is true with no live-patching primitive, so a switch with the fixed image staged but not reloaded still runs the vulnerable code and counts as exposed. Until that reload, the only operator-side lever is limiting which accounts can open an NX-OS Administrator session, which bounds who can attempt the escalation but does not close it, because any account that legitimately reaches the configuration CLI still reaches root. And because exploitation is confirmed, a switch whose Administrator credentials may have been held by an attacker needs forensic triage and credential rotation — custom malware ran on Cisco Nexus switches for persistent, low-visibility access, and the upgrade does not remove what was left behind.",
-        "evidence": "Packet fields: cwe_refs CWE-78; vector 'A vulnerability in the CLI of Cisco NX-OS Software could allow an authenticated user in possession of Administrator credentials to execute arbitrary commands as root on the underlying operating system', 'due to insufficient validation of arguments that are passed to specific configuration CLI commands', and the note that Nexus 3000 Series, Nexus 7000 Series running releases 8.1(1) and later, and Nexus 9000 Series in standalone NX-OS mode 'already allow administrative users to access the underlying operating system through the bash-shell feature, so, for these devices, this vulnerability does not grant any additional privileges'; affected_versions 'Cisco NX-OS on MDS 9000 Series' and 'Nexus 3000, 5500 platform, 5600 platform, 6000, 7000, and 9000 Series (fixed releases per cisco-sa-nxos-cmd-injection-xD9OhyOP)'; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'; active_exploitation 'confirmed' with active_exploitation_notes describing Velvet Ant using it as a zero-day 'to run custom malware on Cisco Nexus switches for persistent, low-visibility access'; NIST-800-53-AC-6 gap 'The flaw defeats the CLI/root privilege separation on NX-OS, so least-privilege between admin-CLI and the underlying OS is not actually enforced.'; ISO-27001-2022-A.8.8 gap 'Technical vulnerability management assumes patch closure suffices, but the zero-day was exploited pre-fix by a state actor with valid admin access.'",
+        "description": "The NX-OS configuration CLI is the constrained user surface this control governs, and this flaw is that surface failing in exactly the forbidden shape: insufficient validation of arguments passed to specific configuration CLI commands lets an authenticated Administrator's crafted argument execute as an arbitrary root command on the underlying operating system. Bound to this product, the control means the values NX-OS configuration commands hand to underlying OS operations are validated at that boundary, so a command argument cannot select what the underlying OS runs and the CLI's own argument handling is not the single thing standing between an NX-OS Administrator account and root. Scope from the full list of affected platforms rather than from one headline platform: MDS 9000 Series and the Nexus 3000, 5500 platform, 5600 platform, 6000, 7000 and 9000 Series, each at the fixed release named in cisco-sa-nxos-cmd-injection-xD9OhyOP. Part of that population is carved out, and it matters for prioritization: on Nexus 3000, on Nexus 7000 running 8.1(1) and later, and on Nexus 9000 in standalone NX-OS mode, administrative users already reach the underlying operating system through the bash-shell feature, so the flaw grants no additional privileges there. The boundary this control asserts is load-bearing on the remaining platforms, where the restricted CLI is supposed to be the privilege boundary. Precondition: the vendor update is what repairs the validation; this control states the property to verify and does not implement it. The fix requires a reboot and there is no live-patching primitive, so a switch with the fixed image staged but not reloaded still runs the vulnerable code and counts as exposed. Until that reload, the only operator-side lever is limiting which accounts can open an NX-OS Administrator session, which bounds who can attempt the escalation but does not close it, because any account that legitimately reaches the configuration CLI still reaches root. And because exploitation is confirmed, a switch whose Administrator credentials may have been held by an attacker needs forensic triage and credential rotation: custom malware ran on Cisco Nexus switches for persistent, low-visibility access, and the upgrade does not remove what was left behind.",
+        "evidence": "The weakness is CWE-78. A vulnerability in the CLI of Cisco NX-OS Software could allow an authenticated user in possession of Administrator credentials to execute arbitrary commands as root on the underlying operating system, due to insufficient validation of arguments that are passed to specific configuration CLI commands. Nexus 3000 Series, Nexus 7000 Series running releases 8.1(1) and later, and Nexus 9000 Series in standalone NX-OS mode already allow administrative users to access the underlying operating system through the bash-shell feature, so, for these devices, this vulnerability does not grant any additional privileges. The affected products are Cisco NX-OS on MDS 9000 Series and Nexus 3000, 5500 platform, 5600 platform, 6000, 7000, and 9000 Series (fixed releases per cisco-sa-nxos-cmd-injection-xD9OhyOP). A fixed release is available and requires a reboot, and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. Active exploitation is confirmed: Velvet Ant used it as a zero-day to run custom malware on Cisco Nexus switches for persistent, low-visibility access. The NIST-800-53-AC-6 gap states that the flaw defeats the CLI/root privilege separation on NX-OS, so least-privilege between admin-CLI and the underlying OS is not actually enforced. The ISO-27001-2022-A.8.8 gap states that technical vulnerability management assumes patch closure suffices, but the zero-day was exploited pre-fix by a state actor with valid admin access.",
         "gap_closes": [
           "NIST-800-53-AC-6",
           "ISO-27001-2022-A.8.8"
@@ -49305,7 +49305,7 @@
         "id": "NEW-CTRL-036",
         "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
         "description": "The packet makes stolen Administrator credentials the entire precondition for this CVE — it functions as a stealthy escape from the CLI to root for an actor who already holds an admin credential — which is why patch timelines alone leave the chain intact. For this CVE the control means the accounts that administer the NX-OS fabric named in affected_versions (MDS 9000 and the Nexus 3000, 5500 platform, 5600 platform, 6000, 7000 and 9000 Series) are enumerated as a distinct control-plane admin tier rather than collapsed into a general 'network admin' role: the switch management interfaces reachable only from a PAM jumphost, the NX-OS Administrator identity separate from the operator's other accounts, elevation issued just-in-time against an approval record rather than standing, and a phishing-resistant step-up in the authentication path so a credential harvested elsewhere does not by itself open an Administrator session. Where a device's own admin authentication path cannot carry a phishing-resistant factor directly, the enforceable form is the jumphost and the step-up at that hop, with the residual recorded — the control's requirement is that the tier be enumerated and enforced somewhere in the path, not that a claim be made about what the switch's login supports. This is the half that bites during the window before the reload, because it attacks the precondition rather than the injection sink. Precondition and limit: it changes how a session is obtained and does nothing once one is legitimately open. An attacker who compromises the jumphost, satisfies the step-up, or is an authorised administrator still reaches root through the unfixed CLI, so this is a holding measure that runs alongside the fixed release from cisco-sa-nxos-cmd-injection-xD9OhyOP and its reload, never a substitute for it.",
-        "evidence": "Packet fields: vector 'To successfully exploit this vulnerability on a Cisco NX-OS device, an attacker must have Administrator credentials'; active_exploitation_notes 'requires stolen Administrator credentials, so it functions as a stealthy escape from the CLI to root', with exploitation attributed by Sygnia to the China-nexus espionage group Velvet Ant; UK-CAF-B2 gap 'The chain depends on already-stolen administrator credentials, so the CAF's identity objective — phishing-resistant MFA on network-device admin access — is the load-bearing control, yet B2 doesn't force out-of-band MFA on switch CLI logins that would break the credential precondition.'; NIS2-Art21-network-security gap 'Network-security obligations for critical infrastructure do not force out-of-band admin credential hardening (phishing-resistant MFA) that would blunt the credential-dependent chain.'; NIST-800-53-SI-2 gap 'Even prompt patching leaves exposure because exploitation requires already-stolen admin credentials; flaw remediation does not address the credential-theft precondition.'; AU-Essential-8-Patch gap 'no strategy mandates the MFA that blunts the credential-theft chain'; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "evidence": "To successfully exploit this vulnerability on a Cisco NX-OS device, an attacker must have Administrator credentials. Exploitation requires stolen Administrator credentials, so it functions as a stealthy escape from the CLI to root, with exploitation attributed by Sygnia to the China-nexus espionage group Velvet Ant. The UK-CAF-B2 gap states that the chain depends on already-stolen administrator credentials, so the CAF's identity objective (phishing-resistant MFA on network-device admin access) is the load-bearing control, yet B2 doesn't force out-of-band MFA on switch CLI logins that would break the credential precondition. The NIS2-Art21-network-security gap states that network-security obligations for critical infrastructure do not force out-of-band admin credential hardening (phishing-resistant MFA) that would blunt the credential-dependent chain. The NIST-800-53-SI-2 gap states that even prompt patching leaves exposure because exploitation requires already-stolen admin credentials; flaw remediation does not address the credential-theft precondition. The AU-Essential-8-Patch gap states that no strategy mandates the MFA that blunts the credential-theft chain. A fixed release is available and requires a reboot, and no live patch is available.",
         "gap_closes": [
           "UK-CAF-B2",
           "NIS2-Art21-network-security",
@@ -49356,8 +49356,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "The distinguishing fact on this entry is the interval. The fix is in Roundcube Webmail 1.3.12 and 1.4.5 and the KEV listing is dated 2024-06-26, so the KEV clock opens on a fix that has been available for years — which makes the work here discovery rather than scheduling. The packet's own flaw-remediation gap names it: self-hosted Roundcube instances go long-unpatched, and the flaw reached KEV four years after the fix shipped. So the SLA's first deliverable is an enumeration of every Roundcube deployment the organisation's users can reach, including the instances that arrived with a hosting package, run on a departmental or project server, or survived a mail migration as a fallback interface — an SLA measured against a list that contains only the sanctioned webmail host will report complete while the exposed instance is one nobody owns. Record the running version of each against 1.3.12 or 1.4.5 and later, and measure completion on the version the instance actually serves to a browser rather than the version in a package manifest or a change ticket; the packet registers no live-patch path, so an instance whose files were replaced while the old code is still being served has not been remediated. Because exploitation is confirmed with a public PoC, and the outcome is mail, contacts and session tokens taken from the authenticated session, an instance found below the fixed version is an incident question as well as a patch item: updating the code closes the preview path but tells you nothing about what was read from the mailboxes while it was open, so the sessions and credentials that instance carried need invalidating and rotating rather than being closed on the version number.",
-        "evidence": "The packet's vector records an issue in Roundcube Webmail before 1.3.12 and 1.4.x before 1.4.5, with XSS via a malicious XML attachment because text/xml is among the allowed types for a preview; affected_versions lists < 1.3.12 and 1.4.0 through 1.4.4. cisa_kev true with kev_date 2024-06-26, active_exploitation confirmed, poc_available true, CVSS 6.1, RWEP 64. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes stating there is no live-patching primitive for this product and the vendor update is the remediation. The cited flaw-remediation gap states the fix shipped in 2020 but the flaw reached KEV in 2024, showing self-hosted Roundcube instances go long-unpatched; the cited technical-vulnerability-management gap states a 'medium' XSS is often deprioritized but in webmail yields full mailbox compromise for high-value diplomatic targets. attack_vector states attacker JavaScript runs in the authenticated webmail session and can steal mail, contacts and session tokens; active_exploitation_notes records Roundcube XSS flaws being chained by espionage actors against government and diplomatic targets, with KEV ransomware status Unknown.",
+        "description": "The distinguishing fact on this entry is the interval. The fix is in Roundcube Webmail 1.3.12 and 1.4.5 and the KEV listing is dated 2024-06-26, so the KEV clock opens on a fix that has been available for years, which makes the work here discovery rather than scheduling. The flaw-remediation gap on this entry names it: self-hosted Roundcube instances go long-unpatched, and the flaw reached KEV four years after the fix shipped. So the SLA's first deliverable is an enumeration of every Roundcube deployment the organization's users can reach, including the instances that arrived with a hosting package, run on a departmental or project server, or survived a mail migration as a fallback interface. An SLA measured against a list that contains only the sanctioned webmail host will report complete while the exposed instance is one nobody owns. Record the running version of each against 1.3.12 or 1.4.5 and later, and measure completion on the version the instance actually serves to a browser rather than the version in a package manifest or a change ticket; there is no live-patch path, so an instance whose files were replaced while the old code is still being served has not been remediated. Because exploitation is confirmed with a public PoC, and the outcome is mail, contacts and session tokens taken from the authenticated session, an instance found below the fixed version is an incident question as well as a patch item: updating the code closes the preview path but tells you nothing about what was read from the mailboxes while it was open, so the sessions and credentials that instance carried need invalidating and rotating rather than being closed on the version number.",
+        "evidence": "The issue is in Roundcube Webmail before 1.3.12 and 1.4.x before 1.4.5, with XSS via a malicious XML attachment because text/xml is among the allowed types for a preview; the affected versions are < 1.3.12 and 1.4.0 through 1.4.4. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-06-26. Active exploitation is confirmed, a proof of concept is available, and the flaw carries a CVSS score of 6.1 and an RWEP score of 64. A fixed release is available and does not require a reboot, and no live patch is available: there is no live-patching primitive for this product, and the vendor update is the remediation. The cited flaw-remediation gap states the fix shipped in 2020 but the flaw reached KEV in 2024, showing self-hosted Roundcube instances go long-unpatched; the cited technical-vulnerability-management gap states a 'medium' XSS is often deprioritized but in webmail yields full mailbox compromise for high-value diplomatic targets. Attacker JavaScript runs in the authenticated webmail session and can steal mail, contacts and session tokens. Espionage actors have chained Roundcube XSS flaws against government and diplomatic targets, and the KEV ransomware status is Unknown.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "ISO-27001-2022-A.8.8"
@@ -49366,8 +49366,8 @@
       {
         "id": "NEW-CTRL-040",
         "name": "OWA-PER-REQUEST-SIEM-INGESTION",
-        "description": "Applied to Roundcube, this control requires the webmail tier's per-request access logs — the web-server request log for the webmail vhost plus the application's own action log, not the login events — to be forwarded to a SIEM off the webmail host, with retention long enough to cover an instance discovered years after the fix shipped. The reason is the exact shape of this exploit: the packet has attacker JavaScript executing when the victim previews a text/xml attachment, running inside the victim's own already-authenticated session. So the requests that steal the mailbox are indistinguishable at the authentication layer from the victim working — one successful login is recorded, and everything after it belongs to a valid session. What an exploit doing exactly what the packet describes emits is a request stream: a fetch of an attachment part whose declared type is text/xml as the message is previewed, followed within that same session by a run of message-fetch, contact and attachment requests at a pace and breadth that does not match a person reading mail, which is the packet's own stated outcome of mail, contacts and session tokens taken from the session. That pairing — the preview of an XML part, then bulk reads in the same session — is the rule; either half alone is ordinary webmail traffic. Note what will not see it: no file lands on the host and no process is spawned, so signature-based endpoint tooling has no artifact to match; the traffic is TLS to the organisation's own webmail from the user's normal client, so network-indicator monitoring sees nothing anomalous, which is precisely the security-monitoring gap on this entry; and alerting on failed logins or on new authentications would miss an attempt that behaves exactly as described. Precondition: per-request logging has to be enabled and shipped off-host before the attempt. A deployment that logs only authentication, or that keeps its request log locally on the very webmail server the attacker's script is operating inside, produces nothing for an after-the-fact rule to run against. And detection does not prevent the theft — the script runs the moment the message is previewed — so this bounds the exposure to alert-and-response time (session invalidation, credential rotation, mailbox review) during the period before the 1.3.12 / 1.4.5 update removes the preview path.",
-        "evidence": "The packet's attack_vector states an attacker emails a crafted text/xml attachment and that when the victim previews it in a vulnerable Roundcube version attacker JavaScript runs in the authenticated webmail session and can steal mail, contacts and session tokens; the vector records that text/xml is among the allowed types for a preview. The cited security-monitoring gap states that monitoring focused on network indicators misses client-side script execution within the webmail DOM, delaying detection of mailbox exfiltration; the cited network-security gap states that network-security measures do not inspect authenticated in-app script execution, so an XSS running inside the trusted webmail session evades perimeter controls. active_exploitation is confirmed with poc_available true, kev_date 2024-06-26, and active_exploitation_notes recording Roundcube XSS being chained by espionage actors to steal mail and session data from government and diplomatic targets. patch_available true with the fixed releases recorded as 1.3.12 and 1.4.5, live_patch_available false.",
+        "description": "Applied to Roundcube, this control requires the webmail tier's per-request access logs (the web-server request log for the webmail vhost plus the application's own action log, not the login events) to be forwarded to a SIEM off the webmail host, with retention long enough to cover an instance discovered years after the fix shipped. The reason is the exact shape of this exploit: attacker JavaScript executes when the victim previews a text/xml attachment, running inside the victim's own already-authenticated session. So the requests that steal the mailbox are indistinguishable at the authentication layer from the victim working: one successful login is recorded, and everything after it belongs to a valid session. What an exploit doing exactly that emits is a request stream: a fetch of an attachment part whose declared type is text/xml as the message is previewed, followed within that same session by a run of message-fetch, contact and attachment requests at a pace and breadth that does not match a person reading mail, which is the exploit's stated outcome of mail, contacts and session tokens taken from the session. That pairing (the preview of an XML part, then bulk reads in the same session) is the rule; either half alone is ordinary webmail traffic. Note what will not see it: no file lands on the host and no process is spawned, so signature-based endpoint tooling has no artifact to match; the traffic is TLS to the organization's own webmail from the user's normal client, so network-indicator monitoring sees nothing anomalous, which is precisely the security-monitoring gap on this entry; and alerting on failed logins or on new authentications would miss an attempt that behaves exactly as described. Precondition: per-request logging has to be enabled and shipped off-host before the attempt. A deployment that logs only authentication, or that keeps its request log locally on the very webmail server the attacker's script is operating inside, produces nothing for an after-the-fact rule to run against. And detection does not prevent the theft (the script runs the moment the message is previewed), so this bounds the exposure to alert-and-response time (session invalidation, credential rotation, mailbox review) during the period before the 1.3.12 / 1.4.5 update removes the preview path.",
+        "evidence": "An attacker emails a crafted text/xml attachment, and when the victim previews it in a vulnerable Roundcube version, attacker JavaScript runs in the authenticated webmail session and can steal mail, contacts and session tokens; text/xml is among the allowed types for a preview. The cited security-monitoring gap states that monitoring focused on network indicators misses client-side script execution within the webmail DOM, delaying detection of mailbox exfiltration; the cited network-security gap states that network-security measures do not inspect authenticated in-app script execution, so an XSS running inside the trusted webmail session evades perimeter controls. Active exploitation is confirmed and a proof of concept is available. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-06-26, and espionage actors have chained Roundcube XSS to steal mail and session data from government and diplomatic targets. Fixed releases are available as 1.3.12 and 1.4.5, and no live patch is available.",
         "gap_closes": [
           "UK-CAF-C1",
           "NIS2-Art21-network-security"
@@ -49377,7 +49377,7 @@
         "id": "NEW-CTRL-119",
         "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
         "description": "The decision this flaw turns on is a rendering decision taken from attacker-supplied metadata: text/xml is among the allowed types for a preview, so the attachment's declared content type is what selects the inline-preview path that carries the payload, and the sender controls that value. Applied to this product, the control requires that whether an email attachment is treated as inert or as active content be established outside the message — by the mail boundary inspecting what the attachment actually is — rather than inherited from the type the sender declared, and that the resulting classification survive the container the attachment arrives in, so an XML document nested in an archive or renamed is still handled as active content. The mail boundary is where this is enforceable, because it is the only point that sees the message before it is stored in a mailbox where the victim can preview it. The two gaps this closes are exactly that omission: malicious-code and attachment inspection typically does not treat a benign-looking XML attachment as active content, and Essential-Eight user-application hardening does not treat a text/xml email attachment as active content — so both attest clean while the script-bearing preview reaches the reading pane. Distinguishing test: send an XML attachment carrying a script payload through each mail ingress path to a test mailbox, once plain and once inside an archive, and confirm it arrives classified as active content — quarantined, stripped, or marked so the client will not inline it — rather than confirming only that an attachment policy exists in the console. Precondition, and it is the load-bearing one: this bounds delivery, it does not repair the sanitizer. A gateway rule applied today does nothing about messages already sitting in mailboxes, and this flaw fires when a stored message is previewed, so with confirmed exploitation and a public PoC on the record, mailboxes served by a vulnerable instance need reviewing rather than being closed on the new rule. It also does not cover mail arriving by a path the gateway does not front. Only the update to 1.3.12 or 1.4.5 removes the preview path itself.",
-        "evidence": "The packet's vector states the XSS occurs via a malicious XML attachment because text/xml is among the allowed types for a preview, in Roundcube Webmail before 1.3.12 and 1.4.x before 1.4.5. The cited malicious-code-protection gap states that malicious-code / attachment inspection typically does not treat a benign-looking XML attachment as active content, so the script-bearing preview slips past content filtering; the cited user-application-hardening gap states Essential-Eight hardening does not treat a text/xml email attachment as active content, so the script-bearing XML previews in Roundcube despite hardening. attack_vector records that the payload executes when the victim previews the attachment, running in the authenticated webmail session. active_exploitation confirmed, poc_available true, kev_date 2024-06-26, CVSS 6.1, RWEP 64. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes recording the vendor update as the remediation.",
+        "evidence": "The XSS occurs via a malicious XML attachment because text/xml is among the allowed types for a preview, in Roundcube Webmail before 1.3.12 and 1.4.x before 1.4.5. The cited malicious-code-protection gap states that malicious-code / attachment inspection typically does not treat a benign-looking XML attachment as active content, so the script-bearing preview slips past content filtering; the cited user-application-hardening gap states Essential-Eight hardening does not treat a text/xml email attachment as active content, so the script-bearing XML previews in Roundcube despite hardening. The payload executes when the victim previews the attachment, running in the authenticated webmail session. Active exploitation is confirmed, a proof of concept is available, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-06-26. The flaw carries a CVSS score of 6.1 and an RWEP score of 64. A fixed release is available and does not require a reboot, no live patch is available, and the vendor update is the remediation.",
         "gap_closes": [
           "NIST-800-53-SI-3",
           "AU-Essential-8-App-Hardening"
@@ -49426,8 +49426,8 @@
       {
         "id": "NEW-CTRL-130",
         "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
-        "description": "This flaw's precondition is explicit rather than implicit: the local attacker needs CAP_NET_ADMIN before the netfilter nf_tables configuration path is reachable at all, and the attack vector says that capability is often obtained through an unprivileged user namespace. For this CVE the control means unprivileged user-namespace creation (kernel.unprivileged_userns_clone) is disabled on every Linux host whose workloads do not genuinely require it, and each container is confined with an LSM profile plus a seccomp profile that does not hand it CAP_NET_ADMIN — because on a host still running a kernel without the nf_tables fix, that combination removes the entry condition while the reboot onto the fixed kernel is pending. On a container host the boundary claim itself is what is at stake: a confined workload able to create a user namespace holds CAP_NET_ADMIN inside it, creates an nft object referencing a set in a different table, deletes that table to free the set, and reclaims the dangling object as host root, so the confinement is not a boundary and the kernel is the only thing left. Distinguishing test: from a representative unprivileged container or an ordinary user session on a staging host running an affected kernel, create a user namespace and attempt the cross-table nft object/set configuration the packet describes, and confirm it is refused before the set can be freed. Two preconditions, both routinely skipped when this control is claimed. It closes only the user-namespace route — a process that already holds CAP_NET_ADMIN in the host's initial namespace (a container deliberately granted NET_ADMIN, a firewall or network-management daemon, a service account carrying the capability) reaches the identical path with unprivileged userns disabled, so that population must have the capability withdrawn or be counted as exposed until it reboots onto the fixed kernel. And it is unavailable on hosts that need unprivileged user namespaces to function — rootless container runtimes, build and CI hosts, sandboxes built on the same primitive — where the interim measure is detection plus the reboot, not this. Note also what is not available here: nf_tables is the host's own packet-filtering path, so unloading or blacklisting the subsystem is not the least-functionality answer the way an unused driver would be.",
-        "evidence": "Packet attack_vector: 'A local user obtains CAP_NET_ADMIN (often via an unprivileged user namespace), creates an nft object referencing a set in another table, deletes that table to free the set, and reclaims the dangling object to corrupt kernel memory and escalate to root.' The NIST-800-53-CM-7 gap records that 'Least-functionality controls rarely disable unprivileged user namespaces (kernel.unprivileged_userns_clone), which is what grants the CAP_NET_ADMIN needed to reach the nf_tables path'; the UK-CAF-B4 gap records that 'System-security assurance for Linux hosts seldom disables unprivileged user namespaces, the very setting that grants the CAP_NET_ADMIN this nf_tables use-after-free needs; CAF sets no requirement for that compensating control while the KEV-listed kernel LPE awaits a reboot'; the NIS2-Art21-patch-management gap records that patch-management obligations 'do not mandate the compensating control (disabling unprivileged userns) while kernel updates are pending.' An interim measure is needed because patch_available is true but patch_required_reboot is true and live_patch_available is false, with live_patch_notes stating 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' cisa_kev true (kev_date 2024-06-26), active_exploitation confirmed, poc_available true, rwep_score 73, cvss 7.8.",
+        "description": "This flaw's precondition is explicit rather than implicit: the local attacker needs CAP_NET_ADMIN before the netfilter nf_tables configuration path is reachable at all, and that capability is often obtained through an unprivileged user namespace. For this CVE the control means unprivileged user-namespace creation (kernel.unprivileged_userns_clone) is disabled on every Linux host whose workloads do not genuinely require it, and each container is confined with an LSM profile plus a seccomp profile that does not hand it CAP_NET_ADMIN, because on a host still running a kernel without the nf_tables fix, that combination removes the entry condition while the reboot onto the fixed kernel is pending. On a container host the boundary claim itself is what is at stake: a confined workload able to create a user namespace holds CAP_NET_ADMIN inside it, creates an nft object referencing a set in a different table, deletes that table to free the set, and reclaims the dangling object as host root, so the confinement is not a boundary and the kernel is the only thing left. Distinguishing test: from a representative unprivileged container or an ordinary user session on a staging host running an affected kernel, create a user namespace and attempt the cross-table nft object/set configuration described above, and confirm it is refused before the set can be freed. Two preconditions apply, and both are routinely skipped when this control is claimed. It closes only the user-namespace route: a process that already holds CAP_NET_ADMIN in the host's initial namespace (a container deliberately granted NET_ADMIN, a firewall or network-management daemon, a service account carrying the capability) reaches the identical path with unprivileged userns disabled, so that population must have the capability withdrawn or be counted as exposed until it reboots onto the fixed kernel. And it is unavailable on hosts that need unprivileged user namespaces to function, such as rootless container runtimes, build and CI hosts, and sandboxes built on the same primitive, where the interim measure is detection plus the reboot, not this. Note also what is not available here: nf_tables is the host's own packet-filtering path, so unloading or blacklisting the subsystem is not the least-functionality answer the way an unused driver would be.",
+        "evidence": "A local user obtains CAP_NET_ADMIN (often via an unprivileged user namespace), creates an nft object referencing a set in another table, deletes that table to free the set, and reclaims the dangling object to corrupt kernel memory and escalate to root. The NIST-800-53-CM-7 gap records that 'Least-functionality controls rarely disable unprivileged user namespaces (kernel.unprivileged_userns_clone), which is what grants the CAP_NET_ADMIN needed to reach the nf_tables path'; the UK-CAF-B4 gap records that 'System-security assurance for Linux hosts seldom disables unprivileged user namespaces, the very setting that grants the CAP_NET_ADMIN this nf_tables use-after-free needs; CAF sets no requirement for that compensating control while the KEV-listed kernel LPE awaits a reboot'; the NIS2-Art21-patch-management gap records that patch-management obligations 'do not mandate the compensating control (disabling unprivileged userns) while kernel updates are pending.' An interim measure is needed because a fixed release is available but installing it requires a reboot, and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-06-26, and active exploitation is confirmed. A proof of concept is available, the RWEP score is 73, and the CVSS score is 7.8.",
         "gap_closes": [
           "NIST-800-53-CM-7",
           "UK-CAF-B4",
@@ -49438,7 +49438,7 @@
         "id": "NEW-CTRL-145",
         "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
         "description": "This is a local privilege escalation in the Linux kernel's netfilter nf_tables subsystem, so for this CVE the control means the distro kernel update carrying the backported nf_tables fix is driven across every affected host on the clock that opened with the 2024-06-26 KEV listing, rather than folded into the next quarterly maintenance window — with completion measured against the kernel the host is actually executing, not against the kernel package a configuration-management console reports as installed. The packet makes that distinction load-bearing: patch_required_reboot is true and live_patch_available is false, with the entry recording that the vendor update requires a reboot and is the remediation, so a host that has taken the new kernel package but has not rebooted onto it still runs the vulnerable code and must be counted as exposed. On the multi-user and long-uptime hosts most exposed to a local escalation the reboot is precisely the step that gets deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Scoping cannot be done by kernel version number alone: the defect has been present since v3.16-rc1, and distro kernels prior to the backported nf_tables patch (RHEL/Ubuntu/SUSE) are a separate affected population, so a vendor kernel with a lower upstream base may already carry the backport while a higher-numbered one does not — each host has to be compared against the fixed build its own distro published for that kernel line. Enumerate first the hosts where the flaw's precondition is the normal operating state rather than an anomaly: shared and multi-user systems, CI and build runners, and container hosts, anywhere unprivileged local code runs by design. Priority follows the exploitation facts rather than the CVSS band — a 7.8 with a local vector reads as a deferrable endpoint item, while active exploitation is confirmed, a public PoC exists and a KEV listing covers a primitive that converts any code execution as a local user into root, which is what makes it a containment step for a chain rather than a standalone item.",
-        "evidence": "Packet fields: patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' cisa_kev true with kev_date 2024-06-26; active_exploitation confirmed; active_exploitation_notes 'Added to CISA KEV 2024-06-26 as actively exploited. A use-after-free in the Linux kernel nf_tables (nft_object cross-table set reference) lets a local attacker with CAP_NET_ADMIN escalate to root. Ransomware association is unconfirmed.' poc_available true; cvss 7.8; rwep_score 73. Scope from affected ('Present since v3.16-rc1') and affected_versions ('Linux kernel >= 3.16-rc1 prior to the netfilter fix', 'distro kernels prior to the backported nf_tables patch (RHEL/Ubuntu/SUSE)'). The NIST-800-53-SI-2 gap records that 'Kernel patch-deployment cadence and reboot windows leave hosts exposed long after a working public LPE exists'; the AU-Essential-8-Patch gap that 'Patch-application timeframes for OS/kernel are measured in weeks, exceeding the exploitation window for a KEV-listed kernel LPE'; the ISO-27001-2022-A.8.8 gap that vulnerability management 'typically prioritizes remote flaws, deprioritizing a local kernel UAF that is in fact a ready root primitive for post-exploitation.'",
+        "evidence": "A fixed release is available, installing it requires a reboot, and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2024-06-26 as actively exploited, and active exploitation is confirmed. A use-after-free in the Linux kernel nf_tables (nft_object cross-table set reference) lets a local attacker with CAP_NET_ADMIN escalate to root. Ransomware association is unconfirmed. A proof of concept is available, the CVSS score is 7.8, and the RWEP score is 73. The flaw has been present since v3.16-rc1; the affected versions are Linux kernel >= 3.16-rc1 prior to the netfilter fix, and distro kernels prior to the backported nf_tables patch (RHEL/Ubuntu/SUSE). The NIST-800-53-SI-2 gap records that 'Kernel patch-deployment cadence and reboot windows leave hosts exposed long after a working public LPE exists'; the AU-Essential-8-Patch gap records that 'Patch-application timeframes for OS/kernel are measured in weeks, exceeding the exploitation window for a KEV-listed kernel LPE'; the ISO-27001-2022-A.8.8 gap records that vulnerability management 'typically prioritizes remote flaws, deprioritizing a local kernel UAF that is in fact a ready root primitive for post-exploitation.'",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "AU-Essential-8-Patch",
@@ -49448,8 +49448,8 @@
       {
         "id": "NEW-CTRL-003",
         "name": "KERNEL-EXPLOITATION-DETECTION",
-        "description": "On hosts that cannot yet take the reboot, and on the hosts where unprivileged user namespaces must stay enabled for rootless containers or build sandboxes, detection is the only interim measure left — and the packet describes the exploitation behaviour precisely enough to key on it instead of on a guess. The rule keys on the sequence the packet's attack vector states: an unprivileged uid creating a user namespace, followed within the same session lineage by nf_tables netlink configuration traffic that creates an nft object referencing a set belonging to a different table and then deletes that table, paired with the outcome the packet names — a privilege transition to uid 0 in a process descended from that non-root session. Both halves are needed. Netlink nf_tables configuration on its own is what ordinary firewall tooling does all day on a firewall or container host, and a uid-0 transition on its own arrives with no context; it is the pairing inside a short window, from a session that began unprivileged, that separates this exploit from routine administration. Note what will not see it: nothing is compiled, no kernel module is loaded, no setuid binary changes, and the attacker uses the kernel's normal configuration interface, so file-integrity monitoring and signature-matching endpoint tooling have no artifact to match, and a rule written against process crashes or named exploit tooling would miss an attempt that behaves exactly as the packet describes — with poc_available true, the exact sequence is public and need not resemble any particular tool. Preconditions: this requires host audit or eBPF telemetry already being collected and shipped off-host before the attempt, which on shared multi-user hosts is exactly where it is least often enabled, and a rule authored after the fact against telemetry nobody collected produces nothing. Detection also does not prevent the escalation and does not undo root already obtained — it bounds the window to alert-and-response time during the period before the host reboots onto the fixed kernel.",
-        "evidence": "Packet attack_vector: 'A local user obtains CAP_NET_ADMIN (often via an unprivileged user namespace), creates an nft object referencing a set in another table, deletes that table to free the set, and reclaims the dangling object to corrupt kernel memory and escalate to root.' active_exploitation confirmed and poc_available true. The interim window exists because patch_required_reboot is true and live_patch_available is false ('No live-patching primitive for this product; the vendor update requires a reboot and is the remediation'). The NIS2-Art21-patch-management gap records that 'Patch-management obligations do not mandate the compensating control (disabling unprivileged userns) while kernel updates are pending' — this control covers that pending window on the hosts where disabling unprivileged user namespaces is not available.",
+        "description": "On hosts that cannot yet take the reboot, and on the hosts where unprivileged user namespaces must stay enabled for rootless containers or build sandboxes, detection is the only interim measure left, and the exploitation sequence is specific enough to key a rule on it instead of on a guess. The rule keys on that sequence: an unprivileged uid creating a user namespace, followed within the same session lineage by nf_tables netlink configuration traffic that creates an nft object referencing a set belonging to a different table and then deletes that table, paired with the resulting privilege transition to uid 0 in a process descended from that non-root session. Both halves are needed. Netlink nf_tables configuration on its own is what ordinary firewall tooling does all day on a firewall or container host, and a uid-0 transition on its own arrives with no context; it is the pairing inside a short window, from a session that began unprivileged, that separates this exploit from routine administration. Note what will not see it: nothing is compiled, no kernel module is loaded, no setuid binary changes, and the attacker uses the kernel's normal configuration interface, so file-integrity monitoring and signature-matching endpoint tooling have no artifact to match, and a rule written against process crashes or named exploit tooling would miss an attempt that behaves exactly as described here. Because a proof of concept is available, the exact sequence is public and need not resemble any particular tool. Preconditions: this requires host audit or eBPF telemetry already being collected and shipped off-host before the attempt, which on shared multi-user hosts is exactly where it is least often enabled, and a rule authored after the fact against telemetry nobody collected produces nothing. Detection also does not prevent the escalation and does not undo root already obtained; it bounds the window to alert-and-response time during the period before the host reboots onto the fixed kernel.",
+        "evidence": "A local user obtains CAP_NET_ADMIN (often via an unprivileged user namespace), creates an nft object referencing a set in another table, deletes that table to free the set, and reclaims the dangling object to corrupt kernel memory and escalate to root. Active exploitation is confirmed, and a proof of concept is available. The interim window exists because installing the fix requires a reboot and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. The NIS2-Art21-patch-management gap records that 'Patch-management obligations do not mandate the compensating control (disabling unprivileged userns) while kernel updates are pending.' This control covers that pending window on the hosts where disabling unprivileged user namespaces is not available.",
         "gap_closes": [
           "NIS2-Art21-patch-management"
         ]
@@ -49497,7 +49497,7 @@
       {
         "id": "NEW-CTRL-021",
         "name": "TIER-3-DEPENDENCY-INVENTORY",
-        "description": "The vulnerable code is not GeoServer — it is jt-jiffle inside JAI-EXT, which GeoServer bundles, and the execution runs a level further down through Janino, which compiles the supplied Jiffle script into Java. An inventory that records the GeoServer version and stops there cannot answer whether a given deployment carries the vulnerable component, which is exactly how an estate keeps a maximum-severity unauthenticated RCE it does not know it has. Applied here the control means the inventory resolves to the JAR level for these deployments: record the jt-jiffle version each instance loads against the fixed 1.1.22 / 1.2.22 line as well as the GeoServer version against 2.18.6, 2.19.6 and 2.20.4, and search for the jt-jiffle artifact itself rather than only for the product name. The packet describes the flaw as affecting programs that allow a Jiffle script to be supplied via network request, with GeoServer named as the downstream project it particularly affects, so any other application in the estate that bundles jt-jiffle carries the same compile-and-execute sink and a product-name sweep will report it clean. This is also the step that reaches the unattended instance: a GeoServer standing up a public map service outside routine maintenance cannot be placed on any remediation clock until an inventory names both the instance and the component inside it.",
+        "description": "The vulnerable code is not GeoServer; it is jt-jiffle inside JAI-EXT, which GeoServer bundles, and the execution runs a level further down through Janino, which compiles the supplied Jiffle script into Java. An inventory that records the GeoServer version and stops there cannot answer whether a given deployment carries the vulnerable component, which is exactly how an estate keeps a maximum-severity unauthenticated RCE it does not know it has. Applied here the control means the inventory resolves to the JAR level for these deployments: record the jt-jiffle version each instance loads against the fixed 1.1.22 / 1.2.22 line as well as the GeoServer version against 2.18.6, 2.19.6 and 2.20.4, and search for the jt-jiffle artifact itself rather than only for the product name. The flaw affects programs that allow a Jiffle script to be supplied via network request, and GeoServer is the downstream project it particularly affects, so any other application in the estate that bundles jt-jiffle carries the same compile-and-execute sink and a product-name sweep will report it clean. This is also the step that reaches the unattended instance: a GeoServer standing up a public map service outside routine maintenance cannot be placed on any remediation clock until an inventory names both the instance and the component inside it.",
         "evidence": "The affected field identifies JAI-EXT jt-jiffle (used by GeoServer) as the vulnerable component, and the vector states that programs allowing Jiffle script to be provided via network request can lead to remote code execution because the script is compiled into Java code via Janino and executed, and that this in particular affects the downstream GeoServer project. affected_versions gives JAI-EXT (jt-jiffle) before 1.1.22 / 1.2.22 and GeoServer before 2.18.6 / 2.19.6 / 2.20.4. The cited A.8.8 gap states that technical-vulnerability management must track transitive dependencies — jt-jiffle inside GeoServer — because a top-level GeoServer inventory alone misses the vulnerable component; the UK CAF gap records GeoServer instances as frequently deployed as unattended GIS infrastructure outside routine maintenance, and the NIS2 gap records vulnerability-management obligations as not by themselves surfacing what is needed here.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
@@ -49509,7 +49509,7 @@
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
         "description": "This CVE ships with exactly the configuration-side path this control requires operators to hold ready: users unable to upgrade may negate the ability to compile Jiffle scripts from the final application by removing janino-x.y.z.jar from the classpath, which takes the compile-and-execute sink out of reach without waiting for the JAI-EXT or GeoServer release. The requirement is that this path is inventoried, tested on a staging instance, and deployable independently of the upgrade path — and it matters more than usual here because segmentation is not an alternative: the packet's boundary-protection gap records the Jiffle-backed WPS process as reachable on the same unauthenticated WMS/OWS endpoint the service exists to publish, so there is no network restriction that removes the path while leaving the service useful. Removing the sink is the lever that does. Two preconditions must be stated before this is recorded as an active mitigation. Removing janino negates Jiffle compilation altogether, so a deployment that legitimately renders Jiffle-backed processes loses that function and has to confirm it does not depend on it before applying this. And the classpath change is not in effect while the servlet container is still running with janino already loaded — there is no live-patch primitive and no host reboot, so the JVM has to be restarted and the state measured on what the running instance has loaded rather than on what is on disk.",
-        "evidence": "The packet's vector states that users unable to upgrade may negate the ability to compile Jiffle scripts from the final application by removing janino-x.y.z.jar from the classpath, and that version 1.2.22 contains a patch disabling the ability to inject malicious code into the resulting script. The attack_vector describes an unauthenticated WPS request to the GeoServer WMS/OWS endpoint invoking the ras:Jiffle process with injected Java that Janino compiles and executes. The cited boundary-protection gap states that boundary protection is ineffective because the Jiffle-backed WPS process is reachable on the same unauthenticated WMS/OWS endpoint the service exists to expose; the NIS2 gap states that vulnerability-management obligations do not by themselves surface the compensating control of removing janino from the classpath when immediate upgrade is not possible. patch_required_reboot is false and live_patch_available is false, with live_patch_notes recording no live-patching primitive for this product.",
+        "evidence": "Users unable to upgrade may negate the ability to compile Jiffle scripts from the final application by removing janino-x.y.z.jar from the classpath, and version 1.2.22 contains a patch disabling the ability to inject malicious code into the resulting script. The attack is an unauthenticated WPS request to the GeoServer WMS/OWS endpoint invoking the ras:Jiffle process with injected Java that Janino compiles and executes. The boundary-protection gap states that boundary protection is ineffective because the Jiffle-backed WPS process is reachable on the same unauthenticated WMS/OWS endpoint the service exists to expose; the NIS2 gap states that vulnerability-management obligations do not by themselves surface the compensating control of removing janino from the classpath when immediate upgrade is not possible. Installing the fix does not require a reboot, and no live patch is available; there is no live-patching primitive for this product.",
         "gap_closes": [
           "NIS2-Art21-vulnerability-management",
           "NIST-800-53-SC-7",
@@ -49582,8 +49582,8 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "For this entry the cost argument that normally justifies a slow patch queue is absent: a vendor update exists with no live-patch path and requires no reboot, so nothing about applying it needs a host outage window, which removes the usual reason a reporting server sits behind a 30-day application-patching cycle. Applied here the control means every Telerik Report Server instance is enumerated and taken past the affected build on the clock that opened with the 2024-06-13 KEV listing rather than on the next quarterly application cycle, with completion measured by the build each instance actually reports — the packet names version 2024 Q1 (10.0.24.305) or earlier as affected, so an instance still reporting that build or earlier is exposed regardless of what its patch-status field says. Enumerate instances by reachability first: the exploit precondition is simply reaching the registration endpoint of an already-configured instance, so an instance answering to a broad network population is where the KEV clock matters most. Priority follows the exploitation record rather than the CVSS band alone: confirmed in-the-wild exploitation, a public PoC and the bypass being commonly chained into CVE-2024-1800 deserialization make this a remote-code-execution precursor, not a standalone account-creation defect. Precondition: the update closes the bypass, it does not remove an administrator account an attacker created before it landed and it does not undo anything executed through the chained deserialization step. An instance that was reachable during the exposure window needs an administrator-account and credential review alongside the upgrade, not instead of it — flaw-remediation and technical-vulnerability-management attestations both read clean on a server that is now patched and still carries the attacker's administrator.",
-        "evidence": "CISA KEV listing on 2024-06-13, active_exploitation confirmed, poc_available true, CVSS 9.8 and RWEP 68 for Progress Telerik Report Server, version 2024 Q1 (10.0.24.305) or earlier, on IIS. patch_available is true, live_patch_available is false, and live_patch_notes states: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" The packet's attack path is an unauthenticated spoofed request to the registration endpoint of an already-configured instance creating a new administrator account, commonly chained with CVE-2024-1800 deserialization for remote code execution. AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are cited as the insufficient controls.",
+        "description": "For this entry the cost argument that normally justifies a slow patch queue is absent: a vendor update exists with no live-patch path and requires no reboot, so nothing about applying it needs a host outage window, which removes the usual reason a reporting server sits behind a 30-day application-patching cycle. Applied here the control means every Telerik Report Server instance is enumerated and taken past the affected build on the clock that opened with the 2024-06-13 KEV listing rather than on the next quarterly application cycle, with completion measured by the build each instance actually reports. Version 2024 Q1 (10.0.24.305) or earlier is affected, so an instance still reporting that build or earlier is exposed regardless of what its patch-status field says. Enumerate instances by reachability first: the exploit precondition is simply reaching the registration endpoint of an already-configured instance, so an instance answering to a broad network population is where the KEV clock matters most. Priority follows the exploitation record rather than the CVSS band alone: confirmed in-the-wild exploitation, a public PoC and the bypass being commonly chained into CVE-2024-1800 deserialization make this a remote-code-execution precursor, not a standalone account-creation defect. Precondition: the update closes the bypass, it does not remove an administrator account an attacker created before it landed and it does not undo anything executed through the chained deserialization step. An instance that was reachable during the exposure window needs an administrator-account and credential review alongside the upgrade, not instead of it. Flaw-remediation and technical-vulnerability-management attestations both read clean on a server that is now patched and still carries the attacker's administrator.",
+        "evidence": "CISA listed this vulnerability in Progress Telerik Report Server, version 2024 Q1 (10.0.24.305) or earlier, on IIS, in its Known Exploited Vulnerabilities catalog on 2024-06-13. Active exploitation is confirmed, a proof of concept is available, and the vulnerability has a CVSS score of 9.8 and an RWEP score of 68. A fixed release is available, and no live patch is available: this product has no live-patching primitive, and the vendor update (no reboot required) is the remediation. The attack path is an unauthenticated spoofed request to the registration endpoint of an already-configured instance creating a new administrator account, commonly chained with CVE-2024-1800 deserialization for remote code execution. AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are cited as the insufficient controls.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
@@ -49633,7 +49633,7 @@
       {
         "id": "NEW-CTRL-145",
         "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
-        "description": "The packet places this in the Windows Error Reporting Service (werkernel.sys) and describes a local authenticated user reaching SYSTEM through improper privilege management — the account is already legitimate, so no account model is being abused and no boundary between users is being crossed by an unauthorized identity; a privilege boundary inside a Windows service is failing. For this CVE the control means the March 2024 Windows cumulative update carrying the fix is driven across the affected population on the KEV clock that opened 2024-06-13, with completion measured against each host's installed build for its SKU rather than by an approved or downloaded state in the update console. The population is the one the packet names — Windows 10, Windows 11 and Windows Server editions prior to that cumulative update — and it is an every-endpoint population rather than a server one, because the exploit's precondition, an interactive session held by a low-privileged local user, is the ordinary operating state of a workstation rather than an anomaly. There is no live-patch path and the vendor update requires a reboot and is the remediation, so a host that installed the update but has not restarted still carries the vulnerable code and must be counted as exposed; the restart is the step most often deferred and a deferral recorded as patched is the specific way this remediation goes wrong. The least-privilege control cited as insufficient on this entry is why the update is the load-bearing step: the escalation runs from an ordinary user account to SYSTEM through a service path, so tightening per-account privilege does not contain it and that attestation passes cleanly while the flaw stays fully exploitable. Note the half this control cannot cover — an exploit tool attributed to the Cardinal / Storm-1811 group behind Black Basta carries build timestamps predating the patch, so for part of the exposure there was no remediation window in existence to enforce. This governs the lag after March 2024; detection has to cover the rest.",
+        "description": "The flaw is in the Windows Error Reporting Service (werkernel.sys) and lets a local authenticated user reach SYSTEM through improper privilege management. The account is already legitimate, so no account model is being abused and no boundary between users is being crossed by an unauthorized identity; a privilege boundary inside a Windows service is failing. For this CVE the control means the March 2024 Windows cumulative update carrying the fix is driven across the affected population on the KEV clock that opened 2024-06-13, with completion measured against each host's installed build for its SKU rather than by an approved or downloaded state in the update console. The affected population is Windows 10, Windows 11 and Windows Server editions prior to that cumulative update, and it is an every-endpoint population rather than a server one, because the exploit's precondition, an interactive session held by a low-privileged local user, is the ordinary operating state of a workstation rather than an anomaly. There is no live-patch path and the vendor update requires a reboot and is the remediation, so a host that installed the update but has not restarted still carries the vulnerable code and must be counted as exposed; the restart is the step most often deferred and a deferral recorded as patched is the specific way this remediation goes wrong. The least-privilege control cited as insufficient on this entry is why the update is the load-bearing step: the escalation runs from an ordinary user account to SYSTEM through a service path, so tightening per-account privilege does not contain it and that attestation passes cleanly while the flaw stays fully exploitable. Note the half this control cannot cover: an exploit tool attributed to the Cardinal / Storm-1811 group behind Black Basta carries build timestamps predating the patch, so for part of the exposure there was no remediation window in existence to enforce. This governs the lag after March 2024; detection has to cover the rest.",
         "evidence": "Packet affected: 'Microsoft Windows — Windows Error Reporting Service (werkernel.sys) improper privilege management, exploitable by a local authenticated user to gain SYSTEM.' affected_versions: 'Windows 10 / 11 and Windows Server editions prior to the March 2024 cumulative update'. cwe_refs: CWE-269. cisa_kev true, kev_date 2024-06-13, active_exploitation confirmed, poc_available true, rwep_score 75, cvss 7.8. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' active_exploitation_notes: 'Ransomware-linked: Symantec attributed an exploit tool for this flaw to the Cardinal/Storm-1811 group behind Black Basta, with build timestamps predating the patch (likely zero-day). Added to CISA KEV 2024-06-13.' NIST-800-53-SI-2 gap: 'Black Basta held a working exploit weeks-to-months before the March 2024 patch; any standard remediation cadence was irrelevant during the zero-day period, and lag after patch still enables ransomware escalation.' NIST-800-53-AC-6 gap: 'Least-privilege cannot contain this flaw — it escalates a standard user to SYSTEM via a system-service registry path, defeating the privilege model.' AU-Essential-8-Patch gap: 'The Essential Eight OS-patch timeframe far exceeds the zero-day window in which Black Basta was already exploiting this flaw.' UK-CAF-B4 gap: 'CAF system-security hardening does not cover the WER service registry path Black Basta abused to jump user-to-SYSTEM.'",
         "gap_closes": [
           "AU-Essential-8-Patch",
@@ -49645,7 +49645,7 @@
       {
         "id": "NEW-CTRL-003",
         "name": "KERNEL-EXPLOITATION-DETECTION",
-        "description": "What this control means for this CVE is a host rule keyed on the two-step behaviour the packet describes, expressed in the telemetry a Windows host produces rather than in the Linux audit primitives the control was first written against. The exploit path is specific: a local low-privileged user manipulates Windows Error Reporting registry values, and WerFaultSecure — which runs with a null security descriptor — then launches an attacker-controlled process with SYSTEM privileges. The rule therefore keys on that pairing: writes to the WER registry values by a process running under a non-administrative user, followed within a short window by a WER service process creating a child whose token is SYSTEM. Both halves are needed. Windows Error Reporting writes its own registry state in normal operation, and Windows services create SYSTEM children constantly; it is the non-administrative write followed closely by the privilege transition that distinguishes this exploit from either, and the alerting posture has to be fast because the packet places this step inside a ransomware operator's chain rather than at its end. Note what will not see it: nothing crashes, no driver is installed, no new service is registered, and the work is done by an ordinary user session using the registry API together with a Windows service doing what it is built to do — so file-integrity monitoring, signature-based anti-malware, and any rule keyed on process crashes or on named exploit tooling have no artifact to match. That is precisely why the anti-malware control is recorded as insufficient on this entry: it targets the payload, and this is the escalation primitive chained ahead of it. Precondition: this requires registry-write auditing scoped to the WER keys and process-creation logging that records each child's user context, both already enabled and already shipping off-host before the attempt. A rule authored afterwards against telemetry nobody was collecting produces nothing, and on the shared and multi-user hosts where a low-privileged local session is routine that telemetry is often exactly what is not enabled. And this detects rather than prevents: a host that alerts has already had a SYSTEM process spawned by an unprivileged user and belongs on the incident path with credential rotation and forensic triage, not on the patch queue.",
+        "description": "What this control means for this CVE is a host rule keyed on the exploit's two-step behavior, expressed in the telemetry a Windows host produces rather than in the Linux audit primitives the control was first written against. The exploit path is specific: a local low-privileged user manipulates Windows Error Reporting registry values, and WerFaultSecure, which runs with a null security descriptor, then launches an attacker-controlled process with SYSTEM privileges. The rule therefore keys on that pairing: writes to the WER registry values by a process running under a non-administrative user, followed within a short window by a WER service process creating a child whose token is SYSTEM. Both halves are needed. Windows Error Reporting writes its own registry state in normal operation, and Windows services create SYSTEM children constantly; it is the non-administrative write followed closely by the privilege transition that distinguishes this exploit from either, and the alerting posture has to be fast because this step occurs within a ransomware operator's chain rather than at its end. Note what will not see it: nothing crashes, no driver is installed, no new service is registered, and the work is done by an ordinary user session using the registry API together with a Windows service doing what it is built to do, so file-integrity monitoring, signature-based anti-malware, and any rule keyed on process crashes or on named exploit tooling have no artifact to match. That is precisely why the anti-malware control is recorded as insufficient on this entry: it targets the payload, and this is the escalation primitive chained ahead of it. Precondition: this requires registry-write auditing scoped to the WER keys and process-creation logging that records each child's user context, both already enabled and already shipping off-host before the attempt. A rule authored afterwards against telemetry nobody was collecting produces nothing, and on the shared and multi-user hosts where a low-privileged local session is routine that telemetry is often exactly what is not enabled. And this detects rather than prevents: a host that alerts has already had a SYSTEM process spawned by an unprivileged user and belongs on the incident path with credential rotation and forensic triage, not on the patch queue.",
         "evidence": "attack_vector: 'A local low-privileged user manipulates Windows Error Reporting registry values so that the WerFaultSecure service, which runs with a null security descriptor, launches an attacker-controlled process with SYSTEM privileges.' SOC2-CC7-anomaly-detection gap (also recorded in framework_coverage as covered/not adequate): 'Anomaly-detection controls that do not baseline WER registry manipulation and WerFault SYSTEM children miss the exact behavior ransomware operators used.' ISO-27001-2022-A.8.7 gap: 'Antimalware controls target payload delivery and execution, not the privilege-escalation primitive a ransomware operator chains beforehand; A.8.7 would not flag WerFault spawning a SYSTEM child during the zero-day window Black Basta exploited.' NIS2-Art21-incident-handling gap: 'Incident-handling obligations do not require hunting for post-access EoP tooling, so the escalation step of a ransomware chain goes unnoticed until encryption.' active_exploitation_notes: exploit tool attributed by Symantec to the Cardinal/Storm-1811 group behind Black Basta, build timestamps predating the patch. active_exploitation confirmed; poc_available true; kev_date 2024-06-13.",
         "gap_closes": [
           "SOC2-CC7-anomaly-detection",
@@ -49697,7 +49697,7 @@
         "id": "NEW-CTRL-056",
         "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
         "description": "Pixel handsets take this fix as a vendor update that requires a reboot, with no live-patch path, so remediation is the update plus a restart on every affected device — and on a handset both steps sit with the user unless enrolment makes them mandatory. For this CVE the control means the update policy on managed Pixel devices is enforced rather than advisory: automatic installation of the security update, a mandated restart window, user deferral disallowed, and completion measured by the security patch level each device reports after it has restarted rather than by 'update pushed' or 'update downloaded'. The restart is the specific step that goes wrong here — the packet ties remediation to a reboot, so a Pixel that has taken the update and not restarted still runs the vulnerable code, and counting it as patched is how this remediation is recorded complete while the exposure stands. Priority follows the packet rather than the 7.8 base score: confirmed in-the-wild exploitation and a public PoC against an escalation that needs no additional execution privileges, on a device class that leaves the managed network every day. Precondition: enforcement reaches only devices the estate actually manages. An unenrolled or personally-owned Pixel carrying organizational data is outside this control's reach entirely, and is remediated by enrolling it or withdrawing the data from it, not by leaving it uncounted on a compliance report. And the update does nothing about a device already exploited during the window before it landed — with exploitation confirmed, a device on which the crafted application ran belongs on the incident path rather than being closed on its new patch level.",
-        "evidence": "The packet describes a logic-error bypass leading to local escalation of privilege with no additional execution privileges needed, and states that user interaction is needed for exploitation; the attack path is a locally present, crafted application escalating from an unprivileged context to system-level privileges on Pixel firmware / the Android Framework (CWE-670, CWE-783). CISA KEV-listed 2024-06-13, active_exploitation confirmed, poc_available true, CVSS 7.8, RWEP 73. patch_available is true, live_patch_available is false, and live_patch_notes states: \"No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.\" NIS2-Art21-patch-management, NIST-800-53-SI-2, AU-Essential-8-Patch and ISO-27001-2022-A.8.8 are cited as the insufficient controls.",
+        "evidence": "The flaw is a logic-error bypass leading to local escalation of privilege with no additional execution privileges needed, and user interaction is needed for exploitation; the attack path is a locally present, crafted application escalating from an unprivileged context to system-level privileges on Pixel firmware / the Android Framework (CWE-670, CWE-783). CISA added it to its Known Exploited Vulnerabilities catalog on 2024-06-13. Active exploitation is confirmed, a proof of concept is available, the CVSS score is 7.8, and it has an RWEP score of 73. A fixed release is available and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. NIS2-Art21-patch-management, NIST-800-53-SI-2, AU-Essential-8-Patch and ISO-27001-2022-A.8.8 are cited as the insufficient controls.",
         "gap_closes": [
           "NIS2-Art21-patch-management",
           "NIST-800-53-SI-2",
@@ -49708,8 +49708,8 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "The trigger is a locally present, crafted application, and the escalation runs from an unprivileged context to system-level privileges with no additional execution privileges needed — so for this entry the control's access-condition half is the load-bearing one. Applied to the Pixel devices in the estate, the build carrying the fix has to function as an access condition: mail, VPN and document access denied to a Pixel below it, not the stale patch level surfacing as a row on a compliance dashboard while the device keeps its access. Because the packet ties remediation to a reboot, the condition must be evaluated against the patch level the device reports after restarting; a device that has installed but not restarted sits below the bar. Distinguishing test: enrol a Pixel pinned below the fixed build and confirm the policy actually denies it access to protected resources — an estate that reports the stale build while the handset keeps syncing mail has recorded the exposure rather than removed it. The least-privilege control cited as insufficient here is not the lever it appears to be: the escalation begins in an unprivileged context and crosses a privilege boundary inside the platform, so per-application privilege scoping is never the thing that fails and an AC-6 attestation passes cleanly while the flaw stays fully exploitable. Precondition: restricting untrusted or side-loaded application installation raises the bar for getting the attacker's application onto a device, but it does not evict an application already installed, and it does not cover one that arrived through the normal store channel; the packet's requirement of user interaction also means the delivery step runs through a user, which policy narrows but does not eliminate. A device suspected of already running the crafted application belongs on the incident path, not the install-policy path. This is a holding measure for the window before the update and its restart land, not a substitute for them.",
-        "evidence": "The packet's vector states there is a possible way to bypass due to a logic error in the code, leading to local escalation of privilege with no additional execution privileges needed, and that user interaction is needed for exploitation; the attack path is a locally present, crafted application bypassing a privilege boundary in Pixel firmware / the Android Framework to reach system-level privileges. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are cited as insufficient controls on this entry. patch_available is true, live_patch_available is false, and live_patch_notes states the vendor update requires a reboot and is the remediation. It names no affected Pixel model or Android release, so no build or version is asserted here beyond \"the build carrying the vendor fix\".",
+        "description": "The trigger is a locally present, crafted application, and the escalation runs from an unprivileged context to system-level privileges with no additional execution privileges needed, so for this entry the control's access-condition half is the load-bearing one. Applied to the Pixel devices in the estate, the build carrying the fix has to function as an access condition: mail, VPN and document access denied to a Pixel below it, not the stale patch level surfacing as a row on a compliance dashboard while the device keeps its access. Because the vendor update that remediates this flaw requires a reboot, the condition must be evaluated against the patch level the device reports after restarting; a device that has installed but not restarted sits below the bar. Distinguishing test: enroll a Pixel pinned below the fixed build and confirm the policy actually denies it access to protected resources. An estate that reports the stale build while the handset keeps syncing mail has recorded the exposure rather than removed it. The least-privilege control cited as insufficient here is not the lever it appears to be: the escalation begins in an unprivileged context and crosses a privilege boundary inside the platform, so per-application privilege scoping is never the thing that fails and an AC-6 attestation passes cleanly while the flaw stays fully exploitable. Precondition: restricting untrusted or side-loaded application installation raises the bar for getting the attacker's application onto a device, but it does not evict an application already installed, and it does not cover one that arrived through the normal store channel; because user interaction is needed for exploitation, the delivery step also runs through a user, which policy narrows but does not eliminate. A device suspected of already running the crafted application belongs on the incident path, not the install-policy path. This is a holding measure for the window before the update and its restart land, not a substitute for them.",
+        "evidence": "The vulnerability description states there is a possible way to bypass due to a logic error in the code, leading to local escalation of privilege with no additional execution privileges needed, and that user interaction is needed for exploitation; the attack path is a locally present, crafted application bypassing a privilege boundary in Pixel firmware / the Android Framework to reach system-level privileges. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are cited as insufficient controls on this entry. A fixed release is available, no live patch is available, and the vendor update requires a reboot and is the remediation. The description names no affected Pixel model or Android release, so no build or version is asserted here beyond \"the build carrying the vendor fix\".",
         "gap_closes": [
           "NIST-800-53-AC-6",
           "UK-CAF-B4"
@@ -49769,8 +49769,8 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "The configuration-side path for this CVE is the interpreter mode, and the packet's own PCI gap names it: the patching requirement never prompts anything about the CGI SAPI, so the injectable mode stays deployed on an estate that patches diligently. Applied to a Windows Apache estate the control means holding an inventory of which virtual hosts route requests to the CGI binary, because that is the exposed surface — the primitive here exists because the request becomes command-line arguments handed to the PHP binary, which is a property of the CGI interface rather than of a particular PHP build. State the constraint that bounds this half honestly, because it is the one an operator will hit first: there is no drop-in alternative interpreter mode on the affected platform. PHP-FPM is a Unix SAPI and is not shipped for Windows, and Windows is where this CVE lives, so the available moves are dropping the CGI mapping on sites that do not need it, or moving the workload to a platform where a non-CGI SAPI exists — and for a site that must keep serving PHP through CGI on Windows, neither is available and the fixed build is the remediation. The second half is the request-filtering path, and it is where this is most often recorded as mitigated while staying open: the packet describes the injection arriving as a soft-hyphen (0xAD) that Windows Best-Fit remaps to '-', so any rule written to block option injection must be validated by replaying a request that carries the 0xAD byte, not the literal '-' the rule author had in mind. Distinguishing test: send the encoded form against a staging host and confirm the request is rejected before PHP is invoked; a rule proven against a literal '-' has demonstrated nothing about this CVE. Precondition: the Best-Fit remapping is conditioned on the code page — it occurs where the system is set up to use certain code pages — so a mitigation premised on the code page requires knowing each host's exact configuration and cannot be asserted fleet-wide, whereas removing the CGI mapping removes the argument path itself. Neither half evicts an attacker already resident on a host that was exposed during the mass-exploitation window.",
-        "evidence": "The packet's vector states the flaw arises when using Apache and PHP-CGI on Windows where the system is set up to use certain code pages, and that Windows may use Best-Fit behavior to replace characters in the command line given to Win32 API functions, which the PHP CGI module may misinterpret as PHP options. The attack_vector records the soft-hyphen (0xAD) being remapped to '-' so that PHP-CGI options (auto_prepend_file=php://input, allow_url_include=1) are injected into the PHP binary, yielding execution of attacker-supplied PHP or disclosure of script source. The cited ISO/IEC 27001:2022 A.8.9 gap states configuration management does not flag the insecure Windows Apache + PHP-CGI + Best-Fit code-page combination that is the precondition for this bug; the PCI DSS 4.0 6.3.3 gap states the requirement is satisfied by the fixed build and prompts nothing about the interpreter mode, and records that PHP-FPM is a Unix SAPI not shipped for Windows so there is no drop-in alternative on the affected platform; the NIST 800-53 SC-7 gap states boundary/WAF rules keyed on literal '-' options miss the Best-Fit 0xAD encoding, so perimeter filtering fails to block the argument injection.",
+        "description": "The configuration-side path for this CVE is the interpreter mode, and the PCI gap cited for this CVE names it: the patching requirement never prompts anything about the CGI SAPI, so the injectable mode stays deployed on an estate that patches diligently. Applied to a Windows Apache estate the control means holding an inventory of which virtual hosts route requests to the CGI binary, because that is the exposed surface: the primitive here exists because the request becomes command-line arguments handed to the PHP binary, which is a property of the CGI interface rather than of a particular PHP build. State the constraint that bounds this half honestly, because it is the one an operator will hit first: there is no drop-in alternative interpreter mode on the affected platform. PHP-FPM is a Unix SAPI and is not shipped for Windows, and Windows is where this CVE lives, so the available moves are dropping the CGI mapping on sites that do not need it, or moving the workload to a platform where a non-CGI SAPI exists. For a site that must keep serving PHP through CGI on Windows, neither is available and the fixed build is the remediation. The second half is the request-filtering path, and it is where this is most often recorded as mitigated while staying open: the injection arrives as a soft-hyphen (0xAD) that Windows Best-Fit remaps to '-', so any rule written to block option injection must be validated by replaying a request that carries the 0xAD byte, not the literal '-' the rule author had in mind. Distinguishing test: send the encoded form against a staging host and confirm the request is rejected before PHP is invoked; a rule proven against a literal '-' has demonstrated nothing about this CVE. Precondition: the Best-Fit remapping is conditioned on the code page (it occurs where the system is set up to use certain code pages), so a mitigation premised on the code page requires knowing each host's exact configuration and cannot be asserted fleet-wide, whereas removing the CGI mapping removes the argument path itself. Neither half evicts an attacker already resident on a host that was exposed during the mass-exploitation window.",
+        "evidence": "The flaw arises when using Apache and PHP-CGI on Windows where the system is set up to use certain code pages: Windows may use Best-Fit behavior to replace characters in the command line given to Win32 API functions, and the PHP CGI module may misinterpret those characters as PHP options. The soft-hyphen (0xAD) is remapped to '-' so that PHP-CGI options (auto_prepend_file=php://input, allow_url_include=1) are injected into the PHP binary, yielding execution of attacker-supplied PHP or disclosure of script source. The cited ISO/IEC 27001:2022 A.8.9 gap states configuration management does not flag the insecure Windows Apache + PHP-CGI + Best-Fit code-page combination that is the precondition for this bug; the PCI DSS 4.0 6.3.3 gap states the requirement is satisfied by the fixed build and prompts nothing about the interpreter mode, and records that PHP-FPM is a Unix SAPI not shipped for Windows so there is no drop-in alternative on the affected platform; the NIST 800-53 SC-7 gap states boundary/WAF rules keyed on literal '-' options miss the Best-Fit 0xAD encoding, so perimeter filtering fails to block the argument injection.",
         "gap_closes": [
           "ISO-27001-2022-A.8.9",
           "PCI-DSS-4.0-6.3.3",
@@ -49780,7 +49780,7 @@
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "The packet's CAF gap records the failure mode this control exists for: an internet-facing PHP-CGI RCE at an EPSS near 1.0 was mass-exploited faster than an incident-response cycle could spin up, so the runbook has to pre-exist the disclosure rather than be written during it. For this CVE the requirement is that any internet-facing Windows Apache/PHP-CGI host that ran a pre-8.1.29 / 8.2.20 / 8.3.8 build during the exploitation window is triaged as a compromise rather than closed on the upgrade: the primitive the packet describes runs attacker-supplied PHP as the web-server identity, and the upgrade removes the injection path while removing nothing written or read through it. The runbook content is therefore the content of the host, not the version of the binary — web-root and application directories compared against a known-good source, and the database and application credentials held in the site's configuration files rotated, because the same flaw discloses script source and those files were readable through it. Precondition: this is a response control. It does not block the injection, does not shorten the exposure window, and depends on knowing when each host reached the fixed build; a host with no reliable record of its PHP version history has to be treated as exposed for the whole period since the 2024-06-12 KEV listing rather than cleared by an upgrade applied later.",
+        "description": "The CAF gap cited for this CVE records the failure mode this control exists for: an internet-facing PHP-CGI RCE at an EPSS near 1.0 was mass-exploited faster than an incident-response cycle could spin up, so the runbook has to pre-exist the disclosure rather than be written during it. For this CVE the requirement is that any internet-facing Windows Apache/PHP-CGI host that ran a pre-8.1.29 / 8.2.20 / 8.3.8 build during the exploitation window is triaged as a compromise rather than closed on the upgrade: the primitive runs attacker-supplied PHP as the web-server identity, and the upgrade removes the injection path while removing nothing written or read through it. The runbook content is therefore the content of the host, not the version of the binary: web-root and application directories compared against a known-good source, and the database and application credentials held in the site's configuration files rotated, because the same flaw discloses script source and those files were readable through it. Precondition: this is a response control. It does not block the injection, does not shorten the exposure window, and depends on knowing when each host reached the fixed build; a host with no reliable record of its PHP version history has to be treated as exposed for the whole period since the 2024-06-12 KEV listing rather than cleared by an upgrade applied later.",
         "evidence": "The entry records active_exploitation confirmed with mass exploitation in the wild since disclosure in June 2024 against Windows Apache + PHP-CGI, used by multiple actors and ransomware operators for arbitrary code execution and source disclosure, and CISA KEV flagging ransomware use as Known. The affected field states that command-line options are injectable into the PHP binary, yielding source disclosure or RCE, and the attack_vector records auto_prepend_file=php://input with allow_url_include=1 causing attacker-supplied PHP to execute. The cited UK CAF D1 gap states response-and-recovery planning does not account for the same-week ransomware weaponization observed here, where an internet-facing PHP-CGI RCE is mass-exploited faster than an incident-response cycle can spin up.",
         "gap_closes": [
           "UK-CAF-D1"
@@ -49829,8 +49829,8 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "The trigger is a local, non-privileged app performing improper GPU memory-processing operations against the Mali kernel driver to reach already-freed memory and escalate privilege or escape the app sandbox — so the population is every device carrying a Bifrost or Valhall driver in the r34p0-through-r40p0 range, and the remediating state is a build carrying r41p0. The operator cannot make that build exist: the packet's flaw-remediation gap records that Arm's fix has to be integrated by SoC vendors and shipped through Android OEM and carrier update chains. What the operator does hold is the access decision, and this control's requirement is that the fixed driver becomes a condition of access rather than a row on a patch-compliance report — a device that cannot show a build carrying r41p0 is denied mail, VPN and document access until it can. Distinguishing test: enrol a device pinned to a pre-r41p0 build and confirm the policy actually denies it the protected resources; an estate that surfaces the stale driver on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition on the remediation half: patch_required_reboot is true, there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation — so a device that has taken the OEM update but has not rebooted is still executing the pre-r41p0 driver and counts as exposed, not as patched. Precondition on the interim half: restricting installation to vetted application sources raises the bar for getting the attacker's app onto the device, but the packet's exploit runs from an ordinary installed app needing no additional execution privilege, so it does not evict an app already present and does not cover one delivered through the normal store channel; a device suspected of already running such an app belongs on the incident path. This is a holding measure for the window before a build carrying r41p0 lands and is rebooted onto, not a substitute for it.",
-        "evidence": "Packet: cisa_kev true with kev_date 2024-06-12; active_exploitation confirmed, with active_exploitation_notes recording that Arm confirmed indications of exploitation in the wild and that a local non-privileged app can leverage it for privilege escalation / sandbox escape across a very large population of Android devices; cwe_refs CWE-416. affected names the Arm Bifrost and Valhall Mali GPU Kernel Drivers (mali_kbase), 'Fixed in driver version r41p0'; affected_versions are 'Bifrost GPU Kernel Driver r34p0 through r40p0' and 'Valhall GPU Kernel Driver r34p0 through r40p0'. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' The NIST-800-53-SI-2 gap records that the upstream Arm fix (r41p0) 'must be integrated by SoC vendors and shipped through Android OEM/carrier update chains'; the AU-Essential-8-Patch gap records that OS-patch maturity models 'assume a controllable update path'; the UK-CAF-B4 gap records endpoint-hardening expectations undercut when the vulnerable component is a vendor GPU kernel driver outside the operator's patch control.",
+        "description": "The trigger is a local, non-privileged app performing improper GPU memory-processing operations against the Mali kernel driver to reach already-freed memory and escalate privilege or escape the app sandbox, so the population is every device carrying a Bifrost or Valhall driver in the r34p0-through-r40p0 range, and the remediating state is a build carrying r41p0. The operator cannot make that build exist: Arm's fix has to be integrated by SoC vendors and shipped through Android OEM and carrier update chains. What the operator does hold is the access decision, and this control's requirement is that the fixed driver becomes a condition of access rather than a row on a patch-compliance report. A device that cannot show a build carrying r41p0 is denied mail, VPN and document access until it can. Distinguishing test: enroll a device pinned to a pre-r41p0 build and confirm the policy actually denies it the protected resources; an estate that surfaces the stale driver on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition on the remediation half: the vendor update requires a reboot and is the remediation, and there is no live-patching primitive for this product, so a device that has taken the OEM update but has not rebooted is still executing the pre-r41p0 driver and counts as exposed, not as patched. Precondition on the interim half: restricting installation to vetted application sources raises the bar for getting the attacker's app onto the device, but the exploit runs from an ordinary installed app needing no additional execution privilege, so it does not evict an app already present and does not cover one delivered through the normal store channel; a device suspected of already running such an app belongs on the incident path. This is a holding measure for the window before a build carrying r41p0 lands and is rebooted onto, not a substitute for it.",
+        "evidence": "CISA added CVE-2024-4610 to its Known Exploited Vulnerabilities catalog on 2024-06-12. Active exploitation is confirmed: Arm confirmed indications of exploitation in the wild, and a local non-privileged app can leverage the flaw for privilege escalation or sandbox escape across a very large population of Android devices. The weakness is CWE-416. The affected components are the Arm Bifrost and Valhall Mali GPU Kernel Drivers (mali_kbase), and the fix is in driver version r41p0. The affected versions are Bifrost GPU Kernel Driver r34p0 through r40p0 and Valhall GPU Kernel Driver r34p0 through r40p0. A fixed release is available, and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. The NIST-800-53-SI-2 gap records that the upstream Arm fix (r41p0) 'must be integrated by SoC vendors and shipped through Android OEM/carrier update chains'; the AU-Essential-8-Patch gap records that OS-patch maturity models 'assume a controllable update path'; the UK-CAF-B4 gap records endpoint-hardening expectations undercut when the vulnerable component is a vendor GPU kernel driver outside the operator's patch control.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "NIST-800-53-SI-2",
@@ -49840,8 +49840,8 @@
       {
         "id": "NEW-CTRL-018",
         "name": "SCANNER-PAPER-COMPLIANCE-TEST",
-        "description": "The paper-compliance case for this CVE is a device-management console or scanner that reads the device's OS security patch level, finds it current, and reports the fleet remediated. The packet rules that out: the vulnerable component is Arm's Bifrost/Valhall Mali kernel driver, and the packet's own flaw-remediation gap says the r41p0 fix must be integrated by the SoC vendor and shipped through the OEM chain — so an OS-level currency date is not evidence that the driver in service is r41p0 rather than something in the r34p0-through-r40p0 range. The operational test for this entry is the driver version actually running on the device, checked against that affected range and the r41p0 fix, per device model, rather than the OS patch date or the existence of an update policy. Precondition and limit, which is where this control is most often over-claimed: where the management channel cannot report the driver version, the model-and-build to driver-version mapping has to be obtained from the OEM or SoC vendor for that exact model, not assumed in either direction. The packet establishes that the fix may not reach older devices but does not say which models those are, so a model whose status the vendor has not answered is an open question — neither a pass nor a device that can be written off as unfixable.",
-        "evidence": "Packet: affected records the fix as driver version r41p0 and affected_versions give the vulnerable ranges as Bifrost r34p0 through r40p0 and Valhall r34p0 through r40p0. The NIST-800-53-SI-2 gap records that 'The upstream Arm fix (r41p0) must be integrated by SoC vendors and shipped through Android OEM/carrier update chains, so device patch latency far exceeds the exploitation window for a KEV-listed mobile LPE.' The ISO-27001-2022-A.8.8 gap records that technical-vulnerability management for mobile endpoints 'depends on OEM update availability; a control cannot remediate a device whose vendor never ships r41p0.' The AU-Essential-8-Patch gap records that OS-patch maturity models assume a controllable update path 'which does not hold for fragmented Android OEM firmware where the GPU driver fix may never reach older devices.' cisa_kev true (2024-06-12) with active_exploitation confirmed.",
+        "description": "The paper-compliance case for this CVE is a device-management console or scanner that reads the device's OS security patch level, finds it current, and reports the fleet remediated. That report does not hold for this CVE: the vulnerable component is Arm's Bifrost/Valhall Mali kernel driver, and the r41p0 fix must be integrated by the SoC vendor and shipped through the OEM chain, so an OS-level currency date is not evidence that the driver in service is r41p0 rather than something in the r34p0-through-r40p0 range. The operational test for this entry is the driver version actually running on the device, checked against that affected range and the r41p0 fix, per device model, rather than the OS patch date or the existence of an update policy. Precondition and limit, which is where this control is most often over-claimed: where the management channel cannot report the driver version, the model-and-build to driver-version mapping has to be obtained from the OEM or SoC vendor for that exact model, not assumed in either direction. The fix may not reach older devices, but this entry does not identify which models those are, so a model whose status the vendor has not answered is an open question: it is neither a pass nor a device that can be written off as unfixable.",
+        "evidence": "The fix is driver version r41p0, and the vulnerable ranges are Bifrost r34p0 through r40p0 and Valhall r34p0 through r40p0. The NIST-800-53-SI-2 gap records that 'The upstream Arm fix (r41p0) must be integrated by SoC vendors and shipped through Android OEM/carrier update chains, so device patch latency far exceeds the exploitation window for a KEV-listed mobile LPE.' The ISO-27001-2022-A.8.8 gap records that technical-vulnerability management for mobile endpoints 'depends on OEM update availability; a control cannot remediate a device whose vendor never ships r41p0.' The AU-Essential-8-Patch gap records that OS-patch maturity models assume a controllable update path 'which does not hold for fragmented Android OEM firmware where the GPU driver fix may never reach older devices.' CISA lists CVE-2024-4610 in its Known Exploited Vulnerabilities catalog (added 2024-06-12), and active exploitation is confirmed.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "AU-Essential-8-Patch"
@@ -49850,8 +49850,8 @@
       {
         "id": "NEW-CTRL-038",
         "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
-        "description": "Applied to a fleet carrying this driver, the three states the packet forces apart are: a device on a build carrying r41p0 that has been rebooted onto it — remediated; a device still below r41p0 with an access restriction or install policy holding the line — a compensating state that must be reported as such, with a dated action item and a named owner pursuing the OEM for that model; and a device below r41p0 with neither — full exposure to a KEV-listed use-after-free with confirmed exploitation, reachable by any app already installed on it. The gap this closes is the one the packet's patch-management text describes: obligations that cannot reach third-party SoC and OEM firmware pipelines resolve today to 'policy exists and is applied', which reports a fleet as compliant without ever counting how many devices sit in the third state or for how long. The verdict class makes that count exist and makes it age, and it stops the second state being recorded as patched-per-SLA. Precondition: the compensating state is not remediation and must not close the item — there is no live-patching primitive and the reboot-requiring vendor update is the remediation, so an access restriction bounds what a compromised device can reach while the local escalation on the device itself stays fully available to any app already installed there.",
-        "evidence": "Packet: patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' cisa_kev true with kev_date 2024-06-12 and active_exploitation confirmed. The NIS2-Art21-patch-management gap records that 'Patch-management obligations cannot force fixes through third-party SoC/OEM firmware pipelines that carry the Mali driver, leaving managed mobile fleets exposed.' The ISO-27001-2022-A.8.8 gap records that 'a control cannot remediate a device whose vendor never ships r41p0.' The attack vector is a local, non-privileged app using the use-after-free to corrupt kernel memory and escalate privileges or escape the app sandbox.",
+        "description": "In a fleet carrying this driver, the control keeps three states apart: a device on a build carrying r41p0 that has been rebooted onto it, which is remediated; a device still below r41p0 with an access restriction or install policy holding the line, which is a compensating state that must be reported as such, with a dated action item and a named owner pursuing the OEM for that model; and a device below r41p0 with neither, which has full exposure to a KEV-listed use-after-free with confirmed exploitation, reachable by any app already installed on it. The gap this closes is in patch management: obligations that cannot reach third-party SoC and OEM firmware pipelines resolve today to 'policy exists and is applied', which reports a fleet as compliant without ever counting how many devices sit in the third state or for how long. The verdict class makes that count exist and makes it age, and it stops the second state being recorded as patched-per-SLA. Precondition: the compensating state is not remediation and must not close the item. There is no live-patching primitive, and the reboot-requiring vendor update is the remediation, so an access restriction bounds what a compromised device can reach while the local escalation on the device itself stays fully available to any app already installed there.",
+        "evidence": "A fixed release is available, and no live patch is available: there is no live-patching primitive for this product, and the vendor update requires a reboot and is the remediation. CISA added CVE-2024-4610 to its Known Exploited Vulnerabilities catalog on 2024-06-12, and active exploitation is confirmed. The NIS2-Art21-patch-management gap records that 'Patch-management obligations cannot force fixes through third-party SoC/OEM firmware pipelines that carry the Mali driver, leaving managed mobile fleets exposed.' The ISO-27001-2022-A.8.8 gap records that 'a control cannot remediate a device whose vendor never ships r41p0.' The attack vector is a local, non-privileged app using the use-after-free to corrupt kernel memory and escalate privileges or escape the app sandbox.",
         "gap_closes": [
           "NIS2-Art21-patch-management",
           "ISO-27001-2022-A.8.8"
@@ -50284,7 +50284,7 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "For this entry the control fixes when the browser build has to land and what an operator is allowed to count as holding the line until it does. The clock opens at the 2026-era-agnostic fact recorded here: KEV listing 2024-05-20 with active_exploitation 'confirmed', against a product whose fix needs no reboot — so the interval between listing and a fleet-wide build at or above 125.0.6422.60 is measured in the estate's update-ring latency and nothing else. Where an endpoint genuinely cannot take the build inside that window, the packet supports exactly one compensating lever, and it is the delivery path rather than the vulnerable code: exploitation requires the victim's browser to load the attacker's crafted page, which in the observed campaign the packet describes as a fake blockchain/game site. Restricting which sites managed browsers may load — denying uncategorized and newly-observed destinations for the affected population — bounds who can be brought to the page. Precondition, and it must be written down as one rather than recorded as the mitigation: this bounds reach, it does not repair the type confusion. It gives nothing against a crafted page served from a domain the filter permits, and nothing at all for an endpoint that has already loaded one — with exploitation confirmed in the wild and no PoC needed by the attacker, a browser that ran the crafted script belongs on the incident path, not the filtering path. The packet registers no live-patch primitive and no vendor mitigation rule, so there is no third state to claim: an endpoint is either on the fixed build or it is running the vulnerable one behind a holding measure with a dated expiry. Distinguishing test: for every endpoint still below the fixed build, produce the named compensating measure and its removal date; an entry on the risk register with no build target and no expiry is deferral recorded as compliance.",
+        "description": "For this entry the control fixes when the browser build has to land and what an operator is allowed to count as holding the line until it does. The clock opens at the KEV listing on 2024-05-20, with exploitation confirmed, against a product whose fix needs no reboot, so the interval between listing and a fleet-wide build at or above 125.0.6422.60 is measured in the estate's update-ring latency and nothing else. Where an endpoint genuinely cannot take the build inside that window, exactly one compensating lever applies, and it is the delivery path rather than the vulnerable code: exploitation requires the victim's browser to load the attacker's crafted page. Restricting which sites managed browsers may load (denying uncategorized and newly-observed destinations for the affected population) bounds who can be brought to the page. Precondition, and it must be written down as one rather than recorded as the mitigation: this bounds reach, it does not repair the type confusion. It gives nothing against a crafted page served from a domain the filter permits, and nothing at all for an endpoint that has already loaded one. With exploitation confirmed in the wild and no PoC needed by the attacker, a browser that ran the crafted script belongs on the incident path, not the filtering path. No live-patch mechanism and no vendor mitigation rule exist, so there is no third state to claim: an endpoint is either on the fixed build or it is running the vulnerable one behind a holding measure with a dated expiry. Distinguishing test: for every endpoint still below the fixed build, produce the named compensating measure and its removal date; an entry on the risk register with no build target and no expiry is deferral recorded as compliance.",
         "evidence": "Catalog facts only. cisa_kev true, kev_date 2024-05-20; active_exploitation 'confirmed'; poc_available false; ai_discovered false; RWEP 56, CVSS 9.6. patch_available true; live_patch_available false; live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' vector names the fixed boundary as Google Chrome prior to 125.0.6422.60. attack_vector: 'A victim visits an attacker-controlled page (a fake blockchain/game site in the observed campaign) that runs crafted JavaScript triggering a V8 type confusion, corrupting the heap and executing code inside the renderer sandbox.' Cited as insufficient on this entry: ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation).",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
@@ -59970,7 +59970,7 @@
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
         "description": "For this CVE the control means the RocketMQ upgrade runs on the clock that opened with the 2023-09-06 KEV listing rather than on the cluster's normal release cadence, with the population enumerated from the affected version ranges: every 5.x instance at or below 5.1.0 to 5.1.1 or later, and every 4.x instance at or below 4.9.5 to 4.9.6 or later. The priority argument rests on the exploitation record rather than on the CVSS band: public exploit code exists, exploitation is confirmed, EPSS is around 0.966, and the DreamBus botnet weaponized this against internet-exposed brokers, which makes an exposed cluster a swept target rather than a targeted one. Two things decide whether the remediation is real. First, there is no live-patch mechanism and remediation requires applying the vendor fixed release, so replacing the package is not the completion event. The fix does not require a reboot, which means no machine reboot is needed, not that a NameServer, Broker or Controller process already running the old build stops executing it; measure completion on the version each running component reports. Second, because exploitation is confirmed and the outcome is command execution as the RocketMQ service user, a component that was reachable from an untrusted network during the exposure window belongs on the incident path: the upgrade removes the injection path but nothing that was already placed on the host through it, and the service account's own credentials and any secrets in the broker's configuration are in scope for rotation.",
-        "evidence": "Packet: cisa_kev true with kev_date 2023-09-06; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 70. active_exploitation_notes: 'Actively exploited preauth RCE; the DreamBus botnet weaponized it against internet-exposed RocketMQ brokers... EPSS ~0.966.' affected_versions: 'RocketMQ 5.x <= 5.1.0 (fixed in 5.1.1)', 'RocketMQ 4.x <= 4.9.5 (fixed in 4.9.6)'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' framework_control_gaps 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.' Command execution occurs 'as the system users that RocketMQ is running as' (vector).",
+        "evidence": "CISA added it to its Known Exploited Vulnerabilities catalog on 2023-09-06. Active exploitation is confirmed, a proof of concept is available, and the CVE carries a CVSS score of 9.8 and an RWEP score of 70. It is an actively exploited preauth RCE. The DreamBus botnet weaponized it against internet-exposed RocketMQ brokers, and its EPSS score is about 0.966. Affected versions are RocketMQ 5.x <= 5.1.0 (fixed in 5.1.1) and RocketMQ 4.x <= 4.9.5 (fixed in 4.9.6). A fixed release is available, applying it does not require a reboot, and no live patch is available. There is no vendor live-patch mechanism, and remediation requires applying the vendor fixed release. The ISO-27001-2022-A.8.8 gap is that technical-vulnerability management cadence trails an internet-facing preauth RCE with a public Metasploit module and active botnet use. According to CISA's KEV entry, command execution occurs 'as the system users that RocketMQ is running as'.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8"
         ]
@@ -62618,7 +62618,7 @@
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
         "description": "On this entry the control's value is which event starts the clock. The fix, Netwrix Auditor 10.5, shipped in 2022 while the unauthenticated 9004/TCP path was still being exploited by Truebot into 2023, so the availability of a patch was never the constraint; the prioritization was. The requirement is that the 2023-07-11 KEV listing, with its 2023-08-01 due date, sets the remediation deadline for every Auditor instance below 10.5, irrespective of the internal-versus-internet-facing placement that the entry's patch-cadence gaps say drives the estate's urgency scoring. Completion is measured against the remediation requirement rather than against whether a reboot is needed: there is no live-patch mechanism, remediation is an upgrade to 10.5 or later with the affected services restarted, and the upgrade requiring no reboot means only that the machine need not be restarted. An Auditor service still running the pre-10.5 build after the installer completes is still exploitable. Enumerate the whole affected population, which includes the agents installed on monitored systems and not only the Auditor server. And treat this as a foothold rather than an endpoint finding: in-the-wild exploitation is confirmed and attributed to Truebot for initial access, ransomware use is listed as Known, and exploitation yields SYSTEM on a server that monitors Active Directory. An instance that was reachable during the exposure window needs forensic triage and rotation of the credentials that server held, because the upgrade closes the path and removes nothing an operator established through it.",
-        "evidence": "Packet: cisa_kev true, kev_date 2023-07-11; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 70. active_exploitation_notes: 'CISA/FBI/CCCS joint advisory AA23-187A (2023-07-06) attributes exploitation to the Truebot malware campaign for initial access, and CISA lists ransomware use as Known. Added to KEV 2023-07-11 with a 2023-08-01 due date... yields SYSTEM on a server that already monitors Active Directory, so a hit cascades to domain compromise.' affected_versions: 'Netwrix Auditor < 10.5'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires upgrading to Netwrix Auditor 10.5 (or later) and restarting the affected services.' framework_control_gaps NIST-800-53-SI-2: 'the fix (Auditor 10.5) shipped in 2022 but the unauthenticated 9004/TCP deserialization was still being exploited by Truebot into 2023'; NIS2-Art21-patch-management: 'timelines rarely prioritize an internal audit appliance'; AU-Essential-8-Patch: 'patch prioritization keys off internet-facing exposure, but Netwrix Auditor is typically an internal management server'. vector: flaws affect 'both the Netwrix Auditor server and agents installed on monitored systems'.",
+        "evidence": "CISA added it to its Known Exploited Vulnerabilities catalog on 2023-07-11 with a 2023-08-01 due date, and CISA lists ransomware use as Known. Active exploitation is confirmed, a proof of concept is available, and the CVE carries a CVSS score of 9.8 and an RWEP score of 70. CISA/FBI/CCCS joint advisory AA23-187A (2023-07-06) attributes exploitation to the Truebot malware campaign for initial access. Exploitation yields SYSTEM on a server that already monitors Active Directory, so a hit cascades to domain compromise. Affected versions are Netwrix Auditor < 10.5. A fixed release is available, applying it does not require a reboot, and no live patch is available. There is no vendor live-patch mechanism, and remediation requires upgrading to Netwrix Auditor 10.5 (or later) and restarting the affected services. The NIST-800-53-SI-2 gap is that the fix (Auditor 10.5) shipped in 2022, but the unauthenticated 9004/TCP deserialization was still being exploited by Truebot into 2023. The NIS2-Art21-patch-management gap is that timelines rarely prioritize an internal audit appliance. The AU-Essential-8-Patch gap is that patch prioritization keys off internet-facing exposure, but Netwrix Auditor is typically an internal management server. The flaws affect both the Netwrix Auditor server and agents installed on monitored systems.",
         "gap_closes": [
           "NIST-800-53-SI-2",
           "NIS2-Art21-patch-management",
@@ -62946,7 +62946,7 @@
         "id": "NEW-CTRL-056",
         "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
         "description": "The Samsung fix, SMR Oct-2021 Release 1, predates the 2023-06-29 KEV listing by well over a year, so what this control manages on this entry is uptake rather than availability: handsets sat below a build that had shipped long before CISA listed the flaw as exploited. Applied to a Samsung estate, it means enrolled devices are driven to a reported security-patch level at or above SMR Oct-2021 Release 1 on the KEV clock through the management platform, with the handset user unable to defer indefinitely. Remediation is a device update that reboots the handset, and a reboot the user keeps postponing is the specific way this one goes unremediated while the management console shows the update as delivered. Completion must therefore be measured by each device reporting its actual security-patch level, never by 'pushed', 'downloaded' or 'approved'. Precondition: this reaches only handsets the management platform enrolls. A personally-owned Samsung device carrying corporate mail without enrollment sits entirely outside the control, and a handset whose model or carrier channel no longer receives Samsung maintenance releases cannot be driven to the fixed level at all. Those two populations belong on an access-denial or replacement path, and counting them as 'pending update' is how they stay in service unremediated. There is no live-patch mechanism for the modem driver, so there is no interim binary mitigation this SLA could substitute for the firmware update.",
-        "evidence": "Packet fields for CVE-2021-25487: name 'Samsung Mobile Devices Out-of-Bounds Read Vulnerability'; cwe_refs CWE-125; vector 'Lack of boundary checking of a buffer in set_skb_priv() of modem interface driver prior to SMR Oct-2021 Release 1 allows OOB read and it results in arbitrary code execution by dereference of invalid function pointer.'; cisa_kev true with kev_date 2023-06-29; active_exploitation confirmed; poc_available false; cvss 7.8; rwep_score 48; patch_available true; live_patch_available false with live_patch_notes 'No live-patch mechanism for the modem driver; remediation is the Samsung SMR Oct-2021 Release 1 (or later) firmware update, applied via a device update that reboots the handset.'; citing_gaps include AU-Essential-8-Patch, NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-patch-management.",
+        "evidence": "CVE-2021-25487 is the Samsung Mobile Devices Out-of-Bounds Read Vulnerability, classified as CWE-125. Lack of boundary checking of a buffer in set_skb_priv() of the modem interface driver prior to SMR Oct-2021 Release 1 allows an OOB read, and it results in arbitrary code execution by dereference of an invalid function pointer. CISA lists it in its Known Exploited Vulnerabilities catalog, with a KEV date of 2023-06-29. Active exploitation is confirmed, and no proof-of-concept is available. It carries a CVSS score of 7.8 and an RWEP score of 48. A fixed release is available, and no live patch is available: there is no live-patch mechanism for the modem driver, and remediation is the Samsung SMR Oct-2021 Release 1 (or later) firmware update, applied via a device update that reboots the handset. The framework gaps that cite this CVE include AU-Essential-8-Patch, NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-patch-management.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "NIST-800-53-SI-2",
@@ -63114,7 +63114,7 @@
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "For these handsets the fix has exactly one form: Samsung's SMR MAY-2021 Release 1, delivered over the air and rebooting the device. The framework gaps recorded for this entry say plainly that the operator controls neither its delivery nor, often, its visibility: rollout is staggered by model and carrier, and an organization may not know which handsets still carry the vulnerable MFC charger driver. That is why the fixed SMR level has to function as an access condition rather than a dashboard row: a Samsung device reporting an SMR level below MAY-2021 Release 1 is denied mail, VPN and document access until it reports at or above it, which is the one lever that works whether or not the carrier has shipped. Enumerate the affected population: Samsung mobile devices on Android 8.1, 9.0, 10.0 and 11.0, across both the Exynos and Qualcomm model families. Scoping the search to a single chipset family misses the other, and widening it to the Android fleet generally covers devices no evidence implicates, since the vulnerable driver is a Samsung component. Distinguishing test: enroll a handset pinned below SMR MAY-2021 Release 1 and confirm the policy actually refuses it access to protected resources; an estate that surfaces the stale SMR level on a compliance report while the device keeps its mailbox has recorded the exposure rather than removed it. Precondition, stated rather than implied: this is a holding measure and not remediation. The race and the arbitrary kernel write remain fully available to anything already running on the handset, so this bounds what the device can reach, not what an attacker on it can do. It reaches only enrolled devices whose SMR level is actually readable; a personally-owned handset outside enrollment is not covered. And because the update is an over-the-air firmware install that reboots the device, a handset that has taken the SMR but not rebooted onto it is still running the vulnerable driver. Where a specific model and carrier combination appears never to have received SMR MAY-2021 Release 1, that status has to be obtained from the vendor or carrier for that exact model rather than assumed in either direction, because the answer determines whether the device is a remediation item or a longer-term one.",
-        "evidence": "Packet: affected is 'Samsung mobile devices (selected Exynos and Qualcomm models), where a race condition in the MFC charger driver causes a use-after-free that permits an arbitrary kernel write from a compromised radio-privilege context'; affected_versions is 'Samsung mobile devices (Android O/8.1, P/9.0, Q/10.0, R/11.0) before SMR MAY-2021 Release 1'. live_patch_notes: 'No live-patch mechanism for the mobile kernel; remediation requires installing the Samsung Security Maintenance Release for May 2021 (SMR MAY-2021 Release 1) via an over-the-air firmware update, which reboots the device.' patch_available true; patch_required_reboot true; live_patch_available false. The ISO-27001-2022-A.8.8 gap states 'visibility into per-device SMR level is limited; an organization may not even know which handsets still carry the vulnerable MFC charger driver'; the NIS2-Art21-patch-management gap states 'Samsung SMR rollout is staggered by model and carrier'; the AU-Essential-8-Patch gap states mobile SMR delivery 'is outside the organization's direct control'; the UK-CAF-B4 gap states 'device hardening and MDM policy do not stop the escalation' without the vendor SMR fix. cisa_kev true, kev_date 2023-06-29, active_exploitation confirmed.",
+        "evidence": "The affected products are Samsung mobile devices (selected Exynos and Qualcomm models), where a race condition in the MFC charger driver causes a use-after-free that permits an arbitrary kernel write from a compromised radio-privilege context. The affected versions are Samsung mobile devices (Android O/8.1, P/9.0, Q/10.0, R/11.0) before SMR MAY-2021 Release 1. There is no live-patch mechanism for the mobile kernel; remediation requires installing the Samsung Security Maintenance Release for May 2021 (SMR MAY-2021 Release 1) via an over-the-air firmware update, which reboots the device. A fixed release is available, the fix requires a reboot, and no live patch is available. The ISO-27001-2022-A.8.8 gap states 'visibility into per-device SMR level is limited; an organization may not even know which handsets still carry the vulnerable MFC charger driver'; the NIS2-Art21-patch-management gap states 'Samsung SMR rollout is staggered by model and carrier'; the AU-Essential-8-Patch gap states mobile SMR delivery 'is outside the organization's direct control'; the UK-CAF-B4 gap states 'device hardening and MDM policy do not stop the escalation' without the vendor SMR fix. CISA lists it in its Known Exploited Vulnerabilities catalog, with a KEV date of 2023-06-29, and active exploitation is confirmed.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
           "AU-Essential-8-Patch",
@@ -63126,7 +63126,7 @@
         "id": "NEW-CTRL-056",
         "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
         "description": "This control governs the half of the Samsung population the delivery gaps do not excuse: handsets whose model and carrier did ship SMR MAY-2021 Release 1. CISA listed this flaw on 2023-06-29, more than two years after that release, so a device in that population that is still vulnerable is one where an available update was simply never installed, whether deferred by the user or never enforced by the management platform. The requirement is that the management platform push the SMR on a KEV-tied clock with user deferral disallowed, and that per-device SMR level be reported back so the estate can distinguish 'update not available for this model' from 'update available and not taken'. The framework gaps recorded for this entry show that distinction is currently invisible, and it decides which of the two remaining actions applies to each handset. Because the fix is an over-the-air firmware update that reboots the device, the deferral that actually matters is the reboot: measure completion on the SMR level the handset reports after restart, never on 'downloaded' or 'approved'. Precondition: enforcement can only reach enrolled devices and can only push an update the carrier or OEM has actually released for that exact model, so where the release never arrived this control has nothing to push and the exposure falls back to withholding access, not to a compliance exception. It also does nothing for a handset already compromised: exploitation has occurred as part of targeted device-compromise chains that first obtain radio privilege on the device and end in full device control, so a handset suspected of having been through that chain is an incident-response and credential-rotation question, and installing the SMR afterwards does not make it a closed patch record.",
-        "evidence": "Packet: cisa_kev true with kev_date 2023-06-29, against a fix identified in live_patch_notes as 'the Samsung Security Maintenance Release for May 2021 (SMR MAY-2021 Release 1) via an over-the-air firmware update, which reboots the device'; patch_available true, patch_required_reboot true, live_patch_available false. active_exploitation confirmed, with active_exploitation_notes recording that 'the low EPSS (~0.004) reflects that exploitation is not mass-scanning but part of targeted device-compromise chains that first obtain radio/privileged context on Samsung handsets, then use the MFC charger-driver race to gain an arbitrary kernel write for privilege escalation' and that no public proof-of-concept specific to this CVE is available (poc_available false). attack_vector ends in 'escalating to full device control'. The AU-Essential-8-Patch gap notes the standard critical-patch window 'is only met when the carrier/OEM ships SMR MAY-2021'; the ISO-27001-2022-A.8.8 gap notes limited visibility into per-device SMR level.",
+        "evidence": "CISA lists it in its Known Exploited Vulnerabilities catalog, with a KEV date of 2023-06-29. The fix is the Samsung Security Maintenance Release for May 2021 (SMR MAY-2021 Release 1) via an over-the-air firmware update, which reboots the device. A fixed release is available, the fix requires a reboot, and no live patch is available. Active exploitation is confirmed. The low EPSS (~0.004) reflects that exploitation is not mass-scanning but part of targeted device-compromise chains that first obtain radio/privileged context on Samsung handsets, then use the MFC charger-driver race to gain an arbitrary kernel write for privilege escalation. No public proof-of-concept specific to this CVE is available. The attack ends by escalating to full device control. The AU-Essential-8-Patch gap notes the standard critical-patch window 'is only met when the carrier/OEM ships SMR MAY-2021'; the ISO-27001-2022-A.8.8 gap notes limited visibility into per-device SMR level.",
         "gap_closes": [
           "AU-Essential-8-Patch",
           "NIS2-Art21-patch-management",
@@ -70658,7 +70658,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2022-33891's injection path exists only while spark.acls.enable=true, so setting it to false removes the doAs-to-shell code path in one configuration change, independent of the 3.1.3 / 3.2.2 / 3.3.0 upgrade — and it is the operator's only substitute for the input validation they cannot add to a shipped HttpSecurityFilter. Because that toggle is also the hardening step, it has to be inventoried and tested in advance rather than discovered mid-incident.",
         "gap_closes": [
           "UK-CAF-B4",
@@ -70751,7 +70751,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2022-35914 has a vendor-published configuration-side mitigation that closes the endpoint in minutes — delete vendor/htmlawed/htmlawed/htmLawedTest.php, keeping the legitimate htmLawed.php, and block web access to vendor/ — while the GLPI 10.0.3 / 9.5.9 upgrade is a scheduled change. During the mass-scanning wave that began 2022-10-03 that difference was the entire exposure, and the file's presence was the shipped baseline rather than drift, so the removal has to be a pre-tested deployable path.",
         "gap_closes": [
           "UK-CAF-B4",
@@ -72072,7 +72072,7 @@
       {
         "id": "NEW-CTRL-079",
         "name": "AV-EDR-AVAILABILITY-MONITORING",
-        "description": "Treat loss of AV/EDR availability as a first-class security event: alarm when an endpoint stops reporting Defender/EDR telemetry or its protection service crashes/restarts abnormally, correlate with inbound network activity, and patch the Defender antimalware platform to the fixed build (4.18.26040.7) as a KEV-priority item. A remotely-disable-able defender must not fail silent.",
+        "description": "Treat loss of AV/EDR availability as a first-class security event: alarm when an endpoint stops reporting Defender/EDR telemetry or its protection service crashes/restarts abnormally, and correlate with inbound network activity. A defender that has been disabled must not fail silent.",
         "evidence": "CVE-2018-19320 is used to terminate protected anti-malware processes from kernel mode with tamper protection bypassed, so the endpoint agent is killed as the chain's first move and produces no evidence of its own failure. Once the ring0 write lands, the agent going silent is the only remaining signal — which means silence has to be alarmed on rather than read as a healthy host.",
         "gap_closes": [
           "NIST-800-53-SI-3",
@@ -72949,7 +72949,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes the KEV-listed flaw, and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below that patch level and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2021-25337 is driven entirely by a locally installed untrusted app calling Samsung's exported SemClipboardProvider in system_server with no permission attribute, and the caller check that fixes it exists only in SMR Mar-2021 Release 1 or later — a carrier-staggered, reboot-bearing OEM update that Google Play system updates do not cover. Blocking handsets below that SMR level from organizational data and constraining side-loaded installs on devices that cannot yet reach it is the only operator-side lever, since no MDM policy or platform hardening setting affects the provider declaration.",
         "gap_closes": [
           "UK-CAF-B4",
@@ -73031,7 +73031,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes the KEV-listed flaw, and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below that patch level and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2021-25369 is remediated only by SMR Mar-2021 Release 1, whose fix deletes the sec_log duplicate of the kernel ring buffer outright, and delivery is OEM- and carrier-gated per model and per region. The exposed Exynos handsets are consumer hardware frequently outside enrolment entirely, so making the minimum security-patch level a condition of access to organizational data — rather than a dashboard field — is what removes vulnerable phones from corporate mail and VPN.",
         "gap_closes": [
           "AU-Essential-8-Patch"
@@ -73121,7 +73121,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes the KEV-listed flaw, and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below that patch level and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2021-25370 has no configuration workaround — the vulnerable path is the ordinary DECON window-config ioctl the Exynos display stack uses in normal operation — and the fix exists only in SMR Mar-2021 Release 1 (SVE-2021-19925), which moves fd_install() to the end of decon_set_win_config. The escalation runs from a locally installed app that first obtains system_app context, so enforcing the minimum SMR level as an access condition and constraining side-loaded installs are the only levers an operator holds on the device.",
         "gap_closes": [
           "UK-CAF-B4",
@@ -74529,7 +74529,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes the KEV-listed flaw, and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below that patch level and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2011-1823 — the vold SO_PASSCRED fix landed in AOSP on 2011-04-18 and shipped in Android 2.3.4, but reached a handset only when its OEM and carrier pushed an OTA, and GingerBreak was delivered by locally-installed repackaged apps (GingerMaster, DroidKungFu) on unenrolled personal devices. Reading the device build level and denying access below the fixed release — plus constraining side-loaded installs on handsets that will never update — is the only lever available when the fix exists upstream and never arrives on the device.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -74613,7 +74613,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2022-26352 — setting CONTENT_APIS_ALLOW_ANONYMOUS to anything other than WRITE stops /api/content/ accepting unauthenticated writes immediately and removes the preauth reachability that makes this a 9.8, without waiting for the 22.03 / 5.3.8.10_lts / 21.06.7_lts upgrade and its Tomcat restart. That configuration path has to be inventoried and pre-tested, because dotCMS shipped the anonymous-write default from 3.0 onward and the patch-cadence control the operator is measured against never names it.",
         "gap_closes": [
           "NIS2-Art21-patch-management",
@@ -74798,7 +74798,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2022-24112 — commenting batch-requests out of conf/config.yaml and conf/config-default.yaml removes the header-spoofing primitive outright, and rebinding the Admin API to its own port and interface removes the reachability, both deployable before the 2.12.1 / 2.10.4 upgrade. Those paths must be inventoried and rehearsed in advance, because nothing in a least-functionality baseline tells an operator that this one plugin, out of dozens shipped enabled, voids the Admin API's IP allowlist.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -74880,7 +74880,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2022-22963 — the spring.cloud.function.routing-expression header has no legitimate external use, so dropping it at the reverse proxy or WAF and unpublishing /functionRouter mitigates in minutes, while operators of embedded copies waited on Oracle's April and July 2022 Critical Patch Updates. That proxy-side path must be inventoried and testable independent of the vendor release, because Akamai observed mass exploitation attempts three days after the 3.1.7 / 3.2.3 fix shipped.",
         "gap_closes": [
           "AU-Essential-8-Patch",
@@ -75043,7 +75043,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2021-39226 — Grafana states the three literal paths (/api/snapshots/:key, /api/snapshots-delete/:deleteKey, /dashboard/snapshot/:key) have no normal function and can be blocked at the reverse proxy with no side effects, which stops the read-then-delete enumeration instantly and also covers repackaged copies — NetApp, distribution rebuilds, embedded dashboards — that have no 8.1.6 / 7.5.11 upgrade of their own. Because each read destroys a snapshot to reach the next, that path has to be already inventoried, not devised after the first deletion.",
         "gap_closes": [
           "AU-Essential-8-Patch"
@@ -76442,7 +76442,7 @@
       {
         "id": "NEW-CTRL-078",
         "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
-        "description": "Treat the EDR/endpoint-management server's agent-deployment channel (package/key-table → agent push) as a privileged supply-chain control plane: integrity-monitor the deployment artifacts and key tables, alert on agent pushes not tied to a sanctioned admin action, and patch the management server to the fixed build (Apex One on-prem 14.0.0.17079 / SaaS 14.0.20731) as a KEV-priority item. A server foothold must not silently become fleet-wide agent code execution.",
+        "description": "Treat the EDR/endpoint-management server's agent-deployment channel (package/key-table → agent push) as a privileged supply-chain control plane: integrity-monitor the deployment artifacts and key tables, alert on agent pushes not tied to a sanctioned admin action, and patch the management server to the fixed build as a KEV-priority item. A server foothold must not silently become fleet-wide agent code execution.",
         "evidence": "CVE-2022-40139 is the Apex One agent installing a rollback package its own management server named without validating the components (KEV maps it to missing integrity-check support), so the deployment channel itself is the code-execution primitive and one console instruction fans out to every managed endpoint. Because the flaw lives in client-side rollback logic driven from the server, both halves must reach the fixed build, and integrity-monitoring the deployment artifacts plus alerting on pushes not tied to a sanctioned admin action is the only measure that reaches inside a closed agent's update path.",
         "gap_closes": [
           "NIST-800-53-SR-11",
@@ -76534,7 +76534,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes the KEV-listed flaw, and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below that patch level and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2013-6282's fix shipped upstream in Linux 3.5.5 in September 2012, more than a year before the CVE, and reached handsets only through OEM and carrier builds that mostly never came — so OS-version attestation reports Android 4.3 as current while the ARMv6k/v7 kernel underneath still lacks the __user check. The exploit arrives as locally running code (it shipped already weaponised inside the vroot rooting application), so reading the device patch level, denying protected-resource access below it, and constraining untrusted app installation are the only levers an operator holds over a build pipeline it does not control.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -76618,7 +76618,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes the KEV-listed flaw, and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below that patch level and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2013-2597 needs nothing more than membership of the audio group — which any application granted RECORD_AUDIO obtains — to open /dev/msm_acdb and smash acdb_ioctl's stack on a Qualcomm MSM handset that never took the 2013-06-21 Code Aurora fix. Since the escalation is driven entirely by locally installed code, blocking devices below the fixed build from organisational data and constraining untrusted app installation are the enforceable levers, and keying that enforcement to the KEV listing rather than to EPSS matters here because EPSS sits near 0.015 on a confirmed-exploited kernel takeover.",
         "gap_closes": [
           "NIST-800-53-AC-6",
@@ -76711,7 +76711,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes the KEV-listed flaw, and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below that patch level and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2013-2596 is reached by Motochopper through the ADB shell on Motorola Android 4.1.2 builds that never received the 3.8.9 fb_mmap fix, and developer options stayed enabled across enterprise-issued Atrix HD, RAZR HD and RAZR M fleets whose configuration baselines enumerated software, ports and services but not device-side debug transports. An MDM that reads the patch level, quarantines devices below the fixed build and constrains locally installed or side-loaded code governs exactly the precondition the exploit needs.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -77172,7 +77172,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2020-28949 has a no-code-change mitigation Drupal published with its own advisory — block .tar, .tar.gz, .bz2 and .tlz uploads — which removes the extraction path entirely at the point the trigger occurs, an authorised editor uploading an archive through a sanctioned workflow. Hosts on end-of-life PHP 7.2/7.3 streams were told no php-pear patch would ship at all, so the configuration-side path was their only available remediation.",
         "gap_closes": [
           "DORA-Art-9",
@@ -77255,7 +77255,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2022-0028's vendor workarounds — removing the URL-filtering profile from any security rule whose source zone has an external-facing interface, or enabling zone protection with 'TCP Drop > TCP SYN with Data' and 'Strip TCP Options > TCP Fast Open' or a SYN activation threshold of 0 — neutralise the reflection in a single configuration commit with no reboot, while the PAN-OS 10.2.2-h2-class upgrade is maintenance-window work on the device carrying all site traffic. The mitigation path has to be pre-inventoried and tested, because the patch-centric framing gives an assessor no prompt toward taking it.",
         "gap_closes": [
           "AU-Essential-8-Patch",
@@ -78150,7 +78150,7 @@
       {
         "id": "NEW-CTRL-144",
         "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
-        "description": "The packet names the affected product as Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the packet ties the CWE-1321 sink to Acrobat and Reader and provides no mapping from the vulnerable code into other PDF-handling software, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version — an estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. The packet registers no live-patch path, so each copy carries the service restart or system reboot the vendor fix requires, and a copy updated but not restarted is not yet remediated.",
+        "description": "The affected product is Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the vulnerable code is in Acrobat and Reader, and no mapping from it into other PDF-handling software is established, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version. An estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. No live-patch path is available, so each copy must be updated to the fixed build.",
         "evidence": "The affected set here is exactly the two-track case the control describes: Adobe Reader and Adobe Acrobat Professional/Standard/3D at 8.1.1 and earlier, fixed on separate tracks at 8.1.2, with the 7.x line served by a third fix at 7.1.0 under APSB08-13, plus distribution repackages (RHSA-2008-0144, Gentoo, Solaris) carrying their own update paths. The parity test is the operative half: with a public Metasploit module targeting Reader 8.1.1 specifically, a single surviving Acrobat copy below 8.1.2 makes the whole estate exploitable regardless of how clean the Reader record reads. Note the restart nuance for this product — no host reboot, but Reader/Acrobat and any browser hosting the plugin must be relaunched before the fix is live.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -78253,7 +78253,7 @@
       {
         "id": "NEW-CTRL-144",
         "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
-        "description": "The packet names the affected product as Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the packet ties the CWE-1321 sink to Acrobat and Reader and provides no mapping from the vulnerable code into other PDF-handling software, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version — an estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. The packet registers no live-patch path, so each copy carries the service restart or system reboot the vendor fix requires, and a copy updated but not restarted is not yet remediated.",
+        "description": "The affected product is Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the vulnerable code is in Acrobat and Reader, and no mapping from it into other PDF-handling software is established, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version. An estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. No live-patch path is available, so each copy must be updated to the fixed build.",
         "evidence": "This entry is the two-track case exactly: Adobe Reader and Adobe Acrobat Professional/Standard/3D before 8.1.2 on separate update tracks, with the 7.x line served by a third fix at 7.1.0 under APSB08-13. Parity matters more than usual because the id is an aggregate — NVD carries it as multiple unspecified vulnerabilities before 8.1.2 — so a copy left below the fixed build is exposed to the whole bundle, not to one characterised defect. Restart nuance for this product: no host reboot, but Reader/Acrobat and any browser hosting the plugin must be relaunched before the fix is in force.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -78356,7 +78356,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "The control's framing matches this entry exactly: CVE-2009-0557 is classified as CWE-94, the sink is reached by opening a crafted Excel workbook, and MS09-021 confirms that opening the file is the only interaction required. The delivery half is the enforceable lever for the affected products (Office 2000/XP/2003, the 2007 Office System, Excel Viewer and the Compatibility Pack), with one precondition stated honestly: Protected View does not exist on Office 2003 and earlier, so on those builds only the gateway-side provenance marking and File Block are deliverable, and the sandbox half arrives with migration to a supported Office release.",
         "gap_closes": [
           "NIST-800-53-SC-44",
@@ -78680,7 +78680,7 @@
       {
         "id": "NEW-CTRL-144",
         "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
-        "description": "The packet names the affected product as Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the packet ties the CWE-1321 sink to Acrobat and Reader and provides no mapping from the vulnerable code into other PDF-handling software, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version — an estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. The packet registers no live-patch path, so each copy carries the service restart or system reboot the vendor fix requires, and a copy updated but not restarted is not yet remediated.",
+        "description": "The affected product is Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the vulnerable code is in Acrobat and Reader, and no mapping from it into other PDF-handling software is established, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version. An estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. No live-patch path is available, so each copy must be updated to the fixed build.",
         "evidence": "This entry is the hardest version of the parity problem in the batch: APSB10-02 fixes three concurrently-serviced lines — 9.3, 8.2 on Windows and macOS, and 7.1.4 — and Reader and Acrobat each have their own track within every line, so the estate has up to six distinct pre-fix versions to enumerate rather than one. The public Metasploit module names Reader 8.1.2 as a working target specifically, which is the older-line build an inventory scoped to the current major version never sees. Restart nuance for this product: no host reboot, but Reader/Acrobat and any browser hosting the plugin must be relaunched before the fixed parser is in use.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -78889,7 +78889,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "This JBoss flaw is entirely configuration-side: removing the <http-method> elements from the jmx-console security-constraint restores deny-all across every verb, which is Red Hat's own guidance in solution 30744 and the only remedy available for community JBoss AS 4.0.x, where RHSA-2010:0379 does not apply. Treating that edit as an inventoried, tested artefact — held in configuration management and reapplied after any console redeploy — is what lets an operator close the path without an EAP upgrade window, and it is also what would have covered the embedded JBossAS instances the SamSam campaign found in 2016.",
         "gap_closes": [
           "NIST-800-53-AC-3",
@@ -79218,7 +79218,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "The whole remedy for this JBoss defect is configuration: undeploy /web-console where it is unused, or remove the <http-method> elements from its security-constraint so deny-all covers every verb, which is Red Hat's own guidance in solution 30744 and the only remedy available for community JBoss AS 4.0.x where RHSA-2010:0376 does not apply. Holding that artefact in configuration management — tested, and reapplied after any console redeploy restores the shipped descriptor — is what closes the path without an EAP upgrade window, and it is the only measure that would have covered the embedded JBossAS instances JexBoss found in 2016.",
         "gap_closes": [
           "NIST-800-53-AC-3",
@@ -79531,7 +79531,7 @@
       {
         "id": "NEW-CTRL-122",
         "name": "EOL-ASSET-DECOMMISSION",
-        "description": "This entry is the case the control exists for, and both halves are on record. patch_available is true — a fixed build carrying this JavaScriptCore fix exists — and the vector itself states that the impacted product could be end-of-life and/or end-of-service and that users should discontinue product utilization. Those facts together define the requirement: on a unit whose hardware can still take an Apple security update, reaching the fixed build is an interim state; on a unit that can no longer take one, the terminal state is removal or replacement, because that device is exposed not only to this code-execution flaw but to everything found in that engine since its last build. Scope to what the packet names — macOS, iOS, tvOS, Safari and watchOS — and inventory those. The packet ties the CWE-94 sink to JavaScriptCore in those products and gives no mapping into other vendors' browsers or other software that embeds a web engine, so treating every renderer in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. In operational terms: enumerate every macOS, iOS, tvOS, watchOS and Safari install that renders untrusted web content, record for each whether its hardware can still receive a build carrying the fix, put those on the interim clock against the 2025-10-20 KEV listing, and put the rest on a dated replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: live_patch_available is false and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a device that downloaded the update but has not restarted still runs the vulnerable code and is not remediated. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "description": "Software with no vendor patch path must be isolated and decommissioned within a bounded window; mandatory compensating configuration applies until removal.",
         "evidence": "Applied here to Adobe Flash Player, Adobe AIR and the authplay.dll copy inside Adobe Reader and Acrobat. Both halves the control describes are present: fixed builds exist (Flash Player 10.2.153.1, AIR 2.6, Reader/Acrobat 9.4.3, 2011-03-21) and the product line is dead - Adobe stopped supporting Flash Player on 2020-12-31, blocked Flash content in the player on 2021-01-12, and tells users to uninstall. CISA's KEV entry of 2022-06-08 states the required action as disconnection rather than update. So reaching a patched Flash build is not an end state for any of the three product families; enumerating every install that can render Flash - browsers, AIR applications, and Reader/Acrobat 9.x and 10.0.x - and putting each on a dated removal schedule is. A risk acceptance with no removal date leaves a KEV-listed flaw with public Metasploit and Exploit-DB code (EDB-17027) in service indefinitely, and the runtime does not restart-and-remediate: an updated host that never closed its browser or PDF reader is still executing the old code.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -79621,7 +79621,7 @@
       {
         "id": "NEW-CTRL-144",
         "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
-        "description": "The affected product is Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the CWE-1321 sink is in Acrobat and Reader, and no mapping from the vulnerable code into other PDF-handling software is established, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version. An estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. No live-patch path is available, so each copy carries the service restart or system reboot the vendor fix requires, and a copy updated but not restarted is not yet remediated.",
+        "description": "The affected product is Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the vulnerable code is in Acrobat and Reader, and no mapping from it into other PDF-handling software is established, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version. An estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. No live-patch path is available, so each copy must be updated to the fixed build.",
         "evidence": "Adobe Reader and Acrobat are exactly the split this control describes, and CVE-2011-2462 made the cost visible: Adobe fixed Reader and Acrobat 9.4.7 for Windows on 2011-12-16 but did not ship Reader X and Acrobat X 10.1.2 or the 9.x Linux Reader until 2012-01-10, so an estate that closed the ticket on the December package left its X-line installs exploitable for another 25 days while the vulnerability was under active targeted attack per Adobe's APSA11-04. Public exploit code (Exploit-DB 18366) landed 2012-01-14, four days after the last fix, and EPSS still rates this 0.86563 at the 99.721st percentile on 2026-08-13 because unmanaged Reader and Acrobat copies persist. The parity test is per-product and per-track, not per-package.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -79841,7 +79841,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "The in-the-wild campaign against Adobe Flash Player CVE-2012-0754, found 2012-03-02, was a Word document ('Iran's Oil and Nuclear Situation.doc') with an embedded Flash object that fetched the malicious MP4 - so the vulnerable Flash MP4 parser was reached through Office, sixteen days after Adobe shipped 10.3.183.15 and 11.1.102.62 on 2012-02-15. Provenance enforcement is the control that covers that interval on an estate that has not yet updated, because a document opened in an isolated reduced-privilege render does not instantiate the embedded object at the user's own privilege. The same enforcement is the durable answer for the residual population: Flash Player has been end-of-life since 2020-12-31, so for any host that still has the runtime there is no fixed build left to reach, only the delivery path to close.",
         "gap_closes": [
           "NIST-800-53-SC-44",
@@ -79961,7 +79961,7 @@
       {
         "id": "NEW-CTRL-122",
         "name": "EOL-ASSET-DECOMMISSION",
-        "description": "This entry is the case the control exists for, and both halves hold here. A fixed build carrying this JavaScriptCore fix is available. The impacted product could be end-of-life and/or end-of-service, and users should discontinue product utilization. Those facts together define the requirement: on a unit whose hardware can still take an Apple security update, reaching the fixed build is an interim state; on a unit that can no longer take one, the terminal state is removal or replacement, because that device is exposed not only to this code-execution flaw but to everything found in that engine since its last build. Scope to macOS, iOS, tvOS, Safari and watchOS, and inventory those. The CWE-94 sink is in JavaScriptCore in those products, and no mapping into other vendors' browsers or other software that embeds a web engine is established, so treating every renderer in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. In operational terms: enumerate every macOS, iOS, tvOS, watchOS and Safari install that renders untrusted web content, record for each whether its hardware can still receive a build carrying the fix, put those on the interim clock against the 2025-10-20 KEV listing, and put the rest on a dated replacement schedule. A risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: no live patch is available, and the vendor patch typically requires a service restart or system reboot, so a device that downloaded the update but has not restarted still runs the vulnerable code and is not remediated. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "description": "Software with no vendor patch path must be isolated and decommissioned within a bounded window; mandatory compensating configuration applies until removal.",
         "evidence": "Applied to Adobe Flash Player, where both halves hold in the same shape: a fixed build exists (10.3.183.15 and 11.1.102.62, 2012-02-15) and the product line is dead - Adobe ended support on 2020-12-31, blocked Flash content in the player on 2021-01-12, and instructs users to uninstall, while CISA's KEV entry of 2022-06-08 states the required action as disconnection rather than update. Reaching a patched Flash build is therefore an interim state only; the terminal state is removing the runtime from every browser and every application that embeds it, because a host that still renders Flash content is exposed not just to this same-origin bypass but to everything found in that runtime since its last build. Delivery here was attacker-controlled web content reached from a mailed link, so a user who followed one while exposed belongs on the session-integrity incident path rather than being closed out on the plugin version.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -80073,7 +80073,7 @@
       {
         "id": "NEW-CTRL-122",
         "name": "EOL-ASSET-DECOMMISSION",
-        "description": "This entry is the case the control exists for, and both halves hold. A fixed build carrying this JavaScriptCore fix is available. The impacted product could be end-of-life and/or end-of-service, and users should discontinue product utilization. Those facts together define the requirement: on a unit whose hardware can still take an Apple security update, reaching the fixed build is an interim state; on a unit that can no longer take one, the terminal state is removal or replacement, because that device is exposed not only to this code-execution flaw but to everything found in that engine since its last build. Scope to macOS, iOS, tvOS, Safari and watchOS, and inventory those. The CWE-94 sink is in JavaScriptCore in those products, and no mapping into other vendors' browsers or other software that embeds a web engine is established, so treating every renderer in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. In operational terms: enumerate every macOS, iOS, tvOS, watchOS and Safari install that renders untrusted web content, record for each whether its hardware can still receive a build carrying the fix, put those on the interim clock against the 2025-10-20 KEV listing, and put the rest on a dated replacement schedule. A risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: no live patch is available, and the vendor patch typically requires a service restart or system reboot, so a device that downloaded the update but has not restarted still runs the vulnerable code and is not remediated. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "description": "Software with no vendor patch path must be isolated and decommissioned within a bounded window; mandatory compensating configuration applies until removal.",
         "evidence": "Applied to Oracle WebCenter Forms Recognition on Fusion Middleware 10.1.3.5, where both halves the control describes hold: a fixed build exists (Oracle patch 13882540, April 2012 CPU, released 2012-04-17) and the release line is past its supported life, since Oracle Forms Recognition 10gR3 (10.1.3.x) - GA February 2011 - left Premier Support in December 2016, has no Extended Support tier available, and now carries only indefinite Sustaining Support, which delivers no new security fixes. Applying 13882540 is therefore an interim state; the terminal state is migration to a supported Forms Recognition release or retirement of the component, because a 10.1.3.5 install carries not only this caller-controlled file write but everything found in that release since its last patch. The inventory this control demands is unusually specific here: it is the Designer workstations with Sssplt30.ocx and CroScPlt.dll registered, not the server tier, and each needs either a dated migration or removal of the Designer. A risk acceptance with no removal date leaves a CVE that CISA listed on 2022-05-25 and flagged ransomware-associated in service indefinitely.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -81840,7 +81840,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "The in-the-wild attack FireEye reported to Microsoft delivered this exact CWE-94 sink through content carrying a malicious TrueType font, with Qualys' 2014-10-14 analysis naming an Office document as an exploit vector — so on the unpatched Windows population the provenance of the incoming document is the only lever an operator holds. The control's own caveat is sharper here than usual: the font is parsed by win32k.sys in the kernel, so the reduced-privilege render is a delivery-path control and not a containment boundary for this bug, and it must be paired with KB3000061 plus the reboot rather than treated as sufficient. Its value is that it bounds who can get a weaponised font in front of the parser during the window before that reboot lands.",
         "gap_closes": [
           "AU-Essential-8-App-Hardening",
@@ -82313,7 +82313,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "Microsoft names opening a specially crafted document as one of the two delivery routes into this DirectWrite font parser, alongside visiting a page with embedded TrueType fonts, and Office 2007 SP3 and Office 2010 SP2 are both in MS15-044's affected list — so document provenance is a real lever on the population that has not yet closed every patch channel. Two limits have to be stated with it: the second delivery route is an untrusted web page carrying embedded TrueType fonts, which document provenance does not touch at all; and a reduced-privilege render bounds what the attacker's code inherits without repairing the parser. It is a delivery-path control for the window before 3045171, the .NET packages, the Office and Lync updates and Silverlight 5.1.40416.00 all land and the applications are relaunched.",
         "gap_closes": [
           "UK-CAF-B4",
@@ -82909,7 +82909,7 @@
       {
         "id": "NEW-CTRL-122",
         "name": "EOL-ASSET-DECOMMISSION",
-        "description": "This entry is the case the control exists for, and it carries both halves. A fixed build carrying this JavaScriptCore fix is available. The impacted product could be end-of-life and/or end-of-service, and users should discontinue product utilization. Those facts together define the requirement: on a unit whose hardware can still take an Apple security update, reaching the fixed build is an interim state; on a unit that can no longer take one, the terminal state is removal or replacement, because that device is exposed not only to this code-execution flaw but to everything found in that engine since its last build. Scope to macOS, iOS, tvOS, Safari and watchOS, and inventory those. The CWE-94 sink is in JavaScriptCore in those products, and no mapping into other vendors' browsers or other software that embeds a web engine is established, so treating every renderer in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. In operational terms: enumerate every macOS, iOS, tvOS, watchOS and Safari install that renders untrusted web content, record for each whether its hardware can still receive a build carrying the fix, put those on the interim clock against the 2025-10-20 KEV listing, and put the rest on a dated replacement schedule. A risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: no live patch is available, and the vendor patch typically requires a service restart or system reboot, so a device that downloaded the update but has not restarted still runs the vulnerable code and is not remediated. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "description": "Software with no vendor patch path must be isolated and decommissioned within a bounded window; mandatory compensating configuration applies until removal.",
         "evidence": "Adobe Flash Player is the archetype the control describes, and CISA states the disposition outright in this CVE's KEV entry of 2022-05-25: 'The impacted product is end-of-life and should be disconnected if still in use.' A fixed build exists — 20.0.0.267 on Windows and OS X, 18.0.0.324 for the extended-support release, 11.2.202.559 on Linux, AIR at 20.0.0.233, all from APSB16-01 on 2015-12-28 — and reaching it is now meaningless, because Adobe ended Flash support on 31 December 2020 and the runtime is exposed to everything found in it since. The inventory the control demands has to enumerate every channel separately for this product: standalone NPAPI and PPAPI installs, the Chrome-bundled build, the Microsoft-serviced build in Edge and Internet Explorer, the ActiveX control, and AIR-packaged desktop applications that embed the runtime with no browser involved. Adobe AIR needs its own determination rather than inheriting Flash's status, since that line moved to HARMAN and remains maintained.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -83026,7 +83026,7 @@
       {
         "id": "NEW-CTRL-122",
         "name": "EOL-ASSET-DECOMMISSION",
-        "description": "This entry is the case the control exists for, and both halves are explicit. A fixed build carrying this JavaScriptCore fix is available. The impacted product could be end-of-life and/or end-of-service, and users should discontinue product utilization. Those facts together define the requirement: on a unit whose hardware can still take an Apple security update, reaching the fixed build is an interim state; on a unit that can no longer take one, the terminal state is removal or replacement, because that device is exposed not only to this code-execution flaw but to everything found in that engine since its last build. Scope to macOS, iOS, tvOS, Safari and watchOS, and inventory those. The CWE-94 sink is in JavaScriptCore in those products, and no mapping into other vendors' browsers or other software that embeds a web engine is established, so treating every renderer in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. In operational terms: enumerate every macOS, iOS, tvOS, watchOS and Safari install that renders untrusted web content, record for each whether its hardware can still receive a build carrying the fix, put those on the interim clock against the 2025-10-20 KEV listing, and put the rest on a dated replacement schedule. A risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: no live patch is available, and the vendor patch typically requires a service restart or system reboot, so a device that downloaded the update but has not restarted still runs the vulnerable code and is not remediated. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "description": "Software with no vendor patch path must be isolated and decommissioned within a bounded window; mandatory compensating configuration applies until removal.",
         "evidence": "Microsoft Silverlight is the product this control governs on this entry, and CISA states the disposition in the KEV record of 2022-05-25: 'The impacted products are end-of-life and should be disconnected if still in use.' A fixed build exists — 5.1.41212.0 from MS16-006 / KB3126036 on 2016-01-12 — so reaching it was the interim state, and Silverlight 5's end of support turned removal into the terminal one. The inventory the control demands is per-host and per-browser rather than per-product: read the build from sllauncher.exe or HKLM\\SOFTWARE\\Microsoft\\Silverlight on Windows and Silverlight.Plugin's info.plist on Mac, and record for each host whether an internal application actually needs the plug-in, because that dependency — not the update — is what keeps it installed. A risk acceptance with no removal date leaves a KEV-listed flaw that Angler EK was serving with TeslaCrypt from 2016-02-22 and RIG with Qbot from 2016-03-29 in service indefinitely.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -85154,7 +85154,7 @@
       {
         "id": "NEW-CTRL-144",
         "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
-        "description": "The affected product is Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the CWE-1321 sink is in Acrobat and Reader, and no mapping from the vulnerable code into other PDF-handling software is established, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version. An estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. No live-patch path is available, so each copy carries the service restart or system reboot the vendor fix requires, and a copy updated but not restarted is not yet remediated.",
+        "description": "The affected product is Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the vulnerable code is in Acrobat and Reader, and no mapping from it into other PDF-handling software is established, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version. An estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. No live-patch path is available, so each copy must be updated to the fixed build.",
         "evidence": "The three-track inventory problem is literal on this CVE: NVD fixes the vulnerable boundary separately for the Continuous track (Acrobat DC / Acrobat Reader DC <= 2018.011.20038), the 2017 track (<= 2017.011.30079) and the Classic 2015 track (<= 2015.006.30417), each closed by its own APSB18-09 update in May 2018. The weakness here is a double free (CWE-415) reached through PDF JavaScript rather than the CWE-1321 sink the control text cites from the entry it was written for; the inventory-and-parity requirement is what carries across, not that classification. Sweep scope should stay on Adobe Acrobat and Reader — no verified source maps this vulnerable code into other vendors' PDF software. On the restart clause, adjust for this product: no host reboot is needed, but a resident Acrobat or Reader process keeps the vulnerable parser loaded until it relaunches, so 'updated' without a relaunch is not remediated.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -85889,7 +85889,7 @@
       {
         "id": "NEW-CTRL-054",
         "name": "BACKUP-TIER-NETWORK-ISOLATION",
-        "description": "A BeeStation is a consumer NAS whose whole purpose is holding the primary and backup copy of a household's or a branch site's data, and the attack path reaches it with no credential and no user interaction: a pre-auth chain against the BeeStation Manager web management surface ending in OS command execution on the box that holds the data. Applied to this product, the control means the BeeStation Manager web surface answers only from an operator subnet or an authenticated VPN: not from the general user VLAN, and not from the internet via a UPnP mapping or a home-router port forward, which is how consumer NAS hardware at remote-worker and small-branch sites normally acquires exposure. The appliance's outbound path should be constrained too, so a rooted BeeStation cannot reach arbitrary destinations with the data it holds. Reachability is the entire exploit precondition for a pre-auth CWE-78 flaw, and it is the only lever an operator holds between a public exploit chain and a firmware update landing on a device that no enterprise console manages. A vendor patch exists but there is no live-patch path, so the appliance has to be taken through the update to remediate. The distinguishing test: from a general user VLAN and from an external address, attempt to load the BeeStation Manager web surface; anything that answers is within reach of the published chain, and \"the NAS is on the internal network\" is an assertion about topology, not a demonstration that the management surface is unreachable from untrusted segments.",
+        "description": "Backup-orchestration appliances and backup-data destinations must be network-isolated from the data-plane networks they protect. Management surfaces must be reachable only from operator subnets; backup-data paths must use unidirectional or pull-only patterns from the backup tier to the protected systems where possible.",
         "evidence": "The identical reachability logic governs QNAP Photo Station CVE-2019-7194: a pre-auth traversal chain on a consumer/SMB NAS web surface, with ~312K units found internet-exposed by CyCarrier and no operator-side lever other than reachability once the public chain (Exploit-DB 48531) exists. Restricting the Photo Station / QTS web surface to an operator subnet or VPN removes the exposure that the KEV listing (2022-06-08) and EPSS 0.831 make attacker-attractive.",
         "gap_closes": [
           "NIST-800-53-SC-7"
@@ -85977,7 +85977,7 @@
       {
         "id": "NEW-CTRL-054",
         "name": "BACKUP-TIER-NETWORK-ISOLATION",
-        "description": "A BeeStation is a consumer NAS whose whole purpose is holding the primary and backup copy of a household's or a branch site's data, and the attack path reaches it with no credential and no user interaction: a pre-auth chain against the BeeStation Manager web management surface ending in OS command execution on the box that holds the data. Applied to this product, the control means the BeeStation Manager web surface answers only from an operator subnet or an authenticated VPN: not from the general user VLAN, and not from the internet via a UPnP mapping or a home-router port forward, which is how consumer NAS hardware at remote-worker and small-branch sites normally acquires exposure. The appliance's outbound path should be constrained too, so a rooted BeeStation cannot reach arbitrary destinations with the data it holds. Reachability is the entire exploit precondition for a pre-auth CWE-78 flaw, and it is the only lever an operator holds between a public exploit chain and a firmware update landing on a device that no enterprise console manages. A vendor patch exists but there is no live-patch path, so the appliance has to be taken through the update to remediate. The distinguishing test: from a general user VLAN and from an external address, attempt to load the BeeStation Manager web surface; anything that answers is within reach of the published chain, and \"the NAS is on the internal network\" is an assertion about topology, not a demonstration that the management surface is unreachable from untrusted segments.",
+        "description": "Backup-orchestration appliances and backup-data destinations must be network-isolated from the data-plane networks they protect. Management surfaces must be reachable only from operator subnets; backup-data paths must use unidirectional or pull-only patterns from the backup tier to the protected systems where possible.",
         "evidence": "The same reachability logic governs QNAP Photo Station CVE-2019-7195: a pre-auth traversal on a consumer/SMB NAS web surface, ~312K units found internet-exposed, and reachability the only operator lever once Exploit-DB 48531 exists. Restricting the Photo Station / QTS web surface to an operator subnet or VPN removes the exposure the KEV listing and EPSS 0.897 make attacker-attractive.",
         "gap_closes": [
           "NIST-800-53-SC-7"
@@ -86421,7 +86421,7 @@
       {
         "id": "NEW-CTRL-121",
         "name": "MOBILE-ZERO-CLICK-HARDENING",
-        "description": "For the population plausibly inside the targeting set this class of Apple flaw serves (executives, journalists, legal and security staff), the reboot-gated update is not fast enough on its own, because the overflow is a sandbox-escape / privilege step inside a chain rather than a standalone bug. Place those users in a reduced-attack-surface mode so untrusted web content, message attachments, fonts and link previews are not processed automatically, narrowing the delivery path into the CWE-119 primitive during the window between the 2026-03-20 KEV listing and completed fleet restart. This has to be a standing posture for the high-risk cohort assigned before the next disclosure, not a reaction to this CVE. The mode only helps if it was already on when the chain arrived.",
+        "description": "For the population plausibly inside the targeting set this class of Apple flaw serves (executives, journalists, legal and security staff), the reboot-gated update is not fast enough on its own, because the overflow is a sandbox-escape / privilege step inside a chain rather than a standalone bug. Place those users in a reduced-attack-surface mode so untrusted web content, message attachments, fonts and link previews are not processed automatically, narrowing the delivery path into the overflow during the window between the 2022-06-27 KEV listing and completed fleet restart. This has to be a standing posture for the high-risk cohort assigned before the next disclosure, not a reaction to this CVE. The mode only helps if it was already on when the chain arrived.",
         "evidence": "IOMobileFrameBuffer bugs like CVE-2021-30983 are the privilege step of iOS chains, and a sibling IOMobileFrameBuffer flaw was exploited as a zero-day the same year; a reduced-attack-surface mode (Lockdown-style) assigned to the high-risk cohort narrows the delivery path into this kernel-buffer-overflow primitive during the window before the reboot-gated iOS 15.2 update lands.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -86669,7 +86669,7 @@
       {
         "id": "NEW-CTRL-145",
         "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
-        "description": "The flaw is in Windows Remote Desktop Services and lets an authorized attacker elevate privileges locally (CWE-269). The account is already legitimate, so no account model is being abused; a privilege boundary inside the service is failing. For this CVE the control means the Windows update carrying the fix is driven across every affected host on the KEV clock that opened 2026-02-10 rather than folded into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. Hosts running the Remote Desktop Services role are the population to enumerate first, because a machine where many non-administrative users hold interactive sessions is a machine where the precondition this flaw needs (an already-authorized local user) is the normal operating state rather than an anomaly. There is a vendor patch with no live-patch path, and the fix typically requires a service restart or system reboot, so a host that has taken the update but not restarted still carries the vulnerable code and must be counted as exposed; on a session host that restart is also the step most likely to be deferred, because taking it evicts logged-on users, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. The control's second half is the load-bearing one here: since the attacker is already authorized, tightening account privilege does not contain the escalation, which is exactly why the least-privilege and identity-and-access controls cited on this entry can pass their attestations while the flaw stays fully exploitable. Priority follows the exploitation evidence rather than the CVSS band: a public PoC, confirmed exploitation, and the routine pairing of LPEs of this class with an initial-access flaw by ransomware operators make this the containment step for a chain, not a standalone endpoint item.",
+        "description": "When an OS vendor flags a local-privilege-escalation flaw as exploited in the wild and it is KEV-listed, the monthly cumulative update that fixes it must be applied and rebooted rather than merely staged.",
         "evidence": "CVE-2022-22047 is a Windows CSRSS local escalation to SYSTEM that Microsoft flagged exploited-in-the-wild at the July 2022 Patch Tuesday and CISA KEV-listed 2022-07-12 (due 2022-08-02). Like the RDS case the control was written for, it is a same-host escalation of an already-authorized user across a service privilege boundary, the fix requires a reboot with no live-patch path, and completion must be measured by rebooted build — session/server hosts where the deferred reboot is most tempting are exactly where it stays exposed.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -87358,7 +87358,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "The Metasploit module for this CVE ships both DOCX and RTF generators, and its documentation records that the RTF variant fires from the Explorer preview pane rather than on open — so on Windows without the June 2022 cumulative update, provenance marking is the difference between a document that renders in an isolated Protected View instance and one that reaches the remote-template relationship at full user privilege. The control's warning about macro-and-OLE-only hardening attestations is exactly the Essential Eight application-hardening gap recorded on this entry: none of those settings touch the ms-msdt path.",
         "gap_closes": [
           "NIST-800-53-SI-3",
@@ -87913,7 +87913,7 @@
       {
         "id": "NEW-CTRL-145",
         "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
-        "description": "The packet's vector places this in Windows Remote Desktop Services and describes an authorized attacker elevating privileges locally (CWE-269) — the account is already legitimate, so no account model is being abused; a privilege boundary inside the service is failing. For this CVE the control means the Windows update carrying the fix is driven across every affected host on the KEV clock that opened 2026-02-10 rather than folded into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. Hosts running the Remote Desktop Services role are the population to enumerate first, because a machine where many non-administrative users hold interactive sessions is a machine where the precondition this flaw needs — an already-authorized local user — is the normal operating state rather than an anomaly. There is a vendor patch with no live-patch path, and the fix typically requires a service restart or system reboot, so a host that has taken the update but not restarted still carries the vulnerable code and must be counted as exposed; on a session host that restart is also the step most likely to be deferred, because taking it evicts logged-on users, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. The control's second half is the load-bearing one here: since the attacker is already authorized, tightening account privilege does not contain the escalation, which is exactly why the least-privilege and identity-and-access controls cited on this entry can pass their attestations while the flaw stays fully exploitable. Priority follows the packet rather than the CVSS band: a public PoC, confirmed exploitation, and the packet's own note that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators make this the containment step for a chain, not a standalone endpoint item.",
+        "description": "When an OS vendor flags a local-privilege-escalation flaw as exploited in the wild and it is KEV-listed, the monthly cumulative update that fixes it must be applied and rebooted rather than merely staged.",
         "evidence": "CVE-2026-68820 is an afd.sys use-after-free that elevates an already-authorized local user to SYSTEM, KEV-listed 2026-08-11 with a 2026-08-25 due date and Microsoft's Exploitation Detected flag. The fix (e.g. KB5121003 to build 10.0.26200.9168) has no live-patch path and requires a reboot; RDS and shared-workstation hosts, where many non-admin users hold interactive logons, are exactly where the 'already-authorized local user' precondition is normal, and where the reboot is most often deferred.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -88008,7 +88008,7 @@
       {
         "id": "NEW-CTRL-085",
         "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
-        "description": "Parameterization must be verified at the database abstraction layer / query builder, not assumed from application-layer input validation or a perimeter WAF. For Drupal, apply SA-CORE-2026-004 (10.4.10 / 10.5.10 / 10.6.9 / 11.1.10 / 11.2.12 / 11.3.10), prioritize PostgreSQL-backed sites, and meet the CISA KEV due date 2026-05-27. The distinguishing test: send a JSON:API request with a SQL metacharacter in a filter condition against a staging instance and confirm the query builder parameterizes rather than concatenates it.",
+        "description": "Parameterization must be verified at the database abstraction layer / query builder, not assumed from application-layer input validation or a perimeter WAF. The distinguishing test: send a request with a SQL metacharacter in a filter condition against a staging instance and confirm the query builder parameterizes rather than concatenates it.",
         "evidence": "CVE-2026-72898 is exactly a query-builder parameterization failure: Metabase passed a caller-supplied JSON object (token / user-id) into HoneySQL on the unauthenticated /api/session/reset_password path, so {\"select\":{\"raw\":...}} became live SQL against core_session. The distinguishing test applies directly — send a non-string token ({\"select\":1}) to a staging instance and confirm rejection rather than a HoneySQL error. Fixed in v58.24 / v59.21 / v60.17 / v61.11 / v62.9 / v63.5; KEV-listed 2026-08-11, due 2026-08-14.",
         "gap_closes": [
           "NIST-800-53-SI-10",
@@ -94007,7 +94007,7 @@
       {
         "id": "NEW-CTRL-122",
         "name": "EOL-ASSET-DECOMMISSION",
-        "description": "This entry is the case the control exists for, and both halves are on record. patch_available is true — a fixed build carrying this JavaScriptCore fix exists — and the vector itself states that the impacted product could be end-of-life and/or end-of-service and that users should discontinue product utilization. Those facts together define the requirement: on a unit whose hardware can still take an Apple security update, reaching the fixed build is an interim state; on a unit that can no longer take one, the terminal state is removal or replacement, because that device is exposed not only to this code-execution flaw but to everything found in that engine since its last build. Scope to what the packet names — macOS, iOS, tvOS, Safari and watchOS — and inventory those. The packet ties the CWE-94 sink to JavaScriptCore in those products and gives no mapping into other vendors' browsers or other software that embeds a web engine, so treating every renderer in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. In operational terms: enumerate every macOS, iOS, tvOS, watchOS and Safari install that renders untrusted web content, record for each whether its hardware can still receive a build carrying the fix, put those on the interim clock against the 2025-10-20 KEV listing, and put the rest on a dated replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: live_patch_available is false and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a device that downloaded the update but has not restarted still runs the vulnerable code and is not remediated. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "description": "Software with no vendor patch path must be isolated and decommissioned within a bounded window; mandatory compensating configuration applies until removal.",
         "evidence": "For Checkbox Survey there is no interim half at all, which is what makes the decommissioning requirement absolute rather than conditional. CERT/CC VU#706695 records that Checkbox is no longer developing version 6, so no build carrying a fix exists for the affected line; version 7.0 removed view state from the product entirely and is a migration target, not an update. CISA said the same thing in its own words on 2022-04-11: versions 6 and earlier are end-of-life and must be removed from agency networks, due 2022-05-02. The inventory to produce is every Windows host with CheckboxWeb.dll at a 6.x product version, with its IIS bindings and application-pool identity recorded, and each entry needs a dated migration-or-removal commitment — a risk acceptance with no removal date leaves a CVSS 9.8 unauthenticated deserialization RCE, reported exploited in the wild since May 2021, answering anonymous requests indefinitely.",
         "gap_closes": [
           "NIST-800-53-SR-3",
@@ -94661,7 +94661,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "Microsoft Office Access Connectivity Engine is exactly the delivery-path case: CVSS PR:N with UI:R means the attacker supplies a file and the victim's click is the whole precondition, and because the artefact is a data source rather than a macro-bearing document, no macro policy is consulted anywhere in the sequence. The engine ships with Microsoft 365 Apps, Office 2013 SP1, Office 2016 and Office 2019 rather than only with Access, so the exposed population is every Office desktop until its version is verified against 15.0.5381.1000 or 16.0.5215.1000. With CISA's KEV entry of 2022-03-28 carrying knownRansomwareCampaignUse 'Known' and no public exploit artefact to build a signature from, the provenance-to-Protected-View path is the only control an operator can actually enforce on a machine that has not yet been updated and relaunched.",
         "gap_closes": [
           "AU-Essential-8-App-Hardening",
@@ -97405,7 +97405,7 @@
       {
         "id": "NEW-CTRL-144",
         "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
-        "description": "The packet names the affected product as Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the packet ties the CWE-1321 sink to Acrobat and Reader and provides no mapping from the vulnerable code into other PDF-handling software, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version — an estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. The packet registers no live-patch path, so each copy carries the service restart or system reboot the vendor fix requires, and a copy updated but not restarted is not yet remediated.",
+        "description": "Adobe Acrobat and Reader are the affected products, and on a real estate they are never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the vulnerable code is in Acrobat and Reader, and no evidence maps it into other PDF-handling software, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version. An estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. No live-patch path is available, so each copy must be updated to the fixed build.",
         "evidence": "CVE-2009-0927 is the dual-track problem in its plainest form: NVD gives one set of boundaries — 9 before 9.1, 8 before 8.1.3, 7 before 7.1.1 — that applies identically to Adobe Reader and Adobe Acrobat, two products that update independently on the same workstation. An estate that drives its inventoried Reader package to 9.1 and closes the KEV item opened 2022-03-25 still opens crafted PDFs into the Collab.getIcon sink through any Acrobat 9.0.x copy beside it. The restart half of the control applies with a correction specific to this product: the vendor fix needs no host reboot, but it is inert until Reader, Acrobat and any browser hosting the PDF plugin are relaunched, so the enumeration must confirm the running build rather than the installed one.",
         "gap_closes": [
           "UK-CAF-B4",
@@ -97500,7 +97500,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "phpMyAdmin gives the operator a configuration-side path that beats the vendor path on both speed and coverage, and CVE-2009-1151 is the case for inventorying it: deleting scripts/setup.php, setup/ and the /config/ directory removes the sink on any 2.11.x or 3.x build, works on a hosting-panel-bundled copy the operator cannot upgrade, and needs no coordination with a package maintainer. Exploit-DB 8921 records the /config/ directory as an explicit attack requirement, which is what makes its removal a real mitigation rather than a cosmetic one. Against EPSS 0.95438 on 2026-08-17 and a maintained Nuclei template that puts this CVE in default scan coverage, the mitigation has to be deployable on its own clock rather than behind the upgrade to 2.11.9.5 or 3.1.3.1.",
         "gap_closes": [
           "UK-CAF-B4",
@@ -98306,7 +98306,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "PHP published the configuration-side path itself in the 2012-05-03 news entry, before 5.3.12 and 5.4.2 existed: reject query strings that begin with '-' and contain no '=', in the Apache form 'RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]' plus 'RewriteRule ^(.*) $1? [L]', with Eindbazen's argv-stripping wrapper as an alternative. Both are deployable without touching the PHP build, and both would have held through the CVE-2012-2311 bypass that the 5.3.12 upgrade did not.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -101886,7 +101886,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "This Apache Tomcat entry has a configuration-side mitigation that is strictly stronger than the upgrade: restoring the Default servlet's readonly parameter to true removes HTTP PUT and the whole write path, on any 7.0.0-7.0.79 Windows instance, without moving off a branch Apache archived on 2021-03-31. An estate that can enumerate which instances have readonly=false can remediate the KEV entry CISA added 2022-03-25 in one configuration change; an estate that only tracks versions has to wait for an upgrade window on a dead branch.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -103558,7 +103558,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2019-11043 has exactly such a path: adding try_files $uri =404 or removing the anchored fastcgi_split_path_info in nginx removes the underflow reachability immediately, without waiting for the PHP 7.1.33/7.2.24/7.3.11 upgrade or the php-fpm master restart it requires.",
         "gap_closes": [
           "NIST-800-53-CM-7"
@@ -105628,7 +105628,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "This Sitecore RCE has exactly such a config-side path: KB1000776 lets 7.5-8.2 operators delete /sitecore/shell/ClientBin/Reporting/Report.ashx to neutralise the deserialization sink without the XP 9.0.0 upgrade, so that removal must be inventoried and deployable on its own track ahead of the version bump.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -107150,7 +107150,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "CVE-2021-21973 has exactly such a configuration-side path: VMware KB82374 sets the vROPS plugin to incompatible, neutralizing the getvcdetails SSRF without the vCenter upgrade window — critical because the fix (7.0 U1c / 6.7 U3l / 6.5 U3n) requires an appliance restart and the 6.5/6.7 lines are end-of-life. Inventorying and pre-testing that workaround is what lets an operator close this KEV item (added 2022-03-07, EPSS 0.876) immediately.",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -108414,7 +108414,7 @@
       {
         "id": "NEW-CTRL-025",
         "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
-        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path. Operators cannot wait for nginx 1.30.1+ if a named-capture refactor mitigates immediately.",
+        "description": "For any web-fabric vulnerability with a configuration-side mitigation path: that path must be inventoried, tested, and deployable independent of the vendor-patch path.",
         "evidence": "Apache Tomcat is the case this control describes exactly. Apache's own advisory text states that mitigation is only required if an AJP port is accessible to untrusted users, which means commenting out or loopback-binding the AJP/1.3 Connector in conf/server.xml removes the exposure with no upgrade at all — while the vendor-patch path to 9.0.31, 8.5.51 or 7.0.100 additionally requires configuration changes and a Tomcat process restart. With EPSS at 0.9927 on 2026-08-20 and Exploit-DB 48143 public since February 2020, the two-year gap between exploit publication and the 2022-03-03 KEV listing is exactly the window a configuration-side path exists to cover.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -108790,7 +108790,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "Microsoft's FAQ for this Excel CVE settles that the delivery path is the whole exploitation cost: it states that exploitation requires a user to open a specially crafted file with an affected version of Excel and that the Preview Pane is not an attack vector. That makes Protected View the boundary that matters, and the control's spreadsheet-in-a-ZIP test is the right one for this defect because the affected population is wide — Excel 2010 SP2 through Excel 2016, Office 2016 and 2019 for Mac, Office 2019 and Office 365 ProPlus — and includes builds now past end of support where no further Office patch will arrive at all. The memory-handling defect itself is inside Excel; provenance enforcement is what keeps an untrusted file from reaching it at full user privilege.",
         "gap_closes": [
           "AU-Essential-8-App-Hardening",
@@ -110363,7 +110363,7 @@
       {
         "id": "NEW-CTRL-077",
         "name": "SECURITY-AGENT-ENGINE-CURRENCY-AUDIT",
-        "description": "Treat the EDR/AV agent's own engine/platform build as a first-class, audited remediation target: verify (not assume) that the deployed Microsoft Defender Malware Protection Engine is >= the fixed build (1.1.26040.8 for CVE-2026-41091) on every endpoint, and alarm on hosts whose engine build lags despite an auto-update policy. A SYSTEM-privileged security agent's flaws are LPE-to-SYSTEM by construction.",
+        "description": "Treat the EDR/AV agent's own engine/platform build as a first-class, audited remediation target: verify (not assume) that the deployed Microsoft Defender Malware Protection Engine is at or above the fixed build on every endpoint, and alarm on hosts whose engine build lags despite an auto-update policy. A SYSTEM-privileged security agent's flaws are LPE-to-SYSTEM by construction.",
         "evidence": "The control names the measurement this CVE needs, with a different fixed build: for CVE-2017-8540 the audited threshold is Malware Protection Engine 1.1.13704.0, against 1.1.13701.0 as the last affected version, on the Forefront and Defender installs NVD scopes to Windows 7 SP1 through Windows 10 1703, Windows Server 2008 SP2 through 2016, and Exchange Server 2013 and 2016. The 'verify, not assume' half is load-bearing because the engine updates automatically by default, which is exactly the assumption that lets a host with a broken or filtered definition path sit below the fixed build while its auto-update policy reports as applied.",
         "gap_closes": [
           "NIST-800-53-SI-3",
@@ -112072,7 +112072,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "CVE-2017-11826 is CWE-119 rather than the CWE-94 sink the control's text describes, and the provenance argument transfers exactly because the failure is in parsing rather than in a feature the user enables. Qihoo 360 found this Microsoft Word flaw exploited in the wild in the month before the 10 October 2017 patch, and the container nesting in the analysed sample - an RTF carrying Word.Document.12 compound-document objects that hold the OOXML - is precisely the provenance-stripping shape the control's survive-the-container clause addresses. Protected View is the one measure that puts the corrupting parse in a reduced-privilege render instead of the opening user's own context, and it is the only thing that would have applied during the zero-day window when no patch and no signature existed. The control's caveat about macro and ActiveX/OLE attestations is literally the failure here: those settings govern decision points this exploit never reaches.",
         "gap_closes": [
           "AU-Essential-8-App-Hardening",
@@ -112162,7 +112162,7 @@
       {
         "id": "NEW-CTRL-122",
         "name": "EOL-ASSET-DECOMMISSION",
-        "description": "This entry is the case the control exists for, and both halves are documented here. patch_available is true — a fixed build carrying this JavaScriptCore fix exists — and the vector itself states that the impacted product could be end-of-life and/or end-of-service and that users should discontinue product utilization. Those facts together define the requirement: on a unit whose hardware can still take an Apple security update, reaching the fixed build is an interim state; on a unit that can no longer take one, the terminal state is removal or replacement, because that device is exposed not only to this code-execution flaw but to everything found in that engine since its last build. Scope to what the packet names — macOS, iOS, tvOS, Safari and watchOS — and inventory those. The packet ties the CWE-94 sink to JavaScriptCore in those products and gives no mapping into other vendors' browsers or other software that embeds a web engine, so treating every renderer in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. In operational terms: enumerate every macOS, iOS, tvOS, watchOS and Safari install that renders untrusted web content, record for each whether its hardware can still receive a build carrying the fix, put those on the interim clock against the 2025-10-20 KEV listing, and put the rest on a dated replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: live_patch_available is false and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a device that downloaded the update but has not restarted still runs the vulnerable code and is not remediated. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "description": "Software with no vendor patch path must be isolated and decommissioned within a bounded window; mandatory compensating configuration applies until removal.",
         "evidence": "The control's structure fits this Adobe Flash Player entry with the vendor and engine changed and one difference that makes it stricter. Both halves hold: a fixed build exists - Adobe shipped 27.0.0.170 across every Flash Player line in APSB17-32 on 16 October 2017 - and CISA's required action states the impacted product is end-of-life and should be disconnected if still in use. The difference is that Flash Player has no interim half left for anyone. Where the control lets hardware that can still take an update sit at the fixed build as an interim state, Adobe stopped supporting Flash Player on 31 December 2020 and blocked Flash content from running on 12 January 2021, so every remaining install is in the terminal category regardless of the host it runs on, and removal is the only end state. Scope the inventory the way the control demands - to the products the record actually names: Flash Player Desktop Runtime on Windows, macOS and Linux, and the copies embedded in Google Chrome and in Microsoft Edge and Internet Explorer 11, which arrived through the browser's update channel and are missing from a standalone-installer inventory. Adobe AIR is a separate product line not covered by APSB17-32, and sweeping it in on the strength of a shared vendor name manufactures replacement work against software this record does not implicate. Because exploitation is confirmed - Kaspersky attributes it to BlackOasis delivering FinSpy - a host that opened untrusted Office documents while exposed belongs on the incident path rather than being closed on the uninstall record.",
         "gap_closes": [
           "NIST-800-53-CM-7",
@@ -112614,7 +112614,7 @@
       {
         "id": "NEW-CTRL-120",
         "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
-        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink at the user's own process privilege. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — a user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
+        "description": "Exploitation here requires the victim to open an attacker-supplied Office document, so on an estate that has not yet reached the fixed build the delivery path is the only enforceable control. Require Mark-of-the-Web on every Office file arriving by mail, web download, or untrusted file share, and require MOTW-tagged documents to open in Protected View (an isolated, reduced-privilege render) instead of the full parsing path. Provenance must survive the container: files extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced documents must be blocked by policy rather than left to the user. The distinguishing test: mail a MOTW-tagged spreadsheet nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View. A user-application-hardening attestation that covers only macro and ActiveX/OLE settings still lets a provenance-stripped document reach the vulnerable parser with full user privileges.",
         "evidence": "This CVE needs the victim to leave the read-only render and interact with the workbook — Microsoft's own account is that the attacker must convince the user to open the document file and interact with it by clicking on a specific cell — so whether an externally sourced spreadsheet reaches an editable Excel session is the whole of the operator-side lever before the MS16-148 updates land. The control's provenance-survives-the-container requirement is the load-bearing half for a spreadsheet delivered inside an archive, and its Enable Editing clause addresses the exact step the exploit depends on.",
         "gap_closes": [
           "UK-CAF-B4",
@@ -124444,7 +124444,7 @@
       {
         "id": "NEW-CTRL-131",
         "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
-        "description": "FortiOS and FortiProxy are the authentication enforcement point for the perimeter, so an authentication bypass on them is not an appliance-patch-window item — it is the enforcement point failing open. There is a vendor patch with no live-patch path and a restart-or-reboot requirement, so the expedited clock has to run from the 2026-01-27 KEV listing through the reboot of every affected FortiAnalyzer, FortiManager, FortiOS and FortiProxy unit. Because the packet names FortiCloud SSO authentication being enabled on the device as the condition under which the bypass works, interim exposure is bounded by enumerating which units have that path enabled and restricting reachability of their administrative surfaces until the reboot completes.",
+        "description": "A remote-access gateway is itself the authentication enforcement point for the network edge, so a credential-exposing or authentication-bypassing flaw on it is remediated on a listing-tied expedited clock and every reachable authentication surface is enumerated first.",
         "evidence": "This is the SSL-VPN-portal case the control names. The flaw is reachable with no credential at all, and its product is a credential the attacker chose for an account that already exists — so the control's distinguishing test lands exactly: on a staging device running 5.4.10, 5.6.8, 6.0.4 or FortiProxy below 1.2.9, POST to /remote/logincheck with a `magic` parameter and confirm no password is written and no session follows. The control's enumeration half is the load-bearing half here, because the affected population is defined by SSL VPN portals being enabled rather than by device model, and DEVCORE identified those portals from the internet by the /remote/login URL alone. Where the control says restrict exposure to known client networks, that is also the only interim measure available on this flaw: there is no vendor mitigation rule to deploy and no live patch, so the choice before the reboot window is reachability or nothing. One precondition the control does not carry and this CVE needs: applying the fixed build does not revoke a password the flaw already set, so expedited remediation here is upgrade plus credential rotation, not upgrade alone.",
         "gap_closes": [
           "NIST-800-53-IA-2"
@@ -125471,7 +125471,7 @@
       {
         "id": "NEW-CTRL-078",
         "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
-        "description": "Treat the EDR/endpoint-management server's agent-deployment channel (package/key-table → agent push) as a privileged supply-chain control plane: integrity-monitor the deployment artifacts and key tables, alert on agent pushes not tied to a sanctioned admin action, and patch the management server to the fixed build (Apex One on-prem 14.0.0.17079 / SaaS 14.0.20731) as a KEV-priority item. A server foothold must not silently become fleet-wide agent code execution.",
+        "description": "Treat the EDR/endpoint-management server's agent-deployment channel (package/key-table → agent push) as a privileged supply-chain control plane: integrity-monitor the deployment artifacts and key tables, alert on agent pushes not tied to a sanctioned admin action, and patch the management server to the fixed build as a KEV-priority item. A server foothold must not silently become fleet-wide agent code execution.",
         "evidence": "The control names the exact escalation this CVE enables. Code execution on the Desktop Central server is not confined to that host, because the server's sanctioned function is distributing software and configuration to every managed endpoint — so a single unauthenticated request converts into a signed, expected, fleet-wide delivery channel, and on MSP builds one that crosses customer boundaries. The operator-side requirement is the second clause: alert on agent pushes and package changes that do not correspond to a sanctioned administrator action, with the record held off the management server, since a compromised control plane is not a trustworthy reporter about its own deployments. The build that carries the fix on this product is Desktop Central 10.1.2127.18 or 10.1.2137.3, depending on the installed range, for both the Enterprise and MSP editions.",
         "gap_closes": [
           "UK-CAF-B2"
@@ -132354,7 +132354,7 @@
       {
         "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
+        "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes the KEV-listed flaw, and constrain installation of untrusted/side-loaded apps on devices that cannot yet update, since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below that patch level and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard). Paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "The fixed Mali driver reaches a handset only inside a manufacturer firmware build, and the artefact the fleet can read is the Android security patch level — 2021-05-05 or later for this CVE, per the May 2021 Android Security Bulletin. Enforcement rather than reporting is the whole control here, because the update depends on a third party the organisation does not control: a dashboard that records stale patch levels leaves exploitable handsets in production indefinitely, since there is no follow-up action the operator can take against the manufacturer. The distinguishing test is to enrol a device pinned below 2021-05-05 and confirm the policy denies it access to protected resources. The second clause matters too: for handsets that cannot yet update, constrain installation to managed application channels, because the flaw requires locally running code. The date to enforce for this CVE is 2021-05-05 and no other: the shared control text carries a different level as its worked example, and a policy built from that example rather than from this entry admits every handset this CVE affects.",
         "gap_closes": [
           "NIS2-Art21-patch-management"