@blamejs/exceptd-skills 0.19.12 → 0.19.14

package/data/zeroday-lessons.json

@@ -14282,7 +14282,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": "Cisco Catalyst SD-WAN Controller (formerly SD-WAN vSmart) and Catalyst SD-WAN Manager (formerly SD-WAN vManage) are the management plane the packet names, and the defect sits on the interface where they authenticate fabric peers: the packet states the peering authentication mechanism in an affected system is not working properly, so crafted requests let an unauthenticated remote attacker log in as an internal, high-privileged, non-root user account, access NETCONF from it, and manipulate network configuration for the SD-WAN fabric. Bound to these two products the control means the peering interface takes its own authorization decision on every request before a session exists — a peer's asserted identity is verified rather than accepted — and that no Controller or Manager instance is left with its peering and NETCONF interfaces reachable from a segment holding no fabric role. This is also why the cited least-privilege and identity-and-access gaps cannot close the path: the account the attacker lands in is internal to the product rather than one the operator provisioned, so per-account privilege scoping is never consulted and an attestation covering administrator accounts passes cleanly while an unauthenticated caller holds administrative privileges on the system. Distinguishing test: from a segment carrying no SD-WAN fabric role, send unauthenticated peering requests to a staging Controller and Manager and confirm each is refused before any session is issued, then attempt a NETCONF session from that same origin and confirm it is refused too — an estate that audits vManage operator roles and passes remains fully exposed to the path the packet describes, because the path never touches those roles. Precondition: repairing the peering authentication mechanism is what the vendor update does; this control states the property to verify and does not implement it. Until that update and the restart the packet's live-patch note requires have landed, restricting which segments can present requests bounds who can attempt the bypass but leaves it fully available to anything inside the permitted segment — and because a fabric's peers are distributed by design, the peering interface must stay reachable to those peers for the overlay to work, so the restriction is partial by construction rather than a closure.",
+        "evidence": "Packet vector: Catalyst SD-WAN Controller, formerly SD-WAN vSmart, and Catalyst SD-WAN Manager, formerly SD-WAN vManage, \"contain an authentication bypass vulnerability could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system. This vulnerability exists because the peering authentication mechanism in an affected system is not working properly... A successful exploit could allow the attacker to log in to an affected Cisco Catalyst SD-WAN Controller as an internal, high-privileged, non-root user account. Using this account, the attacker could access NETCONF, which would then allow the attacker to manipulate network configuration for the SD-WAN fabric.\" CWE-287. CISA KEV-listed 2026-02-25, active_exploitation confirmed, poc_available true, CVSS 9.1, RWEP 77. patch_available true; live_patch_available false with the note 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": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock this control sets opens on this entry at the 2026-02-25 KEV listing, and what counts as verified mitigation has to be stated in these products' own terms. The packet records a vendor fix with no live-patch path and a note that the patch typically requires a service restart or system reboot, so completion is measured by each Catalyst SD-WAN Controller and Manager having taken the fixed image and come back from that restart — an instance carrying the image but not yet restarted still runs the vulnerable peering authentication code and counts as exposed, and on a fabric controller the restart is the step most likely to be deferred because taking it disturbs the overlay it serves. Where the restart cannot be scheduled inside the window, the documented-compensating-control branch is the only one this SLA leaves, and it has to be written down as a compensating control with its residual stated rather than recorded as compliant: restricting which segments can present requests to the peering and NETCONF interfaces bounds who can attempt the bypass, but it does not repair the mechanism, and every legitimate fabric peer's network remains a permitted origin. Priority follows the packet rather than the CVSS band — confirmed in-the-wild exploitation and a public PoC against a system whose compromise yields NETCONF-level authority over the fabric's configuration makes this a control-plane containment item, not a scheduled network-device update. Precondition: because exploitation is confirmed, the update does not close an instance that was reachable during the window. The packet's end state is an attacker manipulating SD-WAN fabric configuration, so a Controller or Manager exposed before the fix landed needs its fabric configuration and the accounts defined on it compared against a known-good copy; an update applied to a system that already issued an administrative session removes the entry path and nothing the attacker did through it.",
+        "evidence": "Packet: CISA KEV-listed 2026-02-25 with active_exploitation confirmed and poc_available true; CVSS 9.1, RWEP 77; CWE-287. patch_available true, live_patch_available false, with live_patch_notes stating \"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 unauthenticated remote attacker can \"bypass authentication and obtain administrative privileges on an affected system,\" log in \"as an internal, high-privileged, non-root user account,\" and \"access NETCONF, which would then allow the attacker to manipulate network configuration for the SD-WAN fabric.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-25108": {
     "name": "Soliton Systems K.K FileZen OS Command Injection Vulnerability",
@@ -15100,7 +15124,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 packet's path into BeyondTrust Remote Support and Privileged Remote Access needs no credential and no user interaction — an unauthenticated remote attacker reaches the product and executes operating system commands in the context of the site user — so these systems are not servers sitting behind an access boundary, they are the boundary the exploit crosses, which is what puts them in this control's distinct SLA tier rather than in the general server population. For these two products the control means the remediation clock runs from the 2026-02-13 KEV listing rather than from the next scheduled maintenance window, and that completion is measured per system by the version actually running against the vendor's fixed version, not by 'update approved', 'update downloaded' or a closed change ticket. The packet registers no live-patch path and records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a system that has taken the update but not restarted still runs the vulnerable code and has to be counted as exposed for the whole interval until it restarts. The control's alternative branch — isolating the vulnerable interface instead of meeting the clock — carries a precondition that frequently does not hold for this product: Remote Support and Privileged Remote Access exist in order to be reachable, so isolation is only available where the operator can name a user and technician population whose access can be suspended for the duration, and where it cannot, the update plus its restart is the only lever and there is no compensating control to record in its place. Priority follows the packet rather than the CVSS band alone: confirmed in-the-wild exploitation plus a public PoC against a no-authentication path means the window is being actively worked. Distinguishing test: produce, per affected system, the running version and the timestamp of the restart that activated it, set against the vendor's fixed version — a patch-management attestation that reports an SLA-compliance percentage over a 14- or 30-day window passes cleanly while a system sits updated-but-unrestarted on a KEV-listed no-authentication remote command-execution flaw.",
+        "evidence": "Packet: BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA); CWE-78 OS command injection. Vector: 'Successful exploitation could allow an unauthenticated remote attacker to execute operating system commands in the context of the site user. Successful exploitation requires no authentication or user interaction.' cisa_kev true, kev_date 2026-02-13, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 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.' Citing gaps closed here: AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation), 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"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records confirmed in-the-wild exploitation and a public PoC against a path that requires no authentication and no user interaction, which changes what the response has to cover: any Remote Support or Privileged Remote Access system that was reachable before it was updated is possibly already executed against, not merely possibly vulnerable. Bound to this product, the control means the answer to the 2026-02-13 KEV listing is not the vendor update alone — for each system reachable during the exposure window, export the configuration off the box, rebuild from vendor media rather than patching in place, and rotate the credentials and key material the system held. The packet's own outcome statement is the reason: command execution in the context of the site user, with the vendor stating exploitation may lead to system compromise including unauthorized access, data exfiltration and service disruption. An attacker who reached that before the update keeps everything they wrote after it. This is also precisely why the anti-malware control cited against this entry does not close the path: an anti-malware attestation covers the hosts the agent is installed on and the content it has signatures for, whereas an operating-system command-execution foothold on this product typically leaves an added account, an altered configuration entry, or a script the platform itself executes on schedule — content with nothing to match. Distinguishing test: take a system that was reachable before remediation and diff its accounts, automated tasks and on-disk content against a freshly built system at the same fixed version; a clean anti-malware scan and a version number at or above the fixed release are both fully consistent with a system that is still implanted. Preconditions: the vendor update is what closes the injection path and this control does not substitute for it; the control applies only to systems that were actually reachable during the window, not to every unit in the inventory; and where a rebuild genuinely cannot be scheduled, the honest record is an accepted exposure with a dated review, because the system continues to be trusted with no evidence it is clean — not a remediation entry.",
+        "evidence": "Packet: BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA); CWE-78 OS command injection; unauthenticated remote attacker executes operating system commands 'in the context of the site user'; vector states exploitation 'may lead to system compromise, including unauthorized access, data exfiltration, and service disruption'. active_exploitation confirmed; cisa_kev true, kev_date 2026-02-13; poc_available true; RWEP 83; 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.' Citing gaps closed here: CIS-Controls-v8-10.1 (Deploy and Maintain Anti-Malware Software), NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "CIS-Controls-v8-10.1",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "Remote Support and Privileged Remote Access are, by what the packet names them, the products through which support sessions into other systems are established, so command execution on them is not bounded by the systems themselves. Applied to this CVE, the control means the response includes an accounting of what passed through each affected system during the exposure window — the accounts that authenticated to or through it, the credential and session material it held for the systems it serves, and the trust those serviced systems extend to it — with each of those rotated or re-established rather than left standing because the system now reports a fixed version. Two preconditions must be stated rather than assumed. First, the scope list cannot be drawn solely from the affected system's own records: the packet gives an attacker executing operating system commands in the context of the site user, and records written on a system in that state are attacker-influenceable, so an off-system record of sessions is the authoritative source where one exists, and where it does not, the defensible scope is every account that used the service during the window. Second, this control assumes the deployment actually brokers access to other systems — the packet establishes the products and the exploitation outcome, not any particular site's session inventory, so the rotation list is a deployment fact the operator has to produce and it may be narrower or wider than the product name suggests. Rotation is also not containment on its own: it invalidates what the attacker took, it does not remove what the attacker left, which is the rebuild half of the response, and it gives nothing back to a system that was never reachable during the window. Distinguishing test: name the accounts whose sessions traversed each affected system between the earliest plausible compromise and completion of its rebuild, and show a rotation timestamp after that completion for each — an identity-and-access attestation showing that every technician holds a unique account with MFA passes cleanly here, because the packet's path never authenticates as any of them and no per-account privilege decision is ever consulted.",
+        "evidence": "Packet: BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA); CWE-78; vector states successful exploitation 'requires no authentication or user interaction' and that the attacker executes operating system commands 'in the context of the site user', which 'may lead to system compromise, including unauthorized access, data exfiltration, and service disruption'. cisa_kev true, kev_date 2026-02-13; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 83; patch_available true; live_patch_available false (vendor patch typically requires service restart or system reboot per the KEV requiredAction). Citing gaps closed here: UK-CAF-B2 (Identity and access control), NIST-800-53-AC-6 (Least Privilege).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2026-20700": {
     "name": "Apple Multiple Buffer Overflow Vulnerability",
@@ -16259,7 +16317,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "FreePBX's password check is where the product makes its access decision, and this CVE is that decision failing open: the packet describes unauthorized users bypassing password authentication and reaching the services provided by the FreePBX admin, ending in administrative access to the telephony server for an attacker who never held an account. Bound to this product, the control means each administrative function on the FreePBX server authorizes its caller itself rather than inheriting a verdict from the authentication layer that fronts it, and the administrative surface is segmented so an untrusted caller cannot present a request to that layer at all — the FreePBX admin interface answers only from an operator or management segment, or an authenticated VPN, and never from the internet or a general user or voice VLAN. The identity and least-privilege gaps recorded on this entry do not touch this path: because no password is presented, no password policy, lockout threshold or second factor on any operator account is ever exercised, per-account privilege scoping is never consulted, and the account model an identity attestation examines is bypassed rather than abused. Distinguishing test: from a segment with no operational need for telephony administration, issue unauthenticated requests to each administrative function on a staging FreePBX instance and confirm each refuses the caller before the function runs — an attestation that every FreePBX administrator holds a unique account with a strong password passes cleanly while this path stays fully open. Precondition: the per-function authorization property is what the vendor update establishes; this control states what to verify and what to restrict, it does not implement the fix. Restricting reachability bounds who can attempt the bypass but leaves it fully available to anything inside the permitted segment, and it is not available at all where the admin surface must stay reachable for remote administration — those instances depend on the update and its required service restart. And because active exploitation is confirmed, an instance whose admin surface was reachable during the exposure window needs its administrative accounts and the configuration reachable from that surface reviewed, and its credentials rotated; the update does not undo changes an attacker made while holding admin access.",
+        "evidence": "Packet records CWE-287 improper authentication. The vector states Sangoma FreePBX 'contains an improper authentication vulnerability that potentially allows unauthorized users to bypass password authentication and access services provided by the FreePBX admin', and the attack-vector line records an unauthenticated attacker gaining administrative access to the telephony server. CVSS 9.1, RWEP 77, poc_available true, active_exploitation confirmed, CISA KEV-listed 2026-02-03. patch_available true, live_patch_available false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot. Citing gaps include UK-CAF-B2 (identity and access control), NIST-800-53-AC-6 (least privilege) and NIS2-Art21-network-security — the first two are cited precisely because no account is authenticated anywhere on this path.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the control means the FreePBX fix is driven across every instance on the clock that opened with the 2026-02-03 KEV listing rather than deferred to the next telephony maintenance window, with completion measured per instance by the installed version against the vendor's fixed version and by the required restart having been taken — not by an update having been downloaded or scheduled. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot, so an instance that has taken the update but not restarted still runs the vulnerable code and must be counted as exposed; on a PBX that restart is also the step most likely to be deferred, because taking it interrupts calls in progress, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Priority follows the packet rather than the CVSS band: a public PoC plus confirmed exploitation against a pre-authentication administrative bypass on a telephony server means the routine cadence a PBX usually sits on is the wrong tier. The packet also pairs a 2019 CVE identifier with a 2026-02-03 KEV listing, which makes discovery the first task rather than the last — the exposed population is instances nobody is currently patching, so enumerate FreePBX servers that no software inventory tracks (branch sites, lab and test instances, vendor- or contractor-managed deployments) before measuring compliance against the ones already in the console. Precondition: the SLA governs the clock and provides no interim mitigation; until the restart completes, restricting which segments can reach the administrative surface is the only operator-side lever, and it is unavailable where that surface must stay reachable for remote administration.",
+        "evidence": "Packet records patch_available true, live_patch_available false, and live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' CISA KEV-listed 2026-02-03, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 9.1. The CVE identifier year (2019) and the KEV listing date (2026-02-03) are both packet fields; the discovery-first ordering is the inference drawn from that pairing, not a claim the packet makes. Citing gaps AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are the patch-cadence controls this listing outruns.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-40551": {
     "name": "SolarWinds Web Help Desk Deserialization of Untrusted Data Vulnerability (variant: CVE-2025-40551)",
@@ -17448,7 +17530,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 names five separately shipped products — Cisco Unified Communications Manager, Unified CM Session Management Edition, Unified CM IM & Presence Service, Unity Connection, and Webex Calling Dedicated Instance — each carrying its own version and its own upgrade, so a remediation record showing Unified CM at the fixed version says nothing about the IM & Presence Service or Unity Connection instances standing beside it. For this CVE the control's clock therefore has to be tracked per named product and per instance, running from the 2026-01-21 KEV listing. The mitigation the clock demands here is the vendor update and nothing else: the packet records patch_available true, live_patch_available false, and a note that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so there is no in-place mitigation to deploy while the update waits, and an instance that has taken the update but not restarted still runs the vulnerable code and must be counted as exposed rather than as met. Keep the sweep to the five products the packet names: it ties the CWE-94 sink to those and provides no mapping into other Cisco software, so treating every Cisco system in the estate as an instance of this CVE manufactures findings and upgrade work against products no evidence implicates. Priority follows the packet rather than the CVSS band on its own — confirmed in-the-wild exploitation, a public PoC, and an outcome the packet describes as user-level access to the underlying operating system followed by elevation to root, which means the end state is control of the platform, not degradation of a service. Distinguishing test: produce, per named product and per instance, the running version and the restart timestamp against the vendor's fixed version — a vulnerability-management attestation that records the estate as compliant because the change tickets closed inside the window passes cleanly while an unrestarted instance keeps serving.",
+        "evidence": "Packet: 'Cisco Unified Communications Manager (Unified CM), Cisco Unified Communications Manager Session Management Edition (Unified CM SME), Cisco Unified Communications Manager IM & Presence Service (Unified CM IM&P), Cisco Unity Connection, and Cisco Webex Calling Dedicated Instance contain a code injection vulnerability that could allow the attacker to obtain user-level access to the underlying operating system and then elevate privileges to root.' CWE-94. cisa_kev true, kev_date 2026-01-21, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps closed here: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The packet's escalation has two stages, and the second is the one this control governs: code injection gives the attacker user-level access to the underlying operating system of the Unified Communications product, and from that user-level context privileges are elevated to root. A constrained context reaching root operations on the platform beneath it is exactly the pattern the control forbids. Bound to these five products, it means the platform's privileged operations sit behind their own authorization boundary that the application tier can only reach through a constrained, validated interface, so that a defect in the application's input handling does not leave an attacker one step from root on the call-control and messaging platform. This is why the least-privilege gap cited on this entry cannot close the path: the escalation happens inside the product, between an operating-system user context the attacker obtained through injection and root — there is no operator-assignable account whose privileges could be narrowed to prevent it, so an attestation covering administrator accounts on these products passes while the path stays open. Preconditions, stated rather than implied: the boundary is a property the vendor update establishes, so this control names what to verify and does not implement it, and the packet records no live-patch path, meaning each instance carries the service restart or system reboot the fix requires before it is remediated. Until that lands, the operator-side lever is restricting which segments can reach the affected products' interfaces — that bounds who can attempt the injection but leaves the path fully exploitable to anything inside a permitted segment, and it is simply unavailable where the interface must stay reachable for the products to carry calls, voicemail and presence. And because active_exploitation is confirmed with a public PoC, any instance reachable during the exposure window needs forensic triage and credential rotation: an update applied to a system that already granted root does not remove what the attacker left behind.",
+        "evidence": "Packet: CWE-94 code injection in Cisco Unified CM, Unified CM SME, Unified CM IM&P, Cisco Unity Connection and Cisco Webex Calling Dedicated Instance; vector states the flaw 'could allow the attacker to obtain user-level access to the underlying operating system and then elevate privileges to root'. active_exploitation confirmed; cisa_kev true, kev_date 2026-01-21; poc_available true; CVSS 9.8; RWEP 77. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps closed here: NIST-800-53-AC-6 (Least Privilege), UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-20805": {
     "name": "Microsoft Windows Information Disclosure Vulnerability",
@@ -17657,7 +17763,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation here requires a victim to open an attacker-supplied presentation: the packet's vector is a PowerPoint file whose OutlineTextRefAtom carries an invalid index value, triggering memory corruption and code execution inside the PowerPoint process at the user's own privilege. On the unpatched long-tail installs the packet says the re-listing exists for, the delivery path is the only enforceable control. Require Mark-of-the-Web on every presentation arriving by mail, web download, or untrusted file share, and require MOTW-tagged presentations to open in Protected View — an isolated, reduced-privilege render — rather than the full parsing path that reaches the vulnerable record handling. Provenance has to survive the container: a presentation extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the tag rather than lose it, and 'Enable Editing' on externally sourced presentations must be blocked by policy rather than left to the user, because parsing the file is the whole exploit. Distinguishing test: mail a presentation nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — an application-hardening attestation covering only macro and ActiveX/OLE settings passes cleanly while a provenance-stripped presentation reaches the parser with full user privileges. Preconditions: Protected View bounds the render, it does not repair the parser. A user who clicks through to editing, or a file arriving on an ingress path that never applies the tag, is back on the vulnerable path with nothing in between — so the tagging must be enforced at each ingress rather than assumed. This is a holding measure for hosts that have not yet taken the vendor fix, not a substitute for it.",
+        "evidence": "Packet vector: a PowerPoint file with an OutlineTextRefAtom containing an invalid index value that triggers memory corruption, allowing remote attackers to execute arbitrary code; the packet's attack_vector places execution in the PowerPoint process. CWE-94. CISA KEV-listed 2026-01-07 with confirmed active exploitation; poc_available true; CVSS 9.8; RWEP 77. Citing gaps include AU-Essential-8-App-Hardening (User application hardening) and NIST-800-53-AC-6 (Least Privilege).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The vendor fix for this defect is not new; what the 2026-01-07 KEV listing changes is that the installs which never took it are now on a KEV clock. The packet states the reason for the re-listing outright — long-tail unpatched estates remain exposed — so for this CVE the control is not 'apply the update' but 'enumerate what never received it'. Run the clock from the listing against a census of every PowerPoint install actually in service, and measure completion by the build each install reports rather than by a 'no updates pending' state in a management console: the hosts that keep a defect of this vintage reachable are precisely the hosts that fell out of the managed update path, so the console's silence is an absence of visibility rather than evidence of remediation. The packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot, so an install updated but not restarted is still exposed. Distinguishing test: pull the reported PowerPoint build from every host carrying the product — including machines restored from backup images and rebuilt from older media, which is where a pre-fix build silently returns — and confirm none is pre-fix; a patch-management attestation scoped to the currently supported Office channel reports clean while the long-tail installs the packet names stay exploitable. Precondition: this closes the exposure only where the inventory can see the install. A copy no console enumerates is remediated by removing it or bringing it under management, never by recording it as compliant.",
+        "evidence": "patch_available true; live_patch_available false, with the packet noting no live-patch tool registered and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. CISA KEV-listed 2026-01-07 with confirmed active exploitation; poc_available true; CVSS 9.8; RWEP 77. The packet's attack_vector states the legacy re-listing exists because long-tail unpatched estates remain exposed. Citing gaps include NIST-800-53-SI-2 (Flaw Remediation), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-patch-management (Vulnerability handling and disclosure).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-37164": {
     "name": "Hewlett Packard Enterprise (HPE) OneView Code Injection Vulnerability",
@@ -21569,7 +21698,22 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Common Log File System Driver and describes a local, privileged attacker bypassing certain security mechanisms (CWE-269) — the attacker already holds a legitimate account on the host, so no account model is being abused and no credential is being guessed; a privilege boundary inside an operating-system driver is failing. For this CVE the control means the Windows update carrying the CLFS fix is driven across every affected host on the KEV clock that opened 2025-10-06 rather than folded into the next routine rollup, with completion measured per host by the installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot per the KEV required action, so a host that has taken the update but not restarted is still running the vulnerable driver and must be counted as exposed, not as patched-pending-reboot. That distinction is load-bearing here because there is no interim lever to hold the exposure down while the restart is deferred: the flaw is in a driver Windows ships as part of the operating system and loads on the running system, so unlike a vulnerable third-party driver there is nothing to blocklist and no module an operator can disable, and unlike a network-reachable flaw there is no segment to restrict — the restart is what puts the fixed code in service. The second half of the control is the half the citing gaps miss: because the attacker is already a local, privileged user, tightening account privilege or access control does not contain the escalation, which is why patch and vulnerability-management attestations are the ones that actually have to move on this entry. Priority follows the packet rather than the CVSS 7.8 band — a public PoC, confirmed in-the-wild 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 in a chain rather than a standalone endpoint hygiene item, and a host that was reachable to an untrusted local account during the exposure window warrants triage rather than being closed on the patch alone.",
+        "evidence": "The packet's vector states that Microsoft Windows Common Log File System Driver contains a privilege escalation vulnerability that could allow a local, privileged attacker to bypass certain security mechanisms, classified CWE-269. CISA KEV-listed 2025-10-06 with active_exploitation confirmed and poc_available true; CVSS 7.8, RWEP 77. patch_available true; live_patch_available false, with the packet noting no live-patch tool registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The packet's attack_vector adds that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators. The framework controls this entry already cites as insufficient are ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8, EU NIS2 Article 21 vulnerability handling and disclosure, NIST SP 800-53 SI-2 Flaw Remediation, and UK NCSC CAF B4 System security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2013-3918": {
     "name": "Microsoft Windows Out-of-Bounds Write Vulnerability",
@@ -22882,7 +23026,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Android Runtime and describes a use-after-free (recorded under CWE-269) reached by a local app to escalate privileges on the device, with the vector naming a Chrome sandbox escape as the route in. Nothing about the account model is being abused here — the attacker already holds execution inside a sandboxed context and a privilege boundary inside the runtime is what fails — so for this CVE the control means the vendor fix is driven across every managed Android device on the clock that opened with the 2025-09-04 KEV listing, rather than left to whenever each handset next takes an update. Completion has to be measured by the patch level the device itself reports back to the management platform, not by 'update pushed' or 'policy applied' in the console. The packet records a vendor patch with no live-patch path and notes the fix typically requires a service restart or system reboot, so a device that has downloaded and staged the update but has not restarted still runs the vulnerable runtime and must be counted as exposed — on a phone the restart is the step a user defers indefinitely, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Priority follows the packet rather than the 7.8 base score: a public PoC, confirmed in-the-wild exploitation, and the packet's own framing of this as the local-escalation half of a mobile exploit chain make it the step that converts a browser-sandboxed foothold into device-wide compromise, which is why it belongs on a chain-containment clock rather than in the routine mobile-update queue. Precondition: this control only reaches devices whose vendor is still shipping them the fix and whose reported patch level the operator can actually see; a device that cannot reach the fixed level is not remediated by scheduling it, and belongs on a replacement or access-denial path instead.",
+        "evidence": "Packet facts only: cwe_refs CWE-269; vector states Android Runtime contains a use-after-free 'potentially allowing a chrome sandbox escape leading to local privilege escalation'; attack_vector describes exploitation by a local app to escalate privileges and calls it the local-escalation step after an initial-access primitive in a mobile exploit chain, with escalation flaws of this class forming the second half of an intrusion chain; cisa_kev true with kev_date 2025-09-04; active_exploitation confirmed; poc_available true; rwep_score 77 against cvss 7.8; patch_available true; live_patch_available false with live_patch_notes recording no live-patch tool for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Exploitation as the packet describes it needs attacker code already executing on the handset — a local app, or the Chrome sandbox the vector names — so on this entry the control's access-condition half is the load-bearing one. The fixed Android patch level has to function as a condition of access: a device below it is refused organizational mail, VPN and document access until it takes the fix and completes the restart the packet says the vendor patch requires. The distinguishing test is to enrol a device held below the fixed patch level and confirm the policy actually denies it protected resources; an estate that surfaces the stale patch level on a compliance dashboard while the device keeps its access has recorded the exposure rather than removed it, and the flaw-remediation and technical-vulnerability attestations cited against this entry pass on exactly that kind of reporting. Precondition, and this is where the control is usually over-claimed: restricting which applications may install raises the bar for getting the attacker's local app onto the device, but it does not evict an app already installed, and it does not cover the second delivery path the packet names at all — a Chrome sandbox escape routes through the browser that is already on the device and is driven by rendered web content, so no install decision is ever made and no install policy is ever consulted. A device suspected of having already run the escalation belongs on the incident path, not the install-policy path. This is a holding measure for the window before the fixed runtime and its restart land, not a substitute for them.",
+        "evidence": "Packet facts only: vector states the Android Runtime use-after-free potentially allows a chrome sandbox escape leading to local privilege escalation; attack_vector states exploitation is by a local app escalating privileges on the device; active_exploitation confirmed with poc_available true and kev_date 2025-09-04; patch_available true; live_patch_available false, with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The citing framework gaps recorded on this entry are the patch and technical-vulnerability-management controls (AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2) plus UK-CAF-B4 system security.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-53690": {
     "name": "Sitecore Multiple Products Deserialization of Untrusted Data Vulnerability",
@@ -22942,7 +23110,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The packet puts the secret inside the product rather than in the operator's configuration: Sitecore Experience Manager, Experience Platform, Experience Commerce and Managed Cloud carry a deserialization-of-untrusted-data flaw involving the use of default machine keys, and the exploitation path is a known/static ASP.NET machine key abused through ViewState to reach unauthenticated remote code execution. Because the ViewState key is a value the attacker already holds rather than one they must obtain from the target, no amount of operator-side password or account hygiene reduces the exposure — which is exactly why the least-privilege gap is recorded against this entry: the attacker never authenticates as any Sitecore user, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the path stays open. Bound to these products, the control means enumerating every XM, XP, XC and Managed Cloud instance in the estate as depending on a product-supplied machineKey, then for each one reading the key actually in effect at runtime and confirming it is unique to that instance rather than a product-default or template-inherited value. Re-run that check after any deployment clone, image restore, environment refresh or scale-out of a content-delivery role, since those are the operations that quietly reintroduce one shared key across a set of instances that had already been rotated — the unit of remediation is the key, so a farm whose nodes share one configuration is one key, not many. Precondition: the packet records a vendor patch with no live-patch path, and its live-patch note states the fix typically requires a service restart or system reboot per the KEV requiredAction, so an instance that has taken the update but not restarted is not yet remediated. Replacing the key also removes only future forgery — with exploitation confirmed in the wild and a public PoC, an instance that served a default key while reachable needs its deployed assemblies, content tree and administrator accounts compared against a known-good state and any credential material handled during the exposure window rotated. This control governs whether the key is unique; it does not evict a foothold established before it was changed.",
+        "evidence": "Packet vector: Sitecore XM, XP, XC and Managed Cloud \"contain a deserialization of untrusted data vulnerability involving the use of default machine keys. This flaw allows attackers to exploit exposed ASP.NET machine keys to achieve remote code execution.\" Attack vector records CWE-502 \"abusing a known/static ASP.NET machine key via ViewState, enabling unauthenticated remote code execution.\" CISA KEV-listed 2025-09-04, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false with the note 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": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A version-based verdict is the specific way remediation goes wrong on this CVE. The packet's exploitation path is a known/static ASP.NET machine key abused through ViewState, so a Sitecore instance can sit at the vendor's fixed release and stay fully exploitable if the default machine key the packet names was never replaced — a scanner reads the product version, and the product version is not where this vulnerability lives. The operational test that separates paper compliance from remediation, per instance of XM, XP, XC and Managed Cloud: produce the machineKey in effect at runtime and show that it is not a product-default or template-inherited value, that it differs between instances built from the same deployment template, and that it was generated after that instance's exposure window rather than carried across the update unchanged. A vulnerability-management report listing the instance as patched on version evidence alone has recorded the update and not the fix, and the same report will keep reading clean on every instance the deployment pipeline recreates from the pre-rotation template. Precondition: this is a verification control — it tells the operator whether the exposure is actually gone, it does not remove it, and neither the version check nor the key check speaks to whether the instance was already exploited. With the packet recording confirmed in-the-wild exploitation and a public PoC, an instance that fails this test on first run has to be treated as having been reachable with a known key, which is an incident-triage question rather than a scan-and-close one.",
+        "evidence": "Packet vector: the flaw \"involv[es] the use of default machine keys\" and \"allows attackers to exploit exposed ASP.NET machine keys to achieve remote code execution\" across Sitecore XM, XP, XC and Managed Cloud. Attack vector: CWE-502 deserialization \"abusing a known/static ASP.NET machine key via ViewState, enabling unauthenticated remote code execution.\" CISA KEV-listed 2025-09-04 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 77. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-50224": {
     "name": "TP-Link TL-WR841N Authentication Bypass by Spoofing Vulnerability",
@@ -23147,7 +23339,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries two facts that have to be resolved per unit before anything else: a vendor patch is recorded as available, and the entry's own vector states the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization. So the first requirement is an inventory that names every TL-WA855RE in service with its hardware revision and an end-of-support date obtained from the vendor, not an assumption in either direction. Units whose revision still has supported firmware are patch items and belong on the remediation clock; units whose revision has none cannot be patched at all and are replacement items with a dated schedule, because a risk acceptance with no removal date leaves a KEV-listed device with a public exploit in service indefinitely. The exposure the inventory is scoring is specific: a single unauthenticated TDDP_RESET POST factory-resets and reboots the extender, after which the attacker sets a new administrative password and holds the device. Precondition on the reachability half, which is where this control is usually over-claimed: restricting the management surface bounds who can send that POST, but the packet's only stated access requirement is being on the same network, and a range extender exists to serve the client network it sits on — every client associated to it satisfies that condition, so for a unit extending a general user WLAN there is no segment that removes the path, only isolation of the extended WLAN itself from anything that matters. And because active exploitation is confirmed, a unit that was already reset and re-provisioned by an attacker is not remediated by firmware: its configuration and administrative credential are attacker-set and must be rebuilt from a known-good baseline rather than inherited through the update.",
+        "evidence": "The packet's vector states that TP-Link TL-WA855RE contains a missing authentication for critical function vulnerability allowing an unauthenticated attacker on the same network to submit a TDDP_RESET POST request for a factory reset and reboot, after which the attacker can obtain incorrect access control by setting a new administrative password; it further states the impacted products could be end-of-life (EoL) and/or end-of-service (EoS) and that users should discontinue product utilization. CWE-306; CISA KEV-listed 2025-09-02 with active_exploitation confirmed; poc_available true; CVSS 9.1, RWEP 77; patch_available true, live_patch_available false. ISO/IEC 27001:2022 A.8.8 and EU NIS2 Article 21 network and information system security are recorded among the framework controls insufficient for this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock is not the hard part on this entry; delivery is. The packet records a vendor patch with no live-patch path and a note that the vendor patch typically requires a service restart or system reboot per the KEV required action, so remediating a TL-WA855RE means each physical unit is taken through a firmware update and a reboot by hand. A consumer-grade Wi-Fi range extender is on no managed patch console, which means the KEV clock that opened 2025-09-02 can only be discharged against a hand-maintained inventory of where these units are actually deployed, and completion has to be measured by the firmware version the unit reports after it comes back up — not by an update having been pushed or a ticket closed. Urgency follows what the packet records rather than the CVSS band alone: exploitation is confirmed in the wild, a PoC is public, and the exploit is a single unauthenticated request that needs nothing but network adjacency. Precondition and limit: the packet also states the impacted products could be end-of-life or end-of-service with users advised to discontinue use, so for any unit whose hardware revision has no supported firmware this SLA cannot be met by patching at all and the item is discharged only by replacement — the two controls on this entry are read together, not as alternatives.",
+        "evidence": "CISA KEV-listed 2025-09-02 with active_exploitation confirmed and poc_available true. patch_available true; live_patch_available false, with the packet noting no live-patch tool registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The exploit path recorded is an unauthenticated TDDP_RESET POST from an attacker on the same network. ASD Essential Eight 'Patch operating systems' and NIST SP 800-53 SI-2 Flaw Remediation are recorded among the framework controls insufficient for this entry. CVSS 9.1, RWEP 77.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-55177": {
     "name": "Meta Platforms WhatsApp Incorrect Authorization Vulnerability",
@@ -23612,7 +23826,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The Citrix Session Recording server is the deserialization sink here, and the packet's stated access requirement is why a perimeter-shaped defence does nothing for it: the attacker is an authenticated user on the same intranet as the recording server, so the traffic carrying the untrusted serialized object is ordinary internal traffic from an ordinary internal account. Bound to this product, the control means the Session Recording server's listening surface is treated as a trust boundary rather than an internal convenience — it accepts connections only from the hosts that legitimately deliver session-recording traffic and from the administrative segment that manages the server, enforced by host firewall or network ACL rather than inherited from the assumption that the recording server is internal, and the content arriving on that surface is constrained to what the service legitimately needs instead of being reconstructed into arbitrary objects. The sink's own content handling is the only thing standing between an unprivileged intranet account and execution as the NetworkService account on the recording server, because the caller's account privilege is never consulted on this path. Distinguishing test: from a general user VLAN on a staging deployment, open a connection to the Session Recording server's listening surface and send content the service never legitimately receives, and confirm the peer is refused before the content is deserialized — a deployment that passes a Citrix role-and-permission review while the recording server answers from every internal segment still carries the path. Precondition, and this is where the control is usually over-claimed: restricting reachability bounds which hosts and accounts can present the payload, it does not repair the deserialization, and any authenticated user inside a permitted segment satisfies the packet's stated access requirement in full. It is a holding measure for the window before the vendor update and its required restart land, and it offers nothing where the recording server must stay reachable from the segments that legitimately deliver recordings.",
+        "evidence": "Packet records CWE-502 deserialization of untrusted data in Citrix Session Recording. The vector states the flaw 'allows limited remote code execution with privilege of a NetworkService Account access' and that the 'Attacker must be an authenticated user on the same intranet as the session recording server'. CVSS 9.8, RWEP 77, poc_available true, active_exploitation confirmed, CISA KEV-listed 2025-08-25. Citing gaps include NIS2-Art21-network-security and UK-CAF-B4; NIST-800-53-AC-6 is also cited, consistent with an access requirement that any authenticated intranet account satisfies regardless of its privilege.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the control means the Citrix Session Recording update is driven across every recording server on the clock that opened with the 2025-08-25 KEV listing, rather than folded into the next scheduled virtualization-platform maintenance window, with completion measured per server by its installed version against the vendor's fixed version and by the required restart having been taken — not by 'approved' or 'downloaded' in a management console. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot, so a recording server that has taken the update but not restarted still runs the vulnerable code and must be counted as exposed. The tier assignment is the load-bearing part: because the exploit's only stated access requirement is an authenticated account on the same intranet, an internal, non-internet-facing recording server does not qualify for the relaxed cadence such assets normally receive — internal reachability is this exploit's precondition, not a mitigating factor, which is exactly how the patch-cadence controls cited on this entry pass their attestations while the server stays exploitable. Precondition: the SLA governs the clock, it supplies no interim mitigation; for the window before the restart completes, constraining who can reach the recording server's listening surface is the only operator-side lever. And because active exploitation is confirmed, a recording server that was reachable by intranet accounts during the exposure window belongs on the incident path rather than being closed on the patch — the update removes the deserialization path, not anything an attacker executed as NetworkService through it.",
+        "evidence": "Packet records patch_available true, live_patch_available false, and live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' CISA KEV-listed 2025-08-25, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 9.8. The vector's access requirement — an authenticated user on the same intranet as the session recording server — is the packet fact that rules out treating this as a low-urgency internal asset. Citing gaps AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are the patch-cadence controls this listing outruns.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-54948": {
     "name": "Trend Micro Apex One OS Command Injection Vulnerability",
@@ -26693,7 +26930,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The packet states that this flaw affects various products implementing the Erlang/OTP SSH server, including but not limited to Cisco, NetApp and SUSE. For most operators that means the vulnerable code is not something they installed but something a vendor embedded, and no host in the estate reports 'Erlang/OTP' anywhere an administrator would look. Bound to this CVE the control means the component inventory has to be able to answer 'which products in service contain an Erlang/OTP SSH server' from vendor SBOM and advisory data rather than from installed-package lists, with the three vendors the packet names enumerated first and the enumeration extended by vendor response rather than stopped there — the packet's own wording is explicitly non-exhaustive, so treating those three as the affected set is a decision to leave the rest unknown. The distinguishing test is deliberately an absence test done properly: take an appliance whose vendor is not one of the three named and show the answer to 'does this product embed an Erlang/OTP SSH server?' comes from that vendor's SBOM or advisory, not from the absence of an Erlang package on the host — for an embedded runtime, absence from an installed-software list and true absence look identical. Precondition: the inventory remediates nothing on its own; it determines which vendor updates apply. The packet records a vendor patch, no live-patch path, and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so each identified product carries its own update and its own restart, and a product identified and updated but not restarted is still running the vulnerable listener. The packet names no fixed Erlang/OTP release, so the fixed version is whatever each product's vendor publishes for that product.",
+        "evidence": "Packet vector: 'This vulnerability could affect various products that implement Erlang/OTP SSH server, including—but not limited to—Cisco, NetApp, and SUSE.' CWE-306; CVSS 9.8; RWEP 77; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-06-09. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Erlang/OTP SSH server is exactly the pre-authentication protocol listener this control governs: the packet places the defect in how SSH protocol messages are handled and has an attacker executing arbitrary commands without valid credentials, so the message handler answers — and is exploitable — before any credential is presented, and the parser is itself the vulnerable code. Bound to this deployment the requirement is that the SSH surface of every product identified as embedding the Erlang/OTP SSH server accepts connections only from the management and jump networks that legitimately administer it, enforced by network ACL or host firewall rather than assumed from 'SSH is internal', and that this KEV-listed defect is remediated on an accelerated clock with the service restart or reboot the packet records actually taken rather than folded into the next maintenance window. This is also why the least-privilege and identity-and-access gaps recorded against this entry do not close the path: the attacker never authenticates, so no account's privileges are consulted and the account model an identity attestation examines is bypassed rather than abused — key-only authentication, disabled password login, MFA on SSH accounts and per-account privilege scoping all pass cleanly while the pre-auth path stays fully open. Distinguishing test: from a segment with no administrative role, open a connection to the SSH port of each identified product on a staging instance and confirm it is refused before the protocol exchange begins. Preconditions: reachability restriction bounds who can send the pre-authentication messages, it does not repair the handler; it is unavailable wherever that SSH surface must stay reachable for normal operation, and any compromised jump host or automation account already inside the permitted segment satisfies the exploit's only stated requirement in full. Because the packet records confirmed exploitation with a public PoC, a product whose SSH surface was reachable during the exposure window needs forensic triage and credential rotation — the update closes the path, it does not remove what unauthenticated command execution left behind.",
+        "evidence": "Packet vector: 'Erlang Erlang/OTP SSH server contains a missing authentication for critical function vulnerability. This could allow an attacker to execute arbitrary commands without valid credentials... By exploiting a flaw in how SSH protocol messages are handled, a malicious actor could gain unauthorized access to affected systems.' CWE-306; CVSS 9.8; RWEP 77; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-06-09. patch_available true; live_patch_available false; live_patch_notes records that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B2 (Identity and access control).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2025-5419": {
     "name": "Google Chromium V8 Out-of-Bounds Read and Write Vulnerability",
@@ -27533,7 +27794,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a severity-tiered remediation queue and the real exposure disagree: CVSS 6.1 puts it below the critical/high trigger most patch programs act on, while the packet carries RWEP 77, confirmed in-the-wild exploitation, a public PoC and a CISA KEV listing dated 2025-05-19. Bound to this product the control means the ZCS remediation item opens on the KEV listing rather than on the CVSS band, and completion is measured by each mailbox node running the vendor-fixed release with the restart taken — the packet records a vendor patch, no live-patch path, and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so a node that has taken the package but not restarted is still serving the vulnerable CalendarInvite render path and must be counted as exposed. The distinguishing test is to produce the remediation record for this CVE and show what triggered it: a program ordered by CVSS will show this sitting in a medium-severity backlog with an attestation that reads clean, while a flaw with confirmed exploitation executes attacker JavaScript in users' authenticated mail sessions. Precondition: the vendor release closes the render path, it does not undo a session that was already scripted. Arbitrary JavaScript in an authenticated webmail session can do whatever that session can do, so with exploitation confirmed, mailboxes whose users opened invites during the exposure window need review of the state that session could have changed — forwarding and filter configuration, and message access — rather than being closed on the patch.",
+        "evidence": "Packet: CVSS 6.1 against RWEP 77; CWE-79; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-05-19. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Vector places the flaw in 'the CalendarInvite feature of the Zimbra webmail classic user interface'. No fixed ZCS version is recorded in the packet.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Zimbra's classic web client is the webmail tier this control governs, and this CVE is precisely the failure mode it exists for: the packet has the payload arriving inside an email message's crafted calendar header, executing when the CalendarInvite feature renders it, and running in a victim's already-authenticated session. Nothing in that sequence produces an authentication event — the user signed in normally, once, before the message arrived — so an estate whose mail-platform logging is authentication events plus administrator actions holds no record that exploitation occurred. Bound to this product the requirement is per-request access logging from every ZCS mailbox node forwarded to a SIEM outside the mail platform, retained long enough to cover a window that opened before the 2025-05-19 KEV listing, and correlated with inbound-message telemetry. The two observable halves of what the packet describes are an inbound message carrying markup in a calendar header, and subsequent requests issued inside one already-authenticated session that do not correspond to what that user was doing, with no new sign-in between them. A rule keyed on failed logins, impossible-travel or new-device sign-ins, or malicious attachments fires on none of it: there is no failed login, no new device, and no attachment — the payload rides a header on an otherwise ordinary invite. Distinguishing test: send a benign but structurally equivalent invite carrying markup in the calendar header to a mailbox on a staging node, open it in the classic UI, and confirm the SIEM shows both the inbound message and the resulting per-request activity under the pre-existing session; if the only retrievable artifact is that day's login event, the logging cannot evidence this exploitation. Precondition: this is detection, not prevention — it does not stop the script from running and it yields nothing retrospectively if per-request logs were never retained, so it has value only where it was already in place. It covers only the nodes actually forwarding.",
+        "evidence": "Packet vector: 'Zimbra Collaboration contains a cross-site scripting (XSS) vulnerability in the CalendarInvite feature of the Zimbra webmail classic user interface. An attacker can exploit this vulnerability via an email message containing a crafted calendar header, leading to the execution of arbitrary JavaScript code.' Attack vector: 'letting an attacker run script in a victim's authenticated session.' CWE-79; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-05-19.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-27920": {
     "name": "Srimax Output Messenger Directory Traversal Vulnerability",
@@ -28067,7 +28351,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Ancillary Function Driver for WinSock (afd.sys) and describes an authorized attacker escalating to administrator — the account is legitimate, so no account model is being abused; a privilege boundary inside a kernel driver is failing. For this CVE the control means the Windows update carrying the afd.sys fix is driven across every affected host on the clock that opened with the 2025-05-13 KEV listing rather than folded into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. Hosts where non-administrative users hold interactive sessions are the population to enumerate first, because the precondition this flaw needs — an already-authorized local user — is the normal operating state there 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 per the KEV requiredAction, so a host that has installed the update but not restarted still runs the vulnerable driver and must be counted as exposed; the restart is also the step most likely to be deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. The load-bearing half is that tightening account privilege does not contain this escalation at all: the attacker already holds an authorized local session, which is exactly why a patch-cadence attestation can report the estate compliant while the flaw stays fully exploitable on every host that has not restarted. Priority follows the packet rather than the 8.8 band — a public PoC, confirmed in-the-wild 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 in a chain rather than a standalone endpoint ticket. Distinguishing test: report installed build plus last-restart time per host against the fixed build, and confirm the reboot-pending population is counted as exposed rather than as remediated.",
+        "evidence": "Packet: 'Microsoft Windows Ancillary Function Driver for WinSock contains a use-after-free vulnerability that allows an authorized attacker to escalate privileges to administrator' (CWE-416); attack_vector: 'a use-after-free (CWE-416) in the Windows Ancillary Function Driver for WinSock (afd.sys), exploited by a local foothold to escalate privileges to SYSTEM ... LPEs of this class are routinely paired with an initial-access flaw by ransomware operators'. cisa_kev true, kev_date 2025-05-13, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 77. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps closed here: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Detection for this CVE has to key on what the packet says the exploit achieves: an already-authorized local user context becoming administrator or SYSTEM through the afd.sys use-after-free. The signal is that privilege transition itself — a process owned by a standard interactive user acquiring a SYSTEM-level token, or spawning a child running as SYSTEM, without having passed through a sanctioned elevation path (a consented UAC elevation, a service-control-manager start, a task registered by an administrator) — with the alert raised inside the control's stated window. An exploit doing exactly what the packet describes emits that transition, which is why it is the right anchor: a rule built instead on afd.sys crash or bugcheck telemetry would miss the case that matters, because a working exploit escalates rather than faults, and a rule built on named tooling or file hashes misses any re-implementation of the same use-after-free by a different operator. Because the packet gives no live-patch path and a restart-gated fix, this is the control that covers the interval between the 2025-05-13 KEV listing and the last host's restart, and it is worth weighting toward the hosts where that restart is most deferred and where non-administrative users hold interactive sessions. Distinguishing test: on a staging host, have a benign program running as a standard user obtain a SYSTEM token by a route the elevation allowlist does not cover, and confirm the alert actually fires — verifying that the agent is installed and its policy reads 'enabled' proves nothing about whether the transition is detected. Preconditions: this is a dwell-time control, not a mitigation — it fires after the escalation has already happened and reduces none of the exposure the reboot-pending hosts carry; telemetry from a host where an attacker reached SYSTEM is attacker-influenceable, so the alert has to leave the host and be evaluated off-box to survive the event it exists to catch; and sanctioned elevation is routine on administrator and developer workstations, so the allowlist of legitimate transition paths must be built per host population before the rule is enabled, or it will be tuned off within a week.",
+        "evidence": "Packet: CWE-416 use-after-free in the Windows Ancillary Function Driver for WinSock (afd.sys); vector: 'allows an authorized attacker to escalate privileges to administrator'; attack_vector: 'exploited by a local foothold to escalate privileges to SYSTEM'; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-05-13; CVSS 8.8; RWEP 77. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gap closed here: UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-30397": {
     "name": "Microsoft Windows Scripting Engine Type Confusion Vulnerability",
@@ -30658,7 +30965,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "This entry is the case the control exists for, because the remediation the packet records for Postfix has two halves and only one of them is a package version: a software update, and — the packet names it explicitly for the STARTTLS class — a server configuration change. The vulnerable behaviour is not a memory-corruption bug that a binary replaces but an acceptance decision about bytes that arrived before the TLS handshake, and that decision is also governed by how the MTA is configured to offer and require transport security. Applied to this deployment: enumerate every Postfix instance together with its transport-security configuration, and hold the configuration change as a tested, deployable artifact maintained independently of the maintenance-release rollout, so an instance whose package cannot move immediately still has a lever. Distinguishing test, keyed on the behaviour the packet describes rather than on a version string: from an on-path position against a staging instance, deliver plaintext SMTP command bytes after the STARTTLS response and before the handshake, then confirm they are not executed in the encrypted session that follows — a scan that reads the Postfix package version cannot tell a fixed instance from one that still carries the buffering defect. Precondition, and it is a real limit: the configuration lever only removes the in-band upgrade for peers that can be moved off it. A peer that can only negotiate opportunistically still performs the in-band upgrade against the buffering defect, and for those sessions nothing but the patched 2.x maintenance release the packet names closes the path. The packet records no live-patch primitive and a service restart rather than a host reboot, so an instance whose package was replaced without that restart is still running the vulnerable code; the configuration change is a holding measure for the window before the restart, not a substitute for it.",
+        "evidence": "Packet vector: Postfix's STARTTLS implementation 'does not properly restrict I/O buffering, so plaintext SMTP commands inserted by a man-in-the-middle before the TLS handshake are executed within the encrypted session afterward. Fix: upgrade to the patched 2.x maintenance release.' live_patch_notes: 'Remediation is a software update (and, for the smuggling/STARTTLS classes, a server configuration change); no live-patch primitive applies. Service restart, not host reboot.' patch_available true, live_patch_available false. CWE-77 / CWE-264; CVSS 4.8, RWEP 17; poc_available true; cisa_kev false; active_exploitation none.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The packet places this Postfix defect at the head of a lineage rather than treating it as a closed 2011 item: it records the entry as part of the NO STARTTLS research lineage running from 2011 Postfix to a 2021 multi-MTA round — the same failure to discard bytes buffered before the handshake resurfacing in other mail transfer agents a decade later. For this entry the control means the transport-security configuration change the packet names as part of remediation is not reverted the moment the patched 2.x maintenance release lands and the service restarts; it stays in place through a stated review period, because the primitive it constrains has already demonstrated that it reappears in implementations previously considered fixed. Precondition: retention only helps for the sessions the configuration actually governs — it does nothing for a peer that can only negotiate the in-band upgrade, and it does not detect an injection that already succeeded, because the packet has the injected commands executing inside the encrypted session, carried on the same channel as the legitimate peer's traffic. Retention is also not grounds to defer the update: patch_available is true and the packet registers no live-patch primitive, so every instance still has to take the maintenance release and the service restart. Priority follows the packet rather than the CWE severity: cisa_kev is false and active_exploitation is none, so this belongs on the scheduled maintenance path, and the reason to keep the compensating configuration is the recurrence the packet documents, not an active-exploitation clock.",
+        "evidence": "Packet attack_vector: 'STARTTLS command/response injection: the server/client does not discard bytes buffered before the TLS handshake, so an on-path attacker injects plaintext SMTP commands/responses that are processed inside the encrypted session. Part of the NO STARTTLS research lineage (2011 Postfix → 2021 multi-MTA).' live_patch_notes names a server configuration change for the smuggling/STARTTLS classes alongside the software update, with no live-patch primitive and a service restart rather than a host reboot. cisa_kev false; active_exploitation none; RWEP 17; CVSS 4.8; poc_available true; patch_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-50387": {
     "name": "KeyTrap — DNSSEC validating-resolver CPU exhaustion via crafted DNSKEY/RRSIG combinations",
@@ -32088,7 +32418,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Unified CM is the call-control plane the packet names, and the defect sits on a service endpoint it exposes: WebDialer is reachable by an unauthenticated remote attacker, and improper input validation of specific HTTP requests lets the caller choose what the server requests and drives file writes to the underlying OS that are then used to reach root. Bound to this product, the control means the WebDialer request handlers authorize their caller before the request is processed at all, and the destination the server is asked to contact and the path it is asked to write are canonicalized and validated against an allowlist before either action executes — so a caller-supplied value cannot select an internal target or which file gets written; and no Unified CM node is left with WebDialer reachable from a segment that has no click-to-dial need. This is also why the cited boundary-protection gap does not close the path by itself: a perimeter that keeps the node off the internet still leaves the endpoint answering any host inside the permitted segment, and a boundary attestation passes cleanly while it does. Distinguishing test: from a segment with no click-to-dial requirement, send unauthenticated HTTP requests to the WebDialer endpoints on a staging node whose parameters name an internal address the server should never contact, and confirm each is refused before the server issues the outbound request or writes anything. Preconditions: endpoint-side authorization and input validation are properties the vendor update establishes — this control states what to verify, it does not implement it, and the packet registers no live-patch path for the product class. Restricting reachability bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable where WebDialer must stay reachable for normal click-to-dial operation. Because exploitation is confirmed and the packet's path ends in files written to the OS and root privilege, a node reachable during the exposure window needs forensic review — the update does not remove what was already written.",
+        "evidence": "Packet vector: 'The Unified CM WebDialer service is reachable by an unauthenticated remote attacker. Improper input validation of specific HTTP requests (CWE-918) lets the attacker coerce the server into issuing attacker-controlled requests and writing files to the underlying OS, which are then used to elevate to root. Cisco rates the Security Impact Critical above the 8.6 base because the end state is root compromise of the call-control plane.' cwe_refs CWE-918; cisa_kev true with kev_date 2026-06-25; active_exploitation confirmed; poc_available true; CVSS 8.6; RWEP 78. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives this entry a vendor update, no live-patch path for the product class, confirmed exploitation and a public PoC, so the remediation clock runs from the 2026-06-25 KEV listing through the update landing on every Unified CM node — including the nodes an operator would ordinarily defer, because a telephony cluster's change window is scheduled around call availability rather than around exploit availability. That deferral is the specific way this remediation goes wrong: the packet's end state is root on the call-control plane, so a node left running past the clock while the cluster waits for its next maintenance window is not the low-risk member of the cluster, it is the one the unauthenticated path reaches. Where a node genuinely cannot take the update inside the clock, the packet's own remediation line requires the compensating controls to be in force for the whole interval and the node counted as exposed, not recorded as scheduled.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-06-25, active_exploitation confirmed, poc_available true, CVSS 8.6, RWEP 78. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Vector records the end state as root compromise of the call-control plane.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet's remediation line for this entry — the vendor update plus the named compensating controls until it lands — describes exactly the intermediate state a vulnerability-management verdict collapses into 'handled'. For this product the interim measure is operator-side rather than a vendor rule: restricting which segments can reach WebDialer on an un-updated Unified CM node. That is the mitigation-active state, not remediation, and its residual risk is specific enough to record — anything that can already route to the node still reaches an unauthenticated endpoint whose documented end state is root. The verdict for this CVE must therefore carry the list of nodes still in that state, the segments each remains reachable from, and a dated action item for the vendor update, instead of reporting the cluster as remediated because a segmentation change was made. Precondition worth stating in the same verdict: for a node with confirmed exposure during the window, neither the segmentation change nor the later update evicts anything the attacker already wrote to the OS.",
+        "evidence": "Packet: live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands'; vector states the WebDialer service is reachable by an unauthenticated remote attacker and that the attacker-driven file writes are used to elevate to root; active_exploitation confirmed; poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-67038": {
     "name": "Lantronix EDS5000 Code Injection Vulnerability",
@@ -32198,7 +32560,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "UniFi OS is the management plane running on the device, and the defect sits on one of its configuration endpoints: the packet has the package-update handler passing attacker-influenced input into a command executed with root privilege, CWE-20 improper input validation becoming the CWE-78 injection. Bound to this product, the control means the update handler authorizes its caller before any supplied input is acted on, and neutralizes that input before the privileged command runs, so a caller-supplied value cannot become part of what the console executes as root; and it means no UniFi OS console is left with its management surface reachable from a network with no management role, including any path into the site from outside. Reachability is doing real work here, and it is also where this control is normally over-claimed. The packet says the flaw on its own requires reaching the handler, but chained behind CVE-2026-34908 (access-control bypass) and CVE-2026-34909 (path traversal) it completes an unauthenticated root RCE — so restricting who holds a UniFi administrative account changes nothing about this path, because the attacker never authenticates, and only restricting who can route to the management surface bounds the attempt. Distinguishing test: from a segment with no management role, and from outside the site, attempt to reach the UniFi OS management surface on a staging console and confirm the request is refused before the update handler is entered — a console that passes an administrator-account and password-policy audit while answering a general user VLAN or an inbound mapping is still fully exposed to the published chain. Precondition: the caller authorization and input neutralization are properties the vendor update establishes; this control states what to verify, it does not implement it. The packet records a vendor update with no live-patch path, so until that update lands, restricting reachability bounds the population that can present a request to the handler but leaves the handler itself entirely exploitable to anything inside the permitted segment, and it is unavailable wherever the console must stay reachable for remote site management.",
+        "evidence": "Packet facts only: cwe_refs CWE-20 and CWE-78; vector states the UniFi OS package-update handler passes attacker-influenced input into a command executed with root privilege, that on its own it requires reaching the handler, and that chained behind CVE-2026-34908 (access-control bypass) and CVE-2026-34909 (path traversal) it completes an unauthenticated root RCE that operators use to install a Mirai/Gafgyt-derived botnet; cisa_kev true with kev_date 2026-06-23; active_exploitation confirmed; poc_available true; cvss 10 with rwep_score 79; patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' NIST-800-53-SC-7 boundary protection is one of the framework gaps already citing this CVE.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at root RCE — it names the outcome operators are observing, a Mirai/Gafgyt-derived botnet installed on the device, with exploitation confirmed and the entry KEV-listed 2026-06-23. That makes the vendor update the wrong closing step for any console that was reachable by the chain during the exposure window: applying it removes the injection path but leaves an implant that was installed with root exactly where it is, along with whatever the attacker changed or read on the box, and the device keeps operating as a botnet member after the flaw-remediation ticket closes. For a suspect console the response is to treat it as compromised infrastructure rather than as a patch item — capture the running configuration for analysis, rebuild from vendor firmware rather than restoring that configuration wholesale, and rotate the console's administrative credentials along with anything else it stored or that was presented to it during the window, since the packet establishes the attacker held root and root on this device is custody of everything on it. The distinguishing test keys on what the packet documents rather than on tool signatures: an installed botnet client exists to reach its operator, so examine the console's own outbound connections for destinations that no management, update or telemetry function explains — a console that reports the fixed version and still initiates them was compromised before the update landed, and a version check alone cannot tell those two states apart. Precondition, stated rather than assumed: rebuild is warranted where the console was reachable by the chain during the exposure window. Where the packet's stated requirement of reaching the update handler was never satisfiable — a console with no route from any untrusted network across that period — the update alone is closure. Deciding which case a given console is in requires reachability evidence from the exposure window, not a present-tense assertion that the console sits on an internal network.",
+        "evidence": "Packet facts only: vector and attack_vector state the chain completes an unauthenticated root RCE that operators use to install a Mirai/Gafgyt-derived botnet; active_exploitation confirmed; cisa_kev true with kev_date 2026-06-23; poc_available true; cvss 10 with rwep_score 79; the flaw requires reaching the package-update handler on its own, and is chained behind CVE-2026-34908 and CVE-2026-34909; patch_available true with live_patch_available false and live_patch_notes stating remediation is the vendor update plus the named compensating controls until it lands. NIST-800-53-SI-2 flaw remediation and AU-Essential-8-Patch are among the framework gaps already citing this CVE.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2026-34909": {
     "name": "Ubiquiti UniFi OS Path Traversal Vulnerability",
@@ -33939,7 +34325,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's delivery is a spear-phished link to an attacker-controlled page, so every Chrome/Chromium install in the estate is in scope the moment a user can open a link — there is no server-side surface to isolate, and the packet names no configuration-side mitigation, recording remediation as the vendor update plus the named compensating controls until it lands. For this CVE the control means the managed update ring for Chrome/Chromium carries no deferral: the fixed build is driven out on the KEV clock that opened 2025-03-27 rather than held for a ring's soak period, and completion is measured by the build the browser is actually running on each host, not by the update being approved or downloaded in the management console, because the packet registers no live-patch path. Enumerate the Windows population first — the packet's primitive is the Windows sentinel handle (the -2 pseudo-handle) being supplied and used without validation while the broker duplicates handles across the renderer-to-broker boundary. Precondition, and it is the important one on this entry: the update removes the escape primitive, it does not evict an attacker who already used it. The packet has ForumTroll operators staging the Dante spyware loader through this chain into the medium-integrity browser/broker context with no user interaction beyond opening the link, so a host whose user opened the lure during the exposure window needs host-level triage; updating that host closes the door behind whatever is already inside it, and an estate that reports 100% on the fixed build has evidence about the primitive, not about residency.",
+        "evidence": "Packet: CWE-501 sandbox escape in Chrome/Chromium on Windows. 'A victim ... visits an attacker-controlled page (delivered via spear-phishing), giving the compromised renderer a reachable path to the Mojo IPC layer. A logic error causes an incorrect/sentinel OS handle (the -2 pseudo-handle) to be supplied and used without validation when the broker process duplicates handles across the renderer-to-broker boundary ... escalates the constrained, sandboxed renderer to arbitrary code execution in the medium-integrity browser/broker context, from which the ForumTroll operators staged the Dante spyware loader — all with no user interaction beyond opening the link.' CISA KEV 2025-03-27, active_exploitation confirmed, CVSS 8.3, RWEP 56, poc_available false. patch_available true, live_patch_available false; live-patch note: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Cited gaps include AU-Essential-8-Patch, NIST-800-53-SI-2, ISO-27001-2022-A.8.8 and UK-CAF-B4.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet's remediation note defines the interval this control governs in its own words — remediation is the vendor update plus the named compensating controls until it lands, with no live-patch path for this product class. On this entry that interval is unusually exposed, because the trigger is a user opening a link and the packet records the chain completing with no user interaction beyond that: a Chrome/Chromium host waiting on the fixed build is not carrying a reduced-probability version of the risk, it is carrying the full one behind measures that never touch the Mojo handle-duplication path. The requirement here is that such a host be recorded as a distinct, time-bound compensating-control state with an owner and a date — not folded into a 'patched per SLA' percentage — and that the evidence for the remediated state be the build the browser is actually running, since a console reporting the update approved, downloaded or pushed is reporting a deployment step rather than a remediation. Precondition: this control is bookkeeping. It makes the exposure visible and removes none of it, and it is worth attaching precisely because this exposure is the one most likely to be closed on paper: CVSS 8.3 on a browser reads as endpoint hygiene, while the packet records confirmed in-the-wild exploitation delivering a spyware loader. It also says nothing about a host that was already exploited during the window — that host belongs on the incident path regardless of which state the register shows.",
+        "evidence": "Packet: live_patch_available false with the note 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands'; patch_available true. Exploitation requires only that the victim open the attacker-controlled page — 'no user interaction beyond opening the link' — with active_exploitation confirmed and a CISA KEV listing of 2025-03-27. CVSS 8.3 against RWEP 56; poc_available false. Cited gaps include ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-9875": {
     "name": "Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (post-authentication)",
@@ -34885,7 +35295,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "SimpleHelp is a remote-support server and the packet gives the bypass no cost: an unauthenticated remote caller submits an identity token whose cryptographic signature is never verified and receives a fully authenticated technician session, with no user interaction. For this entry the control means the vendor update is driven across every SimpleHelp server instance on the KEV clock that opened 2026-06-29 against a 2026-07-02 due date — a three-day window, not a monthly cycle — with completion measured by each server's running version against the fixed one rather than by an approved change ticket, since the packet places the defect in versions 5.5.15 and prior and in 6.0 pre-release builds. The packet records a vendor patch and no live-patch path, so nothing mitigates a running instance short of taking it through that update. The population to enumerate first is the servers that have OIDC authentication configured: the packet conditions the bypass on that configuration ('When OIDC authentication is configured'), so that enumeration is what bounds the exposed set while the update rolls. Precondition, and it is narrow: taking the OIDC login path out of service removes the stated precondition only on an instance whose technicians hold another login method, it is unavailable where OIDC is the organization's only route into the console, and it does nothing about a session an attacker already holds — the forged token yields the session directly, so an instance that was reachable with OIDC configured during the window belongs on the incident path, not the configuration path. Priority follows the packet rather than the RWEP band: the absence of a public PoC is the only thing holding the score below the CVSS 10 and confirmed-exploitation signals, and it is not a reason to let a three-day due date slip.",
+        "evidence": "Packet: CWE-347; 'SimpleHelp versions 5.5.15 and prior and 6.0 pre-release versions contain an authentication bypass vulnerability in the OIDC authentication flow. When OIDC authentication is configured, identity tokens submitted during login are accepted without verifying their cryptographic signature'; 'a remote, unauthenticated attacker can submit a forged token containing arbitrary identity claims to obtain a fully authenticated technician session'; 'No user interaction is required'; CISA KEV-listed 2026-06-29 (due 2026-07-02) with confirmed in-the-wild exploitation; CVSS 10, RWEP 50, poc_available false; patch_available true, live_patch_available false with the note 'No live-patch path for this product class; remediation is the vendor update ... plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The asset at risk here is not the SimpleHelp server's own files but what a technician session on it can do to the endpoints that server administers, and the packet hands an attacker that session outright: a forged token carrying arbitrary identity claims, accepted without signature verification, and in some configurations without the second factor. Applied to this product, the control means the SimpleHelp installation and every directory it serves artifacts from are file-integrity-monitored, and every technician session in the exposure window is reconciled against a sanctioned administrator action rather than read off the session's own identity — the claims in that session are attacker-chosen, so the username attached to it is not evidence of who opened it. The distinguishing test keys on precisely what the packet describes the exploit producing, a session created from a token the identity provider never issued: list SimpleHelp technician sessions across the window and match each against a sign-in record at the configured OIDC provider; a technician session with no corresponding provider authentication event is the signal, while an authentication log that records only 'technician logged in' shows the forged session as a clean login. This is the control that retains value after the update lands, because the fix restores signature verification and removes nothing that was pushed, run, or created through a session obtained before it. Precondition: this is detection and eviction, not prevention — it does not stop the forged token, only the vendor update does, and the reconciliation depends on session and identity-provider logs retained from before the update. Where those logs have rolled or the server has already been rebuilt, the comparison cannot be made and the endpoints that server administered must be handled as attacker-reachable rather than recorded as clean.",
+        "evidence": "Packet: 'a remote, unauthenticated attacker can submit a forged token containing arbitrary identity claims to obtain a fully authenticated technician session. In some configurations, this may also allow bypass of multi-factor authentication'; 'identity tokens submitted during login are accepted without verifying their cryptographic signature'; CWE-347; active_exploitation confirmed, CISA KEV-listed 2026-06-29; patch_available true, live_patch_available false. Existing inventory entry NEW-CTRL-078 already governs the SimpleHelp server as a privileged distribution channel.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-26633": {
     "name": "Microsoft Windows Management Console (MMC) Improper Neutralization Vulnerability",
@@ -35280,7 +35715,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet turns this SLA into a build check an operator can actually perform: every VeraCore instance released before 2024.4.2.1 carries the upload.aspx path, so the object of the clock is a version string read off each running instance, not an attestation that a patching process exists. Run that clock from the 2025-03-10 KEV listing rather than the 2025-03-31 due date the entry records, because active exploitation is already confirmed — the three-week interval between those dates is precisely the window in which an authenticated user places a file into a folder the packet says is accessible during web browsing by other users, and the file outlives the window. The packet records no live-patch path for this product class, so the vendor update is the only thing that closes the upload path; it records no restart or reboot requirement either, so a deferral justified by needing a downtime window for the fulfilment platform is not supported by anything in this entry. Precondition, and the reason the scope cannot be narrowed to instances someone judges externally exposed: the packet's stated access requirement is a remote authenticated user, so every account that can sign in to an instance already satisfies the exploit precondition. Restricting who can reach the application bounds the population that can send the upload; it removes nothing for anyone already inside that population, and it is not a substitute for reaching 2024.4.2.1. Distinguishing test: produce every VeraCore instance in service with its version string and show each is at or past 2024.4.2.1 — an inventory row reading 'VeraCore: patching current' without a per-instance build is the state this control rejects, because a second instance on an older track keeps upload.aspx reachable while the ticket reads clean.",
+        "evidence": "Packet vector: 'Advantive VeraCore before 2024.4.2.1 allows remote authenticated users to upload files to unintended folders (e.g., ones that are accessible during web browsing by other users). upload.aspx can be used for this.' CISA KEV-listed 2025-03-10 with a 2025-03-31 due date; active_exploitation confirmed; patch_available true; live_patch_available false, with live_patch_notes recording no live-patch path for this product class and the vendor update plus compensating controls as the remediation until it lands — no restart or reboot requirement is recorded. CWE-434; cvss 9.9; rwep_score 44; poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scan that reports VeraCore remediated because the instance now returns 2024.4.2.1 is paper compliance on this entry specifically, because the upgrade closes the upload path and removes nothing that was written through it. The packet records active exploitation as confirmed and describes the primitive as an authenticated user placing a file into a folder accessible during web browsing by other users — a file that landed there before the upgrade is still on disk, still under a path the application serves, and still returned to whatever requests it, after the version string changes. The operational test the scan has to carry is therefore a content test rather than a version test: for each instance, enumerate the contents of the directories VeraCore serves to browsing users and reconcile them against the deployment's own record of what belongs there, covering the whole interval the instance ran a build below 2024.4.2.1 and not merely the days since the 2025-03-10 KEV listing, and flag every file that upload.aspx could have placed and that no operator can account for. Precondition on that reconciliation, which is where this is usually over-claimed: it is conclusive only where a known-good manifest or build-time file list exists for the served directories. Where it does not, the honest output is an unresolved-content finding that puts the instance on a rebuild-from-known-good path — not a clean result, and not a finding that the upgrade closes. Distinguishing test: on a staging instance at 2024.4.2.1, sign in as an ordinary VeraCore user and POST a file through upload.aspx aimed at a folder that browsing users can reach, and confirm it is refused before the write — an attestation that the flaw-remediation ticket closed on the version bump answers a question this exploitation path never asked.",
+        "evidence": "Packet vector: 'Advantive VeraCore before 2024.4.2.1 allows remote authenticated users to upload files to unintended folders (e.g., ones that are accessible during web browsing by other users). upload.aspx can be used for this.' active_exploitation confirmed; CISA KEV-listed 2025-03-10 (due 2025-03-31); patch_available true with 2024.4.2.1 as the fixed release named in the vector; live_patch_available false, live_patch_notes recording no live-patch path for this product class; CWE-434; cvss 9.9; rwep_score 44. Framework gaps cited on this entry are the patch- and vulnerability-management controls (ASD Essential Eight patching, ISO/IEC 27001:2022 A.8.8, NIST SP 800-53 SI-2, NIS2 vulnerability handling, UK CAF B4), none of which asks what the exposure window left behind.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-25181": {
     "name": " Advantive VeraCore SQL Injection Vulnerability",
@@ -36076,7 +36536,21 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_disclosure",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "Power Pages is a vendor-operated service and the packet says the fix already happened inside it: the vulnerability 'has already been mitigated in the service', all affected customers were notified, and those customers were given instructions on reviewing their sites for potential exploitation and cleanup methods. That produces a compliance state none of the cited controls has a box for, and it maps onto this control's state (b) rather than state (a) — a mitigation the operator did not deploy, cannot verify by version or build, and holds no artifact for, while a KEV clock that opened 2025-02-21 with a 2025-03-14 due date names an action the operator cannot perform. Recording the entry as 'patched per SLA' is precisely the failure this control exists to prevent, because the outstanding work is the other half: the flaw let an unauthorized attacker elevate privileges over the network by bypassing the user registration control, and a service-side fix closes that bypass without removing any account, role or site content an attacker obtained through it beforehand. The verdict for this CVE must therefore read as vendor-mitigated-in-service carrying a distinct, time-bound operator action item — work through the vendor's cleanup instructions and review each Power Pages site's registered users and their assigned privileges across the exposure window — and stay open until that review is evidenced rather than closing when the vendor's mitigation is acknowledged. The distinguishing test is documentary: ask for the artifact behind the 'remediated' verdict; a patch record for a service the operator never patched, or a copy of the vendor's mitigation notice, is not evidence that any site was reviewed. Two preconditions, both load-bearing. The packet states that an operator who was not notified is not affected, so the review scope is set by whether the notification was received, and an operator should establish that positively rather than infer exposure from the KEV listing. And the packet records poc_available false alongside confirmed active exploitation, so there is no public exploit for a scanner or detection signature to key on — the review has to run off the vendor's instructions and the site's own registration and privilege records, not off waiting for exploitation evidence to surface on its own.",
+        "evidence": "Packet facts only: cwe_refs CWE-284; vector states an improper access control vulnerability in Power Pages allows an unauthorized attacker to elevate privileges over a network potentially bypassing the user registration control, that 'This vulnerability has already been mitigated in the service and all affected customers have been notified', that the update addressed the registration control bypass, that affected customers were given instructions on reviewing their sites for potential exploitation and clean up methods, and that 'If you've not been notified this vulnerability does not affect you'; cisa_kev true with kev_date 2025-02-21 and the attack_vector recording a 2025-03-14 due date; active_exploitation confirmed; poc_available false; cvss 8.2 with rwep_score 46; patch_available true; live_patch_available false with live_patch_notes recording no live-patch path for this product class.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-0111": {
     "name": "Palo Alto Networks PAN-OS File Read Vulnerability",
@@ -37269,7 +37743,38 @@
         "adequate": false,
         "gap": "Essential Eight patch-OS timelines are typically prioritized by remote exploitability; physical-access LPE bugs used in real device-seizure scenarios need equivalent urgency."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The vulnerable code is uvcvideo's descriptor parsing: uvc_parse_format does not skip frames of type UVC_VS_UNDEFINED, and frames of that type were never counted when uvc_parse_streaming sized the frames buffer, so a crafted UVC device presented to a host drives an out-of-bounds kernel write while the host enumerates it. Bound to this driver, least functionality means splitting the estate by whether uvcvideo has any business function: on servers, virtual machines, appliances and fixed-function hosts that never use a webcam, uvcvideo belongs on a modprobe blacklist so presenting a USB video-class device does not autoload the vulnerable parser, and the loaded-module inventory is what identifies which hosts those are. Precondition, and this is where the control is routinely over-claimed: a blacklist only suppresses autoload. It does nothing on a host where the video class is built into the kernel image rather than built as a module, and nothing on a host where uvcvideo is already loaded — that module has to be unloaded, or the host has to be running the patched kernel, before the blacklist entry means anything. Where uvcvideo cannot be removed because the host genuinely uses a camera, the remaining lever is device authorization: refuse enumeration of USB devices that are not already authorized, so an attacker-presented device never reaches uvc_parse_format. The packet's access condition includes emulated or virtual device presentation, so an argument that the host's physical ports are inaccessible does not by itself remove the path on a virtualized host.",
+        "evidence": "The packet's vector is the upstream fix text: 'media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format', stating that out-of-bounds writes arise because frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. The recorded attack path is an attacker with physical (or emulated/virtual) access presenting a malicious or specially crafted UVC device, with the mis-sized frame buffer causing an out-of-bounds kernel write leveraged for privilege escalation. NIST SP 800-53 CM-7 Least Functionality and UK CAF B4 System security are among the framework controls this entry already cites as insufficient. CWE-787; CISA KEV-listed 2025-02-05 with active_exploitation confirmed; CVSS 7.8, RWEP 51; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "The packet records no public PoC for this flaw, so there is no exploit-tool signature to match and detection has to key on the behaviour the packet actually describes: a UVC device being presented to the host, uvcvideo parsing its format and frame descriptors during enumeration, and an out-of-bounds kernel write leveraged for privilege escalation. The rule is therefore a pairing, not a single event — a kernel device-enumeration event binding uvcvideo to a newly presented USB video-class device, correlated within a short window against a process on that host acquiring root/uid 0 or new capabilities without passing a sanctioned setuid or service-manager path. Take the attach half of the signal from the kernel's own enumeration events rather than from physical-port or badge-style monitoring, because the packet's access condition explicitly includes emulated and virtual device presentation, which produces no physical event to observe. Limits worth stating rather than leaving implied: this is an after-the-fact control — it surfaces the attempt and shortens dwell time, it does not prevent the write — and on hosts that legitimately use cameras the attach event is routine, which is exactly why the alarm must be the attach-plus-privilege-transition pairing and not either half alone. Anti-malware scanning, which is the control this entry cites as insufficient, has no view of either half: nothing is written to disk and no file is scanned.",
+        "evidence": "The packet describes an attacker with physical (or emulated/virtual) access presenting a malicious or specially crafted UVC device, the uvcvideo driver mis-sizing its frame buffer for UVC_VS_UNDEFINED frame types, and an out-of-bounds kernel write (CWE-787) that can be leveraged for privilege escalation. poc_available is false. ISO/IEC 27001:2022 A.8.7 Protection against malware is recorded as one of the framework controls insufficient for this entry. CISA KEV-listed 2025-02-05, active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Two distinct states on this entry are invisible to a version-based scan. First, the packet records a vendor patch with live_patch_available false, so the fixed uvc_parse_format is not in effect on a host until the patched kernel is the kernel actually running — an inventory field showing a patched kernel package installed does not establish that, and the gap between the two is exactly where a fleet reports itself remediated while still running the vulnerable parser. Second, on hosts whose recorded mitigation is the uvcvideo blacklist rather than the patch, no kernel version number describes that state at all, so the scan reports on something other than the thing protecting the host. The scan therefore has to answer both questions: is the running kernel at or past the build carrying this fix, and on every host where the mitigation of record is 'uvcvideo disabled', is uvcvideo genuinely absent when a USB video-class device is attached. Distinguishing test, keyed to the real exploit trigger rather than a stand-in: attach a USB video-class device to a host recorded as mitigated and read the loaded-module list. If uvcvideo binds, the mitigation exists on paper only and the parser is reachable, while a scan that cleared the host from package metadata never looked at the surface that mattered.",
+        "evidence": "patch_available true and live_patch_available false are recorded on this entry, with no live-patch note. The defect is in uvcvideo descriptor parsing (uvc_parse_format / uvc_parse_streaming frame-buffer sizing) reached by presenting a crafted UVC device. ASD Essential Eight 'Patch operating systems' and EU NIS2 Article 21 vulnerability handling are both recorded as framework controls insufficient for this entry. CISA KEV-listed 2025-02-05, active_exploitation confirmed, CVSS 7.8, RWEP 51.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-45195": {
     "name": "Apache OFBiz Forced Browsing Vulnerability",
@@ -38968,7 +39473,40 @@
         "adequate": false,
         "gap": "Apple's fix landed in Safari 18.1.1/iOS/macOS point releases, but the JIT memory-corruption bug was exploited as a zero-day, so patch-cadence controls could not prevent initial compromise."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The fix for this CVE is not one build, it is a list of them: Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, iOS 18.1.1 and iPadOS 18.1.1, macOS Sequoia 15.1.1, visionOS 2.1.1. Bound to this entry the control means every enrolled Apple device is driven onto the build that corresponds to the train it is on, on the clock that opened with the 2024-11-21 KEV listing rather than the estate's normal update ring, with user deferral removed rather than discouraged — the trigger is processing maliciously crafted web content, so a single page load during a deferral window is sufficient and the exposure ends only when the device is actually running the fixed build. Completion has to be measured per device against the fixed build for its own train (17.7.2 on the 17 train, 18.1.1 on the 18 train, 15.1.1 on Sequoia); a fleet report that counts only the newest train, or that counts 'update approved/downloaded' as done, marks devices compliant while they still run the vulnerable code. Enumerate Intel-based Macs first, since that is the only population the packet attaches exploitation to. Precondition: the packet records a vendor patch and no live-patch path, so an update that is pending rather than applied changes nothing and the device must still be counted as exposed. And because the packet places this flaw chained with CVE-2024-44309 in a targeted campaign, a device that already loaded the attacker's content is an incident-response case, not a patch-compliance case — the fixed build removes the flaw, not what already executed.",
+        "evidence": "Packet: CISA KEV-listed 2024-11-21, active_exploitation confirmed, CVSS 8.8, RWEP 59, CWE-787, poc_available false. patch_available true, live_patch_available false, live_patch_notes null. Vector: 'This issue is fixed in Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, iOS 18.1.1 and iPadOS 18.1.1, macOS Sequoia 15.1.1, visionOS 2.1.1. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems.' Attack vector: chained with the CVE-2024-44309 cookie XSS flaw in a targeted campaign.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's fix list names Safari 18.1.1 as its own fixed version alongside macOS Sequoia 15.1.1, so on the Mac side the OS build and the browser version are two separate facts and only one of them is what the exploit path runs through: the packet puts the defect in JavaScriptCore's DFG JIT compiler, reached by loading attacker-controlled web content. Applied to this CVE the control means the Mac estate's update policy can report, per machine, the Safari version actually in service and holds it to the same no-deferral security channel as the OS — a browser update batched into the general software catalogue or held for a weekly ring leaves the vulnerable rendering path live for the length of that ring against a flaw the packet records as already exploited. The distinguishing test is to produce the Safari version per Mac and confirm each is at or above 18.1.1: a compliance view built on macOS build number alone cannot answer that question, because the packet treats Safari as a separately versioned fix, and an estate that reports 'macOS current' while a Mac still runs a pre-18.1.1 Safari reads clean against a flaw-remediation attestation while remaining exploitable. Scope this to Macs — on the iOS, iPadOS and visionOS trains the packet's fixed builds are OS builds, so those devices are closed by the fleet update rather than by a browser channel. Precondition: the packet records no live-patch path, so the fixed version must actually be installed and running; a downloaded update is not a remediated browser. This control reaches only Macs the management console can see and update, and it does nothing for a machine that already rendered the attacker's page.",
+        "evidence": "Packet vector names Safari 18.1.1 as a fixed build distinct from macOS Sequoia 15.1.1, and states 'Processing maliciously crafted web content may lead to arbitrary code execution.' Attack vector: 'A victim on an Intel-based Mac loads attacker-controlled web content that triggers a register-corruption bug in JavaScriptCore's DFG JIT compiler, leading to arbitrary code execution.' patch_available true; live_patch_available false; live_patch_notes null. CISA KEV-listed 2024-11-21, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet's exploitation profile is narrow rather than commodity: no public PoC, RWEP 59 against CVSS 8.8, exploitation reported on Intel-based Mac systems, and the flaw observed chained with the CVE-2024-44309 cookie XSS in a targeted campaign. For the population that profile implicates — executives, journalists, legal and security staff — the control means those users' Apple devices sit in the vendor's reduced-attack-surface mode as a standing posture, so untrusted web content is not processed through the full engine and the delivery path into the JavaScriptCore DFG JIT register-corruption primitive is narrowed during the window between the 2024-11-21 KEV listing and the completed fleet update. The distinguishing test is to take a managed device from that cohort and confirm the mode is enforced by policy and cannot be switched off locally, rather than confirming the mode exists in a policy template — a least-functionality attestation that enumerates installed applications says nothing about which classes of web content a browser will process, which is the surface this CVE is reached through. Preconditions, and this is where the control is usually over-claimed: the mode helps only if it was already enabled when the campaign arrived, so it must be assigned before the next disclosure rather than in response to this one; it does not remove the vulnerable code from the device and is therefore a holding measure for the window before the fixed build, not a substitute for it; and it does nothing for a device that already rendered the attacker's page. Given the packet's chained cookie-XSS flaw, such a device belongs on the incident path with its session and cookie material treated as exposed.",
+        "evidence": "Packet attack_vector: 'A victim on an Intel-based Mac loads attacker-controlled web content that triggers a register-corruption bug in JavaScriptCore's DFG JIT compiler, leading to arbitrary code execution; observed chained with the CVE-2024-44309 cookie XSS flaw in a targeted campaign.' CWE-787; CVSS 8.8; RWEP 59; poc_available false; active_exploitation confirmed; CISA KEV-listed 2024-11-21; patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2024-21287": {
     "name": "Oracle Agile Product Lifecycle Management (PLM) Incorrect Authorization Vulnerability",
@@ -39066,7 +39604,31 @@
         "adequate": false,
         "gap": "Least-privilege enforcement within vCenter's own service architecture failed due to the improper privilege-drop condition, which is a defect in the product itself rather than a misconfiguration operators can fully compensate for."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "vCenter Server is the listener this control governs on this estate, and the packet states the entire exploit precondition as reachability: a malicious actor with network access to vCenter Server triggers the flaw by sending a specially crafted network packet, escalating to root. No account appears anywhere in that path, which is why the least-privilege control cited as insufficient on this entry cannot close it — the attacker holds no vCenter role, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the packet's path stays open. Applied to this deployment, the requirement is that vCenter's network listeners accept connections only from management and jump networks and the hosts vCenter administers, enforced by network ACL or host firewall rather than inferred from 'vCenter is internal'. The distinguishing test: from a general user or workstation VLAN against a staging deployment, attempt to open each vCenter listening port and confirm the connection is dropped before it reaches the service. Scope note, because the packet is specific about what it does and does not establish: it names the product, the crafted network packet, and the observed chain with the CVE-2024-38812 heap overflow that turns this into a full unauthenticated-to-root compromise, but it does not name the protocol this particular packet arrives on — so the restriction is written against vCenter's listeners as a set rather than against one named port. Precondition: restricting reachability bounds who can send the packet, it does not repair the privilege-drop check, so any host already inside a permitted management segment — a compromised administrator workstation or jump host — reaches root exactly as before, and the control is unavailable for the segments that must reach vCenter for normal operation. The packet records a vendor patch and no live-patch path; the update is the fix, and this is what bounds exposure until each instance takes it.",
+        "evidence": "Packet: 'The vCenter Server contains a privilege escalation vulnerability. A malicious actor with network access to vCenter Server may trigger this vulnerability to escalate privileges to root by sending a specially crafted network packet'; attack_vector adds 'abuses an improper privilege-drop check ... observed chained with the CVE-2024-38812 heap overflow for a full unauthenticated-to-root compromise'; CWE-250 and CWE-273; NIST-800-53-AC-6 (Least Privilege) is a citing gap on this entry; patch_available true, live_patch_available false, live_patch_notes null. Existing inventory entry NEW-CTRL-128 already governs vCenter's pre-authentication protocol listeners.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's own signals argue against handling this as a routine 7.5-band item: RWEP 75, a public PoC, confirmed in-the-wild exploitation, and an observed chain with CVE-2024-38812 that converts 'escalate to root' into a full unauthenticated-to-root compromise of the virtualization control plane. For this entry the control means the vendor update is driven across every vCenter Server instance from the 2024-11-20 KEV listing rather than folded into the next quarterly virtualization maintenance window, with completion measured by each appliance's running build against the vendor's fixed build — an update staged on the appliance but not applied leaves the vulnerable code answering the crafted packet, and 'approved' in a change queue is not the same measurement. The packet records a vendor patch and registers no live-patch path, so there is no in-place mitigation: each instance has to be taken through the vendor update, following the vendor's own procedure rather than assuming the service stays available, since the packet carries no live-patch note that would say otherwise. Ordering inside the estate follows the chain the packet names: an instance whose listeners are reachable from segments that also carry the unauthenticated CVE-2024-38812 path is where the escalation completes with no credential at all, so it goes first.",
+        "evidence": "Packet: CISA KEV-listed 2024-11-20, active_exploitation confirmed, poc_available true, RWEP 75 against CVSS 7.5; 'observed chained with the CVE-2024-38812 heap overflow for a full unauthenticated-to-root compromise'; patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-38812": {
     "name": "VMware vCenter Server Heap-Based Buffer Overflow Vulnerability",
@@ -39409,7 +39971,19 @@
         "adequate": false,
         "gap": "Boundary/egress filtering didn't block outbound SMB (445) to external IPs, which is what let the forced-authentication hash-leak succeed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "What makes the update the whole of the remediation here is the trigger the packet documents: the malicious .url shortcut arrives by phishing mail, and right-clicking, deleting, or moving it is enough to force the victim's machine into an SMB authentication handshake with the attacker's server. Nothing the user is normally told to do — don't open it, delete it — avoids the handshake, and no application sandbox is ever entered, so the ordinary holding measures for a mailed file give nothing and this packet contains no compensating control to run a clock against. The control therefore means the Windows update is driven across the estate from the 2024-11-12 KEV listing rather than the next monthly rollup, with completion measured by each host's installed build rather than by 'approved' or 'downloaded' in the management console; the packet records a vendor patch and registers no live-patch path. Priority should not be read off the 6.5 base or the RWEP 51 — the packet records no public PoC, which is what holds that score down, alongside confirmed in-the-wild exploitation and an outcome the packet states plainly: the user's NTLMv2 hash in the attacker's hands for pass-the-hash reuse or offline cracking, which is a credential compromise rather than the information disclosure the CVSS band suggests. Hosts whose users are inside the phishing target set complete first, because the packet's delivery path is mail and the exposure begins at delivery, not at execution. Precondition on the ordering, not on the fix: a user who already received and handled such a file before the update landed has already leaked the hash, and the update does not invalidate what left the host.",
+        "evidence": "Packet: 'A phishing email delivers a malicious .url shortcut file; minimal interaction (even right-clicking, deleting, or moving it) forces the victim's machine to initiate an SMB authentication handshake to an attacker server, leaking the user's NTLMv2 hash for pass-the-hash reuse or offline cracking'; CWE-73; CISA KEV-listed 2024-11-12, active_exploitation confirmed; CVSS 6.5, RWEP 51, poc_available false; patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-41277": {
     "name": "Metabase GeoJSON API Local File Inclusion Vulnerability",
@@ -39688,7 +40262,30 @@
         "adequate": false,
         "gap": "The ISM's patch-timeframe control for extreme-risk vulnerabilities is difficult to meet given fragmented Android OEM patch-distribution timelines."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The defect is in the Android Framework's own filter: shouldHideDocument() in ExternalStorageProvider.java decides which directories a document request may reach, and incorrect Unicode normalization lets a normalized path walk past that decision. There is no provider to disable and no setting that re-closes the filter, so a handset is either on a build carrying the fix or it is exposed. On an Android estate that makes the Android security patch level an access condition rather than a dashboard column: an enrolled handset below the level carrying this Framework fix is denied mail, VPN and document access, instead of being flagged non-compliant while its mail keeps syncing. The install-restriction half of this control carries unusual weight for this CVE, because the packet puts the entire exploitation path behind an application the attacker controls - the crafted path arrives at shouldHideDocument() from a malicious or compromised app already on the device - so restricting installs to a managed catalogue and blocking side-loading removes the most common way that app arrives. Precondition, and it must be stated rather than assumed: install policy does not evict an app already on the handset, and the packet's own wording covers a compromised app, one that arrived legitimately and turned, which no install allowlist would have stopped. A handset suspected of already running such an app belongs on the incident path, with rotation of any credential reachable through the directories the filter was protecting, not on the install-policy path; and the lever is unavailable entirely on an estate that permits personal-profile installs. Distinguishing test: enrol a handset pinned below the fixing security patch level and confirm the access policy actually denies it the protected resources - an estate that surfaces the stale patch level in a report while the device keeps its access has recorded the exposure, not removed it. This is a holding measure for the window before the fixed build reaches the model; the packet registers a vendor patch and no live-patch path, so nothing short of the device taking that build closes the filter.",
+        "evidence": "Packet vector: 'In shouldHideDocument of ExternalStorageProvider.java, there is a possible bypass of a file path filter designed to prevent access to sensitive directories due to incorrect unicode normalization. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.' attack_vector: 'A malicious or compromised app on the device supplies a Unicode-normalized path to ExternalStorageProvider's shouldHideDocument() filter, bypassing the restricted-directory check to reach files it should not be able to access, escalating local privileges with user interaction required.' CWE-176. cisa_kev true, kev_date 2024-11-07, active_exploitation confirmed, CVSS 7.3, RWEP 57, poc_available false, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null - the packet records a vendor fix and no live-patch path, and states no restart or reboot requirement.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "ISO-27001-2022-A.8.9",
+          "NIST-800-53-CM-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this CVE the remediation is the platform build carrying the ExternalStorageProvider fix and nothing else, so the only variables an operator controls are how fast that build lands on each handset and whether the user may decline it. The managed-device policy must drive the update on the clock that opened with the 2024-11-07 KEV listing rather than on the estate's ordinary monthly cadence, with user deferral disallowed, and completion measured per handset by its reported Android security patch level rather than by an 'assigned' or 'downloaded' state in the management console. The urgency does not come from the score: at CVSS 7.3, with no public PoC recorded and user interaction required for exploitation, this reads as a routine local privilege escalation and lands in a normal patch queue, while the packet records KEV listing with confirmed in-the-wild exploitation and RWEP 57. Precondition, and it is the one that breaks this SLA on Android specifically: policy can force only a build the model's OEM or carrier has actually released, so the fleet report has to separate two failure states that a single compliance percentage hides - handsets that could have taken the fixed build and were allowed to defer, which policy enforcement closes, and models for which no fixed build has shipped, which policy cannot close and which fall to the access-condition control above or to a replacement schedule. Distinguishing test: list enrolled handsets by model against reported security patch level and the days elapsed since the fixed level became available for that model; a report showing policy assignment rather than per-model patch level is measuring the console, not the estate.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2024-11-07, active_exploitation confirmed, RWEP 57 against CVSS 7.3, poc_available false, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null. Packet vector states 'User interaction is needed for exploitation' and that the bypass 'could lead to local escalation of privilege with no additional execution privileges needed'; attack_vector names the affected component as ExternalStorageProvider's shouldHideDocument() filter in the Android Framework.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2019-16278": {
     "name": "Nostromo nhttpd Directory Traversal Vulnerability",
@@ -39883,7 +40480,29 @@
         "adequate": false,
         "gap": "Boundary protection assumed the RAVPN authentication path had rate-limiting; resource exhaustion from bulk auth requests bypassed standard perimeter controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The affected device is the remote-access concentrator itself - Cisco ASA and FTD terminating the RAVPN service - so what fails is the trust boundary's availability rather than code execution on it, and that is precisely what routes this CVE into the wrong tier. At CVSS 5.8 it lands in the medium queue most estates service on a 30- or 90-day cycle, while the packet records CISA KEV listing on 2024-10-24, confirmed in-the-wild exploitation, and RWEP 57. Bound to this product, the tier means the Cisco software update is scheduled against the KEV clock and not the next appliance-maintenance window, because an unauthenticated attacker who exhausts RAVPN resources removes remote access for the entire remote workforce and, per the packet, may leave the device requiring a reload before that service returns. Precondition, and it removes the alternative this tier normally offers: the tier permits isolating the vulnerable interface in place of patching to the clock, and that option does not exist here - the RAVPN service exists to accept connections from unauthenticated clients on the public internet, so there is no source restriction that leaves the service usable. Narrowing which addresses may reach it is available only to an estate whose remote users all originate from a fixed set of ranges; for everyone else the clock is the only lever. The packet's note that services unrelated to VPN are unaffected should not be read as bounding the impact either, because for a remote workforce the VPN service is the access path. Distinguishing test: pull the remediation date recorded against this CVE and compare it to 2024-10-24 rather than to the ticket's CVSS-derived due date - a vulnerability-management attestation reporting that the medium-severity SLA was met is the specific way this one is missed.",
+        "evidence": "Packet vector: 'A vulnerability in the Remote Access VPN (RAVPN) service of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) of the RAVPN service... This vulnerability is due to resource exhaustion... Depending on the impact of the attack, a reload of the device may be required to restore the RAVPN service. Services that are not related to VPN are not affected.' CWE-772. cisa_kev true, kev_date 2024-10-24, active_exploitation confirmed, CVSS 5.8, RWEP 57, poc_available false, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The device that would record this attack is the device the attack exhausts, and the packet says restoring the RAVPN service may require reloading it - so the record of what happened is held on the one component least likely to survive the event. For ASA and FTD units terminating RAVPN this control means syslog and VPN authentication logs are forwarded to a collector outside the appliance, on a separate management plane with its own credentials, before the exposure rather than after it. The rationale differs from the compromise case the control usually covers: nothing here says an attacker gains control of the appliance, so the load-bearing property is simply that the record survives the reload; keep the separate trust zone anyway, because the same collector is what makes the compromise case answerable. The alerting must key on the behaviour the packet documents and not on the outcome: a rising rate of VPN authentication requests to the RAVPN service from unauthenticated sources, correlated with the RAVPN service's own resource consumption - the packet ties this CVE to the Cisco Talos reporting on large-scale brute-force activity against VPN and SSH services, which is the same high-volume authentication signal. A rule that fires on the device becoming unreachable, or on a service restart, detects the end state after remote access is already gone. Precondition: this control does not prevent the exhaustion and does not shorten it - it is detection and post-event reconstruction only, and it holds only while the appliance can still export logs. Because resource exhaustion can degrade that export, the collector's loss of signal from an ASA or FTD unit has to be an alerting condition in its own right rather than a silent gap in the timeline. Distinguishing test: on a staging appliance, generate a sustained burst of RAVPN authentication requests, then reload the device and confirm the off-box collector still holds the request-rate record for the period before the reload.",
+        "evidence": "Packet attack_vector: 'An unauthenticated remote attacker sends a large number of VPN authentication requests to the RAVPN service, exhausting device resources and causing a denial of service that may require a device reload to fully restore.' Packet vector adds: 'An attacker could exploit this vulnerability by sending a large number of VPN authentication requests to an affected device... Depending on the impact of the attack, a reload of the device may be required to restore the RAVPN service' and 'Cisco Talos discussed these attacks in the blog post Large-scale brute-force activity targeting VPNs, SSH services with commonly used login credentials.' CWE-772; cisa_kev true, kev_date 2024-10-24; active_exploitation confirmed; CVSS 5.8; RWEP 57; poc_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-4",
+          "UK-CAF-D1"
+        ]
+      }
+    ]
   },
   "CVE-2024-47575": {
     "name": "Fortinet FortiManager Missing Authentication Vulnerability",
@@ -40363,7 +40982,32 @@
         "adequate": false,
         "gap": "Patch Applications extreme-risk timelines (48 hours) are routinely missed for appliance firmware requiring scheduled maintenance windows."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "This is the tier's core case: an unauthenticated attacker reaching a perimeter device's management daemon and executing code on it. Bound to this packet, the affected estate is FortiOS, FortiProxy, FortiPAM and FortiSwitchManager within the version ranges the packet lists - four separate products, so an inventory keyed only on FortiGate firewalls will report clean while FortiProxy, FortiPAM or FortiSwitchManager units stay exposed. The vendor fixed release must be scheduled against the 2024-10-09 KEV listing, not the appliance-maintenance window, and completion measured per unit by its running version against the fixed release rather than by the change ticket being approved. Unlike most entries in this tier, the isolation alternative is genuinely available here and should run in parallel with the upgrade rather than instead of it: the packet places the attack on the FGFM FortiGate-to-FortiManager management service on TCP/541, whose only legitimate peer is the FortiManager that manages the unit, so restricting which sources may reach TCP/541 - or closing the service on units that are not centrally managed at all - bounds who can deliver the crafted packets during the window before the upgrade lands. Precondition: that restriction holds only where the legitimate peer set is actually enumerable and enforceable at the network edge. A unit whose FortiManager reaches it across untrusted transit still exposes fgfmd to anything that can route to it along that path, and the restriction does nothing for a unit that was already exploited - it bounds future delivery, it does not remove the surface. Distinguishing test: from an address outside the FortiManager peer set, attempt to open TCP/541 on each unit in the affected products and confirm it is refused; a patch-management attestation that records the fixed release as scheduled says nothing about which units are still answering the FGFM port in the meantime.",
+        "evidence": "Packet vector: 'A use of externally-controlled format string in Fortinet FortiOS versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.6, 7.0.0 through 7.0.13, FortiProxy versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.8, 7.0.0 through 7.0.14, FortiPAM versions 1.2.0, 1.1.0 through 1.1.2, 1.0.0 through 1.0.3, FortiSwitchManager versions 7.2.0 through 7.2.3, 7.0.0 through 7.0.3 allows attacker to execute unauthorized code or commands via specially crafted packets.' attack_vector: 'An unauthenticated attacker sends crafted packets to the FGFM (FortiGate-to-FortiManager) management service on TCP/541 that contain externally-controlled format-string specifiers, corrupting memory in the fgfmd daemon to achieve remote code execution or crash the service.' CWE-134. cisa_kev true, kev_date 2024-10-09, active_exploitation confirmed, CVSS 9.8, RWEP 83, poc_available true, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives an unauthenticated attacker code execution in the fgfmd daemon on the appliance, a public PoC, and confirmed in-the-wild exploitation from the 2024-10-09 KEV listing - which means that for any FortiOS, FortiProxy, FortiPAM or FortiSwitchManager unit that was answering TCP/541 to untrusted sources during that window, installing the fixed release answers the wrong question. The upgrade replaces the vulnerable binary; it does not establish that nothing was left behind by an attacker who already ran code on the unit. For this CVE the IR default is therefore configuration extraction, rebuild from a known-good image, and rotation of the secrets the unit held - administrative accounts and any credentials or keys it stored for authenticating users or upstream services - because code execution on the appliance places all of them in reach. Precondition, and it decides which units this applies to: rebuild-not-patch is scoped to units whose FGFM service was reachable from an untrusted source during the exposure window, and the running firmware version cannot tell you which those were. The reachability evidence has to come from records the appliance is not the sole holder of - edge ACL and flow data, management-network topology, or an off-box log collector - and where no such record exists for the window, the unit is treated as in scope rather than assumed clean. A unit whose TCP/541 was demonstrably never reachable from an untrusted source is a patch-in-place case. Distinguishing test: for each affected unit, produce the evidence that answers whether TCP/541 was reachable from outside the FortiManager peer set between the KEV listing and the upgrade; a flaw-remediation record showing the fixed release installed, with no answer to that question, has closed the ticket without deciding whether the device is trustworthy.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends crafted packets to the FGFM (FortiGate-to-FortiManager) management service on TCP/541 that contain externally-controlled format-string specifiers, corrupting memory in the fgfmd daemon to achieve remote code execution or crash the service.' Packet vector names the affected products as Fortinet FortiOS, FortiProxy, FortiPAM and FortiSwitchManager and states the flaw 'allows attacker to execute unauthorized code or commands via specially crafted packets'. CWE-134; cisa_kev true with kev_date 2024-10-09; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 83; patch_available true; live_patch_available false; live_patch_notes null.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-43573": {
     "name": "Microsoft Windows MSHTML Platform Spoofing Vulnerability",
@@ -40442,7 +41086,30 @@
         "adequate": false,
         "gap": "Least-functionality/least-privilege baselines rarely block execution of attacker-supplied .msc files by default prior to this patch — MMC did not treat untrusted console files as high-risk content."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The execution path the packet records runs at the opening user's own privilege inside mmc.exe — a crafted .msc console file references the apds.dll ActiveX control through the file's StringTable section and runs attacker JScript when the victim opens it — so the population to drive the Windows update across is the general workstation estate where users open files, not a server tier, and the estate's own inventory of who opens files is the enumeration that matters. Run that update on the clock that opened with the 2024-10-08 KEV listing rather than folding it into the next monthly rollup, and measure completion by each host's installed build rather than by 'approved' or 'downloaded' in the management console. The packet registers a vendor patch, live_patch_available false, and no live-patch note at all, so there is no vendor-mitigation state to fall back into and no rule to deploy while the rollout runs: every host either takes the update or is exposed, and the only other lever is the delivery-path control recorded alongside this one, which is the 'documented compensating controls' branch this SLA allows and must be recorded with a dated end rather than as a patched outcome. Priority follows the packet rather than the 7.8 base — a public PoC, confirmed in-the-wild exploitation and RWEP 81 put this above other 7.8-band Windows items in the same cycle, because the vulnerability-management and flaw-remediation controls cited as insufficient here are the ones that set the cadence, and a monthly-rollup cadence is exactly what leaves a KEV-listed, publicly-exploited file-open RCE reachable for weeks after the fix ships.",
+        "evidence": "Packet entry 'Microsoft Windows Management Console Remote Code Execution Vulnerability' (CWE-707): cisa_kev true with kev_date 2024-10-08, active_exploitation 'confirmed', cvss 7.8, rwep_score 81, poc_available true, patch_available true, live_patch_available false, live_patch_notes null. Attack vector as recorded: \"An attacker crafts a malicious .msc console file referencing a vulnerable ActiveX control (apds.dll) via the file's StringTable section, smuggling in an old XSS flaw that executes arbitrary JScript inside mmc.exe when the victim opens the file — the 'GrimResource' technique.\" Framework gaps citing this CVE include NIST-800-53-SI-2 (Flaw Remediation), ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) and EU NIS2 Art. 21 vulnerability handling.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation here requires the victim to open an attacker-crafted .msc console file, so on an estate that has not yet taken the update the delivery path is the only enforceable lever. Require the untrusted-origin marking on every file arriving by mail, web download or untrusted file share, and require it to survive the container: a .msc extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the marking rather than lose it, because a provenance-stripped copy reaches mmc.exe indistinguishable from a console an administrator authored locally. Pair the marking with an ingress rule that quarantines .msc content at the mail and web boundary — a saved console file is not a document type a user has an ordinary reason to receive from outside the organization, which makes this one of the few cases where restricting the file type outright costs the business nothing. Distinguishing test: deliver a .msc nested inside a ZIP through each ingress path to a managed workstation, extract it, and confirm the extracted file still carries the untrusted-origin marking and is refused by policy — a user-application-hardening attestation that enumerates Office macro and ActiveX settings passes cleanly while a provenance-stripped console file opens straight into the apds.dll path with the user's own privileges, and a least-functionality attestation that never names .msc as a restricted type passes with it. Precondition: the marking produces a warning the user can accept, not a block, so it raises the bar on casual delivery rather than removing the path; it gives nothing for a copy already resident on disk, nothing for one delivered before enforcement was turned on, and nothing for a host where the file has already been opened — that host is an incident-response case, not an ingress-policy case. This is a holding measure for the window before the vendor update reaches the workstation, not a substitute for it.",
+        "evidence": "Packet attack vector: the .msc file executes arbitrary JScript inside mmc.exe \"when the victim opens the file\", establishing victim-opened delivery as the exploitation precondition; poc_available true and active_exploitation 'confirmed' with kev_date 2024-10-08; patch_available true with live_patch_available false, so the pre-update window is real. Framework gaps citing this CVE include ASD Essential Eight 'User application hardening' and NIST SP 800-53 CM-7 (Least Functionality).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2024-43047": {
     "name": "Qualcomm Multiple Chipsets Use-After-Free Vulnerability",
@@ -40553,7 +41220,39 @@
         "adequate": false,
         "gap": "Ivanti's fix shipped in May 2024 but active exploitation was still being observed and added to KEV in October 2024 — a five-month unpatched-fleet exposure window well beyond a reasonable SLA."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "The injection sink the packet names sits inside a shipped Ivanti binary — SQL injection in RecordGoodApp (PatchBiz.dll) on the Ivanti Endpoint Manager Core server, reached by a crafted goodApp.md5 value sent to /WSStatusEvents/EventHandler — so the parameterization this control requires is a property of the vendor's query construction, not of anything the operator writes. That makes the operator-side expression a verification duty: require the fixed Ivanti release on any Core server running EPM 2022 SU5 or prior, and prove the injection path is closed by exercising it rather than by reading a version. Distinguishing test, taken straight from the packet's own path: on a staging Core server, send a goodApp.md5 value carrying a SQL metacharacter to /WSStatusEvents/EventHandler and confirm it is parameterized rather than concatenated into a query. The control's second premise is the load-bearing one here — the packet's attacker is unauthenticated and on the same network, so a perimeter WAF and an assumption that the Core server is internal never see the request, leaving the query layer as the only place the input is neutralized. Precondition: this control states the property to verify, it does not implement it; the repair is the vendor's. The packet records no live-patch path, so each Core server has to be taken through the vendor update, and until that update lands the only operator-side lever is restricting which network segments can reach /WSStatusEvents/EventHandler — which bounds who can send the request but leaves the endpoint fully exploitable to anything inside a permitted segment, and is unavailable where managed endpoints must keep reaching that service for normal operation.",
+        "evidence": "Packet vector: 'An unspecified SQL Injection vulnerability in Core server of Ivanti EPM 2022 SU5 and prior allows an unauthenticated attacker within the same network to execute arbitrary code.' Packet attack_vector: 'An unauthenticated attacker on the same network sends a crafted goodApp.md5 value to the EPM Core server's /WSStatusEvents/EventHandler endpoint, exploiting SQL injection in RecordGoodApp (PatchBiz.dll) to reach xp_cmdshell and execute arbitrary commands.' CWE-89; cisa_kev true, kev_date 2024-10-02, active_exploitation confirmed; poc_available true; CVSS 8.8, RWEP 70; patch_available true; live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-060",
+        "name": "DATABASE-SERVER-SIDE-SCRIPTING-DEFAULT-DENY",
+        "description": "The packet's chain does not stop at data access: the injection in RecordGoodApp reaches xp_cmdshell and from there executes arbitrary commands on the EPM Core server. That final step is a database-engine feature that runs operating-system commands, and it is what converts an injection into the arbitrary code execution the packet's vector describes. Bound to this deployment, the control means the database instance behind the Ivanti EPM Core server carries no enabled OS-command path, and the login the Core server authenticates with cannot invoke one — with any enabled state carrying a documented, dated threat-model acceptance that names the function requiring it, rather than being inherited from an installation choice or a troubleshooting session nobody reverted. Distinguishing test: on a staging Core server, attempt an operating-system command through the database engine using the login the EPM Core server itself uses, and confirm it is refused — an application patch-level attestation says nothing about whether that path is open. Precondition, and it decides whether the control is available at all: denying the command path does not repair the injection. An unauthenticated attacker on the same network still reaches the vulnerable query through /WSStatusEvents/EventHandler and still reads and writes the EPM database, and the packet gives no basis for treating that as harmless. If the Ivanti deployment genuinely requires the privilege for a product function, this lever is unavailable and the vendor update is the only closure — establish which of those two states each Core server is in rather than assuming a default.",
+        "evidence": "Packet attack_vector: the crafted goodApp.md5 value sent to '/WSStatusEvents/EventHandler' exploits 'SQL injection in RecordGoodApp (PatchBiz.dll) to reach xp_cmdshell and execute arbitrary commands.' Packet vector: the flaw 'allows an unauthenticated attacker within the same network to execute arbitrary code' against 'Core server of Ivanti EPM 2022 SU5 and prior.' CWE-89; CVSS 8.8, RWEP 70; poc_available true; patch_available true; live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet's end state is arbitrary command execution on the Core server of Ivanti Endpoint Manager — the management server of an endpoint-management product — so the exposure is the estate of endpoints that server administers, not the one host, and the response has to be scoped that way. The window matters here more than on most entries: KEV listing is 2024-10-02, active_exploitation is confirmed, and poc_available is true, so a working exploit was in circulation across whatever interval separated the listing from each operator's update. Applied to this product, the playbook covers what the Core server distributed or instructed to managed endpoints during that window, a defined quarantine criterion for endpoints that acted on those instructions, and rotation of credentials that were used or authenticated through the Core server while it was exposed. Precondition: this is response, not prevention. It stops no injection, and it applies specifically to Core servers that were reachable by an unauthenticated party on the same network during the exposure window — which, given the packet places the attacker on the same network rather than across the perimeter, includes instances an operator considers internal-only. Applying the vendor update to a Core server that already executed attacker commands neither removes what was left behind nor re-validates what it pushed downstream, and closing the finding on the patch is exactly the failure this control exists to prevent.",
+        "evidence": "Packet: CWE-89 SQL injection in 'Core server of Ivanti EPM 2022 SU5 and prior' allowing 'an unauthenticated attacker within the same network to execute arbitrary code'; attack_vector ends in 'xp_cmdshell and execute arbitrary commands.' cisa_kev true, kev_date 2024-10-02; active_exploitation confirmed; poc_available true; CVSS 8.8, RWEP 70; patch_available true; live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-25280": {
     "name": "D-Link DIR-820 Router OS Command Injection Vulnerability",
@@ -40928,7 +41627,31 @@
         "adequate": false,
         "gap": "Network-security measures for essential entities seldom treat the building-automation/OT bus as in-scope, leaving the KNX segment flat and reachable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-118",
+        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
+        "description": "The packet states this exploit's access requirement outright: a device configured to interface with a network can be reached by an attacker with access to that network, who then interfaces with the KNX installation, purges devices without additional security options enabled, and sets a BCU key. So the segmentation half of this control is the load-bearing half here — the KNX installation's network interface must answer only from a segmented building-automation management plane holding the commissioning workstations and servers with an operational need to program the bus, not from a general office VLAN, a tenant or guest network, or any routable path from outside. The credential half is not a vendor default the operator can rotate away: the BCU key is the device's own password mechanism, and because the packet records that it often cannot be reset without entering the current key, it behaves as a first-mover control — a reachable device with no BCU key set is an unlocked device, and whoever sets one first holds it. Where the implementation supports the additional security options the packet names, enable them and set the BCU key under operator control, then escrow that key, because the same irreversibility that blocks the attacker locks the operator out of every device whose key is lost. Distinguishing test: from a segment with no commissioning role, attempt to reach the KNX installation's network interface; anything that answers is within reach of the path the packet describes, and 'the bus is on the internal network' is an assertion about topology rather than a demonstration that the interface is unreachable from untrusted segments. Preconditions: segmentation bounds who can reach the bus over the network and repairs nothing about the reset defect, and the packet is explicit that it does not close the surface — an attacker with physical access to a device exploits it the same way with no network involved at all, so device enclosure and cabinet access control belong inside this control rather than beside it. Neither half restores a device an attacker has already locked; that device falls to the vendor path the packet records, and a site that was reachable during the exposure window should be inventoried for devices that no longer accept the operator's key.",
+        "evidence": "Packet entry 'KNX Association KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout Mechanism Vulnerability' (CWE-645), vector as recorded: \"If the device is configured to interface with a network, an attacker with access to that network could interface with the KNX installation, purge all devices without additional security options enabled, and set a BCU key, locking the device. Even if a device is not connected to a network, an attacker with physical access to the device could also exploit this vulnerability in the same way.\" Also recorded: \"The BCU key feature on the devices can be used to create a password for the device, but this password can often not be reset without entering the current password\", and the implementation-dependent qualifier \"depending on the implementation\". active_exploitation 'confirmed'; cisa_kev true, kev_date 2026-07-15. Framework gaps citing this CVE include NIST SP 800-53 SC-7 (Boundary Protection), EU NIS2 Art. 21 security of network and information systems, and UK CAF B4 (System security).",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "A 2023 CVE that entered the KEV catalogue on 2026-07-15 with confirmed exploitation is the case this SLA exists for: an entry closed years earlier as a low-impact building-automation issue has to be reopened on the KEV clock, and the affected population — KNX devices that use Connection Authorization and support Option 1, which the packet qualifies as implementation-dependent — is one that normally lives in a facilities asset register rather than in the vulnerability-management system that runs the clock, so the first action this control forces is producing that list at all. The packet records a vendor update, no live-patch primitive, and a remediation that requires a reboot, so closing this means taking each affected device through the update and its restart; on a building's lighting, HVAC or access-control bus that is a maintenance window rather than a four-hour push, which is exactly why this control's third branch is the operative one here — until the update lands, the documented compensating state is the reachability restriction recorded alongside it, logged as an active mitigation with a dated end rather than reported as 'patched per SLA'. Distinguishing test is inventory-side rather than scan-side: produce the list of Option 1 KNX devices in service and show a firmware level and a dated remediation decision for each. An operating-system patch attestation and a technical-vulnerability-management attestation both pass cleanly over this estate, because no operating-system agent reports a KNX device and nothing in the scanner's coverage will ever raise it.",
+        "evidence": "Packet: cisa_kev true with kev_date 2026-07-15 against CVE-2023-4346, active_exploitation 'confirmed', cvss 7.5, rwep_score 47, poc_available false, patch_available true, 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.\" Affected population per the vector: \"KNX devices that use KNX Connection Authorization and support Option 1 are, depending on the implementation, vulnerable\". Framework gaps citing this CVE 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",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-56155": {
     "name": "Microsoft Active Directory Federation Services Insufficient Granularity of Access Control Vulnerability",
@@ -40965,7 +41688,38 @@
         "adequate": false,
         "gap": "Federated-identity management guidance assumes the token-signing key material is protected; it does not detect the insufficiently-granular ACL that exposes the AD FS DKM key to lateral privilege elevation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in Active Directory Federation Services and describes an authorized attacker elevating privileges locally: a low-privileged local principal abuses an over-permissive DKM container ACL to reach the federation master key or elevate to administrator. The account is already legitimate, so no account model is being abused — an access-control boundary inside AD FS is failing, which is precisely why the least-privilege gap and the identity-and-access-control gap recorded on this entry can pass their attestations while the flaw stays fully exploitable, and why tightening account privilege does not contain the escalation. For this CVE the control means driving the Windows update across every AD FS server in the estate on the clock that opened with the 2026-07-14 KEV listing rather than folding it into the next monthly rollup, with completion measured by each server's installed build rather than by an approval or download state in the management console. The packet records a vendor patch, no live-patch path, and an update whose remediation requires a reboot, so a server that has taken the update but not restarted still carries the vulnerable code and must be counted as exposed — and on a federation farm that restart is the step most likely to be deferred, because taking a node out interrupts every authentication depending on it. A deferral recorded as 'patched' is the specific way this remediation goes wrong here: drain and restart nodes in rotation and hold the farm open on the exposure report until the last one is back, rather than closing the ticket when the update is approved. Priority follows the packet rather than the 7.8 base — confirmed in-the-wild exploitation on the component that signs the estate's federated tokens, with the packet recording the chain from the stolen key into token-signing forgery and ransomware-style intrusion, makes this a containment step for an intrusion chain rather than a standalone endpoint item.",
+        "evidence": "Packet entry 'Microsoft Active Directory Federation Services Insufficient Granularity of Access Control Vulnerability' (CWE-1220). Vector as recorded: \"Insufficient granularity of access control in Active Directory Federation Services (AD FS) allows an authorized attacker to elevate privileges locally.\" Attack vector as recorded: \"A low-privileged local principal abuses an over-permissive DKM container ACL in AD FS to access the federation master key or elevate to administrator, enabling token-signing forgery that can be chained with an RCE in ransomware-style intrusions.\" cisa_kev true with kev_date 2026-07-14, active_exploitation 'confirmed', cvss 7.8, rwep_score 57, poc_available false, patch_available true, 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.\" Framework gaps citing this CVE include ASD Essential Eight 'Patch operating systems' and EU NIS2 Art. 21 vulnerability handling.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "AD FS is an identity provider — the class this control names explicitly — and the packet's precondition is a low-privileged local principal on that system, so the tier question here is not who holds domain administrator but who holds any local presence on a federation server at all. Applied to this deployment: AD FS servers are administered only from a privileged access workstation through a jumphost, under an identity separate from every other admin role, with just-in-time elevation and step-up authentication, and every other principal that can obtain a logon on the box is enumerated and either removed or justified in writing. The accounts that matter are the unglamorous ones — backup and monitoring agents, helpdesk groups, and service accounts inherited from a general-purpose server build — because each of them quietly satisfies the packet's 'low-privileged local principal' on a host holding the federation master key, and none of them appears in an attestation that lists AD FS administrators. Distinguishing test: enumerate every principal that can obtain an interactive or service logon on each AD FS server together with every principal holding read access to the DKM container, and show each one inside the federation tier; a least-privilege attestation showing a short list of named AD FS administrators passes cleanly while a general-purpose server build grants a dozen non-federation principals local presence on the same host. Precondition: this bounds the population that can reach the over-permissive ACL and repairs nothing about the ACL itself — the vendor update does that, and any principal legitimately inside the tier still reaches the flaw. It also evicts no one already resident: with active exploitation confirmed on this entry, a federation server that carried extra local principals during the exposure window belongs on the incident path, not the hardening path.",
+        "evidence": "Packet attack vector: \"A low-privileged local principal abuses an over-permissive DKM container ACL in AD FS to access the federation master key or elevate to administrator\" — the exploitation precondition is local presence by a principal that need not be privileged. vector: \"allows an authorized attacker to elevate privileges locally\". active_exploitation 'confirmed', cisa_kev true, kev_date 2026-07-14. Framework gaps citing this CVE include NIST SP 800-53 AC-6 (Least Privilege) and UK NCSC CAF B2 (Identity and access control), both recorded as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The asset the packet names is the federation master key, and the end state it names is token-signing forgery — material the vendor update does not invalidate, because a key read before the patch stays valid after it. The playbook for this CVE is therefore keyed to the key rather than to the host: rotate the AD FS token-signing material and drive every relying party onto the new signing key, invalidate issued sessions and refresh tokens across the federated applications, and rotate credentials for any account whose access was obtained through federated sign-in during the exposure window. The review that goes with it is the one this attack actually permits: compare assertions accepted at the relying parties against authentication events recorded on the federation servers for the window preceding the 2026-07-14 KEV listing, and treat a cryptographically valid assertion with no matching federation-server authentication event as the finding — a token forged with the stolen signing key never transits the sign-in path, so it produces no failed authentication, no anomalous logon at the identity provider, and nothing for a rule keyed on brute-force or credential-stuffing patterns to fire on. Trigger and precondition: run this on any AD FS server where a non-federation local principal existed during the exposure window, not only where an alert fired, because waiting for detection evidence before rotating is waiting for a signal this path does not emit by construction. The rotation is also not free — every relying party must consume the new signing key, so the playbook has to name the relying-party inventory and the re-consumption step in advance rather than discovering it mid-incident. This control governs what is done after the key may have been read; the vendor update the packet records is what closes the read path itself.",
+        "evidence": "Packet attack vector: the low-privileged local principal reaches \"the federation master key\", \"enabling token-signing forgery that can be chained with an RCE in ransomware-style intrusions\". active_exploitation 'confirmed'; cisa_kev true with kev_date 2026-07-14; patch_available true, 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\" — the packet records the update as remediation of the flaw, not as invalidation of material already read. Framework gap citing this CVE: ISO/IEC 27001:2022 'Identity Management + Authentication Information — federated-state extension'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.5.16-Federated"
+        ]
+      }
+    ]
   },
   "CVE-2026-56164": {
     "name": "Microsoft SharePoint Server Missing Authentication for Critical Function Vulnerability",
@@ -41330,7 +42084,32 @@
         "adequate": false,
         "gap": "SI-2 flaw remediation has no patch path for an EoL plugin; only removal mitigates, which SI-2 alone does not compel."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet names four separately-versioned products carrying this double free, not one: Adobe Flash Player, Adobe AIR on Android, the Adobe AIR SDK, and the Adobe AIR SDK & Compiler — and inside Flash Player the fixed build differs by operating system (11.7.700.269 and, for the 11.8.x through 12.0.x line, 12.0.0.70 on Windows and Mac OS X; 11.2.202.341 on Linux), while the three AIR products are fixed at 4.0.0.1628. Each is its own update track, so 'Flash is patched' is not a statement this estate can make from one inventory line: a Linux install at 11.2.202.341 is remediated and a Windows install below 11.7.700.269 is not, and a single software-inventory row reading 'Adobe Flash Player' cannot tell those apart. The control here is to enumerate every installed copy across the four tracks and every operating system the packet names, and confirm each reports at or above the fixed build for its own track, rather than closing the flaw-remediation ticket when the managed desktop image updates. The AIR SDK and AIR SDK & Compiler are the copies estates miss, because an SDK lives where development happens rather than on the desktop software inventory that drives endpoint patching, and the packet lists them as affected in their own right with their own fixed build — they need remediating whether or not the endpoint estate has been cleared. Scope the inventory to those products and no further: the packet ties this double free to Flash Player, Adobe AIR, the AIR SDK and the AIR SDK & Compiler, and gives no mapping from the vulnerable code into any other SWF-handling or media-parsing software, so instructing operators to treat every plugin or media renderer in the estate as an instance of this CVE manufactures findings and real removal work against software no evidence here implicates. Widen only where a verified source identifies another product carrying the same component. Distinguishing test: after the update lands, enumerate the Flash Player, AIR runtime and AIR SDK installs per platform and confirm none reports a build below the fixed one for its track — an estate that updates the browser-side plugin while a build machine keeps a pre-4.0.0.1628 AIR SDK still holds vulnerable code with a flaw-remediation attestation that reads clean. Precondition: this reaches only copies the inventory can see and the operator can update; a hand-installed or per-user copy is remediated by removing it, not by recording it as covered. Per the packet the vendor update needs no reboot, so an unremediated copy here is an inventory failure rather than a scheduling one. Terminal state, and this is what the version comparison above must not be mistaken for: Adobe Flash Player is end-of-life and receives no further fixes, so a copy sitting at the fixed build named here is current for this CVE and unpatched for every Flash defect found since. Reaching the fixed build is an interim state for a copy that cannot be removed today, not remediation. The requirement completes at removal of the Flash Player runtime and browser plugin, or replacement of whatever still depends on them; an estate that reports every install at or above the 2014 build and closes the finding has recorded parity with an abandoned product rather than removed the exposure. Where a business function still needs it, the honest record is an accepted exposure with a dated review and the runtime confined to hosts that reach nothing else — not a remediation entry. The AIR products named here are a separate case and must not inherit that conclusion: Adobe AIR was transferred to HARMAN and continues to be maintained, so for the AIR runtime and the AIR SDKs the terminal state is a supported, current build — patch parity is remediation there, and removing them is a decision about whether the dependency is still wanted, not a security requirement this CVE establishes.",
+        "evidence": "The packet's vector enumerates the affected products and their fixed builds: Adobe Flash Player before 11.7.700.269 and 11.8.x through 12.0.x before 12.0.0.70 on Windows and Mac OS X and before 11.2.202.341 on Linux, Adobe AIR before 4.0.0.1628 on Android, Adobe AIR SDK before 4.0.0.1628, and Adobe AIR SDK & Compiler before 4.0.0.1628, allowing remote attackers to execute arbitrary code, 'as exploited in the wild in February 2014'. CWE-415, CISA KEV-listed 2024-09-17, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 73. patch_available is true and live_patch_available is false; the packet's live-patch note states there is no live-patching primitive for this product and that the vendor update (no reboot required) is the remediation.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry reads unusually and an estate that treats the KEV listing as 'newly disclosed' will misprioritise it: the packet records the flaw as exploited in the wild in February 2014 and the KEV listing as 2024-09-17, so the listing is not the start of exploitation — it is notice that installs below the fixed builds are still being hit a decade after those builds shipped, which makes this an inventory-age problem being surfaced by a KEV date rather than a fresh disclosure. The SLA applies from the listing regardless: every Flash Player, Adobe AIR, AIR SDK and AIR SDK & Compiler copy the estate still runs must reach the fixed build for its own track inside the KEV window, or carry a documented, dated compensating control where a specific copy cannot get there in that window. Per the packet the vendor update requires no reboot, so there is no maintenance-window basis for deferral — the delay in practice is finding the copies, not scheduling a restart, which is why this clock is only meaningful when it runs against an enumeration spanning all four product tracks rather than a single desktop-software line item. Precondition: the SLA governs the clock, not the exploit path. It does nothing for the delivery half, because the packet's path is a crafted SWF served from a compromised or attacker-controlled page — the victim visits a site, with no download prompt or file to inspect — so between the listing and the completed update, exposure stands on any host that still has a vulnerable copy able to render page-supplied SWF content, and no policy setting in this packet closes it. And because active exploitation is confirmed, a host that rendered attacker-controlled content during that window is an incident-triage question the update does not answer: applying the fixed build removes the double free, not code that already executed in the plugin process. Terminal state, and this is what the version comparison above must not be mistaken for: Adobe Flash Player is end-of-life and receives no further fixes, so a copy sitting at the fixed build named here is current for this CVE and unpatched for every Flash defect found since. Reaching the fixed build is an interim state for a copy that cannot be removed today, not remediation. The requirement completes at removal of the Flash Player runtime and browser plugin, or replacement of whatever still depends on them; an estate that reports every install at or above the 2014 build and closes the finding has recorded parity with an abandoned product rather than removed the exposure. Where a business function still needs it, the honest record is an accepted exposure with a dated review and the runtime confined to hosts that reach nothing else — not a remediation entry. The AIR products named here are a separate case and must not inherit that conclusion: Adobe AIR was transferred to HARMAN and continues to be maintained, so for the AIR runtime and the AIR SDKs the terminal state is a supported, current build — patch parity is remediation there, and removing them is a decision about whether the dependency is still wanted, not a security requirement this CVE establishes.",
+        "evidence": "CISA KEV-listed 2024-09-17 with active_exploitation confirmed and poc_available true, while the packet's own vector records the flaw 'as exploited in the wild in February 2014' and names the fixed builds (Flash Player 11.7.700.269 and 12.0.0.70 on Windows and Mac OS X, 11.2.202.341 on Linux; Adobe AIR, AIR SDK and AIR SDK & Compiler 4.0.0.1628). patch_available is true, live_patch_available is false, and the live-patch note states the vendor update (no reboot required) is the remediation. The recorded attack vector is a crafted SWF served from a compromised or attacker-controlled page triggering a double free in the Flash plugin, corrupting memory and allowing arbitrary code execution in the browser plugin process. RWEP 73, CVSS 8.8.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2013-0648": {
     "name": "Adobe Flash Player Code Execution Vulnerability",
@@ -41441,7 +42220,29 @@
         "adequate": false,
         "gap": "Least-functionality controls that still permit the Flash Player browser plugin leave a memory-corruption RCE surface exposed; the plugin should have been disabled/removed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this entry the fixed builds do not sort into one threshold, so a scan that compares a single version string is paper compliance regardless of how many hosts it covers. The packet gives 11.7.700.261 for the 11.7 branch, 12.0.0.44 for the 11.8.x-through-12.0.x range on Windows and Mac OS X, and 11.2.202.336 on Linux. A scanner set to 12.0.0.44 marks a correctly remediated 11.7.700.261 host and every correctly remediated Linux host at 11.2.202.336 as vulnerable, generating remediation work against systems already fixed; a scanner set to 11.7.700.261 passes every build in the 11.8.x-through-12.0.x range, all of which sort above that string while remaining affected until 12.0.0.44 — the direction that matters, because those hosts stay exposed with a clean report. The operational test for this entry is whether the scan resolves each install's branch and platform first and compares against the fixed build for that branch, rather than against any build merely newer than one of the three. Precondition: the check only reports on installs the scanner authenticates to and identifies by product. A per-user copy the scan does not resolve yields no finding, and no finding is indistinguishable from a clean host, so coverage has to be demonstrated by reconciling scan output against an independently built install inventory rather than by the absence of results. This control validates the comparison logic; it does not itself update anything. Terminal state, and this is what the version comparison above must not be mistaken for: Adobe Flash Player is end-of-life and receives no further fixes, so a copy sitting at the fixed build named here is current for this CVE and unpatched for every Flash defect found since. Reaching the fixed build is an interim state for a copy that cannot be removed today, not remediation. The requirement completes at removal of the Flash Player runtime and browser plugin, or replacement of whatever still depends on them; an estate that reports every install at or above the 2014 build and closes the finding has recorded parity with an abandoned product rather than removed the exposure. Where a business function still needs it, the honest record is an accepted exposure with a dated review and the runtime confined to hosts that reach nothing else — not a remediation entry.",
+        "evidence": "Packet vector: 'Integer underflow in Adobe Flash Player before 11.7.700.261 and 11.8.x through 12.0.x before 12.0.0.44 on Windows and Mac OS X, and before 11.2.202.336 on Linux, allows remote attackers to execute arbitrary code via unspecified vectors.' CWE-191. patch_available=true; live_patch_available=false; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' CISA KEV-listed 2024-09-17, active_exploitation=confirmed, CVSS 9.8, RWEP 50.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Two things about this entry defeat the usual prioritisation inputs, and this control's 'later of KEV listing or patch availability' rule is what corrects both. First, the fixed builds date from 2014 while CISA listed the CVE on 2024-09-17, so the SLA clock opens at the listing — a Flash Player install still in service on that date is inside a same-day mitigation window, not a ten-year-old backlog item that age-sorting pushes below current work. Second, the packet records poc_available=false alongside active_exploitation=confirmed: an intake rule that starts its clock on public exploit-code publication never starts at all on this entry, even though the packet states the flaw is being exploited. The listing date, not PoC availability and not the CVE year, is the trigger. Applied here that means driving the fixed build for each branch — 11.7.700.261, 12.0.0.44 for the 11.8.x-through-12.0.x range, 11.2.202.336 on Linux — across every install on the KEV clock, with completion measured by each install reporting the fixed build for its own branch rather than by the update being approved or downloaded in a management console. Precondition: the control permits documented compensating controls in place of the binary fix, but the packet registers no vendor mitigation and no live-patch path for this product, so there is nothing to substitute — the vendor update, which the packet states requires no reboot, is the remediation. An install that cannot take it inside the window is an open, dated exception carried as exposed, not an SLA closure. Terminal state, and this is what the version comparison above must not be mistaken for: Adobe Flash Player is end-of-life and receives no further fixes, so a copy sitting at the fixed build named here is current for this CVE and unpatched for every Flash defect found since. Reaching the fixed build is an interim state for a copy that cannot be removed today, not remediation. The requirement completes at removal of the Flash Player runtime and browser plugin, or replacement of whatever still depends on them; an estate that reports every install at or above the 2014 build and closes the finding has recorded parity with an abandoned product rather than removed the exposure. Where a business function still needs it, the honest record is an accepted exposure with a dated review and the runtime confined to hosts that reach nothing else — not a remediation entry.",
+        "evidence": "Packet: cisa_kev=true, kev_date 2024-09-17, active_exploitation=confirmed, poc_available=false, CVSS 9.8, RWEP 50. Vector gives fixed builds before 11.7.700.261, 11.8.x through 12.0.x before 12.0.0.44 on Windows and Mac OS X, and before 11.2.202.336 on Linux. attack_vector: 'An integer underflow during SWF parsing corrupts heap memory; a victim who loads an attacker-controlled Flash object (drive-by or malvertising) triggers arbitrary code execution in the browser context.' patch_available=true; live_patch_available=false; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-6670": {
     "name": "Progress WhatsUp Gold SQL Injection Vulnerability",
@@ -41478,7 +42279,41 @@
         "adequate": false,
         "gap": "Logical-access controls assume the admin password stays secret, but an unauthenticated SQLi extracts it — the control's trust boundary is bypassed rather than enforced."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "The packet places this defect on a WhatsUp Gold web endpoint that answers an unauthenticated caller, and the query behind it returns the stored encrypted user password. For this product the control means parameterization is proven at the query layer of the endpoints that answer without a session — those are the ones the packet's attack path uses — rather than inferred from an application input-validation layer or from a WAF fronting the console. That distinction is the reason the boundary-protection control cited against this entry does not close the path: the injection arrives as a well-formed request to an endpoint that is supposed to answer unauthenticated, so a perimeter rule tight enough to catch it also breaks legitimate monitoring traffic, and the query still concatenates on everything the rule lets through. Remediation is a build check the packet makes unambiguous: the flaw sits in versions released before 2024.0.0, and the packet records the vendor update as the remediation with no reboot required — so the usual objection that the monitoring server cannot be taken down does not apply to an update that does not take it down, and there is no live-patching primitive to wait for instead. Distinguishing test: against a staging WhatsUp Gold instance, send an unauthenticated request carrying a SQL metacharacter in the parameter the endpoint reads and confirm the query builder parameterizes it rather than returning stored password material — an attestation that the application validates input and sits behind a WAF passes while this endpoint keeps building the query by concatenation.",
+        "evidence": "Packet vector: 'In WhatsUp Gold versions released before 2024.0.0, a SQL Injection vulnerability allows an unauthenticated attacker to retrieve the users encrypted password.' attack_vector: 'An unauthenticated attacker sends a SQL injection payload to a WhatsUp Gold web endpoint to read the stored encrypted user password, then authenticates to the admin console and abuses monitoring tooling for code execution and lateral movement.' CWE-89; cvss 9.8; rwep_score 68; poc_available true; active_exploitation confirmed; CISA KEV-listed 2024-09-16; patch_available true; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' NIST SP 800-53 SC-7 (Boundary Protection) is among the framework controls this entry cites as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The packet's path does not stop at disclosure: the attacker reads the stored password, authenticates to the WhatsUp Gold admin console, and then abuses the monitoring tooling itself for code execution and lateral movement. That makes the WhatsUp Gold administrator a control-plane identity rather than an application administrator — the console's own legitimate capabilities are the execution vehicle, so downstream telemetry cannot separate the attacker's actions from an operator's, and collapsing this account into the generic 'admin' tier is what leaves it protected only by a password. Bound to this product, the control means console login is not satisfiable by a password alone: a phishing-resistant second factor at the console, an administrative identity used on no other system, and administrative access reached through a jump path rather than from general workstation segments. The second factor is the lever this specific CVE demands, because the primitive the packet describes yields a credential and nothing else — it is recovered with no interaction from the account owner at all, so every control premised on credential compromise happening through the user is out of the loop. Precondition, and this is where the control gets over-claimed: the factor blocks the packet's step-two console login; it does not stop step one. The unauthenticated read still returns the stored password material, so that material must be treated as disclosed and rotated wherever it was reused, and the factor gives nothing against a session or token already established during the exposure window. Distinguishing test: on a staging instance, attempt an admin-console login with a valid username and password and no second factor and confirm it is refused — the logical-access attestation this entry cites as insufficient asks whether console administrators are authorized, and in this attack every one of them is.",
+        "evidence": "Packet attack_vector: the attacker 'read[s] the stored encrypted user password, then authenticates to the admin console and abuses monitoring tooling for code execution and lateral movement.' Vector confirms the injection is reachable by an unauthenticated attacker and returns the stored encrypted user password. active_exploitation confirmed; poc_available true; CISA KEV-listed 2024-09-16; cvss 9.8; rwep_score 68. SOC 2 CC6 (Logical and Physical Access Controls) is among the framework controls this entry cites as insufficient.",
+        "gap_closes": [
+          "SOC2-CC6-logical-access"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "This entry's exposure outlives its own remediation, which is why an incident path is required alongside the update: the packet's primitive hands a stored password to an unauthenticated caller, and moving the instance to a build at or past 2024.0.0 stops further reads without invalidating anything already read. Bound to WhatsUp Gold, the playbook is to rotate the account passwords the packet says are stored and retrievable — and any credential reused from them on another system — then review the console's configured actions and monitoring tasks across the exposure window, because the packet names the monitoring tooling itself as the code-execution and lateral-movement vehicle, which makes a task or action added through the console the persistence mechanism to hunt for rather than a file on disk. Scope the review to the hosts the platform can act on, not to the monitoring server alone. The window to reconstruct runs from the 2024-09-16 KEV listing at the latest, and the packet's public-exploit flag means the capability was never limited to whoever found it. This also answers the security-monitoring gap cited on this entry, and answers it awkwardly: the asset under investigation is the estate's monitoring platform, so its own record of the period is a record an attacker holding console administration could alter, and the review has to be conducted against telemetry held where the console cannot write. Precondition: the playbook establishes what was done during the window and rotates what was exposed — it does not close the injection path, which only the vendor update does, and the packet records that update as requiring no reboot, so there is no sequencing excuse for running the investigation before remediating. Distinguishing test: for an instance that ran a build below 2024.0.0 while reachable, produce the rotation record for its stored credentials together with a diff of its configured actions across the exposure window; an instance closed out on the version upgrade alone has stopped the reads and left the consequences of the reads that already happened untouched.",
+        "evidence": "Packet vector: the injection 'allows an unauthenticated attacker to retrieve the users encrypted password' in versions released before 2024.0.0. attack_vector: the attacker 'then authenticates to the admin console and abuses monitoring tooling for code execution and lateral movement.' active_exploitation confirmed; poc_available true; CISA KEV-listed 2024-09-16; patch_available true; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' UK NCSC CAF C1 (Security monitoring) and SOC 2 CC6 (Logical and Physical Access Controls) are among the framework controls this entry cites as insufficient.",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "SOC2-CC6-logical-access"
+        ]
+      }
+    ]
   },
   "CVE-2024-43461": {
     "name": "Microsoft Windows MSHTML Platform Spoofing Vulnerability (CVE-2024-43461)",
@@ -42925,7 +43760,41 @@
         "adequate": false,
         "gap": "The vendor-default-account requirement is exactly the gap: the appliance shipped with a usable default password that operators did not change, yielding unauthenticated RCE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The packet puts the credential inside the product: remote command execution due to use of default passwords, with a remote unauthenticated attacker using the shipped default password to reach the ACI web portal and the PostgreSQL database. Because the password the attacker needs ships with ACI rather than being set per site, no amount of operator-side account hygiene reduces the exposure — which is precisely why the identity-and-access-control and IA-2 gaps are recorded against this entry: the attacker never authenticates as any named ACI administrator, so per-account privilege scoping is never consulted and the account model an identity attestation examines is bypassed rather than abused. Applied to this product the control means inventorying every ACI installation as depending on a product-shipped credential and gating each one on the fixed build for its own branch. The packet gives five separate branch lines — 5.0.1-61, 5.1.1-71, 5.2.1-69, 5.3.1-53 and 5.4.4-132 — so an installation on the 5.2 line is remediated at 5.2.1-69 and is not made safe by any build number that merely sorts higher than one of the other four. The check must be re-run after any appliance rebuild, image restore or node replacement, since those are the operations that quietly reinstate a pre-fix ACI carrying the shipped default at a site that had already been remediated. Distinguishing test: against a staging ACI at the build the estate intends to run, attempt authentication to the web portal and to the PostgreSQL service using the vendor's shipped default credential from a host holding no administrative role; anything that accepts it is exploitable, while an attestation showing every ACI administrator holds a unique named account passes cleanly the whole time. Precondition: the vendor update is what removes the dependence on the shipped default — 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. The packet records no live-patch path and a vendor update that requires a reboot, so an installation that has staged the fixed build but not restarted still carries the default and must be counted as exposed. It also does not detect an installation an attacker already reached, so anything reachable during the exposure window is closed out through the rebuild-and-rotation path, not on the update.",
+        "evidence": "Packet: CWE-1393; vector 'Remote command execution due to use of default passwords. The following products are affected: Acronis Cyber Infrastructure (ACI) before build 5.0.1-61, ... before build 5.1.1-71, ... before build 5.2.1-69, ... before build 5.3.1-53, ... before build 5.4.4-132.' attack_vector: 'A remote unauthenticated attacker uses the shipped default password to access the ACI web portal / PostgreSQL database, then uploads SSH keys to gain root on the appliance and execute arbitrary commands.' CISA KEV-listed 2024-07-29, active_exploitation=confirmed, poc_available=true, CVSS 9.8, RWEP 75. 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.'",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's attack path does not end at code execution — it ends at installed persistence: the attacker uses the shipped default password to reach the ACI web portal and PostgreSQL, then uploads SSH keys to gain root on the appliance. A key written into the appliance's authorized-keys material survives the vendor update, because the update removes the default credential that let the attacker in, not the key that keeps them in. On this entry, therefore, 'updated to the fixed build' is not a statement about whether the appliance is still attacker-accessible, and the packet's confirmed active exploitation plus public PoC mean that distinction is operational, not theoretical. Applied here the control means any ACI installation that was reachable by an unauthenticated caller during the exposure window is handled as a suspected compromise rather than a patch ticket: capture the configuration, the SSH authorized-keys material and the local account state for analysis first; rebuild the appliance from the fixed build rather than updating in place; and rotate every credential the appliance held or could reach, including the database credentials and any keys or tokens stored for the systems it serves. Distinguishing test: on an installation that has already taken the update, enumerate the SSH authorized keys and the local accounts on the appliance and reconcile every entry against an operator-owned record of what belongs there — an unexplained key is standing root access that both the patch and the flaw-remediation attestations record as closed. Precondition: rebuilding is remediation only if the rebuild source is the fixed build for that branch. Re-imaging from the installer media the site already had reinstates the same shipped default password and returns the appliance to the exploitable state — that is the specific way this recovery goes wrong. The rebuild also requires the reboot the packet's remediation note describes, and it recovers nothing the attacker took while resident: data reachable from the appliance and credentials it stored must be treated as disclosed however cleanly the appliance comes back.",
+        "evidence": "Packet attack_vector: 'A remote unauthenticated attacker uses the shipped default password to access the ACI web portal / PostgreSQL database, then uploads SSH keys to gain root on the appliance and execute arbitrary commands.' Vector: 'Remote command execution due to use of default passwords', fixed builds 5.0.1-61 / 5.1.1-71 / 5.2.1-69 / 5.3.1-53 / 5.4.4-132. CISA KEV-listed 2024-07-29, active_exploitation=confirmed, poc_available=true, CVSS 9.8, RWEP 75. 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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The packet names two surfaces the remote unauthenticated attacker reaches with the shipped default password, and one of them is not a web surface: the PostgreSQL database on the appliance. A database remoting endpoint that answers callers before any site-controlled authentication decision is the class this control governs, and it is the surface that web-tier hardening and role-and-permission audits of ACI never touch. The requirement for this deployment is that the ACI PostgreSQL listener accepts connections only from the hosts that legitimately speak to it — the appliance's own components and the management hosts with an operational need — enforced by network ACL or host firewall, rather than assumed from 'ACI is on the internal network'. Distinguishing test: from a general user or workstation VLAN on a staging deployment, open a connection to the ACI PostgreSQL port and confirm it is dropped before the service answers; a deployment that passes its ACI administrator-account review while leaving that listener reachable from any internal segment still hands the shipped default credential a live target. Preconditions, and they are severe enough that this must never be recorded as the remediation. It bounds who can present the default password; it does not change the fact that the password is valid, which only the vendor update does. It covers the PostgreSQL half only — the packet also names the ACI web portal, which is an HTTP surface outside this control and remains reachable to everyone the portal is meant to serve, so the exposure is reduced rather than removed. It does nothing against a caller already inside the permitted segment: a compromised management host or jump box satisfies the reachability precondition in full. And it does not evict an attacker who is already resident — an SSH key uploaded during the exposure window keeps working from wherever that key is used. This is a holding measure for the window before the update and its required reboot land, not a closure.",
+        "evidence": "Packet attack_vector: 'A remote unauthenticated attacker uses the shipped default password to access the ACI web portal / PostgreSQL database, then uploads SSH keys to gain root on the appliance and execute arbitrary commands.' Vector: 'Remote command execution due to use of default passwords', CWE-1393. CISA KEV-listed 2024-07-29, active_exploitation=confirmed, poc_available=true, CVSS 9.8, RWEP 75. 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.'",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "PCI-DSS-4.0-2.2.3"
+        ]
+      }
+    ]
   },
   "CVE-2024-5217": {
     "name": "ServiceNow Incomplete List of Disallowed Inputs Vulnerability",
@@ -42962,7 +43831,39 @@
         "adequate": false,
         "gap": "Input-validation control expectations were not met by the GlideExpression sanitizer's incomplete disallowed-input list, allowing template-injection payloads through."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The protection mechanism that failed here is a denylist inside the Now Platform itself: the packet places the bypass in the GlideExpression sanitizer, whose incomplete list of disallowed inputs lets a crafted jvar_page_title value submitted to /login.do carry Glide/Jelly expression syntax through to server-side template evaluation. A list that omitted one expression form is evidence about the form of the defence, not about that one payload. Bound to this product, the control means the verification battery for the Now Platform's expression sanitizer covers the family of Glide/Jelly expression encodings that can reach it, and is re-run on each Now Platform patch and hot fix rather than run once against the published jvar_page_title payload. Distinguishing test, keyed on the behaviour the packet documents: on a staging instance at the fixed patch level, submit each encoding variant of a Glide/Jelly expression in jvar_page_title to /login.do as an unauthenticated caller and confirm none reaches template evaluation — a check that replays only the one published payload passes while a sibling encoding still evaluates, which is precisely the failure CWE-184 names. Preconditions: this is a verification control and it repairs nothing — the sanitizer itself is fixed only by the vendor's June 2024 patch or hot fix, and the battery catches a re-opened form only if that form is in it, so an instance that passes a thin battery is not thereby patched. It is also a staging control: the packet records confirmed in-the-wild exploitation and a public exploit, so firing expression payloads at a production instance to 'confirm' the fix is not a substitute for applying it.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker submits a crafted jvar_page_title value to /login.do containing Glide/Jelly expression syntax; the GlideExpression sanitizer's incomplete disallowed-input list lets the payload reach server-side template evaluation, yielding remote code execution and data exfiltration.' Packet cwe_refs: CWE-184, CWE-697. Packet vector: the vulnerability 'is addressed in the listed patches and hot fixes below, which were released during the June 2024 patching cycle.' Packet: poc_available true; active_exploitation confirmed; cvss 9.2; rwep_score 74. Citing gaps record PCI-DSS-4.0-6.2.4 ('Software engineering techniques or other methods are defined and used by personnel to prevent or mitigate common software attacks') and UK-CAF-B4 (System security) against this entry.",
+        "gap_closes": [
+          "PCI-DSS-4.0-6.2.4",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet names the affected population by release family — Washington DC, Vancouver, and earlier Now Platform releases — but records the fix as patches and hot fixes shipped during the June 2024 patching cycle. Those two facts do not line up inside an asset inventory: an instance recorded as 'Washington DC' or 'Vancouver' is both the vulnerable and the fixed state depending on whether the June 2024 patch or hot fix has been applied, so a scan or CMDB field carrying only the family name cannot answer the question and will read as compliant on an unpatched instance. Bound to this product, the control means the vulnerability-management record for each Now Platform instance carries the applied patch and hot-fix level rather than the release family, and that the level is read from the instance rather than inherited from a change ticket asserting it. Operational test: for every instance, pull the applied patch/hot-fix level and confirm it is at or past the June 2024 fix for its family, then on staging submit the jvar_page_title expression payload the packet describes to /login.do and confirm it does not evaluate. An estate whose scanner reports every instance as a supported release family, while none has taken the June 2024 hot fix, passes the scan and stays exploitable. Precondition: this control finds an unremediated instance, it does not remediate one — a confirmed-unpatched instance still needs the vendor patch. And because the packet records confirmed exploitation with a public exploit, an instance found unpatched now was reachable and unpatched through the exposure window, so it warrants triage of what the instance served rather than a silent patch-and-close.",
+        "evidence": "Packet vector: 'ServiceNow has addressed an input validation vulnerability that was identified in the Washington DC, Vancouver, and earlier Now Platform releases. This vulnerability could enable an unauthenticated user to remotely execute code within the context of the Now Platform. The vulnerability is addressed in the listed patches and hot fixes below, which were released during the June 2024 patching cycle.' Packet: cisa_kev true, kev_date 2024-07-29, active_exploitation confirmed, poc_available true, rwep_score 74, cvss 9.2, patch_available true. Citing gaps record ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling) against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is KEV-listed 2024-07-29 with exploitation confirmed and a public exploit recorded, and it is one of the cases where the usual reason a KEV clock slips does not exist: the packet records no live-patching primitive but states that the vendor update is the remediation and needs no reboot, so there is no restart to schedule and no outage window to wait on. The SLA's completion criterion for this CVE is therefore each Now Platform instance running the June 2024 patch or hot fix for its release family — not a change request raised, not a KEV due-date row closed, not 'the update is staged'. The compensating-control half is where this entry differs from a typical appliance CVE: the packet places the payload on /login.do, the platform's login page, which has to answer unauthenticated callers for the platform to be usable, so restricting reachability is simply not available as the documented interim mitigation for any instance serving remote or customer traffic — which is why the boundary-protection gap cited on this entry cannot be written up as the mitigation while the patch waits. Where an instance's login page genuinely is reachable only from a private segment, that bounds who can send the payload and does nothing else: the endpoint stays fully exploitable to anything inside that segment, so it is a holding measure for hours, never a substitute for the patch.",
+        "evidence": "Packet: cisa_kev true; kev_date 2024-07-29; active_exploitation confirmed; poc_available true; rwep_score 74; cvss 9.2; 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.' Packet attack_vector places the crafted jvar_page_title value on /login.do, submitted by an unauthenticated attacker. Citing gaps record AU-Essential-8-Patch, NIST-800-53-SI-2 (Flaw Remediation) and NIST-800-53-SC-7 (Boundary Protection) against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-4879": {
     "name": "ServiceNow Improper Input Validation Vulnerability",
@@ -43036,7 +43937,18 @@
         "adequate": false,
         "gap": "Security-of-processing obligations were unmet because personal data (phone-number registration status) was disclosable without authentication or abuse-rate controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "What the packet records is not a flaw in the operator's own systems: the enumeration ran against an unauthenticated Twilio Authy API endpoint that answered whether each submitted phone number was registered, and the packet notes Authy accounts themselves were not compromised. The one operator-side surface the packet does name is the client build — the endpoint is described as accessed by Authy Android before 25.1.0 and Authy iOS before 26.1.0, and the packet records a vendor update, requiring no reboot, as the remediation. Bound to this entry, the control means managed devices on both platforms are driven to at least those builds under the KEV-class clock that opened 2024-07-23, enforced by the MDM as a required minimum app version with user deferral disallowed, rather than left to each user's store-update habits — an authenticator is exactly the app a user hesitates to touch, so a policy that merely offers the update leaves a long tail sitting below the fix. Distinguishing test: query the MDM for installed Authy versions across enrolled Android and iOS devices and confirm none sits below 25.1.0 and 26.1.0 respectively; an estate whose mobile attestation covers only the OS build reports fully compliant while the authenticator app stays below the fixed version. Preconditions, and they carry more weight than the rollout itself: moving devices to the fixed builds does not retract phone numbers already enumerated — the packet records exploitation in the wild in June 2024, and numbers read then stay in the attacker's hands as targeting data for exactly the phishing and SIM-swap activity the packet names as the downstream use. Nor is there operator-side detection to fall back on, because the requests went to the vendor's API: no telemetry inside the estate observed them and the exposed population cannot be derived locally. For that half of the exposure the remaining lever is treating the staff who hold Authy as a known-targeted set, which is a briefing and factor-choice decision this control does not deliver.",
+        "evidence": "Packet vector: 'In the Twilio Authy API, accessed by Authy Android before 25.1.0 and Authy iOS before 26.1.0, an unauthenticated endpoint provided access to certain phone-number data, as exploited in the wild in June 2024. Specifically, the endpoint accepted a stream of requests containing phone numbers, and responded with information about whether each phone number was registered with Authy. (Authy accounts were not compromised, however.)' Packet attack_vector: 'An attacker submitted large batches of phone numbers to an unauthenticated Authy API endpoint, which replied indicating whether each number was registered, enabling mass enumeration of Authy users for downstream phishing and SIM-swap targeting.' Packet: cisa_kev true; kev_date 2024-07-23; active_exploitation confirmed; poc_available false; cvss 5.3; rwep_score 40; 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 record UK-CAF-B4 (System security) against this entry.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2012-4792": {
     "name": "Microsoft Internet Explorer Use-After-Free Vulnerability",
@@ -43110,7 +44022,39 @@
         "adequate": false,
         "gap": "Least-privilege role design cannot remediate a vendor-shipped incorrect-default-permission that exposes secrets to non-administrative accounts; only the vendor patch or an explicit ACL fix closes it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records a vendor update as the remediation for these over-permissioned vCenter files, with no live-patch path and a fix that requires a reboot — so on this appliance the KEV clock that opened 2024-07-17 runs to the completed restart of every vCenter Server instance, not to the point the update is staged or a console reports it applied. A vCenter that has taken the update but not been restarted still carries the readable files, and restarting the management appliance is the step most likely to be deferred into the next virtualization maintenance window, which is the specific way this remediation gets recorded as done while the exposure stands. Priority has to come from the packet rather than the 6.5 base score: exploitation is confirmed in the wild, and the payoff the packet names is configuration data and secrets that enable privilege escalation and lateral movement in the virtualization estate, not the read-only outcome an information-disclosure severity band implies. poc_available is false, and that is not grounds to schedule this as routine — the packet records no public exploit alongside confirmed in-the-wild use. Distinguishing test: measure elapsed time from the KEV listing to each instance's post-update restart and report the tail per instance; a patch-compliance report counting deployed updates passes while instances await the restart that makes the fix effective.",
+        "evidence": "Packet: CWE-276; CISA KEV-listed 2024-07-17 with active_exploitation confirmed; RWEP 53, CVSS 6.5, poc_available false, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Packet attack_vector: 'A user with non-administrative access to vCenter Server reads sensitive files exposed by incorrect default file permissions, harvesting configuration data and secrets that enable privilege escalation and lateral movement in the virtualization estate.' Citing gaps name ASD Essential Eight 'Patch operating systems' and NIST SP 800-53 SI-2 (Flaw Remediation) as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "vCenter Server is the control plane for the virtualization estate the packet says this flaw enables lateral movement across, and the actor who exploits it is not an administrator — the packet's attacker holds non-administrative access to vCenter and reads secrets straight off the appliance's files. Bound to this product, the control means the privileged tier is drawn at every identity that can authenticate to vCenter at all — read-only, operator, integration and service accounts included — rather than at the vCenter administrator role: those sessions come through the privileged-access path with step-up authentication and just-in-time grant, held separately from identities used for ordinary application administration. That is exactly what the cited least-privilege and identity-and-access-control gaps do not reach here: role scoping inside vCenter is the thing the attacker is already inside of, so an estate can demonstrate that non-administrative roles carry no administrative permissions and still hand those same roles the configuration data and secrets the file permissions expose. Precondition: this bounds and instruments the population that can reach the files — it does not repair the permissions, which per the packet is the vendor update with the restart taken, and it gives nothing to an instance whose low-privilege accounts are already provisioned and in use. Distinguishing test: enumerate every principal that can open a session against vCenter, service and integration accounts included, and show each reaches it only through the tiered path; an attestation that vCenter administrators are separately tiered passes cleanly while a low-privilege role sits within reach of the same files.",
+        "evidence": "Packet vector: 'The vCenter Server contains an information disclosure vulnerability due to improper permission of files. A malicious actor with non-administrative access to the vCenter Server may exploit this issue to gain access to sensitive information.' CWE-276; CISA KEV-listed 2024-07-17 with active_exploitation confirmed; RWEP 53, CVSS 6.5. patch_available true, live_patch_available false. Citing gaps name UK NCSC CAF v3.2 B2 (Identity and access control) and NIST SP 800-53 AC-6 (Least Privilege) as insufficient.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "What this flaw yields, per the packet, is configuration data and secrets — so the moment a patched-and-restarted vCenter is clean is not the moment the estate is. The requirement here is a rehearsed sequence for any instance that was reachable by a non-administrative account while unpatched: rotate the credentials and keys carried in the files the packet says those accounts could read, re-issue whatever those secrets authenticate, review privileged authentications made with those identities across the window, and set quarantine criteria for the systems vCenter administers, because the packet's stated payoff is lateral movement in the virtualization estate rather than compromise of the appliance alone. The window closes at the restart, not at the KEV date, and on this entry it can be long — the listing is 2024-07-17 against a defect carrying a CVE-2022 identifier. Preconditions: rotation covers only secrets the operator can enumerate, so the list must be derived from what the appliance actually holds on disk rather than from a general credential inventory; and rotation is not detection — the packet's exploitation step is a read by an account authorized to be on the appliance, with poc_available false, so there is no distinct exploit artifact to hunt and misuse has to be looked for downstream in the authentications those secrets enable. Distinguishing test: for each vCenter that ran unpatched past the KEV listing, produce the list of secrets its readable files held and show each has been rotated after the restart; an incident record closed on 'update applied' passes flaw-remediation review with every one of those secrets still valid.",
+        "evidence": "Packet attack_vector: 'A user with non-administrative access to vCenter Server reads sensitive files exposed by incorrect default file permissions, harvesting configuration data and secrets that enable privilege escalation and lateral movement in the virtualization estate.' CWE-276; CISA KEV-listed 2024-07-17 with active_exploitation confirmed; RWEP 53, CVSS 6.5, poc_available false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gaps name NIST SP 800-53 SI-2 (Flaw Remediation) and UK NCSC CAF v3.2 B2 (Identity and access control) as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2024-28995": {
     "name": "SolarWinds Serv-U Path Traversal Vulnerability",
@@ -43184,7 +44128,38 @@
         "adequate": false,
         "gap": "Payment-card patch requirements lag the near-immediate skimmer deployment on compromised commerce sites."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-133",
+        "name": "ECOMMERCE-PLATFORM-EXTENSION-UNTRUSTED-DESERIALIZATION-GUARD",
+        "description": "The packet's chain has two halves and only the first is the XXE. The crafted XML POSTed to Magento's guest-cart REST/GraphQL endpoint resolves an external entity and returns the store's encryption key and files; it is the object-injection step the packet names behind it that converts that read into remote code execution and the skimmer/webshell deployment recorded as the outcome. Bound to Adobe Commerce and Magento Open Source, the control means no unauthenticated storefront request path hands request-supplied data to a native deserializer (PHP unserialize() on this platform) — the guest-cart REST and GraphQL paths named in the packet first, then every path a third-party extension registers — and that the installed extensions are enumerated as part of the storefront's code-execution surface rather than treated as configuration sitting on top of a patched core. Distinguishing test: against a staging store, send an unauthenticated guest-cart request carrying a crafted serialized object in each cookie and header the installed extensions read, and confirm it is refused before any deserialization runs; a store that can produce a clean platform-patch attestation while an extension still deserializes request data has evidence for the core and none for the sink the packet's chain actually lands in. Precondition: this governs the object-injection sink, not the XXE parser. A store that closes every deserialization path still leaks the encryption key and readable files through the entity resolution until the vendor update lands, and the packet records no live-patch path — the update is the only thing that closes the read half. It also does nothing for a store already carrying skimmer or webshell content from the exposure window.",
+        "evidence": "The packet's attack_vector states the crafted XML is POSTed to Magento's guest-cart REST/GraphQL endpoint, that the parser resolves the entity leaking the encryption key and files, and that the flaw \"chained with object injection achieves remote code execution and skimmer/webshell deployment\" — the packet itself names object injection as the step that turns the read into execution. The vector adds that \"Exploitation of this issue does not require user interaction\" and lists Adobe Commerce 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier as affected (CWE-611). poc_available true, active_exploitation \"confirmed\", CVSS 9.8, RWEP 74. Citing gaps ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and PCI-DSS-4.0-6.3.3 (\"All system components are protected from known vulnerabilities by installing applicable security patches/updates\") are both patch-installation attestations.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "PCI-DSS-4.0-6.3.3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "What the packet describes an attacker walking away with — the store's encryption key, the files the parser could read, and a deployed skimmer or webshell — is not taken back by the vendor update. For an internet-facing Adobe Commerce or Magento storefront reached through this unauthenticated, no-user-interaction chain during a period of confirmed exploitation, the default response has to be to treat the host as compromised rather than remediated: rotate the encryption key and every credential and API token reachable from files readable by the web process, hunt the storefront and checkout render paths for injected skimmer script and for webshells, and rebuild from a known-good baseline where that hunt cannot be made conclusive. Distinguishing test is temporal rather than technical: ask what version the store was running before the update and whether the encryption key was rotated after it — a flaw-remediation record showing only \"updated to a fixed release\" attests to closing the parser while leaving a key the attacker may already hold in service, and the same signed-payload path stays open with the patched parser untouched. Precondition: this is an incident-response default, not a mitigation of the vulnerability. It presumes the vendor update is applied (the packet records it as available, with no live-patch path and no reboot required), and rotation only covers secrets the operator can enumerate — anything readable by the web process that is not inventoried stays valid after the rebuild.",
+        "evidence": "Packet records active_exploitation \"confirmed\" and poc_available true, and the attack_vector states the outcome as \"skimmer/webshell deployment\" reached after the entity resolution \"leaking the encryption key and files\". patch_available is true and live_patch_notes reads \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation\" — the packet records nothing that reverses the key disclosure or removes deployed skimmer/webshell content. KEV-listed 2024-07-17. Citing gaps NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling) are the attestations a completed update satisfies on its own.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the compressed clock is unusually well matched to what the packet records on both sides. On the threat side there is no access precondition for the attacker to satisfy: the entry point is a public storefront's guest-cart REST/GraphQL path, the vector states exploitation does not require user interaction, a PoC is public and exploitation is confirmed. On the remediation side the packet records a vendor update with no live-patch path but also no reboot requirement — for this product the update is a deploy, not an outage — so the control's requirement of a verified mitigation within 4 hours of the KEV listing or of patch availability, whichever is later, is actually achievable here rather than aspirational. Applied to Adobe Commerce and Magento Open Source: the store's clock starts at the 2024-07-17 KEV listing, and completion is measured by the version the storefront is running, not by a change ticket reaching approved. Distinguishing test: pull the running version from the storefront itself and compare it against the affected list the packet names, rather than accepting the deployment pipeline's record of what it pushed. Precondition: an SLA governs the length of the window, not what happened inside it. A store that meets the clock but was reachable earlier is patched, not clean, and belongs on the incident path — the KEV listing marks when the obligation starts, not when exploitation started.",
+        "evidence": "cisa_kev true with kev_date 2024-07-17; active_exploitation \"confirmed\"; poc_available true; CVSS 9.8; RWEP 74. The vector states \"Exploitation of this issue does not require user interaction\" and the attack_vector places the entry point on an unauthenticated POST to Magento's guest-cart REST/GraphQL endpoint. patch_available true; live_patch_notes: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" Citing gap AU-Essential-8-Patch (Patch operating systems).",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-36401": {
     "name": "OSGeo GeoServer GeoTools Eval Injection Vulnerability",
@@ -43414,7 +44389,38 @@
         "adequate": false,
         "gap": "Least-functionality that fully removes/disables the legacy Internet Explorer/MSHTML rendering path would have blunted the technique; leaving the retired engine reachable kept the attack surface alive."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation starts with a file the user opens: the packet's lure is a crafted .url internet shortcut whose content is the URL it points at, using the 'mhtml:' scheme and an '!x-usc:' directive so Windows hands the target to the retired Internet Explorer/MSHTML engine and the perceived file type is not what actually renders. Because the endpoint's decision is made from what the shortcut says, the enforceable control on an estate that has not completed the update is the ingress boundary: the mail gateway and file-share boundary apply the untrusted-origin marking themselves rather than leaving the endpoint to infer it, internet shortcut files arriving from outside the organization are held rather than delivered, and the marking survives the container — a shortcut extracted from an archive, mounted from an image, or renamed inherits the tag instead of losing it. Precondition: this narrows the delivery path, it does not close the flaw. A .url reaching the user through any path the boundary does not mark — removable media, an unmanaged share, a link followed directly in a browser — still resolves the mhtml:/!x-usc: handler chain into MSHTML, and per the packet only the vendor update, on a host that has since been restarted, removes that. Distinguishing test: deliver a .url whose displayed name and invoked handler disagree through each ingress path onto a managed workstation and confirm it arrives marked untrusted or is held; the user-application-hardening attestation cited on this entry covers macro and ActiveX settings and guidance to check file extensions, which is precisely what a file-type-spoofing lure defeats.",
+        "evidence": "Packet attack_vector: 'A victim opens a crafted .url internet-shortcut whose URL uses the \"mhtml:\" scheme and an \"!x-usc:\" directive; Windows invokes the retired Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA, spoofing the perceived file type and executing code (Void Banshee delivered the Atlantida stealer this way).' CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gap names ASD Essential Eight 'User application hardening' as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Per the packet this is a vendor update with no live-patch path and a fix that requires a reboot, so the clock opened by the 2024-07-09 KEV listing runs to the completed restart of every affected Windows endpoint, not to update-deployment counts. An endpoint that has taken the update but not restarted still resolves the packet's mhtml:/!x-usc: shortcut into the retired engine, and user-workstation restarts are exactly what deployment reporting conceals — 'installed, pending restart' is the state in which this remediation is recorded as complete while the path stays live. Urgency comes from the packet's own fields rather than the 7.5 base score: poc_available is true, active_exploitation is confirmed, and the packet ties the technique to the Void Banshee delivery of the Atlantida stealer, so every hour of the window on a user endpoint is an hour of potential credential loss rather than only of exposure. Distinguishing test: measure elapsed time from the KEV listing to each endpoint's post-update restart and report the tail rather than the mean; a fleet reported compliant on installed-update counts while endpoints await restart has not closed the window.",
+        "evidence": "Packet: CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Packet attack_vector records that 'Void Banshee delivered the Atlantida stealer this way'. Citing gaps name NIST SP 800-53 SI-2 (Flaw Remediation), EU NIS2 Art.21 vulnerability handling and disclosure, and ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The component this flaw executes through is a retired one the OS still carries: the packet has Windows invoking the Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA because a shortcut asked for it by scheme. The vendor update fixes this defect; it does not take the engine off the host, and the invocation path that reached it is a handler the OS still resolves. The requirement here is that the compensating control an operator stands up before the update lands — an application-control policy that blocks the retired rendering path, and the HTA execution the packet describes, from being invoked out of an internet shortcut — is retained after the update with a stated review period, rather than rolled back as redundant once the fix is deployed. That is the cited least-functionality gap in operational form: least functionality reads as met because Internet Explorer is retired, while the engine behind it stays reachable to anything that names it. Preconditions: application control binds only where it is deployed and running in enforce rather than audit mode, and it governs the invocation, not the parsing — a host without that policy is carried by the update and its restart alone, and on a host where the policy is in audit mode the invocation still succeeds and is merely logged. Distinguishing test: on a fully updated managed workstation, open a test .url that uses the mhtml: scheme and confirm the policy refuses the invocation rather than the engine rendering the content; a least-functionality attestation recording that Internet Explorer is not installed passes cleanly while this path resolves.",
+        "evidence": "Packet attack_vector: 'A victim opens a crafted .url internet-shortcut whose URL uses the \"mhtml:\" scheme and an \"!x-usc:\" directive; Windows invokes the retired Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA, spoofing the perceived file type and executing code.' CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gap names NIST SP 800-53 CM-7 (Least Functionality) as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2024-20399": {
     "name": "Cisco NX-OS Command Injection Vulnerability",
@@ -43599,7 +44605,32 @@
         "adequate": false,
         "gap": "Access enforcement failed at the application layer: the registration endpoint remained reachable and trusted a spoofed identity, so no downstream authorization control was consulted."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The registration endpoint is where Telerik Report Server decides whether a caller may hold an account, and this CVE is that decision failing open: the packet has an unauthenticated caller reach the endpoint on an already-configured instance and create an administrator through a spoofed request. Bound to this product, the control means the account-creation function on the Report Server authorizes its caller itself — an instance past initial setup refusing to enrol any account, and above all an administrator account, for a caller it has not authenticated — rather than deriving that verdict from attacker-supplied request content; and the Report Server's IIS-hosted surface is segmented so a caller with no operational need to reach it cannot present the spoofed request at all. The access-enforcement and identity-and-access controls cited as insufficient on this entry never engage on this path: the attacker holds no Report Server account, so per-account authorization is never consulted and the account model an identity attestation examines is bypassed rather than abused — the attacker supplies the account rather than abusing one. Distinguishing test: from a segment with no operational need for report administration, send unauthenticated account-creation requests to a staging Report Server that has already completed its initial setup, and confirm each is refused before any account exists; an attestation that every Report Server administrator authenticates at login passes cleanly while this path stays open. Precondition: the endpoint-side authorization is a property the vendor update establishes — this control states what to verify, it does not implement it. Until that update lands, restricting which segments can reach the Report Server bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable wherever report consumers must reach the server over the network. Segmentation also says nothing about an administrator account already created through this path: such an account survives both the segmentation change and the update, so an instance reachable during the exposure window needs its administrator accounts and account-creation events reviewed rather than being closed on the patch.",
+        "evidence": "The packet places the flaw in Progress Telerik Report Server, version 2024 Q1 (10.0.24.305) or earlier, on IIS, and describes an unauthenticated attacker gaining access to restricted functionality via authentication bypass by spoofing (CWE-290). The recorded attack path: an unauthenticated attacker reaches the Report Server registration endpoint on an already-configured instance and, via a spoofed request, creates a new administrator account, then commonly chains CVE-2024-1800 deserialization for remote code execution. CISA KEV-listed 2024-06-13 with confirmed in-the-wild exploitation, a public PoC, CVSS 9.8 and RWEP 68. The packet cites NIST-800-53-AC-3 (Access Enforcement), UK-CAF-B2 (Identity and access control), NIST-800-53-SC-7 (Boundary Protection) and NIS2-Art21-network-security as the framework controls this entry demonstrates are insufficient. It records a vendor patch, no live-patch path, and notes the vendor update as the remediation.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B2",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the cost argument that normally justifies a slow patch queue is absent: the packet records a vendor update with no live-patch path and states the update requires no reboot, so nothing about applying it needs a host outage window, which removes the usual reason a reporting server sits behind a 30-day application-patching cycle. Applied here the control means every Telerik Report Server instance is enumerated and taken past the affected build on the clock that opened with the 2024-06-13 KEV listing rather than on the next quarterly application cycle, with completion measured by the build each instance actually reports — the packet names version 2024 Q1 (10.0.24.305) or earlier as affected, so an instance still reporting that build or earlier is exposed regardless of what its patch-status field says. Enumerate instances by reachability first: the exploit precondition the packet states is simply reaching the registration endpoint of an already-configured instance, so an instance answering to a broad network population is where the KEV clock matters most. Priority follows the packet rather than the CVSS band alone: confirmed in-the-wild exploitation, a public PoC and the packet's note that the bypass is commonly chained into CVE-2024-1800 deserialization make this a remote-code-execution precursor, not a standalone account-creation defect. Precondition: the update closes the bypass, it does not remove an administrator account an attacker created before it landed and it does not undo anything executed through the chained deserialization step. An instance that was reachable during the exposure window needs an administrator-account and credential review alongside the upgrade, not instead of it — flaw-remediation and technical-vulnerability-management attestations both read clean on a server that is now patched and still carries the attacker's administrator.",
+        "evidence": "The packet records CISA KEV listing on 2024-06-13, active_exploitation confirmed, poc_available true, CVSS 9.8 and RWEP 68 for Progress Telerik Report Server, version 2024 Q1 (10.0.24.305) or earlier, on IIS. patch_available is true, live_patch_available is false, and live_patch_notes states: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" The packet's attack path is an unauthenticated spoofed request to the registration endpoint of an already-configured instance creating a new administrator account, commonly chained with CVE-2024-1800 deserialization for remote code execution. AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are cited as the insufficient controls.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-26169": {
     "name": "Microsoft Windows Error Reporting Service Improper Privilege Management Vulnerability",
@@ -43673,7 +44704,31 @@
         "adequate": false,
         "gap": "Mobile-device patching guidance cannot close a firmware logic flaw until the OEM update lands, so the control is insufficient against active zero-day use."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Pixel handsets take this fix as a vendor update that the packet says requires a reboot, with no live-patch path, so remediation is the update plus a restart on every affected device — and on a handset both steps sit with the user unless enrolment makes them mandatory. For this CVE the control means the update policy on managed Pixel devices is enforced rather than advisory: automatic installation of the security update, a mandated restart window, user deferral disallowed, and completion measured by the security patch level each device reports after it has restarted rather than by 'update pushed' or 'update downloaded'. The restart is the specific step that goes wrong here — the packet ties remediation to a reboot, so a Pixel that has taken the update and not restarted still runs the vulnerable code, and counting it as patched is how this remediation is recorded complete while the exposure stands. Priority follows the packet rather than the 7.8 base score: confirmed in-the-wild exploitation and a public PoC against an escalation that needs no additional execution privileges, on a device class that leaves the managed network every day. Precondition: enforcement reaches only devices the estate actually manages. An unenrolled or personally-owned Pixel carrying organizational data is outside this control's reach entirely, and is remediated by enrolling it or withdrawing the data from it, not by leaving it uncounted on a compliance report. And the update does nothing about a device already exploited during the window before it landed — with exploitation confirmed, a device on which the crafted application ran belongs on the incident path rather than being closed on its new patch level.",
+        "evidence": "The packet describes a logic-error bypass leading to local escalation of privilege with no additional execution privileges needed, and states that user interaction is needed for exploitation; the attack path is a locally present, crafted application escalating from an unprivileged context to system-level privileges on Pixel firmware / the Android Framework (CWE-670, CWE-783). CISA KEV-listed 2024-06-13, active_exploitation confirmed, poc_available true, CVSS 7.8, RWEP 73. patch_available is true, live_patch_available is false, and live_patch_notes states: \"No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.\" NIS2-Art21-patch-management, NIST-800-53-SI-2, AU-ISM-1546 and ISO-27001-2022-A.8.8 are cited as the insufficient controls.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "AU-ISM-1546",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records is a locally present, crafted application, and the escalation runs from an unprivileged context to system-level privileges with no additional execution privileges needed — so for this entry the control's access-condition half is the load-bearing one. Applied to the Pixel devices in the estate, the build carrying the fix has to function as an access condition: mail, VPN and document access denied to a Pixel below it, not the stale patch level surfacing as a row on a compliance dashboard while the device keeps its access. Because the packet ties remediation to a reboot, the condition must be evaluated against the patch level the device reports after restarting; a device that has installed but not restarted sits below the bar. Distinguishing test: enrol a Pixel pinned below the fixed build and confirm the policy actually denies it access to protected resources — an estate that reports the stale build while the handset keeps syncing mail has recorded the exposure rather than removed it. The least-privilege control cited as insufficient here is not the lever it appears to be: the escalation begins in an unprivileged context and crosses a privilege boundary inside the platform, so per-application privilege scoping is never the thing that fails and an AC-6 attestation passes cleanly while the flaw stays fully exploitable. Precondition: restricting untrusted or side-loaded application installation raises the bar for getting the attacker's application onto a device, but it does not evict an application already installed, and it does not cover one that arrived through the normal store channel; the packet's requirement of user interaction also means the delivery step runs through a user, which policy narrows but does not eliminate. A device suspected of already running the crafted application belongs on the incident path, not the install-policy path. This is a holding measure for the window before the update and its restart land, not a substitute for them.",
+        "evidence": "The packet's vector states there is a possible way to bypass due to a logic error in the code, leading to local escalation of privilege with no additional execution privileges needed, and that user interaction is needed for exploitation; the attack path is a locally present, crafted application bypassing a privilege boundary in Pixel firmware / the Android Framework to reach system-level privileges. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are cited as insufficient controls on this entry. The packet records patch_available true, live_patch_available false, and live_patch_notes stating the vendor update requires a reboot and is the remediation. It names no affected Pixel model or Android release, so no build or version is asserted here beyond \"the build carrying the vendor fix\".",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-4577": {
     "name": "PHP-CGI OS Command Injection Vulnerability",
@@ -43927,7 +44982,29 @@
         "adequate": false,
         "gap": "SI-3 malicious-code protection trusted a signed, vendor-distributed installer and failed to catch the embedded supply-chain backdoor."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-132",
+        "name": "INDEPENDENT-INTEGRITY-VERIFICATION-OF-SIGNED-VENDOR-INSTALLERS",
+        "description": "The defect here is not in JAVS Viewer's code — it is that the installer users pulled from the vendor's own supply chain, Viewer Setup 8.3.7.250-1, contained a malicious binary and was signed with an unexpected Authenticode signature. A signature check on that download returns a valid answer to the wrong question: the file is signed, and signed by a certificate the installing organization never established as this vendor's. Bound to this product, the control means JAVS Viewer builds are not installed onto courtroom recording hosts straight from the vendor download page, but pulled into managed software distribution and checked against an integrity source independent of the download itself — a vendor-published per-release hash obtained over a separate channel, or the signer identity pinned to the certificate the vendor's prior releases carried — before any endpoint is permitted to run them. Distinguishing test: take the version string and the Authenticode signer of the JAVS Viewer build actually installed on each recording host and compare the signer against the pinned vendor identity, not merely against \"signed and trusted\" — a software-installation policy that requires signed installers accepts 8.3.7.250-1 without complaint, which is precisely what the packet records happening. Precondition: this control governs the intake decision and gives nothing to a host that already ran the trojanized installer. The packet records that installer dropping fffmpeg.exe, beaconing to a C2 server and executing unauthorized PowerShell to grant attacker control of the host, so a host that installed 8.3.7 is an incident — installing the vendor's clean build over the top does not remove what the attacker placed or revoke what it already took.",
+        "evidence": "Packet vector: \"Justice AV Solutions Viewer Setup 8.3.7.250-1 contains a malicious binary when executed and is signed with an unexpected authenticode signature. A remote, privileged threat actor may exploit this vulnerability to execute of unauthorized PowerShell commands.\" attack_vector: \"Users downloaded a trojanized JAVS Viewer 8.3.7 installer from the vendor's supply chain; the installer dropped a malicious fffmpeg.exe that beaconed to a C2 server and executed unauthorized PowerShell, granting attacker control of the courtroom recording host.\" CWE-506 (embedded malicious code); cisa_kev true, kev_date 2024-05-29; active_exploitation \"confirmed\"; CVSS 8.7; RWEP 42; poc_available false. Citing gaps NIST-800-53-SI-3 (Malicious Code Protection), ISO-27001-2022-A.8.7 (Protection against malware) and AU-ISM-1546 (Patch operating systems and applications).",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock applies, but for this entry what has to be deployed inside it is not only the vendor's clean build. The packet's malicious artifact is the installed product: a host running Viewer Setup 8.3.7.250-1 holds a dropped fffmpeg.exe that beacons to a C2 server and executes unauthorized PowerShell, so the state the SLA must close is the presence of that build on courtroom recording hosts, and \"verified mitigation\" for this CVE means the trojanized installation is removed and the host rebuilt — not that a newer installer was made available. The packet supports a fast clock on the remediation side: a vendor update exists with no live-patch path and no reboot requirement. Distinguishing test: enumerate hosts by the JAVS Viewer version actually installed and by the presence of the dropped fffmpeg.exe, and confirm each affected host was rebuilt rather than upgraded in place — an estate that verifies the installer currently on the vendor's download page is clean has tested the wrong artifact, since the malicious one is already resident. Where a recording host cannot be taken out of service immediately, the only interim lever the packet supports is watching for the behaviour it documents: outbound connections from the dropped fffmpeg.exe and PowerShell execution originating from the JAVS installation path. That is a detection, and it bounds dwell time rather than removing attacker control — a host that beacons has already granted it.",
+        "evidence": "cisa_kev true with kev_date 2024-05-29; active_exploitation \"confirmed\"; RWEP 42; poc_available false. patch_available true with live_patch_notes \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" The attack_vector records the installed product itself as the malicious artifact — the dropped fffmpeg.exe \"beaconed to a C2 server and executed unauthorized PowerShell, granting attacker control of the courtroom recording host\" — and the vector records the same PowerShell outcome. Citing gap NIS2-Art21-vulnerability-handling (Cybersecurity risk-management measures — vulnerability handling and disclosure).",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-5274": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2024-5274)",
@@ -44015,7 +45092,29 @@
         "adequate": false,
         "gap": "The Flink JobManager REST/dashboard (default 8081) is frequently exposed to the internet; boundary protection is the primary missing control since Flink offers no built-in auth on this interface."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-094",
+        "name": "AI-RUNTIME-API-PATH-TRAVERSAL-VALIDATION",
+        "description": "The Flink JobManager's REST interface serves a log file selected by a caller-supplied path, and the packet names the bypass precisely: double-URL-encoded '../' sequences. That is the signature of containment enforced by inspecting the request string instead of by resolving the path — one decode pass strips the outer encoding, the filter runs against what it sees, and the traversal that finally reaches the filesystem was never the string the filter examined. For this component the requirement is that the JobManager resolve the requested log path to an absolute canonical form and verify the result is still under the permitted log directory immediately before the file handle is opened, rejecting absolute paths, residual '../' segments, and symlinks that leave the directory — the check belongs at path resolution, not at request parsing. The read direction is the entire exposure here: the packet scopes the leak to any file the JobManager process can read and names config, credentials and /etc/passwd, so the identity that process runs as decides what a single unauthenticated GET returns, and tightening the JobManager's own filesystem reach limits the blast radius of the next traversal defect as well as this one. Distinguishing test: against a staging JobManager, request the log endpoint with singly-encoded and doubly-encoded traversal sequences and confirm both are refused at path resolution — a deployment that rejects the plain '../' form and returns a file for the encoded one has a filter, not containment, and that is the exact difference this CVE turns into an arbitrary file read. Precondition: this states the property the vendor fix establishes, it does not implement it. The packet gives Flink 1.11.3 and 1.12.0 as the upgrade targets for the affected 1.11.0, 1.11.1 and 1.11.2 releases and records no live-patch path, so an operator still running an affected release gets nothing from this control by itself.",
+        "evidence": "attack_vector: \"An unauthenticated attacker sends a GET to the Flink JobManager REST logs endpoint with double-URL-encoded '../' sequences, causing the process to return the contents of any file it can read (config, credentials, /etc/passwd).\" vector: the change introduced in Apache Flink 1.11.0 \"allows attackers to read any file on the local filesystem of the JobManager through the REST interface of the JobManager process. Access is restricted to files accessible by the JobManager process. All users should upgrade to Flink 1.11.3 or 1.12.0 if their Flink instance(s) are exposed.\" CWE-552; poc_available true; active_exploitation \"confirmed\"; cisa_kev true, kev_date 2024-05-23; CVSS 7.5; RWEP 65. patch_available true; live_patch_notes: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" Citing gaps ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-088",
+        "name": "AI-COMPUTE-CONTROL-PLANE-AUTHENTICATION",
+        "description": "The exploit in the packet is an unauthenticated GET, and nothing about it is subtle: the JobManager's REST interface — the control plane through which jobs are submitted and the cluster is managed — answers a caller who has presented no credential, and the vector's own upgrade instruction is conditioned on whether the instance is \"exposed\", which is deployment posture doing the security work instead of the service. For a Flink cluster the control means that REST interface is reachable only from segments with an operational need to submit or manage jobs, and is fronted by an authenticating proxy so a caller is identified before the endpoint is consulted, because \"the cluster is on an internal network\" is an assumption about topology rather than an access-control decision — and it is exactly the assumption this CVE converts into an arbitrary file read. It also means a cluster that was reachable during the exposure window is treated as having disclosed whatever the JobManager account could read: the packet names config and credentials among the returned content, and moving to a fixed release does not invalidate a credential already read out, so rotating what the JobManager could reach is part of remediation rather than a follow-up item. Distinguishing test: from a general workstation or application VLAN, and from outside the estate, issue an unauthenticated GET to the JobManager REST endpoint on a staging cluster and confirm it is refused before reaching the service — a cluster whose vulnerability-management record shows the fixed release while its control plane still answers unauthenticated callers has closed this traversal and left the next one fully exposed. Precondition: restricting reachability bounds who can send the request, it does not repair the endpoint, and any host already inside a permitted segment — a compromised application server, a CI runner, a jump host — satisfies the exploit's only stated access requirement in full. It is a holding measure for clusters not yet on 1.11.3 or 1.12.0, not a substitute for them.",
+        "evidence": "The packet's attack_vector requires no credential: \"An unauthenticated attacker sends a GET to the Flink JobManager REST logs endpoint...\" The vector conditions its remediation instruction on exposure — \"All users should upgrade to Flink 1.11.3 or 1.12.0 if their Flink instance(s) are exposed\" — and scopes the returned content to \"any file it can read (config, credentials, /etc/passwd)\", with access \"restricted to files accessible by the JobManager process\". active_exploitation \"confirmed\"; poc_available true; KEV-listed 2024-05-23. patch_available true; live_patch_notes: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" Citing gaps NIST-800-53-SC-7 (Boundary Protection) and NIS2-Art21-network-security (Security of network and information systems).",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-4947": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2024-4947)",
@@ -44052,7 +45151,30 @@
         "adequate": false,
         "gap": "Endpoint malicious-code protection does not reliably stop in-renderer memory-corruption execution delivered from a legitimate-looking site."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's fix boundary for this CVE is a browser build number, not a configuration change: the vector states the type confusion is present in V8 in Google Chrome prior to 125.0.6422.60. Bound to that, the control means every managed Chrome/Chromium install on the estate is driven onto a build at or above 125.0.6422.60 on the security channel, with completion measured per endpoint by the version the browser actually reports rather than by the update policy showing as applied in the management console. The deferral question is the whole control here because the packet removes the usual excuse for it: live_patch_available is false but live_patch_notes record that the vendor update requires no reboot, so nothing about this remediation needs a user's machine taken out of service. What holds an endpoint on a vulnerable build is a pinned or extended-stable ring, a staged rollout percentage, or a user-deferrable relaunch — all policy, not constraint. The user-application-hardening measure cited as insufficient on this entry does not touch the path: the packet's trigger is a victim loading a crafted HTML page whose ordinary JavaScript reaches V8, so there is no plugin to disable, no macro to block and no download to gate, and a hardening attestation covering those settings passes cleanly while the browser build stays below the fix. Distinguishing test: enumerate the reported browser version on every managed endpoint and confirm none is below 125.0.6422.60; a fleet whose console shows the update approved and pushed while endpoints still report a pre-125.0.6422.60 build is not remediated. Scope this to the Chrome/Chromium installs the packet names — it identifies V8 in Google Chrome and gives no mapping from the vulnerable build into other JavaScript-executing software, so treating every browser or embedded web view in the estate as an instance of this CVE manufactures work against software no evidence in the packet implicates. Precondition: this reaches only installs under managed update policy; an unmanaged or per-user copy is remediated by bringing it under management or removing it, not by recording the fleet as patched.",
+        "evidence": "Packet facts only. vector: 'Type Confusion in V8 in Google Chrome prior to 125.0.6422.60 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)'. attack_vector: 'A victim visits an attacker-controlled page (a fake blockchain/game site in the observed campaign) that runs crafted JavaScript triggering a V8 type confusion, corrupting the heap and executing code inside the renderer sandbox.' cisa_kev true, kev_date 2024-05-20, active_exploitation 'confirmed', CVSS 9.6, RWEP 56, CWE-843, poc_available false, ai_discovered false. patch_available true; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' Cited as insufficient on this entry: AU-Essential-8-App-Hardening (User application hardening), ISO-27001-2022-A.8.8, NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the control fixes when the browser build has to land and what an operator is allowed to count as holding the line until it does. The clock opens at the 2026-era-agnostic fact the packet records: KEV listing 2024-05-20 with active_exploitation 'confirmed', against a product whose fix the packet says needs no reboot — so the interval between listing and a fleet-wide build at or above 125.0.6422.60 is measured in the estate's update-ring latency and nothing else. Where an endpoint genuinely cannot take the build inside that window, the packet supports exactly one compensating lever, and it is the delivery path rather than the vulnerable code: exploitation requires the victim's browser to load the attacker's crafted page, which in the observed campaign the packet describes as a fake blockchain/game site. Restricting which sites managed browsers may load — denying uncategorized and newly-observed destinations for the affected population — bounds who can be brought to the page. Precondition, and it must be written down as one rather than recorded as the mitigation: this bounds reach, it does not repair the type confusion. It gives nothing against a crafted page served from a domain the filter permits, and nothing at all for an endpoint that has already loaded one — with exploitation confirmed in the wild and no PoC needed by the attacker, a browser that ran the crafted script belongs on the incident path, not the filtering path. The packet registers no live-patch primitive and no vendor mitigation rule, so there is no third state to claim: an endpoint is either on the fixed build or it is running the vulnerable one behind a holding measure with a dated expiry. Distinguishing test: for every endpoint still below the fixed build, produce the named compensating measure and its removal date; an entry on the risk register with no build target and no expiry is deferral recorded as compliance.",
+        "evidence": "Packet facts only. cisa_kev true, kev_date 2024-05-20; active_exploitation 'confirmed'; poc_available false; ai_discovered false; RWEP 56, CVSS 9.6. patch_available true; live_patch_available false; live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' vector names the fixed boundary as Google Chrome prior to 125.0.6422.60. attack_vector: 'A victim visits an attacker-controlled page (a fake blockchain/game site in the observed campaign) that runs crafted JavaScript triggering a V8 type confusion, corrupting the heap and executing code inside the renderer sandbox.' Cited as insufficient on this entry: ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-43208": {
     "name": "NextGen Healthcare Mirth Connect Deserialization of Untrusted Data Vulnerability",
@@ -44227,7 +45349,32 @@
         "adequate": false,
         "gap": "The affected DIR-600 revisions are end-of-life with no forthcoming fix, so flaw-remediation via patching is impossible and the only remedy is device retirement."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet carries two facts that must be resolved per unit before anything else: patch_available is recorded as false, and live_patch_notes states that firmware after 2.17b02 addressed the original issue only for supported revisions while rev. Bx hardware is end-of-life/end-of-service. So the first requirement is an inventory that names every DIR-600 in service with its hardware revision, taken from the device rather than assumed from the model name. A unit whose revision still receives vendor firmware is one class of item; a rev. Bx unit is a different class entirely, because there is no build it can be moved to and its only resolution is replacement on a dated schedule. Bound to this device, that distinction is invisible without the revision: an asset register that records 'D-Link DIR-600' cannot tell an operator which of its routers the firmware covers, and a risk acceptance with no removal date leaves a KEV-listed router with a public exploit answering hedwig.cgi, pigwidgeon.cgi and diagnostic.php indefinitely. Distinguishing test: read the hardware revision off every DIR-600 in the estate and confirm each rev. Bx unit carries a dated replacement commitment rather than a firmware ticket that will never close; a scanner that reports the model as current because it sees a firmware string at or above 2.17b02, without reading the revision, reports paper compliance on hardware that firmware does not cover.",
+        "evidence": "Packet records patch_available: false and live_patch_notes: 'Affected DIR-600 (rev. Bx) hardware is end-of-life/end-of-service; vendor guidance is retirement and replacement. Firmware after 2.17b02 addressed the original issue only for supported revisions.' Packet vector names D-Link DIR-600 router (rev. Bx) with firmware before 2.17b02 and the endpoints hedwig.cgi, pigwidgeon.cgi and diagnostic.php. CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available true, CVSS 8.0, RWEP 77.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "There is no firmware a rev. Bx DIR-600 owner can move to, so on this entry remediation means removal and the interim measure has to be stated precisely, because the usual segmentation answer does not hold. The packet's path is a lure: an authenticated router administrator is drawn to a malicious page that auto-submits forged requests to hedwig.cgi, pigwidgeon.cgi and diagnostic.php to create an administrator account, enable remote management, or activate new configuration settings. The request therefore originates inside the administrator's own browser and arrives on an already-authenticated session, so blocking the router's admin surface at a network boundary does nothing — the browser is already on the permitted side, and the attacker never authenticates to the device at all. Applied to this router, the compensating measure is that the DIR-600 web administration surface must not be loadable from any network or browser profile an administrator also browses the general web from, that no administrator holds a live session to the router while browsing elsewhere, and that every surviving rev. Bx unit sits on a dated decommission schedule rather than an open-ended acceptance. Preconditions, and why this is a holding measure rather than a fix: none of it restores the missing request-origin validation, so any administrator who legitimately opens the router UI from a general-purpose browser satisfies the exploit's only access requirement in full; and disabling remote management is not durable protection here, because the packet lists enabling remote management as one of the actions the forged request itself performs — its value is limited to denying an external attacker a direct path, not to preventing the lure. Distinguishing test: from the workstation and browser profile an administrator actually uses, confirm the router's admin pages cannot be loaded in the same session context used for general web browsing, and read remote-management state off the device itself rather than from a configuration template, since the flaw's own effect is to change it.",
+        "evidence": "Packet attack_vector: 'An attacker lures an authenticated router administrator to a malicious page that auto-submits forged requests to hedwig.cgi/pigwidgeon.cgi/diagnostic.php, hijacking the admin session to create accounts, enable remote management, or change settings.' Packet vector enumerates the same actions, including enabling remote management via a crafted configuration module to hedwig.cgi and activating settings via a SETCFG,SAVE,ACTIVATE action to pigwidgeon.cgi; cwe_refs CWE-352. patch_available: false; live_patch_notes records rev. Bx as end-of-life/end-of-service with retirement and replacement as vendor guidance. CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-30040": {
     "name": "Microsoft Windows MSHTML Platform Security Feature Bypass Vulnerability",
@@ -44301,7 +45448,22 @@
         "adequate": false,
         "gap": "This was an actively exploited zero-day at patch release; any remediation cadence slower than the May 2024 Patch Tuesday left endpoints escalatable to SYSTEM during live QakBot campaigns."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows DWM Core Library and describes local code triggering a heap buffer overflow — an integer-division size miscalculation in CCommandBuffer::Initialize — to corrupt heap memory and reach SYSTEM. The attacker is already executing on the host, so nothing about this escalation consults an account model; a memory-safety boundary inside a shipped OS component is failing. For this CVE the control means the Windows update carrying the DWM Core Library fix is driven across every affected host on the clock that opened with the 2024-05-14 KEV listing rather than folded into the next monthly rollup, and that completion is measured per host against the installed build rather than by 'approved' or 'downloaded' in the management console. The packet makes the restart the load-bearing step and the specific way this remediation gets recorded wrongly: live_patch_available is false and live_patch_notes state the vendor update requires a reboot and is the remediation, so a host that has installed the update and not yet restarted is still running the vulnerable DWM Core Library and must be counted as exposed. On a general desktop estate the restart is the step users defer indefinitely, which is exactly how a patch dashboard reads compliant over a fleet that still carries the flaw. Priority follows the packet rather than the 7.8 base score: a public PoC, confirmed in-the-wild exploitation, and the packet's record that QakBot chained this after initial access make it the containment step in an intrusion chain, not a routine endpoint item — every host that has taken an initial-access stage already satisfies this flaw's only precondition, which is local code execution. Distinguishing test: join the fleet's patch state to each host's last boot time and confirm no host reports the fix installed with a boot time preceding the install; any host in that set is exposed while the compliance report is green. Precondition and limit: this is a remediation-window control and nothing more. It does not detect exploitation, and on a host where the chain already ran, the reboot removes the vulnerable code but not the SYSTEM-level access the attacker established through it — with exploitation confirmed and the packet naming a chain after initial access, a host with corroborating intrusion evidence belongs on the incident path in parallel with, not after, the update.",
+        "evidence": "Packet facts only. attack_vector: 'Local code triggers a heap buffer overflow in the DWM Core Library caused by an integer-division size miscalculation in CCommandBuffer::Initialize, corrupting heap memory to gain SYSTEM privileges; QakBot chained it after initial access.' vector: 'Windows DWM Core Library Elevation of Privilege Vulnerability'. CWE-122 and CWE-787; cisa_kev true, kev_date 2024-05-14; active_exploitation 'confirmed'; poc_available true; ai_discovered false; RWEP 79, CVSS 7.8. patch_available true; live_patch_available false; live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Cited as insufficient on this entry: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2, UK-CAF-B4.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-4671": {
     "name": "Google Chromium Visuals Use-After-Free Vulnerability",
@@ -44375,7 +45537,19 @@
         "adequate": false,
         "gap": "Password-only authentication is fully defeated once the reset email is redirected; without enforced MFA the identity control permits complete takeover, so it is inadequate against this flaw."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The exposure this SLA tier governs on GitLab is fully unauthenticated and needs no foothold to start: the attacker submits the password-reset form supplying multiple email addresses, GitLab delivers the reset link to the attacker-controlled unverified address, and the attacker sets a new password. There is no login step for a monthly patch window to hide behind and no credential to rate-limit — every self-managed instance on an affected release is reset-able by anyone who knows a target account's address, and the affected range spans seven 16.x lines (16.1 through 16.7). The packet records a vendor update with no live-patch primitive but explicitly no reboot requirement, which is what makes the expedited branch of this control real rather than aspirational here: moving an instance to the fixed release in its own 16.x line is a service upgrade, not a maintenance-window event, so a 14- or 30-day cadence is the wrong tier for a KEV-listed pre-authentication account-takeover path with a public exploit. Precondition on the residual half, and it is the part a patch record will not show: the packet ties completion of the takeover to 2FA being absent, so a second factor blocks the takeover but does not prevent the reset itself, and the upgrade bounds new attempts without undoing one that already succeeded — any account that could have been reset during the exposure window must have its password, personal access tokens and session state treated as attacker-known irrespective of the upgrade. Distinguishing test: on a staging instance running the operator's pre-upgrade version, submit the reset form for a known account with a second, attacker-controlled address and confirm no reset link reaches it; an attestation that 'GitLab is patched on the monthly cycle' passes cleanly while an affected 16.x instance stays reset-able for the whole cycle.",
+        "evidence": "Packet vector: 'An issue has been discovered in GitLab CE/EE affecting all versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.3 prior to 16.3.7, 16.4 prior to 16.4.5, 16.5 prior to 16.5.6, 16.6 prior to 16.6.4, and 16.7 prior to 16.7.2 in which user account password reset emails could be delivered to an unverified email address.' Packet attack_vector: unauthenticated attacker submits the reset form supplying multiple email addresses and takes over the account 'when 2FA is absent'; cwe_refs CWE-640. patch_available: true; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' CISA KEV-listed 2024-05-01, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 70.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-29988": {
     "name": "Microsoft SmartScreen Prompt Security Feature Bypass Vulnerability",
@@ -44472,7 +45646,30 @@
         "adequate": false,
         "gap": "Boundary controls leave the CrushFTP WebInterface publicly reachable, and the SSTI rides normal HTTPS so a firewall does not stop it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The CrushFTP WebInterface is the internet-facing half of a managed file-transfer deployment, and the packet's path asks nothing of the attacker but the ability to send it a request: server-side template-injection syntax is rendered by the server, escaping the VFS sandbox to read arbitrary files including configuration and session data, bypassing authentication to administrative access, and executing code. All versions before 10.7.1 and 11.1.0 on all platforms are affected, so the exposed population is every instance until it is moved. The packet records no live-patching primitive but explicitly no reboot requirement, which is what makes the expedited branch of this control real on this product: bringing an instance to 10.7.1 or 11.1.0 is a service upgrade rather than a maintenance-window event, so a 14- or 30-day tier is the wrong clock for a KEV-listed unauthenticated path to admin and code execution with a public exploit. Precondition, stated because this is where operators reach for the wrong lever: segmentation is not available as the interim measure on an externally published instance, since the WebInterface is reachable by design for the users the service exists to serve; where an instance serves only internal users, restricting which segments can reach it bounds who can send the injection but leaves it fully exploitable to anything inside the permitted segment, and it is unavailable wherever the interface must stay published for normal operation. Distinguishing test: enumerate the running version on every CrushFTP instance and confirm each is at or above 10.7.1 or 11.1.0; a vulnerability-management attestation that cites the organisation's standard patch cadence passes cleanly while a published pre-10.7.1 instance stays unauthenticated-RCE-able for the length of that cadence.",
+        "evidence": "Packet vector: 'A server side template injection vulnerability in CrushFTP in all versions before 10.7.1 and 11.1.0 on all platforms allows unauthenticated remote attackers to read files from the filesystem outside of the VFS Sandbox, bypass authentication to gain administrative access, and perform remote code execution on the server.' cwe_refs CWE-1336 and CWE-94. patch_available: true; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' CISA KEV-listed 2024-04-24, active_exploitation confirmed, poc_available true, CVSS 10, RWEP 72.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's own ordering is why upgrading CrushFTP is not the same as remediating it. Before the attacker reaches code execution they have already read files from outside the VFS sandbox — the attack_vector names configuration and session data specifically — and bypassed authentication to hold administrative access, all without a credential. Moving the instance to 10.7.1 or 11.1.0 removes the template-rendering path; it does not invalidate a session token or an administrative credential the attacker lifted out of the configuration, and it does not remove accounts, VFS definitions, scheduled jobs or files an admin-level attacker left on a server whose entire purpose is storing and moving other people's data. Bound to this product, the default response for any instance that ran an affected version while exposed is: treat the CrushFTP configuration and every secret in it as disclosed, rotate the administrative and service credentials and any keys the server held, invalidate all sessions, compare user and VFS definitions and scheduled jobs against a known-good baseline, and rebuild from that baseline rather than upgrade in place wherever the exposure window cannot be bounded from logs. Precondition and its hard limit: this bounds what the attacker retains going forward, and it does nothing about what already left — anything the sandbox escape could read is disclosed permanently, so rotating the credentials those files contained is the only recourse, and rotation is only complete if it covers credentials that were valid at any point in the window, not just the ones current at upgrade time. Distinguishing test: for each instance, produce evidence that the admin credential, service account and session keys were rotated after the upgrade and that user and VFS definitions were diffed against a baseline; a flaw-remediation record showing only 'upgraded to 11.1.0' is a patched host that may still be answering to its attacker.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends a request with server-side template-injection syntax to the CrushFTP WebInterface; the server renders the expression, escaping the VFS sandbox to read arbitrary files (config/session data), bypass authentication to gain admin, and execute code.' Packet vector confirms the same three outcomes for all versions before 10.7.1 and 11.1.0 on all platforms. active_exploitation: confirmed; CISA KEV-listed 2024-04-24; poc_available true; CVSS 10; RWEP 72. patch_available: true with live_patch_notes stating the vendor update (no reboot required) is the remediation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-20359": {
     "name": "Cisco ASA and FTD Privilege Escalation Vulnerability",
@@ -44546,7 +45743,40 @@
         "adequate": false,
         "gap": "SC-7 treats the firewall as the boundary, but the vulnerable web service runs on that same edge appliance, so the control cannot protect the device that enforces it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The vulnerable code sits in the management and VPN web servers of Cisco ASA and Cisco FTD — the appliance that is itself the trust boundary — and the packet's path needs no credential: an unauthenticated remote attacker sends a crafted HTTP request, incomplete error checking while parsing an HTTP header drives an infinite loop (CWE-835), and the device reloads. For this CVE the tier means the vendor update runs on a clock that opened at the 2024-04-24 KEV listing rather than being folded into the next appliance maintenance window, and completion is measured per unit by the reload the update requires having actually been taken: the packet records patch_available true with no live-patch path and states the vendor update requires a reboot, so an appliance staged with the fixed image but not yet reloaded is still running the vulnerable parser and must be counted as exposed. Precondition on the isolation half of this control, which is where it is usually over-claimed on ASA/FTD: restricting which networks can reach the management web server bounds one of the two surfaces the packet names, but the VPN web server has to answer unauthenticated requests from untrusted networks to do its job, so on any unit terminating remote-access VPN there is no segment that removes the path — isolation shrinks the management-side surface while the reload is scheduled, it is not an alternative to the update. Distinguishing test: produce, per appliance, the running image and the time of its last reload, and show the reload post-dates the update; a boundary-protection or flaw-remediation attestation that reads 'update deployed' off the management console records an appliance still running the vulnerable image as remediated.",
+        "evidence": "Packet fields: cisa_kev true, kev_date 2024-04-24, active_exploitation 'confirmed', cvss 8.6, rwep_score 57, poc_available false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Vector places the flaw in 'the management and VPN web servers for Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software', reachable by 'an unauthenticated, remote attacker', 'due to incomplete error checking when parsing an HTTP header', exploited 'by sending a crafted HTTP request to a targeted web server on a device'. cwe_refs CWE-835. Citing gaps include NIST-800-53-SC-7 Boundary Protection, NIST-800-53-SI-2 Flaw Remediation and AU-ISM-1546 Patch operating systems and applications.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at the denial of service: it records that in ArcaneDoor this flaw was chained with CVE-2024-20359 for implant persistence. That is what makes 'the appliance reloaded, we then updated it' the wrong close-out for an ASA or FTD that showed the documented behaviour during the exposure window — the update changes the running image, it does not answer whether anything was left behind on the box. For this CVE the control means such a unit is handled as a compromised device rather than a patch item: preserve and export its configuration for analysis, rebuild from vendor-supplied image plus a known-good configuration instead of upgrading in place, and rotate the secrets the appliance held (VPN key material, administrative credentials, certificates) along with any account that authenticated through it during the window. Precondition, stated plainly because this control is expensive if applied blindly: this is triage for units with evidence of the path, not a blanket estate rebuild. The packet gives no on-box indicator, only the unexpected reload as the visible symptom, so the trigger is an unexplained reload correlated with inbound requests to the management or VPN web server; a unit with no such record is an update item under the SLA tier. And the rebuild is only as trustworthy as its source — an image or configuration restored from the suspect device's own storage carries forward whatever was written there. Distinguishing test: take an appliance that reloaded during the exposure window, apply the vendor update, then ask what evidence exists that nothing persisted across it. A flaw-remediation attestation answers 'the image version is current', which is not an answer to implant persistence.",
+        "evidence": "Packet attack_vector: 'An unauthenticated remote attacker sends a crafted HTTP request to the ASA/FTD management or VPN web server; incomplete HTTP-header error checking triggers an infinite loop (CWE-835) that reloads the device, causing denial of service. In ArcaneDoor it was chained with CVE-2024-20359 for implant persistence.' active_exploitation 'confirmed'; cisa_kev true, kev_date 2024-04-24. patch_available true with live_patch_available false and live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gaps include NIST-800-53-SI-2 Flaw Remediation and UK-CAF-B4 System security.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The only symptom the packet gives is the device reloading unexpectedly, and the same packet places this flaw in a chain that ends in implant persistence on that same appliance — so the record that distinguishes a hardware fault from exploitation cannot be allowed to live only on the ASA or FTD itself. For this CVE the control means syslog and the management/VPN web servers' request and authentication records are forwarded continuously to a collector in a separate trust zone, with its own credentials and its own management path, retained across the appliance's reloads, so an analyst can ask after the fact whether a reload was preceded by requests to those web servers from an untrusted source. The detection keys on exactly what an exploit doing what the packet describes emits: an unauthenticated HTTP request to the management or VPN web server followed by an unscheduled reload of that device, and the repetition of that pair across attempts or across appliances — not on a crash signature, because the crash record is produced by the device under attack, and not on authentication events, because the attacker never authenticates. Precondition: this preserves and surfaces evidence, it does not prevent the reload and it is not a mitigation for the flaw. It is also only as good as the window it covers — an appliance whose forwarding was not already configured before the exposure window has no retrospective record to consult — and the collector must not authenticate back through the appliance it is monitoring, or the compromise of that appliance takes the evidence path with it.",
+        "evidence": "Packet vector: the flaw 'could allow an unauthenticated, remote attacker to cause the device to reload unexpectedly, resulting in a denial of service (DoS) condition', triggered 'by sending a crafted HTTP request to a targeted web server on a device'. attack_vector adds 'In ArcaneDoor it was chained with CVE-2024-20359 for implant persistence.' active_exploitation 'confirmed'; cisa_kev true, kev_date 2024-04-24; poc_available false. Citing gap NIS2-Art21-network-security (Security of network and information systems).",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2022-38028": {
     "name": "Microsoft Windows Print Spooler Privilege Escalation Vulnerability",
@@ -44694,7 +45924,40 @@
         "adequate": false,
         "gap": "No patch will ever ship — the devices are end-of-life — so flaw-remediation is unattainable; the only remediation is retirement, which asset-owners routinely fail to perform for cheap NAS boxes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "There is no update to apply here. The packet records patch_available false and states the vendor confirmed the product is end-of-life and that it should be retired and replaced, so for the DNS-320L, DNS-325, DNS-327L and DNS-340L units in service the remediation is removal on a dated schedule and nothing else — neither 'we will update it' nor an open-ended risk acceptance is an available disposition on a device whose exploit has been publicly disclosed and whose exploitation is confirmed. Applied to these NAS units: enumerate every one in service, give each a removal date, and settle the data migration target first, because the appliance exists to hold the data and pulling it without somewhere for the data to go is what converts a removal into an indefinite deferral. Precondition on the interim measure, which is where this gets over-claimed: until the unit is gone, restricting reachability of its HTTP interface bounds who can send the GET to /cgi-bin/nas_sharing.cgi, but it does not close the path — the credential ships inside the product, so every host still permitted to reach the device satisfies the attacker's only requirement. And because exploitation is confirmed and the exploit is public, a unit that was exposed to the internet through a router port-forward or UPnP mapping at any point in the exposure window has to be handled as already reached: the data it stored and any credentials it held are exposed regardless of what happens to the hardware afterwards, so removal alone does not close that half. Distinguishing test: for each unit produce a decommission date and the migration target. A vulnerability-management record that carries these models as 'no patch available, risk accepted' with no removal date is exactly the outcome this control exists to catch.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes 'No patch — affected D-Link NAS models are end-of-life/end-of-service; vendor guidance is to retire and replace the hardware.' Vector: '** UNSUPPORTED WHEN ASSIGNED ** ... D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403 ... /cgi-bin/nas_sharing.cgi of the component HTTP GET Request Handler ... The exploit has been disclosed to the public and may be used ... NOTE: This vulnerability only affects products that are no longer supported by the maintainer. NOTE: Vendor was contacted early and confirmed immediately that the product is end-of-life. It should be retired and replaced.' cisa_kev true, kev_date 2024-04-11, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 81. Citing gaps include AU-Essential-8-Patch, NIST-800-53-SI-2 Flaw Remediation and NIS2-Art21-vulnerability-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "These are network-attached storage appliances whose purpose is holding the primary and backup copy of a household's, remote worker's or branch site's files, and the packet's path reaches that data with no credential at all: an HTTP GET to /cgi-bin/nas_sharing.cgi with the argument user set to messagebus, which — chained with the companion command-injection flaw the packet names — yields unauthenticated remote code execution on the box holding the data. Since the packet records no available fix, reachability is the only lever the operator holds while the units are still in service. For the DNS-320L, DNS-325, DNS-327L and DNS-340L that means the device's web interface answers only from an operator subnet or an authenticated VPN: not from the general user VLAN, and above all not from the internet through a router port-forward or a UPnP mapping, which is how NAS hardware at homes, remote-worker locations and small branches normally acquires its exposure. Constrain the appliance's outbound path too, so a unit that has already been reached cannot ship what it stores to an arbitrary destination. Precondition: this bounds the population that can send the request; it does not remove the flaw and must not be recorded as closure. Any host inside the permitted segment still meets the attacker's only requirement, because the credential travels with the product rather than being obtained from the site — and it does nothing for a unit already reached during the exposure window. Distinguishing test: from a general user VLAN and from an external address, request /cgi-bin/nas_sharing.cgi on the unit; anything that answers is within reach of the published exploit. 'The NAS is on the internal network' is a claim about topology, not a demonstration that the interface is unreachable from untrusted segments.",
+        "evidence": "Packet attack_vector: 'An attacker sends an HTTP GET to /cgi-bin/nas_sharing.cgi using the hardcoded messagebus account (empty password); chained with the companion command-injection flaw this yields unauthenticated remote code execution on end-of-life D-Link NAS devices.' Vector names D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403, the /cgi-bin/nas_sharing.cgi HTTP GET Request Handler, and states 'The attack may be initiated remotely.' patch_available false; live_patch_notes 'No patch — affected D-Link NAS models are end-of-life/end-of-service; vendor guidance is to retire and replace the hardware.' poc_available true; active_exploitation 'confirmed'. Citing gap NIST-800-53-SC-7 Boundary Protection.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The secret in this CVE ships inside the product: the packet's manipulation is the argument user set to messagebus, a hard-coded account with an empty password in the device's HTTP GET request handler (CWE-798). No operator-side credential hygiene touches that exposure — the attacker never uses an account the site created, and there is nothing for the operator to rotate away. That is precisely why the identity-and-access and least-functionality gaps sit on this entry: an attestation showing every NAS administrator holds a unique, strong credential passes cleanly while this path stays fully open, and the vulnerable handler is not a service the operator can turn off on the device. For this estate the control means inventorying devices by whether they authenticate through a vendor-shipped credential the operator cannot change or remove, flagging the DNS-320L, DNS-325, DNS-327L and DNS-340L population on that basis rather than on account policy, and re-running the check after any unit is factory-reset, re-imaged or re-attached to the network — those are the operations that quietly return a device thought to be gone to service. Precondition: because the packet records no fix and vendor guidance is retirement, this detection feeds the decommission decision; it does not reduce the exposure of a unit that stays in service, and it says nothing about whether a unit was already used. A device reachable during the exposure window needs the data it stored and any credentials it held treated as exposed, not closed out on an inventory entry. Scope stays on the four models the packet names — extend it to other storage products only where a verified source places the same shipped credential in them.",
+        "evidence": "Packet cwe_refs CWE-798 (name: 'D-Link Multiple NAS Devices Use of Hard-Coded Credentials Vulnerability'). Vector: 'The manipulation of the argument user with the input messagebus leads to hard-coded credentials', in '/cgi-bin/nas_sharing.cgi of the component HTTP GET Request Handler', affecting 'D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403'. attack_vector notes the hardcoded 'messagebus' account has an empty password. patch_available false; vendor guidance per live_patch_notes is to 'retire and replace the hardware'. Citing gaps include UK-CAF-B2 Identity and access control, NIST-800-53-CM-7 Least Functionality and ISO-27001-2022-A.8.9 Configuration management.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9"
+        ]
+      }
+    ]
   },
   "CVE-2024-29748": {
     "name": "Android Pixel Privilege Escalation Vulnerability (CVE-2024-29748)",
@@ -44731,7 +45994,31 @@
         "adequate": false,
         "gap": "Patch-application timeframes do not account for mobile-OS/firmware, where forensic-extraction exploitation of an unpatched wipe bypass is the real risk."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet gives a vendor update for the affected Pixel devices with no live-patch path and a required reboot, and an exploitation precondition of local or physical access plus user interaction — so the population that matters is handsets in people's hands, and the enforcement point has to be the device's reported security patch level acting as an access condition rather than a row on a compliance report. For this CVE that means the enrolled Pixel fleet is gated: a device below the fixed patch level is denied mail, VPN and document access until it is at or above it, and the check reads the level the device reports after it has restarted, because the packet records the update as requiring a reboot — a handset that has taken the update but not restarted is still running the vulnerable logic and has to count as exposed. Precondition, and for this flaw it is the load-bearing one: the control governs what a below-fix device is allowed to reach; it does nothing about the data already resident on that device, and the attacker the packet describes already has local or physical access to the handset, which is past the point where an access policy applies at all. That case belongs on the incident path — server-side revocation of the device's sessions, tokens and credentials — not on the patch-compliance path. Distinguishing test: enrol a Pixel pinned below the fixed patch level and confirm the policy actually denies it access to protected resources. An estate that surfaces the stale patch level on a dashboard while the device keeps its access has recorded the exposure rather than removed it.",
+        "evidence": "Packet: name 'Android Pixel Privilege Escalation Vulnerability'; cisa_kev true, kev_date 2024-04-04, active_exploitation 'confirmed'; cvss 7.8, rwep_score 53, poc_available false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Vector: 'This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.' attack_vector: 'An attacker with local/physical access interrupts a factory reset initiated by a device-admin app...'. Citing gaps include AU-Essential-8-Patch, NIST-800-53-SI-2 Flaw Remediation, ISO-27001-2022-A.8.8 and NIS2-Art21-patch-management. The packet names no fixed build identifier, so none is asserted here.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "What fails in this CVE is a protection mechanism rather than a general-purpose code path: the packet describes an attacker with local or physical access interrupting a factory reset initiated by a device-admin app so that the wipe does not complete, yielding local privilege escalation and defeating the remote-wipe and data-protection assurance an estate leans on for lost, stolen and returned Pixel handsets. For this CVE the control means the wipe primitive itself is regression-tested rather than assumed from the presence of the vendor update: on a representative Pixel at the current patch level, issue the device-admin wipe, interrupt it in the way the packet describes, and verify the handset came back with the data actually gone and the escalation unavailable — then re-run that battery on each subsequent platform update, since a condition-handling logic error of this shape (CWE-755 with CWE-280) is the kind a later change in the same path reintroduces. The signal to watch for in the fleet is the behaviour the packet documents, not a proxy for it: a wipe that was commanded but never reached a completed state, and a device that reappears after a commanded wipe still carrying its prior enrolment, identity or data. Precondition: this test tells you whether the assurance holds; it does not remediate a handset, and it is a check on the mechanism, not a substitute for the vendor update and the restart it requires. A device that has already had an interrupted wipe is an incident rather than a test result — the data was not removed, so it and any credentials the device held must be handled as exposed and revoked server-side.",
+        "evidence": "Packet cwe_refs CWE-755 and CWE-280. attack_vector: 'An attacker with local/physical access interrupts a factory reset initiated by a device-admin app, exploiting a logic error so the wipe does not complete, and gains local privilege escalation — defeating remote-wipe/data-protection assurances.' Vector: 'there is a possible way to bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.' cisa_kev true, kev_date 2024-04-04, active_exploitation 'confirmed'. patch_available true with live_patch_available false and live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gaps include UK-CAF-B4 System security and ISO-27001-2022-A.8.8.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-29745": {
     "name": "Android Pixel Information Disclosure Vulnerability",
@@ -44768,7 +46055,31 @@
         "adequate": false,
         "gap": "Security-of-processing controls assume lock-screen protection preserves data confidentiality; the fastboot memory leak undermines confidentiality of personal data on a seized device despite a locked screen."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The population is Google Pixel devices, and the packet's path needs no code running on the device at all: with physical possession of a Pixel in the After-First-Unlock state, the attacker reboots it into fastboot mode — where USB access is enabled before memory is zeroed — and dumps the uninitialized memory to recover data the lock screen would otherwise protect. Bound to this product, the control means the fixed Android build has to function as an access condition rather than a reporting field: a Pixel below it is denied the organizational mail, VPN and document access that puts protected data onto the device in the first place. The measurement must be the build actually running, because the packet records no live-patching primitive and states the vendor update requires a reboot to be the remediation — a Pixel that has taken the update but not restarted is still running the vulnerable boot path and must be counted below the fix. Distinguishing test: enrol a Pixel pinned below the fixed build and confirm policy actually denies it access to protected resources; an estate that surfaces the stale build on a compliance report while the device keeps its mailbox has recorded the exposure, not reduced it. Precondition, and it decides how far this control reaches: gating access limits what a below-fix Pixel is permitted to hold from this point forward — it does not reach data already resident on the device, and it does nothing once the device is in someone else's hands. Because the packet's path requires only physical possession, with no additional execution privileges and no user interaction, a Pixel that is lost, stolen or seized while below the fixed build belongs on the device-loss and personal-data-exposure path — the assessment the cited security-of-processing obligation drives — and not on the patch queue.",
+        "evidence": "Packet: 'Android Pixel Information Disclosure Vulnerability', CWE-908, with the vector recording 'a possible Information Disclosure due to uninitialized data... local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.' The attack path recorded is: 'With physical possession of a Pixel in the After-First-Unlock state, an attacker reboots it into fastboot mode where USB access is enabled before memory is zeroed, then dumps uninitialized fastboot memory to recover data that the lock screen would otherwise protect.' CISA KEV-listed 2024-04-04, active_exploitation confirmed, poc_available false, CVSS 5.5, RWEP 47. patch_available true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Cited as insufficient on this entry: ISO/IEC 27001:2022 A.8.8 (management of technical vulnerabilities), UK CAF B4 (system security), GDPR Art. 32 (security of processing).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "GDPR-Art32"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For the Pixel estate, the update carrying this fix is driven from the management platform on the clock that opened with the 2024-04-04 KEV listing, rather than left to each user's own update prompt. Completion is measured per device as installed security patch level and completed restart together, because the packet records no live-patching primitive for this product and states the vendor update requires a reboot to be the remediation — the read the attacker performs happens in the boot path that only the restart replaces, so a device counted as updated but not restarted is still exposed. Deferred restarts are therefore the specific way this remediation goes wrong on a phone estate: the download is invisible to the user and the restart is not, so it is the half that slips. Preconditions: an enforced SLA only governs devices that check in, so a Pixel that is unenrolled, offline or long out of contact never receives the push and has to be measured against enrollment and last-check-in rather than assumed compliant. And because the path the packet describes is exercised with physical possession rather than network reach, the SLA shortens the exposure window but does not defend a device inside it — a Pixel that goes missing during the window is not made safe by an update that lands afterwards, and that device is an incident, not a pending patch.",
+        "evidence": "Packet: CISA KEV-listed 2024-04-04 with active_exploitation confirmed; CVSS 5.5, RWEP 47, poc_available false. patch_available true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' The recorded path requires physical possession of a Pixel in the After-First-Unlock state and a reboot into fastboot mode, and the vector states no additional execution privileges are needed and no user interaction is required. Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', NIST SP 800-53 Rev 5 SI-2 (flaw remediation), EU NIS2 Art. 21 vulnerability handling and disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-24955": {
     "name": "Microsoft SharePoint Server Code Injection Vulnerability",
@@ -44973,7 +46284,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management as an annual/periodic control does not compel the network segmentation that would keep an unauthenticated attacker off the TeamCity admin surface."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "TeamCity takes its authentication decision in the layer that routes requests, and this CVE is that layer failing open: the packet has an unauthenticated request to a bogus path carrying a jsp= parameter that points at an authenticated REST endpoint, after which the attacker performs admin actions. Bound to this product, the control means each administrative REST function on the TeamCity server — account creation, token issuance, plugin upload — authorizes its caller itself rather than inheriting a verdict from the path-matching filter in front of it, and the server's HTTP surface is segmented so an untrusted caller cannot present that request to the filter in the first place. Distinguishing test: against a staging TeamCity server, issue unauthenticated requests to a non-existent path carrying a jsp= parameter that names an administrative REST endpoint, and confirm each is refused before the function runs — an attestation that every TeamCity administrator authenticates at login passes cleanly while this path stays open, because the attacker never holds an account and the account model is bypassed rather than abused. Preconditions: per-function authorization is a property the vendor fixed release establishes; this control states what to verify, it does not implement it, and the packet records no live-patch mechanism. Until that release is applied, restricting which segments reach the server bounds who can send the request but leaves it exploitable from anywhere inside the permitted segment, and that lever is unavailable where the server's HTTP surface must stay reachable for normal build operation. Because exploitation is confirmed and the packet's path ends in an attacker-created admin account or token and an uploaded plugin, a server reachable during the exposure window must be audited for administrators, tokens and plugins it did not legitimately gain — applying the fixed release does not remove them.",
+        "evidence": "Packet attack_vector: 'An unauthenticated request to a bogus path with a jsp= parameter pointing at an authenticated REST endpoint bypasses auth; the attacker then creates an admin account/token and uploads a malicious plugin to achieve RCE on the build server.' Vector: 'In JetBrains TeamCity before 2023.11.4 authentication bypass allowing to perform admin actions was possible.' cwe_refs CWE-288; cisa_kev true with kev_date 2024-03-07; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 71. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet pairs a 2024-03-07 KEV listing with a public PoC and an unauthenticated path to admin actions, so for this product the exposure window has to be measured in hours from the listing rather than in the cycle a build server usually gets. The mismatch is the point: a TeamCity server is normally inventoried as internal developer tooling and patched on a cadence that assumes an account is needed to reach anything sensitive, while the packet's path needs no account at all and ends in RCE on the build server. Bound to this entry, the clock runs from the KEV listing to the vendor fixed release being live on the server — the packet records no live-patch mechanism, so there is no partial state to claim against it, and a server past the clock is fully exposed to a documented, publicly available exploit path.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-03-07, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 71; attack_vector ends in 'RCE on the build server'. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-23225": {
     "name": "Apple Multiple Products Memory Corruption Vulnerability",
@@ -45765,7 +47099,30 @@
         "adequate": false,
         "gap": "System-security assurance assumes the browser sandbox holds; a renderer type-confusion with sandbox escape defeats that assumption without additional exploit-mitigation controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's exploitation path is a victim loading an attacker-controlled page, so every hour a managed endpoint keeps browsing on a Chrome build below 116.0.5845.179 is an hour that path stays open, and the packet records no live-patch mechanism — applying the vendor fixed release is the only thing that closes it. Bound to this deployment, the control means the browser's security channel is exempt from the pilot/broad ring staging that enterprise update policy applies to feature updates, and that completion is measured by the version the browser itself reports on each endpoint rather than by an 'approved' or 'downloaded' state in the management console. Distinguishing test: enumerate the Chrome version actually running across managed endpoints and confirm none report below 116.0.5845.179 — a ring policy that reports the update as deployed while endpoints still report a pre-fix build leaves the vulnerable V8 in the renderer that parses attacker-supplied HTML, with a clean patch-compliance row. Precondition: the ring reaches only Chrome installs the management channel can see and update. A user-installed copy outside that channel takes no ring policy at all, so it is remediated by bringing it under management or removing it, not by recording the fleet as patched.",
+        "evidence": "Packet vector: 'Type Confusion in V8 in Google Chrome prior to 116.0.5845.179 allowed a remote attacker to execute arbitrary code via a crafted HTML page.' attack_vector: a victim visits an attacker-controlled web page and malicious JavaScript drives the V8 type confusion, yielding code execution inside the renderer. cwe_refs CWE-843; cisa_kev true with kev_date 2024-02-06; active_exploitation confirmed. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock is the load-bearing half. The packet records no public PoC alongside confirmed in-the-wild exploitation, so an estate that prioritises by CVSS band alone files an 8.8 browser bug into the routine desktop-software cycle while it is actually being exploited — and the packet's RWEP of 55 sitting below the CVSS band is exactly the reading that invites the deferral. Bound to this product, the control means Chrome carries the same KEV-driven remediation clock an internet-facing server would: the vendor fixed release is available per the packet, so the deadline runs from the 2024-02-06 KEV listing rather than from the next scheduled application-update window. Because the packet registers no live-patch mechanism and no vendor mitigation rule, there is no intermediate state an operator can claim against that clock — an endpoint is either running the fixed release or fully exposed to the crafted-HTML path, and the clock has to be measured against the former.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-02-06, active_exploitation confirmed, poc_available false, CVSS 8.8, RWEP 55, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2022-48618": {
     "name": "Apple Multiple Products Memory Corruption Vulnerability",
@@ -45970,7 +47327,31 @@
         "adequate": false,
         "gap": "System-security assurance for the application does not mandate WAF/virtual-patching that would blunt the OGNL-injection request pattern before the vendor fix is applied."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Confluence Data Center and Server on an affected older version is the asset, and the packet describes what an operator inherits after exploitation rather than only the defect: an unauthenticated POST to /template/aui/text-inline.vm carrying an OGNL expression is evaluated server-side and executes arbitrary OS commands, which the packet records as being used to drop miners, C2 implants or webshells. Those payloads do not live in the vulnerable template path, so applying the vendor fixed release removes the injection point and leaves them running. Bound to this product, the control means an instance that was reachable by an unauthenticated caller while on an affected version is handled as a suspected compromise: rebuilt from a known-good baseline instead of upgraded in place, with the credentials and integration tokens the instance held rotated, since arbitrary OS command execution runs with the Confluence process's access to them. Precondition, and this is where the runbook is habitually under-triggered: the trigger is unauthenticated reachability during the exposure window, not an observed webshell — the packet records a public PoC and confirmed in-the-wild exploitation, and an implant that survives an in-place upgrade also outlives the logs that would have shown its arrival, so 'we found nothing' is not the same evidence as 'nothing happened'. Distinguishing test: take an instance recorded as remediated and ask what was done besides the version change. An upgrade ticket closed against the KEV listing satisfies every patch-management attestation cited on this entry while a webshell dropped before the upgrade still answers.",
+        "evidence": "Packet: 'Atlassian Confluence Data Center and Server Template Injection Vulnerability', CWE-74, with the recorded path 'An unauthenticated attacker sends a POST to /template/aui/text-inline.vm containing an OGNL expression; Confluence evaluates the template server-side, executing arbitrary OS commands that are used to drop miners, C2 implants or webshells.' The vector states the flaw 'allows an unauthenticated attacker to achieve RCE on an affected instance' and that 'Customers using an affected version must take immediate action.' CISA KEV-listed 2024-01-24, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 75. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' Cited as insufficient on this entry: NIST SP 800-53 Rev 5 SI-2 (flaw remediation), ISO/IEC 27001:2022 A.8.8, EU DORA Art. 9 (ICT risk management framework).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock attaches to the asset the packet names — Confluence Data Center and Server instances on an affected older version — and runs from the 2024-01-24 KEV listing. There is no privilege, account or user-interaction precondition between an attacker and the sink: the packet's path is a single unauthenticated POST to /template/aui/text-inline.vm, so for any instance an unauthenticated caller can reach, the interval between listing and upgrade is the whole of the control. The packet records a vendor fixed release with no live-patch mechanism, which makes the upgrade the only clock-stopping action — there is no rule to deploy in the meantime and none should be recorded as one. Completion has to be measured as the version actually serving requests on each instance, not a change ticket raised, because the packet's own vector says recent supported versions are unaffected as the flaw was mitigated during regular version updates: that makes 'we are on a supported version' a per-instance claim to verify, and the routine multi-week remediation window the cited patch controls sanction is the specific thing that fails against a KEV-listed unauthenticated RCE with a public PoC. Precondition: an accelerated SLA bounds the window going forward and does nothing for the instances that were already reachable before it started — those belong on the compromise-assumption path above, not on this one. Distinguishing test: pick an instance recorded as compliant and query the version it is actually serving, rather than reading the version field the inventory carries.",
+        "evidence": "Packet: CISA KEV-listed 2024-01-24 with active_exploitation confirmed; CVSS 9.8, RWEP 75, poc_available true. Vector: 'A template injection vulnerability on older versions of Confluence Data Center and Server allows an unauthenticated attacker to achieve RCE on an affected instance. Customers using an affected version must take immediate action... Most recent supported versions of Confluence Data Center and Server are not affected by this vulnerability as it was ultimately mitigated during regular version updates.' Recorded path: an unauthenticated POST to /template/aui/text-inline.vm containing an OGNL expression. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', EU NIS2 Art. 21 vulnerability handling and disclosure, UK CAF B4 (system security).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-23222": {
     "name": "Apple Multiple Products WebKit Type Confusion Vulnerability (CVE-2024-23222)",
@@ -46255,7 +47636,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management as written does not elevate a KEV-listed, actively-exploited appliance flaw above routine CVEs, so it under-prioritises the emergency reboot window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A NetScaler ADC or Gateway configured as a Gateway or AAA virtual server is the remote-access trust boundary itself, and the packet's requests arrive at that boundary with no authentication, crash the packet engine and can read adjacent memory. The tier the frameworks lack is what applies here: remediation measured from the 2024-01-17 KEV listing rather than from the next appliance maintenance window, and completion measured per appliance rather than per version approved in a change record. The packet's own precondition scopes the work — the flaw is reached on an appliance configured as a Gateway or AAA virtual server, so the enumeration that gates remediation is which units carry that configuration, not how many NetScaler units exist. That distinction also determines whether the control's isolation half is available at all: where a unit carries an unused Gateway or AAA virtual server, removing that vserver removes the reachable path; where the vserver is in service, isolation is not a lever, because it is published to untrusted networks by design, and the fixed release is then the only remediation. State that plainly rather than recording 'restrict access to the management interface' as the interim mitigation — the exploited surface here is the user-facing remote-access vserver, not the management plane. The packet records no live-patch mechanism and states remediation requires applying the fixed release and rebooting, so an appliance that has taken the release without the reboot still runs the vulnerable code and must be counted as exposed. Distinguishing test: produce, per appliance, whether a Gateway or AAA virtual server is configured and the build actually running since its last restart; a fleet-wide change record showing the fixed release approved, against an appliance still serving on a pre-fix build, is a paper close.",
+        "evidence": "Packet: CISA KEV-listed 2024-01-17, active_exploitation confirmed, CVSS 7.5, RWEP 60, poc_available false. Vector: 'Improper Restriction of Operations within the Bounds of a Memory Buffer in NetScaler ADC and NetScaler Gateway allows Unauthenticated Denial of Service and Out-Of-Bounds Memory Read'. attack_vector: 'An unauthenticated attacker sends crafted requests to a NetScaler appliance configured as a Gateway or AAA virtual server, triggering an out-of-bounds memory operation that crashes the packet engine (denial of service) and can leak adjacent memory.' patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "What this exploitation emits is documented in the packet: unauthenticated requests to a Gateway or AAA virtual server, followed by packet-engine crashes, with adjacent memory read out. A packet-engine crash on its own is indistinguishable from a fault; it becomes evidence only when it can be correlated with the unauthenticated request that preceded it, and that correlation needs both records — the vserver access record and the crash/restart record — side by side. The appliance is the component failing, so its own storage is the least dependable place to hold them. For this device the control means NetScaler syslog together with the Gateway and AAA vserver access records forwarding to a SIEM in a separate trust zone with its own management plane and credentials, retained across the window between the 2024-01-17 KEV listing and the completion of the reboot each appliance requires. Precondition, stated rather than implied: this is a detection-and-evidence control, not a mitigation — it does not prevent the out-of-bounds read or the crash, it does not reduce the exposure of a unit serving a Gateway vserver, and it must never be the reason an appliance's fixed release and reboot are deferred. It also depends on the forwarding path being up: while the packet engine is down the stream stops, so a gap in the stream that brackets a restart is itself the signal to investigate, not an absence of one, and the collector has to alarm on an appliance that goes quiet rather than only on the events it sends.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends crafted requests to a NetScaler appliance configured as a Gateway or AAA virtual server, triggering an out-of-bounds memory operation that crashes the packet engine (denial of service) and can leak adjacent memory.' CISA KEV-listed 2024-01-17, active_exploitation confirmed, poc_available false, CVSS 7.5, RWEP 60. live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting' — the reboot is what bounds the window this retention has to cover. Citing gaps include UK-CAF-B4 (System security) and NIS2-Art21-network-security, neither of which requires appliance data-plane events to be retained off the appliance.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2023-6548": {
     "name": "Citrix NetScaler ADC and NetScaler Gateway Code Injection Vulnerability",
@@ -46438,7 +47842,39 @@
         "adequate": false,
         "gap": "Technical-vulnerability management did not prioritise a critical, PoC-available SharePoint auth bypass ahead of its ransomware weaponization."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "SharePoint Server's token validation is where the product makes its authentication decision, and this CVE is that decision failing open: the packet has an unauthenticated attacker presenting a spoofed JWT whose signature is not properly validated, being granted administrator context, and then chaining CVE-2023-24955 code injection to reach remote code execution. Bound to this product, the control means each administrative function on the server establishes its caller's authority itself — the identity a token asserts is only usable once the signature and issuer behind it have been validated at the point the privileged function runs — instead of inheriting an 'administrator' verdict settled once at the front door; and that the server's administrative surface is segmented so an untrusted caller cannot present that token to it at all. This is precisely why the identity and authentication controls cited as insufficient here never engage: the attacker holds no SharePoint account, so nothing in the account model is misused, no credential is guessed and no second factor is ever requested — an authentication-assurance attestation and an identity-and-access review both pass cleanly while an unauthenticated caller sits in administrator context. Distinguishing test: from a segment with no operational need to reach the SharePoint administrative surface, send a staging instance requests bearing a well-formed but invalidly-signed token and confirm each privileged function refuses before it executes; confirming that every named SharePoint administrator authenticates with MFA tests nothing on this path. Precondition: the signature-validation repair is the vendor's, and the packet records a fixed release with no live-patch mechanism that requires a reboot — this control names the property to verify and the segmentation that bounds who can attempt the forgery, it does not implement the fix. Segmentation limits the caller population and closes nothing for anything already inside the permitted segment.",
+        "evidence": "Packet: 'Microsoft SharePoint Server Privilege Escalation Vulnerability', CWE-303, vector 'Microsoft SharePoint Server Elevation of Privilege Vulnerability'. Recorded path: 'An unauthenticated attacker presents a spoofed JWT whose signature is not properly validated by SharePoint, is granted administrator context, and can then chain CVE-2023-24955 code injection to reach remote code execution.' CISA KEV-listed 2024-01-10, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 78. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Cited as insufficient on this entry: NIST SP 800-63B Rev 4 (authentication and lifecycle management, AAL/IAL/FAL) and UK CAF B2 (identity and access control).",
+        "gap_closes": [
+          "NIST-800-63B-rev4",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock runs from the 2024-01-10 KEV listing across every SharePoint Server on an affected build, and completion is measured per server as the running build plus a completed restart — the packet records no live-patch mechanism and states remediation requires applying the fixed release and rebooting, so a server that installed the update and has not restarted still runs the vulnerable code and has to be counted as exposed. On a collaboration server that users are working in through the day, that restart is the step most likely to be deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Priority follows what the packet records rather than the maintenance calendar: a public PoC, confirmed in-the-wild exploitation, and an unauthenticated caller reaching administrator context with a documented chain onward into code execution, which is not a monthly-rollup item. Precondition: the SLA governs the window from listing forward and settles nothing about servers that were already reachable by an unauthenticated caller on an affected build — the packet's chain terminates in remote code execution, so those servers are a triage question, not a patching one, and closing them on the update ticket is what the compromise-assumption control below exists to prevent.",
+        "evidence": "Packet: CISA KEV-listed 2024-01-10 with active_exploitation confirmed; CVSS 9.8, RWEP 78, poc_available true. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Recorded path: an unauthenticated attacker presents a spoofed JWT whose signature is not properly validated, is granted administrator context, and can chain CVE-2023-24955 code injection to reach remote code execution. Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8, EU NIS2 Art. 21 vulnerability handling and disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's chain does not stop at elevated privilege — it terminates in remote code execution through CVE-2023-24955, with exploitation confirmed and a PoC public. Applying the fixed release settles the signature-validation defect; it does not answer whether an unauthenticated caller already reached administrator context on that server, and whatever followed does not live in the code the update replaces, so it survives the update and the reboot. Bound to this product, the control means a SharePoint Server that was reachable by an unauthenticated caller while on an affected build is triaged as a suspected compromise rather than closed on the patch ticket: server content and configuration compared against a known-good baseline, and the credentials and secrets the server held rotated, because the chain's recorded end state is code execution on that server. Precondition and honest limit: the packet records the end state as remote code execution and does not record what an attacker left behind, so the trigger for this runbook is unauthenticated reachability during the exposure window — not an observed implant, which is exactly the evidence a server with code execution on it is in a position to remove. The rebuild half also has an ordering constraint worth stating: if the triage is skipped now and the question is reopened later, a rebuild taken from a baseline that was already modified reproduces the modification rather than removing it.",
+        "evidence": "Packet: recorded path is 'An unauthenticated attacker presents a spoofed JWT whose signature is not properly validated by SharePoint, is granted administrator context, and can then chain CVE-2023-24955 code injection to reach remote code execution.' CISA KEV-listed 2024-01-10, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 78. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The packet records no implant, tooling or post-exploitation artifact for this entry — the chain's stated end state is remote code execution. Cited as insufficient on this entry: EU NIS2 Art. 21 vulnerability handling and disclosure.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-46805": {
     "name": "Ivanti Connect Secure and Policy Secure Authentication Bypass Vulnerability",
@@ -47351,7 +48787,31 @@
         "adequate": false,
         "gap": "Technical vulnerability management closed the first advisory but not the request-smuggling primitive the incomplete fix left reachable until the follow-up patch."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Qlik Sense Enterprise for Windows terminates the raw HTTP request in a front tier and hands work to the backend server hosting the repository application, and this CVE is that split failing: the packet describes an attacker tunneling an HTTP request inside the raw HTTP request so the backend executes it, under the service account, with elevated privilege. The inner request never passes the front tier's authorization decision, so the backend acts on a caller nothing authorized. Bound to this product, the control means the repository application's privileged operations authorize their own caller rather than inheriting a verdict from the tier that fronts them, and the Qlik front-end surface answers only from segments with an operational need to reach it, so an untrusted caller cannot present a raw request to that tier at all. The least-privilege gap recorded against this entry does not close this path: the tunneled request runs under the Qlik service account, and chained with the CVE-2023-41266 anonymous-session flaw the packet names, the attacker holds no Qlik account, so per-user privilege scoping is never consulted and an AC-6 attestation passes cleanly while the path stays open. Distinguishing test: from a segment with no business need to reach the analytics platform, send a staging deployment a raw request carrying a second, tunneled request aimed at a privileged repository endpoint and confirm the backend refuses it before the operation runs, rather than relying on the front tier having stripped it. Precondition: consistent request parsing between the two tiers is a property the vendor fixed release establishes — this control states what to verify and where to segment, it does not repair the parser. Until the fixed build is in place, restricting reachability bounds who can send the raw request but leaves the tunneling path fully exploitable to anything inside the permitted segment, and it is unavailable where the deployment must serve a broad user population.",
+        "evidence": "Packet: CWE-444; an HTTP Request Tunneling flaw in Qlik Sense Enterprise for Windows allowing a remote attacker to elevate privilege by tunneling HTTP requests in the raw HTTP request, sending requests that get executed by the backend server hosting the repository application. The packet's attack path adds that execution occurs under the service account and that, combined with the CVE-2023-41266 anonymous session, it yields unauthenticated remote code execution. CISA KEV-listed 2023-12-07, active_exploitation confirmed, poc_available true, RWEP 70 against CVSS 9.9.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet names five maintenance tracks with a different fixed build on each — August 2023 IR, May 2023 Patch 4, February 2023 Patch 8, November 2022 Patch 11, August 2022 Patch 13 — so on this CVE the SLA's failure mode is a mis-measured deadline rather than a missed one. A server sitting on November 2022 Patch 10 is current by its own track's reckoning and still carries the tunneling path. Applied here, the remediation clock opened by the 2023-12-07 KEV listing is measured per deployment against the fixed build named for that deployment's own track, not against whether the deployment is up to date within its track. The packet records a vendor fixed release and no live-patch mechanism, so nothing closes this without taking each deployment through the update; during that window the compensating half of the control is restricting who can reach the Qlik front end, which bounds the attacker population and does not close the flaw. Distinguishing test: produce, per Qlik Sense Enterprise deployment, its maintenance track and its installed build, and compare each against the fixed build named for that track — an estate whose patch report shows every server current has not answered this question. And because active exploitation is confirmed and the packet has the tunneled request executing under the service account, a deployment reachable during the exposure window is not remediated by the update alone: the update closes the path but removes nothing already done through it, so such a server needs forensic triage and service-account credential rotation rather than being closed on the patch.",
+        "evidence": "Packet: affected versions are May 2023 Patch 3 and earlier, February 2023 Patch 7 and earlier, November 2022 Patch 10 and earlier, and August 2022 Patch 12 and earlier; the fix is recorded as August 2023 IR, May 2023 Patch 4, February 2023 Patch 8, November 2022 Patch 11, and August 2022 Patch 13. CISA KEV-listed 2023-12-07, active_exploitation confirmed, poc_available true, RWEP 70 against CVSS 9.9. patch_available true, live_patch_available false, live_patch_notes: no vendor live-patch mechanism, remediation requires applying the vendor fixed release. The packet's attack path records execution under the service account.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-33107": {
     "name": "Qualcomm Multiple Chipsets Integer Overflow Vulnerability",
@@ -47489,7 +48949,30 @@
         "adequate": false,
         "gap": "Technical vulnerability management presumes an available remediation path, but here it is gated behind OEM firmware rebuilds, leaving a long unremediable exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's trigger is a local, low-privileged Android app submitting an oversized sync-point list in an IOCTL_KGSL_GPU_AUX_COMMAND to the Adreno GPU (KGSL) driver, and the fix does not originate with the operator: the packet records remediation as the OEM firmware/OS update carrying Qualcomm's fix, plus a device reboot. That routing makes the access-condition half of this control the load-bearing half — for a device model whose OEM has not yet shipped that build, there is no patch to deploy and the operator's only remaining lever is withholding organizational data from the handset. The fixed build must therefore function as an access condition, with mail, VPN and document access denied to any device below the OEM build carrying the fix, rather than as a row on a patch-compliance report. Distinguishing test: enrol a handset pinned to a pre-fix OEM build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a dashboard while the device keeps its mail and VPN has recorded the exposure rather than removed it. Two preconditions this control cannot cross. First, the packet requires a reboot after the OEM update, so a device that has taken the update but not restarted still runs the vulnerable driver and must be counted as exposed, not compliant. Second, restricting which applications may be installed raises the bar for getting the attacker's app onto the handset but does not evict one already installed, so a device suspected of already running it belongs on the incident path rather than the install-policy path. There is also no disable-the-component option to fall back on here: KGSL is the GPU path the device renders through, so unlike a discretionary kernel module it cannot be blocked or unloaded while waiting for the OEM build.",
+        "evidence": "Packet: CWE-823 and CWE-119, memory corruption while submitting a large list of sync points in an AUX command to the IOCTL_KGSL_GPU_AUX_COMMAND. The packet's attack path is a local, low-privileged Android app submitting that oversized sync-point list to the Adreno GPU (KGSL) driver, causing an out-of-range pointer write corralled into a privilege-escalation primitive. CISA KEV-listed 2023-12-05, active_exploitation confirmed, poc_available false, RWEP 57 against CVSS 7.8. patch_available true and live_patch_available false, with live_patch_notes stating there is no live-patch mechanism for chipset drivers and that remediation requires the OEM firmware/OS update carrying Qualcomm's fix and a device reboot.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This control's clock — mitigation within four hours of KEV listing or patch availability, whichever is later — is the right shape for this CVE only if patch availability is read per device model. The packet routes the fix through the OEM: remediation is the OEM firmware/OS update carrying Qualcomm's fix plus a reboot, so the 2023-12-05 KEV listing is not a date on which any operator could deploy anything. Applied here the SLA has to be written in two parts: documented compensating controls in force from the KEV listing for every affected handset, and the binary update measured against a per-model availability date the estate tracks itself, because no single date covers a fleet spanning multiple OEMs and models. Distinguishing test: for each affected device model in the fleet, produce the date its OEM published the build carrying Qualcomm's fix and the date that model's devices reached it; a programme that records one KEV due date across the whole fleet can produce neither number, and will report models whose OEM never shipped the build as merely late rather than as unremediated with no remaining patch path. Precondition: the compensating-controls half is what actually holds during that gap, and on this CVE it reduces to controlling what the device is trusted with — the packet's exploit needs only a locally installed low-privileged app on the handset, so no network-boundary measure sits anywhere in the path, and an SLA that logs a network control as the interim mitigation here has recorded something that does not touch the exploit.",
+        "evidence": "Packet: CISA KEV-listed 2023-12-05 with active_exploitation confirmed; poc_available false; RWEP 57 against CVSS 7.8. patch_available true, live_patch_available false, and live_patch_notes recording that there is no live-patch mechanism for chipset drivers and that remediation requires the OEM firmware/OS update carrying Qualcomm's fix and a device reboot. The packet's attack path establishes the only access requirement as a local, low-privileged Android app issuing IOCTL_KGSL_GPU_AUX_COMMAND to the Adreno GPU (KGSL) driver.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-33063": {
     "name": "Qualcomm Multiple Chipsets Use-After-Free Vulnerability (DSP Services)",
@@ -47971,7 +49454,39 @@
         "adequate": false,
         "gap": "Technical vulnerability management must prioritize a ubiquitous library flaw with a public root-shell PoC, yet fleet-wide glibc remediation is operationally heavy and easily deprioritized."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-142",
+        "name": "SUID-MINIMIZATION-FOR-KERNEL-LPE-CARRIER-BINARIES",
+        "description": "The carrier for this escalation is the binary, not the account. The packet's path requires a local user to launch a binary carrying the SUID bit with a maliciously crafted GLIBC_TUNABLES value in its environment, and ld.so performs the overflow while parsing those tunables inside the already-privileged process. Applied to an affected glibc estate, the control means enumerating every setuid-root binary on each host and removing the bit from those whose function does not require it, so the set of privileged processes an unprivileged user can drive through the tunables parser shrinks during the window before the distribution's patched package lands. The packet records this as one of the two available stop-gaps, alongside the vendor's GLIBC_TUNABLES handling. This is also why the cited least-privilege control does not reach the flaw: AC-6 grades what accounts are permitted to do, and the account here is an ordinary unprivileged one — the privilege transition comes from the binary's mode bits, which no account-scoped attestation examines. Distinguishing test: enumerate the setuid-root binaries on a representative host and produce, per binary, either the removed bit or a written operational need; an estate whose least-privilege evidence is a role matrix passes cleanly while every local user still holds a set of privileged carriers. Preconditions: removal helps only for binaries that actually lose the bit — any binary that must stay setuid-root for the host to function still presents the caller's environment to the loader, so the path stays open there and the estate must know which those are rather than assume the sweep was complete. It gives nothing on a host where escalation has already occurred, and it is a holding measure for the window before the patched glibc package and the reboot or service restart it requires, not a substitute for them.",
+        "evidence": "GNU C Library Buffer Overflow Vulnerability (CWE-122 / CWE-787), CISA KEV-listed 2023-11-21, active exploitation confirmed, public PoC available, CVSS 7.8, RWEP 78. The packet's vector record: a buffer overflow in the GNU C Library's dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable, allowing a local attacker to use maliciously crafted GLIBC_TUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges. The packet's live-patch record states no userspace live-patch tool exists and names the stop-gap as removing setuid bits or setting GLIBC_TUNABLES handling per vendor mitigation.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock runs from the 2023-11-21 KEV listing to the point where each affected host is running the distribution's patched glibc and has taken the reboot or service restart the packet names — not to the point where the package is approved, downloaded, or shown as installed. The packet registers no live-patch tool and states that kernel live-patching does not cover glibc, so an estate that meets its uptime obligations through a live-patching product holds no equivalent lever here: the restart cannot be traded away, and deferring it to the next maintenance window is the specific way this remediation is recorded as done while the packet's own completion criterion is unmet. Sequence by where the exploit's single precondition is the normal operating state rather than an anomaly: hosts carrying many interactive local accounts — shared shell, build and jump hosts — before single-user endpoints, because a local user account is all the packet requires and a public PoC exists against confirmed in-the-wild exploitation. Where the restart genuinely cannot be taken inside the clock, the packet's stop-gap — setuid-bit removal or the vendor GLIBC_TUNABLES handling — must be recorded as an active compensating control with a dated removal, not as remediation.",
+        "evidence": "CISA KEV-listed 2023-11-21 with active exploitation confirmed and a public PoC available; CVSS 7.8, RWEP 78. Patch available. The packet's live-patch record: no userspace live-patch tool, kernel live-patching does not cover glibc, and remediation requires the distribution's patched glibc package followed by a reboot or restart of all affected services. The packet's attack-vector record places the trigger in a local user's invocation of a SUID-root binary with a crafted GLIBC_TUNABLES environment variable, yielding code execution with root privileges.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scanner that reads the installed glibc package version and reports the host remediated answers half of what the packet requires. The packet's remediation is the patched package followed by a reboot or restart of all affected services, so a host whose package database shows the fixed build while that restart has not been taken has not met the stated completion criterion, yet it is counted green by a version-only check. The second half is the carrier surface: the flaw is reachable only through a binary carrying the SUID bit, so a vulnerability-management verdict for this CVE has to account for the setuid inventory and for whether the interim mitigation the packet names — setuid-bit removal or the vendor GLIBC_TUNABLES handling — was actually in place during the exposure window; a version-only scan cannot distinguish a host that carried that mitigation from one that never had it. Distinguishing test: take a host the scanner reports remediated and confirm both facts independently — the installed glibc is the distribution's fixed package, and the reboot or service restart occurred after it was installed. A technical-vulnerability attestation built on scanner output alone reports the pre-restart hosts as closed.",
+        "evidence": "GNU C Library dynamic loader ld.so, CISA KEV-listed 2023-11-21, active exploitation confirmed, public PoC available, CVSS 7.8, RWEP 78, patch available. The packet's live-patch record states remediation requires the distribution's patched glibc package followed by a reboot or restart of all affected services, with no live-patch tool available, and names removing setuid bits or setting GLIBC_TUNABLES handling per vendor mitigation as the stop-gap. The packet's vector confines exploitation to launching binaries with SUID permission.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-36584": {
     "name": "Microsoft Windows Mark of the Web (MOTW) Security Feature Bypass Vulnerability (CVE-2023-36584)",
@@ -48028,7 +49543,40 @@
         "adequate": false,
         "gap": "Protection-against-malware controls that depend on the OS trust prompt are insufficient when the file arrives without the MOTW marking that would trigger scanning/warnings."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "This CVE is the Mark-of-the-Web tag failing to be applied at all: the packet describes an attacker crafting a delivered file so Windows does not tag it, after which SmartScreen and Office Protected View do not trigger when the victim opens it. That makes half of this control inert here — requiring MOTW-tagged documents to open in Protected View does nothing for a file that carries no tag. The load-bearing half is the delivery boundary applying and preserving the untrusted-origin marking itself: the mail gateway, the web proxy and the untrusted file-share boundary mark externally-sourced files as they cross into the estate, so the sandbox decision is taken from provenance the operator established rather than from the OS tagging path this CVE defeats, and the marking survives the container it arrives in so extraction or renaming does not drop it. Distinguishing test keyed on the behaviour the packet documents: send, through each ingress path, a file constructed so Windows does not apply the tag, and confirm it still reaches the handler marked untrusted and opens in the reduced-privilege render — an attestation that Protected View and SmartScreen are enabled in policy passes cleanly against this CVE, because that policy is never consulted for a file that was never tagged. Precondition: this covers only channels that cross a boundary the operator controls. A file arriving on removable media, through a personal sync client, or over a channel the gateway cannot inspect still reaches the handler untagged, and for that population the only remaining lever is the Microsoft Windows October 2023 cumulative update the packet names — the packet records no live-patch path, so nothing restores the tagging behaviour on the host short of that update.",
+        "evidence": "Packet: CWE-693, 'Windows Mark of the Web Security Feature Bypass Vulnerability'. Attack path: 'An attacker crafts a delivered file so Windows fails to apply the Mark-of-the-Web tag; when the victim opens it, SmartScreen and Office Protected View do not trigger, smoothing execution of the next stage in a phishing chain.' CISA KEV 2023-11-16, active_exploitation confirmed, CVSS 5.4, RWEP 55, poc_available false. patch_available true, live_patch_available false; live-patch note: 'No live patch; requires the Microsoft Windows October 2023 cumulative update.' Cited gaps include AU-Essential-8-App-Hardening (User application hardening) and ISO-27001-2022-A.8.7 (Protection against malware).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "Mark-of-the-Web is one of the protection-mechanism classes this control names, and this entry is that class failing by construction — CWE-693, with the packet describing SmartScreen and Protected View not triggering because the tag was never applied. For this estate the control means the detonation chamber, the EDR rules and the application-control policy are regression-tested against the MOTW class on every patch deployment, with the battery built from the behaviour the packet documents rather than from tool signatures or process-crash indicators: deliver a file that arrives without the tag, confirm the estate still detonates and evaluates it, and confirm an alert fires when the handler that opened it launches the next stage of the chain. A battery that only shows SmartScreen prompting on a normally-tagged download validates the one path this CVE avoids, and will pass while the estate stays exposed. Precondition: this is a verification and detection control. It reveals that the class is still bypassable and gives a second signal when it is; it does not restore the tagging behaviour, which only the Microsoft Windows October 2023 cumulative update the packet names does. Because the packet records no live-patch path, an unpatched host stays bypassable however well the battery performs, and a behavioural alert that fires once the next stage has executed is a detection rather than a prevention — it shortens dwell time, it does not stop the chain.",
+        "evidence": "Packet: CWE-693 protection-mechanism failure; the attack path states that with the tag absent 'SmartScreen and Office Protected View do not trigger, smoothing execution of the next stage in a phishing chain.' active_exploitation confirmed; CISA KEV 2023-11-16; poc_available false. patch_available true, live_patch_available false; live-patch note names the Microsoft Windows October 2023 cumulative update as the requirement. Cited gaps include ISO-27001-2022-A.8.7 (Protection against malware), NIST-800-53-SI-4 (System Monitoring) and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.7",
+          "NIST-800-53-SI-4",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's own numbers are the argument for this control on this entry: CVSS 5.4 is the band most vulnerability-management programs schedule into a routine monthly cycle, while the packet records RWEP 55, a CISA KEV listing on 2023-11-16 and confirmed in-the-wild exploitation — because the bypass is a step that smooths a phishing chain rather than an impact in itself, and severity scoring of the step under-reads the chain. The control's clock is unusual here in a way worth stating: the fix the packet names, the Microsoft Windows October 2023 cumulative update, was already available when CISA listed the CVE, so on this entry the SLA is not waiting on a vendor — the measured quantity is the estate's own deployment lag, and hosts count as remediated by the build actually installed rather than by the update showing approved or downloaded in the management console. Precondition: this control governs deployment speed and nothing else. It says nothing about a file that already arrived untagged before the update landed, so the delivery-boundary and class-regression controls on this entry are not superseded by it; and because the packet records no live-patch path, there is no way to shorten the exposure window other than deploying the update itself.",
+        "evidence": "Packet: CISA KEV listed 2023-11-16 with active_exploitation confirmed; CVSS 5.4 against RWEP 55; poc_available false. patch_available true, live_patch_available false; live-patch note: 'No live patch; requires the Microsoft Windows October 2023 cumulative update' — an October 2023 update against a 2023-11-16 KEV listing. Cited gaps include NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-patch-management (Vulnerability handling and disclosure).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-1671": {
     "name": "Sophos Web Appliance Command Injection Vulnerability",
@@ -48537,7 +50085,42 @@
         "adequate": false,
         "gap": "Technical vulnerability management patches the CVE but does not mandate removing the exposed management plane the exploit chain depends on."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "SRX Series are firewalls and EX Series are the switches behind them, and the packet's J-Web flaw is pre-authentication remote code execution on that hardware — the device enforcing the boundary is the device being taken, so the ordinary 14- or 30-day appliance patch window does not apply to it. For these units the requirement is the Junos fixed release for the affected train deployed with the reboot the packet says remediation requires, on a clock that opened with the 2023-11-13 KEV listing, or J-Web reachability cut until that reboot completes. Reachability is the entire exploit precondition: the packet's attacker is unauthenticated and network-based and reaches the PHPRC-setting request through J-Web, so restricting which segments can present an HTTP request to that interface bounds who can attempt the chain. Precondition, and this is where the lever is routinely over-claimed: restricting reachability repairs nothing in the PHP external-variable handling. Any host inside the permitted management segment still reaches the flaw in full, so a compromised administrator workstation or jump host satisfies the attacker's only stated access requirement; and the lever is unavailable at all on units where J-Web is the operational management path. It is a holding measure for the window before the fixed release and reboot land, not a closure. Distinguishing test: from every segment that can route to the device, attempt to load J-Web on a staging unit — anything that answers is inside the published exploit's reach, and an appliance-patch attestation that records the fixed image as staged or downloaded while the unit has not rebooted is still describing a device running the vulnerable code.",
+        "evidence": "Packet: CISA KEV listed 2023-11-13, active_exploitation 'confirmed', CVSS 9.8, RWEP 79, poc_available true. vector: 'A PHP External Variable Modification vulnerability in J-Web of Juniper Networks Junos OS on EX Series and SRX Series allows an unauthenticated, network-based attacker to remotely execute code', with per-train fixed releases enumerated. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "DORA-Art-9",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation path writes to the device before any code runs, and the upgrade does not undo that: the attacker sets PHPRC through a crafted J-Web request so the PHP execution environment loads a planted configuration whose auto_prepend_file executes a payload uploaded earlier. Both the planted configuration and the uploaded payload are files on the EX or SRX filesystem, and installing the fixed Junos release closes the PHPRC path while leaving whatever was staged through it in place. So for any EX or SRX unit whose J-Web was reachable from an untrusted segment during the exposure window opened by the 2023-11-13 KEV listing, the default response is config-exfil and rebuild rather than upgrade-in-place: extract the running and stored configuration for offline comparison against a known-good baseline, rebuild from vendor image plus that baseline, and rotate every credential and key the unit holds — local administrative accounts, any RADIUS/TACACS or SNMP shared secrets it is configured with, VPN pre-shared keys, and stored certificates. The packet records poc_available true alongside confirmed in-the-wild exploitation, so an exposed unit should be treated as having had the chain attempted, and the chain's second stage requires the attacker to have already written to the box. Precondition: this presumes a known-good baseline exists to compare against — a unit with no captured baseline can be rebuilt but cannot be cleared, so an unremarkable file listing is not evidence it is clean. Distinguishing test: on an exposed unit, diff the on-device file set and configuration against the baseline before the upgrade; a flaw-remediation attestation showing every EX and SRX at the fixed release proves the PHPRC path is closed and says nothing about a payload staged before it was.",
+        "evidence": "Packet: attack_vector states the attacker 'sets the PHPRC environment variable via a crafted J-Web request to load a planted PHP config (auto_prepend_file) that executes a previously uploaded payload, achieving remote code execution on SRX/EX devices'. active_exploitation 'confirmed', poc_available true, KEV listed 2023-11-13. patch_available true with live_patch_available false and remediation requiring the fixed release plus reboot.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "J-Web is the device-management gateway on these EX and SRX units, and this CVE is that gateway letting request-supplied input reach the interpreter's own execution environment before any caller is authenticated: a crafted request sets PHPRC and redirects which PHP configuration is loaded. Bound to this product, the control means no J-Web request parameter is permitted to select or modify the PHP execution environment, and every endpoint on the device that accepts file content authorises its caller before the content is stored — the packet's chain needs both halves, an earlier upload and an unauthenticated request that points the interpreter at it, so an endpoint-side fix on either one breaks it. The user-application-hardening gap cited on this entry does not reach here at all: that control governs the browsers, Office and PDF handlers on operator workstations, and the vulnerable application is the appliance's own web management interface, which no workstation-hardening attestation examines. Precondition: the endpoint-side authorisation and input neutralisation are properties the Junos fixed release establishes — this control states what to verify, it does not implement it. The operator-side lever before that release lands is least functionality: J-Web disabled outright on units genuinely managed by another channel (console, SSH CLI, or a management platform), which removes the delivery path on those units only, is unavailable where J-Web is the management path, and does nothing for a unit already exploited during the exposure window, since disabling the interface afterwards does not remove what was written to the filesystem. Distinguishing test: against a staging unit, issue unauthenticated J-Web requests carrying environment-influencing parameters and confirm each is refused before the PHP environment is consulted.",
+        "evidence": "Packet: CWE-473 (PHP External Variable Modification); vector states 'Using a crafted request which sets the variable PHPRC an attacker is able to modify the PHP execution environment allowing the injection und execution of code', reached by an unauthenticated, network-based attacker through J-Web on EX Series and SRX Series. attack_vector adds that the executed payload was 'previously uploaded'. AU-Essential-8-App-Hardening (User application hardening) and NIST-800-53-CM-7 (Least Functionality) are recorded among the citing framework gaps. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2023-36846": {
     "name": "Juniper Junos OS SRX J-Web Missing Authentication File Upload",
@@ -49210,7 +50793,31 @@
         "adequate": false,
         "gap": "Technical-vulnerability-management that closes on 'patched' fails to include the mandatory session-invalidation step, so the residual token-replay risk persists."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A NetScaler ADC or Gateway configured as a VPN virtual server, ICA Proxy, CVPN, RDP Proxy or AAA virtual server is the authentication boundary for the applications behind it, so the standard 14/30-day windows the citing patch controls grade against are the wrong clock: the device is not protected by the perimeter, it is the perimeter, and the packet's request is unauthenticated and single-shot. This CVE argues for a distinct tier — for an internet-reachable appliance in one of those roles, either the fixed release is running or the exposed virtual server's public interface is taken offline, within hours of the 2023-10-18 KEV listing, with that shutdown pre-authorized so an on-call engineer can take it without a change window. The tier must be driven by configured role rather than product name: the packet ties the disclosure specifically to the Gateway and AAA virtual-server configurations, so an asset record showing only that a NetScaler exists cannot select the affected population — the inventory has to record which virtual servers are published and in which role. The completion criterion is the reboot, not the upload: the packet records no vendor live-patch mechanism and states remediation requires applying the fixed release and rebooting, so an appliance staged with the fixed build but not rebooted is not remediated. Distinguishing test: produce the list of appliances with a Gateway or AAA virtual server configured and show, per appliance, the running release and the reboot timestamp — an estate whose patch evidence is a product-level inventory passes while the exposed virtual servers keep answering.",
+        "evidence": "Citrix NetScaler ADC and NetScaler Gateway buffer overflow (CWE-119), CISA KEV-listed 2023-10-18, active exploitation confirmed, public PoC available, CVSS 7.5, RWEP 81, patch available. The packet's vector record scopes the sensitive information disclosure to appliances configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server. The packet's attack-vector record: an unauthenticated attacker sends an oversized request to a Gateway/AAA endpoint, triggering an out-of-bounds read that returns leaked memory. The packet's live-patch record: no vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The half of this control that binds here is the credential half, not the rebuild half, and the distinction is load-bearing: the packet establishes an out-of-bounds read that returns memory, not code execution on the appliance, so treating every exposed unit as carrying an implant would send operators after evidence the packet does not support. What the packet does establish is that the leaked memory contains valid session tokens which are replayed to hijack authenticated sessions and bypass MFA — and a token captured before the upgrade stays valid after it, because applying the fixed release stops further leakage and invalidates nothing already taken. Remediation for this CVE is therefore ordered: fixed release and reboot first, then invalidate every existing session on the appliance so leaked tokens cannot be replayed, then rotate the credentials and review the accounts reachable through the sessions the appliance was brokering. The replay produces no authentication event, which is exactly why the identity controls cited on this entry can pass their attestations while the path stays open — the second factor is never presented and no access decision is ever consulted, so evidence that every gateway user holds MFA says nothing about this exposure. Distinguishing test: on a staging appliance, capture a session token before the upgrade and replay it afterwards, confirming it is refused; an appliance recorded as remediated on release version alone still honours pre-upgrade tokens. Precondition: session invalidation stops replay of what leaked up to that moment — it does not undo actions already taken through a hijacked session, so any appliance that served a Gateway or AAA virtual server from an untrusted network on a vulnerable build needs the activity in that window reviewed rather than closed on the upgrade.",
+        "evidence": "Citrix NetScaler ADC and NetScaler Gateway, CISA KEV-listed 2023-10-18, active exploitation confirmed, public PoC available, CVSS 7.5, RWEP 81, patch available. The packet's attack-vector record: an unauthenticated attacker sends an oversized request to a Gateway/AAA endpoint, triggering an out-of-bounds read that returns leaked memory containing valid session tokens, which are then replayed to hijack authenticated sessions and bypass MFA. The packet's live-patch record: no vendor live-patch mechanism; remediation requires applying the fixed release and rebooting — an action that addresses the leak and not the tokens already obtained through it.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-B2",
+          "NIST-800-53-IA-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-20198": {
     "name": "Cisco IOS XE Web UI Privilege Escalation Vulnerability",
@@ -49267,7 +50874,41 @@
         "adequate": false,
         "gap": "ISM management-traffic-segregation guidance is widely unmet for edge routers, so the web UI remains internet-facing and abusable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet describes precisely what survives an upgrade. After reaching the IOS XE web UI unauthenticated, the actor issued a privilege 15 command to create a local user and password combination, logged in with that account, then used CVE-2023-20273 to elevate to root and write an implant to the file system. Installing a fixed IOS XE release removes neither: the account is stored configuration and the implant is a file, and an in-place upgrade inherits both. So for any unit whose web UI was reachable during the exposure window opened by the 2023-10-16 KEV listing, the default response is config-exfil, rebuild and credential rotation rather than patch-and-close: export running and startup configuration for offline comparison against a known-good baseline, enumerate the locally defined users and their privilege levels against that baseline and treat any account not in it as attacker-created, rebuild from vendor image plus baseline configuration, and rotate every credential the device held — local accounts, enable and AAA secrets, any shared secrets, and stored certificates. Precondition: this presumes a captured known-good baseline to diff against; a device without one can be rebuilt but cannot be cleared, so the absence of an obviously extra account is not evidence the unit is clean. Distinguishing test: on an exposed unit, diff the on-device account list and filesystem against the baseline before the upgrade — an attestation that every IOS XE unit sits at a fixed release proves the initial-access path is closed while a privilege-15 account the attacker created still authenticates and the implant still runs, and that is the specific way an account-management or access-control review passes on this device while the compromise persists.",
+        "evidence": "Packet: vector states 'The attacker first exploited CVE-2023-20198 to gain initial access and issued a privilege 15 command to create a local user and password combination... The attacker then exploited another component of the web UI feature, leveraging the new local user to elevate privilege to root and write the implant to the file system. Cisco has assigned CVE-2023-20273 to this issue.' CISA KEV listed 2023-10-16, active_exploitation 'confirmed', CVSS 10, RWEP 83, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' NIST-800-53-AC-2, ISO-27001-2022-A.5.15 and UK-CAF-B2 are recorded among the citing framework gaps.",
+        "gap_closes": [
+          "NIST-800-53-AC-2",
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The web UI is the entire initial-access path in this packet — an unauthenticated remote attacker reaches it and issues a privilege 15 command — and it is a feature of IOS XE that can be turned off. On the routers and switches carrying that software the exposure has to be graded at the trust boundary rather than as a generic OS patch item: the packet records CVSS 10, KEV listing on 2023-10-16, confirmed exploitation and a public PoC, so the requirement is the fixed IOS XE release deployed with the reboot the packet says remediation requires, on a clock that opens at the KEV listing — or the HTTP/HTTPS management server disabled, or its reachability cut, on every affected unit until that reboot completes. The standard 14- and 30-day appliance SLAs do not apply, because this device is the boundary everything behind it depends on. Precondition on the interim lever: disabling or restricting the web UI removes the delivery path only where the unit is genuinely managed by another channel — console, SSH CLI, or a management platform — and it is unavailable where the web UI is the operational management path. It also does nothing for a unit already compromised during the exposure window: the packet's attacker-created privilege-15 account lives in configuration and the implant on the filesystem, and both persist whether or not the interface is later turned off. Distinguishing test: from every segment that can route to the device, including any internet-facing interface, attempt to load the IOS XE web UI on a staging unit and confirm nothing answers — a patch-compliance report listing units as scheduled while the HTTP server still answers from an untrusted segment is measuring the wrong thing.",
+        "evidence": "Packet: CVSS 10, RWEP 83, poc_available true, KEV listed 2023-10-16 with active_exploitation 'confirmed'. attack_vector: 'An unauthenticated remote attacker abuses the IOS XE web UI to issue a privilege-15 command that creates a local user/password...'. patch_available true (the vector notes the vendor 'updating the list of fixed releases and adding the Software Checker'), live_patch_available false with remediation requiring the fixed release and a reboot. NIST-800-53-CM-7 (Least Functionality), NIST-800-53-SC-7 (Boundary Protection) and AU-ISM-1546 are recorded among the citing framework gaps.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIST-800-53-SC-7",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet names the exact record that decides whether an operator ever learns this happened: a privilege 15 command creating a local user and password combination. That is a configuration change the device itself emits — and the same chain ends with the attacker at root on that device, able to alter or suppress anything it retains locally. So IOS XE configuration-change and account-creation records must be forwarded as they are generated to a collector in a separate trust zone — different management plane, different credentials, no path from a rooted router back to the stored copy — with retention long enough to cover a window that here runs from the 2023-10-16 KEV listing back to whenever the unit first became reachable. Key the alert on the behaviour the packet documents rather than on a tool signature: a new locally defined user appearing on a network device outside a change window, and configuration writes not attributable to a known administrator session. Precondition: this detects, it does not prevent — nothing here stops the unauthenticated request — and it degrades exactly where it matters most, because an attacker who reached root can stop the device sending anything further, so a device going quiet is a reason to investigate rather than evidence it is clean. Distinguishing test: on a staging unit, create a local user from a privileged session, then attempt to remove the corresponding record from the device with root-equivalent access, and confirm the off-box copy is intact and has alerted.",
+        "evidence": "Packet: the attacker 'issued a privilege 15 command to create a local user and password combination', then 'elevate[d] privilege to root and write[s] the implant to the file system' (CVE-2023-20273). NIST-800-53-AC-2 (Account Management) is recorded among the citing framework gaps. active_exploitation 'confirmed'; patch_available true with live_patch_available false, so the detection covers the window before the fixed release and reboot land.",
+        "gap_closes": [
+          "NIST-800-53-AC-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-21608": {
     "name": "Adobe Acrobat and Reader Use-After-Free Vulnerability",
@@ -50181,7 +51822,30 @@
         "adequate": false,
         "gap": "System security assumes a sound browser sandbox, but the WebKit flaw is the initial code-execution primitive that breaks that assumption."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet records the fix in macOS Sonoma 14 and exploitation against iOS versions before iOS 16.7, so the population is the whole Apple estate — Macs alongside iPhones and iPads — and for this CVE the control means those builds are pushed as a managed, non-deferrable update on the clock that opened with the 2023-09-25 KEV listing rather than left to each user's own Software Update prompt. Measure completion by the OS build each device reports against the fixed build, never by the update having been offered, downloaded or marked approved: the packet records no live-patch mechanism and a remediation that requires applying the fixed release and rebooting, so a device that has staged the update but not restarted is still running the WebKit that processes the crafted content and belongs in the exposed count. The distinguishing test is to pull reported builds for the enrolled fleet and compare each against the fixed build; a compliance view showing the update as deployed while devices still report pre-fix builds is measuring the management console, not the estate. Precondition, and it is where this control gets over-claimed: the SLA reaches only devices the platform enrols and can actually compel. A personally-owned or lightly-managed device that receives configuration profiles but not update enforcement can sit below the fixed build indefinitely, and carrying it as 'pending' on the same clock hides a device that will never take the update through this path — for those the remaining lever is withholding organizational data until the build is at or above the fix.",
+        "evidence": "The packet records CVE-2023-41993 (Apple Multiple Products WebKit Code Execution Vulnerability, CWE-754) as CISA KEV-listed 2023-09-25 with active_exploitation 'confirmed', poc_available false, RWEP 61 against CVSS 8.8, patch_available true, and live_patch_available false with the note 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The packet's vector states: 'The issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14. Processing web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.' The documented attack path is a victim opening a targeted link or page, WebKit processing crafted web content, and arbitrary code execution in the renderer as the opening stage of the spyware chain.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this bug at the opening stage of a spyware chain, which makes the acutely exposed population narrower and more identifiable than the estate as a whole — the staff plausibly inside a targeting set. For that cohort the reboot-gated update is not fast enough on its own, so the control means those devices are held in a reduced-attack-surface mode in which untrusted web content, link previews, attachments and fonts are not processed automatically, narrowing the delivery path into the WebKit parsing bug across the window between the 2023-09-25 KEV listing and a completed update-and-restart. Two preconditions have to be stated rather than assumed, because this is where the control is routinely over-claimed. First, the packet's delivery step is a victim opening a targeted link or page: the mode's automatic-processing restrictions do not cover a user who deliberately opens the page, so it constrains how untrusted content is handled and shrinks the passive delivery paths — it does not stop the lure and it removes no part of the vulnerable code. Second, it only helps if it was already assigned when the chain arrived; switching it on after delivery does nothing about content already processed, and a device suspected of having already run the chain belongs on the incident path rather than the hardening path. Treat the assignment as a standing posture for the high-risk cohort set before the next disclosure, and as a holding measure for the window — not as a substitute for the fixed release and its restart.",
+        "evidence": "The packet documents the exploitation path as a victim opening a targeted link or page, WebKit processing crafted web content, giving arbitrary code execution in the renderer 'as the opening stage of the spyware chain' (CWE-754). It records active_exploitation 'confirmed' with poc_available false, CISA KEV listing 2023-09-25, CVSS 8.8, RWEP 61, and a vector noting the issue may have been actively exploited against versions of iOS before iOS 16.7, with the fix in macOS Sonoma 14. patch_available is true and live_patch_available false, noted as 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' AU-Essential-8-App-Hardening (User application hardening) is among the framework controls this entry cites as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2023-41179": {
     "name": "Trend Micro Apex One and Worry-Free Business Security Remote Code Execution Vulnerability",
@@ -50352,7 +52016,31 @@
         "adequate": false,
         "gap": "System security relies on kernel/driver integrity that this NPU-driver use-after-free directly violates."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet names the fixed release, SMR Jan-2022 Release 1, and a KEV listing date of 2023-09-18, and the distance between those two facts is the problem this control addresses: on a handset estate an OS update is applied at the user's convenience unless management compels it, so a fix that had existed for well over a year was still absent from enough Samsung devices to make the entry a KEV item. For this CVE the control means the mobile-management platform pushes and enforces that release on a defined KEV clock with user deferral disallowed, and reports completion from the security-patch level each handset actually reports rather than from the update having been made available to it. The packet records no live-patch path and a remediation that requires applying the fixed release and rebooting, so a handset that has downloaded the update but not restarted still runs the vulnerable NPU driver and stays in the exposed count — on a phone the restart is user-initiated, which is precisely where a 'deployed' figure and the real fleet state diverge. Precondition: the SLA binds only handsets the platform enrols with update-enforcement authority. A personally-owned device enrolled for mail access alone will typically expose its patch level to the platform without accepting compelled updates; for those the operative lever is the access condition, not this clock, and carrying them as 'pending enforcement' on the same SLA conceals devices that will never take the update through this path.",
+        "evidence": "The packet records CVE-2022-22265 (Samsung Mobile Devices Use-After-Free Vulnerability, CWE-703) as CISA KEV-listed 2023-09-18 with active_exploitation 'confirmed', poc_available false, RWEP 53 against CVSS 7.8, patch_available true, and live_patch_available false with the note 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Its vector states: 'An improper check or handling of exceptional conditions in NPU driver prior to SMR Jan-2022 Release 1 allows arbitrary memory write and code execution.' The documented attack path is a local app abusing improper exception handling in the Exynos NPU driver to trigger a use-after-free, gaining arbitrary kernel memory write and code execution for privilege escalation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records is a local app driving improper exception handling in the Exynos NPU driver into an arbitrary kernel memory write, so for a Samsung handset estate this control means treating the security-maintenance-release level as an access condition rather than a dashboard row: a device reporting below SMR Jan-2022 Release 1 is denied mail, VPN and document access until it is at or above that release. The distinguishing test is to enrol a handset pinned below that release and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale patch level on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition on the access half, which is where this is over-claimed: constraining which applications may be installed raises the bar for getting the attacker's app onto the handset, but it does not evict an app already installed and it does not cover one delivered through the normal store channel — a device suspected of already running it belongs on the incident path, not the install-policy path. There is also no driver-side lever to fall back on here. The packet's fix ships in the vendor's own maintenance release, which places the NPU driver inside the vendor OS build rather than in anything an enterprise can blacklist or unload, so unlike a loadable-module case there is no configuration that keeps the vulnerable code out of service — the fixed release is the only thing that removes it. This is a holding measure for the window before that release and its required restart land, not a substitute for them; the packet records no live-patch path and a remediation requiring the fixed release plus a reboot.",
+        "evidence": "The packet's vector states the flaw is 'An improper check or handling of exceptional conditions in NPU driver prior to SMR Jan-2022 Release 1 allows arbitrary memory write and code execution', and its attack path is a local app abusing improper exception handling in the Exynos NPU driver to trigger a use-after-free, gaining arbitrary kernel memory write and code execution for privilege escalation (CWE-703). It records CISA KEV listing 2023-09-18, active_exploitation 'confirmed', poc_available false, CVSS 7.8, RWEP 53, patch_available true, and live_patch_available false with the note 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2014-8361": {
     "name": "Realtek SDK Improper Input Validation Vulnerability",
@@ -51444,7 +53132,41 @@
         "adequate": false,
         "gap": "A.8.8 would surface FG-IR-25-934 as a vulnerability to patch, but because exploitation requires an existing filesystem-level compromise, A.8.8's patch-centric remedy never triggers the compromise-recovery process needed to remove the attacker's symlink foothold."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This CVE is the case the control exists for, stated by the advisory text itself: the flaw bypasses the patch developed for the symbolic-link persistency mechanism observed in some post-exploit cases, and its stated precondition is an attacker who has already compromised the product via another vulnerability, at filesystem level. On a FortiOS unit with evidence of that prior compromise, the upgrade is not eviction — it closes the current bypass while leaving whatever the attacker placed on the filesystem, and the packet shows this is the second time a patch has been asked to do that job and the second time it did not hold. For such a unit the default response is configuration extraction for review, rebuild from vendor image, and rotation of the credentials the device held or handled — administrative accounts first, then the SSL-VPN user credentials, since the packet's outcome is re-exposure of sensitive files on the device and restoration of the attacker's foothold through the SSL-VPN web surface. Preconditions, both directions: the rebuild path applies only to units with evidence of prior filesystem-level compromise; for every other affected unit the vendor upgrade is the remediation and is still mandatory. And the upgrade is required on the rebuilt unit too — the packet records no live-patch mechanism and states remediation requires upgrading to FortiOS 7.6.2 / 7.4.7, or migrating 7.2 / 7.0 / 6.4 to a supported fixed release, which reboots the appliance, so an image restored to a pre-fix build reopens the same path. What this control refuses is the reverse substitution: treating the upgrade as eviction on a device whose filesystem an attacker already reached.",
+        "evidence": "Packet vector: the flaw in FortiOS 7.6.0-7.6.1, 7.4.0-7.4.6, 7.2 all versions, 7.0 all versions and 6.4 all versions 'may allow a remote unauthenticated attacker to bypass the patch developed for the symbolic link persistency mechanism observed in some post-exploit cases, via crafted HTTP requests. An attacker would need first to have compromised the product via another vulnerability, at filesystem level.' attack_vector: an attacker who has already compromised a FortiOS device at the filesystem level 're-create[s] the symbolic-link read Fortinet's earlier patch was designed to block, re-exposing sensitive files and restoring post-exploit persistence.' CISA KEV-listed 2026-07-27, active_exploitation confirmed. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism for FortiOS; remediation requires upgrading to FortiOS 7.6.2 / 7.4.7 (or migrating 7.2/7.0/6.4 to a supported fixed release), which reboots the appliance.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet names this defect's position in a sequence rather than leaving it to be inferred: it bypasses the patch developed for the symbolic-link persistency mechanism, so it is at minimum the second entry on that same primitive and the earlier fix is now demonstrated incomplete. Two consequences for how a FortiOS vulnerability queue treats it. Its own ranking first: the packet records CVSS 5.9 and RWEP 46, a mid-band pair that a severity-sorted queue places behind higher-scored appliance items, against a KEV listing of 2026-07-27 and confirmed in-the-wild exploitation of a mechanism whose entire function is restoring an attacker's foothold on a device that was already compromised. The multiplier is what corrects that ordering, and on this entry it is the difference between the upgrade landing in the current cycle and landing in the next one. Its forward implication second: a primitive that has now been patched once and bypassed once should be carried as likely to be bypassed again, so the symbolic-link read path reachable through the FortiOS SSL-VPN belongs on a standing watch list for the next advisory rather than being closed out when 7.6.2 / 7.4.7 is deployed. Distinguishing test: ask the vulnerability-management program to produce, for this CVE, the record linking it to the earlier symlink-persistency fix it bypasses; a program that scores each Fortinet advisory as a discrete mid-band item cannot produce that link, and will rank the next bypass on the same primitive exactly the same way. Precondition: this control changes prioritization and tracking only — it schedules the upgrade sooner, it does not remediate anything on its own.",
+        "evidence": "Packet vector: the flaw 'may allow a remote unauthenticated attacker to bypass the patch developed for the symbolic link persistency mechanism observed in some post-exploit cases, via crafted HTTP requests' — the packet identifies the bypassed prior patch on the same primitive. CVSS 5.9, RWEP 46, poc_available false, CISA KEV-listed 2026-07-27, active_exploitation confirmed. live_patch_notes: remediation requires upgrading to FortiOS 7.6.2 / 7.4.7 (or migrating 7.2/7.0/6.4 to a supported fixed release), which reboots the appliance; live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet's stated precondition settles where this appliance's logs can be trusted: the attacker already holds the device at filesystem level, so on-box records are attacker-writable, and the exact events that matter — the crafted HTTP requests to the SSL-VPN that re-create the symbolic-link read, and the file reads that follow — are the ones an attacker on the box has both motive and access to remove. Those requests also arrive through the same web surface that serves legitimate SSL-VPN users, so they are separable in the record rather than at the connection. For this appliance the control means FortiOS event and traffic logs, including SSL-VPN web request and file-access events, forwarding to a collector in a separate trust zone with its own credentials and management path, retained across the whole exposure window rather than the appliance's local rotation. Preconditions, and they are the load-bearing part here: this preserves evidence and makes the re-persistence visible, it does not block the symbolic-link read and it does not substitute for the upgrade to FortiOS 7.6.2 / 7.4.7 (or migration off 7.2 / 7.0 / 6.4) and the reboot that upgrade requires. On a device already compromised at filesystem level the attacker can also stop the forwarder, so the collector must alarm on a FortiOS unit that goes silent and a silent unit must be treated as an incident rather than a logging fault. And it gives nothing retroactively: a device compromised before forwarding was configured has no off-box record to consult, which is why this has to be standing configuration rather than a response to this advisory.",
+        "evidence": "Packet attack_vector: 'An attacker who has already compromised a FortiOS device at the filesystem level sends crafted HTTP requests to the SSL-VPN that re-create the symbolic-link read Fortinet's earlier patch was designed to block, re-exposing sensitive files and restoring post-exploit persistence.' Vector states the attacker 'would need first to have compromised the product via another vulnerability, at filesystem level.' CISA KEV-listed 2026-07-27, active_exploitation confirmed, poc_available false. live_patch_available false; live_patch_notes: remediation requires upgrading to FortiOS 7.6.2 / 7.4.7 (or migrating 7.2/7.0/6.4 to a supported fixed release), which reboots the appliance. Citing gap UK-CAF-B4 (System security) does not require appliance logs to be held outside the appliance.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-16812": {
     "name": "Arista VeloCloud Orchestrator On-Prem OS Command Injection Vulnerability",
@@ -51749,7 +53471,40 @@
         "adequate": false,
         "gap": "A.5.15 access control relies on an enforced authorization model; the insufficiently restrictive HTTPD configuration in Sentry <= 9.18.0 bypasses that model on the admin API, so documented access-control policy does not prevent the unauthenticated administrative takeover exploited in 2023."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Ivanti MobileIron Sentry is the device-management gateway this control governs, and only the authorization half of it is load-bearing here — this flaw carries no attacker-supplied file or path, so the input-neutralization half has nothing to act on. The packet places the defect in an insufficiently restrictive Apache HTTPD configuration fronting the MICS Admin Portal: the administrative interface takes its authentication verdict from that fronting configuration instead of deciding it at the function, so an unauthenticated request to TCP/8443 reaches the System Manager API behind it and runs commands as root. Bound to this product, the control means each MICS administrative function on Sentry authorizes its own caller before the function executes, and no Sentry appliance is left with TCP/8443 reachable from a segment with no operational need to administer it. This is also why the access-control and identity gaps recorded against this entry cannot close the path: the attacker never authenticates as any Sentry administrator, so per-account privilege scoping is never consulted and the account model those attestations examine is bypassed rather than abused. Distinguishing test: from a segment with no Sentry administration role, send an unauthenticated request to the MICS Admin Portal on TCP/8443 of a staging appliance and confirm it is refused before the System Manager API is reached — an attestation that every Sentry administrator authenticates at login passes cleanly while this path stays open. Precondition: the endpoint-side authorization is a property the Ivanti fixed release establishes; this control states what to verify, it does not implement it. The packet records a vendor patch with no live-patch path, so remediation is upgrading Sentry 9.18.0 and below to the Ivanti fixed release and restarting the appliance. Until that lands, restricting which segments can reach TCP/8443 bounds who can send the request but leaves the portal fully exploitable to anything inside the permitted segment, and it is unavailable wherever the administrative interface must stay reachable for normal operation.",
+        "evidence": "Packet: CWE-863 in the MICS Admin Portal of Ivanti MobileIron Sentry 'versions 9.18.0 and below, which may allow an attacker to bypass authentication controls on the administrative interface due to an insufficiently restrictive Apache HTTPD configuration'. Attack path: 'An unauthenticated request to the MICS admin portal on TCP/8443 bypasses authentication ... then abuses the System Manager API to execute commands as root and drop a webshell.' CVSS 9.8, RWEP 76, poc_available true, CISA KEV 2023-08-22, active_exploitation confirmed. patch_available true, live_patch_available false; live-patch note: 'remediation requires upgrading Sentry to the Ivanti fixed release (RPM/appliance update) and restarting the appliance'. Cited gaps on this entry include boundary protection (NIST-800-53-SC-7) and access control / identity management (ISO-27001-2022-A.5.15, UK-CAF-B2, NIS2-Art21-identity-management).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.5.15",
+          "NIS2-Art21-identity-management",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's chain does not stop at authentication bypass: it ends in command execution as root and a webshell dropped on the Sentry appliance, with exploitation confirmed in the wild since the 2023-08-22 KEV listing. Applying the Ivanti fixed release to an appliance that was reachable during that window replaces the permissive Apache HTTPD configuration but leaves in place anything the attacker wrote with root privilege — the webshell the packet names is the first artifact to expect, not the only one that fits the primitive. Bound to this product, the control means any Sentry whose MICS Admin Portal on TCP/8443 was reachable during the exposure window is handled as compromised until shown otherwise: configuration and logs pulled off for analysis, the appliance rebuilt onto the fixed release from vendor media rather than upgraded in place, and every credential the MDM handled rotated — which is the packet's own remediation instruction, not an addition to it. Distinguishing test: for each remediated appliance, show the build in service came from a rebuild or vendor-media restore and that MDM-handled credentials were rotated; an appliance whose upgrade completed while its filesystem was never examined satisfies a flaw-remediation attestation and still carries the webshell. Precondition: a rebuild removes only what is on the appliance. It does not invalidate credentials or trust material the attacker already read, which is why rotation belongs in the same action rather than as a follow-up; and restoring a configuration backup taken inside the exposure window can carry attacker-modified configuration back onto the clean build, so configuration is re-applied selectively rather than wholesale.",
+        "evidence": "Packet: attack path is 'An unauthenticated request to the MICS admin portal on TCP/8443 ... then abuses the System Manager API to execute commands as root and drop a webshell.' active_exploitation confirmed; CISA KEV 2023-08-22; RWEP 76; poc_available true. patch_available true, live_patch_available false, with the live-patch note requiring 'upgrading Sentry to the Ivanti fixed release (RPM/appliance update) and restarting the appliance, plus rotating any credentials handled by a potentially compromised MDM'. The entry's cited patch gap is AU-Essential-8-Patch (Patch operating systems).",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet ties this appliance to an MDM — its remediation note requires rotating any credentials handled by a potentially compromised MDM — so a root-level compromise of Sentry has a blast radius measured in managed devices and the credentials that flowed through them, not in one appliance. The playbook for this product hunts what the packet documents rather than a generic malware signature sweep: requests to the MICS Admin Portal on TCP/8443 with no preceding authentication event, command execution in root context originating from the System Manager API, and content written into the paths the appliance serves (the webshell). The window opens at the earliest date the portal was reachable, and inside it the playbook's actions are the identity ones frameworks do not prescribe post-compromise: rotate every credential the MDM handled, invalidate device-trust state, and review configuration profiles pushed to managed devices during the window. Precondition: these actions must be issued from a control plane the attacker does not hold. Pushing revocations or profiles from a Sentry that is still compromised routes them through the attacker's foothold, so the appliance rebuild precedes them. And this is a response capability, not a fix — it repairs nothing in the authorization path, and it only helps if it was rehearsed before the 2023-08-22 listing rather than drafted during the incident.",
+        "evidence": "Packet: live_patch_notes states remediation includes 'rotating any credentials handled by a potentially compromised MDM'; the product is Ivanti MobileIron Sentry. Attack path reaches 'execute commands as root and drop a webshell' from an unauthenticated request to the MICS admin portal on TCP/8443. active_exploitation confirmed; CISA KEV 2023-08-22; CVSS 9.8; RWEP 76. Cited gaps include NIS2-Art21-identity-management (Identity and access management) and ISO-27001-2022-A.5.15 (Access control).",
+        "gap_closes": [
+          "NIS2-Art21-identity-management",
+          "ISO-27001-2022-A.5.15"
+        ]
+      }
+    ]
   },
   "CVE-2023-27532": {
     "name": "Veeam Backup & Replication Cloud Connect Missing Authentication for Critical Function Vulnerability",
@@ -55025,7 +56780,38 @@
         "adequate": false,
         "gap": "A.8.24 use-of-cryptography is silently undermined: leaking the IKE pre-shared key/RSA material via memory disclosure lets an attacker impersonate or decrypt the VPN, so strong crypto configuration is worthless once CVE-2016-6415 hands over the keys."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-137",
+        "name": "DEPRECATED-VPN-KEY-EXCHANGE-DISABLE-AND-MACHINE-CERT-ENFORCEMENT",
+        "description": "The vulnerable surface here is the deprecated key-exchange responder itself: the packet places the flaw in the server IKEv1 implementation and reaches it with a single crafted Security Association negotiation request to UDP/500 from an unauthenticated remote attacker. Bound to the products the packet names — Cisco IOS 12.2 through 12.4 and 15.0 through 15.6, IOS XE through 3.18S, IOS XR 4.3.x and 5.0.x through 5.2.x, and PIX before 7.0 — the control means inventorying which of those devices have IKEv1 enabled and answering, moving the peers that can move to IKEv2, and disabling IKEv1 where no peer requires it, so the responder the attacker talks to is gone rather than merely patched on the vendor's schedule. Scope it to those devices: the packet ties the defect to those Cisco trains and provides no mapping into other vendors' IKEv1 stacks, so a sweep that disables IKEv1 across every gateway in the estate manufactures work against products no evidence implicates. The certificate half of this control is not the operative half on this entry — the packet describes memory disclosure of key material, not a certificate-validation bypass, and certificates held by the device are among the material the packet says the leak may return, so requiring machine certificates does not reduce this exposure. Distinguishing test: from an address outside the configured peer set, send an IKEv1 SA negotiation request to UDP/500 against each named device and confirm nothing answers. Preconditions: disabling IKEv1 closes the path only on devices where every peer can be moved off it. A device that must keep IKEv1 for a legacy peer still answers on UDP/500, and the remaining lever there is restricting which sources may reach that port to the known peer addresses — which bounds who can send the request but leaves the responder fully exploitable to anything inside the permitted set, and is unavailable where peers connect from dynamic addresses. Neither measure removes material that was already read out.",
+        "evidence": "Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure Vulnerability (CWE-200), CISA KEV-listed 2023-05-19, active exploitation confirmed, public PoC available, CVSS 7.5, RWEP 70, patch available. The packet's vector record: the server IKEv1 implementation in Cisco IOS 12.2 through 12.4 and 15.0 through 15.6, IOS XE through 3.18S, IOS XR 4.3.x and 5.0.x through 5.2.x, and PIX before 7.0 allows remote attackers to obtain sensitive information from device memory via a Security Association negotiation request (Bug IDs CSCvb29204 and CSCvb36055, aka BENIGNCERTAIN). The packet's attack-vector record places the request on UDP/500 from a remote unauthenticated attacker, with insufficient condition checks causing the device to return chunks of memory that may contain IKE pre-shared keys, certificates, and configuration.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The credential half of this control is what binds on this entry, and the rebuild half deliberately does not: the packet's primitive is a read — a crafted IKEv1 negotiation request that returns chunks of device memory — and nothing in it establishes attacker code on the router, so dispositioning every exposed unit as implanted would send operators after evidence the packet does not support. What the packet does establish, and states outright in its own remediation note, is that the returned memory may contain IKE pre-shared keys, certificates and configuration, and that those should be rotated after exposure. So for this CVE the flaw-remediation record is not the remediation: upgrading to a fixed Cisco image stops further leakage and leaves every key already read fully valid. Applied to these devices that means re-keying the IKE pre-shared key on each tunnel the device terminates — on both peers, since the key is shared — re-issuing the certificates it held, and reviewing the running configuration for anything else that would be sensitive in the clear. Ordering matters: rotating before the fixed image is running re-exposes the new material to the same request, so the upgrade and its reboot come first and the rotation follows. Distinguishing test: for each device whose UDP/500 responder was reachable from an untrusted network before the upgrade, produce the date each tunnel's pre-shared key was changed and show it falls after the fixed image was running; a record showing the fixed image with the original keys still in service documents the leak as closed while the leaked keys stay usable. Precondition: rotation removes the value of what was read — it does not tell you whether anything was read, and the packet supplies no per-device indicator, so disposition must be driven by whether the responder was reachable from untrusted networks during the window rather than by a search for evidence of exploitation.",
+        "evidence": "Cisco IOS, IOS XR, and IOS XE IKEv1 information disclosure, CISA KEV-listed 2023-05-19, active exploitation confirmed, public PoC available, CVSS 7.5, RWEP 70, patch available. The packet's attack-vector record: a remote unauthenticated attacker sends a crafted IKEv1 Security Association negotiation request to UDP/500 and insufficient condition checks cause the device to return chunks of memory that may contain IKE pre-shared keys, certificates, and configuration. The packet's live-patch record: no live-patch mechanism for classic Cisco IOS/PIX; remediation is upgrading to a Cisco fixed IOS/IOS XE/IOS XR image, which reboots the device, and pre-shared keys/certificates should be rotated after exposure.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.24",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Two things about this entry defeat an ordinary vulnerability-management clock. First, the CVE identifier is from 2016 while the KEV listing is 2023-05-19 — a program that ages and prioritises items by publication date deprioritised this years before it was listed, so the SLA has to key on the listing date and on the confirmed-exploitation and public-PoC status the packet records, not on the CVE year. Second, the completion criterion is the reload: the packet records no live-patch mechanism for classic Cisco IOS/PIX and states that remediation is upgrading to a fixed IOS, IOS XE or IOS XR image, an operation that reboots the device. A router with the fixed image copied to flash but not yet booted from it is not remediated, and on a device terminating production tunnels the reload is precisely the step that gets deferred into an indefinite change window. Sequence the affected trains by whether the device's UDP/500 responder is reachable from untrusted networks, since the packet's attack requires nothing but the ability to send that one request. The clock does not end at the reload either — the packet ties the same remediation to rotating the pre-shared keys and certificates that may have been in the returned memory, so an SLA that closes on image version alone closes early.",
+        "evidence": "Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure Vulnerability, CISA KEV-listed 2023-05-19 with active exploitation confirmed and a public PoC available; CWE-200, CVSS 7.5, RWEP 70, patch available. The packet's live-patch record: no live-patch mechanism for classic Cisco IOS/PIX; remediation is upgrading to a Cisco fixed IOS/IOS XE/IOS XR image, which reboots the device, and pre-shared keys/certificates should be rotated after exposure. The packet's attack-vector record requires only a crafted IKEv1 Security Association negotiation request to UDP/500 from a remote unauthenticated attacker.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-21492": {
     "name": "Samsung Mobile Devices Insertion of Sensitive Information Into Log File Vulnerability",