@blamejs/exceptd-skills 0.19.13 → 0.19.15

package/data/zeroday-lessons.json

@@ -16257,7 +16257,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "FreePBX Endpoint Manager is the control-panel module this control governs, and the packet's vector is the forbidden pattern in a single line: a testconnection feature in the administration UI reaches check_ssh_connect(), which composes an OS command from caller-supplied input (CWE-78), so a form field on a user-facing surface is the only thing standing between a panel operator and command execution on the telephony server as the asterisk user. Applied to this product, the requirement is that the connection-test path pass its parameters to the SSH invocation as arguments rather than as a shell string, and that any privileged operation the module needs sit behind its own validated interface, so the module's own input handling is not the single boundary. The stake is not reduced by the outcome being the asterisk account rather than root: asterisk is the service identity the PBX runs as, so the packet's stated outcome — remote access to the system as an asterisk user — is control of the telephony service and everything it holds, not a low-privilege shell. Distinguishing test: on a staging FreePBX, submit an Endpoint Manager connection test whose host or credential field carries shell metacharacters and confirm no subcommand executes — a patch attestation taken against the FreePBX core that never enumerates installed modules reads clean while an unpatched Endpoint Manager keeps the sink. Precondition, and this is where the control is most likely to be over-claimed on this entry: the packet's detailed vector requires an authenticated known user, but the packet's own summary of the same flaw describes unauthenticated remote command execution, so restricting who holds a FreePBX administrative account bounds the population that can reach testconnection only if the authenticated precondition is the true one — it does nothing if the summary is. Constrain the module's reachability rather than the account list until the vendor update lands, and note that this control states the property the vendor fix must establish; it does not implement it.",
+        "evidence": "Packet: CWE-78, CVSS 9.8, RWEP 77, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2026-02-03. Vector: 'Sangoma FreePBX Endpoint Manager contains an OS command injection vulnerability that could allow for a post-authentication command injection by an authenticated known user via the testconnection -> check_ssh_connect() function. An attacker can leverage this vulnerability to potentially obtain remote access to the system as an asterisk user.' The packet's attack_vector field summarises the same entry as 'an OS command-injection flaw (CWE-78) enabling unauthenticated remote command execution on the telephony server' — the two disagree on whether authentication is required, and this description does not resolve that disagreement in the operator's favour. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On a PBX the usual patch-window argument inverts. The packet records patch_available true, live_patch_available false, and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction — and a service restart on a production telephony server drops every call in progress, which is the specific reason this remediation gets marked done when the module update is installed rather than when the service comes back. Per the packet's own live_patch_notes, a host that has taken the update without the restart is still running the vulnerable code, so 'updated' and 'remediated' are different states here and only the second one counts. Applied to this entry, the clock starts at the 2026-02-03 KEV listing, the maintenance window is scheduled as part of the response rather than deferred into the next telephony change window, and completion is measured per host by the Endpoint Manager version actually loaded after restart rather than by an 'update applied' flag in a console. The compensating-control branch covers the interval: restrict which network segments can reach the FreePBX administration interface at all, since with a public PoC and confirmed exploitation the reachability of that interface is the remaining precondition an operator can act on. State its limits plainly — that bounds who can send the request, it does not close the injection, and it is unavailable wherever the administration interface must stay reachable for normal operation. It also does nothing for a host already reached: the packet marks exploitation confirmed, and an attacker who obtained the asterisk service identity survives the module update, so a server that was reachable during the exposure window needs its stored telephony credentials treated as disclosed and rotated rather than closed out on the patch.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-02-03, active_exploitation 'confirmed', poc_available true, CVSS 9.8, RWEP 77, ai_discovered false. 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.' Vector states the outcome as an attacker potentially obtaining 'remote access to the system as an asterisk user' via the Endpoint Manager testconnection -> check_ssh_connect() function.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-19006": {
     "name": " Sangoma FreePBX Improper Authentication Vulnerability",
@@ -16317,7 +16341,31 @@
     },
     "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": "FreePBX's password check is where the product makes its access decision, and this CVE is that decision failing open: the packet describes unauthorized users bypassing password authentication and reaching the services provided by the FreePBX admin, ending in administrative access to the telephony server for an attacker who never held an account. Bound to this product, the control means each administrative function on the FreePBX server authorizes its caller itself rather than inheriting a verdict from the authentication layer that fronts it, and the administrative surface is segmented so an untrusted caller cannot present a request to that layer at all — the FreePBX admin interface answers only from an operator or management segment, or an authenticated VPN, and never from the internet or a general user or voice VLAN. The identity and least-privilege gaps recorded on this entry do not touch this path: because no password is presented, no password policy, lockout threshold or second factor on any operator account is ever exercised, per-account privilege scoping is never consulted, and the account model an identity attestation examines is bypassed rather than abused. Distinguishing test: from a segment with no operational need for telephony administration, issue unauthenticated requests to each administrative function on a staging FreePBX instance and confirm each refuses the caller before the function runs — an attestation that every FreePBX administrator holds a unique account with a strong password passes cleanly while this path stays fully open. Precondition: the per-function authorization property is what the vendor update establishes; this control states what to verify and what to restrict, it does not implement the fix. Restricting reachability bounds who can attempt the bypass but leaves it fully available to anything inside the permitted segment, and it is not available at all where the admin surface must stay reachable for remote administration — those instances depend on the update and its required service restart. And because active exploitation is confirmed, an instance whose admin surface was reachable during the exposure window needs its administrative accounts and the configuration reachable from that surface reviewed, and its credentials rotated; the update does not undo changes an attacker made while holding admin access.",
+        "evidence": "Packet records CWE-287 improper authentication. The vector states Sangoma FreePBX 'contains an improper authentication vulnerability that potentially allows unauthorized users to bypass password authentication and access services provided by the FreePBX admin', and the attack-vector line records an unauthenticated attacker gaining administrative access to the telephony server. CVSS 9.1, RWEP 77, poc_available true, active_exploitation confirmed, CISA KEV-listed 2026-02-03. patch_available true, live_patch_available false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot. Citing gaps include UK-CAF-B2 (identity and access control), NIST-800-53-AC-6 (least privilege) and NIS2-Art21-network-security — the first two are cited precisely because no account is authenticated anywhere on this path.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the control means the FreePBX fix is driven across every instance on the clock that opened with the 2026-02-03 KEV listing rather than deferred to the next telephony maintenance window, with completion measured per instance by the installed version against the vendor's fixed version and by the required restart having been taken — not by an update having been downloaded or scheduled. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot, so an instance that has taken the update but not restarted still runs the vulnerable code and must be counted as exposed; on a PBX that restart is also the step most likely to be deferred, because taking it interrupts calls in progress, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Priority follows the packet rather than the CVSS band: a public PoC plus confirmed exploitation against a pre-authentication administrative bypass on a telephony server means the routine cadence a PBX usually sits on is the wrong tier. The packet also pairs a 2019 CVE identifier with a 2026-02-03 KEV listing, which makes discovery the first task rather than the last — the exposed population is instances nobody is currently patching, so enumerate FreePBX servers that no software inventory tracks (branch sites, lab and test instances, vendor- or contractor-managed deployments) before measuring compliance against the ones already in the console. Precondition: the SLA governs the clock and provides no interim mitigation; until the restart completes, restricting which segments can reach the administrative surface is the only operator-side lever, and it is unavailable where that surface must stay reachable for remote administration.",
+        "evidence": "Packet records patch_available true, live_patch_available false, and 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-listed 2026-02-03, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 9.1. The CVE identifier year (2019) and the KEV listing date (2026-02-03) are both packet fields; the discovery-first ordering is the inference drawn from that pairing, not a claim the packet makes. Citing gaps AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are the patch-cadence controls this listing outruns.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-40551": {
     "name": "SolarWinds Web Help Desk Deserialization of Untrusted Data Vulnerability (variant: CVE-2025-40551)",
@@ -17739,7 +17787,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation here requires a victim to open an attacker-supplied presentation: the packet's vector is a PowerPoint file whose OutlineTextRefAtom carries an invalid index value, triggering memory corruption and code execution inside the PowerPoint process at the user's own privilege. On the unpatched long-tail installs the packet says the re-listing exists for, the delivery path is the only enforceable control. Require Mark-of-the-Web on every presentation arriving by mail, web download, or untrusted file share, and require MOTW-tagged presentations to open in Protected View — an isolated, reduced-privilege render — rather than the full parsing path that reaches the vulnerable record handling. Provenance has to survive the container: a presentation extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced presentations must be blocked by policy rather than left to the user, because parsing the file is the whole exploit. Distinguishing test: mail a presentation nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — an application-hardening attestation covering only macro and ActiveX/OLE settings passes cleanly while a provenance-stripped presentation reaches the parser with full user privileges. Preconditions: Protected View bounds the render, it does not repair the parser. A user who clicks through to editing, or a file arriving on an ingress path that never applies the tag, is back on the vulnerable path with nothing in between — so the tagging must be enforced at each ingress rather than assumed. This is a holding measure for hosts that have not yet taken the vendor fix, not a substitute for it.",
+        "evidence": "Packet vector: a PowerPoint file with an OutlineTextRefAtom containing an invalid index value that triggers memory corruption, allowing remote attackers to execute arbitrary code; the packet's attack_vector places execution in the PowerPoint process. CWE-94. CISA KEV-listed 2026-01-07 with confirmed active exploitation; poc_available true; CVSS 9.8; RWEP 77. Citing gaps include AU-Essential-8-App-Hardening (User application hardening) and NIST-800-53-AC-6 (Least Privilege).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The vendor fix for this defect is not new; what the 2026-01-07 KEV listing changes is that the installs which never took it are now on a KEV clock. The packet states the reason for the re-listing outright — long-tail unpatched estates remain exposed — so for this CVE the control is not 'apply the update' but 'enumerate what never received it'. Run the clock from the listing against a census of every PowerPoint install actually in service, and measure completion by the build each install reports rather than by a 'no updates pending' state in a management console: the hosts that keep a defect of this vintage reachable are precisely the hosts that fell out of the managed update path, so the console's silence is an absence of visibility rather than evidence of remediation. The packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot, so an install updated but not restarted is still exposed. Distinguishing test: pull the reported PowerPoint build from every host carrying the product — including machines restored from backup images and rebuilt from older media, which is where a pre-fix build silently returns — and confirm none is pre-fix; a patch-management attestation scoped to the currently supported Office channel reports clean while the long-tail installs the packet names stay exploitable. Precondition: this closes the exposure only where the inventory can see the install. A copy no console enumerates is remediated by removing it or bringing it under management, never by recording it as compliant.",
+        "evidence": "patch_available true; live_patch_available false, with the packet noting no live-patch tool registered and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. CISA KEV-listed 2026-01-07 with confirmed active exploitation; poc_available true; CVSS 9.8; RWEP 77. The packet's attack_vector states the legacy re-listing exists because long-tail unpatched estates remain exposed. Citing gaps include NIST-800-53-SI-2 (Flaw Remediation), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-patch-management (Vulnerability handling and disclosure).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-37164": {
     "name": "Hewlett Packard Enterprise (HPE) OneView Code Injection Vulnerability",
@@ -17799,7 +17870,40 @@
     },
     "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": "HPE OneView is the management plane for the server infrastructure it administers, and the packet places the defect on a path a remote unauthenticated user can reach: code injection (CWE-94) ending in remote code execution on the appliance itself. Bound to this product, the control means every endpoint the OneView appliance exposes authorizes its caller before the request reaches anything that evaluates content, and that caller-supplied content is neutralized rather than passed into an interpreter — and that no OneView instance is left answering from a segment with no operational need to manage infrastructure. This is also why the least-privilege gap cited on this entry does not close the path: the attacker never holds a OneView operator account, so per-account privilege scoping is never consulted and an access-review attestation passes cleanly while the injection path stays open. Distinguishing test: from a segment with no operational need to reach the management plane, send unauthenticated requests to each endpoint on a staging OneView appliance and confirm each is refused before any supplied content is evaluated. Precondition: the endpoint-side authorization and input neutralization are properties the vendor update establishes — this control states what to verify, it does not implement it. Until that update and its restart land, restricting which segments can reach the appliance bounds who can send the request but leaves it fully exploitable from anything inside the permitted segment, and that lever is unavailable for the management network the appliance must keep answering in order to administer the hardware it exists to manage.",
+        "evidence": "Packet: HPE OneView contains a code injection vulnerability (CWE-94) that allows a remote unauthenticated user to perform remote code execution on the infrastructure-management appliance; CVSS 9.8, RWEP 77; poc_available true; CISA KEV-listed 2026-01-07 with active_exploitation confirmed; NIST-800-53-AC-6 (Least Privilege) is one of the framework controls this entry cites as insufficient; patch_available true with live_patch_available false and live_patch_notes recording that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "OneView is a fleet control plane for server infrastructure, and the packet gives a pre-auth RCE with a public PoC and confirmed in-the-wild exploitation — so an appliance that was reachable between the 2026-01-07 KEV listing and its restart has to be triaged as possibly already compromised, because the vendor update closes the injection path and removes nothing an attacker executed, placed or read through it beforehand. For this CVE the playbook means: rotating every credential the appliance holds or brokers for the hardware it manages and every account that authenticated through it during that window; auditing the appliance's configuration and profile changes across the window; and having stated quarantine criteria for managed hardware whose configuration OneView could have altered while under attacker control. Precondition: this is a response control, not a preventive one — it does not lower the chance of exploitation, it bounds what an already-executed compromise retains, and it is only worth running where the exposure window can be established. Since the flaw yields code execution on the appliance, an attacker is above the appliance's own logging, so the window has to be reconstructed from network-side and collector-side records rather than trusted from the appliance's local logs.",
+        "evidence": "Packet: remote unauthenticated code execution (CWE-94) on the HPE OneView infrastructure-management appliance; CISA KEV-listed 2026-01-07 with active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 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 per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "An infrastructure-management appliance is usually inventoried as the tool an estate patches its servers with rather than as an asset carrying its own patch clock, which is exactly how a KEV-listed pre-auth RCE on OneView ends up riding the next infrastructure maintenance window while the operating-system patching attestation reads clean. For this CVE the control means the appliance's own update runs on the KEV clock that opened 2026-01-07, not on the cadence of the fleet updates OneView distributes, with completion measured by the version the appliance is actually running rather than by a staged or downloaded update. The packet records no live-patch path and a fix that typically requires a service restart or system reboot, so an appliance that has taken the update but not restarted still carries the vulnerable code and must be counted as exposed — and on a management appliance that restart is the step most likely to be deferred, because it interrupts the console the estate's operators depend on. Priority follows the packet: unauthenticated remote code execution with a public PoC and confirmed exploitation, on the plane that administers the hardware underneath it.",
+        "evidence": "Packet: CISA KEV-listed 2026-01-07 with active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 77; unauthenticated remote code execution (CWE-94) on the HPE OneView management appliance; patch_available true, live_patch_available false, live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction; the entry cites AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-52163": {
     "name": "Digiever DS-2105 Pro Missing Authorization Vulnerability",
@@ -22979,7 +23083,31 @@
     },
     "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 Android Runtime and describes a use-after-free (recorded under CWE-269) reached by a local app to escalate privileges on the device, with the vector naming a Chrome sandbox escape as the route in. Nothing about the account model is being abused here — the attacker already holds execution inside a sandboxed context and a privilege boundary inside the runtime is what fails — so for this CVE the control means the vendor fix is driven across every managed Android device on the clock that opened with the 2025-09-04 KEV listing, rather than left to whenever each handset next takes an update. Completion has to be measured by the patch level the device itself reports back to the management platform, not by 'update pushed' or 'policy applied' in the console. The packet records a vendor patch with no live-patch path and notes the fix typically requires a service restart or system reboot, so a device that has downloaded and staged the update but has not restarted still runs the vulnerable runtime and must be counted as exposed — on a phone the restart is the step a user defers indefinitely, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Priority follows the packet rather than the 7.8 base score: a public PoC, confirmed in-the-wild exploitation, and the packet's own framing of this as the local-escalation half of a mobile exploit chain make it the step that converts a browser-sandboxed foothold into device-wide compromise, which is why it belongs on a chain-containment clock rather than in the routine mobile-update queue. Precondition: this control only reaches devices whose vendor is still shipping them the fix and whose reported patch level the operator can actually see; a device that cannot reach the fixed level is not remediated by scheduling it, and belongs on a replacement or access-denial path instead.",
+        "evidence": "Packet facts only: cwe_refs CWE-269; vector states Android Runtime contains a use-after-free 'potentially allowing a chrome sandbox escape leading to local privilege escalation'; attack_vector describes exploitation by a local app to escalate privileges and calls it the local-escalation step after an initial-access primitive in a mobile exploit chain, with escalation flaws of this class forming the second half of an intrusion chain; cisa_kev true with kev_date 2025-09-04; active_exploitation confirmed; poc_available true; rwep_score 77 against cvss 7.8; patch_available true; live_patch_available false with live_patch_notes recording no live-patch tool for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "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": "Exploitation as the packet describes it needs attacker code already executing on the handset — a local app, or the Chrome sandbox the vector names — so on this entry the control's access-condition half is the load-bearing one. The fixed Android patch level has to function as a condition of access: a device below it is refused organizational mail, VPN and document access until it takes the fix and completes the restart the packet says the vendor patch requires. The distinguishing test is to enrol a device held below the fixed patch level and confirm the policy actually denies it protected resources; an estate that surfaces the stale patch level on a compliance dashboard while the device keeps its access has recorded the exposure rather than removed it, and the flaw-remediation and technical-vulnerability attestations cited against this entry pass on exactly that kind of reporting. Precondition, and this is where the control is usually over-claimed: restricting which applications may install raises the bar for getting the attacker's local app onto the device, but it does not evict an app already installed, and it does not cover the second delivery path the packet names at all — a Chrome sandbox escape routes through the browser that is already on the device and is driven by rendered web content, so no install decision is ever made and no install policy is ever consulted. A device suspected of having already run the escalation belongs on the incident path, not the install-policy path. This is a holding measure for the window before the fixed runtime and its restart land, not a substitute for them.",
+        "evidence": "Packet facts only: vector states the Android Runtime use-after-free potentially allows a chrome sandbox escape leading to local privilege escalation; attack_vector states exploitation is by a local app escalating privileges on the device; active_exploitation confirmed with poc_available true and kev_date 2025-09-04; patch_available true; live_patch_available false, with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The citing framework gaps recorded on this entry are the patch and technical-vulnerability-management controls (AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2) plus UK-CAF-B4 system security.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-53690": {
     "name": "Sitecore Multiple Products Deserialization of Untrusted Data Vulnerability",
@@ -23695,7 +23823,21 @@
     },
     "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 puts the attacker inside the trust boundary before the flaw is touched: exploitation requires an authenticated user in the same Windows Active Directory domain as the Session Recording server, and the outcome is escalation to the NetworkService account on that server (CWE-269). For this CVE the control means the Citrix Session Recording update is driven across every Session Recording server on the clock that opened with the 2025-08-25 KEV listing rather than folded into the next Citrix maintenance window, with completion measured per server by the code actually running rather than by 'approved' or 'deployed' in a change record. 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 still carries the vulnerable code and must be counted as exposed; on a recording server that restart is the step most likely to be deferred, because taking it interrupts recording of live sessions, and a deferral logged as 'patched' is the specific way this remediation goes wrong. The control's second half is the load-bearing one here: every framework control cited against this entry is a patch-timeline control, and none of them can contain an escalation whose only precondition is holding an ordinary domain account — the attacker is already authenticated, so entitlement review and account-privilege tightening leave the path fully intact while their attestations pass. Enumerate first the Session Recording servers joined to a domain whose ordinary users are not administrators of them, because there the exploit's precondition is the normal operating state rather than an anomaly. Distinguishing test: produce, per server, the running Session Recording build and the service start time, and confirm the start time is later than the update install time — a fleet report showing the fixed package installed on every server, with services still running from before the install, is a fleet that is still exploitable. Precondition: with a public PoC and confirmed in-the-wild exploitation, the update remediates the flaw but establishes nothing about whether it was used first; a server that ordinary domain accounts could reach through the exposure window needs its post-exploitation state examined rather than closed on the patch record.",
+        "evidence": "Packet fields for CVE-2024-8068 (Citrix Session Recording Improper Privilege Management Vulnerability): cwe_refs CWE-269; vector 'Citrix Session Recording contains an improper privilege management vulnerability that could allow for privilege escalation to NetworkService Account access. An attacker must be an authenticated user in the same Windows Active Directory domain as the session recording server domain.'; attack_vector records escalation of an authenticated user's privileges on the recording server. cisa_kev true with kev_date 2025-08-25; active_exploitation confirmed; poc_available true; cvss 7.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: AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIS2-Art21-patch-management (Vulnerability handling and disclosure), 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",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-8069": {
     "name": "Citrix Session Recording Deserialization of Untrusted Data Vulnerability",
@@ -23755,7 +23897,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The Citrix Session Recording server is the deserialization sink here, and the packet's stated access requirement is why a perimeter-shaped defence does nothing for it: the attacker is an authenticated user on the same intranet as the recording server, so the traffic carrying the untrusted serialized object is ordinary internal traffic from an ordinary internal account. Bound to this product, the control means the Session Recording server's listening surface is treated as a trust boundary rather than an internal convenience — it accepts connections only from the hosts that legitimately deliver session-recording traffic and from the administrative segment that manages the server, enforced by host firewall or network ACL rather than inherited from the assumption that the recording server is internal, and the content arriving on that surface is constrained to what the service legitimately needs instead of being reconstructed into arbitrary objects. The sink's own content handling is the only thing standing between an unprivileged intranet account and execution as the NetworkService account on the recording server, because the caller's account privilege is never consulted on this path. Distinguishing test: from a general user VLAN on a staging deployment, open a connection to the Session Recording server's listening surface and send content the service never legitimately receives, and confirm the peer is refused before the content is deserialized — a deployment that passes a Citrix role-and-permission review while the recording server answers from every internal segment still carries the path. Precondition, and this is where the control is usually over-claimed: restricting reachability bounds which hosts and accounts can present the payload, it does not repair the deserialization, and any authenticated user inside a permitted segment satisfies the packet's stated access requirement in full. It is a holding measure for the window before the vendor update and its required restart land, and it offers nothing where the recording server must stay reachable from the segments that legitimately deliver recordings.",
+        "evidence": "Packet records CWE-502 deserialization of untrusted data in Citrix Session Recording. The vector states the flaw 'allows limited remote code execution with privilege of a NetworkService Account access' and that the 'Attacker must be an authenticated user on the same intranet as the session recording server'. CVSS 9.8, RWEP 77, poc_available true, active_exploitation confirmed, CISA KEV-listed 2025-08-25. Citing gaps include NIS2-Art21-network-security and UK-CAF-B4; NIST-800-53-AC-6 is also cited, consistent with an access requirement that any authenticated intranet account satisfies regardless of its privilege.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the control means the Citrix Session Recording update is driven across every recording server on the clock that opened with the 2025-08-25 KEV listing, rather than folded into the next scheduled virtualization-platform maintenance window, with completion measured per server by its installed version against the vendor's fixed version and by the required restart having been taken — not by 'approved' or 'downloaded' in a management console. 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 recording server that has taken the update but not restarted still runs the vulnerable code and must be counted as exposed. The tier assignment is the load-bearing part: because the exploit's only stated access requirement is an authenticated account on the same intranet, an internal, non-internet-facing recording server does not qualify for the relaxed cadence such assets normally receive — internal reachability is this exploit's precondition, not a mitigating factor, which is exactly how the patch-cadence controls cited on this entry pass their attestations while the server stays exploitable. Precondition: the SLA governs the clock, it supplies no interim mitigation; for the window before the restart completes, constraining who can reach the recording server's listening surface is the only operator-side lever. And because active exploitation is confirmed, a recording server that was reachable by intranet accounts during the exposure window belongs on the incident path rather than being closed on the patch — the update removes the deserialization path, not anything an attacker executed as NetworkService through it.",
+        "evidence": "Packet records patch_available true, live_patch_available false, and 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-listed 2025-08-25, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 9.8. The vector's access requirement — an authenticated user on the same intranet as the session recording server — is the packet fact that rules out treating this as a low-urgency internal asset. Citing gaps AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are the patch-cadence controls this listing outruns.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-54948": {
     "name": "Trend Micro Apex One OS Command Injection Vulnerability",
@@ -25138,7 +25303,39 @@
     },
     "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 outright that this CVE is a patch bypass for CVE-2025-49704 and that its updates carry more robust protection than 49704's did. That means an on-premises SharePoint farm which took the 49704 update and was recorded as remediated sat on the vulnerability-management ledger as 'patched' while remaining fully exploitable through the same CWE-502 sink — the earlier fix is the thing that failed, not the operator's SLA. Bound to this farm, the control requires that a SharePoint deserialization CVE which supersedes an earlier fix on the same sink is scored and scheduled above what its CVSS band alone implies, and that the superseded CVE's remediation record is reopened rather than left closed. It also sets the intake expectation for what follows: the packet already names a second CVE (CVE-2025-53771) this one can be chained with, so the farm's exposure is a sequence on one primitive, not a discrete ticket that closes. Precondition, and it is the limit of this control: it changes priority, scoring and record-keeping only — it remediates nothing. The vendor update plus the service restart or system reboot the packet records as typically required is what removes the code path, and a farm server that has taken the update but not the restart is still running the vulnerable code.",
+        "evidence": "Packet vector: 'CVE-2025-53770 is a patch bypass for CVE-2025-49704, and the updates for CVE-2025-53770 include more robust protection than those for CVE-2025-49704' and 'This vulnerability could be chained with CVE-2025-53771'. cwe_refs CWE-502; cisa_kev true, kev_date 2025-07-20; active_exploitation confirmed; rwep_score 83, cvss 9.8; poc_available true; patch_available true; live_patch_available false with live_patch_notes 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's attack path does not end at code execution — it ends at web-shell deployment on an on-premises SharePoint Server reached over the network by an attacker holding no credential. For this CVE that makes the farm an already-compromised host to be triaged, not a patch target to be closed. Applied to a SharePoint deployment: every front-end and application server that was network-reachable across the exposure window is examined for attacker-written content in the directories the web application serves, and every secret the farm's application identity holds — service accounts, application credentials, and the farm's own cryptographic material — is rotated, because the update closes the deserialization sink but removes nothing already written through it or read out of it. This is also the specific reason the anti-malware control cited against this entry cannot carry the remediation: a bespoke .aspx file dropped through the application's own request path is not a signature-matched sample, so a fully deployed and current anti-malware estate reports clean over a live web shell. Preconditions: rebuild-and-rotate reaches only the farm's own hosts and its own credentials — if the foothold was used to move to an identity outside the farm, that account is out of scope here and needs separate containment; and the triage is bounded by an exposure window the operator can actually establish, so a farm 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.",
+        "evidence": "Packet vector: 'Microsoft SharePoint Server on-premises contains a deserialization of untrusted data vulnerability that could allow an unauthorized attacker to execute code over a network.' Packet attack_vector: 'deserialization of untrusted data (CWE-502) on SharePoint Server (the ToolShell chain), yielding unauthenticated remote code execution and web-shell deployment. CISA KEV-listed 2025-07-20 with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available true; patch_available true; citing gap CIS-Controls-v8-10.1 'Deploy and Maintain Anti-Malware Software'.",
+        "gap_closes": [
+          "CIS-Controls-v8-10.1",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "An unauthenticated network RCE on an on-premises SharePoint farm, KEV-listed 2025-07-20 with confirmed in-the-wild exploitation, a public PoC and an RWEP of 83, is the case a KEV clock exists for — and the clock has to run to the completed restart rather than to the installed update. The packet registers no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a farm with more than one server is remediated only when every server has both taken the update and been restarted; completion is measured per server against the fixed build, not from a deployment console reporting 'approved' or 'applied'. That distinction is where this remediation goes wrong in practice, because the restart is the step a farm operator defers to avoid taking the site offline, and a deferral recorded as patched is indistinguishable on the dashboard from a real fix. Precondition: this is a deployment clock and nothing more. It says nothing about whether the farm was exploited before the clock started — which, for a KEV-listed pre-auth RCE with confirmed exploitation and web-shell deployment, is the likely case — so meeting the SLA is not a statement that the farm is clean.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-07-20; active_exploitation confirmed; rwep_score 83; cvss 9.8; 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.' Vector: 'could allow an unauthorized attacker to execute code over a network.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-25257": {
     "name": "Fortinet FortiWeb SQL Injection Vulnerability",
@@ -26235,7 +26432,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 two facts that have to be held together: patch_available is recorded true, and the vector states that all associated hardware revisions of the DIR-859 have reached end-of-life or end-of-service and should be retired and replaced per vendor instructions. Both are real, and together they settle the terminal state — whatever fixed firmware exists is an interim step on hardware with no ongoing patch path, so removal and replacement is the end state for every unit, not an option to weigh against patching. The requirement here is therefore an inventory that names each DIR-859 in service with its location and hardware revision and carries a dated replacement commitment, rather than a firmware-version column that turns green and stays green. A remediation record that ends at 'every DIR-859 reports the fixed build' marks the estate compliant while each unit remains exposed to everything found in that platform after the build shipped, with no vendor left to fix it — and the packet's confirmed exploitation and public PoC mean this device class is under active attention now, not hypothetically. Precondition on the interim measure, which is where this control is usually over-claimed: restricting who can reach the device's HTTP interface bounds who can send the POST, but the packet places the flaw in the router's own HTTP POST request handler, and a router exists to serve the clients behind it. Every host on the network it serves can reach that interface, so for a unit serving a general user or guest network there is no segment that removes the path — only isolation of that served network from anything else that matters, and replacement on the dated schedule.",
+        "evidence": "Packet vector: 'D-Link DIR-859 routers contain a path traversal vulnerability in the file /hedwig.cgi of the component HTTP POST Request Handler... This vulnerability affects legacy D-Link products. All associated hardware revisions have reached their end-of-life (EOL) or end-of-service (EOS) life cycle and should be retired and replaced per vendor instructions.' patch_available true; live_patch_available false; cisa_kev true, kev_date 2025-06-25; active_exploitation confirmed; poc_available true; rwep_score 77; cvss 7.8; cwe_refs CWE-22.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive the packet describes is a read, not a write: manipulating the service argument with ../../../../htdocs/webinc/getcfg/DHCPS6.BRIDGE-1.xml leaks session data from the device configuration, which the packet says potentially enables privilege escalation and unauthorized control of the device. Everything that leaked stays valid after firmware is applied — the update stops further reads, it does not invalidate what an attacker already holds, and it does not undo configuration an attacker with device control has already changed. Bound to this router: a DIR-859 that was reachable during the exposure window is treated as having had its configuration read, so the device administrative credential, the wireless keys, and any WAN or dynamic-DNS credential the configuration carries are rotated, and the unit is re-provisioned from a known-good configuration rather than left running the settings that were exposed. Preconditions, both load-bearing. First, re-provisioning is not the terminal state for this device: the packet's own vector directs retirement and replacement, so the rebuilt unit is a bridge to its replacement and any credential rotated onto it is rotated again at decommission — a rebuild recorded as closure leaves an unsupported router in service. Second, the rotation scope is only as good as the exposure window the operator can establish; a consumer-class router that retains no request logs cannot bound it, and in that case every deployed unit's configuration is treated as read.",
+        "evidence": "Packet vector: 'Manipulation of the argument service with the input ../../../../htdocs/webinc/getcfg/DHCPS6.BRIDGE-1.xml allows for the leakage of session data potentially enabling privilege escalation and unauthorized control of the device.' Packet attack_vector: 'letting an attacker read sensitive files including credentials from the device configuration. CISA KEV-listed 2025-06-25 with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available true; patch_available true; vector's retirement-and-replacement instruction for all hardware revisions.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-54085": {
     "name": "AMI MegaRAC SPx Authentication Bypass by Spoofing Vulnerability",
@@ -26836,7 +27056,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The packet states that this flaw affects various products implementing the Erlang/OTP SSH server, including but not limited to Cisco, NetApp and SUSE. For most operators that means the vulnerable code is not something they installed but something a vendor embedded, and no host in the estate reports 'Erlang/OTP' anywhere an administrator would look. Bound to this CVE the control means the component inventory has to be able to answer 'which products in service contain an Erlang/OTP SSH server' from vendor SBOM and advisory data rather than from installed-package lists, with the three vendors the packet names enumerated first and the enumeration extended by vendor response rather than stopped there — the packet's own wording is explicitly non-exhaustive, so treating those three as the affected set is a decision to leave the rest unknown. The distinguishing test is deliberately an absence test done properly: take an appliance whose vendor is not one of the three named and show the answer to 'does this product embed an Erlang/OTP SSH server?' comes from that vendor's SBOM or advisory, not from the absence of an Erlang package on the host — for an embedded runtime, absence from an installed-software list and true absence look identical. Precondition: the inventory remediates nothing on its own; it determines which vendor updates apply. The packet records a vendor patch, no live-patch path, and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so each identified product carries its own update and its own restart, and a product identified and updated but not restarted is still running the vulnerable listener. The packet names no fixed Erlang/OTP release, so the fixed version is whatever each product's vendor publishes for that product.",
+        "evidence": "Packet vector: 'This vulnerability could affect various products that implement Erlang/OTP SSH server, including—but not limited to—Cisco, NetApp, and SUSE.' CWE-306; CVSS 9.8; RWEP 77; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-06-09. 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",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Erlang/OTP SSH server is exactly the pre-authentication protocol listener this control governs: the packet places the defect in how SSH protocol messages are handled and has an attacker executing arbitrary commands without valid credentials, so the message handler answers — and is exploitable — before any credential is presented, and the parser is itself the vulnerable code. Bound to this deployment the requirement is that the SSH surface of every product identified as embedding the Erlang/OTP SSH server accepts connections only from the management and jump networks that legitimately administer it, enforced by network ACL or host firewall rather than assumed from 'SSH is internal', and that this KEV-listed defect is remediated on an accelerated clock with the service restart or reboot the packet records actually taken rather than folded into the next maintenance window. This is also why the least-privilege and identity-and-access gaps recorded against this entry do not close the path: the attacker never authenticates, so no account's privileges are consulted and the account model an identity attestation examines is bypassed rather than abused — key-only authentication, disabled password login, MFA on SSH accounts and per-account privilege scoping all pass cleanly while the pre-auth path stays fully open. Distinguishing test: from a segment with no administrative role, open a connection to the SSH port of each identified product on a staging instance and confirm it is refused before the protocol exchange begins. Preconditions: reachability restriction bounds who can send the pre-authentication messages, it does not repair the handler; it is unavailable wherever that SSH surface must stay reachable for normal operation, and any compromised jump host or automation account already inside the permitted segment satisfies the exploit's only stated requirement in full. Because the packet records confirmed exploitation with a public PoC, a product whose SSH surface was reachable during the exposure window needs forensic triage and credential rotation — the update closes the path, it does not remove what unauthenticated command execution left behind.",
+        "evidence": "Packet vector: 'Erlang Erlang/OTP SSH server contains a missing authentication for critical function vulnerability. This could allow an attacker to execute arbitrary commands without valid credentials... By exploiting a flaw in how SSH protocol messages are handled, a malicious actor could gain unauthorized access to affected systems.' CWE-306; CVSS 9.8; RWEP 77; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-06-09. patch_available true; live_patch_available false; live_patch_notes records that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B2 (Identity and access control).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2025-5419": {
     "name": "Google Chromium V8 Out-of-Bounds Read and Write Vulnerability",
@@ -27676,7 +27920,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": "This entry is the case where a severity-tiered remediation queue and the real exposure disagree: CVSS 6.1 puts it below the critical/high trigger most patch programs act on, while the packet carries RWEP 77, confirmed in-the-wild exploitation, a public PoC and a CISA KEV listing dated 2025-05-19. Bound to this product the control means the ZCS remediation item opens on the KEV listing rather than on the CVSS band, and completion is measured by each mailbox node running the vendor-fixed release with the restart taken — the packet records a vendor patch, no live-patch path, and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so a node that has taken the package but not restarted is still serving the vulnerable CalendarInvite render path and must be counted as exposed. The distinguishing test is to produce the remediation record for this CVE and show what triggered it: a program ordered by CVSS will show this sitting in a medium-severity backlog with an attestation that reads clean, while a flaw with confirmed exploitation executes attacker JavaScript in users' authenticated mail sessions. Precondition: the vendor release closes the render path, it does not undo a session that was already scripted. Arbitrary JavaScript in an authenticated webmail session can do whatever that session can do, so with exploitation confirmed, mailboxes whose users opened invites during the exposure window need review of the state that session could have changed — forwarding and filter configuration, and message access — rather than being closed on the patch.",
+        "evidence": "Packet: CVSS 6.1 against RWEP 77; CWE-79; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-05-19. 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.' Vector places the flaw in 'the CalendarInvite feature of the Zimbra webmail classic user interface'. No fixed ZCS version is recorded in the packet.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Zimbra's classic web client is the webmail tier this control governs, and this CVE is precisely the failure mode it exists for: the packet has the payload arriving inside an email message's crafted calendar header, executing when the CalendarInvite feature renders it, and running in a victim's already-authenticated session. Nothing in that sequence produces an authentication event — the user signed in normally, once, before the message arrived — so an estate whose mail-platform logging is authentication events plus administrator actions holds no record that exploitation occurred. Bound to this product the requirement is per-request access logging from every ZCS mailbox node forwarded to a SIEM outside the mail platform, retained long enough to cover a window that opened before the 2025-05-19 KEV listing, and correlated with inbound-message telemetry. The two observable halves of what the packet describes are an inbound message carrying markup in a calendar header, and subsequent requests issued inside one already-authenticated session that do not correspond to what that user was doing, with no new sign-in between them. A rule keyed on failed logins, impossible-travel or new-device sign-ins, or malicious attachments fires on none of it: there is no failed login, no new device, and no attachment — the payload rides a header on an otherwise ordinary invite. Distinguishing test: send a benign but structurally equivalent invite carrying markup in the calendar header to a mailbox on a staging node, open it in the classic UI, and confirm the SIEM shows both the inbound message and the resulting per-request activity under the pre-existing session; if the only retrievable artifact is that day's login event, the logging cannot evidence this exploitation. Precondition: this is detection, not prevention — it does not stop the script from running and it yields nothing retrospectively if per-request logs were never retained, so it has value only where it was already in place. It covers only the nodes actually forwarding.",
+        "evidence": "Packet vector: 'Zimbra Collaboration contains a cross-site scripting (XSS) vulnerability in the CalendarInvite feature of the Zimbra webmail classic user interface. An attacker can exploit this vulnerability via an email message containing a crafted calendar header, leading to the execution of arbitrary JavaScript code.' Attack vector: 'letting an attacker run script in a victim's authenticated session.' CWE-79; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-05-19.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-27920": {
     "name": "Srimax Output Messenger Directory Traversal Vulnerability",
@@ -28445,7 +28712,31 @@
     },
     "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 Windows Common Log File System driver and describes an authorized attacker elevating privileges locally through a use-after-free — the account is already legitimate, so no account model is being abused; a kernel privilege boundary is failing. For this CVE the control means the Windows update carrying the CLFS fix is driven across the affected estate on the KEV clock that opened 2025-05-13 rather than folded into the next monthly rollup, with completion measured per host by installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. CLFS is a driver that ships with Windows and loads on every install, so there is no subset to carve out, no module to blacklist and no feature to disable as an interim measure — the update is the only remediation available, which is precisely why measuring it accurately is the whole of the control. 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 host that has installed the update but not rebooted still runs the vulnerable driver and must be counted as exposed; shared and multi-user hosts are where that reboot is deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Priority follows the packet rather than the CVSS band: at CVSS 7.8 this sorts below the 9.x remote flaws in a severity-ordered queue, while the packet records RWEP 77, a public PoC, confirmed exploitation, and that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators — making it the containment step for a chain rather than a standalone endpoint item.",
+        "evidence": "Packet: use-after-free (CWE-416) in the Windows Common Log File System (CLFS) Driver allowing an authorized attacker to elevate privileges locally, exploited by a local foothold to escalate to SYSTEM; CISA KEV-listed 2025-05-13 with active_exploitation confirmed; poc_available true; CVSS 7.8 against RWEP 77; the packet describes CLFS as a recurring kernel-LPE target and notes LPEs of this class are routinely paired with an initial-access flaw by ransomware operators; patch_available true, live_patch_available false, live_patch_notes recording that 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-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Every framework control cited on this entry is a patch or vulnerability-handling control, and none of them observe anything during the interval between the 2025-05-13 KEV listing and the reboot that completes the fix — which is the interval in which the packet says this flaw is being exploited. For this CVE the control means kernel-privilege-escalation telemetry on Windows endpoints keyed on the transition the packet actually describes: a process running under an already-authorized non-administrative account that ends up holding SYSTEM privileges, or spawning a SYSTEM-integrity child, without passing through a legitimate elevation path — correlated with that same process driving the CLFS driver from user mode. Alert within 60 seconds. What not to key on, because it would miss this exploit entirely: the packet describes a use-after-free that succeeds in escalating, not one that faults, so a rule watching for driver crashes or bugchecks never fires on a working exploit; and the packet records a public PoC, so a rule keyed on a named tool or a file hash misses the derived variant an operator will meet. The distinguishing test has to exercise the real transition rather than a stand-in: on a staging host, have a standard user account run a local escalation that ends with a SYSTEM-integrity process and confirm the rule alerts on the privilege transition itself. Preconditions: this detects, it does not prevent — its value is bounding dwell time on hosts that have not yet taken the reboot, and it does not make an unrebooted host remediated. And because the escalation's own outcome is SYSTEM, a successful attacker ends up above the agent that would report the alert, so telemetry has to reach an off-host collector to be a control at all.",
+        "evidence": "Packet: use-after-free (CWE-416) in the Windows CLFS driver exploited by a local foothold to escalate to SYSTEM, with the attacker described as an authorized user elevating privileges locally; CISA KEV-listed 2025-05-13 with active_exploitation confirmed; poc_available true; CVSS 7.8, RWEP 77; the packet notes LPEs of this class are routinely paired with an initial-access flaw by ransomware operators; patch_available true, live_patch_available false, live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction; the framework controls this entry cites are all patch or vulnerability-handling controls.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-12450": {
     "name": "RAGFlow web_crawl Full-Read SSRF + Arbitrary File Read",
@@ -32277,7 +32568,39 @@
     },
     "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": "Unified CM is the call-control plane the packet names, and the defect sits on a service endpoint it exposes: WebDialer is reachable by an unauthenticated remote attacker, and improper input validation of specific HTTP requests lets the caller choose what the server requests and drives file writes to the underlying OS that are then used to reach root. Bound to this product, the control means the WebDialer request handlers authorize their caller before the request is processed at all, and the destination the server is asked to contact and the path it is asked to write are canonicalized and validated against an allowlist before either action executes — so a caller-supplied value cannot select an internal target or which file gets written; and no Unified CM node is left with WebDialer reachable from a segment that has no click-to-dial need. This is also why the cited boundary-protection gap does not close the path by itself: a perimeter that keeps the node off the internet still leaves the endpoint answering any host inside the permitted segment, and a boundary attestation passes cleanly while it does. Distinguishing test: from a segment with no click-to-dial requirement, send unauthenticated HTTP requests to the WebDialer endpoints on a staging node whose parameters name an internal address the server should never contact, and confirm each is refused before the server issues the outbound request or writes anything. Preconditions: endpoint-side authorization and input validation are properties the vendor update establishes — this control states what to verify, it does not implement it, and the packet registers no live-patch path for the product class. Restricting reachability bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable where WebDialer must stay reachable for normal click-to-dial operation. Because exploitation is confirmed and the packet's path ends in files written to the OS and root privilege, a node reachable during the exposure window needs forensic review — the update does not remove what was already written.",
+        "evidence": "Packet vector: 'The Unified CM WebDialer service is reachable by an unauthenticated remote attacker. Improper input validation of specific HTTP requests (CWE-918) lets the attacker coerce the server into issuing attacker-controlled requests and writing files to the underlying OS, which are then used to elevate to root. Cisco rates the Security Impact Critical above the 8.6 base because the end state is root compromise of the call-control plane.' cwe_refs CWE-918; cisa_kev true with kev_date 2026-06-25; active_exploitation confirmed; poc_available true; CVSS 8.6; RWEP 78. 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-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives this entry a vendor update, no live-patch path for the product class, confirmed exploitation and a public PoC, so the remediation clock runs from the 2026-06-25 KEV listing through the update landing on every Unified CM node — including the nodes an operator would ordinarily defer, because a telephony cluster's change window is scheduled around call availability rather than around exploit availability. That deferral is the specific way this remediation goes wrong: the packet's end state is root on the call-control plane, so a node left running past the clock while the cluster waits for its next maintenance window is not the low-risk member of the cluster, it is the one the unauthenticated path reaches. Where a node genuinely cannot take the update inside the clock, the packet's own remediation line requires the compensating controls to be in force for the whole interval and the node counted as exposed, not recorded as scheduled.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-06-25, active_exploitation confirmed, poc_available true, CVSS 8.6, RWEP 78. 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.' Vector records the end state as root compromise of the call-control plane.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet's remediation line for this entry — the vendor update plus the named compensating controls until it lands — describes exactly the intermediate state a vulnerability-management verdict collapses into 'handled'. For this product the interim measure is operator-side rather than a vendor rule: restricting which segments can reach WebDialer on an un-updated Unified CM node. That is the mitigation-active state, not remediation, and its residual risk is specific enough to record — anything that can already route to the node still reaches an unauthenticated endpoint whose documented end state is root. The verdict for this CVE must therefore carry the list of nodes still in that state, the segments each remains reachable from, and a dated action item for the vendor update, instead of reporting the cluster as remediated because a segmentation change was made. Precondition worth stating in the same verdict: for a node with confirmed exposure during the window, neither the segmentation change nor the later update evicts anything the attacker already wrote to the OS.",
+        "evidence": "Packet: live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands'; vector states the WebDialer service is reachable by an unauthenticated remote attacker and that the attacker-driven file writes are used to elevate to root; active_exploitation confirmed; poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-67038": {
     "name": "Lantronix EDS5000 Code Injection Vulnerability",
@@ -32387,7 +32710,31 @@
     },
     "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 the defect sits on one of its configuration endpoints: the packet has the package-update handler passing attacker-influenced input into a command executed with root privilege, CWE-20 improper input validation becoming the CWE-78 injection. Bound to this product, the control means the update handler authorizes its caller before any supplied input is acted on, and neutralizes that input before the privileged command runs, so a caller-supplied value cannot become part of what the console executes as root; and it means no UniFi OS console is left with its management surface reachable from a network with no management role, including any path into the site from outside. Reachability is doing real work here, and it is also where this control is normally over-claimed. The packet says the flaw on its own requires reaching the handler, but chained behind CVE-2026-34908 (access-control bypass) and CVE-2026-34909 (path traversal) it completes an unauthenticated root RCE — so restricting who holds a UniFi administrative account changes nothing about this path, because the attacker never authenticates, and only restricting who can route to the management surface bounds the attempt. Distinguishing test: from a segment with no management role, and from outside the site, attempt to reach the UniFi OS management surface on a staging console and confirm the request is refused before the update handler is entered — a console that passes an administrator-account and password-policy audit while answering a general user VLAN or an inbound mapping is still fully exposed to the published chain. Precondition: the caller authorization and input neutralization are properties the vendor update establishes; this control states what to verify, it does not implement it. The packet records a vendor update with no live-patch path, so until that update lands, restricting reachability bounds the population that can present a request to the handler but leaves the handler itself entirely exploitable to anything inside the permitted segment, and it is unavailable wherever the console must stay reachable for remote site management.",
+        "evidence": "Packet facts only: cwe_refs CWE-20 and CWE-78; vector states the UniFi OS package-update handler passes attacker-influenced input into a command executed with root privilege, that on its own it requires reaching the handler, and that chained behind CVE-2026-34908 (access-control bypass) and CVE-2026-34909 (path traversal) it completes an unauthenticated root RCE that operators use to install a Mirai/Gafgyt-derived botnet; cisa_kev true with kev_date 2026-06-23; active_exploitation confirmed; poc_available true; cvss 10 with rwep_score 79; 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.' NIST-800-53-SC-7 boundary protection is one of the framework gaps already citing this CVE.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at root RCE — it names the outcome operators are observing, a Mirai/Gafgyt-derived botnet installed on the device, with exploitation confirmed and the entry KEV-listed 2026-06-23. That makes the vendor update the wrong closing step for any console that was reachable by the chain during the exposure window: applying it removes the injection path but leaves an implant that was installed with root exactly where it is, along with whatever the attacker changed or read on the box, and the device keeps operating as a botnet member after the flaw-remediation ticket closes. For a suspect console the response is to treat it as compromised infrastructure rather than as a patch item — capture the running configuration for analysis, rebuild from vendor firmware rather than restoring that configuration wholesale, and rotate the console's administrative credentials along with anything else it stored or that was presented to it during the window, since the packet establishes the attacker held root and root on this device is custody of everything on it. The distinguishing test keys on what the packet documents rather than on tool signatures: an installed botnet client exists to reach its operator, so examine the console's own outbound connections for destinations that no management, update or telemetry function explains — a console that reports the fixed version and still initiates them was compromised before the update landed, and a version check alone cannot tell those two states apart. Precondition, stated rather than assumed: rebuild is warranted where the console was reachable by the chain during the exposure window. Where the packet's stated requirement of reaching the update handler was never satisfiable — a console with no route from any untrusted network across that period — the update alone is closure. Deciding which case a given console is in requires reachability evidence from the exposure window, not a present-tense assertion that the console sits on an internal network.",
+        "evidence": "Packet facts only: vector and attack_vector state the chain completes an unauthenticated root RCE that operators use to install a Mirai/Gafgyt-derived botnet; active_exploitation confirmed; cisa_kev true with kev_date 2026-06-23; poc_available true; cvss 10 with rwep_score 79; the flaw requires reaching the package-update handler on its own, and is chained behind CVE-2026-34908 and CVE-2026-34909; patch_available true with live_patch_available false and live_patch_notes stating remediation is the vendor update plus the named compensating controls until it lands. NIST-800-53-SI-2 flaw remediation and AU-Essential-8-Patch are among the framework gaps already citing this CVE.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2026-34909": {
     "name": "Ubiquiti UniFi OS Path Traversal Vulnerability",
@@ -35518,7 +35865,32 @@
     },
     "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 packet turns this SLA into a build check an operator can actually perform: every VeraCore instance released before 2024.4.2.1 carries the upload.aspx path, so the object of the clock is a version string read off each running instance, not an attestation that a patching process exists. Run that clock from the 2025-03-10 KEV listing rather than the 2025-03-31 due date the entry records, because active exploitation is already confirmed — the three-week interval between those dates is precisely the window in which an authenticated user places a file into a folder the packet says is accessible during web browsing by other users, and the file outlives the window. The packet records no live-patch path for this product class, so the vendor update is the only thing that closes the upload path; it records no restart or reboot requirement either, so a deferral justified by needing a downtime window for the fulfilment platform is not supported by anything in this entry. Precondition, and the reason the scope cannot be narrowed to instances someone judges externally exposed: the packet's stated access requirement is a remote authenticated user, so every account that can sign in to an instance already satisfies the exploit precondition. Restricting who can reach the application bounds the population that can send the upload; it removes nothing for anyone already inside that population, and it is not a substitute for reaching 2024.4.2.1. Distinguishing test: produce every VeraCore instance in service with its version string and show each is at or past 2024.4.2.1 — an inventory row reading 'VeraCore: patching current' without a per-instance build is the state this control rejects, because a second instance on an older track keeps upload.aspx reachable while the ticket reads clean.",
+        "evidence": "Packet vector: 'Advantive VeraCore before 2024.4.2.1 allows remote authenticated users to upload files to unintended folders (e.g., ones that are accessible during web browsing by other users). upload.aspx can be used for this.' CISA KEV-listed 2025-03-10 with a 2025-03-31 due date; active_exploitation confirmed; patch_available true; live_patch_available false, with live_patch_notes recording no live-patch path for this product class and the vendor update plus compensating controls as the remediation until it lands — no restart or reboot requirement is recorded. CWE-434; cvss 9.9; rwep_score 44; poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scan that reports VeraCore remediated because the instance now returns 2024.4.2.1 is paper compliance on this entry specifically, because the upgrade closes the upload path and removes nothing that was written through it. The packet records active exploitation as confirmed and describes the primitive as an authenticated user placing a file into a folder accessible during web browsing by other users — a file that landed there before the upgrade is still on disk, still under a path the application serves, and still returned to whatever requests it, after the version string changes. The operational test the scan has to carry is therefore a content test rather than a version test: for each instance, enumerate the contents of the directories VeraCore serves to browsing users and reconcile them against the deployment's own record of what belongs there, covering the whole interval the instance ran a build below 2024.4.2.1 and not merely the days since the 2025-03-10 KEV listing, and flag every file that upload.aspx could have placed and that no operator can account for. Precondition on that reconciliation, which is where this is usually over-claimed: it is conclusive only where a known-good manifest or build-time file list exists for the served directories. Where it does not, the honest output is an unresolved-content finding that puts the instance on a rebuild-from-known-good path — not a clean result, and not a finding that the upgrade closes. Distinguishing test: on a staging instance at 2024.4.2.1, sign in as an ordinary VeraCore user and POST a file through upload.aspx aimed at a folder that browsing users can reach, and confirm it is refused before the write — an attestation that the flaw-remediation ticket closed on the version bump answers a question this exploitation path never asked.",
+        "evidence": "Packet vector: 'Advantive VeraCore before 2024.4.2.1 allows remote authenticated users to upload files to unintended folders (e.g., ones that are accessible during web browsing by other users). upload.aspx can be used for this.' active_exploitation confirmed; CISA KEV-listed 2025-03-10 (due 2025-03-31); patch_available true with 2024.4.2.1 as the fixed release named in the vector; live_patch_available false, live_patch_notes recording no live-patch path for this product class; CWE-434; cvss 9.9; rwep_score 44. Framework gaps cited on this entry are the patch- and vulnerability-management controls (ASD Essential Eight patching, ISO/IEC 27001:2022 A.8.8, NIST SP 800-53 SI-2, NIS2 vulnerability handling, UK CAF B4), none of which asks what the exposure window left behind.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-25181": {
     "name": " Advantive VeraCore SQL Injection Vulnerability",
@@ -36039,7 +36411,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet forecloses the remediation this entry's framework gaps assume: Cisco has not and will not release software updates that address this vulnerability, and the entry records no patch and no live-patch path. For the RV016, RV042, RV042G, RV082, RV320 and RV325 routers the packet names, remediation therefore means removal from service on a dated schedule, and the interim state is the vendor's own workaround — disabling the affected feature described in the Workarounds section — together with restricting which segments can reach the web-based management interface at all. Scope it to those six models: the packet ties the flaw to that management interface on those routers and gives no basis for treating other Cisco equipment as an instance of it. The precondition is sharp here and must be stated rather than glossed — segmentation and the feature workaround bound who can send the crafted HTTP request, they do not remove the defect, and the packet's stated access requirement is valid administrative credentials on the device, so an attacker holding or replaying those credentials from a permitted management segment still reaches the root-level command execution. Because active exploitation is confirmed and the outcome is root-level privileges plus access to unauthorized data, a unit that was reachable during the exposure window has to be treated as attacker-held: its configuration and every credential it stored are suspect, and re-provisioning it returns it to a state where no fix exists — which is why the terminal state is replacement rather than a hardened surviving unit. A requirement that ends at 'the workaround is applied' marks a device the vendor has permanently declined to fix as compliant while it stays exposed to this flaw and to anything found in it later.",
+        "evidence": "Packet: patch_available false; the vector states 'Cisco has not and will not release software updates that address this vulnerability' and directs administrators to disable the affected feature per the Workarounds section. live_patch_available false, with live_patch_notes recording no live-patch path for this product class and decommissioning as the remediation for end-of-life products. CISA KEV-listed 2025-03-03 (due 2025-03-24), active_exploitation confirmed, poc_available true, RWEP 83 against CVSS 6.5. Affected models named in the packet: RV016, RV042, RV042G, RV082, RV320, RV325. The documented path is a crafted HTTP request to the web-based management interface exploiting improper validation of user input (CWE-77); the packet states the attacker must hold valid administrative credentials on the affected device and that a successful exploit yields root-level privileges.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this entry the control's middle verdict state is not a temporary one, because nothing is pending behind it: the packet records that no software update addressing this vulnerability will be released, so the feature-disable workaround is the only technical measure that will ever exist. Any RV-series unit still in service must therefore be recorded as 'vendor workaround active, no fix, none forthcoming' with a dated removal action attached, and never as satisfying a patch-cadence control. The distinguishing test is on the register rather than the device: pull the vulnerability-management record for each RV016, RV042, RV042G, RV082, RV320 and RV325 in service and read what it reports once the workaround is applied — if it reads 'remediated' or 'patched per SLA', the record has lost both the fact that a KEV-listed, actively-exploited flaw with a public PoC is still present in the device and the fact that the residual risk is now bounded only by whatever the workaround itself is worth. Precondition: this control changes what the record says, not what the device does. It reduces no exposure on its own; its whole value is preventing the workaround from closing the item and removing the schedule pressure that decommissioning depends on.",
+        "evidence": "Packet: patch_available false and the vector states Cisco has not and will not release software updates that address this vulnerability, offering only that 'administrators may disable the affected feature as described in the Workarounds section'. live_patch_available false. CISA KEV-listed 2025-03-03 (due 2025-03-24) with active_exploitation confirmed and poc_available true; RWEP 83, CVSS 6.5.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-34192": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Vulnerability",
@@ -36314,7 +36710,21 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_disclosure",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "Power Pages is a vendor-operated service and the packet says the fix already happened inside it: the vulnerability 'has already been mitigated in the service', all affected customers were notified, and those customers were given instructions on reviewing their sites for potential exploitation and cleanup methods. That produces a compliance state none of the cited controls has a box for, and it maps onto this control's state (b) rather than state (a) — a mitigation the operator did not deploy, cannot verify by version or build, and holds no artifact for, while a KEV clock that opened 2025-02-21 with a 2025-03-14 due date names an action the operator cannot perform. Recording the entry as 'patched per SLA' is precisely the failure this control exists to prevent, because the outstanding work is the other half: the flaw let an unauthorized attacker elevate privileges over the network by bypassing the user registration control, and a service-side fix closes that bypass without removing any account, role or site content an attacker obtained through it beforehand. The verdict for this CVE must therefore read as vendor-mitigated-in-service carrying a distinct, time-bound operator action item — work through the vendor's cleanup instructions and review each Power Pages site's registered users and their assigned privileges across the exposure window — and stay open until that review is evidenced rather than closing when the vendor's mitigation is acknowledged. The distinguishing test is documentary: ask for the artifact behind the 'remediated' verdict; a patch record for a service the operator never patched, or a copy of the vendor's mitigation notice, is not evidence that any site was reviewed. Two preconditions, both load-bearing. The packet states that an operator who was not notified is not affected, so the review scope is set by whether the notification was received, and an operator should establish that positively rather than infer exposure from the KEV listing. And the packet records poc_available false alongside confirmed active exploitation, so there is no public exploit for a scanner or detection signature to key on — the review has to run off the vendor's instructions and the site's own registration and privilege records, not off waiting for exploitation evidence to surface on its own.",
+        "evidence": "Packet facts only: cwe_refs CWE-284; vector states an improper access control vulnerability in Power Pages allows an unauthorized attacker to elevate privileges over a network potentially bypassing the user registration control, that 'This vulnerability has already been mitigated in the service and all affected customers have been notified', that the update addressed the registration control bypass, that affected customers were given instructions on reviewing their sites for potential exploitation and clean up methods, and that 'If you've not been notified this vulnerability does not affect you'; cisa_kev true with kev_date 2025-02-21 and the attack_vector recording a 2025-03-14 due date; active_exploitation confirmed; poc_available false; cvss 8.2 with rwep_score 46; patch_available true; 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",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-0111": {
     "name": "Palo Alto Networks PAN-OS File Read Vulnerability",
@@ -36442,7 +36852,30 @@
         "adequate": false,
         "gap": "Patch-applications control assumes a known-vulnerable window between disclosure and exploitation; here the window was negative, so patch cadence alone can't be the only control."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The vulnerable code here is a Joomla extension rather than Joomla itself, and that is precisely where this entry's patch-cadence gaps fail: a site whose CMS core is current, and whose operating-system patching attests clean, can still be serving the unauthenticated Balbooa Forms attachment endpoint the packet describes. Applied to this CVE, the KEV clock that opened 2026-07-10 runs against an inventory of every Joomla site in the estate carrying the Balbooa Forms extension — including sites where the form sits on a low-traffic marketing page nobody treats as an application, which is the population that goes uncounted when the inventory unit is 'the website' rather than 'the extensions this website loads'. Completion is measured by the extension version each installation reports against the vendor's fixed release, not by the Joomla core version and not by a 'site updated' line in the change record. The packet records a vendor patch as available and no live-patch path, so the fixed extension release applied per installation is the remediation; the packet registers no restart requirement for this entry, so nothing in it supports treating this as a maintenance-window item. Priority follows the packet rather than the CVSS band alone: an unauthenticated upload requiring no user interaction, a public PoC, and confirmed in-the-wild exploitation mean the interval between listing and update is an interval in which the endpoint is being used. Scope: the packet ties this to the Balbooa Forms extension and to nothing else — it is a reason to know which sites carry that extension, not a reason to treat every Joomla extension in the estate as an instance of this flaw.",
+        "evidence": "Packet: CISA KEV-listed 2026-07-10, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 65. patch_available true; live_patch_available false; live_patch_notes null (no restart or live-patch detail recorded for this entry). The affected product is the Joomla extension Balbooa Forms (CWE-434, unrestricted upload of file with dangerous type); the packet's documented path is an unauthenticated attacker submitting a .php file to a Balbooa Forms attachment field, which the extension stores in a public uploads folder with no file-type or authentication check, and which the attacker then requests directly to execute — the packet records the outcome as full RCE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet describes a flaw that does not stop mattering when the extension is updated: the attacker's artifact is a .php file already written into a public uploads folder, and requesting that URL executes it whether or not the upload path has since been repaired. On an internet-facing Joomla site, with exploitation confirmed in the wild and a public PoC, applying the fixed extension release is the first step and the compromise assessment is the rest — enumerate the Balbooa Forms upload directory and the site's web-served tree against a known-good baseline, rebuild the site from source and known-good content rather than trusting an in-place clean, and rotate every credential the web process could reach: the site database credentials, Joomla administrator accounts, keys held in site configuration, and any of those reused elsewhere. The trigger for this playbook has to be exposure rather than an alert, and the detection has to key on what the packet's path actually emits: a file with an executable extension appearing in the uploads directory outside any sanctioned change, and web-server log entries requesting a file under that uploads path directly. It will not arrive as an anti-malware hit — a small bespoke PHP file delivered through an endpoint whose purpose is accepting uploads has no signature to match — and it produces no failed-authentication event, because the packet's attacker never authenticates. Precondition: this control bounds the damage of an intrusion that already occurred. It prevents nothing on a site that has not yet been reached, and it is not a substitute for the vendor's fixed extension release, which is the only thing that closes the upload path itself.",
+        "evidence": "Packet: active_exploitation confirmed, poc_available true, CISA KEV-listed 2026-07-10, CVSS 9.8, RWEP 65. The documented exploitation path is an unauthenticated .php upload through a Balbooa Forms attachment field into a public uploads folder, which the attacker then requests directly to execute the code — the file's persistence is independent of the extension's (absent) file-type and authentication checks. patch_available true; live_patch_available false; live_patch_notes null. The packet's vector records the result as full RCE.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-48939": {
     "name": "iCagenda Unrestricted Upload of File with Dangerous Type Vulnerability",
@@ -37281,7 +37714,31 @@
         "adequate": false,
         "gap": "Boundary protection blocking outbound SMB (445) to arbitrary external hosts would have prevented NTLM hash relay/capture even where the client-side Protected View bypass succeeded."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The mechanism this CVE defeats is Office Protected View itself: per the packet, a crafted 'file://' moniker hyperlink carrying the '!' new-window parameter makes Outlook bypass Protected View and open the linked remote document in edit mode when the recipient clicks it. That makes an attestation of the form 'Protected View is enforced by policy' simultaneously true and worthless — the policy is enforced and the document opens outside it, so a user-application-hardening review that inspects the policy finds nothing wrong. For this CVE the control means the moniker-link primitive becomes a permanent case in the estate's Protected-View / untrusted-document test battery, re-executed on every Office and Outlook update rather than exercised once while remediating this CVE, because a mechanism that has been bypassed once is a mechanism whose future updates need proving rather than assuming. Distinguishing test, keyed to the behaviour the packet documents rather than to a stand-in: send a managed workstation at the fixed build an email whose body carries a 'file://' moniker hyperlink with the '!' new-window parameter pointing at a share you control, click it, and check two observables — that the linked document opens in Protected View rather than edit mode, and that the workstation makes no authentication attempt to that share. The second observable is the one a naive test drops: the packet records NTLM hash leakage to an attacker SMB share as an outcome distinct from code execution, so an outbound authentication attempt is the signal that the primitive still works even when the document render looks contained, and a test that watches only the render will pass over it. Precondition: this is a verification control, not a mitigation. It tells an operator whether the protection class is actually restored on a given build; it restores nothing itself, and it gives nothing to a client that has not yet taken the vendor update. A battery that runs only at remediation time also cannot see a later regression, which is the entire reason for tying it to every update rather than to this ticket.",
+        "evidence": "Packet fields for CVE-2024-21413 (Microsoft Outlook Improper Input Validation Vulnerability): cwe_refs CWE-20; vector 'Microsoft Outlook Remote Code Execution Vulnerability'; attack_vector 'An attacker sends an email containing a crafted file:// moniker hyperlink with a ! new-window parameter; when the recipient clicks it, Outlook bypasses Office Protected View and opens the linked remote document in edit mode, enabling NTLM hash leakage via an attacker SMB share or remote code execution.' cisa_kev true with kev_date 2025-02-06; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 74. patch_available true, live_patch_available false, live_patch_notes null. Citing gaps recorded on this entry: AU-Essential-8-Patch, ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIS2-Art21-patch-management, NIST-800-53-SC-7 (Boundary Protection), NIST-800-53-SI-2 (Flaw Remediation) and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "What the clock governs on this entry is distribution, not availability: the packet records patch_available true against a CVE from the 2024 identifier series that CISA did not list until 2025-02-06, with exploitation confirmed and a public PoC. The remediation unit is also unusual for a KEV item — the vulnerable code is the Outlook client on every user's machine, not a server or an appliance, so the SLA has to be measured as the count of Outlook installs reporting the fixed build and closed against the estate's install inventory, not against a change ticket for a single system. The packet registers no live-patch path and carries no live-patch note for this entry, so each install reaches remediation only by taking the vendor update; there is no interim state in which the client is running fixed code. Precondition on the compensating-control branch, which is where this gets over-claimed: for the window before the update lands, the outbound leg the packet names — NTLM authentication to an attacker-controlled SMB share — can be restricted at the boundary, and that is what the entry's boundary-protection gap points at, but it bounds only the credential-leak half. The packet records remote code execution as a separate outcome that this restriction does not address, and it does nothing where the link's destination is reachable inside the estate rather than across the boundary being filtered, so it is a bound on one outcome for one class of destination, not a substitute for the update. Second precondition: the update closes the client path forward and recovers nothing backward. Credential material already leaked during the exposure window stays valid after every client is patched, so any account whose workstation authenticated outward to an untrusted host in that window is a rotation item and a hunt item, not a line that clears when the install count reaches 100 percent.",
+        "evidence": "Packet fields for CVE-2024-21413: attack_vector 'An attacker sends an email containing a crafted file:// moniker hyperlink with a ! new-window parameter; when the recipient clicks it, Outlook bypasses Office Protected View and opens the linked remote document in edit mode, enabling NTLM hash leakage via an attacker SMB share or remote code execution.' cisa_kev true with kev_date 2025-02-06 against a CVE in the 2024 identifier series; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 74; cwe_refs CWE-20. patch_available true, live_patch_available false, live_patch_notes null — no live-patch path and no live-patch note is recorded for this entry. The citing gaps are dominated by patch-timeline controls (AU-Essential-8-Patch, NIS2-Art21-patch-management, NIST-800-53-SI-2, ISO-27001-2022-A.8.8), with NIST-800-53-SC-7 (Boundary Protection) recorded alongside them.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2022-23748": {
     "name": "Dante Discovery Process Control Vulnerability",
@@ -38836,7 +39293,30 @@
         "adequate": false,
         "gap": "Vulnerability handling processes did not flag an internet-facing admin interface as an unacceptable exposure ahead of exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The ColdFusion Administrator is the management surface on this entry, and the packet places the defect behind it: an unauthenticated attacker sends crafted requests to the ColdFusion admin API / PMS servlet and reads arbitrary files on the server filesystem, with no user interaction required. Bound to this product, the control means each administrative endpoint on that admin API decides its own caller's authorization before performing the file operation — an unauthenticated request is refused by the endpoint itself, not by whatever fronts it — and the Administrator surface is segmented so an untrusted caller cannot present the request in the first place. The packet makes that second half unusually concrete for a KEV entry: it states that exploitation requires the admin panel be exposed to the internet, so on a deployment where the Administrator answers only from an internal or VPN-reached segment, the published path has no origin to come from. The access-control gap recorded against this entry is cited precisely because no account is authenticated anywhere on this path: the attacker holds no ColdFusion administrator credential, so per-account access rules are never consulted, and an access-control attestation showing every ColdFusion administrator named, provisioned and reviewed passes cleanly while the read succeeds. Distinguishing test: from an untrusted network segment, issue unauthenticated requests to the admin API / PMS servlet paths on a staging ColdFusion instance and confirm each is refused before any file is read. Preconditions: the endpoint-side authorization is a property the vendor update establishes — this control states what to verify, it does not implement it. Removing internet reachability bounds who can send the request, and the packet gives that reachability as the exploit's stated prerequisite, but it does not repair the access control: any caller inside the permitted segment still reaches it, so a compromised internal host, a jump box or a partner-network path satisfies the precondition in full, and the measure is unavailable where the Administrator must stay reachable for operational reasons. And because the primitive is an arbitrary file read with exploitation confirmed, an instance that was internet-reachable before remediation has to have the secrets held in the files it could serve treated as read and rotated — neither the update nor the segmentation recovers what already left.",
+        "evidence": "Packet fields for CVE-2024-20767 (Adobe ColdFusion Improper Access Control Vulnerability): cwe_refs CWE-284; vector 'ColdFusion versions 2023.6, 2021.12 and earlier are affected by an Improper Access Control vulnerability that could result in arbitrary file system read. An attacker could leverage this vulnerability to access or modify restricted files. Exploitation of this issue does not require user interaction. Exploitation of this issue requires the admin panel be exposed to the internet.'; attack_vector 'An unauthenticated attacker sends crafted requests to the ColdFusion admin API/PMS servlet to read arbitrary files on the server filesystem, exposed only because the admin panel itself was reachable from the internet.' cisa_kev true with kev_date 2024-12-16; active_exploitation confirmed; poc_available true; cvss 7.4; rwep_score 70. patch_available true, live_patch_available false, live_patch_notes null. Citing gaps recorded on this entry include ISO-27001-2022-A.5.15 (Access control) and NIST-800-53-SC-7 (Boundary Protection), alongside AU-Essential-8-Patch, NIST-800-53-SI-2, NIS2-Art21-vulnerability-management and UK-CAF-B4.",
+        "gap_closes": [
+          "ISO-27001-2022-A.5.15",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "This entry carries two independent conditions, and a scan verdict that checks only the first is paper compliance: the packet names the affected levels (ColdFusion 2023.6, 2021.12 and earlier) and separately states that exploitation requires the admin panel be exposed to the internet. Those two checks fail in opposite directions — a host at a fixed build whose Administrator still answers from the internet keeps every subsequent admin-surface defect on the published path, and a host below the fixed build that no untrusted network can route to is not on that path at all — so a vulnerability-management program that reports ColdFusion remediation as a build number has scored the wrong condition. The operational test this entry requires runs from outside: from each untrusted origin the panel could be reachable from, request the admin API / PMS servlet paths against every ColdFusion host and record whether anything answers, and report that result alongside the build level rather than in place of it. Precondition, and it is the one that makes this test worth anything: a reachability check proves only what is unreachable from the vantage point actually used. A host that one scan origin cannot route to may still answer through a cloud load-balancer rule, a partner link, a management VPN, or a hostname the scan never resolved, so a clean result from a single origin is not an exposure verdict — and an exposure check that has never returned a positive against a host known to be published is a broken check rather than a clean estate, and must be proven against a known-reachable instance before any absence is believed. The check also has to be applied retrospectively: the primitive is an arbitrary file read and exploitation is confirmed, so a host that answered externally at any point in the exposure window has to be handled as having served its files, which no version-based verdict will ever surface.",
+        "evidence": "Packet fields for CVE-2024-20767: the vector states 'ColdFusion versions 2023.6, 2021.12 and earlier are affected by an Improper Access Control vulnerability that could result in arbitrary file system read' and, separately, 'Exploitation of this issue requires the admin panel be exposed to the internet'; attack_vector records an unauthenticated attacker reading arbitrary files via the ColdFusion admin API/PMS servlet, 'exposed only because the admin panel itself was reachable from the internet'. cisa_kev true with kev_date 2024-12-16; active_exploitation confirmed; poc_available true; cvss 7.4; rwep_score 70; patch_available true. The citing gaps this addresses are the remediation-and-handling ones recorded on the entry: AU-Essential-8-Patch (Patch operating systems), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-50623": {
     "name": "Cleo Multiple Products Unrestricted File Upload Vulnerability",
@@ -39237,7 +39717,40 @@
         "adequate": false,
         "gap": "Apple's fix landed in Safari 18.1.1/iOS/macOS point releases, but the JIT memory-corruption bug was exploited as a zero-day, so patch-cadence controls could not prevent initial compromise."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The fix for this CVE is not one build, it is a list of them: 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. Bound to this entry the control means every enrolled Apple device is driven onto the build that corresponds to the train it is on, on the clock that opened with the 2024-11-21 KEV listing rather than the estate's normal update ring, with user deferral removed rather than discouraged — the trigger is processing maliciously crafted web content, so a single page load during a deferral window is sufficient and the exposure ends only when the device is actually running the fixed build. Completion has to be measured per device against the fixed build for its own train (17.7.2 on the 17 train, 18.1.1 on the 18 train, 15.1.1 on Sequoia); a fleet report that counts only the newest train, or that counts 'update approved/downloaded' as done, marks devices compliant while they still run the vulnerable code. Enumerate Intel-based Macs first, since that is the only population the packet attaches exploitation to. Precondition: the packet records a vendor patch and no live-patch path, so an update that is pending rather than applied changes nothing and the device must still be counted as exposed. And because the packet places this flaw chained with CVE-2024-44309 in a targeted campaign, a device that already loaded the attacker's content is an incident-response case, not a patch-compliance case — the fixed build removes the flaw, not what already executed.",
+        "evidence": "Packet: CISA KEV-listed 2024-11-21, active_exploitation confirmed, CVSS 8.8, RWEP 59, CWE-787, poc_available false. patch_available true, live_patch_available false, live_patch_notes null. Vector: 'This issue is 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. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems.' Attack vector: chained with the CVE-2024-44309 cookie XSS flaw in a targeted campaign.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's fix list names Safari 18.1.1 as its own fixed version alongside macOS Sequoia 15.1.1, so on the Mac side the OS build and the browser version are two separate facts and only one of them is what the exploit path runs through: the packet puts the defect in JavaScriptCore's DFG JIT compiler, reached by loading attacker-controlled web content. Applied to this CVE the control means the Mac estate's update policy can report, per machine, the Safari version actually in service and holds it to the same no-deferral security channel as the OS — a browser update batched into the general software catalogue or held for a weekly ring leaves the vulnerable rendering path live for the length of that ring against a flaw the packet records as already exploited. The distinguishing test is to produce the Safari version per Mac and confirm each is at or above 18.1.1: a compliance view built on macOS build number alone cannot answer that question, because the packet treats Safari as a separately versioned fix, and an estate that reports 'macOS current' while a Mac still runs a pre-18.1.1 Safari reads clean against a flaw-remediation attestation while remaining exploitable. Scope this to Macs — on the iOS, iPadOS and visionOS trains the packet's fixed builds are OS builds, so those devices are closed by the fleet update rather than by a browser channel. Precondition: the packet records no live-patch path, so the fixed version must actually be installed and running; a downloaded update is not a remediated browser. This control reaches only Macs the management console can see and update, and it does nothing for a machine that already rendered the attacker's page.",
+        "evidence": "Packet vector names Safari 18.1.1 as a fixed build distinct from macOS Sequoia 15.1.1, and states 'Processing maliciously crafted web content may lead to arbitrary code execution.' Attack vector: 'A victim on an Intel-based Mac loads attacker-controlled web content that triggers a register-corruption bug in JavaScriptCore's DFG JIT compiler, leading to arbitrary code execution.' patch_available true; live_patch_available false; live_patch_notes null. CISA KEV-listed 2024-11-21, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet's exploitation profile is narrow rather than commodity: no public PoC, RWEP 59 against CVSS 8.8, exploitation reported on Intel-based Mac systems, and the flaw observed chained with the CVE-2024-44309 cookie XSS in a targeted campaign. For the population that profile implicates — executives, journalists, legal and security staff — the control means those users' Apple devices sit in the vendor's reduced-attack-surface mode as a standing posture, so untrusted web content is not processed through the full engine and the delivery path into the JavaScriptCore DFG JIT register-corruption primitive is narrowed during the window between the 2024-11-21 KEV listing and the completed fleet update. The distinguishing test is to take a managed device from that cohort and confirm the mode is enforced by policy and cannot be switched off locally, rather than confirming the mode exists in a policy template — a least-functionality attestation that enumerates installed applications says nothing about which classes of web content a browser will process, which is the surface this CVE is reached through. Preconditions, and this is where the control is usually over-claimed: the mode helps only if it was already enabled when the campaign arrived, so it must be assigned before the next disclosure rather than in response to this one; it does not remove the vulnerable code from the device and is therefore a holding measure for the window before the fixed build, not a substitute for it; and it does nothing for a device that already rendered the attacker's page. Given the packet's chained cookie-XSS flaw, such a device belongs on the incident path with its session and cookie material treated as exposed.",
+        "evidence": "Packet attack_vector: 'A victim on an Intel-based Mac loads attacker-controlled web content that triggers a register-corruption bug in JavaScriptCore's DFG JIT compiler, leading to arbitrary code execution; observed chained with the CVE-2024-44309 cookie XSS flaw in a targeted campaign.' CWE-787; CVSS 8.8; RWEP 59; poc_available false; active_exploitation confirmed; CISA KEV-listed 2024-11-21; patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2024-21287": {
     "name": "Oracle Agile Product Lifecycle Management (PLM) Incorrect Authorization Vulnerability",
@@ -41815,7 +42328,32 @@
         "adequate": false,
         "gap": "SI-2 flaw remediation has no patch path for an EoL plugin; only removal mitigates, which SI-2 alone does not compel."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet names four separately-versioned products carrying this double free, not one: Adobe Flash Player, Adobe AIR on Android, the Adobe AIR SDK, and the Adobe AIR SDK & Compiler — and inside Flash Player the fixed build differs by operating system (11.7.700.269 and, for the 11.8.x through 12.0.x line, 12.0.0.70 on Windows and Mac OS X; 11.2.202.341 on Linux), while the three AIR products are fixed at 4.0.0.1628. Each is its own update track, so 'Flash is patched' is not a statement this estate can make from one inventory line: a Linux install at 11.2.202.341 is remediated and a Windows install below 11.7.700.269 is not, and a single software-inventory row reading 'Adobe Flash Player' cannot tell those apart. The control here is to enumerate every installed copy across the four tracks and every operating system the packet names, and confirm each reports at or above the fixed build for its own track, rather than closing the flaw-remediation ticket when the managed desktop image updates. The AIR SDK and AIR SDK & Compiler are the copies estates miss, because an SDK lives where development happens rather than on the desktop software inventory that drives endpoint patching, and the packet lists them as affected in their own right with their own fixed build — they need remediating whether or not the endpoint estate has been cleared. Scope the inventory to those products and no further: the packet ties this double free to Flash Player, Adobe AIR, the AIR SDK and the AIR SDK & Compiler, and gives no mapping from the vulnerable code into any other SWF-handling or media-parsing software, so instructing operators to treat every plugin or media renderer in the estate as an instance of this CVE manufactures findings and real removal work against software no evidence here implicates. Widen only where a verified source identifies another product carrying the same component. Distinguishing test: after the update lands, enumerate the Flash Player, AIR runtime and AIR SDK installs per platform and confirm none reports a build below the fixed one for its track — an estate that updates the browser-side plugin while a build machine keeps a pre-4.0.0.1628 AIR SDK still holds vulnerable code with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; a hand-installed or per-user copy is remediated by removing it, not by recording it as covered. Per the packet the vendor update needs no reboot, so an unremediated copy here is an inventory failure rather than a scheduling one. Terminal state, and this is what the version comparison above must not be mistaken for: Adobe Flash Player is end-of-life and receives no further fixes, so a copy sitting at the fixed build named here is current for this CVE and unpatched for every Flash defect found since. Reaching the fixed build is an interim state for a copy that cannot be removed today, not remediation. The requirement completes at removal of the Flash Player runtime and browser plugin, or replacement of whatever still depends on them; an estate that reports every install at or above the 2014 build and closes the finding has recorded parity with an abandoned product rather than removed the exposure. Where a business function still needs it, the honest record is an accepted exposure with a dated review and the runtime confined to hosts that reach nothing else — not a remediation entry. The AIR products named here are a separate case and must not inherit that conclusion: Adobe AIR was transferred to HARMAN and continues to be maintained, so for the AIR runtime and the AIR SDKs the terminal state is a supported, current build — patch parity is remediation there, and removing them is a decision about whether the dependency is still wanted, not a security requirement this CVE establishes.",
+        "evidence": "The packet's vector enumerates the affected products and their fixed builds: Adobe Flash Player before 11.7.700.269 and 11.8.x through 12.0.x before 12.0.0.70 on Windows and Mac OS X and before 11.2.202.341 on Linux, Adobe AIR before 4.0.0.1628 on Android, Adobe AIR SDK before 4.0.0.1628, and Adobe AIR SDK & Compiler before 4.0.0.1628, allowing remote attackers to execute arbitrary code, 'as exploited in the wild in February 2014'. CWE-415, CISA KEV-listed 2024-09-17, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 73. patch_available is true and live_patch_available is false; the packet's live-patch note states there is no live-patching primitive for this product and that the vendor update (no reboot required) is the remediation.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry reads unusually and an estate that treats the KEV listing as 'newly disclosed' will misprioritise it: the packet records the flaw as exploited in the wild in February 2014 and the KEV listing as 2024-09-17, so the listing is not the start of exploitation — it is notice that installs below the fixed builds are still being hit a decade after those builds shipped, which makes this an inventory-age problem being surfaced by a KEV date rather than a fresh disclosure. The SLA applies from the listing regardless: every Flash Player, Adobe AIR, AIR SDK and AIR SDK & Compiler copy the estate still runs must reach the fixed build for its own track inside the KEV window, or carry a documented, dated compensating control where a specific copy cannot get there in that window. Per the packet the vendor update requires no reboot, so there is no maintenance-window basis for deferral — the delay in practice is finding the copies, not scheduling a restart, which is why this clock is only meaningful when it runs against an enumeration spanning all four product tracks rather than a single desktop-software line item. Precondition: the SLA governs the clock, not the exploit path. It does nothing for the delivery half, because the packet's path is a crafted SWF served from a compromised or attacker-controlled page — the victim visits a site, with no download prompt or file to inspect — so between the listing and the completed update, exposure stands on any host that still has a vulnerable copy able to render page-supplied SWF content, and no policy setting in this packet closes it. And because active exploitation is confirmed, a host that rendered attacker-controlled content during that window is an incident-triage question the update does not answer: applying the fixed build removes the double free, not code that already executed in the plugin process. Terminal state, and this is what the version comparison above must not be mistaken for: Adobe Flash Player is end-of-life and receives no further fixes, so a copy sitting at the fixed build named here is current for this CVE and unpatched for every Flash defect found since. Reaching the fixed build is an interim state for a copy that cannot be removed today, not remediation. The requirement completes at removal of the Flash Player runtime and browser plugin, or replacement of whatever still depends on them; an estate that reports every install at or above the 2014 build and closes the finding has recorded parity with an abandoned product rather than removed the exposure. Where a business function still needs it, the honest record is an accepted exposure with a dated review and the runtime confined to hosts that reach nothing else — not a remediation entry. The AIR products named here are a separate case and must not inherit that conclusion: Adobe AIR was transferred to HARMAN and continues to be maintained, so for the AIR runtime and the AIR SDKs the terminal state is a supported, current build — patch parity is remediation there, and removing them is a decision about whether the dependency is still wanted, not a security requirement this CVE establishes.",
+        "evidence": "CISA KEV-listed 2024-09-17 with active_exploitation confirmed and poc_available true, while the packet's own vector records the flaw 'as exploited in the wild in February 2014' and names the fixed builds (Flash Player 11.7.700.269 and 12.0.0.70 on Windows and Mac OS X, 11.2.202.341 on Linux; Adobe AIR, AIR SDK and AIR SDK & Compiler 4.0.0.1628). patch_available is true, live_patch_available is false, and the live-patch note states the vendor update (no reboot required) is the remediation. The recorded attack vector is a crafted SWF served from a compromised or attacker-controlled page triggering a double free in the Flash plugin, corrupting memory and allowing arbitrary code execution in the browser plugin process. RWEP 73, CVSS 8.8.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2013-0648": {
     "name": "Adobe Flash Player Code Execution Vulnerability",
@@ -41852,7 +42390,31 @@
         "adequate": false,
         "gap": "Least-functionality controls that still permit the Flash browser plugin leave this client-side RCE reachable; the plugin must be removed, not merely patched."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "A vendor fix for this specific CVE exists — the packet's vector names the fixed Flash Player builds per platform — but the product carrying it has no ongoing patch path, so reaching a fixed build is an interim state and removing the Flash Player runtime is the terminal one. Applied here: enumerate every host that still has an Adobe Flash Player runtime installed and carry each to uninstall on a bounded, dated schedule rather than an open-ended risk acceptance. Until removal completes, block Flash content at the browser and the web gateway, because the packet's path begins with a user loading a page that serves a crafted SWF — an SWF that never reaches the runtime never reaches the ExternalInterface memory-corruption sink. Precondition, and the reason the block is a holding measure and not the fix: it covers only the browsing paths it actually mediates, and the vulnerable runtime stays installed and reachable by any SWF that gets to it through a path the policy does not sit on. Scope this to the Adobe Flash Player runtime the packet names; the packet ties the ExternalInterface sink to that product and gives no mapping into other browser plugins or media runtimes, so treating every plugin in the estate as an instance of this CVE manufactures removal work against software no evidence implicates. Distinguishing test: on a representative host, confirm the Flash runtime is absent rather than confirming the browser is configured to block it — a machine whose browser blocks Flash while the runtime remains installed still carries the vulnerable code, and a record that stops at 'this host is on the fixed build' marks a product that will receive no fix for anything found after that build as compliant.",
+        "evidence": "The packet places the flaw in the ExternalInterface ActionScript functionality of Adobe Flash Player (CWE-787, CWE-119) and describes the attack as luring a user to a page serving a malicious SWF, corrupting memory and executing arbitrary code in the Flash Player process; CVSS 8.8, RWEP 48, poc_available false, active_exploitation confirmed, CISA KEV-listed 2024-09-17. The entry cites NIST-800-53-CM-7 (Least Functionality) and AU-Essential-8-App-Hardening as insufficient, and its own framework_coverage for CM-7 records least-functionality controls that still permit the Flash browser plugin as leaving this client-side RCE reachable, with the plugin needing to be removed rather than merely patched. Its defense chain records the product as end-of-life and states that only decommissioning removes the exposure.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock for this entry opened on the 2024-09-17 KEV listing, and the 'verified mitigation' it demands cannot be a version bump: the entry records the product as end-of-life with no ongoing patch path, so the mitigation that satisfies the clock is removal of the Flash Player runtime from the host, or — where removal cannot complete inside the window — a documented, time-bound block of Flash content at the browser and gateway carrying a removal date. Why this has to be stated explicitly for a 2013 CVE is visible in the packet's own dates: the vector records exploitation in the wild in February 2013 and names the builds that fixed it, and CISA still listed the flaw in 2024 with confirmed in-the-wild exploitation — which only happens against installs that never reached those builds and were never removed. A vulnerability-management programme that reads this entry as 'get to the fixed build within the SLA' closes its ticket on a runtime that is frozen at a decade-old security state. Distinguishing test: for each host the KEV clock covers, produce evidence the runtime is gone, or that the content block is in force with a dated removal plan attached, rather than evidence that an installed version number is at or above the fixed build.",
+        "evidence": "The packet records CISA KEV listing on 2024-09-17 with active_exploitation confirmed, while its vector states the flaw was exploited in the wild in February 2013 and names the builds that fix it. patch_available is true and live_patch_notes records 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' RWEP 48 against CVSS 8.8, poc_available false. The entry cites ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management as insufficient, and its defense chain records removal — not patching — as the prevention step because the product is end-of-life.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2013-0643": {
     "name": "Adobe Flash Player Incorrect Default Permissions Vulnerability",
@@ -41931,7 +42493,7 @@
       {
         "id": "NEW-CTRL-018",
         "name": "SCANNER-PAPER-COMPLIANCE-TEST",
-        "description": "On this entry the fixed builds do not sort into one threshold, so a scan that compares a single version string is paper compliance regardless of how many hosts it covers. The packet gives 11.7.700.261 for the 11.7 branch, 12.0.0.44 for the 11.8.x-through-12.0.x range on Windows and Mac OS X, and 11.2.202.336 on Linux. A scanner set to 12.0.0.44 marks a correctly remediated 11.7.700.261 host and every correctly remediated Linux host at 11.2.202.336 as vulnerable, generating remediation work against systems already fixed; a scanner set to 11.7.700.261 passes every build in the 11.8.x-through-12.0.x range, all of which sort above that string while remaining affected until 12.0.0.44 — the direction that matters, because those hosts stay exposed with a clean report. The operational test for this entry is whether the scan resolves each install's branch and platform first and compares against the fixed build for that branch, rather than against any build merely newer than one of the three. Precondition: the check only reports on installs the scanner authenticates to and identifies by product. A per-user copy the scan does not resolve yields no finding, and no finding is indistinguishable from a clean host, so coverage has to be demonstrated by reconciling scan output against an independently built install inventory rather than by the absence of results. This control validates the comparison logic; it does not itself update anything.",
+        "description": "On this entry the fixed builds do not sort into one threshold, so a scan that compares a single version string is paper compliance regardless of how many hosts it covers. The packet gives 11.7.700.261 for the 11.7 branch, 12.0.0.44 for the 11.8.x-through-12.0.x range on Windows and Mac OS X, and 11.2.202.336 on Linux. A scanner set to 12.0.0.44 marks a correctly remediated 11.7.700.261 host and every correctly remediated Linux host at 11.2.202.336 as vulnerable, generating remediation work against systems already fixed; a scanner set to 11.7.700.261 passes every build in the 11.8.x-through-12.0.x range, all of which sort above that string while remaining affected until 12.0.0.44 — the direction that matters, because those hosts stay exposed with a clean report. The operational test for this entry is whether the scan resolves each install's branch and platform first and compares against the fixed build for that branch, rather than against any build merely newer than one of the three. Precondition: the check only reports on installs the scanner authenticates to and identifies by product. A per-user copy the scan does not resolve yields no finding, and no finding is indistinguishable from a clean host, so coverage has to be demonstrated by reconciling scan output against an independently built install inventory rather than by the absence of results. This control validates the comparison logic; it does not itself update anything. Terminal state, and this is what the version comparison above must not be mistaken for: Adobe Flash Player is end-of-life and receives no further fixes, so a copy sitting at the fixed build named here is current for this CVE and unpatched for every Flash defect found since. Reaching the fixed build is an interim state for a copy that cannot be removed today, not remediation. The requirement completes at removal of the Flash Player runtime and browser plugin, or replacement of whatever still depends on them; an estate that reports every install at or above the 2014 build and closes the finding has recorded parity with an abandoned product rather than removed the exposure. Where a business function still needs it, the honest record is an accepted exposure with a dated review and the runtime confined to hosts that reach nothing else — not a remediation entry.",
         "evidence": "Packet vector: 'Integer underflow in Adobe Flash Player before 11.7.700.261 and 11.8.x through 12.0.x before 12.0.0.44 on Windows and Mac OS X, and before 11.2.202.336 on Linux, allows remote attackers to execute arbitrary code via unspecified vectors.' CWE-191. 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.' CISA KEV-listed 2024-09-17, active_exploitation=confirmed, CVSS 9.8, RWEP 50.",
         "gap_closes": [
           "ISO-27001-2022-A.8.8",
@@ -41941,7 +42503,7 @@
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "Two things about this entry defeat the usual prioritisation inputs, and this control's 'later of KEV listing or patch availability' rule is what corrects both. First, the fixed builds date from 2014 while CISA listed the CVE on 2024-09-17, so the SLA clock opens at the listing — a Flash Player install still in service on that date is inside a same-day mitigation window, not a ten-year-old backlog item that age-sorting pushes below current work. Second, the packet records poc_available=false alongside active_exploitation=confirmed: an intake rule that starts its clock on public exploit-code publication never starts at all on this entry, even though the packet states the flaw is being exploited. The listing date, not PoC availability and not the CVE year, is the trigger. Applied here that means driving the fixed build for each branch — 11.7.700.261, 12.0.0.44 for the 11.8.x-through-12.0.x range, 11.2.202.336 on Linux — across every install on the KEV clock, with completion measured by each install reporting the fixed build for its own branch rather than by the update being approved or downloaded in a management console. Precondition: the control permits documented compensating controls in place of the binary fix, but the packet registers no vendor mitigation and no live-patch path for this product, so there is nothing to substitute — the vendor update, which the packet states requires no reboot, is the remediation. An install that cannot take it inside the window is an open, dated exception carried as exposed, not an SLA closure.",
+        "description": "Two things about this entry defeat the usual prioritisation inputs, and this control's 'later of KEV listing or patch availability' rule is what corrects both. First, the fixed builds date from 2014 while CISA listed the CVE on 2024-09-17, so the SLA clock opens at the listing — a Flash Player install still in service on that date is inside a same-day mitigation window, not a ten-year-old backlog item that age-sorting pushes below current work. Second, the packet records poc_available=false alongside active_exploitation=confirmed: an intake rule that starts its clock on public exploit-code publication never starts at all on this entry, even though the packet states the flaw is being exploited. The listing date, not PoC availability and not the CVE year, is the trigger. Applied here that means driving the fixed build for each branch — 11.7.700.261, 12.0.0.44 for the 11.8.x-through-12.0.x range, 11.2.202.336 on Linux — across every install on the KEV clock, with completion measured by each install reporting the fixed build for its own branch rather than by the update being approved or downloaded in a management console. Precondition: the control permits documented compensating controls in place of the binary fix, but the packet registers no vendor mitigation and no live-patch path for this product, so there is nothing to substitute — the vendor update, which the packet states requires no reboot, is the remediation. An install that cannot take it inside the window is an open, dated exception carried as exposed, not an SLA closure. Terminal state, and this is what the version comparison above must not be mistaken for: Adobe Flash Player is end-of-life and receives no further fixes, so a copy sitting at the fixed build named here is current for this CVE and unpatched for every Flash defect found since. Reaching the fixed build is an interim state for a copy that cannot be removed today, not remediation. The requirement completes at removal of the Flash Player runtime and browser plugin, or replacement of whatever still depends on them; an estate that reports every install at or above the 2014 build and closes the finding has recorded parity with an abandoned product rather than removed the exposure. Where a business function still needs it, the honest record is an accepted exposure with a dated review and the runtime confined to hosts that reach nothing else — not a remediation entry.",
         "evidence": "Packet: cisa_kev=true, kev_date 2024-09-17, active_exploitation=confirmed, poc_available=false, CVSS 9.8, RWEP 50. Vector gives fixed builds before 11.7.700.261, 11.8.x through 12.0.x before 12.0.0.44 on Windows and Mac OS X, and before 11.2.202.336 on Linux. attack_vector: 'An integer underflow during SWF parsing corrupts heap memory; a victim who loads an attacker-controlled Flash object (drive-by or malvertising) triggers arbitrary code execution in the browser context.' 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.'",
         "gap_closes": [
           "NIST-800-53-SI-2",
@@ -41985,7 +42547,41 @@
         "adequate": false,
         "gap": "Logical-access controls assume the admin password stays secret, but an unauthenticated SQLi extracts it — the control's trust boundary is bypassed rather than enforced."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "The packet places this defect on a WhatsUp Gold web endpoint that answers an unauthenticated caller, and the query behind it returns the stored encrypted user password. For this product the control means parameterization is proven at the query layer of the endpoints that answer without a session — those are the ones the packet's attack path uses — rather than inferred from an application input-validation layer or from a WAF fronting the console. That distinction is the reason the boundary-protection control cited against this entry does not close the path: the injection arrives as a well-formed request to an endpoint that is supposed to answer unauthenticated, so a perimeter rule tight enough to catch it also breaks legitimate monitoring traffic, and the query still concatenates on everything the rule lets through. Remediation is a build check the packet makes unambiguous: the flaw sits in versions released before 2024.0.0, and the packet records the vendor update as the remediation with no reboot required — so the usual objection that the monitoring server cannot be taken down does not apply to an update that does not take it down, and there is no live-patching primitive to wait for instead. Distinguishing test: against a staging WhatsUp Gold instance, send an unauthenticated request carrying a SQL metacharacter in the parameter the endpoint reads and confirm the query builder parameterizes it rather than returning stored password material — an attestation that the application validates input and sits behind a WAF passes while this endpoint keeps building the query by concatenation.",
+        "evidence": "Packet vector: 'In WhatsUp Gold versions released before 2024.0.0, a SQL Injection vulnerability allows an unauthenticated attacker to retrieve the users encrypted password.' attack_vector: 'An unauthenticated attacker sends a SQL injection payload to a WhatsUp Gold web endpoint to read the stored encrypted user password, then authenticates to the admin console and abuses monitoring tooling for code execution and lateral movement.' CWE-89; cvss 9.8; rwep_score 68; poc_available true; active_exploitation confirmed; CISA KEV-listed 2024-09-16; patch_available true; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' NIST SP 800-53 SC-7 (Boundary Protection) is among the framework controls this entry cites as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The packet's path does not stop at disclosure: the attacker reads the stored password, authenticates to the WhatsUp Gold admin console, and then abuses the monitoring tooling itself for code execution and lateral movement. That makes the WhatsUp Gold administrator a control-plane identity rather than an application administrator — the console's own legitimate capabilities are the execution vehicle, so downstream telemetry cannot separate the attacker's actions from an operator's, and collapsing this account into the generic 'admin' tier is what leaves it protected only by a password. Bound to this product, the control means console login is not satisfiable by a password alone: a phishing-resistant second factor at the console, an administrative identity used on no other system, and administrative access reached through a jump path rather than from general workstation segments. The second factor is the lever this specific CVE demands, because the primitive the packet describes yields a credential and nothing else — it is recovered with no interaction from the account owner at all, so every control premised on credential compromise happening through the user is out of the loop. Precondition, and this is where the control gets over-claimed: the factor blocks the packet's step-two console login; it does not stop step one. The unauthenticated read still returns the stored password material, so that material must be treated as disclosed and rotated wherever it was reused, and the factor gives nothing against a session or token already established during the exposure window. Distinguishing test: on a staging instance, attempt an admin-console login with a valid username and password and no second factor and confirm it is refused — the logical-access attestation this entry cites as insufficient asks whether console administrators are authorized, and in this attack every one of them is.",
+        "evidence": "Packet attack_vector: the attacker 'read[s] the stored encrypted user password, then authenticates to the admin console and abuses monitoring tooling for code execution and lateral movement.' Vector confirms the injection is reachable by an unauthenticated attacker and returns the stored encrypted user password. active_exploitation confirmed; poc_available true; CISA KEV-listed 2024-09-16; cvss 9.8; rwep_score 68. SOC 2 CC6 (Logical and Physical Access Controls) is among the framework controls this entry cites as insufficient.",
+        "gap_closes": [
+          "SOC2-CC6-logical-access"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "This entry's exposure outlives its own remediation, which is why an incident path is required alongside the update: the packet's primitive hands a stored password to an unauthenticated caller, and moving the instance to a build at or past 2024.0.0 stops further reads without invalidating anything already read. Bound to WhatsUp Gold, the playbook is to rotate the account passwords the packet says are stored and retrievable — and any credential reused from them on another system — then review the console's configured actions and monitoring tasks across the exposure window, because the packet names the monitoring tooling itself as the code-execution and lateral-movement vehicle, which makes a task or action added through the console the persistence mechanism to hunt for rather than a file on disk. Scope the review to the hosts the platform can act on, not to the monitoring server alone. The window to reconstruct runs from the 2024-09-16 KEV listing at the latest, and the packet's public-exploit flag means the capability was never limited to whoever found it. This also answers the security-monitoring gap cited on this entry, and answers it awkwardly: the asset under investigation is the estate's monitoring platform, so its own record of the period is a record an attacker holding console administration could alter, and the review has to be conducted against telemetry held where the console cannot write. Precondition: the playbook establishes what was done during the window and rotates what was exposed — it does not close the injection path, which only the vendor update does, and the packet records that update as requiring no reboot, so there is no sequencing excuse for running the investigation before remediating. Distinguishing test: for an instance that ran a build below 2024.0.0 while reachable, produce the rotation record for its stored credentials together with a diff of its configured actions across the exposure window; an instance closed out on the version upgrade alone has stopped the reads and left the consequences of the reads that already happened untouched.",
+        "evidence": "Packet vector: the injection 'allows an unauthenticated attacker to retrieve the users encrypted password' in versions released before 2024.0.0. attack_vector: the attacker 'then authenticates to the admin console and abuses monitoring tooling for code execution and lateral movement.' active_exploitation confirmed; poc_available true; CISA KEV-listed 2024-09-16; patch_available true; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' UK NCSC CAF C1 (Security monitoring) and SOC 2 CC6 (Logical and Physical Access Controls) are among the framework controls this entry cites as insufficient.",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "SOC2-CC6-logical-access"
+        ]
+      }
+    ]
   },
   "CVE-2024-43461": {
     "name": "Microsoft Windows MSHTML Platform Spoofing Vulnerability (CVE-2024-43461)",
@@ -43800,7 +44396,38 @@
         "adequate": false,
         "gap": "Payment-card patch requirements lag the near-immediate skimmer deployment on compromised commerce sites."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-133",
+        "name": "ECOMMERCE-PLATFORM-EXTENSION-UNTRUSTED-DESERIALIZATION-GUARD",
+        "description": "The packet's chain has two halves and only the first is the XXE. The crafted XML POSTed to Magento's guest-cart REST/GraphQL endpoint resolves an external entity and returns the store's encryption key and files; it is the object-injection step the packet names behind it that converts that read into remote code execution and the skimmer/webshell deployment recorded as the outcome. Bound to Adobe Commerce and Magento Open Source, the control means no unauthenticated storefront request path hands request-supplied data to a native deserializer (PHP unserialize() on this platform) — the guest-cart REST and GraphQL paths named in the packet first, then every path a third-party extension registers — and that the installed extensions are enumerated as part of the storefront's code-execution surface rather than treated as configuration sitting on top of a patched core. Distinguishing test: against a staging store, send an unauthenticated guest-cart request carrying a crafted serialized object in each cookie and header the installed extensions read, and confirm it is refused before any deserialization runs; a store that can produce a clean platform-patch attestation while an extension still deserializes request data has evidence for the core and none for the sink the packet's chain actually lands in. Precondition: this governs the object-injection sink, not the XXE parser. A store that closes every deserialization path still leaks the encryption key and readable files through the entity resolution until the vendor update lands, and the packet records no live-patch path — the update is the only thing that closes the read half. It also does nothing for a store already carrying skimmer or webshell content from the exposure window.",
+        "evidence": "The packet's attack_vector states the crafted XML is POSTed to Magento's guest-cart REST/GraphQL endpoint, that the parser resolves the entity leaking the encryption key and files, and that the flaw \"chained with object injection achieves remote code execution and skimmer/webshell deployment\" — the packet itself names object injection as the step that turns the read into execution. The vector adds that \"Exploitation of this issue does not require user interaction\" and lists Adobe Commerce 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier as affected (CWE-611). poc_available true, active_exploitation \"confirmed\", CVSS 9.8, RWEP 74. Citing gaps ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and PCI-DSS-4.0-6.3.3 (\"All system components are protected from known vulnerabilities by installing applicable security patches/updates\") are both patch-installation attestations.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "PCI-DSS-4.0-6.3.3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "What the packet describes an attacker walking away with — the store's encryption key, the files the parser could read, and a deployed skimmer or webshell — is not taken back by the vendor update. For an internet-facing Adobe Commerce or Magento storefront reached through this unauthenticated, no-user-interaction chain during a period of confirmed exploitation, the default response has to be to treat the host as compromised rather than remediated: rotate the encryption key and every credential and API token reachable from files readable by the web process, hunt the storefront and checkout render paths for injected skimmer script and for webshells, and rebuild from a known-good baseline where that hunt cannot be made conclusive. Distinguishing test is temporal rather than technical: ask what version the store was running before the update and whether the encryption key was rotated after it — a flaw-remediation record showing only \"updated to a fixed release\" attests to closing the parser while leaving a key the attacker may already hold in service, and the same signed-payload path stays open with the patched parser untouched. Precondition: this is an incident-response default, not a mitigation of the vulnerability. It presumes the vendor update is applied (the packet records it as available, with no live-patch path and no reboot required), and rotation only covers secrets the operator can enumerate — anything readable by the web process that is not inventoried stays valid after the rebuild.",
+        "evidence": "Packet records active_exploitation \"confirmed\" and poc_available true, and the attack_vector states the outcome as \"skimmer/webshell deployment\" reached after the entity resolution \"leaking the encryption key and files\". patch_available is true and live_patch_notes reads \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation\" — the packet records nothing that reverses the key disclosure or removes deployed skimmer/webshell content. KEV-listed 2024-07-17. Citing gaps NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling) are the attestations a completed update satisfies on its own.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the compressed clock is unusually well matched to what the packet records on both sides. On the threat side there is no access precondition for the attacker to satisfy: the entry point is a public storefront's guest-cart REST/GraphQL path, the vector states exploitation does not require user interaction, a PoC is public and exploitation is confirmed. On the remediation side the packet records a vendor update with no live-patch path but also no reboot requirement — for this product the update is a deploy, not an outage — so the control's requirement of a verified mitigation within 4 hours of the KEV listing or of patch availability, whichever is later, is actually achievable here rather than aspirational. Applied to Adobe Commerce and Magento Open Source: the store's clock starts at the 2024-07-17 KEV listing, and completion is measured by the version the storefront is running, not by a change ticket reaching approved. Distinguishing test: pull the running version from the storefront itself and compare it against the affected list the packet names, rather than accepting the deployment pipeline's record of what it pushed. Precondition: an SLA governs the length of the window, not what happened inside it. A store that meets the clock but was reachable earlier is patched, not clean, and belongs on the incident path — the KEV listing marks when the obligation starts, not when exploitation started.",
+        "evidence": "cisa_kev true with kev_date 2024-07-17; active_exploitation \"confirmed\"; poc_available true; CVSS 9.8; RWEP 74. The vector states \"Exploitation of this issue does not require user interaction\" and the attack_vector places the entry point on an unauthenticated POST to Magento's guest-cart REST/GraphQL endpoint. patch_available true; live_patch_notes: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" Citing gap AU-Essential-8-Patch (Patch operating systems).",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-36401": {
     "name": "OSGeo GeoServer GeoTools Eval Injection Vulnerability",
@@ -44623,7 +45250,29 @@
         "adequate": false,
         "gap": "SI-3 malicious-code protection trusted a signed, vendor-distributed installer and failed to catch the embedded supply-chain backdoor."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-132",
+        "name": "INDEPENDENT-INTEGRITY-VERIFICATION-OF-SIGNED-VENDOR-INSTALLERS",
+        "description": "The defect here is not in JAVS Viewer's code — it is that the installer users pulled from the vendor's own supply chain, Viewer Setup 8.3.7.250-1, contained a malicious binary and was signed with an unexpected Authenticode signature. A signature check on that download returns a valid answer to the wrong question: the file is signed, and signed by a certificate the installing organization never established as this vendor's. Bound to this product, the control means JAVS Viewer builds are not installed onto courtroom recording hosts straight from the vendor download page, but pulled into managed software distribution and checked against an integrity source independent of the download itself — a vendor-published per-release hash obtained over a separate channel, or the signer identity pinned to the certificate the vendor's prior releases carried — before any endpoint is permitted to run them. Distinguishing test: take the version string and the Authenticode signer of the JAVS Viewer build actually installed on each recording host and compare the signer against the pinned vendor identity, not merely against \"signed and trusted\" — a software-installation policy that requires signed installers accepts 8.3.7.250-1 without complaint, which is precisely what the packet records happening. Precondition: this control governs the intake decision and gives nothing to a host that already ran the trojanized installer. The packet records that installer dropping fffmpeg.exe, beaconing to a C2 server and executing unauthorized PowerShell to grant attacker control of the host, so a host that installed 8.3.7 is an incident — installing the vendor's clean build over the top does not remove what the attacker placed or revoke what it already took.",
+        "evidence": "Packet vector: \"Justice AV Solutions Viewer Setup 8.3.7.250-1 contains a malicious binary when executed and is signed with an unexpected authenticode signature. A remote, privileged threat actor may exploit this vulnerability to execute of unauthorized PowerShell commands.\" attack_vector: \"Users downloaded a trojanized JAVS Viewer 8.3.7 installer from the vendor's supply chain; the installer dropped a malicious fffmpeg.exe that beaconed to a C2 server and executed unauthorized PowerShell, granting attacker control of the courtroom recording host.\" CWE-506 (embedded malicious code); cisa_kev true, kev_date 2024-05-29; active_exploitation \"confirmed\"; CVSS 8.7; RWEP 42; poc_available false. Citing gaps NIST-800-53-SI-3 (Malicious Code Protection), ISO-27001-2022-A.8.7 (Protection against malware) and AU-ISM-1546 (Patch operating systems and applications).",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock applies, but for this entry what has to be deployed inside it is not only the vendor's clean build. The packet's malicious artifact is the installed product: a host running Viewer Setup 8.3.7.250-1 holds a dropped fffmpeg.exe that beacons to a C2 server and executes unauthorized PowerShell, so the state the SLA must close is the presence of that build on courtroom recording hosts, and \"verified mitigation\" for this CVE means the trojanized installation is removed and the host rebuilt — not that a newer installer was made available. The packet supports a fast clock on the remediation side: a vendor update exists with no live-patch path and no reboot requirement. Distinguishing test: enumerate hosts by the JAVS Viewer version actually installed and by the presence of the dropped fffmpeg.exe, and confirm each affected host was rebuilt rather than upgraded in place — an estate that verifies the installer currently on the vendor's download page is clean has tested the wrong artifact, since the malicious one is already resident. Where a recording host cannot be taken out of service immediately, the only interim lever the packet supports is watching for the behaviour it documents: outbound connections from the dropped fffmpeg.exe and PowerShell execution originating from the JAVS installation path. That is a detection, and it bounds dwell time rather than removing attacker control — a host that beacons has already granted it.",
+        "evidence": "cisa_kev true with kev_date 2024-05-29; active_exploitation \"confirmed\"; RWEP 42; poc_available false. patch_available true with live_patch_notes \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" The attack_vector records the installed product itself as the malicious artifact — the dropped fffmpeg.exe \"beaconed to a C2 server and executed unauthorized PowerShell, granting attacker control of the courtroom recording host\" — and the vector records the same PowerShell outcome. Citing gap NIS2-Art21-vulnerability-handling (Cybersecurity risk-management measures — vulnerability handling and disclosure).",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-5274": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2024-5274)",
@@ -44711,7 +45360,29 @@
         "adequate": false,
         "gap": "The Flink JobManager REST/dashboard (default 8081) is frequently exposed to the internet; boundary protection is the primary missing control since Flink offers no built-in auth on this interface."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-094",
+        "name": "AI-RUNTIME-API-PATH-TRAVERSAL-VALIDATION",
+        "description": "The Flink JobManager's REST interface serves a log file selected by a caller-supplied path, and the packet names the bypass precisely: double-URL-encoded '../' sequences. That is the signature of containment enforced by inspecting the request string instead of by resolving the path — one decode pass strips the outer encoding, the filter runs against what it sees, and the traversal that finally reaches the filesystem was never the string the filter examined. For this component the requirement is that the JobManager resolve the requested log path to an absolute canonical form and verify the result is still under the permitted log directory immediately before the file handle is opened, rejecting absolute paths, residual '../' segments, and symlinks that leave the directory — the check belongs at path resolution, not at request parsing. The read direction is the entire exposure here: the packet scopes the leak to any file the JobManager process can read and names config, credentials and /etc/passwd, so the identity that process runs as decides what a single unauthenticated GET returns, and tightening the JobManager's own filesystem reach limits the blast radius of the next traversal defect as well as this one. Distinguishing test: against a staging JobManager, request the log endpoint with singly-encoded and doubly-encoded traversal sequences and confirm both are refused at path resolution — a deployment that rejects the plain '../' form and returns a file for the encoded one has a filter, not containment, and that is the exact difference this CVE turns into an arbitrary file read. Precondition: this states the property the vendor fix establishes, it does not implement it. The packet gives Flink 1.11.3 and 1.12.0 as the upgrade targets for the affected 1.11.0, 1.11.1 and 1.11.2 releases and records no live-patch path, so an operator still running an affected release gets nothing from this control by itself.",
+        "evidence": "attack_vector: \"An unauthenticated attacker sends a GET to the Flink JobManager REST logs endpoint with double-URL-encoded '../' sequences, causing the process to return the contents of any file it can read (config, credentials, /etc/passwd).\" vector: the change introduced in Apache Flink 1.11.0 \"allows attackers to read any file on the local filesystem of the JobManager through the REST interface of the JobManager process. Access is restricted to files accessible by the JobManager process. All users should upgrade to Flink 1.11.3 or 1.12.0 if their Flink instance(s) are exposed.\" CWE-552; poc_available true; active_exploitation \"confirmed\"; cisa_kev true, kev_date 2024-05-23; CVSS 7.5; RWEP 65. patch_available true; live_patch_notes: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" Citing gaps ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-088",
+        "name": "AI-COMPUTE-CONTROL-PLANE-AUTHENTICATION",
+        "description": "The exploit in the packet is an unauthenticated GET, and nothing about it is subtle: the JobManager's REST interface — the control plane through which jobs are submitted and the cluster is managed — answers a caller who has presented no credential, and the vector's own upgrade instruction is conditioned on whether the instance is \"exposed\", which is deployment posture doing the security work instead of the service. For a Flink cluster the control means that REST interface is reachable only from segments with an operational need to submit or manage jobs, and is fronted by an authenticating proxy so a caller is identified before the endpoint is consulted, because \"the cluster is on an internal network\" is an assumption about topology rather than an access-control decision — and it is exactly the assumption this CVE converts into an arbitrary file read. It also means a cluster that was reachable during the exposure window is treated as having disclosed whatever the JobManager account could read: the packet names config and credentials among the returned content, and moving to a fixed release does not invalidate a credential already read out, so rotating what the JobManager could reach is part of remediation rather than a follow-up item. Distinguishing test: from a general workstation or application VLAN, and from outside the estate, issue an unauthenticated GET to the JobManager REST endpoint on a staging cluster and confirm it is refused before reaching the service — a cluster whose vulnerability-management record shows the fixed release while its control plane still answers unauthenticated callers has closed this traversal and left the next one fully exposed. Precondition: restricting reachability bounds who can send the request, it does not repair the endpoint, and any host already inside a permitted segment — a compromised application server, a CI runner, a jump host — satisfies the exploit's only stated access requirement in full. It is a holding measure for clusters not yet on 1.11.3 or 1.12.0, not a substitute for them.",
+        "evidence": "The packet's attack_vector requires no credential: \"An unauthenticated attacker sends a GET to the Flink JobManager REST logs endpoint...\" The vector conditions its remediation instruction on exposure — \"All users should upgrade to Flink 1.11.3 or 1.12.0 if their Flink instance(s) are exposed\" — and scopes the returned content to \"any file it can read (config, credentials, /etc/passwd)\", with access \"restricted to files accessible by the JobManager process\". active_exploitation \"confirmed\"; poc_available true; KEV-listed 2024-05-23. patch_available true; live_patch_notes: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" Citing gaps 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-4947": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2024-4947)",
@@ -44946,7 +45617,32 @@
         "adequate": false,
         "gap": "The affected DIR-600 revisions are end-of-life with no forthcoming fix, so flaw-remediation via patching is impossible and the only remedy is device retirement."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet carries two facts that must be resolved per unit before anything else: patch_available is recorded as false, and live_patch_notes states that firmware after 2.17b02 addressed the original issue only for supported revisions while rev. Bx hardware is end-of-life/end-of-service. So the first requirement is an inventory that names every DIR-600 in service with its hardware revision, taken from the device rather than assumed from the model name. A unit whose revision still receives vendor firmware is one class of item; a rev. Bx unit is a different class entirely, because there is no build it can be moved to and its only resolution is replacement on a dated schedule. Bound to this device, that distinction is invisible without the revision: an asset register that records 'D-Link DIR-600' cannot tell an operator which of its routers the firmware covers, and a risk acceptance with no removal date leaves a KEV-listed router with a public exploit answering hedwig.cgi, pigwidgeon.cgi and diagnostic.php indefinitely. Distinguishing test: read the hardware revision off every DIR-600 in the estate and confirm each rev. Bx unit carries a dated replacement commitment rather than a firmware ticket that will never close; a scanner that reports the model as current because it sees a firmware string at or above 2.17b02, without reading the revision, reports paper compliance on hardware that firmware does not cover.",
+        "evidence": "Packet records patch_available: false and live_patch_notes: 'Affected DIR-600 (rev. Bx) hardware is end-of-life/end-of-service; vendor guidance is retirement and replacement. Firmware after 2.17b02 addressed the original issue only for supported revisions.' Packet vector names D-Link DIR-600 router (rev. Bx) with firmware before 2.17b02 and the endpoints hedwig.cgi, pigwidgeon.cgi and diagnostic.php. CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available true, CVSS 8.0, RWEP 77.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "There is no firmware a rev. Bx DIR-600 owner can move to, so on this entry remediation means removal and the interim measure has to be stated precisely, because the usual segmentation answer does not hold. The packet's path is a lure: an authenticated router administrator is drawn to a malicious page that auto-submits forged requests to hedwig.cgi, pigwidgeon.cgi and diagnostic.php to create an administrator account, enable remote management, or activate new configuration settings. The request therefore originates inside the administrator's own browser and arrives on an already-authenticated session, so blocking the router's admin surface at a network boundary does nothing — the browser is already on the permitted side, and the attacker never authenticates to the device at all. Applied to this router, the compensating measure is that the DIR-600 web administration surface must not be loadable from any network or browser profile an administrator also browses the general web from, that no administrator holds a live session to the router while browsing elsewhere, and that every surviving rev. Bx unit sits on a dated decommission schedule rather than an open-ended acceptance. Preconditions, and why this is a holding measure rather than a fix: none of it restores the missing request-origin validation, so any administrator who legitimately opens the router UI from a general-purpose browser satisfies the exploit's only access requirement in full; and disabling remote management is not durable protection here, because the packet lists enabling remote management as one of the actions the forged request itself performs — its value is limited to denying an external attacker a direct path, not to preventing the lure. Distinguishing test: from the workstation and browser profile an administrator actually uses, confirm the router's admin pages cannot be loaded in the same session context used for general web browsing, and read remote-management state off the device itself rather than from a configuration template, since the flaw's own effect is to change it.",
+        "evidence": "Packet attack_vector: 'An attacker lures an authenticated router administrator to a malicious page that auto-submits forged requests to hedwig.cgi/pigwidgeon.cgi/diagnostic.php, hijacking the admin session to create accounts, enable remote management, or change settings.' Packet vector enumerates the same actions, including enabling remote management via a crafted configuration module to hedwig.cgi and activating settings via a SETCFG,SAVE,ACTIVATE action to pigwidgeon.cgi; cwe_refs CWE-352. patch_available: false; live_patch_notes records rev. Bx as end-of-life/end-of-service with retirement and replacement as vendor guidance. CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-30040": {
     "name": "Microsoft Windows MSHTML Platform Security Feature Bypass Vulnerability",
@@ -45109,7 +45805,19 @@
         "adequate": false,
         "gap": "Password-only authentication is fully defeated once the reset email is redirected; without enforced MFA the identity control permits complete takeover, so it is inadequate against this flaw."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The exposure this SLA tier governs on GitLab is fully unauthenticated and needs no foothold to start: the attacker submits the password-reset form supplying multiple email addresses, GitLab delivers the reset link to the attacker-controlled unverified address, and the attacker sets a new password. There is no login step for a monthly patch window to hide behind and no credential to rate-limit — every self-managed instance on an affected release is reset-able by anyone who knows a target account's address, and the affected range spans seven 16.x lines (16.1 through 16.7). The packet records a vendor update with no live-patch primitive but explicitly no reboot requirement, which is what makes the expedited branch of this control real rather than aspirational here: moving an instance to the fixed release in its own 16.x line is a service upgrade, not a maintenance-window event, so a 14- or 30-day cadence is the wrong tier for a KEV-listed pre-authentication account-takeover path with a public exploit. Precondition on the residual half, and it is the part a patch record will not show: the packet ties completion of the takeover to 2FA being absent, so a second factor blocks the takeover but does not prevent the reset itself, and the upgrade bounds new attempts without undoing one that already succeeded — any account that could have been reset during the exposure window must have its password, personal access tokens and session state treated as attacker-known irrespective of the upgrade. Distinguishing test: on a staging instance running the operator's pre-upgrade version, submit the reset form for a known account with a second, attacker-controlled address and confirm no reset link reaches it; an attestation that 'GitLab is patched on the monthly cycle' passes cleanly while an affected 16.x instance stays reset-able for the whole cycle.",
+        "evidence": "Packet vector: 'An issue has been discovered in GitLab CE/EE affecting all versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.3 prior to 16.3.7, 16.4 prior to 16.4.5, 16.5 prior to 16.5.6, 16.6 prior to 16.6.4, and 16.7 prior to 16.7.2 in which user account password reset emails could be delivered to an unverified email address.' Packet attack_vector: unauthenticated attacker submits the reset form supplying multiple email addresses and takes over the account 'when 2FA is absent'; cwe_refs CWE-640. patch_available: true; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' CISA KEV-listed 2024-05-01, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 70.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-29988": {
     "name": "Microsoft SmartScreen Prompt Security Feature Bypass Vulnerability",
@@ -45206,7 +45914,30 @@
         "adequate": false,
         "gap": "Boundary controls leave the CrushFTP WebInterface publicly reachable, and the SSTI rides normal HTTPS so a firewall does not stop it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The CrushFTP WebInterface is the internet-facing half of a managed file-transfer deployment, and the packet's path asks nothing of the attacker but the ability to send it a request: server-side template-injection syntax is rendered by the server, escaping the VFS sandbox to read arbitrary files including configuration and session data, bypassing authentication to administrative access, and executing code. All versions before 10.7.1 and 11.1.0 on all platforms are affected, so the exposed population is every instance until it is moved. The packet records no live-patching primitive but explicitly no reboot requirement, which is what makes the expedited branch of this control real on this product: bringing an instance to 10.7.1 or 11.1.0 is a service upgrade rather than a maintenance-window event, so a 14- or 30-day tier is the wrong clock for a KEV-listed unauthenticated path to admin and code execution with a public exploit. Precondition, stated because this is where operators reach for the wrong lever: segmentation is not available as the interim measure on an externally published instance, since the WebInterface is reachable by design for the users the service exists to serve; where an instance serves only internal users, restricting which segments can reach it bounds who can send the injection but leaves it fully exploitable to anything inside the permitted segment, and it is unavailable wherever the interface must stay published for normal operation. Distinguishing test: enumerate the running version on every CrushFTP instance and confirm each is at or above 10.7.1 or 11.1.0; a vulnerability-management attestation that cites the organisation's standard patch cadence passes cleanly while a published pre-10.7.1 instance stays unauthenticated-RCE-able for the length of that cadence.",
+        "evidence": "Packet vector: 'A server side template injection vulnerability in CrushFTP in all versions before 10.7.1 and 11.1.0 on all platforms allows unauthenticated remote attackers to read files from the filesystem outside of the VFS Sandbox, bypass authentication to gain administrative access, and perform remote code execution on the server.' cwe_refs CWE-1336 and CWE-94. patch_available: true; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' CISA KEV-listed 2024-04-24, active_exploitation confirmed, poc_available true, CVSS 10, RWEP 72.",
+        "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": "The packet's own ordering is why upgrading CrushFTP is not the same as remediating it. Before the attacker reaches code execution they have already read files from outside the VFS sandbox — the attack_vector names configuration and session data specifically — and bypassed authentication to hold administrative access, all without a credential. Moving the instance to 10.7.1 or 11.1.0 removes the template-rendering path; it does not invalidate a session token or an administrative credential the attacker lifted out of the configuration, and it does not remove accounts, VFS definitions, scheduled jobs or files an admin-level attacker left on a server whose entire purpose is storing and moving other people's data. Bound to this product, the default response for any instance that ran an affected version while exposed is: treat the CrushFTP configuration and every secret in it as disclosed, rotate the administrative and service credentials and any keys the server held, invalidate all sessions, compare user and VFS definitions and scheduled jobs against a known-good baseline, and rebuild from that baseline rather than upgrade in place wherever the exposure window cannot be bounded from logs. Precondition and its hard limit: this bounds what the attacker retains going forward, and it does nothing about what already left — anything the sandbox escape could read is disclosed permanently, so rotating the credentials those files contained is the only recourse, and rotation is only complete if it covers credentials that were valid at any point in the window, not just the ones current at upgrade time. Distinguishing test: for each instance, produce evidence that the admin credential, service account and session keys were rotated after the upgrade and that user and VFS definitions were diffed against a baseline; a flaw-remediation record showing only 'upgraded to 11.1.0' is a patched host that may still be answering to its attacker.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends a request with server-side template-injection syntax to the CrushFTP WebInterface; the server renders the expression, escaping the VFS sandbox to read arbitrary files (config/session data), bypass authentication to gain admin, and execute code.' Packet vector confirms the same three outcomes for all versions before 10.7.1 and 11.1.0 on all platforms. active_exploitation: confirmed; CISA KEV-listed 2024-04-24; poc_available true; CVSS 10; RWEP 72. patch_available: true with live_patch_notes stating the vendor update (no reboot required) is the remediation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-20359": {
     "name": "Cisco ASA and FTD Privilege Escalation Vulnerability",
@@ -45280,7 +46011,40 @@
         "adequate": false,
         "gap": "SC-7 treats the firewall as the boundary, but the vulnerable web service runs on that same edge appliance, so the control cannot protect the device that enforces it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The vulnerable code sits in the management and VPN web servers of Cisco ASA and Cisco FTD — the appliance that is itself the trust boundary — and the packet's path needs no credential: an unauthenticated remote attacker sends a crafted HTTP request, incomplete error checking while parsing an HTTP header drives an infinite loop (CWE-835), and the device reloads. For this CVE the tier means the vendor update runs on a clock that opened at the 2024-04-24 KEV listing rather than being folded into the next appliance maintenance window, and completion is measured per unit by the reload the update requires having actually been taken: the packet records patch_available true with no live-patch path and states the vendor update requires a reboot, so an appliance staged with the fixed image but not yet reloaded is still running the vulnerable parser and must be counted as exposed. Precondition on the isolation half of this control, which is where it is usually over-claimed on ASA/FTD: restricting which networks can reach the management web server bounds one of the two surfaces the packet names, but the VPN web server has to answer unauthenticated requests from untrusted networks to do its job, so on any unit terminating remote-access VPN there is no segment that removes the path — isolation shrinks the management-side surface while the reload is scheduled, it is not an alternative to the update. Distinguishing test: produce, per appliance, the running image and the time of its last reload, and show the reload post-dates the update; a boundary-protection or flaw-remediation attestation that reads 'update deployed' off the management console records an appliance still running the vulnerable image as remediated.",
+        "evidence": "Packet fields: cisa_kev true, kev_date 2024-04-24, active_exploitation 'confirmed', cvss 8.6, rwep_score 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.' Vector places the flaw in 'the management and VPN web servers for Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software', reachable by 'an unauthenticated, remote attacker', 'due to incomplete error checking when parsing an HTTP header', exploited 'by sending a crafted HTTP request to a targeted web server on a device'. cwe_refs CWE-835. Citing gaps include NIST-800-53-SC-7 Boundary Protection, NIST-800-53-SI-2 Flaw Remediation and AU-ISM-1546 Patch operating systems and applications.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at the denial of service: it records that in ArcaneDoor this flaw was chained with CVE-2024-20359 for implant persistence. That is what makes 'the appliance reloaded, we then updated it' the wrong close-out for an ASA or FTD that showed the documented behaviour during the exposure window — the update changes the running image, it does not answer whether anything was left behind on the box. For this CVE the control means such a unit is handled as a compromised device rather than a patch item: preserve and export its configuration for analysis, rebuild from vendor-supplied image plus a known-good configuration instead of upgrading in place, and rotate the secrets the appliance held (VPN key material, administrative credentials, certificates) along with any account that authenticated through it during the window. Precondition, stated plainly because this control is expensive if applied blindly: this is triage for units with evidence of the path, not a blanket estate rebuild. The packet gives no on-box indicator, only the unexpected reload as the visible symptom, so the trigger is an unexplained reload correlated with inbound requests to the management or VPN web server; a unit with no such record is an update item under the SLA tier. And the rebuild is only as trustworthy as its source — an image or configuration restored from the suspect device's own storage carries forward whatever was written there. Distinguishing test: take an appliance that reloaded during the exposure window, apply the vendor update, then ask what evidence exists that nothing persisted across it. A flaw-remediation attestation answers 'the image version is current', which is not an answer to implant persistence.",
+        "evidence": "Packet attack_vector: 'An unauthenticated remote attacker sends a crafted HTTP request to the ASA/FTD management or VPN web server; incomplete HTTP-header error checking triggers an infinite loop (CWE-835) that reloads the device, causing denial of service. In ArcaneDoor it was chained with CVE-2024-20359 for implant persistence.' active_exploitation 'confirmed'; cisa_kev true, kev_date 2024-04-24. patch_available true with live_patch_available false and live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gaps include NIST-800-53-SI-2 Flaw Remediation and UK-CAF-B4 System security.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The only symptom the packet gives is the device reloading unexpectedly, and the same packet places this flaw in a chain that ends in implant persistence on that same appliance — so the record that distinguishes a hardware fault from exploitation cannot be allowed to live only on the ASA or FTD itself. For this CVE the control means syslog and the management/VPN web servers' request and authentication records are forwarded continuously to a collector in a separate trust zone, with its own credentials and its own management path, retained across the appliance's reloads, so an analyst can ask after the fact whether a reload was preceded by requests to those web servers from an untrusted source. The detection keys on exactly what an exploit doing what the packet describes emits: an unauthenticated HTTP request to the management or VPN web server followed by an unscheduled reload of that device, and the repetition of that pair across attempts or across appliances — not on a crash signature, because the crash record is produced by the device under attack, and not on authentication events, because the attacker never authenticates. Precondition: this preserves and surfaces evidence, it does not prevent the reload and it is not a mitigation for the flaw. It is also only as good as the window it covers — an appliance whose forwarding was not already configured before the exposure window has no retrospective record to consult — and the collector must not authenticate back through the appliance it is monitoring, or the compromise of that appliance takes the evidence path with it.",
+        "evidence": "Packet vector: the flaw 'could allow an unauthenticated, remote attacker to cause the device to reload unexpectedly, resulting in a denial of service (DoS) condition', triggered 'by sending a crafted HTTP request to a targeted web server on a device'. attack_vector adds 'In ArcaneDoor it was chained with CVE-2024-20359 for implant persistence.' active_exploitation 'confirmed'; cisa_kev true, kev_date 2024-04-24; poc_available false. Citing gap NIS2-Art21-network-security (Security of network and information systems).",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2022-38028": {
     "name": "Microsoft Windows Print Spooler Privilege Escalation Vulnerability",
@@ -45428,7 +46192,40 @@
         "adequate": false,
         "gap": "No patch will ever ship — the devices are end-of-life — so flaw-remediation is unattainable; the only remediation is retirement, which asset-owners routinely fail to perform for cheap NAS boxes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "There is no update to apply here. The packet records patch_available false and states the vendor confirmed the product is end-of-life and that it should be retired and replaced, so for the DNS-320L, DNS-325, DNS-327L and DNS-340L units in service the remediation is removal on a dated schedule and nothing else — neither 'we will update it' nor an open-ended risk acceptance is an available disposition on a device whose exploit has been publicly disclosed and whose exploitation is confirmed. Applied to these NAS units: enumerate every one in service, give each a removal date, and settle the data migration target first, because the appliance exists to hold the data and pulling it without somewhere for the data to go is what converts a removal into an indefinite deferral. Precondition on the interim measure, which is where this gets over-claimed: until the unit is gone, restricting reachability of its HTTP interface bounds who can send the GET to /cgi-bin/nas_sharing.cgi, but it does not close the path — the credential ships inside the product, so every host still permitted to reach the device satisfies the attacker's only requirement. And because exploitation is confirmed and the exploit is public, a unit that was exposed to the internet through a router port-forward or UPnP mapping at any point in the exposure window has to be handled as already reached: the data it stored and any credentials it held are exposed regardless of what happens to the hardware afterwards, so removal alone does not close that half. Distinguishing test: for each unit produce a decommission date and the migration target. A vulnerability-management record that carries these models as 'no patch available, risk accepted' with no removal date is exactly the outcome this control exists to catch.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes 'No patch — affected D-Link NAS models are end-of-life/end-of-service; vendor guidance is to retire and replace the hardware.' Vector: '** UNSUPPORTED WHEN ASSIGNED ** ... D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403 ... /cgi-bin/nas_sharing.cgi of the component HTTP GET Request Handler ... 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.' cisa_kev true, kev_date 2024-04-11, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 81. Citing gaps include AU-Essential-8-Patch, NIST-800-53-SI-2 Flaw Remediation and NIS2-Art21-vulnerability-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "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's path reaches that data with no credential at all: an HTTP GET to /cgi-bin/nas_sharing.cgi with the argument user set to messagebus, which — chained with the companion command-injection flaw the packet names — yields unauthenticated remote code execution on the box holding the data. Since the packet records no available fix, reachability is the only lever the operator holds while the units are still in service. For the DNS-320L, DNS-325, DNS-327L and DNS-340L that means the device's web 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 branches normally acquires its exposure. Constrain the appliance's outbound path too, so a unit that has already been reached cannot ship what it stores to an arbitrary destination. Precondition: this bounds the population that can send the request; it does not remove the flaw and must not be recorded as closure. Any host inside the permitted segment still meets the attacker's only requirement, because the credential travels with the product rather than being obtained from the site — and it does nothing for a unit already reached during the exposure window. 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 published 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 attacker sends an HTTP GET to /cgi-bin/nas_sharing.cgi using the hardcoded messagebus account (empty password); chained with the companion command-injection flaw this yields unauthenticated remote code execution on end-of-life D-Link NAS devices.' Vector names D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403, the /cgi-bin/nas_sharing.cgi HTTP GET Request Handler, and states 'The attack may be initiated remotely.' patch_available false; live_patch_notes 'No patch — affected D-Link NAS models are end-of-life/end-of-service; vendor guidance is to retire and replace the hardware.' poc_available true; active_exploitation 'confirmed'. Citing gap NIST-800-53-SC-7 Boundary Protection.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The secret in this CVE ships inside the product: the packet's manipulation is the argument user set to messagebus, a hard-coded account with an empty password in the device's HTTP GET request handler (CWE-798). No operator-side credential hygiene touches that exposure — the attacker never uses an account the site created, and there is nothing for the operator to rotate away. That is precisely why the identity-and-access and least-functionality gaps sit on this entry: an attestation showing every NAS administrator holds a unique, strong credential passes cleanly while this path stays fully open, and the vulnerable handler is not a service the operator can turn off on the device. For this estate the control means inventorying devices by whether they authenticate through a vendor-shipped credential the operator cannot change or remove, flagging the DNS-320L, DNS-325, DNS-327L and DNS-340L population on that basis rather than on account policy, and re-running the check after any unit is factory-reset, re-imaged or re-attached to the network — those are the operations that quietly return a device thought to be gone to service. Precondition: because the packet records no fix and vendor guidance is retirement, this detection feeds the decommission decision; it does not reduce the exposure of a unit that stays in service, and it says nothing about whether a unit was already used. A device reachable during the exposure window needs the data it stored and any credentials it held treated as exposed, not closed out on an inventory entry. Scope stays on the four models the packet names — extend it to other storage products only where a verified source places the same shipped credential in them.",
+        "evidence": "Packet cwe_refs CWE-798 (name: 'D-Link Multiple NAS Devices Use of Hard-Coded Credentials Vulnerability'). Vector: 'The manipulation of the argument user with the input messagebus leads to hard-coded credentials', in '/cgi-bin/nas_sharing.cgi of the component HTTP GET Request Handler', affecting 'D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403'. attack_vector notes the hardcoded 'messagebus' account has an empty password. patch_available false; vendor guidance per live_patch_notes is to 'retire and replace the hardware'. Citing gaps include UK-CAF-B2 Identity and access control, NIST-800-53-CM-7 Least Functionality and ISO-27001-2022-A.8.9 Configuration management.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9"
+        ]
+      }
+    ]
   },
   "CVE-2024-29748": {
     "name": "Android Pixel Privilege Escalation Vulnerability (CVE-2024-29748)",
@@ -45465,7 +46262,31 @@
         "adequate": false,
         "gap": "Patch-application timeframes do not account for mobile-OS/firmware, where forensic-extraction exploitation of an unpatched wipe bypass is the real risk."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet gives a vendor update for the affected Pixel devices with no live-patch path and a required reboot, and an exploitation precondition of local or physical access plus user interaction — so the population that matters is handsets in people's hands, and the enforcement point has to be the device's reported security patch level acting as an access condition rather than a row on a compliance report. For this CVE that means the enrolled Pixel fleet is gated: a device below the fixed patch level is denied mail, VPN and document access until it is at or above it, and the check reads the level the device reports after it has restarted, because the packet records the update as requiring a reboot — a handset that has taken the update but not restarted is still running the vulnerable logic and has to count as exposed. Precondition, and for this flaw it is the load-bearing one: the control governs what a below-fix device is allowed to reach; it does nothing about the data already resident on that device, and the attacker the packet describes already has local or physical access to the handset, which is past the point where an access policy applies at all. That case belongs on the incident path — server-side revocation of the device's sessions, tokens and credentials — not on the patch-compliance path. Distinguishing test: enrol a Pixel pinned below the fixed patch level and confirm the policy actually denies it access to protected resources. An estate that surfaces the stale patch level on a dashboard while the device keeps its access has recorded the exposure rather than removed it.",
+        "evidence": "Packet: name 'Android Pixel Privilege Escalation Vulnerability'; cisa_kev true, kev_date 2024-04-04, active_exploitation 'confirmed'; cvss 7.8, rwep_score 53, 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.' Vector: 'This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.' attack_vector: 'An attacker with local/physical access interrupts a factory reset initiated by a device-admin app...'. Citing gaps include AU-Essential-8-Patch, NIST-800-53-SI-2 Flaw Remediation, ISO-27001-2022-A.8.8 and NIS2-Art21-patch-management. The packet names no fixed build identifier, so none is asserted here.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "What fails in this CVE is a protection mechanism rather than a general-purpose code path: the packet describes an attacker with local or physical access interrupting a factory reset initiated by a device-admin app so that the wipe does not complete, yielding local privilege escalation and defeating the remote-wipe and data-protection assurance an estate leans on for lost, stolen and returned Pixel handsets. For this CVE the control means the wipe primitive itself is regression-tested rather than assumed from the presence of the vendor update: on a representative Pixel at the current patch level, issue the device-admin wipe, interrupt it in the way the packet describes, and verify the handset came back with the data actually gone and the escalation unavailable — then re-run that battery on each subsequent platform update, since a condition-handling logic error of this shape (CWE-755 with CWE-280) is the kind a later change in the same path reintroduces. The signal to watch for in the fleet is the behaviour the packet documents, not a proxy for it: a wipe that was commanded but never reached a completed state, and a device that reappears after a commanded wipe still carrying its prior enrolment, identity or data. Precondition: this test tells you whether the assurance holds; it does not remediate a handset, and it is a check on the mechanism, not a substitute for the vendor update and the restart it requires. A device that has already had an interrupted wipe is an incident rather than a test result — the data was not removed, so it and any credentials the device held must be handled as exposed and revoked server-side.",
+        "evidence": "Packet cwe_refs CWE-755 and CWE-280. attack_vector: 'An attacker with local/physical access interrupts a factory reset initiated by a device-admin app, exploiting a logic error so the wipe does not complete, and gains local privilege escalation — defeating remote-wipe/data-protection assurances.' Vector: 'there is a possible way to bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.' cisa_kev true, kev_date 2024-04-04, active_exploitation 'confirmed'. patch_available true with live_patch_available false and live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gaps include UK-CAF-B4 System security and ISO-27001-2022-A.8.8.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-29745": {
     "name": "Android Pixel Information Disclosure Vulnerability",
@@ -45502,7 +46323,31 @@
         "adequate": false,
         "gap": "Security-of-processing controls assume lock-screen protection preserves data confidentiality; the fastboot memory leak undermines confidentiality of personal data on a seized device despite a locked screen."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The population is Google Pixel devices, and the packet's path needs no code running on the device at all: with physical possession of a Pixel in the After-First-Unlock state, the attacker reboots it into fastboot mode — where USB access is enabled before memory is zeroed — and dumps the uninitialized memory to recover data the lock screen would otherwise protect. Bound to this product, the control means the fixed Android build has to function as an access condition rather than a reporting field: a Pixel below it is denied the organizational mail, VPN and document access that puts protected data onto the device in the first place. The measurement must be the build actually running, because the packet records no live-patching primitive and states the vendor update requires a reboot to be the remediation — a Pixel that has taken the update but not restarted is still running the vulnerable boot path and must be counted below the fix. Distinguishing test: enrol a Pixel pinned below the fixed build and confirm policy actually denies it access to protected resources; an estate that surfaces the stale build on a compliance report while the device keeps its mailbox has recorded the exposure, not reduced it. Precondition, and it decides how far this control reaches: gating access limits what a below-fix Pixel is permitted to hold from this point forward — it does not reach data already resident on the device, and it does nothing once the device is in someone else's hands. Because the packet's path requires only physical possession, with no additional execution privileges and no user interaction, a Pixel that is lost, stolen or seized while below the fixed build belongs on the device-loss and personal-data-exposure path — the assessment the cited security-of-processing obligation drives — and not on the patch queue.",
+        "evidence": "Packet: 'Android Pixel Information Disclosure Vulnerability', CWE-908, with the vector recording 'a possible Information Disclosure due to uninitialized data... local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.' The attack path recorded is: 'With physical possession of a Pixel in the After-First-Unlock state, an attacker reboots it into fastboot mode where USB access is enabled before memory is zeroed, then dumps uninitialized fastboot memory to recover data that the lock screen would otherwise protect.' CISA KEV-listed 2024-04-04, active_exploitation confirmed, poc_available false, CVSS 5.5, RWEP 47. 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.' Cited as insufficient on this entry: ISO/IEC 27001:2022 A.8.8 (management of technical vulnerabilities), UK CAF B4 (system security), GDPR Art. 32 (security of processing).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "GDPR-Art32"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For the Pixel estate, the update carrying this fix is driven from the management platform on the clock that opened with the 2024-04-04 KEV listing, rather than left to each user's own update prompt. Completion is measured per device as installed security patch level and completed restart together, because the packet records no live-patching primitive for this product and states the vendor update requires a reboot to be the remediation — the read the attacker performs happens in the boot path that only the restart replaces, so a device counted as updated but not restarted is still exposed. Deferred restarts are therefore the specific way this remediation goes wrong on a phone estate: the download is invisible to the user and the restart is not, so it is the half that slips. Preconditions: an enforced SLA only governs devices that check in, so a Pixel that is unenrolled, offline or long out of contact never receives the push and has to be measured against enrollment and last-check-in rather than assumed compliant. And because the path the packet describes is exercised with physical possession rather than network reach, the SLA shortens the exposure window but does not defend a device inside it — a Pixel that goes missing during the window is not made safe by an update that lands afterwards, and that device is an incident, not a pending patch.",
+        "evidence": "Packet: CISA KEV-listed 2024-04-04 with active_exploitation confirmed; CVSS 5.5, RWEP 47, 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.' The recorded path requires physical possession of a Pixel in the After-First-Unlock state and a reboot into fastboot mode, and the vector states no additional execution privileges are needed and no user interaction is required. Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', NIST SP 800-53 Rev 5 SI-2 (flaw remediation), EU NIS2 Art. 21 vulnerability handling and disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-24955": {
     "name": "Microsoft SharePoint Server Code Injection Vulnerability",
@@ -45650,7 +46495,40 @@
         "adequate": false,
         "gap": "Boundary protection frequently leaves the EMS FmDatabaseServer TCP/8013 reachable; exposing that service to untrusted networks is the precondition for exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The vulnerable surface on this product is not the EMS web console but FmDatabaseServer on TCP/8013: a non-HTTP listener that answers before any authentication and whose own input handling is the defect, which is exactly why a deployment audited on web-tier hardening and perimeter firewall rules can be fully exposed. Applied to FortiClient EMS, the control means TCP/8013 on every EMS host accepts connections only from hosts with an operational need to speak that protocol to it — the endpoint population EMS serves and the management network — enforced by a host firewall on the EMS server or a network ACL in front of it, rather than inherited from the assumption that EMS sits on an internal network. The least-privilege gap recorded against this entry is not closable on this path and should not be attempted: the packet's attacker is unauthenticated and never holds an EMS account, so per-account privilege scoping is never consulted and that attestation passes cleanly while the injection runs to SYSTEM. Distinguishing test: from a general user or server VLAN with no endpoint-registration or administrative role, open a TCP connection to 8013 on a staging EMS and confirm it is refused before the listener parses anything — an estate that can show every EMS administrator authenticates, and that the appliance is filtered at the perimeter, still hands this listener to anything that can route to it internally. Precondition: reachability restriction bounds who can send the crafted packet, it does not repair the SQL handling. Any host inside the permitted set — including a compromised endpoint that legitimately talks to EMS — still reaches the injection, and the restriction is unavailable across the part of the path where endpoints must reach the listener for the product to function. Repairing the parsing itself is what the vendor update does; the packet records that update as available and as requiring no reboot.",
+        "evidence": "Packet: an unauthenticated attacker sends specially crafted packets to the FortiClient EMS FmDatabaseServer (TCP/8013) with SQL injected into the FCTUID field (CWE-89), enabling and invoking xp_cmdshell to run arbitrary commands as SYSTEM on the EMS host. Affected versions named in the packet: FortiClientEMS 7.2.0 through 7.2.2 and FortiClientEMS 7.0.1 through 7.0.10. CISA KEV-listed 2024-03-25, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 74. patch_available true; live_patch_available false, with live_patch_notes stating there is no live-patching primitive for this product and that the vendor update (no reboot required) is the remediation. NIST-800-53-AC-6 (Least Privilege) appears among the citing gaps for this entry, while the packet's path requires no authentication.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "The affected asset here is a security product's own management server, and this CVE is the case the control exists for: compromise of that server yields SYSTEM on the host that administers endpoints, and the builds the packet names (FortiClientEMS 7.2.0-7.2.2 and 7.0.1-7.0.10) sit on a vendor product track that most estates patch on a product cadence rather than on the KEV cadence they apply to operating systems — which is why the flaw-remediation and technical-vulnerability-management attestations on this entry can read clean while an affected EMS stays in service. The requirement for this product is that every EMS instance is enumerated in the vulnerability-management inventory as privileged software with an operating-system-grade SLA, treated as an asset with attack surface rather than as a defense that is assumed sound, and that each instance's reported version is compared against the vendor's fixed release with the clock running from the 2024-03-25 KEV listing. The packet leaves little room for deferral: it records a vendor update as available, no live-patching primitive, and no reboot required, so remediation is a service-level update on the EMS host rather than a fleet-wide maintenance event. Precondition: this control gets the fixed code onto the host and nothing more. It says nothing about what happened during the exposure window, so on any EMS whose 8013 listener was reachable while the flaw was unpatched the update has to be paired with a compromise assessment — SYSTEM-level command execution leaves artifacts that installing the fixed build does not remove.",
+        "evidence": "Packet: the product is Fortinet FortiClient EMS, affected in versions 7.2.0 through 7.2.2 and 7.0.1 through 7.0.10; the documented chain ends in arbitrary commands executing as SYSTEM on the EMS host. CISA KEV-listed 2024-03-25, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 74. patch_available true; live_patch_available false, with live_patch_notes recording no live-patching primitive for this product and the vendor update (no reboot required) as the remediation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "SYSTEM on an EMS host is control of the console that administers endpoints, so response to this CVE cannot end at the EMS server. The playbook's trigger has to be exposure rather than an alert: any EMS on an affected build (7.2.0-7.2.2, 7.0.1-7.0.10) whose TCP/8013 listener was reachable between the 2024-03-25 KEV listing and the update landing gets triaged, because the packet's path produces no failed logon and no account event at all — the attacker never authenticates, which is exactly why monitoring built around identity telemetry sees nothing. The detection that does key on the documented behaviour has three signals: connections to 8013 on the EMS host from sources outside the population that legitimately speaks to it, the database service's configuration being changed to enable xp_cmdshell, and process creation as SYSTEM parented by the EMS database service. Where any of those are present, the playbook has to cover what SYSTEM on that host reaches: the EMS database contents and any credentials held in them, the deployment and configuration actions the console issued during the window, the endpoint-facing artifacts it distributes, and rotation of every credential the EMS host held or could reach. Precondition: this is a post-exposure control. It prevents no injection and does not substitute for the vendor update the packet records as available, and its triage list only reaches the endpoints and credentials the inventory can name — anything the console administers that is missing from that inventory stays unexamined.",
+        "evidence": "Packet: the chain ends with arbitrary commands executing as SYSTEM on the EMS host, reached by an unauthenticated attacker who injects SQL into the FCTUID field on FmDatabaseServer (TCP/8013) and thereby enables and invokes xp_cmdshell. active_exploitation confirmed, poc_available true, CISA KEV-listed 2024-03-25, CVSS 9.8, RWEP 74. Affected builds per the packet: FortiClientEMS 7.2.0 through 7.2.2 and 7.0.1 through 7.0.10. patch_available true, live_patch_available false, live_patch_notes recording the vendor update (no reboot required) as the remediation.",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-27198": {
     "name": "JetBrains TeamCity Authentication Bypass Vulnerability",
@@ -45707,7 +46585,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management as an annual/periodic control does not compel the network segmentation that would keep an unauthenticated attacker off the TeamCity admin surface."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "TeamCity takes its authentication decision in the layer that routes requests, and this CVE is that layer failing open: the packet has an unauthenticated request to a bogus path carrying a jsp= parameter that points at an authenticated REST endpoint, after which the attacker performs admin actions. Bound to this product, the control means each administrative REST function on the TeamCity server — account creation, token issuance, plugin upload — authorizes its caller itself rather than inheriting a verdict from the path-matching filter in front of it, and the server's HTTP surface is segmented so an untrusted caller cannot present that request to the filter in the first place. Distinguishing test: against a staging TeamCity server, issue unauthenticated requests to a non-existent path carrying a jsp= parameter that names an administrative REST endpoint, and confirm each is refused before the function runs — an attestation that every TeamCity administrator authenticates at login passes cleanly while this path stays open, because the attacker never holds an account and the account model is bypassed rather than abused. Preconditions: per-function authorization is a property the vendor fixed release establishes; this control states what to verify, it does not implement it, and the packet records no live-patch mechanism. Until that release is applied, restricting which segments reach the server bounds who can send the request but leaves it exploitable from anywhere inside the permitted segment, and that lever is unavailable where the server's HTTP surface must stay reachable for normal build operation. Because exploitation is confirmed and the packet's path ends in an attacker-created admin account or token and an uploaded plugin, a server reachable during the exposure window must be audited for administrators, tokens and plugins it did not legitimately gain — applying the fixed release does not remove them.",
+        "evidence": "Packet attack_vector: 'An unauthenticated request to a bogus path with a jsp= parameter pointing at an authenticated REST endpoint bypasses auth; the attacker then creates an admin account/token and uploads a malicious plugin to achieve RCE on the build server.' Vector: 'In JetBrains TeamCity before 2023.11.4 authentication bypass allowing to perform admin actions was possible.' cwe_refs CWE-288; cisa_kev true with kev_date 2024-03-07; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 71. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet pairs a 2024-03-07 KEV listing with a public PoC and an unauthenticated path to admin actions, so for this product the exposure window has to be measured in hours from the listing rather than in the cycle a build server usually gets. The mismatch is the point: a TeamCity server is normally inventoried as internal developer tooling and patched on a cadence that assumes an account is needed to reach anything sensitive, while the packet's path needs no account at all and ends in RCE on the build server. Bound to this entry, the clock runs from the KEV listing to the vendor fixed release being live on the server — the packet records no live-patch mechanism, so there is no partial state to claim against it, and a server past the clock is fully exposed to a documented, publicly available exploit path.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-03-07, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 71; attack_vector ends in 'RCE on the build server'. 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",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-23225": {
     "name": "Apple Multiple Products Memory Corruption Vulnerability",
@@ -46499,7 +47400,30 @@
         "adequate": false,
         "gap": "System-security assurance assumes the browser sandbox holds; a renderer type-confusion with sandbox escape defeats that assumption without additional exploit-mitigation controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's exploitation path is a victim loading an attacker-controlled page, so every hour a managed endpoint keeps browsing on a Chrome build below 116.0.5845.179 is an hour that path stays open, and the packet records no live-patch mechanism — applying the vendor fixed release is the only thing that closes it. Bound to this deployment, the control means the browser's security channel is exempt from the pilot/broad ring staging that enterprise update policy applies to feature updates, and that completion is measured by the version the browser itself reports on each endpoint rather than by an 'approved' or 'downloaded' state in the management console. Distinguishing test: enumerate the Chrome version actually running across managed endpoints and confirm none report below 116.0.5845.179 — a ring policy that reports the update as deployed while endpoints still report a pre-fix build leaves the vulnerable V8 in the renderer that parses attacker-supplied HTML, with a clean patch-compliance row. Precondition: the ring reaches only Chrome installs the management channel can see and update. A user-installed copy outside that channel takes no ring policy at all, so it is remediated by bringing it under management or removing it, not by recording the fleet as patched.",
+        "evidence": "Packet vector: 'Type Confusion in V8 in Google Chrome prior to 116.0.5845.179 allowed a remote attacker to execute arbitrary code via a crafted HTML page.' attack_vector: a victim visits an attacker-controlled web page and malicious JavaScript drives the V8 type confusion, yielding code execution inside the renderer. cwe_refs CWE-843; cisa_kev true with kev_date 2024-02-06; active_exploitation confirmed. 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",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock is the load-bearing half. The packet records no public PoC alongside confirmed in-the-wild exploitation, so an estate that prioritises by CVSS band alone files an 8.8 browser bug into the routine desktop-software cycle while it is actually being exploited — and the packet's RWEP of 55 sitting below the CVSS band is exactly the reading that invites the deferral. Bound to this product, the control means Chrome carries the same KEV-driven remediation clock an internet-facing server would: the vendor fixed release is available per the packet, so the deadline runs from the 2024-02-06 KEV listing rather than from the next scheduled application-update window. Because the packet registers no live-patch mechanism and no vendor mitigation rule, there is no intermediate state an operator can claim against that clock — an endpoint is either running the fixed release or fully exposed to the crafted-HTML path, and the clock has to be measured against the former.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-02-06, active_exploitation confirmed, poc_available false, CVSS 8.8, RWEP 55, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2022-48618": {
     "name": "Apple Multiple Products Memory Corruption Vulnerability",
@@ -46704,7 +47628,31 @@
         "adequate": false,
         "gap": "System-security assurance for the application does not mandate WAF/virtual-patching that would blunt the OGNL-injection request pattern before the vendor fix is applied."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Confluence Data Center and Server on an affected older version is the asset, and the packet describes what an operator inherits after exploitation rather than only the defect: an unauthenticated POST to /template/aui/text-inline.vm carrying an OGNL expression is evaluated server-side and executes arbitrary OS commands, which the packet records as being used to drop miners, C2 implants or webshells. Those payloads do not live in the vulnerable template path, so applying the vendor fixed release removes the injection point and leaves them running. Bound to this product, the control means an instance that was reachable by an unauthenticated caller while on an affected version is handled as a suspected compromise: rebuilt from a known-good baseline instead of upgraded in place, with the credentials and integration tokens the instance held rotated, since arbitrary OS command execution runs with the Confluence process's access to them. Precondition, and this is where the runbook is habitually under-triggered: the trigger is unauthenticated reachability during the exposure window, not an observed webshell — the packet records a public PoC and confirmed in-the-wild exploitation, and an implant that survives an in-place upgrade also outlives the logs that would have shown its arrival, so 'we found nothing' is not the same evidence as 'nothing happened'. Distinguishing test: take an instance recorded as remediated and ask what was done besides the version change. An upgrade ticket closed against the KEV listing satisfies every patch-management attestation cited on this entry while a webshell dropped before the upgrade still answers.",
+        "evidence": "Packet: 'Atlassian Confluence Data Center and Server Template Injection Vulnerability', CWE-74, with the recorded path 'An unauthenticated attacker sends a POST to /template/aui/text-inline.vm containing an OGNL expression; Confluence evaluates the template server-side, executing arbitrary OS commands that are used to drop miners, C2 implants or webshells.' The vector states the flaw 'allows an unauthenticated attacker to achieve RCE on an affected instance' and that 'Customers using an affected version must take immediate action.' CISA KEV-listed 2024-01-24, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 75. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' Cited as insufficient on this entry: NIST SP 800-53 Rev 5 SI-2 (flaw remediation), ISO/IEC 27001:2022 A.8.8, EU DORA Art. 9 (ICT risk management framework).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock attaches to the asset the packet names — Confluence Data Center and Server instances on an affected older version — and runs from the 2024-01-24 KEV listing. There is no privilege, account or user-interaction precondition between an attacker and the sink: the packet's path is a single unauthenticated POST to /template/aui/text-inline.vm, so for any instance an unauthenticated caller can reach, the interval between listing and upgrade is the whole of the control. The packet records a vendor fixed release with no live-patch mechanism, which makes the upgrade the only clock-stopping action — there is no rule to deploy in the meantime and none should be recorded as one. Completion has to be measured as the version actually serving requests on each instance, not a change ticket raised, because the packet's own vector says recent supported versions are unaffected as the flaw was mitigated during regular version updates: that makes 'we are on a supported version' a per-instance claim to verify, and the routine multi-week remediation window the cited patch controls sanction is the specific thing that fails against a KEV-listed unauthenticated RCE with a public PoC. Precondition: an accelerated SLA bounds the window going forward and does nothing for the instances that were already reachable before it started — those belong on the compromise-assumption path above, not on this one. Distinguishing test: pick an instance recorded as compliant and query the version it is actually serving, rather than reading the version field the inventory carries.",
+        "evidence": "Packet: CISA KEV-listed 2024-01-24 with active_exploitation confirmed; CVSS 9.8, RWEP 75, poc_available true. Vector: 'A template injection vulnerability on older versions of Confluence Data Center and Server allows an unauthenticated attacker to achieve RCE on an affected instance. Customers using an affected version must take immediate action... Most recent supported versions of Confluence Data Center and Server are not affected by this vulnerability as it was ultimately mitigated during regular version updates.' Recorded path: an unauthenticated POST to /template/aui/text-inline.vm containing an OGNL expression. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', EU NIS2 Art. 21 vulnerability handling and disclosure, UK CAF B4 (system security).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-23222": {
     "name": "Apple Multiple Products WebKit Type Confusion Vulnerability (CVE-2024-23222)",
@@ -46761,7 +47709,30 @@
         "adequate": false,
         "gap": "System-security assurance credits the WebKit/Safari sandbox; a renderer type-confusion undermines that assumption absent additional exploit-mitigation controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet's fix list is nine parallel builds, not one — Safari 17.3, iOS/iPadOS 15.8.7, iOS/iPadOS 16.7.5, iOS/iPadOS 17.3, macOS Monterey 12.7.3, macOS Ventura 13.6.4, macOS Sonoma 14.3, tvOS 17.3 and visionOS 1.0.2 — so for this CVE the control means the management platform drives each enrolled device to the fixed build for the OS major that device is actually on, on the clock that opened with the 2024-01-23 KEV listing, with user deferral disabled rather than discouraged. Two properties of this entry decide whether that succeeds. First, the packet records no vendor live-patch mechanism and states remediation requires applying the fixed release and rebooting: a device that has downloaded or even installed the update but has not restarted is still running the vulnerable WebKit and must be counted as exposed. On user-carried handsets the restart is the step most often deferred, and a deferral recorded as 'updated' is the specific way this remediation goes wrong. Second, tvOS 17.3 and visionOS 1.0.2 sit in the same fix list as the phones and laptops; an update SLA scoped to iPhone, iPad and Mac leaves those two builds unaddressed while the flaw-remediation attestation reads clean. Distinguishing test: enumerate the installed build and the last-restart time per enrolled device and compare each against the fixed build for that device's own OS major — not against 'latest available' and not against the console's 'deployed' or 'approved' state, both of which report success on a host that has never restarted. Precondition: this lever reaches only enrolled devices the platform can compel, which is why it is paired here with the access-condition control rather than presented as complete coverage; a personally-owned or unenrolled device carrying organizational data is outside it entirely.",
+        "evidence": "Packet: CISA KEV-listed 2024-01-23, active_exploitation confirmed, CVSS 8.8, RWEP 60, 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.' The packet's vector names the fixed builds as 'Safari 17.3, iOS 15.8.7 and iPadOS 15.8.7, iOS 16.7.5 and iPadOS 16.7.5, iOS 17.3 and iPadOS 17.3, macOS Monterey 12.7.3, macOS Sonoma 14.3, macOS Ventura 13.6.4, tvOS 17.3, visionOS 1.0.2' and states 'Processing maliciously crafted web content may lead to arbitrary code execution.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet states the update 'brings that fix to devices that cannot update to the latest iOS version', so this estate provably contains hardware that will not reach the current OS major. The compliance floor for this CVE is therefore a per-major table — iOS/iPadOS 15.8.7, 16.7.5 and 17.3; macOS 12.7.3, 13.6.4 and 14.3; Safari 17.3; tvOS 17.3; visionOS 1.0.2 — not a single number. A policy keyed to 'latest iOS' marks a correctly-remediated 15.8.7 device permanently non-compliant and buries the devices that actually matter; a policy keyed only to major version passes an unpatched 17.x device. The control's requirement is that this per-major floor operate as an access condition — mail, VPN and document access refused to a device below the floor for its own major — rather than as a row on a patch-compliance report, because the packet's attack path needs only that the user open attacker-controlled web content in Safari or any WebKit-based renderer, which is ordinary daily use on exactly the devices least likely to be current. Distinguishing test: enrol a device pinned one build below the floor for its major 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. Preconditions, stated rather than assumed: denying access bounds what organizational data an exploited device can reach — it does not remove the vulnerable renderer from the device, so the user's personal browsing on that handset still reaches the sink, and it does nothing for a device compromised during the exposure window, which belongs on the incident path. It is also a holding measure only until the fixed release and its required restart land on that device. And for hardware that cannot take the current major, reaching the backported build is the ceiling that hardware allows for this CVE, not a resting state: those units need a dated replacement schedule, because a floor that can only ever name backported builds marks aging hardware compliant while everything not backported accumulates against it.",
+        "evidence": "Packet: vector states 'This fix associated with the Coruna exploit was shipped in iOS 17.3 on January 22, 2024. This update brings that fix to devices that cannot update to the latest iOS version,' and lists fixed builds across Safari 17.3, iOS/iPadOS 15.8.7, 16.7.5 and 17.3, macOS Monterey 12.7.3, Sonoma 14.3, Ventura 13.6.4, tvOS 17.3 and visionOS 1.0.2. Attack vector: 'A victim opens attacker-controlled web content in Safari or any WebKit-based renderer; the content triggers a type confusion in WebKit, letting the attacker execute arbitrary code in the browser process as a foothold on the device.' CWE-843; CISA KEV-listed 2024-01-23 with active_exploitation confirmed; poc_available false, so there is no public exploit artifact for a signature to key on and prevention carries the weight; patch_available true with live_patch_available false and live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-34048": {
     "name": "VMware vCenter Server Out-of-Bounds Write Vulnerability",
@@ -47195,7 +48166,39 @@
         "adequate": false,
         "gap": "Technical-vulnerability management did not prioritise a critical, PoC-available SharePoint auth bypass ahead of its ransomware weaponization."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "SharePoint Server's token validation is where the product makes its authentication decision, and this CVE is that decision failing open: the packet has an unauthenticated attacker presenting a spoofed JWT whose signature is not properly validated, being granted administrator context, and then chaining CVE-2023-24955 code injection to reach remote code execution. Bound to this product, the control means each administrative function on the server establishes its caller's authority itself — the identity a token asserts is only usable once the signature and issuer behind it have been validated at the point the privileged function runs — instead of inheriting an 'administrator' verdict settled once at the front door; and that the server's administrative surface is segmented so an untrusted caller cannot present that token to it at all. This is precisely why the identity and authentication controls cited as insufficient here never engage: the attacker holds no SharePoint account, so nothing in the account model is misused, no credential is guessed and no second factor is ever requested — an authentication-assurance attestation and an identity-and-access review both pass cleanly while an unauthenticated caller sits in administrator context. Distinguishing test: from a segment with no operational need to reach the SharePoint administrative surface, send a staging instance requests bearing a well-formed but invalidly-signed token and confirm each privileged function refuses before it executes; confirming that every named SharePoint administrator authenticates with MFA tests nothing on this path. Precondition: the signature-validation repair is the vendor's, and the packet records a fixed release with no live-patch mechanism that requires a reboot — this control names the property to verify and the segmentation that bounds who can attempt the forgery, it does not implement the fix. Segmentation limits the caller population and closes nothing for anything already inside the permitted segment.",
+        "evidence": "Packet: 'Microsoft SharePoint Server Privilege Escalation Vulnerability', CWE-303, vector 'Microsoft SharePoint Server Elevation of Privilege Vulnerability'. Recorded path: 'An unauthenticated attacker presents a spoofed JWT whose signature is not properly validated by SharePoint, is granted administrator context, and can then chain CVE-2023-24955 code injection to reach remote code execution.' CISA KEV-listed 2024-01-10, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 78. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Cited as insufficient on this entry: NIST SP 800-63B Rev 4 (authentication and lifecycle management, AAL/IAL/FAL) and UK CAF B2 (identity and access control).",
+        "gap_closes": [
+          "NIST-800-63B-rev4",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock runs from the 2024-01-10 KEV listing across every SharePoint Server on an affected build, and completion is measured per server as the running build plus a completed restart — the packet records no live-patch mechanism and states remediation requires applying the fixed release and rebooting, so a server that installed the update and has not restarted still runs the vulnerable code and has to be counted as exposed. On a collaboration server that users are working in through the day, that restart is the step most likely to be deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Priority follows what the packet records rather than the maintenance calendar: a public PoC, confirmed in-the-wild exploitation, and an unauthenticated caller reaching administrator context with a documented chain onward into code execution, which is not a monthly-rollup item. Precondition: the SLA governs the window from listing forward and settles nothing about servers that were already reachable by an unauthenticated caller on an affected build — the packet's chain terminates in remote code execution, so those servers are a triage question, not a patching one, and closing them on the update ticket is what the compromise-assumption control below exists to prevent.",
+        "evidence": "Packet: CISA KEV-listed 2024-01-10 with active_exploitation confirmed; CVSS 9.8, RWEP 78, poc_available true. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Recorded path: an unauthenticated attacker presents a spoofed JWT whose signature is not properly validated, is granted administrator context, and can chain CVE-2023-24955 code injection to reach remote code execution. Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8, EU NIS2 Art. 21 vulnerability handling and disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's chain does not stop at elevated privilege — it terminates in remote code execution through CVE-2023-24955, with exploitation confirmed and a PoC public. Applying the fixed release settles the signature-validation defect; it does not answer whether an unauthenticated caller already reached administrator context on that server, and whatever followed does not live in the code the update replaces, so it survives the update and the reboot. Bound to this product, the control means a SharePoint Server that was reachable by an unauthenticated caller while on an affected build is triaged as a suspected compromise rather than closed on the patch ticket: server content and configuration compared against a known-good baseline, and the credentials and secrets the server held rotated, because the chain's recorded end state is code execution on that server. Precondition and honest limit: the packet records the end state as remote code execution and does not record what an attacker left behind, so the trigger for this runbook is unauthenticated reachability during the exposure window — not an observed implant, which is exactly the evidence a server with code execution on it is in a position to remove. The rebuild half also has an ordering constraint worth stating: if the triage is skipped now and the question is reopened later, a rebuild taken from a baseline that was already modified reproduces the modification rather than removing it.",
+        "evidence": "Packet: recorded path is 'An unauthenticated attacker presents a spoofed JWT whose signature is not properly validated by SharePoint, is granted administrator context, and can then chain CVE-2023-24955 code injection to reach remote code execution.' CISA KEV-listed 2024-01-10, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 78. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The packet records no implant, tooling or post-exploitation artifact for this entry — the chain's stated end state is remote code execution. Cited as insufficient on this entry: EU NIS2 Art. 21 vulnerability handling and disclosure.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-46805": {
     "name": "Ivanti Connect Secure and Policy Secure Authentication Bypass Vulnerability",
@@ -47744,7 +48747,31 @@
         "adequate": false,
         "gap": "Application-hardening guidance focuses on macro/Office hardening on endpoints, not on server-side spreadsheet parsers that eval format strings."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The vulnerable code here is a third-party Perl module, and the packet's exploitation path is 'a service embedding Spreadsheet::ParseExcel' — so an operator's exposure is a property of software it bought or built on, not of anything its own package list names. Bound to this CVE, the requirement is that the component inventory resolve to the depth at which Spreadsheet::ParseExcel actually sits — inside an appliance image, a container layer, or a vendor product that ingests spreadsheets — and record the module version, obtained from the supplier's SBOM or a direct written answer wherever the operator cannot inspect the image itself. Hold the scope there: the packet ties the string-eval sink to this module and the services embedding it, and provides no mapping from the defect into other spreadsheet-parsing code, so widening the sweep to every library in the estate that reads Excel files manufactures findings and rework against components no evidence implicates. The vulnerability-management and flaw-remediation controls cited as insufficient for this entry fail at their input rather than in their process: both act on an asset register, and a module bundled three levels down never reaches one, so the programme can be fully conformant and never open a ticket for a KEV-listed remote code execution it is running every day. Distinguishing test: for each product in the estate that ingests spreadsheets, ask whether it embeds Spreadsheet::ParseExcel and at what version, and require the answer to come from the supplier — because querying the operator's own package manager returns 'not installed' on a fully exposed system, which is the specific way this check gets recorded as clean. Precondition and limit: inventory is visibility, not remediation. The packet records a vendor fixed release as available and no live-patch mechanism, so every copy the inventory surfaces still has to be taken to that release by whoever controls it; for a bundled copy that is the embedding vendor, and until they ship it the operator's position is a known-exposed parsing path to be constrained, not a closed finding.",
+        "evidence": "Packet: 'Spreadsheet::ParseExcel version 0.65 is a Perl module used for parsing Excel files. Spreadsheet::ParseExcel is vulnerable to an arbitrary code execution (ACE) vulnerability due to passing unvalidated input from a file into a string-type \"eval\"', with the issue stemming from evaluation of Number format strings within the Excel parsing logic; attack vector records that the code executes when 'a service embedding Spreadsheet::ParseExcel parses the file'; CWE-95 and CWE-94; CISA KEV-listed 2024-01-02 with active_exploitation confirmed and poc_available true; RWEP 66 / CVSS 7.8; patch_available true and live_patch_available false, with the live-patch note recording that 'remediation requires applying the vendor fixed release'. ISO 27001:2022 A.8.8, NIST 800-53 SI-2 and DORA Art.9 are the framework controls recorded as insufficient for this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-116",
+        "name": "MULTI-TRIGGER-DEPENDENCY-EXECUTION-POLICY",
+        "description": "This CVE adds a dependency-execution trigger that no policy enumerates: document-parse time. The packet has the module passing a Number-format string out of an attacker-crafted Excel file into a Perl string eval, so the attacker's code runs when a service performs an ordinary data-processing operation on a business document — not when the dependency is installed, imported, or built. Every safeguard an estate is likely to hold is keyed to a moment that is never reached: ignore-scripts defaults and lockfile pinning govern install time, build sandboxes govern compile time, and none of them is consulted when a mail-handling service, a reporting job, or an upload handler opens the attachment. Applied here, the policy must list document/data-parse time alongside install, import and build time as an execution trigger, and every service that feeds files into Spreadsheet::ParseExcel must run under an identity scoped to that job alone — no credentials the parse itself does not need, no interactive shell, and constrained egress — so that code executed out of a format string lands somewhere that cannot reach the estate's secrets or call outward. The user-application-hardening control cited as insufficient here is aimed at a different machine entirely: it governs macro, OLE and add-in behaviour in an Office client on a user's endpoint, while this code executes inside a server-side Perl process with that service's privileges, on a file no person may ever open. Distinguishing test: feed a file whose Number-format string carries a Perl payload to a staging instance of each service that parses spreadsheets through this module, and confirm from the service account's own context that the payload can neither read credentials nor open an outbound connection — an attestation covering endpoint Office hardening passes cleanly while the server-side parse path executes attacker code unimpeded. Precondition: this constrains what the executed code can reach; it does not stop the execution. The packet records a vendor fixed release with no live-patch path, so every copy still has to be taken to that release, and the least-privilege identity is worth nothing on a service whose parse job simply inherited the application's main credentials — which is the normal case, and the thing to change first.",
+        "evidence": "Packet: the flaw stems from 'the evaluation of Number format strings (not to be confused with printf-style format strings) within the Excel parsing logic', passing unvalidated input from a file into a string-type eval; attack vector records that an attacker crafts an Excel file whose Number-format string contains Perl code and the module executes it when a service embedding Spreadsheet::ParseExcel parses the file; CWE-95 and CWE-94; KEV 2024-01-02, active_exploitation confirmed, poc_available true; patch_available true, live_patch_available false, remediation is applying the vendor fixed release. AU Essential Eight user application hardening, NIS2 Art.21 security of network and information systems, and UK CAF B4 (System security) are the framework controls recorded as insufficient for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-7024": {
     "name": "Google Chromium WebRTC Heap Buffer Overflow Vulnerability",
@@ -48108,7 +49135,31 @@
         "adequate": false,
         "gap": "Technical vulnerability management closed the first advisory but not the request-smuggling primitive the incomplete fix left reachable until the follow-up patch."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Qlik Sense Enterprise for Windows terminates the raw HTTP request in a front tier and hands work to the backend server hosting the repository application, and this CVE is that split failing: the packet describes an attacker tunneling an HTTP request inside the raw HTTP request so the backend executes it, under the service account, with elevated privilege. The inner request never passes the front tier's authorization decision, so the backend acts on a caller nothing authorized. Bound to this product, the control means the repository application's privileged operations authorize their own caller rather than inheriting a verdict from the tier that fronts them, and the Qlik front-end surface answers only from segments with an operational need to reach it, so an untrusted caller cannot present a raw request to that tier at all. The least-privilege gap recorded against this entry does not close this path: the tunneled request runs under the Qlik service account, and chained with the CVE-2023-41266 anonymous-session flaw the packet names, the attacker holds no Qlik account, so per-user privilege scoping is never consulted and an AC-6 attestation passes cleanly while the path stays open. Distinguishing test: from a segment with no business need to reach the analytics platform, send a staging deployment a raw request carrying a second, tunneled request aimed at a privileged repository endpoint and confirm the backend refuses it before the operation runs, rather than relying on the front tier having stripped it. Precondition: consistent request parsing between the two tiers is a property the vendor fixed release establishes — this control states what to verify and where to segment, it does not repair the parser. Until the fixed build is in place, restricting reachability bounds who can send the raw request but leaves the tunneling path fully exploitable to anything inside the permitted segment, and it is unavailable where the deployment must serve a broad user population.",
+        "evidence": "Packet: CWE-444; an HTTP Request Tunneling flaw in Qlik Sense Enterprise for Windows allowing a remote attacker to elevate privilege by tunneling HTTP requests in the raw HTTP request, sending requests that get executed by the backend server hosting the repository application. The packet's attack path adds that execution occurs under the service account and that, combined with the CVE-2023-41266 anonymous session, it yields unauthenticated remote code execution. CISA KEV-listed 2023-12-07, active_exploitation confirmed, poc_available true, RWEP 70 against CVSS 9.9.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet names five maintenance tracks with a different fixed build on each — August 2023 IR, May 2023 Patch 4, February 2023 Patch 8, November 2022 Patch 11, August 2022 Patch 13 — so on this CVE the SLA's failure mode is a mis-measured deadline rather than a missed one. A server sitting on November 2022 Patch 10 is current by its own track's reckoning and still carries the tunneling path. Applied here, the remediation clock opened by the 2023-12-07 KEV listing is measured per deployment against the fixed build named for that deployment's own track, not against whether the deployment is up to date within its track. The packet records a vendor fixed release and no live-patch mechanism, so nothing closes this without taking each deployment through the update; during that window the compensating half of the control is restricting who can reach the Qlik front end, which bounds the attacker population and does not close the flaw. Distinguishing test: produce, per Qlik Sense Enterprise deployment, its maintenance track and its installed build, and compare each against the fixed build named for that track — an estate whose patch report shows every server current has not answered this question. And because active exploitation is confirmed and the packet has the tunneled request executing under the service account, a deployment reachable during the exposure window is not remediated by the update alone: the update closes the path but removes nothing already done through it, so such a server needs forensic triage and service-account credential rotation rather than being closed on the patch.",
+        "evidence": "Packet: affected versions are May 2023 Patch 3 and earlier, February 2023 Patch 7 and earlier, November 2022 Patch 10 and earlier, and August 2022 Patch 12 and earlier; the fix is recorded as August 2023 IR, May 2023 Patch 4, February 2023 Patch 8, November 2022 Patch 11, and August 2022 Patch 13. CISA KEV-listed 2023-12-07, active_exploitation confirmed, poc_available true, RWEP 70 against CVSS 9.9. patch_available true, live_patch_available false, live_patch_notes: no vendor live-patch mechanism, remediation requires applying the vendor fixed release. The packet's attack path records execution under the service account.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-33107": {
     "name": "Qualcomm Multiple Chipsets Integer Overflow Vulnerability",
@@ -48246,7 +49297,30 @@
         "adequate": false,
         "gap": "Technical vulnerability management presumes an available remediation path, but here it is gated behind OEM firmware rebuilds, leaving a long unremediable exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's trigger is a local, low-privileged Android app submitting an oversized sync-point list in an IOCTL_KGSL_GPU_AUX_COMMAND to the Adreno GPU (KGSL) driver, and the fix does not originate with the operator: the packet records remediation as the OEM firmware/OS update carrying Qualcomm's fix, plus a device reboot. That routing makes the access-condition half of this control the load-bearing half — for a device model whose OEM has not yet shipped that build, there is no patch to deploy and the operator's only remaining lever is withholding organizational data from the handset. The fixed build must therefore function as an access condition, with mail, VPN and document access denied to any device below the OEM build carrying the fix, rather than as a row on a patch-compliance report. Distinguishing test: enrol a handset pinned to a pre-fix OEM build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a dashboard while the device keeps its mail and VPN has recorded the exposure rather than removed it. Two preconditions this control cannot cross. First, the packet requires a reboot after the OEM update, so a device that has taken the update but not restarted still runs the vulnerable driver and must be counted as exposed, not compliant. Second, restricting which applications may be installed raises the bar for getting the attacker's app onto the handset but does not evict one already installed, so a device suspected of already running it belongs on the incident path rather than the install-policy path. There is also no disable-the-component option to fall back on here: KGSL is the GPU path the device renders through, so unlike a discretionary kernel module it cannot be blocked or unloaded while waiting for the OEM build.",
+        "evidence": "Packet: CWE-823 and CWE-119, memory corruption while submitting a large list of sync points in an AUX command to the IOCTL_KGSL_GPU_AUX_COMMAND. The packet's attack path is a local, low-privileged Android app submitting that oversized sync-point list to the Adreno GPU (KGSL) driver, causing an out-of-range pointer write corralled into a privilege-escalation primitive. CISA KEV-listed 2023-12-05, active_exploitation confirmed, poc_available false, RWEP 57 against CVSS 7.8. patch_available true and live_patch_available false, with live_patch_notes stating there is no live-patch mechanism for chipset drivers and that remediation requires the OEM firmware/OS update carrying Qualcomm's fix and a device reboot.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This control's clock — mitigation within four hours of KEV listing or patch availability, whichever is later — is the right shape for this CVE only if patch availability is read per device model. The packet routes the fix through the OEM: remediation is the OEM firmware/OS update carrying Qualcomm's fix plus a reboot, so the 2023-12-05 KEV listing is not a date on which any operator could deploy anything. Applied here the SLA has to be written in two parts: documented compensating controls in force from the KEV listing for every affected handset, and the binary update measured against a per-model availability date the estate tracks itself, because no single date covers a fleet spanning multiple OEMs and models. Distinguishing test: for each affected device model in the fleet, produce the date its OEM published the build carrying Qualcomm's fix and the date that model's devices reached it; a programme that records one KEV due date across the whole fleet can produce neither number, and will report models whose OEM never shipped the build as merely late rather than as unremediated with no remaining patch path. Precondition: the compensating-controls half is what actually holds during that gap, and on this CVE it reduces to controlling what the device is trusted with — the packet's exploit needs only a locally installed low-privileged app on the handset, so no network-boundary measure sits anywhere in the path, and an SLA that logs a network control as the interim mitigation here has recorded something that does not touch the exploit.",
+        "evidence": "Packet: CISA KEV-listed 2023-12-05 with active_exploitation confirmed; poc_available false; RWEP 57 against CVSS 7.8. patch_available true, live_patch_available false, and live_patch_notes recording that there is no live-patch mechanism for chipset drivers and that remediation requires the OEM firmware/OS update carrying Qualcomm's fix and a device reboot. The packet's attack path establishes the only access requirement as a local, low-privileged Android app issuing IOCTL_KGSL_GPU_AUX_COMMAND to the Adreno GPU (KGSL) driver.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-33063": {
     "name": "Qualcomm Multiple Chipsets Use-After-Free Vulnerability (DSP Services)",
@@ -48728,7 +49802,39 @@
         "adequate": false,
         "gap": "Technical vulnerability management must prioritize a ubiquitous library flaw with a public root-shell PoC, yet fleet-wide glibc remediation is operationally heavy and easily deprioritized."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-142",
+        "name": "SUID-MINIMIZATION-FOR-KERNEL-LPE-CARRIER-BINARIES",
+        "description": "The carrier for this escalation is the binary, not the account. The packet's path requires a local user to launch a binary carrying the SUID bit with a maliciously crafted GLIBC_TUNABLES value in its environment, and ld.so performs the overflow while parsing those tunables inside the already-privileged process. Applied to an affected glibc estate, the control means enumerating every setuid-root binary on each host and removing the bit from those whose function does not require it, so the set of privileged processes an unprivileged user can drive through the tunables parser shrinks during the window before the distribution's patched package lands. The packet records this as one of the two available stop-gaps, alongside the vendor's GLIBC_TUNABLES handling. This is also why the cited least-privilege control does not reach the flaw: AC-6 grades what accounts are permitted to do, and the account here is an ordinary unprivileged one — the privilege transition comes from the binary's mode bits, which no account-scoped attestation examines. Distinguishing test: enumerate the setuid-root binaries on a representative host and produce, per binary, either the removed bit or a written operational need; an estate whose least-privilege evidence is a role matrix passes cleanly while every local user still holds a set of privileged carriers. Preconditions: removal helps only for binaries that actually lose the bit — any binary that must stay setuid-root for the host to function still presents the caller's environment to the loader, so the path stays open there and the estate must know which those are rather than assume the sweep was complete. It gives nothing on a host where escalation has already occurred, and it is a holding measure for the window before the patched glibc package and the reboot or service restart it requires, not a substitute for them.",
+        "evidence": "GNU C Library Buffer Overflow Vulnerability (CWE-122 / CWE-787), CISA KEV-listed 2023-11-21, active exploitation confirmed, public PoC available, CVSS 7.8, RWEP 78. The packet's vector record: a buffer overflow in the GNU C Library's dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable, allowing a local attacker to use maliciously crafted GLIBC_TUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges. The packet's live-patch record states no userspace live-patch tool exists and names the stop-gap as removing setuid bits or setting GLIBC_TUNABLES handling per vendor mitigation.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock runs from the 2023-11-21 KEV listing to the point where each affected host is running the distribution's patched glibc and has taken the reboot or service restart the packet names — not to the point where the package is approved, downloaded, or shown as installed. The packet registers no live-patch tool and states that kernel live-patching does not cover glibc, so an estate that meets its uptime obligations through a live-patching product holds no equivalent lever here: the restart cannot be traded away, and deferring it to the next maintenance window is the specific way this remediation is recorded as done while the packet's own completion criterion is unmet. Sequence by where the exploit's single precondition is the normal operating state rather than an anomaly: hosts carrying many interactive local accounts — shared shell, build and jump hosts — before single-user endpoints, because a local user account is all the packet requires and a public PoC exists against confirmed in-the-wild exploitation. Where the restart genuinely cannot be taken inside the clock, the packet's stop-gap — setuid-bit removal or the vendor GLIBC_TUNABLES handling — must be recorded as an active compensating control with a dated removal, not as remediation.",
+        "evidence": "CISA KEV-listed 2023-11-21 with active exploitation confirmed and a public PoC available; CVSS 7.8, RWEP 78. Patch available. The packet's live-patch record: no userspace live-patch tool, kernel live-patching does not cover glibc, and remediation requires the distribution's patched glibc package followed by a reboot or restart of all affected services. The packet's attack-vector record places the trigger in a local user's invocation of a SUID-root binary with a crafted GLIBC_TUNABLES environment variable, yielding code execution with root privileges.",
+        "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": "A scanner that reads the installed glibc package version and reports the host remediated answers half of what the packet requires. The packet's remediation is the patched package followed by a reboot or restart of all affected services, so a host whose package database shows the fixed build while that restart has not been taken has not met the stated completion criterion, yet it is counted green by a version-only check. The second half is the carrier surface: the flaw is reachable only through a binary carrying the SUID bit, so a vulnerability-management verdict for this CVE has to account for the setuid inventory and for whether the interim mitigation the packet names — setuid-bit removal or the vendor GLIBC_TUNABLES handling — was actually in place during the exposure window; a version-only scan cannot distinguish a host that carried that mitigation from one that never had it. Distinguishing test: take a host the scanner reports remediated and confirm both facts independently — the installed glibc is the distribution's fixed package, and the reboot or service restart occurred after it was installed. A technical-vulnerability attestation built on scanner output alone reports the pre-restart hosts as closed.",
+        "evidence": "GNU C Library dynamic loader ld.so, CISA KEV-listed 2023-11-21, active exploitation confirmed, public PoC available, CVSS 7.8, RWEP 78, patch available. The packet's live-patch record states remediation requires the distribution's patched glibc package followed by a reboot or restart of all affected services, with no live-patch tool available, and names removing setuid bits or setting GLIBC_TUNABLES handling per vendor mitigation as the stop-gap. The packet's vector confines exploitation to launching binaries with SUID permission.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-36584": {
     "name": "Microsoft Windows Mark of the Web (MOTW) Security Feature Bypass Vulnerability (CVE-2023-36584)",
@@ -48989,7 +50095,32 @@
         "adequate": false,
         "gap": "Applying vendor patches within the ISM timeframe still leaves the zero-day window uncovered; the control does not mandate the EDR/exploit-guard telemetry that would catch DWM token abuse."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Desktop Window Manager (DWM) Core Library and describes an attacker who already holds a low-privilege foothold abusing an untrusted-pointer / memory-corruption flaw to move from the Window Manager\\DWM context the packet names to SYSTEM. The escalation starts from an account the host already accepts, so nothing in the account model is being abused — a privilege boundary inside the component is failing. For this CVE the control means driving the Windows update carrying the DWM Core Library fix across every affected host on the clock that opened with the 2023-11-14 KEV listing rather than folding it into the next monthly rollup, with completion measured per host by the installed build against the fixed build for that Windows release, not by 'approved' or 'downloaded' in the management console. The packet records no vendor live-patch mechanism and remediation requiring the fixed release plus a reboot, so a host that has installed the update but not restarted is still running the vulnerable library and has to be counted as exposed; on a shared workstation or session host that restart is the step most likely to be deferred because taking it evicts logged-on users, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Enumerate first the hosts where an unprivileged interactive logon is the normal operating state, because that is where the exploit's stated precondition — an existing low-privilege foothold — is met continuously rather than exceptionally. The control's second half is the load-bearing one here: the entry cites NIST-800-53-AC-6 as insufficient and it is, because the attacker is a local user by precondition and tightening what that account may do does not contain a flaw that hands it SYSTEM, which is why a least-privilege attestation passes cleanly while the escalation stays fully available.",
+        "evidence": "Packet: CISA KEV-listed 2023-11-14, active_exploitation confirmed, CVSS 7.8, RWEP 59, CWE-822 / CWE-119. attack_vector: 'After gaining a low-privilege foothold, an attacker abuses a memory-corruption / untrusted-pointer flaw in the DWM Core Library to escalate from the Window Manager\\DWM context to SYSTEM.' patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' NIST-800-53-AC-6 (Least Privilege), NIST-800-53-SI-2 (Flaw Remediation), ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, AU-ISM-1546 and UK-CAF-B4 are all recorded as insufficient controls on this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-ISM-1546",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Bound to this CVE, the signal to instrument is the one transition the packet actually documents: a process running in the Window Manager\\DWM context, or under an ordinary interactive user, obtaining SYSTEM on a host where no legitimate elevation path — an operator-consented UAC elevation, a service start by the Service Control Manager, a scheduled-task launch — accounts for it. Alerting keys on that token/integrity-level transition and on the SYSTEM-integrity child processes that follow it. Two other signals are the wrong answer and both are worth naming, because they are the ones a rule-writer reaches for by default. A rule keyed on an exploit artifact's hash, command line or loaded-module set cannot exist honestly here: the packet records poc_available false, so there is no public exploit to derive a signature from and any such rule would be built from an assumption. A rule keyed on dwm.exe crashing is worse than useless, because the packet describes the untrusted-pointer flaw being abused to escalate, not to fault — a working exploit produces a privilege transition and no crash, so the rule stays silent through exactly the case it was written for. Instrumentation is user-mode process and token telemetry: the packet places the flaw in the DWM Core Library, not in a kernel driver, so driver-load and kernel-callback signals do not observe this path. The distinguishing test is to force a benign SYSTEM-token acquisition from an unprivileged interactive process on a staging host and confirm the alert fires from the transition alone, with no exploit sample present. Preconditions: this detects, it does not prevent — by the time the alert exists the escalation has already happened, so it cannot be recorded as this CVE's mitigation, which the packet gives as the vendor fixed release plus a reboot. And it covers only hosts where the telemetry is deployed and reporting, a smaller population on any real estate than the one the patch report counts.",
+        "evidence": "Packet: attack_vector documents the escalation 'from the Window Manager\\DWM context to SYSTEM' following a low-privilege foothold, and locates the flaw in the DWM Core Library. poc_available is false. active_exploitation is confirmed and the entry is CISA KEV-listed 2023-11-14. NIST-800-53-SI-4 (System Monitoring) is recorded as an insufficient control on this entry. Remediation per live_patch_notes is applying the fixed release and rebooting; live_patch_available is false.",
+        "gap_closes": [
+          "NIST-800-53-SI-4"
+        ]
+      }
+    ]
   },
   "CVE-2023-36025": {
     "name": "Windows SmartScreen Security Feature Bypass",
@@ -49115,7 +50246,32 @@
         "adequate": false,
         "gap": "The 48-hour patch-exploited-flaw target still leaves the zero-day window open, and the control does not mandate the kernel/EDR telemetry that would surface driver-level escalation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet puts the attacker on the host already — from a low-privilege foothold, driving crafted placeholder and reparse-point operations into the Cloud Files Mini Filter Driver to reach a heap-based buffer overflow and land as SYSTEM. The account is legitimate throughout and no boundary between users is crossed, so nothing in the account model is being abused: a privilege boundary inside a Windows driver is failing. For this CVE the control means the Windows update carrying the fix is driven across the affected estate on the clock that opened with the 2023-11-14 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 — not by 'approved', 'downloaded' or 'deployed' in the management console. The packet records no vendor live-patch mechanism and states remediation requires applying the fixed release and rebooting, so a host that has installed the update but not restarted is still running the vulnerable driver and must be counted as exposed; a pending-reboot host reported as patched is the specific way this remediation goes wrong. The population to enumerate is the general Windows workstation estate rather than one server role: the packet names a Windows driver component and states only one precondition — a low-privilege foothold — which is the normal operating state of any machine where ordinary users hold interactive sessions. The control's second half is the load-bearing one here. Because the attacker is already an authorized local user, tightening per-account privilege does not contain the escalation, which is exactly why the least-privilege gap cited on this entry can pass a clean attestation while the flaw remains fully exploitable. Priority follows the packet rather than the 7.8 CVSS band: confirmed in-the-wild exploitation of a foothold-to-SYSTEM step makes this a chain-containment item, not a routine endpoint ticket.",
+        "evidence": "Packet: CWE-122 and CWE-787; CISA KEV-listed 2023-11-14 with active_exploitation confirmed; CVSS 7.8, RWEP 59; poc_available false. Attack vector: 'From a low-privilege foothold, an attacker triggers a heap-based buffer overflow in the Cloud Files Mini Filter Driver via crafted placeholder/reparse-point operations, escalating to SYSTEM.' patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' NIST-800-53-AC-6 (Least Privilege) is among the framework control gaps citing this CVE.",
+        "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",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "The monitoring gap cited on this entry is the one the patch clock does not close, and its shape here is set by a specific packet fact: poc_available is false while active exploitation is confirmed, so there is no public exploit for a tool signature or hash to key on and only the behaviour the packet describes is available to detect. Two signals follow from it directly. First the operation: repeated crafted placeholder and reparse-point operations against the Cloud Files Mini Filter Driver issued by a process with no cloud-sync role — the processes that legitimately drive the cloud-files placeholder path on a host are its sync clients and the shell, so the same operations arriving from an unrelated user process are the anomaly, and a heap-overflow attempt against a driver is far likelier to be repeated than single-shot, which makes the repetition itself part of the signal. Second the outcome: a privilege transition with no corresponding authorized elevation — an already-running non-elevated process coming to hold a SYSTEM token, or a SYSTEM-level child spawned by a non-elevated parent — correlated back to the process that issued those driver operations, which is what turns an alert into the initial-access foothold a responder can pivot from. The control's 60-second alerting requirement is what makes this useful, because the escalation exists to precede the attacker's next action rather than to be the action. Preconditions and limits, stated because they change what this control can be recorded as achieving: it is post-hoc — it fires after SYSTEM has already been obtained, so it bounds dwell time rather than preventing the escalation, and it is not a substitute for the reboot-gated update. It also misses an exploit that uses the acquired token in-process without spawning anything, which is why the driver-operation signal must be collected in its own right and not merely as context attached to a process-spawn alert. And a host whose endpoint telemetry is not collected at kernel-object and process-token granularity produces neither signal at all, so estate coverage has to be verified on a sample rather than assumed from the agent's install count.",
+        "evidence": "Packet: poc_available false with active_exploitation confirmed and CISA KEV listing 2023-11-14 — exploitation is occurring without a public exploit artifact to signature. Attack vector: 'From a low-privilege foothold, an attacker triggers a heap-based buffer overflow in the Cloud Files Mini Filter Driver via crafted placeholder/reparse-point operations, escalating to SYSTEM' — the driver operations and the privilege transition are both stated behaviours. CWE-122 (heap-based buffer overflow) and CWE-787. NIST-800-53-SI-4 (System Monitoring) is among the framework control gaps citing this CVE. patch_available true with live_patch_available false and live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting,' so detection covers the window until each host has been restarted onto the fixed build.",
+        "gap_closes": [
+          "NIST-800-53-SI-4"
+        ]
+      }
+    ]
   },
   "CVE-2023-47246": {
     "name": "SysAid Server Path Traversal to Code Execution",
@@ -49327,7 +50483,42 @@
         "adequate": false,
         "gap": "Technical vulnerability management patches the CVE but does not mandate removing the exposed management plane the exploit chain depends on."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "SRX Series are firewalls and EX Series are the switches behind them, and the packet's J-Web flaw is pre-authentication remote code execution on that hardware — the device enforcing the boundary is the device being taken, so the ordinary 14- or 30-day appliance patch window does not apply to it. For these units the requirement is the Junos fixed release for the affected train deployed with the reboot the packet says remediation requires, on a clock that opened with the 2023-11-13 KEV listing, or J-Web reachability cut until that reboot completes. Reachability is the entire exploit precondition: the packet's attacker is unauthenticated and network-based and reaches the PHPRC-setting request through J-Web, so restricting which segments can present an HTTP request to that interface bounds who can attempt the chain. Precondition, and this is where the lever is routinely over-claimed: restricting reachability repairs nothing in the PHP external-variable handling. Any host inside the permitted management segment still reaches the flaw in full, so a compromised administrator workstation or jump host satisfies the attacker's only stated access requirement; and the lever is unavailable at all on units where J-Web is the operational management path. It is a holding measure for the window before the fixed release and reboot land, not a closure. Distinguishing test: from every segment that can route to the device, attempt to load J-Web on a staging unit — anything that answers is inside the published exploit's reach, and an appliance-patch attestation that records the fixed image as staged or downloaded while the unit has not rebooted is still describing a device running the vulnerable code.",
+        "evidence": "Packet: CISA KEV listed 2023-11-13, active_exploitation 'confirmed', CVSS 9.8, RWEP 79, poc_available true. vector: 'A PHP External Variable Modification vulnerability in J-Web of Juniper Networks Junos OS on EX Series and SRX Series allows an unauthenticated, network-based attacker to remotely execute code', with per-train fixed releases enumerated. 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": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "DORA-Art-9",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation path writes to the device before any code runs, and the upgrade does not undo that: the attacker sets PHPRC through a crafted J-Web request so the PHP execution environment loads a planted configuration whose auto_prepend_file executes a payload uploaded earlier. Both the planted configuration and the uploaded payload are files on the EX or SRX filesystem, and installing the fixed Junos release closes the PHPRC path while leaving whatever was staged through it in place. So for any EX or SRX unit whose J-Web was reachable from an untrusted segment during the exposure window opened by the 2023-11-13 KEV listing, the default response is config-exfil and rebuild rather than upgrade-in-place: extract the running and stored configuration for offline comparison against a known-good baseline, rebuild from vendor image plus that baseline, and rotate every credential and key the unit holds — local administrative accounts, any RADIUS/TACACS or SNMP shared secrets it is configured with, VPN pre-shared keys, and stored certificates. The packet records poc_available true alongside confirmed in-the-wild exploitation, so an exposed unit should be treated as having had the chain attempted, and the chain's second stage requires the attacker to have already written to the box. Precondition: this presumes a known-good baseline exists to compare against — a unit with no captured baseline can be rebuilt but cannot be cleared, so an unremarkable file listing is not evidence it is clean. Distinguishing test: on an exposed unit, diff the on-device file set and configuration against the baseline before the upgrade; a flaw-remediation attestation showing every EX and SRX at the fixed release proves the PHPRC path is closed and says nothing about a payload staged before it was.",
+        "evidence": "Packet: attack_vector states the attacker 'sets the PHPRC environment variable via a crafted J-Web request to load a planted PHP config (auto_prepend_file) that executes a previously uploaded payload, achieving remote code execution on SRX/EX devices'. active_exploitation 'confirmed', poc_available true, KEV listed 2023-11-13. patch_available true with live_patch_available false and remediation requiring the fixed release plus reboot.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "J-Web is the device-management gateway on these EX and SRX units, and this CVE is that gateway letting request-supplied input reach the interpreter's own execution environment before any caller is authenticated: a crafted request sets PHPRC and redirects which PHP configuration is loaded. Bound to this product, the control means no J-Web request parameter is permitted to select or modify the PHP execution environment, and every endpoint on the device that accepts file content authorises its caller before the content is stored — the packet's chain needs both halves, an earlier upload and an unauthenticated request that points the interpreter at it, so an endpoint-side fix on either one breaks it. The user-application-hardening gap cited on this entry does not reach here at all: that control governs the browsers, Office and PDF handlers on operator workstations, and the vulnerable application is the appliance's own web management interface, which no workstation-hardening attestation examines. Precondition: the endpoint-side authorisation and input neutralisation are properties the Junos fixed release establishes — this control states what to verify, it does not implement it. The operator-side lever before that release lands is least functionality: J-Web disabled outright on units genuinely managed by another channel (console, SSH CLI, or a management platform), which removes the delivery path on those units only, is unavailable where J-Web is the management path, and does nothing for a unit already exploited during the exposure window, since disabling the interface afterwards does not remove what was written to the filesystem. Distinguishing test: against a staging unit, issue unauthenticated J-Web requests carrying environment-influencing parameters and confirm each is refused before the PHP environment is consulted.",
+        "evidence": "Packet: CWE-473 (PHP External Variable Modification); vector states 'Using a crafted request which sets the variable PHPRC an attacker is able to modify the PHP execution environment allowing the injection und execution of code', reached by an unauthenticated, network-based attacker through J-Web on EX Series and SRX Series. attack_vector adds that the executed payload was 'previously uploaded'. AU-Essential-8-App-Hardening (User application hardening) and NIST-800-53-CM-7 (Least Functionality) are recorded among the citing framework gaps. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2023-36846": {
     "name": "Juniper Junos OS SRX J-Web Missing Authentication File Upload",
@@ -50000,7 +51191,31 @@
         "adequate": false,
         "gap": "Technical-vulnerability-management that closes on 'patched' fails to include the mandatory session-invalidation step, so the residual token-replay risk persists."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A NetScaler ADC or Gateway configured as a VPN virtual server, ICA Proxy, CVPN, RDP Proxy or AAA virtual server is the authentication boundary for the applications behind it, so the standard 14/30-day windows the citing patch controls grade against are the wrong clock: the device is not protected by the perimeter, it is the perimeter, and the packet's request is unauthenticated and single-shot. This CVE argues for a distinct tier — for an internet-reachable appliance in one of those roles, either the fixed release is running or the exposed virtual server's public interface is taken offline, within hours of the 2023-10-18 KEV listing, with that shutdown pre-authorized so an on-call engineer can take it without a change window. The tier must be driven by configured role rather than product name: the packet ties the disclosure specifically to the Gateway and AAA virtual-server configurations, so an asset record showing only that a NetScaler exists cannot select the affected population — the inventory has to record which virtual servers are published and in which role. The completion criterion is the reboot, not the upload: the packet records no vendor live-patch mechanism and states remediation requires applying the fixed release and rebooting, so an appliance staged with the fixed build but not rebooted is not remediated. Distinguishing test: produce the list of appliances with a Gateway or AAA virtual server configured and show, per appliance, the running release and the reboot timestamp — an estate whose patch evidence is a product-level inventory passes while the exposed virtual servers keep answering.",
+        "evidence": "Citrix NetScaler ADC and NetScaler Gateway buffer overflow (CWE-119), CISA KEV-listed 2023-10-18, active exploitation confirmed, public PoC available, CVSS 7.5, RWEP 81, patch available. The packet's vector record scopes the sensitive information disclosure to appliances configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server. The packet's attack-vector record: an unauthenticated attacker sends an oversized request to a Gateway/AAA endpoint, triggering an out-of-bounds read that returns leaked memory. The packet's live-patch record: no vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The half of this control that binds here is the credential half, not the rebuild half, and the distinction is load-bearing: the packet establishes an out-of-bounds read that returns memory, not code execution on the appliance, so treating every exposed unit as carrying an implant would send operators after evidence the packet does not support. What the packet does establish is that the leaked memory contains valid session tokens which are replayed to hijack authenticated sessions and bypass MFA — and a token captured before the upgrade stays valid after it, because applying the fixed release stops further leakage and invalidates nothing already taken. Remediation for this CVE is therefore ordered: fixed release and reboot first, then invalidate every existing session on the appliance so leaked tokens cannot be replayed, then rotate the credentials and review the accounts reachable through the sessions the appliance was brokering. The replay produces no authentication event, which is exactly why the identity controls cited on this entry can pass their attestations while the path stays open — the second factor is never presented and no access decision is ever consulted, so evidence that every gateway user holds MFA says nothing about this exposure. Distinguishing test: on a staging appliance, capture a session token before the upgrade and replay it afterwards, confirming it is refused; an appliance recorded as remediated on release version alone still honours pre-upgrade tokens. Precondition: session invalidation stops replay of what leaked up to that moment — it does not undo actions already taken through a hijacked session, so any appliance that served a Gateway or AAA virtual server from an untrusted network on a vulnerable build needs the activity in that window reviewed rather than closed on the upgrade.",
+        "evidence": "Citrix NetScaler ADC and NetScaler Gateway, CISA KEV-listed 2023-10-18, active exploitation confirmed, public PoC available, CVSS 7.5, RWEP 81, patch available. The packet's attack-vector record: an unauthenticated attacker sends an oversized request to a Gateway/AAA endpoint, triggering an out-of-bounds read that returns leaked memory containing valid session tokens, which are then replayed to hijack authenticated sessions and bypass MFA. The packet's live-patch record: no vendor live-patch mechanism; remediation requires applying the fixed release and rebooting — an action that addresses the leak and not the tokens already obtained through it.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-B2",
+          "NIST-800-53-IA-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-20198": {
     "name": "Cisco IOS XE Web UI Privilege Escalation Vulnerability",
@@ -50057,7 +51272,41 @@
         "adequate": false,
         "gap": "ISM management-traffic-segregation guidance is widely unmet for edge routers, so the web UI remains internet-facing and abusable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet describes precisely what survives an upgrade. After reaching the IOS XE web UI unauthenticated, the actor issued a privilege 15 command to create a local user and password combination, logged in with that account, then used CVE-2023-20273 to elevate to root and write an implant to the file system. Installing a fixed IOS XE release removes neither: the account is stored configuration and the implant is a file, and an in-place upgrade inherits both. So for any unit whose web UI was reachable during the exposure window opened by the 2023-10-16 KEV listing, the default response is config-exfil, rebuild and credential rotation rather than patch-and-close: export running and startup configuration for offline comparison against a known-good baseline, enumerate the locally defined users and their privilege levels against that baseline and treat any account not in it as attacker-created, rebuild from vendor image plus baseline configuration, and rotate every credential the device held — local accounts, enable and AAA secrets, any shared secrets, and stored certificates. Precondition: this presumes a captured known-good baseline to diff against; a device without one can be rebuilt but cannot be cleared, so the absence of an obviously extra account is not evidence the unit is clean. Distinguishing test: on an exposed unit, diff the on-device account list and filesystem against the baseline before the upgrade — an attestation that every IOS XE unit sits at a fixed release proves the initial-access path is closed while a privilege-15 account the attacker created still authenticates and the implant still runs, and that is the specific way an account-management or access-control review passes on this device while the compromise persists.",
+        "evidence": "Packet: vector states 'The attacker first exploited CVE-2023-20198 to gain initial access and issued a privilege 15 command to create a local user and password combination... The attacker then exploited another component of the web UI feature, leveraging the new local user to elevate privilege to root and write the implant to the file system. Cisco has assigned CVE-2023-20273 to this issue.' CISA KEV listed 2023-10-16, active_exploitation 'confirmed', CVSS 10, RWEP 83, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' NIST-800-53-AC-2, ISO-27001-2022-A.5.15 and UK-CAF-B2 are recorded among the citing framework gaps.",
+        "gap_closes": [
+          "NIST-800-53-AC-2",
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The web UI is the entire initial-access path in this packet — an unauthenticated remote attacker reaches it and issues a privilege 15 command — and it is a feature of IOS XE that can be turned off. On the routers and switches carrying that software the exposure has to be graded at the trust boundary rather than as a generic OS patch item: the packet records CVSS 10, KEV listing on 2023-10-16, confirmed exploitation and a public PoC, so the requirement is the fixed IOS XE release deployed with the reboot the packet says remediation requires, on a clock that opens at the KEV listing — or the HTTP/HTTPS management server disabled, or its reachability cut, on every affected unit until that reboot completes. The standard 14- and 30-day appliance SLAs do not apply, because this device is the boundary everything behind it depends on. Precondition on the interim lever: disabling or restricting the web UI removes the delivery path only where the unit is genuinely managed by another channel — console, SSH CLI, or a management platform — and it is unavailable where the web UI is the operational management path. It also does nothing for a unit already compromised during the exposure window: the packet's attacker-created privilege-15 account lives in configuration and the implant on the filesystem, and both persist whether or not the interface is later turned off. Distinguishing test: from every segment that can route to the device, including any internet-facing interface, attempt to load the IOS XE web UI on a staging unit and confirm nothing answers — a patch-compliance report listing units as scheduled while the HTTP server still answers from an untrusted segment is measuring the wrong thing.",
+        "evidence": "Packet: CVSS 10, RWEP 83, poc_available true, KEV listed 2023-10-16 with active_exploitation 'confirmed'. attack_vector: 'An unauthenticated remote attacker abuses the IOS XE web UI to issue a privilege-15 command that creates a local user/password...'. patch_available true (the vector notes the vendor 'updating the list of fixed releases and adding the Software Checker'), live_patch_available false with remediation requiring the fixed release and a reboot. NIST-800-53-CM-7 (Least Functionality), NIST-800-53-SC-7 (Boundary Protection) and AU-ISM-1546 are recorded among the citing framework gaps.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIST-800-53-SC-7",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet names the exact record that decides whether an operator ever learns this happened: a privilege 15 command creating a local user and password combination. That is a configuration change the device itself emits — and the same chain ends with the attacker at root on that device, able to alter or suppress anything it retains locally. So IOS XE configuration-change and account-creation records must be forwarded as they are generated to a collector in a separate trust zone — different management plane, different credentials, no path from a rooted router back to the stored copy — with retention long enough to cover a window that here runs from the 2023-10-16 KEV listing back to whenever the unit first became reachable. Key the alert on the behaviour the packet documents rather than on a tool signature: a new locally defined user appearing on a network device outside a change window, and configuration writes not attributable to a known administrator session. Precondition: this detects, it does not prevent — nothing here stops the unauthenticated request — and it degrades exactly where it matters most, because an attacker who reached root can stop the device sending anything further, so a device going quiet is a reason to investigate rather than evidence it is clean. Distinguishing test: on a staging unit, create a local user from a privileged session, then attempt to remove the corresponding record from the device with root-equivalent access, and confirm the off-box copy is intact and has alerted.",
+        "evidence": "Packet: the attacker 'issued a privilege 15 command to create a local user and password combination', then 'elevate[d] privilege to root and write[s] the implant to the file system' (CVE-2023-20273). NIST-800-53-AC-2 (Account Management) is recorded among the citing framework gaps. active_exploitation 'confirmed'; patch_available true with live_patch_available false, so the detection covers the window before the fixed release and reboot land.",
+        "gap_closes": [
+          "NIST-800-53-AC-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-21608": {
     "name": "Adobe Acrobat and Reader Use-After-Free Vulnerability",
@@ -50971,7 +52220,30 @@
         "adequate": false,
         "gap": "System security assumes a sound browser sandbox, but the WebKit flaw is the initial code-execution primitive that breaks that assumption."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet records the fix in macOS Sonoma 14 and exploitation against iOS versions before iOS 16.7, so the population is the whole Apple estate — Macs alongside iPhones and iPads — and for this CVE the control means those builds are pushed as a managed, non-deferrable update on the clock that opened with the 2023-09-25 KEV listing rather than left to each user's own Software Update prompt. Measure completion by the OS build each device reports against the fixed build, never by the update having been offered, downloaded or marked approved: the packet records no live-patch mechanism and a remediation that requires applying the fixed release and rebooting, so a device that has staged the update but not restarted is still running the WebKit that processes the crafted content and belongs in the exposed count. The distinguishing test is to pull reported builds for the enrolled fleet and compare each against the fixed build; a compliance view showing the update as deployed while devices still report pre-fix builds is measuring the management console, not the estate. Precondition, and it is where this control gets over-claimed: the SLA reaches only devices the platform enrols and can actually compel. A personally-owned or lightly-managed device that receives configuration profiles but not update enforcement can sit below the fixed build indefinitely, and carrying it as 'pending' on the same clock hides a device that will never take the update through this path — for those the remaining lever is withholding organizational data until the build is at or above the fix.",
+        "evidence": "The packet records CVE-2023-41993 (Apple Multiple Products WebKit Code Execution Vulnerability, CWE-754) as CISA KEV-listed 2023-09-25 with active_exploitation 'confirmed', poc_available false, RWEP 61 against CVSS 8.8, patch_available true, and live_patch_available false with the note 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The packet's vector states: 'The issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14. Processing web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.' The documented attack path is a victim opening a targeted link or page, WebKit processing crafted web content, and arbitrary code execution in the renderer as the opening stage of the spyware chain.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this bug at the opening stage of a spyware chain, which makes the acutely exposed population narrower and more identifiable than the estate as a whole — the staff plausibly inside a targeting set. For that cohort the reboot-gated update is not fast enough on its own, so the control means those devices are held in a reduced-attack-surface mode in which untrusted web content, link previews, attachments and fonts are not processed automatically, narrowing the delivery path into the WebKit parsing bug across the window between the 2023-09-25 KEV listing and a completed update-and-restart. Two preconditions have to be stated rather than assumed, because this is where the control is routinely over-claimed. First, the packet's delivery step is a victim opening a targeted link or page: the mode's automatic-processing restrictions do not cover a user who deliberately opens the page, so it constrains how untrusted content is handled and shrinks the passive delivery paths — it does not stop the lure and it removes no part of the vulnerable code. Second, it only helps if it was already assigned when the chain arrived; switching it on after delivery does nothing about content already processed, and a device suspected of having already run the chain belongs on the incident path rather than the hardening path. Treat the assignment as a standing posture for the high-risk cohort set before the next disclosure, and as a holding measure for the window — not as a substitute for the fixed release and its restart.",
+        "evidence": "The packet documents the exploitation path as a victim opening a targeted link or page, WebKit processing crafted web content, giving arbitrary code execution in the renderer 'as the opening stage of the spyware chain' (CWE-754). It records active_exploitation 'confirmed' with poc_available false, CISA KEV listing 2023-09-25, CVSS 8.8, RWEP 61, and a vector noting the issue may have been actively exploited against versions of iOS before iOS 16.7, with the fix in macOS Sonoma 14. patch_available is true and live_patch_available false, noted as 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' AU-Essential-8-App-Hardening (User application hardening) is among the framework controls this entry cites as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2023-41179": {
     "name": "Trend Micro Apex One and Worry-Free Business Security Remote Code Execution Vulnerability",
@@ -51142,7 +52414,31 @@
         "adequate": false,
         "gap": "System security relies on kernel/driver integrity that this NPU-driver use-after-free directly violates."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet names the fixed release, SMR Jan-2022 Release 1, and a KEV listing date of 2023-09-18, and the distance between those two facts is the problem this control addresses: on a handset estate an OS update is applied at the user's convenience unless management compels it, so a fix that had existed for well over a year was still absent from enough Samsung devices to make the entry a KEV item. For this CVE the control means the mobile-management platform pushes and enforces that release on a defined KEV clock with user deferral disallowed, and reports completion from the security-patch level each handset actually reports rather than from the update having been made available to it. The packet records no live-patch path and a remediation that requires applying the fixed release and rebooting, so a handset that has downloaded the update but not restarted still runs the vulnerable NPU driver and stays in the exposed count — on a phone the restart is user-initiated, which is precisely where a 'deployed' figure and the real fleet state diverge. Precondition: the SLA binds only handsets the platform enrols with update-enforcement authority. A personally-owned device enrolled for mail access alone will typically expose its patch level to the platform without accepting compelled updates; for those the operative lever is the access condition, not this clock, and carrying them as 'pending enforcement' on the same SLA conceals devices that will never take the update through this path.",
+        "evidence": "The packet records CVE-2022-22265 (Samsung Mobile Devices Use-After-Free Vulnerability, CWE-703) as CISA KEV-listed 2023-09-18 with active_exploitation 'confirmed', poc_available false, RWEP 53 against CVSS 7.8, patch_available true, and live_patch_available false with the note 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Its vector states: 'An improper check or handling of exceptional conditions in NPU driver prior to SMR Jan-2022 Release 1 allows arbitrary memory write and code execution.' The documented attack path is a local app abusing improper exception handling in the Exynos NPU driver to trigger a use-after-free, gaining arbitrary kernel memory write and code execution for privilege escalation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records is a local app driving improper exception handling in the Exynos NPU driver into an arbitrary kernel memory write, so for a Samsung handset estate this control means treating the security-maintenance-release level as an access condition rather than a dashboard row: a device reporting below SMR Jan-2022 Release 1 is denied mail, VPN and document access until it is at or above that release. The distinguishing test is to enrol a handset pinned below that release and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale patch level on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition on the access half, which is where this is over-claimed: constraining which applications may be installed raises the bar for getting the attacker's app onto the handset, but it does not evict an app already installed and it does not cover one delivered through the normal store channel — a device suspected of already running it belongs on the incident path, not the install-policy path. There is also no driver-side lever to fall back on here. The packet's fix ships in the vendor's own maintenance release, which places the NPU driver inside the vendor OS build rather than in anything an enterprise can blacklist or unload, so unlike a loadable-module case there is no configuration that keeps the vulnerable code out of service — the fixed release is the only thing that removes it. This is a holding measure for the window before that release and its required restart land, not a substitute for them; the packet records no live-patch path and a remediation requiring the fixed release plus a reboot.",
+        "evidence": "The packet's vector states the flaw is 'An improper check or handling of exceptional conditions in NPU driver prior to SMR Jan-2022 Release 1 allows arbitrary memory write and code execution', and its attack path is a local app abusing improper exception handling in the Exynos NPU driver to trigger a use-after-free, gaining arbitrary kernel memory write and code execution for privilege escalation (CWE-703). It records CISA KEV listing 2023-09-18, active_exploitation 'confirmed', poc_available false, CVSS 7.8, RWEP 53, patch_available true, and live_patch_available false with the note 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2014-8361": {
     "name": "Realtek SDK Improper Input Validation Vulnerability",
@@ -52051,7 +53347,39 @@
         "adequate": false,
         "gap": "Periodic technical-vulnerability management cannot compel the emergency out-of-band upgrade to 6.9.5 / 7.0.2 that a KEV-listed unauthenticated RCE with a 3-day remediation window demands."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives an unauthenticated path from the open internet to remote code execution on a default WordPress install, so the clock this control sets is what stands between the 2026-07-21 KEV listing and a site being taken. The remediation the packet names is upgrading to 6.9.5 or 7.0.2, and the specific failure mode for this CVE is treating the forced automatic security update WordPress.org enabled as coverage. That push is a delivery mechanism, not an inventory: completion has to be measured per site by the core version each install actually reports, so that sites with core auto-updates disabled, deployed on a read-only filesystem, or built through a pipeline that pins core are surfaced as still vulnerable instead of assumed carried by the vendor. Scope the enumeration to the WordPress installs the organisation operates — including the ones that never reached an application inventory, such as campaign microsites, documentation and event sites, and multisite networks where one core version serves many hostnames — and not to web software generally; the packet ties this defect to the WordPress REST batch endpoint and implicates nothing else. The distinguishing test: pull the reported core version from every site the organisation serves and confirm each is at or above the fixed release, rather than confirming that automatic updates are enabled in policy — a policy attestation reads clean on an install whose updater has been disabled for years. Precondition: reaching the fixed version closes the dispatch defect for requests arriving afterwards and nothing more. Exploitation is confirmed and a public exploit exists, so for a site that was internet-reachable before the upgrade landed, the version bump is the start of the response, not the end of it.",
+        "evidence": "Packet: CISA KEV-listed 2026-07-21, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 79, CWE-436. vector: 'WordPress Core REST API batch endpoint (/wp-json/batch/v1) has an array-desynchronization interpretation conflict that misroutes handler dispatch, letting an unauthenticated attacker bypass validation to perform SQL injection and achieve remote code execution.' patch_available true; live_patch_available false; live_patch_notes: 'No live-patch mechanism; WordPress.org enabled forced automatic security updates. Remediation is upgrading to 6.9.5 / 7.0.2; interim mitigation is WAF-blocking /wp-json/batch/v1.' AU-Essential-8-Patch, NIST-800-53-SI-2, ISO-27001-2022-A.8.8 and UK-CAF-B4 are recorded as insufficient controls on this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet names an interim mitigation — WAF-blocking /wp-json/batch/v1 — alongside the fixed releases 6.9.5 and 7.0.2, and this control exists to stop the first being recorded as the second. A site running the WAF rule on a pre-fix core is in state (b): the batch endpoint's array-desynchronization defect is untouched and what stands between an attacker and it is a request-matching rule, whose failure reopens unauthenticated remote code execution in full. Carry that on the compliance record as its own state with a dated action item to reach the upgrade, rather than closing the finding as remediated. The preconditions that must travel with the rule, stated rather than assumed: it covers only requests that actually traverse the WAF, and only those its pattern matches. An origin reachable directly by IP or by a hostname that does not resolve through the proxy is unprotected; so is any route to the same REST handler that the pattern does not anticipate. And the reason that second precondition is sharper here than for an ordinary WAF-mitigated CVE is the defect itself — an interpretation conflict that desynchronizes handler dispatch is a disagreement about what a request means, which is precisely the assumption a request matcher in front of the handler depends on. Treat the rule as bounding exposure, never as removing the endpoint. The distinguishing test: from outside the network, send a batch-endpoint request to the site's origin address rather than through the WAF-fronted hostname, and confirm it is refused — a site whose audit record reads 'mitigated' while the origin answers directly is in state (c) and does not know it.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism; WordPress.org enabled forced automatic security updates. Remediation is upgrading to 6.9.5 / 7.0.2; interim mitigation is WAF-blocking /wp-json/batch/v1.' live_patch_available false; patch_available true. vector and attack_vector describe an 'interpretation conflict' / 'array-desynchronization' in the /wp-json/batch/v1 endpoint that 'misroutes handler dispatch', letting an unauthenticated attacker bypass validation. CVSS 9.8, RWEP 79, poc_available true, active_exploitation confirmed, KEV-listed 2026-07-21. NIST-800-53-SI-2 (Flaw Remediation) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as insufficient controls on this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's chain does not stop at code execution: the attacker bypasses validation, smuggles the CVE-2026-60137 SQL injection, forges an administrator account, and uploads a malicious plugin. Each of those is persistence that lives in the site's own database and filesystem, and upgrading to 6.9.5 or 7.0.2 removes none of them — a forged administrator is still a valid account after the upgrade, and an uploaded plugin is still loaded on the next request. An internet-facing WordPress install that takes a pre-auth RCE is in the same position this control was written for even though it is not a network appliance: the system that was breached is the system whose own records would have to be trusted to report the breach. So with exploitation confirmed and a public exploit available, an install that was serving before the fix landed is handled as possibly-compromised rather than closed on the version bump. Enumerate administrator and other privileged accounts with their creation times, compare the installed plugin set against a known-good manifest, and rotate what the exposed install held — database credentials, the site's authentication keys and salts, and any API keys or tokens stored in its configuration, since the SQL injection in the chain reaches the same database that holds them. Where those checks cannot be made conclusive, rebuild from a known-good baseline and re-import content instead of inheriting the running filesystem. Precondition, and the sequencing matters: this is the response for an install exposed during the window, not a substitute for the upgrade. Running the eviction work while the site is still on a pre-fix core hands the attacker the same path straight back in, so the upgrade — or, failing that, the packet's interim WAF block on /wp-json/batch/v1 with its own limits understood — goes first, and the account, plugin and credential work follows it.",
+        "evidence": "Packet attack_vector: 'An interpretation conflict in the WordPress REST batch endpoint desynchronizes handler dispatch, letting an unauthenticated attacker bypass validation, smuggle the CVE-2026-60137 SQLi, forge an administrator, and upload a malicious plugin for RCE on default installs (wp2shell).' active_exploitation confirmed; poc_available true; CISA KEV-listed 2026-07-21; CVSS 9.8, RWEP 79. patch_available true with live_patch_notes naming 6.9.5 / 7.0.2 as the remediation and WAF-blocking /wp-json/batch/v1 as the interim mitigation. NIS2-Art21-incident-handling (Incident handling) is recorded as an insufficient control on this entry.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2026-0770": {
     "name": "Langflow Inclusion of Functionality from Untrusted Control Sphere Vulnerability",
@@ -52112,7 +53440,42 @@
         "adequate": false,
         "gap": "Technical-vulnerability management cannot drive a patch that the vendor has not shipped; without a fixed release it does not compel the compensating network isolation and endpoint removal that actually stop exploitation of this unauthenticated exec() surface."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-103",
+        "name": "AI-APP-BUILDER-EXECUTION-ENDPOINT-AUTH-AND-SANDBOX",
+        "description": "Langflow is the visual LLM app/agent builder this control names, and CVE-2026-0770 is the precise defect it forbids: /api/v1/validate/code answers an unauthenticated POST and validate_code() hands the request body straight to exec(), with an exec_globals context that still exposes importlib and builtins, so attacker-supplied Python runs as the Langflow process — root in a default container. Bound to this product the requirement is that no route reaching that exec() sink answers an unauthenticated caller, and that any code the platform evaluates on a user's behalf runs with no filesystem, network or process reach beyond the flow's intent, instead of inside the server's own interpreter. Precondition, which is where this control is normally over-claimed: the packet records no patched version, so an operator cannot establish that property by updating. What they can do is what the packet names — block or remove exposure of /api/v1/validate/code at the reverse proxy, network-isolate the instance, and keep port 7860 off untrusted networks. That bounds who can send the POST; it does not repair the sink, it holds only for the routes the proxy actually fronts, and it is unavailable wherever the builder must stay reachable for normal use. It also does nothing for an instance already exploited: because exploitation is confirmed and the observed activity steals AWS credentials and cloud metadata, an instance that was reachable during the exposure window needs the container's cloud identity rotated and the flows and container rebuilt, not merely fronted with a new proxy rule. Distinguishing test: from an unauthenticated client against a staging instance, POST to /api/v1/validate/code a payload that imports a module and opens a network connection, and confirm it is refused before any code runs — an attestation that the AI platform is 'hardened' passes cleanly while a reachable 7860 keeps an unauthenticated exec() live.",
+        "evidence": "Packet vector: Langflow exposes an unauthenticated /api/v1/validate/code endpoint whose validate_code() passes attacker-supplied Python to exec() with an exec_globals context exposing importlib and builtins, yielding remote code execution as the Langflow process; attack_vector adds 'root in default containers' and that observed exploitation steals AWS credentials and cloud metadata. CWE-829, CVSS 9.8, RWEP 82, poc_available true, active_exploitation confirmed, CISA KEV-listed 2026-07-21. patch_available false and live_patch_available false; live_patch_notes record GHSA-g22f-v6f7-2hrh with first_patched_version: null, that ZDI published this as a zero-day, that a fixed release could not be confirmed from a primary source, that the CISA KEV required action is vendor mitigation or product discontinuation, and that the compensating controls are blocking/removing /api/v1/validate/code exposure, network-isolating Langflow, and not exposing port 7860 to untrusted networks.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this CVE the three-state distinction is not a refinement, it is the whole finding: state (a) is unreachable. The packet records patch_available false, GHSA-g22f-v6f7-2hrh carrying first_patched_version: null, and a fixed release that could not be confirmed from a primary source — so no Langflow deployment can legitimately be recorded as 'patched per SLA' for CVE-2026-0770, and a remediation register that closes this row on a patch is recording an event that has not happened. The verdict every instance must carry instead is state (b): compensating controls active, no binary patch, with the specific set named on the record — /api/v1/validate/code exposure blocked or removed, the instance network-isolated, port 7860 not reachable from untrusted networks — and the residual risk stated as what it is, that any gap in the proxy rule or any alternate route into the same exec() sink reopens unauthenticated RCE. Because the CISA KEV required action offers only vendor mitigation or product discontinuation, the time-bound action item this control demands cannot be 'apply the patch when it ships'; it has to be a dated decision point at which continuing to run Langflow is re-authorised against discontinuing it, so that an instance with no patch path does not sit under an open-ended risk acceptance while the ISMS reads clean. Distinguishing test: pull the vulnerability register's row for this CVE and confirm it shows a compensating-control state with a named review date and a discontinuation decision point, not a closed 'remediated' verdict — an SI-2 flaw-remediation attestation that treats the mitigation as a patch marks a confirmed-exploited, no-fix RCE compliant.",
+        "evidence": "Packet records patch_available false, live_patch_available false, and live_patch_notes stating GHSA-g22f-v6f7-2hrh has first_patched_version: null, that ZDI published this as a zero-day, that a fixed release could not be confirmed from a primary source, and that the CISA KEV required action is vendor mitigation or product discontinuation, with the compensating controls enumerated as blocking/removing /api/v1/validate/code exposure, network-isolating Langflow, and not exposing port 7860 to untrusted networks. active_exploitation confirmed; CISA KEV-listed 2026-07-21; RWEP 82; CVSS 9.8.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-033",
+        "name": "AI-ML-DEVELOPER-TOOLING-INVENTORY",
+        "description": "Langflow is an agent-framework control plane of exactly the kind this inventory exists to capture, and with no patched version recorded the inventory is the precondition for every other action on this CVE: the compensating controls the packet names can only be applied to instances someone knows about. Scoped to this product, the inventory must name every Langflow deployment with its listening endpoint (port 7860 by default), whether /api/v1/validate/code is reachable and from which networks, and the blast radius — which for CVE-2026-0770 is concrete rather than abstract, because the process runs as root in default containers and the observed in-the-wild activity takes AWS credentials and cloud metadata, so the blast radius is the cloud identity and instance-metadata reach the container holds. The control's patch-SLA-tier element cannot be exercised here and should not be recorded as though it were: the packet registers no fixed version, so the tier this asset class sits in is a compensating-control review clock, not a patch clock. Precondition: an inventory assembled from managed software distribution will miss the instances that matter, because self-hosted LLM builders are typically stood up by an application or data-science team outside it — the enumeration has to be done from the network side and reconciled, and it must be repeated, since a new instance stood up after the sweep is unprotected by definition. Distinguishing test: scan every environment for services answering on 7860 and on Langflow's API routes, reconcile the result against the asset register, and confirm each hit carries a recorded exposure decision — an ISMS asset register that lists no Langflow at all makes the technical-vulnerability-management attestation vacuous rather than clean.",
+        "evidence": "Packet attack_vector states the unauthenticated POST reaches exec() and gives remote code execution as the Langflow process, 'root in default containers', and that observed exploitation steals AWS credentials and cloud metadata. live_patch_notes name the compensating controls as blocking/removing /api/v1/validate/code exposure, network-isolating Langflow, and not exposing port 7860 to untrusted networks, and record that no patched version exists (GHSA-g22f-v6f7-2hrh, first_patched_version: null) with the CISA KEV required action being vendor mitigation or product discontinuation. CWE-829; poc_available true; active_exploitation confirmed; CISA KEV-listed 2026-07-21.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-27137": {
     "name": "DD-WRT Stack-Based Buffer Overflow Vulnerability",
@@ -52173,7 +53536,34 @@
         "adequate": false,
         "gap": "Technical-vulnerability management depends on an asset inventory that enumerates the firmware build; embedded UPnP services on edge routers are routinely outside that inventory, so the fixed changeset is never applied."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A DD-WRT router is the WAN/LAN trust boundary, and this CVE reaches it with a single unauthenticated UDP datagram: an M-SEARCH to SSDP/1900 whose oversized ST header is strcpy'd unbounded into a fixed 128-byte stack buffer in ssdp.c's ssdp_msearch, giving code execution with no credential, no session and no user interaction in the path. A generic operating-system patch window is the wrong instrument for it twice over — the device is usually not an OS line item on the estate at all, and the remediation the packet records is flashing a DD-WRT build at or after change set 45724, which needs a device reboot and, on most fleets, a hands-on flash per unit that no monthly cycle can absorb. So the tier requirement has to be met by the isolation half while the flash schedule runs: disable UPnP and block UDP/1900 at the WAN edge, as the packet's interim mitigation states. Precondition, stated because this control is routinely recorded as though it closed the surface: the WAN-edge block stops only the internet-side attacker. UPnP exists to serve the client network, so on a unit where the service stays enabled the vulnerable handler remains reachable from every host on the LAN, including an already-compromised IoT device — the filter bounds the attacker population, it does not remove the path. Where UPnP is not operationally needed, disabling it removes the listener and is the stronger action; where a LAN service depends on UPnP port mapping, neither lever applies and reaching change set 45724 is the only remedy for that unit. Distinguishing test: from the WAN side and again from a client on the LAN, send an M-SEARCH whose ST value exceeds 128 bytes and confirm no SSDP handler answers either — a patch attestation covering servers and workstations reports green while the boundary device itself still parses attacker-controlled datagrams.",
+        "evidence": "Packet vector: the DD-WRT UPnP/SSDP handler (ssdp.c, ssdp_msearch) performs an unbounded strcpy of a user-supplied oversized ST-header value into a fixed 128-byte stack buffer, allowing an unauthenticated attacker to overflow the buffer and achieve code execution; attack_vector confirms the trigger is an unauthenticated UDP M-SEARCH to SSDP/1900. CWE-121, CVSS 8.1, RWEP 70, poc_available true, active_exploitation confirmed, CISA KEV-listed 2026-07-21. live_patch_available false, with live_patch_notes stating there is no live-patch mechanism for router firmware, that remediation is flashing a DD-WRT build at or after change set 45724 which requires a device reboot, and that the interim mitigation is to disable UPnP and block UDP/1900 at the WAN edge.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not leave post-exploitation hypothetical: exploitation is confirmed and it names both the weaponizer and its objective — the Gafgyt/C0XMO botnet, weaponizing this overflow in 2026 to recruit routers as DDoS bots. On any DD-WRT unit whose SSDP/1900 was reachable during the exposure window, flashing change set 45724 is a patch and not a remediation, because the attacker already held code execution on the device. Flashing router firmware normally preserves the stored configuration, so an attacker-set administrative credential, DNS server, port forward or startup script carries across the upgrade untouched and the operator finishes with a device that reports the fixed build and is still attacker-held. The runbook for this device must therefore default to capturing the running configuration for analysis, reflashing to the fixed build with the stored configuration erased rather than migrated, re-entering settings from a known-good record, and rotating the administrative credential and any wireless or upstream credential the unit held — patch-in-place is the failure mode, not the plan. Detection, keyed to what an exploit doing exactly what this packet describes actually emits: inbound SSDP M-SEARCH datagrams to UDP/1900 whose ST header runs past the 128-byte buffer, and sustained outbound flood traffic sourced from the router itself, which is what recruitment as a DDoS bot produces. Precondition: both signals need the router's WAN-side traffic visible to something upstream, and a branch or home-office unit with no upstream telemetry produces no such record — there the safe default is to treat any unit that was exposed as compromised and rebuild it rather than to read the absence of an alert as evidence it was not hit.",
+        "evidence": "Packet attack_vector: an unauthenticated UDP M-SEARCH to SSDP/1900 with an oversized ST header overflows a 128-byte stack buffer in DD-WRT's UPnP handler via unbounded strcpy, enabling code execution; 'weaponized in 2026 by the Gafgyt/C0XMO botnet to recruit routers as DDoS bots'. active_exploitation confirmed; CISA KEV-listed 2026-07-21; poc_available true; CWE-121; RWEP 70. live_patch_notes record no live-patch mechanism for router firmware and that remediation is flashing a DD-WRT build at or after change set 45724, requiring a device reboot.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-68686": {
     "name": "Fortinet FortiOS Exposure of Sensitive Information to an Unauthorized Actor Vulnerability",
@@ -53629,7 +55019,33 @@
         "adequate": false,
         "gap": "A.8.7 protection against malware assumes reputation/warning controls raise friction on downloaded payloads, but this bypass removed the SmartScreen prompt entirely, letting Magniber-style loaders execute on first click until the fix was deployed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation of this CVE needs the victim to open the file, and the whole trick sits in the delivery: the payload is wrapped so the Mark-of-the-Web is stripped or evaded, and with no untrusted-origin mark on the file SmartScreen's Open File - Security Warning never appears, so the download executes on the first open with no reputation check in the path. On an estate that has not yet taken the July 2023 Windows cumulative security update and restarted, the enforceable control is upstream of the handler: the mail gateway, the web proxy and the untrusted file-share boundary apply the untrusted-origin tag themselves, rather than leaving the marking to whatever container the attacker chose, and that tag must survive extraction from an archive, mounting from an ISO or VHD, and renaming, so the wrapper cannot launder a downloaded payload into looking locally originated. Precondition, and it has two halves that both have to be said. First, boundary-applied provenance reaches only the ingress paths those boundaries actually control: a payload written to disk by a cloud-sync client, arriving on removable media, or delivered over any channel that never applies the tag lands unmarked regardless of policy, and on that host the cumulative update and its reboot is the only thing that closes the path. Second, this addresses the strip variant — where the crafted wrapper causes the marked file to be mishandled rather than unmarked, the tag is present and the check still fails, and again only the update closes it. Distinguishing test: deliver the payload through each ingress path nested inside an archive, extract it on a managed workstation, and confirm the extracted file still carries the untrusted-origin mark and still raises the warning — a user-application-hardening attestation covering macro and add-in settings says nothing about whether provenance survived the container.",
+        "evidence": "Packet attack_vector: 'A crafted file wrapped to strip or evade the Mark-of-the-Web bypasses SmartScreen's Open File - Security Warning, so a downloaded payload executes without the reputation prompt once the user opens it.' Vector and name identify it as a Microsoft Windows Defender SmartScreen security-feature-bypass vulnerability; CWE-693; CVSS 8.8; RWEP 65; poc_available true; active_exploitation confirmed; CISA KEV-listed 2023-07-11. patch_available true with live_patch_available false, and live_patch_notes stating there is no vendor live-patch mechanism and that remediation is the July 2023 Windows cumulative security update, which requires a reboot to take effect.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "What failed here is a defense rather than a parser: CWE-693, a SmartScreen security-feature bypass, where the file is wrapped so the Mark-of-the-Web is stripped or evaded and the Open File - Security Warning simply does not appear. That changes what counts as proof of remediation — for a memory-safety bug the build number is reasonable evidence, but for a bypassed protection mechanism the only evidence the July 2023 Windows cumulative security update fixed anything is that the warning now fires for the wrapping that previously suppressed it. Applied to this CVE, the MotW/SmartScreen class needs a standing battery in the detonation chamber that replays the wrapper forms which strip or evade the mark, executed on every cumulative-update deployment rather than once against this CVE, and held alongside the EDR and AppLocker/WDAC rules that have to carry the load whenever the prompt does not fire — because a reputation prompt the user can be walked past was never an execution control to begin with. Precondition: the battery proves only what it replays, so a wrapper form nobody added to it is untested no matter how green the run looks; and because this update takes effect only after a reboot, a host that installed it and has not restarted will pass a patch-inventory query while still executing the payload silently. Distinguishing test: after the update lands and the host has restarted, open the wrapped payload on a managed workstation and confirm the Open File - Security Warning is raised — a patch register showing the July 2023 cumulative update deployed is a record of an install, not evidence that the bypass class is closed.",
+        "evidence": "Packet name and vector: Microsoft Windows Defender SmartScreen Security Feature Bypass Vulnerability / 'Windows SmartScreen Security Feature Bypass Vulnerability', CWE-693. attack_vector: a crafted file wrapped to strip or evade the Mark-of-the-Web bypasses SmartScreen's Open File - Security Warning, so a downloaded payload executes without the reputation prompt once the user opens it. active_exploitation confirmed; CISA KEV-listed 2023-07-11; poc_available true; CVSS 8.8; RWEP 65. live_patch_available false and live_patch_notes record no vendor live-patch mechanism, with remediation being the July 2023 Windows cumulative security update, which requires a reboot to take effect.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-35311": {
     "name": "Microsoft Outlook Security Feature Bypass Vulnerability",
@@ -53690,7 +55106,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would prioritize CVE-2023-35311 on its KEV listing, but until the Office update is applied the compensating control (user heeding the security prompt) is exactly what the flaw neutralizes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The thing this CVE defeats is itself a protective control: a time-of-check-time-of-use race suppresses the Outlook Security Notice, the prompt that normally precedes activation of risky content in a message. Bound to Outlook, the control means that prompt is treated as a protection-mechanism class with its own regression battery — every known primitive that has suppressed or bypassed the Security Notice is replayed against a staged Outlook build on each Office and Windows update deployment, and the outcome is recorded as a pass/fail on the mechanism itself rather than inferred from the build number. That distinction is the whole point here: the compliance record for this entry is a patch level, while the thing an operator actually depends on is whether the warning still appears, and nothing in a flaw-remediation attestation exercises the prompt. The same applies downward — any phishing or user-awareness control in the estate that assumes the user is warned before activating message content must be recorded as not operative on clients below the fix, because the packet's exploitation path is precisely that the warning is not shown. Distinguishing test: on a staged client at or above the July 2023 update, deliver the crafted-message primitive and confirm the Security Notice is displayed before any risky content can be activated; recording the update as installed is not a demonstration that the prompt returned. Precondition, and it is a real limit: a regression battery can only replay bypass primitives that are already known and reproducible, so it will pass against a novel suppression of the same prompt. It also verifies rather than remediates — it gives an operator nothing during the window before the July 2023 Microsoft security update is applied and Outlook is restarted.",
+        "evidence": "The packet's attack vector is a time-of-check-time-of-use race (cwe_refs: CWE-367) in Outlook that lets a maliciously crafted message bypass the Outlook Security Notice prompt, 'so the protective warning that normally precedes activation of risky content is not shown, easing execution of a phished payload' — the bypassed item is a protection mechanism, which is what puts this entry in that class. The entry is CISA KEV-listed 2023-07-11 with active_exploitation 'confirmed' (rwep_score 47, cvss 8.8); poc_available is false, so prioritization rests on the KEV listing and confirmed exploitation rather than on a public exploit. patch_available is true and live_patch_available is false, with live_patch_notes stating the fix ships in the July 2023 Microsoft security update and applies on the next Office/Windows update cycle, typically requiring an application restart or reboot.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the KEV clock opened 2023-07-11 and the packet records no live-patch path, so the only remediation is the July 2023 Microsoft security update — which the packet says applies on the next Office/Windows update cycle and typically requires an application restart or reboot. Bound to Outlook, that makes the completion definition the load-bearing half: the clock runs to a restarted Outlook client on every mailbox, not to an update marked approved, downloaded or installed in the management console. A workstation that took the July 2023 update while Outlook stayed running continuously still carries the vulnerable code, and a long-uptime desktop with a never-closed mail client is exactly where that deferral hides from a patch report. Standard 14- and 30-day patch SLAs miss this twice: the window is wrong for a KEV-listed flaw under confirmed exploitation, and the completion measure is wrong for a fix that only takes effect on client restart. Distinguishing test: report, per mailbox client, whether the Outlook process has been restarted since the update was applied, not merely which Office build is present on disk. Precondition: this control is a clock and a completion definition, not a mitigation. It does not reduce exposure during the window, and the packet names no vendor mitigation and no compensating control for this entry — until the update lands and Outlook restarts, nothing operator-side restores the suppressed prompt, so any process that treats the Security Notice as a barrier should be assumed to have none.",
+        "evidence": "cisa_kev is true with kev_date 2023-07-11 and active_exploitation 'confirmed' (rwep_score 47, cvss 8.8). patch_available is true; live_patch_available is false; live_patch_notes: 'No live-patch mechanism; the fix ships in the July 2023 Microsoft security update and applies on the next Office/Windows update cycle, typically requiring an application restart or reboot.' The packet records no vendor mitigation or compensating control for this entry. The gaps cited against it are patch- and vulnerability-management controls (ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8, NIST SP 800-53 SI-2 Flaw Remediation, NIS2 Art. 21 vulnerability handling and disclosure).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-36874": {
     "name": "Microsoft Windows Error Reporting Service Privilege Escalation Vulnerability",
@@ -53751,7 +55191,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management may downgrade a 7.8 local-only LPE versus network CVEs, yet as a live-exploited escalation link in intrusion chains it warranted emergency patching that a CVSS-vector-only triage would delay."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet puts the attacker at ordinary standard-user privilege on the host: they plant a malicious wermgr.exe and use NTFS junctions or hard links in a WER-controlled path so the Windows Error Reporting service, which trusts the link target, launches that binary as SYSTEM. For this CVE the control means the July 2023 Windows cumulative update is driven across every affected host on the clock that opened with the 2023-07-11 KEV listing rather than folded into the next monthly rollup, with completion measured per host as installed build at or above the fixed build AND the reboot actually taken — the packet records no live-patch path and a fix applied through the standard servicing stack that requires a reboot, so a host that staged the update and has not restarted still runs the vulnerable code and must be counted as exposed. Enumerate first the hosts where non-administrative users hold interactive local sessions — shared workstations, session hosts, jump boxes, build and developer machines — because on those the exploit's only stated precondition, an ordinary local user, is the normal operating state rather than an anomaly. The control's second half is the load-bearing one here, and it is exactly why the least-privilege gap is recorded against this entry: the attacker holds no privilege they were not legitimately granted, so removing local-administrator rights or tightening per-account scoping does not contain the escalation, and an AC-6 attestation passes cleanly while the flaw stays fully exploitable. Precondition on the interim lever: restricting which accounts may log on interactively bounds the population that can attempt this, but it does not close the path — any account that legitimately reaches the desktop satisfies the precondition in full, and on a shared session host that is every user. And because active exploitation is confirmed and a public PoC exists, a host that carried untrusted local users during the exposure window needs forensic triage and credential rotation rather than closure on the patch: the update repairs the link handling but removes nothing an attacker already installed while holding SYSTEM.",
+        "evidence": "The packet's attack vector: 'A standard user plants a malicious wermgr.exe and uses NTFS junctions/hard links in a WER-controlled path so the Windows Error Reporting service, which trusts the link target (CWE-59), launches the attacker binary as NT AUTHORITY SYSTEM.' cwe_refs is CWE-59. cisa_kev true, kev_date 2023-07-11, active_exploitation 'confirmed', poc_available true, rwep_score 68, cvss 7.8. patch_available is true and live_patch_available is false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires the July 2023 Windows cumulative update, which is applied via the standard servicing stack and requires a reboot.' NIST SP 800-53 AC-6 (Least Privilege) is among the framework gaps citing this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scan that reports this host 'patched' because the July 2023 cumulative update appears in its servicing record is paper compliance twice over. First, the packet states the update is applied through the standard servicing stack and requires a reboot, so a host with the update staged and no restart reports patched while still running the vulnerable Windows Error Reporting path — reboot-pending state has to be reported alongside installed build for every host in the remediation population, or the dashboard converts an exposed host into a compliant one. Second, and more fundamental for this CVE, the exploitable condition is a filesystem-link behaviour rather than a version: a standard user creating an NTFS junction or hard link in a WER-controlled path so the service launches a planted binary from a location that user can write. No version query observes that. The operational test, keyed to the behaviour the packet documents: on a staging host at or above the fixed build and rebooted, run as a standard user, plant a binary, redirect a WER-controlled path at it through a junction or hard link, and confirm the Error Reporting service does not launch the linked target with SYSTEM privileges. Precondition: this is a verification method, not a mitigation. It tells the operator whether remediation actually landed on the build they tested and nothing about hosts on a different build, it requires a staging host on which the plant can be attempted safely, and it says nothing about a host already compromised before the test was run — confirmed exploitation means the estate can hold hosts where the answer is 'the primitive worked, weeks ago'.",
+        "evidence": "live_patch_notes record the fix as 'the July 2023 Windows cumulative update, which is applied via the standard servicing stack and requires a reboot', with live_patch_available false — so an installed-but-unrebooted host is still vulnerable. The attack vector describes the exploitable condition as a standard user planting a malicious wermgr.exe and using NTFS junctions/hard links in a WER-controlled path that the Windows Error Reporting service trusts (CWE-59) to launch the binary as SYSTEM, which is a behaviour rather than a version state. active_exploitation is 'confirmed' and poc_available is true (kev_date 2023-07-11). The entry's cited gaps include ISO/IEC 27001:2022 A.8.8 (management of technical vulnerabilities) and ASD Essential Eight patching.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2022-31199": {
     "name": "Netwrix Auditor Insecure Object Deserialization Vulnerability",
@@ -54350,7 +55814,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management struggles with mobile-baseband/DSP components an organisation cannot directly patch; the ELF-into-DSP capability was an OEM-only fix, leaving a coverage gap until the SMR propagated to each device."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's exploitation path is local: a process already running on the handset abuses the Samsung DSP driver's missing ELF validation to load arbitrary libraries into the DSP, gaining code execution in DSP context as a step in an on-device privilege-escalation chain. Remediation is the SMR Mar-2021 Release 1 or later firmware update, which reboots the device. Bound to this estate, the control means the fixed security-patch level is enforced as an access condition rather than published as a statistic: a managed Samsung handset below SMR Mar-2021 Release 1 is denied mail, VPN and document access by policy until it reaches that level, so the exposure is removed from the organization's data instead of being recorded against it. Enrolment has to read the device's actual security-patch level, because that — not the Android version and not the model — is what distinguishes a handset still carrying the vulnerable DSP driver. For any handset that cannot be brought to SMR Mar-2021 Release 1 or later, reaching a fixed build is not available at all: the terminal state is replacement and removal from the estate on a dated schedule, and a requirement that ends at 'every device reports the fixed level' would mark such a handset compliant only by leaving it out of the count. Distinguishing test: enrol a handset pinned below SMR Mar-2021 Release 1 and confirm policy actually denies it access to protected resources — an estate that surfaces the stale patch level on a report while the device keeps its mail and VPN sessions has recorded the exposure, not removed it. Precondition, and it is the limit that matters here: this is an access condition on organizational data, and the packet's exploitation path presupposes a local process already running on the device. It therefore neither removes that process nor reverses code already loaded into the DSP on a handset exploited before enrolment — a device suspected of that belongs on the incident path, not the access-policy path — and it is a holding measure only for the window before the firmware update and its reboot land.",
+        "evidence": "The packet's vector: 'A vulnerability in DSP driver prior to SMR Mar-2021 Release 1 allows attackers load arbitrary ELF libraries inside DSP', and its attack vector: 'A local process abuses the Samsung DSP driver's missing ELF validation to load arbitrary libraries into the DSP, gaining code execution in the DSP context as a stepping stone in an on-device privilege-escalation chain.' cwe_refs is CWE-912. cisa_kev true with kev_date 2023-06-29 and active_exploitation 'confirmed'; poc_available false; rwep_score 48, cvss 6.7. patch_available is true and live_patch_available is false; live_patch_notes: 'No live-patch mechanism for the Samsung DSP driver; remediation is applying the SMR Mar-2021 Release 1 (or later) firmware update, which reboots the device.' The packet states no end-of-support status for the affected handsets, so whether a given unit can reach the fixed level is a per-device question the inventory has to answer.",
+        "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": "The KEV clock on this entry opened 2023-06-29 under confirmed exploitation, and the packet records no live-patch mechanism for the Samsung DSP driver — the only remediation is the SMR Mar-2021 Release 1 or later firmware update, which reboots the device. The control means that update is driven from the MDM/EMM managing the handset on the KEV clock with user deferral disallowed, and completion measured per device as the security-patch level the handset itself reports after it restarts. The restart is the step this particular remediation loses: a firmware update that reboots a phone someone carries is the update a user postpones indefinitely, and a handset that has downloaded it without restarting still runs the vulnerable driver while appearing actioned in the console. Priority should follow the packet rather than the 6.7 CVSS band — the packet describes DSP-context code execution as a stepping stone in an on-device privilege-escalation chain, so this is a chain link on a device holding organizational mail, tokens and credentials rather than a standalone low-severity item, and confirmed in-the-wild exploitation is what sets the clock, not the score. Precondition: enforcement reaches only handsets the MDM/EMM actually enrols and can drive to a firmware level. An unenrolled or personally-managed device is outside this control entirely and has to be handled by conditional access instead, and a handset for which SMR Mar-2021 Release 1 or later is not obtainable cannot be remediated by this control at all — that unit belongs on the replacement path, since there is no build the operator can drive it to.",
+        "evidence": "cisa_kev true, kev_date 2023-06-29, active_exploitation 'confirmed' (rwep_score 48 against cvss 6.7). live_patch_available is false with live_patch_notes: 'No live-patch mechanism for the Samsung DSP driver; remediation is applying the SMR Mar-2021 Release 1 (or later) firmware update, which reboots the device.' The attack vector describes the DSP-context code execution as 'a stepping stone in an on-device privilege-escalation chain'. The gaps citing this entry are patch- and vulnerability-management controls (ASD Essential Eight 'Patch operating systems', NIST SP 800-53 SI-2 Flaw Remediation, NIS2 Art. 21 vulnerability handling).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-25372": {
     "name": "Samsung Mobile Devices Improper Boundary Check Vulnerability",
@@ -55394,7 +56882,44 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management for network appliances often lacks asset visibility into edge firewalls, so the unauthenticated RCE persisted on unpatched Zyxel devices well past the vendor's 2023-05-24 fix while botnet enrollment proceeded."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The affected units are the trust boundary itself — Zyxel ATP, USG FLEX, USG FLEX 50(W), USG20(W)-VPN, VPN series and ZyWALL/USG firewalls — and the packet places the overflow in the ID-processing function reachable by an unauthenticated attacker, so the device that terminates the perimeter is the device that runs the attacker's code. For these units the control means the fixed firmware branch (above 5.36 Patch 1, or above 4.73 Patch 1 on the ZyWALL/USG line) is driven on the KEV clock that opened 2023-06-05 rather than into the next appliance-maintenance window, and completion is measured per unit by the firmware version actually running after the reboot the flash requires. The packet records no live-patch path, so a unit with the image staged but not yet rebooted is still running the vulnerable ID-processing code and must be counted exposed. Where the reboot cannot be taken immediately, the control's alternative is isolation of the vulnerable interface, which the packet identifies as restricting WAN-side management and VPN access. Precondition, and this is where that interim mitigation is routinely over-claimed: restricting WAN-side reachability bounds who can send the crafted request, but on a USG20(W)-VPN or VPN-series unit whose function is terminating remote-access VPN from the internet, the VPN service must keep answering untrusted sources, so for that interface the restriction removes nothing and only the firmware flash does. A unit in that state is on the accelerated clock, not on a compensating control.",
+        "evidence": "Packet: CWE-120 buffer overflow in the ID-processing function, reachable by an unauthenticated attacker for DoS or remote code execution. Affected branches ATP 4.32–5.36 Patch 1, USG FLEX 4.50–5.36 Patch 1, USG FLEX 50(W) 4.25–5.36 Patch 1, USG20(W)-VPN 4.25–5.36 Patch 1, VPN 4.30–5.36 Patch 1, ZyWALL/USG 4.25–4.73 Patch 1. CISA KEV 2023-06-05, active_exploitation confirmed, CVSS 9.8, RWEP 57. patch_available true; live_patch_available false, with live_patch_notes stating remediation requires flashing fixed firmware above the affected 5.36 Patch 1 / 4.73 Patch 1 branches, which reboots the device, and naming restriction of WAN-side management/VPN access as the recommended interim mitigation.",
+        "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-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives unauthenticated code execution on the firewall with confirmed in-the-wild exploitation from the 2023-06-05 KEV listing, so for any unit that was internet-reachable during the exposure window the open question is not whether the vulnerable function is still present but whether the device is still the operator's. Flashing the fixed firmware replaces the vulnerable ID-processing code; it does not remove configuration an attacker wrote, accounts an attacker added, or credentials an attacker read out of the device — and on an ATP / USG FLEX / USG20(W)-VPN / VPN-series / ZyWALL unit that means VPN pre-shared keys, remote-access user credentials and administrator passwords. For this CVE the control means any such unit that answered from the WAN during the window is handled as suspected-compromised: its configuration exported for comparison against a known-good baseline rather than carried forward, the device rebuilt onto the fixed firmware from a clean configuration, and every credential the device held rotated. Precondition: the rebuild is only as good as the baseline it restores from — a configuration exported after the exposure window and re-imported unchanged reinstates whatever the attacker left in it — and the reboot the flash requires is not a compromise-recovery step on its own. The packet records poc_available false; that is not a triage input here, because active exploitation is separately recorded as confirmed, so absence of a public exploit is not evidence a given unit was untouched.",
+        "evidence": "Packet: unauthenticated attacker sends a crafted request that overflows the buffer in the firewall's ID-processing function, causing a crash or executing attacker-controlled code on the device. CISA KEV 2023-06-05; active_exploitation confirmed; poc_available false; CVSS 9.8; RWEP 57. patch_available true, live_patch_available false, with the vendor fix being a firmware flash that reboots the device.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry has two remediation states that a vulnerability register normally collapses into one. State (a) is the Zyxel firmware above the 5.36 Patch 1 / 4.73 Patch 1 branches, flashed and rebooted, which removes the overflow. State (b) is the packet's own named interim mitigation — WAN-side management and VPN access restricted — with the vulnerable firmware still running, so the ID-processing overflow is intact and reachable by anything still inside the permitted scope. For these firewalls the control means state (b) is recorded as a time-bound compensating control with a dated action item to reach the flash, never as 'patched within SLA', and the register carries the firmware version running on each unit rather than a remediation flag. The distinguishing test is per unit and keys on what the device reports rather than on what the register asserts: read back the firmware version actually running and the current WAN access rules, and confirm the recorded verdict matches. An estate whose report shows the KEV item closed while units still run 5.36 Patch 1 behind an access rule has recorded a mitigation as a fix. Precondition: this is accounting, not defence — it changes nothing on the device. Its value is that it stops the interim state ageing out of view, which on unmanaged edge units is how the exposure outlives the availability of the fix.",
+        "evidence": "Packet: patch_available true and live_patch_available false, with live_patch_notes stating that remediation requires flashing fixed firmware above the affected 5.36 Patch 1 / 4.73 Patch 1 branches (which reboots the device) and that restricting WAN-side management/VPN access is the recommended interim mitigation — two distinct states named in the same entry. CISA KEV 2023-06-05, active_exploitation confirmed, CVSS 9.8.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-34362": {
     "name": "Progress MOVEit Transfer SQL Injection Vulnerability",
@@ -55699,7 +57224,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management struggles to enforce timely WebKit updates on personally-owned or embedded devices that rely on WebKit for HTML processing, leaving a known-exploited info-disclosure flaw unremediated past the KEV due date."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The fix for this WebKit read does not ship as one update — the packet names watchOS 9.5, tvOS 16.5, macOS Ventura 13.4, iOS and iPadOS 16.5, iOS and iPadOS 15.7.6, and Safari 16.5. An enforcement policy written only against iOS/iPadOS and current macOS therefore leaves the Apple TVs, the Watches, and any Mac taking Safari 16.5 as a separate update outside the SLA entirely, while the compliance view reads clean. For this CVE the control means the enforced minimum is expressed per train against the specific fixed build rather than as 'latest major version': a device on the 15.x line is remediated by 15.7.6 and must be driven there rather than written off as unsupportable, and a Mac left on an older macOS is remediated by Safari 16.5. The packet records no live-patch path and states the fix requires installing the update and restarting the device, so the completion signal is the post-restart build each device reports — an update downloaded or sitting at 'pending restart' still runs the vulnerable HTML-processing path and is not remediated. Precondition: this reaches only devices the management channel actually enrols and can compel. Hardware in the estate that no management channel holds is not covered by this control at all, and the remaining lever there is withholding access to organizational data until the device reports a fixed build — not carrying it as a standing exception.",
+        "evidence": "Packet: CWE-125 out-of-bounds read; the vector states the issue is fixed in watchOS 9.5, tvOS 16.5, macOS Ventura 13.4, iOS 15.7.6 and iPadOS 15.7.6, Safari 16.5, iOS 16.5 and iPadOS 16.5, and that processing web content may disclose sensitive information. CISA KEV 2023-05-22; active_exploitation confirmed; CVSS 6.5; RWEP 45. patch_available true; live_patch_available false, with live_patch_notes stating there is no live-patch mechanism and that the listed fixes require installing the update and restarting the device.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet's outcome is an information disclosure — sensitive memory including pointers usable to defeat ASLR — not code execution, and the CVSS of 6.5 reflects that. Read as a chain input rather than a standalone bug, the priority inverts: the leak is what makes a following memory-corruption step reliable, so the population that matters is the cohort the operator has already designated as high-risk. For those users the control means a standing reduced-attack-surface posture on their Apple devices, so untrusted web content is not processed automatically by WebKit, narrowing the delivery path into the out-of-bounds read during the window between the 2023-05-22 KEV listing and the completed install-and-restart of watchOS 9.5 / tvOS 16.5 / macOS Ventura 13.4 / iOS and iPadOS 16.5 or 15.7.6 / Safari 16.5. Two preconditions, both load-bearing. The posture narrows what reaches the parser; it does not remove the flaw — content the user deliberately opens still reaches WebKit's HTML processing — so this is a holding measure for the pre-update window, not a substitute for the fixed build and its restart. And it only helps if it was already on when the content arrived: assigning it after a device has rendered the attacker's page changes nothing about what was already read out of that process, which is an incident-response matter rather than a configuration one. Scope it to the designated cohort and to the Apple products the packet names; extending it estate-wide is a usability cost that adds no coverage of this CVE.",
+        "evidence": "Packet: maliciously crafted web content drives WebKit's HTML processing past a buffer boundary, reading out-of-bounds memory and disclosing sensitive information such as pointers used to defeat ASLR (CWE-125). Vector states processing web content may disclose sensitive information and that Apple is aware of a report the issue may have been actively exploited; active_exploitation recorded as confirmed. CISA KEV 2023-05-22; CVSS 6.5; RWEP 45. live_patch_available false, with the fix requiring installation of the listed builds and a device restart.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-32373": {
     "name": "Apple Multiple Products WebKit Use-After-Free Vulnerability (CVE-2023-32373)",
@@ -55882,7 +57431,38 @@
         "adequate": false,
         "gap": "A.8.24 use-of-cryptography is silently undermined: leaking the IKE pre-shared key/RSA material via memory disclosure lets an attacker impersonate or decrypt the VPN, so strong crypto configuration is worthless once CVE-2016-6415 hands over the keys."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-137",
+        "name": "DEPRECATED-VPN-KEY-EXCHANGE-DISABLE-AND-MACHINE-CERT-ENFORCEMENT",
+        "description": "The vulnerable surface here is the deprecated key-exchange responder itself: the packet places the flaw in the server IKEv1 implementation and reaches it with a single crafted Security Association negotiation request to UDP/500 from an unauthenticated remote attacker. Bound to the products the packet names — Cisco IOS 12.2 through 12.4 and 15.0 through 15.6, IOS XE through 3.18S, IOS XR 4.3.x and 5.0.x through 5.2.x, and PIX before 7.0 — the control means inventorying which of those devices have IKEv1 enabled and answering, moving the peers that can move to IKEv2, and disabling IKEv1 where no peer requires it, so the responder the attacker talks to is gone rather than merely patched on the vendor's schedule. Scope it to those devices: the packet ties the defect to those Cisco trains and provides no mapping into other vendors' IKEv1 stacks, so a sweep that disables IKEv1 across every gateway in the estate manufactures work against products no evidence implicates. The certificate half of this control is not the operative half on this entry — the packet describes memory disclosure of key material, not a certificate-validation bypass, and certificates held by the device are among the material the packet says the leak may return, so requiring machine certificates does not reduce this exposure. Distinguishing test: from an address outside the configured peer set, send an IKEv1 SA negotiation request to UDP/500 against each named device and confirm nothing answers. Preconditions: disabling IKEv1 closes the path only on devices where every peer can be moved off it. A device that must keep IKEv1 for a legacy peer still answers on UDP/500, and the remaining lever there is restricting which sources may reach that port to the known peer addresses — which bounds who can send the request but leaves the responder fully exploitable to anything inside the permitted set, and is unavailable where peers connect from dynamic addresses. Neither measure removes material that was already read out.",
+        "evidence": "Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure Vulnerability (CWE-200), CISA KEV-listed 2023-05-19, active exploitation confirmed, public PoC available, CVSS 7.5, RWEP 70, patch available. The packet's vector record: the server IKEv1 implementation in Cisco IOS 12.2 through 12.4 and 15.0 through 15.6, IOS XE through 3.18S, IOS XR 4.3.x and 5.0.x through 5.2.x, and PIX before 7.0 allows remote attackers to obtain sensitive information from device memory via a Security Association negotiation request (Bug IDs CSCvb29204 and CSCvb36055, aka BENIGNCERTAIN). The packet's attack-vector record places the request on UDP/500 from a remote unauthenticated attacker, with insufficient condition checks causing the device to return chunks of memory that may contain IKE pre-shared keys, certificates, and configuration.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The credential half of this control is what binds on this entry, and the rebuild half deliberately does not: the packet's primitive is a read — a crafted IKEv1 negotiation request that returns chunks of device memory — and nothing in it establishes attacker code on the router, so dispositioning every exposed unit as implanted would send operators after evidence the packet does not support. What the packet does establish, and states outright in its own remediation note, is that the returned memory may contain IKE pre-shared keys, certificates and configuration, and that those should be rotated after exposure. So for this CVE the flaw-remediation record is not the remediation: upgrading to a fixed Cisco image stops further leakage and leaves every key already read fully valid. Applied to these devices that means re-keying the IKE pre-shared key on each tunnel the device terminates — on both peers, since the key is shared — re-issuing the certificates it held, and reviewing the running configuration for anything else that would be sensitive in the clear. Ordering matters: rotating before the fixed image is running re-exposes the new material to the same request, so the upgrade and its reboot come first and the rotation follows. Distinguishing test: for each device whose UDP/500 responder was reachable from an untrusted network before the upgrade, produce the date each tunnel's pre-shared key was changed and show it falls after the fixed image was running; a record showing the fixed image with the original keys still in service documents the leak as closed while the leaked keys stay usable. Precondition: rotation removes the value of what was read — it does not tell you whether anything was read, and the packet supplies no per-device indicator, so disposition must be driven by whether the responder was reachable from untrusted networks during the window rather than by a search for evidence of exploitation.",
+        "evidence": "Cisco IOS, IOS XR, and IOS XE IKEv1 information disclosure, CISA KEV-listed 2023-05-19, active exploitation confirmed, public PoC available, CVSS 7.5, RWEP 70, patch available. The packet's attack-vector record: a remote unauthenticated attacker sends a crafted IKEv1 Security Association negotiation request to UDP/500 and insufficient condition checks cause the device to return chunks of memory that may contain IKE pre-shared keys, certificates, and configuration. The packet's live-patch record: no live-patch mechanism for classic Cisco IOS/PIX; remediation is upgrading to a Cisco fixed IOS/IOS XE/IOS XR image, which reboots the device, and pre-shared keys/certificates should be rotated after exposure.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.24",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Two things about this entry defeat an ordinary vulnerability-management clock. First, the CVE identifier is from 2016 while the KEV listing is 2023-05-19 — a program that ages and prioritises items by publication date deprioritised this years before it was listed, so the SLA has to key on the listing date and on the confirmed-exploitation and public-PoC status the packet records, not on the CVE year. Second, the completion criterion is the reload: the packet records no live-patch mechanism for classic Cisco IOS/PIX and states that remediation is upgrading to a fixed IOS, IOS XE or IOS XR image, an operation that reboots the device. A router with the fixed image copied to flash but not yet booted from it is not remediated, and on a device terminating production tunnels the reload is precisely the step that gets deferred into an indefinite change window. Sequence the affected trains by whether the device's UDP/500 responder is reachable from untrusted networks, since the packet's attack requires nothing but the ability to send that one request. The clock does not end at the reload either — the packet ties the same remediation to rotating the pre-shared keys and certificates that may have been in the returned memory, so an SLA that closes on image version alone closes early.",
+        "evidence": "Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure Vulnerability, CISA KEV-listed 2023-05-19 with active exploitation confirmed and a public PoC available; CWE-200, CVSS 7.5, RWEP 70, patch available. The packet's live-patch record: no live-patch mechanism for classic Cisco IOS/PIX; remediation is upgrading to a Cisco fixed IOS/IOS XE/IOS XR image, which reboots the device, and pre-shared keys/certificates should be rotated after exposure. The packet's attack-vector record requires only a crafted IKEv1 Security Association negotiation request to UDP/500 from a remote unauthenticated attacker.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-21492": {
     "name": "Samsung Mobile Devices Insertion of Sensitive Information Into Log File Vulnerability",
@@ -55943,7 +57523,30 @@
         "adequate": false,
         "gap": "A.8.15 logging controls require logs not to expose sensitive data and to be access-protected; here the kernel writes raw pointers into a log a privileged process can read, so the logging control as implemented leaks the exact addresses that defeat ASLR."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet pins remediation to one named build level: kernel pointers are printed in the log file prior to SMR May-2023 Release 1, and the only remediation it records is Samsung SMR May-2023 Release 1 or later delivered by device OTA, which reboots the handset. Bound to this estate, the control means that SMR level is enforced as an access condition on every managed Samsung handset — a device reporting below SMR May-2023 Release 1 is refused organizational mail, VPN and document access until it reports at or above it — rather than appearing as a stale row on a patch-compliance report. Enforcement rather than reporting is the point here because this entry's own severity signals argue for deferral: the packet gives CVSS 4.4, RWEP 44 and poc_available false, while the flaw's function is to hand a privileged local process the kernel addresses that defeat ASLR, which is an enabling step whose value to an attacker never shows up in its own score. Distinguishing test: enrol a handset pinned below SMR May-2023 Release 1 and confirm the policy actually denies it protected resources; an estate that surfaces the stale patch level on a dashboard while the device keeps mail and VPN has recorded the exposure rather than removed it. Preconditions, all of which are ways this control is over-claimed: it reaches only enrolled, managed handsets, so an unenrolled or personally-owned device is bounded solely by withholding organizational data from it; the packet records live_patch_available false, so a handset that has downloaded the OTA but not completed it and its reboot is still running the logging kernel and must be counted as exposed, not remediated; and where the OTA carrying SMR May-2023 Release 1 or later is not offered for a given model, no enforcement action produces the fixed build at all — for those models the terminal state is withdrawal of organizational data and replacement of the handset, not an access-policy exception. Because active_exploitation is confirmed, a device suspected of having already been through the chain this disclosure primitive feeds belongs on the incident path; reaching the fixed build does not evict what a prior compromise established.",
+        "evidence": "Packet vector: \"Kernel pointers are printed in the log file prior to SMR May-2023 Release 1 allows a privileged local attacker to bypass ASLR.\" Packet live_patch_notes: \"No live-patch mechanism; remediation requires Samsung SMR May-2023 Release 1 or later via the device OTA update, which reboots the handset\" — with patch_available true and live_patch_available false. CISA KEV listed 2023-05-19 with active_exploitation confirmed, against CVSS 4.4, RWEP 44 and poc_available false, which is the deprioritization pressure the packet records. The packet's attack_vector states the addresses are used to defeat KASLR and provide the address-disclosure primitive needed for reliable follow-on kernel exploitation in a spyware chain. The entry cites NIST-800-53-SI-2, NIS2-Art21-patch-management and UK-CAF-B4 as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-059",
+        "name": "SENSITIVE-DATA-IN-LOGS-LINT",
+        "description": "On this CVE the disclosure is the log's content. The CWE is CWE-532 and the packet's vector says kernel pointers are printed in the log file, which a privileged local process then reads to learn kernel addresses. That is precisely the question a logging control does not ask: an A.8.15-style attestation verifies that logs are produced, retained, time-referenced and access-protected, and every one of those passes on a handset whose log is itself the address-disclosure primitive, because the defect is what the platform chose to write rather than who may read it. Bound to this product, the requirement is that log content be treated as an output classified by what it reveals. On the platform side that is a supplier requirement, since only the OEM build stops the pointers being written: mobile-platform acceptance and re-acceptance must ask whether kernel and diagnostic logs carry raw kernel addresses, not only whether logging is enabled and protected. On the operator side, every pipeline that collects these device logs — MDM diagnostic capture, crash and bug-report upload, log-forwarding agents — inherits those addresses off the handset, so on any device below SMR May-2023 Release 1 those captures widen the set of readers and must be scoped, access-restricted and retention-bounded as sensitive material rather than handled as routine telemetry. Distinguishing test: on a handset below SMR May-2023 Release 1, read the log through the privileged local path the packet describes and confirm whether raw kernel pointers appear; a logging attestation reporting collection coverage, retention period and log access control passes cleanly while the pointers sit in the file. Precondition: this control governs what is written and who receives it — it does not repair the kernel. Nothing operator-side prevents the pointers being logged on a device below the fixed build, so restricting log handling bounds readership without removing the primitive, and the privileged local process the packet describes is already inside that boundary by definition. It is a holding measure for the window before SMR May-2023 Release 1 and its reboot land, not a substitute for them.",
+        "evidence": "Packet cwe_refs: CWE-532 (Insertion of Sensitive Information Into Log File), matching the entry name \"Samsung Mobile Devices Insertion of Sensitive Information Into Log File Vulnerability\". Packet vector: kernel pointers are printed in the log file prior to SMR May-2023 Release 1, allowing a privileged local attacker to bypass ASLR. Packet attack_vector: \"The kernel writes raw kernel pointers into a log file; a privileged local process reads those entries to learn kernel addresses and defeat KASLR.\" The entry cites ISO-27001-2022-A.8.15 (Logging) and AU-Essential-8-App-Hardening (User application hardening) as insufficient. CISA KEV listed 2023-05-19 with active_exploitation confirmed; patch_available true with live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.15",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2023-25717": {
     "name": "Multiple Ruckus Wireless Products CSRF and RCE Vulnerability",
@@ -56065,7 +57668,42 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management often deprioritizes local-only CVEs, yet this one converts any low-privilege foothold into root, so treating it as low-urgency (no network vector) misjudges its post-compromise value."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "polkit arbitrates privileged D-Bus operations on effectively every Linux install, and the packet's path needs nothing but an unprivileged local account: repeatedly call a privileged D-Bus method and kill the client mid-request until polkit races, treats the disconnected caller as root, authorizes the action, and lets the caller create a new local administrator. For this CVE the control means the distribution's fixed polkit package is driven across every Linux host on the clock that opened with the 2023-05-12 KEV listing, with completion measured per host against the polkit that is actually running rather than against 'deployed' in a management console. The packet makes that measurement both cheap and easy to skip: there is no kernel live-patch to consider because polkit is a userspace daemon, and the flaw closes once polkitd restarts with no full reboot — so there is no maintenance window to schedule and no user-visible outage to defer, and a host that took the package but never restarted polkitd is still running the vulnerable daemon and must be counted exposed. Enumerate first the hosts where this exploit's precondition is the normal operating state rather than an anomaly: multi-user shell servers, jump hosts, shared build machines and CI runners, where every interactive account already satisfies 'unprivileged local user'. The least-privilege gap cited on this entry cannot contain the escalation — the attacker is a legitimately authorized user, the privilege transition happens inside polkit's credential check, and an attestation that every account holds only the rights it needs passes cleanly while the flaw stays fully exploitable. Because active exploitation is confirmed and a PoC is public, remediation also has to look backwards: the outcome the packet names is a new local administrator account, and that account survives the package update untouched. Reconcile local accounts and administrative group membership on hosts that were exposed instead of closing the finding on the package version.",
+        "evidence": "Packet: CWE-863 / CWE-754, CISA KEV 2023-05-12, active_exploitation confirmed, poc_available true, CVSS 7.8, RWEP 64. attack_vector: 'An unprivileged local user repeatedly calls a privileged D-Bus method and kills the client mid-request; polkit races and treats the disconnected caller as root, authorizing the action and allowing creation of a new administrator account.' Vector: the flaw 'could be used by an unprivileged local attacker to, for example, create a new local administrator.' patch_available true; live_patch_available false with live_patch_notes 'No kernel live-patch applies — polkit is a userspace daemon; remediation is the distribution's fixed polkit package, after which restarting polkitd (no full reboot) closes the flaw.' NIST-800-53-AC-6 (Least Privilege) is recorded among the citing gaps.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-146",
+        "name": "USERSPACE-PRIVILEGED-DBUS-RACE-DETECTION",
+        "description": "polkit is a userspace daemon, so what this control means for this CVE is host audit or eBPF rules on the privilege-escalation behaviour rather than kernel-exploit indicators — and the packet describes that behaviour precisely enough to key on it. The exploit is a race, and a race is repetitive: an unprivileged local user calls a privileged D-Bus method over and over and kills the client mid-request until the timing lands. The rule therefore keys on that shape — bursts of short-lived invocations of privileged D-Bus methods from a non-root uid that terminate before the call completes — paired with the privilege transition the packet names as the result: a new local account appearing with administrative rights, seen as writes to the local account and group files or as account-management utilities running outside a change window. Both halves are needed. Repeated D-Bus calls alone can be benign; an account creation alone arrives with no context, and it is the pairing inside a short window that distinguishes this exploit from either. Note what will not see it: nothing is compiled, no module is loaded, no setuid binary changes, no process crashes, and the work is done by an ordinary user session calling a system daemon through its normal interface — so file-integrity monitoring and signature-based endpoint tooling have no artifact to match, and alerting on crashes or on named exploit tooling would miss an attempt that behaves exactly as the packet describes. Precondition: this requires host audit or eBPF telemetry already collected and shipped off-host before the attempt, which on the multi-user and shared hosts most exposed to this flaw is precisely where it is least often enabled; a rule authored after the fact against telemetry nobody was collecting produces nothing. And detection does not prevent the escalation and does not remove an administrator account already created — it bounds the window to alert-and-response time during the period before the fixed polkit package and the polkitd restart land.",
+        "evidence": "Packet attack_vector: 'An unprivileged local user repeatedly calls a privileged D-Bus method and kills the client mid-request; polkit races and treats the disconnected caller as root, authorizing the action and allowing creation of a new administrator account.' Vector: 'polkit could be tricked into bypassing the credential checks for D-Bus requests, elevating the privileges of the requestor to the root user'; the stated example outcome is creating 'a new local administrator'. active_exploitation confirmed, poc_available true, CISA KEV 2023-05-12. live_patch_notes states polkit is a userspace daemon and no kernel live-patch applies.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE the paper-compliance failure has one exact shape: a scanner reads the installed polkit package version, finds it at or above the distribution's fixed build, and reports the host remediated — while the polkitd process that actually arbitrates D-Bus authorization is still the pre-update binary, because the packet states the flaw closes only after polkitd restarts. A package-version query cannot tell those two hosts apart, and on a long-uptime multi-user server — the same population where any interactive account already satisfies this exploit's 'unprivileged local user' precondition — they diverge as a matter of routine, since installing the package does not by itself take the daemon down. The operational test is therefore not the package query but the running daemon: for every host reported patched, show that the polkitd currently running was started after the fixed package was installed, or verify the running daemon's on-disk image directly. Anything that stops at the package version is an attestation about the filesystem, not about the process making the authorization decision. Precondition: this test verifies remediation, it does not perform it — a host that fails it is remediated by restarting polkitd, which the packet records as needing no full reboot — and it says nothing about whether the host was already exploited. With exploitation confirmed in the wild and the documented outcome being a new local administrator account that the package update does not remove, that is a separate question answered by reconciling local accounts, not by any version check.",
+        "evidence": "Packet live_patch_notes: 'No kernel live-patch applies — polkit is a userspace daemon; remediation is the distribution's fixed polkit package, after which restarting polkitd (no full reboot) closes the flaw.' patch_available true, live_patch_available false. active_exploitation confirmed, poc_available true, CISA KEV 2023-05-12. attack_vector places the attacker as an unprivileged local user; the vector's stated outcome is creation of a new local administrator.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2014-0196": {
     "name": "Linux Kernel Race Condition Vulnerability",
@@ -56126,7 +57764,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management that scores by CVSS treated this 5.5 issue as low urgency, understating that it yields reliable local root; the low base score let it linger unpatched despite a public exploit and KEV listing."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this CVE the distance between \"patched\" and \"not vulnerable\" is exactly one reboot, and that is where the compliance record goes wrong. The packet's remediation is upgrading to a fixed Linux kernel past 3.14.3 and rebooting, with live_patch_available false. A scanner that reads the installed kernel package version marks a host compliant the moment the fixed package lands, while the kernel actually executing — the one still carrying the vulnerable n_tty_write path in the LECHO and !OPOST case — is unchanged until the machine restarts. The requirement for this entry is that the vulnerability verdict be taken from the running kernel, comparing the live release against the fixed build, and that \"fixed package installed, reboot pending\" be reported as its own exposed state with a dated restart rather than as a pass. The entry's compliance risk is the compound of two ordinary program behaviours: the packet gives CVSS 5.5 against RWEP 71 with poc_available true and confirmed exploitation, so a program that prioritises by base score defers the kernel update, and a program that then measures by package version closes the deferral without the reboot ever happening. Enumerate the population where the deferral matters most first — hosts where unprivileged users hold interactive shell sessions, since the exploit needs a local account and a pty, which on a shared or multi-user host is the normal operating state rather than an anomaly. Distinguishing test: take a host that has installed the fixed kernel package but has not restarted, run the scan, and confirm it reports that host as still exposed; a scan returning \"patched\" there is measuring the package rather than the kernel in memory, and the fleet's remediation count for this CVE is inflated by every host in that state. Precondition: this control corrects what is measured and what action is scheduled — it removes nothing on its own, and a host it correctly reports as exposed stays exploitable until the restart is taken.",
+        "evidence": "Packet live_patch_notes: \"Standard remediation is upgrading to a fixed Linux kernel (past 3.14.3) and rebooting,\" with patch_available true and live_patch_available false; the same note records that no specific vendor live-patch for this CVE is confirmed. Packet vector: the n_tty_write function in drivers/tty/n_tty.c in the Linux kernel through 3.14.3 does not properly manage tty driver access in the \"LECHO & !OPOST\" case. Packet scoring: CVSS 5.5 against rwep_score 71, with poc_available true, CISA KEV listing 2023-05-12 and active_exploitation confirmed. Packet attack_vector: a local user races writes to a pty to escalate to root. The entry cites NIST-800-53-SI-2, AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIS2-Art21-patch-management as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "This is the control for the window the reboot deferral leaves open, and for this CVE it has to key on the two behaviours the packet actually documents. First, the race itself: an unprivileged process opens a pty, puts the line discipline into the echo-on with output-processing-off configuration the packet names, and then drives sustained concurrent long writes to it from more than one thread. An interactive session does not produce that — a human-driven terminal does not emit multi-threaded bulk writes to its own pty — so the write pattern is the signal that fires while the exploit is looping, which matters because a race is attempted many times before it wins. Second, the transition it is racing toward: a euid change to 0 in a process descended from an unprivileged login session with no preceding setuid execution or authorization event to account for it. Both halves are required — the write-storm rule sees the attempts, the uid-transition rule sees a success — and the alert has to reach an operator inside 60 seconds because the response to a win is isolating the host, not queueing a ticket. Do not build the rule around the crash. The packet does record memory corruption and system crash as the alternative outcome, but the run that wins the race produces no crash at all, so a rule keyed on kernel oops volume alone is blind to exactly the case that matters and would read as clean during a successful escalation. Distinguishing test: the packet records poc_available true, so run the public exploit against a staging host on an unfixed kernel and confirm the write-storm rule fires during the attempt loop and the uid-transition rule fires on success — a rule set validated only against a synthetic uid change or a forced panic has not been shown to see this exploit. Precondition: detection does not restore the containment this flaw breaks; it tells you the boundary failed. It requires a low-privilege foothold to be visible to the sensor in the first place, and it is a compensating measure for hosts awaiting the restart, not a reason to extend the deferral.",
+        "evidence": "Packet attack_vector: \"Two threads race concurrent long writes to a pty in the n_tty_write LECHO/!OPOST path, overflowing the tty buffer to corrupt kernel memory and escalate a local user to root (or crash the machine).\" Packet vector: the flaw allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings; cwe_refs CWE-362. Packet poc_available true supports a runnable validation. Packet live_patch_available false with remediation requiring a reboot establishes the deferral window this covers. CISA KEV listed 2023-05-12, active_exploitation confirmed, rwep_score 71. The entry cites UK-CAF-B4 (System security) as insufficient, and the lesson's framework_coverage records the B4 gap as the least-privilege containment assumption failing on shared and multi-tenant Linux hosts that skipped the kernel bump.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2010-3904": {
     "name": "Linux Kernel Improper Input Validation Vulnerability (CVE-2010-3904)",
@@ -56187,7 +57848,41 @@
         "adequate": false,
         "gap": "A.8.9 configuration management should enforce a hardened kernel-module baseline, but default configurations that leave the rarely-used RDS module loadable let a local user reach the unvalidated rds_page_copy_user copy, so configuration drift/default-on modules sustained the root-escalation exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The packet names this mitigation itself: the RDS module can be blacklisted or unloaded on hosts that do not use it, removing the reachable code path without an immediate kernel update. Bound to this CVE, the control means resolving, per host, which of three states net/rds is actually in — already loaded, loadable on demand, or built into the running kernel image — and blacklisting it everywhere RDS carries no business function, because the exploit's first move is an unprivileged user opening an AF_RDS socket, and on a host where rds is merely auto-loadable that socket call is what pulls the unvalidated rds_page_copy_user path into the kernel in the first place. The inventory is the load-bearing half, because \"we blacklisted rds\" is a fleet-level assertion and the three states behave nothing alike. Preconditions, which is exactly where this control gets over-claimed as removing the surface outright: a blacklist prevents the on-demand load and does nothing on a host where rds is already loaded — that host also needs the module unloaded, and the unload fails while anything holds an RDS socket open, so a host that cannot be quiesced enough to unload is a reboot rather than a blacklist. A blacklist does nothing at all where RDS is built into the kernel image rather than shipped as a module: there is no module to refuse, the AF_RDS path exists from boot, and the only remediation there is the fixed kernel — address validation in rds_page_copy_user, in 2.6.36 or a distro backport — with the reboot the packet says it requires. And hosts that genuinely use RDS cannot take this mitigation in any form; they are patch-and-reboot items with no interim compensating control from this direction. Distinguishing test: on a representative host, as an unprivileged user, attempt to open an AF_RDS socket and confirm it fails, and confirm rds is absent from the loaded module set — not merely that a blacklist file is present in configuration. A configuration-management attestation showing the blacklist deployed passes on a host that loaded rds before the file landed and on a host whose kernel has RDS built in, and on both the arbitrary-kernel-write path is still fully reachable by any local account.",
+        "evidence": "Packet live_patch_notes: \"the kernel fix (address validation in rds_page_copy_user, in 2.6.36 or a distro backport) requires a reboot to take effect. As a non-reboot mitigation, the RDS module can be blacklisted/unloaded on hosts that do not use it, removing the reachable code path without an immediate kernel update,\" with patch_available true and live_patch_available false. Packet vector: rds_page_copy_user in net/rds/page.c in the RDS implementation in the Linux kernel before 2.6.36 does not properly validate addresses obtained from user space, allowing local users to gain privileges via crafted use of sendmsg and recvmsg. Packet attack_vector: \"A local user opens an AF_RDS socket and issues crafted sendmsg/recvmsg calls,\" giving an arbitrary kernel write leveraged to escalate to root. poc_available true; CISA KEV listed 2023-05-12; active_exploitation confirmed; rwep_score 70. The entry cites NIST-800-53-CM-7, ISO-27001-2022-A.8.9, AU-Essential-8-App-Hardening and UK-CAF-B4 as insufficient; the lesson's framework_coverage records that stock distributions left the module auto-loadable and that only patching to 2.6.36+ or disabling the module closes it.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9",
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry produces the middle state the control exists to name, and produces it by design rather than by accident. The packet records no vendor live patch, a kernel fix that requires a reboot, and a module blacklist or unload as the interim mitigation — so a host with rds blacklisted is not patched: the unvalidated rds_page_copy_user copy is still present in the running kernel and becomes reachable again the instant anything loads the module. The requirement is that compliance records for this CVE carry that as its own verdict — mitigation active, vulnerable kernel running, reboot pending, with a dated action item for the fixed kernel — and never merge it into the same remediated bucket as a host actually running 2.6.36 or a backported kernel. The distinction is operational rather than clerical, because the events that silently return a mitigated host to full exposure are all routine maintenance: a kernel package upgrade or image rebuild that reinstates a default module configuration, a host restored from a baseline predating the blacklist, or a new host provisioned from an older image. None of those generate a vulnerability event, because from the scanner's point of view nothing about the host changed, so a fleet can drift back toward exposure while its remediation count for this CVE holds steady. Distinguishing test: take any host recorded as remediated on CVE-2010-3904 and check whether its record distinguishes \"module blacklisted\" from \"running a fixed kernel\"; if the report cannot tell those apart, the remediation count includes hosts that are one configuration-management run from exploitable by any local account. Precondition: this control changes what is recorded and what action is scheduled — it removes no code path itself, and a host sitting in the mitigated state carries the residual risk for as long as the reboot is deferred, which on a long-lived server is the entire point of the deferral.",
+        "evidence": "Packet live_patch_notes records both states explicitly: no vendor-provided live patch is published for this CVE, the kernel fix requires a reboot to take effect, and the RDS module can be blacklisted/unloaded as a non-reboot mitigation on hosts that do not use it. patch_available true with live_patch_available false. Packet attack_vector: a local user opens an AF_RDS socket and issues crafted sendmsg/recvmsg calls for an arbitrary kernel write leveraged to root; poc_available true and active_exploitation confirmed, CISA KEV listed 2023-05-12. The entry cites NIS2-Art21-vulnerability-management and ISO-27001-2022-A.8.9 as insufficient; the lesson's framework_coverage records the A.8.9 gap as configuration drift and default-on modules sustaining the exposure.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The blacklist and the patch are not equivalent removals here, which is why dropping the blacklist once the fixed kernel lands is a net loss of posture on hosts that never used RDS. The packet's fix is address validation in rds_page_copy_user — one function, one missing check. Refusing to load net/rds removes reachability of the whole subsystem, of which the unvalidated copy is one defect. So on any host where the inventory established that RDS carries no business function, the blacklist should be treated as a permanent least-functionality decision that survives the kernel upgrade, not as a temporary measure to be reverted when the patched kernel boots. The concrete failure this prevents is a rollback framed as cleanup: an operator reversing the modprobe configuration as part of closing the CVE ticket, restoring an unprivileged-reachable protocol implementation to a host that had no use for it, and doing so at exactly the moment the change looks safest. Distinguishing test: after the fixed kernel is deployed and the host has restarted, confirm the blacklist entry is still in place and that an unprivileged AF_RDS socket open still fails — a remediation workflow that reverts compensating configuration on patch confirmation will show a host that is patched for this CVE and once again carrying the full net/rds surface. Precondition: this governs retention of a control that was available in the first place. It gives nothing to a host where RDS is in genuine use or is built into the kernel image, since no blacklist existed there to retain, and it is not a reason to defer the fixed kernel — the retention applies after the patch lands, not instead of it.",
+        "evidence": "Packet live_patch_notes names both the fix and the mitigation: \"the kernel fix (address validation in rds_page_copy_user, in 2.6.36 or a distro backport) requires a reboot to take effect. As a non-reboot mitigation, the RDS module can be blacklisted/unloaded on hosts that do not use it, removing the reachable code path.\" Packet vector scopes the defect to rds_page_copy_user in net/rds/page.c failing to validate addresses obtained from user space. Packet attack_vector: an unprivileged local user reaches it by opening an AF_RDS socket. The entry cites NIST-800-53-CM-7 (Least Functionality) and ISO-27001-2022-A.8.9 (Configuration management) as insufficient; the lesson's framework_coverage records the CM-7 gap as stock distributions leaving the module auto-loadable so hosts that never used RDS still exposed the arbitrary-kernel-write path.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9"
+        ]
+      }
+    ]
   },
   "CVE-2015-5317": {
     "name": "Jenkins User Interface (UI) Information Disclosure Vulnerability",
@@ -56248,7 +57943,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management may rank a 2015 info-disclosure as low priority, yet its KEV status means the leak of otherwise-restricted job/build names remains a live reconnaissance vector on any Jenkins below 1.638 / LTS 1.625.2."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Jenkins enforces per-item access control at the view layer, and this CVE is one view not enforcing it: the packet has a direct request to the Fingerprints pages returning the names of jobs and builds the requester is not authorized to see. Bound to this product, the control means every Jenkins page and endpoint resolves the caller's permission on the specific item it is about to name — the fingerprint record, the job, the build — before it renders, rather than inheriting the verdict that allowed the caller to reach Jenkins at all; and the Jenkins web surface is segmented so callers with no operational need cannot issue that direct request in the first place. This is exactly why the access-enforcement gap recorded on this entry passes its attestation while the path stays open: the deployment's authorization matrix can be configured precisely as intended, reviewed, and evidenced, and this page still never consults it, so the finding is invisible to any audit that inspects the permission configuration rather than the response body. Precondition: the per-page authorization behaviour is what upgrading to 1.638 or later (LTS 1.625.2 or later) establishes — this control states the property to verify, it does not implement it — and the packet records no live-patch mechanism, so until that release and the Jenkins service restart land, restricting who can reach the controller (removing anonymous read, fronting it with authenticated access, taking it off any internet-reachable path) bounds the population that can issue the request and leaves it fully effective for every developer, contractor and service account that legitimately reaches Jenkins, which on a shared controller is most of the organization. Distinguishing test: with an account authorized to read exactly one job, request the Fingerprints pages on a staging controller and confirm no job or build name outside that account's authorization appears in the response — an attestation that Jenkins role-based authorization is configured and reviewed passes cleanly while this page keeps answering.",
+        "evidence": "Packet: CWE-200. Vector: 'The Fingerprints pages in Jenkins before 1.638 and LTS before 1.625.2 might allow remote attackers to obtain sensitive job and build name information via a direct request.' attack_vector: 'A direct request to the Jenkins Fingerprints pages returns names of jobs and builds the user is not authorized to see, disclosing CI/CD pipeline structure for reconnaissance.' NIST-800-53-AC-3 (Access Enforcement) is recorded among the citing gaps. patch_available true; live_patch_available false with live_patch_notes requiring the upgrade to 1.638 or later (LTS 1.625.2 or later) and a Jenkins service restart.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The remediation this packet records is narrow and fully specified: upgrade Jenkins to 1.638 or later (LTS 1.625.2 or later) and restart the Jenkins service. There is no live-patch mechanism, so a controller whose WAR was replaced but whose service was never restarted is still serving the vulnerable pages and has to be counted exposed rather than patched. What puts this on the KEV clock is not the score — RWEP 36, CVSS 7.5, and the packet records no public PoC — but that exploitation is confirmed in the wild while the technique the packet describes is a direct request to a page, so the absence of published exploit code is no barrier to its use and no reason to let the item sit in a low-severity queue. The population this control has to reach is precisely the one a severity-ordered backlog deprioritizes: a controller still on a pre-1.638 line at the 2023-05-12 KEV listing is not a host waiting on a vendor, it is a host nobody owns — a team-run build server, an instance left behind after a migration to another CI system, a controller inside a project VM. So the first obligation here is enumeration: every Jenkins controller reachable on the estate, with its reported version and its service start time, discovered from the network rather than taken from the CI team's inventory. Precondition: the compensating-control branch of this SLA is weaker than usual for this CVE. The disclosure happens on an ordinary page request, so there is no distinctive request pattern for a proxy or WAF rule to key on, and restricting reachability only narrows who can ask — it does not stop the page answering. Remediation is also not restorative: job and build names disclosed before the upgrade stay disclosed, and the packet identifies the value of that disclosure as reconnaissance on CI/CD pipeline structure, so a controller with confirmed exposure warrants review of what that structure reveals rather than closure on the version bump alone.",
+        "evidence": "Packet: CISA KEV 2023-05-12, active_exploitation confirmed, poc_available false, CVSS 7.5, RWEP 36, CWE-200. patch_available true, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation requires upgrading Jenkins to 1.638 or later (LTS 1.625.2 or later) and restarting the Jenkins service.' Vector names the affected versions ('before 1.638 and LTS before 1.625.2') and the technique ('via a direct request'); attack_vector states the disclosure is of 'CI/CD pipeline structure for reconnaissance'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2016-3427": {
     "name": "Oracle Java SE and JRockit Unspecified Vulnerability",
@@ -56553,7 +58271,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management relies on an accurate component inventory (SBOM); without one, organizations could not enumerate where the vulnerable Log4j library ran, leaving a ransomware-associated RCE unremediated well past the KEV due date."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This CVE exists because a prior remediation was incomplete: the packet's vector states the fix that addressed CVE-2021-44228 in Log4j 2.15.0 was incomplete in certain non-default configurations, leaving the same JNDI-lookup primitive reachable through attacker-controlled Thread Context Map data. That makes the operator's problem a records problem as much as a code problem — the version move to 2.15.0 is already closed on the flaw-remediation ledger, so the follow-on step reads as a routine minor bump rather than as an unremediated actively-exploited flaw. Applied to this CVE, an application on 2.15.0 must be scored as unremediated for this primitive and driven to 2.16.0 (Java 8) or 2.12.2 (Java 7) with the affected Java application restarted, on the clock that opened with the 2023-05-01 KEV listing. The sequence position also sets the standard for what counts as a fix: the packet credits the fixed releases with removing support for message lookup patterns and disabling JNDI functionality by default — a capability removal — so a narrower fix on this same primitive should be treated as provisionally incomplete until the capability-removing version is in service. Distinguishing test: pull the remediation evidence for this CVE and check what it points at; if it points at the December 2021 Log4Shell response rather than at a per-application version reading of 2.16.0 or 2.12.2 on the runtime classpath, the attestation is recording the first CVE's closure as this one's.",
+        "evidence": "Packet vector: the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations, allowing attackers with control over Thread Context Map (MDC) input data to craft a JNDI Lookup pattern; the packet states Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix the issue by removing support for message lookup patterns and disabling JNDI functionality by default. live_patch_notes: remediation requires upgrading Log4j to 2.16.0 (Java 8) or 2.12.2 (Java 7) and restarting the affected Java application. CISA KEV-listed 2023-05-01, active_exploitation confirmed, PoC available, CVSS 9.0, RWEP 74, patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet itself separates the two states this control requires an audit to distinguish: removing the JndiLookup class from the classpath is recorded as a stopgap mitigation, not a vendor live-patch, while remediation is upgrading to 2.16.0 (Java 8) or 2.12.2 (Java 7) and restarting the affected Java application. Applied to this estate, every Java application carrying Log4j needs an explicit verdict of (a) fixed version resolved on the runtime classpath and the application restarted, (b) still on an affected version with the JndiLookup class stripped, or (c) neither — and (b) has to appear as a time-bound compensating-control state with a dated action item, never as a patched-per-SLA outcome. Preconditions on (b), which are the reason it cannot be recorded as closure: the stopgap holds only while that class stays absent from the artifact, so a redeploy, a dependency re-resolution, a rollback to an earlier build, or a restore that reinstates the original library returns the application to full exposure silently, and the removal is applied per artifact rather than centrally, so it has to be re-verified on every build rather than once. It also leaves the affected version in place, so the capability changes the packet credits the fixed releases with — removal of message lookup patterns and JNDI disabled by default — are not in effect for anything else that reaches the same code. And because the fix takes effect only on restart, an application whose dependency was upgraded but whose process has not been restarted is still state (c) dressed as state (a). Distinguishing test: for each application recorded in state (b), rebuild it from its own pipeline and inspect the produced artifact for the JndiLookup class; if it comes back, the mitigation was a one-off edit to a deployed artifact and the next deployment reopens the flaw.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism; remediation requires upgrading Log4j to 2.16.0 (Java 8) or 2.12.2 (Java 7) and restarting the affected Java application. The stopgap of removing the JndiLookup class from the classpath is a mitigation, not a vendor live-patch.' patch_available true, live_patch_available false. Packet vector states the fixed releases remove support for message lookup patterns and disable JNDI functionality by default. CISA KEV-listed 2023-05-01, active_exploitation confirmed, PoC available, CVSS 9.0, RWEP 74.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "Log4j is not an installed product on this estate but a library reached through Java applications — the packet's remediation is expressed per application (upgrade Log4j and restart the affected Java application), so how much of the estate is remediated is exactly how much of it the dependency inventory can see. Applied to this CVE, the inventory has to record per application: the Log4j version actually resolved onto the runtime classpath rather than only the version named as a direct dependency; the Java track, because the packet gives different fixed releases for Java 8 (2.16.0) and Java 7 (2.12.2), so a single target version applied estate-wide leaves one track wrong; and whether the logging configuration uses a non-default PatternLayout with a Context Lookup or a Thread Context Map pattern (%X, %mdc, %MDC), which the packet gives as the condition under which attacker-controlled MDC data reaches the JNDI lookup. That last item is a configuration property rather than a code property, so an application marked not-exploitable on configuration grounds is re-exposed the moment someone adds a correlation-id pattern to a log format, with no dependency change to trigger a re-scan — it has to be re-checked on logging-configuration change, not only on dependency change. Distinguishing test: take applications whose declared direct dependencies name no Log4j at all and enumerate their resolved runtime classpath; an inventory built from declared direct dependencies reports full coverage while transitively-included copies sit on an affected version.",
+        "evidence": "Packet live_patch_notes: remediation requires upgrading Log4j to 2.16.0 (Java 8) or 2.12.2 (Java 7) and restarting the affected Java application — two fixed releases on two Java tracks, applied per application. Packet vector conditions exploitation on a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) plus attacker control over MDC input data. The entry cites NIS2 Art. 21 supply-chain security measures as a framework gap. CISA KEV-listed 2023-05-01, active_exploitation confirmed, PoC available, CVSS 9.0, RWEP 74.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-21839": {
     "name": "Oracle WebLogic Server Unspecified Vulnerability (CVE-2023-21839)",
@@ -56797,7 +58547,30 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management could only react — the sandbox escape was a zero-day, so remediation depended on rapidly deploying Chrome 112.0.5615.137 across all managed endpoints."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet gives a fixed build — Chrome/Chromium 112.0.5615.137 — and a KEV-listed sandbox escape under confirmed exploitation, which is the case a staged enterprise update ring is worst at: the ring exists to soak a release across a validation window, and the window is the exposure. For this CVE the control means the security-channel update to 112.0.5615.137 or later is pushed to every managed Chrome/Chromium install on the clock that opened with the 2023-04-21 KEV listing, with user deferral disabled, and completion measured by the build each browser instance is actually running rather than by the version approved or staged in the management console; the packet records no live-patch mechanism, so an instance still executing a pre-112.0.5615.137 build carries the vulnerable Skia even once the newer build is on disk. This is also the control that carries the exposure the user-application-hardening gap cited on this entry cannot: hardening settings govern what content the renderer is allowed to process, whereas the packet places this defect at the step after that — reached from a renderer the attacker already controls — so no hardening setting narrows the Skia integer overflow, and a hardening attestation passes cleanly while the escape stays available. Priority follows the packet rather than the absence of a public exploit: no PoC is recorded, but exploitation is confirmed, so waiting for a public PoC to raise the priority inverts the evidence. Precondition: this reaches only installs the browser update channel manages; a Chromium build shipped inside another product does not take the Chrome update and is not covered here — it belongs to the embedded-component inventory and parity requirement instead.",
+        "evidence": "Packet vector: 'Integer overflow in Skia in Google Chrome prior to 112.0.5615.137 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.' attack_vector: from a renderer process the attacker already controls, the crafted page drives the overflow to break out of the sandbox and execute in the higher-privileged browser process. live_patch_notes: no live-patch mechanism; remediation requires updating Chrome/Chromium to 112.0.5615.137 or later. CISA KEV-listed 2023-04-21, active_exploitation confirmed, poc_available false, patch_available true, live_patch_available false, CVSS 9.6, RWEP 45. The entry cites ASD Essential Eight user application hardening as a framework gap.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet puts the defect in Skia — an embedded rendering component, not a separately installed product — and states remediation as two distinct actions: update Chrome/Chromium to 112.0.5615.137 or later, and rebuild the downstream products that embed the affected Skia, which it names as ChromeOS, Android and Flutter. Those are separate update tracks, so an attestation built on the browser fleet closes only the first action while shipped copies of the same vulnerable code stay in service. Applied here, the control means enumerating, alongside managed Chrome installs, the packet-named downstream products actually in service — ChromeOS devices, Android builds, and applications built with Flutter — and confirming each is on a build produced after the Skia fix, since each carries its own copy that the Chrome update never touches. Scope it to those products: the packet ties the affected Skia to Chrome/Chromium and to ChromeOS, Android and Flutter and provides no mapping into other software embedding Skia, so instructing operators to treat every graphics-rendering binary in the estate as an instance of this CVE manufactures rebuild and removal work against products no evidence here implicates; widen only where a verified source names another product carrying the affected component. Distinguishing test: after the Chrome fleet reports 112.0.5615.137, take one in-service Flutter-built application and one Android or ChromeOS image and show each was produced after the Skia fix — an estate whose flaw-remediation evidence is the browser inventory alone reads clean while shipped software still embeds the vulnerable code. Precondition: rebuilding is available only for products the operator builds, or for which a fixed build can be obtained; a downstream product whose supplier ships no rebuilt version is not remediated by this control and stays on the exposure register rather than being closed by it.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism; remediation requires updating Chrome/Chromium to 112.0.5615.137 or later and rebuilding downstream products (ChromeOS, Android, Flutter) that embed the affected Skia.' Packet vector places the integer overflow in Skia in Google Chrome prior to 112.0.5615.137, reachable via a crafted HTML page from a compromised renderer process to escape the sandbox. CISA KEV-listed 2023-04-21, active_exploitation confirmed, poc_available false, patch_available true, live_patch_available false, CVSS 9.6, RWEP 45.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2017-6742": {
     "name": "Cisco IOS and IOS XE Software SNMP Remote Code Execution Vulnerability",
@@ -56858,7 +58631,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management frequently omits network-device firmware from the vulnerability program; organizations without an inventory of IOS/IOS XE SNMP exposure could not identify or remediate the vulnerable routers before state-sponsored exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Bound to a Cisco IOS / IOS XE device that was SNMP-reachable from untrusted space while this flaw was unpatched, this control needs re-scoping rather than restating, because its usual premise does not hold here: the packet's implant is in-memory (Jaguar Tooth) and the packet's remediation is a fixed Cisco software release that reboots the device, so the upgrade itself clears memory-resident code. What the upgrade does not touch is the exploit's own precondition. The packet requires the attacker to already know the device's SNMP read-only community string (v1/v2c) or its SNMPv3 user credentials, and an image upgrade rotates neither — so the same access that produced the first implant works against the rebooted device, and the second run costs the attacker nothing. It also does not surface anything the attacker changed while resident. Applied to this device, remediation is three steps, not one: before the reload discards volatile state, capture and diff the running and startup configuration against a known-good baseline (SNMP community and user definitions, ACLs, any added local accounts, any configuration that would restore attacker access after reboot); rotate every SNMP community string and SNMPv3 credential the device carries and every device that shares them, since a community string is a per-device shared secret rather than a per-operator one; then bring the device up on the fixed release from the baseline configuration rather than from the configuration the compromised device saved for itself. Distinguishing test: after the upgrade, show that the device's SNMP credentials differ from the pre-incident values and that its running configuration matches the baseline — an estate that records the fixed IOS release against the asset and closes the ticket has remediated the overflow and preserved the credential. Preconditions and limits: the configuration diff assumes a known-good baseline exists to diff against; where none does, the step degrades to an engineer reviewing the configuration line by line and is weaker for it. And rebuilding the device does not tell you what the resident implant read or reached from that position, so a device confirmed compromised still owes downstream credential rotation for anything it held or could authenticate to.",
+        "evidence": "Packet: CWE-119 buffer overflow in the SNMP implementation of Cisco IOS and IOS XE; the attacker 'must know the SNMP read only community string (SNMP version 2c or earlier) or the user credentials (SNMPv3)'; attack vector records that APT28 used it to inject the in-memory Jaguar Tooth implant; CISA KEV-listed 2023-04-19 with active_exploitation confirmed and poc_available true; RWEP 73 / CVSS 8.8; patch_available true and live_patch_available false, with the live-patch note stating remediation requires upgrading to a Cisco fixed software release per advisory cisco-sa-20170629-snmp, which reboots the device. AU-Essential-8-Patch and ISO 27001:2022 A.8.8 are recorded as insufficient for this entry — both are satisfied the moment the fixed release is installed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The SNMP agent on IOS / IOS XE is the listener class this control governs, on a router rather than an application server: a non-HTTP management protocol that answers on the device itself, whose parser is the vulnerable code, and which the packet says is exploitable only by traffic directed at the affected system. The requirement for these devices is that the SNMP agent answers only the management hosts that legitimately poll it — enforced with an SNMP access list and view on the device plus infrastructure ACLs on the paths that reach it, rather than assumed from 'the management VLAN is internal' — and that the affected MIBs and OIDs the packet's mitigation names are removed from the served view wherever the estate does not poll them, which is the least-functionality step the CM-7 gap is about. Distinguishing test: from a general user VLAN and from external transit, send SNMP requests at a staging device and confirm they are dropped before the agent parses them; a device that passes a configuration audit for 'SNMPv3 with authentication enabled' while its agent still answers packets sourced from anywhere has satisfied the audit and left the overflow reachable. Preconditions, and this is where the control is easy to over-claim: restricting reachability bounds who can send the crafted packet, it does not repair the parser, and the packet states the flaw affects all versions of SNMP (1, 2c and 3) — so moving the estate to SNMPv3 with strong credentials raises the cost of obtaining a valid credential but leaves the overflow fully reachable by anyone holding one, and a leaked v1/v2c community string is a single shared secret rather than a per-operator account. The monitoring platform that must poll the device is by definition inside the permitted set, so its compromise satisfies the exploit's stated access precondition in full. This is the holding measure for the window before the fixed software release lands, and taking that release reboots the device.",
+        "evidence": "Packet: 'The vulnerability is due to a buffer overflow in the affected code area. The vulnerability affects all versions of SNMP (versions 1, 2c, and 3)'; 'Only traffic directed to the affected system can be used to exploit this vulnerability'; the live-patch note records Cisco's recommended mitigations as restricting SNMP access to trusted management hosts, disabling affected MIBs/OIDs, and enforcing SNMPv3 with strong credentials, with the fixed software release (which reboots the device) as the remediation; live_patch_available false; KEV 2023-04-19, active_exploitation confirmed, poc_available true. NIST 800-53 CM-7 (Least Functionality), NIS2 Art.21 security of network and information systems, and UK CAF B4 (System security) are the framework controls recorded as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2019-8526": {
     "name": "Apple macOS Use-After-Free Vulnerability",
@@ -57041,7 +58837,29 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management presumes remediation can be scheduled, but the availability of the fix for this Framework LPE is gated by Android security-patch-level delivery per OEM, so vulnerability-management SLAs cannot guarantee closure of the privilege-escalation path on affected fleets."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's precondition is an app already on the device, and the outcome is local privilege escalation with no additional execution privileges needed and no user interaction — so on a handset below the 2023-03-01 Android security patch level there is no prompt to decline, no permission grant to review and no user decision in the path, and the only lever left is what organizational data that handset is permitted to hold. Applied to this CVE, the 2023-03-01 or later patch level must operate as an access condition across the affected Android 11, 12, 12L and 13 population — mail, VPN and document access denied to a device below it — rather than as a reported field on a patch-compliance dashboard. Distinguishing test: enrol an Android device pinned below the 2023-03-01 patch level and confirm the policy actually refuses it access to protected resources; an estate that surfaces the stale patch level on a report while the device keeps its mail and VPN access has recorded the exposure rather than removed it. Precondition, and this is where the control gets over-claimed: restricting installs to a managed catalogue and blocking sideloading raises the bar for getting the attacker's app onto the device, but it evicts nothing already installed and does not cover an app that arrived through the normal store channel, so a device suspected of already running such an app belongs on the incident path rather than the install-policy path. And because the packet frames remediation as the device receiving the 2023-03-01 or later patch level as a system update, a device model that is never offered that patch level cannot be brought into compliance by any policy the operator holds: for those handsets the access condition is a standing posture, not a bridge, and replacement is the terminal state — leaving them enrolled with an open exception marks them compliant while they stay exposed to everything found since.",
+        "evidence": "Packet vector: 'In WorkSource, there is a possible parcel mismatch. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android Versions: Android-11 Android-12 Android-12L Android-13 Android ID: A-220302519'. attack_vector: a malicious app already on the device triggers the Parcel serialization mismatch in WorkSource, causing the system to grant the app elevated privileges without extra permissions or user interaction. live_patch_notes: no live-patch mechanism for the Android Framework; remediation requires the device receiving the 2023-03-01 (or later) Android security patch level, installed as a system update that reboots the device. CISA KEV-listed 2023-04-13, active_exploitation confirmed, poc_available false, patch_available true, live_patch_available false, CVSS 7.8, RWEP 49.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this CVE remediation is a single event per handset — the device takes the 2023-03-01 or later Android security patch level as a system update and reboots — so the control is about driving that event across the enrolled Android 11, 12, 12L and 13 population on the clock that opened with the 2023-04-13 KEV listing, with user deferral prohibited and the restart forced rather than left to the user's convenience. Completion is counted per device from the security patch level reported after the restart, because the packet records no live-patch mechanism for the Android Framework: a handset that has downloaded and staged the update but not rebooted is still running the affected framework, and on a personal-feeling device the reboot is precisely the step users postpone, which is the specific way this remediation is recorded as done while remaining undone. Precondition, stated because this is where a mobile patch SLA is routinely over-claimed: the management policy can prohibit deferral and force installation of an update the device has already been offered, but it cannot produce a patch level that the device's OEM or carrier update channel has not shipped for that model. The SLA therefore has to be measured against per-model availability, and models with no 2023-03-01 or later build available fail this control by definition — they must be surfaced as unremediated devices carrying a replacement decision, not counted as compliant on the grounds that the policy was applied to them.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism for the Android Framework; remediation requires the device receiving the 2023-03-01 (or later) Android security patch level, which is installed as a system update and reboots the device.' Packet vector names the affected versions as Android-11, Android-12, Android-12L and Android-13 and states the escalation needs no additional execution privileges and no user interaction. CISA KEV-listed 2023-04-13, active_exploitation confirmed, poc_available false, patch_available true, live_patch_available false, CVSS 7.8, RWEP 49.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-29492": {
     "name": "Novi Survey Insecure Deserialization Vulnerability",
@@ -57590,7 +59408,32 @@
         "adequate": false,
         "gap": "A.8.8 would score this 'low' on CVSS alone and defer it, but the KEV listing and spyware chain show the leak's real weight as an exploitation primitive; assessing it purely by base severity mis-prioritises the mobile-fleet patch it actually needs."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's exploit precondition is a non-privileged application performing valid Mali GPU operations — nothing malformed, nothing that fails — and the packet records the fix reaching devices only as the Arm-fixed Mali driver bundled into an OEM/Android security update that reboots the handset. Applied to this driver, the control means each enrolled handset's security-patch level is evaluated as an access condition on what the device may reach — mail, VPN, document and MDM-brokered data withheld from any device below the level that carried the fixed driver — rather than surfaced as a red row on a patch-compliance report while the device keeps its access. The driver-version half is load-bearing here because the affected ranges are per-architecture (Midgard r6p0-r32p0, Bifrost r0p0-r42p0, Valhall r19p0-r42p0, Avalon r41p0-r42p0), so a fleet policy keyed on OS version alone will pass a device still running an in-range driver. The distinguishing test is to enrol a handset pinned below the bulletin level that carried the fixed driver and confirm the policy actually denies it protected-resource access — an estate that lists the stale device on a report while it keeps its mailbox has recorded the exposure rather than removed it. Precondition, stated because it is where this control is usually over-claimed: restricting installation to vetted store applications raises the bar for getting the attacker's non-privileged app onto the handset, but it does not evict an app already installed and does not cover one delivered through the normal store channel, so a device suspected of already running it belongs on the incident path, not the install-policy path. Terminal state: the entry's framework_coverage records that handsets past their Android security-update window keep this leak with no available fix, so for those models the fixed build is unreachable and the requirement ends in removing the device from the estate on a dated schedule — a rule that ends at 'every handset reports the fixed driver' marks a model whose OEM has stopped shipping bulletins as compliant while it stays exposed.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-04-07, active_exploitation 'confirmed', poc_available true; CVSS 3.3, RWEP 66; ai_discovered false. Vector: 'Memory leak vulnerability in Mali GPU Kernel Driver in Midgard GPU Kernel Driver all versions from r6p0 - r32p0, Bifrost GPU Kernel Driver all versions from r0p0 - r42p0, Valhall GPU Kernel Driver all versions from r19p0 - r42p0, and Avalon GPU Kernel Driver all versions from r41p0 - r42p0 allows a non-privileged user to make valid GPU processing operations that expose sensitive kernel metadata.' attack_vector: a non-privileged app performs valid Mali GPU operations that cause the driver to expose raw kernel pointers via a user-readable timeline-stream ring buffer, leaking kernel metadata that defeats KASLR and enables the next stage of a kernel exploit chain. patch_available true, live_patch_available false; live_patch_notes: 'No live-patch mechanism; remediation is the Arm-fixed Mali GPU driver delivered via the OEM/Android security update, applied through a device update that reboots the handset.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "A CVSS 3.3 information disclosure does not survive a severity-threshold patch queue. Most estates set the intake bar at high or critical, so this entry is filtered out of the remediation backlog before a human reads it — which is exactly how a KASLR-defeat primitive stays resident on a handset fleet. Applied to this CVE, the control means the 2023-04-07 KEV listing rather than the 3.3 base score starts the clock on the Mali driver, and queue position follows the packet's RWEP of 66 with confirmed exploitation and a public PoC. The distinguishing test is to reconstruct the remediation queue as it stood on the KEV date and look for this CVE: on a CVSS-banded triage it will be absent rather than deferred, and absent is the failure this control exists to catch — a deferred item at least has an owner. Precondition, and it is the whole difficulty on a handset estate: the operator does not control when an OEM ships the Arm-fixed driver, so for a model whose bulletin has not landed the requirement cannot resolve to the patch branch at all. It resolves instead to the control's documented-compensating-control branch, and on this CVE that branch can only be an access decision, because the packet has the leak occurring during valid GPU processing operations that user space is entitled to perform — there is no on-device setting, driver option or monitoring rule that removes the read, so a compensating control recorded as 'hardened' or 'monitored' here is a compensating control that does not exist.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-04-07, active_exploitation 'confirmed', poc_available true. CVSS 3.3 against RWEP 66 — the packet's attack_vector states why the two disagree: the exposed kernel metadata is what 'defeats KASLR and enables the next stage of a kernel exploit chain'. The vector states the exposure occurs when a non-privileged user makes valid GPU processing operations. patch_available true, live_patch_available false; live_patch_notes: 'No live-patch mechanism; remediation is the Arm-fixed Mali GPU driver delivered via the OEM/Android security update, applied through a device update that reboots the handset.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2022-27926": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Vulnerability (CVE-2022-27926)",