@blamejs/exceptd-skills 0.19.16 → 0.19.18

package/data/zeroday-lessons.json

@@ -1,7 +1,7 @@
 {
   "_meta": {
     "schema_version": "1.1.0",
-    "last_updated": "2026-08-10",
+    "last_updated": "2026-08-11",
     "last_threat_review": "2026-05-17",
     "purpose": "Zero-day learning loop output. Each entry maps a CVE to: attack vector, defense chain analysis, framework coverage, new control requirements generated, and exposure scoring. v1.1.0 (2026-05-15): every entry now carries ai_discovered_zeroday boolean + ai_discovery_source enum + ai_discovery_date + ai_assist_factor ladder, per AGENTS.md Hard Rule #7.",
     "note": "Never delete entries. Closed gaps are marked status: closed. History is data.",
@@ -19620,7 +19620,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "FortiWeb is a web application firewall — the device is deployed as the protective control on the perimeter trust boundary, and this CVE puts OS command execution (CWE-78) on that device's own operating system. For this product the SLA tier means the vendor build is driven onto every Fortinet FortiWeb unit on the clock that opened with the 2025-11-18 KEV listing, not folded into the appliance-firmware maintenance window, and completion is measured by the build each unit is actually running after its restart rather than by 'update staged' or 'approved' in the management console: the packet records patch_required_reboot as true, live_patch_available as false, and states that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a unit carrying the new image but not yet restarted is still executing the vulnerable code and must be counted as exposed. Scope the sweep from the packet's affected fields, which name Fortinet FortiWeb and give no build numbers — 'versions per vendor advisory' — so the inventory is every FortiWeb unit in service and the fixed build for each has to be read off the vendor advisory rather than assumed from a version that merely looks newer. Precondition on the isolation half of this control, which is where it is normally over-claimed: restricting reachability of the administrative and CLI surfaces bounds one of the two delivery paths the packet's vector names, but the other is crafted HTTP requests, and serving HTTP traffic is the entire reason a FortiWeb is deployed — that surface cannot be withdrawn without removing the device's function. Isolation is therefore a holding measure that narrows who can reach the CLI path during the window before the restart lands; it is not a closure, and a unit whose HTTP surface stays in service stays reachable by the path the vector describes.",
+        "evidence": "Packet: 'Fortinet FortiWeb contains an OS command Injection vulnerability that may allow an authenticated attacker to execute unauthorized code on the underlying system via crafted HTTP requests or CLI commands'; CWE-78; cisa_kev true with kev_date 2025-11-18; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 77; patch_available true; patch_required_reboot true; live_patch_available false with live_patch_notes '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.'; affected/affected_versions give 'Fortinet FortiWeb — versions per vendor advisory'. The entry's own AU-Essential-8-Patch gap records that the Essential-Eight cadence for internet-facing appliances trails the KEV due date here, and the UK-CAF-B4 gap records that CAF expectations do not isolate the management surface of a WAF appliance.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Applied to FortiWeb, this is the control that decides what happens to a unit that was in service before its restart on the fixed build. Reaching that build stops re-exploitation; it says nothing about what already ran, because the packet's primitive is execution of unauthorized code on the appliance's underlying system — not a crash, not a config change the appliance would log as such. The default response for any FortiWeb unit reachable during the window that opened with the 2025-11-18 KEV listing is therefore configuration capture for analysis, rebuild from vendor media, and rotation of every credential the unit held, rather than patch-in-place. This is also why the least-privilege gap recorded on this entry does not contain the outcome: the packet's vector describes an authenticated attacker, and the entry's UK-CAF-B4 gap notes the flaw is readily chained with a preceding auth bypass, so per-account privilege scoping on the appliance is not the boundary that held — any credential valid on the unit during the exposure window has to be treated as attacker-known regardless of how narrowly it was scoped. Precondition, and it is the one that usually voids this control in practice: a rebuild seeded from the compromised unit's own configuration backup reinstates whatever the attacker changed on it. The saved configuration is evidence to be diffed against a known-good baseline, not the source to restore from. And the decision has to be pre-made in the runbook — with confirmed exploitation and a public PoC on this entry, the question 'was this unit exploited before we patched it' arrives after the patch window has closed, at which point the fastest available answer is the on-box state the exploit already had authority over.",
+        "evidence": "Packet vector: an attacker may 'execute unauthorized code on the underlying system'; active_exploitation 'confirmed'; cisa_kev true, kev_date 2025-11-18; poc_available true; RWEP 77; CVSS 9.8. The entry's NIS2-Art21-network-security gap states that an OS command injection reachable post-authentication 'turns the web-application firewall into an execution host on the network it guards'; its UK-CAF-B4 gap states the flaw is 'readily chained with a preceding auth bypass'; its NIST-800-53-AC-6 gap states that least-privilege presumes a working authentication/authorization boundary and that the exploit demonstrates the boundary is breakable from a baseline context.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "For FortiWeb the requirement is that the appliance's traffic, administrative and authentication, and system logs are forwarded to a collector in a different trust zone — different management plane, different credentials, different authentication path — with retention covering the period from before the 2025-11-18 KEV listing through each unit's restart on the fixed build. The reason is specific to this CVE's primitive rather than generic log hygiene: the packet's vector puts command execution on the appliance's own underlying system, so whatever the FortiWeb recorded about the crafted HTTP request or CLI command that triggered it is held at the same level of authority the exploit grants. On-box telemetry about this exploitation path cannot be treated as an independent record of it. Off-box telemetry is also the input the rebuild-or-patch decision above depends on — without it an operator has no basis for answering whether a unit was hit, and the default becomes patch-in-place by absence of evidence rather than by finding. Precondition: this control only produces value if the forwarding was already in place before the exposure window. A collector configured in response to the KEV listing returns nothing about the period that matters, and it prevents no exploitation at all — what it does is make the claim that the WAF is still a trusted protective control falsifiable rather than assumed.",
+        "evidence": "Packet: OS command injection (CWE-78) allowing an attacker to 'execute unauthorized code on the underlying system via crafted HTTP requests or CLI commands'; active_exploitation 'confirmed'; cisa_kev true, kev_date 2025-11-18; poc_available true. The entry's NIS2-Art21-network-security gap records that network-security duties 'assume the FortiWeb WAF is a trusted protective control' while the flaw turns it into an execution host on the network it guards.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-64446": {
     "name": "Fortinet FortiWeb Path Traversal Vulnerability",
@@ -20101,269 +20134,301 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
-  },
-  "CVE-2025-11371": {
-    "name": "Gladinet CentreStack and Triofox Files or Directories Accessible to External Parties Vulnerability",
-    "lesson_date": "2026-05-29",
-    "attack_vector": {
-      "description": "a files-or-directories-accessible-to-external-parties flaw (CWE-552) disclosing server files including the machine key, enabling a follow-on deserialization remote code execution. CISA KEV-listed 2025-11-04 with confirmed in-the-wild exploitation.",
-      "privileges_required": "none (the flaw is reachable by an unauthenticated attacker on the application's public interface)",
-      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
-      "ai_factor": "No AI involvement documented in discovery or weaponization."
-    },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Apply the Gladinet CentreStack/Triofox update AND rotate the machine key — the disclosure leaks the key that enables the deserialization RCE, so patching without key rotation leaves the RCE path open.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
-        "adequacy": "Patch is necessary but insufficient alone — forged tokens / leaked keys survive the patch and require explicit key rotation."
-      },
-      "detection": {
-        "what_would_have_worked": "Monitoring on the CentreStack/Triofox: exploit-shaped requests, new web-shell files, unexpected process execution, and authentication/authorization events with no matching legitimate session or with forged key material.",
-        "was_this_required": false,
-        "framework_requiring_it": null,
-        "adequacy": "Necessary to catch resident persistence and key abuse after patching."
-      },
-      "response": {
-        "what_would_have_worked": "Patch immediately, rotate the affected cryptographic/machine keys, rotate application secrets and credentials, and review data and downstream systems reachable from the CentreStack/Triofox; assume compromise of accounts and managed endpoints in its reach.",
-        "was_this_required": true,
-        "framework_requiring_it": "NIST 800-53 IR-4",
-        "adequacy": "Mandatory; patch-in-place without key rotation / web-shell hunting leaves the attacker resident or able to re-authenticate."
-      }
-    },
-    "framework_coverage": {
-      "NIST-800-53-SI-2": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, unauthenticated server-side application RCE/auth-bypass; these are mass-exploited within days, and RMM/file-sharing compromise reaches downstream systems."
-      },
-      "ISO-27001-2022-A.8.8": {
-        "covered": true,
-        "adequate": false,
-        "gap": "'Appropriate timescales' is undefined; the standard 30-day reading is unsafe for an actively-exploited, internet-facing enterprise application."
-      },
-      "NIS2-Art21-network-security": {
-        "covered": true,
-        "adequate": false,
-        "gap": "Treats internet-facing enterprise applications as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA, and does not require the web-shell-hunt / key-rotation cleanup these RCEs and key-disclosure flaws need."
-      },
-      "PCI-DSS-4.0-6.3.3": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day critical-patch window is exploitation acceptance for an internet-facing enterprise application in or adjacent to the CDE; WAF coverage is partial mitigation, not remediation."
-      }
-    },
-    "compliance_exposure_score": {
-      "percent_audit_passing_orgs_still_exposed": 76,
-      "basis": "Internet-facing Gladinet CentreStack and Triofox is run by audited organizations on a standard patch SLA and is mass-exploited within days; the required web-shell hunt and key rotation are rarely part of the documented patch procedure, and RMM/file-sharing/MES reach amplifies the blast radius.",
-      "theater_pattern": "patch_management"
-    },
-    "ai_discovered_zeroday": false,
-    "ai_discovery_source": "vendor_research",
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-001",
-        "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "Gladinet CentreStack and Triofox are the remote file-access tier, so the clock on this entry has to start at the KEV listing rather than at the next maintenance window: the packet's chain is disclosure of server files including the machine key feeding a follow-on deserialization remote code execution, which means an unpatched hour is a full-server-takeover window, not a file-disclosure window. A vendor patch exists and is the mitigation path; because the packet records no live-patch tool for this entry and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, the restart itself must be pre-authorized inside the SLA instead of being deferred to a change board. Any instance that cannot take the restart inside the window needs documented compensating controls (removing untrusted reach to the disclosing path) recorded as the SLA outcome, not an open exception.",
-        "evidence": "CISA KEV-listed 2025-11-04 with active_exploitation confirmed; RWEP 77, CVSS 8.8, poc_available true; patch_available true, live_patch_available false with the packet's note that no live-patch tool is registered for this entry and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "CWP Control Web Panel is the constrained user surface this control governs, and the packet places the defect exactly where the control forbids it: shell metacharacters supplied in the t_total parameter of a filemanager changePerm request reach a shell, so a request-supplied string on the panel's file-manager surface is what selects the command the server runs. Bound to this product the control means the panel's privileged filesystem operations — changing permissions on a hosted account's files is one of them — sit behind their own authorization boundary and are invoked through an argv-array interface, so no parameter of a file-manager request can extend the command line, and the panel authorizes the caller before the operation runs rather than relying on a check the request path reaches afterwards. This is also why the least-privilege gap recorded on this entry does not close the path: the packet's stated access requirement is knowing a valid non-root username, not holding that user's session, so the attacker never authenticates as any panel account, per-account privilege scoping is never consulted, and an AC-6 attestation passes cleanly while an unauthenticated caller reaches the shell. Distinguishing test: from an unauthenticated client against a staging CWP instance, send a filemanager changePerm request whose t_total value carries shell metacharacters and confirm it is refused before any command runs. Precondition: the vendor update is what repairs the endpoint — this control states the property to verify, it does not implement it. Until that update and its restart land, restricting which networks may reach the panel's web surface bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted range, and it is unavailable where the panel must stay reachable for hosted-account administration.",
+        "evidence": "Packet vector: 'CWP Control Web Panel (formerly CentOS Web Panel) contains an OS command Injection vulnerability that allows unauthenticated remote code execution via shell metacharacters in the t_total parameter in a filemanager changePerm request. A valid non-root username must be known.' CWE-78. CISA KEV listed 2025-11-04; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. NIST SP 800-53 AC-6 (Least Privilege) is recorded among this entry's citing framework gaps. patch_available true, live_patch_available false, live_patch_notes: '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.'",
         "gap_closes": [
-          "AU-Essential-8-Patch",
-          "ISO-27001-2022-A.8.8",
-          "NIST-800-53-SI-2"
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
         ]
       },
       {
         "id": "NEW-CTRL-032",
         "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
-        "description": "For a CentreStack or Triofox instance that was reachable while unpatched, installing the vendor update closes the CWE-552 read path but does nothing about what the packet says the read path already handed over: server files including the machine key, which is precisely the material that makes the follow-on deserialization code execution work. The response for an exposed instance must therefore default to treating the disclosed configuration and machine key as attacker-held — rotate that cryptographic material and any credentials stored on the host, and rebuild rather than patch in place — because the same disclosure that leaks the key also gives an operator no way to prove no implant was planted during the exposure window. Patch-only remediation on this CVE produces a host that reports 'remediated' while the attacker still holds a valid key for the deserialization path.",
-        "evidence": "The packet's attack vector: a files-or-directories-accessible-to-external-parties flaw (CWE-552) disclosing server files including the machine key, enabling a follow-on deserialization remote code execution; active_exploitation confirmed and KEV-listed 2025-11-04, with poc_available true.",
-        "gap_closes": [
-          "NIST-800-53-SI-2",
-          "UK-CAF-B4"
-        ]
-      }
-    ]
-  },
-  "CVE-2025-41244": {
-    "name": "Broadcom VMware Aria Operations and VMware Tools Privilege Defined with Unsafe Actions Vulnerability",
-    "lesson_date": "2026-05-29",
-    "attack_vector": {
-      "description": "a privilege-management flaw (CWE-267) in VMware Aria Operations and VMware Tools, letting a local user in a managed guest escalate privileges. CISA KEV-listed 2025-10-30 with confirmed in-the-wild exploitation; escalation flaws of this class form the second half of an intrusion chain.",
-      "privileges_required": "low (a local foothold — an unprivileged app, user, or process on the host)",
-      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
-      "ai_factor": "No AI involvement documented in discovery or weaponization."
-    },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Apply the VMware update; restrict the privileged collection account and segment management access — a guest LPE combined with management reach can pivot across the virtual estate.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
-        "adequacy": "Patch is definitive; the gap is the chain (initial access → unpatched LPE → root/SYSTEM) which a patched host shuts down, with platform hardening as the backstop."
-      },
-      "detection": {
-        "what_would_have_worked": "EDR/auditd telemetry for unprivileged-to-elevated transitions and the escalation primitive without a legitimate trigger.",
-        "was_this_required": false,
-        "framework_requiring_it": null,
-        "adequacy": "Backstops unpatched hosts; escalation is typically silent without endpoint/identity monitoring."
-      },
-      "response": {
-        "what_would_have_worked": "Force the patch; for confirmed exploitation treat the host as compromised, isolate, preserve forensic state, rotate credentials, and review for follow-on persistence.",
-        "was_this_required": true,
-        "framework_requiring_it": "NIST 800-53 IR-4",
-        "adequacy": "Mandatory; root/SYSTEM-level escalation makes the host an unreliable platform and warrants rebuild."
-      }
-    },
-    "framework_coverage": {
-      "NIST-800-53-SI-2": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed local/host privilege-escalation flaw; paired with an initial-access primitive, attackers elevate to root/SYSTEM within hours of a foothold."
-      },
-      "ISO-27001-2022-A.8.8": {
-        "covered": true,
-        "adequate": false,
-        "gap": "'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited escalation flaw, which is the second half of nearly every intrusion chain."
-      },
-      "AU-ISM-1546": {
-        "covered": true,
-        "adequate": false,
-        "gap": "Essential 8 names OS/application patching, but the load-bearing backstops are platform-specific and unnamed: least-privilege and SELinux/seccomp on Linux, MDM-enforced OTA SLAs on Android, management-account segmentation for virtualization, and SMB signing / NTLM-disablement for the reflection class (the last breaks the attack regardless of patch state)."
-      }
-    },
-    "compliance_exposure_score": {
-      "percent_audit_passing_orgs_still_exposed": 69,
-      "basis": "VMware Aria Operations and VMware Tools is widely deployed; audited organizations gate host/agent patches behind change windows and rarely enforce the platform-specific backstop (SELinux/seccomp, MDM OTA SLA, management-account segmentation, SMB signing), leaving the escalation chain open past the in-the-wild window.",
-      "theater_pattern": "patch_management"
-    },
-    "ai_discovered_zeroday": false,
-    "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none",
-    "new_control_requirements": [
-      {
-        "id": "NEW-CTRL-145",
-        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
-        "description": "The packet's vector has a malicious local actor with non-administrative privileges escalating to root on the same VM, through VMware Tools and Aria Operations rather than through anything the guest's own account model governs. For this entry the control means the fixed VMware Tools and Aria Operations builds are driven across every managed guest on the clock that opened with the 2025-10-30 KEV listing, and that completion is measured per guest by the VMware Tools build actually installed and the Aria Operations version actually running — not by 'update approved' or 'package pushed' in the management console, and not by a hypervisor-level rollup that reports host currency while guests lag. Because the packet records patch_available true, live_patch_available false, and live_patch_notes stating no live-patch tool with a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, a guest that has received the update but not restarted the affected components still carries the vulnerable path and has to be counted as exposed. The second half of the control is the load-bearing half here and is why NIST-800-53-AC-6 is cited as insufficient on this entry: the attacker is already a legitimate, non-administrative local user, so removing administrative rights from ordinary guest accounts — the thing a least-privilege attestation measures — does not stand between that account and root. Distinguishing test: on a staging guest running the same VMware Tools version, managed by Aria Operations with SDMP enabled, attempt the escalation from an ordinary non-administrative account and confirm root is not reached; then report fleet coverage as guests at the fixed build post-restart. A least-privilege attestation and a 'patch compliance' percentage both pass while this path stays open.",
-        "evidence": "Packet fields for CVE-2025-41244 (Broadcom VMware Aria Operations and VMware Tools Privilege Defined with Unsafe Actions Vulnerability): cwe_refs CWE-267; vector 'A malicious local actor with non-administrative privileges having access to a VM with VMware Tools installed and managed by Aria Operations with SDMP enabled may exploit this vulnerability to escalate privileges to root on the same VM'; cisa_kev true with kev_date 2025-10-30; active_exploitation confirmed; poc_available true; cvss 8.8; rwep_score 77; patch_available true; live_patch_available false; live_patch_notes '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.' Citing gaps recorded on this entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2 and NIST-800-53-AC-6.",
+        "description": "A CWP server answers unauthenticated callers by design and the packet's path ends in command execution on it, so the control's premise holds here without any appliance framing: the exploit needs no credential, only a known non-root username, and the packet records a public PoC with confirmed in-the-wild exploitation. Any instance that was reachable by untrusted callers before the update landed therefore has to be treated as one that may already have run attacker commands. For this product the runbook is to capture the panel and server configuration and the hosted-account inventory, rebuild the host from a known-good image, and rotate everything the panel held or could reach — panel administrator credentials, hosted-account and database passwords, and any API keys stored on it — rather than applying the update in place. Patch-in-place closes the changePerm injection and removes nothing written through it: a web shell under a hosted document root, an added cron entry, or an attacker-created account survives the upgrade intact, and none of those are what a build-version check inspects. Precondition: this is the response for an instance whose reachable window overlapped the exploitation the packet records; an instance that can be shown to have been unreachable by untrusted callers throughout is a straightforward patch item. Either way the packet registers no live-patch path, so the vendor fix carries the service restart or system reboot, and a server updated but not restarted is not yet remediated.",
+        "evidence": "Packet attack vector: 'an OS command-injection flaw (CWE-78) enabling unauthenticated remote command execution on the hosting-control server. CISA KEV-listed 2025-11-04 with confirmed in-the-wild exploitation.' Vector states exploitation requires only that 'A valid non-root username must be known.' active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. patch_available true, live_patch_available false, live_patch_notes: '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.'",
         "gap_closes": [
-          "AU-Essential-8-Patch",
           "ISO-27001-2022-A.8.8",
-          "NIS2-Art21-patch-management",
-          "NIST-800-53-SI-2",
-          "NIST-800-53-AC-6"
-        ]
-      },
-      {
-        "id": "NEW-CTRL-135",
-        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
-        "description": "CWE-267 (privilege defined with unsafe actions) plus a vector in which a non-administrative local account reaches root on the same VM is this control's pattern: an operation that carries root authority inside the managed guest is reachable from an account that holds no administrative privilege, so the only thing standing between an ordinary guest user and root is the correctness of that privileged path. Bound to this product, the control means the privileged work that Aria Operations and VMware Tools perform inside a guest authorizes what it acts on for itself, at its own boundary, instead of inheriting trust from the fact that the request or the state originated inside the guest it manages — and that this property is verified on the managed-guest configuration the packet names, not assumed from the guest OS's account model. Preconditions, stated plainly: the vendor update is what repairs the boundary — this control states the property to verify, it does not implement it. Until that update is installed and the affected components restarted (the packet records no live-patch path and a restart-or-reboot requirement), the only operator-side lever is the exploit condition the packet itself names — a VM with VMware Tools installed, managed by Aria Operations, with SDMP enabled — so guests outside that configuration are not in the described condition, but where SDMP is operationally required nothing short of the update closes the path, and changing that setting does not evict an attacker who already reached root or remove what root access created on a guest that was in the vulnerable configuration during the exposure window (active_exploitation is confirmed and a PoC is public). Distinguishing test: enumerate which guests are managed with SDMP enabled and, on a staging guest matching that configuration, confirm a non-administrative local account cannot drive the privileged path to root — an attestation that no ordinary guest user holds administrative rights never tests this path.",
-        "evidence": "Packet fields for CVE-2025-41244: cwe_refs CWE-267 ('Privilege Defined with Unsafe Actions' per the entry name); vector names the exploit condition as a VM 'with VMware Tools installed and managed by Aria Operations with SDMP enabled' and the outcome as escalation 'to root on the same VM' by 'a malicious local actor with non-administrative privileges'; attack_vector adds that escalation flaws of this class form the second half of an intrusion chain; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-10-30; patch_available true; live_patch_available false with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include NIST-800-53-AC-6 and UK-CAF-B4.",
-        "gap_closes": [
-          "NIST-800-53-AC-6",
-          "UK-CAF-B4"
+          "NIS2-Art21-vulnerability-management"
         ]
-      }
-    ]
-  },
-  "CVE-2025-24893": {
-    "name": "XWiki Platform Eval Injection Vulnerability",
-    "lesson_date": "2026-05-29",
-    "attack_vector": {
-      "description": "an eval-injection flaw (CWE-95) in XWiki Platform, enabling unauthenticated remote code execution via a crafted document or search request. CISA KEV-listed 2025-10-30 with confirmed in-the-wild exploitation.",
-      "privileges_required": "none (the flaw is reachable by an unauthenticated attacker on the application's public interface)",
-      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
-      "ai_factor": "No AI involvement documented in discovery or weaponization."
-    },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Apply the XWiki update; hunt for web shells and rotate credentials — wiki RCE is routinely used to deploy cryptominers and backdoors.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
-        "adequacy": "Patch is necessary but insufficient alone — web shells and stolen credentials survive the patch; framework-level flaws require updating every consumer."
-      },
-      "detection": {
-        "what_would_have_worked": "Monitoring on the XWiki: exploit-shaped requests, new web-shell files and unexpected child-process execution.",
-        "was_this_required": false,
-        "framework_requiring_it": null,
-        "adequacy": "Necessary to catch exploitation and resident persistence after patching."
-      },
-      "response": {
-        "what_would_have_worked": "Patch immediately, hunt and remove web shells, rotate application secrets/credentials, and review for lateral movement; for a compromised monitoring server (Wazuh) assume detection was blinded during the window.",
-        "was_this_required": true,
-        "framework_requiring_it": "NIST 800-53 IR-4",
-        "adequacy": "Mandatory; patch-in-place without cleanup leaves the attacker resident or with a usable internal-access pivot."
-      }
-    },
-    "framework_coverage": {
-      "NIST-800-53-SI-2": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, unauthenticated server-side flaw that processes untrusted data; deserialization/eval RCE and SSRF/XXE chains are mass-exploited within days."
-      },
-      "ISO-27001-2022-A.8.8": {
-        "covered": true,
-        "adequate": false,
-        "gap": "'Appropriate timescales' is undefined; the standard 30-day reading is unsafe for an actively-exploited, internet-facing application — and framework-level flaws (React Server Components) require updating every consumer."
-      },
-      "NIS2-Art21-network-security": {
-        "covered": true,
-        "adequate": false,
-        "gap": "Treats internet-facing applications as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA, and does not require the web-shell-hunt / secret-rotation / egress-restriction cleanup these flaws need — a compromised SIEM (Wazuh) additionally blinds the detection the framework assumes."
       },
-      "PCI-DSS-4.0-6.3.3": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day critical-patch window is exploitation acceptance for an internet-facing application in or adjacent to the CDE (SAP/Oracle EBS sit adjacent to financial data); WAF coverage is partial mitigation, not remediation."
-      }
-    },
-    "compliance_exposure_score": {
-      "percent_audit_passing_orgs_still_exposed": 75,
-      "basis": "Internet-facing XWiki Platform is run by audited organizations on a standard patch SLA and is mass-exploited within days; the required web-shell hunt, secret rotation, or egress/XXE hardening is rarely part of the documented patch procedure.",
-      "theater_pattern": "patch_management"
-    },
-    "ai_discovered_zeroday": false,
-    "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none",
-    "new_control_requirements": [
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "XWiki's exposure here has no authentication gate to slow it down — the packet records that any guest can reach the eval-injection sink through a SolrSearch request and obtain arbitrary remote code execution — so every hour between KEV listing and deployment of the fixed build is an hour any reachable instance is exploitable by an unauthenticated caller against whom a PoC already exists. The packet records no live-patch path and a fix that typically requires a service restart or system reboot, so meeting the clock means scheduling that restart on the wiki, not deferring it to the next routine window. The SLA must name the XWiki application as its own tracked asset: self-hosted collaboration platforms are commonly patched on a separate cadence from the operating system of the host they run on, and an OS-patching attestation says nothing about the wiki's build.",
-        "evidence": "Packet: XWiki Platform, CWE-95 eval injection; vector 'XWiki Platform contains an eval injection vulnerability that could allow any guest to perform arbitrary remote code execution through a request to SolrSearch'; CISA KEV-listed 2025-10-30 with active_exploitation 'confirmed'; RWEP 77 / CVSS 9.8; poc_available true; patch_available true; live_patch_available false, with live_patch_notes '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.'",
+        "description": "CWP ships and updates on its own vendor channel, so a remediation programme whose patch obligation is written as operating-system patching never schedules this update at all — the host's OS package inventory stays current on every report while the panel that answers unauthenticated requests stays on the vulnerable build. For this CVE the clock runs from the KEV listing of 2025-11-04, with a public PoC and confirmed exploitation already in hand at that date, and completion has to be measured per host by the CWP build actually running rather than by an approved change record. The packet registers no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a server that took the update without restarting still runs the vulnerable code and must be counted as exposed until it does — on a shared hosting box that restart is also the step most likely to be deferred, because taking it interrupts every hosted site, and a deferral recorded as 'patched' is the specific way this remediation goes wrong.",
+        "evidence": "CISA KEV listed 2025-11-04; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77; CWE-78. patch_available true, live_patch_available false, live_patch_notes: '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.' Citing gaps on this entry include ASD Essential Eight 'Patch operating systems' and NIST SP 800-53 SI-2 (Flaw Remediation).",
         "gap_closes": [
           "AU-Essential-8-Patch",
-          "ISO-27001-2022-A.8.8",
-          "NIS2-Art21-patch-management",
           "NIST-800-53-SI-2"
         ]
       }
     ]
   },
-  "CVE-2025-6204": {
-    "name": "Dassault Systèmes DELMIA Apriso Code Injection Vulnerability",
+  "CVE-2025-11371": {
+    "name": "Gladinet CentreStack and Triofox Files or Directories Accessible to External Parties Vulnerability",
     "lesson_date": "2026-05-29",
     "attack_vector": {
-      "description": "a code-injection flaw (CWE-94) enabling unauthenticated remote code execution on the manufacturing-operations server. CISA KEV-listed 2025-10-28 with confirmed in-the-wild exploitation.",
+      "description": "a files-or-directories-accessible-to-external-parties flaw (CWE-552) disclosing server files including the machine key, enabling a follow-on deserialization remote code execution. CISA KEV-listed 2025-11-04 with confirmed in-the-wild exploitation.",
       "privileges_required": "none (the flaw is reachable by an unauthenticated attacker on the application's public interface)",
       "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
       "ai_factor": "No AI involvement documented in discovery or weaponization."
     },
     "defense_chain": {
       "prevention": {
-        "what_would_have_worked": "Apply the Dassault DELMIA Apriso update; hunt for web shells and rotate service credentials. DELMIA Apriso sits in the manufacturing-operations layer, so treat compromise as OT-adjacent.",
+        "what_would_have_worked": "Apply the Gladinet CentreStack/Triofox update AND rotate the machine key — the disclosure leaks the key that enables the deserialization RCE, so patching without key rotation leaves the RCE path open.",
         "was_this_required": true,
         "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
-        "adequacy": "Patch is necessary but, for these RCE/auth-bypass flaws, insufficient alone — web shells and stolen credentials survive the patch and require explicit cleanup."
+        "adequacy": "Patch is necessary but insufficient alone — forged tokens / leaked keys survive the patch and require explicit key rotation."
       },
       "detection": {
-        "what_would_have_worked": "Monitoring on the DELMIA Apriso: exploit-shaped requests, new web-shell files, unexpected process execution, and authentication/authorization events with no matching legitimate session or with forged key material.",
+        "what_would_have_worked": "Monitoring on the CentreStack/Triofox: exploit-shaped requests, new web-shell files, unexpected process execution, and authentication/authorization events with no matching legitimate session or with forged key material.",
         "was_this_required": false,
         "framework_requiring_it": null,
         "adequacy": "Necessary to catch resident persistence and key abuse after patching."
       },
       "response": {
-        "what_would_have_worked": "Patch immediately, hunt and remove web shells, rotate application secrets and credentials, and review data and downstream systems reachable from the DELMIA Apriso; assume compromise of accounts and managed endpoints in its reach.",
+        "what_would_have_worked": "Patch immediately, rotate the affected cryptographic/machine keys, rotate application secrets and credentials, and review data and downstream systems reachable from the CentreStack/Triofox; assume compromise of accounts and managed endpoints in its reach.",
+        "was_this_required": true,
+        "framework_requiring_it": "NIST 800-53 IR-4",
+        "adequacy": "Mandatory; patch-in-place without key rotation / web-shell hunting leaves the attacker resident or able to re-authenticate."
+      }
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, unauthenticated server-side application RCE/auth-bypass; these are mass-exploited within days, and RMM/file-sharing compromise reaches downstream systems."
+      },
+      "ISO-27001-2022-A.8.8": {
+        "covered": true,
+        "adequate": false,
+        "gap": "'Appropriate timescales' is undefined; the standard 30-day reading is unsafe for an actively-exploited, internet-facing enterprise application."
+      },
+      "NIS2-Art21-network-security": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Treats internet-facing enterprise applications as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA, and does not require the web-shell-hunt / key-rotation cleanup these RCEs and key-disclosure flaws need."
+      },
+      "PCI-DSS-4.0-6.3.3": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day critical-patch window is exploitation acceptance for an internet-facing enterprise application in or adjacent to the CDE; WAF coverage is partial mitigation, not remediation."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 76,
+      "basis": "Internet-facing Gladinet CentreStack and Triofox is run by audited organizations on a standard patch SLA and is mass-exploited within days; the required web-shell hunt and key rotation are rarely part of the documented patch procedure, and RMM/file-sharing/MES reach amplifies the blast radius.",
+      "theater_pattern": "patch_management"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "vendor_research",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Gladinet CentreStack and Triofox are the remote file-access tier, so the clock on this entry has to start at the KEV listing rather than at the next maintenance window: the packet's chain is disclosure of server files including the machine key feeding a follow-on deserialization remote code execution, which means an unpatched hour is a full-server-takeover window, not a file-disclosure window. A vendor patch exists and is the mitigation path; because the packet records no live-patch tool for this entry and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, the restart itself must be pre-authorized inside the SLA instead of being deferred to a change board. Any instance that cannot take the restart inside the window needs documented compensating controls (removing untrusted reach to the disclosing path) recorded as the SLA outcome, not an open exception.",
+        "evidence": "CISA KEV-listed 2025-11-04 with active_exploitation confirmed; RWEP 77, CVSS 8.8, poc_available true; patch_available true, live_patch_available false with the packet's note that no live-patch tool is registered for this entry and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For a CentreStack or Triofox instance that was reachable while unpatched, installing the vendor update closes the CWE-552 read path but does nothing about what the packet says the read path already handed over: server files including the machine key, which is precisely the material that makes the follow-on deserialization code execution work. The response for an exposed instance must therefore default to treating the disclosed configuration and machine key as attacker-held — rotate that cryptographic material and any credentials stored on the host, and rebuild rather than patch in place — because the same disclosure that leaks the key also gives an operator no way to prove no implant was planted during the exposure window. Patch-only remediation on this CVE produces a host that reports 'remediated' while the attacker still holds a valid key for the deserialization path.",
+        "evidence": "The packet's attack vector: a files-or-directories-accessible-to-external-parties flaw (CWE-552) disclosing server files including the machine key, enabling a follow-on deserialization remote code execution; active_exploitation confirmed and KEV-listed 2025-11-04, with poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
+  },
+  "CVE-2025-41244": {
+    "name": "Broadcom VMware Aria Operations and VMware Tools Privilege Defined with Unsafe Actions Vulnerability",
+    "lesson_date": "2026-05-29",
+    "attack_vector": {
+      "description": "a privilege-management flaw (CWE-267) in VMware Aria Operations and VMware Tools, letting a local user in a managed guest escalate privileges. CISA KEV-listed 2025-10-30 with confirmed in-the-wild exploitation; escalation flaws of this class form the second half of an intrusion chain.",
+      "privileges_required": "low (a local foothold — an unprivileged app, user, or process on the host)",
+      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
+      "ai_factor": "No AI involvement documented in discovery or weaponization."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Apply the VMware update; restrict the privileged collection account and segment management access — a guest LPE combined with management reach can pivot across the virtual estate.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
+        "adequacy": "Patch is definitive; the gap is the chain (initial access → unpatched LPE → root/SYSTEM) which a patched host shuts down, with platform hardening as the backstop."
+      },
+      "detection": {
+        "what_would_have_worked": "EDR/auditd telemetry for unprivileged-to-elevated transitions and the escalation primitive without a legitimate trigger.",
+        "was_this_required": false,
+        "framework_requiring_it": null,
+        "adequacy": "Backstops unpatched hosts; escalation is typically silent without endpoint/identity monitoring."
+      },
+      "response": {
+        "what_would_have_worked": "Force the patch; for confirmed exploitation treat the host as compromised, isolate, preserve forensic state, rotate credentials, and review for follow-on persistence.",
+        "was_this_required": true,
+        "framework_requiring_it": "NIST 800-53 IR-4",
+        "adequacy": "Mandatory; root/SYSTEM-level escalation makes the host an unreliable platform and warrants rebuild."
+      }
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed local/host privilege-escalation flaw; paired with an initial-access primitive, attackers elevate to root/SYSTEM within hours of a foothold."
+      },
+      "ISO-27001-2022-A.8.8": {
+        "covered": true,
+        "adequate": false,
+        "gap": "'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited escalation flaw, which is the second half of nearly every intrusion chain."
+      },
+      "AU-ISM-1546": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Essential 8 names OS/application patching, but the load-bearing backstops are platform-specific and unnamed: least-privilege and SELinux/seccomp on Linux, MDM-enforced OTA SLAs on Android, management-account segmentation for virtualization, and SMB signing / NTLM-disablement for the reflection class (the last breaks the attack regardless of patch state)."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 69,
+      "basis": "VMware Aria Operations and VMware Tools is widely deployed; audited organizations gate host/agent patches behind change windows and rarely enforce the platform-specific backstop (SELinux/seccomp, MDM OTA SLA, management-account segmentation, SMB signing), leaving the escalation chain open past the in-the-wild window.",
+      "theater_pattern": "patch_management"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "vendor_research",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet's vector has a malicious local actor with non-administrative privileges escalating to root on the same VM, through VMware Tools and Aria Operations rather than through anything the guest's own account model governs. For this entry the control means the fixed VMware Tools and Aria Operations builds are driven across every managed guest on the clock that opened with the 2025-10-30 KEV listing, and that completion is measured per guest by the VMware Tools build actually installed and the Aria Operations version actually running — not by 'update approved' or 'package pushed' in the management console, and not by a hypervisor-level rollup that reports host currency while guests lag. Because the packet records patch_available true, live_patch_available false, and live_patch_notes stating no live-patch tool with a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, a guest that has received the update but not restarted the affected components still carries the vulnerable path and has to be counted as exposed. The second half of the control is the load-bearing half here and is why NIST-800-53-AC-6 is cited as insufficient on this entry: the attacker is already a legitimate, non-administrative local user, so removing administrative rights from ordinary guest accounts — the thing a least-privilege attestation measures — does not stand between that account and root. Distinguishing test: on a staging guest running the same VMware Tools version, managed by Aria Operations with SDMP enabled, attempt the escalation from an ordinary non-administrative account and confirm root is not reached; then report fleet coverage as guests at the fixed build post-restart. A least-privilege attestation and a 'patch compliance' percentage both pass while this path stays open.",
+        "evidence": "Packet fields for CVE-2025-41244 (Broadcom VMware Aria Operations and VMware Tools Privilege Defined with Unsafe Actions Vulnerability): cwe_refs CWE-267; vector 'A malicious local actor with non-administrative privileges having access to a VM with VMware Tools installed and managed by Aria Operations with SDMP enabled may exploit this vulnerability to escalate privileges to root on the same VM'; cisa_kev true with kev_date 2025-10-30; active_exploitation confirmed; poc_available true; cvss 8.8; rwep_score 77; patch_available true; live_patch_available false; live_patch_notes '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.' Citing gaps recorded on this entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2 and NIST-800-53-AC-6.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "CWE-267 (privilege defined with unsafe actions) plus a vector in which a non-administrative local account reaches root on the same VM is this control's pattern: an operation that carries root authority inside the managed guest is reachable from an account that holds no administrative privilege, so the only thing standing between an ordinary guest user and root is the correctness of that privileged path. Bound to this product, the control means the privileged work that Aria Operations and VMware Tools perform inside a guest authorizes what it acts on for itself, at its own boundary, instead of inheriting trust from the fact that the request or the state originated inside the guest it manages — and that this property is verified on the managed-guest configuration the packet names, not assumed from the guest OS's account model. Preconditions, stated plainly: the vendor update is what repairs the boundary — this control states the property to verify, it does not implement it. Until that update is installed and the affected components restarted (the packet records no live-patch path and a restart-or-reboot requirement), the only operator-side lever is the exploit condition the packet itself names — a VM with VMware Tools installed, managed by Aria Operations, with SDMP enabled — so guests outside that configuration are not in the described condition, but where SDMP is operationally required nothing short of the update closes the path, and changing that setting does not evict an attacker who already reached root or remove what root access created on a guest that was in the vulnerable configuration during the exposure window (active_exploitation is confirmed and a PoC is public). Distinguishing test: enumerate which guests are managed with SDMP enabled and, on a staging guest matching that configuration, confirm a non-administrative local account cannot drive the privileged path to root — an attestation that no ordinary guest user holds administrative rights never tests this path.",
+        "evidence": "Packet fields for CVE-2025-41244: cwe_refs CWE-267 ('Privilege Defined with Unsafe Actions' per the entry name); vector names the exploit condition as a VM 'with VMware Tools installed and managed by Aria Operations with SDMP enabled' and the outcome as escalation 'to root on the same VM' by 'a malicious local actor with non-administrative privileges'; attack_vector adds that escalation flaws of this class form the second half of an intrusion chain; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-10-30; patch_available true; live_patch_available false with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include NIST-800-53-AC-6 and UK-CAF-B4.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
+  },
+  "CVE-2025-24893": {
+    "name": "XWiki Platform Eval Injection Vulnerability",
+    "lesson_date": "2026-05-29",
+    "attack_vector": {
+      "description": "an eval-injection flaw (CWE-95) in XWiki Platform, enabling unauthenticated remote code execution via a crafted document or search request. CISA KEV-listed 2025-10-30 with confirmed in-the-wild exploitation.",
+      "privileges_required": "none (the flaw is reachable by an unauthenticated attacker on the application's public interface)",
+      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
+      "ai_factor": "No AI involvement documented in discovery or weaponization."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Apply the XWiki update; hunt for web shells and rotate credentials — wiki RCE is routinely used to deploy cryptominers and backdoors.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
+        "adequacy": "Patch is necessary but insufficient alone — web shells and stolen credentials survive the patch; framework-level flaws require updating every consumer."
+      },
+      "detection": {
+        "what_would_have_worked": "Monitoring on the XWiki: exploit-shaped requests, new web-shell files and unexpected child-process execution.",
+        "was_this_required": false,
+        "framework_requiring_it": null,
+        "adequacy": "Necessary to catch exploitation and resident persistence after patching."
+      },
+      "response": {
+        "what_would_have_worked": "Patch immediately, hunt and remove web shells, rotate application secrets/credentials, and review for lateral movement; for a compromised monitoring server (Wazuh) assume detection was blinded during the window.",
+        "was_this_required": true,
+        "framework_requiring_it": "NIST 800-53 IR-4",
+        "adequacy": "Mandatory; patch-in-place without cleanup leaves the attacker resident or with a usable internal-access pivot."
+      }
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, unauthenticated server-side flaw that processes untrusted data; deserialization/eval RCE and SSRF/XXE chains are mass-exploited within days."
+      },
+      "ISO-27001-2022-A.8.8": {
+        "covered": true,
+        "adequate": false,
+        "gap": "'Appropriate timescales' is undefined; the standard 30-day reading is unsafe for an actively-exploited, internet-facing application — and framework-level flaws (React Server Components) require updating every consumer."
+      },
+      "NIS2-Art21-network-security": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Treats internet-facing applications as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA, and does not require the web-shell-hunt / secret-rotation / egress-restriction cleanup these flaws need — a compromised SIEM (Wazuh) additionally blinds the detection the framework assumes."
+      },
+      "PCI-DSS-4.0-6.3.3": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day critical-patch window is exploitation acceptance for an internet-facing application in or adjacent to the CDE (SAP/Oracle EBS sit adjacent to financial data); WAF coverage is partial mitigation, not remediation."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 75,
+      "basis": "Internet-facing XWiki Platform is run by audited organizations on a standard patch SLA and is mass-exploited within days; the required web-shell hunt, secret rotation, or egress/XXE hardening is rarely part of the documented patch procedure.",
+      "theater_pattern": "patch_management"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "vendor_research",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "XWiki's exposure here has no authentication gate to slow it down — the packet records that any guest can reach the eval-injection sink through a SolrSearch request and obtain arbitrary remote code execution — so every hour between KEV listing and deployment of the fixed build is an hour any reachable instance is exploitable by an unauthenticated caller against whom a PoC already exists. The packet records no live-patch path and a fix that typically requires a service restart or system reboot, so meeting the clock means scheduling that restart on the wiki, not deferring it to the next routine window. The SLA must name the XWiki application as its own tracked asset: self-hosted collaboration platforms are commonly patched on a separate cadence from the operating system of the host they run on, and an OS-patching attestation says nothing about the wiki's build.",
+        "evidence": "Packet: XWiki Platform, CWE-95 eval injection; vector 'XWiki Platform contains an eval injection vulnerability that could allow any guest to perform arbitrary remote code execution through a request to SolrSearch'; CISA KEV-listed 2025-10-30 with active_exploitation 'confirmed'; RWEP 77 / CVSS 9.8; poc_available true; patch_available true; live_patch_available false, with live_patch_notes '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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
+  },
+  "CVE-2025-6204": {
+    "name": "Dassault Systèmes DELMIA Apriso Code Injection Vulnerability",
+    "lesson_date": "2026-05-29",
+    "attack_vector": {
+      "description": "a code-injection flaw (CWE-94) enabling unauthenticated remote code execution on the manufacturing-operations server. CISA KEV-listed 2025-10-28 with confirmed in-the-wild exploitation.",
+      "privileges_required": "none (the flaw is reachable by an unauthenticated attacker on the application's public interface)",
+      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
+      "ai_factor": "No AI involvement documented in discovery or weaponization."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Apply the Dassault DELMIA Apriso update; hunt for web shells and rotate service credentials. DELMIA Apriso sits in the manufacturing-operations layer, so treat compromise as OT-adjacent.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
+        "adequacy": "Patch is necessary but, for these RCE/auth-bypass flaws, insufficient alone — web shells and stolen credentials survive the patch and require explicit cleanup."
+      },
+      "detection": {
+        "what_would_have_worked": "Monitoring on the DELMIA Apriso: exploit-shaped requests, new web-shell files, unexpected process execution, and authentication/authorization events with no matching legitimate session or with forged key material.",
+        "was_this_required": false,
+        "framework_requiring_it": null,
+        "adequacy": "Necessary to catch resident persistence and key abuse after patching."
+      },
+      "response": {
+        "what_would_have_worked": "Patch immediately, hunt and remove web shells, rotate application secrets and credentials, and review data and downstream systems reachable from the DELMIA Apriso; assume compromise of accounts and managed endpoints in its reach.",
         "was_this_required": true,
         "framework_requiring_it": "NIST 800-53 IR-4",
         "adequacy": "Mandatory; patch-in-place without key rotation / web-shell hunting leaves the attacker resident or able to re-authenticate."
@@ -20819,7 +20884,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry is the case the control exists for, and the packet states both halves. 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 packet records that 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.",
+        "evidence": "Packet fields for this entry: name 'Apple Multiple Products Unspecified Vulnerability', CWE-94. Vector: 'Apple macOS, iOS, tvOS, Safari, and watchOS contain an unspecified vulnerability in JavaScriptCore that when processing web content may lead to arbitrary code execution. The impacted product could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' cisa_kev true with kev_date 2025-10-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, live_patch_notes: '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 (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-patch-management (Vulnerability handling and disclosure) are recorded as citing gaps against this entry — every one of them measures whether a fix was applied within a timescale, and none of them has a terminal state for a device on which no future fix will ever be installable.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The population this control has to bite on for this entry is the one the decommission requirement produces: macOS, iOS, tvOS, watchOS and Safari installs that cannot reach a build carrying the JavaScriptCore fix. For those there is no future build that clears them, so the fixed build has to function as an access condition — organizational mail, VPN, document stores and identity access denied to a device below it — rather than as a stale row on a patch-compliance dashboard that ages indefinitely. The same condition covers the shorter window on devices that can take the fix: the packet records that the vendor patch typically requires a restart, so a device between download and restart is still in the exposed population and needs an access-side answer, not a patch-side one. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its mail and VPN has recorded the exposure rather than removed it. Precondition, and it is the reason this cannot be logged as the mitigation: an access condition bounds what an attacker gains from a compromised device, it does nothing to the device itself. It does not remove the JavaScriptCore defect, does not evict an implant on a device already compromised — and the packet's note that Apple flaws of this class are typically used in targeted-spyware chains makes that the case to plan for — and it reaches only devices the management channel enrols. Personally-owned or unenrolled Macs, iPhones, Apple TVs and Watches touching organizational data are not covered by it, and the only lever against those is removing the access path they use.",
+        "evidence": "Packet fields for this entry: CWE-94 code execution in JavaScriptCore across Apple macOS, iOS, tvOS, Safari and watchOS, with the vector stating the flaw 'when processing web content may lead to arbitrary code execution' and that the impacted product could be end-of-life and/or end-of-service. cisa_kev true, kev_date 2025-10-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, live_patch_notes: '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.' attack_vector adds that Apple zero-days of this class are typically used in targeted-spyware chains. AU-Essential-8-Patch (Patch operating systems) and UK-CAF-B4 (System security) are recorded as citing gaps against this entry; both score patch cadence and system-protection policy rather than making the fixed build a precondition of access.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The delivery path the packet records is attacker-controlled web content processed by JavaScriptCore, and its attack_vector notes that Apple flaws of this class are typically used in targeted-spyware chains. For the cohort plausibly inside that targeting set — executives, journalists, legal and security staff — the reboot-gated update is not fast enough on its own, so place their macOS and iOS devices in Apple's reduced-attack-surface mode, where untrusted web content, message attachments, link previews and fonts are not processed automatically. That narrows the path into the CWE-94 sink during the window that opened before anyone in the estate learned of the flaw: the packet records confirmed exploitation and a public PoC, so the exposure predates the 2025-10-20 KEV listing and the assignment cannot be a reaction to it. The mode only helps if it was already on when the content arrived, which makes it a standing posture assigned to the high-risk cohort ahead of the next disclosure rather than a response to this one. Preconditions, and they bound this tightly. The mode reduces what is processed automatically; it does not repair JavaScriptCore, and content the user deliberately chooses to load in a still-permitted path still reaches the engine. It gives nothing against a device already compromised — a device in this cohort that rendered untrusted content while exposed belongs on the incident path, not the hardening path. And on a device the decommission requirement identifies as unable to reach the fixed build, this is the only remaining lever and it is a holding measure until that device is replaced, not a substitute for replacing it.",
+        "evidence": "Packet fields for this entry: vector 'Apple macOS, iOS, tvOS, Safari, and watchOS contain an unspecified vulnerability in JavaScriptCore that when processing web content may lead to arbitrary code execution', CWE-94. attack_vector: 'a code-execution flaw (CWE-94) reachable via attacker-controlled web/media content. CISA KEV-listed 2025-10-20 with confirmed in-the-wild exploitation (Apple zero-days of this class are typically used in targeted-spyware chains).' cisa_kev true, kev_date 2025-10-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot. UK-CAF-B4 (System security) is recorded as a citing gap against this entry; it addresses protection of deployed systems but names no reduced-attack-surface posture for a targeted cohort during the period before a reboot-gated fix lands.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-2746": {
     "name": "Kentico Xperience CMS Authentication Bypass Using an Alternate Path or Channel Vulnerability",
@@ -21195,7 +21293,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives AEM Forms on JEE an unauthenticated remote code-execution path, confirmed in-the-wild exploitation, a public PoC and a KEV listing dated 2025-10-15, so for any instance that was network-reachable by untrusted callers before the update landed the question remediation must answer is not whether the flaw is closed but whether something already ran. On a JEE deployment the artifacts that outlive the patch are ordinary parts of the platform: a deployed application archive, a JSP or class file written under the application server's document or work directories, a scheduled job, or a credential lifted from the server's configuration. The vendor update removes none of them and a build-version check inspects none of them. The requirement for this product is therefore to capture the AEM Forms configuration and deployed-application inventory, rebuild the server from a known-good image, and rotate the credentials that instance held — application-server administrative accounts, repository and datastore credentials, and any service identity it authenticates as — instead of updating in place. Precondition: this applies to instances whose reachable window overlapped the exploitation the packet records; where an instance can be shown to have been unreachable by untrusted callers throughout, the vendor update on its own is the proportionate response. Either way the packet registers no live-patch path, so the fix carries the service restart or system reboot the vendor requires, and an instance updated but not restarted is not yet remediated.",
+        "evidence": "Packet vector: 'Adobe Experience Manager Forms in JEE contains an unspecified vulnerability that allows for arbitrary code execution.' Attack vector: 'a code-execution flaw (CWE-94) enabling unauthenticated remote code execution on the AEM Forms server. CISA KEV-listed 2025-10-15 with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available true; CVSS 8.8; RWEP 77. patch_available true, live_patch_available false, live_patch_notes: '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.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "AEM Forms on JEE runs inside an enterprise application server whose restarts are normally negotiated into a change window, and the packet states the vendor patch typically requires a service restart or system reboot with no live-patch tool registered — so the specific way this remediation fails is an instance that has taken the update but not restarted being recorded as patched while it still runs the vulnerable code. The clock for this CVE runs from the KEV listing of 2025-10-15, with a public PoC and confirmed exploitation already in hand at that date, and completion has to be measured per instance by the build running after the restart rather than by a deployment ticket being closed. Enumerate the JEE Forms instances specifically rather than treating this as an estate-wide Experience Manager item: the packet names Adobe Experience Manager Forms in JEE as the affected product and ties the code-execution path to nothing else, so widening the remediation to every Experience Manager deployment manufactures work against software this entry does not implicate — widen it only where a verified source identifies another deployment carrying the same component. Because the path needs no authentication, priority follows reachability: instances that untrusted callers can reach are the population to take first.",
+        "evidence": "Packet names the affected product as 'Adobe Experience Manager Forms in JEE' with 'an unspecified vulnerability that allows for arbitrary code execution' (CWE-94), reachable per the attack vector as 'unauthenticated remote code execution on the AEM Forms server'. CISA KEV listed 2025-10-15; active_exploitation confirmed; poc_available true; CVSS 8.8; RWEP 77. patch_available true, live_patch_available false, live_patch_notes: '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.' Citing gaps include ASD Essential Eight 'Patch operating systems' and NIST SP 800-53 SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-47827": {
     "name": "IGEL OS Use of a Key Past its Expiration Date Vulnerability",
@@ -21830,7 +21951,35 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry states both halves of the control itself: a vendor patch is recorded as available, and the packet's own vector says the impacted product could be end-of-life and/or end-of-service and that users should discontinue product utilization. Taken together they define the requirement — a host still exposed to this after the 2025-10-06 re-listing is a host whose browser may have no ongoing update path, so reaching the vendor fix is an interim state and the terminal state is taking Internet Explorer out of service on that host, or replacing the host where the workload depends on the browser. Scope the inventory to what the packet names: Internet Explorer rendering attacker-controlled web content. The packet provides no mapping from this uninitialized-memory defect into any other browser or HTML-rendering component, so treating every renderer in the estate as an instance of this CVE manufactures findings and removal work against software no evidence implicates. In operational terms: enumerate every host that can still use Internet Explorer to render untrusted web content, record per host whether it can take the vendor update and be restarted, put those hosts on the interim clock, and put every host that cannot on a dated removal or replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed in-the-wild exploitation in service indefinitely. Precondition on the interim half, which is where this is routinely over-claimed: the packet registers no live-patch path and states the vendor patch typically requires a service restart or system reboot, so a host that received the update but was not restarted still runs the vulnerable code and is not remediated; and applying the fix for this defect says nothing about anything found in that browser since, which is why the requirement cannot end at 'every install reports the fixed build' — that phrasing marks an abandoned browser compliant while it stays exposed. Because active exploitation is confirmed and the delivery path is a page the victim visits, a host that browsed untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet vector: 'Microsoft Internet Explorer contains an uninitialized memory corruption vulnerability that could allow for remote code execution. The impacted product could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' Packet attack_vector: an uninitialized-memory / use-after-free corruption flaw (CWE-94) in Internet Explorer, exploitable by an attacker-controlled web page for code execution in the browser, and 'the legacy re-listing exists because long-tail unpatched estates remain exposed'. CISA KEV listed 2025-10-06; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. patch_available true, live_patch_available false, live_patch_notes: '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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a remediation clock anchored on patch availability produces no action at all. The packet describes the 2025-10-06 entry as a legacy re-listing that exists because long-tail unpatched estates remain exposed — that is, the vendor fix predates the listing by a wide margin — so a flaw-remediation programme that ages this CVE from its original patch date reads it as long since closed and nothing fires, while the KEV listing is the statement that it is being exploited now. Applied to this CVE the control means the clock starts at the KEV listing date, not the patch date, and the verified mitigation recorded per host is one of exactly two things the packet supports: the vendor update with its restart taken, or — following the packet's own instruction that users should discontinue product utilization — a documented, dated discontinuation of Internet Explorer on that host. Precondition, and it is what usually gets an SLA marked met while the flaw stays live: the packet registers no live-patch path and states the vendor patch typically requires a service restart or system reboot, so a host that has installed the update without restarting still runs the vulnerable code and must not be counted as mitigated; and on a host with no supported update path the clock can only be met by the discontinuation route, since there is no compensating rule in this packet that keeps the browser safely rendering untrusted pages. Distinguishing test: pull the remediation due-date the vulnerability-management programme actually assigned this CVE and confirm it is anchored on 2025-10-06 — an estate whose report ages this from the original fix shows it closed years ago while unrestarted and unsupported installs remain exposed to confirmed in-the-wild exploitation with a public PoC available.",
+        "evidence": "CISA KEV listed 2025-10-06; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. Packet attack_vector: 'the legacy re-listing exists because long-tail unpatched estates remain exposed'; delivery is an attacker-controlled web page giving code execution in the browser. patch_available true, live_patch_available false, live_patch_notes: '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.' Packet vector: the impacted product could be end-of-life (EoL) and/or end-of-service (EoS); users should discontinue product utilization.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-43226": {
     "name": "Microsoft Windows Privilege Escalation Vulnerability",
@@ -21955,7 +22104,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This Microsoft Windows entry is the case this control exists for, and the packet states both halves explicitly. patch_available is true, 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; the entry's NIS2-Art21-patch-management gap goes further and states that the InformationCardSigninHelper ActiveX control is end-of-life, so patch management cannot remediate it and only removal or decommissioning of the affected component satisfies the obligation, while the UK-CAF-B4 gap states that compliance requires retiring the still-registered control rather than patching it. The operational requirement follows directly: enumerate every Windows system where the InformationCardSigninHelper Class ActiveX control (icardie.dll) is still registered and reachable from a browser rendering attacker-supplied web content. On a system that can still take a Windows update carrying the fix, reaching that build is the interim state; the terminal state is removing or unregistering the control and retiring the Internet Explorer-era rendering path that instantiates it, because a machine held only at the fixed build is still running an unsupported component and remains exposed to anything found in it since. Scope to what the packet names — the Windows component icardie.dll, reached by a specially crafted webpage. The packet ties the out-of-bounds write to that control and gives no mapping into other vendors' browsers or into other ActiveX components, so treating every ActiveX control in the estate as an instance of this CVE manufactures removal work against components no evidence implicates. Precondition on the interim half: live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot, so a system that took the update but has not restarted still runs the vulnerable code and is not remediated. And a risk acceptance carrying no dated removal schedule leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely.",
+        "evidence": "Packet vector: 'Microsoft Windows contains an out-of-bounds write vulnerability in the InformationCardSigninHelper Class ActiveX control, icardie.dll. An attacker could exploit the vulnerability by constructing a specially crafted webpage... The impacted product could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' cisa_kev true, kev_date 2025-10-06; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 77; CWE-94; patch_available true; patch_required_reboot true; live_patch_available false with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. NIS2-Art21-patch-management gap: 'No patch exists — the InformationCardSigninHelper ActiveX control is end-of-life... only removal or decommissioning of the affected component satisfies the obligation.' UK-CAF-B4 gap: 'an unsupported, still-registered ActiveX control remains exploitable via a crafted webpage, and B4 compliance requires retiring it rather than patching.' AU-Essential-8-App-Hardening gap: 'disabling ActiveX/OLE in browsers neutralises the crafted-webpage vector, whereas patch controls are moot for an end-of-life control.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this Windows entry is not the original disclosure — the packet records the KEV listing as 2025-10-06, so a flaw-remediation programme keyed to first-disclosure date carries no open item for it at all and its SLA never starts. For this CVE the control means the response clock runs from that KEV date, and the mitigation the control accepts has to be chosen per system rather than assumed: on a Windows build that can still take the update carrying the fix, the mitigation is that update plus the restart the packet says the vendor fix typically requires, since live_patch_available is false and there is no in-memory path; where the component sits on an unsupported build, the mitigation is the documented compensating control — unregistering or removing the InformationCardSigninHelper ActiveX control and blocking the browser path that instantiates it — and the record must show it as a compensating control with a removal date attached, not as 'patched per SLA'. The distinguishing test is per-endpoint state rather than a scanner verdict: enumerate the systems on which the control is still instantiable from a rendered page. An estate that reports this CVE closed because its inventory resolved it years ago has recorded the exposure as fixed while it stays live — which is precisely what the entry's own flaw-remediation and technical-vulnerability-management gaps say the legacy KEV re-listing documents.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-10-06 on a CVE identifier from 2013; active_exploitation 'confirmed'; poc_available true; patch_available true; live_patch_available false; patch_required_reboot true; live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. NIST-800-53-SI-2 framework_coverage gap: the 30-day SLA 'is far longer than the observed exploitation window for a KEV-listed, actively-exploited client-side document/browser RCE; legacy KEV re-listings document organizations still running unpatched builds.' ISO-27001-2022-A.8.8 gap: \"'Appropriate timescales' is undefined... the legacy KEV re-listing exists because organizations still run vulnerable Office/IE/Windows builds.\"",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-074",
+        "name": "CVE-REGRESSION-WATCHER",
+        "description": "What is hard about this Windows entry is not the remediation, it is noticing that a remediation is owed. The packet records a CVE identifier from 2013 entering CISA KEV on 2025-10-06 with confirmed exploitation and a public PoC — years after any asset inventory recorded the item as resolved. This control is the intake rule that produces the signal the KEV response clock above needs a start for: surface current exploitation and PoC material that references CVE identifiers from prior years as candidate re-triage cases, and require an explicit re-check of whether the affected component is still present, instead of deferring to the historical 'remediated' state held in the register. Bound to this entry the re-check is one concrete question with an answer independent of the original remediation record — is the InformationCardSigninHelper ActiveX control still registered on any Windows build in service, and can a rendered page still instantiate it. Limits, stated plainly: this control detects nothing on an endpoint and remediates nothing. It converts a historical CVE reappearing in current exploitation material into a work item, and it produces that item only if the threat-intake pipeline ingests something broader than current-year advisory feeds — if it does not, nothing downstream of it fires and the estate's exposure stays invisible rather than accepted.",
+        "evidence": "Packet: a CVE identifier from 2013 with cisa_kev true and kev_date 2025-10-06; active_exploitation 'confirmed'; poc_available true; RWEP 77; the vector names a specific still-registered component (InformationCardSigninHelper Class ActiveX control, icardie.dll). NIST-800-53-SI-2 gap: 'legacy KEV re-listings document organizations still running unpatched builds.' ISO-27001-2022-A.8.8 gap: 'the legacy KEV re-listing exists because organizations still run vulnerable Office/IE/Windows builds.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2011-3402": {
     "name": "Microsoft Windows Remote Code Execution Vulnerability (CVE-2011-3402)",
@@ -22010,7 +22192,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the KEV listing is the only clock that moved. patch_available is already true, so the control's 'KEV listing or patch availability, whichever is later' branch resolves to 2025-10-06, and the work is not obtaining a fix but locating the Windows hosts that never took the one that has long existed. Scope the sweep from the affected fields, not from the vector: the vector names a Word document as one delivery route, but affected and affected_versions name Microsoft Windows with ranges left to the vendor advisory, so the population is every Windows install — an estate that inventories Office installs reports clean while hosts reachable through the web-page route stay exposed. The hosts that a patch-approval report never covers are the ones this CVE lives on: machines rebuilt from images that predate the fix, restored backups, long-dormant VMs, and anything re-provisioned from old media. Measure completion on the win32k.sys code each host is actually executing: live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a host that installed the update but has not restarted still runs the vulnerable font parser and is not remediated. Note also what gives no help here — the packet has the flaw in the kernel-mode drivers with code execution at kernel privilege, so the least-privilege scoping recorded as insufficient on this entry is not a lever: running the user as a non-administrator does not change where the crafted font is parsed.",
+        "evidence": "Packet fields for CVE-2011-3402: vector places an unspecified vulnerability in the TrueType font parsing engine in win32k.sys in the Windows kernel-mode drivers, reachable by remote attackers via crafted font data in a Word document or web page; affected and affected_versions read 'Microsoft Windows — versions per vendor advisory'; cisa_kev true with kev_date 2025-10-06 and active_exploitation confirmed; poc_available true; cvss 9.8 and rwep_score 77; patch_available true with patch_required_reboot true; live_patch_available false, live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction; attack_vector records code execution at kernel privilege and states the legacy re-listing exists because long-tail unpatched estates remain exposed; framework_coverage for NIST-800-53-SI-2 and ISO-27001-2022-A.8.8 both record that organizations still run unpatched builds.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The reason a fourteen-year-old Windows kernel flaw needed a 2025 KEV listing is as much a measurement failure as a remediation one, and this is where paper compliance hides on this entry: a vulnerability console reports the estate clean for CVE-2011-3402 because no check fires for a 2011 Windows CVE that every inventory treats as permanently closed — an outcome byte-identical to an estate where every host is above the fixed build. Prove the check works before trusting its verdict. Point the scanner at a host whose Windows build predates the fix — a restored backup, an archived image, or a VM known never to have taken it — and confirm the CVE is actually reported on it; a clean result from a scan that never tested is not evidence of remediation. The check must read the build the host is running rather than the update-approval or download state in the management console, because live_patch_available is false and the packet records a restart-or-reboot requirement, so a downloaded-but-not-restarted host is still executing the vulnerable win32k.sys font parser while every console field says patched. Precondition and limit: this control produces a truthful inventory and removes nothing — it tells the operator which hosts the KEV clock actually applies to, and the fixed build plus its restart is still what closes them.",
+        "evidence": "Packet fields for CVE-2011-3402: cisa_kev true with kev_date 2025-10-06 against a CVE identifier from 2011, active_exploitation confirmed, poc_available true; attack_vector states the legacy re-listing exists because long-tail unpatched estates remain exposed; framework_coverage for NIST-800-53-SI-2 records that legacy KEV re-listings document organizations still running unpatched builds, and the AU-ISM-1546 coverage entry records that long-tail unpatched estates persist; patch_available true with patch_required_reboot true and live_patch_available false, live_patch_notes recording the service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2010-3765": {
     "name": "Mozilla Multiple Products Remote Code Execution Vulnerability",
@@ -22065,7 +22271,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry states both halves the control needs. A fixed Mozilla build exists — patch_available is true — while the packet's patch-management gap records that this memory-corruption RCE persists on end-of-life Mozilla builds where no vendor patch exists, and the system-security gap records that those legacy JavaScript-enabled clients can only be decommissioned or hardened out. So the requirement is an inventory that resolves that question per install rather than assuming either answer: enumerate every Mozilla Firefox, SeaMonkey and Thunderbird install that renders untrusted web content or HTML mail, and record for each whether it sits on a line that still receives Mozilla security updates. Installs on a maintained line are interim items on the clock that opened with the 2025-10-06 KEV listing, remediated by reaching the fixed version named in the vendor advisory. Installs on a line with no vendor patch cannot be remediated at all and are replacement items with a dated schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely, and such a build is exposed not only to this CWE-94 path through the frame constructor but to everything found in that engine since it was last updated. Scope the inventory to the three products the entry names; widen it only where a verified source identifies other software carrying the same component, since treating every renderer in the estate as an instance of this CVE manufactures replacement work against software no evidence here implicates. Precondition on the interim half: the packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so an install that has taken the update while its process keeps running is still executing pre-fix code and is not yet remediated. And because exploitation is confirmed and delivery is attacker-controlled content, a client that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet NIS2-Art21-patch-management gap: 'Patch-management assumes supported software, but this KEV-listed Firefox/Thunderbird memory-corruption RCE persists on end-of-life Mozilla builds where no vendor patch exists, so the control has no remediation to schedule.' UK-CAF-B4 gap: 'System-security lifecycle expectations are violated by continued exposure of legacy JavaScript-enabled Mozilla clients whose known RCE cannot be patched, only decommissioned or hardened out.' vector: 'Mozilla Firefox, SeaMonkey, and Thunderbird contain an unspecified vulnerability when JavaScript is enabled... via vectors related to nsCSSFrameConstructor::ContentAppended, the appendChild method, incorrect index tracking, and the creation of multiple frames, which triggers memory corruption.' attack_vector notes 'the legacy re-listing exists because long-tail unpatched/end-of-life estates remain exposed.' cisa_kev true, kev_date 2025-10-06, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77. patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' affected_versions: 'Mozilla Multiple Products — versions per vendor advisory.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "For the Mozilla installs that are still on a line receiving updates, this is the control that decides whether the fixed build actually arrives before an attacker-controlled page does. The requirement here is that the managed update ring covers all three products the entry names — Firefox, SeaMonkey and Thunderbird — rather than the browser alone: the packet places the flaw in code reached when JavaScript is enabled, and names the suite and the mail client alongside the browser, so a ring scoped to Firefox leaves the same frame-constructor path live wherever SeaMonkey or Thunderbird renders content. Deferral windows and per-user deferral are the specific failure: the packet records a public PoC and confirmed in-the-wild exploitation, so an update ring that holds these clients back for a validation cycle is holding them on a build with a known-exploited code-execution path. Completion is measured on the version the running process reports, not on what was downloaded or staged — the packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, and a browser or mail client left open for days is the ordinary case, so an install that took the update without the process restarting is still executing pre-fix code. Precondition: this reaches only the installs the management channel can see and that are on a line with a fixed build available. An unmanaged per-user copy is remediated by removing it, and an install on a line with no vendor patch is not an update item at all — that population belongs to the decommissioning path, and counting it in an update-compliance figure is how a KEV-listed flaw stays in service behind a green metric.",
+        "evidence": "Packet NIST-800-53-SI-2 gap: '30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE. CISA due date is the operationally-meaningful clock — typically 14-21 days for new KEV listings', with framework_coverage adding that the SLA 'is far longer than the observed exploitation window for a KEV-listed, actively-exploited client-side browser/reader RCE'. ISO-27001-2022-A.8.8 gap: 'Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses patch-cycle response to incident-speed response', with coverage noting 'appropriate timescales' is undefined. vector names Mozilla Firefox, SeaMonkey and Thunderbird, exploitable 'when JavaScript is enabled'. poc_available true; active_exploitation confirmed; kev_date 2025-10-06. patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-61882": {
     "name": "Oracle E-Business Suite Unspecified Vulnerability (CVE-2025-61882)",
@@ -22125,7 +22353,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet puts an unauthenticated attacker with network access over HTTP through the BI Publisher Integration component and into takeover of Oracle Concurrent Processing, with a public PoC and mass exploitation in a data-theft extortion campaign — so the interval that matters for Oracle E-Business Suite is the one between the 2025-10-06 KEV listing and the moment each application tier is actually running the fixed code, not the quarterly change window an ERP is normally patched in. Applied to this product: enumerate every EBS instance rather than only the ones the organisation thinks of as internet-facing, because the packet's stated access requirement is HTTP network access — an instance reachable only from the corporate network is exposed to every host on that network, and scoping the emergency to the external ones leaves the rest serving the same unauthenticated path. Take the fixed level from the Oracle advisory the packet points to rather than assuming a version, since the entry records affected versions only by reference to it, and apply it out of band. The completion measure is the load-bearing part here: the packet records that the vendor patch typically requires a service restart or system reboot and registers no live-patch tool, so an instance where the patch files landed but the EBS services were not bounced is still serving pre-fix code. On an ERP that restart is the single step most likely to be deferred, because taking it interrupts Concurrent Processing jobs and the user population, and a deferral recorded as 'patched' is the specific way this remediation fails. Priority follows the packet rather than the CVSS band — an 8.8 that is KEV-listed, has a public PoC and is being mass-exploited for extortion outranks higher-scored items with neither.",
+        "evidence": "Packet for CVE-2025-61882, Oracle E-Business Suite Unspecified Vulnerability: CWE-94; cisa_kev true with kev_date 2025-10-06; active_exploitation confirmed; rwep_score 83, cvss 8.8; poc_available true; patch_available true; patch_required_reboot true; live_patch_available false with live_patch_notes '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.'; vector 'Oracle E-Business Suite contains an unspecified vulnerability in the BI Publisher Integration component. The vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Concurrent Processing. Successful attacks can result in takeover of Oracle Concurrent Processing.'; affected_versions 'Oracle E-Business Suite — versions per vendor advisory'; attack_vector 'mass-exploited in a data-theft extortion campaign'; AU-Essential-8-Patch gap 'Essential-Eight internet-facing patch windows trail the mass exploitation of exposed Oracle E-Business Suite by a ransomware crew, where unauthenticated HTTP RCE demands emergency out-of-band patching.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Oracle E-Business Suite is the enterprise ERP this control governs, and this CVE is its function-level authorization failing: the packet has an unauthenticated attacker reaching the BI Publisher Integration component over HTTP and taking over Oracle Concurrent Processing — the batch-execution engine that runs an ERP's privileged jobs and holds the connections and credentials those jobs use. Bound to this deployment, the control means each function the BI Publisher integration exposes, and each path it opens into Concurrent Processing, authorizes its own caller before doing work, rather than inheriting a verdict from the tier that fronts it; and that no EBS instance is left with that HTTP surface reachable from a network segment with no operational need for it. The distinction matters for the audit, not just the engineering: the cited least-privilege gap does not touch this path, because the attacker never authenticates as any EBS user, so responsibility and role scoping — the account model an identity or least-privilege attestation examines — is never consulted at all. That attestation passes cleanly while the unauthenticated path stays fully open. Distinguishing test on a staging EBS instance: from a segment with no operational need for EBS, issue unauthenticated HTTP requests to the BI Publisher Integration endpoints and confirm each is refused before the function executes — an environment that can produce a clean report of every EBS responsibility assignment tells you nothing about this path. Precondition: the vendor update is what establishes the endpoint-side authorization property; this control is the verification and the reachability discipline around it. Restricting which segments can reach the EBS HTTP surface bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable where the instance must serve a broad user population.",
+        "evidence": "Packet for CVE-2025-61882, Oracle E-Business Suite Unspecified Vulnerability: vector 'unspecified vulnerability in the BI Publisher Integration component ... allows unauthenticated attacker with network access via HTTP to compromise Oracle Concurrent Processing. Successful attacks can result in takeover of Oracle Concurrent Processing.'; cwe_refs CWE-94; NIST-800-53-AC-6 gap 'Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.'; active_exploitation confirmed, cisa_kev true (kev_date 2025-10-06); poc_available true; patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For an Oracle E-Business Suite instance that was reachable while exposed, the Oracle patch closes the entry point and removes nothing that came through it. The packet records confirmed in-the-wild exploitation, a public PoC, and mass exploitation in a data-theft extortion campaign against a path needing no credentials, so the response default has to be incident handling rather than a patch ticket. Applied to this product: capture forensic state of the application tier before remediation where the outage budget allows, hunt the web-accessible directories and the EBS file system for artifacts written during the exposure window, rebuild the tier from a known-good deployment wherever an artifact is found or the instance cannot be cleared, and rotate the credentials that tier holds — database accounts, integration and service accounts, and any secret in the EBS configuration — because on a Concurrent Processing takeover those are what leaves the host along with the data. The packet's NIS2 gap is the reporting half of the same requirement: it records that known campaign use lifts this above routine vulnerability handling into a Significant Incident class where disclosure clocks engage, which means the finding of exposure during the window — not the later finding of an implant — is what starts the notification assessment, and a runbook that waits for confirmed compromise before escalating misses the clock. Boundary of the requirement: the rebuild default applies to instances that were reachable by an untrusted caller during the exposure window; an instance that provably was not is a patch item, and conflating the two spends the rebuild effort in the wrong place.",
+        "evidence": "Packet for CVE-2025-61882, Oracle E-Business Suite Unspecified Vulnerability: active_exploitation confirmed; cisa_kev true (kev_date 2025-10-06); poc_available true; attack_vector 'an unauthenticated code-injection / remote code execution flaw (CWE-94), mass-exploited in a data-theft extortion campaign'; vector 'takeover of Oracle Concurrent Processing'; UK-CAF-D1 gap 'CAF response-and-recovery planning must treat this Oracle EBS RCE as an active ransomware-campaign vector rather than a routine patch item, since unauthenticated Concurrent-Processing takeover has been used for large-scale data theft.'; NIS2-Art21-vulnerability-handling gap 'Known ransomware-campaign use elevates this from routine vulnerability handling to a Significant Incident class under NIS2 Art.23(4) — disclosure clocks engage.'; framework_coverage NIS2-Art21-network-security 'does not require the web-shell-hunt / credential-rotation / downstream-review cleanup these RCEs need given their managed-estate reach'; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-D1",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2014-6278": {
     "name": "GNU Bash OS Command Injection Vulnerability",
@@ -22185,7 +22445,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where the control's 'whichever is later' clause is the whole point: the packet records a vendor patch as available and a KEV listing dated 2025-10-02, so the trigger that governs is the listing, and the requirement is that a CVE bearing a 2014 identifier re-enters the remediation queue on the expedited clock instead of being filed as historical by a vulnerability-management process that ages work by CVE year. The population to put on that clock is not every host with bash installed — it is the hosts where the packet's condition holds, namely those where attacker-controlled data reaches a bash environment, with CGI named as the example — so the first deliverable is the enumeration of those service paths, and those hosts are remediated before the general fleet. Completion is measured per host as the installed bash package plus the service restart or system reboot that the packet's live-patch note records as typically required by the KEV requiredAction, since the packet registers no live-patch tool for this entry and a host that installed the package without that restart is not the state the packet describes as remediated. Precondition: this is a scheduling control and reduces nothing by itself; it commits the clock and the ordering, and the work still has to be done. It also says nothing about a host already exploited — the packet records active exploitation as confirmed with a public exploit available, so a host that exposed a bash-reachable path during the exposure window needs triage and credential review rather than closure on a package version.",
+        "evidence": "Packet: GNU Bash contains an OS command injection vulnerability (CWE-78) in Bash environment-variable parsing, described as a Shellshock-family flaw, which allows remote attackers to execute arbitrary commands via a crafted environment, enabling remote command execution wherever attacker-controlled data reaches a Bash environment such as CGI. cisa_kev true, kev_date 2025-10-02, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false with live_patch_notes: no live-patch tool registered for this entry, and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE the paper-compliance failure is a bash package version read, and the packet gives two reasons it is not evidence. First, the packet places the flaw in the Shellshock family, so what has to be shown is that a host runs a build carrying the fix for this member — a build merely newer than the family's first fix is not the same claim, and an estate that closed its Shellshock work years ago on a family-level attestation can hold hosts this member still reaches. Second, exposure here is conditional rather than universal: the packet's condition is that attacker-controlled data reaches a bash environment, with CGI as the named example, so a scan that scores every host carrying bash identically measures neither the real exposure nor its absence. The operational test the control demands is therefore behavioural, and the packet supplies its basis — the trigger is a crafted environment and a public exploit exists: on a staging copy of each enumerated service path, deliver the crafted environment and confirm no injected command runs, then repeat it after the service restart or system reboot the packet's live-patch note records as typically required, since the check run before that restart can pass on the updated package while the exposed path still behaves as before. Scope the claim to what the scanner actually owns: a host-package scan is evidence only for the bash copies the package manager manages, so a clean result covers those copies and no others, and any copy shipped inside an image or appliance that the host scan does not enumerate has to be identified from its own vendor's build information and updated through that vendor's path rather than inferred clean. Precondition: this control changes what counts as proof, not the exposure — it neither patches a host nor detects one already exploited, and with active exploitation confirmed a path that was reachable during the window belongs on the incident path regardless of what the re-test now returns.",
+        "evidence": "Packet: OS command injection (CWE-78) in Bash environment-variable parsing, described as a Shellshock-family flaw; GNU Bash allows remote attackers to execute arbitrary commands via a crafted environment; exploitation is enabled wherever attacker-controlled data reaches a Bash environment such as CGI. poc_available true, active_exploitation confirmed, cisa_kev true with kev_date 2025-10-02, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false, live_patch_notes recording no live-patch tool for this entry and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2017-1000353": {
     "name": "Jenkins Remote Code Execution Vulnerability",
@@ -23498,7 +23783,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries two facts that must be resolved per unit before anything else: a vendor patch is recorded as available with a restart or reboot required and no live-patch path, and the entry's own vector states the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization, with the NIS2, UK-CAF and Essential-Eight gaps recording the affected Archer routers as end-of-life with no fix. So the first requirement is an inventory naming every TP-Link Archer C7(EU) and TL-WR841N/ND(MS) in service with its hardware revision, its running firmware version, and an end-of-support status obtained from the vendor rather than assumed in either direction — the packet gives affected versions only as 'per vendor advisory', so the fixed firmware level has to come from that advisory for that exact model and revision. Units whose revision has firmware carrying the fix are remediation items on the clock that opened with the 2025-09-03 KEV listing, and 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 has not restarted onto it is still executing the vulnerable code and counts as exposed. Units whose revision has no fixed firmware cannot be patched at all and are replacement items needing a dated schedule; a risk acceptance with no removal date leaves a device with a public PoC and confirmed exploitation in service indefinitely. Precondition on the reachability half, which is where this control is most often over-claimed: the injection sits in the Parental Control page, part of the router's web administration surface, so blocking administration from the WAN side bounds who can reach it from the internet — but a home or small-branch router exists to serve the client network attached to it, and every client on that network still reaches the administration surface, so 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. And because active exploitation is confirmed and the flaw yields command execution on the router itself, a unit that was exposed is not remediated 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": "Vector: 'TP-Link Archer C7(EU) and TL-WR841N/ND(MS) contain an OS command injection vulnerability that exists in the Parental Control page. The impacted products could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' affected / affected_versions: 'TP-Link Multiple Routers — see vendor advisory linked in verification_sources for affected version ranges' / 'versions per vendor advisory'. patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes '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.' cisa_kev true, kev_date 2025-09-03, active_exploitation 'confirmed', poc_available true. NIS2-Art21-patch-management gap: 'The affected TP-Link Archer routers are end-of-life with no fix, so patch-management obligations are unmeetable and NIS2 compliance for this KEV-listed command-injection requires device replacement, not patching.' UK-CAF-B4 gap: 'only removing the EoL device from the estate resolves the exposure.' AU-Essential-8-Patch gap: 'Essential-Eight patch maturity presumes a patch exists; for these EoL TP-Link edge devices there is none.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "KEV-listed 2025-09-03 with confirmed exploitation, a public PoC and unauthenticated command execution on the router — and the packet's own framework note that SOHO routers and edge appliances are mass-exploited into botnets and operational-relay networks within days is the reason the ordinary 30-day flaw-remediation window is exposure acceptance here rather than a schedule. What this control requires for these devices is a verified mitigation inside a compressed window measured from the KEV listing, and the end-of-life population forces the point that the mitigation is not always a patch. For an Archer C7(EU) or TL-WR841N/ND(MS) whose hardware revision has firmware carrying the fix, the mitigation is that firmware plus the restart or reboot the packet records as required, verified against the version the unit reports after it has restarted rather than against the version pushed to it. For a revision with no fixed firmware — which the packet's NIS2, UK-CAF and Essential-Eight gaps say is the case for the affected Archer routers — 'no patch available' must not close the item: the documented compensating control is removal of the device from service, or, where it cannot be removed immediately, eliminating any internet-side reachability of its administration surface and isolating the network it serves from anything of value, with a replacement date attached to the record. Precondition: those measures bound who can send the request; they do not repair the Parental Control page's command handling, and any client on the network the router serves still reaches that page, so they are a holding measure until the unit is replaced and never a closure.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-09-03, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 77; attack_vector 'an OS command-injection flaw (CWE-78) enabling unauthenticated remote command execution on the router'. patch_available true, patch_required_reboot true, live_patch_available false ('Vendor patch typically requires service restart or system reboot per the KEV requiredAction'). NIST-800-53-SI-2 gap: '30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE', and framework_coverage for SI-2: 'SOHO routers and edge appliances are mass-exploited into botnets and operational-relay (ORB) networks within days, and many run end-of-life firmware with no available fix.' ISO-27001-2022-A.8.8 gap: 'KEV listing collapses \"patch-cycle response\" to \"incident-speed response\".'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance failure on this entry is a register that marks a TP-Link Archer C7(EU) or TL-WR841N/ND(MS) compliant because it is running the newest firmware available for its model. The packet's structured record says a patch exists, while its vector says the impacted products could be end-of-life or end-of-service and that users should discontinue use, and its NIS2, UK-CAF and Essential-Eight gaps say the affected Archer routers have no fix — which means 'newest available firmware' and 'firmware containing the fix for the Parental Control command injection' are different statements for at least part of this population, and a currency check cannot tell them apart. The operational test for this entry: can the programme produce, per unit, the model, the hardware revision, the running firmware version and the fixed version named in the vendor advisory for that exact revision — and does a revision for which the advisory names no fixed firmware appear as unremediable-pending-replacement rather than as up to date? A second failure mode is specific to this device class: consumer routers usually sit outside authenticated scanning scope, so a scan that never reached the unit reports nothing rather than a finding, and the inventory has to be built from what is physically in service at each site instead of from what the scanner enumerated. Precondition: this test surfaces the exposure and does not reduce it. Units it flags still need firmware carrying the fix and the restart the packet records as required, or replacement — and a unit already exploited needs its configuration and administrative credential rebuilt, since the packet records confirmed exploitation yielding command execution on the router.",
+        "evidence": "Vector states the impacted products 'could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization,' while patch_available is true with patch_required_reboot true and live_patch_available false. affected_versions is recorded only as 'TP-Link Multiple Routers — versions per vendor advisory'. framework_coverage for ISO-27001-2022-A.8.8: \"'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited internet-facing device, and unmanaged/EOL devices fall outside most patch programs entirely.\" AU-Essential-8-Patch gap: 'Essential-Eight patch maturity presumes a patch exists; for these EoL TP-Link edge devices there is none, and the model offers no control for retiring unsupported internet-facing consumer hardware.' active_exploitation 'confirmed'; poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2020-24363": {
     "name": "TP-link TL-WA855RE Missing Authentication for Critical Function Vulnerability",
@@ -24142,7 +24460,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "Apex One is the product the estate relies on for malware defense, and this CVE is that product's own management console accepting attacker input before any authentication decision is made — the packet has a pre-authenticated remote attacker uploading malicious code and executing commands on the on-premise console. Bound to this product, the control means the Apex One console is enrolled in vulnerability management as privileged software in its own right, with the same expedited SLA the estate would apply to any other privileged server, and that security-product audits include the trust-anchor-inversion test rather than only confirming the tool is deployed and reporting. The distinguishing test for this console: on a staging Apex One installation, send an unauthenticated request to the console's upload path carrying OS command metacharacters and confirm it is refused before any command runs on the host. That test is the one that separates paper compliance from the real state here, because an attestation that every Apex One administrator authenticates and holds least privilege passes cleanly while this path is open — the attacker never holds a console account, so the account model the attestation examines is bypassed rather than abused. Preconditions: the input handling is a property the vendor update establishes; this control states what to verify and what SLA tier the product sits in, it does not implement the fix. Until the fixed build named in the vendor advisory and its restart land, restricting which segments can reach the console bounds who can send the request but leaves the endpoint fully exploitable to anything inside a permitted segment, and it is unavailable where the console must stay reachable for agents and administrators to work.",
+        "evidence": "Packet vector: 'Trend Micro Apex One Management Console (on-premise) contains an OS command injection vulnerability that could allow a pre-authenticated remote attacker to upload malicious code and execute commands on affected installations.' cwe_refs CWE-78; cvss 9.8; rwep_score 77; poc_available true; cisa_kev true with kev_date 2025-08-18 and active_exploitation confirmed. NIS2-Art21-network-security gap: 'NIS2 network-security relies on the Apex One console as a protective EDR control; a pre-auth command-injection that runs code on the management server subverts the defense itself, a security-tooling compromise Article-21 does not treat as its own priority class.' NIST-800-53-AC-6 gap: 'Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.' patch_available true; live_patch_available false; live_patch_notes: 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' affected_versions: 'Trend Micro Apex One — versions per vendor advisory.'",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-045",
+        "name": "EDR-PLATFORM-UPDATE-DISTINCT-SLA",
+        "description": "The Apex One management console updates on Trend Micro's own product release channel, which is not the operating-system update channel the estate's patch metrics are usually built on — and that is exactly why the three timing gaps recorded here can all read green while this console stays exploitable. An Essential-Eight control scored on patching operating systems does not look at the Apex One console build at all, and a 30-day flaw-remediation clock is longer than the window the packet describes for a KEV-listed pre-auth RCE. Applied to this product, the control means the on-premise Apex One console is tracked as its own patch surface with its own SLA, driven from the 2025-08-18 KEV listing rather than folded into the next server-patching window, and completion is measured per console on the build the console actually reports against the fixed build named in the vendor advisory — the packet carries no version strings, so the advisory is the reference and 'update approved' or 'update downloaded' in a management view is not the measurement. The packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a console that has taken the update but has not restarted is still executing pre-fix code and must be counted as exposed; on a console that the whole agent fleet reports to, that restart is precisely the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Priority follows the packet rather than the CVSS band alone: a public PoC, confirmed in-the-wild exploitation, and the packet's own note that the in-wild observation may predate the KEV listing by weeks put this ahead of routine server patching.",
+        "evidence": "Packet AU-Essential-8-Patch gap: 'Essential Eight patch targets for internet-facing management consoles trail the KEV window for a pre-auth RCE on the very tool tasked with malware defense.' NIST-800-53-SI-2 gap: '30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE. CISA due date is the operationally-meaningful clock.' ISO-27001-2022-A.8.8 gap: 'Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs.' kev_date 2025-08-18; poc_available true; active_exploitation confirmed; active_exploitation_notes: 'the actual in-wild observation may predate it by weeks.' patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: '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.' affected_versions: 'Trend Micro Apex One — versions per vendor advisory.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet's own framing of the B4 gap is what makes this an IR item rather than a patch item: an unauthenticated OS command injection on the Apex One console inverts the trust the estate places in that console into fleet-wide reach. With active exploitation confirmed and a public PoC recorded, an on-premise console that was reachable during the exposure window is a suspected fleet-control-plane compromise, and applying the vendor update does not resolve it — the update closes the injection path and removes nothing an attacker executed through it. The playbook for this product means: reviewing the console's configuration and the actions it directed at managed endpoints across the suspected window rather than only from the day the update landed, defining quarantine criteria for endpoints that received console-directed actions in that window, and rotating credentials for every account that authenticated to the console during it. Preconditions, both load-bearing here: the console's own logs sit on the host where the packet says commands executed, so the timeline has to be corroborated from an off-host copy or it is evidence the attacker could edit; and the exposure window is not the KEV date — the packet states the in-wild observation may predate the 2025-08-18 listing by weeks, so scoping the review to the listing date understates it. This control governs the response, not the exposure: it does not evict an attacker still resident, and it is not a substitute for the fixed build and the restart the packet requires.",
+        "evidence": "Packet UK-CAF-B4 gap: 'CAF B4 hardening trusts the endpoint-protection console, but a KEV-listed unauth OS-command-injection on Apex One inverts that trust into fleet-wide reach, warranting emergency patching beyond B4's routine expectation.' vector: pre-authenticated remote attacker can 'upload malicious code and execute commands on affected installations' of the on-premise Apex One Management Console. active_exploitation confirmed; poc_available true; rwep_score 77. active_exploitation_notes: 'The dateAdded is the formal KEV listing date; the actual in-wild observation may predate it by weeks.' patch_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-8876": {
     "name": "N-able N-Central Command Injection Vulnerability",
@@ -25405,7 +25754,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet states it outright: CVE-2025-53771 is a patch bypass for this CVE, and the CVE-2025-53771 updates include more robust protection than the ones shipped for CVE-2025-49706. That inverts the usual reading of a remediation record — a SharePoint Server that took the CVE-2025-49706 update and closed the ticket carries a 'patched' verdict against a fix the vendor has since superseded, so the flaw-remediation attestation reads clean while the authentication path it was meant to close stays reachable through the bypass. For this CVE the remediated state is therefore defined by the later build: verify each SharePoint Server against the build carrying the CVE-2025-53771 protections rather than against the update issued for CVE-2025-49706, and hold the two as one open remediation item instead of two closed ones. The packet also names this as the ToolShell chain entry point and records it as chainable with CVE-2025-49704, so the exposure is a sequence on one authentication primitive rather than a discrete ticket — the intake expectation is that further bypasses on the same path are likely and warrant standing monitoring, not a closed record. Precondition, and it is this control's limit: it changes scoring, scheduling and record-keeping and remediates nothing by itself. The packet registers no live-patch path and a vendor patch typically requiring a service restart or system reboot, so a server that has taken the superseding update but not been restarted is still running the vulnerable code.",
+        "evidence": "Packet vector for CVE-2025-49706: 'This vulnerability could be chained with CVE-2025-49704. CVE-2025-53771 is a patch bypass for CVE-2025-49706, and the updates for CVE-2025-53771 include more robust protection than those for CVE-2025-49706.' Packet attack_vector: 'improper authentication (CWE-287) on SharePoint Server — the ToolShell chain entry point — letting an unauthenticated attacker reach the RCE primitives.' cwe_refs CWE-287; cisa_kev true; kev_date 2025-07-22; active_exploitation 'confirmed'; cvss 9.1; rwep_score 83; poc_available true; patch_available true; live_patch_available false; live_patch_notes '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.' Cited as insufficient on this entry: NIST SP 800-53 Rev 5 SI-2 'Flaw Remediation', ISO/IEC 27001:2022 A.8.8, EU NIS2 'Cybersecurity risk-management measures (vulnerability handling and disclosure)', ASD Essential Eight 'Patch operating systems'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "SharePoint Server's authentication check is where the product decides who a caller is, and CWE-287 on this entry is that decision failing. The packet's vector records spoofing performed over a network — a caller presenting an identity it does not hold — and the packet's attack_vector records the consequence as an unauthenticated attacker reaching the RCE primitives at the ToolShell chain entry point. Under either framing the requirement is the same, and that is the point: the privileged SharePoint functions behind the check must establish their caller's authority themselves rather than inheriting a verdict settled once at the front door, and the server's surface must be segmented so a caller with no operational need cannot present the spoofed request at all. This is exactly why the least-privilege and identity-and-access controls cited as insufficient on this entry never engage — the attacker holds no SharePoint account, so no per-account privilege scoping is consulted, no credential is guessed and no second factor is ever requested; an identity-and-access review and a least-privilege attestation both pass cleanly while an unauthorized caller is inside. Distinguishing test: from a segment with no operational need to reach the server, send a staging SharePoint Server requests bearing a spoofed caller identity and confirm each privileged function refuses before it runs; confirming that every named SharePoint user authenticates correctly tests nothing on this path. Precondition: the repair to the authentication decision is the vendor's — this control names the property to verify and the segmentation that bounds who can attempt the spoof; segmentation limits the caller population and closes nothing against anything already inside the permitted segment.",
+        "evidence": "Packet vector for CVE-2025-49706: 'Microsoft SharePoint contains an improper authentication vulnerability that allows an authorized attacker to perform spoofing over a network', with the recorded impact being viewing sensitive information and making changes to disclosed information. Packet attack_vector: 'improper authentication (CWE-287) on SharePoint Server — the ToolShell chain entry point — letting an unauthenticated attacker reach the RCE primitives. CISA KEV-listed 2025-07-22 with confirmed in-the-wild exploitation.' cwe_refs CWE-287; cvss 9.1; rwep_score 83; poc_available true; patch_available true; live_patch_available false. Cited as insufficient on this entry: UK NCSC CAF v3.2 B2 'Identity and access control' and NIST SP 800-53 Rev 5 AC-6 'Least Privilege'.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet places this flaw at the entry of a chain that reaches the RCE primitives, chainable with CVE-2025-49704, with exploitation confirmed from the 2025-07-22 KEV listing and a public PoC — so a SharePoint Server that was network-reachable on an affected build across that window is a triage subject rather than a patch ticket. The update repairs the authentication decision; it revokes nothing obtained while that decision was failing. For an authentication-bypass entry point that means the credentials and cryptographic material the server's application identity holds are rotated as part of remediation rather than as a follow-up, and the content the server hosts and serves is compared against a known-good baseline rather than inferred clean from the absence of an alert. That last point is the specific reason the anti-malware control cited as insufficient on this entry cannot carry the remediation: an artifact written through the application's own request path by an attacker who authenticated as nobody is not a signature-matched sample, so a fully deployed and current anti-malware estate reports clean over it. Preconditions and limits: the rebuild-and-rotate scope is the server's own hosts and its own secrets — an identity outside that scope reached from the foothold is separate containment; and the triage is bounded by an exposure window the operator can actually establish, so a deployment without retained per-request access logs for the period cannot scope the hunt at all, in which case rebuild is the safe default rather than an evidence-driven choice. Note also that the vendor update alone does not settle the exposure here: the packet records CVE-2025-53771 as a patch bypass for this CVE, so the update must be the superseding build and the restart it requires must be completed.",
+        "evidence": "Packet attack_vector for CVE-2025-49706: 'improper authentication (CWE-287) on SharePoint Server — the ToolShell chain entry point — letting an unauthenticated attacker reach the RCE primitives. CISA KEV-listed 2025-07-22 with confirmed in-the-wild exploitation.' Packet vector: 'This vulnerability could be chained with CVE-2025-49704. CVE-2025-53771 is a patch bypass for CVE-2025-49706'. active_exploitation 'confirmed'; kev_date 2025-07-22; poc_available true; cvss 9.1; rwep_score 83; patch_available true; live_patch_available false, with live_patch_notes recording no registered live-patch tool and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction. Cited as insufficient on this entry: CIS Controls v8 10.1 'Deploy and Maintain Anti-Malware Software'.",
+        "gap_closes": [
+          "CIS-Controls-v8-10.1"
+        ]
+      }
+    ]
   },
   "CVE-2025-53770": {
     "name": "Microsoft SharePoint Deserialization of Untrusted Data Vulnerability (variant: CVE-2025-53770)",
@@ -27671,7 +28053,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries the two facts that have to be reconciled per unit before anything else: a vendor patch is recorded as available, and the entry's own vector states the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization. So the first requirement is an inventory that names every ASUS Lyra Mini and ASUS GT-AC2900 in service with its running firmware and a support status obtained from the vendor rather than assumed in either direction. Units whose model still has supported firmware are patch items on the clock that opened with the 2025-06-02 KEV listing; units with no supported firmware cannot be patched at all and are replacement items with a dated schedule, because a risk acceptance with no removal date leaves a device carrying a public PoC and confirmed in-the-wild exploitation in service indefinitely, at a position where it is the network boundary for everything behind it. Scope the inventory to the two models the packet names — no mapping from this authentication flaw into other ASUS models or other consumer routers is established here, and treating every router in the estate as an instance of this CVE manufactures replacement work against hardware no evidence implicates; widen only where a verified source identifies another model carrying the same defect. Precondition on the interim half, which is where this is normally over-claimed: 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 a unit that has taken the firmware but not restarted still runs the vulnerable code and is not remediated; and reaching the fixed firmware closes this defect only, saying nothing about anything found in a model since — which is exactly why the requirement cannot end at 'every unit reports the fixed firmware'. Distinguishing test: produce, per unit, the model, hardware revision, running firmware and the vendor's support status for it, and confirm each unit is either at the fixed firmware or on a dated removal schedule — a patch-compliance report that lists an unsupported model as 'no update available' and closes the item marks an abandoned device compliant while it stays exposed.",
+        "evidence": "Packet name: 'ASUS Routers Improper Authentication Vulnerability'. Vector: 'ASUS Lyra Mini and ASUS GT-AC2900 devices contain an improper authentication vulnerability that allows an attacker to gain unauthorized access to the administrative interface. The impacted products could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' cwe_refs CWE-287; cisa_kev true with kev_date 2025-06-02; active_exploitation confirmed; poc_available true; cvss 9.1; rwep_score 77; patch_available true; live_patch_available false with live_patch_notes '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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The trigger condition this control exists for is present here in the form the packet documents: a pre-authentication flaw on the administrative interface of the device that sits at the network boundary, with confirmed in-the-wild exploitation and a public PoC. The attacker reaches the administrative interface without holding any account, and administrative access means the device's configuration and its stored credentials are attacker-writable — which firmware does not revert. So for any ASUS Lyra Mini or GT-AC2900 that was reachable during the exposure window, the default response is capture the running configuration for analysis, reset to factory defaults and re-provision from a known-good configuration, and rotate the device's administrative credential along with any credential held in or reachable from that configuration — not an in-place firmware upgrade that leaves the attacker's settings intact underneath a version number that now reads clean. Precondition, and it is the half most often skipped: a rebuild restores configuration integrity, it does not deliver fixed code. A unit rebuilt onto firmware that still lacks the fix is exploitable again the moment it is reachable, so the rebuild has to land on the fixed firmware, and where the model has no fixed firmware the rebuild is not a remediation at all — that unit belongs on the replacement schedule rather than being cycled through factory resets. The rebuild also depends on a known-good configuration baseline recorded before the exposure window; where none exists the configuration must be re-entered by hand, because a backup taken during the window carries the attacker's settings forward into the 'clean' device. Distinguishing test: compare each unit's running configuration — administrative accounts, and whether the administrative interface answers from outside the local network — against a known-good baseline, rather than confirming only that the firmware version is current. A fleet where every unit reports fixed firmware while carrying attacker-set administrative configuration passes a patch attestation and stays compromised.",
+        "evidence": "Packet vector: 'ASUS Lyra Mini and ASUS GT-AC2900 devices contain an improper authentication vulnerability that allows an attacker to gain unauthorized access to the administrative interface.' attack_vector: 'an improper-authentication flaw (CWE-287) letting an unauthenticated attacker bypass authentication on the router's administrative interface. CISA KEV-listed 2025-06-02 with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available true; cvss 9.1; rwep_score 77; patch_available true; live_patch_available false with live_patch_notes recording that the vendor patch typically requires service restart or system reboot.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-3935": {
     "name": "ConnectWise ScreenConnect Improper Authentication Vulnerability",
@@ -27731,7 +28136,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's own conditional is why this is a rebuild-and-rotate case rather than a patch ticket: the improper-authentication flaw allows a ViewState code injection attack, which allows remote code execution if machine keys are compromised. Those keys are secret material held by the ScreenConnect server, and applying the vendor update does not change them — so an estate that patches and closes the finding has repaired the injection path while leaving in place the one condition the packet names as turning it into code execution. Bound to this product, remediation of an on-premises ScreenConnect server that was reachable and unpatched during the window opened by the 2025-06-02 KEV listing means: export the server's configuration for offline review before touching it; regenerate the machine keys the ViewState path depends on rather than carrying them across the upgrade; rotate every credential, session and access token the server issued or stored; and default to rebuilding from vendor media wherever the server's state cannot be attested. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot, so a server that has taken the update but not restarted is still running the vulnerable code and must be counted as exposed rather than remediated — a deferred restart recorded as 'patched' is the specific way this goes wrong. Precondition, and it is the one this control is most often recorded without: rotation only holds if the regenerated keys are not reinstated from a pre-incident backup or a configuration snapshot captured during the exposure window, because a rebuild that restores the old machine keys restores exactly the condition the packet names. Rotation also does not retroactively invalidate use already made of the keys before they were changed, so a server inside that window belongs on the incident path and not on the patch record.",
+        "evidence": "Packet vector: 'ConnectWise ScreenConnect contains an improper authentication vulnerability. This vulnerability could allow a ViewState code injection attack, which could allow remote code execution if machine keys are compromised.' attack_vector: an improper-authentication flaw (CWE-287) letting an unauthenticated attacker bypass authentication via ASP.NET ViewState / machine-key abuse. CISA KEV-listed 2025-06-02, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true, live_patch_available false, live_patch_notes: '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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "ScreenConnect is a remote-support server and the packet's stated outcome is code execution on it, which by definition puts everything that server's process can read or write inside the attacker's reach — not the operator console alone, but the artifacts the server serves out, its session and connection configuration, and any credential material stored alongside them. Treat that content as a privileged distribution channel rather than as ordinary application data: file-integrity-monitor the ScreenConnect installation and every directory it serves artifacts from, alert on writes that do not correspond to a sanctioned administrator action or a vendor update, and track the server as a management-plane asset on KEV-priority patching rather than as an internal line-of-business application. This is the half of the response that retains value after the update lands, because the fix closes the authentication bypass but removes nothing placed through it beforehand, and a modified artifact served by a legitimate, trusted support server is not something authentication logging or signature-based endpoint tooling has an artifact to match. Precondition: the monitoring detects a change only against a baseline that predates the exposure window opened by the 2025-06-02 KEV listing — stood up afterwards it baselines whatever is already present and will report clean. Where no such baseline exists, the served content has to be compared against vendor-supplied originals or replaced from them, not certified by the monitor. Note also that the packet conditions the code-execution outcome on machine-key compromise, so this scope applies to servers where that condition cannot be excluded rather than to every install by default.",
+        "evidence": "Packet: ConnectWise ScreenConnect, CWE-287, with the vector stating the ViewState code injection 'could allow remote code execution if machine keys are compromised' and the attack_vector describing an unauthenticated attacker bypassing authentication via ASP.NET ViewState / machine-key abuse. CISA KEV-listed 2025-06-02 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 77. patch_available true; live_patch_available false, with the vendor patch typically requiring a service restart or system reboot per the KEV requiredAction. The entry's citing framework gaps include EU NIS2 Art. 21 supply-chain security measures.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain"
+        ]
+      }
+    ]
   },
   "CVE-2025-35939": {
     "name": "Craft CMS External Control of Assumed-Immutable Web Parameter Vulnerability",
@@ -27935,7 +28362,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "An RT-AX55 is the trust boundary for whatever sits behind it — a home-office or a small branch network — and this entry is the case where the ordinary remediation programme structurally cannot reach the device: the packet's own gaps record that router firmware sits outside standard Essential Eight patch tooling and that CAF's system-security objective assumes centrally-managed network devices rather than SOHO routers whose firmware updates are user-driven. So the requirement here is a remediation tier for the RT-AX55 that does not depend on the estate's software-distribution channel. Enumerate every RT-AX55 in service, including the remote-worker homes and branch closets where these units actually live and where no management console sees them; take the fixed firmware level from the ASUS advisory the packet points to rather than assuming a build, since the entry records affected versions only by reference to that advisory; and drive each unit onto it against the clock that opened with the 2025-06-02 KEV listing rather than a device-refresh cycle. Completion is measured on the firmware the unit is running after its restart, not on a download: the packet records that the vendor patch typically requires a service restart or system reboot and registers no live-patch tool, so a router that fetched firmware and was never restarted is still executing the vulnerable code and must be counted exposed. Where a unit cannot be reached on that clock, the tier's alternative is isolation of the vulnerable interface — the administration surface must not answer from the WAN side, and the segment behind the router is treated as untrusted until the firmware lands. Precondition on that alternative, which is where this control is usually over-claimed: restricting the administration interface bounds who can present the request, but the packet's stated access requirement is a remote authenticated attacker, so every credential holder still satisfies it — including anyone reusing a default or shared password, which the packet's NIS2 gap names as the common condition on this class of edge hardware. Isolation buys the window; it does not close the path.",
+        "evidence": "Packet for CVE-2023-39780, ASUS RT-AX55 Routers OS Command Injection Vulnerability: CWE-78; cisa_kev true with kev_date 2025-06-02; active_exploitation confirmed; rwep_score 77, cvss 9.8; poc_available true; patch_available true; patch_required_reboot true; live_patch_available false with live_patch_notes '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.'; vector 'ASUS RT-AX55 devices contain an OS command injection vulnerability that could allow a remote, authenticated attacker to execute arbitrary commands'; affected_versions 'ASUS RT-AX55 Routers — versions per vendor advisory'; AU-Essential-8-Patch gap 'Router firmware sits outside standard Essential Eight patch tooling, so the 48-hour patch-application window is unreachable on consumer ASUS routers'; UK-CAF-B4 gap 'CAF's system-security objective assumes centrally-managed network devices, not SOHO routers whose firmware updates are user-driven'; NIS2-Art21-network-security gap 'consumer RT-AX55 routers sit at the network edge where default and reused credentials are common'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For an RT-AX55 that was reachable by an untrusted caller during the exposure window, the firmware update is not the end of the work. The packet records confirmed in-the-wild exploitation and a public PoC, and its NIS2 gap names botnet recruitment as what this command injection is used for — so the assumption the runbook must default to is that the box ran attacker code, and reflashing replaces the vulnerable binary while removing nothing the attacker left in the device's configuration. On this product that means specifically: attacker-set DNS servers, port-forwards and firewall rules, a changed or added administrative credential, and any persistence in the router's own settings all survive a firmware update applied in place, and every one of them keeps working after the vulnerability is closed. Credential rotation carries extra weight here because the packet's vector requires an authenticated attacker: the credential that reached the injection is either still valid or has been replaced by one the attacker chose. The runbook for an exposed unit is therefore capture the running configuration as evidence, factory reset, flash the fixed firmware from the vendor advisory, rebuild the configuration from a known-good baseline rather than restoring the saved config file (which is exactly where attacker-set entries would be carried forward), rotate the administrative password and the WLAN pre-shared key, and treat credentials used by clients behind that router during the window as exposed. Boundary of the requirement: this is the default for a unit with plausible exposure during the window, not for every RT-AX55 in the estate — a unit no untrusted caller could reach is a straightforward patch item, and treating them alike wastes the rebuild capacity on the units that need it.",
+        "evidence": "Packet for CVE-2023-39780, ASUS RT-AX55 Routers OS Command Injection Vulnerability: active_exploitation confirmed with cisa_kev true (kev_date 2025-06-02); poc_available true; vector 'a remote, authenticated attacker to execute arbitrary commands'; attack_vector 'an OS command-injection flaw (CWE-78) enabling ... remote command execution on the router'; NIS2-Art21-network-security gap 'making this authenticated command injection a botnet-recruitment vector that network-security obligations do not cover for unmanaged edge hardware'; framework_coverage NIS2-Art21-network-security 'does not address end-of-life devices that can only be replaced, or appliance compromise that requires rebuild rather than patch-in-place'; UK-CAF-B4 gap 'the OS command-injection path on the RT-AX55 falls outside its secure-configuration coverage'; patch_available true with patch_required_reboot true.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The RT-AX55's administration surface is the constrained user surface this control governs, and the packet describes it failing in the exact pattern the control forbids: a remote, authenticated attacker executes arbitrary commands on the device, meaning a management function that should only write a setting is instead passing caller-supplied input into an OS command on the router. Applied to this product, the requirement is that the router's management functions reach system operations only through a constrained, validated interface, so that the administration surface's own parameter handling is not the single thing standing between a logged-in user and command execution at the device's privileged level. This is why the least-privilege gap recorded on this entry cannot close the path: a consumer router's account model is one or two administrative logins, and the flaw needs no privilege beyond what the legitimate user already holds — an attestation stating that only administrators can sign in to the router passes cleanly while any credentialed caller reaches the shell. Precondition: the ASUS firmware update is what repairs that boundary; this control states the property to verify and does not implement it. Until the fixed firmware and its restart land, the only operator-side lever is reducing who can present a request to the administration interface — disabling WAN-side administration, and restricting it to a management segment where the deployment allows one — which bounds the population that can attempt it but does not close it, because every remaining credential holder still reaches the same path, and the lever is simply unavailable on a unit whose administration interface has to stay reachable from the client network it serves.",
+        "evidence": "Packet for CVE-2023-39780, ASUS RT-AX55 Routers OS Command Injection Vulnerability: cwe_refs CWE-78; vector 'ASUS RT-AX55 devices contain an OS command injection vulnerability that could allow a remote, authenticated attacker to execute arbitrary commands. As represented by CVE-2023-41346.'; NIST-800-53-AC-6 gap 'Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.'; NIS2-Art21-network-security gap noting default and reused credentials are common on these edge routers; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2025-4632": {
     "name": "Samsung MagicINFO 9 Server Path Traversal Vulnerability (variant: CVE-2025-4632)",
@@ -28252,7 +28711,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet puts this flaw within reach of an unauthenticated attacker and records the traversal being used in the wild to write to startup paths for code execution, so there is no interior authentication step between a published exploit and the Srimax Output Messenger server — the exposure is the interval between the 2025-05-19 KEV listing and the fixed build actually running. That makes it a KEV-clock item rather than an application-maintenance-window item. Where the clock has to run to is the part that matters for this product: the packet registers no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a server that has taken the update but has not been restarted is still running the vulnerable code and must be counted as exposed. That restart is also the step most likely to be deferred on a messaging server people are working in through the day, and a deferral recorded as 'patched' is indistinguishable on a compliance dashboard from a real fix — which is the specific way this remediation goes wrong. Distinguishing test: read the version off the running Output Messenger service and confirm the restart completed, rather than accepting the change record or the deployment console as evidence. Precondition: this is a deployment clock and nothing more. It settles nothing about a server that was already reachable on an affected build, where the packet's read-and-write primitive makes the question a triage one.",
+        "evidence": "Packet fields for CVE-2025-27920 ('Srimax Output Messenger Directory Traversal Vulnerability'): cwe_refs CWE-22; cisa_kev true; kev_date 2025-05-19; active_exploitation 'confirmed'; cvss 7.5; rwep_score 77; poc_available true; patch_available true; live_patch_available false; live_patch_notes '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.'; ai_discovered false. Packet attack_vector: 'a directory-traversal flaw (CWE-22) in Srimax Output Messenger, letting an unauthenticated attacker read or write files outside the intended directory (used in the wild to write to startup paths for code execution)'. 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'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at file disclosure — it records the traversal being used in the wild to write files outside the intended directory, specifically to startup paths, for code execution. That makes patch-in-place the wrong default for any Srimax Output Messenger server that was reachable on an affected build: the update closes the traversal and removes nothing already written through it. The sequencing is what is specific to this CVE and is easy to get backwards. The packet records the vendor fix as typically requiring a service restart or system reboot, and a reboot is exactly the event that runs whatever an attacker placed in a startup or autorun location — so the enumeration has to come first: compare the server's startup and autorun set, and the filesystem regions the service can write, against a known-good baseline BEFORE taking the restart the patch needs, and rebuild from known-good where that comparison cannot be made cleanly. The read half of the primitive needs its own action rather than the same one: the packet describes access to sensitive files outside the intended directory leading to configuration leakage, so every credential and key present in the server's configuration is treated as disclosed and rotated, not inspected for evidence of use. Preconditions and limits: the packet names no implant, tool or artifact, so the trigger for this runbook is reachability during the exposure window rather than an observed indicator; and rotation reaches only material the server itself held — any credential reused elsewhere in the estate is a separate containment question this control does not cover.",
+        "evidence": "Packet attack_vector for CVE-2025-27920: an unauthenticated attacker can 'read or write files outside the intended directory (used in the wild to write to startup paths for code execution)'. Packet vector: the traversal 'allows an attacker to access sensitive files outside the intended directory, potentially leading to configuration leakage or arbitrary file access'. active_exploitation 'confirmed'; cisa_kev true with kev_date 2025-05-19; poc_available true; patch_available true — the fix exists, which is what makes 'patched' the verdict this control overrides; live_patch_available false with live_patch_notes 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Cited as insufficient on this entry: NIST SP 800-53 Rev 5 SI-2 'Flaw Remediation' and EU NIS2 Directive Art. 21 'Security of network and information systems'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-11182": {
     "name": "MDaemon Email Server Cross-Site Scripting (XSS) Vulnerability",
@@ -33136,7 +33618,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "UniFi OS is the management plane running on the device, and this defect is its authorization decision and its routing decision being taken from two different forms of the same request: the packet has the auth-gateway classifying the raw, percent-encoded URI as a public endpoint while the normalized/decoded request is routed to an authenticated internal service, so encoded '..%2f' sequences smuggle the request out of its intended directory into arbitrary file read and write on the underlying OS. Bound to this product the control has two halves. The endpoint half is that the nginx/unifi-core flow canonicalizes the URI once and takes both the public-versus-authenticated classification and the routing decision from that same normalized form, and that any resolved filesystem path is verified to remain inside the directory the handler is entitled to serve before a file handle is opened — not by stripping traversal sequences from the request string, since the whole defect is that one layer acts on what another has already decoded differently. That half is what the vendor update establishes; this control states the property to verify, it does not implement it. The operator half is that no UniFi OS device is left with its management interface answering from a network with no management role, because the packet's only stated access requirement is network access to the device with no authentication — reachability is the entire exploit precondition. Precondition on that half, which is where it gets over-claimed: restricting reachability bounds who can send the request, it does not repair the URI-handling split, and it is unavailable where the management interface must answer the network the device administers — any host already inside the permitted segment satisfies the packet's access requirement in full. Distinguishing test: from a segment with no management role, send a public UniFi OS endpoint prefix carrying encoded traversal at a staging device and confirm it is refused before any file is read or written; an estate that passes device-account and administrator-MFA attestations still has this path open, because no credential is ever presented on it.",
+        "evidence": "Packet: 'Ubiquiti UniFi OS Path Traversal Vulnerability', CWE-22. Vector: 'The UniFi OS web management interface is reachable by any actor with network access to the device, with no authentication required... the auth-gateway classifies the raw, percent-encoded URI as a public endpoint while the normalized/decoded request is routed to an authenticated internal service, so encoded \"..%2f\" sequences smuggle the request out of its intended directory and yield arbitrary file read/write on the underlying OS', with the KEV description noting accessed files can be 'manipulated to access an underlying account'. cvss 10; rwep_score 79; poc_available true; active_exploitation 'confirmed'; CISA KEV-listed 2026-06-23. 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.' Citing gaps include NIST-800-53-SC-7 (Boundary Protection), UK-CAF-B4 and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The packet describes a management interface that any actor with network access reaches without authenticating, on a device that fronts the network it administers — so the ordinary appliance-patch window does not apply, and the SLA tier for this CVE is vendor firmware deployed within hours of the 2026-06-23 KEV listing, or the management interface isolated from every segment with no management role until it is. The measurement has to be the firmware each unit is actually running, not an update queued, scheduled or downloaded to it, because a device that has taken no restart into the fixed image is still serving the vulnerable request flow. Two things set the priority above the generic patch queue. The packet records CVSS 10, a public PoC and confirmed exploitation with no authentication required, and it names this flaw being combined in the wild with the access-control bypass CVE-2026-34908 and the package-update command injection CVE-2026-34910 to reach an unauthenticated root RCE chain used to drop a Mirai/Gafgyt-derived botnet — so a unit is not remediated by anything that closes this traversal alone; the remediation state to track is the device reaching a firmware level on which all three named defects are closed, tracked as one device outcome rather than three separate vulnerability tickets that can each be marked done at different times. Precondition: the packet registers no live-patch path, so there is no in-place mitigation that removes the defect ahead of the firmware — isolating the management interface is the interim state and it holds only for the segments it actually excludes, which on a device whose management interface must remain reachable to administer the network may be none.",
+        "evidence": "Packet: CISA KEV-listed 2026-06-23; active_exploitation 'confirmed'; cvss 10; rwep_score 79; poc_available true; privileges required none — 'reachable by any actor with network access to the device, with no authentication required'. 'In the wild it is combined with the access-control bypass (CVE-2026-34908) and the package-update command injection (CVE-2026-34910) to reach an unauthenticated root RCE chain used to drop a Mirai/Gafgyt-derived botnet.' 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.' Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2, all cadence-scored.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A UniFi OS device whose management interface answered untrusted requests while on a vulnerable build has to be dispositioned as compromised rather than simply updated. The packet gives the two reasons directly. The primitive is arbitrary file read and write on the underlying OS reached with no credential, so a successful exploit leaves no authentication event to find later, and the firmware update restores the request-handling behaviour while removing nothing that was already written through the write primitive. And the KEV description records that the accessed files can be 'manipulated to access an underlying account', so account access obtained through the read/write path stays valid across the update unless the credential is rotated — while the in-the-wild chain the packet names ends in a Mirai/Gafgyt-derived botnet dropped on the device itself. The response default for an exposed unit is therefore to rebuild it from vendor firmware to a factory-clean state rather than updating in place, re-provision its configuration from a known-good copy rather than preserving the running one, rotate every credential the device held or fronted — its local administrative accounts and anything recoverable from files on it — and review the device's outbound traffic for the botnet activity the packet describes. The distinguishing test is whether the remediation record shows a rebuild and credential rotation alongside the firmware version; a version check reporting the fixed build is exactly the evidence that reads clean while attacker-written content and attacker-held accounts persist, because neither is versioned.",
+        "evidence": "Packet: CWE-22 path traversal yielding 'arbitrary file read/write on the underlying OS' with 'no authentication required'; 'The KEV description notes the accessed files can be \"manipulated to access an underlying account,\" giving credential/account access'; 'In the wild it is combined with the access-control bypass (CVE-2026-34908) and the package-update command injection (CVE-2026-34910) to reach an unauthenticated root RCE chain used to drop a Mirai/Gafgyt-derived botnet.' active_exploitation 'confirmed'; poc_available true; CISA KEV-listed 2026-06-23; cvss 10; rwep_score 79. patch_available true with live_patch_available false — the vendor update is the remediation this control constrains from being applied in place on an already-exploited unit.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-34908": {
     "name": "Ubiquiti UniFi OS Improper Access Control Vulnerability",
@@ -33280,7 +33796,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The defect the packet records is CWE-306 on Splunk Enterprise's PostgreSQL sidecar recovery endpoints: the web application on port 8000 proxies backup and restore file operations to the local PostgreSQL service on port 5435, and those endpoints perform no authentication at all, so any network-reachable caller invokes them. Bound to this product, the control means every recovery, backup and restore function behind the port-8000 web tier authorizes its own caller before it runs, rather than being reachable because it sits behind a front end assumed to have authenticated somebody; and the caller-supplied 'database' parameter is validated as a database identifier instead of being passed through to pg_dump and pg_restore, where the packet shows it becomes a PostgreSQL connection string the attacker can override with his own hostaddr to make the server restore an attacker-supplied dump. This is why the least-privilege control cited as insufficient on this entry never touches the path: the attacker holds no Splunk account, so per-account privilege scoping is never consulted and an access-control attestation covering Splunk roles and capabilities passes cleanly while the endpoints stay open to an unauthenticated caller. Distinguishing test: from a segment with no operational need for Splunk administration, send unauthenticated requests to each recovery endpoint on a staging instance and confirm each is refused before any pg_dump or pg_restore process starts. Precondition, and this is where the control is normally over-claimed: endpoint-side authorization and parameter validation are properties the vendor update establishes — this control states what to verify, it does not implement it. Until that update lands the operator's only lever is limiting who can reach port 8000, and that is a weak lever here, because port 8000 is the product's own web application: restricting it to an administrative segment also removes it from the users the deployment exists to serve, and it does nothing against a caller already inside the permitted segment.",
+        "evidence": "Packet vector: the Splunk Enterprise web application (port 8000) exposes PostgreSQL sidecar recovery endpoints proxied to the local PostgreSQL service on port 5435 that 'perform no authentication, so any network-reachable, unauthenticated attacker can invoke backup/restore file operations (CWE-306)'; 'The attacker controls the database parameter passed to pg_dump/pg_restore, enabling PostgreSQL connection-string injection (e.g. overriding hostaddr) to force the server to restore an attacker-supplied database dump.' CVSS 9.8, RWEP 87, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2026-06-18. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are both recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet supplies every input this clock keys on at once: CVSS 9.8, RWEP 87, a public PoC, confirmed in-the-wild exploitation, and a KEV listing dated 2026-06-18 against a path the packet itself calls pre-auth remote code execution. For this CVE the requirement is that the Splunk Enterprise vendor update run on the KEV clock from that listing rather than being folded into the estate's normal application-patching cadence, with completion measured per instance by the version actually in service rather than by an approval recorded in a change queue. That is the half the cited framework controls do not carry — a patching programme scored on cadence and a technical-vulnerability clause that leaves timescales to the organization both pass their attestations on their own schedule while an unauthenticated network caller still reaches the recovery endpoints. Preconditions the packet sets on the interim window, which is where this control gets over-stated: live_patch_available is false and the packet states remediation is the vendor update plus the named compensating controls until it lands, so there is no mechanism that closes this without taking each instance through the update, and every interim measure is a holding action rather than a fix. Restricting who can reach the port-8000 web tier bounds the population that can send the request; it does not close the endpoint, it does nothing against a caller inside the permitted segment, and it is unavailable wherever that tier has to stay reachable for the deployment's normal use.",
+        "evidence": "Packet: CVSS 9.8, RWEP 87, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2026-06-18. Vector describes an unauthenticated attacker invoking backup/restore operations and the chain escalating 'to pre-auth remote code execution'. 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.' Citing gaps include AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive the packet describes is an arbitrary file create and truncate as the splunk user, reached through lo_export inside an attacker-supplied database dump, and the packet names what the chain does with it: overwriting executable Python scripts in Splunk's application directory, which run as the splunk user when subsequently invoked. That makes Splunk's application directory a code-execution channel rather than application data, and it is the part of this CVE the vendor update does not address — the update closes the unauthenticated endpoint, but a Python file already overwritten through it survives the upgrade and still runs at its next invocation. The requirement is file-integrity monitoring over Splunk's application directory and every path the instance executes from, alerting on writes that do not correspond to a sanctioned administrator action or a vendor update, plus triage of any instance that was network-reachable during the exposure window against a known-good copy rather than closing it on the patch record. The alert has to key on the behaviour the packet documents — a write or truncate to an executable file under the Splunk application directory, performed by the splunk user, outside a change window — because nothing else in this chain emits a signal: the write arrives through the product's own PostgreSQL restore path, so there is no crash, no new binary dropped by an unusual parent, and no exploit-tool signature; a rule watching for process crashes or named tooling would miss an attempt behaving exactly as the packet describes. Preconditions: this depends on a baseline of the application directory captured before the write and on the monitoring records living off-host, because the attacker holds write access as the splunk user — the same identity a locally-stored baseline sits under. An instance with no prior baseline has to be compared against a clean installation of the same version, not against itself. And detection does not prevent the write; it bounds the window to alert-and-response time.",
+        "evidence": "Packet vector: the malicious SQL uses 'lo_export to write arbitrary files as the splunk user, giving an arbitrary file create/truncate primitive. The chain escalates to pre-auth remote code execution by overwriting executable Python scripts in Splunk's application directory, which run as the splunk user when subsequently invoked.' active_exploitation 'confirmed', poc_available true, cisa_kev true with kev_date 2026-06-18. patch_available true; live_patch_available false. NIST-800-53-SI-2 (Flaw Remediation) is recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-48907": {
     "name": "Widget Factory Joomla Content Editor Improper Access Control Vulnerability",
@@ -33493,7 +34041,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Catalyst SD-WAN Manager (formerly SD-WAN vManage) is the management plane the packet names, and the defect sits in its upload handling: the network-reachable web UI/API exposes a file-upload handler that does not validate user-supplied file paths during upload processing, so ../ sequences in a crafted HTTP request select where a privileged write lands. Bound to this product, the control means every file-accepting endpoint on SD-WAN Manager normalizes the caller-supplied destination to an absolute canonical path and rejects it when the resolved result leaves the intended upload directory, with that check performed before the write executes rather than by filtering the request string; and that the endpoint authorizes the caller against what that particular account is entitled to write instead of treating an authenticated session as sufficient. The packet's access requirement is what makes the second half load-bearing on this entry rather than the first alone: the attacker holds only a low-privileged, single-task user account, so on this appliance every account that can authenticate to the web UI/API is in exploit terms a root account on the control plane, and an authorization decision that ends at 'the session is valid' never consults that difference. Distinguishing test: on a staging SD-WAN Manager, authenticate as a single-task, low-privileged user and send each file-accepting endpoint an upload whose destination path resolves outside the intended upload directory; confirm it is refused before anything is written — an instance whose user-role definitions audit cleanly still performs the write if the handler resolves the caller-supplied path. Precondition, and this is where the control is usually over-claimed: the endpoint-side path validation is a property the vendor update establishes, so this control states what to verify and does not implement it. The packet registers no live-patch path for this product class, so until that update and its restart land the only operator-side lever is restricting which segments can reach the web UI/API — which bounds who can present the upload, leaves the handler fully exploitable to anything inside the permitted segment, and is unavailable wherever the interface must stay reachable for operators to manage the fabric.",
+        "evidence": "Packet vector: the web UI/API of Cisco Catalyst SD-WAN Manager (formerly SD-WAN vManage) is network-reachable and exposes a file-upload handler that fails to validate user-supplied file paths during upload processing; an authenticated attacker holding only a low-privileged, single-task user account sends a crafted HTTP request with path-traversal (../) sequences and obtains an arbitrary file create/overwrite primitive anywhere on the underlying operating system. CWE-22. CISA KEV-listed 2026-06-15 with active_exploitation confirmed and poc_available true; RWEP 77 against CVSS 6.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.'",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "This appliance is a fleet control plane in the sense the control governs — the packet states that compromising it yields full compromise of the SD-WAN control plane that pushes policy and routing to every managed edge device — and the packet's escalation path is an attacker overwriting a privileged configuration, cron, or startup file to reach root. That is exactly the case where the patch record and the incident are different questions: the vendor update closes the traversal but reverts nothing already written through it, and a cron or startup file planted before remediation survives the upgrade and keeps running as root. Scoped to what this packet establishes, the playbook for any SD-WAN Manager that was reachable and unpatched during the window opened by the 2026-06-15 KEV listing is: compare the appliance's configuration, cron, and startup content against a known-good baseline instead of accepting the upgraded build as closure; treat every credential and key the controller holds or distributes as exposed and rotate it, since root on the appliance reaches all of it; review the policy and routing pushed to managed edge devices during that window for changes with no corresponding operator action; and set in advance the quarantine criteria for an edge device that accepted configuration from a suspect controller. Precondition: this is post-compromise triage and not prevention — it does nothing to stop the traversal, and it depends on a baseline captured before the exposure window, which is the part most estates do not hold. Where no such baseline exists the comparison cannot be made and the terminal action is rebuilding the controller from vendor media and re-pushing known-good policy, not inspecting it in place.",
+        "evidence": "Packet vector: the arbitrary file create/overwrite primitive is chained by overwriting a privileged configuration, cron, or startup file, or planting executable content, to elevate to root, 'yielding full compromise of the SD-WAN control plane that pushes policy and routing to every managed edge device'. active_exploitation confirmed, CISA KEV-listed 2026-06-15, poc_available true, RWEP 77. patch_available true with live_patch_available false; live_patch_notes state remediation is the vendor update plus the named compensating controls until it lands.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-34028": {
     "name": "Commvault Command Center Path Traversal Vulnerability",
@@ -33548,7 +34120,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The sequence the packet records is what makes the standard cycle indefensible for this CVE: Commvault released patches on 2025-04-10, the advisory and a public watchTowr PoC appeared 2025-04-23/24, a Metasploit module followed, and CISA listed the CVE on 2025-05-02 with a 2025-05-23 due date. A fully weaponized, unauthenticated CVSS 10.0 chain was therefore public roughly two weeks after the fix shipped and three weeks before the KEV due date, and the packet records exploitation as opportunistic and mass-scanning-driven — meaning exposure was a function of being reachable, not of being interesting to an attacker. Applied to this product, the control means the Command Center is driven to a fixed build on the KEV clock rather than in the next backup-infrastructure change window, and completion is recorded per instance against the maintenance pack for that instance's own release line: 11.38.20 via SP38-CU20-433 or SP38-CU20-436, or 11.38.25 via SP38-CU25-434 or SP38-CU25-438. Those are not interchangeable — an estate standardised on the 11.38.25 long-term line is not remediated by a CU20 pack, and the reverse holds too, so a single 'Commvault patched this cycle' line covers instances it never touched. Enumerate both platforms the packet names, Linux and Windows; a sweep of one leaves the other unmeasured. patch_required_reboot is false, which records that no host reboot is required; it does not mean the fix is live on deployment, and live_patch_available is false, so nothing remediates a running Command Center short of taking the maintenance pack — measure on the pack level the running instance reports. Distinguishing test: produce every Command Center instance with its operating system and its running maintenance-pack level and show each is at or above the pack for its line. An instance still on the 11.38.19 build keeps serving deployWebpackage.do to unauthenticated callers no matter how current the surrounding fleet is.",
+        "evidence": "Packet fields for CVE-2025-34028: name 'Commvault Command Center Path Traversal Vulnerability'; affected_versions list 'Commvault Command Center Innovation Release 11.38.0 through 11.38.19 (Linux and Windows)', 'NVD-stated affected range: 11.38.0 to 11.38.20', 'Fixed in 11.38.20 via maintenance packs SP38-CU20-433 and SP38-CU20-436', 'Fixed in 11.38.25 via maintenance packs SP38-CU25-434 and SP38-CU25-438', 'patches released 2025-04-10'; cisa_kev true, kev_date 2025-05-02, framework_control_gaps naming the CISA due date 2025-05-23; active_exploitation 'confirmed'; active_exploitation_notes 'advisory + PoC published 2025-04-23/24 ... exploitation was opportunistic/mass-scanning-driven, accelerated by the public watchTowr PoC and a subsequent Metasploit module'; cvss 10; rwep_score 72; poc_available true; patch_available true; patch_required_reboot false; 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.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The packet puts two distinct defects on one Command Center endpoint, and this control is the statement of what the fixed build has to establish on both. deployWebpackage.do answers without authentication (CWE-306), so any network actor can present a request; and the servicePack parameter selects where content from the fetched ZIP lands (CWE-22), so the caller — not the server — decides the destination path. Bound to this product, the requirement is that the endpoint authorizes its caller before any package is fetched or unpacked at all, and that the destination path is canonicalized and verified to resolve inside the temporary directory before the write executes, so a caller-supplied servicePack value cannot relocate a JSP into a web-accessible path. Precondition: the vendor maintenance pack is what establishes those properties — this control states what to verify, it does not implement it, and it gives nothing to an instance that has not yet taken 11.38.20 or 11.38.25. The half of this control that still has value after the fix lands is the one operators most often skip: the maintenance pack closes the write path and removes nothing already written through it. Exploitation is confirmed, it was mass-scanning-driven, and a public PoC plus a Metasploit module existed before the KEV listing, so an instance that was reachable during that window has to be examined for a planted JSP under its web-accessible paths and for actions taken by the Commvault service account the planted code would run as — an artifact dropped before remediation survives the upgrade and stays executable by anyone who requests it, and no patch-level report will show it. Distinguishing test: on a staging Command Center, send an unauthenticated request to deployWebpackage.do carrying a servicePack value that resolves outside the temporary directory, and confirm it is refused before anything is fetched or written. A system-security attestation recorded as met by 'patches applied in a managed cycle' passes while an unauthenticated endpoint is selecting file destinations from request input.",
+        "evidence": "Packet fields for CVE-2025-34028: cwe_refs CWE-22 and CWE-306; vector 'The Command Center exposes the deployWebpackage.do endpoint without authentication (CWE-306) ... a path-traversal in the servicePack parameter (CWE-22) then relocates a malicious JSP from that temp directory into a web-accessible path. Requesting the planted JSP executes attacker code, yielding unauthenticated remote code execution in the context of the Commvault service account. The chain requires no credentials and no user interaction (CVSS 3.1 = 10.0, AV:N/AC:L/PR:N/UI:N/S:C)'; active_exploitation 'confirmed'; poc_available true with active_exploitation_notes recording the watchTowr PoC (2025-04-23/24) and a subsequent Metasploit module ahead of the 2025-05-02 KEV listing; affected_versions fixed builds 11.38.20 and 11.38.25; framework_control_gaps UK-CAF-B4 'recorded as met by \"patches applied in a managed cycle\"'.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "Commvault Command Center is the console of the backup tier, and the packet's chain ends with code execution in the context of the Commvault service account — the identity the backup platform holds against everything it protects and the data it holds. Reachability is the exploit precondition here in both directions, and both are levers the operator holds during the window before the maintenance pack lands. Inbound: the Command Center web surface should answer only from an operator subnet or an authenticated VPN, not from the internet and not from a general user VLAN. The packet records exploitation as opportunistic and mass-scanning-driven, which means internet reachability rather than targeting is what selected victims — an instance nobody could route to was not in the population regardless of its build. Outbound: the chain's middle link requires the Command Center server itself to fetch an attacker-hosted ZIP, because the endpoint performs no host validation on the fetch, so constraining what the server may reach outbound breaks that link. Preconditions on both halves, because neither removes the surface. Inbound restriction bounds who can present the request and leaves the endpoint fully exploitable to anything inside the permitted segment — a compromised administrator workstation or jump host satisfies it in full — and the console has to stay reachable by the operators who run backups. Outbound restriction narrows where the ZIP can be served from but does not close the path: an attacker-controlled host inside the permitted egress or on an internal range still satisfies it, and a Commvault server that legitimately needs outbound access for vendor or cloud-storage destinations cannot be closed down entirely. Neither substitutes for reaching 11.38.20 or 11.38.25, and neither evicts an attacker who already ran the chain. Distinguishing test: from a general user VLAN and from an external address, attempt to load the Command Center web surface and reach deployWebpackage.do — anything that answers is within reach of the published PoC, and 'the backup console is on the internal network' is a claim about topology, not a demonstration that it is unreachable from untrusted segments.",
+        "evidence": "Packet fields for CVE-2025-34028: affected 'Commvault Command Center'; vector describes the unauthenticated deployWebpackage.do endpoint, a server-side request forgery with 'no host validation' that forces the server to 'download an attacker-hosted ZIP \"install package\"', and remote code execution 'in the context of the Commvault service account' requiring 'no credentials and no user interaction'; active_exploitation_notes 'exploitation was opportunistic/mass-scanning-driven, accelerated by the public watchTowr PoC and a subsequent Metasploit module'; cvss 10 (AV:N/AC:L/PR:N/UI:N/S:C); patch_available true with fixed builds 11.38.20 / 11.38.25; live_patch_available false; framework_control_gaps AU-Essential-8-Patch 'a compliant maturity-level-2 org on its normal cycle remains exposed to this unauthenticated path-traversal to RCE until its next window'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-58136": {
     "name": "Yiiframework Yii Improper Protection of Alternate Path Vulnerability",
@@ -34508,7 +35114,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "clfs.sys ships with Windows and the packet's path into it runs through standard CLFS APIs operating on a crafted base-log (.blf) file, available to any local user — so the affected population is every Windows host in the estate, not a role-scoped subset, and there is no feature to switch off or service to stop that takes the driver out of a normal build. For this CVE the control means driving the Microsoft update that carries the fix across that whole population on the clock that opened with the 2025-04-08 KEV listing rather than folding it 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. The packet registers no live-patch path for this product class and states that remediation is the vendor update plus compensating controls until it lands, so a host that has taken the update but not restarted still runs the vulnerable driver and must be counted as exposed. Priority follows the packet rather than the 7.8 CVSS: from the SYSTEM token this flaw produces, the packet's chain injects into winlogon.exe, dumps LSASS for credentials and launches RansomEXX from dllhost.exe, so a host where the escalation succeeds is a credential-theft and domain-wide ransomware event rather than an endpoint finding. Enumerate multi-user hosts first — session hosts, shared workstations, build agents, jump boxes — because the precondition the flaw needs, a local low-privileged authenticated user running code, is their normal operating state; they are also where the restart is 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 privilege half of the estate's control set cannot substitute here: the attacker already holds a legitimate low-privileged account and the boundary that fails is inside the kernel driver, so tightening account privilege leaves the path intact while its attestation reads clean.",
+        "evidence": "Packet fields for this entry: name 'Microsoft Windows Common Log File System (CLFS) Driver Use-After-Free Vulnerability', CWE-416. Vector and attack_vector: 'A local, low-privileged authenticated user reaches the Common Log File System (clfs.sys) kernel driver through standard CLFS APIs operating on a crafted base-log (.blf) file, triggering a use-after-free (CWE-416) on a freed CLFS structure. The actor leaks kernel addresses to user mode via NtQuerySystemInformation, then weaponizes the dangling pointer together with the RtlSetAllBits primitive to overwrite the exploiting process's token privileges field with 0xFFFFFFFF, granting all privileges and effectively SYSTEM. With SYSTEM, the chain injects into winlogon.exe, dumps LSASS for credentials, and launches RansomEXX from dllhost.exe — turning a post-compromise foothold into domain-wide ransomware impact.' cisa_kev true with kev_date 2025-04-08, active_exploitation confirmed, poc_available true, cvss 7.8, rwep_score 81. 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.' AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "On a Windows estate this control's telemetry is ETW and endpoint-agent event data rather than the auditd or eBPF form it takes on Linux hosts, and the packet describes the exploit precisely enough to key on it rather than on a stand-in. The signature is a same-process privilege transition: a low-privileged process creates or writes a CLFS base-log (.blf) file and drives the CLFS APIs against it, calls NtQuerySystemInformation to leak kernel addresses into user mode, and then keeps running under the same PID with its token privileges field set to all bits. Alert on that transition — a process whose token acquires SYSTEM-equivalent privileges with no corresponding logon, service start, or impersonation event — and correlate it with the follow-on the packet names: code injection into winlogon.exe, a handle opened to lsass.exe with memory-read access, and dllhost.exe spawning a child that is not a COM surrogate workload. The correlation is what makes the rule usable: .blf files are written by legitimate software and NtQuerySystemInformation is called by ordinary tooling, so either signal alone is noise, while the sequence inside a short window is not. Note what would miss an attempt behaving exactly as the packet describes: nothing crashes, no driver is loaded, no service is created, and no new SYSTEM-owned process appears — the escalation happens inside an already-running ordinary process — so rules keyed on crashes, driver-load events, new elevated processes, or named exploit-tool signatures see nothing. Preconditions. This requires endpoint telemetry that was already being collected and forwarded off-host before the attempt, because the moment the token flips the actor holds SYSTEM on that host and can stop or blind a locally-buffered agent, leaving an on-host-only trail under the attacker's control at exactly the point it matters. And detection prevents nothing: it bounds the interval between the escalation and the LSASS dump and ransomware launch to alert-and-response time, during the window before the vendor update and its restart land. It is the interim posture, not the remediation.",
+        "evidence": "Packet fields for this entry: the vector describes the full chain — a crafted base-log (.blf) file driving a use-after-free in clfs.sys, kernel addresses leaked to user mode via NtQuerySystemInformation, the RtlSetAllBits primitive used to overwrite the exploiting process's token privileges field with 0xFFFFFFFF for effective SYSTEM, then injection into winlogon.exe, an LSASS credential dump, and RansomEXX launched from dllhost.exe. cisa_kev true, kev_date 2025-04-08, active_exploitation confirmed, poc_available true, cvss 7.8, rwep_score 81. 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' — the packet itself names compensating controls as what holds until the update. UK-CAF-B4 (System security) is recorded as a citing gap against this entry, and its stated shortfall is precisely this: an interim compensating-control posture for an actively-exploited local privilege escalation with a public PoC is not enumerated as distinct from applying the vendor patch.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-30406": {
     "name": "Gladinet CentreStack and Triofox Use of Hard-coded Cryptographic Key Vulnerability",
@@ -34901,7 +35530,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "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. The packet records a vendor patch with no live-patch path and states that 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: the packet records that 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'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "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 packet records the end state as a reverse shell and names no implant, tooling or artifact, 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'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-9874": {
     "name": "Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (unauthenticated)",
@@ -34956,7 +35608,42 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "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 packet says 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 packet records the outcome as 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.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "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.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "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: the packet records 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.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2017-12637": {
     "name": "SAP NetWeaver Directory Traversal Vulnerability",
@@ -35011,7 +35698,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "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: the packet records original in-the-wild exploitation in August 2017 and a CISA listing 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 the packet states 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.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this entry a version-alone verdict is demonstrably wrong, and the packet says why: 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.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "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.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-48248": {
     "name": "NAKIVO Backup and Replication Absolute Path Traversal Vulnerability",
@@ -35682,7 +36402,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Win32k kernel subsystem and describes an attacker who already holds low-privilege local code execution winning a race to turn a use-after-free on the W32PROCESS structure into a controlled kernel write/execute primitive and a SYSTEM token — the escalation executes in kernel code, below every account boundary an endpoint estate is audited on. For this CVE the control means the Windows update carrying the fix is driven on the clock the 2025-03-11 KEV listing opened rather than folded into the next monthly rollup, with completion measured by the build each host is actually running rather than by 'approved' or 'downloaded' in the management console. The population to enumerate first is the one the packet names — hosts on affected builds predating 1809 — not the Windows estate at large, which the packet does not implicate. The prioritisation half is the load-bearing one here, because every routine escalation trigger points the wrong way: CVSS 7.0, a vendor rating of Important rather than Critical that the packet attributes to the race that must be won, and poc_available false. A program that accelerates on severity band or on public-exploit availability leaves this on the ordinary cycle while the packet records exploitation as confirmed and the flaw already wired into a delivery chain behind the PipeMagic backdoor. Precondition: the packet registers no live-patch path, so nothing removes the defect before the update lands — the compensating controls named on the entry are a holding measure for that window, not a substitute for the update. And because this is a second-stage escalation reached only after an initial foothold, updating a host that was already exploited closes the escalation path without removing the foothold that reached it or undoing what was done with SYSTEM; such a host belongs on the incident path, not on the patch record.",
+        "evidence": "Packet: 'Microsoft Windows Win32k Use-After-Free Vulnerability', CWE-416. Vector: 'An attacker who already has low-privilege local code execution on an affected, pre-1809 Windows build triggers a use-after-free in the Win32k kernel subsystem: by winning a race condition, the W32PROCESS structure is dereferenced one more time than its reference count allows... escalating the process token to SYSTEM', the bug 'reached only after initial foothold (here, via the PipeMagic backdoor)', a 'second-stage local privilege escalation' with follow-on 'credential theft, persistence, and ransomware staging', and 'The high attack complexity reflects the race that must be won, which is why Microsoft rated it Important rather than Critical.' CISA KEV-listed 2025-03-11; active_exploitation 'confirmed'; cvss 7; rwep_score 59; poc_available false; 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, NIS2-Art21-vulnerability-management and UK-CAF-B4 as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "This is a Windows kernel-mode flaw, so the rule is built on host kernel/process telemetry rather than on auditd or eBPF — and the packet describes the behaviour precisely enough to key on it. The exploit has to win a race, and a race is repetitive: a low-privileged user-mode process drives the same Win32k path in a tight loop, many attempts in a short window from one process and its threads, before the timing lands. The rule therefore keys on that shape, paired with the outcome the packet names: that same already-running low-privileged process afterwards holding a SYSTEM token — a token and integrity-level transition inside a live process with no service start, no consented elevation and no scheduled task to account for it — followed by SYSTEM-context activity from a process whose parent chain is an ordinary user session. Both halves are needed: repeated Win32k calls alone are noisy, and a SYSTEM-context process alone is normal; it is the pairing inside a short window that separates this from either. Note what will not see it. Do not key on a crash or bugcheck: the packet's chain grooms the pool to reclaim the freed allocation with attacker-controlled data and continues into credential theft, persistence and ransomware staging, which requires the host to keep running. Do not key on a driver load or a new signed binary — nothing is loaded, the vulnerable code is the operating system's own Win32k, and the exploit runs from a foothold already on the host. Do not key on a public exploit's signature: the packet records poc_available false, so there is no public tool artefact to match. Precondition: this needs kernel-level process and token telemetry already being collected and shipped off-host before the attempt; a rule written afterwards against telemetry nobody was gathering produces nothing. Detection does not prevent the escalation and does not remediate the flaw — it bounds the window between the KEV listing and the update, and because the packet places the bug after an initial foothold, an alert here is an incident already in progress: the response is host isolation and hunting the delivery-stage implant, not only applying the update.",
+        "evidence": "Packet: CWE-416 use-after-free in the Win32k kernel subsystem, exploited 'by winning a race condition' and turned into 'a controlled kernel write/execute primitive, escalating the process token to SYSTEM'; reached 'only after initial foothold (here, via the PipeMagic backdoor)' and used for 'credential theft, persistence, and ransomware staging'. active_exploitation 'confirmed'; CISA KEV-listed 2025-03-11; poc_available false; patch_available true; live_patch_available false, so every affected host carries an exposure window until the vendor update lands.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-45659": {
     "name": "Microsoft SharePoint Server Deserialization of Untrusted Data Vulnerability",
@@ -35737,7 +36480,22 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_disclosure",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's timing is the whole argument on this entry: KEV listing 2026-07-01 with a due date of 2026-07-04 — three days — against SharePoint Server, which in most estates is patched inside a scheduled farm-maintenance window measured in weeks. Applied to this CVE the control means the SharePoint update is driven on the KEV clock rather than folded into the next farm window, and completion is measured per server against the fixed build, not per farm: a farm is remediated only when every server running the SharePoint Server product has taken the update, and one that has updated some of its servers still answers requests on the rest. The population to enumerate first is any farm whose authenticated surface is open to a broad user base, because the packet describes the attacker as authorized — the account is legitimate, so the deserialization path is reachable by whoever already holds a SharePoint account rather than by an attacker who must first defeat authentication, and tightening per-account privilege does not close it. Precondition: the packet records no live-patch path for this product class and gives the vendor update as the remediation, so there is no interim measure here that removes the deserialization sink — the clock is met by the update landing on every affected server, not by a compensating rule, and a server that has taken the update but not been through the restart the product class requires has not met it. Priority follows the packet rather than the CVSS band or PoC availability: no public PoC is recorded, but exploitation is confirmed in the wild and the KEV due date is three days after listing, so the absence of a published exploit is not a reason to run the standard window. Because exploitation is confirmed, a farm reachable by any account holder during the exposure window needs triage of what ran on it rather than being closed on the patch record.",
+        "evidence": "Packet name: 'Microsoft SharePoint Server Deserialization of Untrusted Data Vulnerability' (CWE-502). Packet vector: 'Deserialization of untrusted data in Microsoft Office SharePoint allows an authorized attacker to execute code over a network.' Packet attack_vector adds: 'CISA KEV-listed 2026-07-01 (due 2026-07-04) with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available false; CVSS 8.8; 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 (or, for end-of-life products, decommissioning) plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-48558": {
     "name": "SimpleHelp Authentication Bypass Vulnerability",
@@ -36916,7 +37674,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_disclosure",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-058",
+        "name": "CLOUD-CONTROL-PLANE-CROSS-TENANT-CLAIM-VALIDATION",
+        "description": "Partner Center is not software an operator runs, so the usual expression of this control — patch the thing, then verify — has no target here. What the operator holds is the relationship the packet names: Partner Center brokers access into downstream customer tenants, so an unauthenticated privilege escalation inside partner.microsoft.com lands on the delegated grant rather than on any one organisation's server. Bound to this service the control means the cross-tenant calls a partner identity makes into a customer tenant carry a validated originating-tenant claim and are logged into a channel the customer controls rather than only into the partner's own console, and that the customer side actively watches that channel for partner-attributed actions no engagement explains — privileged-role assignments, application consents, and administrative operations arriving through the delegated path outside a scheduled piece of work. For a downstream customer this monitoring is the only lever that would have surfaced abuse of this flaw at all, because nothing in that customer's vulnerability register ever contained partner.microsoft.com and no scan of their estate would have shown anything. The distinguishing test is attribution rather than inventory: pull the customer tenant's privileged-operation log across the exposure window and show, for each partner-originated action, which engagement authorised it — an organisation that can name its partners but cannot attribute their individual actions has no way to separate this exploitation from routine delegated administration. Two preconditions, both load-bearing: originating-tenant claim validation is a property of the identity provider and not something a customer implements, so the customer's half is the monitoring and the scoping of the grant itself; and monitoring detects rather than prevents — it depends on audit data having been retained and reachable from before the 2025-02-25 KEV listing, and it does nothing about privilege already exercised during the window.",
+        "evidence": "affected_versions records 'Microsoft Partner Center (partner.microsoft.com online service) prior to the November 2024 server-side fix; remediated automatically in the cloud service', and patch_required_reboot is false — there is no operator-side installation step. The vector is 'An improper access control vulnerability in Partner.Microsoft.com allows an a unauthenticated attacker to elevate privileges over a network' (CWE-269, CVSS 8.7). active_exploitation is confirmed: the packet records that Microsoft detected exploitation in the wild but has not published attribution, delivery, or victim specifics, and that CISA added it to KEV on 2025-02-25 with a 2025-03-18 deadline. The downstream scope is the packet's own: Partner Center 'sits on a Power Apps backend used by MSPs and enterprises to manage cloud services and customer tenants', and 'Because Partner Center brokers access to downstream customer tenants, successful privilege escalation carries lateral-movement/supply-chain risk.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "This entry needs an incident playbook rather than a remediation task because its remediation already happened without the operator: the packet records the fix as server-side and applied automatically in the cloud service, so every patch-shaped obligation on this CVE completes itself while confirmed in-the-wild exploitation ran against Partner Center before the November 2024 fix landed. Partner Center is the fleet control plane in this case — the packet places it on a backend used by MSPs and enterprises to manage cloud services and customer tenants — so the unit of compromise is the delegated relationship, not a device. The playbook for this CVE covers both sides of that relationship: enumerate every delegated administrative grant the partner organisation holds into customer tenants and every grant a customer tenant has issued to a partner; review privileged-role assignments, application consents and administrative actions in each downstream tenant across the window that closed with the November 2024 fix; rotate credentials and re-consent applications for any identity that acted through the delegated path during it; and write the criteria that put a downstream tenant in scope rather than assuming it clean. Preconditions: this detects and recovers, it does not close the escalation path — only Microsoft's server-side change closes that — and it reaches only as far back as each tenant's retained audit data, so where retention is shorter than the exposure window the honest output is an unknown rather than a clean finding. That distinction matters more than usual here because poc_available is false and the packet records no published attribution, delivery or victim specifics, leaving an operator with no indicator list to match against and nothing to reason from except the delegated grants themselves.",
+        "evidence": "patch_available is true but affected_versions states the service was 'remediated automatically in the cloud service' after the November 2024 server-side fix, and patch_required_reboot is false; live_patch_available is false, with live_patch_notes recording that remediation for this product class is the vendor update plus compensating controls until it lands. active_exploitation is confirmed — 'Microsoft confirmed it detected exploitation in the wild but has not published attribution, delivery, or victim specifics' — and poc_available is false. CISA KEV listing 2025-02-25, due 2025-03-18. The control plane's reach is from the packet: Partner Center 'sits on a Power Apps backend used by MSPs and enterprises to manage cloud services and customer tenants' and 'brokers access to downstream customer tenants'.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-20953": {
     "name": "Oracle Agile Product Lifecycle Management (PLM) Deserialization Vulnerability",
@@ -36971,7 +37751,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The load-bearing fact on this entry is the interval. Oracle shipped the fix for the Agile PLM Export component in the January 2024 Critical Patch Update, and CISA did not list the CVE until 2025-02-24 with a 2025-03-17 due date — roughly a year later, on confirmed in-the-wild exploitation. So for this CVE the control is not 'respond faster than disclosure'; it is that a KEV listing must re-open an item the organization already triaged and closed. An 8.8 that requires a low-privileged account, on an internal supply-chain application, is exactly the shape of finding that a January 2024 patch review defers behind internet-facing work — and nothing in a normal vulnerability-management cycle revisits that decision when the same CVE is listed thirteen months later. Bind the SLA to the KEV listing date, not to the CVE's publication date, and run it against the population the packet names: every Oracle Agile PLM 9.3.6 deployment with the Export component, remediated by the January 2024 CPU. patch_required_reboot is false on this entry, which records that no host reboot is required; it does not mean the fix is live on deployment, and live_patch_available is false, so there is no path that remediates a running instance without taking the update — completion must be measured on the CPU level the running PLM instance reports, not on a change ticket that says the CPU was applied. Distinguishing test: produce, per instance, the patch level the application is actually executing and show it is at or above the January 2024 CPU. A vulnerability-management attestation recording the CPU as approved, downloaded, or scheduled passes cleanly while a 9.3.6 instance keeps serving the vulnerable ExportServlet. Precondition on how this is prioritised against other KEV work: the packet records poc_available false and exploitation requiring a low-privileged authenticated account, and describes the CVE as most plausibly a post-initial-access step rather than an internet-wide mass-exploitation event. That lowers the likelihood of an untargeted hit; it does not lower the consequence, which the vector states as takeover of Oracle Agile PLM.",
+        "evidence": "Packet fields for CVE-2024-20953: name 'Oracle Agile Product Lifecycle Management (PLM) Deserialization Vulnerability'; affected_versions 'Oracle Agile PLM 9.3.6 (Export component); fixed by the January 2024 CPU'; cisa_kev true with kev_date 2025-02-24 and framework_control_gaps naming the CISA due date 2025-03-17; active_exploitation 'confirmed'; active_exploitation_notes state the flaw was 'patched in Oracle's January 2024 Critical Patch Update and reported via Trend Micro ZDI' and that CISA added it to KEV 'roughly a year after the patch'; poc_available false; rwep_score 44; cvss 8.8 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; patch_available true; patch_required_reboot false; 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.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "Agile PLM's Export component is the endpoint this control governs. The packet places a CWE-502 Java deserialization sink in the ExportServlet, reachable over HTTP, and the CVSS vector records PR:L — the attacker holds a legitimate low-privileged PLM account, so no authentication boundary is bypassed and the endpoint's willingness to reconstruct arbitrary objects out of request content is the entire defect. Bound to this product, the control means the Export endpoint must not let arriving content decide what gets instantiated, and the PLM application must not inherit its safety from the assumption that an internal supply-chain system is only reached by trusted staff — that assumption is precisely what makes a PR:L flaw get scored as low-risk and deferred. Be clear about which half of this control is not a lever here: peer authentication on the listener is already present and the attacker passes it, so requiring authentication changes nothing on this path. The load-bearing half is constraining what the endpoint deserializes, and that property is established by the January 2024 CPU — this control states what to verify, it does not implement it. Precondition on the network half: restricting which segments can reach the PLM HTTP surface bounds the population that can present a request, but the packet's stated access requirement is network access via HTTP plus a low-privileged account, so any compromised or misused PLM user credential inside a permitted segment satisfies that requirement in full. Segmentation bounds who can reach the sink; it does not close it, and it is unavailable to the extent PLM must stay reachable by its normal user population — which, for a product-lifecycle system, is most of engineering and supply-chain operations. Distinguishing test: from a low-privileged account on a staging PLM instance, submit a serialized object to the Export component and confirm it is refused before deserialization runs. A system-security attestation recorded as met by 'patches applied in a managed cycle' — the wording the packet itself records for this control — says nothing about whether the endpoint deserializes untrusted content, and passes cleanly while it does.",
+        "evidence": "Packet fields for CVE-2024-20953: cwe_refs CWE-502; vector 'Vulnerability in the Oracle Agile PLM product of Oracle Supply Chain (component: Export). The supported version that is affected is 9.3.6. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Agile PLM. Successful attacks ... can result in takeover of Oracle Agile PLM' with CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; active_exploitation_notes 'A Java deserialization RCE in the Oracle Agile PLM ExportServlet ... Because exploitation requires low-privileged authentication, it is most plausibly used as a post-initial-access step for code execution/takeover of the PLM host'; framework_control_gaps UK-CAF-B4 'CAF B4 (system security) is recorded as met by \"patches applied in a managed cycle\"'; patch_available true (January 2024 CPU per affected_versions); live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2017-3066": {
     "name": "Adobe ColdFusion Deserialization Vulnerability",
@@ -37026,7 +37830,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The fix here predates the KEV listing by years — the packet records Adobe patching in April 2017 via APSB17-14 against a KEV listing of 2025-02-24 with a 2025-03-17 due date — so the control's 'whichever is later' branch resolves to the listing, and the deliverable is per-instance version proof rather than patch acquisition. Do it per branch, because the packet gives three of them and they do not share a fixed level: ColdFusion 2016 must reach Update 4, ColdFusion 11 must reach Update 12, and ColdFusion 10 must reach Update 23. An estate that upgrades its ColdFusion 2016 instances and closes the ticket while a ColdFusion 10 or 11 instance sits below its own fixed update is still fully exposed, and this is the common shape because the older branches are the ones that fall outside managed software distribution. On completion measurement: patch_required_reboot is false, which records that no machine reboot is required — it does not mean the fix is live the moment the installer finishes. The packet puts the defect in the Apache BlazeDS library used by ColdFusion, library code the ColdFusion server process has loaded, so the instance keeps executing pre-fix code until it is running the updated build; measure completion on the update level the running ColdFusion instance reports, not on the installer having run. One further thing patch_available: true does not establish — that the branch an instance runs is still receiving fixes. The packet records a fix for this CVE at each of the three named update levels and no end-of-support status for any branch, so where an instance's branch support status is unknown, resolve it with the vendor before recording that instance as remediated; an instance sitting at a 2017-era update level on a branch that no longer receives fixes is closed against this CVE and open to everything found in it since.",
+        "evidence": "Packet fields for CVE-2017-3066: vector names Adobe ColdFusion 2016 Update 3 and earlier, ColdFusion 11 update 11 and earlier, and ColdFusion 10 Update 22 and earlier with a Java deserialization vulnerability in the Apache BlazeDS library leading to arbitrary code execution; affected_versions give the fixed levels as ColdFusion 2016 Update 4, ColdFusion 11 Update 12, and ColdFusion 10 Update 23; active_exploitation_notes record an unauthenticated Java deserialization RCE in the BlazeDS AMF handling used by Adobe ColdFusion, patched by Adobe in April 2017 (APSB17-14), with CISA adding it to KEV on 2025-02-24 (due 2025-03-17); cisa_kev true, active_exploitation confirmed, poc_available true; cvss 9.8, rwep_score 68; patch_available true, patch_required_reboot false, live_patch_available false with live_patch_notes recording no live-patch path for this product class.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The packet records this as an unauthenticated deserialization RCE in the BlazeDS AMF handling, which means the ColdFusion message endpoint deserializes attacker-supplied objects before any authentication decision is reached — the AMF path, not the ColdFusion login page or the administrator console, is the trust boundary. Applied to this deployment: enumerate which ColdFusion instances genuinely serve Flex/AMF remoting to clients and which merely have the handler present because it ships with the server. For the second group, restrict reachability of the AMF remoting path to nothing at all from untrusted networks, and do it at the network or web-tier layer rather than inheriting safety from 'ColdFusion sits behind the web server' — the packet's stated exploitation population is internet-exposed ColdFusion servers, which is the topology that assumption produces. Precondition, and this is where a reachability control is usually over-claimed: restricting who can send the AMF message bounds the population that can attempt it and repairs nothing in the deserialization. Any host inside the permitted segment retains the full pre-auth path, and on an instance whose application genuinely serves AMF remoting to client software there is no segment that removes it — for those instances only the branch's fixed update level closes anything. Treat this as a holding measure for the window before the update, not a closure, and record it that way rather than as a mitigated finding.",
+        "evidence": "Packet fields for CVE-2017-3066: vector records a Java deserialization vulnerability in the Apache BlazeDS library in Adobe ColdFusion 2016 Update 3 and earlier, ColdFusion 11 update 11 and earlier, and ColdFusion 10 Update 22 and earlier, with successful exploitation leading to arbitrary code execution; cwe_refs CWE-502; active_exploitation_notes describe it as an unauthenticated Java deserialization RCE in the Apache BlazeDS AMF handling used by Adobe ColdFusion, long a favorite of opportunistic and targeted actors against internet-exposed ColdFusion servers because it is pre-auth and has mature public tooling; poc_available true, active_exploitation confirmed, cvss 9.8; the UK-CAF-B4 gap on this entry records CAF B4 system security being treated as met by 'patches applied in a managed cycle'.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "ColdFusion is an application server rather than a firewall or VPN appliance, but this entry satisfies every condition the control keys on: a pre-authentication RCE, confirmed active exploitation, and public tooling the packet describes as mature and long-favoured against internet-exposed instances, with the observed outcome being webshell drops and server takeover. That combination is precisely the case where patch-in-place yields a compliant record and a still-owned server. Applying ColdFusion 2016 Update 4, 11 Update 12, or 10 Update 23 closes the BlazeDS deserialization path and removes nothing an attacker already wrote through it — a webshell placed in the application's web-accessible content is ordinary content to the updater and survives it untouched, and no version check will surface it. So for any instance that was reachable from untrusted networks while below its branch's fixed update level, the default is not patch-and-close: extract configuration and application content for comparison against a known-good copy, rebuild the instance at the fixed update level, and rotate every credential the ColdFusion service held or could read. The 2025-03-17 CISA due date is the clock for the update; the compromise assessment is not bounded by it and should not be closed with it. Precondition: this is the default for an instance whose exposure during the vulnerable period cannot be ruled out. Where an instance is demonstrably unreachable from untrusted networks throughout — established from network evidence, not from an assertion about where the server sits — the update alone is proportionate, and that determination should be written down rather than assumed.",
+        "evidence": "Packet fields for CVE-2017-3066: active_exploitation_notes record an unauthenticated (pre-auth) Java deserialization RCE with mature public tooling, long a favorite of opportunistic and targeted actors against internet-exposed ColdFusion servers, typically leveraged for webshell drops and server takeover of legacy ColdFusion deployments, with CISA adding it to KEV on 2025-02-24 (due 2025-03-17) reaffirming ongoing exploitation; active_exploitation confirmed and poc_available true; affected_versions name the fixed levels ColdFusion 2016 Update 4, ColdFusion 11 Update 12, and ColdFusion 10 Update 23; patch_available true with live_patch_available false and live_patch_notes recording that remediation is the vendor update plus the named compensating controls until it lands; the NIS2-Art21-vulnerability-management gap on this entry records that a documented vulnerability-handling procedure satisfies the obligation on paper.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-24989": {
     "name": "Microsoft Power Pages Improper Access Control Vulnerability",
@@ -37352,7 +38187,38 @@
         "adequate": false,
         "gap": "Patch cadence alone doesn't help sites still on end-of-support Joomla 3/4 branches, which needed separate back-ported fixes (3.1.1 / 3.4.10)."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry is unusually short and the packet states it: CISA added the Page Builder CK flaw to KEV on 2026-07-07 with a due date of 2026-07-10 — three days against an unauthenticated arbitrary file upload that leads to full RCE, with a public PoC and confirmed exploitation. For this product the verified mitigation is the extension update: every Joomla site running Page Builder CK 3.5.10 or earlier moves to a fixed release, and sites on end-of-support Joomla 3/4 branches take the separately back-ported fixes (3.1.1 / 3.4.10) rather than being recorded as unremediable. Completion is measured per site, on the Page Builder CK version the site is actually serving — an agency or hosting operator will have this extension installed at different versions across many Joomla sites, an inventory built from a single reference install proves nothing about the rest, and one un-updated site is unauthenticated RCE. Precondition on this control's compensating-control branch: the only interim lever available on a public website is a request-filtering rule at a reverse proxy or WAF in front of the front-end upload endpoint, and it holds only where every request reaches the site through that proxy — a site published directly, or reachable on a second hostname or on its origin IP, bypasses the rule entirely. And because exploitation is confirmed and the packet records webshells being planted on connected sites, a site that served a vulnerable version needs its web root compared against a known-good copy and its credentials rotated: updating the extension closes the upload path but does not remove a PHP file already written through it.",
+        "evidence": "Packet: cisa_kev true, 'CISA added this to KEV on 2026-07-07 (due date 2026-07-10) citing active exploitation; multiple reports describe webshells being planted on connected Joomla sites through the flaw'; active_exploitation 'confirmed'; poc_available true; cvss 9.8; affected_versions '<= 3.5.10'; vector 'The Joomla extension Page Builder CK is vulnerable to an unauthenticated arbitrary file upload that allows uploading executable files and leads to full RCE'; patch_available true, patch_required_reboot false, live_patch_available false. AU-Essential-8-Patch gap names the back-ported fixes '(3.1.1 / 3.4.10)' for end-of-support Joomla 3/4 branches; the NIS2-Art21-network-security gap records WAF/reverse-proxy rules as 'the practical compensating control while the flaw was unpatched'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "Page Builder CK is a Joomla extension whose front-end surface is wired directly to a privileged operation: the packet describes an upload endpoint that accepts a caller-chosen destination folder and file type, gated only by a publicly-readable CSRF token, so an unauthenticated attacker scrapes the token from a public page and writes an executable PHP file into a web-accessible path. That is the pattern this control forbids — a user-facing surface reaching a filesystem write the web server will subsequently execute. Read the privilege precisely for this product: what the attacker obtains is code execution in the context the web server runs Joomla as, which the packet calls full RCE; it is not a root operation, and the requirement here is the authorization boundary, not a claim about the account reached. A CSRF token is a replay defence and carries no identity, which is why the identity-and-access gap recorded on this entry cannot close the path: the attacker never holds a Joomla account, so no account model or privilege assignment is ever consulted and an access-control attestation passes cleanly while the endpoint stays open. Bound to this extension, the property to verify is that the front-end upload path makes its own authorization decision before any write occurs, and that the destination directory and the permitted file types are fixed server-side rather than taken from the request, so no caller input selects where the file lands or whether it is executable. Distinguishing test: on a staging Joomla site, take a CSRF token from a public page and post a PHP file with a chosen destination folder to the Page Builder CK front-end upload endpoint, and confirm the request is refused before anything is written. Preconditions: the vendor update establishes that boundary — this control states the property to verify, it does not implement it — and a Joomla site's front end must remain publicly reachable, so unlike a management interface there is no segment to withdraw it into. The only pre-update lever is the proxy rule blocking that endpoint, which covers only traffic traversing the proxy and does nothing about a webshell already planted.",
+        "evidence": "Packet affected field: 'Page Builder CK extension for Joomla (Joomlack) — front-end upload endpoint accepts a caller-chosen destination folder and file type, gated only by a publicly-readable CSRF token'. attack_vector: 'An unauthenticated attacker scrapes a CSRF token from a public page, then uses it to call Page Builder CK's front-end upload endpoint with an arbitrary destination folder and a PHP payload, achieving RCE without any real authentication check.' cwe_refs CWE-434. NIST-800-53-CM-7 gap: 'Least-functionality controls should prevent an unauthenticated caller from choosing an arbitrary upload destination, but the extension exposed that as normal front-end behavior.' UK-CAF-B2 gap: 'Identity and access management guidance doesn't address an endpoint whose only \"authentication\" is a publicly-readable anti-CSRF token.' NIS2-Art21-network-security gap: WAF/reverse-proxy rules 'were the practical compensating control while the flaw was unpatched, but aren't mandated for third-party CMS plugins by default.' active_exploitation 'confirmed', with webshells planted.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet names a second population that the extension update alone does not resolve: Joomla sites still on end-of-support Joomla 3 and 4 branches, which needed the separately back-ported Page Builder CK fixes (3.1.1 / 3.4.10). On those sites taking the back-port closes this CVE, but it leaves the site on a Joomla core branch that receives no further security maintenance — so it is an interim state and the terminal state is migration to a supported Joomla branch or retirement of the site. The requirement is an inventory that records, per site, the Joomla core branch alongside the Page Builder CK version: sites on supported branches run against the KEV clock (listed 2026-07-07, due 2026-07-10), and sites on end-of-support branches carry a dated migration schedule. A risk acceptance with no migration date is what this control exists to prevent — the next extension or core defect on an end-of-support branch may have no back-port at all, and this entry already demonstrates a KEV-listed unauthenticated file upload reaching full RCE on exactly that population. Scope this to what the packet establishes: the vulnerable component is the Page Builder CK extension at 3.5.10 and earlier on Joomla, so the inventory covers Joomla sites running that extension. The packet gives no mapping from this defect into other CMS platforms or other page-builder extensions, so treating every third-party plugin in the estate as an instance of this CVE manufactures migration work against software no evidence implicates. Precondition: migrating to a supported branch does not clean a site that was already exploited — the packet records confirmed exploitation with webshells planted on connected sites, so a site that served a vulnerable version must be rebuilt from a known-good copy rather than carried across, and its credentials rotated.",
+        "evidence": "AU-Essential-8-Patch gap: 'Patch cadence alone doesn't help sites still on end-of-support Joomla 3/4 branches, which needed separate back-ported fixes (3.1.1 / 3.4.10).' Packet: affected_versions '<= 3.5.10'; cisa_kev true, kev_date 2026-07-07, 'due date 2026-07-10'; active_exploitation 'confirmed' with 'multiple reports describe webshells being planted on connected Joomla sites through the flaw'; patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2026-55255": {
     "name": "Langflow Authorization Bypass Through User-Controlled Key Vulnerability",
@@ -37469,7 +38335,32 @@
         "adequate": false,
         "gap": "Technical vulnerability management requires confirming remediation efficacy, not just patch application — relevant here given the reported incomplete fix."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Every framework control cited on this entry closes on a version number, and this is the packet where that is not evidence of remediation: the live-patch note records community reports on the JoomShaper forum, post-6.6.2, that the IconsTrait.php code path may remain exploitable after the 6.6.2 patch, and states that operators should verify remediation rather than treat the version bump alone as sufficient. An extension inventory that reads SP Page Builder's reported version and marks the site patched is therefore paper compliance on this specific defect. The operational test for this product is a request rather than a version read: against a staging copy of the site, from an unauthenticated client carrying no session and no CSRF token, POST a PHP payload to SP Page Builder's asset.uploadCustomIcon task and then attempt to fetch the resulting file. The site is remediated when the upload is refused before anything is written — not when the extension reports 6.6.2. Re-run the test after every subsequent SP Page Builder update, because the packet's point is that a version bump on this exact code path has already once been reported as not closing it. Precondition: this control verifies, it does not repair. The missing session, permission and CSRF checks on the upload task are the vendor's to restore, so a site that fails the test has only the vendor's next release, or removal of the extension, as an actual fix — the test result is not itself a mitigation. And because the packet records confirmed exploitation with a public PoC, a site passing the test today establishes nothing about whether it was already exploited before the test was run.",
+        "evidence": "Packet live_patch_notes: 'Community reports (JoomShaper forum, post-6.6.2) indicate the IconsTrait.php code path may remain exploitable after the 6.6.2 patch; operators should verify remediation rather than treat the version bump alone as sufficient.' patch_available true, live_patch_available false. attack_vector: 'An unauthenticated attacker POSTs directly to SP Page Builder's asset.uploadCustomIcon task, which accepts any file type with no session, permission, or CSRF check, then requests the uploaded PHP file to execute code and create a rogue Super User account.' Vector: 'A vulnerability in SP Page Builder for Joomla allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code.' cisa_kev true, kev_date 2026-07-07, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 68, cwe_refs CWE-434. Citing gaps: ISO-27001-2022-A.8.8 Management of technical vulnerabilities, NIST-800-53-SI-2 Flaw Remediation, NIS2-Art21-vulnerability-management and AU-ISM-1546 Patch operating systems and applications.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation path ends in two artifacts that no extension update removes: a PHP file the attacker uploaded through the asset.uploadCustomIcon task and then requested in order to execute it, and a rogue Super User account created on the Joomla site. Updating SP Page Builder replaces extension code — it does not delete a file already written into the site's upload directories, and it does not touch the Joomla user table, so a site recorded as patched can still be holding an administrator account the attacker controls. Applied to this deployment the requirement is that a publicly reachable Joomla site running SP Page Builder during the exposure window is handled as compromised rather than as patched: enumerate Super User and administrator accounts against a known-good list and remove any not provisioned by the site's own administrators, rotate the credentials of the accounts that remain, search the extension's upload directories and the web root for PHP files that belong to no installed package, and restore from a known-good backup in preference to cleaning in place where the site's content allows it. This entry gives the control more weight than usual, because the packet also records that the 6.6.2 patch may not have closed the upload path — so the update can be treated as ending neither the exposure nor the persistence. Precondition: this is the incident-response default, not a preventive control. It does not close the upload endpoint — that is the vendor fix, subject to the verification requirement recorded separately on this entry — and a backup taken during the exposure window may itself already contain the rogue account or the uploaded file, so the restore point must be chosen against that window rather than by recency.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker POSTs directly to SP Page Builder's asset.uploadCustomIcon task, which accepts any file type with no session, permission, or CSRF check, then requests the uploaded PHP file to execute code and create a rogue Super User account.' Vector: 'A vulnerability in SP Page Builder for Joomla allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code.' live_patch_notes: 'Community reports (JoomShaper forum, post-6.6.2) indicate the IconsTrait.php code path may remain exploitable after the 6.6.2 patch; operators should verify remediation rather than treat the version bump alone as sufficient.' patch_available true, live_patch_available false, poc_available true, active_exploitation 'confirmed', cisa_kev true, kev_date 2026-07-07, cvss 9.8, rwep_score 68. Citing gaps include NIST-800-53-SI-2 Flaw Remediation, NIS2-Art21-vulnerability-management and UK-CAF-B4 System security.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-48282": {
     "name": "Adobe ColdFusion Path Traversal Vulnerability",
@@ -37659,7 +38550,30 @@
         "adequate": false,
         "gap": "Identification/authentication control assumes session-validation logic is sound; here the SSLVPN mechanism itself failed to validate sessions correctly, bypassing IA-2's intent regardless of any MFA configuration."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "SonicOS SSLVPN is the authentication enforcement point for remote access, and this CVE is that enforcement point failing open: a crafted session cookie makes the gateway resolve an unauthenticated request onto an already-authenticated user's live VPN session, putting the attacker inside on someone else's session. The clock cannot start at the KEV listing, because the packet's own sequence puts exploitation ahead of it — Bishop Fox published a PoC on 2025-02-10, exploitation followed within days, and CISA listed the CVE on 2025-02-18, so the listing is confirmation rather than warning, and the packet records roughly 4,500 internet-facing instances still unpatched a week after the PoC. Scope from the affected fields, not from the headline: the population is Gen7 firewalls, Gen7 NSv and TZ80 units with SSL VPN enabled and internet-facing, across three separate build lines — SonicOS 7.1.x (7.1.1-7058 and earlier), 7.1.2-7019, and 8.0.0-8035 — so a sweep run only against the 7.1 branch reports clean across an estate standardised on 8.0.0-8035, and each unit must be shown at or above the vendor's fixed build for its own line. patch_required_reboot is true and live_patch_available is false, so a unit that has taken the firmware but has not rebooted is still executing the vulnerable session-validation code and must be counted as exposed. On a remote-access gateway that reboot is the step most likely to be deferred, because taking it drops every active VPN session — a deferral recorded as patched is the specific way this remediation goes wrong, so completion is measured on the firmware the unit is running, not on the upload. Interim exposure is bounded by the packet's own scoping condition, that the flaw affects these units when SSL VPN is enabled and internet-facing: enumerate which units have that listener enabled and reachable, and restrict or suspend it until the reboot completes. Precondition on that interim measure — it is available only where the remote-access population is address-bounded or where remote access can be taken out of service; a general remote-workforce portal cannot be source-restricted without denying the workforce, and neither restriction helps a unit whose sessions were hijacked before the restriction went on. Because the packet records confirmed ransomware use and initial access to internal network resources, a gateway that was internet-facing with SSL VPN enabled during that window belongs on the incident path: the intrusion this exploit enables lives behind the firewall, not on it, so a rebooted, patched gateway is not evidence that the network behind it is clean.",
+        "evidence": "Packet fields for CVE-2024-53704: name 'SonicWall SonicOS SSLVPN Improper Authentication Vulnerability'; affected 'SonicOS SSLVPN authentication/session-management mechanism on Gen7 firewalls, Gen7 NSv, and TZ80, when SSL VPN is enabled and internet-facing'; affected_versions 'SonicOS 7.1.x (7.1.1-7058 and earlier)', 'SonicOS 7.1.2-7019', 'SonicOS 8.0.0-8035'; attack_vector 'A remote, unauthenticated attacker sends a crafted session cookie to the SonicOS SSLVPN authentication endpoint, exploiting improper session validation to hijack an already-authenticated user's active VPN session and reach internal network resources'; active_exploitation_notes 'Actively exploited in the wild within days of Bishop Fox publishing a public PoC (Feb 10, 2025); CISA KEV flags confirmed ransomware use — responders observed exploitation tied to intrusions that hijacked active SSL VPN sessions for initial access'; kev_date 2025-02-18; framework_control_gaps AU-Essential-8-Patch 'roughly 4,500 internet-facing instances remained unpatched a week after the public PoC'; cvss 9.8; rwep_score 80; poc_available true; patch_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "The SonicWall gateway is itself the security product, and this CVE is the case the control's trust-anchor-inversion test exists for. The packet places the failure inside the SSLVPN authentication mechanism: improper session validation resolves an attacker-supplied session cookie onto an active session, which is exactly why the identification-and-authentication gap on this entry says the control's intent is bypassed regardless of any MFA configuration. No factor is ever challenged because no authentication event occurs at all — the attacker inherits a session that was authenticated by someone else. That makes the estate's identity evidence, however strong, evidence about a path this exploit does not take, and it means the missing obligation is a test aimed at the product rather than at the account model: deliver a crafted session cookie to a staging gateway's SSLVPN endpoint and confirm it is rejected rather than resolved onto an existing session. The same reclassification governs how the appliance is managed day to day — its firmware belongs in vulnerability management under the same SLA as any other privileged software, and its advisories belong in threat intake, because a device bought as a defense is routinely excluded from both and is inventoried as infrastructure rather than as attack surface. Note also what an exploit doing exactly what the packet describes will not emit: no credential is guessed and no factor is presented, so authentication logs and MFA telemetry carry no record of the event; the observable is an active SSL VPN session being used from a source address that never authenticated it, which is only visible where per-session activity, not just authentication events, is collected off the appliance. Precondition: this control produces a testing obligation and evidence about the product's behaviour — it does not repair the session-validation logic, which only the vendor firmware and its reboot do, and a clean result on a staging unit says nothing about whether a production gateway's sessions were hijacked during the exposure window.",
+        "evidence": "Packet fields for CVE-2024-53704: cwe_refs CWE-287; vector 'An Improper Authentication vulnerability in the SSLVPN authentication mechanism allows a remote attacker to bypass authentication'; attack_vector 'sends a crafted session cookie to the SonicOS SSLVPN authentication endpoint, exploiting improper session validation to hijack an already-authenticated user's active VPN session'; framework_control_gaps / framework_coverage NIST-800-53-IA-2 'Identification/authentication control assumes session-validation logic is sound; here the SSLVPN mechanism itself failed to validate sessions correctly, bypassing IA-2's intent regardless of any MFA configuration'; active_exploitation 'confirmed' with KEV-flagged ransomware use; poc_available true (Bishop Fox, Feb 10 2025); patch_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-IA-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-57727": {
     "name": "SimpleHelp Path Traversal Vulnerability",
@@ -38033,7 +38947,30 @@
         "adequate": false,
         "gap": "The emergency patches (15.8.9 / 23.10, released Jan 28-29 2025) landed only after in-the-wild zero-day exploitation was already underway, showing standard patch-SLA timelines don't cover a pre-disclosure exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "Cityworks reaches its deserialization sink over an ordinary authenticated application request to the IIS site, so only one half of this control is a lever here and the other half must not be claimed. The bind-the-listener-and-authenticate-the-peer half gives nothing: the packet's exploitation precondition is a low-privileged authenticated Cityworks session, which every legitimate field and office user already holds, and the deployments the packet describes as exploited are internet-facing by design for local-government and utility users — there is no network position to remove that does not also remove the product's function. The load-bearing half is constraining what arriving content the service is permitted to construct or evaluate: the Cityworks request path must not inherit safety from the fact that the caller authenticated, and the deserializer must be bound to an explicit set of expected types rather than reconstructing whatever object graph the submitted payload names. That is exactly why the least-privilege control cited against this entry passes its attestation while the flaw stays fully exploitable — the attacker is a legitimate low-privileged account behaving like one, so per-account privilege scoping is never the thing that fails and no access decision is ever wrong. Precondition: this states the property the vendor build must hold, it does not implement it. Cityworks 15.8.9 and Cityworks with Office Companion 23.10 are what establish it, and until a deployment is on those builds nothing on the operator side constrains the sink, because the request that reaches it is indistinguishable from a legitimate authenticated one. Measure completion per component on the version the running IIS deployment actually serves: the packet gives Office Companion its own fixed build, so a site that took the Cityworks update alone is not remediated.",
+        "evidence": "Packet vector: 'Trimble Cityworks versions prior to 15.8.9 and Cityworks with office companion versions prior to 23.10 are vulnerable to a deserialization vulnerability. This could allow an authenticated user to perform a remote code execution attack against a customer's Microsoft Internet Information Services (IIS) web server.' cwe_refs CWE-502. affected: 'Trimble Cityworks GIS-centric asset-management software deployed on Microsoft IIS, including the Cityworks with Office Companion add-on, vulnerable to a .NET deserialization flaw reachable by an authenticated user.' affected_versions: 'Cityworks < 15.8.9', 'Cityworks with Office Companion < 23.10'. The NIST-800-53-AC-6 gap states exploitation only requires a low-privileged authenticated session (PR:L), so the deserialization surface itself needs to be constrained regardless of the caller's privilege level; the ISO-27001-2022-A.8.28 gap states the root cause is unsafe deserialization and that account-level trust in a low-privileged authenticated user cannot compensate. active_exploitation confirmed against internet-facing Cityworks/IIS deployments at local-government and utility operators; patch_available true, live_patch_available false, live_patch_notes null, patch_required_reboot false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.28",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet dates exploitation of Cityworks to around January 2025, the emergency builds 15.8.9 and Office Companion 23.10 to 28-29 January 2025, and the KEV listing to 2025-02-07. For this CVE the control's 'whichever is later' clause does real work: patch availability was the trigger that had already passed, and the interval between the vendor's emergency release and a site's next scheduled application-update window is the whole of the operator-controllable exposure. Concretely for a Cityworks estate that means the emergency build is driven out on an incident clock rather than folded into the normal application-update cycle, with each site's remediation recorded as the version its running IIS deployment serves and both components tracked separately, since Office Companion carries its own build number. The sector profile the packet records — water and wastewater, energy, transportation — is why the clock has to be the incident one rather than the cadence one, since these are the operators for whom a documented vulnerability-handling procedure is what currently satisfies the obligation. Precondition, stated because this is where a KEV SLA is routinely over-claimed: the control bounds the post-release window only. The packet records this as a zero-day exploited before the vendor build existed, so no SLA reaches the period in which the documented victims were actually compromised. And because the packet records custom Rust-based loaders staging VShell and Cobalt Strike in memory on the IIS host, an installation upgraded to 15.8.9 without triage carries whatever was staged on it into the fixed build — reaching the fixed version closes the sink, not the intrusion.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-02-07, active_exploitation confirmed, cvss 8.8, rwep_score 50, poc_available false, patch_available true, live_patch_available false, live_patch_notes null. The NIST-800-53-SI-2 gap states: 'The emergency patches (15.8.9 / 23.10, released Jan 28-29 2025) landed only after in-the-wild zero-day exploitation was already underway, showing standard patch-SLA timelines don't cover a pre-disclosure exploitation window.' active_exploitation_notes: 'Actively exploited as a zero-day beginning around January 2025 against internet-facing Cityworks/IIS deployments at local-government and utility operators; Trimble-shared IOCs indicate attackers deployed custom Rust-based loaders to stage the VShell and Cobalt Strike post-exploitation frameworks in memory... the affected sectors span water/wastewater, energy, and transportation.' The AU-Essential-8-Patch gap states the 48-hour guidance could not be met because the vendor's own emergency patch trailed the observed zero-day exploitation start date; the NIS2-Art21-vulnerability-handling gap states critical-infrastructure operators running Cityworks had no coordinated emergency-patch SLA matching that timeline.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2025-0411": {
     "name": "7-Zip Mark of the Web Bypass Vulnerability",
@@ -38642,7 +39579,30 @@
         "adequate": false,
         "gap": "Identity-and-access controls were structurally bypassed since the vulnerability itself manufactures a valid administrator identity without authentication."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "PRTG Network Monitor's web interface is the management plane for everything it polls, and the packet places the defect at two points on it at once. /public/login.htm is a page that by design answers unauthenticated callers, and a crafted HTTP request can override the attributes of its include directive; /api/addusers, the account-creation function that request is then made to reach, performs no authentication of its own — which is why the entry is classed CWE-306, missing authentication for a critical function. Bound to this product, the control means every PRTG API function that changes state, account creation first among them, makes its own authorization decision before it executes rather than inheriting one from the authenticated pages that normally invoke it; and the attribute the pre-authentication login page uses to select what it includes is validated against a fixed allow-list rather than taken from the request. It also means no PRTG web interface is left reachable from a segment with no operational need to reach it. This is why the identity-and-access controls cited on this entry do not touch the path: the attacker never holds a PRTG account, so no credential is presented and no access decision is consulted — an attestation that every PRTG operator authenticates at login passes cleanly while the endpoint creates administrators for callers who never logged in. Distinguishing test: from an unauthenticated client on a staging instance, send the crafted request to /public/login.htm naming /api/addusers with id and users parameters, then enumerate the instance's user list and confirm it is unchanged — testing that the login page rejects bad credentials proves nothing here, because the exploit never attempts a login. Preconditions: the endpoint-side authorization and the include-attribute validation are properties the vendor fix establishes — the packet records PRTG before 18.2.40.1683 as affected with a patch available, so this control states what to verify, not what an operator can implement. Restricting which segments can reach the web interface bounds who can send the request but leaves the path fully exploitable to anything inside the permitted segment, and it is unavailable where the console must stay broadly reachable for operational use. And because exploitation is confirmed and the outcome is a persistent read-write account, upgrading closes the inclusion path but does not delete an account created through it: an instance that was reachable during the exposure window needs its user list compared against a known-good baseline rather than being closed on the version number.",
+        "evidence": "Packet vector: 'PRTG Network Monitor before 18.2.40.1683 allows remote unauthenticated attackers to create users with read-write privileges (including administrator). A remote unauthenticated user can craft an HTTP request and override attributes of the include directive in /public/login.htm and perform a Local File Inclusion attack, by including /api/addusers and executing it. By providing the id and users parameters, an unauthenticated attacker can create a user with read-write privileges (including administrator).' cwe_refs CWE-306; cisa_kev true with kev_date 2025-02-04; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 67; patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-IA-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry is unusual and that is the point: the packet places the fix at PRTG 18.2.40.1683 while CISA listed the CVE on 2025-02-04, so under this control's 'KEV listing or patch availability, whichever is later' rule the SLA runs from the listing, against a defect whose fix had been shipping for years already. The population still exposed at listing is therefore not one waiting on a vendor — it is instances that no update process has touched — which makes meeting the SLA a discovery problem before it is a patching problem. The requirement here is to find every PRTG installation, including the ones standing on a departmental server, a lab host, or a machine inherited from a team that no longer exists, and confirm each reports a version at or above 18.2.40.1683 rather than confirming that the inventoried instances were updated. Track and document mitigation state per instance, not in aggregate: with a public PoC, confirmed in-the-wild exploitation and an unauthenticated path that mints an administrator on a monitoring server, one missed install is not a percentage point on a compliance figure. Precondition: the packet records a vendor patch and no live-patch path, so there is nothing that removes this flaw short of reaching the fixed version — where an instance genuinely cannot take the upgrade inside the window, the only remaining lever is removing its reachability from segments that have no need to reach it, and that is a holding measure with a review date, not a remediation. Because exploitation is confirmed, an instance found late is a triage item as well as a patch item: the flaw's product is a persistent privileged account, and the upgrade does not remove one already created.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-02-04; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 67; patch_available true; live_patch_available false. Vector states the affected range as 'PRTG Network Monitor before 18.2.40.1683' and the outcome as remote unauthenticated attackers creating 'users with read-write privileges (including administrator)'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.9"
+        ]
+      }
+    ]
   },
   "CVE-2025-24085": {
     "name": "Apple Multiple Products Use-After-Free Vulnerability",
@@ -38684,7 +39644,33 @@
         "adequate": false,
         "gap": "Essential Eight's patch-OS timeline (48 hours for extreme-risk vulnerabilities) is difficult to meet for a distributed device fleet without forced MDM update enforcement."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet names the fixed build per platform — iOS 18.3 and iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3, watchOS 11.3 — and that list is what makes this a fleet-enforcement problem rather than a single-update problem: a real Apple estate spans several of those trains at once, and a device held on an older train is remediated only by the build named for its own train, not by the newest one. Applied to this CVE the control means the update is driven from the management plane on the KEV clock that opened 2025-01-29 with user deferral disallowed, and completion is measured per device against the fixed build for the train it is actually on — not against 'update available', 'assigned' or 'downloaded' in the management console. Deferral is the load-bearing part here because of how short the exploitation path is: once the malicious application is on the device it reaches the flaw with a small number of local XPC calls into the mediaplaybackd daemon's CoreMedia Remaker subsystem, needing no network position and no further user step, so the exposure window is exactly the time the device spends below its fixed build and a user postponing the update for a week is a week in which any application on that device holds a path to privileged code execution. Precondition: the packet records no live-patch path, so nothing short of the device reaching its fixed build removes the flaw — a device that cannot reach it is not covered by this SLA at all and belongs on the access-condition and application-restriction levers instead of being carried as an exception. Because exploitation is confirmed, a device that ran an untrusted application while below its fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet vector: 'A use after free issue was addressed with improved memory management. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3, watchOS 11.3. A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 17.2.' Packet attack_vector: 'A malicious application on the device makes a small number of XPC calls to the mediaplaybackd daemon's CoreMedia Remaker subsystem, triggering a use-after-free in FigRemakerTrack object handling that yields code execution in that privileged process and, ultimately, privilege escalation.' CWE-416; CISA KEV listed 2025-01-29; active_exploitation confirmed; poc_available true; CVSS 10; RWEP 83. patch_available true, live_patch_available false (live_patch_notes null — no interim mechanism is recorded).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Because the packet's exploitation path starts with a malicious application resident on the device, this control's two halves split cleanly for this CVE. First, the fixed build named for each train must operate as an access condition — organizational mail, VPN and document access denied to any device below iOS/iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3 or watchOS 11.3 — rather than a row on a patch-compliance report; an estate that surfaces the stale build on a dashboard while the device keeps its access has recorded the exposure rather than removed it. The distinguishing test is to enrol a device pinned below the fixed build for its train and confirm the policy actually denies it protected resources. Second, since the attacker's foothold is an installed application making XPC calls into the CoreMedia Remaker subsystem of mediaplaybackd, constraining what code is permitted to install and run at all is the only lever the operator holds on a device that cannot yet take its fixed build. Precondition, and this is where the second half gets over-claimed: restricting untrusted or side-loaded application installation raises the bar for getting the attacker's application onto the device, but it does not evict an application already installed, and it does not cover one that arrived through the normal store channel — a device suspected of already running the malicious application belongs on the incident path, not the install-policy path. The whole control is a holding measure for the window before the fixed build lands, not a substitute for it: the packet records no live-patch path, so only the build itself removes the use-after-free.",
+        "evidence": "Packet vector names the fixed builds ('iOS 18.3 and iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3, watchOS 11.3') and states 'A malicious application may be able to elevate privileges.' Packet attack_vector places the trigger in a malicious application on the device making a small number of XPC calls to the mediaplaybackd daemon's CoreMedia Remaker subsystem, triggering a use-after-free (CWE-416) in FigRemakerTrack object handling. CISA KEV listed 2025-01-29; active_exploitation confirmed; CVSS 10; RWEP 83; poc_available true. patch_available true; live_patch_available false. Citing gap NIST-800-53-CM-7 (Least Functionality) is recorded against this entry.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-23006": {
     "name": "SonicWall SMA1000 Appliances Deserialization Vulnerability",
@@ -38758,7 +39744,30 @@
         "adequate": false,
         "gap": "A five-year-old client-side library flaw remained unpatched in production long enough to appear in attacker C2 infrastructure, showing flaw-remediation tracking rarely extends to bundled front-end JS dependencies."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "jQuery is not installed software on an estate — it is a file that ships inside applications, and the packet's affected range (greater than or equal to 1.0.3 and before 3.5.0) covers effectively every copy ever vendored into a web root, emitted by a build step, or embedded in a third-party product's web interface. That is why a flaw-remediation programme keyed to installed packages reports nothing here: the vulnerable code is a dependency no manifest on the host declares, so the scan result is silence rather than a finding. The requirement is that the software inventory reach those copies — enumerate jQuery across the served content and build outputs of every web application in the estate, not only the declared direct dependencies, and record each copy's version against the packet's fixed version of 3.5.0. Two populations fall out of that scan and they have different terminal states, which is the part an inventory row alone hides. A copy the organisation builds and ships is a code change, not a patch: the packet fixes the flaw in 3.5.0, and a copy on 1.x or 2.x reaches that only through a major-version upgrade of the library, which is application work with regression risk and has to be scheduled as such. A copy bundled inside a third-party product is not substitutable by the operator at all — that item belongs on the vendor's fixed-build clock, and where the vendor ships no build carrying jQuery 3.5.0 or later, the honest terminal state is replacing or removing that product, because an inventory row left open indefinitely marks a KEV-listed flaw with a public PoC as managed while it stays exploitable. Scope the sweep to what the packet establishes — jQuery below 3.5.0 — rather than to front-end libraries in general, which the packet gives no basis for.",
+        "evidence": "Packet vector: 'In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.' CWE-79, CVSS 6.9, RWEP 65, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2025-01-23. patch_available true; live_patch_available false with live_patch_notes null. AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 (Flaw Remediation) are recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Two distinct measurements report clean on this CVE while it stays exploitable, and the control's job here is to name both. The first is version-only scanning: an inventory that reads installed operating-system packages has no row for a jQuery file served out of a web root, so the result says nothing about the flaw rather than saying it is absent — silence read as a pass. The second is specific to this defect and is the one that catches operators out. The packet states the untrusted HTML executes 'even after sanitizing it', and that the crafted <option> content survives common sanitization, so an application recording an HTML sanitizer as its compensating control has recorded something the packet says does not hold on this path. The operational test therefore has to exercise the documented behaviour rather than a version string: on a staging copy of each affected application, pass HTML containing crafted <option> elements through whatever sanitization that application applies and on into the jQuery DOM manipulation methods the packet names — .html(), .append() and the others — and confirm nothing executes in the resulting page. A copy that executes the payload is exploitable regardless of what the sanitizer is configured to strip, and an application whose primary bundle reports jQuery 3.5.0 while a second bundle on the same page still loads an older copy fails this test even though the version report reads clean. Precondition: this is a test, not a mitigation. A failing result identifies an application that must take the library upgrade to 3.5.0 or later; passing it on one application says nothing about the others, so it runs per application rather than once for the estate, and no result of it removes the need for the upgrade.",
+        "evidence": "Packet vector: untrusted HTML containing <option> elements passed to jQuery's DOM manipulation methods '(i.e. .html(), .append(), and others) may execute untrusted code', and the packet states this holds 'even after sanitizing it'; 'This problem is patched in jQuery 3.5.0.' Attack vector: the crafted <option> content 'survives common sanitization', 'causing the browser to execute attacker-controlled JavaScript in the victim's session'. CWE-79, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2025-01-23. NIS2-Art21-vulnerability-management and UK-CAF-B4 (System security) are recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-50603": {
     "name": "Aviatrix Controllers OS Command Injection Vulnerability",
@@ -38832,7 +39841,32 @@
         "adequate": false,
         "gap": "Microsoft confirmed active exploitation at time of disclosure, meaning routine patch-cycle SLAs did not cover the exposure window for this Hyper-V component."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Hyper-V NT Kernel Integration Virtual Service Provider — the host-side component that manages VM-to-host communication — and describes a local low-privilege attacker, on the host or by way of a guest VM, triggering a use-after-free (CWE-416) that causes the kernel to operate on freed memory and lands as SYSTEM. For this CVE the control means the January 2025 cumulative update carrying the fix is driven across every Windows Server and Windows client system with the Hyper-V role enabled on the clock that opened with the 2025-01-14 KEV listing, rather than folded into the next virtualization maintenance window, with completion measured by each host's running build against the fixed build for its SKU. The packet does not carry per-SKU build numbers — it points at the MSRC advisory for them — so the target build has to be read off that advisory per SKU rather than inferred from any build that merely looks newer. patch_required_reboot is true and live_patch_available is false, so a host that installed the update and has not rebooted is still executing the vulnerable kernel; on a virtualization host that reboot means draining or restarting the guests the host is running, which is exactly the step a change process defers, and a deferral recorded as patched is the specific way this remediation goes wrong. The second half of the control is the load-bearing one here: the attacker the packet describes is already a legitimate low-privilege local principal, so tightening account privilege does not contain the escalation — which is why the least-privilege gap recorded on this entry can pass its attestation while the flaw stays fully exploitable. Priority follows the packet rather than the 7.8 CVSS band: Microsoft confirmed exploitation in the wild at the time of disclosure, and the packet records the flaw being used as the local privilege-escalation step to reach SYSTEM after initial host or guest access, which makes it the containment step in a chain rather than a standalone endpoint item. Note also that poc_available is false — there is no public exploit to test an estate against, so the population to enumerate is every Hyper-V-enabled host, not the subset someone can demonstrate against.",
+        "evidence": "Packet: name 'Microsoft Windows Hyper-V NT Kernel Integration VSP Use-After-Free Vulnerability (CVE-2025-21335)'; CWE-416; attack_vector 'A local low-privilege attacker (on the host or via a guest VM) triggers a use-after-free in the Hyper-V NT Kernel Integration VSP component, causing the kernel to operate on freed memory and allowing escalation to SYSTEM'; affected 'Windows Server and Windows client systems running the Hyper-V role, specifically the NT Kernel Integration Virtual Service Provider (VSP) component that manages VM-to-host communication'; affected_versions 'Windows Server and Windows client builds with the Hyper-V role enabled, prior to the January 2025 cumulative update (see MSRC advisory for exact per-SKU build numbers)'; cisa_kev true with kev_date 2025-01-14; active_exploitation 'confirmed'; active_exploitation_notes 'Microsoft confirmed exploitation in the wild at time of disclosure. Used as a local privilege-escalation step to reach SYSTEM after initial host or guest access. Not flagged for ransomware.'; CVSS 7.8; RWEP 54; poc_available false; patch_available true; patch_required_reboot true; live_patch_available false. NIST-800-53-AC-6 gap: 'Least-privilege controls on host/guest processes do not stop a use-after-free that grants a low-privilege local process a path directly to SYSTEM.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-068",
+        "name": "HYPERVISOR-VM-ESCAPE-TENANCY-ASSUMPTION",
+        "description": "The packet states that the trigger can come from inside a guest — a local low-privilege attacker on the host or via a guest VM — against the very component that manages VM-to-host communication, so for this flaw the guest boundary is not a boundary. Applied to this CVE, the control means every Windows Server and Windows client host with the Hyper-V role enabled is treated as adversary-facing from its own guests regardless of who owns those guests: not only multi-tenant hosts, but internal workload hosts and developer test hosts, because the packet's precondition is low-privilege local access rather than a hostile tenant. Two things follow. The host's remediation priority is set by the flaw's KEV status and confirmed exploitation rather than by how trusted the workloads on it are, and a guest administrator is not accepted as a principal below the host — a machine whose guests are 'internal' satisfies the packet's stated precondition just as fully as one whose guests are customers. The packet also records this as one of three Hyper-V NT Kernel Integration VSP memory-corruption elevation-of-privilege flaws fixed in the same January 2025 Patch Tuesday, alongside CVE-2025-21333 and CVE-2025-21334, so the assumption being corrected is about the component's trust position rather than about one bug. Precondition, stated because this control governs prioritization and trust assumptions and not the code path: it does not remove the surface. The VSP exists to service VM-to-host communication, so a host running the Hyper-V role cannot withdraw the interface, and restricting who holds an interactive low-privilege session on the host or inside its guests bounds the population that can attempt the escalation without closing it for anyone who legitimately has one. Closure is the January 2025 cumulative update and the reboot it requires — live_patch_available is false and patch_required_reboot is true — so a host that cannot absorb that reboot immediately is on an interim clock, not remediated, and must be recorded that way.",
+        "evidence": "Packet: attack_vector 'A local low-privilege attacker (on the host or via a guest VM) triggers a use-after-free in the Hyper-V NT Kernel Integration VSP component'; affected names the 'NT Kernel Integration Virtual Service Provider (VSP) component that manages VM-to-host communication'; cisa_kev true, kev_date 2025-01-14; active_exploitation 'confirmed'; active_exploitation_notes 'One of three Windows Hyper-V NT Kernel Integration VSP memory-corruption elevation-of-privilege flaws (alongside CVE-2025-21333 and CVE-2025-21334) patched in Microsoft's January 2025 Patch Tuesday'; patch_available true; patch_required_reboot true; live_patch_available false. UK-CAF-B4 gap: 'Secure configuration baselines for virtualization hosts do not mitigate a kernel use-after-free in the VSP component itself.' AU-Essential-8-Patch gap: 'Patch Applications/OS guidance is tested by a confirmed-exploited kernel flaw requiring emergency out-of-cycle patching of virtualization hosts.'",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-21334": {
     "name": "Microsoft Windows Hyper-V NT Kernel Integration VSP Use-After-Free Vulnerability (CVE-2025-21334)",
@@ -38869,7 +39903,32 @@
         "adequate": false,
         "gap": "Microsoft confirmed active exploitation at time of disclosure, meaning routine patch-cycle SLAs did not cover the exposure window for this Hyper-V component."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "Scope from the affected fields, which name both halves of the estate: Windows Server and Windows client systems running the Hyper-V role, at builds prior to the January 2025 cumulative update. The client half is where this sweep normally comes back falsely clean — a Hyper-V VSP defect reads as a datacentre problem, so an estate that enumerates only its Windows Server hosts leaves every Hyper-V-enabled workstation on pre-fix code. Drive the January 2025 cumulative update across that population on the clock that opened with the 2025-01-14 KEV listing rather than folding it into the next quarterly virtualization window, since Microsoft confirmed exploitation in the wild at the time of disclosure. Measure completion per host against its own SKU's fixed build from the MSRC advisory, not by 'approved' or 'downloaded' in the management console: patch_required_reboot is true and live_patch_available is false, so a host that installed the update and has not rebooted still runs the vulnerable NT Kernel Integration VSP. On a virtualization host that reboot is the single most-deferred step in the whole remediation, because taking it means draining, migrating, or stopping every guest the host carries — a host recorded as patched while its reboot waits for a maintenance window is the specific way this one goes wrong, so the evidence of completion has to be the running build. The second half of this control is the load-bearing half here: the packet's attacker is a low-privilege local principal on the host or inside a guest, already legitimately authenticated, so tightening account privilege does not contain the escalation — which is exactly why the least-privilege gap recorded on this entry can pass its attestation while the flaw stays fully exploitable.",
+        "evidence": "Packet fields for CVE-2025-21334: name and vector record the Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability, CWE-416; affected names Windows Server and Windows client systems running the Hyper-V role, specifically the NT Kernel Integration Virtual Service Provider component that manages VM-to-host communication; affected_versions names Windows Server and Windows client builds with the Hyper-V role enabled prior to the January 2025 cumulative update, with exact per-SKU build numbers in the MSRC advisory; attack_vector describes a local low-privilege attacker on the host or via a guest VM triggering the use-after-free and escalating to SYSTEM; cisa_kev true with kev_date 2025-01-14, active_exploitation confirmed, and active_exploitation_notes recording that Microsoft confirmed exploitation in the wild at time of disclosure; cvss 7.8, rwep_score 54, poc_available false; patch_available true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-068",
+        "name": "HYPERVISOR-VM-ESCAPE-TENANCY-ASSUMPTION",
+        "description": "The packet places the defect in the component that manages VM-to-host communication and places the attacker on either side of it — on the host or via a guest VM — so the boundary the deployment is designed around is the thing that fails. For the exposure window that means the population who can attempt this is not the host administrator list: it is the union of every local principal who can execute code inside any guest on that host. Single-tenant estates need this stated most, because 'every VM here is ours' is where the assumption goes unexamined; the packet describes this flaw being used as a local privilege-escalation step after initial host or guest access, so any initial-access event inside any guest during the window puts that guest's attacker one step from host SYSTEM. Concrete action while hosts wait for their reboot: shrink that population rather than assume it. Move guests running untrusted or lower-assurance workloads — internet-facing services, developer and lab VMs, anything with interactive non-administrative users — onto hosts that have already completed the update and reboot, and hold new workloads of that kind off unremediated hosts. Treat the KEV-listed hypervisor defect on a 24-hour class clock regardless of tenancy. Precondition, and it is the whole caveat: this is a threat-model and prioritization control and it repairs nothing in the VSP. The packet records a vendor patch with no live-patch path, so each host still has to reach the fixed build and reboot; relocating guests bounds who can attempt the escalation and does nothing for any principal still running on an unremediated host. Where a host's guests cannot be relocated, the exposure stands until the reboot and should be recorded as such, not as mitigated.",
+        "evidence": "Packet fields for CVE-2025-21334: affected identifies the NT Kernel Integration Virtual Service Provider component that manages VM-to-host communication on Windows Server and Windows client systems running the Hyper-V role; attack_vector states a local low-privilege attacker on the host or via a guest VM triggers the use-after-free, causing the kernel to operate on freed memory and allowing escalation to SYSTEM; active_exploitation_notes record Microsoft-confirmed exploitation in the wild at disclosure, use as a local privilege-escalation step to reach SYSTEM after initial host or guest access, and that it is not flagged for ransomware; cisa_kev true, kev_date 2025-01-14; the NIST-800-53-AC-6 gap on this entry records that least-privilege controls on host/guest processes do not stop a use-after-free granting a low-privilege local process a path directly to SYSTEM, and the UK-CAF-B4 gap records that secure configuration baselines for virtualization hosts do not mitigate a kernel use-after-free in the VSP component itself; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-21333": {
     "name": "Microsoft Windows Hyper-V NT Kernel Integration VSP Heap-based Buffer Overflow Vulnerability",
@@ -39490,7 +40549,31 @@
         "adequate": false,
         "gap": "Technical vulnerability management assumes an eventual vendor patch — NUUO has not responded to disclosure and the flaw persists in the latest firmware, so remediation-SLA-based controls cannot be satisfied and must fall back to decommissioning."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The NVRmini2 is a network video recorder, and this packet resolves the patch-versus-replace question in one direction: patch_available is false and no live-patch path is recorded, so there is no fixed build for an operator to reach. That makes each unit in service a replacement item rather than a remediation-clock item, and the requirement is an inventory naming every NVRmini2 with its firmware level - the packet scopes the defect to builds 'through 3.11' - together with a vendor-obtained answer on whether a fixed firmware exists for that hardware, rather than an assumption in either direction. Any unit for which the vendor produces a fix belongs on a remediation clock; every unit for which it does not belongs on a dated removal or replacement schedule, because a risk acceptance with no removal date leaves a KEV-listed device carrying a public PoC and confirmed exploitation in service indefinitely. Scope the inventory to what the packet names - NUUO NVRmini2 - not to every recorder or camera on the estate; the packet ties the missing authentication check to handle_import_user.php on this product and provides no mapping into other video hardware, so treating all surveillance appliances as instances of this CVE manufactures removal work against devices no evidence implicates. The distinguishing test is per unit rather than per estate: produce, for each NVRmini2 in service, its firmware level and the vendor's answer on a fix - an asset register that records the device as 'segmented' or 'monitored' with no removal date has recorded the exposure rather than removed it. Precondition, and it is why this cannot end at a segmentation entry in the risk register: the exposure being scored is an unauthenticated archive upload that creates an arbitrary account, so restricting which segments can reach the device bounds who can send that upload but repairs nothing, and with no vendor fix recorded there is no update behind which that interim state resolves. Because active_exploitation is confirmed and the primitive is account creation, a unit that was reachable during the exposure window may already carry an attacker-created account and, through the CVE-2011-5325 chain the packet names, attacker-written files under the web root; isolating that unit afterwards does not clear it, and its accounts and configuration must be treated as attacker-controlled until it is removed.",
+        "evidence": "Packet records patch_available: false, live_patch_available: false, live_patch_notes: null - no fixed build is recorded for this entry. CISA KEV-listed 2024-12-18, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 79. Vector: 'NUUO NVRmini2 through 3.11 allows an unauthenticated attacker to upload an encrypted TAR archive, which can be abused to add arbitrary users because of the lack of handle_import_user.php authentication. When combined with another flaw (CVE-2011-5325), it is possible to overwrite arbitrary files under the web root and achieve code execution as root.' Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIS2-Art21-vulnerability-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The NVRmini2's web interface is the device's configuration plane, and the defect is that plane's file-accepting endpoint making no authorization decision at all: the packet places the missing check in handle_import_user.php, which takes an encrypted TAR archive from an unauthenticated caller and imports users from it, so an attacker creates an arbitrary account without ever presenting a credential. Bound to this product, the control means a configuration endpoint that accepts an uploaded archive authorizes its caller before the archive is processed, and resolves and validates every destination path the import writes before the write executes - the chained CVE-2011-5325 step the packet names is exactly that second half failing, with archive content overwriting files under the web root and ending in code execution as root. This is also why the identification-and-authentication and identity-and-access gaps cited on this entry pass their attestations while the path stays open: the attacker never authenticates as any NVR user, so per-account authentication and privilege scoping are never consulted - the account model is bypassed rather than abused, and an attestation that every recorder administrator authenticates at login reads clean. Distinguishing test: from a segment with no operational need to administer the recorder, send an unauthenticated upload to the user-import handler on a bench unit and confirm it is refused before anything is imported or written to disk. Precondition, and it is decisive on this entry: endpoint-side authorization and path validation are properties a vendor fix would have to establish, and this packet records patch_available false with no live-patch path, so there is no update behind which this control resolves. The only operator-side lever left is reachability - restricting which segments can reach the management interface bounds the population that can send the upload, but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable wherever the recorder's web interface must stay reachable for normal viewing and administration. Treat reachability restriction as a holding measure attached to a removal date, never as closure of the endpoint.",
+        "evidence": "Packet vector: 'NUUO NVRmini2 through 3.11 allows an unauthenticated attacker to upload an encrypted TAR archive, which can be abused to add arbitrary users because of the lack of handle_import_user.php authentication. When combined with another flaw (CVE-2011-5325), it is possible to overwrite arbitrary files under the web root and achieve code execution as root.' CWE-306 (missing authentication), CVSS 9.8, RWEP 79, poc_available true, active_exploitation confirmed, CISA KEV-listed 2024-12-18. patch_available: false and live_patch_available: false, with live_patch_notes null. Citing gaps include NIST-800-53-IA-2 (Identification and Authentication), UK-CAF-B2 (Identity and access control) and NIST-800-53-CM-7 (Least Functionality).",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2021-40407": {
     "name": "Reolink RLC-410W IP Camera OS Command Injection Vulnerability",
@@ -39989,7 +41072,38 @@
         "adequate": false,
         "gap": "Vulnerability management did not catch mass in-the-wild scanning that predated the CISA KEV addition."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "ProjectSend's configuration surface is options.php, and this CVE is that surface making no authentication decision at all: the packet has remote, unauthenticated attackers sending crafted HTTP requests to options.php and modifying the application's configuration. Bound to this product, the control means every configuration-writing action in ProjectSend authorizes its caller itself before the setting is persisted - not merely that the administrative UI requires a login - because at the moment of the write the attacker holds no ProjectSend account at all; the account it uses afterwards is one the write creates by enabling self-registration. That is also why the cited access-enforcement and identification-and-authentication controls do not close this path: the account model those attestations examine is bypassed rather than abused, so a review confirming that every ProjectSend user authenticates passes cleanly while an unauthenticated caller rewrites the site's security-relevant settings. Distinguishing test: from an unauthenticated client against a staging instance, POST configuration changes to options.php - the packet names self-registration and permissive upload types as the settings this attack toggles - and confirm each is refused before anything is written. Precondition: the endpoint-side authorization is a property the r1720 release establishes; this control states what to verify, it does not implement it. Until r1720 is deployed, restricting which networks can reach the instance bounds the caller population but leaves the endpoint fully exploitable to anything inside the permitted network, and the packet records mass scanning of internet-facing instances, so an instance published to the internet has no such bound at all.",
+        "evidence": "The packet's vector states that ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability, that remote unauthenticated attackers can exploit it by sending crafted HTTP requests to options.php enabling unauthorized modification of the application's configuration, and that successful exploitation allows attackers to create accounts, upload webshells and embed malicious JavaScript; the attack_vector record adds that the configuration change enables self-registration and permissive upload types, after which the attacker registers an account and uploads a webshell for remote code execution. CWE-306; affected_versions: prior to r1720. CISA KEV-listed 2024-12-03 with active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 64; patch_available true, patch_required_reboot false, live_patch_available false. The framework record states that the configuration endpoint (options.php) lacked authentication enforcement allowing unauthenticated modification of security-relevant settings (NIST SP 800-53 AC-3), that identification and authentication were not enforced on a configuration endpoint capable of enabling attacker-controlled account creation (NIST SP 800-53 IA-2), and that UK CAF B4 system-security lifecycle management allowed a self-hosted file-sharing app with unauthenticated config-write to remain internet-exposed.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "NIST-800-53-IA-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This exploitation chain ends in attacker-created artifacts rather than a transient condition, and the packet lists them: modified site configuration, created accounts, uploaded webshells and embedded malicious JavaScript, with mass scanning and exploitation of internet-facing instances observed since mid-2024. Upgrading to r1720 closes the unauthenticated configuration write and leaves every one of those artifacts exactly where it is - the webshell is application content sitting in the upload path, not product code the release replaces, and the attacker-created account and the flipped settings survive the upgrade untouched. So for any ProjectSend instance that was internet-reachable on a pre-r1720 build during that window, the remediation verdict cannot be 'now on r1720'. Audit the site configuration back to intended values, starting with self-registration and the permitted upload types the packet names; enumerate every account against a known-good roster and remove those with no owner; inspect the upload directory for files served as executable content; and check served pages for injected JavaScript. If any of those turn up, rebuild the deployment from known-good source and restore only reviewed data. Detection keys on the documented behaviour rather than a tool signature: unauthenticated requests to options.php, configuration changes with no corresponding administrator action, accounts appearing without an approval record, and new files in the upload path being requested directly. patch_required_reboot is false, so there is no host reboot to coordinate, but that is not the completion criterion either - measure completion on the release the deployed instance actually reports, and the packet registers no live-patch path, so nothing mitigates the code in place before that release lands.",
+        "evidence": "The packet's vector states that successful exploitation allows attackers to create accounts, upload webshells and embed malicious JavaScript, and affected names unauthenticated requests to options.php allowing modification of site configuration enabling attacker account creation, webshell upload and stored XSS. active_exploitation_notes record exploitation in the wild since mid-2024, with VulnCheck and honeypot telemetry observing mass scanning and exploitation of internet-facing ProjectSend instances to plant webshells and stored XSS payloads ahead of CISA's KEV addition. CISA KEV-listed 2024-12-03; active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 64. patch_available true with the fixed version recorded as r1720 (affected_versions: prior to r1720); patch_required_reboot false; live_patch_available false with live_patch_notes null. The framework record states that the ASD Essential Eight patch-applications control is reactive and that exploitation was already occurring in the wild before widespread patching - the gap this control answers, because on an instance exposed during that window the patch is not the completion criterion.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-072",
+        "name": "PRIMARY-SOURCE-INTAKE-VENDOR-BLOG-COVERAGE",
+        "description": "On this entry the exploitation signal existed months before the compliance-visible one, and the packet names both. Exploitation in the wild ran from mid-2024, seen by VulnCheck and honeypot telemetry as mass scanning and exploitation of internet-facing ProjectSend instances; the KEV listing that most vulnerability programmes trigger on is dated 2024-12-03. A pipeline that ingests advisory feeds and the KEV catalogue alone learns about this at the far end of that interval, which is the whole of the exposure for an internet-published instance. The requirement here is that threat intake also covers exploitation-telemetry reporting of that class - vendor and research publications of mass-scanning and honeypot observations - and that such a report naming a product the organisation actually runs opens a ticket on its own authority, without waiting for a KEV entry or a CVSS score to justify it. Distinguishing test: take a currently-reported mass-exploitation campaign against a self-hosted web application present in the estate and check whether the intake pipeline already holds a record of it; if the only record is the eventual KEV entry, the pipeline is the gap. Precondition: this is early warning, not mitigation - it advances the moment the operator knows, and on this entry the actual fix remains the r1720 release plus the compromise check for anything the earlier exposure already left behind.",
+        "evidence": "active_exploitation_notes state that ProjectSend was actively exploited in the wild since mid-2024, and that VulnCheck and honeypot telemetry observed mass scanning and exploitation of internet-facing ProjectSend instances to plant webshells and stored XSS payloads ahead of CISA's KEV addition; the KEV listing date recorded on this entry is 2024-12-03, with active_exploitation confirmed. poc_available true; CVSS 9.8, RWEP 64; patch_available true with the fixed version recorded as r1720. The framework record states that EU NIS2 Article 21 vulnerability management did not catch mass in-the-wild scanning that predated the CISA KEV addition - the gap this control is attached to, since the shortfall named there is source coverage rather than remediation speed.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-11667": {
     "name": "Zyxel Multiple Firewalls Path Traversal Vulnerability",
@@ -40123,7 +41237,40 @@
         "adequate": false,
         "gap": "Flaw remediation existed as a vendor patch (9.4.0.484) since March 2023, but SSL VPN gateways are commonly deprioritized for patching since they sit outside standard endpoint patch cycles, leaving a 20+ month exploitation window before CISA KEV listing."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "An Array AG Series or vxAG unit is a VPN concentrator, so this is the tier's own case rather than an appliance-patch-window item: an unauthenticated HTTP request carrying a crafted flags attribute in the header browses the gateway filesystem and chains through a vulnerable URL into remote code execution, with no credential presented at any point. Bound to this product, the tier means the fixed ArrayOS AG build (9.4.0.484 per the packet) is driven onto every unit on a KEV-anchored clock rather than the next planned firmware maintenance window, and where a unit cannot take it immediately the SSL VPN interface is removed from untrusted reachability instead of left serving. Two scoping decisions determine whether the sweep is real. Cover vxAG alongside the AG Series hardware — the packet names both, and virtual instances routinely sit outside the hardware appliance register a firmware-currency review walks. And measure completion on the ArrayOS version each unit is actually running: the packet records patch_required_reboot true with no live-patch path, so a unit holding the new image but not yet rebooted is still executing 9.4.0.481-or-earlier code and is not remediated, which is exactly the state a maintenance-window process leaves behind when the reboot slips to the next window. The clock this replaces is the one the packet indicts — a vendor fix in existence since March 2023 against a KEV listing more than twenty months later.",
+        "evidence": "Packet: KEV-listed 2024-11-25; active_exploitation confirmed; poc_available true; RWEP 77; CVSS 9.8; patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes null. Vector: Array Networks Array AG Series and vxAG (9.4.0.481 and earlier) allow remote code execution — an attacker can browse the filesystem on the SSL VPN gateway using a flags attribute in an HTTP header without authentication, and the product can then be exploited through a vulnerable URL; the 2023-03-09 vendor advisory stated 'a new Array AG release with the fix will be available soon.' NIST-800-53-SI-2 gap as recorded: the vendor patch 9.4.0.484 existed since March 2023, but SSL VPN gateways are commonly deprioritized because they sit outside standard endpoint patch cycles, leaving a 20+ month exploitation window before the KEV listing. AU-Essential-8-Patch gap as recorded: the 48-hour internet-facing target is outrun in practice because gateway firmware updates require planned maintenance windows.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This entry is the case the control's default exists for: a pre-authentication path to remote code execution on an SSL VPN gateway, used in the wild by Earth Kasha for initial access into target networks, with the KEV entry also carrying a known history of ransomware-actor use, against a fixed build that had existed for more than twenty months before the listing. For an Array AG or vxAG unit that was reachable from untrusted networks during that window, moving to the fixed ArrayOS build closes the header-flags file-browse path and removes nothing an attacker already took or placed — the packet's primitive reaches the appliance filesystem and then code execution on the gateway. The IR default is therefore to capture and preserve the configuration, rebuild the unit from vendor media, and rotate what the gateway held or brokered: its administrative credentials, its certificates and keys, and the VPN user credentials and session material that passed through it — rather than record the version bump as closure. Why this cannot be settled by looking for evidence first is also in the packet: the missing-authentication flaw has no built-in detection, so the absence of an alert on a gateway is not evidence it went unused, and the appliance is itself where any local record an attacker with code execution could alter lives. Precondition: rebuild-and-rotate applies to units that were reachable while unpatched. A unit that can be shown unreachable from untrusted networks for the whole exposure window is a patch item — but that demonstration has to come from network-side records, not from the gateway's own logs.",
+        "evidence": "Packet active_exploitation_notes: actively exploited in the wild by the China-linked espionage group Earth Kasha for initial access into target networks; CISA KEV flags this entry with a known history of ransomware-actor use. attack_vector: an unauthenticated HTTP request with a crafted flags attribute in the header grants filesystem browsing on the Array AG/vxAG SSL VPN portal and, through a vulnerable URL, remote code execution on the gateway. UK-CAF-B4 gap as recorded: a missing-authentication flaw with no built-in detection left gateways exposed long after a fix existed. NIST-800-53-SI-2 gap as recorded: a 20+ month exploitation window before the CISA KEV listing, with the vendor patch (9.4.0.484) available since March 2023. active_exploitation confirmed; poc_available true.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet states why a scanner verdict cannot carry this entry: the primitive is an unauthenticated file-browse on the SSL VPN gateway, invisible to standard vulnerability scanners that only probe authenticated surfaces, so a clean scan against an Array AG or vxAG unit says nothing about whether the flaw is present. The operational test is a version-and-state check taken on the device rather than a network verdict: produce, per unit and including the vxAG virtual instances, the ArrayOS AG version currently running against the 9.4.0.484 fixed build, and confirm the unit has actually rebooted onto it — the packet records the fix as reboot-required with no live-patch path, so an appliance showing the new image staged while still executing 9.4.0.481-or-earlier code is exposed with every dashboard reading remediated. The distinguishing exercise on a staging unit is to send the unauthenticated header-flags request and confirm the filesystem browse is refused before anything is returned; a firmware-currency review that walks only the hardware appliance register, and a scan report with no findings, both pass while an unregistered vxAG instance keeps serving the path. Precondition: this is a verification control — it tells the operator which units are still exposed, it does not reduce the exposure of any of them.",
+        "evidence": "ISO-27001-2022-A.8.8 gap as recorded: technical vulnerability management requires timely identification and remediation, but an unauthenticated file-browse primitive on a VPN gateway is invisible to standard vulnerability scanners that only probe authenticated surfaces. Packet affected/affected_versions: Array Networks AG Series and vxAG SSL VPN gateway appliances, ArrayOS AG 9.4.0.481 and earlier; the fixed vendor patch is recorded as 9.4.0.484, available since March 2023. patch_required_reboot true; live_patch_available false. Vector: unauthenticated filesystem browsing via a flags attribute in an HTTP header, chained through a vulnerable URL into remote code execution.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-44309": {
     "name": "Apple Multiple Products Cross-Site Scripting (XSS) Vulnerability",
@@ -40160,7 +41307,30 @@
         "adequate": false,
         "gap": "Apple shipped a fix in Safari 18.1.1/iOS 17.7.2/18.1.1/macOS 15.1.1, but the flaw was exploited as a zero-day before any patch existed, so flaw remediation alone could not have prevented initial exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet's fix list is what makes this a fleet-wide push rather than one update: Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, iOS 18.1.1 and iPadOS 18.1.1, macOS Sequoia 15.1.1 and visionOS 2.1.1 all carry the same cookie-state-management fix, so remediation means every Apple device class the organization manages moves together on the clock that opened with the 2024-11-21 KEV listing — not on the next OS-upgrade window, and not in the order a severity-ranked queue would produce. That ranking is the specific failure mode here: the packet records CVSS 6.3 and poc_available false, which is precisely the profile a monthly patch queue defers, while the same packet records active exploitation as confirmed, notes Apple is aware of a report of exploitation on Intel-based Mac systems, and describes this cross-site-scripting flaw being chained with a separate code-execution flaw. The user-deferral half of the control is the load-bearing half on this fix, because on iOS, iPadOS and visionOS it arrives as an OS update whose prompt the person holding the device can dismiss indefinitely; the packet records live_patch_available false, so the fixed build is the only remediation and a dismissed prompt is untreated exposure. Distinguishing test: take an enrolled device one build below the fixed build for its track and confirm the management system installs the update inside the SLA without the holder being able to postpone it — an estate whose compliance report shows the update as available and pending user action has recorded the exposure rather than removed it. Precondition: this reaches enrolled devices only. Personally-owned Macs, iPhones and iPads used for work, and any unenrolled device, sit outside the push entirely, and the delivery path the packet describes — a user lured to attacker-controlled web content in Safari — needs nothing from the organization to work on them.",
+        "evidence": "Packet: CWE-79 cross-site scripting, with the vector stating a cookie management issue addressed with improved state management, fixed in Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, iOS 18.1.1 and iPadOS 18.1.1, macOS Sequoia 15.1.1, visionOS 2.1.1, and that Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems. cisa_kev true, kev_date 2024-11-21, active_exploitation confirmed, poc_available false, cvss 6.3, rwep_score 55. patch_available true, live_patch_available false, live_patch_notes null. The attack_vector records a targeted campaign against Intel-based Macs, chained with a separate code-execution flaw. AU-Essential-8-Patch (Patch operating systems), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet names two concurrently fixed iOS/iPadOS tracks — 17.7.2 and 18.1.1 — and that is what a single numeric minimum-version floor cannot express. Set the floor at 18.1.1 and every device correctly remediated on 17.7.2 fails the policy; set it at 17.7.2 and a device on 18.0 or 18.1 passes it, because those builds compare as newer while still carrying the unfixed cookie-state handling. For this entry the enforced floor has to be stated per track: at or above 17.7.2 on the 17.x line, at or above 18.1.1 on the 18.x line. The Mac side has the same shape for a different reason — the packet lists Safari 18.1.1 as a fixed build distinct from macOS Sequoia 15.1.1, so a check keyed only on the macOS build cannot see a Mac whose remediation is the Safari update, and the packet places the reported exploitation on Intel-based Mac systems. visionOS 2.1.1 sits on the same fix list and is the device class conditional-access policies most often do not enumerate at all. The requirement is that the per-track fixed build function as an access condition — a device below it is refused mail, VPN and document access until it is at or above it — rather than appearing as a row on a patch-compliance report. Distinguishing test: enrol one device pinned at 18.0 and one at 17.7.2 and confirm the policy denies the first and admits the second; a floor expressed as a single version number gets exactly this pair wrong, in the direction that admits the unfixed device. Precondition: withholding access bounds what a below-fix device can reach, it does not protect the device. The packet's exploitation path is a user loading attacker-controlled web content in Safari, which requires no organizational resource, so a blocked device remains fully exploitable and its user's own sessions and credentials stay in scope. Where a device cannot be brought to the fixed build, blocking it is the holding measure for the window, not the remediation.",
+        "evidence": "Packet: CWE-79 cross-site scripting reached by processing maliciously crafted web content; the vector names the fix as Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, iOS 18.1.1 and iPadOS 18.1.1, macOS Sequoia 15.1.1, visionOS 2.1.1 — two iOS/iPadOS tracks fixed concurrently, and Safari listed separately from macOS Sequoia. cisa_kev true, kev_date 2024-11-21, active_exploitation confirmed, poc_available false, cvss 6.3, rwep_score 55. patch_available true, live_patch_available false, live_patch_notes null. The vector states Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems. ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and UK-CAF-B4 (System security) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-44308": {
     "name": "Apple Multiple Products Code Execution Vulnerability",
@@ -40524,7 +41694,40 @@
         "adequate": false,
         "gap": "Access enforcement on the management plane failed because the interface itself lacked authentication for privileged actions, not because an access policy was misconfigured."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The device that has to be remediated here is the firewall itself: an unauthenticated caller who can reach the PAN-OS management web interface obtains PAN-OS administrator privileges, so the appliance enforcing the perimeter is the appliance failing open, and no standard 14- or 30-day appliance patch window applies to it. Scope the sweep from the packet's affected list rather than from 'our Palo Alto estate': PAN-OS 10.2, 11.0, 11.1 and 11.2 are the applicable trains, and the vector states Cloud NGFW and Prisma Access are not impacted, so an inventory must enumerate the on-prem units on those four trains at each train's own fixed release and must not raise findings against the cloud-delivered products. The clock runs from the 2024-11-18 KEV listing rather than from the next maintenance window, because the packet records a public PoC, confirmed exploitation, KEV ransomware use flagged as Known, and a chain with CVE-2024-9474 that converts administrator access into full firewall takeover. patch_available is true and live_patch_available is false, and the packet records the fix as requiring a reboot — so a unit that has installed the fixed PAN-OS release but has not restarted is still running the vulnerable code, and completion must be measured on the PAN-OS version the running unit reports rather than on an 'installed' or 'downloaded' state in the management console. Precondition on the interim measure, which is where this is usually over-claimed: the vector's guidance is that risk is greatly reduced by restricting management-web-interface access to trusted internal IP addresses — greatly reduced is not removed. The restriction bounds who can send the request; it does not restore the authentication the interface is not performing, so any address inside the permitted range — an administrator workstation, a jump host, a management VLAN routable from the general internal network — still reaches an interface that authenticates no one, and the measure is unavailable at all where the management interface must stay reachable for operations.",
+        "evidence": "Packet vector: 'An authentication bypass in Palo Alto Networks PAN-OS software enables an unauthenticated attacker with network access to the management web interface to gain PAN-OS administrator privileges to perform administrative actions, tamper with the configuration, or exploit other authenticated privilege escalation vulnerabilities like CVE-2024-9474', with 'The risk of this issue is greatly reduced if you secure access to the management web interface by restricting access to only trusted internal IP addresses', 'This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, PAN-OS 11.1, and PAN-OS 11.2 software' and 'Cloud NGFW and Prisma Access are not impacted by this vulnerability.' affected_versions: PAN-OS 10.2 / 11.0 / 11.1 / 11.2 prior to fixed releases. cisa_kev true, kev_date 2024-11-18, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 83. active_exploitation_notes: 'Actively exploited in the wild beginning November 2024 in a campaign researchers dubbed Operation Lunar Peek; chained with CVE-2024-9474 privilege-escalation to achieve full PAN-OS firewall takeover. CISA KEV flags ransomware use as Known.' patch_available true, patch_required_reboot true, live_patch_available false. AU-Essential-8-Patch gap: 'The Essential-Eight 48-hour internet-facing patch window is still slower than the ransomware-linked exploitation of a pre-auth admin bypass on a PAN-OS management interface.' NIS2-Art21-vulnerability-management gap: 'NIS2 vulnerability-handling obligations ... didn't prevent weeks of active exploitation before KEV listing forced remediation.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The PAN-OS management web interface is the device-management surface this control governs, and for this CVE the authorization half is the load-bearing one — the packet places the defect in the interface's own authentication decision, with administrative actions and configuration tampering reachable by a caller who never authenticates (CWE-306), not in a misconfigured access policy. Bound to this product the control means two things. First, that the privileged functions behind the management interface authorize their caller themselves rather than inheriting a verdict from a front-end that can be bypassed; that property is what the fixed PAN-OS release for each of 10.2, 11.0, 11.1 and 11.2 establishes — this control states what to verify, it does not implement it. Second, that no PAN-OS unit is left with its management web interface reachable from a segment with no operational need to reach it: the vector's own deployment guidance points at restricting access to trusted internal IP addresses, and reachability is the entire exploit precondition. This is also why the cited access-enforcement and identity-side attestations pass cleanly while the path stays open — the attacker never presents a PAN-OS account, so per-account privilege scoping is never consulted and the account model an audit examines is bypassed rather than abused. Distinguishing test: from a general user VLAN and from an external address, attempt to load the PAN-OS management web interface on a staging unit and confirm nothing answers; anything that responds is within reach of the published bypass, and 'the firewall's management plane is internal' is an assertion about topology rather than a demonstration that it is unreachable from untrusted segments. Precondition: restricting reachability bounds the population that can send the request and does not repair the authentication decision, and it gives nothing against a caller already inside the permitted management segment — a compromised administrator workstation or jump host satisfies the exploit's only stated access requirement in full.",
+        "evidence": "Packet vector places the flaw in the PAN-OS 'management web interface' with an unauthenticated attacker gaining 'PAN-OS administrator privileges to perform administrative actions, tamper with the configuration', and states 'The risk of this issue is greatly reduced if you secure access to the management web interface by restricting access to only trusted internal IP addresses'. cwe_refs: CWE-306. NIST-800-53-AC-3 gap: 'Access enforcement on the management plane failed because the interface itself lacked authentication for privileged actions, not because an access policy was misconfigured.' NIST-800-53-SC-7 gap: 'Restricting the management interface to trusted internal IPs is a mitigating control, not a fix — PAN-OS instances with any internet exposure of the management plane remained vulnerable regardless of standard perimeter controls.' ISO-27001-2022-A.8.9 gap: 'a hardening baseline forbidding exposure of the PAN-OS management plane to untrusted networks would blunt this pre-auth bypass, whereas access-control policy cannot help once the interface authenticates no one.' DORA-Art-9 gap: 'ICT protection and prevention measures for financial-sector firewalls didn't account for a pre-auth bypass on the management plane of core network security appliances.' affected_versions: PAN-OS 10.2 / 11.0 / 11.1 / 11.2. patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-AC-3",
+          "ISO-27001-2022-A.8.9",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation record is what makes this a rebuild question rather than a patch ticket: confirmed in-the-wild exploitation from November 2024 in the campaign researchers dubbed Operation Lunar Peek, chained with CVE-2024-9474 to reach full PAN-OS firewall takeover, with KEV ransomware use flagged as Known. On a unit whose management web interface was reachable from an untrusted segment during that window, the fixed PAN-OS release restores the authentication check but removes nothing an attacker did with administrator privileges beforehand — the vector names configuration tampering explicitly, and a firewall's configuration is where administrative accounts, API keys, certificates and the rules the rest of the estate depends on live. So for an exposed unit the sequence is: export and preserve the running and candidate configuration for comparison against a known-good baseline before touching the device, rebuild from that baseline rather than upgrading in place, and rotate every credential the unit held or authenticated — local administrator accounts, API keys, certificates and any shared secret configured on it. The identity assumption the cited identity-and-access control rests on cannot be restored by the update alone, because the material that assumption depends on was readable and writable by an unauthenticated caller. Precondition: this is scoped to units whose management interface was actually reachable from an untrusted segment during the exposure window, and that determination has to come from network evidence rather than from an assumption in either direction. Where the evidence does not exist, the unit belongs in the rebuilt population by default — an authentication bypass leaves no failed-login record to hunt for, because the request never presents a credential for the device to reject.",
+        "evidence": "active_exploitation_notes: 'Actively exploited in the wild beginning November 2024 in a campaign researchers dubbed Operation Lunar Peek; chained with CVE-2024-9474 privilege-escalation to achieve full PAN-OS firewall takeover. CISA KEV flags ransomware use as Known.' Packet vector: unauthenticated attacker gains 'PAN-OS administrator privileges to perform administrative actions, tamper with the configuration, or exploit other authenticated privilege escalation vulnerabilities like CVE-2024-9474'. attack_vector: 'An unauthenticated attacker with network access to the PAN-OS management web interface gains administrator privileges, then chains CVE-2024-9474 for full root-equivalent compromise of the firewall.' active_exploitation confirmed; poc_available true; kev_date 2024-11-18. UK-CAF-B2 gap: 'Identity and access management guidance assumes authentication exists on privileged interfaces; this flaw bypassed authentication entirely.' patch_available true, live_patch_available false, patch_required_reboot true.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2024-9465": {
     "name": "Palo Alto Networks Expedition SQL Injection Vulnerability",
@@ -40658,7 +41861,29 @@
         "adequate": false,
         "gap": "Endpoint anomaly detection wasn't tuned to catch AppContainer-to-service RPC escalation, which requires sandbox-escape-specific telemetry most EDR baselines lack."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "Windows Task Scheduler is the component the packet names, and the escalation begins from a process that is already running: a low-privileged local application or AppContainer process invokes privileged Task Scheduler RPC functions, escapes the sandbox and reaches Medium integrity. For this CVE the control means the November 2024 Windows update carrying the fix is driven across the population the packet's affected_versions actually names — multiple supported Windows client AND server builds — rather than across the browser-facing workstations the RomCom delivery path implies; a sweep scoped to laptops because the entry point was a browser renderer reports clean across a server estate that is equally affected. Completion is measured per host against the fixed build for that SKU from the November 2024 advisory, not against 'approved' or 'downloaded' in the management console: patch_required_reboot is true and no live-patch path is registered, so a host that has taken the update but not restarted is still executing the vulnerable code and must be counted as exposed. The control's second half is the load-bearing one here — the attacker's starting position is a sandboxed process rather than an over-privileged account, so tightening user privilege contains nothing, which is precisely why an application-hardening attestation (browser sandboxing enabled) and an environment-segregation attestation can both pass cleanly while the privileged RPC path stays open; the AppContainer boundary is the thing being defeated, not a boundary that can be re-asserted by configuration. Precondition: the packet records no live-patch path and names no interim vendor mitigation, so nothing in it supports treating hardening as a substitute for the update — and because exploitation is confirmed and the chain needed no user interaction beyond the initial browser compromise, a host that rendered untrusted web content during the exposure window belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet: patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. affected is 'Microsoft Windows Task Scheduler; elevation-of-privilege vulnerability allowing a low-privileged local application/AppContainer process to escape sandbox restrictions and access privileged RPC functions'; affected_versions is 'Multiple supported Windows client and server versions per the November 2024 Patch Tuesday advisory'. cisa_kev true with kev_date 2024-11-12, active_exploitation 'confirmed', poc_available true, RWEP 77, CVSS 8.8. attack_vector: 'After gaining code execution inside a sandboxed AppContainer (e.g. via a browser renderer exploit), an attacker invokes privileged Task Scheduler RPC functions to escape the sandbox and escalate to Medium integrity, with no user interaction required beyond the initial browser compromise.' Cited gaps: NIST-800-53-SI-2 'Monthly Patch Tuesday cadence trailed live zero-day exploitation by RomCom; the flaw was weaponized before a patch existed'; AU-Essential-8-App-Hardening 'Application hardening (browser sandboxing) was itself the control defeated by this chained zero-day, showing hardening alone is insufficient against a companion OS-level flaw'; ISO-27001-2022-A.8.22 'The AppContainer sandbox is a segregation boundary this flaw crosses to reach privileged RPC'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.22"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet attributes exploitation of this Task Scheduler flaw to the Russia-aligned RomCom threat actor, used as a zero-day and chained with a Mozilla Firefox zero-day against European and North American targets between October and November 2024. For this CVE the control means the runbook's escalation trigger is the chain shape rather than a malware verdict: a browser-renderer compromise followed on the same host by a Task Scheduler privilege transition to Medium integrity is the pattern the packet describes, and handling it as commodity browser-exploit cleanup under-scopes the response. Escalation here has to assume targeting rather than opportunism — preserve the host rather than reimaging it first, scope what the Medium-integrity foothold could reach, and treat other hosts in the same targeted population as in scope, because the packet describes campaign activity across two regions over a two-month window rather than an isolated infection. Precondition, and it is the binding one: this is a response control that fires only if something reported the escalation. The packet's own system-monitoring gap states that endpoint anomaly detection was not tuned to catch AppContainer-to-service RPC escalation and that most EDR baselines lack that sandbox-escape telemetry, so an estate that never collected it has no event for the runbook to escalate — the runbook does not create the signal. It also prevents nothing: it does not stop the escalation, and it does not evict an actor already holding Medium integrity on the host.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited in the wild as a zero-day by the Russia-aligned RomCom threat actor, chained with a Mozilla Firefox zero-day (CVE-2024-9680) to escape the browser sandbox and escalate to Medium integrity with no user interaction, in campaigns against European and North American targets between October and November 2024.' active_exploitation is 'confirmed'. Cited gaps: NIS2-Art21-incident-handling 'EU entities lacked telemetry to detect this AppContainer-escape technique as part of standard incident-handling baselines'; NIST-800-53-SI-4 'Endpoint anomaly detection wasn't tuned to catch AppContainer-to-service RPC escalation, which requires sandbox-escape-specific telemetry most EDR baselines lack.'",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-43451": {
     "name": "Microsoft Windows NTLMv2 Hash Disclosure Spoofing Vulnerability",
@@ -40860,7 +42085,38 @@
         "adequate": false,
         "gap": "Renewed exploitation of a decade-old, MEDIUM-severity XSS wasn't detected by most operators until Cisco publicly revised its bulletin; CAF C1 security monitoring needs signature coverage extended to old CVEs."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-074",
+        "name": "CVE-REGRESSION-WATCHER",
+        "description": "Nothing about this vulnerability changed - only its status did, and that is what the intake pipeline has to be able to see. The packet records poc_available false and CVSS 6.1, so no new exploit publication forced anyone's hand; what happened is that Cisco PSIRT revised its advisory for this decade-old ASA WebVPN login-page XSS to note renewed exploitation attempts (the packet records a 2024-03-18 publication and a further bulletin revision on 2024-12-02 confirming additional attempted exploitation), and CISA added CVE-2014-2120 to KEV on 2024-11-12. The requirement is an intake rule that re-opens historical CVE identifiers on exactly those two events - a vendor advisory revision and a KEV addition - instead of only on first disclosure, and that the resulting re-triage runs against the estate as it stands rather than inheriting the risk decision filed in 2014. Bound to this product, the watcher's hit list is CVE-2014-2120 / Cisco Bug ID CSCun19025 against every Cisco ASA in service, and the re-triage has to be allowed to override the severity filter that closed the item originally: a MEDIUM-scored XSS is precisely what a CVSS-keyed cadence deprioritises, while this entry carries confirmed active exploitation and an RWEP of 53 against that 6.1 base score. Distinguishing test: query the intake pipeline for CVE identifiers older than two years that acquired a KEV date or an advisory revision in the last quarter, and confirm each produced a ticket - a pipeline that only surfaces newly published CVEs returns an empty set and reports clean while this one is being exploited.",
+        "evidence": "active_exploitation_notes state that CISA added this to KEV in November 2024 after Cisco PSIRT revised its decade-old advisory (originally published 2024-03-18) to note renewed exploitation attempts, with a further bulletin revision on 2024-12-02 confirming additional attempted exploitation, and that CloudSEK reports AndroxGh0st botnet operators chaining this WebVPN login-page XSS with other Cisco ASA/IOS flaws in attempts to upload and backdoor PHP files for persistence; it is not flagged as ransomware. kev_date 2024-11-12, active_exploitation confirmed, poc_available false, CVSS 6.1, RWEP 53. The vector identifies the flaw as a cross-site scripting vulnerability in the WebVPN login page in Cisco ASA Software, injectable via an unspecified parameter, Bug ID CSCun19025. The framework record states that a 2014 flaw resurfacing a decade later shows patch-verification programmes rarely re-check advisories on EOL-adjacent devices and that SI-2 needs a KEV-relisting trigger rather than first-disclosure tracking; that A.8.8 vulnerability-management scope should include re-triage when a vendor revises a decade-old bulletin, since most asset inventories treat 2014 CVEs as permanently resolved; and that NIS2 Article 21 network-security obligations for entities running Cisco ASA as their VPN boundary require re-verification of decade-old advisories once CISA confirms renewed exploitation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The operative fact on this entry is in affected_versions: Cisco ASA Software releases predating the CSCun19025 fix, including EOL and unpatched branches still in production in 2024. patch_available is true, so a fixed release exists - but not necessarily for the branch a given appliance runs, and that has to be established per unit rather than assumed in either direction. The inventory therefore names every Cisco ASA in service with the software branch it runs and that branch's support status obtained from Cisco. Units on a branch that still receives fixes are remediation items: move them to a release carrying the CSCun19025 fix, and because patch_required_reboot is true with no live-patch path registered on this entry, completion is the image the appliance is running after the reload, not the image staged on it. Units on an end-of-life branch cannot reach the fix at all; those are replacement items - onto a supported branch the hardware can run, or onto new hardware - and they need a dated schedule, because a risk acceptance with no end date leaves a KEV-listed, actively-exploited VPN boundary appliance in service against everything found in that branch since it stopped receiving fixes, not merely against this XSS. Precondition on reachability, which is where this control is usually over-claimed: the defect lives in the WebVPN login page, so a unit that does not have WebVPN in operational use does not present that page - confirm that per unit rather than assume it - and on a unit that does, the page must stay reachable to the remote-access population it exists to serve, so there is no network restriction that removes the path while the service is in use.",
+        "evidence": "affected_versions state: Cisco ASA Software releases predating the CSCun19025 fix, including EOL/unpatched branches still in production in 2024. affected names the Cisco Adaptive Security Appliance (ASA) Software WebVPN login page, with reflected cross-site scripting via an unspecified parameter, Bug ID CSCun19025. CWE-79; CISA KEV-listed 2024-11-12 with active_exploitation confirmed; poc_available false; CVSS 6.1, RWEP 53. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. The framework record states that Essential Eight patch cadence typically deprioritizes MEDIUM-severity, decade-old bugs and that this CVE shows old low/medium CVEs can return to active exploitation and need periodic re-triage against KEV - the gap this control answers for the subset of units whose branch has no fix to apply, where a cadence-based patch control cannot complete at all.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The Cisco ASA is the perimeter-trust-boundary device this control names, and the monitoring failure on this entry is concrete: renewed exploitation attempts went unnoticed by operators until Cisco revised its bulletin. The packet also describes where the chain is heading - AndroxGh0st operators chaining this WebVPN login-page XSS with other Cisco ASA/IOS flaws in attempts to upload and backdoor PHP files for persistence - which is the case that makes the separate trust zone load-bearing, because telemetry that only lives on a device an attacker is trying to backdoor is not evidence you can rely on afterwards. So ASA syslog, WebVPN request logs and authentication logs must be forwarded to a collector in a different trust zone with its own credentials and management path, and the detection content on that collector has to key on what this attack actually emits: requests to the WebVPN login page carrying script or HTML markup in a URL parameter - the flaw is reflected, so the payload is present in the request as delivered - and the same source progressing to the upload and file-write attempts the packet describes as the chained follow-on. A rule keyed on appliance crashes, reboots or exploit-tool signatures will not fire here: a successful reflection produces an ordinary login-page render, and with poc_available false there is no public tool fingerprint to match. Precondition: this is detection, not prevention. Forwarding telemetry shortens the interval between the crafted request and the operator knowing; it does not stop the injection, which only a release carrying the CSCun19025 fix does, applied and reloaded.",
+        "evidence": "The vector states the flaw is a cross-site scripting vulnerability in the WebVPN login page in Cisco ASA Software allowing remote attackers to inject arbitrary web script or HTML via an unspecified parameter (Bug ID CSCun19025), and affected records it as reflected. attack_vector states an attacker crafts a URL targeting the ASA WebVPN login page with a script-injection payload in an unspecified parameter and that, a decade after disclosure, actors including AndroxGh0st began chaining it with other Cisco flaws to attempt file upload and backdooring; active_exploitation_notes attribute that chaining report to CloudSEK, naming AndroxGh0st botnet operators chaining this XSS with other Cisco ASA/IOS flaws in attempts to upload and backdoor PHP files for persistence. poc_available false; CISA KEV-listed 2024-11-12 with active_exploitation confirmed; CVSS 6.1, RWEP 53; patch_available true, patch_required_reboot true, live_patch_available false. The framework record states that renewed exploitation of a decade-old, MEDIUM-severity XSS was not detected by most operators until Cisco publicly revised its bulletin, and that UK CAF C1 security monitoring needs signature coverage extended to old CVEs, not only recent ones - the gap this control is attached to.",
+        "gap_closes": [
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2024-5910": {
     "name": "Palo Alto Networks Expedition Missing Authentication Vulnerability",
@@ -40902,7 +42158,38 @@
         "adequate": false,
         "gap": "Expedition is itself security infrastructure whose compromise cascades to every firewall it manages, raising the bar beyond routine vulnerability-handling timelines."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Expedition is the device-management tool the packet names — a Palo Alto Networks utility for firewall configuration migration, tuning and enrichment — and the defect sits on its administrative surface: the admin password-reset function performs no authentication, so an attacker with network access resets the admin password and takes the account over. Of this control's two halves, the authentication half is the load-bearing one and the input-neutralization half does not apply: nothing is being smuggled past a filter, the function simply never makes an authentication decision, which is why the packet's CWE is missing authentication for a critical function. Bound to this product it means each administrative function on Expedition — the password-reset path first — authorizes its caller before it executes, and no Expedition instance is left reachable from a segment with no operational need to reach it. The distinguishing test: from a segment with no configuration-migration role, send an unauthenticated request to the admin password-reset function on a staging Expedition instance and confirm it is refused before the password changes. An attestation that every Expedition operator authenticates at login passes cleanly while this path stays wide open, because the attacker never holds any Expedition account and the identity control's account model is never consulted. Precondition: the caller-side authorization is a property the vendor update to 1.2.92 establishes — this control states what to verify, it does not implement it. Until 1.2.92 is running, restricting which segments can reach Expedition bounds who can send the reset (the packet's only stated access requirement is network access to Expedition), but it leaves the function fully exploitable to anything inside the permitted segment, including a compromised engineering workstation or jump host, and it is unavailable where migration engineers must reach the tool. Measure the fix on the version the running Expedition service reports: patch_required_reboot is false, which records no host reboot, not that a service still executing pre-fix code has picked the fix up.",
+        "evidence": "Packet vector: 'Missing authentication for a critical function in Palo Alto Networks Expedition can lead to an Expedition admin account takeover for attackers with network access to Expedition. Note: Expedition is a tool aiding in configuration migration, tuning, and enrichment. Configuration secrets, credentials, and other data imported into Expedition is at risk due to this issue.' cwe_refs CWE-306; attack_vector describes a request to the admin password-reset function 'which performs no authentication check'. affected_versions: 'Expedition versions prior to 1.2.92'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null; poc_available true; CVSS 9.8, RWEP 72. Cited gaps: NIST-800-53-IA-2 'Expedition's admin password-reset function lacked identification/authentication entirely; IA-2 controls assumed at the app layer were absent by design in the vulnerable versions'; ISO-27001-2022-A.8.9 'configuration management should have caught an admin function shipped with no authentication gate by design before release'; UK-CAF-B4 'secure configuration expectations were violated by shipping an admin function with no authentication check by default.'",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "ISO-27001-2022-A.8.9",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "Expedition is a control-plane asset for a firewall fleet: the packet states that configuration secrets, credentials and other data imported into it are at risk from this flaw, and that harvested credentials give attackers a path to compromise downstream production firewalls. That makes the upgrade to 1.2.92 the smaller half of the response — the update closes the unauthenticated reset path but does not un-disclose a single secret already read out of the instance, and those secrets stay valid until they are rotated. For this product the playbook means: enumerate which PAN-OS configurations were imported into each Expedition instance and when, rotate every credential and secret contained in those imported configurations plus the Expedition admin account itself, audit the downstream firewalls whose configurations were exposed for changes made during the window, and set quarantine criteria for any of them showing unexplained configuration or account changes. Ordering matters here in a way it does not for an ordinary application: rotating on the firewalls while an unpatched Expedition instance still holds the new material simply re-exposes it, so the instance is patched or taken offline first. Precondition: the rotation scope is bounded by knowing what was imported, so the import inventory is part of the playbook rather than an input to it — an Expedition instance stood up ad hoc for a migration, with no record of which device configurations were loaded, cannot scope its own rotation and has to be treated as having exposed everything it ever imported. This control does not prevent the takeover and it does not detect it; it bounds what a takeover that already happened costs, and the packet records confirmed in-the-wild exploitation with a public proof of concept, so an instance that was network-reachable during the exposure window belongs on this path rather than being closed on the upgrade.",
+        "evidence": "Packet vector note: 'Configuration secrets, credentials, and other data imported into Expedition is at risk due to this issue.' affected: 'missing authentication for a critical admin function allows account takeover and access to imported PAN-OS configuration secrets and credentials.' active_exploitation_notes: 'Horizon3.ai researcher Zach Hanley published a working PoC (\"From N-Day to Full Compromise\") showing an unauthenticated attacker could reset the Expedition admin password and reach imported PAN-OS configuration secrets and credentials. Not flagged as ransomware, but harvested credentials give attackers a path to compromise downstream production firewalls.' active_exploitation 'confirmed'; poc_available true; patch_available true with affected_versions 'Expedition versions prior to 1.2.92'. Cited gap NIS2-Art21-vulnerability-handling: 'Expedition is itself security infrastructure whose compromise cascades to every firewall it manages.'",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock this control sets runs for this CVE from the 2024-11-07 KEV listing, with the fixed release (1.2.92) already available and a working proof of concept public — so there is no window in which a normal application-patch cadence is defensible, and the packet's own Essential Eight gap says the KEV remediation window is already tight given the trust Expedition holds over a firewall fleet. What makes the SLA hard to meet here is enumeration rather than the upgrade itself: Expedition is a migration utility, typically stood up by an engineer for a specific project and left running afterwards, so the instances most likely to be missed are the ones no software inventory records and no owner claims. The SLA therefore has to be driven from a deliberate hunt for Expedition instances — including any that were built for a finished migration — and each one taken to 1.2.92 or shut down, with completion measured on the version the running instance reports. Precondition on the interim mitigation, and it is the usual over-claim: the exploit precondition the packet states is network access to Expedition, so restricting reachability to a migration-engineering segment bounds who can send the unauthenticated reset but does not close the function for anything inside that segment, and it is unavailable while engineers are actively using the tool. It also gives nothing retroactively — reachability restriction applied after the fact does not invalidate secrets already read out of the instance, which is the separate rotation obligation.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-11-07, active_exploitation 'confirmed', poc_available true, patch_available true, affected_versions 'Expedition versions prior to 1.2.92', patch_required_reboot false, live_patch_available false, live_patch_notes null, CVSS 9.8, RWEP 72. Vector states the attacker requirement is 'network access to Expedition'. Cited gap AU-Essential-8-Patch: 'Essential Eight patch-applications guidance for network/security tooling; a 21-day KEV remediation window is tight given Expedition typically holds elevated trust to an entire firewall fleet.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-51567": {
     "name": "CyberPanel Incorrect Default Permissions Vulnerability",
@@ -41416,7 +42703,29 @@
         "adequate": false,
         "gap": "Security monitoring tuned to known-bad indicators misses a first-seen exploit chain with no prior signature."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's affected list is not one product on one channel: the fix lands as Firefox 131.0.2, Firefox ESR 128.3.1 and Firefox ESR 115.16.1, and as Thunderbird 131.0.1, 128.3.1 and 115.16.0. A no-deferral rule scoped to the browser's release channel therefore reports an estate clean while two ESR populations and every Thunderbird install stay on pre-fix code — and ESR is precisely the channel an organisation that defers updates has standardised on, so the population most likely to be governed by an update ring is the population a release-channel-only ring misses. For this CVE the requirement is per-channel: each of the six builds is its own target, and an install counts as remediated only against the fixed build for the channel it is actually on. Thunderbird has to be enumerated as its own deployment with its own owner, because in most estates it is neither distributed nor measured by browser update policy, even though the packet places the same content-process animation-timeline defect in it. Completion is measured on the version the running process is executing rather than the version present on disk: patch_required_reboot is false, but that is a statement about the machine, not about the application — a Firefox or Thunderbird process already running when the update was staged keeps executing the pre-fix animation-timeline code until that process itself restarts, and a mail client left open for weeks is the normal case rather than the exception. Precondition: this control compresses only the window after the fixed builds existed. The packet records ESET finding the flaw already weaponised in the wild on 2024-10-08 and CISA listing it on 2024-10-15, so no update cadence covers the period before the fix shipped, and a host that rendered untrusted web content while below its channel's fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet affected: 'Mozilla Firefox and Thunderbird content-process animation-timeline handling: use-after-free reachable via crafted web content, enabling code execution in the content process.' affected_versions: Firefox < 131.0.2, Firefox ESR < 128.3.1, Firefox ESR < 115.16.1, Thunderbird < 131.0.1, Thunderbird < 128.3.1, Thunderbird < 115.16.0. cwe_refs CWE-416; cvss 9.8; rwep_score 50; poc_available false; ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null, patch_required_reboot false. cisa_kev true with kev_date 2024-10-15 and active_exploitation confirmed; active_exploitation_notes record ESET discovering it in the wild on 2024-10-08. The NIST-800-53-SI-2 gap states that standard flaw-remediation SLAs assume disclosed vulnerabilities rather than a zero-day weaponised in a drive-by chain before a patch exists; the NIS2-Art21-vulnerability-handling gap states that vulnerability-handling processes built around vendor advisories lag a same-day-disclosed zero-day.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet does not describe an opportunistic browser bug. It names RomCom (Storm-0978 / Tropical Scorpius / UNC2596) running this Firefox content-process use-after-free chained to a second Windows privilege-escalation zero-day, CVE-2024-49039, so that visiting a page produced sandbox-escaped code execution and a silently installed backdoor with no user interaction — an attributed actor operating a confirmed exploit chain, which is the escalation trigger this control defines. For this CVE the operational consequence is that the trigger cannot be an alert: poc_available is false, the chain was first-seen when ESET found it, and delivery is zero-click, so there is no user report, no prompt, no download and no prior signature to fire on. The trigger has to be exposure itself — a host on a pre-fix Firefox or Thunderbird build that rendered untrusted content during the window. Hosts identified that way go onto the actor-attributed initial-access path, which includes reviewing the Windows host and not only the browser process, because the packet places the sandbox escape in a separate Windows flaw; they do not go into commodity-malware handling that closes when anti-malware reports clean, which is the specific way this response goes wrong. Precondition: this control changes the response class, it does not prevent exploitation and it evicts nothing. Reaching the fixed Firefox and Thunderbird builds removes the entry point but removes nothing the backdoor already installed on a host that was exploited, so an in-scope host is triaged on its own evidence rather than closed on its browser version.",
+        "evidence": "Packet active_exploitation_notes: 'Discovered in the wild by ESET on 2024-10-08 as the trigger for a RomCom (Storm-0978/Tropical Scorpius/UNC2596) zero-click drive-by campaign that chained this Firefox content-process UAF with Windows privilege-escalation flaw CVE-2024-49039 to escape the sandbox and drop the RomCom backdoor with no user interaction. CISA KEV flags this entry as tied to known ransomware-affiliated activity.' attack_vector: 'A crafted web page triggers a use-after-free in Firefox's Animation timeline handling inside the content process... so a mere page visit resulted in sandbox-escaped code execution and silent backdoor install.' active_exploitation confirmed; poc_available false; cisa_kev true, kev_date 2024-10-15. The ISO-27001-2022-A.8.7 gap states that malware-protection controls assume signature or heuristic coverage while this first-seen zero-click chain delivers a payload no anti-malware baseline recognizes; the UK-CAF-B4 gap states that monitoring tuned to known-bad indicators misses a first-seen exploit chain with no prior signature.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-30088": {
     "name": "Microsoft Windows Kernel TOCTOU Race Condition Vulnerability",
@@ -41599,7 +42908,39 @@
         "adequate": false,
         "gap": "Patch Applications guidance assumes a supported product; CSA 4.6.x's EOL status means the compliant action is decommission, not patch."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry is a split estate and the split has to be resolved per appliance before any remediation clock means anything. The packet places the flaw in the admin web console of Ivanti CSA before version 5.0.2, so units on the 5.0.x branch have a build to reach — 5.0.2 or later — and belong on the KEV clock that opened 2024-10-09. The lesson entry's framework_coverage records the other population: CSA 4.6.x is past end-of-life with no vendor patch for that branch, so for those units there is no fixed build at all and the compliant action it names is decommission, not patch. The requirement in operational terms: enumerate every Ivanti CSA in service with its branch, put the 5.0.x units on the interim upgrade clock, and put every 4.6.x unit on a dated replacement or removal schedule — a risk acceptance with no removal date leaves a KEV-listed appliance with confirmed in-the-wild exploitation in service indefinitely. Scope it to what the packet names, Ivanti CSA units; nothing here implicates other Ivanti products, and inventorying them as instances of this CVE manufactures replacement work against software no evidence in this entry touches. Precondition, and this is where the interim half is normally over-claimed: reaching 5.0.2 closes this defect only and says nothing about anything found in the appliance since that build, which is exactly why the requirement cannot end at 'every CSA reports 5.0.2 or later'. The packet records patch_available true with live_patch_available false and no live-patch note, so each unit has to be taken through the vendor update — there is no in-place mitigation that leaves the appliance running unmodified. And because active exploitation is confirmed, a unit that was reachable during the exposure window is an incident item first: an appliance that already executed an attacker's commands is not remediated by the upgrade it later receives, and a 4.6.x unit being replaced is not remediated by the replacement either — what it held has to be treated as read.",
+        "evidence": "Packet: 'An OS command injection vulnerability in the admin web console of Ivanti CSA before version 5.0.2 allows a remote authenticated attacker with admin privileges to obtain remote code execution.' CISA KEV listing 2024-10-09; active_exploitation confirmed; poc_available false (so the absence of a public exploit is not grounds to defer — exploitation is already observed); RWEP 55; CVSS 7.2; patch_available true; live_patch_available false with live_patch_notes null. The repo lesson entry's framework_coverage for NIST-800-53-SI-2 records that 'CSA 4.6.x is past end-of-life with no vendor patch available for this branch, so flaw-remediation controls have no compliant remediation path short of migration', and its AU-Essential-8-Patch entry records that 'CSA 4.6.x's EOL status means the compliant action is decommission, not patch.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For this appliance the control's trigger conditions are met literally rather than by analogy: the packet's outcome is full remote code execution on the CSA, the admin position the flaw needs can be obtained by chaining a separate CSA authentication-bypass flaw so the effective path requires no credential, and exploitation is confirmed in the wild. What that means here is that the vendor upgrade is not the remediation decision for any CSA that was reachable while unpatched — the upgrade closes the injection sink and removes nothing an attacker executed through it. The default for those units is extraction of the running configuration for reference, rebuild from vendor media onto a build at or above 5.0.2, and rotation of every credential the appliance held or could authenticate to, before it is returned to service. This is precisely what the two vulnerability-management gaps cited here cannot express: A.8.8 and NIS2 Art 21 handling both terminate at a binary open/remediated verdict, so an appliance that was compromised and then upgraded closes as remediated on both attestations while the attacker's access persists through whatever was left on it. The distinguishing test is a question asked per unit rather than a scan: for each CSA in service before the upgrade, what evidence exists that it was not compromised? The lesson entry records that appliance-level logging on CSA is limited, so for most estates that evidence does not exist, and absence of an alert is not it. Precondition: rebuilding is only remediation if the rebuilt unit lands at or above 5.0.2 and the credentials it held are rotated — a 4.6.x unit rebuilt from its own image is reinstated with the vulnerability intact, since the lesson records no patch exists for that branch, and a rebuild without credential rotation returns a clean appliance to an attacker who already holds what it stored.",
+        "evidence": "Packet attack_vector: an attacker with admin access to the CSA administrative web console — 'obtained directly or by chaining a separate CSA authentication-bypass flaw' — injects OS commands 'passed unsanitized to the underlying operating system, yielding full remote code execution on the appliance'. CISA KEV 2024-10-09; active_exploitation confirmed; CWE-77 and CWE-78; patch_available true; live_patch_available false, live_patch_notes null. The repo lesson entry's defense_chain response section states that 'response must assume complete appliance compromise and treat any credentials it held as burned' and names isolating the appliance, hunting for implanted webshells and harvested credentials, and rotating all credentials the appliance had access to; its detection section records that 'appliance-level logging on CSA is limited'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The CSA's administrative web console is the management surface this control governs, and the defect sits on it: operator-supplied input reaches the underlying operating system unsanitized (CWE-77, CWE-78) and executes. Bound to this appliance the control means two properties. First, the console's command-invoking functions neutralize their input at the point it reaches the operating system — argument-array invocation or validation at the sink — rather than relying on the caller having authenticated as an administrator, because the packet's own path has that authentication reached by chaining a separate CSA authentication-bypass flaw, at which point the privilege verdict the sink is trusting is worthless. Second, no CSA is left with its administrative console reachable from a segment with no operational need to administer it. This is why the least-privilege gap cited on this entry does not close the path: the admin role is correctly assigned and correctly scoped, and the exploit trades that bounded application-admin position for unbounded OS execution on the appliance — an application-admin-to-host-OS bridge that a user-to-role privilege review never examines, so an AC-6 attestation passes cleanly while the console stays wired to a shell. Distinguishing test: enumerate, per CSA, which networks can reach the administrative console, and from a segment with no administrative role confirm the console does not answer — 'the appliance is behind the firewall' is a statement about topology, not a demonstration that the admin surface is unreachable. Precondition, and this is the half that gets over-claimed: the input neutralization is a property the vendor update at 5.0.2 or later establishes; this control states what to verify, it does not implement it, and the lesson records no such update exists for the end-of-life 4.6.x branch. Until the update lands, restricting reachability bounds who can present the request but leaves the console fully exploitable to anything inside the permitted segment — a compromised administrator workstation or jump host satisfies the precondition in full — and the lever is unavailable entirely where the administrative interface must stay reachable for the appliance's normal operation. It also does nothing about an appliance that already holds an implant.",
+        "evidence": "Packet: the flaw is in 'the admin web console of Ivanti CSA before version 5.0.2'; CWE-77 and CWE-78; the attack_vector describes injected OS commands 'passed unsanitized to the underlying operating system, yielding full remote code execution on the appliance', with the admin position reachable 'by chaining a separate CSA authentication-bypass flaw'. The entry cites NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) as insufficient. patch_available true with the packet's affected range ending before 5.0.2; live_patch_available false with no live-patch note recorded, so no in-place mitigation is available from the vendor.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-9379": {
     "name": "Ivanti Cloud Services Appliance (CSA) SQL Injection Vulnerability",
@@ -41773,7 +43114,29 @@
         "adequate": false,
         "gap": "Application hardening that doesn't disable/restrict the legacy MSHTML engine leaves this repeatedly-abused spoofing surface exposed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet names the sequence this CVE belongs to rather than leaving it to inference: it records that CVE-2024-43573 follows the same MSHTML-spoofing pattern as CVE-2024-38112 and CVE-2024-43461, the pair Void Banshee abused to trick victims into rendering malicious content through the deprecated MSHTML/Internet Explorer engine and deliver the Atlantida infostealer. Applied to this CVE, the control means the remediation ticket for the Windows MSHTML platform inherits that family's exploitation history instead of opening at this entry's own numbers — a 6.5 CVSS and an impact word of 'spoofing', both of which sort below the remote-code-execution items competing for the same maintenance window, while the packet simultaneously records confirmed active exploitation and a KEV listing on 2024-10-08. The second half of the requirement is the forward-looking one: an estate that treats this fix as closing the class has assumed the sequence ended at its third member, when the packet gives three members inside one year, all reached the same way and all used for the same purpose. Plan for a further member of the family rather than for a closed issue. Scope the sweep from the packet's affected_versions, which names Windows and Windows Server builds prior to the October 2024 cumulative security update — not client Windows alone. On remediation: that cumulative update is the fix, and because the packet records live_patch_available false with patch_required_reboot true, a host that has installed the update but has not yet restarted is still executing the pre-fix MSHTML platform and must be counted as exposed rather than as patched. Distinguishing test: ask the vulnerability-management program to produce the priority it assigned this CVE and the priority it assigned CVE-2024-38112 and CVE-2024-43461 — a program that scored each independently from its own severity band, and closed each on its own ticket, is the failure this control names.",
+        "evidence": "All from the packet for CVE-2024-43573: active_exploitation_notes states the flaw was patched and flagged as actively exploited in Microsoft's October 2024 Patch Tuesday, added to CISA KEV on 2024-10-08, and that it 'follows the same MSHTML-spoofing pattern as CVE-2024-38112 and CVE-2024-43461, which the Void Banshee APT abused to trick victims into rendering malicious content via the deprecated MSHTML/Internet Explorer engine to deliver the Atlantida infostealer'. cisa_kev true, kev_date 2024-10-08, active_exploitation confirmed, cvss 6.5, rwep_score 57, poc_available false. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. affected_versions: 'Windows and Windows Server builds prior to the October 2024 cumulative security update'. The NIST-800-53-SI-2 gap states patch-SLA windows for a moderate-severity spoofing bug (CVSS 6.5) do not reflect that it was actively used as a malware-delivery primitive before patching; the NIS2-Art21-vulnerability-management gap states severity-based prioritization that deprioritizes 'spoofing' classifications over 'RCE' misses that this class is repeatedly weaponized for initial-access malware delivery.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-119",
+        "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
+        "description": "The packet's affected field describes the defect precisely: an unauthenticated remote attacker who convinces a victim to open a crafted file can spoof the rendering context, tricking the user into executing attacker-controlled content. The file's own content is therefore what decides how it is presented, and the thing being deceived is the user's judgement about what the file is. Bound to this CVE, the control means the handling decision for an externally-sourced file is taken from provenance established at the ingress boundary — the mail gateway, the web download path, the untrusted file share — and applied by that boundary itself, rather than derived by the endpoint from what the file presents itself as. The untrusted-origin marking must survive the container the file is delivered in, so that a file extracted from an archive or renamed on the way still reaches the endpoint marked as externally sourced. The distinguishing test is delivery-side, not policy-side: send an externally-sourced file through each ingress path into the estate and confirm it arrives at the endpoint carrying the untrusted-origin marking, rather than confirming only that a handling policy exists for marked files. This is also the reason the control acts where signature-based malicious-code protection cannot: origin is known at the boundary, whereas the packet records that the payload here is only revealed after the deprecated MSHTML engine renders the file deceptively, which is after any signature decision has already been made. Preconditions, both load-bearing. This bounds only files that cross a boundary which applies the marking — a file arriving on removable media, or through a channel that applies none, reaches the MSHTML platform with no provenance at all, and for that path the control offers nothing. And the marking does not repair the spoofing: the platform still misrepresents the rendering context until the October 2024 cumulative security update is installed and the host restarted, which the packet records as required, with no live-patch path available. This is a holding measure for the window before that update and restart, not a substitute for them.",
+        "evidence": "All from the packet for CVE-2024-43573: affected states 'Windows MSHTML Platform: an unauthenticated remote attacker who convinces a victim to open a crafted file can spoof the rendering context, tricking the user into executing attacker-controlled content (used as a malware-delivery primitive)'. attack_vector states the attacker convinces a victim to open a crafted file that abuses the Windows MSHTML platform to spoof its true content/rendering context, following the technique family used to disguise malware droppers as benign documents. cwe_refs CWE-79. The UK-CAF-B4 gap states user-facing security awareness and file-type verification controls are defeated when the OS itself misrepresents the rendering engine/file type to the user; the NIST-800-53-SI-3 gap states malicious-code protection tuned to known file signatures misses a spoofing technique whose payload is only revealed after the deprecated MSHTML engine renders it deceptively. patch_available true, patch_required_reboot true, live_patch_available false; affected_versions names Windows and Windows Server builds prior to the October 2024 cumulative security update.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-3"
+        ]
+      }
+    ]
   },
   "CVE-2024-43572": {
     "name": "Microsoft Windows Management Console Remote Code Execution Vulnerability",
@@ -43000,7 +44363,31 @@
         "adequate": false,
         "gap": "Least-functionality/removal of the end-of-life Flash Player plugin is the only durable fix; a control that merely inventories software does not force removal of an unsupported client component."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This packet carries both halves of the control. A vendor fix is recorded — the vector names Flash Player 10.3.183.67 and, on the 11.x branch, 11.6.602.171 on Windows and Mac OS X and 11.2.202.273 on Linux — and the live-patch notes state the vendor update requires no reboot. Against that, the lesson's framework coverage records that removal of the end-of-life Flash Player plugin is the only durable fix, and that a control which merely inventories software does not force removal of an unsupported client component. Together those set the requirement: reaching a fixed Flash Player build is an interim state, and the terminal state is removing Flash Player from the host, or replacing the workload where something still depends on it. A KEV listing dated 2024-09-17 for a flaw the vector records as exploited in the wild in February 2013 is the evidence that the long tail is real — a host still exposed eleven years after the fix shipped is a host with no functioning update path for the product. Scope it to what the packet names: Adobe Flash Player, and specifically the Firefox plugin sandbox the vector identifies, on Windows, Mac OS X and Linux. The packet provides no mapping from this defect into other SWF-capable or media-runtime software, so treating every plug-in or media player in the estate as an instance of this CVE manufactures removal work against software no evidence implicates. Operationally: enumerate every host with Flash Player installed, record for each whether it can take the fixed build for its branch and platform, put those on the interim clock, and put every host on a dated removal or replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with confirmed exploitation in service indefinitely. Precondition on the interim half, which is where this is usually over-claimed: applying the 2013 update closes this defect only and says nothing about anything found in Flash Player since, and because the product's patch path has ended there is no later update to take, which is exactly why the requirement cannot end at every install reporting a fixed build. And because exploitation is confirmed and the delivery path is crafted SWF content the victim's browser loads, a host that browsed untrusted web content while exposed belongs on the incident path — hunted for second-stage payloads and rebuilt if confirmed — rather than being closed on the patch record.",
+        "evidence": "Packet: CWE-269 incorrect default permissions — the vector states the Firefox sandbox in Adobe Flash Player before 10.3.183.67 and 11.x before 11.6.602.171 on Windows and Mac OS X, and before 10.3.183.67 and 11.x before 11.2.202.273 on Linux, does not properly restrict privileges, making it easier for remote attackers to execute arbitrary code via crafted SWF content, as exploited in the wild in February 2013. cisa_kev true, kev_date 2024-09-17, active_exploitation confirmed, poc_available false, cvss 8.8, rwep_score 48. 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.' The lesson's framework_coverage for NIST-800-53-CM-7 records that least-functionality/removal of the end-of-life Flash Player plugin is the only durable fix, and that a control which merely inventories software does not force removal of an unsupported client component; its response guidance names purging Flash from managed endpoints, hunting for post-exploitation second-stage payloads, and reimaging confirmed-compromised hosts. AU-Essential-8-App-Hardening (User application hardening), NIST-800-53-CM-7 (Least Functionality), NIST-800-53-SI-2 (Flaw Remediation) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock is the one thing a vulnerability-management program will get wrong on this entry. The packet records the fix as shipping against exploitation the vector places in February 2013, and the KEV listing as 2024-09-17, so under 'whichever is later' the deadline runs from the 2024 listing rather than from the original disclosure — an eleven-year-old finding becomes a current obligation the day CISA lists it. Two of the packet's own fields are what keep it off the queue otherwise: poc_available is false, so a triage rule gated on public exploit code never raises it, and a program that ages or deprioritizes findings by CVE year treats a 2013 identifier as historic while the packet records active_exploitation as confirmed. For this entry the documented-compensating-controls branch is the one most operators will need, because live_patch_available is false and the durable answer for an unsupported plugin is removal, which usually needs a change window longer than the deadline: block SWF content at the web gateway for the hosts that cannot be reached inside the window, and record that as a time-bound compensating state carrying a removal date, not as remediation. Distinguishing test: query the vulnerability register for items whose KEV listing date postdates their CVE year by more than a year, and confirm each carries a deadline derived from the listing date — a register whose Flash Player finding is dated 2013 and sorted to the bottom is measuring disclosure age rather than exposure. Precondition: a gateway block on SWF content bounds delivery only over the paths the gateway sees; it does nothing for content that reaches the browser without traversing it, and it does not remove the plugin, so it holds only until the removal schedule lands.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-09-17, against a vector that records exploitation in the wild in February 2013 and names the fixed builds (10.3.183.67; 11.x fixed at 11.6.602.171 on Windows and Mac OS X and 11.2.202.273 on Linux). active_exploitation confirmed, poc_available false, cvss 8.8, rwep_score 48. 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.' The lesson's prevention guidance names uninstalling or disabling the Flash Player plugin and blocking SWF content at the web gateway. NIS2-Art21-vulnerability-management (Vulnerability handling) and UK-CAF-B4 (System security) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2014-0497": {
     "name": "Adobe Flash Player Integer Underflow Vulnerablity",
@@ -43334,7 +44721,22 @@
         "adequate": false,
         "gap": "Least-privilege alone does not help — the flaw lets an already-present low-privileged user escalate to SYSTEM, defeating the privilege boundary the control assumes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet puts this in Windows Installer and describes a local low-privileged user triggering a repair, which briefly runs an elevated process, then either hijacking that elevated context or racing the rollback temp files with symlinks and oplocks to obtain a SYSTEM shell. Every account in that sequence is already legitimate, which is what makes the least-privilege gap cited on this entry unclosable from the account side: nothing over-broad is being abused, so an attestation showing ordinary users hold ordinary rights passes cleanly while any interactive user on the host can take SYSTEM. The remediation is therefore the Windows update itself, driven across every affected host on the clock that opened with the 2024-09-10 KEV listing rather than folded into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU - never by 'approved', 'downloaded' or 'installed' in the management console. The packet's live-patch notes are decisive on that measurement: there is no live-patching primitive for this product and the vendor update requires a reboot to be the remediation, so a host that has taken the update and not restarted is still running the vulnerable Windows Installer path and must be counted as exposed rather than compliant. Enumerate hosts where many non-administrative users hold interactive sessions first - shared workstations, terminal and jump hosts - because on those the precondition this flaw needs, an ordinary local user able to trigger an installer repair, is the normal operating state rather than an anomaly, and those are also the hosts where the required restart is most likely to be deferred because taking it evicts logged-on users. The distinguishing test pairs the build with the boot: read each host's installed build and its last restart time together, and treat any host whose last restart predates the update as unremediated - a patch report showing the update installed marks that machine compliant while the vulnerable repair path is still live in memory. Priority follows the packet rather than the CVSS band: 7.8 reads as a routine endpoint item, while confirmed exploitation plus a public PoC on a user-triggerable path to SYSTEM makes this the escalation half of a chain whose initial-access half arrives separately.",
+        "evidence": "Packet: CISA KEV-listed 2024-09-10, active_exploitation confirmed, poc_available true, CVSS 7.8, RWEP 75, CWE-269, 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.' Attack vector: 'A local low-privileged user triggers a Windows Installer repair, which briefly runs an elevated process; by hijacking that elevated context (or racing the rollback temp files with symlinks/oplocks) the attacker obtains a SYSTEM shell.' Citing gaps include NIST-800-53-AC-6 (Least Privilege), NIST-800-53-SI-2 (Flaw Remediation), AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIS2-Art21-patch-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2024-38226": {
     "name": "Microsoft Publisher Protection Mechanism Failure Vulnerability",
@@ -43739,7 +45141,30 @@
         "adequate": false,
         "gap": "Even with an available patch, the interval between the emergency Chrome release and enterprise-wide browser update rollout leaves a window that observed in-the-wild exploitation can hit."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The delivery path the packet describes is a user visiting a crafted HTML page, so for this CVE the browser's own update channel is the entire remediation and the enterprise update ring is the only thing that can delay it. Bound to this product, the control means the Chrome security channel is not held in a staged or piloted ring for this release: the packet records a vendor fix (builds at or above 128.0.6613.84 no longer carry the V8 defect) with no live-patching primitive and no host reboot requirement — but a browser already running when the update lands keeps the pre-fix V8 resident, because the replaced binary is inert until the browser process itself restarts. So there is no maintenance window to schedule and no host to reboot, and there is still a relaunch to force: completion is the version V8 is actually executing, not the version deployed, and a managed record reading 128.0.6613.84 against a session nobody has restarted is a host still running the vulnerable renderer. Two things therefore keep an estate exposed — a deferral the operator configured, and a long-lived browser session the policy never forced to relaunch, which is the one most likely to have met a crafted page in the interim. The clock runs from the 2024-08-28 KEV listing, not from the next scheduled ring promotion, because exploitation is already confirmed. Note what the packet does and does not support about priority: poc_available is false, so an estate that ranks work by public exploit availability will place this below flaws with published code while it is being used in the wild — the ranking input here is the confirmed-exploitation flag, not PoC presence. Precondition: removing the ring deferral reaches only browser instances a managed update policy actually governs. A personally-installed Chrome, or one whose update policy has been overridden locally, is not covered by shortening the ring; those instances are remediated by bringing them under policy or removing them. And because the packet places the heap corruption in the renderer and describes it as typically chained with a sandbox escape, the update closes the V8 defect but says nothing about a host that was already reached through a chain built on it.",
+        "evidence": "Packet: CWE-787 and CWE-358, CVSS 8.8, RWEP 54, cisa_kev true with kev_date 2024-08-28, active_exploitation 'confirmed', poc_available false. Vector: 'Inappropriate implementation in V8 in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.' Attack vector: 'A user visits a crafted HTML page that exploits an inappropriate implementation in V8 to corrupt the heap in the renderer, typically chained with a sandbox escape for full code execution.' patch_available true, patch_required_reboot false; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The entry's framework_control_gaps state the relaunch requirement directly — NIS2-Art21-patch-management: 'Standard patch management must be augmented with forced browser relaunch, since an updated binary is inert until the browser restarts.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Chrome takes this fix through its own security channel rather than through the operating system's package inventory, so on this CVE an operating-system patching attestation is measuring something that never carried the fix — which is exactly why an OS-patching control is recorded as insufficient here. The requirement is that browser currency be measured from the version each managed Chrome instance actually reports, checked against the packet's fixed level of 128.0.6613.84, and never from a management console's 'approved' or 'pushed' state or from an OS patch report that has no row for the browser at all. Distinguishing test: pull the running browser version from every managed endpoint — Chrome against 128.0.6613.84, and each other Chromium-based product against its own vendor fixed build — and show none is below it — an estate whose OS patch compliance reads clean while its fleet report carries no browser-version column has recorded nothing whatsoever about this flaw, and that is the specific way this one is marked compliant while it stays exploitable. Scope the sweep to what the entry names, which is wider than Chrome: the defect is in V8, and the affected products are recorded as Google Chrome and other Chromium-based browsers, Edge and Opera among them, on affected V8 builds. A sweep limited to Chrome therefore reports clean across an estate standardised on Edge, and those products are checked against their own vendor fixed builds rather than against the Chrome version string, which they do not report. The Chromium lineage is also the bound: treating every browser or every JavaScript engine in the estate as an instance of this CVE manufactures remediation work against software no evidence implicates. Precondition: this check sees only instances enrolled in the reporting channel. A browser installed outside managed software distribution produces no row, and an absent row is not a pass — it is an unmeasured instance that has to be enrolled or removed before the estate figure means anything.",
+        "evidence": "Packet vector names the affected component and fixed level: 'Inappropriate implementation in V8 in Google Chrome prior to 128.0.6613.84'. The entry's affected field reads 'Google Chrome and other Chromium-based browsers: an inappropriate implementation in the V8 JavaScript engine permits heap corruption via a crafted HTML page', and affected_versions lists both 'Google Chrome prior to 128.0.6613.84' and 'Chromium-based browsers (Edge, Opera) on affected V8 builds'. patch_available true; live_patch_notes state 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' active_exploitation 'confirmed', cisa_kev true, kev_date 2024-08-28. AU-Essential-8-Patch (Patch operating systems) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are both recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-38856": {
     "name": "Apache OFBiz Incorrect Authorization Vulnerability",
@@ -43897,7 +45322,40 @@
         "adequate": false,
         "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."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "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 — the packet records that update as 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 sweep from the packet's 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.",
+        "evidence": "Packet 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-ISM-1546 gap 'The ISM control for restricting web-application file uploads was not applied to the appliance's admin UI'; 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",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security",
+          "ISO-27001-2022-A.8.9",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The packet gives this Versa Director exploit exactly one precondition and it is an identity: Change Favicon is available only to Provider-Data-Center-Admin and Provider-Data-Center-System-Admin, tenant-level users do not have the privilege, and the vector states that exploitation is possible only after such a user has successfully authenticated and logged in. That makes the provider-level Director administrator the subject of this control rather than a generic application admin — the Director orchestrates the SD-WAN fabric and the packet records the victims as ISPs and MSPs, so the account that can change a favicon on this appliance is an account with reach into downstream customer networks. Applied here the control means those two roles are enumerated as a distinct privilege tier: identities separate from their holders' other admin or day-to-day accounts, phishing-resistant step-up authentication per session, access only through a privileged-access path rather than from general workstations, and just-in-time elevation so neither role is standing. That raises the cost of the only precondition the packet records, which is what mattered on this CVE specifically — the packet places exploitation as a zero-day from at least June 2024, months in which no vendor fix existed and holding a provider-level account was the entire attack path. Precondition: this bounds who can reach the upload function, it does not repair the function, and it gives nothing against an attacker already holding a valid provider-admin credential or session — the packet records the deployed web shell as stealing credentials, so on a Director that was exposed, rotating the credentials for these roles comes before any tier hardening means anything. Distinguishing test: enumerate every account holding Provider-Data-Center-Admin or Provider-Data-Center-System-Admin and confirm each is separate from its holder's ordinary identity and cannot authenticate to the Director from a general user segment — an access review recording that administrators are named and approved passes cleanly while one standing provider-admin credential remains the whole exploit precondition.",
+        "evidence": "Packet facts only: vector 'This option is only available for a user logged with Provider-Data-Center-Admin or Provider-Data-Center-System-Admin. (Tenant level users do not have this privilege) ... This is possible only after a user with Provider-Data-Center-Admin or Provider-Data-Center-System-Admin has successfully authenticated and logged in.'; attack_vector 'An attacker who has (or obtains) high-privilege Provider-Data-Center admin access uploads a Java/JSP payload disguised as a .png via the Change Favicon function ... then loaded the memory-resident VersaMem web shell to steal credentials'; active_exploitation_notes 'Exploited as a zero-day since at least June 2024 ... against ISPs and MSPs'; the UK-CAF-B4 gap 'System-security hardening for an SD-WAN orchestrator failed to lock down the privileged Change-Favicon upload path'; cisa_kev true (2024-08-23), active_exploitation confirmed, poc_available true, RWEP 75 / CVSS 7.2.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "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 packet's own system-security gap 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 the packet records as requiring 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.",
+        "evidence": "Packet 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"
+        ]
+      }
+    ]
   },
   "CVE-2021-31196": {
     "name": "Microsoft Exchange Server Remote Code Execution Vulnerability",
@@ -45588,7 +47046,32 @@
         "adequate": false,
         "gap": "Anomaly-detection controls that do not baseline WER registry manipulation and WerFault SYSTEM children miss the exact behavior ransomware operators used."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "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. The packet records no live-patch path and states plainly that 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 — the packet records an exploit tool attributed to the Cardinal / Storm-1811 group behind Black Basta with 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",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "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 packet's exploit path is specific: a local low-privileged user manipulates Windows Error Reporting registry values, and WerFaultSecure — which the packet records as running 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.",
+        "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",
+          "NIS2-Art21-incident-handling",
+          "ISO-27001-2022-A.8.7"
+        ]
+      }
+    ]
   },
   "CVE-2024-32896": {
     "name": "Android Pixel Privilege Escalation Vulnerability (CVE-2024-32896)",
@@ -46346,7 +47829,30 @@
         "adequate": false,
         "gap": "Malicious-code protection that relies on OLE/MSHTML mitigations is exactly what this security-feature bypass defeats, so signature/heuristic AV on the mitigation layer is insufficient."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "The packet's delivery path is an attacker-supplied document the victim opens, and what the flaw defeats is the prompt: MSHTML bypasses the OLE/mitigation prompts, loads malicious content, and executes in the user's context. That is precisely why provenance has to drive an isolated render rather than a warning on this entry — the mechanism this CVE breaks is the one that asks the user, so a policy that tightens prompt settings is hardening the thing the packet says stops firing. Bound to this entry the requirement is that every document arriving by mail, web download or untrusted file share be marked untrusted at the ingress boundary; that a marked document open in a reduced-privilege isolated view instead of the full handler path that reaches the MSHTML platform; and that the mark survive its container — extracted from an archive, mounted from a disk image, or renamed — because a document that loses it is indistinguishable from a locally authored one and takes the full path with the user's privileges. The distinguishing test is a delivery test, not a settings export: send a document through each ingress path to a managed workstation, extract it from whatever container it arrived in, and confirm it still opens isolated. An estate whose user-application-hardening and malware-protection attestations show the OLE and macro settings configured passes cleanly while the packet's exact scenario — a crafted document that bypasses those prompts — still executes, and signature-based malware protection has no artifact to match on a bespoke document. Precondition: an isolated render bounds this path, it does not remove it. A document that reaches the full handler anyway — provenance stripped in transit, delivered from an internal share the boundary does not mark, or opened out of the isolated view by the user — reaches the same code. The packet registers no live-patch path and states the vendor update requires a reboot and is the remediation, so a host that installed the update without restarting still runs the vulnerable code, and a host that already opened such a document belongs on the incident path rather than being closed on the delivery control.",
+        "evidence": "Packet: Windows MSHTML Platform Security Feature Bypass Vulnerability (CWE-20). Attack path per the packet: \"An attacker delivers a crafted document that, when opened, causes the MSHTML platform to bypass OLE/mitigation prompts and load malicious content, leading to code execution in the user's context.\" CISA KEV-listed 2024-05-14 with confirmed in-the-wild exploitation; CVSS 8.8, RWEP 57; poc_available 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.\" AU-Essential-8-App-Hardening (User application hardening), NIST-800-53-SI-3 (Malicious Code Protection) and ISO-27001-2022-A.8.7 (Protection against malware) are cited as insufficient on this entry.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The packet classifies this as a security feature bypass and names what fails: the OLE/mitigation prompts do not fire on the crafted document. The estate's evidence that its hardening works is evidence about settings, while the thing this CVE changes is whether the mechanism behind those settings still triggers — and nothing in a configuration report distinguishes the two. Bound to this entry the requirement is that the prompt-and-provenance class be re-exercised as a class after each patch deployment on this platform: the OLE/mitigation prompt path, the untrusted-origin mark, and whatever mail detonation and endpoint rules the estate relies on to catch a document that gets past them, driven with a document that takes the MSHTML platform down the path the packet describes — rather than tested once against this CVE and retired. The distinguishing test is a detonation result, not a policy export: a document exercising the mitigation-prompt path must be shown to be stopped on the build currently deployed; a report showing the prompt enabled is exactly the artifact that stayed green while this bypass was exploited in the wild, which is what makes the flaw-remediation and vulnerability-handling controls cited here insufficient — they record that an update was applied, not that the mechanism the update was supposed to restore now fires. Precondition: this is verification, not prevention. It tells the operator the mechanism has stopped working; it removes nothing, and the packet records the vendor update — which requires a reboot — as the remediation. A battery can also only cover primitives already known to it, so a bypass discovered after the battery was written passes it; its value is that it catches this class of mechanism failing without any setting changing or any signature firing, which is what the packet establishes happened here.",
+        "evidence": "Packet: the entry is a Windows MSHTML Platform Security Feature Bypass (CWE-20) in which the crafted document causes the MSHTML platform to bypass OLE/mitigation prompts and load malicious content. CISA KEV-listed 2024-05-14 with confirmed in-the-wild exploitation; CVSS 8.8, RWEP 57; poc_available false; patch_available true with live_patch_available false and the packet stating the vendor update requires a reboot and is the remediation. NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-handling are cited as insufficient on this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-30051": {
     "name": "Microsoft DWM Core Library Privilege Escalation Vulnerability",
@@ -46785,7 +48291,42 @@
         "adequate": false,
         "gap": "The compromised device IS the network boundary; boundary protection cannot compensate when the firewall's own preauth GlobalProtect endpoint yields root RCE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "PAN-OS running GlobalProtect is the perimeter-trust-boundary case this tier exists for, and the packet states why a generic patch SLA cannot govern it: an unauthenticated attacker sends GlobalProtect requests with a crafted SESSID cookie and ends with arbitrary code execution at root privilege on the firewall itself. The lesson's framework coverage puts it plainly — the compromised device IS the network boundary, so boundary protection cannot compensate when the firewall's pre-auth GlobalProtect endpoint yields root RCE. For this CVE the tier means the clock starts at the 2024-04-12 KEV listing, and the alternative to meeting it is taking the GlobalProtect portal and gateway interface out of service, not accepting a 14- or 30-day window. Scope the enumeration to what the packet names — PAN-OS in the affected versions with the GlobalProtect feature configured — and explicitly do not sweep Cloud NGFW, Panorama appliances or Prisma Access, which the vector states are not impacted; counting those produces emergency change work against products no evidence implicates. Precondition on the isolation half, which is where this control is most often over-claimed: the GlobalProtect portal and gateway exist to answer unauthenticated requests from the internet so remote users can connect, so isolating that interface means withdrawing remote access for the duration, and it is simply unavailable at a site where remote access is the business function. Where isolation is not available, the vendor fix on the accelerated clock is the only remaining lever. The packet records live_patch_available false and states the vendor update requires a reboot, so a firewall that has taken the fix but has not been rebooted is still running the vulnerable code and must be counted as exposed — on a device carrying production traffic that reboot is the step most likely to be deferred, because taking it interrupts the traffic the firewall is passing, and a deferral recorded as patched is the specific way this remediation goes wrong.",
+        "evidence": "Packet: CWE-20 / CWE-77 command injection arising from arbitrary file creation in the GlobalProtect feature of PAN-OS; the vector states it may enable an unauthenticated attacker to execute arbitrary code with root privileges on the firewall, for specific PAN-OS versions and distinct feature configurations, and that Cloud NGFW, Panorama appliances and Prisma Access are not impacted. cisa_kev true, kev_date 2024-04-12, active_exploitation confirmed, poc_available true, cvss 10, rwep_score 84. 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.' The lesson's framework_coverage for NIST-800-53-SC-7 records that the compromised device IS the network boundary and that boundary protection cannot compensate when the firewall's pre-auth GlobalProtect endpoint yields root RCE. AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, NIST-800-53-SC-7 and UK-CAF-B4 are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records what survives the fix here: observed chains deploy the UPSTYLE Python backdoor, which reads the device error log for further commands. That implant is a file and a running process on the firewall, placed by code that executed as root — the update closes the SESSID file-creation path but removes nothing already written through it, so a device exploited before remediation comes out of the update still implanted and still reachable by its operator. For a PAN-OS firewall the default response therefore has to be: capture the configuration and support data for analysis, rebuild the device from known-good firmware, and treat every secret the firewall held as exposed — GlobalProtect and management credentials, the directory or RADIUS service accounts it authenticated with, its certificates and private keys, and any pre-shared key on a tunnel it terminated — because the packet's stated outcome is root on the device that stored all of them. This is the state a flaw-remediation or technical-vulnerability-management attestation cannot express: both close when the fixed version is installed, and an implanted-then-patched firewall satisfies them exactly while remaining under attacker control. Distinguishing test: for any device that was internet-reachable and unpatched during the exposure window, require evidence that the rebuild-and-rotation path was taken rather than the version record — an estate that can produce a fixed version for every firewall but cannot say which of them were reachable before the fix landed has not answered the question. Precondition: a rebuild removes what is on the device, it does not reach what left it. Credentials read off the firewall before the rebuild stay valid until they are rotated, and sessions or tunnels established with them stay live — so the rotation is the part that must complete, not the reimage.",
+        "evidence": "Packet: the attack_vector states that an unauthenticated attacker sends GlobalProtect requests with a crafted SESSID cookie whose value is written to disk as an attacker-controlled filename, that a later process executes that content as an OS command with root privileges, and that observed chains deploy the UPSTYLE Python backdoor which reads the device error log for further commands. cisa_kev true, kev_date 2024-04-12, active_exploitation confirmed, poc_available true, cvss 10, rwep_score 84. 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.' The lesson's response guidance records assuming full device compromise, rotating all secrets and certificates on the firewall, and rebuilding from known-good firmware, on the basis that root RCE on the perimeter device means every credential and key it held must be considered exposed. NIS2-Art21-incident-handling (Incident handling), NIST-800-53-SI-2 (Flaw Remediation) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet makes the firewall's own log a component of the exploit rather than a record of it: the UPSTYLE backdoor reads the device error log for further commands, and the attacker holds root, so every log the device writes sits in the attacker's read-and-write path. Anything an investigator later asks that firewall about the incident is answered by a file the attacker could edit. For this deployment the control means the GlobalProtect authentication logs, the system and configuration logs and the traffic logs are streamed as they are written to a collector in a separate trust zone — different management plane, different credentials, different authentication path from the firewall's own — so a pre-tamper copy exists off the device. What the rules key on has to be what this chain actually emits: GlobalProtect requests carrying anomalous SESSID cookie values, files appearing under the GlobalProtect and device-telemetry temp paths that the request handling writes to, and — because the backdoor's command channel is the device's own error log rather than a network callback — outbound connections originating from the firewall's management plane to destinations it has no operational reason to reach. A rule written against appliance crashes or named exploit tooling would see none of this: the request is a well-formed GlobalProtect request, the write is performed by the device's own service, and the implant runs as a Python process on the appliance. Precondition, and it is the whole control: the off-device stream must already have been running before the compromise. A collector stood up during the investigation holds nothing from the exposure window, and root on the firewall can stop the forwarder or feed it falsified entries from that point on — so the separate-zone copy is authoritative for what it received before the attacker acted, and no further. Constrain the management plane's egress at the same time, or the same root access that reaches the log reaches the internet.",
+        "evidence": "Packet: the attack_vector states the crafted SESSID cookie value is written to disk as an attacker-controlled filename and later executed as an OS command with root privileges, and that observed chains deploy the UPSTYLE Python backdoor which reads the device error log for further commands. cisa_kev true, kev_date 2024-04-12, active_exploitation confirmed, poc_available true, cvss 10, rwep_score 84. The lesson's detection guidance records that the backdoor manipulates on-box logs, so external/network telemetry is more trustworthy than the appliance's own logs, and names anomalous files under GlobalProtect/device-telemetry temp paths, crafted SESSID cookie values, UPSTYLE artifacts and outbound connections from the management plane as the hunt indicators. NIS2-Art21-incident-handling (Incident handling) is recorded as a citing gap against this entry.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-3273": {
     "name": "D-Link Multiple NAS Devices Command Injection Vulnerability",
@@ -46822,7 +48363,31 @@
         "adequate": false,
         "gap": "No patch exists for these EoL NAS devices, so flaw remediation cannot apply; the only fix is retirement, which SI-2's patch framing does not compel."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet closes off every disposition except removal and states it in the entry's own words: the vulnerability only affects products no longer supported by the maintainer, the vendor was contacted early and confirmed immediately that the product is end-of-life, and it should be retired and replaced. patch_available is false and the live-patch note reads 'End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.' So for the DNS-320L, DNS-325, DNS-327L and DNS-340L there is no fixed build to reach at all — this is not a product where removal becomes the terminal state after an interim patch, it is one where removal is the only state, and any requirement phrased as 'every unit reports the fixed firmware' is unsatisfiable by construction. Requirement in operational terms: enumerate every unit of these four models in service, give each a dated removal or replacement schedule, and settle the migration target for the stored data first — a NAS pulled with nowhere for its contents to go is exactly how a removal date decays into an open-ended risk acceptance. Hold the scope to the four models the packet names; it ties the command-injection sink to /cgi-bin/nas_sharing.cgi on those devices and provides no mapping into other D-Link hardware, so treating the wider storage estate as an instance of this CVE manufactures replacement work against products no evidence implicates. Precondition, which is where this is routinely over-claimed on cheap appliances: because exploitation is confirmed, the exploit has been publicly disclosed, and the packet records botnets weaponizing it to drop Mirai, a unit reachable during the exposure window may already be running attacker code as root. Removing the hardware ends the exposure but does not undo it — the data the unit held and any credential stored on it are to be treated as exposed regardless of the decommission date, and a unit suspected of having been reached belongs on the incident path rather than only on the replacement schedule. Distinguishing test: for each unit, produce a removal date and the migration target for its data. A vulnerability-management record carrying these models as 'no patch available, risk accepted' with no removal date is the outcome this control exists to catch, and it is a record every patch-framed framework control on this entry will accept as complete.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes 'End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.' Vector: '** UNSUPPORTED WHEN ASSIGNED ** ... D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403. Affected is an unknown function of the file /cgi-bin/nas_sharing.cgi of the component HTTP GET Request Handler. The manipulation of the argument system leads to command injection ... The exploit has been disclosed to the public and may be used ... NOTE: This vulnerability only affects products that are no longer supported by the maintainer. NOTE: Vendor was contacted early and confirmed immediately that the product is end-of-life. It should be retired and replaced.' attack_vector: the base64-encoded command in the 'system' parameter 'is passed to a shell and executed as root, and botnets weaponized it to drop Mirai.' cisa_kev true, kev_date 2024-04-11, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 79, cwe_refs CWE-77. Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 Flaw Remediation and UK-CAF-B4 System security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "These are network-attached storage appliances whose purpose is holding the primary and backup copy of a household's, remote worker's or branch site's files, and the packet reaches root on them in a single unauthenticated HTTP GET: a base64-encoded command in the 'system' parameter of /cgi-bin/nas_sharing.cgi is passed to a shell and executed as root. Since the packet records no vendor fix and names isolation as one of only two available dispositions, reachability is the only lever the operator holds for as long as a unit remains in service. For the DNS-320L, DNS-325, DNS-327L and DNS-340L that means the device's HTTP interface answers only from an operator subnet or an authenticated VPN — not from the general user VLAN, and above all not from the internet through a router port-forward or a UPnP mapping, which is how NAS hardware at homes, remote-worker locations and small branch sites normally acquires its exposure. Constrain the outbound path too: the packet records botnets weaponizing this to drop Mirai, and a Mirai-class implant on a rooted NAS needs egress both to reach its controller and to ship what the device stores. Precondition, and it must never be recorded as closure: this bounds who can send the GET, it does not close the path. The request carries no credential the site issued, so every host inside the permitted segment already satisfies the attacker's only requirement, and the appliance exists to serve the client network it sits on — for a unit serving a general user VLAN there is no segment that removes the path, only isolation of that VLAN from anything that matters. It also does nothing for a unit already reached: root execution has already happened, no firmware update exists to displace what was left behind, and re-segmenting a compromised NAS leaves the implant resident and the stored data already exposed. Isolation here is a holding measure for the window before removal, not an alternative to it. Distinguishing test: from a general user VLAN and from an external address, request /cgi-bin/nas_sharing.cgi on the unit; anything that answers is within reach of the publicly disclosed exploit. 'The NAS is on the internal network' is a claim about topology, not a demonstration that the interface is unreachable from untrusted segments.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends a crafted HTTP GET to /cgi-bin/nas_sharing.cgi using the hardcoded messagebus backdoor account (CVE-2024-3272) with a base64-encoded command in the system parameter; the value is passed to a shell and executed as root, and botnets weaponized it to drop Mirai.' Vector names 'D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403', the '/cgi-bin/nas_sharing.cgi of the component HTTP GET Request Handler', and states 'It is possible to launch the attack remotely.' patch_available false, live_patch_available false, live_patch_notes 'End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.' poc_available true, active_exploitation 'confirmed', cisa_kev true, kev_date 2024-04-11, cvss 9.8. Citing gaps include NIST-800-53-SC-7 Boundary Protection and NIS2-Art21-network-security (Security of network and information systems).",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-3272": {
     "name": "D-Link Multiple NAS Devices Use of Hard-Coded Credentials Vulnerability",
@@ -47332,7 +48897,30 @@
         "adequate": false,
         "gap": "Essential-Eight OS-patching maturity is scoped to workstations/servers and does not compel the same-day mobile-device update discipline this actively-exploited iOS/iPadOS flaw requires."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The remediation this packet records is not one build but a set of per-train builds — iOS 16.7.6 and iPadOS 16.7.6, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.4, macOS Sonoma 14.4, macOS Ventura 13.6.5, tvOS 17.4, visionOS 1.1 and watchOS 10.4 — so for this CVE a single minimum-version rule is the wrong instrument and 'on the latest major release' is not the test. Each device must be at or above the fixed build for the train it is actually running: a Mac held on Monterey or Ventura for application-compatibility reasons has a fix available on that train and stays exposed until it takes it, and a policy expressed only as 'Sonoma 14.4 or later' either misses those devices or reports them non-compliant for the wrong reason. Make the per-train fixed build an access condition — mail, VPN and document access denied to a device below it — rather than a stale-build row on a patch-compliance dashboard. Enumerate every train the packet names, including tvOS, visionOS and watchOS, because those are the ones that sit outside most managed-device inventories, so their exposure never reaches the report the estate reads. Precondition: the packet records no vendor live-patch mechanism and states that remediation requires applying the fixed release and rebooting, so a device that has installed the update but not restarted still runs the vulnerable kernel and must be counted as exposed, not compliant. And the access condition bounds what the estate exposes to a device below the fixed build; it does nothing for a device already compromised — this bug is reached by an attacker who already holds arbitrary kernel read and write, so a device plausibly inside the targeted chain the packet describes belongs on the incident path rather than the update path. Distinguishing test: enrol a device pinned below its own train's fixed build and confirm the policy denies it protected-resource access — an estate that surfaces the stale build on a report while the device keeps its mail and VPN access has recorded the exposure rather than removed it.",
+        "evidence": "Packet vector: 'A memory corruption issue was addressed with improved validation. This issue is fixed in iOS 16.7.6 and iPadOS 16.7.6, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.4, macOS Sonoma 14.4, macOS Ventura 13.6.5, tvOS 17.4, visionOS 1.1, watchOS 10.4. An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.' attack_vector: 'As a late stage of a targeted exploit chain, an attacker who already holds arbitrary kernel read/write uses this memory-corruption flaw to defeat kernel memory protections and gain durable kernel control.' cwe_refs CWE-787; cisa_kev true with kev_date 2024-03-06; active_exploitation confirmed; cvss 7.8; rwep_score 61; poc_available false; patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this entry the enforcement mechanism is the load-bearing part, because the packet's remediation is a reboot-gated OS update and nothing else: no live-patch mechanism is registered, and applying the fixed release and rebooting is the whole of it. On an Apple estate that update is normally offered to the user, and the restart is the step users postpone — so an estate that 'deployed' the update but permits deferral has recorded a deployment that has not happened, on a defect KEV-listed 2024-03-06 with confirmed exploitation and Apple's own note that it may have been exploited. Drive it instead through managed device configuration with a hard deadline and an enforced restart, on a KEV-tied clock rather than the estate's routine monthly ring, and measure completion by devices restarted onto the fixed build for their train rather than by updates approved, downloaded or 'available'. Precondition: this reaches only devices actually enrolled in management. Personally-owned devices carrying organizational data, and the tvOS, visionOS and watchOS units the packet names — which are frequently enrolled in nothing — are outside the enforcement path entirely, and for those the remaining lever is withholding organizational access from a device below the fixed build, not a push the estate cannot make. Enforcement also cannot help a device that is already in an attacker's hands: this bug is used by an attacker who already holds arbitrary kernel read and write, so the enforced update closes the exposure going forward and says nothing about a device that was already carried through the chain.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-03-06; active_exploitation confirmed; vector states 'Apple is aware of a report that this issue may have been exploited' and names the fixed builds across iOS/iPadOS, macOS Monterey/Sonoma/Ventura, tvOS, visionOS and watchOS; patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'; cvss 7.8; rwep_score 61; poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-23296": {
     "name": "Apple Multiple Products Memory Corruption Vulnerability",
@@ -47389,7 +48977,39 @@
         "adequate": false,
         "gap": "Essential-Eight patch maturity is workstation/server-scoped and does not compel same-day mobile OS updates for an active mobile zero-day."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet names the fixed releases across the iOS, iPadOS, macOS, tvOS, visionOS and watchOS families — iOS 16.7.8 and iPadOS 16.7.8, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.6, macOS Sonoma 14.4, macOS Ventura 13.6.7, tvOS 17.4, visionOS 1.1, watchOS 10.4 — and that list is this control's scope statement: an estate that drives the KEV clock opened 2024-03-06 across managed iPhones and Macs alone still leaves the tvOS, visionOS and watchOS builds the packet names running the vulnerable code, and those device classes typically sit outside the management channel that enforces the phone and Mac deadline. For this CVE the control means the update is pushed on that clock with user deferral disallowed, and completion is measured per device against the specific build the packet names for that device's OS family and track — not against an 'available' or 'downloaded' state in the management console. The packet records no live-patch mechanism and states that remediation requires applying the fixed release and rebooting, so a device that has staged the update but not restarted is still running the vulnerable code and must be counted as exposed; on a phone or a watch the restart is precisely the step a user defers, which is how this remediation gets recorded as complete while the exposure stands. Distinguishing test: enumerate the estate's Apple devices by OS family and installed build and confirm each is at or above the build the packet names for it, including the device classes the standard patch report does not cover. Precondition: this reaches only devices the management channel can see and compel — a personally owned or unenrolled device carrying organizational data is remediated by removing that access or that data, not by a deadline it never receives.",
+        "evidence": "Packet vector: 'A memory corruption issue was addressed with improved validation. This issue is fixed in iOS 16.7.8 and iPadOS 16.7.8, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.6, macOS Sonoma 14.4, macOS Ventura 13.6.7, tvOS 17.4, visionOS 1.1, watchOS 10.4. An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.' CWE-787, CISA KEV-listed 2024-03-06, active_exploitation confirmed, poc_available false, CVSS 7.8, RWEP 60. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet fixes this on two parallel iOS/iPadOS tracks — 16.7.8 and 17.4 — and on three separate macOS releases, Monterey 12.7.6, Sonoma 14.4 and Ventura 13.6.7. That is the condition a single minimum-version threshold cannot express, and it fails in the dangerous direction: a policy admitting anything at or above 16.7.8 admits a device running 17.0, which is numerically higher and still carries the flaw, while a policy pinned at 17.4 marks every device that correctly took 16.7.8 as non-compliant. For this CVE the control therefore means the minimum build is stated per OS family and per track, and enforced as an access condition — mail, VPN and document access withheld from a device below the build named for its own track — rather than surfaced as a row on a patch-compliance report. The distinguishing test is to enrol a device sitting above one track's fix but below its own, a 17.x device on a build under 17.4, and confirm the policy denies it access to protected resources; an estate whose compliance rule is a single version comparison passes that device while it stays exposed. Precondition: withholding access bounds what the device can reach while it is exposed, it does not remediate the device, and the packet's attack description is of a device whose attacker already holds arbitrary kernel read and write — so a device suspected of having been in that state belongs on the incident path and is not returned to service by clearing a build check. This is a holding measure for the window before the fixed release and its required reboot land, not a substitute for them.",
+        "evidence": "Packet vector names the fixed builds on parallel tracks: 'iOS 16.7.8 and iPadOS 16.7.8, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.6, macOS Sonoma 14.4, macOS Ventura 13.6.7, tvOS 17.4, visionOS 1.1, watchOS 10.4', and states 'An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections.' attack_vector: the attacker already holds arbitrary kernel read/write and uses this RTKit memory-corruption flaw to bypass kernel memory protections, a late stage of a targeted exploit chain. CWE-787, KEV 2024-03-06, active_exploitation confirmed. patch_available true with live_patch_available false; remediation requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this flaw at a late stage of a targeted exploit chain: the attacker already holds arbitrary kernel read and write, and uses this RTKit memory-corruption bug to bypass kernel memory protections. Nothing an operator configures reduces that primitive once the chain has reached this point, and the control must not be recorded as if it did. What it means for this CVE is the earlier stage — for the cohort plausibly inside the targeting set chains of this class serve, place the device in a reduced-attack-surface posture so untrusted web content, message attachments, fonts and link previews are not processed automatically, narrowing the delivery of the stages that produce the kernel read/write this bug consumes. Two conditions have to be stated or this becomes a mitigation on paper only. First, the posture has to already be in force: assigned in response to a disclosure it gives nothing for the window that mattered, and the packet's own record is Apple aware of a report that the issue may have been exploited — that is after the fact by construction. Second, it does not evict an attacker already resident; a device believed to have carried the chain goes to the incident path rather than into a hardening rollout, and the packet's description of an attacker with arbitrary kernel read and write is the state in which no device-side setting is trustworthy. Distinguishing test: name the high-risk cohort and show the reduced-attack-surface posture was applied to each of those devices before the disclosure date, not after — a policy that exists but was assigned reactively passes an attestation while providing nothing during the exposure.",
+        "evidence": "Packet attack_vector: 'An attacker already holding arbitrary kernel read/write uses this RTKit memory-corruption flaw to bypass kernel memory protections, a late stage of a targeted exploit chain.' Packet vector: 'An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.' CWE-787, CISA KEV-listed 2024-03-06, active_exploitation confirmed, poc_available false, CVSS 7.8, RWEP 60. patch_available true, live_patch_available false — remediation requires applying the fixed release and rebooting. The entry cites NIST SP 800-53 Rev 5 CM-7 (Least Functionality) among its insufficient framework controls.",
+        "gap_closes": [
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2023-21237": {
     "name": "Android Pixel Information Disclosure Vulnerability",
@@ -48479,7 +50099,39 @@
         "adequate": false,
         "gap": "Security-monitoring expectations rarely include vmdird crash telemetry, so the earliest reliable signal of this exploit went uncollected."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The vulnerable code on this entry is vCenter Server's DCERPC implementation: the packet places the out-of-bounds write in the vmdird service's handling of crafted DCERPC packets, a binary listener that answers a network peer before any authentication, so the vCenter role-and-permission review and web-tier hardening most deployments are audited against never touch this path. Bound to this deployment, the control means the DCERPC listener on every vCenter Server accepts connections only from the management and jump networks and the hosts vCenter administers, enforced by network ACL or host firewall rather than inferred from 'vCenter is internal'. Scope that enforcement to everything the packet's affected_versions names - vCenter Server 8.0 and 7.0 appliances and the vCenter component inside VMware Cloud Foundation 5.x and 4.x - because an inventory built only from standalone vCenter appliances reports clean across a Cloud Foundation estate that carries the same listener. Distinguishing test: from a general user or workstation VLAN on a staging deployment, send DCERPC traffic at vCenter and confirm it is dropped before the listener processes it. Precondition, and this is where the control gets over-claimed: an ACL bounds who can send the packet, it does not repair the parser - any host inside the permitted segment still reaches the same out-of-bounds write, and the packet records the defect as network-facing, unauthenticated and RCE-class. Repair is the fixed release (vCenter Server 8.0 U1d/U2, 7.0 U3o, or the corresponding Cloud Foundation update); live_patch_available is false and the entry states remediation requires applying the fixed release and rebooting, so an appliance carrying the fixed release that has not rebooted is still executing the vulnerable vmdird and completion is measured on the version the running appliance reports.",
+        "evidence": "The packet's vector states vCenter Server contains an out-of-bounds write vulnerability in the implementation of the DCERPC protocol, and that a malicious actor with network access to vCenter Server may trigger it, potentially leading to remote code execution; the attack_vector record places the write in the vmdird service, triggered by crafted DCERPC packets, with code execution reached through control of the byte-swapped base address. CWE-787. affected lists VMware vCenter Server and vCenter within Cloud Foundation; affected_versions lists vCenter Server 8.0 before 8.0 U1d / U2, vCenter Server 7.0 before 7.0 U3o, and VMware Cloud Foundation 5.x / 4.x (vCenter component). CISA KEV-listed 2024-01-22 with active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 80; EPSS approximately 0.99. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes stating there is no vendor live-patch mechanism and that remediation requires applying the fixed release and rebooting. NIST SP 800-53 SC-7 (Boundary Protection) and EU NIS2 Article 21 network security are recorded among the framework controls insufficient for this entry, the first because vCenter is an internal management plane many networks leave broadly reachable so the DCERPC surface is exposed to any host that can reach the appliance, the second because network-security controls that assume the virtualization management plane is trusted neither segment nor monitor DCERPC to vCenter.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "On this entry the fixed build is not the remediation verdict, and the packet says why: the flaw was exploited as a zero-day by the China-nexus espionage group UNC3886 from approximately 2021, years before the October 2023 disclosure, and the vCenter foothold was used to reach ESXi hosts and deploy VIRTUALPITA and VIRTUALPIE implants. Those implants sit on the managed hosts, entirely outside anything a vCenter update rewrites, so an appliance moved to 8.0 U1d/U2 or 7.0 U3o can be fully patched and still sit in a live intrusion. For any vCenter Server - or Cloud Foundation vCenter component - that was network-reachable on a pre-fix build during that window, the default response is compromise assessment rather than patch-and-close: capture the appliance configuration and logs before touching it, rebuild the appliance from known-good media at the fixed release, extend the assessment to the ESXi hosts that appliance administers rather than stopping at the appliance boundary, and rotate the administrative credentials used for vCenter and for those hosts. Detection keys on what the packet documents rather than on a generic exploit signature: the same out-of-bounds write that can execute code can also crash the service, so vmdird crash and restart events on vCenter are the recorded observable, together with DCERPC connections to the appliance from segments that have no administrative relationship with it. Deleting a single located implant and then patching is not equivalent - dwell measured in years is long enough for access paths that no longer depend on the DCERPC defect.",
+        "evidence": "active_exploitation is confirmed and active_exploitation_notes state the flaw was exploited as a zero-day by the China-nexus espionage group UNC3886 since approximately 2021, years before the October 2023 disclosure, to reach ESXi hosts and deploy VIRTUALPITA/VIRTUALPIE implants, and that KEV ransomware use is unconfirmed. The attack_vector record states the crafted DCERPC packets corrupt memory to crash the vmdird service or, with control of the byte-swapped base address, execute code - a foothold UNC3886 used to reach ESXi hosts. patch_available true with fixed builds listed in affected_versions as vCenter Server 8.0 U1d / U2 and 7.0 U3o; patch_required_reboot true; live_patch_available false, live_patch_notes stating remediation requires applying the fixed release and rebooting. CISA KEV-listed 2024-01-22; CVSS 9.8, RWEP 80; poc_available true. The framework record states that NIST SP 800-53 SI-2 addresses known flaws and not a silent nation-state zero-day exploited for roughly two years before disclosure, and that ISO/IEC 27001:2022 A.8.8 technical-vulnerability management is disclosure-driven so its coverage begins only at VMware's advisory, not during the exploited window - which is precisely why the completion criterion on an exposed appliance has to be an assessment outcome rather than a build number.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "This entry carries named attribution, and a commodity-incident path under-escalates it. The packet attributes exploitation to UNC3886, a China-nexus espionage group, operating from approximately 2021 with implants named VIRTUALPITA and VIRTUALPIE on the ESXi hosts reached through vCenter. The finding an operator is holding is therefore not 'an appliance had a CVE' but a long-dwell espionage intrusion in the virtualization management plane, and the runbook needs an explicit trigger that routes it there: attribution or implant indicators of this class on a vCenter or ESXi finding escalate to the nation-state path, which sets the assessment scope to the managed virtualization estate rather than the appliance, extends telemetry retention past the normal window because the exposure predates the advisory by roughly two years, and treats regulatory notification and threat-intelligence reporting as part of closure rather than closing on a patch ticket. The trigger also has to be fed, which is the monitoring half: vmdird crash and restart events and DCERPC connection records from vCenter have to be collected into the SIEM, because the packet's own attack-vector description makes a crashing vmdird the observable byproduct of the same write that executes code. An estate that ingests vCenter administrative audit logs alone has no signal at all for a pre-authentication parser defect, which is exactly how the earliest reliable indicator of this exploit went uncollected. Precondition: this is detection and response scope, not prevention - it shortens dwell and sizes the investigation, and only the fixed release plus the reboot the packet requires removes the defect.",
+        "evidence": "active_exploitation_notes name the actor and the implants: exploited as a zero-day by the China-nexus espionage group UNC3886 since approximately 2021, years before the October 2023 disclosure, to reach ESXi hosts and deploy VIRTUALPITA/VIRTUALPIE implants; network-facing, unauthenticated, RCE-class. The attack_vector record states the out-of-bounds write in vmdird can crash the service or execute code, and that the foothold was used to reach ESXi hosts. CISA KEV-listed 2024-01-22, active_exploitation confirmed, CVSS 9.8, RWEP 80, EPSS approximately 0.99. The framework record states that EU DORA Article 9 ICT protection requirements do not mandate the compromise assessment of the hypervisor management layer needed after a stealthy, long-dwell vCenter intrusion, and that UK CAF C1 security-monitoring expectations rarely include vmdird crash telemetry, so the earliest reliable signal of this exploit went uncollected - the two gaps this control is attached to.",
+        "gap_closes": [
+          "DORA-Art-9",
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2023-35082": {
     "name": "Ivanti Endpoint Manager Mobile (EPMM) and MobileIron Core Authentication Bypass Vulnerability",
@@ -48593,7 +50245,30 @@
         "adequate": false,
         "gap": "System-security assurance assumes the renderer sandbox holds; a V8 out-of-bounds primitive undermines that assumption without additional exploit-mitigation controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The exploited surface is the browser on ordinary user endpoints — a victim visits an attacker-controlled page and JavaScript drives an out-of-bounds memory access in V8, corrupting the heap for code execution in the renderer — so for this CVE the control means the browser security channel is not held in any deferral ring on a managed fleet. The target build is per product, not per vendor: Chrome at 120.0.6099.224 or later, and the Edge, Opera and Brave builds that carry the fixed V8, because the packet places all of them in the affected set. An estate standardised on Edge that measures only its Chrome population reports full coverage while every endpoint keeps executing the vulnerable engine — the defect is in V8, and the vector's headline product is not the scope. Completion is measured on the version the running browser process reports, not the version installed: patch_required_reboot is false, which means no machine reboot, not that the fix is live — a Chromium browser that has downloaded the update keeps running the old V8 in its existing processes until the browser is relaunched, and the packet records that force-relaunch is often not enforced, which is precisely how a fleet reaches full installed coverage while a large share of it stays exploitable. Enforce the relaunch through policy with a bounded deadline rather than leaving it to the user closing their tabs. Precondition: there is no live-patch path here — the packet states remediation requires applying the vendor fixed release, so a deferral ring left in place has no compensating control behind it, only exposure to routine browsing.",
+        "evidence": "Packet: KEV-listed 2024-01-17; active_exploitation confirmed and exploited in the wild as a zero-day in January 2024; poc_available false; RWEP 55; CVSS 8.8; 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.' affected_versions: Google Chrome before 120.0.6099.224; Chromium-based browsers (Edge, Opera, Brave) shipping V8 before the 120.0.6099.224 fix. AU-Essential-8-Patch gap as recorded: Essential-8 patch timelines can trail a browser zero-day already exploited before the CVE is public, and force-relaunch is often not enforced. NIS2-Art21-patch-management gap as recorded: endpoint-browser patch management is rarely enforced as tightly as server patching, yet browsing is the exact exploited vector. attack_vector: a victim visits an attacker-controlled page; JavaScript drives an out-of-bounds memory access in V8, corrupting the heap to gain code execution in the renderer.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "An installed-version verdict is paper compliance for this CVE for two specific reasons, both of which the packet supplies. First, the installed build and the executing build diverge: patch_required_reboot is false, so nothing forces a machine restart, and a Chromium browser continues running the pre-fix V8 in its existing processes until it is relaunched — the packet notes force-relaunch is often not enforced, so an inventory that reads the on-disk version marks an endpoint remediated while its open browser is still exploitable by the crafted page. Second, the scope is keyed to the wrong product: Edge, Opera and Brave are inventoried under their own names and their own version numbers, so a rule written as 'Chrome at or above 120.0.6099.224' silently returns nothing for them and an estate standardised on one of those reports clean. The operational test is therefore per endpoint and per browser: collect the version the running browser process reports for every Chromium-based browser installed, and check each against its own product's build that carries the fixed V8 rather than against Chrome's number. Precondition: this is verification only — it identifies which endpoints are still executing the vulnerable engine, and the remediation remains the vendor fixed release plus the relaunch, since the packet records no live-patch mechanism.",
+        "evidence": "Packet affected_versions: Google Chrome before 120.0.6099.224; Chromium-based browsers (Edge, Opera, Brave) shipping V8 before the 120.0.6099.224 fix. patch_required_reboot false; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' AU-Essential-8-Patch gap as recorded: force-relaunch is often not enforced. ISO-27001-2022-A.8.8 gap as recorded: technical-vulnerability management under-prioritizes client browsers, leaving the actual exploited surface under-governed. Vector: out of bounds memory access in V8 in Google Chrome prior to 120.0.6099.224 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page; poc_available false; active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-6549": {
     "name": "Citrix NetScaler ADC and NetScaler Gateway Buffer Overflow Vulnerability",
@@ -49002,7 +50677,38 @@
         "adequate": false,
         "gap": "Technical-vulnerability management offers no route for a KEV appliance command-injection zero-day where only a temporary mitigation existed before a patch."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For Ivanti Connect Secure 9.x/22.x and Policy Secure 9.x/22.x, the packet records the outcome of exploitation and not only the flaw: crafted requests to the ICS/IPS web components executed arbitrary OS commands, and webshells (GIFTEDVISITOR, WIREFIRE) were dropped across the fleet while this was still a zero-day. Applying the fixed release and rebooting — which the packet records as the only remediation path, with no vendor live-patch mechanism — restores the code but removes nothing an attacker wrote to the appliance during the exposure window. So for any ICS/IPS unit that was reachable between the 2024-01-10 KEV listing and the fixed release, the default runbook must be: export the configuration for review, rebuild the appliance from the vendor image onto the fixed release, and rotate every credential and certificate the appliance held or brokered — VPN user credentials, appliance administrator credentials, and any service account reachable through it — rather than patching in place and closing the item. The packet also removes the usual reassurance that would otherwise justify patch-in-place: the appliance's own Integrity Checker Tool was subverted by the attackers, so a clean on-box integrity result is not evidence the unit is clean, and 'ICT reports no changes' cannot be the basis for skipping the rebuild. Preconditions: the rebuild holds only if the unit returns on the fixed release — a rebuilt appliance restored to a pre-fix build is immediately re-exploitable through the same web-component path — and rebuilding does not retract credential material already exfiltrated, which is why rotation runs as part of the same action rather than as a later phase.",
+        "evidence": "Packet records a mass-exploited zero-day, CISA-flagged ransomware-associated, KEV-listed 2024-01-10 with active_exploitation 'confirmed' and poc_available true; webshells named as GIFTEDVISITOR and WIREFIRE dropped 'across the fleet', and the path becomes fully unauthenticated RCE when chained with the CVE-2023-46805 auth bypass. patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting'. The AU-Essential-8-Patch gap states 'interim mitigation plus factory reset were required beyond the normal patch SLA', and the NIST-800-53-SI-4 gap states the appliance's 'own Integrity Checker Tool was subverted by attackers'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "Both monitoring gaps recorded on this entry are on-box-trust failures: the packet states operators lacked telemetry from the Ivanti appliance and that its built-in integrity check was tampered with, so the two records an operator would consult after the fact were under the control of an attacker who held command execution on the box. For ICS/IPS the requirement is that the appliance continuously forward web-component request logs, administrative-action logs and authentication logs to a collector in a separate trust zone — different management plane, different credentials, different authentication path — so the record of exploitation survives the appliance that was exploited. The detection built on that feed has to key on what the packet describes this exploit doing: crafted requests to ICS/IPS web-component endpoints that result in OS command execution; an administrator-context request against those endpoints with no corresponding successful administrator authentication, which is the shape the packet records when the flaw is chained with CVE-2023-46805 and becomes unauthenticated; and subsequent requests to web-accessible paths that are not part of the vendor image, which is how a planted webshell is reached. Rules written around appliance crashes, malware signatures, or named exploit tooling would miss every stage of that — the packet describes well-formed requests to legitimate endpoints and a webshell as the artifact, not a crash. Precondition: this only produces evidence if the off-box collection was already running before the intrusion, which for a closed appliance is exactly where it is least often configured; and once a unit is compromised its own on-box logs cannot be used to fill the gap retrospectively, because the attacker had command execution on the system that wrote them.",
+        "evidence": "NIST-800-53-SI-4 gap: 'System monitoring does not natively cover a closed appliance whose own Integrity Checker Tool was subverted by attackers, so command-injection and webshell activity evaded the expected detection surface.' UK-CAF-C1 gap: 'Security-monitoring expectations were defeated because operators lacked telemetry from the appliance and the built-in integrity check was tampered with, hiding the command-execution stage.' Vector: a command injection in web components of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) where an authenticated administrator sends specially crafted requests to execute arbitrary commands; the packet records the same path as unauthenticated when chained with CVE-2023-46805, used to drop webshells. active_exploitation 'confirmed'.",
+        "gap_closes": [
+          "NIST-800-53-SI-4",
+          "UK-CAF-C1"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet records this as exploited before any fix existed, with only a temporary mitigation available in the interim — the state that compliance reporting on ICS/IPS could not express, because it has no verdict between 'vulnerable' and 'patched per SLA'. For this CVE the requirement is that an Ivanti Connect Secure or Policy Secure appliance carrying the interim mitigation with no fixed release installed be recorded as its own state — mitigation active, no fixed build — with a dated action item attached, and that the state age against the 2024-01-10 KEV listing rather than resetting the clock on the day the mitigation was applied. Two consequences are specific to this entry. Any defect in the interim mitigation reopens a command-injection path that the packet already shows was being exploited at scale across the fleet, so the residual risk in state (b) here is not theoretical. And the mitigation says nothing about units already compromised: the packet records that a factory reset was required alongside it, so an appliance in this state that was reachable during the exposure window sits on the rebuild path at the same time and must not be closed on the mitigation record. This control is a reporting requirement, not a defence — it makes the residual exposure countable; what removes it is the fixed release and the reboot the packet records as required, with no live-patch alternative.",
+        "evidence": "ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management offers no route for a KEV appliance command-injection zero-day where only a temporary mitigation existed before a patch.' AU-Essential-8-Patch gap: 'The patch objective could not apply during a zero-day with no fix; interim mitigation plus factory reset were required beyond the normal patch SLA.' Packet fields: cisa_kev true with kev_date 2024-01-10, active_exploitation 'confirmed', patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-23752": {
     "name": "Joomla! Improper Access Control Vulnerability",
@@ -49059,7 +50765,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management does not chain to secrets rotation, leaving leaked DB credentials valid after the Joomla update."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet establishes the fact this control exists for: the unauthenticated request returns the application configuration including the MySQL username, password and host, and those credentials are reused for deeper access. The vendor fixed release stops the endpoint from serving that configuration; it does not invalidate a credential that has already been served. With a public PoC and confirmed in-the-wild exploitation against a version range as wide as 4.0.0 through 4.2.7, any site that was reachable before it was upgraded has to be treated as having disclosed those secrets. Bound to this entry the requirement is that the response for an exposed site is upgrade plus rotation, in that order and both recorded: rotate the database credential and every other secret carried in the site configuration, then review what that database account could reach and what was done with it across the exposure window, scoping the review from the site's own request logs rather than from whether anything looks wrong in the CMS — nothing needs to look wrong, because the exploit is a well-formed GET that returns 200. Note which half of this control the packet supports: it establishes configuration disclosure and credential reuse, not code execution on the web server, so the rebuild default the control specifies for a pre-auth RCE is not what this entry calls for; the config-exfiltration and credential-rotation half is, and it is the half the cited patching and vulnerability-management controls miss entirely, because their completion criterion is the installed version. Precondition: rotation closes the disclosed credential and nothing else. If the deeper access the packet describes was already used to establish something durable — an application account, or a change to stored content — rotating the database password does not remove it, and a site that cannot account for its exposure window needs its administrative accounts and content compared against a known-good state rather than being closed on the upgrade record.",
+        "evidence": "Packet: Joomla! 4.0.0 through 4.2.7; \"An improper access check allows unauthorized access to webservice endpoints\" (CWE-284). Attack path per the packet: \"An unauthenticated attacker appends ?public=true to Joomla 4.x REST config/user endpoints; the improper access check returns the application configuration, including MySQL username, password, and host, which is reused for deeper access.\" CISA KEV-listed 2024-01-08 with confirmed in-the-wild exploitation; poc_available true; CVSS 5.3 against RWEP 68; patch_available true, live_patch_available false, live_patch_notes: \"No vendor live-patch mechanism; remediation requires applying the vendor fixed release.\"",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Read past the product class in this control's name to what it requires — a management function that authorizes its own caller instead of inheriting a verdict — because the Joomla webservice layer is where this product takes its access decision and this CVE is that decision being made from the request. The packet has an unauthenticated caller appending ?public=true to the 4.x REST config and user endpoints, and the improper access check handing back the application configuration. Bound to this product, the control means each webservice endpoint authorizes its caller itself before the handler runs and before any configuration value is serialized into a response, rather than honouring a flag the caller supplies; and the REST API surface answers only from networks with an operational need for it, so an arbitrary internet client cannot present the request at all. The access-enforcement and identity-and-access controls cited on this entry are cited precisely because they do not reach this path: the attacker never holds a Joomla account, so per-account privilege scoping is never consulted, and an attestation showing every administrator authenticates with correctly scoped roles passes cleanly while an unauthenticated GET returns the database password. Distinguishing test: from a network with no operational need for the API, issue unauthenticated requests to the config and user webservice endpoints on a staging site with the caller-supplied public flag set, and confirm each is refused before the handler runs and before anything is emitted — testing that the administrator login requires authentication demonstrates nothing about this path. Precondition: the endpoint-side check is a property the vendor fixed release establishes; this control states what to verify, it does not implement it. On a site still in the 4.0.0-4.2.7 range, restricting reachability bounds who can send the request but closes nothing — anything inside the permitted set still receives the configuration — and that restriction is unavailable where the site's own integrations consume those endpoints from outside a trusted segment.",
+        "evidence": "Packet: Joomla! 4.0.0 through 4.2.7, improper access check allowing unauthorized access to webservice endpoints (CWE-284); the unauthenticated request path is ?public=true against the Joomla 4.x REST config/user endpoints, returning the application configuration. CISA KEV-listed 2024-01-08 with confirmed in-the-wild exploitation; poc_available true; CVSS 5.3, RWEP 68; patch_available true with live_patch_available false and remediation stated as applying the vendor fixed release. NIST-800-53-AC-3 (Access Enforcement) and UK-CAF-B2 (Identity and access control) are cited as insufficient on this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2016-20017": {
     "name": "D-Link DSL-2750B Devices Command Injection Vulnerability",
@@ -49518,7 +51247,29 @@
         "adequate": false,
         "gap": "The application-patch target for browsers is frequently unmet on managed fleets, and 'patched' Chrome is not protected until every process is restarted."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "This is a heap buffer overflow in the WebRTC component of Chrome/Chromium reachable from a crafted HTML page, so the delivery path is ordinary browsing and every endpoint that renders web content is in the exploit population — the update ring is the whole of the remediation, and any ring that stages security-channel browser updates behind a validation window is holding a fleet on exploitable code while the pages that exploit it are already being served. Scope the ring from the packet's affected field rather than from the vector's headline product: it records Google Chrome / Chromium and downstream Chromium browsers, and the exploitation notes state the flaw affects the broad Chromium browser base, so every Chromium-based browser deployed in the estate has to be covered at that product's own fixed build. An estate standardised on a downstream Chromium browser will report clean if the check keys only on Chrome reaching 120.0.6099.129. Measure completion on the build the running browser process is executing, not on the installed package: patch_required_reboot is false, which means no machine reboot is required, not that the fix is live on deployment — a browser process that has been running since before the update keeps executing the pre-fix WebRTC code until it is relaunched, which is what the packet's own gap statements mean by needing a fleet-wide forced restart. Precondition: the ring reaches only browsers under management policy. A per-user or otherwise unmanaged Chromium install on a managed host is outside the ring, and the ring's compliance percentage will not show it; that copy is remediated by bringing it under management or removing it, not by the ring.",
+        "evidence": "Packet vector: 'Heap buffer overflow in WebRTC in Google Chrome prior to 120.0.6099.129 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.' affected: 'Google Chrome / Chromium (and downstream Chromium browsers) — heap buffer overflow in the WebRTC component reachable from a crafted HTML page'; affected_versions: 'Google Chrome prior to 120.0.6099.129'. active_exploitation_notes: exploited in the wild as a Chrome zero-day found by Google's Threat Analysis Group, 'fixed in Chrome 120.0.6099.129/130; affects the broad Chromium browser base'. cisa_kev true, kev_date 2024-01-02, active_exploitation 'confirmed', patch_available true, patch_required_reboot false, live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' Cited gaps: NIST-800-53-SI-2 'auto-update must be enforced, which flaw-remediation policy often does not treat as urgent for endpoints'; ISO-27001-2022-A.8.8 'a browser heap-overflow zero-day needs endpoint-fleet-wide forced restart to take effect'; NIS2-Art21-patch-management 'Baseline patch cadence does not force the near-immediate browser relaunch across a fleet that a drive-by client zero-day requires.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE the paper-compliance trap is specific and the packet states it outright: a scan that reads the installed Chrome/Chromium version off disk and reports the endpoint patched at 120.0.6099.129 is measuring the wrong thing, because the browser process that has been running since before the update is still executing the vulnerable WebRTC code. The operational test that distinguishes real remediation: on a sample of endpoints, compare the build the running browser process itself reports against the fixed build, and treat any host whose on-disk build is at or above the fix while the running process reports lower as exposed rather than remediated. Run the same comparison for every Chromium-based browser the estate deploys, since the packet places the defect in Chromium's WebRTC component and not solely in Chrome. This matters more here than for a server patch because of how endpoints are used — a laptop that is suspended and resumed for weeks without the browser ever being closed is the normal case, not the exception, so the population of 'installed but not yet running the fix' endpoints does not drain on its own. Precondition: this test measures state, it does not change it. It tells the operator which endpoints still owe a browser relaunch and gives nothing on a host where the relaunch is never forced; enforcing the relaunch is the update-ring control's job, not this one. It is also not an exploitation check — the packet's system-security gap notes the attack arrives as ordinary web content to a legitimately running browser, so a clean version comparison says nothing about whether a page already exploited the endpoint during the exposure window.",
+        "evidence": "Packet gap AU-Essential-8-Patch: 'The application-patch target for browsers is frequently unmet on managed fleets, and \"patched\" Chrome is not protected until every process is restarted.' Corroborating packet fields: patch_required_reboot false; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release'; affected 'Google Chrome / Chromium (and downstream Chromium browsers)'; fixed build per vector 'prior to 120.0.6099.129'. Gap UK-CAF-B4: 'Endpoint/patch controls do not detect exploitation delivered as ordinary web content to a legitimately running browser.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-49897": {
     "name": "FXC AE1021, AE1021PE OS Command Injection Vulnerability",
@@ -50671,7 +52422,39 @@
         "adequate": false,
         "gap": "Secure-maintenance objectives assume a maintainable product; an unsupported internet-facing appliance with a pre-auth RCE cannot be brought into compliance by patching."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet carries both halves this control exists to separate, and states them explicitly. A fix exists — the appliance update to 4.3.10.4 or later, auto-applied to supported devices — and the product is end-of-life, so the packet records migration off Sophos Web Appliance as the durable remediation. That defines the requirement: reaching 4.3.10.4+ is an interim state, and the terminal state is removal and replacement of the appliance, because a unit kept in service past end-of-life is exposed not only to this pre-authentication command injection but to everything found in the product since that build, with no update path left to take it anywhere. Operationally: inventory every Sophos Web Appliance in service with the version it currently runs; confirm each has actually reached 4.3.10.4 or later rather than assuming the automatic update applied, since the packet ties auto-application to supported devices while the exposed population at issue is precisely the instances not receiving it; and put every unit on a dated replacement schedule with a named successor web gateway. A remediation record that ends at 'every appliance reports 4.3.10.4' marks an end-of-life, internet-facing appliance compliant while it stays exposed, and a risk acceptance carrying no removal date does the same thing more slowly — which is why the vulnerability-management and system-security gaps on this entry cannot be closed by any patch SLA. Scope to what the packet names: Sophos Web Appliance below 4.3.10.4. It gives no mapping of this warn-proceed handler into other Sophos products, so widening the retirement programme to the vendor's other appliances manufactures replacement work against software no evidence implicates. Precondition on the interim half: patch_required_reboot is true and no live patch exists, so an appliance that has taken the update but has not come back up on 4.3.10.4 is still running the vulnerable code and is not remediated.",
+        "evidence": "live_patch_notes: 'No live patch; requires the appliance update to 4.3.10.4+ (auto-applied to supported devices). The product is end-of-life, so migration off Sophos Web Appliance is the durable remediation.' active_exploitation_notes: added to CISA KEV as actively exploited, EPSS ~1.0 reflecting widespread exploitation attempts, pre-authentication command injection giving full remote code execution on internet-facing appliances, and the product is end-of-life, raising the risk of unpatched exposed instances. affected: Sophos Web Appliance versions older than 4.3.10.4 — a pre-authentication command injection in the warn-proceed handler allowing arbitrary OS commands. affected_versions: 'Sophos Web Appliance < 4.3.10.4'. patch_available true; patch_required_reboot true; live_patch_available false. The packet's NIST-800-53-SI-2 gap states flaw remediation is undercut because the product is end-of-life and many exposed instances will never receive the 4.3.10.4 fix; its NIS2-Art21-vulnerability-management gap states the required action is decommissioning/replacement, not patching; its ISO-27001-2022-A.8.8 gap states the required action for this preauth command-injection RCE with a public PoC is decommissioning/replacement, which A.8.8's patch-oriented remediation does not compel; its AU-Essential-8-Patch gap states the exploited-flaw patch SLA is unmeetable for an end-of-life appliance with no forthcoming update path.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The Sophos Web Appliance is a web security gateway — the device is itself the trust boundary, which is why the boundary-protection control cited on this entry has nothing to act on: the packet places the pre-authentication injection on the very interface the appliance presents to the network it guards, so there is no upstream boundary that contains it and no perimeter posture that a compliant deployment could have adopted to keep the request away. The tier requirement bound to this device: a pre-authentication command injection yielding remote code execution on a security gateway is not an appliance-maintenance item on a 14- or 30-day cadence — it runs on the clock that opened with the 2023-11-16 KEV listing, with the appliance taken to 4.3.10.4 or later and brought back up, or the vulnerable interface isolated until that completes. Precondition, and this is where the isolation half is normally over-claimed: the packet places the flaw in the warn-proceed handler, part of the surface the appliance presents to the network it filters, and describes full remote code execution on internet-facing appliances. Removing internet reachability bounds who can send the crafted request, but every client the appliance exists to filter still reaches that handler, so isolation shrinks the attacker population rather than closing the path — and it is simply unavailable where the appliance must keep serving that surface to do its job. It is a holding measure for the window before 4.3.10.4 and the reboot the packet records as required, not a substitute for them; on a unit that will never receive 4.3.10.4 it is a holding measure for the window before removal, and must be recorded as such rather than as a mitigation.",
+        "evidence": "affected: 'Sophos Web Appliance versions older than 4.3.10.4: a pre-authentication command injection in the warn-proceed handler allows execution of arbitrary OS commands, yielding remote code execution.' vector: 'A pre-auth command injection vulnerability in the warn-proceed handler of Sophos Web Appliance older than version 4.3.10.4 allows execution of arbitrary code.' CWE-77; CVSS 9.8; RWEP 73; poc_available true; cisa_kev true with kev_date 2023-11-16; active_exploitation 'confirmed'. patch_available true; patch_required_reboot true; live_patch_available false, with live_patch_notes requiring the appliance update to 4.3.10.4+. active_exploitation_notes: EPSS ~1.0 (top percentile) reflecting widespread exploitation attempts; pre-authentication command injection gives full remote code execution on internet-facing appliances. The packet's NIST-800-53-SC-7 gap states boundary protection is ineffective when the appliance is itself the internet-facing security gateway and that the pre-auth injection is reachable on the very interface the device presents to the network.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Active exploitation is confirmed here and the packet puts EPSS at roughly 1.0, reflecting widespread exploitation attempts against a path that needs no credential — so for any Sophos Web Appliance that was internet-facing below 4.3.10.4, the operating assumption is exposure, not exposure-if-something-was-detected. The update is the specific trap on this entry because the packet records it as auto-applied to supported devices: an appliance can arrive at 4.3.10.4 with no operator action and read as remediated on a maintenance report, while whatever an attacker placed through the warn-proceed handler beforehand — added accounts, altered appliance configuration, persistence — survives the upgrade untouched. That is why recording secure maintenance as met by the update is the wrong verdict for an exposed unit. The response for a unit exposed during the window is configuration capture, rebuild from vendor media or outright replacement, and rotation of every credential the appliance held or could observe: its administrative credentials, any directory or authentication integration it used, and any credential that transited the gateway, since a compromised web proxy sits in the path of the traffic it filters. Detection must key on the behaviour the packet documents rather than on a crash or a tool signature: the attacker sends a crafted request to the warn-proceed handler with shell metacharacters in a parameter the appliance passes to an OS command, so the observables are command execution spawned by the appliance's web-handling process and outbound connections from the appliance to destinations it has no operational reason to reach — a successful injection does not require the service to fail, so alerting on process crashes would miss an attempt behaving exactly as described. Precondition: this depends on appliance telemetry being forwarded off the device before the compromise, because a rooted appliance's local logs are attacker-writable; and on an end-of-life product there is no future update that would later remove attacker persistence, so an exposed unit that is not rebuilt or replaced stays owned.",
+        "evidence": "vector and attack_vector: an unauthenticated attacker sends a crafted request to the warn-proceed handler, injecting shell metacharacters into a parameter the appliance passes to an OS command, achieving remote code execution. CWE-77; CVSS 9.8; RWEP 73; poc_available true; active_exploitation 'confirmed'; cisa_kev true, kev_date 2023-11-16. active_exploitation_notes: EPSS ~1.0 (top percentile) reflecting widespread exploitation attempts; pre-authentication command injection gives full remote code execution on internet-facing appliances; the product is end-of-life, raising the risk of unpatched exposed instances; no specific ransomware attribution. live_patch_notes: 'No live patch; requires the appliance update to 4.3.10.4+ (auto-applied to supported devices). The product is end-of-life, so migration off Sophos Web Appliance is the durable remediation.' patch_required_reboot true; live_patch_available false. The packet's UK-CAF-B4 gap states secure-maintenance objectives assume a maintainable product and that an unsupported internet-facing appliance with a pre-auth RCE cannot be brought into compliance by patching.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2020-2551": {
     "name": "Oracle Fusion Middleware WebLogic IIOP Deserialization RCE",
@@ -52231,7 +54014,21 @@
         "adequate": false,
         "gap": "System-security controls do not constrain outbound requests the collaboration server is allowed to make, so the SSRF-driven internal scanning is not prevented by the existing boundary posture."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case the control exists for, because the two numbers on it point in opposite directions: CVSS 5.3 puts it in the band most vulnerability-management programs park on a routine medium-severity clock, while the packet records it KEV-listed 2023-10-10 with confirmed in-the-wild exploitation, a public PoC, and RWEP 66. For this CVE the control means the KEV listing sets the clock on every Skype for Business Server the organization runs, not the severity band — and the reason the band misleads is specific: the impact the 5.3 reflects is disclosure, but the packet describes an unauthenticated request forcing the server to make an outbound HTTP request that reveals internal IP and port information from the perimeter. That is reconnaissance feeding a later intrusion, not the end of one, and it is available continuously because the server is internet-facing by design.\n\nRemediation, per the packet: patch_available is true, live_patch_available is false, and the recorded note is that remediation requires applying the vendor fixed release. There is nothing to run in place while the change waits for the next server-maintenance window, so the interval between the KEV listing and the fixed release actually being applied is exposure rather than planning time.\n\nDistinguishing test: produce, per Skype for Business Server instance, the date the fixed release was applied measured against 2023-10-10 — not the date the finding was closed in the tracker. A program that triages by CVSS records this as within SLA on a medium-severity clock while a KEV-listed, actively exploited flaw stays live on an internet-facing server for the whole of that window, and the attestation reads clean throughout.\n\nPrecondition, and it is why this is a scheduling control rather than a closure: an expedited clock governs when the fix lands; it does not constrain what the server is permitted to request outbound, so for the whole pre-patch window the forced-request path stays fully open and no amount of prioritization narrows it. And because exploitation is confirmed and the flaw's output is internal topology rather than an artifact left on the host, applying the fixed release stops future probes but does not retract addressing and port information an attacker already collected — a server that was internet-reachable during the window should have that reconnaissance treated as attacker-held, rather than the entry being closed on the patch record.",
+        "evidence": "Packet facts only. CISA KEV-listed 2023-10-10; active_exploitation 'confirmed'; poc_available true; CVSS 5.3; RWEP 66; CWE-918; ai_discovered false. Vector: 'Skype for Business Elevation of Privilege Vulnerability'. Attack vector: 'An unauthenticated attacker sends a crafted request to an internet-facing Skype for Business Server that forces the server to make an outbound HTTP request, disclosing internal IP/port information and enabling internal-network reconnaissance from the perimeter.' patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-36563": {
     "name": "Microsoft WordPad Information Disclosure Vulnerability",
@@ -52288,7 +54085,30 @@
         "adequate": false,
         "gap": "Application-hardening guidance rarely disables or removes WordPad, leaving a legacy document handler that can be coerced into outbound authentication."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "The packet's path into Microsoft WordPad begins with delivery rather than with a memory defect: a victim opens an attacker-crafted document in WordPad, and the file coerces the client into an outbound authentication attempt that leaks NTLM hash material to a host the attacker controls. Nothing else about the endpoint has to be true for that to work, so on any Windows host that has not yet reached the fixed build and taken the reboot the packet requires, keeping the attacker's file away from the WordPad handler is the enforceable control. Applied here that means the untrusted-origin marking is applied at the ingress boundaries themselves — mail gateway, web download, untrusted file share — rather than derived by the application from the file it was handed, and that the marking survives whatever container the document arrives in: a document extracted from an archive, mounted from an ISO or VHD, or renamed must still present as externally sourced, because the container is exactly where provenance is normally lost. Where policy can refuse to open externally-marked documents in the legacy handler at all, that is stronger than any per-file decision. The distinguishing test keys on the delivery the packet documents: send an externally-sourced document through each ingress path nested inside an archive, extract it on a managed host, and confirm it still carries the untrusted-origin marking when it reaches the handler — a user-application-hardening attestation that records macro and ActiveX settings says nothing about a provenance-stripped document opening in WordPad under the user's own token. Precondition: this bounds delivery, it does not repair the flaw, and it is unavailable for any path the marking does not cover. It also retracts nothing: the packet describes the disclosed NTLM material as relayable or crackable, so an endpoint that opened an untrusted document during the exposure window is a credential-rotation item, not a delivery-policy one.",
+        "evidence": "attack_vector: 'A victim opens an attacker-crafted document in WordPad; the file coerces the client into an outbound authentication attempt that leaks NTLM hash material to an attacker-controlled host, which can then be relayed or cracked.' affected states WordPad ships with supported Windows versions and that 'opening a crafted document can disclose NTLM credential material'. The packet's AU-Essential-8-App-Hardening gap: 'Application-hardening guidance rarely disables or removes WordPad, leaving a legacy document handler that can be coerced into outbound authentication.' Its UK-CAF-B2 gap: 'B2 assumes credentials aren't exfiltrable through a document handler, yet the leak enables downstream relay and lateral movement.' patch_required_reboot is true and live_patch_available is false, with live_patch_notes stating remediation requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The population this SLA has to run against is wider than the word WordPad suggests, and affected_versions is the authority rather than the vector: Windows 10 on all supported builds carrying WordPad, Windows 11 on supported builds carrying it, and Windows Server 2008 through 2022 with WordPad. An estate that scopes a document handler to desktops leaves the server population reporting clean — and on a server the interactive account that opens a document is disproportionately an administrator, whose hash is the one worth leaking. For this CVE the control means the Windows update carrying the fix is driven across all three of those populations on the clock that opened with the 2023-10-10 KEV listing rather than folded into the next monthly rollup, with completion measured per host on the build actually running. That last part is where this specific remediation goes wrong: live_patch_available is false and the packet states remediation requires applying the fixed release and rebooting, so a host that has the update installed but has not restarted still carries the vulnerable component and must be counted exposed. Priority has to follow the packet rather than the severity band — CVSS 5.5 with poc_available false sorts below routine items on a score-ranked register, while active_exploitation is confirmed and the outcome is credential material leaving the endpoint into relay and lateral movement. Distinguishing test: produce the running build for every Windows 10, Windows 11 and Windows Server host in the estate that carries WordPad and show each at or above the fixed build — a patch-compliance report that counts updates approved or downloaded, or that enumerates only the workstation fleet, passes cleanly while the exposed population is untouched. Precondition: patching stops future leaks and retracts nothing already taken, so hashes that left an endpoint before the update remain usable until the underlying credentials are rotated.",
+        "evidence": "affected_versions names three populations: 'Windows 10 (all supported builds with WordPad)', 'Windows 11 (supported builds with WordPad)', 'Windows Server 2008 through 2022 (with WordPad)'. cisa_kev is true with kev_date 2023-10-10; active_exploitation is confirmed and active_exploitation_notes records that 'the flaw discloses NTLM credential material and can be chained into relay/authentication attacks'. cvss is 5.5 and poc_available is false. patch_available is true, live_patch_available is false, patch_required_reboot is true, and live_patch_notes states 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The packet's NIST-800-53-SI-2 gap: 'The fix ships in a Windows monthly update; endpoints that defer OS patching remain exposed, and WordPad is a default-installed component that operators rarely track as attack surface.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-22515": {
     "name": "Atlassian Confluence Data Center and Server Broken Access Control Vulnerability",
@@ -52345,7 +54165,39 @@
         "adequate": false,
         "gap": "Patch-application timelines are irrelevant to a zero-day; the control offers no protection until Atlassian's fix is released, underscoring the need for network restriction of admin/setup endpoints."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "For Confluence Data Center and Confluence Server the administrative surface that must authorize its own caller is the setup/onboarding path. The packet's attack vector is an unauthenticated, internet-based caller reaching those endpoints, moving the instance into a configurable state, and creating a new Confluence administrator account it then logs in with — so the product granted 'this request may configure the instance' without ever consulting an identity. Bound to this product the control means each setup/onboarding endpoint refuses a caller not authorized for it regardless of what state the instance believes it is in, and no self-hosted Confluence presents those endpoints to untrusted networks: a reverse proxy or network ACL denies setup/onboarding from any segment with no operational need to run first-time setup, while ordinary user-facing Confluence paths stay open. This is also why the identity-and-access gap is recorded against this entry rather than an account-hygiene finding — the attacker never authenticates as any existing Confluence user, so per-account privilege scoping and SSO/MFA posture are never consulted; the account model is bypassed, not abused. Scope: the packet names Confluence Data Center and Confluence Server 8.0.0 through 8.5.1 and states Atlassian Cloud sites accessed via an atlassian.net domain are not affected, so inventorying Cloud tenants for this flaw manufactures findings against a deployment the vendor states is not vulnerable. Distinguishing test: from an untrusted network, request each setup/onboarding endpoint on a staging Confluence Data Center instance and confirm it is refused before any state change — an estate whose Confluence administrators all authenticate through SSO with MFA passes an access-governance attestation cleanly while this path stays fully open. Precondition: the endpoint-side authorization is a property the vendor fixed release establishes; this control states what to verify and does not implement it. Reachability restriction is the operator-side lever before that release lands, and it bounds who can send the request rather than repairing the check — any caller inside a permitted segment still reaches the endpoint.",
+        "evidence": "Packet vector: external attackers exploited a previously unknown vulnerability in publicly accessible Confluence Data Center and Server instances to create unauthorized Confluence administrator accounts and access the instances; attack_vector adds that the attacker reaches setup/onboarding endpoints, moves the instance into a configurable state, creates an administrator account and logs in with full administrative control. affected: publicly accessible, self-hosted Confluence Data Center and Confluence Server exposing setup/onboarding endpoints; Atlassian Cloud (atlassian.net) is not affected. affected_versions: 8.0.0 through 8.5.1. CWE-20, CVSS 9.8, RWEP 73, poc_available true, CISA KEV 2023-10-05 with confirmed active exploitation. The packet's NIST-800-53-SC-7 gap states boundary protection often left the product directly internet-facing and that without restricting access to the setup/onboarding endpoints the perimeter did not contain the pre-auth admin-creation path; its UK-CAF-B2 gap states the flaw mints a fully-privileged Confluence admin outside any identity process, so access governance offers nothing until the internet-facing setup endpoints are restricted.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Upgrading to a fixed Confluence release closes the pre-auth path; it does not delete an administrator account the exploit already created, and the packet's own incident-handling gap says post-hoc handling must include hunting for attacker-created admins. So for any internet-facing Confluence Data Center or Server instance that ran 8.0.0 through 8.5.1 during the exposure window, the default response is not patch-in-place: enumerate every Confluence administrator against the organisation's own provisioning record, revoke any account with no matching record, rotate administrator credentials, personal-access/API tokens and every integration secret the instance held, and review what those accounts did — app installations, space and global permission changes, bulk exports — because an attacker holding full administrative control of a Confluence instance holds its content. Where an unaccounted administrator is found, restoration from a pre-exposure known-good state is the terminal action and the upgrade alone is not remediation. Detection has to key on what the packet documents, not on a synthetic stand-in: the account is minted through the product's own provisioning path, so it is well-formed and its first login succeeds on the first attempt with a password the attacker set — rules keyed on failed logins, brute-force volume, or malformed requests would miss an attempt behaving exactly as the packet describes. The observable pairing is unauthenticated requests to the setup/onboarding endpoints followed, in the same window, by a new Confluence administrator appearing and authenticating with no change record behind it. Precondition: this depends on holding a provisioning record to compare against and web/application logs covering the window; where neither exists the instance cannot be cleared by inspection, and rebuild from a pre-exposure state is the only honest verdict rather than an assumption of cleanliness.",
+        "evidence": "Packet vector and attack_vector: unauthorized Confluence administrator accounts were created on publicly accessible instances and used to access them. active_exploitation 'confirmed'; active_exploitation_notes record exploitation as a zero-day against internet-facing Confluence Data Center/Server instances to create unauthorized administrator accounts, a CISA KEV known ransomware association, EPSS ~0.99, and public exploitation that was rapid and widespread after disclosure. The packet's NIS2-Art21-incident-handling gap states that incident-handling obligations assume detection precedes admin-account creation, that the exploit mints a legitimate-looking admin account, and that post-hoc handling must therefore include hunting for attacker-created admins — which baseline procedures do not mandate. patch_available true with live_patch_available false and live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Self-hosted Confluence Data Center and Confluence Server instances on 8.0.0 through 8.5.1 must be driven to 8.3.3, 8.4.3, 8.5.2 or later on the clock that opened with the 2023-10-05 KEV listing, not on a quarterly application-upgrade window — the packet records a public PoC, a KEV ransomware association, EPSS ~0.99 and exploitation that was rapid and widespread after disclosure. Two limits bound what this control delivers, and stating them is the point. First, the packet records this as a zero-day exploited before a patch existed, so an SLA keyed to patch availability gave nothing during the pre-disclosure window; the only operator lever then was restricting reachability of the setup/onboarding endpoints, which is why the patch-cadence gaps on this entry cannot be closed by speed alone. Second, patch_required_reboot is false — there is no host reboot to schedule — but that does not make the fix live when the installer exits: live_patch_available is false and remediation is applying the vendor fixed release, so completion is measured per instance on the version the running Confluence reports, not on an upgrade ticket marked done. Scope the sweep to self-hosted Data Center and Server, because the packet states Atlassian Cloud sites on atlassian.net are not affected. And because active exploitation is confirmed, reaching a fixed release does not close an instance that was internet-facing during the window — that instance moves to the incident path with its administrator accounts enumerated, rather than being closed on the patch record.",
+        "evidence": "cisa_kev true with kev_date 2023-10-05; active_exploitation 'confirmed'; CVSS 9.8; RWEP 73; poc_available true; ai_discovered false. affected_versions: 'Confluence Data Center and Server 8.0.0 through 8.5.1 (fixed in 8.3.3, 8.4.3, 8.5.2 and later)'. 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.' active_exploitation_notes: exploited as a zero-day against internet-facing instances, KEV ransomware association, EPSS ~0.99, public exploitation rapid and widespread after disclosure. The packet's NIST-800-53-SI-2 gap states this was a zero-day exploited before a patch existed and that compensating perimeter controls were the only defense during the exposure window; its ISO-27001-2022-A.8.8 gap states technical-vulnerability management could not enumerate an unknown flaw; its AU-Essential-8-Patch gap states patch-application timelines are irrelevant to a zero-day until Atlassian's fix is released. affected states Atlassian Cloud (atlassian.net) is not affected.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-40044": {
     "name": "Progress WS_FTP Server Deserialization of Untrusted Data Vulnerability",
@@ -53297,7 +55149,31 @@
         "adequate": false,
         "gap": "Patch maturity is unattainable for unmaintained embedded firmware; device replacement is the only remediation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet carries the two facts this control exists to resolve per unit, and they point in opposite directions: a patch is recorded as available, while the affected field states that numerous affected devices are end-of-life without fixed firmware. The flaw is in the Realtek SDK's miniigd UPnP SOAP service as shipped inside OEM router and IoT firmware, so whether a fix exists is a per-model question that has to be answered from each OEM rather than assumed either way across the estate. Scope the inventory to what the packet names — every router or IoT device whose firmware embeds the Realtek SDK miniigd service, across OEMs, with the packet naming D-Link among others — rather than to one vendor's model line, because an inventory built by brand misses the same embedded component under a different badge. Units whose OEM shipped fixed firmware are patch items, and the packet records no live-patch mechanism and a reboot as part of applying the fixed release, so such a unit is not remediated until it has come back up running the new firmware. Units whose model has no fixed firmware cannot be patched at all: for those the terminal state is replacement on a dated schedule, because a risk acceptance with no removal date leaves a device carrying a public exploit, an EPSS the packet puts at roughly 0.9998 and exploitation confirmed in the wild through 2023 in service indefinitely — and that device is exposed not only to this command-injection flaw but to everything found in its unmaintained firmware since. Precondition, which is where this control is normally over-claimed: an inventory is what makes action possible, it is not itself a mitigation, and the packet's exploit needs nothing more than the ability to send a crafted NewInternalClient SOAP request to the miniigd service. On ISP-provided CPE the operator may hold neither the firmware decision nor the configuration, in which case the replacement item is a conversation with the provider rather than a maintenance task, and recording it as an internal patch backlog item misstates who can act. Because exploitation is confirmed and the packet records this flaw as a staple of Mirai- and Gafgyt-class botnet recruitment, a unit that was reachable during the exposure window should be rebuilt from a known-good firmware image and re-provisioned rather than closed out on a firmware version number.",
+        "evidence": "Packet facts only: CWE-77; vector 'The miniigd SOAP service in Realtek SDK allows remote attackers to execute arbitrary code via a crafted NewInternalClient request, as exploited in the wild through 2023'; affected 'Devices embedding the Realtek SDK miniigd UPnP SOAP service ... Reachable across many OEM routers/IoT (e.g., D-Link and others); numerous affected devices are end-of-life without fixed firmware'; affected_versions 'Realtek SDK (miniigd UPnP service) as shipped in affected OEM router/IoT firmware'; cisa_kev true, kev_date 2023-09-18, active_exploitation confirmed, poc_available true, RWEP 79 / CVSS 9.8; active_exploitation_notes 'EPSS ~0.9998 ... a staple of Mirai/Gafgyt-class IoT botnets'; patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting'; the SI-2 gap 'Many affected consumer/embedded devices are end-of-life with no vendor firmware; flaw remediation has no patch to apply'; the ISO A.8.8 gap 'cannot inventory or patch the Realtek SDK buried in third-party OEM firmware across heterogeneous SOHO hardware'; the Essential Eight gap 'device replacement is the only remediation'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this Realtek SDK flaw the estate splits into exactly the three states this control requires be told apart, and the packet supplies the split. A device whose OEM shipped fixed firmware and has been rebooted onto it is the patched state. A device with no fixed firmware whose WAN-side access to the miniigd UPnP/SOAP port has been blocked is the mitigation-active state — the packet's own framing is that network-security controls are the only realistic defense — and the requirement here is that such a device is recorded as an active compensating control carrying a dated replacement action, never as patched per SLA, because nothing about the vulnerable code has changed and the crafted NewInternalClient request still executes if it arrives. A device with neither is full exposure and has to be scored that way rather than absorbed into a patch-compliance percentage, which is the specific way this CVE disappears from a compliance report while remaining exploitable. Precondition on the mitigation-active state, which is where it gets over-recorded: blocking WAN-side reachability removes the internet-facing route the packet attributes to Mirai- and Gafgyt-class botnet recruitment, but it removes nothing for a caller already on the device's own network, which is where the UPnP service is intended to answer — so a compromised host inside the LAN reaches the unauthenticated path unimpeded, and a device already enrolled in a botnet is not recovered by closing the WAN side. The packet also records that default configurations and ISP-provided CPE frequently leave the service WAN-reachable, so on a unit whose configuration the operator does not control, the mitigation-active state is not available at all and the honest verdict is full exposure. The distinguishing test is per device and from outside: probe the unit's WAN address for the UPnP/SOAP service and confirm nothing answers — a fleet record asserting that UPnP is disabled is a statement about intended configuration, not a demonstration that the port is closed.",
+        "evidence": "Packet facts only: patch_available true, patch_required_reboot true, live_patch_available false ('remediation requires applying the fixed release and rebooting'); affected 'numerous affected devices are end-of-life without fixed firmware'; the SC-7 gap 'Boundary protection must block WAN-side access to the UPnP/SOAP port; default configs and ISP-provided CPE frequently leave it reachable'; the NIS2 network-security gap 'Network-security controls are the only realistic defense (block WAN-side UPnP/SOAP), yet many devices expose the service to the WAN by default'; the UK-CAF-B4 gap 'the durable defense is blocking WAN-side UPnP/SOAP access to the miniigd service; the control does not compel that egress/ingress hardening, and default CPE configs leave the command-injection port reachable'; attack_vector 'A remote, unauthenticated attacker sends a crafted UPnP SOAP NewInternalClient request to the Realtek miniigd service ... typically enrolling the device in a botnet'; active_exploitation confirmed with poc_available true and KEV listing 2023-09-18.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2017-6884": {
     "name": "Zyxel EMG2926 Routers Command Injection Vulnerability",
@@ -53582,7 +55458,28 @@
         "adequate": false,
         "gap": "Identity and access control expects strong authentication yet does not compel the tunnel-group hardening (no-MFA default group disabled, rate-limiting) needed to stop credential brute forcing on the appliance."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "ASA and FTD are the perimeter's remote-access authentication enforcement point, and the packet places this defect inside that enforcement rather than around it: AAA is not properly separated between the RA VPN feature and the HTTPS-management and site-to-site VPN features, so specifying a default connection profile/tunnel group lets an unauthenticated attacker run credential guessing directly against the gateway, and on ASA 9.16 and earlier lets a clientless SSL VPN session be established with an unauthorized user. Be precise about which half is which, because the packet is: it states the flaw does not allow bypassing authentication, and that valid credentials — including a valid second factor where MFA is configured — are still required to establish a remote-access VPN session. The expedited clock is therefore warranted not by a full authentication bypass but by what the gateway gives an unauthenticated attacker for free, which is unlimited credential discovery against the enforcement point itself, plus the authorization failure on 9.16 and earlier.\n\nFor this CVE the clock runs from the 2023-09-13 KEV listing through the reload of every affected ASA and FTD unit. The packet records patch_available true, live_patch_available false, and remediation as applying the fixed release and rebooting — so a unit that has taken the release but has not been reloaded still runs the vulnerable code and must be counted as exposed, not as patched. On a production VPN concentrator that reload is the step most likely to be deferred, because taking it drops live tunnels, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Enumerate units on ASA 9.16 or earlier first: those carry the clientless-session path on top of the credential-discovery path.\n\nDistinguishing test: report, per ASA and FTD unit, the software version the device is actually running and the timestamp of its last reload, rather than the version staged from the management console — a fleet where the console shows the fixed release pushed everywhere passes a patch attestation while unreloaded devices keep serving the vulnerable code.\n\nPrecondition on interim exposure, which is where this is normally over-claimed: the packet's stated exploitation requirement is reaching a default connection profile/tunnel group on the RA VPN feature. Restricting who can reach that profile bounds the population that can attempt it, but a remote-access VPN exists to answer from untrusted networks, so on any gateway serving general remote access there is no source restriction that removes the path — only the fixed release and the reload do. Interim measures narrow the attempt rate; they do not close it.\n\nAnd what the reload does not do: the flaw's product is valid username and password combinations identified by brute force, and the packet records Akira ransomware using this for initial access. Credentials harvested during the exposure window remain valid after the fixed release is applied — the update repairs the AAA separation, it does not invalidate what was already taken — so a gateway whose RA VPN was reachable during the window needs those accounts rotated and established sessions reviewed, not closed on the patch record.",
+        "evidence": "Packet facts only. CISA KEV-listed 2023-09-13; active_exploitation 'confirmed'; CVSS 9.1; RWEP 62; poc_available false; CWE-288 and CWE-863; ai_discovered false. Vector: the RA VPN feature of Cisco ASA and FTD 'could allow an unauthenticated, remote attacker to conduct a brute force attack in an attempt to identify valid username and password combinations or an authenticated, remote attacker to establish a clientless SSL VPN session with an unauthorized user'; 'due to improper separation of authentication, authorization, and accounting (AAA) between the remote access VPN feature and the HTTPS management and site-to-site VPN features'; exploited 'by specifying a default connection profile/tunnel group'; clientless SSL VPN session 'only when running Cisco ASA Software Release 9.16 or earlier'; and the packet's own notes that 'This vulnerability does not allow an attacker to bypass authentication. To successfully establish a remote access VPN session, valid credentials are required, including a valid second factor if multi-factor authentication (MFA) is configured.' Attack vector records 'Akira ransomware used this for initial access'. patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "ASA and FTD are perimeter firewalls, and for this CVE the gateway is also the only place the attack is visible before it succeeds. The packet gives the exploitation shape precisely enough to key on: an unauthenticated attacker specifies a default connection profile/tunnel group and conducts a brute-force attack to identify valid username and password combinations, then uses those credentials to establish a remote-access VPN session. The successful login is not the signal — the packet states the flaw does not bypass authentication and that valid credentials are required, so that session looks exactly like a legitimate one on the wire and in the logs. The distinguishing signal is the failed-authentication volume against the default connection profile on the RA VPN feature immediately preceding it, from a source that then authenticates successfully. That correlation — burst of failed RA VPN authentications against a default tunnel group, followed by a successful RA VPN authentication for one of the guessed accounts — is what the rule keys on.\n\nApplied to this device, the control means the gateway's authentication logs, not only its traffic and threat logs, are forwarded to a SIEM in a separate trust zone: the correlation is over time and across attempts and across units, which is not something a single appliance's local view supports, and the appliance is itself the asset under attack rather than a sensor watching one.\n\nAsk what an exploit doing exactly what the packet describes emits, because it is very little: no malware, no file write, no process crash, no exploit tooling on any host — only VPN authentication records on the gateway, then a valid VPN session. A rule keyed on endpoint telemetry, malware signatures, or appliance instability sees none of it, and an authentication-monitoring posture that only counts successes sees the intrusion but not the attack that produced it.\n\nPreconditions, and they are why this is a compensating measure rather than a fix. The logs must already be shipping and the volume rule must already exist — telemetry configured after the intrusion produces nothing, and on a perimeter gateway authentication-log forwarding is exactly what is most often left at defaults. Detection does not prevent the brute force from succeeding; it bounds the exposure to alert-and-response time during the window before the fixed release and the reload land, and it supplies the account list to rotate afterwards. It also does not cover the clientless SSL VPN path the packet attributes to ASA 9.16 and earlier, where a session is established with an unauthorized user using valid credentials — no failed-attempt burst necessarily precedes that, so this rule would not distinguish it from a normal session.",
+        "evidence": "Packet facts only. Vector and attack_vector state that an unauthenticated remote attacker can 'conduct a brute force attack in an attempt to identify valid username and password combinations' by 'specifying a default connection profile/tunnel group', that the identified credentials 'could then be used to establish an unauthorized remote access VPN session', and that on ASA Software Release 9.16 or earlier a clientless SSL VPN session can be established with an unauthorized user 'using valid credentials'; the packet's notes state the flaw 'does not allow an attacker to bypass authentication' and that valid credentials remain required. CISA KEV-listed 2023-09-13 with active_exploitation 'confirmed'; the attack_vector records Akira ransomware using this for initial access. patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2023-4863": {
     "name": "Google Chromium WebP Heap-Based Buffer Overflow Vulnerability",
@@ -53696,7 +55593,27 @@
         "adequate": false,
         "gap": "Technical-vulnerability management periodicity does not cover the NTLM-relay hardening (SMB signing, Extended Protection for Authentication) that turns a leaked hash from a breach into a non-event."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation of this CVE requires the victim to receive an attacker-crafted Word/Office document containing an external reference, so on an estate that has not yet reached the fixed release the delivery path is the enforceable control. Bound to this product: documents arriving by mail, web download or untrusted file share carry an untrusted-origin marking applied at the boundary, that marking survives the container the document is delivered in so a file extracted from an archive or renamed on the way still arrives marked, and an externally-sourced document opens into the isolated reduced-privilege render rather than the full parsing path that follows the external reference outbound. Scope this to what the packet's affected_versions names, which is four products on four update tracks — Microsoft 365 Apps for Enterprise, Office 2019, Office LTSC 2021 and Word 2013 Service Pack 1 — and note why that matters here: those tracks reach their fixed builds at different times, and the ingress marking is the single measure that applies identically to all four while they do, because it acts before the document reaches any of them. The distinguishing test is delivery-side: send an externally-sourced document through each ingress path — mail, web, file share, and nested inside an archive — and confirm it arrives marked as externally sourced, rather than confirming only that a policy for marked documents exists. Preconditions, and the first is the one that decides whether this control is worth anything on this CVE. The packet records that the forced authentication fires on open OR on a Preview-pane render, so a measure that acts on the user's open action does not by itself cover the preview path; the estate must be able to demonstrate that the preview render is governed by the same untrusted-origin decision, and where it cannot, preview rendering of externally-sourced documents has to be turned off — the packet's own application-hardening gap names disabling the Preview Pane as a mitigating measure for exactly this reason. Second, provenance marking bounds which documents reach the vulnerable parsing path; it does not stop a document that reaches it from forcing the outbound authentication, and it does nothing for a document arriving through a channel that applies no marking. This is a holding measure. The remediation the packet records is the vendor fixed release, with live_patch_available false and live_patch_notes stating there is no vendor live-patch mechanism. patch_required_reboot is false, which means no machine restart — it does not mean the fix is live on an Office process that is already running, which keeps executing the build it started with, so measure completion per track on the version the running Word or Office process reports.",
+        "evidence": "All from the packet for CVE-2023-36761: affected states 'Microsoft Word / Office document parsing; a crafted document (openable or Preview-pane-rendered) forces an outbound authentication that discloses the victim's NTLM hash.' attack_vector states a crafted Word/Office document contains an external reference that forces the client to authenticate outbound (SMB/WebDAV) to an attacker-controlled server on open or Preview-pane render, disclosing the victim's NetNTLM hash for relay or offline cracking. active_exploitation_notes states it was exploited in the wild as a zero-day patched by Microsoft in September 2023, that opening — or merely previewing in the Preview Pane — a crafted document forces the outbound authentication, and that CISA added it to KEV on 2023-09-12. affected_versions lists Microsoft 365 Apps for Enterprise, Microsoft Office 2019, Microsoft Office LTSC 2021, and Microsoft Word 2013 Service Pack 1. cwe_refs CWE-20, cvss 6.5, rwep_score 50, poc_available false. 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.' The AU-Essential-8-App-Hardening gap states application hardening (disabling the Preview Pane, blocking outbound SMB, enforcing SMB signing) is the mitigating control the KEV entry does not require, and that patching alone left the Preview-pane vector live until applied.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry is unusual in that the packet itself enumerates the compensating measures and states what they achieve: the application-hardening gap names disabling the Preview Pane, blocking outbound SMB and enforcing SMB signing, and the technical-vulnerability-management gap describes NTLM-relay hardening — SMB signing and Extended Protection for Authentication — as what turns a leaked hash from a breach into a non-event. Read precisely, that is a statement about what an attacker can do with the NetNTLM hash, not about whether the hash leaves the host: the crafted document still forces the outbound authentication when it is opened or previewed, and the disclosure still occurs. A hardened estate is therefore in a compensating state, not a remediated one, and this control exists to keep those two apart in the record. Applied to this CVE, it means the compliance verdict is carried per Office update track and distinguishes three states: the vendor fixed release applied and the running Office process reporting a fixed build; relay and preview hardening active while that release is still pending on this track; and neither. The middle state is recorded as a compensating-control state with a dated action item, never as patched per SLA. Per-track is the load-bearing part, because the packet's affected_versions names Microsoft 365 Apps for Enterprise, Office 2019, Office LTSC 2021 and Word 2013 Service Pack 1 — four products on separate update tracks — and a single estate-wide 'hardening in place' verdict is exactly how a track that never reached the fixed release gets closed out while it keeps leaking the hash on the first crafted document a user previews. The distinguishing test is to ask the vulnerability-management record to produce, per track, which of the three states that track is in and the date its middle-state action item comes due; a record that reports one verdict for 'Office' cannot answer it. Precondition: this control governs how the state is recorded and tracked — it does not itself apply the hardening, and it does not remediate. The packet records no live-patch mechanism and states remediation requires applying the vendor fixed release, so that release is the only thing that moves a track out of the middle state; and because active exploitation is confirmed and the disclosure is silent, a hash disclosed while a track sat in the middle state stays valid to an attacker until the affected credential is changed.",
+        "evidence": "All from the packet for CVE-2023-36761: the ISO-27001-2022-A.8.8 gap states 'Technical-vulnerability management periodicity does not cover the NTLM-relay hardening (SMB signing, Extended Protection for Authentication) that turns a leaked hash from a breach into a non-event.' The AU-Essential-8-App-Hardening gap names disabling the Preview Pane, blocking outbound SMB and enforcing SMB signing as the mitigating control the KEV entry does not require. affected_versions lists Microsoft 365 Apps for Enterprise, Microsoft Office 2019, Microsoft Office LTSC 2021 and Microsoft Word 2013 Service Pack 1. attack_vector states the crafted document forces the client to authenticate outbound (SMB/WebDAV) to an attacker-controlled server on open or Preview-pane render, disclosing the NetNTLM hash for relay or offline cracking. cisa_kev true, kev_date 2023-09-12, active_exploitation confirmed. 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.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-36802": {
     "name": "Microsoft Streaming Service Proxy Privilege Escalation Vulnerability",
@@ -55004,7 +56921,33 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would flag CVE-2023-24489 only once tracked as KEV; the low-key May release meant many asset owners had no ticket until August, so the padding-oracle-to-web-shell chain stayed live on unpatched controllers."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation path does not end at code execution, it ends at a file on disk: an unauthenticated attacker exploits the AES-CBC padding oracle in the StorageZones Controller, forges valid-padding encrypted parameters, chains a path traversal, and uploads an .aspx web shell into the IIS webroot via /documentum/upload.aspx. The remediation the packet records — upgrading the ShareFile StorageZones Controller to 5.11.24 or later and recycling the IIS application pool — replaces product code and restarts the worker process. Neither step deletes an .aspx file an attacker already wrote into the webroot, and neither invalidates any credential the application-pool identity holds, so the upgraded controller keeps serving the shell through the patched application. Applied to this product the requirement is that any customer-managed StorageZones Controller reachable during the exposure window is handled as compromised rather than as patched: export and preserve its configuration, rebuild the host at the fixed build from a known-good image instead of upgrading in place, rotate the credentials the controller's service identity holds, and enumerate the IIS webroot and the directories it serves against a known-good installation for .aspx files that are not part of the product. Distinguishing test: on a controller that has already been upgraded, list the webroot's .aspx files and account for each one — an attestation that every StorageZones Controller reports 5.11.24 or later passes cleanly with a web shell dropped before the upgrade still present. Precondition, and this is where the control gets over-claimed: it is an incident-response default, not a preventive measure. It does nothing for a controller still running a vulnerable build, since only the upgrade closes the padding oracle, and a rebuild helps only if the restore point predates the exposure window — where the stored content forces a later restore point, the artifact hunt above is the remaining lever, not the rebuild.",
+        "evidence": "Packet attack_vector: 'Unauthenticated attacker exploits an unauthenticated-AES-CBC padding oracle in the StorageZones Controller, forges valid-padding encrypted parameters, and chains a path traversal to upload an .aspx web shell to the IIS webroot via /documentum/upload.aspx, achieving remote code execution.' Packet live_patch_notes: 'No live-patch mechanism; remediation is upgrading the ShareFile StorageZones Controller to version 5.11.24 or later and recycling the IIS application pool.' patch_available true, live_patch_available false. Vector: 'A vulnerability has been discovered in the customer-managed ShareFile storage zones controller which, if exploited, could allow an unauthenticated attacker to remotely compromise the customer-managed ShareFile storage zones controller.' cisa_kev true, kev_date 2023-08-16, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 74, cwe_refs CWE-284. Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 Management of technical vulnerabilities, NIST-800-53-SI-2 Flaw Remediation and NIS2-Art21-patch-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's vector names the customer-managed ShareFile storage zones controller, which is the fact that decides who owns the clock: none of this fix arrives through the vendor's cloud service, so the operator takes the upgrade to 5.11.24 or later and the IIS application-pool recycle themselves, on every controller they run, and the packet records no live-patch path that would let them defer the restart. Applied to this CVE the control means that clock runs from the 2023-08-16 KEV listing rather than from the next scheduled application-patch window: the flaw needs no credential, the PoC is public, exploitation is confirmed, and /documentum/upload.aspx answers an unauthenticated request, so a controller left on a vulnerable build across even a standard two-week application SLA is exposed for the whole window with no authentication step in front of it. The control's 'whichever is later' clause is the part that matters on this entry — the vendor's fixed build and the KEV listing are separate events, and an SLA keyed only to a vendor release starts counting from a build an operator may never have registered as security-relevant, whereas the KEV date is an unambiguous trigger. Distinguishing test: produce, per controller, the installed StorageZones Controller version and the timestamp of the application-pool recycle that followed it, measured against 2023-08-16. A patch report showing the fixed build with no recorded recycle does not demonstrate that the patched code is the code running, because the packet makes the recycle part of the remediation and offers no live-patch alternative. Precondition: meeting this SLA closes the exploit path forward only. It says nothing about a controller that was already reached during the window, which is the separate incident-response requirement recorded against this entry.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-08-16, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 74. patch_available true, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation is upgrading the ShareFile StorageZones Controller to version 5.11.24 or later and recycling the IIS application pool.' Vector: 'A vulnerability has been discovered in the customer-managed ShareFile storage zones controller which, if exploited, could allow an unauthenticated attacker to remotely compromise the customer-managed ShareFile storage zones controller.' attack_vector places the unauthenticated upload at '/documentum/upload.aspx'. Citing gaps include AU-Essential-8-Patch (ASD Essential Eight), NIS2-Art21-patch-management, NIST-800-53-SI-2 Flaw Remediation and UK-CAF-B4 System security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-38180": {
     "name": "Microsoft .NET Core and Visual Studio Denial-of-Service Vulnerability",
@@ -55323,7 +57266,41 @@
         "adequate": false,
         "gap": "An organization's technical-vulnerability register scored this 5.5 and would not flag it as chain-critical; A.8.8 as normally run does not correlate a low-CVSS kernel item with an active APT zero-click chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "This Apple kernel flaw is not a standalone bug an operator can triage as an endpoint item — the packet places it as the kernel-primitive stage of the Operation Triangulation zero-click iMessage chain against iOS devices released before iOS 15.7.1, with Kaspersky documenting the abuse of undocumented hardware MMIO registers to defeat the memory-protection controller. Zero-click is the whole difficulty: there is no attachment for a user to decline and no link to leave untapped, so awareness training contributes nothing and the only pre-fix lever is refusing to process the content on arrival. For the cohort plausibly inside the targeting set this chain served, the requirement is a standing reduced-attack-surface posture on their iPhones, iPads and Macs in which message attachments, link previews, fonts and untrusted web content are not parsed automatically — assigned before the next disclosure rather than configured in response to this one, because the posture only helps if it was already on when the chain arrived. That timing is the point of the control on this entry: the packet's own flaw-remediation gap notes the exploited primitive was an undocumented hardware feature, so no remediation cadence could act until Apple shipped the fixed builds on 2023-07-24, which means the entire in-the-wild window was covered by whatever posture each device already carried. Preconditions: this narrows the delivery path into the kernel primitive, it does not remove it, and it is not available as a retroactive fix — a device compromised during the confirmed exploitation window is not remediated by enabling the posture afterwards and belongs on the incident path with its build and message history examined. It is a holding measure for the window before the fixed build and its required restart land, not a substitute for them.",
+        "evidence": "active_exploitation_notes: 'Exploited in the wild as a kernel-primitive stage of the Operation Triangulation zero-click iMessage chain against iOS devices released before iOS 15.7.1. Apple confirmed awareness of active exploitation; Kaspersky documented the abuse of undocumented hardware MMIO registers to defeat memory protection.' affected records that 'a malicious app can modify sensitive kernel state by abusing undocumented memory-mapped I/O (MMIO) registers to bypass the hardware page-protection controller'. The packet's NIST-800-53-SI-2 gap: 'The exploited primitive was an undocumented hardware feature, so no SI-2 flaw-remediation cadence could act until Apple shipped iOS 15.7.8/16.6 on 2023-07-24; devices patched only by the KEV due date (2023-08-16) stayed exposed across the entire zero-click in-the-wild window.' Its UK-CAF-B4 gap adds that 'B4 system-security assurance cannot be verified against an undocumented silicon MMIO register the vendor itself never documented.' active_exploitation is confirmed; kev_date 2023-07-26.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The scope trap on this entry sits in affected_versions, not in the vector's wording. Five Apple OS families are named — iOS/iPadOS below 15.7.8, iOS/iPadOS 16.x below 16.6, macOS Ventura below 13.5, macOS Monterey below 12.6.8, macOS Big Sur below 11.7.9, tvOS below 16.6 and watchOS below 9.6 — so an estate that enforces update policy on iPhones, iPads and Macs while never enumerating its Apple TV and Watch devices reports full compliance with two affected platforms untouched. For this CVE the control means the fixed build for each of those lines is pushed on the clock that opened with the 2023-07-26 KEV listing, with user deferral disallowed, rather than left to the device holder or to the next image refresh — the packet's Essential Eight gap records exactly this failing, that MDM update lag left devices exposed after the 2023-07-24 fix while the chain was actively deployed. Completion is measured on the build the device is running after its restart: live_patch_available is false and the packet states Apple ships no live-kernel-patch mechanism and that remediation requires installing the fixed OS build and rebooting the device, so an update downloaded and staged is not remediation and must not close the item. The trigger has to be the KEV listing rather than the score, because at CVSS 5.5 with poc_available false this ranks below routine work on a severity-sorted queue while being a live stage of a zero-click chain. Distinguishing test: report the running OS build for every enrolled iPhone, iPad, Mac, Apple TV and Watch and show each against the fixed build for its own line — a console that reports 'update policy applied', or that covers only the families the management platform was set up for, is the paper form of this control.",
+        "evidence": "affected_versions lists 'iOS/iPadOS < 15.7.8', 'iOS/iPadOS 16.x < 16.6', 'macOS Ventura < 13.5', 'macOS Monterey < 12.6.8', 'macOS Big Sur < 11.7.9', 'tvOS < 16.6', 'watchOS < 9.6'. live_patch_available is false and live_patch_notes states 'Apple ships no live-kernel-patch mechanism; remediation requires installing the fixed OS build (iOS/iPadOS 15.7.8 or 16.6, macOS Ventura 13.5, macOS Monterey 12.6.8, macOS Big Sur 11.7.9, tvOS 16.6, watchOS 9.6) and rebooting the device'; patch_required_reboot is true. cisa_kev is true with kev_date 2023-07-26 and active_exploitation confirmed; cvss is 5.5 and poc_available is false. The packet's AU-Essential-8-Patch gap: 'MDM update lag left devices exposed after the 2023-07-24 fix while the chain was actively deployed.' Its NIS2-Art21-patch-management gap: 'severity-driven patching misses low-CVSS kernel primitives that are chain-critical in real attacks.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Half of this control applies to this Apple flaw and half does not, and the half that does not is worth stating so it is never recorded as a mitigation. The packet's trigger is an app modifying sensitive kernel state, which would ordinarily make application-install restriction the operator's lever — but the delivery it documents is a zero-click iMessage chain, so the malicious code arrives without any installation an install policy could refuse, and restricting untrusted or side-loaded applications does nothing against this path. What remains is making the fixed build a condition of access rather than a row on a report: an enrolled iPhone, iPad or Mac running below its own line's fixed build — 15.7.8 or 16.6 for iOS/iPadOS, 13.5 for Ventura, 12.6.8 for Monterey, 11.7.9 for Big Sur — is denied mail, VPN and document access until it is at or above it, instead of keeping every entitlement it had while showing as non-compliant. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually withholds access to protected resources; an estate that surfaces the stale build and leaves the access in place has recorded the exposure rather than removed it. Where a device family holds no organisational resource for the gate to withhold, the access condition has no grip and those devices — the tvOS and watchOS units affected_versions names at fixed builds 16.6 and 9.6 — must be held to the fixed build by enumeration instead, not dropped from scope because the gate cannot reach them. Precondition: because the packet requires the fixed build to be installed and the device rebooted, the condition must evaluate the build the device is running rather than the update it has downloaded, or it re-admits a device still executing the vulnerable kernel. This is a holding measure for the window before the build lands, and it does nothing for a device already compromised during the confirmed exploitation window.",
+        "evidence": "vector: 'An app may be able to modify sensitive kernel state. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.7.1', with the fix list 'macOS Monterey 12.6.8, iOS 15.7.8 and iPadOS 15.7.8, iOS 16.6 and iPadOS 16.6, tvOS 16.6, macOS Big Sur 11.7.9, macOS Ventura 13.5, watchOS 9.6'. active_exploitation_notes place delivery in 'the Operation Triangulation zero-click iMessage chain', not in a user-initiated installation. patch_required_reboot is true and live_patch_notes states remediation 'requires installing the fixed OS build ... and rebooting the device'. The packet's ISO-27001-2022-A.8.8 gap: 'An organization's technical-vulnerability register scored this 5.5 and would not flag it as chain-critical', and its AU-Essential-8-Patch gap records MDM update lag leaving devices exposed after the 2023-07-24 fix.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-35078": {
     "name": "Ivanti Endpoint Manager Mobile Authentication Bypass Vulnerability",
@@ -55445,7 +57422,38 @@
         "adequate": false,
         "gap": "A.5.15 access control is enforced by ColdFusion's own administrator authentication; CVE-2023-29298 bypasses that check via an unexpected path segment, so the documented access-control policy did not actually restrict the administrator endpoints."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "ColdFusion decides which requests may reach its administrator CFM and CFC endpoints, and this CVE is that decision failing open: the packet's attack vector is a crafted request path carrying an unexpected extra segment that defeats the access-control check, exposing administrator endpoints to unauthenticated callers with no user interaction required. Bound to this product the control means each administrator CFM/CFC endpoint authorizes its own caller rather than inheriting a verdict from the path-matching layer in front of it, and the ColdFusion administrator surface is segmented so an untrusted network caller cannot present a request to that layer at all — an internet-facing ColdFusion server should not answer administrator endpoints from the public internet whatever application content it serves. Apply this across all three product tracks the packet names, not just the one an inventory happens to list: ColdFusion 2018, 2021 and 2023 installations each carry the same administrator surface. This is also why an access-control-policy attestation passes while the flaw is live — the documented policy is enforced by ColdFusion's own administrator authentication, and the attacker never authenticates as any ColdFusion administrator, so no account model is ever consulted. Priority follows the chain rather than the 7.5 CVSS band: the packet records attackers chaining this with CVE-2023-29300 (WDDX deserialization) to reach unauthenticated RCE on internet-facing ColdFusion, so this is a code-execution precondition, not an information-exposure item. Distinguishing test: from a segment with no operational need to administer ColdFusion, request each administrator CFM/CFC endpoint on a staging instance — including with extra path segments appended — and confirm each is refused before the endpoint runs. Precondition: the endpoint-side check is what Adobe's update repairs; segmentation is the operator-side lever until that update and its follow-up land, and it bounds who can send the crafted request without repairing the check, so any caller inside a permitted segment still reaches it.",
+        "evidence": "Packet vector: ColdFusion 2018u16 and earlier, 2021u6 and earlier and 2023.0.0.330468 and earlier are affected by an Improper Access Control vulnerability resulting in a security feature bypass; an attacker could leverage it to access the administration CFM and CFC endpoints, and exploitation does not require user interaction. attack_vector: a crafted request path with an unexpected extra segment defeats ColdFusion's access-control check, exposing administrator CFM/CFC endpoints to unauthenticated callers, after which attackers chain the WDDX deserialization flaw CVE-2023-29300 for remote code execution. CWE-284; CVSS 7.5; RWEP 68; poc_available true; CISA KEV 2023-07-20 with confirmed active exploitation. affected_versions: ColdFusion 2018 <= Update 16, 2021 <= Update 6, 2023 <= 2023.0.0.330468. The packet's UK-CAF-B4 gap states CAF B4 assumes the admin console is authentication-gated and that this flaw let unauthenticated requests reach administrator endpoints; its ISO-27001-2022-A.5.15 gap states access control is enforced by ColdFusion's own administrator authentication, which the CVE bypasses via an unexpected path segment, so the documented policy did not actually restrict the administrator endpoints.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.5.15"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This entry is the case the control names. The packet records that Adobe's initial fix was incomplete and required a follow-up update, and that first-pass remediation left the access-control bypass exploitable until that follow-up landed. For ColdFusion that means the vulnerability-management record cannot treat 'the July update was applied' as closure: the closing evidence is the build each running ColdFusion instance reports, measured against both the initial update the packet names for its track — 2018 Update 17, 2021 Update 7, 2023.0.0.1 — and the follow-up fix that completed it, with every server re-verified after the follow-up rather than only after the first pass. It also sets what the operator should expect next on this surface. A bypass reachable by appending an unexpected segment to the request path, whose first vendor fix did not fully close it, points at the path-handling layer itself rather than one endpoint, so further bypasses against the same primitive are a live expectation: the administrator-endpoint segmentation should be retained past the update rather than removed once the patch record reads clean. Distinguishing test: after applying the update, re-issue the crafted extra-path-segment request against an administrator CFM/CFC endpoint on a staging ColdFusion instance instead of reading the installed update level — an estate that verified only the first patch carried a clean flaw-remediation record while the bypass still worked, which is exactly the failure this control exists to catch.",
+        "evidence": "live_patch_notes: 'No live-patch mechanism; remediation requires Adobe's ColdFusion update (2018 Update 17, 2021 Update 7, 2023.0.0.1) plus the follow-up fix that completed the incomplete initial patch.' active_exploitation_notes: Adobe's initial fix was incomplete and required a follow-up update, and attackers chained the flaw with CVE-2023-29300 to achieve unauthenticated RCE on internet-facing ColdFusion within days of Adobe's July 2023 patch. The packet's NIST-800-53-SI-2 gap states that Adobe's APSB23-40 fix was initially incomplete, so flaw remediation applied on the first patch still left the access-control bypass exploitable until the follow-up update, and that mass exploitation began within days of the 2023-07-20 KEV listing — faster than a single-pass remediation could verify. attack_vector identifies the primitive as a crafted request path with an unexpected extra segment defeating the access-control check. patch_available true; poc_available true; active_exploitation 'confirmed'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "ColdFusion 2018 up to Update 16, 2021 up to Update 6 and 2023 up to 2023.0.0.330468 must be driven to their fixed updates on the clock that opened with the 2023-07-20 KEV listing, not on a monthly or fortnightly application cadence — the packet records mass exploitation beginning within days of that listing, a public PoC, and a chain to unauthenticated remote code execution via CVE-2023-29300. Enumerate all three tracks: an estate that updates its inventoried ColdFusion 2021 servers while a 2018 or 2023 install sits on an affected build still answers the crafted request. The clock does not stop at the first update — live_patch_available is false and the packet states remediation is Adobe's ColdFusion update (2018 Update 17, 2021 Update 7, 2023.0.0.1) plus the follow-up fix that completed the incomplete initial patch, so the SLA has to carry through the follow-up on every server rather than closing when the first pass is recorded. patch_required_reboot is false, which means there is no host reboot to schedule; it does not mean the fixed code is executing when the installer exits, so completion is measured on the build each running ColdFusion instance reports. And because active exploitation is confirmed and the chained outcome is code execution in the ColdFusion context, an internet-facing server that ran an affected build during the window belongs on the incident path — reviewing what was placed or executed through the administrator endpoints — rather than being closed on the update record.",
+        "evidence": "cisa_kev true with kev_date 2023-07-20; active_exploitation 'confirmed'; CVSS 7.5; RWEP 68; poc_available true; ai_discovered false; patch_available true; patch_required_reboot false; live_patch_available false. live_patch_notes: 'No live-patch mechanism; remediation requires Adobe's ColdFusion update (2018 Update 17, 2021 Update 7, 2023.0.0.1) plus the follow-up fix that completed the incomplete initial patch.' affected_versions: Adobe ColdFusion 2018 <= Update 16, Adobe ColdFusion 2021 <= Update 6, Adobe ColdFusion 2023 <= 2023.0.0.330468. active_exploitation_notes: added to KEV 2023-07-20 amid active exploitation; attackers chained it with CVE-2023-29300 to achieve unauthenticated RCE on internet-facing ColdFusion within days of Adobe's July 2023 patch. The packet's AU-Essential-8-Patch gap states the two-week patch SLA for internet-facing applications was too slow because the preauth bypass was chained to RCE and exploited within days of the 2023-07-20 KEV date; its NIS2-Art21-patch-management gap states a monthly cadence leaves internet-facing ColdFusion exposed during the days-long window between the July 2023 disclosure and the emergency patching active exploitation demanded.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-38205": {
     "name": "Adobe ColdFusion Improper Access Control Vulnerability (CVE-2023-38205)",
@@ -55506,7 +57514,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management presumes tracking and applying vendor fixes closes exposure, but the superseded fix left the admin endpoints reachable; the control needed to recognize the patch-bypass relationship to CVE-2023-29298 and re-remediate before near-immediate exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This Adobe ColdFusion flaw is the second CVE on one primitive and the packet states the relation outright: CVE-2023-38205 is recorded as a bypass of the CVE-2023-29298 fix, reinstating unauthenticated reach to the ColdFusion administrator's CFM and CFC endpoints. For this product the control means a ColdFusion server that already took the earlier update is not carried forward as remediated — the earlier ticket's evidence proves nothing about this CVE — and that a second bypass of the same access-control check is ranked on the expectation that a third is likely, rather than as a discrete 7.5-rated item. Scope the sweep from the packet's affected list, not from the headline product name: three separate release trains are named (ColdFusion 2018 Update 18 and earlier, 2021 Update 8 and earlier, 2023 Update 2 and earlier), each with its own fixed update recorded in the packet as 2018u19, 2021u9 and 2023u3 or later in APSB23-47, so an estate that updates only its ColdFusion 2023 servers leaves the 2018 and 2021 installs fully exposed behind a remediation report that reads clean. Measure completion on the build the running service is executing: the packet records no live-patch mechanism and requires a restart of the ColdFusion service after the upgrade, so a server whose files were replaced but whose service was never restarted is still running the pre-fix code — patch_required_reboot being false means no host reboot is needed, not that the fix is live. The clock is the KEV listing of 2023-07-20 against a 2023-08-10 due date, and the packet records exploitation within days of disclosure against internet-facing servers, so the re-remediation runs ahead of that due date rather than to it. Finally, keep the second half of the chain in scope: the packet's exploitation path reaches code execution by combining admin-endpoint reach with deserialization primitives, and the packet records Adobe recommending the associated lockdown and serial-filter guidance alongside the update — the update closes the access-control bypass, that guidance constrains what the bypass was being chained into.",
+        "evidence": "Packet facts only: CWE-284; cisa_kev true with kev_date 2023-07-20 and a 2023-08-10 due date; active_exploitation confirmed; poc_available true; RWEP 68 / CVSS 7.5; active_exploitation_notes 'Actively exploited within days of disclosure in July 2023 as the access-control bypass that reinstated attacker reach to admin endpoints after the incomplete CVE-2023-29298 fix; EPSS sits at ~0.998'; affected_versions 'ColdFusion 2018 Update 18 and earlier', 'ColdFusion 2021 Update 8 and earlier', 'ColdFusion 2023 Update 2 and earlier'; patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation requires upgrading to the fixed ColdFusion builds in APSB23-47 (2018u19, 2021u9, 2023u3 or later) and restarting the ColdFusion service. Adobe also recommends applying the associated lockdown/serial-filter guidance.'; attack_vector 'combined with deserialization primitives this yields remote code execution on internet-facing servers'; the SI-2, ISO A.8.8, NIS2 patch-management and Essential Eight gap statements, each of which names the incomplete-fix relationship to CVE-2023-29298.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The ColdFusion administrator access-control check is where the product decides whether a caller may reach administrative functionality, and this CVE is that check failing open: the packet places the defect in the ColdFusion administrator interface as an improper access control (CWE-284) and has an unauthenticated caller reaching administrative CFM and CFC endpoints through a crafted request, with the vector stating that exploitation does not require user interaction. Bound to this product the control means each administrative CFM and CFC endpoint makes its own authorization decision rather than inheriting a verdict from the check that fronts it, and the ColdFusion Administrator surface is segmented so a caller on an untrusted network cannot present a request to that check at all — the packet records exploitation against internet-facing ColdFusion servers, which is precisely the deployment where the front check is the only thing in the path. Distinguishing test: from an external address and from an internal segment with no operational need for the ColdFusion Administrator, issue unauthenticated requests to administrative CFM and CFC endpoints on a staging server and confirm each is refused before the endpoint runs; a system-security attestation recording that 'administrator access is restricted' passes cleanly while this path stays open, because the restriction being attested to is the check the CVE bypasses. Precondition, stated rather than assumed: the endpoint-side authorization is a property the APSB23-47 update establishes — this control says what to verify, it does not implement it. Until that update and the ColdFusion service restart the packet requires have both landed, restricting which networks can reach the Administrator bounds who can send the crafted request but leaves the bypass fully usable from inside any permitted segment, and it is not available at all where the Administrator has to stay reachable for operations. And because exploitation is confirmed and a public PoC exists, a server that was internet-reachable during the window is a triage item rather than a patch item: the packet's path continues from admin-endpoint reach into code execution via deserialization primitives, so the update removes the reach without removing anything an attacker already placed.",
+        "evidence": "Packet facts only: CWE-284; affected 'Adobe ColdFusion administrator interface, where an improper access-control check allows unauthenticated reach to administrative CFM and CFC endpoints (a bypass of the CVE-2023-29298 fix)'; vector 'An attacker could leverage this vulnerability to access the administration CFM and CFC endpoints. Exploitation of this issue does not require user interaction.'; attack_vector 'A crafted request bypasses the ColdFusion administrator access-control check, letting an unauthenticated attacker reach admin CFM/CFC endpoints; combined with deserialization primitives this yields remote code execution on internet-facing servers.'; active_exploitation confirmed, poc_available true, cisa_kev true (2023-07-20); the UK-CAF-B4 gap statement 'hardening of the ColdFusion administrator surface is undermined because the access-control filter itself is bypassable; restricting admin functionality does not stop unauthenticated reach to CFM/CFC endpoints until APSB23-47 is applied'; live_patch_notes recording the APSB23-47 builds and the required ColdFusion service restart.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-36884": {
     "name": "Microsoft Windows Search Remote Code Execution Vulnerability",
@@ -57336,7 +59367,38 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management should have flagged the Roundcube advisory, but organisations running webmail as a secondary service frequently omit it from the asset/patch register, so CVE-2021-44026 stayed open on exactly the mail servers APT28 targeted."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "The packet puts the defect exactly where this control requires verification: crafted values submitted in Roundcube's mail search and search_params are concatenated into a SQL query without proper escaping. The property to establish is therefore at the layer that builds the search query — the search terms bound as parameters rather than interpolated into the statement — and it must be established by reading that layer's behaviour, not inferred from an input filter in front of it or from a WAF on the webmail host. That substitution is the specific failure the CAF B4 citation on this entry describes: securely configuring the host, its TLS and its service accounts leaves the injection reachable, because the malformed value is carried inside a request the application is supposed to accept. Remediation per the packet is upgrading Roundcube Webmail to 1.3.17 or 1.4.12 or later, and the packet records this as an application update with no host reboot required — so on this entry the reason a KEV item usually slips its window, a reboot that has to be scheduled against a mail outage, does not apply. Distinguishing test, run against the version actually in service rather than the version on the asset register: submit a search request whose search / search_params values carry SQL metacharacters to a staging instance and confirm the query layer binds them as values instead of concatenating them into the statement. An instance sitting behind a rule that blocks the obvious payload shapes still concatenates, and the next encoding the rule does not match reaches the same sink. Preconditions: parameterization is a property of the shipped code, so the upgrade is what establishes it — this control is the verification and the gate, and it gives nothing on its own to an instance that has not been upgraded. A WAF rule on the search endpoint is a holding measure bounded to the request shapes it recognizes and to traffic that traverses it, and it does nothing for a request reaching the application by another route. Neither the upgrade nor the rule undoes a read that already happened: the packet has the injection reading the webmail database including mail, contacts and credentials, and those credentials stay valid on every service they were reused against until they are rotated.",
+        "evidence": "Packet attack_vector: 'An attacker submits crafted values in Roundcube's mail search / search_params, which are concatenated into a SQL query without proper escaping, allowing injection that reads or manipulates the webmail database (mail, contacts, credentials).' CWE-89; CVSS 9.8; RWEP 66; poc_available true; active_exploitation confirmed; CISA KEV 2023-06-22. Packet live_patch_notes: 'No live-patch mechanism; remediation is upgrading Roundcube Webmail to 1.3.17 or 1.4.12 (or later), an application update with no host reboot required.' The repo lesson entry's framework_coverage for UK-CAF-B4 records that 'CAF B4 secure-configuration would not stop a code-level SQLi in Roundcube's search: the injection is in the application's query construction, so hardening the host or TLS does nothing against the malformed _search/search_params input.'",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "The requirement this control carries is webmail request-level telemetry rather than authentication telemetry, and Roundcube's search flow is where it has to be applied for this CVE. The packet's exploitation is a crafted search request: the attacker's content sits in the search / search_params values of a request the webmail application is built to serve, so nothing appears in the authentication record — no failed login, no privilege change, no new session anomaly — and the lesson records that the campaign reached the search flow through legitimate sessions. What must be forwarded off the webmail host, to a collector the webmail service cannot write to, is the per-request web-tier access record including the search parameter values, together with query-level logging from the Roundcube database, retained long enough to cover the interval between exposure and discovery rather than the days a default web-server log rotation keeps. Detection keys on what the packet documents and nothing else: search requests whose parameter values carry SQL syntax, and queries against the mail store whose scope exceeds the requesting session's own mailbox. Both halves matter — SQL-shaped text in a search box can be a user typing a quotation mark, and a broad query can be a maintenance job; it is the pairing inside one session that distinguishes the exploit. Note what will not see it: no file is written, no process is spawned, no authentication fails, and a successful injection returns an ordinary response — so file-integrity monitoring, endpoint anti-malware and failed-login alerting have no artifact to match, and a rule keyed on server errors would miss a read that succeeds. This closes the incident-handling gap directly, because the notification clock starts at awareness and a quiet database read produces no awareness at all. Preconditions: the telemetry has to be collected and shipped off-host before the attempt — a query written afterwards against logs nobody retained produces nothing, and self-hosted webmail is exactly where request-level logging is least often exported. And this detects; it does not prevent. Mail and contacts read during the window stay read, and credentials the packet places in that database stay usable until they are rotated.",
+        "evidence": "Packet attack_vector: the attacker 'submits crafted values in Roundcube's mail search / search_params', and the injection 'reads or manipulates the webmail database (mail, contacts, credentials)'. CISA KEV 2023-06-22; active_exploitation confirmed; poc_available true. The repo lesson entry records privileges_required as 'none per CVSS scoring (PR:N)' while noting the operators reached the search flow through spearphishing-driven sessions; its defense_chain detection section names 'Query-level logging/alerting on the Roundcube database and web-tier detection of SQL fragments in _search/search_params' as what would have worked, with the adequacy note that 'Detection is what most ... victims lacked, letting the espionage read go unnoticed', and its framework_coverage for NIS2-Art21-incident-handling records that 'a successful SQLi read of the Roundcube mail store is quiet exfiltration; without query-level logging on the webmail DB ... leaves little trace to trigger the incident process.'",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the KEV clock is both the cheapest control to satisfy and the one the estate most often fails, and the packet says why in its own remediation note. The fix is an application upgrade to 1.3.17 or 1.4.12 or later with no host reboot required, so the mitigation this control demands within the KEV window is an in-place application update on an internet-facing service — not a firmware cycle, not a maintenance window negotiated against a mail outage. That removes the usual justification for a 30-day interpretation of 'appropriate timescales', which is the undefined interval the ISO A.8.8 citation on this entry rests on, and it is why a 4-hour-class response is realistic here rather than aspirational. The Essential Eight patch citation fails for a different reason worth stating separately: Roundcube is an application running on the host, frequently maintained outside whatever pipeline pushes operating-system updates, so an attestation that measures OS patch level reads clean on a host whose webmail has been years behind since the fix shipped. Verified mitigation means the version read from the running instance is at or above 1.3.17 on the 1.3 branch or 1.4.12 on the 1.4 branch, or a later release — read from the instance, not from an inventory record, because the register omission is the documented failure mode for this class of asset. Precondition: reaching the minimum build named in the packet closes this defect only and says nothing about anything found in Roundcube since, so the requirement is a current supported release rather than the floor, and a site that was exposed while unpatched still needs its stored mail credentials rotated — the clock governs how fast the injection path closes, not what was read through it.",
+        "evidence": "Packet: CISA KEV listing 2023-06-22; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 66; patch_available true; live_patch_available false. Packet live_patch_notes: 'No live-patch mechanism; remediation is upgrading Roundcube Webmail to 1.3.17 or 1.4.12 (or later), an application update with no host reboot required.' The repo lesson entry's framework_coverage records for ISO-27001-2022-A.8.8 that 'organisations running webmail as a secondary service frequently omit it from the asset/patch register', and for AU-Essential-8-Patch that 'Essential 8 patch cadence targets vendor-supplied fixes, but internet-facing webmail is often community-maintained and slips patch windows'; its defense_chain prevention adequacy note records that 'the recurring failure was operational — webmail left off the patch inventory.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2016-9079": {
     "name": "Mozilla Firefox, Firefox ESR, and Thunderbird Use-After-Free Vulnerability",
@@ -57616,7 +59678,21 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management scores by CVSS/priority, but an 8.8 rating understates a confirmed zero-day under active exploitation; teams deprioritising 'High (not Critical)' browser CVEs left the type-confusion exploitable while it was already being used."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The exploitation path here is a crafted HTML/JavaScript page — no install, no attachment, no privilege — so every managed workstation is exposed the moment a user browses, and the only variable an operator controls is which build the browser process is executing. Bound to this CVE, the control means the enterprise update ring carries Chrome to 114.0.5735.110 on Windows and 114.0.5735.106 on macOS/Linux without sitting in a pilot or staging tier: the packet records patch_available true but live_patch_available false, so there is no interim protected state and no vendor mitigation rule to run while a ring soaks — a machine is either on the fixed build or fully exposed to the page.\n\nThe second half is where this remediation is routinely recorded as complete while the estate stays exposed, and the packet states it outright: remediation is the auto-update 'followed by a browser restart to load the patched build'. The update lands on disk without the running process taking it, so a software inventory that reads the installed version reports the fixed build while every already-running browser keeps executing the vulnerable V8. The machines this misses are precisely the worst ones — the long-lived sessions that are never closed and never rebooted. Completion must therefore be measured on the build the live browser process reports, and the relaunch has to be forced by policy rather than left to a dismissible prompt.\n\nDistinguishing test: on a workstation that has been running since before the update, read the version the live browser process reports rather than the version on disk, and confirm it is at or above the fixed build. A fleet whose software inventory shows 114.0.5735.110 everywhere while running processes report a pre-fix build satisfies a patch-cadence attestation and still executes the crafted page.\n\nScope: the packet ties the type confusion to V8 in Chrome/Chromium and names no other product, so this covers the Chrome and Chromium installs in the estate. Extending it to other browsers or to embedded renderers would manufacture removal and update work against software no evidence in this packet implicates.\n\nWhat it does not do: forcing the relaunch closes this defect only. It does not reduce the renderer attack surface the page reaches, and the packet describes the heap corruption as being chained with a renderer sandbox escape — so a workstation that browsed untrusted content while below the fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet facts only. CISA KEV-listed 2023-06-07; active_exploitation 'confirmed'; poc_available true; CVSS 8.8; RWEP 66; ai_discovered false. Vector: 'Type confusion in V8 in Google Chrome prior to 114.0.5735.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)'. Attack vector: 'A crafted HTML/JavaScript page forces V8 to misinterpret an object's type, corrupting the heap into read/write primitives that, chained with a renderer sandbox escape, yield code execution.' patch_available true; live_patch_available false; live_patch_notes: 'No live-patch mechanism; remediation is Chrome/Chromium auto-update to 114.0.5735.110 (Windows) or 114.0.5735.106 (macOS/Linux) followed by a browser restart to load the patched build.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-33009": {
     "name": "Zyxel Multiple Firewalls Buffer Overflow Vulnerability (CVE-2023-33009)",
@@ -57872,7 +59948,32 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management prioritizes by score, but the EPSS ~0.999 preauth SQLi with confirmed ransomware use and supply-chain reach means only removing internet exposure of MOVEit before the fix could have helped; risk-rated scheduling was too slow for a zero-day mass-exploitation event."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The MOVEit Transfer web application answers unauthenticated callers over HTTP or HTTPS, and the packet's exploitation path does not stop at the SQL injection: the attacker writes the LEMURLOOT web shell (human2.aspx) into the application and uses it to enumerate and exfiltrate the files the transfer server holds together with its Azure storage keys. Bound to this product, the control means an instance that was network-reachable during the exploitation window is handled as a compromised host rather than as a patch ticket — hunt the web root for human2.aspx and any other file written through the injection, rebuild from a known-good baseline where one is found, and rotate everything the instance held or brokered: the Azure storage keys the packet names, the credentials the web application uses against its MySQL, Microsoft SQL Server or Azure SQL back end, and the accounts of counterparties whose files it stored. The packet's own remediation note states both halves in order — upgrade to a fixed release, hunt for the LEMURLOOT web shell, then restart the service — and it is the second half the cited flaw-remediation and technical-vulnerability-management controls do not carry: each of them closes when the installed version reaches the fixed build, so a server reporting a fixed release while human2.aspx still answers passes those attestations with the attacker's access intact. Distinguishing test: for each MOVEit Transfer instance produce the web-root file listing and its change history covering the exposure window and show no unaccounted .aspx file was written, instead of producing the upgrade record. Precondition, and this is where the control is usually over-claimed: it is a response requirement and removes nothing preventively — it does not close the injection, and it applies only to instances exposed before the fixed release landed. The packet places exploitation in May and June 2023, so an instance first stood up on a fixed release and never reachable before it is a patch case, not an incident case; conversely, an instance that took the upgrade without the hunt has not been cleared, because the fix removes the write path and not what was already written through it.",
+        "evidence": "Packet: an unauthenticated attacker sends crafted requests to the MOVEit Transfer web app to trigger SQL injection, then writes the LEMURLOOT (human2.aspx) web shell to enumerate and exfiltrate stored files and Azure storage keys; exploitation of unpatched systems can occur via HTTP or HTTPS; exploited in the wild in May and June 2023; depending on the database engine (MySQL, Microsoft SQL Server, or Azure SQL) an attacker may execute SQL statements that alter or delete database elements. cisa_kev true, kev_date 2023-06-02, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 76. patch_available true; live_patch_available false with live_patch_notes: no vendor live-patch mechanism, remediation requires upgrading MOVEit Transfer to a fixed release (2021.0.6 / 2021.1.4 / 2022.0.4 / 2022.1.5 / 2023.0.1 or later) and hunting for the LEMURLOOT web shell, then restarting the service.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "The defect the packet describes is SQL injection in the MOVEit Transfer web application reachable by an unauthenticated caller, with impact varying by the database engine behind it — the packet names MySQL, Microsoft SQL Server and Azure SQL — and extending past inference of structure and contents to executing SQL statements that alter or delete database elements. For a product the operator does not build, this control's requirement lands on what is accepted as evidence that the injection is closed: the parameterization must hold inside the shipped query layer, not in a filter placed in front of it. A WAF or request-inspection rule at the MOVEit boundary is therefore not a remediation state for this CVE and must not be recorded as one; the only state that closes it is the instance running one of the fixed releases the packet names — 2021.0.6, 2021.1.4, 2022.0.4, 2022.1.5 or 2023.0.1 or later — with the service restart the packet's remediation note requires, so an instance upgraded but not restarted is not yet remediated. Scope this to MOVEit Transfer, which is the product the packet names. The packet also states that all versions before those five are affected including older unsupported versions, naming 2020.0 and 2019x, so an instance on a branch with no fixed release in that list cannot reach a fixed build in place and has to be moved onto a supported branch — a migration decision that a patch ticket keyed to 'latest available for the installed branch' will never surface, and one that the cited flaw-remediation and system-security controls do not distinguish from routine patching. Precondition: reaching a fixed release closes this injection and says nothing about anything found in the product since, and it does not undo a database that was already read or altered through the injection during the exposure window — that remains an incident-response question, not a version question.",
+        "evidence": "Packet: a SQL injection vulnerability in the MOVEit Transfer web application could allow an unauthenticated attacker to gain access to MOVEit Transfer's database; depending on the database engine being used (MySQL, Microsoft SQL Server, or Azure SQL), an attacker may be able to infer information about the structure and contents of the database and execute SQL statements that alter or delete database elements; all versions before 2021.0.6, 2021.1.4, 2022.0.4, 2022.1.5 and 2023.0.1 are affected, including older unsupported versions (e.g. 2020.0 and 2019x); exploitation can occur via HTTP or HTTPS. patch_available true; live_patch_available false with live_patch_notes recording remediation as upgrading to a fixed release then restarting the service. CVSS 9.8, RWEP 76, poc_available true, active_exploitation confirmed, KEV-listed 2023-06-02.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-28771": {
     "name": "Zyxel Multiple Firewalls OS Command Injection Vulnerability",
@@ -59713,7 +61814,21 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management ranking by CVSS treats 8.8 as High-not-Critical, understating a zero-day with a public exploit; deprioritising it left the type confusion open while it was actively used."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet records no live-patch mechanism for this flaw and states the remediation exactly: Chrome/Chromium auto-update to 112.0.5615.121 or later, followed by a browser restart to load the patched build. That places the whole residual exposure in the gap between the update arriving on disk and the user relaunching the browser, which is why this control has to bind both halves for this CVE. On a managed estate it means the security update channel is not deferred by the update ring at all for a KEV-listed renderer defect, and the relaunch is forced by policy rather than left to the user's convenience — the delivery path here is an ordinary page visit (the packet's path is a crafted JavaScript page passing a JSGlobalProxy to Error.captureStackTrace, confusing V8's object typing and corrupting the heap into read/write primitives usable for renderer code execution), and the browser session least likely to be restarted, an instance left open for weeks, is exactly the one most likely to meet such a page. Completion must be measured on the version V8 is actually executing, not the version deployed: a host whose management record shows 112.0.5615.121 while the running browser has never been relaunched is still executing the pre-fix renderer, and every framework control citing this CVE closes on the deployed version. Distinguishing test: collect the running browser's version from managed hosts and confirm it is at or above 112.0.5615.121 — an estate reporting package-level compliance while long-lived sessions keep the old build resident is exposed to a defect the packet records as KEV-listed since 2023-04-17, with a public exploit and confirmed in-the-wild use. Precondition: forcing the relaunch bounds the window, it does not undo a visit that already happened; a host that rendered untrusted web content while below the fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet: type confusion in V8 in Google Chrome prior to 112.0.5615.121 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page; a crafted JavaScript page passes a JSGlobalProxy to Error.captureStackTrace, confusing V8's object typing and corrupting the heap into read/write primitives usable for renderer code execution. cisa_kev true, kev_date 2023-04-17, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 66. patch_available true; live_patch_available false with live_patch_notes: no live-patch mechanism, remediation is Chrome/Chromium auto-update to 112.0.5615.121 or later followed by a browser restart to load the patched build.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-20963": {
     "name": "Android Framework Privilege Escalation Vulnerability (CVE-2023-20963)",
@@ -61026,7 +63141,31 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management could not remediate a driver whose fix was withheld by the device supply chain; the kernel write primitive persisted on inventoried mobile assets despite being a known, KEV-listed exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's remediation is an OEM firmware/security update that ships the fixed Mali driver and reboots the device — the operator does not build that update and cannot accelerate it, so the only lever they actually hold is whether a device still carrying an affected driver keeps its access. For this CVE the enforced minimum has to be expressed as the OEM build that carries a Mali kernel driver outside the affected revision ranges (Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, Valhall r19p0 through r35p0), and it must function as an access condition — mail, VPN and document access denied to a device below it — not as a row on a patch-compliance dashboard. Distinguishing test: enrol a device whose Mali driver is still inside an affected range and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition, and this is where the control is usually over-claimed: the packet's path starts with an unprivileged local app, so restricting which applications may be installed raises the bar for getting that app onto the device but does not evict one already installed and does not cover one that arrived through the normal store channel — a device suspected of having run it belongs on the incident path, because the escalation ends at root and the packet records this as the local-escalation stage of a spyware chain. The update also reboots the device, so a device that has downloaded it but not restarted still runs the vulnerable driver and is not remediated.",
+        "evidence": "Packet vector: 'Arm Mali GPU Kernel Driver allows a non-privileged user to achieve write access to read-only memory pages. This affects Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, and Valhall r19p0 through r35p0.' Attack vector: 'An unprivileged local app abuses the Mali GPU kernel driver to obtain host-writable mappings of read-only imported pages, corrupting kernel memory to escalate privileges to root (used as the local-escalation stage of a spyware chain).' CISA KEV listed 2023-03-30; active_exploitation confirmed; poc_available true; CVSS 7.8; RWEP 72. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch mechanism for the Mali GPU kernel driver on affected devices; remediation requires the OEM firmware/security update that ships the fixed driver, which reboots the device.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet scopes this vulnerability by Mali kernel driver revision — Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, Valhall r19p0 through r35p0 — and not by an OS version or a reported patch-level string, while the fixed driver arrives inside an OEM firmware/security update rather than as a package the operator installs. So a fleet report that reads a device's OS build or patch-level date and marks it compliant has tested nothing about this CVE: the driver revision is chosen by the OEM's build, so two devices reporting the same patch level from different vendors can ship different Mali revisions, and one of them can still be inside an affected range. The operational test is to read the Mali driver revision actually loaded on a representative device of each OEM and model in the estate, check it against the three affected ranges, and re-run that check after every OEM update — because the update that moves the patch-level string is not necessarily the one that moves the driver, and that mismatch is exactly what a version-only scan cannot see. Precondition: this establishes exposure or its absence, it does not remediate. The packet records no live-patch mechanism, so a device found inside an affected range stays exposed until the OEM update lands and the device reboots, and a device the check clears today can regress if a later OEM build ships a driver revision back inside the range.",
+        "evidence": "Packet vector names the affected component by driver revision: 'This affects Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, and Valhall r19p0 through r35p0.' live_patch_available false with live_patch_notes: 'No live-patch mechanism for the Mali GPU kernel driver on affected devices; remediation requires the OEM firmware/security update that ships the fixed driver, which reboots the device.' CISA KEV listed 2023-03-30; active_exploitation confirmed; poc_available true; CVSS 7.8; RWEP 72; patch_available true. Citing gaps on this entry include ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) and UK CAF B4 (System security).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-26360": {
     "name": "Adobe ColdFusion Deserialization of Untrusted Data Vulnerability (CVE-2023-26360)",