@blamejs/exceptd-skills 0.19.9 → 0.19.11

package/data/zeroday-lessons.json

@@ -1,7 +1,7 @@
 {
   "_meta": {
     "schema_version": "1.1.0",
-    "last_updated": "2026-08-09",
+    "last_updated": "2026-08-10",
     "last_threat_review": "2026-05-17",
     "purpose": "Zero-day learning loop output. Each entry maps a CVE to: attack vector, defense chain analysis, framework coverage, new control requirements generated, and exposure scoring. v1.1.0 (2026-05-15): every entry now carries ai_discovered_zeroday boolean + ai_discovery_source enum + ai_discovery_date + ai_assist_factor ladder, per AGENTS.md Hard Rule #7.",
     "note": "Never delete entries. Closed gaps are marked status: closed. History is data.",
@@ -2944,7 +2944,20 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "low"
+    "ai_assist_factor": "low",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "Bound to this appliance: the QTS / QuTS hero web management surface on a TS-453E-class NAS answers only from an operator subnet or an authenticated VPN — not from a general user VLAN, and not from the internet via a UPnP mapping or a router port-forward, which is how small-office NAS hardware normally acquires exposure — and the appliance's outbound path is constrained so a NAS running attacker code cannot reach arbitrary destinations with the data it holds. State the precondition plainly: this bounds who can present input to the CWE-78 command-injection sink, it does not remove the sink. It does nothing for an attacker already holding a foothold on the operator subnet or on the NAS itself, nothing for the later components of the demonstrated chain once the first stage has landed, and because the packet records no live-patch path (live_patch_available false, live_patch_notes null) the appliance still has to be taken through the vendor firmware update to remediate. Where the business genuinely needs the web UI reachable from user segments, the isolation does not hold and the firmware update is the only remaining action. Distinguishing test: from a general user VLAN and from an external address, attempt to load the appliance's web management surface; anything that answers is within reach of the demonstrated chain, and 'the NAS is on the internal network' is a statement about topology, not evidence that the management surface is unreachable from untrusted segments.",
+        "evidence": "Packet records CWE-78, CVSS 9.8, RWEP 40, poc_available true, patch_available true, live_patch_available false with live_patch_notes null, cisa_kev false and active_exploitation 'unknown'. Attack vector: component 1/3 of the DEVCORE Research Team chain on the QNAP TS-453E appliance at Pwn2Own Ireland 2025 — a chained injection plus format-string bug demonstrated as part of the three-CVE chain that earned $40,000 and 4 Master of Pwn points. Citing gaps are all patch-cadence / system-security controls (AU-Essential-8-Patch, NIST-800-53-SI-2, ISO-27001-2022-A.8.8, NIS2-Art21-vulnerability-management, UK-CAF-B4) plus EU-CRA-Art13.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-62848": {
     "name": "QNAP QTS/QuTS hero RCE (Pwn2Own Ireland 2025, chain 2/3)",
@@ -3077,7 +3090,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "low"
+    "ai_assist_factor": "low",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "The TS-453E is a NAS, so the box that this chain lands privileged execution on is the box holding the data. The packet places this CVE as the elevation step that converts the unauthenticated RCE foothold from the chain's earlier components into appliance-level privileged execution, which means the operator-side lever is the network position of the appliance rather than anything about the elevation primitive itself. Applied to this product the control means the QTS/QuTS hero management and service surfaces answer only from an operator subnet or an authenticated VPN — not from a general user VLAN, and not from the internet through a router port-forward or a UPnP mapping, which is how small-site and remote-worker NAS hardware normally acquires exposure — and that the appliance's outbound path is constrained so a rooted unit cannot ship the data it holds to arbitrary destinations. The precondition is exact and has to be stated rather than implied: isolation removes the chain's entry point only for callers outside the permitted segment. It does nothing once an attacker already holds the foothold this CVE elevates from, nothing against a caller inside the operator subnet or a compromised administrator host, and nothing about an implant placed before the restriction was applied. The packet records an available vendor patch with no live-patch path, so the appliance still has to be taken through the firmware update to remediate; a unit left isolated and unpatched is a deferral with an expiry date attached, not a closed finding. Distinguishing test: from a general user VLAN and from an external address, attempt to load the appliance's management surface — anything that answers is within reach of the published chain, and 'the NAS is on the internal network' is a claim about topology rather than a demonstration that the surface is unreachable from untrusted segments.",
+        "evidence": "Packet attack_vector: 'Component 3/3 of the DEVCORE Research Team chain on the QNAP TS-453E appliance at Pwn2Own Ireland 2025 — post-auth elevation (CWE-269, T1068). Used by the chain to convert the unauth RCE foothold from CVE-2025-62847/62848 into appliance-level privileged execution.' poc_available true; cisa_kev false with kev_date null and active_exploitation unknown; patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The gaps recorded against this entry are patch-and-vulnerability-management controls, and the paper-compliance failure they permit here is specific to appliance firmware: an estate can hold a green 'patch operating systems' attestation covering its servers and workstations while the QNAP appliance's firmware build was never enumerated by the scan at all, because appliance firmware is not an OS package and the unit is not a managed host. The operational test for this CVE therefore has two halves. First, does the scan report a running firmware build read from the appliance itself, rather than treating absence of data as absence of findings? Second, does the build it reports carry the fixes for the chain's other links and not this CVE alone — the packet places this defect as component 3/3 and attributes the unauthenticated RCE foothold to CVE-2025-62847/62848, so a unit remediated only for the elevation step leaves the chain's entry point standing as an independently exploitable unauthenticated path. A verdict derived from a model name, a purchase record or a support-contract entry instead of the running build is the paper-compliance case this control exists to catch.",
+        "evidence": "Packet citing gaps: AU-Essential-8-Patch ('Patch operating systems'), ISO-27001-2022-A.8.8 ('Management of technical vulnerabilities') and NIST-800-53-SI-2 ('Flaw Remediation') are recorded as insufficient for this entry. Packet attack_vector identifies the defect as component 3/3 of the chain and names 'the unauth RCE foothold from CVE-2025-62847/62848'; the packet gives the affected product as the QNAP TS-453E appliance running QTS/QuTS hero, with patch_available true.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-59389": {
     "name": "QNAP Hyper Data Protector critical RCE (Pwn2Own Ireland 2025)",
@@ -7654,7 +7690,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": "Catalyst SD-WAN Manager is the management plane the packet names, and the defect sits on its API interface: improper file handling lets an uploaded file drive a privileged API into overwriting arbitrary files on the system, ending in vmanage user privileges. Bound to this product, the control means every file-accepting API endpoint on SD-WAN Manager authorizes its caller before the upload is processed at all, and normalizes and validates the destination path before the privileged write executes, so a caller-supplied name cannot select which file gets overwritten; and no SD-WAN Manager instance is left with that API interface reachable from a segment with no operational need to reach it. The packet's own summary describes the path as reachable by an unauthenticated attacker, which is why the endpoint's own authorization decision — not the surrounding account model — is the only thing standing between an untrusted caller and a privileged file write. This is also why the cited least-privilege gap does not close this path: the attacker never holds a vManage operator account, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the path stays open. Distinguishing test: on a staging SD-WAN Manager, send each file-accepting API endpoint an unauthenticated upload whose destination path resolves outside the intended upload directory, and confirm it is refused before anything is written. Precondition: the endpoint-side authorization and path validation 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 API interface bounds who can send the upload but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable where the API interface must stay reachable for normal operation.",
+        "evidence": "Packet vector: 'Cisco Catalyst SD-WAN Manager contains an incorrect use of privileged APIs vulnerability due to improper file handling on the API interface of an affected system. An attacker could exploit this vulnerability by uploading a malicious file on the local file system. A successful exploit could allow the attacker to overwrite arbitrary files on the affected system and gain vmanage user privileges.' Packet attack_vector: 'an incorrect use of privileged APIs (CWE-648) reachable by an unauthenticated attacker, enabling privileged actions on the management plane.' Citing gaps record NIST-800-53-AC-6 (Least Privilege) against this entry. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive the packet records is an arbitrary file overwrite on the SD-WAN Manager host carried out with vmanage privileges — so the exposed asset is not one upload directory but every file that management plane holds. Applied to this product, the control means treating the SD-WAN Manager installation as privileged content rather than as application data: file-integrity-monitor the installation and the directories its API writes into, and alert on any write that does not correspond to a sanctioned administrator action or a vendor update. This is the control that still has value after the update lands, because the fix closes the write path but removes nothing already written through it — a file overwritten or planted before remediation survives the upgrade and the restart. With exploitation confirmed and a public exploit recorded in the packet, an instance whose API interface was reachable before remediation needs forensic triage of what was written rather than being closed on the patch. Precondition: integrity monitoring is a detection and triage control, not a preventive one — it does not stop the overwrite, and it only yields an answer where a known-good baseline of the installation predates the exposure window. Where no such baseline exists, the honest position is that the overwritten set is unknown and the instance is a rebuild candidate, not a patched-and-cleared one.",
+        "evidence": "Packet vector: a successful exploit 'could allow the attacker to overwrite arbitrary files on the affected system and gain vmanage user privileges.' Packet: active_exploitation confirmed, poc_available true, CISA KEV listed 2026-04-20, RWEP 77, CVSS 8.8. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is KEV-listed with confirmed exploitation and a public exploit recorded, and the packet gives a vendor patch, no live-patch path, and a fix that per the KEV requiredAction typically requires a service restart or system reboot. For this CVE the SLA's completion criterion is therefore each SD-WAN Manager instance running the fixed build after that restart has been taken — not 'update staged', 'change request raised', or a KEV due-date row marked closed on the management console. Where the restart cannot be taken inside the window, the documented compensating control this SLA permits is restricting reachability of the API interface to the operator segments with an operational need for it, and that restriction has to be written down as the active mitigation with a dated action item tied to the restart, not silently counted as remediation. Precondition: the reachability restriction bounds who can send the upload the packet describes; it does not repair the file-handling defect. Any host inside the permitted segment still reaches the vulnerable endpoint with the full primitive, so the restriction is a holding measure for the window before the restart, never a substitute for it.",
+        "evidence": "Packet: CISA KEV listed 2026-04-20, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 8.8, patch_available true, live_patch_available false. live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-20133": {
     "name": "Cisco Catalyst SD-WAN Manager Exposure of Sensitive Information to an Unauthorized Actor Vulnerability",
@@ -8049,7 +8117,42 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "This flaw's entire precondition is a low-privileged local account on the SD-WAN Manager appliance: the packet has an authenticated, local attacker reading a credential file for the DCA user from the filesystem and thereby gaining DCA privileges. Bound here, privilege tiering means the appliance carries no general-purpose local accounts at all — every operator who can obtain shell or filesystem-level access on vManage sits in a distinct tier above application and network admins, reached only through a PAM jumphost with FIDO2 step-up, just-in-time elevation, an identity used for nothing else, and per-session attribution. State the precondition honestly rather than claiming the surface is removed: this shrinks the population that can reach the credential file, it does not make the stored password unrecoverable. Any principal that does obtain low-privileged local access on the appliance — through an operational account, a support process, or any other local-access defect on the same host — still recovers the DCA credential, and the control has no effect at all on a credential that was already read. The cited least-privilege and identity-and-access-control gaps are recorded here because the escalation runs from one local account to another via a file read, so an attestation that vManage roles are least-privileged passes cleanly while the recoverable credential file sits on disk. Distinguishing test: from a deliberately low-privileged local account on a staging appliance, attempt to read the DCA credential file and confirm the account cannot exist in the first place under the tiering policy.",
+        "evidence": "Packet fields for CVE-2026-20128: cwe_refs CWE-257; vector 'Cisco Catalyst SD-WAN Manager contains a storing passwords in a recoverable format vulnerability that allows an authenticated, local attacker to gain DCA user privileges by accessing a credential file for the DCA user on the filesystem as a low-privileged user.'; cisa_kev true with kev_date 2026-04-20; active_exploitation confirmed; rwep_score 77; cvss 8.8; poc_available true; patch_available true; live_patch_available false. NIST-800-53-AC-6 (Least Privilege), UK-CAF-B2 (Identity and access control) and NIS2-Art21-network-security are among the citing framework gaps.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "A recoverable-format password disclosure is not closed by the code fix: the update changes how the DCA credential is stored, but a password an attacker has already read stays valid until it is changed. With the packet recording confirmed in-the-wild exploitation from the 2026-04-20 KEV listing on a controller whose own filesystem held the credential, the response half of this control is the load-bearing half — rotate the DCA credential and any other credential recoverable from the appliance filesystem as part of the update rather than as a follow-up ticket, audit what that account was used for across the exposure window, and invalidate device-trust state established through the controller where the account's use cannot be accounted for. Two preconditions decide whether the rotation is worth anything. It has to happen after the fixed build is running: rotating first simply writes a fresh password back into the recoverable format, leaving the operator with a rotation record and an unchanged exposure. And it only covers credentials the operator knows the appliance stores, so an inventory of what the controller holds on disk has to precede the rotation. This is a response control — it does not reduce the likelihood of the initial low-privileged local foothold that the flaw requires.",
+        "evidence": "Packet fields for CVE-2026-20128: vector states an 'authenticated, local attacker' can 'gain DCA user privileges by accessing a credential file for the DCA user on the filesystem as a low-privileged user'; attack_vector records 'storage of passwords in a recoverable format (CWE-257), allowing an attacker with access to recover credentials'; cisa_kev true with kev_date 2026-04-20; active_exploitation confirmed; poc_available true; rwep_score 77; patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' UK-CAF-B2 (Identity and access control), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-network-security are among the citing framework gaps.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV listing of 2026-04-20 with confirmed in-the-wild exploitation puts this controller on the KEV clock rather than in the standard appliance patch window, and two packet details decide how the SLA is measured. There is no live-patch tool recorded for this entry, and the packet states the vendor patch typically requires a service restart or system reboot per the KEV required action — so the SLA is satisfied when each controller has restarted onto the fixed build, not when the package is staged or installed, and the restart outage has to be scheduled inside the clock rather than deferred to the next maintenance window. The limit belongs in the control statement: meeting the SLA does not close this entry on its own, because the credential file was readable for the whole pre-patch window on every affected controller. A patch-currency attestation showing the fixed build installed fleet-wide is fully consistent with an attacker still holding a valid DCA password, which is why the clock has to be paired with rotation of the exposed credential rather than recorded as the remediation.",
+        "evidence": "Packet fields for CVE-2026-20128: cisa_kev true with kev_date 2026-04-20; active_exploitation confirmed; rwep_score 77; cvss 8.8; poc_available true; patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'; vector describes an authenticated local attacker gaining DCA user privileges by accessing a credential file for the DCA user on the filesystem. AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are among the citing framework gaps.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-32975": {
     "name": "Quest KACE Systems Management Appliance (SMA) Improper Authentication Vulnerability",
@@ -8109,7 +8212,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KACE SMA entry is KEV-listed with confirmed exploitation and a public PoC, so the clock for this appliance runs from the listing date rather than the next appliance-maintenance window. The packet records a vendor patch with no live-patch path and notes that the patch typically requires a service restart or system reboot per the KEV requiredAction, which fixes how completion must be measured: by each appliance actually running the fixed build after that restart, not by 'update approved' or 'update staged' in a change record. An appliance that holds the update but has not been restarted is still serving the vulnerable authentication path and must be counted as exposed. Because no live-patch primitive exists for this product, any interval the operator cannot compress has to be carried as a documented compensating control (restricting which network segments may reach the appliance's authentication surface) recorded as a compensating state with a dated action, not reported as remediated.",
+        "evidence": "Packet: cisa_kev true with kev_date 2026-04-20, active_exploitation confirmed, rwep_score 77, cvss 9.1, poc_available true. 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.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "KACE SMA takes an authentication decision in front of an endpoint-management console, and this CVE is that decision failing open: the packet has an attacker impersonating legitimate users without valid credentials, reaching functionality behind the gate without ever presenting an account. Bound to this appliance the control means each administrative and API function on the SMA authorizes its own caller instead of inheriting a verdict from the front-door authentication, and the appliance's management surface is segmented so a caller with no operational need cannot present a request to that front door at all. This is precisely why the packet's cited multi-factor, identity-and-access and least-privilege gaps do not help here: the attacker never authenticates, so no second factor is demanded and no role is consulted, and an attestation that every KACE operator uses MFA passes cleanly while the path stays open. The precondition on the segmentation half must be stated rather than implied — it bounds who can reach the bypass, not whether the bypass works. A request originating from a permitted management segment, from an already-compromised administrator workstation, or from access obtained before the restriction was applied still reaches it, so segmentation buys time until the appliance is restarted onto the fixed build and never substitutes for that restart. Distinguishing test: from a segment with no operational need for the SMA console, issue unauthenticated requests to each administrative endpoint on a staging appliance and confirm each is refused before the function runs.",
+        "evidence": "Packet vector: the appliance 'contains an improper authentication vulnerability that could allow attackers to impersonate legitimate users without valid credentials'; attack_vector records an improper-authentication flaw (CWE-287) letting an unauthenticated attacker bypass authentication on the endpoint-management appliance. The entry's citing gaps name AU-Essential-8-MFA (Multi-factor authentication), UK-CAF-B2 (Identity and access control) and NIST-800-53-AC-6 (Least Privilege) as the framework controls that do not cover it.",
+        "gap_closes": [
+          "AU-Essential-8-MFA",
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet pairs confirmed in-the-wild exploitation and a public PoC with a fix that the vendor notes typically requires a restart or reboot, which means every affected appliance had an exposure window and the update closes the authentication path without touching anything already done through it. Because the compromised asset is an endpoint-management appliance, the playbook has to cover what that appliance can reach and not just the appliance itself: review what it was configured to distribute to managed endpoints across the window running from first plausible exposure to the restart onto the fixed build, rotate the credentials the appliance holds for reaching those endpoints along with any operator account used through it during that window, invalidate device-trust state, and set quarantine criteria for endpoints that received anything from it in that period. The precondition worth naming is that the playbook must already exist and be rehearsed before the next disclosure, because the detection an operator would reach for first will not fire: the packet's own words are that the attacker impersonates legitimate users without valid credentials, so the activity presents as a legitimate operator and authentication-failure monitoring has nothing to surface. Patching alone answers the vulnerability question and leaves the compromise question unasked.",
+        "evidence": "Packet: active_exploitation confirmed, cisa_kev true with kev_date 2026-04-20, poc_available true, against what the attack_vector describes as an endpoint-management appliance. patch_available true but live_patch_available false, with live_patch_notes stating the vendor patch 'typically requires service restart or system reboot per the KEV requiredAction'. Packet vector: attackers 'impersonate legitimate users without valid credentials'.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-27199": {
     "name": "JetBrains TeamCity Relative Path Traversal Vulnerability",
@@ -8473,7 +8609,29 @@
     },
     "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": "The sink on this entry is reached only when a user opens an attacker-controlled document that causes VBA to resolve a library from a path the attacker controls, so on any workstation not yet on the fixed and restarted build the ingress path is the surface an operator can actually enforce. Require the untrusted-origin mark on every VBA-bearing Office document arriving by mail, web download or untrusted file share, and require marked documents to open in an isolated reduced-privilege render instead of the full load path that resolves the hijacked library at the user's own privilege. The mark has to be applied at the ingress boundary and survive the container the document travels in — extraction from an archive, mount of an ISO or VHD, rename — because a search-order hijack needs the substitute library to sit in a directory the opening process searches, which is typically the same container that carried the document; a provenance scheme that tags the document but not its sibling files leaves the payload sitting where the loader will find it. Precondition: this constrains delivery only, and it holds only where the mark is applied and preserved. A document reaching the user over an internal share, a sync client or any channel that strips the tag, or a policy that lets the user click through to full editing, restores the vulnerable path in one step; and once an attacker already has write access to a searched directory on the host, provenance enforcement contributes nothing. Those cases close only with the vendor fix, and the packet records no live-patch tool for this entry with the fix typically requiring a service restart or system reboot — so hosts that have taken the update but not restarted must be counted as exposed rather than remediated.",
+        "evidence": "Packet fields for this entry: CWE-426 insecure library loading in Microsoft Visual Basic for Applications; attack_vector records an attacker-controlled document loading a malicious DLL from an unexpected path (search-order hijacking) for code execution. cisa_kev true with kev_date 2026-04-13, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77. patch_available true and live_patch_available false, with live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" AU-Essential-8-App-Hardening (User application hardening) and NIST-800-53-AC-6 (Least Privilege) are both recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-074",
+        "name": "CVE-REGRESSION-WATCHER",
+        "description": "This entry carries a 2012 CVE identifier alongside a 2026-04-13 KEV listing, confirmed in-the-wild exploitation and an available PoC — precisely the historical-identifier-resurfacing signal this control asks a threat-intake pipeline to raise. Applied here, intake must treat exploitation reports and PoC publications that name an identifier years older than the current advisory stream as a candidate re-exposure and force the affected-asset question back open for the VBA-bearing estate, because a vulnerability-management queue driven by current-year advisories will never revisit an identifier of this age on its own — the hosts get scoped only if something pushes the old ID back into the queue. Precondition: this is an intake and detection control and nothing more. It shortens time-to-notice; it does not remediate, it fires only where the pipeline covers the source that names the old identifier, and it gives no coverage on hosts compromised before the listing. The action it must hand off to is the vendor fix plus the restart or reboot the packet records as required, since no live-patch path is registered for this entry.",
+        "evidence": "Packet fields for this entry: the identifier is CVE-2012-1854, while cisa_kev is true with kev_date 2026-04-13 and active_exploitation confirmed; poc_available true, rwep_score 77, cvss 9.8. 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.\" ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-patch-management (Vulnerability handling and disclosure) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-60710": {
     "name": "Microsoft Windows Link Following Vulnerability",
@@ -8937,7 +9095,29 @@
     },
     "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 of this entry requires a user to open a crafted PDF, so until every Acrobat and Reader install in the estate is on the fixed build and has been restarted, the delivery path is the enforceable surface. Require the untrusted-origin mark on PDFs arriving by mail, web download and untrusted file share, applied at the ingress boundary rather than derived from metadata travelling with the file, and require marked PDFs to open in the reader's isolated reduced-privilege render instead of the full parsing path that carries the CWE-1321 prototype-pollution sink at the user's own privilege. The mark must survive the container, so a PDF extracted from an archive or mounted from an image still reaches the reader marked untrusted. Precondition: this narrows the path to the sink, it does not remove the sink. A PDF arriving over an internal share, a sync client or a chat client that writes the file locally reaches the parser unmarked, and a policy that permits the user to leave the protected render restores the full path in one click — neither case has compensating coverage and both need the vendor update plus the application or system restart the packet records as required. If the estate additionally disables document scripting, record that as unverified coverage for this entry rather than as a substitute for the update: the packet does not identify which component the prototype-pollution sink sits behind, so the operator cannot assert the scripting toggle covers it.",
+        "evidence": "Packet fields for this entry: CWE-1321 prototype pollution in Adobe Acrobat and Reader; vector and attack_vector both record arbitrary code execution when a crafted PDF is opened. cisa_kev true with kev_date 2026-04-13, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true and live_patch_available false, with live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" AU-Essential-8-App-Hardening (User application hardening) and NIST-800-53-AC-6 (Least Privilege) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet names the affected product as Adobe Acrobat and Reader, which on a real estate is never one install: Reader and Acrobat ship as separate products on separate update tracks, and per-user copies land outside managed software distribution. The control here means enumerating every installed Acrobat and Reader copy across those tracks and confirming each reports the fixed build, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope it to those products: the packet ties the CWE-1321 sink to Acrobat and Reader and provides no mapping from the vulnerable code into other PDF-handling software, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates. Widen the inventory only where a verified source identifies another product carrying the same component. The distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs on the estate and confirm none still report a pre-fix version — an estate that patches the inventoried Reader while a second Acrobat track keeps the old build still opens crafted PDFs into the sink, with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; an unmanaged per-user install is remediated by removing it, not by recording it as patched. The packet registers no live-patch path, so each copy carries the service restart or system reboot the vendor fix requires, and a copy updated but not restarted is not yet remediated.",
+        "evidence": "Packet fields for this entry: the affected product is recorded as \"Adobe Acrobat and Reader\" with a CWE-1321 prototype-pollution flaw reached by opening a crafted PDF; cisa_kev true, kev_date 2026-04-13, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIST-800-53-SI-2 (Flaw Remediation) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-1340": {
     "name": "Ivanti Endpoint Manager Mobile (EPMM) Code Injection Vulnerability",
@@ -12351,7 +12531,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet's affected surface spans watchOS, iOS, iPadOS, macOS, visionOS and tvOS, and the fix is a full OS build with no live-patch path — so for this entry the control means the KEV clock that opened 2026-03-20 drives the update across the managed Apple estate on a declared short SLA with user deferral disallowed, not on the estate's normal OS-upgrade cadence. Completion must be measured by each device's installed build against the fixed build for its product, and because the packet records that the vendor fix typically requires a service restart or system reboot, a device that has downloaded or staged the update but not restarted is still running the vulnerable code and counts as exposed rather than remediated. Precondition: the declarative-management lever exists for enrolled iPhone, iPad and Mac. The watchOS, tvOS and visionOS units named in the same packet are commonly updated through a paired device or are not enrolled at all, so no-deferral enforcement does not reach them — those must be enumerated separately and driven manually or held outside the trust boundary until their build is confirmed. Omitting them makes the SLA report read complete while the devices nobody enrolled are the ones still carrying the flaw.",
+        "evidence": "Packet fields for this entry: the vector states that Apple watchOS, iOS, iPadOS, macOS, visionOS and tvOS contain an improper locking vulnerability (CWE-667) that could allow a malicious application to cause unexpected changes in memory shared between processes. cisa_kev true with kev_date 2026-03-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true and live_patch_available false, with live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-patch-management (Vulnerability handling and disclosure) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records is a malicious application causing unexpected changes in memory shared between processes, so for this entry the control's access-condition half is the load-bearing one: on any Apple device that cannot yet take the fixed build, the operator's remaining levers are constraining what code is allowed to run at all and withholding organizational data from the device until its build is at or above the fix. The fixed build must function as an access condition — mail, VPN and document access denied to a device below it — not as a row on a patch-compliance dashboard. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition: restricting untrusted or side-loaded application installation raises the bar for getting the attacker's application onto the device, but it does not evict an application already installed, and it does not cover one that arrived through the normal store channel. A device suspected of already running the malicious application belongs on the incident path, not the install-policy path. This is a holding measure for the window before the fixed build and its required restart land, not a substitute for them.",
+        "evidence": "Packet fields for this entry: CWE-667 improper locking across Apple watchOS, iOS, iPadOS, macOS, visionOS and tvOS, with the vector stating it could allow a malicious application to cause unexpected changes in memory shared between processes. cisa_kev true, kev_date 2026-03-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" AU-Essential-8-Patch (Patch operating systems) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-43520": {
     "name": "Apple Multiple Products Classic Buffer Overflow Vulnerability",
@@ -13070,7 +13272,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-103",
+        "name": "AI-APP-BUILDER-EXECUTION-ENDPOINT-AUTH-AND-SANDBOX",
+        "description": "n8n is the visual workflow/agent builder class this control governs, and the defect sits in exactly the sink the control names: the workflow expression evaluation system, a dynamic-evaluation path that turns workflow-supplied content into executable code. For an n8n deployment the requirement is that every surface which can reach expression evaluation authenticates the caller before the expression is evaluated — the editor API, workflow import, and any trigger whose fields are expression-evaluated — and that the n8n execution process runs confined rather than with host privileges, so a successful evaluation cannot reach filesystem, network or process operations beyond what the workflows legitimately need. Preconditions, all of which must be recorded rather than assumed: this bounds who can reach the evaluator, it does not repair the evaluator, so the vendor update remains the only fix for the flaw itself. Anyone already holding an editor-capable account is inside the authentication boundary and the control does nothing against them. Confinement added after the fact does not evict an attacker resident from an earlier execution on that host. And where a trigger must stay reachable by untrusted callers for the workflow to do its job, that path cannot be closed by authentication at all — for it, the update is the only remedy and the interim state is exposure, not mitigation.",
+        "evidence": "The packet records CWE-913, described as an improper control of dynamically managed code resources vulnerability in n8n's workflow expression evaluation system that allows for remote code execution, at CVSS 9.8 with rwep_score 77 and poc_available true. cisa_kev is true with kev_date 2026-03-11 and active_exploitation confirmed. The entry cites NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) among the framework controls that are insufficient here, which is the privilege-and-boundary half this control addresses. patch_available is true and live_patch_available is false.",
+        "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 opens at the 2026-03-11 KEV listing, and what has to be measured is the n8n build actually running, not the release pulled. The packet records no live-patch tool for this entry and notes the vendor patch typically requires a service restart or system reboot, so an instance that has fetched the fixed release but has not restarted the n8n service is still executing the vulnerable expression evaluator and must be counted as exposed rather than remediated. The second requirement follows from active_exploitation being confirmed with a public exploit available: an instance whose editor or trigger surface was reachable during the exposure window needs forensic review of the workflows present on it and rotation of any credential the n8n process could reach, because code execution on that host precedes the update and is not undone by it — patch-and-close is the wrong verdict for an instance that was reachable, and the compliance record must distinguish 'updated and restarted' from 'updated, restarted, and triaged'.",
+        "evidence": "cisa_kev true with kev_date 2026-03-11, active_exploitation confirmed, poc_available true, rwep_score 77 against cvss 9.8. patch_available is true and live_patch_available is false; live_patch_notes states that no live-patch tool is registered for this entry at bulk-import time and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The four cited patch-and-vulnerability-handling gaps — AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management — are the risk-based-timeframe controls that carry no KEV-triggered clock.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2021-22054": {
     "name": "Omnissa Workspace ONE Server-Side Request Forgery",
@@ -13451,7 +13677,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-118",
+        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
+        "description": "The packet states this exploit's only access requirement outright: an unauthorized user would require network access to the controller. So on this entry the segmentation half of this control is the load-bearing half, and the credential-elimination half is not a lever the operator holds — the key that authenticates design software to Logix controllers is discoverable from Studio 5000 itself rather than set per site, so there is no vendor-default or blank administrative account for the operator to rotate away. Applied here, it means the Logix controllers' network interfaces answer only from a segmented engineering and management plane — the engineering workstations and servers with an operational need to program them — and not from a flat plant network, a general business VLAN, or any routable path from outside. Distinguishing test: from a segment with no programming role, attempt to open a connection to a Logix controller on a staging cell; anything that answers is within reach of the published exploit, because past that point the attacker supplies the key from the design software rather than obtaining anything from the target. Precondition: segmentation bounds the population that can reach the controller, it does not repair the key handling. The packet's stated requirement is only network access to the controller, so any compromised engineering workstation, contractor laptop or jump host already inside the permitted segment satisfies that precondition in full, and the segmentation does nothing against an unauthorized application running on a host that legitimately talks to the controller. It is a holding measure for the window before the vendor update, not a closure.",
+        "evidence": "Packet vector: 'This key is used to verify Logix controllers are communicating with Rockwell Automation design software. If successfully exploited, this vulnerability could allow an unauthorized application to connect with Logix controllers. To leverage this vulnerability, an unauthorized user would require network access to the controller.' Packet: CISA KEV listed 2026-03-05, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 8.8.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The packet puts the secret inside the product: Studio 5000 Logix Designer 'may allow a key to be discovered', and that key is what verifies Logix controllers are communicating with Rockwell design software. Because the constant an attacker needs is obtainable from the design software rather than from the target site, no amount of operator-side credential hygiene reduces the exposure — which is exactly why the least-privilege and identity-and-access-control gaps are recorded against this entry: the attacker never authenticates as any engineer, so per-account privilege scoping is never consulted and the account model an identity attestation examines is bypassed rather than abused. The control's requirement here is to inventory every Studio 5000 installation and every Logix controller in the estate as depending on a product-shipped verification key, gate each of those deployments on the vendor update rather than on a password or account policy, and re-run that check after any engineering-workstation rebuild, image restore or controller replacement, since those are the operations that quietly reintroduce an unpatched pairing at a site that had been remediated. Distinguishing test: produce, per cell, the Studio 5000 version and the controller firmware actually in service and show each is at or above the vendor's fixed level — an attestation that every engineer holds a unique Studio 5000 account passes cleanly while this flaw stays fully exploitable. Precondition: the vendor update is what removes the dependence on the discoverable key; this control is the inventory and the gate that ensure every installation reaches it, and it gives nothing on its own to a site that has not yet taken the update. It also does not detect a controller an unauthorized application has already connected to, so a cell that was reachable during the exposure window needs its controller configuration and control logic compared against a known-good copy rather than being closed on the patch.",
+        "evidence": "Packet vector: 'Studio 5000 Logix Designer software may allow a key to be discovered. This key is used to verify Logix controllers are communicating with Rockwell Automation design software.' CWE-522. Citing gaps record NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B2 (Identity and access control) against this entry. patch_available true; active_exploitation confirmed; poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet records a vendor patch, no live-patch path, and a fix that per the KEV requiredAction typically requires a service restart or system reboot. On Logix controllers driving a live process, that restart is scheduled against the process rather than against the 2026-03-05 KEV clock, which produces a long interval in which the estate's real state is 'reachability restricted, patch pending' — not remediated. This control requires that state to be recorded distinctly for each affected cell: the compensating control actually in force (the controller-reachability restriction), the residual risk it leaves (any host already inside the permitted segment still meets the exploit's only stated precondition, network access to the controller), and a dated action item tied to the next outage window in which the restart can be taken. It must not be reported as 'patched per SLA' and the KEV row must not be closed on the basis of the update having been obtained. Precondition and limit: this is a reporting-integrity control, not a technical mitigation — it changes what the audit sees, not what the attacker can reach, and it is only honest if the compensating control it records has been tested against a staging cell rather than asserted from a network diagram.",
+        "evidence": "Packet: 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.' CISA KEV listed 2026-03-05, active_exploitation confirmed. Packet vector: 'To leverage this vulnerability, an unauthorized user would require network access to the controller.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-43000": {
     "name": "Apple Multiple products Use-After-Free Vulnerability",
@@ -13911,7 +14170,38 @@
     },
     "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": "The Cisco SD-WAN application CLI is the constrained user surface this control governs. The packet's vector describes an authenticated local attacker gaining elevated privileges via improper access controls on commands within the application CLI, with a successful exploit allowing arbitrary commands as the root user — a user-facing surface wired straight to a root operation, which is the pattern the control forbids. Applied to this device, it means the SD-WAN privileged operations sit behind their own authorization boundary that the application CLI can only request through a constrained, validated interface, so that the CLI's own command-and-path handling is not the single thing standing between a non-root operator account and root. Preconditions: the vendor update is what repairs that boundary — the control states the property to verify, it does not implement it. Until the update is applied, the only operator-side lever is limiting which accounts can open a CLI session, which bounds the population that can attempt the escalation but does not close it, because any account that legitimately reaches the CLI still reaches root. And because active_exploitation is confirmed, a device whose CLI was reachable by a non-root account during the exposure window needs forensic triage and credential rotation; an update applied to a device that already granted root does not remove what the attacker left behind.",
+        "evidence": "The packet's vector states that the Cisco SD-WAN CLI contains a path traversal vulnerability that could allow an authenticated local attacker to gain elevated privileges via improper access controls on commands within the application CLI, and that a successful exploit could allow the attacker to execute arbitrary commands as the root user. cwe_refs are CWE-25 and CWE-282. cvss 7.5, rwep_score 77, poc_available true, cisa_kev true with kev_date 2026-02-25 and active_exploitation confirmed. UK-CAF-B4 (System security) is cited as an insufficient framework control on this entry. patch_available is true, live_patch_available is false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "An SD-WAN device CLI programs the WAN fabric that every site depends on, so the identities that can open a session on it belong in the fleet-control-plane tier this control defines rather than in a general network-operations account pool. For this CVE the tier is load-bearing on one half specifically: the packet's vector places the attacker at an authenticated CLI session, so routing every CLI path through a PAM jumphost with per-session step-up and just-in-time elevation shrinks the set of identities that can reach the vulnerable command handling at all, and makes each attempt attributable. The preconditions are where this control is usually recorded as holding when it does not. It only holds if every path to the device CLI is behind the same gate — console and out-of-band or serial access, recovery and break-glass accounts, and any automation or monitoring service account that logs into the device all bypass a jumphost by default and re-open the full path unless they are enumerated and brought under it. And the tier does not fix the escalation itself: an identity that legitimately passes the gate still reaches root through the flaw. This is a blast-radius and attribution measure that runs alongside the vendor update, never a substitute for it.",
+        "evidence": "The packet's vector places the attacker at an authenticated local session on the application CLI of a Cisco SD-WAN device, escalating to arbitrary commands as root. cisa_kev true with kev_date 2026-02-25, active_exploitation confirmed, poc_available true, rwep_score 77. NIS2-Art21-network-security (Security of network and information systems) is cited as an insufficient framework control on this entry. patch_available is true, live_patch_available is false. Note the packet is internally inconsistent on the privilege precondition: the attack_vector summary line instead describes the flaw as reachable by an unauthenticated attacker, contradicting the vector field this description relies on.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock for this entry opens at the 2026-02-25 KEV listing, and for an SD-WAN estate it has to be measured per device against the software actually running, not against the change record. The packet records no live-patch tool for this entry and notes the vendor patch typically requires a service restart or system reboot, so a device with the fixed image staged but not reloaded still runs the vulnerable CLI command handling and is counted as exposed. Because these devices are updated fleet-wide in waves, the SLA has to be evidenced by the count of devices confirmed running the fixed version rather than by the update being approved or pushed, which is the measurement that lets a partially-completed rollout be reported as within SLA. Where a site's reload window cannot be taken inside the clock, that device is recorded as an open exposure with the restriction of who can open a CLI session on it as the named interim measure — not as patched.",
+        "evidence": "cisa_kev true with kev_date 2026-02-25, active_exploitation confirmed, poc_available true, rwep_score 77 against cvss 7.5. patch_available is true and live_patch_available is false; live_patch_notes states that no live-patch tool is registered for this entry at bulk-import time and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The cited AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 gaps are the risk-based-timeframe patching controls carrying no KEV-triggered clock.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-20127": {
     "name": "Cisco Catalyst SD-WAN Controller and Manager Authentication Bypass Vulnerability",
@@ -14604,7 +14894,20 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock runs from the 2026-02-17 KEV listing, and completion has to be measured on the endpoint rather than in the management console: the packet records no live-patch path and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, so a workstation that has taken the update but not restarted still hosts the vulnerable Microsoft Video ActiveX control (msvidctl) and remains exposed to a crafted web page rendered in Internet Explorer. Two things this SLA must not be allowed to substitute for on this path, and both are why the corresponding gaps are recorded against the entry: the flaw yields the same rights as the logged-on user, so running users as non-administrators narrows the blast radius but does not stop the drive-by execution; and a user-application-hardening attestation covering macro, plugin and advertisement settings does not enumerate the browser-invocable ActiveX control the bug lives in. Until the restart completes on a given host, the only remaining levers are keeping that host away from untrusted web content and recording it as exposed — neither privilege posture nor the hardening baseline closes the path, so an SLA measured on 'update approved' or 'update downloaded' records the exposure instead of removing it.",
+        "evidence": "Packet records CWE-94 in the Microsoft Video ActiveX control (msvidctl), CVSS 9.8, RWEP 77, cisa_kev true with kev_date 2026-02-17, active_exploitation confirmed, poc_available true, 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.' Vector: an attacker constructs a specially crafted Web page; when a user views it the vulnerability could allow remote code execution, giving the attacker the same user rights as the logged-on user; the attack_vector field places this in Internet Explorer for drive-by remote code execution. Citing gaps include NIST-800-53-AC-6 (Least Privilege) and AU-Essential-8-App-Hardening (User application hardening).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2026-2441": {
     "name": "Google Chromium CSS Use-After-Free Vulnerability",
@@ -15234,7 +15537,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": "For this entry the KEV clock opens 2026-02-10 and the unit of completion is a restarted host, not an approved update. The packet records a vendor patch with no live-patch tool registered and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so a Windows host that has installed the update but has not taken the restart is still running the pre-patch Remote Access Connection Manager image and has to be counted as exposed rather than as remediated. Scope the rollout to every host carrying the component rather than to a subset chosen from an assumed reachability model: the packet's vector describes an unauthorized attacker denying service locally, while the packet's own summary line describes the flaw conservatively as network-reachable pending Microsoft's component detail — the two framings do not agree, and narrowing the rollout to whichever one is cheaper is how a KEV-listed defect with confirmed exploitation survives the SLA on paper. The distinguishing test: query the fleet for hosts whose installed build carries the fix AND whose RasMan service has restarted since installation; a management-console report of 'update deployed' does not answer that question.",
+        "evidence": "Packet: cisa_kev true with kev_date 2026-02-10, active_exploitation confirmed, poc_available true, rwep_score 77 against cvss 8.8. 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: 'Microsoft Windows Remote Access Connection Manager contains a NULL pointer dereference that could allow an unauthorized attacker to deny service locally' (CWE-476). The packet's attack_vector line instead reads 'a NULL pointer dereference (CWE-476) in a network-reachable Windows component ... described conservatively as a network-reachable memory-safety flaw pending Microsoft's component detail.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The state this entry forces a framework to name is 'update installed, restart deferred'. Because the packet gives no live-patch tool and a fix that typically needs a service restart or system reboot, a host in that state has not eliminated the defect — it holds a time-bound compensating position, and the audit record has to surface it as one instead of as 'patched per SLA'. The deferral pressure here is structural rather than incidental: the impact the packet describes is denial of service, and the remediation itself costs a RasMan restart or a reboot, so the operators most motivated to defer are running exactly the workloads whose interruption the cited availability gap is about. Two preconditions bound the compensating state and both belong in the record. It is valid only while a dated restart is scheduled — an open-ended deferral is exposure, not mitigation. And the packet says 'service restart or system reboot' without settling which applies to a given build, so the operator has to establish that for their estate and count only hosts where the action actually completed; a host credited on the assumption that a service restart sufficed, when the build needed a reboot, is recorded as remediated while still vulnerable. Where neither has happened and no date exists, the entry is full exposure and should be scored as such.",
+        "evidence": "Packet: 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: Remote Access Connection Manager NULL pointer dereference (CWE-476) allowing an unauthorized attacker to deny service locally; active_exploitation confirmed, kev_date 2026-02-10, rwep_score 77. The entry's citing gaps include NIS2 Art. 21 'Availability and resilience risk-management measures' and ISO/IEC 27001:2022 A.8.8 'Management of technical vulnerabilities'.",
+        "gap_closes": [
+          "NIS2-Art21-availability",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2026-21510": {
     "name": "Microsoft Windows Shell Protection Mechanism Failure Vulnerability",
@@ -15370,7 +15696,23 @@
     },
     "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's vector places this in Windows Remote Desktop Services and describes an authorized attacker elevating privileges locally (CWE-269) — the account is already legitimate, so no account model is being abused; a privilege boundary inside the service is failing. For this CVE the control means the Windows update carrying the fix is driven across every affected host on the KEV clock that opened 2026-02-10 rather than folded into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. Hosts running the Remote Desktop Services role are the population to enumerate first, because a machine where many non-administrative users hold interactive sessions is a machine where the precondition this flaw needs — an already-authorized local user — is the normal operating state rather than an anomaly. 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 taken the update but not restarted still carries the vulnerable code and must be counted as exposed; on a session host that restart is also the step most likely to be deferred, because taking it evicts logged-on users, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. The control's second half is the load-bearing one here: since the attacker is already authorized, tightening account privilege does not contain the escalation, which is exactly why the least-privilege and identity-and-access controls cited on this entry can pass their attestations while the flaw stays fully exploitable. Priority follows the packet rather than the CVSS band: a public PoC, confirmed exploitation, and the packet's own note that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators make this the containment step for a chain, not a standalone endpoint item.",
+        "evidence": "Packet: 'Microsoft Windows Improper Privilege Management Vulnerability', CWE-269; vector 'Microsoft Windows Remote Desktop Services contains an improper privilege management vulnerability that could allow an authorized attacker to elevate privileges locally.' CISA KEV-listed 2026-02-10, active_exploitation confirmed, CVSS 8.8, RWEP 77, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' attack_vector adds that 'LPEs of this class are routinely paired with an initial-access flaw by ransomware operators.' The entry cites AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2, UK-CAF-B2 and NIST-800-53-AC-6 as insufficient.",
+        "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-B2"
+        ]
+      }
+    ]
   },
   "CVE-2026-21519": {
     "name": "Microsoft Windows Type Confusion Vulnerability",
@@ -16503,7 +16845,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-119",
+        "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
+        "description": "CWE-807 on this entry is Office deciding whether content is trusted from input the attacker supplies, so the durable operator-side control is to move the origin determination off the document and onto a boundary the organization operates: the mail gateway, the managed file share and the web download path apply and preserve the untrusted-origin marking themselves, and that marking survives archives, disk-image containers and renames, so the Office host is told the file is externally sourced instead of deriving it from metadata travelling with the file. This matters more than usual here because the packet does not name which Office security feature the bypass defeats — no in-product setting can be assumed to be the intact one, which is exactly why the control that is worth attaching is the one whose input is established outside the vulnerable decision. The precondition has to be written down rather than assumed: boundary-applied marking only covers files that cross a boundary you run. A document arriving on removable media, through a personal cloud-sync client, or on any unmanaged path never passes a marking point and reaches Office unmarked, so those ingress paths must be blocked or brought under the same marking; where that is not done, this control does not cover them and the vulnerable decision is still reached with attacker-supplied input. The distinguishing test: send an externally-sourced document through each ingress path in turn and confirm it arrives at the Office host already marked untrusted, rather than confirming that a hardening policy shows as enabled in the management console.",
+        "evidence": "Packet vector: 'Microsoft Office contains a security feature bypass vulnerability in which reliance on untrusted inputs in a security decision in Microsoft Office could allow an unauthorized attacker to bypass a security feature locally' (CWE-807). cisa_kev true, kev_date 2026-01-26, active_exploitation confirmed, poc_available true, rwep_score 77 against cvss 8.8. The packet does not name the specific Office security feature that is bypassed. Citing gaps on this entry include ASD Essential Eight 'User application hardening' and UK NCSC CAF B4 'System security'.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "This entry is the case that makes a configured-and-enabled attestation worthless: the packet's flaw is the bypass of an Office security feature, so the setting is on and the check returns the wrong answer. Treat Office document handling as a protection-mechanism class and hold a regression battery of the known bypass primitives for that class, re-run on every Office patch deployment rather than once against this CVE, with the fixed build validated by detonating the battery on a representative managed image instead of by reading a version number off an inventory. The packet's own note that some impacted products may be end-of-life or end-of-service makes the recurring form of the test the load-bearing half: those installs will not receive the next fix, so the battery is the only mechanism that tells an operator whether the posture built around them still blocks. State the limit plainly instead of recording the battery as coverage — it exercises only the primitives already known to it and says nothing about the next bypass in the class, so it establishes that this fix landed and that the surrounding controls still hold, not that Office is immune to the class.",
+        "evidence": "Packet vector: Microsoft Office security feature bypass (CWE-807) that 'could allow an unauthorized attacker to bypass a security feature locally', carrying the note 'Some of the impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS).' active_exploitation confirmed, poc_available true, kev_date 2026-01-26, rwep_score 77. Citing gap on this entry: ISO/IEC 27001:2022 A.8.8 'Management of technical vulnerabilities'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV clock on this entry opens 2026-01-26 with exploitation confirmed and a PoC available, and the packet splits the estate into two populations that need different completion criteria. For supported Office builds the mitigation is the vendor update driven across the fleet with the restart the packet says the fix typically requires, since no live-patch tool is registered — an install that has not restarted is not a closed item. For the installs the packet flags as end-of-life or end-of-service, no update is coming, and the packet's stated action is to discontinue use or transition to a supported version; for that population the 'verified mitigation' leg of this control is a dated transition or removal plan, and there is no patch task to track. Naming that split is the point of attaching this control here: a patch-compliance report that files the EoL/EoS installs under 'no update available' drops them out of the SLA permanently, and on an entry with confirmed in-the-wild exploitation that is exactly the population an attacker keeps.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-01-26, active_exploitation confirmed, poc_available true, rwep_score 77 against cvss 8.8. 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: 'Some of the impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-37079": {
     "name": "Broadcom VMware vCenter Server Out-of-bounds Write Vulnerability",
@@ -16646,7 +17019,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV clock on this entry opens 2026-01-22 against a mail server, and the scoping unit that matters is the endpoint, not the host count: every ZCS instance whose /h/rest endpoint answers remote callers is in the exploited population, which is why the ordinary multi-week application-patch cadence that mail platforms are usually audited under is the gap this entry demonstrates. The packet records a vendor patch, no live-patch tool, and a fix that typically requires a service restart or system reboot, so completion is per-instance and is only real once ZCS services come back on the fixed build — an update staged on a mailbox node that has not been restarted is still serving the vulnerable dispatch path. The SLA record for this entry should also capture the exposure window it closes, per instance, from the 2026-01-22 KEV listing to the completed restart, because that window is the input to the compromise-assessment decision the rebuild runbook depends on; an SLA that records only a completion date destroys the information needed to decide whether patching was sufficient.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-01-22, active_exploitation confirmed, poc_available true, rwep_score 77 against cvss 8.8. 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: crafted requests to the /h/rest endpoint 'influence internal request dispatching, allowing inclusion of arbitrary files from the WebRoot directory' (CWE-98). attack_vector: 'a PHP remote file inclusion flaw (CWE-98) on ZCS, enabling remote code execution on the mail server.'",
+        "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": "Zimbra ZCS sits on the internet mail boundary and the packet puts remote code execution on that server, so this entry belongs to the class this runbook exists for: the update repairs the request-dispatch defect but removes nothing that was placed on, or read from, the server through it beforehand, and patch-in-place closes the ticket over whatever is already resident. The default for an affected instance is therefore capture configuration and forensic evidence, rebuild from a known-good image onto the fixed build, and rotate the credentials and tokens the server held, rather than update-and-close. Two preconditions have to be stated or the runbook is mis-scoped. First, the trigger is exposure during the window between the 2026-01-22 KEV listing and the completed update, not the CVE in the abstract: where per-request logs covering that window exist and show no exploitation against the /h/rest path, patch-and-verify is the proportionate response — but where those logs were never collected, absence of alerts is not evidence of absence, and the instance belongs in the rebuild path rather than being cleared by default. Second, the packet does not state whether the /h/rest request path requires authentication, so exposure cannot be narrowed to unauthenticated reachability; an instance reachable only by authenticated users stays in scope until vendor detail settles that, and 'the endpoint is behind login' is not a basis for skipping the assessment.",
+        "evidence": "Packet: active_exploitation confirmed, cisa_kev true with kev_date 2026-01-22, poc_available true, rwep_score 77. Vector: 'remote attackers to craft requests to the /h/rest endpoint to influence internal request dispatching, allowing inclusion of arbitrary files from the WebRoot directory'. attack_vector: 'a PHP remote file inclusion flaw (CWE-98) on ZCS, enabling remote code execution on the mail server.' patch_available true, live_patch_available false. The packet does not state whether the /h/rest request path requires authentication. Citing gap on this entry: UK NCSC CAF B4 'System security'.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-34026": {
     "name": "Versa Concerto Improper Authentication Vulnerability",
@@ -18914,7 +19309,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "FortiWeb is a web application firewall — it sits on the trust boundary and is the thing other systems are protected by, which is the device class this control is written for. The packet's vector puts administrative command execution on the appliance in the hands of an unauthenticated attacker sending crafted HTTP or HTTPS requests, so the remediation clock has to run from the 2025-11-14 KEV listing, not from the next appliance maintenance window under a 14- or 30-day vulnerability-management SLA. Completion must be measured per unit by the firmware actually running after restart: the packet records patch_available true but live_patch_available false, with live_patch_notes stating no live-patch tool and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so a FortiWeb where the image is staged but the service has not been restarted is still running the vulnerable code and must be counted as exposed, not as remediated. The isolation half of this tier has a precondition that must be stated rather than assumed: restricting which networks can reach a unit's HTTP/HTTPS listeners bounds who can send the crafted request, but a FortiWeb deployed to front internet-facing applications has to keep HTTP/HTTPS reachable from untrusted clients to do its job, so for those units isolation is not available at all and only the restarted vendor update closes the path — those units must be sequenced first rather than treated as covered by a network control. Distinguishing test: on a staging FortiWeb, send crafted HTTP/HTTPS requests carrying relative-traversal sequences to the same listeners production units expose and confirm no administrative command runs; then report fleet remediation as the number of units whose running firmware is the fixed build post-restart. An attestation of 'critical patches applied within SLA' passes cleanly while an unauthenticated administrative-command path stays reachable for the whole SLA period.",
+        "evidence": "Packet fields for CVE-2025-64446 (Fortinet FortiWeb Path Traversal Vulnerability): cwe_refs CWE-23; vector 'Fortinet FortiWeb contains a relative path traversal vulnerability that may allow an unauthenticated attacker to execute administrative commands on the system via crafted HTTP or HTTPS requests'; cisa_kev true with kev_date 2025-11-14; active_exploitation confirmed; poc_available true; cvss 7.5; rwep_score 77; patch_available true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps recorded on this entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records active_exploitation as confirmed and poc_available as true for a path that needs no credentials and executes administrative commands on the FortiWeb itself, so for any unit whose HTTP/HTTPS listeners were reachable before the fixed firmware was running, the working assumption has to be that administrative commands may already have run — and installing the vendor update does not undo them. Applied to this appliance, the runbook default is to capture and examine the configuration off the box, rebuild onto the fixed firmware, and rotate every credential and certificate the unit held or could observe, rather than to record the upgrade as closure. Preconditions, stated plainly: this does not apply to units that were never reachable by an untrusted client during the exposure window, and rebuilding does not by itself remove anything — restoring the rebuilt unit's configuration from a backup taken during the exposure window reintroduces any administrative account, policy change or scheduled task an attacker created, so the restored configuration has to be diffed against a known-good baseline before it is loaded, and credential rotation has to extend to anything the appliance authenticated to, because rotation on the device alone leaves harvested secrets valid elsewhere. Distinguishing test: take a production FortiWeb and compare its current administrator list, and its configuration change record, against a baseline captured before the exposure window. If no such pre-exposure baseline exists, the organization cannot distinguish an untouched appliance from a modified one, and 'patched per SLA' is being recorded as remediation on faith — which is exactly what the patch-shaped framework controls cited against this entry accept as sufficient.",
+        "evidence": "Packet fields for CVE-2025-64446: active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-11-14; rwep_score 77; vector states an unauthenticated attacker may 'execute administrative commands on the system via crafted HTTP or HTTPS requests'; patch_available true and live_patch_available false, with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include AU-Essential-8-Patch, NIST-800-53-SI-2 and UK-CAF-B4.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-12480": {
     "name": "Gladinet Triofox Improper Access Control Vulnerability",
@@ -19448,7 +19868,32 @@
     },
     "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's vector has a malicious local actor with non-administrative privileges escalating to root on the same VM, through VMware Tools and Aria Operations rather than through anything the guest's own account model governs. For this entry the control means the fixed VMware Tools and Aria Operations builds are driven across every managed guest on the clock that opened with the 2025-10-30 KEV listing, and that completion is measured per guest by the VMware Tools build actually installed and the Aria Operations version actually running — not by 'update approved' or 'package pushed' in the management console, and not by a hypervisor-level rollup that reports host currency while guests lag. Because the packet records patch_available true, live_patch_available false, and live_patch_notes stating no live-patch tool with a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, a guest that has received the update but not restarted the affected components still carries the vulnerable path and has to be counted as exposed. The second half of the control is the load-bearing half here and is why NIST-800-53-AC-6 is cited as insufficient on this entry: the attacker is already a legitimate, non-administrative local user, so removing administrative rights from ordinary guest accounts — the thing a least-privilege attestation measures — does not stand between that account and root. Distinguishing test: on a staging guest running the same VMware Tools version, managed by Aria Operations with SDMP enabled, attempt the escalation from an ordinary non-administrative account and confirm root is not reached; then report fleet coverage as guests at the fixed build post-restart. A least-privilege attestation and a 'patch compliance' percentage both pass while this path stays open.",
+        "evidence": "Packet fields for CVE-2025-41244 (Broadcom VMware Aria Operations and VMware Tools Privilege Defined with Unsafe Actions Vulnerability): cwe_refs CWE-267; vector 'A malicious local actor with non-administrative privileges having access to a VM with VMware Tools installed and managed by Aria Operations with SDMP enabled may exploit this vulnerability to escalate privileges to root on the same VM'; cisa_kev true with kev_date 2025-10-30; active_exploitation confirmed; poc_available true; cvss 8.8; rwep_score 77; patch_available true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps recorded on this entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2 and NIST-800-53-AC-6.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "CWE-267 (privilege defined with unsafe actions) plus a vector in which a non-administrative local account reaches root on the same VM is this control's pattern: an operation that carries root authority inside the managed guest is reachable from an account that holds no administrative privilege, so the only thing standing between an ordinary guest user and root is the correctness of that privileged path. Bound to this product, the control means the privileged work that Aria Operations and VMware Tools perform inside a guest authorizes what it acts on for itself, at its own boundary, instead of inheriting trust from the fact that the request or the state originated inside the guest it manages — and that this property is verified on the managed-guest configuration the packet names, not assumed from the guest OS's account model. Preconditions, stated plainly: the vendor update is what repairs the boundary — this control states the property to verify, it does not implement it. Until that update is installed and the affected components restarted (the packet records no live-patch path and a restart-or-reboot requirement), the only operator-side lever is the exploit condition the packet itself names — a VM with VMware Tools installed, managed by Aria Operations, with SDMP enabled — so guests outside that configuration are not in the described condition, but where SDMP is operationally required nothing short of the update closes the path, and changing that setting does not evict an attacker who already reached root or remove what root access created on a guest that was in the vulnerable configuration during the exposure window (active_exploitation is confirmed and a PoC is public). Distinguishing test: enumerate which guests are managed with SDMP enabled and, on a staging guest matching that configuration, confirm a non-administrative local account cannot drive the privileged path to root — an attestation that no ordinary guest user holds administrative rights never tests this path.",
+        "evidence": "Packet fields for CVE-2025-41244: cwe_refs CWE-267 ('Privilege Defined with Unsafe Actions' per the entry name); vector names the exploit condition as a VM 'with VMware Tools installed and managed by Aria Operations with SDMP enabled' and the outcome as escalation 'to root on the same VM' by 'a malicious local actor with non-administrative privileges'; attack_vector adds that escalation flaws of this class form the second half of an intrusion chain; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-10-30; patch_available true; live_patch_available false with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include NIST-800-53-AC-6 and UK-CAF-B4.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-24893": {
     "name": "XWiki Platform Eval Injection Vulnerability",
@@ -19809,7 +20254,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "WSUS is the host the rest of the estate takes its updates from, so this entry inverts the usual remediation ordering: the clock that opened with the 2025-10-24 KEV listing has to be run on the update server itself ahead of the endpoints it serves, because an unauthenticated deserialization path to remote code execution on WSUS sits upstream of every patch decision those endpoints make. The packet records no live-patch path and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, so completion is measured by the WSUS host's state after that restart — a server that has installed the update and not restarted is still running the vulnerable service and must be counted as exposed, not as remediated. Because active exploitation is confirmed and a public PoC exists, an instance that stayed reachable through the window before that restart needs triage rather than a 'patched per SLA' verdict.",
+        "evidence": "Packet records CWE-502 deserialization of untrusted data in Windows Server Update Service (WSUS), reachable by an unauthenticated attacker for remote code execution; CVSS 9.8, RWEP 77, cisa_kev true with kev_date 2025-10-24, active_exploitation confirmed, poc_available true, 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.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The WSUS listener accepts content from a peer that never authenticates and hands it to a deserializer — the packet puts remote code execution ahead of any authentication decision — so that listener has to be treated as a trust boundary rather than as an internal convenience. For this deployment the requirement is that the WSUS service endpoints accept connections only from the managed clients and administrative hosts that legitimately speak to them, enforced by host firewall or network ACL rather than inherited from the assumption that WSUS sits on a trusted network, and that content arriving there is constrained to what the update protocol legitimately conveys instead of being permitted to construct arbitrary objects. The precondition has to be stated rather than implied: WSUS must remain reachable by every endpoint it services, so this narrows the caller set and cannot close the path for anything inside it — a compromised managed client, or any host that can place itself in that set, still reaches the deserializer. It bounds exposure during the remediation window and is not a substitute for taking the server through the update and its restart. This is also why the cited least-privilege gap is recorded here: the attacker never authenticates, so no account-privilege scoping is consulted on this path and an access-control attestation passes cleanly while it stays open.",
+        "evidence": "Packet records CWE-502, vector 'Microsoft Windows Server Update Service (WSUS) contains a deserialization of untrusted data vulnerability that allows for remote code execution', and an attack_vector stating the flaw is 'reachable by an unauthenticated attacker for remote code execution'. CVSS 9.8, RWEP 77, active_exploitation confirmed, poc_available true. Citing gaps include NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "Code execution on WSUS lands inside the software-distribution channel every managed endpoint already trusts, so the WSUS installation and the content it serves have to be governed as a privileged distribution channel rather than as application data: file-integrity-monitor the installation and the directories it serves artifacts from, alert on writes that do not correspond to a sanctioned administrator action or a vendor synchronization, and hold the server to KEV-priority patching as a management-plane asset in its own right rather than as one more Windows server in the general fleet. This is the half of the response that still has value after the vendor update lands, because the fix closes the deserialization sink but removes nothing an attacker wrote through it — and with exploitation confirmed from the 2025-10-24 listing, an instance that was reachable before remediation needs forensic triage rather than patch-and-close. The precondition: integrity monitoring detects, it does not prevent, and it is only meaningful where the baseline predates the exposure window. Where no pre-exposure baseline exists, the content the server distributes has to be re-established from vendor-sourced material instead of being trusted from the server's present state.",
+        "evidence": "Packet records active_exploitation confirmed with cisa_kev true and kev_date 2025-10-24, poc_available true, and an unauthenticated deserialization path (CWE-502) to remote code execution on the WSUS server. patch_available is true with live_patch_available false, so the deserialization sink is closed only once the vendor update and its restart are taken. NIS2-Art21-supply-chain (Supply chain security measures) is recorded as a citing gap for this entry.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain"
+        ]
+      }
+    ]
   },
   "CVE-2025-61932": {
     "name": "Motex LANSCOPE Endpoint Manager Improper Verification of Source of a Communication Channel Vulnerability",
@@ -19869,7 +20346,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "LANSCOPE Endpoint Manager is the device-management platform itself, and CWE-940 places the defect precisely at the trust decision: the receiving component decides whether to act on a packet by judging where it appears to have come from rather than by verifying who sent it, so an unauthenticated attacker's crafted packets are processed as trusted commands and reach arbitrary code execution. Applied to this product, the control means every service on the LANSCOPE management agent and server that accepts commands authenticates its caller cryptographically before the command is parsed or executed — a verdict that cannot be satisfied by source address, network position, or any other property the sender controls — and that those listening services are not reachable from networks with no managed endpoints on them. The precondition on the network half has to be stated rather than left implied: managed endpoints must be able to reach the management server for the product to function, so restricting reachability shrinks the population that can send crafted packets to hosts inside the managed network but does not close the path — any compromised workstation in that population still has it, and for a deployment where agents span the whole estate the reduction is small. Closure is the vendor update, and the packet records no live-patch tool with a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, so a server or agent that has taken the update without restarting is not remediated. Distinguishing test: on a staging LANSCOPE instance, send crafted command packets from an unauthenticated host and confirm refusal before execution — then repeat from a host inside the managed address range and confirm the command is still refused. If the second attempt succeeds, the product is still authenticating the channel rather than the caller, which is the defect itself; the least-privilege control cited against this entry is never consulted on this path because the attacker holds no LANSCOPE account to scope.",
+        "evidence": "Packet fields for CVE-2025-61932 (Motex LANSCOPE Endpoint Manager Improper Verification of Source of a Communication Channel Vulnerability): cwe_refs CWE-940; vector 'Motex LANSCOPE Endpoint Manager contains an improper verification of source of a communication channel vulnerability allowing an attacker to execute arbitrary code by sending specially crafted packets'; attack_vector describes an unauthenticated attacker sending trusted commands to the management agent/server for remote code execution; cisa_kev true with kev_date 2025-10-22; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 77; patch_available true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps recorded on this entry include NIST-800-53-AC-6, UK-CAF-B4 and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The packet puts arbitrary code execution on the LANSCOPE management agent and server — the component that holds the management relationship with the endpoints it administers — and records active_exploitation as confirmed with a public PoC. That makes the installation and, wherever the deployment uses it to distribute software or run commands on managed endpoints, the content it hands to its agents a privileged distribution channel rather than ordinary application data. Bound to this product, the control means file-integrity monitoring across the LANSCOPE installation and the directories it serves content from, with alerts on any write that does not correspond to a sanctioned administrator action or a vendor update, and holding the LANSCOPE server to KEV-priority patching as a management-plane asset in its own right. This is the control that retains value after the vendor update lands, which is why the update-shaped framework controls cited on this entry are insufficient on their own: the fix closes the path by which crafted packets became trusted commands, but it removes nothing that was already written or already executed through that path, and an artifact placed on the server before remediation survives the upgrade and keeps whatever reach the server has. Preconditions: monitoring neither prevents exploitation nor reconstructs the period before it was enabled — a monitor stood up after the exposure window has no baseline for what changed during it, so the comparison must be made against a record captured before that window or against vendor-shipped file state, and where neither exists the honest verdict is that server integrity is unestablished rather than clean. Distinguishing test: enumerate the content the LANSCOPE server would currently distribute or execute and reconcile it item by item against the change record of sanctioned administrator actions since before the exposure window; unreconciled items are the finding. An attestation that the LANSCOPE server is running the fixed build passes cleanly while a payload placed pre-update continues to reach managed endpoints.",
+        "evidence": "Packet fields for CVE-2025-61932: attack_vector describes an unauthenticated attacker sending trusted commands to the LANSCOPE 'management agent/server' for remote code execution; vector confirms arbitrary code execution via specially crafted packets; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-10-22; cvss 9.8; rwep_score 77; patch_available true; live_patch_available false, with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2022-48503": {
     "name": "Apple Multiple Products Unspecified Vulnerability",
@@ -20355,7 +20856,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's chain runs entirely below the operating system: igel-flash-driver mis-verifies the image signature, so a crafted root filesystem mounts from an unverified SquashFS image and the device runs an attacker's OS. Nothing inside the booted session can detect or contain that, so the vendor update is the only closure, driven across every IGEL OS endpoint on the clock that opened with the 2025-10-14 KEV listing rather than folded into the next scheduled image-refresh cycle. Completion must be measured by the build each device actually booted, not by 'update assigned' or 'update downloaded' in the management console: the packet records a vendor patch with no live-patch path and a fix that requires a service restart or system reboot, so a device that has taken the update but not rebooted is still running an image the unfixed verification path admitted and has to be counted as exposed, not remediated. Scope this to IGEL OS, which is the product the packet names; it gives no mapping from igel-flash-driver into any other boot chain.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-10-14, active_exploitation confirmed, poc_available true, RWEP 77 against CVSS 8.8. 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: 'IGEL OS contains a use of a key past its expiration date vulnerability that allows for Secure Boot bypass. The igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image.' (CWE-324).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The mechanism that failed on this entry is boot-image signature verification itself: per the packet igel-flash-driver accepts a signature made with a key past its expiration date, so Secure Boot reports enforcement while an unverified SquashFS root filesystem mounts. A version-number attestation cannot separate 'verification restored' from 'verification still failing open', because the version string is exactly what the mechanism was already reporting while it admitted the image. For this CVE the control means the boot-verification path is re-tested as a class on every IGEL OS image deployment, keyed on the behaviour the packet documents: on a staging device, present the boot chain with a modified or unverified SquashFS root filesystem image and confirm it refuses to mount it — and keep that test in the battery for subsequent images instead of retiring it once this CVE is closed, since the defect is in the check rather than in one image. Precondition: the test needs a staging device the operator can attempt an unverified boot on and a way to observe the refusal. Where that does not exist the mechanism's state is unverified, and the device must be treated as exposed until it boots a build the vendor names as fixed rather than passing because a scanner read the version.",
+        "evidence": "Packet vector: 'The igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image', classed CWE-324 (use of a key past its expiration date) and described in the attack vector as a Secure Boot / boot-trust bypass letting an attacker boot a modified or unverified OS image. cisa_kev true with kev_date 2025-10-14, active_exploitation confirmed and poc_available true, so the failing check is being exercised rather than theoretical. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-24990": {
     "name": "Microsoft Windows Untrusted Pointer Dereference Vulnerability",
@@ -20632,7 +21157,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This flaw lets an unauthenticated attacker read arbitrary local files on the Grafana host, including its own configuration and secrets, so time on the vulnerable build is continuing disclosure rather than only continuing risk — which is what distinguishes it from the ordinary patch-cadence item the cited controls treat it as. Run the clock from the 2025-10-09 KEV listing rather than the next maintenance window, and define 'mitigated' for this product as the Grafana service restarted onto the fixed build: the packet records a vendor patch with no live-patch path and a restart-or-reboot requirement, so an instance whose package was replaced but whose process was never restarted has not met the SLA no matter what the change record says. Where the restart genuinely cannot be taken inside the window, the documented compensating control this SLA permits is removing untrusted reachability to the instance for the duration — and that substitution carries two conditions that must be stated rather than assumed. It holds only where the instance's exposure is actually controllable at the network boundary, which is not true of a Grafana deployment published for external users; and it does nothing about files already read, so any credential, datasource secret or key material readable through this flaw during the exposure window must be treated as disclosed and rotated, since patching closes the read path but does not revoke what the path already returned.",
+        "evidence": "Packet records a path-traversal flaw (CWE-22) letting an unauthenticated attacker read arbitrary files including configuration and secrets; product described as Grafana with a path traversal vulnerability allowing access to local files. CISA KEV-listed 2025-10-09 with active_exploitation 'confirmed'; poc_available true; RWEP 77, CVSS 7.5. patch_available true, live_patch_available false, and the live-patch note states the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance failure for this CVE is specific and mechanical: the packet records a fix with no live-patch path that requires a service restart, so a scanner reading the installed Grafana package version reports the instance remediated while the process still listening continues to serve the vulnerable traversal handler from the code it loaded at start. The distinguishing test is to exercise the flaw against the running instance rather than compare version strings — issue a traversal request that attempts to reach a local file outside the served root and confirm the listening process refuses it — and to cross-check that the process start time is later than the update. This matters more than usual on Grafana because the asset being read is the instance's own configuration and secrets: a version-only inventory cannot separate an instance that restarted from one that did not, so the vulnerability-management attestation passes for hosts that are still disclosing credentials to any unauthenticated caller.",
+        "evidence": "Packet records patch_available true, live_patch_available false, and a live-patch note stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction; the flaw is a CWE-22 path traversal permitting an unauthenticated attacker to read arbitrary local files including configuration and secrets. CISA KEV-listed 2025-10-09, active_exploitation 'confirmed', poc_available true, RWEP 77, CVSS 7.5.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-27915": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Cross-site Scripting Vulnerability (variant: CVE-2025-27915)",
@@ -21371,7 +21921,33 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this out-of-bounds write inside Samsung's image-parsing library libimagecodec.quram.so and describes zero-click code execution from a malicious image forming the initial-access half of a mobile-spyware chain, so no user decision and no application-privilege boundary stands between delivery and the vulnerable parser — the reboot-gated firmware update is the only real fix and it is not fast enough on its own for the population this class targets. For the plausibly targeted cohort — executives, journalists, legal and security staff — place devices in a reduced-attack-surface posture that stops untrusted images, message attachments and link previews from being fetched and rendered automatically, narrowing the delivery path into the CWE-787 write during the window between the 2025-10-02 KEV listing and completed fleet restart. This is also the only substitute available for the least-privilege control cited against this entry, which never engages on this path: the write happens inside the platform codec before any account or app privilege decision is consulted, so scoping privilege leaves the flaw fully reachable and constraining what content reaches the codec is the remaining lever. Three preconditions must be stated rather than assumed. The posture only helps if it was already standing for that cohort before the disclosure, since it does nothing if switched on after the image arrived. It narrows the messaging delivery path but does not remove the parser surface — any application that fetches and renders an image still reaches the same codec — so it is a narrowing measure, not elimination. And it does not evict an attacker already resident: a cohort device that was reachable during the exposure window needs forensic triage and credential revocation, not a settings change.",
+        "evidence": "Packet records an out-of-bounds write (CWE-787) in libimagecodec.quram.so on Samsung mobile devices, allowing remote attackers to execute arbitrary code, exploitable by a malicious image for zero-click code execution on the device, and characterizes the class as the initial-access half of a mobile-spyware chain. CISA KEV-listed 2025-10-02 with active_exploitation 'confirmed'; poc_available true; RWEP 77, CVSS 9.8. patch_available true, live_patch_available false, and the live-patch note states the vendor patch typically requires service restart or system reboot per the KEV requiredAction. NIST-800-53-AC-6 (Least Privilege) is recorded among the framework controls citing this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Treat the Samsung firmware build that carries this codec fix as a condition of access to organizational data rather than a figure on a patch-compliance report: a handset below it is denied or quarantined from mail, VPN and documents. The packet gives no live-patch path and a fix requiring a restart or reboot, which makes the restart the completion criterion — a handset that has downloaded the firmware but not restarted still loads the vulnerable libimagecodec.quram.so and must be counted exposed rather than remediated. One half of this control's usual shape does not carry on this path and should not be recorded as though it does: because the trigger is a zero-click malicious image rather than a malicious installed application, restricting side-loaded or untrusted app installs does not reduce reachability here, so the levers are the build and the content path only. Preconditions: the gate is meaningful only where Samsung has published a build carrying the fix for that exact model and the device is enrolled in management; until such a build exists the correct state is quarantine, and any unenrolled or BYOD population is outside the control entirely and has to be denied access to organizational data rather than assumed compliant. Distinguishing test: enrol a handset pinned below the fixed build and confirm access to protected resources is actually refused — an estate that surfaces the stale build on a dashboard while the device keeps its mail and VPN has recorded the exposure, not removed it.",
+        "evidence": "Packet records an out-of-bounds write (CWE-787) in libimagecodec.quram.so on Samsung mobile devices allowing remote attackers to execute arbitrary code, exploitable by a malicious image for zero-click code execution. CISA KEV-listed 2025-10-02, active_exploitation 'confirmed', poc_available true, RWEP 77, CVSS 9.8. patch_available true, live_patch_available false, and the live-patch note states the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-4008": {
     "name": "Smartbedded Meteobridge Command Injection Vulnerability",
@@ -21675,7 +22251,39 @@
     },
     "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 packet puts the sink in the GoAnywhere MFT license servlet and names the entry condition as a validly forged license response signature: the product's trust decision is that a signature-checked license response is safe to deserialize into an arbitrary actor-controlled object, and from there CWE-502 becomes the CWE-77 command injection the packet records. For this product the control means the license servlet is treated as an unauthenticated trust boundary rather than a vendor-to-product internal convenience. Two requirements follow. First, the servlet must constrain what an arriving license response is permitted to construct or evaluate — an allowlist of the concrete types the licensing flow legitimately carries — instead of inheriting safety from the signature check, which is precisely the check the packet says the actor forges. Second, the servlet path must answer only from the management segment rather than from arbitrary internet callers. Distinguishing test: against a staging instance, submit to the license servlet a response object of a type the licensing flow never legitimately conveys and confirm it is refused before any object is constructed — an instance that passes a patch-level audit while the servlet answers unauthenticated internet callers still carries the deserialization path the moment the next parsing defect lands. Precondition: the reachability half holds only where the deployment can separate the licensing and administrative surface from the partner-facing file-transfer listeners. Where partners and the servlet share one exposed surface, segmentation buys nothing and the vendor update is the only remediation — and the packet records that update as requiring a service restart or system reboot with no live-patch path, so an instance updated but not restarted is not yet remediated. Second precondition: on an instance that was internet-reachable on a vulnerable build this control does not remove what an operator with command execution already placed there; that is a separate disposition, not something the hardening covers.",
+        "evidence": "Packet fields for this entry: attack_vector records \"a deserialization-of-untrusted-data flaw (CWE-502/CWE-77) in the GoAnywhere MFT license servlet, enabling unauthenticated remote code execution on the managed-file-transfer server\"; the vector records \"an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object, possibly leading to command injection\". cwe_refs CWE-502 and CWE-77. cisa_kev true, kev_date 2025-09-29, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 83. 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.\" UK-CAF-B4 (System security) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records this entry as mass-exploited in data-theft extortion campaigns with confirmed in-the-wild exploitation, and the flaw yields unauthenticated command execution on the managed-file-transfer server itself — the host that holds and moves the organisation's files. Applying the Fortra update closes the deserialization path and says nothing about what ran on the box while it was open. Applied to this product: any GoAnywhere MFT instance that was reachable from an untrusted network on a vulnerable build is dispositioned as compromised regardless of what a post-update version check reports. Capture and diff the running configuration and the directories the service serves content from against known-good, rebuild from vendor media at the fixed version rather than updating in place, and rotate what the server held — the MFT service and administrative account credentials, the trading-partner keys and passwords it authenticated with, and any TLS private key stored on it. Then review which transferred files were exposed, because the campaign class the packet names is data-theft extortion: the files are the objective, not a side effect, and no amount of post-hoc patching un-exfiltrates them. The behaviour to hunt for is the one the packet's own chain produces — the MFT service process spawning a shell or interpreter child, which is what a deserialization sink reaching a command-injection sink looks like at execution time — rather than a generic malware signature, which is exactly what the anti-malware control this entry cites does not reliably produce for an in-process injection chain. Precondition: this disposition applies to instances whose exposure during the vulnerable window cannot be excluded; an instance that provably never answered an untrusted network on a vulnerable build takes the vendor update on the KEV clock instead. Rebuilding is not relief from the update — the rebuilt instance must come up on the fixed version, with the service restart or reboot the packet records as required.",
+        "evidence": "Packet fields for this entry: attack_vector records \"unauthenticated remote code execution on the managed-file-transfer server (mass-exploited in data-theft extortion campaigns)\" arising from the CWE-502/CWE-77 flaw in the GoAnywhere MFT license servlet. cisa_kev true, kev_date 2025-09-29, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 83. 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.\" CIS-Controls-v8-10.1 (Deploy and Maintain Anti-Malware Software) and NIS2-Art21-vulnerability-handling (Cybersecurity risk-management measures (vulnerability handling and disclosure)) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "CIS-Controls-v8-10.1",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the control's \"KEV listing or patch availability, whichever is later\" clause sets a clock the operator can actually run: the packet records patch_available true and a KEV listing dated 2025-09-29, and the flaw is a pre-authentication path to command execution on an internet-facing managed-file-transfer server at CVSS 9.8 and RWEP 83 that is already mass-exploited. A month-scale critical-patch window is exploitation acceptance against that profile, and an operating-system patch programme never reaches this server's application build at all — the vulnerable code is the GoAnywhere license servlet, not the host OS, so an estate can be fully current on OS updates while every MFT instance stays open. Applied here, the SLA governs the GoAnywhere application build specifically, and completion is measured by each instance reporting the fixed version after it has been restarted, not by \"update downloaded\" or \"change request raised\": the packet registers no live-patch path and states the vendor patch requires a service restart or system reboot, so the restart sits inside the clock rather than after it. Precondition for anything done inside the open window: narrowing who can reach the license servlet reduces exposure but does not remediate the entry, and it must be recorded as an interim compensating measure with the update date attached, not as satisfaction of the SLA. An instance that cannot be restarted inside the window is a named, dated exception carrying that restriction, not a silently open item.",
+        "evidence": "Packet fields for this entry: \"Fortra GoAnywhere MFT contains a deserialization of untrusted data vulnerability allows an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object, possibly leading to command injection\"; attack_vector adds \"unauthenticated remote code execution on the managed-file-transfer server (mass-exploited in data-theft extortion campaigns)\". cisa_kev true, kev_date 2025-09-29, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 83. patch_available true, live_patch_available false, live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" AU-Essential-8-Patch (Patch operating systems) and NIST-800-53-SI-2 (Flaw Remediation) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-20352": {
     "name": "Cisco IOS and IOS XE Software SNMP Denial of Service and Remote Code Execution Vulnerability",
@@ -21818,7 +22426,29 @@
     },
     "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": "Adminer is a database-administration front end and the packet's path needs no credential at all: an unauthenticated caller coerces the instance into issuing requests to internal resources, so the exposed asset is the whole set of destinations the hosting web server can reach from where it sits, including the database hosts the tool exists to talk to. The KEV listing here dates from 2025-09-29 for a defect published years earlier, so the work item never arrives through new-CVE inflow — it arrives only if the vulnerability-management program re-scans the deployed estate against the KEV catalogue on a schedule. Applied to this product the SLA needs an explicit completion definition, because the packet records patch_available true, live_patch_available false, and a fix that typically requires a service restart or reboot per the KEV requiredAction: remediation is the replaced Adminer build plus the restart of the process serving it, not an entry in a package inventory. The enumeration step is what a generic patch SLA misses on this product class — every deployed copy has to be located, including copies dropped under a web root by hand and copies baked into an application or container image, because a copy no package manager owns is a copy no patch cycle will ever update, and one forgotten instance is sufficient to keep the primitive live.",
+        "evidence": "Packet vector: 'Adminer contains a server-side request forgery vulnerability that, when exploited, allows a remote attacker to obtain potentially sensitive information.' attack_vector: a server-side request forgery flaw (CWE-918) 'letting an unauthenticated attacker coerce the server into making requests to internal resources'. CVSS 7.5, RWEP 77, poc_available true, CISA KEV-listed 2025-09-29 with active_exploitation confirmed. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The lever operators actually reach for first on this flaw is not the build — it is reachability and egress, because the packet's primitive is the server issuing requests on the attacker's behalf, so restricting who can reach the instance or what the web host may connect outbound to blunts the impact immediately. That response puts the entry in this control's state (b): a compensating control is active while the vulnerable code is still deployed, and it must be recorded as that distinct state with a dated action item to take the vendor build and the service restart the packet says it needs, not rolled into a patched-per-SLA count. The precondition is the whole point and has to be written down next to the mitigation: a network or egress restriction bounds the SSRF only for as long as the specific route it blocks stays blocked, so a new internal service, a security-group or routing change, a move of the host into a segment with broader reach, or simply a valuable destination inside the still-permitted set reopens the identical primitive with no change to the application and no alert. It also does nothing for an attacker who can still reach the instance and probe whatever remains permitted, and nothing about information already retrieved before the restriction went in — so an instance that was reachable while the PoC the packet records was public warrants a review of what it could have reached during that window, not only a forward-looking block. Where the restriction cannot be verified route by route, the entry stays in state (c) and should be reported as full exposure.",
+        "evidence": "Packet: CWE-918 server-side request forgery in Adminer; attack_vector states an unauthenticated attacker coerces the server into making requests to internal resources, and the vector states the result is disclosure of potentially sensitive information. poc_available true, CISA KEV-listed 2025-09-29, active_exploitation confirmed, RWEP 77, CVSS 7.5. 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 — so the interval between mitigation and remediation is real and has to be tracked.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-20362": {
     "name": "Cisco Secure Firewall Adaptive Security (ASA) Appliance and Secure Firewall Threat Defense (FTD) Missing Authorization Vulnerability",
@@ -21878,7 +22508,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The affected component per the packet is the VPN web server on Cisco Secure Firewall ASA and Secure Firewall Threat Defense — the device is the perimeter trust boundary, so a missing-authorization flaw letting an unauthenticated caller reach restricted URL endpoints cannot sit in an ordinary appliance-maintenance window. A 14- or 30-day remediation SLA applied here is being applied to the thing that enforces the boundary. For this CVE the tier means the fixed release is driven onto every ASA and FTD unit whose VPN web server is reachable, on a clock that opened with the 2025-09-25 KEV listing, or the VPN web-services interface is withdrawn from untrusted reachability until it is. The packet records a vendor patch with no live-patch path and a service-restart-or-reboot requirement, so the clock does not stop at 'image loaded' — it stops when the unit has reloaded onto the fixed release, because a unit staged but not reloaded still serves the vulnerable path. Precondition on the interim half: restricting reachability bounds exposure only where the VPN web server can actually be withdrawn from the untrusted side. A unit that must keep terminating remote-access VPN from the internet cannot use that lever at all and has only the expedited reload, and pairing it with a reachability restriction it cannot apply would record a mitigation it does not have.",
+        "evidence": "Packet: 'Cisco Secure Firewall Adaptive Security (ASA) Appliance and Secure Firewall Threat Defense (FTD) Software VPN Web Server contain a missing authorization vulnerability. This vulnerability could be chained with CVE-2025-20333.' Attack vector: a missing-authorization flaw (CWE-862) allowing an unauthenticated attacker to reach restricted URL endpoints. cisa_kev true, kev_date 2025-09-25, active_exploitation confirmed, poc_available true, RWEP 77 against CVSS 8.8. patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records confirmed in-the-wild exploitation from the 2025-09-25 KEV listing and states the flaw could be chained with CVE-2025-20333, so for any ASA or FTD unit whose VPN web server was reachable during that window the operative question is not whether it now runs the fixed release but whether it was already reached. Upgrading closes the missing-authorization path; the packet gives no basis for treating the upgrade as removing anything an attacker may have left on the box beforehand. The control means those units default to the compromise path rather than the patch path: capture the running and startup configuration and diff it against a known-good baseline before touching the unit, rebuild from vendor image instead of upgrading in place, and rotate every credential and key the device held or terminated — device administrative accounts, remote-access VPN credentials, and any shared secret configured on it. Precondition, and it decides which units this applies to: the default is for units whose VPN web server was actually reachable from an untrusted network during the exposure window. A unit that was never so exposed can take the ordinary expedited upgrade, but that determination has to come from configuration and network evidence rather than from assumption — an untested assumption of non-reachability is how a compromised unit gets upgraded in place and returned to service.",
+        "evidence": "Packet: active_exploitation confirmed with cisa_kev true and kev_date 2025-09-25, poc_available true. Vector: 'Cisco Secure Firewall Adaptive Security (ASA) Appliance and Secure Firewall Threat Defense (FTD) Software VPN Web Server contain a missing authorization vulnerability. This vulnerability could be chained with CVE-2025-20333.' patch_available true, live_patch_available false. The packet establishes that the update closes the flaw; it records nothing indicating the update remediates a unit already reached through it.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "Because the packet's path is an unauthenticated caller reaching restricted URL endpoints on the ASA/FTD VPN web server, the signal that a unit was touched is a web-services request to a restricted VPN web-server path with no successful prior authentication on that session — the exact behaviour the packet documents, and something an exploit doing only what the packet describes necessarily emits at the web-services layer. That record lives on the device an attacker reaching those endpoints is in a position to alter, so ASA/FTD web-services, syslog and authentication records must be forwarded as they are produced to a collector in a separate trust zone, with different credentials and a different management path from the firewall itself. Precondition, and the reason this is a standing posture rather than an incident action: forwarding only produces evidence for the period it was already running. A unit that logged locally through the window opened by the 2025-09-25 KEV listing cannot have its history reconstructed afterwards, and for that unit the compromise-assumption path is the answer instead of a log review. Forwarding also prevents nothing — it makes the access visible and makes the record survive the device; it is not a substitute for the reload onto the fixed release.",
+        "evidence": "Packet attack vector: a missing-authorization flaw (CWE-862) allowing an unauthenticated attacker to reach restricted URL endpoints on the ASA web-services chain, chainable with CVE-2025-20333 per the vector text. cisa_kev true, kev_date 2025-09-25, active_exploitation confirmed, poc_available true. patch_available true with live_patch_available false and a restart-or-reboot requirement, so units carry the exposure until they reload.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-20333": {
     "name": "Cisco Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD) Buffer Overflow Vulnerability",
@@ -23161,7 +23825,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The vulnerable component is the browser itself and the delivery is an attacker-controlled web page — the packet describes the SetMouseCapture flaw used in watering-hole attacks, so the victim reaches the CWE-399 use-after-free by visiting a site: there is no attachment to strip, no file to inspect, and no user action to train against beyond browsing. Applied to this CVE the control means Internet Explorer's servicing is driven on its own accelerated channel rather than deferred into an enterprise update ring or folded into a monthly workstation rollup, and that completion is measured per host against the installed build rather than by 'update approved' in the management console. The packet records a vendor patch, no live-patch path, and a fix that requires a service restart or system reboot, so a host that has taken the update but has not restarted is still running the vulnerable renderer and must be counted as exposed rather than remediated. Precondition: an update-ring policy only reaches copies a managed channel can see and drive. The packet notes the impacted products could be end-of-life or end-of-service, so part of the exposed population sits outside managed servicing entirely; for those hosts the policy changes nothing and the exposure is closed only by applying the update by hand or by taking the product out of use, per the packet's own instruction that users should discontinue product utilization. Recording such a host as covered because a ring policy exists leaves it fully exploitable. The distinguishing test: take a host the update-ring report shows as compliant and read its installed Internet Explorer build and its last restart time — a fleet reporting 100% approved while hosts sit un-restarted has measured the console's state, not the renderer's.",
+        "evidence": "Packet: CWE-399 resource-management memory-corruption use-after-free in Internet Explorer, recorded as the SetMouseCapture flaw used in watering-hole attacks and exploitable by an attacker-controlled web page for code execution in the browser. CISA KEV-listed 2025-08-12 with active_exploitation confirmed and poc_available true; RWEP 77 against CVSS 9.8. 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 packet also records that the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization.",
+        "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": "The KEV listing on this entry is dated 2025-08-12 against a CVE assigned in 2013, and that mismatch is the operative problem for a vulnerability-management program. Nothing here is newly disclosed, no advisory feed re-publishes it, and a program that opens work items from disclosure feeds — or that triages by CVE age — creates no ticket at all, while the packet records exploitation as confirmed now and a PoC as available. Applied to this CVE the control means the KEV listing date starts the remediation clock independently of the CVE's age: the estate is re-queried in 2025 for Internet Explorer installs still on a pre-fix build, rather than consulted for a 2013 remediation record asserting the flaw was closed against the estate that existed then. The verified-mitigation state the SLA demands is per-host — the packet gives a vendor patch, no live-patch path, and a restart-or-reboot requirement, so 'fixed build installed and the host restarted' is the only state that counts, not 'the bulletin was deployed'. Precondition: the clock is only meetable against hosts the estate can still enumerate and service. The packet's note that impacted products could be end-of-life or end-of-service means some of the exposed population has no patch pipeline pointed at it; for that population the SLA is satisfied by removing the exposure on a dated schedule, and carrying an unreachable host as perpetually 'pending' converts the clock into a record of the omission. The distinguishing test: query the vulnerability-management system for an open item on this CVE carrying a due date derived from 2025-08-12 — a program whose only record is a closed 2013 ticket has no active work item while KEV states the flaw is being exploited today.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-08-12 on CVE-2013-3893, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 9.8. attack_vector records that the legacy re-listing exists because long-tail unpatched/end-of-life estates remain exposed. 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. Citing framework gaps include EU NIS2 vulnerability handling and NIST SP 800-53 SI-2 Flaw Remediation.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2020-25078": {
     "name": "D-Link DCS-2530L and DCS-2670L Devices Unspecified Vulnerability",
@@ -23364,7 +24051,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-132",
+        "name": "INDEPENDENT-INTEGRITY-VERIFICATION-OF-SIGNED-VENDOR-INSTALLERS",
+        "description": "The DNR-322L accepts and runs code it downloads without checking its integrity (CWE-494), so nothing on the device distinguishes a genuine D-Link image from one an attacker substitutes — the packet's path is precisely that: an attacker supplies a malicious update and obtains OS-level command execution on the device. Applied to this product the control means the operator, not the device, makes the integrity decision: obtain the DNR-322L firmware through a controlled path, verify it against a vendor-published integrity value obtained over a channel separate from the download itself, and load the verified image deliberately rather than letting the device pull and run whatever an update endpoint offers it. This is the harder form of the control's premise — the original case was a client trusting a signature it should not have, whereas this device performs no verification step at all, so an out-of-band check is the only thing standing between a substituted image and code execution on the box. Precondition, and it is load-bearing: operator-side verification governs only the images the operator supplies. The packet places the attack behind device authentication, so an attacker holding or obtaining a DNR-322L credential feeds the device an image directly, and no verification discipline applied to the operator's own images intercepts that path. Bounding who can authenticate to the device's management surface is the other half of the control, and it is not substituted for by loading a verified image. The distinguishing test: for the image you are about to load, confirm you can match it to a vendor-published integrity value obtained independently of the file you downloaded — the fact that the device accepted the image tells you nothing, because it accepts unverified code by construction.",
+        "evidence": "Packet: CWE-494, download of code without an integrity check, on the D-Link DNR-322L. vector states an authenticated attacker could execute OS-level commands on the device; attack_vector states an attacker can supply a malicious update for code execution. CISA KEV-listed 2025-08-05 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Two things separate the KEV clock on this entry from an ordinary server patch item. First, the DNR-322L is not reached by the estate's operating-system patching program — the cited Essential Eight 'patch operating systems' control is measured against machines carrying a patch agent, and this device carries none, so the 2025-08-05 listing produces no work item at all unless the SLA is written against the named asset rather than against the pipeline that happens to cover it. Second, the remediation action itself travels the vulnerable path: the defect is in how the device ingests code, so every image the device takes — the remediation image included — is accepted without an integrity check. Meeting the clock therefore means loading an image the operator has verified out of band and then confirming the unit came back on the fixed version; the packet records a vendor patch, no live-patch path, and a fix requiring a service restart or system reboot, so a device handed the image but not restarted onto it is not yet remediated. Precondition: this is only actionable for units the operator can physically or administratively reach and re-verify. The packet notes the impacted products could be end-of-life or end-of-service, so where no reachable fixed image exists the clock is closed by removing the unit from service on a dated schedule, not by carrying it indefinitely as pending. The distinguishing test: pull the KEV-derived due date for this CVE and ask which named DNR-322L units it is tracked against — an SLA reporting 'no affected assets' because the patch console cannot see the device has measured the console, not the estate.",
+        "evidence": "Packet: CISA KEV-listed 2025-08-05 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8; CWE-494 with attack_vector recording that an attacker can supply a malicious update for code execution. Citing framework gaps include ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8 and EU NIS2 vulnerability handling. 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 packet also records that the impacted products could be end-of-life and/or end-of-service.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-2533": {
     "name": "PaperCut NG/MF Cross-Site Request Forgery (CSRF) Vulnerability",
@@ -23840,7 +24550,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet states this ANGLE/GPU flaw affects multiple browsers that use Chromium — Chrome, Edge and Opera are named and the list is explicitly not exhaustive — so the ring that matters is the union of every Chromium-derived browser on the estate, not the single browser the organization treats as standard. Holding the security channel for a validation week here means holding a fix for a bug being exploited in the wild through a crafted web page: the delivery is a page visit, so there is no attachment to strip, no macro to block and no user action to police between the page and the GPU process. Applied here the control also has to count remediation at the right moment — the packet records no live-patch path and a fix that takes effect only after a restart, so a device that has downloaded the update but has not relaunched the browser is still running the vulnerable ANGLE and GPU-process code, and an update dashboard that counts 'version downloaded' overstates coverage. Precondition and limit: fast updating closes the entry path, it does not evict an attacker who already landed. Because exploitation is confirmed, a device that browsed while unpatched needs triage on its own merits — updating a compromised host removes the bug, not the implant. Second-string Chromium builds that no enterprise update policy governs (kiosk browsers, embedded webviews, developer channels, bundled runtimes) have to be enumerated and either brought under the same ring or removed; where such a build has no managed update channel at all, the no-deferral rule cannot be applied to it and removal is the only honest disposition.",
+        "evidence": "Packet vector, verbatim: 'Google Chromium contains an improper input validation vulnerability in ANGLE and GPU. This vulnerability could allow a remote attacker to potentially perform a sandbox escape via a crafted HTML page. This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera.' CISA KEV-listed 2025-07-22 (kev_date) with active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, and live_patch_notes records no registered live-patch tool with the vendor patch typically requiring a service restart or system reboot per the KEV requiredAction — the basis for counting remediation at relaunch rather than at download. Citing gaps include ASD Essential Eight 'User application hardening' and NIST 800-53 SI-2, both of which an estate can attest to while its update ring still defers the security channel and while non-standard Chromium builds sit outside the policy.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE the paper-compliance failure takes two distinct shapes and a version-based scan catches neither. Coverage first: the packet says the defect affects browsers that utilize Chromium including but not limited to Chrome, Edge and Opera, so a scan scoped to the organization's standard browser reports the estate clean while Edge and Opera installs, embedded Chromium webviews and bundled runtimes still carry the vulnerable ANGLE/GPU code. State second: the packet records no live-patch path and a fix that takes effect after a restart, so the version on disk can be the fixed one while the still-running browser process — the one hosting the GPU process a crafted page reaches — is the old build. The operational test: on a sample of workstations, enumerate every Chromium-derived binary present rather than only the managed browser, and compare the version of the running process against the version installed on disk; a scanner that declares the estate remediated without answering both questions has produced a compliance artifact, not a statement about whether a crafted page can still reach the sandbox-escape path. Precondition: where the scanner cannot read running-process versions, the substitute is a forced relaunch or reboot campaign with per-device confirmation, and until that confirmation exists the estate's status is unknown rather than remediated — treating 'update deployed' as the completion signal is the exact assumption this test exists to break.",
+        "evidence": "Packet vector states the improper input validation is in ANGLE and GPU and that it 'could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera'; attack_vector describes an attacker-controlled web page escaping the browser sandbox (CWE-20). CISA KEV-listed 2025-07-22, active_exploitation confirmed, poc_available true, rwep_score 77. 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 — the basis for distinguishing the installed build from the running one. ISO 27001 A.8.8, NIST 800-53 SI-2 and UK CAF B4 are the cited gaps; each is routinely evidenced with precisely the version-based scan report this test invalidates.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-54309": {
     "name": " CrushFTP Unprotected Alternate Channel Vulnerability",
@@ -24254,7 +24988,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet supplies every precondition this control keys on: an unauthenticated attacker reaches remote code execution on Wing FTP Server, exploitation is confirmed in the wild, a PoC is available, and the injected Lua executes with the privileges of the FTP service — root or SYSTEM by default. That last fact is what makes patch-in-place the wrong default here: a successful exploit owns the host, not merely the FTP application, so the vendor update closes the null-byte injection path while leaving intact whatever was installed through it — added accounts, scheduled tasks, altered service configuration, or attacker Lua left in the session-file tree the product itself evaluates. Applied to this product, an exploited or suspected-exploited instance is dispositioned by exporting configuration, rebuilding the host, and rotating every credential the service held or handled: Wing FTP account passwords, any service or database credentials in its configuration, and any key material stored on the host — not by upgrading in place and closing the ticket. Precondition: this disposition is for instances that were reachable by untrusted clients during the exposure window, which the packet opens at the 2025-07-14 KEV listing and which closes only when the fix is actually in service. For an instance demonstrably unreachable across that window, the vendor update plus the restart it requires is sufficient; the packet records a vendor patch with no live-patch path and a service-restart-or-reboot requirement, so an instance updated but not restarted has not closed the window at all. Which case a host is in has to be established from reachability evidence — 'the server is internal' is a statement about topology, not a demonstration that no untrusted client could reach the listener. The distinguishing test: on a host that has taken the update, look for artefacts the update does not remove — accounts and session files created during the exposure window, and service-configuration changes not traceable to an administrator action; an upgrade record alone does not distinguish a clean host from an occupied one.",
+        "evidence": "Packet: CWE-158, improper neutralization of a null byte or NUL character, allowing injection of arbitrary Lua code into user session files, used to execute arbitrary system commands with the privileges of the FTP service (root or SYSTEM by default). attack_vector records an unauthenticated attacker achieving remote code execution, exploitable even via anonymous login. CISA KEV-listed 2025-07-14 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8. 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.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "Wing FTP's pre-authentication login and session-file handling is the unprivileged user surface this control governs, and the packet has it wired straight to a root operation: a NUL character that is not neutralized carries attacker-controlled text into a user session file, that file is evaluated as Lua, and the interpreter runs as the FTP service — root or SYSTEM by default. Applied to this product the property to verify is that nothing arriving on the pre-authentication surface can reach an interpreter holding host authority: content the login path writes into a session file is consumed as data rather than evaluated, and the service's privileged operations sit behind their own boundary instead of being reachable by anything that can present a username. The vendor update is what repairs the neutralization — the control states the property to verify, it does not implement it. The operator-side lever in the meantime is the authority the interpreter inherits: where the product permits it, run Wing FTP under a dedicated account without host-level administrative rights, so injected Lua executes without root or SYSTEM authority. Two preconditions, and the first is the one most likely to be recorded as the mitigation when it is not one. Disabling anonymous login does not close this path: the packet states the attacker is unauthenticated and names anonymous login only as the easiest route, so the injection is reached before any account decision is made and an instance with anonymous access turned off remains exploitable. And the service-account change does not stop the injection — it bounds what the injected code can do, and it does nothing at all on a deployment that must retain root or SYSTEM. This is why the cited least-privilege gap is recorded against this entry: per-account privilege scoping is never consulted, because the attacker holds no account. The distinguishing test: on a staging instance with anonymous login disabled, submit NUL-bearing input to the pre-authentication surface and confirm nothing is written into a session file the Lua interpreter will later evaluate — an attestation that every Wing FTP account has a strong password tests the account model this attack never touches.",
+        "evidence": "Packet: CWE-158, improper neutralization of null byte or NUL character, allowing injection of arbitrary Lua code into user session files, which can be used to execute arbitrary system commands with the privileges of the FTP service (root or SYSTEM by default). attack_vector records an unauthenticated attacker and notes it is exploitable even via anonymous login. NIST SP 800-53 AC-6 (Least Privilege) is one of the framework control gaps citing this CVE. CISA KEV-listed 2025-07-14 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8. 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": "This entry pairs the three conditions that collapse a normal patch window: the packet records exploitation as confirmed, a PoC as available, and code execution at root or SYSTEM from an attacker holding no credential — so the interval between the 2025-07-14 KEV listing and the fix being in service is time during which any reachable instance can be taken at host level by anyone who can send it traffic. Applied to this product the control means Wing FTP is remediated on the KEV clock rather than in the next application-maintenance window, and that completion is measured per instance by the running version after restart. The packet gives a vendor patch, no live-patch path, and a fix requiring a service restart or system reboot, so an instance whose files were replaced but whose service still holds the old code in memory is exposed, not remediated — on a file-transfer service that is the common case, because restarting it interrupts transfers and gets deferred. Precondition: the clock covers only instances the operator knows about. Wing FTP is the kind of service that gets stood up by a business unit for a partner file exchange and never enters the application inventory, and a KEV SLA cannot be met against an instance nobody has listed — enumerating who is running it is the first action the clock demands, not the last. The distinguishing test: for each Wing FTP instance, compare the running service's version and its process start time against the time the fix was applied; a compliance record showing the package updated within the SLA, on a service that has not restarted since, records the file copy rather than the remediation.",
+        "evidence": "Packet: CISA KEV-listed 2025-07-14 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8. vector records that the injected Lua executes arbitrary system commands with the privileges of the FTP service (root or SYSTEM by default), and attack_vector records an unauthenticated attacker, exploitable even via anonymous login. 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. Citing framework gaps include ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8 and NIST SP 800-53 SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-5777": {
     "name": "Citrix NetScaler ADC and Gateway Out-of-Bounds Read Vulnerability",
@@ -24409,7 +25176,21 @@
     },
     "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 is a 2019-identified flaw that entered CISA KEV on 2025-07-07 with confirmed in-the-wild exploitation and a public proof-of-concept, which is what makes an exploitation-driven SLA the operative control instead of the age- or score-ordered queue most vulnerability-management programs run: at CVSS 7.5 and six years old, this entry sorts near the bottom of a queue ordered by severity and disclosure date while being actively exploited, and the packet's RWEP of 77 against that CVSS is the size of the mis-ranking. Applied to this product, the clock runs from the KEV listing to a Zimbra Collaboration Suite instance actually running the fixed code, and the packet's remediation note is where that goes wrong: it records a vendor patch with no live-patch tool registered and states the patch typically requires a service restart or system reboot per the KEV requiredAction, so a ZCS host where the package was applied but the services were never restarted is still serving the vulnerable ProxyServlet and must be counted as exposed rather than remediated. No compensating control is offered here that removes the path, and inventing one would be worse than saying so: the SSRF is reachable by an unauthenticated attacker through ProxyServlet on the ZCS web surface, and on a mail and collaboration server that surface is reachable by design. Source-restricting it is available only for an instance whose web client serves a bounded, known user population; for an internet-facing deployment it is not, and there the completed, restarted update is the only action that closes the path. Distinguishing test: query each ZCS host for the version of the running services rather than the installed package version, and confirm the restart has happened — a patch-deployment report that closes the ticket at package install leaves an actively exploited path open on a host that reports as patched.",
+        "evidence": "Packet: Synacor Zimbra Collaboration Suite (ZCS) contains a server-side request forgery vulnerability via the ProxyServlet component (CWE-918, CWE-807), letting an unauthenticated attacker coerce server-side requests — described as a known chain toward RCE on ZCS. CISA KEV-listed 2025-07-07; active_exploitation confirmed; poc_available true; CVSS 7.5; RWEP 77. patch_available true; live_patch_available false; live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-5418": {
     "name": "Rails Ruby on Rails Path Traversal Vulnerability",
@@ -24469,7 +25250,29 @@
     },
     "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 places the traversal in Action View, a component inside the Ruby on Rails framework rather than a dependency a deployed application declares for itself — an application declares Rails, or declares a gem that declares Rails, and Action View arrives underneath. That is why the framework control this entry cites, patching operating systems, cannot reach it: a host package inventory and an OS patch report can both read clean across the whole estate while every Rails application on it still renders arbitrary files in response to a crafted Accept header. Applied here, the inventory has to resolve to the framework-component level: enumerate the resolved Action View version behind every deployed application — internal tools, vendor-supplied Rails applications, and containers built from base images the platform team does not rebuild — from the application's own lockfile, and drive flaw-remediation tickets from that list instead of from the host patch report. Distinguishing test: ask the estate's inventory for the resolved Action View version behind each deployed Rails application; any application whose framework component version the inventory cannot produce is unremediated by default, not compliant, because nothing in the OS-scoped evidence would ever have shown otherwise. Precondition: this finds the exposure, it does not close it. The packet records a vendor patch with no live-patch path and a service restart requirement, so each application must be moved onto the fixed framework version and restarted before it counts as remediated. An application whose lockfile the operator does not control — a vendor-supplied appliance shipping its own Rails build — is remediated by the vendor's update or by removing its exposure, not by recording it as inventoried. And because the packet says the read reaches configuration and secrets, an application found exposed after the fact needs those secrets rotated; the framework update does not un-disclose what was already read.",
+        "evidence": "Packet fields for this entry: \"Rails Ruby on Rails contains a path traversal vulnerability in Action View. Specially crafted accept headers in combination with calls to `render file:` can cause arbitrary files on the target server to be rendered, disclosing the file contents\"; attack_vector adds that this lets \"an unauthenticated attacker read arbitrary files including configuration and secrets\". cwe_refs CWE-22. cisa_kev true, kev_date 2025-07-07, active_exploitation confirmed, poc_available true, cvss 7.5, rwep_score 77. patch_available true, live_patch_available false, live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" AU-Essential-8-Patch (Patch operating systems) and NIST-800-53-SI-2 (Flaw Remediation) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A vulnerability-management verdict of \"patched\" reached from a host package version is paper compliance for this entry twice over: the defect lives in the application's bundled framework rather than in a host package, and the attacker's input is somewhere most detection never looks. The packet is explicit that the crafted content rides in the Accept header, in combination with a `render file:` call — the request path and query string are unremarkable. So a scanner rule, WAF signature or SIEM query written against traversal sequences in URLs sees a clean request and stays silent through actual exploitation, and the resulting green report is the compliance-theater artefact. Operational test for this entry: from an unauthenticated client against a staging deployment, issue a request carrying a crafted Accept header to a route that reaches `render file:`, and confirm the response body does not contain a file from outside the application's view root — a real behavioural result, not a version comparison. Two supporting checks belong with it: confirm the request-logging pipeline actually retains the Accept header, since a pipeline that drops it cannot evidence exploitation afterwards; and write the detection against the behaviour the packet documents, which is inbound Accept header values carrying traversal sequences or absolute paths, together with the application returning file content of a type that route does not otherwise serve. Precondition and limit: a passing test proves this route is closed, nothing more — it does not survey the estate, and it does not undo disclosure. Because the packet records the read as reaching configuration and secrets, any application where the test fails or where exploitation is evidenced needs every secret reachable through that read rotated, and the vendor update applied with the service restart the packet requires, before the finding is closed.",
+        "evidence": "Packet fields for this entry: \"Specially crafted accept headers in combination with calls to `render file:` can cause arbitrary files on the target server to be rendered, disclosing the file contents\"; attack_vector records \"a path-traversal flaw (CWE-22) in Ruby on Rails Action View (crafted Accept header), letting an unauthenticated attacker read arbitrary files including configuration and secrets\". cisa_kev true, kev_date 2025-07-07, active_exploitation confirmed, poc_available true, cvss 7.5, 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.\" ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2016-10033": {
     "name": "PHPMailer Command Injection Vulnerability",
@@ -24788,7 +25591,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-138",
+        "name": "VERIFY-MESSAGING-BACKEND-DATA-HANDLING-AGAINST-E2E-CLAIM",
+        "description": "TM SGNL is a messaging-archiving backend, and this defect is only catastrophic because of what that backend was holding. The packet describes a JSP application whose heap content is 'roughly equivalent to a core dump', states that a password previously sent over HTTP is included in that dump, and records the exposure as disclosing plaintext messages and credentials from the TeleMessage server. A memory-disclosure bug in an archive that genuinely could not read message contents would return ciphertext; here it returned the messages themselves, so what this CVE demonstrates is the end-to-end claim failing rather than the dump primitive being unusually powerful. Bound to this product, the control means the archiving tier is not accepted on the strength of its encryption datasheet: require evidence — independent cryptographic review, a documented key-custody model that excludes the vendor, or a controlled test — that the backend cannot produce the plaintext of a stored message without the endpoint's keys, and put the same question to the credentials the web tier receives, since the packet places a password submitted over HTTP inside the process heap. The distinguishing test is a procurement-and-onboarding test rather than a scan: ask the vendor to produce the plaintext of a message you stored, and ask whether the account credential you submitted is recoverable from the running process. If either answer is yes, any memory-exposure defect in the product is a full-content breach, and the multi-factor and identity-and-access attestations the estate carries do not reduce it — the credential leaves the server without any authentication event taking place, so a second factor is never presented and no access decision is ever consulted. This control governs whether the product is trusted with the data; it does not remediate the disclosure path itself. The packet records a vendor patch for that, and material already read out of an exposed instance stays valid until it is rotated.",
+        "evidence": "Packet: CISA KEV-listed 2025-07-01 with active_exploitation 'confirmed'; CVSS 8.8, RWEP 77; poc_available true; patch_available true; live_patch_available false. Vector: 'TeleMessage TM SGNL contains an exposure of core dump file to an unauthorized control sphere Vulnerability. This vulnerability is based on a JSP application in which the heap content is roughly equivalent to a \"core dump\" in which a password previously sent over HTTP would be included in this dump.' attack_vector: 'exposure of a core-dump file to an unauthorized control sphere (CWE-528), disclosing memory contents including plaintext messages and credentials from the TeleMessage server.' Citing gaps recorded against this entry include AU-Essential-8-MFA (multi-factor authentication) and UK-CAF-B2 (identity and access control).",
+        "gap_closes": [
+          "AU-Essential-8-MFA",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records a vendor patch, no live-patch path, and live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so on this product remediation is not complete when the fixed build is installed, only when the archiving service has been restarted onto it. Until that restart the JSP application is still the process serving the heap-equivalent dump. For this entry the control means the fixed release lands on a KEV-tied clock opened 2025-07-01 rather than in the next maintenance window, and that completion is measured per instance by the version actually running after restart, not by 'update applied' in a change record. The second half is specific to a disclosure defect under confirmed in-the-wild exploitation with a public PoC: the patch stops the dump being served from that moment forward and does nothing about what was already read. Every instance that was reachable before the restart therefore has to be treated as having leaked the message content and the credentials the packet places in that dump, with those credentials rotated inside the same SLA rather than as a later follow-up — patching an information-disclosure flaw is not a containment step. Distinguishing test: for each TM SGNL instance, measure elapsed time from the KEV listing to the fixed build running post-restart, and check whether the remediation record carries a rotation decision for the credentials that were resident in the process heap. A vulnerability-management programme that closes the ticket at patch deployment reports this entry as remediated while the disclosed credentials remain usable.",
+        "evidence": "Packet: CISA KEV-listed 2025-07-01, active_exploitation 'confirmed', poc_available true, CVSS 8.8, RWEP 77. patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' The vector places 'a password previously sent over HTTP' inside the dump, and the attack_vector describes 'disclosing memory contents including plaintext messages and credentials from the TeleMessage server' (CWE-528).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-48927": {
     "name": "TeleMessage TM SGNL Initialization of a Resource with an Insecure Default Vulnerability",
@@ -24848,7 +25674,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": "/heapdump is a framework diagnostic function, not part of the archiving product's user-facing surface, and the packet puts the defect exactly there: TM SGNL ships with the Spring Boot Actuator configured so the heap-dump endpoint is exposed at a /heapdump URI, and an unauthenticated caller retrieves a heap dump containing plaintext messages and credentials. Bound to this deployment, the control means each Actuator management endpoint on the TM SGNL server authorizes its own caller before the function runs rather than inheriting reachability from the shipped default; that every diagnostic endpoint with no operational need — the heap-dump path first — is turned off rather than merely fronted; and that the management surface is segmented so a caller from an untrusted network cannot present the request at all. The least-privilege gap cited against this entry does not touch this path: the attacker never authenticates as any TM SGNL user, so per-account privilege scoping is never consulted and an access-review attestation passes cleanly while the endpoint answers anyone who can route to it. Two preconditions have to be stated rather than assumed. First, the configuration-side fix requires the operator to control the instance's Actuator endpoint-exposure settings; on a vendor-hosted or vendor-managed instance that lever belongs to the vendor, and the operator's only available actions are written confirmation that the endpoint is closed plus the network restriction below. Second, a reverse-proxy or WAF rule that blocks the /heapdump path constrains only requests that traverse the proxy — it does nothing for a caller that reaches the application's listener directly, so the restriction must be enforced at the listener bind address or by a host/network ACL, not at a filtering layer that can be routed around. Neither measure evicts an attacker who already pulled a dump: the messages and credentials inside it stay readable and valid until rotated. Distinguishing test: from a segment with no operational need for TM SGNL diagnostics, request /heapdump unauthenticated against a staging instance both through the normal proxy path and directly against the application listener, and confirm both are refused before a dump is generated.",
+        "evidence": "Packet vector: 'TeleMessage TM SGNL contains an initialization of a resource with an insecure default vulnerability. This vulnerability relies on how the Spring Boot Actuator is configured with an exposed heap dump endpoint at a /heapdump URI.' attack_vector: 'an insecure-default initialization (CWE-1188) that leaves a Spring Boot Actuator diagnostic endpoint (/heapdump) exposed, letting an unauthenticated attacker retrieve a heap dump containing plaintext messages and credentials.' CISA KEV-listed 2025-07-01 with active_exploitation 'confirmed'; CVSS 9.8, RWEP 77; poc_available true. Citing gaps recorded against this entry include AU-Essential-8-App-Hardening (user application hardening), NIST-800-53-AC-6 (least privilege), UK-CAF-B4 (system security) and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records a vendor patch with no live-patch path and live_patch_notes stating that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so an instance that has taken the fixed build but has not restarted is still running the process whose Actuator configuration exposes /heapdump, and must be counted as exposed rather than remediated. For this entry the control means the fix lands on a KEV-tied clock opened 2025-07-01, with completion measured per instance by the build actually running after restart. What makes the SLA unusual on this entry is that a configuration-side action exists ahead of the vendor build: the packet attributes the exposure to how the Actuator is configured, so removing the endpoint's exposure closes the path immediately on any instance whose configuration the operator controls, and that action belongs on the KEV clock. It is not a reason to defer the patch — a configuration change can be reverted by a redeploy, a template rebuild, or a vendor update that restores the shipped default, and on a vendor-managed instance the operator may not hold that lever at all. Distinguishing test: re-request /heapdump on each instance after the service restart and again after any redeploy or image rebuild, and confirm it is still refused. A vulnerability-management programme that verifies once at patch time will not notice the shipped default returning on the next deployment.",
+        "evidence": "Packet: CISA KEV-listed 2025-07-01 with active_exploitation 'confirmed'; CVSS 9.8, RWEP 77; poc_available true; patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' The vector attributes the exposure to configuration: 'This vulnerability relies on how the Spring Boot Actuator is configured with an exposed heap dump endpoint at a /heapdump URI.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-6543": {
     "name": "Citrix NetScaler ADC and Gateway Buffer Overflow Vulnerability",
@@ -25232,7 +26082,40 @@
     },
     "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's vector puts the defect in the Linux kernel's OverlayFS subsystem — a uid-mapping bug in how a user copies a capable file from a nosuid mount into another mount — and says a local user escalates privileges on the system, so the flaw executes below every account boundary the Linux estate is audited on. For this CVE the control means the distribution kernel carrying the fix is driven across the whole affected fleet on the KEV clock that opened 2025-06-17 rather than folded into the next quarterly kernel window, and that completion is measured by the kernel each host is actually running, not by the kernel package version the inventory reports as installed. That distinction is the load-bearing one on Linux: the packet records no live-patch path and a fix that requires a service restart or system reboot, so a host that has installed the fixed kernel package but is still booted on the old image carries the vulnerable OverlayFS code in memory and must be counted as exposed, not as remediated. A patch-compliance report built on installed-package version alone will show this fleet green while every un-rebooted host remains fully exploitable. The control's second half is why the least-privilege gap is cited against this entry: the attacker is already an ordinary local user by the packet's own description, so tightening account privilege, sudo policy or group membership does not contain the escalation to root — a least-privilege attestation passes cleanly while the flaw stays fully exploitable. With a public PoC and confirmed in-the-wild exploitation, the pre-reboot window is contested rather than theoretical, which is what makes the reboot part of the remediation rather than a scheduling detail.",
+        "evidence": "Packet: CISA KEV-listed 2025-06-17 with active_exploitation 'confirmed'; CVSS 8.8, RWEP 77; poc_available true. Vector: 'Linux Kernel contains an improper ownership management vulnerability, where unauthorized access to the execution of the setuid file with capabilities was found in the Linux kernel's OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid mapping bug allows a local user to escalate their privileges on the system.' (CWE-282). patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps recorded against this entry include NIST-800-53-AC-6 (Least Privilege).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "With no live-patch path and a fix that only takes effect after reboot, every Linux host in the estate runs the vulnerable OverlayFS code until it restarts, and the packet records a public PoC alongside confirmed in-the-wild exploitation — so that window needs telemetry, not only a patch ticket. The auditd or eBPF rule has to key on what the packet says the exploit does rather than on what an exploit tool looks like: a non-root user assembling an overlay mount; a file carrying the setuid bit or file capabilities appearing in the writable upper layer after a copy-up from a nosuid lower mount; and then an execve of that file followed by the process transitioning to uid 0 while its audit login uid remains that of an ordinary user. Those three events are the mandatory emissions of the sequence the vector describes — mount, copy the capable file across, run it — so a rule built on them fires on any implementation of that sequence. Rules built on the usual alternatives do not fire at all here: this path completes successfully and produces no crash, so oops- or segfault-based kernel-exploit heuristics never trigger, and name- or hash-matching a published PoC binary misses a rebuild under any other name, which is the expected form given the packet records PoC availability. Alerting must be measured in seconds and routed as an active-intrusion signal rather than a hygiene finding, because the packet notes LPEs of this class are routinely paired with an initial-access primitive: by the time this rule fires the earlier step has already been missed, and the transition to root is the last observable event before the operator owns the host.",
+        "evidence": "Packet: poc_available true with active_exploitation 'confirmed'; CISA KEV-listed 2025-06-17; CVSS 8.8, RWEP 77. Vector describes 'unauthorized access to the execution of the setuid file with capabilities ... in the Linux kernel's OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid mapping bug allows a local user to escalate their privileges on the system.' attack_vector: 'an improper-ownership-management flaw (CWE-282) in the Linux kernel OverlayFS, exploited by a local user to copy a SUID file across mounts and gain root ... LPEs of this class are routinely paired with an initial-access primitive.' live_patch_available false, with live_patch_notes stating no live-patch tool is registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. UK-CAF-B4 (system security) is among the citing gaps.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The vulnerable code the packet names is the OverlayFS subsystem, so on hosts that do not use it the escalation path can be removed before the reboot the kernel fix requires — that is what this control buys on this CVE, and the precondition has to be stated precisely because it fails on a large share of a modern Linux estate. Where overlay is built as a loadable module and is not currently loaded, blacklisting it in modprobe configuration prevents the autoload that a user's mount attempt would otherwise trigger, and the escalation path is gone for that host. Where overlay is compiled into the kernel image rather than built as a module, a modprobe blacklist has no effect whatsoever, because there is no load to prevent. Where it is already loaded — any host whose container runtime uses an overlay filesystem for image layers, and any host with a live overlay mount — the blacklist changes nothing for the running kernel: the module cannot be unloaded while mounts reference it, and the host would have to reboot to come up without it, which is the same reboot the kernel fix needs, and on those hosts overlay usually cannot be removed at all because the runtime depends on it. Both of those cases fall back to the patch-and-reboot path plus kernel-escalation detection, and the blacklist must not be recorded as their mitigation. Verify per host rather than per policy: check the loaded-module list and the kernel's registered-filesystem list for overlay, and enumerate active overlay mounts. A non-empty result in any of the three means this control does not apply to that host — recording a fleet-wide blacklist as deployed would credit a mitigation that never took effect on exactly the hosts most likely to be running untrusted local workloads.",
+        "evidence": "Packet vector locates the flaw 'in the Linux kernel's OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount', with 'a local user' escalating privileges on the system (CWE-282). CISA KEV-listed 2025-06-17, active_exploitation 'confirmed', poc_available true, CVSS 8.8, RWEP 77. patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' — that reboot requirement is what creates the window this least-functionality control covers. UK-CAF-B4 (system security) is among the citing gaps.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-33538": {
     "name": "TP-Link Multiple Routers Command Injection Vulnerability",
@@ -25292,7 +26175,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "On the small sites these units serve, the router is the trust boundary itself, and the packet's flaw is unauthenticated command execution reached through the /userRpm/WlanNetworkRpm component on the device's own web management surface — so the device that would enforce any network-layer control is the thing running the attacker's command. Scope the tier to the revisions the packet names and no further: TL-WR940N V2/V4, TL-WR841N V8/V10, TL-WR740N V1/V2. Nothing in the packet ties this component to other TP-Link models, so widening it to the vendor's line manufactures replacement work against hardware no evidence implicates. The tier requirement for this entry: firmware for the affected revision is deployed on the clock that opened with the 2025-06-16 KEV listing, not on the branch- or home-equipment cadence these devices normally sit on, and until it is, reachability of the HTTP management surface is the only lever an operator holds — the exploit needs nothing except the ability to put a request on that path, since the attacker never authenticates. Two preconditions have to be stated or the isolation gets recorded as the mitigation: restricting reach bounds who can send the request but leaves the vulnerable handler intact, and on a device whose LAN side is where its own users sit, \"internal only\" is a statement about topology rather than a demonstration that the surface is unreachable. It also does nothing for a unit already executing attacker commands. The distinguishing test: from every segment the device serves and from an external address, attempt to load its HTTP management surface — anything that answers is within reach of the published exploit. One caveat the packet forces: it records patch_available true while also stating the impacted products could be end-of-life and/or end-of-service with CISA advising users discontinue product utilization, so the per-revision support status decides whether fixed firmware exists for a given unit at all, and a revision for which it does not is replaced rather than carried forward on a patch report.",
+        "evidence": "Packet fields for CVE-2023-33538 (TP-Link Multiple Routers Command Injection Vulnerability): cwe_refs CWE-77; cisa_kev true, kev_date 2025-06-16; active_exploitation confirmed; cvss 9.8; rwep_score 77; poc_available true; patch_available true; live_patch_available false; live_patch_notes \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" Vector: \"TP-Link TL-WR940N V2/V4, TL-WR841N V8/V10, and TL-WR740N V1/V2 contain a command injection vulnerability via the component /userRpm/WlanNetworkRpm. The impacted products could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.\" attack_vector: \"a command-injection flaw (CWE-77) enabling unauthenticated remote command execution on the router.\" Citing gaps recorded on the entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, NIST-800-53-AC-6, UK-CAF-B4, NIS2-Art21-network-security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Applied to these routers: exploitation is confirmed in the wild and a PoC is public for a path that reaches command execution with no credential at all, so a TL-WR940N, TL-WR841N or TL-WR740N unit that was reachable on /userRpm/WlanNetworkRpm before its firmware was updated cannot be returned to service on the strength of a version string. The runbook for such a unit defaults to capturing the running configuration as evidence first, flashing the fixed firmware from vendor media rather than upgrading in place from the running system, re-entering settings by hand instead of restoring a backup taken after the exposure window opened, and rotating everything the device held — the administrative credential, the wireless pre-shared key, and any credential reused on it. The limit is the point of the control: the firmware update closes the injection path, it does not undo a configuration change made through that path, so the operator still has to diff the items command execution can reach — administrative accounts, DNS settings, forwarding rules — against a known-good record, and a configuration restore from the exposure window reinstates exactly those changes under the fixed firmware. The cited least-privilege gap stays open in both directions on this path and no operator-side account scoping closes it: the attacker never authenticates, so no per-account privilege decision is ever consulted, and an attestation that every router administrator holds a scoped account passes cleanly while the unauthenticated path runs.",
+        "evidence": "Packet fields for CVE-2023-33538: active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 77; cisa_kev true with kev_date 2025-06-16. attack_vector: \"a command-injection flaw (CWE-77) enabling unauthenticated remote command execution on the router.\" Vector names the affected revisions TL-WR940N V2/V4, TL-WR841N V8/V10, TL-WR740N V1/V2 and the component /userRpm/WlanNetworkRpm. patch_available true; live_patch_available false, with live_patch_notes recording no registered live-patch tool and a vendor patch that typically requires service restart or system reboot per the KEV requiredAction. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are both recorded as citing gaps on the entry.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-43200": {
     "name": "Apple Multiple Products Unspecified Vulnerability (variant: CVE-2025-43200)",
@@ -25546,7 +26452,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Roundcube's mailbox surface has to be logged at the per-request level, shipped off the webmail host, because the theft this flaw enables never produces a failed or unusual authentication event — the same webmail per-request telemetry requirement the inventory entry states for Exchange OWA, applied to a Roundcube estate. The packet's path is a crafted email that hits a desanitization issue in message_body() in program/actions/mail/show.php, so the injected script runs when the victim opens the message, inside a session the victim authenticated normally, and the attacker's mail reads and outbound sends are issued by the victim's own browser over the victim's own session. Applied here: forward the Roundcube HTTP access log and the mailbox-side (IMAP/webmail application) request log for every mailbox operation — not just the login events — to a collector the webmail host cannot write to, retain it long enough to cover the span between the KEV listing of 2025-06-09 and the day each instance was actually restarted onto the fixed code, and review it for read/send patterns rather than authentication failures. The distinguishing test: ask the SIEM to reconstruct every message a chosen account opened and sent on a chosen day; a source that can only answer 'the user logged in at 09:14' cannot see this attack at all. Precondition and limit: this is detection, not prevention — it does not stop the script from executing, and it only yields evidence if per-request logging was already shipping before the crafted message arrived. If the deployment sits behind a reverse proxy that logs only at the proxy, mailbox-side actions over the authenticated session will not appear, and the webmail application/IMAP log must be added as its own source. Where per-request logging was absent during the exposure window, retrospective review cannot answer the question and the mailboxes have to be treated as potentially read and their stored credentials as potentially taken.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-06-09, active_exploitation confirmed, poc_available true, RWEP 77 against CVSS 6.1 — the in-the-wild status rather than the base score is what makes the pre-restart window worth reconstructing. The vector records that the flaw 'could allow a remote attacker to steal and send emails of a victim via a crafted e-mail message that abuses a Desanitization issue in message_body() in program/actions/mail/show.php'; the attack_vector records script running 'in a victim's authenticated session via a crafted email (exploited in espionage credential-theft campaigns)'. patch_available true but live_patch_available false, and live_patch_notes records that no live-patch tool is registered for this entry and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so every deployment carried a window between listing and restart. The citing gaps NIST 800-53 SI-2 (Flaw Remediation) and NIS2 Art. 21 vulnerability handling are both remediation-side and close at 'patched', leaving session-borne theft that already happened unrecorded.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock starts at the KEV listing of 2025-06-09 with a public PoC already available and exploitation confirmed, and what decides whether an operator can meet it is not the package — it is the restart. The packet records a vendor patch but no registered live-patch tool, and states the fix typically requires a service restart or system reboot, so a Roundcube instance is not remediated when the upgrade lands on disk; it is remediated when the webmail service and the PHP worker serving program/actions/mail/show.php have been recycled and a request actually executes the fixed message_body(). Applied here: schedule that recycle inside the response window rather than at the next maintenance weekend, and where a shared-hosting or multi-tenant webmail platform genuinely cannot be recycled that fast, book the delay as a dated, named exception with the compensating measure written down — not as 'patch scheduled', which reads as compliant on a report while every mailbox on the instance stays reachable through a single crafted message. Precondition: the compressed clock only covers instances the operator knows about. A KEV-triggered SLA applied over an inventory that omits departmental, hosted or legacy Roundcube instances silently exempts exactly the instances nobody restarts, so the enumeration of webmail instances is part of the control rather than a prerequisite assumed to hold.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-06-09, active_exploitation confirmed, poc_available true, rwep_score 77, cvss 6.1. patch_available true, live_patch_available false, and live_patch_notes states that no live-patch tool is registered for this entry at bulk-import time and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — the restart, not the package upgrade, is the step that ends the exposure. The vector places the defect in message_body() in program/actions/mail/show.php, reached by a crafted email. The citing gaps NIST 800-53 SI-2, ISO 27001 A.8.8 and NIS2 Art. 21 vulnerability handling all impose an obligation to remediate but none carries a KEV-triggered deadline, which is the gap this control fills.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-32433": {
     "name": "Erlang Erlang/OTP SSH Server Missing Authentication for Critical Function Vulnerability",
@@ -25917,7 +26846,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The defect is a use-after-free in the Qualcomm Adreno GPU driver, and the packet records the trigger as memory corruption while rendering graphics using Adreno GPU drivers in Chrome, with the attack path a local foothold escalating privilege on the device. That combination is what makes the access-condition half of this control the load-bearing half: the operator cannot patch the driver directly, because the fixed driver code reaches a device only inside the build its hardware vendor ships for that chipset. The fixed build therefore has to act as a condition of access — organizational mail, VPN and document access denied to any device below it — rather than as a row on a patch-compliance dashboard. Scope it to the population the packet establishes: devices carrying the affected Qualcomm chipsets and the Adreno GPU driver. The packet ties the flaw to that driver and provides no mapping into other GPU stacks or renderers, so extending this to every graphics-accelerated endpoint in the estate would manufacture findings and denial-of-access work against hardware no evidence implicates. Distinguishing test: enrol a device pinned below the fixed build and confirm the policy actually refuses 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: a device whose hardware vendor has not shipped a build containing this fix cannot be remediated by this control at all, and for those units the remaining levers are constraining what code the device is permitted to run, withholding organizational data from it, and — where no fixed build is coming — replacement. Restricting what runs on a device also does not evict code already resident on one, so a device suspected of already holding the local foothold the packet describes belongs on the incident path, not the policy path. And because the packet records no live-patch path and a fix requiring service restart or system reboot, a device that has downloaded the vendor build but not restarted is still running the vulnerable driver.",
+        "evidence": "Packet facts: CWE-416 use-after-free affecting multiple Qualcomm chipsets; the recorded vector is memory corruption while rendering graphics using Adreno GPU drivers in Chrome, and the recorded attack path is a local foothold escalating privilege on the device, with the packet noting that LPEs of this class are routinely paired with an initial-access primitive. CISA KEV-listed 2025-06-03, active_exploitation=confirmed, poc_available=true, CVSS 8.8, RWEP 77. patch_available=true, live_patch_available=false, with the note that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. Citing gaps include ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8, NIST SP 800-53 SI-2 and UK CAF B4.",
+        "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": "For this CVE the KEV clock that opened 2025-06-03 runs against a fix the operator does not publish: the Adreno driver correction arrives inside a device-vendor build, so the SLA has to be written as 'fixed build installed and the device restarted, or a recorded time-bounded access restriction for that device', with the clock starting at the KEV listing or at availability of the build for that device model, whichever is later. Measuring the SLA as 'patches approved' or 'update pushed' is vacuous on this path, because the packet records no live-patch path and a fix requiring restart or reboot — a device that has taken the update and not restarted is still running the vulnerable driver and must be counted against the SLA as exposed. The state that has to be reported distinctly, rather than folded into a pass, is the device that is inside the window with no fixed build available for its model: that is not a deferral, it is an unremediated device, and the only lever left is the access restriction, which bounds what the device can reach and does not repair the driver.",
+        "evidence": "Packet facts: CISA KEV-listed 2025-06-03 with active_exploitation=confirmed and poc_available=true; CVSS 8.8, RWEP 77; CWE-416 in the Qualcomm Adreno GPU driver. patch_available=true, live_patch_available=false, with the recorded note 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps include ASD Essential Eight 'Patch operating systems', NIST SP 800-53 SI-2 and EU NIS2 Art.21 vulnerability handling and disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2021-32030": {
     "name": "ASUS Routers Improper Authentication Vulnerability",
@@ -26097,7 +27051,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive the packet records is a write, not a read: an unauthenticated client introduces arbitrary values — the packet names PHP code — into a known local file location on the Craft CMS server. That is the distinction this control exists for, because the vendor update repairs the parameter-handling path and reverts nothing already written through it. Applied to this product: any internet-reachable Craft install that was serving before the fixed release landed is triaged as a possibly-compromised host rather than closed out on the upgrade — the deployed tree is compared against the source of record for files the web server can execute but that no deployment put there, and the credentials and keys that install held are rotated. The packet also records this flaw as chainable with CVE-2024-58136 (as represented by CVE-2025-32432), so the exposure to assess is the chain's outcome on the host, not a single tampered parameter. Precondition, and it is the load-bearing one: this comparison only decides anything if the operator holds a reference the install can be diffed against — a version-controlled deployment or a known-good image from before the exposure window. A Craft install whose web root has been edited in place over its life has no such reference; inspection cannot clear it, and redeployment from the source of record is the remaining option rather than an optional stronger step. Distinguishing test: after upgrading a formerly exposed install, diff the deployed tree against the source of record and confirm no unaccounted PHP file — a flaw-remediation attestation recording that Craft was upgraded to the fixed release reads clean over a file written before the upgrade.",
+        "evidence": "The packet's vector states that the vulnerability could allow an unauthenticated client to introduce arbitrary values, such as PHP code, to a known local file location on the server, and that it could be chained with CVE-2024-58136 as represented by CVE-2025-32432 (CWE-472). active_exploitation is confirmed and poc_available is true; the entry is CISA KEV-listed 2025-06-02 with CVSS 8.8 and RWEP 77. patch_available is true and live_patch_available is false, with live_patch_notes recording that no live-patch tool is registered for this entry and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "A CVSS 8.8 web-application flaw normally enters a routine application-patch queue, but the packet pairs it with confirmed in-the-wild exploitation and a public PoC against a path that needs no credential — which is the condition the compressed clock exists for. For Craft CMS the control means the fixed release is driven across every Craft install the organization operates, on the clock that opened with the 2025-06-02 KEV listing, and completion is measured by each site reporting the fixed Craft version rather than by 'update scheduled' on a release board. The installs that decide the outcome are the ones an application inventory tends not to hold — sites standing up under an agency or contractor deployment — because a copy nobody is tracking keeps serving the unauthenticated write path on the same schedule as one that is. The packet registers no live-patch path and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a site whose files carry the fixed release but whose service has not been cycled is counted as exposed, not as remediated. Precondition on any interim measure: the packet records no vendor workaround or compensating mitigation for this flaw, so anything an operator puts in front of a site that cannot take the update inside the window — restricted reachability, a maintenance page, a filtering layer — is unvalidated against this specific parameter and reduces exposure rather than removing it; the site is still counted against the SLA until it reports the fixed version.",
+        "evidence": "CISA KEV-listed 2025-06-02 with active_exploitation confirmed and poc_available true; CVSS 8.8, RWEP 77. The vector describes an unauthenticated client introducing arbitrary values, such as PHP code, to a known local file location on the server. patch_available is true; live_patch_available is false, and live_patch_notes records that no live-patch tool is registered for this entry and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction. The packet records no vendor-supplied workaround or compensating mitigation for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-56145": {
     "name": "Craft CMS Code Injection Vulnerability (variant: CVE-2024-56145)",
@@ -26637,7 +27615,41 @@
     },
     "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": "This is the authentication half of the EPMM chain. The packet places the flaw in EPMM's API component, where crafted API requests reach protected resources without proper credentials because of an insecure implementation of the Spring Framework open-source library, and states that chained with the code-injection flaw it yields unauthenticated remote code execution on the device-management gateway itself. Bound to this product, the control means every EPMM API endpoint authorizes its own caller before it processes the request rather than inheriting a verdict from the framework layer that fronts it, and that no EPMM instance is left with those endpoints reachable from an untrusted network. The two identity gaps cited against this entry are cited precisely because they never engage: the attacker presents no credentials at all, so per-account privilege scoping (AC-6) is never consulted, and the account and credential model a UK-CAF-B2 identity-and-access attestation examines is bypassed rather than abused — an estate where every EPMM operator authenticates with strong MFA passes that attestation cleanly while this path stays wide open. The precondition on the network half: restricting reachability bounds who can present the crafted request, but it cannot be complete for an instance that has to answer devices enrolling from outside the corporate network, which is a deployment fact the operator must establish per instance rather than one the packet supplies. Reachability limits are therefore a bound on exposure, not a substitute for endpoint-level authorization. Distinguishing test: from an unauthenticated client on a staging EPMM, request each protected API resource and confirm each is refused before the resource is served.",
+        "evidence": "The packet states that Ivanti Endpoint Manager Mobile (EPMM) contains an authentication bypass vulnerability in the API component that allows an attacker to access protected resources without proper credentials via crafted API requests, and that this results from an insecure implementation of the Spring Framework open-source library. Its attack vector records an authentication bypass (CWE-288) that, chained with the code-injection flaw, yields unauthenticated remote code execution. Entry facts: CVSS 9.8, RWEP 77, poc_available true, CISA KEV-listed 2025-05-19 with active_exploitation confirmed. UK-CAF-B2 (Identity and access control) and NIST-800-53-AC-6 (Least Privilege) are both among the framework control gaps citing this CVE.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the KEV clock opens at the 2025-05-19 listing, and what makes the clock specific to EPMM is where it has to stop. The packet records no live-patch tool registered for this entry and notes that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so an EPMM instance whose update is installed but whose service has not been restarted is still running the vulnerable API component and must be counted as exposed, not as remediated. Completion is therefore measured by restarted instances, not by patch-applied counts in a deployment console. The compensating-control branch of the SLA has to name its precondition rather than imply coverage: the only interim lever is restricting who can reach the EPMM API surface, and for any instance that must answer devices enrolling from outside the corporate network that restriction cannot be complete — it narrows the caller population but does not remove the crafted-request path, and it does not stop the clock. Nothing in the interim branch reduces the exposure to a caller already inside the permitted segment, because the flaw needs no credentials at all.",
+        "evidence": "The packet records CISA KEV listing 2025-05-19 with active_exploitation confirmed and poc_available true, CVSS 9.8 and RWEP 77 for an authentication bypass (CWE-288) in the EPMM API component that, chained with the code-injection flaw, yields unauthenticated remote code execution. patch_available is true; live_patch_available is false, and the live-patch notes state that no live-patch tool is registered for this entry at bulk-import time and 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",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "EPMM is the gateway that manages an enrolled device population, so an instance that was reachable while this bypass was live is a fleet-control-plane exposure rather than a single-server one, and patch-and-close does not address it. The playbook this CVE demands covers: certificate revocation pushed to enrolled devices, device-trust-state invalidation, an audit of configuration profiles pushed during the exposure window, quarantine criteria for downstream devices, and rotation of credentials for any account that authenticated through the EPMM instance during that window. The reason it is needed here specifically is that the packet's chain ends in unauthenticated remote code execution on the management gateway — an attacker at that position acts as the fleet's own control plane, and every profile, certificate and credential it handled during the window is suspect, none of which the vendor patch reverses. Two preconditions, both stated rather than assumed. The playbook is only actionable if the exposure window can be bounded from EPMM logs that predate the suspected compromise; where it cannot be bounded, the whole enrolled population is in scope rather than out. And the packet establishes confirmed in-the-wild exploitation of this CVE, not that any particular instance was compromised — the trigger for invoking the playbook is evidence that the instance's API was reachable during the window, not the existence of the CVE.",
+        "evidence": "The packet identifies the product as Ivanti Endpoint Manager Mobile (EPMM) and places the flaw in its API component: crafted API requests reach protected resources without proper credentials (CWE-288), and chained with the code-injection flaw this yields unauthenticated remote code execution. It records CISA KEV listing 2025-05-19, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available is true; live_patch_available is false, with notes that no live-patch tool is registered and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-42999": {
     "name": "SAP NetWeaver Deserialization Vulnerability",
@@ -26817,7 +27829,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The packet puts remote code or command execution behind a crafted HTTP request to four named Fortinet appliances — FortiFone, FortiVoice, FortiNDR and FortiMail — with no credential and no user interaction anywhere in the path, so the appliance's own request-handling surface is what fails. That is the tier's premise, and it is why the standard 14/30-day appliance-patch window does not apply here: the fixed firmware has to be driven across every affected unit of those four product families on the clock that opened with the 2025-05-14 KEV listing. The packet registers no live-patch path and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so completion is measured per unit as 'running the fixed build and restarted since', not as 'image pushed' or 'update approved' in a management console — a unit that has staged the firmware without restarting is still executing the vulnerable code. The tier's alternative branch, isolating the vulnerable interface, carries a precondition that must be stated rather than assumed: the packet says 'crafted HTTP requests' without distinguishing an administrative interface from a user-facing web surface, so any reachability restriction has to cover every HTTP listener each unit exposes, and on a unit that must answer HTTP from untrusted networks to perform its function isolation is not available at all — for those, the update plus the restart is the only path and no interim control substitutes for it. Distinguishing test: query each affected unit directly for its running firmware and its uptime since the update, rather than accepting a fleet report that lists the four product families as patched to policy.",
+        "evidence": "The packet's vector: 'Fortinet FortiFone, FortiVoice, FortiNDR and FortiMail contain a stack-based overflow vulnerability that may allow a remote unauthenticated attacker to execute arbitrary code or commands via crafted HTTP requests' (CWE-124). CISA KEV-listed 2025-05-14 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 77. patch_available is true; live_patch_available is false, with live_patch_notes recording that no live-patch tool is registered for this entry and 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",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Exploitation is confirmed and a PoC is public, so on these four Fortinet products the question the firmware update does not answer is what executed before it landed. The packet's outcome is arbitrary code or command execution on the appliance by a caller who never authenticated, which means anything left behind — an added administrative account, an altered configuration, a placed file — survives an in-place upgrade, because the upgrade replaces the vulnerable code and not the unit's configuration and stored state. For any FortiFone, FortiVoice, FortiNDR or FortiMail unit whose HTTP surface was reachable from an untrusted network between the 2025-05-14 KEV listing and its restart on the fixed build, the default response is to export and diff the configuration against a known-good baseline, rebuild the unit from that baseline rather than upgrading in place, and rotate every credential the unit held or that authenticated through it. Precondition, and it decides whether this is usable at all: the diff is only meaningful against a configuration baseline captured before the exposure window, and 'we found nothing on the appliance' is not evidence of anything when the only record of the unauthenticated HTTP requests sits on the same device that the packet says an attacker can execute code on. Where no pre-exposure baseline and no off-box record of what the unit served exist, the honest position is that the unit's state is undecidable and rebuilding is faster than proving it clean — not that the upgrade closed the matter.",
+        "evidence": "The packet's vector records a remote unauthenticated attacker executing arbitrary code or commands via crafted HTTP requests against FortiFone, FortiVoice, FortiNDR and FortiMail (CWE-124, stack-based overflow). active_exploitation is confirmed and poc_available is true; CISA KEV-listed 2025-05-14, CVSS 9.8, RWEP 77. patch_available is true and live_patch_available is false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so the fixed build is reached through a restart, and it replaces the vulnerable code rather than the unit's configuration.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-32709": {
     "name": "Microsoft Windows Ancillary Function Driver for WinSock Use-After-Free Vulnerability",
@@ -28380,7 +29417,34 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "CrushFTP is the file-transfer server that faces external counterparties, and the packet's defect is its authentication path failing open: a crafted HTTP Authorization header assumes crushadmin or another known account and hands over administrative control of the server. Nothing is stolen and no privilege is misused first, so the tier's premise holds exactly — a defect in the component that decides who is authenticated on an internet-reachable server does not belong in a standard application-patch window, and the fixed release has to land on the clock that opened with the 2025-04-07 KEV listing rather than at the next scheduled maintenance. The tier's second branch, isolating the vulnerable interface, has a precondition the packet states outright: the takeover grants administrative control unless the instance is fronted by a DMZ proxy instance. That deployment mode bounds this specific path and a directly exposed instance has no such buffer — so it is a per-instance condition to verify, not a control to record once for the product. It also does not hold retroactively: an instance that was directly exposed before a proxy was placed in front of it is an incident to work, not an instance the proxy has protected, and the proxy does not undo an administrative session an attacker already opened. Distinguishing test: enumerate every CrushFTP instance the organization runs and record, per instance, whether it answers HTTP directly from untrusted networks or only through the DMZ proxy instance, and whether it is on the fixed release — a patch-management attestation reporting the product as covered does not distinguish the two deployment shapes, and it is the directly exposed instances that carry the whole exposure.",
+        "evidence": "The packet's vector: a crafted HTTP Authorization header exploits a flaw in the authentication path to bypass authentication and assume the crushadmin (or other known) account, granting administrative control of the file-transfer server (CWE-305). The attack_vector adds that this holds 'unless fronted by a DMZ proxy instance', that it was exploited in the wild March-April 2025, and that the managed-file-transfer class is a proven ransomware/data-extortion initial-access vector (MOVEit lineage). CISA KEV-listed 2025-04-07 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 76. patch_available is true; live_patch_available is false and live_patch_notes is null, so the packet records the vendor update as the remediation and registers no live-patch path.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3",
+          "AU-ISM-1546",
+          "NIS2-Art21-network-security",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records exploitation in the wild in March-April 2025 against a flaw that hands an unauthenticated caller the crushadmin account on a server whose purpose is holding and moving files with external counterparties, and it ties this product class to ransomware and data-extortion initial access through the MOVEit lineage. The update repairs the authentication path and reverts nothing done through it while it was open: accounts and permissions added or altered, server and job configuration changed, credentials readable from the administrative surface, and data already copied out. For any instance that answered HTTP from untrusted networks before the fixed release landed, the default is to treat the server as compromised until shown otherwise — diff the current account list and configuration against a copy captured before the exposure window, rotate every account the server holds including counterparty credentials, and scope the data-exposure question across everything the server could reach, because the packet's outcome is administrative control rather than a single file read. Precondition and scope limit: the packet describes administrative takeover, not code execution, so the justification for rebuilding is that the account and configuration state is untrustworthy — not that the binary is. Whether that is decidable turns on holding a pre-exposure configuration baseline and access records kept off the server; where neither exists, redeploying the fixed release onto a known-good configuration is the shorter path, and the absence of alerts is not a substitute for the diff. Distinguishing test: compare the current CrushFTP account list against the pre-exposure baseline and account for every difference.",
+        "evidence": "The packet's vector places the bypass in the authentication path via a crafted HTTP Authorization header, with the attacker assuming crushadmin or another known account and gaining administrative control of the file-transfer server (CWE-305). active_exploitation is confirmed, and the attack_vector records exploitation in the wild March-April 2025 plus the managed-file-transfer class as a proven ransomware/data-extortion initial-access vector (MOVEit lineage); poc_available is true. CISA KEV-listed 2025-04-07; CVSS 9.8, RWEP 76. patch_available is true, live_patch_available is false and live_patch_notes is null — the packet records the vendor update as the remediation, and that update addresses the authentication path rather than any account or configuration change made through it.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3",
+          "AU-ISM-1546"
+        ]
+      }
+    ]
   },
   "CVE-2009-3459": {
     "name": "Adobe Acrobat and Reader Heap-Based Buffer Overflow",
@@ -28623,7 +29687,28 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet names the sink as the QuickTime parsing path inside Microsoft DirectShow and dates the fix to MS09-028 in 2009, while the KEV listing is dated 2026-05-20 — and that pairing is the whole finding. The remediation question here is not whether a fix exists but which hosts never received one that has been available for that long. On a real estate those hosts are precisely the ones a monthly update report does not describe: hosts built from an old image and never re-baselined, hosts restored from backup, hosts held offline, and hosts embedded in an appliance or process-control system whose vendor owns the Windows build. The control here means enumerating the hosts on which the DirectShow media stack is present and confirming each reports the MS09-028-fixed state of that component directly, rather than accepting a \"fully patched\" verdict from a scan whose baseline begins at a modern build and never asks about a 2009 bulletin. Scope it to what the packet establishes: the packet ties the CWE-787 sink to Microsoft DirectShow's QuickTime parsing path and provides no mapping from that code into Apple QuickTime Player or any other media application, so instructing operators to inventory and strip every media-handling binary on the estate manufactures findings and real removal work against software no evidence implicates — widen only where a verified source identifies another product carrying the same parser. Distinguishing test: select the hosts least likely to sit in the managed update channel — restored, imaged, appliance-embedded — and verify the DirectShow component's patch state on each directly; an estate whose flaw-remediation attestation reads clean because the scanner only reports on the updates it currently tracks still opens crafted QuickTime media straight into the sink. Precondition: this reaches only hosts the inventory can see and the operator can update. The packet records no live-patch path and states MS09-028 requires a reboot, so a host that has taken the update but not rebooted is not yet remediated, and a host whose build the operator cannot change — a vendor-owned appliance image — is remediated by the vendor or by removing its exposure to attacker-supplied media, not by recording it as patched.",
+        "evidence": "Packet fields for this entry: \"Parsing a maliciously crafted QuickTime media file in Microsoft DirectShow corrupts memory (NULL-byte overwrite class), allowing remote code execution when a user opens the file\"; attack_vector records \"a memory-corruption flaw (CWE-787) in the Windows DirectShow QuickTime parser, exploitable by an attacker-controlled media file for code execution when the victim opens it\". cwe_refs CWE-787. cisa_kev true, kev_date 2026-05-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 70. patch_available true, live_patch_available false, live_patch_notes: \"Microsoft patch MS09-028 (2009); requires reboot.\" ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIST-800-53-SI-2 (Flaw Remediation) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The control's \"KEV listing or patch availability, whichever is later\" clause resolves unusually cleanly for this entry: the packet dates the vendor fix to MS09-028 in 2009 and the KEV listing to 2026-05-20, so the clock starts at the listing and there is no patch-development wait to absorb. The entire remediation window is the operator's own discovery-and-reboot time, which turns the SLA from a deployment obligation into a hunt-and-reboot obligation — find the hosts still missing MS09-028 and get them restarted onto the fix inside the clock, and measure completion by the DirectShow component's state on each host after restart rather than by \"update approved\" in a management console. The packet records the fix as reboot-required with no live-patch path, so the restart sits inside the window, not after it. Precondition and honest limit: the clock does not shorten the discovery problem — a host the estate does not know about cannot be counted against it, so this SLA only means anything when it is paired with the direct per-host enumeration this entry's inventory control describes. A host that genuinely cannot be rebooted inside the window — a production-control or vendor-owned appliance host — is a named, dated exception whose exposure to attacker-supplied media is restricted in the interim, not a silently open item. That restriction narrows the delivery path, since the packet requires a user to open the crafted file, but it does not remove the sink: the exception must carry a reboot date, or it is a risk acceptance wearing a mitigation's name.",
+        "evidence": "Packet fields for this entry: the vector records remote code execution \"when a user opens the file\" after Microsoft DirectShow parses a maliciously crafted QuickTime media file (CWE-787). cisa_kev true, kev_date 2026-05-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 70. patch_available true, live_patch_available false, live_patch_notes: \"Microsoft patch MS09-028 (2009); requires reboot.\" NIS2-Art21-patch-management (Vulnerability handling and disclosure) is recorded as a citing gap against this entry.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2008-4250": {
     "name": "Microsoft Windows Server Service RPC Buffer Overflow (MS08-067)",
@@ -28683,7 +29768,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV listing on this entry lands nearly two decades after the vendor fix the packet names, so the clock that matters here is the listing date, not patch availability, and a vulnerability-management program keyed to newly published CVE inflow never generates a work item for it at all. The population still exploitable is by definition the hosts the original update never reached, which is exactly the population a patch-management console cannot report on because it does not manage them. Applied to this flaw the SLA therefore has two non-standard requirements: enumeration must start from what actually answers Server Service RPC on the network rather than from the console's asset list, and completion must be measured as installed build plus a completed reboot, because the packet records live_patch_available false and a fix that requires a reboot, so a host that has taken the update but not restarted is still running the vulnerable service and counts as exposed rather than remediated. The distinguishing test: sweep each segment for hosts answering Server Service RPC and compare each responder's build against the fixed build; a KEV-SLA attestation driven off the management console's patch inventory reports full compliance while the unmanaged responders that carry this CVE are never in the denominator.",
+        "evidence": "Packet: CISA KEV-listed 2026-05-20, active_exploitation confirmed, CVSS 9.3, RWEP 70, poc_available true. patch_available true and live_patch_available false, with live_patch_notes recording 'Microsoft patch MS08-067 (2008); requires reboot. No live-patch primitive.' — a KEV listing dated many years after the vendor patch. The vector records a crafted RPC request to the Windows Server service triggering a buffer overflow (CWE-119) allowing unauthenticated remote code execution, described as wormable.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "This is the remoting-protocol class exactly: a non-HTTP RPC listener that parses an attacker's request before any credential is presented, where the parser is itself the vulnerable code, so web-tier hardening and the perimeter firewall never touch the path. For this flaw the requirement is that the Windows Server service's RPC listener accept connections only from the management and file/print peers that legitimately need it, enforced per segment by host firewall rule and network ACL rather than inherited from an assumption that the host sits on an internal network — which is the assumption a wormable defect defeats, since a worm's requests originate inside the trusted segment and not at the edge. The limit has to be stated rather than left implied: this bounds which hosts can present the crafted request, it does not remove the defect from any host that must keep answering Server Service RPC to its own segment, and it does nothing once a host inside the permitted segment is already compromised or once an infected laptop, contractor machine or removable-media host is introduced behind the ACL. Where the listener cannot be restricted because the host's function depends on it, the only remaining lever is the update and the reboot it requires, since the packet records no live-patch primitive. The distinguishing test: from a general user VLAN on a staging network, send Server Service RPC traffic at a representative host and confirm it is dropped before reaching the service; an estate that blocks this protocol at the perimeter while every internal segment can reach every host still carries the propagation path intact.",
+        "evidence": "Packet vector: 'A crafted RPC request to the Windows Server service triggers a buffer overflow allowing unauthenticated remote code execution — wormable.' attack_vector names it as the MS08-067 flaw exploited by Conficker, CISA KEV-listed 2026-05-20 with active_exploitation confirmed and poc_available true. live_patch_available false; live_patch_notes state the patch requires reboot and that there is no live-patch primitive.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-23812": {
     "name": "node-ipc geo-targeted file-wiper protestware (RU/BY heart-emoji overwrite; peacenotwar dropper in 11.0.0+)",
@@ -31103,7 +32211,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The unit of remediation for this flaw is the JCE extension, not the Joomla platform, so the clock that opened with the 2026-06-16 KEV listing has to be measured against the installed JCE build on every site in the estate. A site whose Joomla core is current still answers index.php?option=com_jce&task=profiles.import if the extension itself was not updated, and estates whose sites are operated by an agency or reseller need the count taken there rather than inferred. The packet records a vendor update with no live-patch path, so there is no way to close the endpoint short of taking each site through the extension update. Nothing about a site's configuration buys time: the path needs no account and no user interaction, only a CSRF token scrapable from any public page, so every publicly reachable install is exposed for exactly the interval between the listing and the update landing on the last site. The distinguishing test is to query each site for its installed JCE version instead of accepting a platform-level 'Joomla is up to date' attestation, and to re-check after any restore from a pre-update backup, which silently reinstates the vulnerable extension on a site that was already remediated.",
+        "evidence": "Packet: CWE-284 improper access control; CISA KEV-listed 2026-06-16 with active_exploitation confirmed; CVSS 9.8, RWEP 70, poc_available true. patch_available true with live_patch_available false and live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' The packet's vector names index.php?option=com_jce&task=profiles.import as reachable by any unauthenticated visitor, requiring only a CSRF token scrapable from any public page. The citing gaps AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management are the patch-timing controls the packet's own remediation note points back at.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "The packet's remediation note says the vendor update 'plus the named compensating controls' is the remediation, and for this product the compensating path lives in the web-server configuration rather than in the application. Two rules are deployable without waiting on the extension update: refuse to hand any file under the JCE upload root to the PHP handler, so the write the attacker obtains through File::upload(..., false, true) cannot become execution, and reject requests carrying task=profiles.import at the reverse proxy so the crafted profile that whitelists executable uploads is never imported. Both have to be inventoried and rehearsed before the next disclosure, because authoring a deny-execute rule for the first time during an active exploitation window is where sites get broken or missed. The preconditions have to be recorded alongside the rules rather than left implicit: the deny-execute rule covers only the directories it names — the packet places the shell in the web root's default images/ folder, so an install whose upload root has been relocated, or that permits writes to any other docroot path, is untouched by it — and the request filter holds only for the request shapes it matches, so an alternate encoding or an alias reaching the same task goes around it. Neither rule evicts a shell already written, so a site that was publicly reachable before the rules went in needs its docroot audited against a known-good source tree, not merely the rules applied. This is also why the cited least-privilege gap does not close on its own: the attacker never authenticates, so per-account privilege scoping is never consulted, and the code runs as the web-server user — constraining what that account's writable directories are permitted to execute is the half that actually bites.",
+        "evidence": "Packet vector: 'File::makeSafe() sanitizes the filename but never restricts the extension, and File::upload(..., false, true) is called with unsafe handling enabled, bypassing Joomla's extension blacklist,' letting the attacker 'write a .php web shell into the web root (default images/ folder), yielding unauthenticated remote code execution and a persistent backdoor running as the web-server user.' 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.' NIST-800-53-AC-6 and UK-CAF-B4 are recorded as citing gaps on this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-54420": {
     "name": "LiteSpeed cPanel Plugin UNIX Symbolic Link (Symlink) Following Vulnerability",
@@ -31660,7 +32792,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "The packet's opening fact about this deployment is that the Commvault Web Server is internet-reachable, and reachability is what makes the rest of the path available: an attacker holding any valid low-privilege Commvault account sends crafted requests to that web surface to create and execute a webshell. Applied to this product, the control means the Commvault Web Server's HTTP surface answers only from an operator subnet or an authenticated VPN rather than from the open internet, and that the host's outbound path is constrained so a webshell running in the web-application context cannot freely reach arbitrary destinations with what the same host holds. Two preconditions have to be stated rather than assumed. First, restricting reachability bounds who can present the crafted request; it does not repair the upload primitive, and it gives nothing against a caller who already has a foothold on a permitted host or against a webshell planted before the restriction was applied. Second, the egress constraint only limits what the webshell itself can reach — the packet records that the stored Azure/M365 application client secrets were read, and once those secrets are off the host they are replayable from any address, so egress filtering does not contain the cross-tenant half at all. The distinguishing test: from an external address and from a general user VLAN, attempt to load the Commvault Web Server's HTTP surface; anything that answers is within reach of a caller holding any valid low-privilege account, and 'the server is behind our firewall' is a claim about topology, not a demonstration that the surface is unreachable from untrusted networks.",
+        "evidence": "The packet states the Commvault Web Server is internet-reachable and that an attacker holding valid (low-privilege) authenticated user credentials can send crafted requests that create and execute a webshell, yielding remote code execution within the web-application context; it states unauthenticated access is not exploitable, so the primitive requires a prior valid-account foothold. It records that in the observed Metallic SaaS breach this foothold was used to read Commvault-stored Azure/M365 application credentials (client secrets), allowing impersonation of customer service principals and lateral movement into downstream M365 tenants. Entry facts: CWE-434, CVSS 8.8, RWEP 72, poc_available true, CISA KEV-listed 2025-04-28 with active exploitation confirmed. patch_available is true; live_patch_available is false, with live-patch notes stating there is no live-patch path for this product class and that remediation is the vendor update plus the named compensating controls until it lands.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For an internet-reachable Commvault Web Server under confirmed exploitation, the IR default has to be configuration capture, rebuild and credential rotation rather than patch-in-place, because the packet's outcome is a webshell running on the host and the vendor update does not evict it. The rotation scope is the part that is specific to this product and larger than the host: the packet records the observed Metallic SaaS breach reading Commvault-stored Azure/M365 application credentials (client secrets) and impersonating customer service principals into downstream M365 tenants, so every application credential the server held must be rotated in the tenants that trust it and the sessions those secrets minted revoked — rebuilding the Commvault host alone leaves the attacker holding credentials that work from anywhere, with no dependency on the rebuilt server. Two preconditions, stated rather than implied. This control's usual trigger is a pre-auth RCE, and this path is not pre-auth — the packet is explicit that unauthenticated access is not exploitable and a prior valid low-privilege account is required — so the runbook trigger for this CVE is evidence that any account could have reached the web server during the exposure window, and an instance whose access logs cannot establish that is treated as in scope rather than out. And the packet establishes confirmed in-the-wild exploitation of the CVE, not that a given instance was compromised; the rebuild decision is driven by unbounded exposure, not by the CVE alone.",
+        "evidence": "The packet states the Commvault Web Server is internet-reachable, that exploitation requires an attacker holding valid low-privilege authenticated credentials (unauthenticated access is not exploitable), and that crafted requests let the attacker create and execute a webshell for remote code execution in the web-application context, providing persistent code execution. It records that in the observed Metallic SaaS breach the foothold was used to read Commvault-stored Azure/M365 application credentials (client secrets), allowing impersonation of customer service principals and lateral movement into downstream M365 tenants — turning a single web-server compromise into cross-tenant cloud access. CISA KEV-listed 2025-04-28, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 72, CWE-434. patch_available true; live_patch_available false, with notes recording no live-patch path for this product class and remediation as the vendor update plus the named compensating controls until it lands.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-24054": {
     "name": "Microsoft Windows NTLM Hash Disclosure Spoofing Vulnerability",
@@ -31874,7 +33028,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The delivery path in this packet removes every user-side gate: a crafted media file arrives over iMessage and CoreAudio decodes the embedded audio stream with no user interaction, so nothing the device holder does or declines to do changes their exposure, and an update ring that permits holder deferral is itself the exposure window. Push the Apple update carrying the CoreAudio fix across the iOS, iPadOS and macOS estate under declarative device management with deferral disallowed, on a clock started at the 2025-04-17 KEV listing, and measure completion by the build each device reports rather than by the update policy having been assigned. The packet records a vendor update and no live-patch path for this product class, so a device that has downloaded but not completed the update still runs the vulnerable CoreAudio parser and counts as exposed. Precondition: this reaches only devices the management channel actually controls — personal and unenrolled devices carrying organizational mail or messaging sit outside the push, and for those the fixed build has to become a condition of that access instead, because there is no user-behaviour guidance that helps against a path requiring no user interaction.",
+        "evidence": "Packet: vector states CoreAudio \"parses audio streams embedded in media files without adequate bounds checking (CWE-119)\" and that the crafted file is \"reachable with no user interaction via zero-click iMessage delivery\", triggering an out-of-bounds write during audio-stream decoding (network attack vector, no privileges, no UI: CVSS 9.8). CISA KEV 2025-04-17, active_exploitation confirmed, RWEP 81, patch_available true, live_patch_available false, live_patch_notes: \"No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this bug inside a chain used in a spyware operation — the CoreAudio out-of-bounds write supplies code execution in the media-processing context and was paired with CVE-2025-31201 to defeat pointer-authentication and escalate toward fuller device compromise — which is a targeted profile rather than opportunistic exploitation. For the cohort plausibly inside that targeting set, the update alone is not fast enough: the packet gives no live-patch path, so every device has to be carried through the vendor update individually. Place that cohort in the platform's reduced-attack-surface mode so message attachments and other untrusted media are not decoded automatically on receipt, which narrows the no-interaction route into the CoreAudio parser during the window between the 2025-04-17 listing and the completed update. The preconditions are the substance of this control, not a footnote. The mode only helps if it was already enabled when the message arrived, so it has to be a standing posture assigned to the high-risk cohort ahead of the next disclosure rather than a response to this one. It constrains automatic decoding only — it does not make the parser unreachable, and a media file the holder deliberately opens from another channel still reaches it. And it evicts nothing already resident: a device suspected of having received this chain belongs on the incident path with the second-stage compromise the packet describes treated as assumed, since enabling the mode afterwards neither removes an implant nor disproves one.",
+        "evidence": "Packet: vector states the out-of-bounds write yields \"the primitive for arbitrary code execution in the media-processing context\" and that \"in observed in-the-wild use it was chained with CVE-2025-31201 (Pointer Authentication / RPAC bypass with arbitrary read-write) to defeat memory-safety mitigations and escalate toward fuller device compromise as part of a sophisticated spyware operation\"; zero-click iMessage delivery with no user interaction; CISA KEV 2025-04-17; active_exploitation confirmed; poc_available true; live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-20035": {
     "name": "SonicWall SMA100 Appliances OS Command Injection Vulnerability",
@@ -32735,7 +33913,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "FortiOS and FortiProxy are the authentication enforcement point for the perimeter, and this defect is that enforcement failing open on a second channel: authentication is enforced on the primary path but not consistently on the Security Fabric (CSF) proxy path served by the Node.js websocket and CSF request handler, so a crafted CSF proxy request is processed with downstream-device super-admin authority. For this CVE the expedited clock runs from the KEV listing of 2025-03-18 through the completed vendor update of every affected FortiGate and FortiProxy unit. The packet records a vendor patch with no live-patch path and states that remediation is the vendor update plus the named compensating controls until it lands, so a unit not yet taken through that update is exposed regardless of how well its administrator accounts are governed. Precondition on the interim measure, stated plainly because it is the part that gets recorded as the mitigation: the packet makes reachability conditional on the Security Fabric being enabled and the HTTP/HTTPS admin interface (or the CSF proxy) being exposed, so the window can be bounded — bounded, not closed — by enumerating which units have Security Fabric enabled and restricting which sources can reach their administrative surfaces. It does not remove the path. A unit that must keep Security Fabric enabled to do its job, and any source already able to route to the admin interface or CSF proxy, still reaches the alternate channel; the packet's only other stated requirement is that the attacker know the upstream and downstream CSF device serial numbers. Distinguishing test: from a segment with no fabric role and no administrative role, attempt to reach the CSF proxy and the HTTP/HTTPS admin interface of a staging unit and confirm both are refused before any request is processed — a patch-compliance report showing the fleet on a supported release says nothing about which of those units still accept CSF proxy requests from arbitrary sources.",
+        "evidence": "Packet: CWE-288, authentication bypass using an alternate path or channel, on Fortinet FortiOS and FortiProxy. A remote, unauthenticated attacker who can reach the FortiGate/FortiProxy management plane and who knows the serial numbers of the upstream and downstream Security Fabric (CSF) devices sends crafted CSF proxy requests over the Node.js websocket and CSF request handler; because authentication is enforced on the primary path but not consistently on this alternate channel, the request is processed with downstream-device super-admin authority. Reachability requires the Security Fabric to be enabled and the HTTP/HTTPS admin interface (or CSF proxy) to be exposed. CISA KEV-listed 2025-03-18, active_exploitation confirmed, CVSS 8.1, RWEP 59. patch_available true; live_patch_available false; live_patch_notes: \"No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at the bypass — it records what the operator does with the super-admin authority it grants: creates persistent admin and SSL-VPN accounts, alters firewall policy, and pivots into the internal network, with exploitation confirmed in the wild. The vendor update undoes none of that. Applied to this device, the control means any FortiGate or FortiProxy unit that met the packet's reachability conditions during the exposure window — Security Fabric enabled and the admin interface or CSF proxy exposed — is handled as a compromised device rather than an unpatched one: export the configuration and diff it against a known-good baseline for administrator and SSL-VPN accounts and policy entries that no change record accounts for, rotate every credential the device holds or terminates, and restore from a verified baseline rather than patching in place. The flaw is an authentication bypass rather than code execution, so the persistence the packet documents is configuration-resident — accounts and policy — which is precisely what a configuration diff and credential rotation address and what a firmware upgrade preserves. Scope limit: this is the response for units whose stated reachability conditions held; a unit where the Security Fabric was never enabled does not meet the packet's precondition for the attack and belongs on the update path, not the rebuild path. The distinguishing test runs against account and policy state, not build number: on a unit already taken through the update, enumerate the administrator and SSL-VPN accounts and the policy table and confirm every entry maps to an authorized change — a fleet reporting the fixed build while carrying an attacker-created super-admin or SSL-VPN account is still under attacker control, and the flaw-remediation attestation reads clean the whole time.",
+        "evidence": "Packet: \"The bypass yields full super-admin on the downstream device, from which the operator creates persistent admin and SSL-VPN accounts, alters firewall policy, and pivots into the internal network.\" Reachability requires the Security Fabric to be enabled and the HTTP/HTTPS admin interface (or CSF proxy) to be exposed. active_exploitation confirmed; CISA KEV-listed 2025-03-18. patch_available true, live_patch_available false — remediation is the vendor update, which changes device code and not device configuration state.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-21590": {
     "name": "Juniper Junos OS Improper Isolation or Compartmentalization Vulnerability",
@@ -32933,7 +34136,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 has the profile a severity-threshold patch policy defers: CVSS 5.5, no public PoC, and the packet's own statement that there is no direct privilege escalation from the bug alone. The control's requirement for this CVE is that the clock is driven by the 2025-03-11 KEV listing and the confirmed exploitation, not by the score — and that the co-patched NTFS/FAT flaws the packet names (CVE-2025-24993 RCE and CVE-2025-24985) are remediated as one unit with it, because the value of this out-of-bounds read is what it hands those memory-corruption bugs: heap contents including cached credentials, cryptographic key material, and addresses useful for defeating ASLR. Treating an information-disclosure primitive as a lower tier than the RCE it is chained with is what leaves the chain viable after a partial rollout. The packet records no live-patch path for this product class, so there is no way to shorten the window other than the fleet's own update cadence, and remediation state must be read per host rather than from an update-approval record. Until the update lands, the only exploit precondition the packet actually names is user interaction — the victim must mount a specially crafted VHD/VHDX, delivered by phishing or inside a bundled archive — so refusing untrusted disk images at the mail and file-share boundary, plus user guidance not to mount them, is the interim lever. State its limit: that lever holds only where mounting disk images is not part of a routine workflow and where the image is recognizable as externally sourced; an image nested inside an archive or dropped on an internal share does not present as untrusted, and it does nothing on a host where a malicious image has already been mounted and the memory contents already read.",
+        "evidence": "Packet: CWE-125; attack_vector — reachability \"requires local presence plus user interaction (CVSS UI:R): an attacker must get a victim to mount a specially crafted VHD/VHDX, typically delivered through phishing or a bundled archive\"; the primitive \"discloses small portions of heap memory, which can leak secrets such as cached credentials, cryptographic key material, or addresses useful for defeating ASLR\"; \"There is no direct privilege escalation from this bug alone, but the leaked data is commonly chained with the co-patched NTFS/FAT memory-corruption flaws (CVE-2025-24993 RCE, CVE-2025-24985) to harden an exploit chain into code execution.\" CISA KEV-listed 2025-03-11, active_exploitation confirmed; CVSS 5.5, RWEP 59, poc_available false; 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.\" citing_gaps: AU-Essential-8-Patch, NIST-800-53-SI-2, NIS2-Art21-vulnerability-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance shape on this entry is the vulnerability report itself. A scan that grades endpoints by their highest-severity finding shows a Windows host as clean of criticals while this KEV-listed CVSS 5.5 out-of-bounds read in the NTFS driver stays unremediated, and a management-console row reading \"update approved\" or \"update downloaded\" is not evidence that a given host's NTFS driver carries the fix. The operational test for this CVE: query each endpoint's installed Windows build against the build that fixes this entry and its co-patched siblings (CVE-2025-24993, CVE-2025-24985) treated as one remediation unit, and close the finding against that build check rather than against the scanner's severity ranking or the absence of a critical on the host. The verification must also cover the estate's real shape — hosts held back by a deferred update ring, and re-imaged or restored hosts that were rebuilt from a pre-fix image, are where a build check finds exposure that a fleet-level compliance percentage hides. Precondition and limit: this control proves remediation state, it does not reduce exposure on a host that is still unpatched; and because the packet records no public PoC, the absence of exploitation signal in scanner or endpoint telemetry is not evidence a host is unaffected — the leak is a read, so a successful exploitation of this primitive leaves little for a scanner to find.",
+        "evidence": "Packet: CVSS 5.5, RWEP 59, poc_available false, CISA KEV-listed 2025-03-11 with active_exploitation confirmed; patch_available true, live_patch_available false; attack_vector names the co-patched NTFS/FAT flaws CVE-2025-24993 (RCE) and CVE-2025-24985 as the bugs this leak is chained with, and states the primitive is an out-of-bounds read disclosing heap memory rather than a privilege escalation. citing_gaps record ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and AU-Essential-8-Patch (Patch operating systems) as insufficient for this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-24985": {
     "name": "Microsoft Windows Fast FAT File System Driver Integer Overflow Vulnerability",
@@ -33468,7 +34694,40 @@
     },
     "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": "Ivanti EPM is the endpoint-management server itself, and this defect is an absolute path traversal (CWE-36) that a remote unauthenticated attacker uses to leak sensitive information — the file-read sink is reached before any authentication decision is taken, so the caller's identity is never consulted and no account-side control is in the path. Bound to this product the requirement is twofold: the EPM endpoint must authenticate the caller before it processes the request at all, and it must resolve a caller-supplied path to its canonical absolute form and confirm the result still sits inside the directory the endpoint is meant to serve, before any file handle is opened — rejecting absolute paths outright rather than filtering the request string. Preconditions: that repair lives in the vendor update — the 2024 January-2025 Security Update, or the 2022 SU6 January-2025 Security Update on the 2022 branch — so this control states the property to verify, it does not implement it. Until the update lands the operator's only lever is reachability: no EPM instance should present that endpoint to a network with no operational need to reach it. That bounds who can send the traversal; it does not close it for anyone who legitimately reaches the console, so it is a compensating restriction with an end date, not a fix. The packet records no live-patch path, so remediation is the vendor update plus those compensating controls until it lands. Distinguishing test: from an unauthenticated client on a staging instance, request an absolute path outside the served directory and confirm refusal before the file is opened.",
+        "evidence": "Packet: cwe_refs CWE-36; vector 'Absolute path traversal in Ivanti EPM before the 2024 January-2025 Security Update and 2022 SU6 January-2025 Security Update allows a remote unauthenticated attacker to leak sensitive information.' cvss 9.8, poc_available true, active_exploitation confirmed, kev_date 2025-03-10. live_patch_available false with live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update (or, for end-of-life products, decommissioning) plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the fix predates the listing — the packet places the vulnerability in builds before the 2024 January-2025 Security Update and the 2022 SU6 January-2025 Security Update, while CISA listed on 2025-03-10 with a due date of 2025-03-31 — so the control's 'whichever is later' clock runs from the KEV listing, and the operator-visible question is what happens in the 21 days the KEV due date permits and the framework patch cadences permit on top of that. The packet's facts do not survive that window: a remote, unauthenticated, CVSS 9.8 disclosure flaw on a fleet-management server, with a public PoC and confirmed in-the-wild exploitation, needs no target-specific reconnaissance to fire. For this CVE the requirement is that the January-2025 Security Update (or 2022 SU6 January-2025 Security Update) is deployed within 4 hours of the 2025-03-10 listing, or that the reachability restriction is recorded as an active compensating mitigation with a bounded end date rather than as SLA compliance. Precondition on the measurement: 'deployed' means each EPM server's own reported version, not an approved or downloaded state in the update console — the packet gives no live-patch path, so nothing is remediated until the server is actually running the updated build.",
+        "evidence": "Packet: kev_date 2025-03-10, with attack_vector recording 'CISA KEV-listed 2025-03-10 (due 2025-03-31) with confirmed in-the-wild exploitation.' The vector places the fix in the 2024 January-2025 Security Update and the 2022 SU6 January-2025 Security Update. cvss 9.8, poc_available true, patch_available true, live_patch_available false, active_exploitation confirmed.",
+        "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": "EPM administers the endpoint fleet, and the outcome the packet records is disclosure: an unauthenticated remote attacker leaking sensitive information off that server, with exploitation confirmed in the wild and a public PoC. Patching a disclosure flaw does not un-disclose it — an instance that was reachable and below the January-2025 Security Update during the exposure window has to be handled as having returned whatever an arbitrary-file read from that host would return, which on a fleet-management server is service-account and configuration material the rest of the estate trusts. The playbook for this product: enumerate what the EPM service account and the server's on-disk configuration can reach, rotate the secrets held there, and review agent and policy changes pushed through the console during the window — all before the vulnerability ticket closes. Preconditions and limits: the packet does not enumerate which files the traversal returns, so the rotation scope is derived from what the host holds rather than from confirmed exfiltration; and the packet records information disclosure with no code-execution outcome, so this is a disclosure-scoped response — credential rotation and change review are warranted, a rebuild is not implied by these facts alone. The playbook is also bounded by exposure evidence: an instance you cannot show was unreachable during the window is in scope by default.",
+        "evidence": "Packet: vector states 'a remote unauthenticated attacker to leak sensitive information'; active_exploitation confirmed, poc_available true, cisa_kev true with kev_date 2025-03-10, rwep_score 73. The packet enumerates no specific files returned by the traversal and records no code-execution impact.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-13159": {
     "name": "Ivanti Endpoint Manager (EPM) Absolute Path Traversal Vulnerability (GetHashForWildcardRecursive)",
@@ -33912,7 +35171,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV clock means different work depending on where a Pentaho deployment sits, because this entry names fixed builds on two branches only — 9.4.0.1 and 9.3.0.2 — while explicitly including 8.3.x among the affected releases. A 9.3.x or 9.4.x server takes a point upgrade and can meet a short window; an 8.3.x server has no in-branch fix named here and has to be carried onto a fixed branch, which is a migration with report, schedule and plugin compatibility work behind it, not a maintenance-window task. Programmes that measure this SLA as days-to-apply-the-vendor-patch will show the 8.3.x estate as perpetually pending while it is in fact fully exposed against a public exploit, so those instances need a dated migration commitment plus a documented interim restriction running from the KEV listing (2025-03-03), not an open counter. No live-patch path exists for this product class, so the analytics outage the upgrade requires belongs inside the KEV window rather than in the next quarterly release train.",
+        "evidence": "KEV-listed 2025-03-03 (due 2025-03-24), active_exploitation \"confirmed\", poc_available true; CVSS 8.8, RWEP 65; patch_available true with the vector naming the fixed versions as 9.4.0.1 and 9.3.0.2 and listing 8.3.x among the affected releases; live_patch_available false — \"No live-patch path for this product class; remediation is the vendor update (or, for end-of-life products, decommissioning) plus the named compensating controls until it lands.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A version-string verdict is unusually unsafe on this CVE because the affected set is not one ordered range: the fixes land at 9.4.0.1 and 9.3.0.2 while 8.3.x is separately called out as affected. Any scanner rule shaped as \"below 9.4.0.1 is vulnerable\" or \"only the current branch is in scope\" mis-verdicts the 8.3.x and 9.3.x estates in opposite directions — the first marks a patched 9.3.0.2 server as vulnerable, the second quietly drops the 8.3.x servers that are exposed. The operational test for a Pentaho estate: stand up a staging server on each branch actually in production use and confirm the scanner marks the 9.3.x server clean only at or above 9.3.0.2 (not merely above 9.3.0.0), and never marks an 8.3.x server clean; then confirm the check reaches every Pentaho instance, including analytics servers stood up by business units outside the platform team's inventory. This control changes exploitability not at all — it exists so the remediation percentage a compliance report shows corresponds to servers that were actually upgraded, which matters here precisely because the entry carries confirmed exploitation and a public PoC.",
+        "evidence": "The vector names the fixed versions as 9.4.0.1 and 9.3.0.2 and states the flaw affects releases \"prior to\" those \"including 8.3.x\"; patch_available true; KEV-listed 2025-03-03 with active_exploitation \"confirmed\" and poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The defect sits in the gap between two components that trust each other: web services accept a property value, and something downstream interprets that stored value as a Spring template — so the write side never treats the value as code, and the interpreting side never re-checks who supplied it. Bound to a Pentaho BA Server deployment the control means each web service that can set a server property authorises the caller for that specific action before storing the value, rather than accepting the write from any caller that can reach the endpoint, and that the property-setting surface is routable only from the administrative segment rather than from wherever analytics consumers and embedded dashboards sit. The limit has to be stated plainly: this narrows who can plant the template, it does not stop the template from being interpreted. Any caller with a legitimate route to those services, and any integration account wired into them, still lands on the same sink — so the 9.4.0.1 / 9.3.0.2 upgrade remains the only closure, and this control only bounds exposure until that upgrade is scheduled. Distinguishing test: on a staging BA Server, call each property-setting web service as an unauthenticated client and again as an ordinary report consumer, and confirm the write is refused before the value is stored.",
+        "evidence": "The vector states the server allows \"certain web services to set property values which contain Spring templates that are interpreted downstream\"; cwe_refs CWE-74 and CWE-94; CVSS 8.8, RWEP 65; KEV-listed 2025-03-03 with active_exploitation \"confirmed\".",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-43939": {
     "name": "Hitachi Vantara Pentaho BA Server Authorization Bypass Vulnerability",
@@ -35284,7 +36574,30 @@
         "adequate": false,
         "gap": "Unauthenticated SQL injection against the WebAdmin login endpoint bypasses access enforcement entirely at the authentication layer itself, before any access-control policy is evaluated."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at 'unauthenticated SQL injection' — it records the observed outcome as the creation of unauthorized administrative accounts on the appliance, which is an implant built out of the product's own account model rather than a file dropped on disk. Applying the December 2020 hotfix closes the injection point at the WebAdmin authentication endpoint and removes nothing an attacker already created through it, so for any CyberoamOS unit that was reachable before the hotfix landed the default disposition is export-config, rebuild or replace, and rotate every credential the appliance holds or terminates — not hotfix-in-place followed by closing the ticket. The audit that decides this cannot be run against the appliance's own account list on its own terms: an attacker-created administrator is indistinguishable from a legitimate one by privilege alone, so the list has to be reconciled against an authoritative roster of who is supposed to hold WebAdmin access, and any account that cannot be attributed to a person is the finding. State the limit rather than recording this as remediation: it is a detection-and-recovery control, not a fix. It tells the operator whether the box is trustworthy today, and on a platform that will receive no further updates a clean answer has a short shelf life.",
+        "evidence": "Packet: CWE-89; CISA KEV-listed 2025-02-06 with active_exploitation confirmed; CVSS 9.8, RWEP 73, poc_available true. attack_vector: 'An unauthenticated remote attacker submits crafted SQL injection payloads to the CyberoamOS WebAdmin login/authentication endpoint, executing arbitrary SQL statements against the backend database — in observed cases used to create unauthorized administrative accounts on the appliance.' live_patch_available false; live_patch_notes record a hotfix distributed December 4, 2020 (including to EOL versions 10.6.2+). NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management are recorded as citing gaps.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet's live_patch_notes carry the whole decision: a hotfix was distributed December 4, 2020, including to EOL versions 10.6.2+, but CyberoamOS is now fully end-of-life/end-of-service per CISA's required action and no further updates will be issued for remaining deployments. That makes the hotfix worth applying to any unit that never took it, and worthless as a posture — it settles this defect and leaves the next WebAdmin defect with no fix path at all. Applied to this product, the control means every surviving CyberoamOS unit carries an end-of-support date in the asset inventory together with a dated replacement decision, because the packet's exploitation path is an unauthenticated remote request to the appliance's web management surface, so reachability is the entire precondition and the inventory is what tells the operator where reachability exists. Until replacement lands, the WebAdmin surface comes off every untrusted segment. Name the precondition instead of claiming the surface is gone: that restriction holds only while it is enforced from every segment an attacker can occupy; it does not cover a unit whose WebAdmin must stay reachable for remote administration, which has to be moved behind an authenticated gateway performing its own enforcement, since the appliance's own authentication is precisely what the injection bypasses; and it does nothing for a unit that already carries an attacker-created administrator. The distinguishing test: from each untrusted segment, attempt to load WebAdmin on every inventoried unit — anything that answers is reachable by the exact request the packet describes, and a risk-acceptance record with no replacement date leaves a KEV-listed device on a retired platform in service indefinitely.",
+        "evidence": "Packet live_patch_notes, verbatim: 'A hotfix was distributed December 4, 2020 (including to EOL versions 10.6.2+), but CyberoamOS is now fully end-of-life/end-of-service per CISA's required action — no further updates will be issued for remaining deployments.' live_patch_available false. Vector: 'An SQL injection vulnerability in the WebAdmin of Cyberoam OS through 2020-12-04 allows unauthenticated attackers to execute arbitrary SQL statements remotely.' CISA KEV-listed 2025-02-06, active_exploitation confirmed, CVSS 9.8, RWEP 73. NIST-800-53-AC-3, AU-ISM-1546 and UK-CAF-B4 are recorded as citing gaps.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "AU-ISM-1546",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2020-15069": {
     "name": "Sophos XG Firewall Buffer Overflow Vulnerability",
@@ -35326,7 +36639,31 @@
         "adequate": false,
         "gap": "Essential Eight patch-applications timelines (days, not years) were not met for a large population of still-exploited XG units."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The XG Firewall is the trust boundary, and the packet's path reaches code execution on the appliance itself from an unauthenticated crafted HTTP/S request to the User Portal's clientless-access Bookmarks feature — no credential is presented at any point. For this product the control means the v17.x estate is driven onto Hotfix HF062020.1 on a perimeter clock measured in hours from the 2025-02-06 KEV listing, not on the operating-system patch cadence the cited Essential Eight and ISO A.8.8 attestations are measured against: a 14- or 30-day window applied to the device that terminates remote access is a window with the boundary open. The cited NIST SC-7 Boundary Protection gap is the reason this needs its own tier — the boundary-protection control an operator would point at is the firewall, and here the firewall is the vulnerable asset, so SC-7 evidence cannot serve as the compensating control for its own defect. The isolation alternative this tier permits carries a precondition that must be stated rather than assumed: the User Portal clientless-access surface is a remote-access feature, so withdrawing it is available only where remote users do not depend on it. Where they do, restricting the portal to known source ranges narrows the caller set but does not remove the unauthenticated overflow path — HF062020.1 is the only thing that closes it, and the packet records no live-patch path, so the hotfix has to be taken on the unit rather than deferred. Distinguishing test: from an address outside any administrative or VPN range, request the User Portal on each v17.x unit; anything that answers is reachable by the unauthenticated overflow, and a patch-compliance report listing the firewall as 'within the current cycle' has recorded the exposure rather than removed it.",
+        "evidence": "Packet: CWE-120 buffer overflow; attack_vector states an unauthenticated attacker sends a crafted HTTP/S request to the XG Firewall's clientless-access User Portal Bookmarks feature, triggering a buffer overflow that yields remote code execution on the firewall appliance itself. Vector: 'Sophos XG Firewall 17.x through v17.5 MR12 allows a Buffer Overflow and remote code execution via the HTTP/S Bookmarks feature for clientless access. Hotfix HF062020.1 was published for all firewalls running v17.x.' CVSS 9.8, RWEP 58, CISA KEV-listed 2025-02-06, active_exploitation 'confirmed', poc_available false. patch_available true; live_patch_available false with live_patch_notes null. Citing gaps include NIST-800-53-SC-7 (Boundary Protection), AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIS2-Art21-vulnerability-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet pairs a pre-auth RCE on the appliance with confirmed in-the-wild exploitation, which makes 'hotfix applied' an incomplete disposition for this device class: HF062020.1 closes the Bookmarks overflow and removes nothing an attacker wrote to the firewall before it landed. Applied to this product, any v17.x unit whose User Portal was reachable from untrusted networks during the exposure window is triaged as potentially compromised rather than closed out — preserve and review the appliance configuration, rebuild the unit from vendor media, and rotate every credential the firewall held or brokered (administrator accounts, User Portal and VPN user credentials, and any authentication secrets carried in its configuration), because code execution on the appliance reaches all of them. The precondition bounds the scope honestly: this escalation is warranted for units whose clientless-access surface was exposed during the window, and a unit that can be shown never to have presented that surface to an untrusted network is remediated by the hotfix alone — the two cases must be separated by evidence, not by assumption. Distinguishing test: on a unit that has taken HF062020.1, compare the running configuration against the last known-good administrative baseline and enumerate administrative accounts and portal users created or modified before the hotfix date; a firewall closed out on version evidence alone has verified the flaw is gone without verifying the attacker is.",
+        "evidence": "Packet: active_exploitation 'confirmed' and CISA KEV listing 2025-02-06 on a flaw whose attack_vector yields remote code execution on the firewall appliance itself from an unauthenticated HTTP/S request. Remediation recorded is the vendor hotfix — 'Hotfix HF062020.1 was published for all firewalls running v17.x' — with live_patch_available false and live_patch_notes null. Cited gaps NIS2-Art21-vulnerability-management (Vulnerability handling) and UK-CAF-B4 (System security) are the handling/assurance controls this entry records as insufficient.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-53104": {
     "name": "Linux Kernel Out-of-Bounds Write Vulnerability",
@@ -35800,7 +37137,32 @@
         "adequate": false,
         "gap": "A public PoC (Exploit-DB 52436) exists for this confirmed-exploited kernel flaw, meaning routine patch-cycle SLAs left an exposure window during which attackers had both an exploit and evidence of active use."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet puts a local low-privilege attacker at a heap-based buffer overflow in the Hyper-V NT Kernel Integration VSP, reached by supplying malformed or oversized data through the integration-service path and corrupting kernel heap memory to reach SYSTEM. That is a kernel-mode component, so the defect executes below every account-level boundary the Windows estate is audited on. For this CVE the control means the Windows update carrying the fix is driven across every affected host on the clock that opened with the 2025-01-14 KEV listing rather than folded into the next monthly rollup cycle, and that completion is measured per host by the installed build against the fixed build for its SKU — not by 'update approved' or 'update downloaded' in the management console. The packet records a vendor patch with no live-patch path registered for this entry, so there is no in-memory remediation to fall back on: a host that cannot take the update inside the window is exposed, not mitigated, and must be tracked and named as such rather than counted compliant. The second half of the control is the load-bearing half on this path. Because the attacker already holds a local low-privilege account, tightening account privilege does not contain the escalation to SYSTEM — a least-privilege attestation passes cleanly while the flaw remains fully exploitable, which is exactly why the AC-6 gap is recorded against this entry.",
+        "evidence": "The packet's attack vector states that a local low-privilege attacker triggers a heap-based buffer overflow in the Hyper-V NT Kernel Integration VSP component by supplying malformed/oversized data through the integration-service path, corrupting kernel heap memory to escalate to SYSTEM; the entry's vector line is 'Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability'. Entry facts: CWE-122, CVSS 7.8, RWEP 74, poc_available true, CISA KEV-listed 2025-01-14, active_exploitation confirmed. patch_available is true; live_patch_available is false and the packet records no live-patch notes for this entry. NIST-800-53-AC-6 (Least Privilege) is among the framework control gaps citing this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-068",
+        "name": "HYPERVISOR-VM-ESCAPE-TENANCY-ASSUMPTION",
+        "description": "The affected component sits in the Hyper-V virtualization stack, and the packet's path is a local low-privilege user reaching SYSTEM through the integration-service path. State the limit precisely rather than blurring it: the packet describes local privilege escalation, not a guest-to-host escape, and the risk write-up should say so. What the packet does defeat is the tenancy assumption operators use to exempt virtualization hosts from expedited patching — 'only trusted administrators have local access to this host' is an assumption, not a control, and the packet's precondition is any local low-privilege account, which on a virtualization host includes service accounts, management agents and any identity permitted to run code there. Applied to this CVE, the control means a KEV-listed defect in a Hyper-V component runs on a compressed clock from the 2025-01-14 listing regardless of whether the host is single-tenant or multi-tenant and regardless of what guests it carries, which is precisely the exemption a quarterly virtualization maintenance window encodes. The precondition that must be stated: the compressed clock only helps where the host can actually absorb the update inside it, and the packet records no live-patch path for this entry, so hosts whose guests cannot be moved inside the window are named individually as accepted exposure with a dated completion — they are not compliant, and the compressed SLA does not make them so.",
+        "evidence": "The packet names the entry 'Microsoft Windows Hyper-V NT Kernel Integration VSP Heap-based Buffer Overflow Vulnerability' and describes the attack as a local low-privilege attacker corrupting kernel heap memory via the integration-service path to escalate to SYSTEM; it does not describe a guest-to-host escape. CISA KEV-listed 2025-01-14 with active_exploitation confirmed and poc_available true; CWE-122, CVSS 7.8, RWEP 74. patch_available is true, live_patch_available is false, and no live-patch notes are recorded for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-55591": {
     "name": "Fortinet FortiOS and FortiProxy Authentication Bypass Vulnerability",
@@ -35921,7 +37283,38 @@
         "adequate": false,
         "gap": "EU operators running Qlik Sense as BI infrastructure face ransomware-grade impact from an incomplete vendor fix; vulnerability handling must include bypass verification, not just patch application."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This entry states outright that the flaw exists because the fix for CVE-2023-41265 was incomplete, which makes it the second defect on the same Qlik Sense header-validation primitive rather than an independent finding — and vulnerability programmes that score each CVE discretely miss exactly that. Two consequences for a Qlik estate. First, an operator who applied the CVE-2023-41265 fix and recorded the header-tunneling risk as remediated is still exposed, so that earlier remediation evidence cannot be carried forward against this CVE and any attestation that reuses it is false. Second, because the same primitive has now failed twice, a third bypass of the Proxy's header validation should be treated as likely rather than hypothetical: the Proxy warrants standing detection for repository-service requests that did not originate from an authenticated front-end session, kept in place beyond the patch rather than retired with the ticket. Prioritisation should follow the sequence position, not the CVE in isolation — this is an unauthenticated remote code execution path at RWEP 72 with confirmed exploitation and a public PoC.",
+        "evidence": "The vector states \"NOTE: this issue exists because of an incomplete fix for CVE-2023-41265\", and describes unauthenticated remote code execution arising from improper validation of HTTP headers (cwe_refs CWE-444); CVSS 9.6, RWEP 72; KEV-listed 2025-01-13 with active_exploitation \"confirmed\" and poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The Qlik Sense Proxy is where this product makes its authentication decision, and the repository application behind it acts on what the Proxy forwards. This CVE is a caller reaching those internal-only repository endpoints by crafting headers the Proxy mis-parses, so the repository never learns the request arrived unauthenticated. Bound to this deployment the control means the repository application authorises each administrative operation on its own evidence rather than inheriting the Proxy's verdict, and that the two highest-consequence operations the entry names — registering a new administrative user, and scheduling an external task — are not reachable by a request whose only claim to identity is a forwarded header. Distinguishing test: on a staging Qlik Sense node, issue a request directly at a repository-service endpoint carrying forged forwarding headers and confirm it is refused before the operation runs. The precondition matters: this bounds the tunneling route only while the repository service is reachable from the Proxy alone. If it also answers on an interface other hosts can route to, the Proxy's header validation is not on that path at all, and neither this control nor the patch to the Proxy addresses that second route — reachability of the repository service has to be verified, not assumed from the deployment being internal.",
+        "evidence": "The attack path in the entry: \"An unauthenticated attacker sends a specially-crafted HTTP request with manipulated headers to the Qlik Sense Proxy, tunneling the request through to internal-only repository service endpoints; the elevated internal session is then used to register a new admin user or schedule an external task, achieving remote code execution.\" cwe_refs CWE-444; CVSS 9.6; KEV-listed 2025-01-13 with active_exploitation \"confirmed\".",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry names eight distinct fixed patch levels — August 2023 Patch 2, May 2023 Patch 6, February 2023 Patch 10, November 2022 Patch 12, August 2022 Patch 14, May 2022 Patch 16, February 2022 Patch 15 and November 2021 Patch 17 — one per release train, so \"Qlik Sense is patched\" is not a statement an estate can make centrally. Each node has to be measured against the fixed patch level of the train it actually runs, and a node on an older train gains nothing from a fix existing on a newer one. Because exploitation is confirmed and the path needs no credentials, the interval that counts runs from the KEV listing (2025-01-13) to the moment each node reaches its train's fixed patch level, not to the moment a change record is raised. No live-patch path is recorded for this entry, so reaching that patch level is the remediation. Where a node cannot get there inside the window, the compensating position is to remove untrusted-network reachability of that node's Proxy and to hunt for the artefacts the entry names — an administrative user nobody provisioned, or a scheduled external task — because those persist through the upgrade and the patch removes neither.",
+        "evidence": "The vector lists the fixed versions as August 2023 Patch 2, May 2023 Patch 6, February 2023 Patch 10, November 2022 Patch 12, August 2022 Patch 14, May 2022 Patch 16, February 2022 Patch 15, and November 2021 Patch 17, and describes the outcome as registering a new admin user or scheduling an external task; patch_available true, live_patch_available false with live_patch_notes null; KEV-listed 2025-01-13 with active_exploitation \"confirmed\" and poc_available true; CVSS 9.6, RWEP 72.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-55550": {
     "name": "Mitel MiCollab Path Traversal Vulnerability (CVE-2024-55550)",
@@ -36164,7 +37557,32 @@
         "adequate": false,
         "gap": "EU-equivalent public-sector operators of niche vertical software need vendor attestation that cryptographic key material is unique per deployment, which standard vulnerability management processes rarely verify."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "USAHERDS ships the same ASP.NET MachineKey (ValidationKey/DecryptionKey) in every install, so the secret an attacker needs to forge material the server will trust comes from the product rather than from the target — and the packet records that APT41 already holds the value. That inverts the usual remediation order: no amount of account hygiene, password policy or session management on the operator's side reduces this exposure, because the forged __VIEWSTATE passes MAC validation before any account is consulted, which is exactly why the cited ISO A.5.15 access-control and NIST IA-2 user-authentication attestations pass cleanly while the path stays open. Gate the deployment on key uniqueness instead: after moving the instance off the affected build (the packet places the flaw in USAHERDS through 7.4.0.1), verify that the instance's machineKey validation and decryption values are unique to that instance and match neither the product-shipped constant nor any other instance you operate, and hold the server out of service until they do. Re-run the check after every restore-from-image, VM template clone or server rebuild, since those are the operations that quietly reintroduce the shipped key onto a host that was previously remediated. The precondition that must be stated: rotating the key closes the forgery path forward only — it does not evict an attacker who already achieved code execution through a forged __VIEWSTATE before rotation, so an instance exposed while carrying the shipped key needs forensic triage of the web application's process and content in addition to the key change. Distinguishing test: read the machineKey values from two independently deployed instances and from a freshly restored image; identical values on any pair means the deserialization path is still forgeable by anyone holding the constant.",
+        "evidence": "Packet: CWE-798 use of hard-coded credentials; vector 'Acclaim USAHERDS through 7.4.0.1 uses hard-coded credentials.' attack_vector states USAHERDS ships with a static, product-wide ASP.NET MachineKey (ValidationKey/DecryptionKey), that an attacker who obtains the key value — 'APT41 acquired it through undisclosed means' — can forge a __VIEWSTATE payload that passes MAC validation, and that the server deserializes it, executing attacker code. CVSS 8.1, RWEP 42, CISA KEV-listed 2024-12-23, active_exploitation 'confirmed', poc_available false. patch_available true; live_patch_available false with live_patch_notes null. Cited gaps include ISO-27001-2022-A.5.15 (Access control), NIST-800-53-IA-2 (Identification and Authentication, Organizational Users) and NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "ISO-27001-2022-A.5.15",
+          "NIST-800-53-IA-2",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry opened with the 2024-12-23 KEV listing against confirmed in-the-wild exploitation, and the remediation shape leaves no shortcut: the packet records a vendor patch with no live-patch path, so the only way the fix reaches a USAHERDS instance is by taking it off the affected build (through 7.4.0.1) and through the vendor update, with the service interruption that implies. For this application the control means that upgrade is scheduled against the KEV clock rather than against the general application-patching cadence the cited AU ISM 1546 and NIST SI-2 attestations are measured on — a line-of-business web application inside a periodic patch cycle is precisely the population that carried this flaw into a KEV listing years after the affected build was identified. The condition to state plainly: meeting the SLA on version alone is not sufficient remediation here, because the vulnerable primitive is a shipped secret rather than a code defect the update independently guarantees to re-key; the version move is the SLA-bearing action and the key-uniqueness verification recorded alongside it is what makes the instance actually non-forgeable. Distinguishing test: for each USAHERDS instance, compare the deployed build against the affected range and the completion date against the 2024-12-23 listing; an instance recorded as 'scheduled in the next maintenance cycle' is an accepted exposure on an actively exploited path, not a remediation.",
+        "evidence": "Packet: CISA KEV-listed 2024-12-23, active_exploitation 'confirmed', RWEP 42, CVSS 8.1. Vector places the flaw in 'Acclaim USAHERDS through 7.4.0.1'. patch_available true; live_patch_available false with live_patch_notes null, so no live-patch path is recorded for this entry. Cited gaps include NIST-800-53-SI-2 (Flaw Remediation), AU-ISM-1546 (Patch operating systems and applications), NIS2-Art21-vulnerability-management (Vulnerability handling) and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-ISM-1546",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-12356": {
     "name": "BeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) Command Injection Vulnerability",
@@ -36582,7 +38000,32 @@
         "adequate": false,
         "gap": "Patch-operating-system control is necessarily reactive to a pre-disclosure zero-day exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "CLFS is a kernel-mode driver of Windows itself, so the heap overflow the packet describes executes below every account boundary the endpoint estate is audited on: the attacker begins as a low-privileged local user who is legitimately entitled to be on the host and ends as SYSTEM. That is why AC-6 and UK-CAF-B2 are recorded as insufficient against this entry — constraining what the user's account may do never contains an escalation that does not consult the account model, and a least-privilege or identity-and-access attestation reads clean while the path stays fully open. The enforceable lever is the remediation window: drive the Windows update carrying the CLFS fix across the whole affected fleet on the clock that opened with the 2024-12-10 KEV listing rather than folding it into the next monthly rollup, and measure completion by each host's installed build rather than by \"approved\" or \"downloaded\" in the management console. The packet records a vendor patch and no live-patch path, so the fix does not reach the driver already resident in a running kernel — a host on which the update is pending completion still runs the vulnerable CLFS driver and counts as exposed, not remediated. Sequence the fleet by where a low-privileged foothold is most likely to already exist: the packet describes this escalation as a step commonly taken before ransomware deployment, so ordinary user endpoints where initial-access payloads land are the priority, not only servers.",
+        "evidence": "Packet: CWE-122 heap-based buffer overflow in the Windows CLFS driver. attack_vector: \"A local attacker with low privileges triggers a heap-based buffer overflow in the CLFS kernel driver via crafted log-file structures, escalating to SYSTEM privileges — commonly used as a precursor step before ransomware deployment.\" CISA KEV 2024-12-10, active_exploitation confirmed, RWEP 81, CVSS 7.8, patch_available true, live_patch_available false. Citing gaps include NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B2 (Identity and access control).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Because the escalation runs inside a kernel driver and never consults the account model, the transition itself is the only place it becomes visible — and the packet states precisely what an exploit doing this emits: a low-privileged local process driving the CLFS logging path with crafted log structures, and then that process or its lineage acting with SYSTEM authority. Build the rule on that pairing: CLFS log creation or manipulation by a process running as an ordinary user, followed within a short window by a SYSTEM-authority token on that process or a SYSTEM-integrity child in the same lineage. Explicitly do not key it on the driver or host faulting — a working exploit corrupts the heap without crashing, so a crash-derived rule is blind on exactly the runs that succeed — and do not key it on the name or hash of a known tool, because the packet records a public proof-of-concept and a recompiled binary defeats that on the first attempt. Distinguishing test: detonate the available proof-of-concept on an instrumented staging host and confirm the rule fires on the log-manipulation-then-SYSTEM sequence, rather than confirming only that kernel telemetry is being collected. Preconditions: this detects, it does not prevent — the escalation completes, and the value is the dwell time removed before the ransomware step the packet names; and the alert must leave the host, because a process that has just reached SYSTEM can stop a local agent and clear a local log, so a rule whose only evidence stays on the compromised endpoint is silent at the moment it fires.",
+        "evidence": "Packet: attack_vector describes a low-privileged local attacker triggering the CLFS heap overflow \"via crafted log-file structures, escalating to SYSTEM privileges — commonly used as a precursor step before ransomware deployment\"; poc_available true; active_exploitation confirmed; CISA KEV 2024-12-10; CWE-122.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2024-51378": {
     "name": "CyberPanel Incorrect Default Permissions Vulnerability",
@@ -37157,7 +38600,30 @@
         "adequate": false,
         "gap": "Least-privilege wasn't enforced at the Expedition database layer, which stored recoverable firewall credentials and API keys reachable via a single unauthenticated SQLi."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Expedition is not itself a firewall, but the packet has its database holding PAN-OS password hashes, usernames, device configurations and device API keys — so an unauthenticated SQL-injection read against Expedition hands over the credentials to the perimeter, not merely to Expedition. The vendor update stops further extraction and does nothing about material already extracted, which is why patch-in-place is the wrong default here. Applied to this product: every PAN-OS credential and every device API key the instance held is treated as disclosed and rotated on the firewalls themselves, and the Expedition host is rebuilt rather than patched in place — the same flaw lets the attacker create arbitrary files on the Expedition system, and a file written before the update survives it. Scope the rotation to every device whose configuration was ever imported into that instance rather than to the current project only, because the packet describes disclosure of the database contents rather than of one record; where the import history cannot be reconstructed, the rotation scope is the whole estate the instance was ever used for. Precondition on the sequencing: rotating firewall credentials while the Expedition host is still standing and unrebuilt re-exposes the new material the moment the estate is re-imported, so rebuild precedes re-import. patch_available is true and no live-patch path is registered for this entry, so the instance goes through the vendor update — but an estate with rotated credentials and an unrebuilt Expedition host is half-remediated, not remediated.",
+        "evidence": "Packet: Palo Alto Networks Expedition SQL Injection Vulnerability, CWE-89, CISA KEV-listed 2024-11-14, active_exploitation confirmed, CVSS 9.1, RWEP 66, poc_available true. Vector: 'An SQL injection vulnerability in Palo Alto Networks Expedition allows an unauthenticated attacker to reveal Expedition database contents, such as password hashes, usernames, device configurations, and device API keys. With this, attackers can also create and read arbitrary files on the Expedition system.' The attack_vector identifies the dumped hashes as PAN-OS firewall password hashes and the keys as device API keys. patch_available is true; live_patch_available is false with no live-patch entry recorded for this CVE.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-046",
+        "name": "PEN-TEST-SCOPE-INCLUDES-SECURITY-PRODUCTS",
+        "description": "Expedition is a security vendor's own product and, on the packet's description of what its database holds, it functions as a credential store for the firewall estate — the category this control says must be attacked rather than assumed to be a defense. The defect is a pre-authentication SQL injection in its web application: the single most-tested class of web finding, reachable by anyone who can route to the interface, sitting in a product that testing programs routinely classify as tooling and leave out of scope. For this CVE the control means the Expedition web application is named explicitly in test and red-team scope with its unauthenticated request surface in scope, and that the PCI-DSS software-engineering requirement cited against this entry is read for what it covers — the entity's own bespoke code. Expedition is purchased software, so no secure-coding attestation the operator signs ever inspects the query carrying this injection, and the requirement can be fully met while this path stays open. Distinguishing test: direct the same unauthenticated injection testing the programme applies to its bespoke applications at a staging Expedition instance; if the scope document contains no line item under which that test could be authorized, the product has been treated as a defense rather than as attack surface. Precondition and limit: this control changes when the operator finds such a defect, not whether it exists — it produces no remediation on its own, and the vendor update plus the credential rotation and host rebuild remain the remediation for this CVE.",
+        "evidence": "Packet: Palo Alto Networks Expedition SQL Injection Vulnerability, CWE-89, CISA KEV-listed 2024-11-14, active_exploitation confirmed, CVSS 9.1, RWEP 66, poc_available true. The vector states the attacker is unauthenticated and that the injection reveals Expedition database contents including password hashes, usernames, device configurations and device API keys, and permits creating and reading arbitrary files on the Expedition system — a security-vendor product holding the estate's privileged material. The citing gap PCI-DSS-4.0-6.2.4 is recorded in the packet as 'Software engineering techniques or other methods are defined and used by personnel to prevent or mitigate common software attacks'.",
+        "gap_closes": [
+          "PCI-DSS-4.0-6.2.4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-9463": {
     "name": "Palo Alto Networks Expedition OS Command Injection Vulnerability",
@@ -38048,7 +39514,32 @@
         "adequate": false,
         "gap": "Authenticator-management guidance assumes operator-issued credentials that can be rotated; a compiled-in credential cannot be rotated by the operator at all."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "SolarWinds Web Help Desk ships a developer login credential compiled into the application rather than read from configuration, so the authenticator an attacker needs comes out of the product itself and is identical on every install — the packet records it being recovered by decompilation. That is precisely why the identity controls cited against this entry cannot reduce the exposure: the account does not exist in the operator's account store, so account-management review, authenticator-strength policy and identity-assurance requirements never examine it, and no password rotation, MFA rollout or joiner-mover-leaver process an operator runs touches it. Gate the instance on the absence of that shipped authenticator instead: after applying the vendor update, attempt authentication to the WHD instance with the built-in credential and require refusal before the instance returns to service; then re-run the same check after any restore-from-image, template clone or appliance rebuild, since those are the operations that quietly reinstate a pre-update build on a host that had already been remediated. Preconditions: the check proves only that this one shipped credential is closed, on the instance you actually tested — it says nothing about other secrets embedded in the same build, and it cannot be run against an instance whose version you cannot establish. And because exploitation is confirmed and the credential grants read and write over help-desk ticket data, an instance that was reachable before the update also needs its ticket contents treated as disclosed — the packet notes tickets carrying reset passwords — rather than closed on the update alone.",
+        "evidence": "Packet: cwe_refs CWE-798; attack_vector states WHD 'ships with a developer login credential hardcoded directly into application code rather than pulled from configuration; any remote attacker who knows the credential (recovered via decompilation, as Horizon3.ai did) can authenticate and read or modify all help-desk ticket data, including tickets carrying reset passwords.' vector: 'allowing remote unauthenticated user to access internal functionality and modify data.' cvss 9.1, poc_available true, active_exploitation confirmed, kev_date 2024-10-15, patch_available true; live_patch_notes is null, so the packet records no live-patch path and no reboot detail.",
+        "gap_closes": [
+          "NIST-800-53-AC-2",
+          "NIST-800-53-IA-2",
+          "NIST-800-63B-rev4",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Exposure on this entry is not gated on any target-specific work. The credential is a constant inside the shipped binary, so once it is recovered from any one copy — the packet records exactly that, by decompilation — every unpatched, reachable Web Help Desk instance is authenticable by anyone holding it: no brute force, no user interaction, no phishing step. The attacker also arrives as a valid built-in account, so the instance's authentication log records a successful login rather than a failure, and volumetric or lockout-based signals have nothing to fire on. A vulnerability-management cadence that schedules a 9.1 application flaw into the next maintenance window is therefore counting a window whose only precondition is reachability. The requirement for this CVE: the vendor update deployed within 4 hours of the 2024-10-15 KEV listing, or the WHD web surface withdrawn from any network the operator cannot vouch for until it is — with that withdrawal recorded as an active compensating mitigation carrying an end date, not as SLA compliance. Precondition on the interim step: restricting reachability bounds who can present the credential, it does not invalidate the credential, so anyone who still legitimately reaches the instance retains the path until the update is applied.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-10-15, active_exploitation confirmed, poc_available true, cvss 9.1, rwep_score 70, patch_available true. attack_vector records the credential as hardcoded in application code and recovered via decompilation (Horizon3.ai), and the vector records access by a 'remote unauthenticated user to access internal functionality and modify data.' live_patch_notes is null.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-ISM-1546"
+        ]
+      }
+    ]
   },
   "CVE-2024-9380": {
     "name": "Ivanti Cloud Services Appliance (CSA) OS Command Injection Vulnerability",
@@ -39530,7 +41021,28 @@
         "adequate": false,
         "gap": "Essential Eight application hardening relies on macro-execution restrictions in Office, exactly the enforcement this flaw defeats, so the mitigation is silently bypassed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The mechanism that fails on this entry is Office's macro-blocking of untrusted content: the packet has a user lured into opening a malicious Publisher file and the security-feature bypass causing embedded macros to run even though policy would normally stop them. That is why a user-application-hardening attestation passes cleanly while the estate is exposed — the attestation is read off the policy setting, and the policy setting is not what failed; the handler enforcing it is. For this CVE the control means the macro-blocking policy is regression-tested by detonating a Publisher document on a managed image, not only Word and Excel samples, and that the Publisher case stays in the battery permanently instead of being retired once this CVE is patched, because CWE-693 bypasses recur against the same primitive and each Office handler enforces the policy separately. The same specificity applies to the endpoint side: application-control and EDR policies written around Office-borne execution must name the Publisher handler explicitly rather than assuming the Word/Excel process images cover the suite. Precondition, stated plainly: this is a verification and detection control, not containment. It proves whether the enforcement path holds for the cases tested and produces telemetry when it does not; it does nothing for a host that has not yet taken the vendor update, and because the packet puts execution in the user's own context, nothing here stops the code from running once the document is opened on an unpatched host.",
+        "evidence": "Packet: CWE-693, entry name \"Microsoft Publisher Protection Mechanism Failure Vulnerability\"; attack_vector — \"A user is lured into opening a malicious Publisher file; the security-feature bypass causes Office to run embedded macros even though macro-blocking policy would normally stop untrusted content, giving the attacker code execution in the user's context.\" CISA KEV-listed 2024-09-10 with active_exploitation confirmed; CVSS 7.3, RWEP 46, poc_available false. citing_gaps record AU-Essential-8-App-Hardening (User application hardening) and ISO-27001-2022-A.8.7 (Protection against malware) as insufficient for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Remediation on this entry is the vendor update, and the packet removes the standard reason for deferring it — there is no live-patching primitive for the product and the update requires no reboot, so the fix reaches an endpoint without an outage and the KEV clock that opened 2024-09-10 is the governing deadline. The measurement problem is specific to this CVE: the packet's own vector places the bypass in Office's macro-blocking, so the vulnerable component is an application inside the productivity suite rather than the OS, and an estate that tracks OS patch compliance while treating the suite as self-updating cannot say which endpoints still carry the vulnerable Publisher handler. Completion has to be measured per host against the installed suite build on every endpoint where Publisher is present, which first requires knowing where it is installed — Publisher is routinely absent from application inventories because it is rarely used deliberately, and an endpoint nobody counts is an endpoint nobody patches. Hosts held on a deferred update channel remain exposed for the full deferral length after the fix has shipped, so that deferral is the exposure window and should be recorded as one. Precondition on the closure claim: this control governs how fast the fix lands and how completion is proven; it does not reduce risk on a host still awaiting the update, where the only remaining lever is the delivery path and the detonation-tested enforcement covered by the regression control above. The packet records no public PoC, which lowers commodity-exploitation likelihood but does not move the clock — exploitation is already confirmed.",
+        "evidence": "Packet: 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-10 with active_exploitation confirmed; poc_available false; CVSS 7.3, RWEP 46. attack_vector places the bypass in Office's macro-blocking of untrusted content. citing_gaps record NIST-800-53-SI-2 (Flaw Remediation) as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-40766": {
     "name": "SonicWall SonicOS Improper Access Control Vulnerability",
@@ -39826,7 +41338,31 @@
         "adequate": false,
         "gap": "Access enforcement is bypassed because authorization is checked on requestUri while rendering follows overrideViewUri — the control assumes a single consistent decision point, which this split defeats."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "OFBiz takes its authorization decision against the requestUri but renders the screen named by overrideViewUri, so the function that actually runs — ProgramExport, which evaluates a Base64-encoded Groovy program as the OFBiz process user — never authorizes its own caller. Bound to this product, the control means every OFBiz screen and export/scripting endpoint authorizes the caller at the point of execution rather than inheriting a verdict taken on the routing key, and the views that can reach a code-evaluation path are refused for any request whose entry point was an unauthenticated public endpoint. The cited access-enforcement control is precisely what fails here: the attacker prefixes a public endpoint (the packet names forgotPassword) so the request never reaches OFBiz's user/role permission model at all — a deployment can pass an access-enforcement review of its permission matrix while this path stays fully open, which is why AC-3 is recorded against this entry rather than credited. The second half of the control, keeping the OFBiz admin/scripting surface off untrusted networks, carries a precondition that must be stated: it bounds exposure only for instances that have no business serving untrusted users, so an internet-facing OFBiz storefront or partner portal cannot rely on it and must take the vendor update; and neither measure evicts a Groovy payload already executed as the process user on an instance that was reachable during the exposure window. Distinguishing test: on a staging instance, request a public endpoint with the view overridden to ProgramExport and confirm the request is refused before the screen renders.",
+        "evidence": "Packet: CWE-863; attack_vector — \"OFBiz checks authorization against the requestUri but renders the screen named by overrideViewUri. An unauthenticated attacker prefixes a public endpoint (e.g. forgotPassword) and overrides the view to ProgramExport, then posts a Base64-encoded Groovy program that executes as the OFBiz process user.\" CVSS 9.8, RWEP 67, poc_available true; CISA KEV-listed 2024-08-27 with active_exploitation confirmed. citing_gaps record NIST-800-53-AC-3 (Access Enforcement) and UK-CAF-B4 (System security) as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records a vendor fix, a public PoC and confirmed in-the-wild exploitation on an unauthenticated code-execution path, so the OFBiz upgrade off the affected 18.12.14-and-earlier line to 18.12.15 runs on the clock that opened with the 2024-08-27 KEV listing, not in the next ERP change window. The usual deferral argument does not exist on this entry: the packet states there is no live-patching primitive for this product and that the vendor update requires no reboot, so the only remaining constraint is the application's own restart/change process — an ERP change-freeze is a scheduling preference here, not a technical blocker, and recording one as a compensating control leaves an unauthenticated Groovy-execution path open. Measure completion from the deployed webapp's reported version rather than from a patch-management row saying \"OFBiz updated\": these deployments are commonly customized builds where the inventory record and the running instance diverge. Precondition on the closure claim: applying the update ends new exploitation of this path but does nothing about an instance that was reachable while unpatched — anything already executed as the OFBiz process user survives the upgrade, so an instance exposed during the window needs forensic triage rather than a patch-and-close.",
+        "evidence": "Packet: patch_available true; vector — \"This issue affects Apache OFBiz: through 18.12.14. Users are recommended to upgrade to version 18.12.15, which fixes the issue.\" live_patch_available false, live_patch_notes \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" CISA KEV-listed 2024-08-27, active_exploitation confirmed, poc_available true, RWEP 67, CVSS 9.8. citing_gaps: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, NIS2-Art21-vulnerability-handling.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-7971": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2024-7971)",
@@ -39863,7 +41399,30 @@
         "adequate": false,
         "gap": "Malicious-code protection at the endpoint did not stop a memory-corruption chain that escaped the browser sandbox and loaded a kernel rootkit (FudModule)."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet gives a clean remediation and a precise boundary: the vendor update, no reboot required, no live-patching primitive, with builds prior to 128.0.6613.84 affected. The control for this CVE is therefore that the browser's security channel is not held behind an enterprise update ring's validation cycle, and that completion is measured per host against the installed browser build rather than against 'auto-update is enabled in policy' — the latter is the state a managed fleet is usually attested on, and it is satisfied while version-pinned, kiosk, and long-uptime roaming hosts sit behind the fixed build. The urgency here is not carried by exploit availability, which is the second half of why this needs enforcing: the packet records poc_available false alongside a 2024-08-26 KEV listing with confirmed in-the-wild exploitation, so a prioritization pipeline that ranks on public-PoC presence will under-rank a bug a named actor was already running in a full chain. The precondition to state is a measurement one: the fleet number has to be the build each host is actually running, not the build the management console reports as approved or downloaded, because an approved-but-not-running update leaves the host exposed on the same terms as one that never received it.",
+        "evidence": "Packet vector: 'Type confusion in V8 in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to exploit heap corruption via a crafted HTML page. (Chromium security severity: High)'. CWE-843; CISA KEV-listed 2024-08-26 with active_exploitation confirmed; CVSS 9.6, RWEP 56; poc_available false. patch_available true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' Citing gaps AU-Essential-8-App-Hardening, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and UK-CAF-B4.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet describes this bug as the opening stage of a chain rather than as a standalone browser fault: a victim visits an attacker-controlled page, crafted JavaScript triggers the V8 type confusion, the resulting heap corruption yields renderer code execution, and Citrine Sleet chained that with a Windows sandbox escape to deploy the FudModule rootkit. Commodity incident response handles only the visible half — a browser anomaly on a user's workstation — and resolves it with a browser reset or a decision scoped to the browser, which is exactly the under-escalation this control exists to stop, because the terminal state of the chain is kernel-level persistence that outlives anything done to the browser. For this CVE the runbook needs a trigger a responder can act on in the moment: renderer-level compromise indicators on a host that browsed externally during the exposure window escalate to full host triage and to the explicit question of whether the second-stage escape ran, rather than being closed out by confirming the browser has since been updated — the update closes the entry point and says nothing about a host already through it. The precondition worth naming is that the actor attribution in this packet was available only after the fact, so the escalation criterion has to be the chain shape (browser renderer execution followed by evidence of privilege escalation or kernel-level persistence), not an actor name the responder will not hold on day one.",
+        "evidence": "Packet attack_vector: 'A victim visits an attacker-controlled page that runs crafted JavaScript triggering a V8 type confusion; the resulting heap corruption yields renderer RCE, which Citrine Sleet chained with a Windows sandbox escape to deploy the FudModule rootkit.' CISA KEV-listed 2024-08-26 with active_exploitation confirmed; poc_available false. NIS2-Art21-incident-handling is recorded as a citing gap on this entry.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-39717": {
     "name": "Versa Director Dangerous File Type Upload Vulnerability",
@@ -40230,7 +41789,30 @@
         "adequate": false,
         "gap": "Standard endpoint monitoring rarely flags a race-condition kernel EoP; without behavioral SYSTEM-token-theft detection the escalation step is invisible, and no patch existed to remediate during the zero-day window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The defect is in the Windows kernel itself, so it executes below every account-level boundary the endpoint estate is audited on, and the packet's path — low-privilege code execution first (its example is a Chromium renderer sandbox escape), then a kernel race corrupting kernel state to reach SYSTEM — means the attacker is already an ordinary user when the escalation begins. For this CVE the control means the Windows update carrying the fix is driven across the whole affected endpoint fleet on the KEV clock that opened 2024-08-13 rather than folded into the next monthly rollup, and that completion is measured per host as installed build against the fixed build for its SKU, not as 'update approved' or 'update downloaded' in the management console. The packet records no live-patching primitive and an update that requires a reboot, so a host that has taken the update but not restarted is still running the vulnerable kernel and must be counted as exposed rather than remediated — the pending-reboot population is the real residual, and it is exactly the population a patch-compliance dashboard reports as green. Tightening account privilege does not contain this path: the escalation begins in whatever context the initial low-privilege execution landed in and terminates at SYSTEM, so a least-privilege attestation passes cleanly while the flaw stays fully exploitable. Distinguishing test: query the fleet for hosts whose installed build carries the fix but whose uptime predates that installation, and confirm those hosts are still counted against the KEV clock rather than reported as patched.",
+        "evidence": "Packet: CISA KEV-listed 2024-08-13, active_exploitation 'confirmed', RWEP 59, CVSS 7.0. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Attack vector: 'After gaining initial low-privilege code execution (e.g. via a Chromium renderer sandbox escape), the attacker triggers a Windows Kernel race condition to corrupt kernel state and elevate to SYSTEM.' CWE-591.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Between the 2024-08-13 KEV listing and the completed reboot of every affected host, detection is the only thing standing between a low-privilege foothold and SYSTEM on this path. Anchor it on what the packet actually documents: the attacker already holds low-privilege code execution, repeatedly attempts a kernel race to corrupt kernel state, and ends holding a SYSTEM token. The durable observable is therefore the privilege transition itself — a sandboxed or low-integrity process acquiring a SYSTEM token or having its integrity level raised — together with the repeated kernel-object access the race requires from a process that has no reason to make it. Do not build the rule on process crashes or respawns: an exploit that retries the race in a tight loop inside one process never crashes, so a crash-correlated rule reports clean through the real attempt, and the packet establishes no crash signal to key on. Do not build it on tool signatures either — the packet records no public PoC, so there is no stable IoC set and a signature-shaped rule reports clean while the behaviour is present. Alert on the transition within 60 seconds. Two preconditions bound this control and must be stated rather than assumed. It detects, it does not prevent: the kernel race stays reachable until the rebooted fixed build lands, so it never substitutes for the update window. And it holds only where telemetry leaves the host continuously — once the race is won the attacker holds SYSTEM and can stop or blind a local agent, so on hosts with no reporting agent, or where telemetry is merely pulled on a schedule, this contributes nothing and the reboot window is the entire defence. Distinguishing test: on a staging host, have a low-integrity process acquire a SYSTEM token and confirm the alert reaches the off-host collector inside 60 seconds — validate the privilege transition, not a synthetic crash.",
+        "evidence": "Packet: attack vector states 'Exploitation depends on repeatedly winning the race' and that escalation follows initial low-privilege code execution, ending at SYSTEM. poc_available false. CISA KEV-listed 2024-08-13, active_exploitation 'confirmed'. live_patch_available false with the vendor update requiring a reboot. NIST-800-53-SI-4 (System Monitoring) is recorded as a citing framework gap on this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-4"
+        ]
+      }
+    ]
   },
   "CVE-2024-38193": {
     "name": "Microsoft Windows Ancillary Function Driver for WinSock Privilege Escalation Vulnerability",
@@ -40304,7 +41886,31 @@
         "adequate": false,
         "gap": "Malicious-code protection leans on SmartScreen/Protected View reputation checks that this bypass specifically defeats, so SI-3 controls that assume MotW is enforced are silently undermined."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "This CVE is the protection mechanism itself failing rather than a flaw in what it protects: the packet's path stages a payload on a WebDAV share and lures the user into copy-pasting it locally, and because the copied file lacks Mark-of-the-Web, opening it skips SmartScreen and Protected View and runs with no reputation check. Nothing about the file's content differs — only its origin metadata. For a Windows estate the control means the MOTW/SmartScreen class gets a standing regression battery re-run on every Windows update rather than a one-off check closed with this CVE's ticket: stage a benign marker file on a WebDAV share, bring it to a managed workstation by exactly the copy-paste path the packet describes, and confirm the resulting local file carries the zone marking and that opening it triggers the reputation check. The EDR half of the battery matters as much, because the packet's behaviour is quiet: a rule keyed on a suppressed SmartScreen prompt, a blocked-execution event, or a known tool signature will never fire here — there is no prompt to suppress and no unusual tooling, just an ordinary copy and an ordinary open. The signal that matches what the packet documents is the pairing of an outbound WebDAV mount to a host outside the estate with subsequent execution of a file copied from that mount carrying no zone marking; a battery that does not replay that pairing is validating a synthetic stand-in rather than the real bypass. Precondition: this is a verification control, not a fix — it tells you whether the mechanism holds on the build a host is currently running. The packet gives the vendor update as the remediation with a required reboot, so a host that installed the update but has not restarted must still be tested and counted as exposed.",
+        "evidence": "Packet vector: 'Windows Mark of the Web Security Feature Bypass Vulnerability' (CWE-693, Protection Mechanism Failure). Attack path per the packet: an attacker stages a payload on a WebDAV share and lures the user to copy-paste it locally; the copied file lacks Mark-of-the-Web, so opening it skips SmartScreen and Protected View, executing without reputation checks. CISA KEV-listed 2024-08-13, active_exploitation confirmed, poc_available false, RWEP 57 / CVSS 6.5. live_patch_available false, with live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "NIST-800-53-SI-4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "On a Windows build that has not yet taken the fix, the endpoint will not attach the untrusted-origin marking on this path at all — that omission is the vulnerability — so 'require Mark-of-the-Web' cannot be enforced from inside the endpoint and the enforceable expression of the control moves to the ingress path. The packet's staging path is a WebDAV share the user browses to and copies from, so restrict outbound WebDAV from managed workstations to hosts inside the estate, and route externally-sourced files through the mail-gateway and download paths that do apply and preserve the marking, so the SmartScreen and Protected View decision rests on provenance established at the boundary rather than on metadata the copy silently dropped. Precondition, and it is the load-bearing half: this removes the one staging path the packet documents. It does not cover a file reaching the workstation by another route that also loses the marking, it does not help where the estate legitimately mounts an external share, and it does nothing on a workstation where the copy and the open have already happened — active_exploitation is confirmed, so a host that copied and ran a file from an external WebDAV mount during the exposure window belongs on the incident path rather than on a configuration-change list. The vendor update, with the reboot the packet says it needs, remains the remediation; this is the measure that bounds exposure until the reboot lands. Distinguishing test: from a managed workstation, attempt to mount an external WebDAV share and copy a file from it — if the mount succeeds, the documented delivery path is open no matter what a user-application-hardening attestation says about macro and reputation settings, because those settings are never consulted for a file that arrives unmarked.",
+        "evidence": "Packet attack path: an attacker stages a payload on a WebDAV share and lures the user to copy-paste it locally; the copied file lacks Mark-of-the-Web, so opening it skips SmartScreen and Protected View, executing without reputation checks. Vector: 'Windows Mark of the Web Security Feature Bypass Vulnerability' (CWE-693). 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.' CISA KEV-listed 2024-08-13, active_exploitation confirmed, RWEP 57 / CVSS 6.5. Citing gaps include AU Essential Eight user application hardening and ISO/IEC 27001:2022 A.8.7 (Protection against malware).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.7"
+        ]
+      }
+    ]
   },
   "CVE-2024-38178": {
     "name": "Microsoft Windows Scripting Engine Memory Corruption Vulnerability",
@@ -40341,7 +41947,31 @@
         "adequate": false,
         "gap": "App-hardening maturity leaves Edge IE mode / legacy WebView enabled by default, keeping the JScript9 engine reachable even on patched systems."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The exploited path needs the victim to be in Edge's Internet Explorer mode, where the JScript9 JIT performs the incorrect type optimization the packet describes; the fix is a Windows update and the packet records that no live-patching primitive exists and that the update requires a reboot to be the remediation. So for this CVE the KEV clock that opened 2024-08-13 runs to completed restart, not to 'update approved' or 'update installed' — a workstation that took the update and has not restarted still loads the vulnerable engine the next time a site opens in IE mode, and must be counted as exposed rather than done. The documented-compensating-control branch this control permits is the only lever for the interval before those restarts land, and for this CVE it is specific: cut the routes into IE mode by pruning the enterprise site list to sites with a current business need and disabling user-initiated reload-in-IE-mode, so attacker-controlled JavaScript arriving through a compromised ad service is rendered by the modern engine instead of JScript9. Precondition: that measure holds only where no legacy application genuinely requires IE mode — for the users who do require it, IE mode stays reachable and they remain exposed until the restart, so they are the population to sequence first rather than the population the site-list change covers. It also evicts nothing: the packet's exploitation outcome is RokRAT deployment, which survives both the site-list change and the update, so a host that browsed in IE mode during the exposure window belongs on the incident path, not on the patch dashboard.",
+        "evidence": "Packet: Microsoft Windows Scripting Engine Memory Corruption Vulnerability, CWE-843, CISA KEV-listed 2024-08-13, active_exploitation confirmed, CVSS 7.5, RWEP 59. attack_vector: 'A victim using Edge in Internet Explorer mode loads attacker-controlled JavaScript (delivered via a compromised ad service); the JScript9 JIT performs an incorrect type optimization, producing a type confusion that leads to remote code execution and RokRAT deployment.' patch_available is true, live_patch_available is false, and the packet's live-patch note reads 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' poc_available is false, so exploitation is confirmed with no public exploit from which signature coverage could be derived. The cited AU-Essential-8-App-Hardening gap is recorded as 'User application hardening'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry produces exactly the middle state the control exists to name, and on an endpoint fleet it is the state most hosts occupy for the longest. Constraining IE mode — pruning the enterprise site list, disabling user-initiated reload-in-IE-mode — is a configuration mitigation with the vulnerable JScript9 code still present and still reachable through any site the list continues to admit; and because the packet's update requires a reboot, a host that has installed but not restarted is likewise mitigated-at-best rather than fixed. Both states have to appear in the compliance record as time-bound compensating states rather than as remediation. For this CVE that means the fleet report separates three populations: hosts on the fixed build and restarted, hosts updated and awaiting restart, and hosts still on the pre-fix build with IE mode constrained — the last two carrying dated action items. Distinguishing test: take a host the report marks compliant, confirm it has actually restarted since the update landed, then open a site the enterprise site list still routes to IE mode and confirm which engine renders it. A report that cannot separate the three states will show a fleet at full compliance while an ordinary reboot deferral leaves the type-confusion path live behind an ad service the operator does not control.",
+        "evidence": "Packet: Microsoft Windows Scripting Engine Memory Corruption Vulnerability, CWE-843, CISA KEV-listed 2024-08-13, active_exploitation confirmed, CVSS 7.5, RWEP 59, poc_available false. patch_available is true with live_patch_available false and the note 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation' — establishing an installed-but-not-restarted state distinct from remediated. The attack_vector places the vulnerable code in the JScript9 JIT reached through Edge in Internet Explorer mode, which is a configuration-reachable surface, so restricting that reachability is a mitigation with the flawed code still resident. The gaps cited against this entry — ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities), EU NIS2 Art. 21 vulnerability handling, and NIST SP 800-53 SI-2 (Flaw Remediation) — are the process controls whose verdicts collapse these states into one.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-38189": {
     "name": "Microsoft Project Remote Code Execution Vulnerability",
@@ -41787,7 +43417,34 @@
         "adequate": false,
         "gap": "Access enforcement fails at the endpoint: /getcfg.php returns sensitive account data without authenticating or authorizing the requester."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet records no fix for this router — the affected DIR-605 hardware revisions are end-of-life/end-of-service and the recorded guidance is to retire and replace — so for this CVE remediation means taking the unit out of service, and every other measure is a holding action that needs a date on it. Applied to this device: each surviving DIR-605 goes onto a dated replacement schedule rather than an open-ended risk acceptance, and until it is pulled its HTTP surface must not be reachable from any position an untrusted party can occupy, because the whole exploit is one unauthenticated POST to /getcfg.php that returns the administrator user name and password in cleartext. Reachability is the entire precondition, and that is also where this control's limit sits: a DIR-605 acting as the gateway for the clients behind it cannot be segmented away from those clients, so a unit in that role is remediated only by replacement — an ACL is not available to it, and recording one is recording a control that does not exist on that path. Because exploitation is confirmed and a public exploit exists, treat the administrator credential the device hands out as already known: any password reused from that router on another system is rotated as part of the decommission rather than after it. The distinguishing test: from every segment that can route to the device, send an unauthenticated POST to /getcfg.php and see whether credentials come back — a vulnerability record that reads 'no patch available, risk accepted' with no removal date leaves a KEV-listed no-fix router in service indefinitely.",
+        "evidence": "Packet records patch_available: false and live_patch_available: false, with live_patch_notes 'No fix available — affected DIR-605 hardware revisions are end-of-life/end-of-service; CISA guidance is to retire and replace.' Attack path per the packet: an unauthenticated attacker forges a POST request to /getcfg.php requesting the device account service; the router returns the administrator credentials in cleartext, which are then reused to take over the device. Weakness CWE-863; product D-LINK-DIR-605 B2 Firmware Version 2.01MT. CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available true, RWEP 79 / CVSS 7.5.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-AC-3",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "A vulnerability-management program keyed on whether a fix is installed has no state to record for this entry, because the packet says no fix exists and the affected DIR-605 revisions are end-of-life/end-of-service. The requirement this CVE demonstrates is that network-attached embedded devices carry an end-of-support date in the asset inventory, so a DIR-605 resolves to a replace-or-formally-decide finding with an owner rather than reappearing every cycle as an unresolvable scanner result. Precondition, and it is the half that decides whether this works: consumer-grade D-Link extender and router hardware of this class normally sits at branch and remote-worker sites that were never enrolled in managed inventory, so an inventory query alone will return nothing and read as clean. Discovery has to be an active sweep for the device's HTTP management surface across every segment the estate reaches, including remote-worker links, repeated after site changes — and the removal decision applies to the DIR-605 units that sweep surfaces, not to embedded devices the packet does not implicate. The distinguishing test: ask the inventory which network-attached devices have an end-of-support date recorded at all; if the field does not exist, the program cannot distinguish 'fix not yet applied' from 'no fix will ever exist', which is the exact state this KEV-listed, actively-exploited router is in.",
+        "evidence": "Packet records patch_available: false with live_patch_notes 'No fix available — affected DIR-605 hardware revisions are end-of-life/end-of-service; CISA guidance is to retire and replace.' The exposed surface is the device's HTTP interface: an unauthenticated forged POST to /getcfg.php returns the administrator user name and password (CWE-863, D-LINK-DIR-605 B2 Firmware Version 2.01MT). CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available true, RWEP 79 / CVSS 7.5. Citing gaps include AU-Essential-8-Patch (Patch operating systems) and ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities), both of which assume a vendor fix exists.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2014-100005": {
     "name": "D-Link DIR-600 Router Cross-Site Request Forgery (CSRF) Vulnerability",
@@ -42718,7 +44375,30 @@
         "adequate": false,
         "gap": "Application-hardening guidance is desktop-browser-centric and does not address Android app-permission/foreground-service abuse that this notification-hiding flaw enables."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet pins this to Android-13 and to a Framework rendering path, and the trigger is an application already running on the device, so both halves of this control bind. First: the Android build carrying the fix is an access condition for organizational data — a device below it is quarantined from mail, VPN and document access rather than surfaced as a row on a patch-compliance dashboard — and because the packet says remediation requires applying the fixed release and rebooting with no vendor live-patch mechanism, a device that has downloaded the update but not restarted sits below the line and must be treated as exposed. Second, and load-bearing for the interval where a device is waiting on an OEM or carrier build it cannot obtain, the exploit needs a malicious app to be running at all, so the remaining lever is constraining what code gets installed: restrict installation to vetted sources and disallow unknown-source and side-loaded installs on any device holding organizational data. The precondition to state is that neither half is retroactive. Enforcing the build stops future suppression of the notification; it does not evict an app already present, does not revoke the background access that app already holds, and does not reconstruct what ran while the indicator was hidden — so a device suspected of carrying such an app needs an installed-app and permission review, not a build check alone. The distinguishing test: enrol a device pinned below the fixed build and confirm the policy actually denies it protected resources; an estate that lists the stale build on a report while the device keeps its mail and VPN access has recorded the exposure rather than removed it.",
+        "evidence": "Packet vector: 'In applyRemoteView of NotificationContentInflater.java, there is a possible way to hide foreground service notification due to misleading or insufficient UI. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android Versions: Android-13 Android ID: A-251586912.' attack_vector: a malicious app hides the foreground-service notification Android normally forces, so background sensor/data access runs without the persistent status-bar indicator. CWE-200, CVSS 5.5, RWEP 47, poc_available false, CISA KEV-listed 2024-03-05 with active_exploitation confirmed. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "Android's forced foreground-service notification is a protection mechanism in the sense this control governs: the platform mandates a persistent visible indicator precisely so background service execution cannot be silent, and the packet describes a Framework path that defeats it through misleading or insufficient UI. That makes the mechanism, not the individual CVE, the thing that needs testing — any detection or user-transparency posture that keys off the presence of the status-bar indicator is only as good as the mechanism producing it, and this entry is proof the mechanism can fail without the monitoring above it noticing anything at all. Applied to a managed mobile estate, the requirement is that every accepted OS build be validated against the known indicator-suppression primitives for this class before it is treated as the fixed build, and that mobile-threat-defense detections which infer background activity from the visible notification be regression-tested on the same schedule rather than assumed to carry forward. State the limits: class regression only covers primitives already known, so it does not detect a novel way of hiding the notification, and passing the battery on a build is not evidence that no app already on the estate used this one — it validates the mechanism going forward, it does not produce history. Because of that, this control complements an app-inventory and permission review rather than substituting for it, and where an operator cannot run the battery at all, the honest position is that indicator-derived monitoring on that build is unvalidated rather than sound.",
+        "evidence": "Packet vector: the flaw is 'a possible way to hide foreground service notification due to misleading or insufficient UI', with 'no additional execution privileges needed' and 'User interaction is not needed for exploitation'. attack_vector: the malicious app's background sensor/data access runs 'without the persistent status-bar indicator that would alert the user'. CISA KEV-listed 2024-03-05, active_exploitation confirmed, poc_available false. The entry cites NIST-800-53-SI-4 (System Monitoring) among the framework controls that were insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-4"
+        ]
+      }
+    ]
   },
   "CVE-2021-36380": {
     "name": "Sunhillo SureLine OS Command Injection Vulnerability",
@@ -42982,7 +44662,32 @@
         "adequate": false,
         "gap": "Essential-Eight patching targets do not specifically drive perimeter-appliance firmware updates, leaving a years-old ASA/FTD fix unapplied on exposed devices."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The affected asset is a Cisco ASA / FTD unit terminating AnyConnect and WebVPN — a VPN concentrator sitting on the trust boundary — and the packet's primitive is reached with no credential: a crafted GET request carrying an invalid URL to the web services interface returns device memory contents through a buffer-tracking flaw. The isolation alternative this tier normally offers is largely unavailable here, and that is the precondition to state rather than skip: the web services interface carrying AnyConnect and WebVPN is reachable by remote users by design, so \"restrict the vulnerable interface\" means withdrawing remote access, not hardening it, and it is an option only for units whose remote-access population is small enough to source-restrict. What is left is the clock. The packet records a vendor fix and states there is no vendor live-patch mechanism — remediation requires applying the fixed release and rebooting — so the tier's requirement is that the fixed release and the reload are driven from the 2024-02-15 KEV listing rather than folded into the next maintenance window, and a unit that has taken the image but not reloaded is still running the vulnerable parser and counts as exposed, not as remediated. The packet also scopes the population for the operator: only specific AnyConnect and WebVPN configurations are affected, so the enumeration step is which units run those configurations — an asset inventory that lists ASA/FTD units without that configuration detail cannot say which are in scope. Distinguishing test: for each unit in the affected configuration set, compare the running image against the fixed release and confirm the reload has occurred; an \"update deployed\" entry in the management console is not evidence that the running device stopped serving the vulnerable web services parser.",
+        "evidence": "Packet: a vulnerability in the web services interface of Cisco ASA and FTD Software allows an unauthenticated, remote attacker to retrieve memory contents; the flaw is a buffer-tracking issue when the software parses invalid URLs requested from the web services interface, exploited by sending a crafted GET request. The packet states the vulnerability affects only specific AnyConnect and WebVPN configurations. CWE-200; CISA KEV-listed 2024-02-15; active_exploitation confirmed; CVSS 7.5; RWEP 60; poc_available false. patch_available true; live_patch_available false; live_patch_notes: \"No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's outcome is a read primitive, not code execution: an unauthenticated crafted GET request returns ASA/FTD memory contents, which the packet says can include cleartext VPN credentials later used for ransomware entry. That makes one half of this control load-bearing here and the other inapplicable, and saying which is which matters. The packet documents no implant and no write to the device, so a rebuild is not what this CVE demands; credential rotation is — and it is exactly the step the fixed release does not perform. Applied to these units: every credential that could have been resident in the memory of an affected AnyConnect/WebVPN unit during the exposure window is treated as disclosed and rotated — remote-access VPN user credentials, the upstream directory or RADIUS accounts those users authenticate against, administrator credentials used on the device, and any shared secret the device holds — and the remote-access session and account history is reviewed for logins that used credentials valid before the rotation. Precondition: rotation reaches only credentials the operator can enumerate and change. A credential held by a third party, or embedded in a partner or appliance configuration outside the operator's control, keeps working after the fixed release lands, and that residual belongs in the record rather than assumed closed. The distinguishing test is not on the device: after the fixed release and reload, confirm that remote-access authentication for the affected units rejects the pre-remediation credential set — an identity-and-access attestation showing every VPN user authenticating correctly passes cleanly while an attacker holds a credential that also authenticates correctly.",
+        "evidence": "Packet: \"An unauthenticated attacker sends a crafted GET request with an invalid URL to the ASA/FTD web services interface; a buffer-tracking flaw returns device memory contents, which can include cleartext VPN credentials later used for ransomware entry.\" active_exploitation confirmed; CISA KEV-listed 2024-02-15. 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 describes retrieval of memory contents only — no code execution, implant, or device write.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-21410": {
     "name": "Microsoft Exchange Server Privilege Escalation Vulnerability (CVE-2024-21410)",
@@ -45243,7 +46948,32 @@
         "adequate": false,
         "gap": "Advisory-driven vulnerability management cannot prioritize an unknown zero-day used to leak memory and defeat mitigations like ASLR."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this CVE the control means the iOS, iPadOS, macOS and Safari update carrying the fix is driven across the whole Apple estate on the KEV clock that opened 2023-12-04 with user deferral disabled, and completion measured by each device's running build after the restart the packet says the fix requires — a device that has downloaded the update but not restarted is still executing the vulnerable WebKit and is counted as exposed, not as remediated. The reason this entry needs the compressed tier rather than the estate's ordinary update ring is that its own numbers argue for deferring it: CVSS 6.5 and 'processing web content may disclose sensitive information' read as a medium-severity information leak, while the packet's actual exploitation path is a memory disclosure used to defeat ASLR and stabilise a companion code-execution exploit. The value of the bug to an attacker sits in the chain, not in this CVE's impact score, and the packet records a report of exploitation against versions before iOS 16.7.1. Precondition: management-enforced updates reach only enrolled devices — personally-owned and unenrolled devices that touch organizational data sit outside this control entirely and are covered, if at all, by the access-condition control paired with it here. Enforcement is also forward-looking only: the update does not make clean a device that ran a vulnerable build through the exposure window, and because exploitation is confirmed for this CVE a device with reason to suspect it belongs on the incident path rather than the compliance report.",
+        "evidence": "Packet gives patch_available true, live_patch_available false, with live_patch_notes 'No live patch; requires the iOS/iPadOS/macOS/Safari update (17.1.2 / 14.1.2, backported to 16.7.2) and a device restart.' Vector: 'An out-of-bounds read was addressed with improved input validation. This issue is fixed in iOS 17.1.2 and iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2. Processing web content may disclose sensitive information. Apple is aware of a report that this issue may have been exploited against versions of iOS before iOS 16.7.1.' Attack path: crafted web content triggers an out-of-bounds read in WebKit (CWE-125) that leaks process memory, typically used to defeat ASLR and stabilize a companion code-execution exploit. CISA KEV-listed 2023-12-04, active_exploitation confirmed, RWEP 57 / CVSS 6.5, poc_available false.",
+        "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": "The fixed build has to act as an access condition on this flaw, not as a row on a patch-compliance dashboard: an iPhone, iPad or Mac below 17.1.2 / 14.1.2 — or below the 16.7.2 backport on the older track — is refused organizational mail, VPN and document access until it is at or above the fix and has taken the restart the packet says the update needs. The delivery path is why the access-condition half is the load-bearing one here: the trigger is crafted web content processed by WebKit, which is the engine behind every browser and in-app web view on the device, so there is no setting the operator can apply that keeps the vulnerable parser away from attacker-controlled content while the device stays in service on an old build. Withholding the data is the only remaining lever for a device that has not yet updated and restarted. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it mail, VPN and document access — an estate that shows the stale build on a report while the device keeps working has recorded the exposure rather than removed it. Precondition: the gate binds only where the resource consults device state at access time, so a service reachable from a browser session or an app that does not check device compliance stays reachable from a device below the fixed build. And it is a containment measure, not a cleanup one — it does not evict an attacker already resident on a device exploited before the update, which matters because the packet records confirmed exploitation and a report of use against versions before iOS 16.7.1.",
+        "evidence": "Packet live_patch_notes: 'No live patch; requires the iOS/iPadOS/macOS/Safari update (17.1.2 / 14.1.2, backported to 16.7.2) and a device restart.' Vector states the issue is fixed in iOS 17.1.2 and iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2, that processing web content may disclose sensitive information, and that Apple is aware of a report that the issue may have been exploited against versions of iOS before iOS 16.7.1. Attack path: crafted web content triggers an out-of-bounds read in WebKit (CWE-125) leaking process memory. CISA KEV-listed 2023-12-04, active_exploitation confirmed, RWEP 57 / CVSS 6.5.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-6345": {
     "name": "Google Skia Integer Overflow Vulnerability",
@@ -45300,7 +47030,31 @@
         "adequate": false,
         "gap": "Advisory-driven vulnerability management cannot pre-empt an unknown browser zero-day used specifically to break out of the renderer sandbox."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "For this CVE the update ring must place Chrome/Chromium on 119.0.6045.199 or later within the 24-hour bound rather than holding it for a validation window, because the packet pairs a 2023-11-30 KEV listing with confirmed exploitation on a sandbox escape — the component that is supposed to contain a compromised renderer is the component that fails. The precondition that decides whether this control actually works is in the packet's own remediation note: the fix requires updating and relaunching the browser. A managed fleet that reports the update as delivered while long-lived browser sessions keep running still has the vulnerable Skia mapped in those processes, so compliance has to be measured on the build the process is actually executing — enforced with a restart deadline or forced relaunch policy — not on the version staged on disk. State the other limit too: this control reaches only software that takes the browser vendor's update channel, so Chromium embedded inside other applications is outside it entirely and is handled by the inventory control rather than counted as covered here. Distinguishing test: query managed-browser reporting for the running build on each host after the ring completes; any host reporting a pre-119.0.6045.199 running build, or a stale process start time against a completed update, is still exposed to the escape.",
+        "evidence": "Packet: CWE-190 integer overflow in Skia; vector 'Integer overflow in Skia in Google Chrome prior to 119.0.6045.199 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a malicious file.' live_patch_notes: 'No live patch; requires updating Chrome/Chromium to 119.0.6045.199+ and relaunching the browser (downstream products must rebuild against the fixed Skia).' CVSS 9.6, RWEP 55, CISA KEV-listed 2023-11-30, active_exploitation 'confirmed', poc_available false. patch_available true; live_patch_available false. Cited gaps include NIS2-Art21-patch-management, NIST-800-53-SI-2 and UK-CAF-B4.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "Skia is a graphics library that ships inside far more than the browser the advisory names, and the packet makes the consequence explicit — downstream products must rebuild against the fixed Skia. So the estate has to be inventoried for every binary that bundles its own Chromium/Skia copy (Chromium-derived browsers, Electron applications, embedded webviews and desktop apps with in-process browser components) and each one held to a build rebuilt against fixed Skia, rather than treating the Chrome fleet reaching 119.0.6045.199+ as closing the CWE-190 primitive across the estate. This is also why the cited Essential Eight user-application-hardening gap is recorded here: that control describes the browser's configuration, while the packet's path begins from an already-compromised renderer, so no content-blocking setting is consulted, and a hardened browser configuration on a host running an application with an unpatched vendored Skia still carries the escape. The precondition has to be stated rather than glossed: an inventory produces a fix only where the embedding vendor has shipped a rebuild — where it has not, there is no build to move to, and the remaining levers are constraining what untrusted content that application is allowed to render and scheduling its withdrawal, not recording it as covered by the browser update. Distinguishing test: after the Chrome/Chromium fleet reports 119.0.6045.199+, enumerate installed applications that ship their own Chromium/Skia and confirm each reports a version its vendor rebuilt against fixed Skia; any that cannot is an open instance of the same overflow, and any that has no such build is an exposure needing a dated decision rather than a passing patch report.",
+        "evidence": "Packet live_patch_notes states verbatim: 'No live patch; requires updating Chrome/Chromium to 119.0.6045.199+ and relaunching the browser (downstream products must rebuild against the fixed Skia).' attack_vector: 'From an already-compromised renderer, an attacker feeds a malicious graphics primitive that overflows an integer in Skia's size calculation, producing an undersized buffer whose subsequent writes corrupt adjacent memory to escape the sandbox.' CWE-190, CVSS 9.6, RWEP 55, CISA KEV-listed 2023-11-30, active_exploitation 'confirmed', patch_available true, live_patch_available false. Cited gaps include AU-Essential-8-App-Hardening (User application hardening), ISO-27001-2022-A.8.8 and NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-49103": {
     "name": "ownCloud graphapi Information Disclosure Vulnerability",
@@ -47509,7 +49263,41 @@
         "adequate": false,
         "gap": "System security relies on kernel integrity that this improper-check flaw directly violates, invalidating the control until patched."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet names the exact builds carrying the fix — macOS Monterey 12.7, iOS 16.7 and iPadOS 16.7, macOS Ventura 13.6 — so the SLA has a concrete per-platform target rather than a vague 'current' state, and the entry is KEV-listed 2023-09-25 with confirmed exploitation. Apple estates fail this differently from server estates: the update is offered and the user defers it indefinitely, so the requirement here is that declarative device management installs and enforces the fixed build on a KEV clock with user deferral disallowed, across iPhone, iPad and Mac alike since all three platforms appear in the packet's fix list. Because the packet records no vendor live-patch mechanism and a remediation that requires applying the fixed release and rebooting, the SLA must be measured to completed restart on the fixed build — a device that has downloaded and staged the update is still running the vulnerable kernel and cannot be counted as remediated. The precondition is enrolment: this reaches only supervised or MDM-enrolled devices and does nothing for unenrolled personal devices holding organizational data, which is why it has to be paired with an access condition that quarantines any device below the fixed build rather than left as the whole answer. Distinguishing test: set a deferral on a managed test device, confirm the platform installs regardless inside the window, and confirm the compliance record only flips to remediated once the device reports the fixed build after restart.",
+        "evidence": "Packet vector: 'This issue is fixed in macOS Monterey 12.7, iOS 16.7 and iPadOS 16.7, macOS Ventura 13.6. A local attacker may be able to elevate their privileges. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.' CISA KEV-listed 2023-09-25, active_exploitation 'confirmed', RWEP 59, CVSS 7.8. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Treat the builds the packet names — macOS Monterey 12.7, iOS 16.7 and iPadOS 16.7, macOS Ventura 13.6 — as an access condition rather than a dashboard metric: a device below its platform's fixed build is denied or quarantined from organizational mail, VPN and documents rather than listed as non-compliant while retaining all of it. That distinction is what matters for this flaw because the outcome the packet records is kernel privileges and full device control by spyware; once the chain completes, every credential and data set that device can reach belongs to the attacker, so leaving access in place while the build catches up grants precisely the reach a quarantine would have removed. Unlike other Apple kernel-memory cases, restricting untrusted or side-loaded application installation is not the covering lever here — the packet places the local process as arriving via a chained WebKit stage, so an app-install restriction leaves the delivery path open and must not be recorded as the mitigation for this entry. The precondition is that the build assertion is enforced at the resource rather than on the device: a device-side self-report is not a control against an attacker who, per the packet, already holds kernel privileges, so the gate has to sit on the identity or management attestation the service trusts before it releases data. Distinguishing test: enrol a device pinned below the fixed build for its platform and confirm it is actually refused organizational data rather than merely flagged on a report.",
+        "evidence": "Packet vector names the fixed releases: macOS Monterey 12.7, iOS 16.7 and iPadOS 16.7, macOS Ventura 13.6, with exploitation reported against versions of iOS before iOS 16.7. Attack vector: 'A local process (delivered via the chained WebKit stage) abuses a kernel improper-check flaw to elevate to kernel privileges, giving the spyware full device control.' CWE-754. CISA KEV-listed 2023-09-25, active_exploitation 'confirmed'. patch_available true; live_patch_available false with remediation requiring the fixed release and a reboot.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this kernel flaw as the escalation step of a chain whose delivery stage is WebKit, with the end state being spyware holding full device control — which is the targeting profile this control's cohort exists for: executives, journalists, legal and security staff. For that cohort, place devices in Apple's reduced-attack-surface mode so untrusted web content and message-borne content (attachments, fonts, link previews) is not processed automatically, narrowing the WebKit stage that delivers the local process into this CWE-754 kernel check during the window between the 2023-09-25 KEV listing and completed fleet restart. Two preconditions bound the claim and neither may be softened. The mode narrows a delivery path; it does not remove the kernel flaw, so the fixed build plus reboot the packet requires remains the remediation and this cannot be recorded as closing the exposure. And it only helps if it was already enabled when the chain arrived — a device compromised before the mode was turned on stays compromised, and must be handled as an incident (restore to the fixed build, rotate every credential that device held) rather than as a hardening item. It follows that the cohort roster is a standing posture assigned ahead of the next disclosure; switching the mode on in reaction to a KEV listing protects nobody already inside the targeting set. Distinguishing test: on a cohort device, confirm untrusted web and message content is refused automatic processing, and separately confirm the roster was assigned before the disclosure date rather than after it.",
+        "evidence": "Packet attack vector: 'A local process (delivered via the chained WebKit stage) abuses a kernel improper-check flaw to elevate to kernel privileges, giving the spyware full device control.' CWE-754. CISA KEV-listed 2023-09-25, active_exploitation 'confirmed', RWEP 59, CVSS 7.8, poc_available false. live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-41993": {
     "name": "Apple Multiple Products WebKit Code Execution Vulnerability",
@@ -48307,7 +50095,41 @@
         "adequate": false,
         "gap": "Response and recovery planning is not scoped for targeted commercial-spyware zero-click intrusions that leave little evidence and demand vendor-assisted forensics."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet's fix is a whole OS build, and it lands on five separate release trains at once: iOS/iPadOS 16.6.1, iOS/iPadOS 15.7.9, macOS Ventura 13.5.2, macOS Monterey 12.6.9 and macOS Big Sur 11.7.10. For this CVE the control means the update is driven across the Apple estate from the management plane on the KEV clock that opened 2023-09-11, with user deferral disallowed, and that completion is measured per device as the build it actually reports against the fixed build for its own train — a device held on the 15.x train is remediated at 15.7.9, and an estate that measures 'latest major OS installed' will read that whole population as stale or unknown rather than as fixed. Preconditions: the packet records no vendor live-patch mechanism, so remediation requires applying the fixed release and rebooting — a device that has downloaded the update but not restarted still runs the vulnerable ImageIO and must be counted as exposed, not as patched. And management-plane enforcement reaches only enrolled devices; an unenrolled personal device belonging to someone in the targeted population is not covered by this control at all, which is why the standing posture below is assigned per user rather than per enrollment.",
+        "evidence": "Packet fields: patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The vector names the fixed releases (iOS 16.6.1 and iPadOS 16.6.1, macOS Monterey 12.6.9, macOS Ventura 13.5.2, iOS 15.7.9 and iPadOS 15.7.9, macOS Big Sur 11.7.10). cisa_kev true with kev_date 2023-09-11; active_exploitation confirmed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "Delivery for this CVE is a crafted image arriving as a PassKit attachment over iMessage and parsed by ImageIO with no user interaction — there is no click to withhold and no user decision to train, so awareness controls and attachment-handling guidance have nothing to act on. Between the 2023-09-11 KEV listing and the completed restart of every device, the only remaining lever is narrowing what the device parses automatically: place the plausibly targeted cohort — executives, journalists, legal and security staff — into Apple's reduced-attack-surface mode for at-risk users so message attachments and untrusted web content are not processed on arrival. This has to be a standing assignment made before the next disclosure, because the mode only helps if it was already on when the message landed. Preconditions, stated plainly: it narrows the delivery path, it does not repair the ImageIO overflow and does not remove the surface outright — any other route that reaches the same parser is unaffected; and it does nothing for a device on which the chain has already run, which belongs on the incident path rather than the hardening path. It is a holding measure for the window before the fixed build and its reboot land, not a substitute for them.",
+        "evidence": "Packet attack_vector: 'A maliciously crafted image sent as a PassKit attachment over iMessage is processed by ImageIO with no user interaction, overflowing a buffer and executing code; combined with CVE-2023-41061 (BLASTPASS) to install Pegasus.' active_exploitation confirmed; kev_date 2023-09-11; live_patch_available false with remediation recorded as the fixed release plus a reboot.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet records a confirmed chain — this overflow combined with CVE-2023-41061 (BLASTPASS) — whose end state is a Pegasus implant delivered with no user interaction. Commodity-malware IR under-escalates that outcome by treating a phone as clean once it takes an update, and the packet's own remediation shows why that is wrong: the fix is applying the fixed release and rebooting, and a build upgrade evicts nothing that executed before it. For this CVE the escalation path triggers on the chain and implant outcome, not on an actor attribution — the packet names no threat group — so the operational rule is that any device in the plausibly targeted population that was below the fixed build during the exposure window is handled as a suspected targeted-implant case: preserved for forensic examination, and the accounts, tokens and mail/VPN sessions reachable from it rotated, before the vulnerability ticket is closed. This is also the substitute for the system-monitoring gap cited on this entry: the affected Apple platforms give the estate no endpoint telemetry that would emit on a zero-click ImageIO parse, so the trigger has to be build-state during the window plus forensic examination rather than a detection rule keyed on process or crash behaviour, which for this delivery path would fire on nothing. Precondition: it covers only the devices whose build history during the window you can establish; a device with no such history cannot be cleared by this path and stays in scope until evidence says otherwise.",
+        "evidence": "Packet: active_exploitation confirmed, cisa_kev true, kev_date 2023-09-11; attack_vector records the combination with CVE-2023-41061 (BLASTPASS) to install Pegasus, processed with no user interaction. live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' poc_available false. The packet names no threat-actor group, so the trigger asserted here is the confirmed chain and its implant outcome, not an attribution.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-D1",
+          "NIST-800-53-SI-4"
+        ]
+      }
+    ]
   },
   "CVE-2023-41061": {
     "name": "Apple iOS, iPadOS, and watchOS Wallet Code Execution Vulnerability",
@@ -49344,7 +51166,21 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management typically triages by CVSS confidentiality/integrity impact, but this is availability-only (C:N/I:N/A:H) and can be de-prioritised, leaving the exploitable .NET runtime unpatched despite confirmed in-the-wild DoS."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is KEV-listed 2023-08-09 with confirmed exploitation and an available vendor fix, and none of the frameworks cited against it carries a KEV-tied clock — so the control supplies the missing deadline: verified mitigation within 4 hours of the KEV listing or patch availability, whichever is later. What 'verified' has to mean here is fixed by the packet's own remediation note — installing the August 2023 .NET 6.0/7.0 runtime and Visual Studio updates and restarting the affected applications, with no live-patch mechanism available — so a long-running Kestrel worker that has taken the runtime package but has not restarted is still executing the vulnerable code and the clock runs to process restart, not to package installation. Package-inventory evidence on its own will report this remediated while the unauthenticated crafted-traffic path still exhausts CPU and memory. The clock also has to span two estates normally on separate patch programs, both named by the packet's remediation: internet-reachable ASP.NET Core services and the Visual Studio installs on developer workstations. The 'documented compensating controls' branch of this SLA is usable only where the service has an enumerable client population whose reachability can be restricted for the window; a publicly reachable endpoint has no such population, and for those the restart is the only lever — restricting reachability narrows who can send the crafted traffic, it does not remove the resource-consumption defect, and it must be recorded as a bounded interim state with the restart still owed. This matters more than the RWEP of 38 suggests, because an availability-only impact is exactly the shape that slips a patch queue despite confirmed in-the-wild exploitation. Distinguishing test: on a staging service, apply the runtime update without restarting the worker and confirm the compliance record does not read remediated until the process itself reports the fixed runtime.",
+        "evidence": "Packet: CISA KEV-listed 2023-08-09, active_exploitation 'confirmed', RWEP 38, CVSS 7.5, poc_available false, CWE-400. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism exists; remediation is installing the August 2023 .NET 6.0/7.0 runtime and Visual Studio updates and restarting the affected applications.' Attack vector: 'An unauthenticated remote attacker sends crafted traffic to an ASP.NET Core / Kestrel or .NET application that triggers uncontrolled resource consumption (CWE-400), exhausting CPU/memory and denying service.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2017-18368": {
     "name": "Zyxel P660HN-T1A Routers Command Injection Vulnerability",
@@ -50719,7 +52555,34 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management struggles to track this on BYOD/managed handsets where firmware version visibility is limited, so the SMR May-2021 fix may not be verifiable as applied across the fleet."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The defect sits in the Samsung MFC charger driver — kernel-mode code, so it executes below every account boundary a mobile estate is audited on. For this CVE the control means the SMR May-2021 Release 1 firmware build is driven across every affected handset on the KEV clock that opened 2023-06-29, not folded into whatever OEM update cadence the fleet happens to follow, and completion is measured per handset by the installed SMR build level rather than by 'update pushed' or 'update available' in the management console. The packet records no live-patch mechanism for this driver and an update that reboots the device, so a handset that has downloaded the firmware but not restarted still runs the vulnerable driver and must be counted as exposed rather than remediated. Two limits belong in the control statement rather than being assumed away. First, the operator can only reach the fixed level where Samsung and the carrier still ship SMR releases for that model; where the model no longer receives them, this control cannot be satisfied at all and the remaining lever is holding the device outside the trust boundary. Second, the packet's precondition is an attacker who already holds compromised radio privileges, so tightening the app-level or user-level privilege model does not contain the escalation — a least-privilege attestation over the handset's user and app accounts passes cleanly while the race to a kernel write and signature-check bypass stays reachable, which is exactly why the AC-6 gap is recorded against this entry.",
+        "evidence": "Packet fields for CVE-2021-25395: cwe_refs CWE-362; cisa_kev true with kev_date 2023-06-29; active_exploitation confirmed; rwep_score 46; cvss 6.4; poc_available false; patch_available true; live_patch_available false with live_patch_notes 'No live-patch mechanism for the mobile kernel driver; remediation requires installing Samsung's SMR May-2021 Release 1 firmware update, which reboots the device.' Vector: 'A race condition in MFC charger driver prior to SMR MAY-2021 Release 1 allows local attackers to bypass signature check given a radio privilege is compromised.' Attack vector adds that the race produces a use-after-free and the attacker 'wins the race to obtain a kernel write and bypass the signature check, escalating to kernel-level control.' NIST-800-53-AC-6 (Least Privilege) is among the citing framework gaps.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Bound to this flaw, minimum-patch-level enforcement means SMR May-2021 Release 1 is an access condition for the handset rather than a line on a patch-compliance report: a device below that SMR level is denied or quarantined from organizational mail, VPN and document access until it has taken the firmware update and rebooted. This is the control that still has an answer where the remediation-window control cannot be met — a model for which the fixed SMR build is not offered can never reach the required level, and holding it outside the trust boundary is then the only remaining lever. Two preconditions have to be stated rather than assumed. First, the gate must be enforced at the resource by conditional access; a console that surfaces the stale SMR level while the handset keeps its live mail and VPN sessions has recorded the exposure, not removed it. Second, this is containment for a handset that is still clean — it does not evict an attacker who already won the race on that device, because the packet puts the outcome at kernel-level control, beneath the management agent that would enforce the policy; a handset with any indication of compromise needs a wipe and re-provision, not a policy flag. Distinguishing test: enrol a handset pinned below SMR May-2021 Release 1 and confirm the policy actually refuses it access to protected resources.",
+        "evidence": "Packet fields for CVE-2021-25395: vector states the race condition exists in the MFC charger driver 'prior to SMR MAY-2021 Release 1' and that local attackers can bypass the signature check 'given a radio privilege is compromised'; attack_vector records escalation 'to kernel-level control'; cisa_kev true with kev_date 2023-06-29 and active_exploitation confirmed; patch_available true; live_patch_available false with live_patch_notes stating remediation 'requires installing Samsung's SMR May-2021 Release 1 firmware update, which reboots the device.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-25371": {
     "name": "Samsung Mobile Devices Unspecified Vulnerability",
@@ -50902,7 +52765,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management depends on a published fix to prioritize; for a kernel integer overflow used as an in-the-wild zero-day the control had nothing to act on until Apple's 2023-06-21 releases, so the exposure preceded any compliant handling cycle."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "On the Apple estate this CVE affects, the fix ships only as an OS build and the build differs per platform and per generation — the packet names iOS/iPadOS 16.5.1 and 15.7.7, macOS Ventura 13.4.1, macOS Monterey 12.6.7, macOS Big Sur 11.7.8, and watchOS 9.5.2 and 8.8.1. The enforcement object therefore has to be a per-SKU target build, not a generic 'latest update installed' policy, because a device sitting on the newest build for its generation can still be below the listed fix for a different generation in the same fleet. The packet records no live-patch mechanism and states the update requires a device restart, so the SLA's completion criterion is the restart having been taken, not 'update pushed', 'update downloaded' or 'update approved' in the management console. Precondition: this control's enforcement channel covers enrolled iOS, iPadOS and macOS devices, while the packet's fix list also carries watchOS 9.5.2 and 8.8.1 — those devices fall outside that enforcement scope and have to be tracked and driven to the listed build explicitly, or the estate will report full compliance while a build named in the fix list stays behind. Distinguishing test: after the enforcement window closes, read the actually-installed build from enrolled devices at each OS generation in the packet's fix list; any device below its generation's listed build, or above it but not yet restarted, is the finding.",
+        "evidence": "Packet: CISA KEV listed 2023-06-23, active_exploitation confirmed, CVSS 7.8, RWEP 51, patch_available true, live_patch_available false. live_patch_notes: 'No live-patch mechanism for the affected kernel; remediation requires the Apple OS update (iOS/iPadOS 16.5.1 or 15.7.7, macOS Ventura 13.4.1, macOS Monterey 12.6.7, macOS Big Sur 11.7.8, watchOS 9.5.2/8.8.1), which requires a device restart.'",
+        "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's trigger is an application on the device reaching arbitrary code execution with kernel privileges, so once that application runs, no account-level boundary on the device contains it — the defect executes below every boundary the endpoint estate is audited on. For this entry the control means the per-generation fixed build named in the packet functions as an access condition: a device below its generation's listed build is denied mail, VPN and document access, rather than appearing as a stale row on a patch-compliance report while keeping its access. Because the packet records a required device restart and no live-patch path, the bar is the restarted state — a device that has installed the update but not restarted is still running the vulnerable kernel and must be counted below the bar, not as remediated. Distinguishing test: hold an enrolled device at a build below its generation's listed fix and confirm the policy actually refuses it access to protected resources; an estate that surfaces the stale build on a dashboard while the device keeps its access has recorded the exposure rather than removed it. Precondition: restricting which applications may be installed raises the bar for getting the attacker's application onto the device, but it does not evict an application already installed, and the packet places this CVE inside a zero-click chain, so an install-policy is not the containment for a device suspected of having already run the chain — that device belongs on the incident path, not the install-policy path.",
+        "evidence": "Packet vector: 'An app may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.7.' CWE-190; active_exploitation confirmed. live_patch_available false; live_patch_notes names the per-generation fixed builds and states the update 'requires a device restart'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this CVE as the kernel-execution stage of the Operation Triangulation zero-click chain, and Apple's own note in the packet is that the issue may have been actively exploited against versions of iOS released before iOS 15.7 — a delivery path that requires no user action, so no amount of user-awareness training or click-discipline is in the loop. For the high-risk cohort this control governs, the reboot-gated OS update is not fast enough on its own: place those devices in a reduced-attack-surface mode so message attachments, web content, fonts and link previews are not processed automatically, narrowing the delivery path for the chain stage that precedes this one during the window between the 2023-06-23 KEV listing and the completed fleet restart. Precondition, and this is the load-bearing sentence: the posture narrows delivery of the chain, it does not touch the integer overflow itself. The packet's trigger is an application already executing on the device, so once the chain has landed the mode changes nothing, it does not evict anything already resident, and a device suspected of having run the chain goes to the incident path rather than being closed on a posture change. It also only helps if it was already enabled when the chain arrived. Distinguishing test: confirm the posture is assigned as a standing profile to the named cohort ahead of the next disclosure — a mode switched on in reaction to a KEV listing was, by construction, off during the in-the-wild exploitation the packet records.",
+        "evidence": "Packet attack_vector: 'An application triggers an integer overflow in the Apple kernel to execute arbitrary code with kernel privileges; in the wild it was the kernel-execution stage of the Operation Triangulation zero-click chain.' Packet vector: 'Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.7.' CISA KEV 2023-06-23, active_exploitation confirmed; live_patch_notes records that remediation 'requires a device restart'.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-32435": {
     "name": "Apple Multiple Products WebKit Memory Corruption Vulnerability (CVE-2023-32435)",