@blamejs/exceptd-skills 0.19.15 → 0.19.17

package/data/zeroday-lessons.json

@@ -1,7 +1,7 @@
 {
   "_meta": {
     "schema_version": "1.1.0",
-    "last_updated": "2026-08-10",
+    "last_updated": "2026-08-11",
     "last_threat_review": "2026-05-17",
     "purpose": "Zero-day learning loop output. Each entry maps a CVE to: attack vector, defense chain analysis, framework coverage, new control requirements generated, and exposure scoring. v1.1.0 (2026-05-15): every entry now carries ai_discovered_zeroday boolean + ai_discovery_source enum + ai_discovery_date + ai_assist_factor ladder, per AGENTS.md Hard Rule #7.",
     "note": "Never delete entries. Closed gaps are marked status: closed. History is data.",
@@ -16039,7 +16039,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The asset on the clock for this CVE is not a server in the production estate: the packet puts the command execution on the developer host, reached through the React Native Community CLI's Metro development server, so the change-managed pipeline that patches production never sees the vulnerable component and the KEV clock has to be pointed at developer workstations and CI/build images explicitly. Requirement: from the 2026-02-05 KEV listing, every host and every build image that can start Metro reaches the fixed CLI release, with completion measured per host and per image rather than by a production deployment count. The packet registers no live-patch path and states the vendor patch typically requires a service restart or system reboot, so a Metro process still running from a pre-fix load remains exposed until it is stopped and restarted on the fixed release — a host where the package was updated while a dev server kept running is not remediated, and this is the specific way the completion count goes wrong on a machine a developer leaves running for days. Compensating control for the window before that completes, with its precondition stated: the packet's stated access requirement is a network attacker reaching the exposed dev server, so binding Metro to loopback and denying inbound connections to its port at the host firewall bounds who can send the POST. That lever exists only where the workflow does not need off-host reach — a physical test device, an emulator or simulator on another machine, or a teammate or CI runner loading the bundle all require the server to answer from the network, and on those hosts the restriction is simply unavailable. It also does not repair the endpoint: anything still permitted to reach the dev server reaches the command-injection path unchanged, and the packet records that on Windows the attacker additionally controls shell arguments in full. Reachability restriction is a holding measure for the window before the fixed release and its restart land, never the recorded remediation.",
+        "evidence": "Packet: CWE-78 OS command injection in the React Native Community CLI's Metro development server; unauthenticated network attackers send POST requests to the Metro Development Server and run arbitrary executables via a vulnerable endpoint exposed by the server, and on Windows can execute arbitrary shell commands with fully controlled arguments; the attack_vector places the execution on the developer host. cisa_kev true, kev_date 2026-02-05, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false with live_patch_notes recording no live-patch tool registered for this entry and a vendor patch that typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The verdict that goes wrong on this CVE is a developer-fleet scan reporting no vulnerable software present. What is vulnerable is a command-line development tool a developer runs inside a project, and the exposure exists only while that tool's Metro dev server is live and answering from the network — neither fact is visible to a scanner that enumerates installed products and OS patch level, so an estate can hold a clean report while a fully exploitable dev server is listening on the same LAN as the attacker. The operational test has two halves and both are required. First, enumerate every developer host and every CI/build image capable of starting Metro and show the React Native Community CLI each one resolves is at or above the fixed release, rather than showing that the workstation's operating system and registered applications are current. Second, with a project running on a representative developer host, send a POST to that host's Metro dev server port from a different host on the same network segment and confirm it is refused before any executable is invoked. The second half is the one the patch dashboard structurally cannot answer, and it is the half that corresponds to the packet's actual access requirement. Scope discipline matters here: the packet ties this CWE-78 sink to the React Native Community CLI's Metro development server and gives no basis for treating other frameworks' development servers as instances of this CVE, so the test population is hosts that run this CLI — widen it only where a verified source identifies another product carrying the same endpoint, because instructing operators to hunt every development server in the estate manufactures findings against tooling no evidence implicates. Limits: this control produces a truthful verdict, it does not remediate. The packet records a vendor patch with no live-patch path and a restart requirement, so hosts the test finds exposed still have to reach the fixed release and restart the dev server.",
+        "evidence": "Packet: the exploit requires unauthenticated network attackers to send POST requests to the Metro Development Server, an endpoint exposed by the React Native Community CLI on the developer host (CWE-78); on Windows the attacker also executes arbitrary shell commands with fully controlled arguments. cisa_kev true (2026-02-05), active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77, patch_available true, live_patch_available false with the vendor patch typically requiring service restart or system reboot.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2026-24423": {
     "name": "SmarterTools SmarterMail Missing Authentication for Critical Function Vulnerability",
@@ -18957,7 +18979,31 @@
     },
     "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": "ArrayOS AG is the operating system of a secure-access gateway, so the appliance the packet describes is not a server behind the perimeter — it is the perimeter, and the packet places an unauthenticated OS command-injection path on it with confirmed in-the-wild exploitation and a public exploit. That is the combination this tier exists for: a routine 14- or 30-day application patch window leaves the device that terminates untrusted remote access executing attacker-supplied commands for weeks, and no severity-band justification changes that, because the exposure is where the flaw sits rather than how it scores. For this CVE the clock runs from the 2025-12-08 KEV listing to the point where each Array Networks appliance running ArrayOS AG is on the vendor's fixed build and has taken the restart the fix requires; the packet registers no live-patch path and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so an appliance that has staged the fixed image but has not restarted still runs the vulnerable code and must be counted as exposed rather than as patched-pending-window. Scope this to the ArrayOS AG appliances the packet names; it gives no basis for treating other gateway products in the estate as instances of this flaw. Precondition on the tier's alternative, which is where this control is usually over-claimed: restricting which source networks can reach the appliance's exposed interface bounds who can send the injection, it does not repair it, and a secure-access gateway exists precisely to answer clients on untrusted networks — for an appliance publishing remote access to the internet there may be no source restriction that removes the path at all, only a reduction to the population that must be able to reach it, every member of which still satisfies the packet's stated access requirement of unauthenticated network reach.",
+        "evidence": "Packet fields for CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection Vulnerability, CWE-78): CISA KEV listed 2025-12-08, active_exploitation confirmed, poc_available true, CVSS 9.8, rwep_score 77. The attack_vector describes an OS command-injection flaw enabling unauthenticated remote command execution on the secure-access gateway appliance; the vector states ArrayOS AG contains an OS command injection vulnerability that could allow an attacker to execute arbitrary commands. patch_available true, live_patch_available false, with live_patch_notes stating no live-patch tool is registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet states this control's trigger condition outright: unauthenticated remote command execution on a perimeter secure-access gateway, KEV-listed 2025-12-08, active exploitation confirmed and a public exploit available. For any Array Networks appliance running ArrayOS AG that was reachable during the exposure window, the default response is therefore not upgrade-in-place. Capture the configuration and whatever logs the box still holds for forensics, rebuild the appliance from vendor media onto the fixed build, and rotate everything it held or brokered — local administrative accounts, the directory or RADIUS bind credentials it authenticated remote users against, its TLS server keys, and any session or token material issued to users through it — because arbitrary command execution as the appliance gave the attacker the same read of that material that the appliance itself had. The vendor fix closes the injection path; it removes nothing already written through it, so an added administrative account, a modified startup script or an implant on the filesystem survives the upgrade and is inherited by the 'remediated' device. This is also the honest answer to the least-privilege gap recorded against this entry: the attacker never authenticates as any gateway operator, so per-account privilege scoping is never consulted and a least-privilege attestation passes cleanly while the path stays fully open — the only privilege containment available after the fact is the rotation, because the blast radius is defined by what the appliance's own identity could reach, not by any user account. The distinguishing test is a records test rather than a scan: for every gateway remediated since the KEV listing, ask for the rebuild evidence and the credential-rotation record alongside the build number. An estate that can produce only 'upgraded to the fixed build' has a patched appliance that may still be attacker-held. Precondition: the scope of this response is set by an exposure-window determination, and the packet supplies no compromise indicator to clear an individual appliance against — so where reachability during the window cannot be excluded, the appliance is treated as compromised rather than cleared on the absence of an alert, and the on-box logs used to make that call are themselves writable by an attacker who held command execution.",
+        "evidence": "Packet fields for CVE-2025-66644: CWE-78, cisa_kev true with kev_date 2025-12-08, active_exploitation confirmed, poc_available true, CVSS 9.8, rwep_score 77. The attack_vector records unauthenticated remote command execution on the secure-access gateway appliance. patch_available true and live_patch_available false, with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. NIST SP 800-53 AC-6 (Least Privilege) and ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) are both recorded as citing framework gaps on this entry — the first is never consulted on an unauthenticated path, and the second closes at 'patch applied'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2025-55182": {
     "name": "Meta React Server Components Remote Code Execution Vulnerability",
@@ -19017,242 +19063,273 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
-  },
-  "CVE-2021-26828": {
-    "name": "OpenPLC ScadaBR Unrestricted Upload of File with Dangerous Type Vulnerability",
-    "lesson_date": "2026-05-29",
-    "attack_vector": {
-      "description": "an unrestricted file-upload flaw (CWE-434) on the ScadaBR SCADA/HMI web interface, letting an unauthenticated attacker upload a file (e.g. a web shell) for code execution on the HMI server. CISA KEV-listed 2025-12-03 with confirmed in-the-wild exploitation.",
-      "privileges_required": "none (the device is reachable by an unauthenticated attacker; exposure is amplified when the OT zone is not segmented)",
-      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
-      "ai_factor": "No AI involvement documented in discovery or weaponization."
-    },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Apply the vendor firmware/update where one exists; where the device cannot be patched, isolate it in a segmented OT zone (zones-and-conduits / Purdue model), block all IT and internet reachability, and restrict access to authenticated engineering workstations.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation) + IEC 62443-3-3",
-        "adequacy": "Patching is often impossible on OT; segmentation and access restriction are the real controls, and a flat or internet-exposed OT network defeats them."
-      },
-      "detection": {
-        "what_would_have_worked": "OT-network monitoring for unauthorized connections to the ScadaBR HMI, unexpected configuration/logic changes, and access from outside the device's intended zone.",
-        "was_this_required": false,
-        "framework_requiring_it": null,
-        "adequacy": "Necessary because unpatched OT devices may stay exploitable indefinitely; behavioral detection is the backstop."
-      },
-      "response": {
-        "what_would_have_worked": "Isolate the device, validate and restore its configuration/logic from a known-good baseline, rotate any credentials/keys it held, and investigate for safety-impacting manipulation; engage OT/safety engineering before any change.",
-        "was_this_required": true,
-        "framework_requiring_it": "NIST 800-82r3 + NIST 800-53 IR-4",
-        "adequacy": "Mandatory; OT compromise can have physical/safety consequences, so response must include process-integrity validation, not just IT cleanup."
-      }
-    },
-    "framework_coverage": {
-      "NIST-800-82r3-ICS": {
-        "covered": true,
-        "adequate": false,
-        "gap": "OT/ICS devices often cannot be patched on an IT cadence (availability and safety constraints, vendor re-certification), so the exposure window for a KEV-listed flaw is months-to-years; the standard treats patching as primary but for OT the load-bearing control is network segmentation and access restriction."
-      },
-      "IEC-62443-3-3-zones-conduits": {
-        "covered": true,
-        "adequate": false,
-        "gap": "Zones-and-conduits segmentation is required, but it is frequently unimplemented or bypassed (flat OT networks, internet-exposed HMIs/cameras/PLCs); the device itself is exploitable whenever it is reachable, and the standard does not force a compromised-device response plan."
-      },
-      "NIS2-Art21-OT": {
-        "covered": true,
-        "adequate": false,
-        "gap": "Treats OT/ICS as essential-function infrastructure but lacks a device-level compressed remediation expectation and does not address the reality that many OT devices are end-of-life or unpatchable and must be isolated rather than fixed."
-      },
-      "ISO-27001-2022-A.8.8": {
-        "covered": true,
-        "adequate": false,
-        "gap": "'Appropriate timescales' is undefined and ill-suited to OT, where patching may be impossible; compensating controls (segmentation, monitoring, restricted engineering-workstation access) carry the load and must be explicit."
-      }
-    },
-    "compliance_exposure_score": {
-      "percent_audit_passing_orgs_still_exposed": 82,
-      "basis": "OpenPLC ScadaBR is OT/ICS equipment that frequently cannot be patched on an IT cadence and is often reachable on flat or internet-exposed networks; audited organizations that rely on a patch SLA rather than enforced segmentation remain exposed for this KEV-listed, actively-exploited flaw.",
-      "theater_pattern": "patch_management"
-    },
-    "ai_discovered_zeroday": false,
-    "ai_discovery_source": "vendor_research",
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-118",
-        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
-        "description": "ScadaBR is an HMI web front end and has to be governed like one. The packet puts the upload-and-execute path at view_edit.shtm, so anything that can reach that page can reach JSP execution on the machine operators use to drive the process — the compromise lands on the supervisory host, not on a back-office web server. Put the ScadaBR interface on a segmented management plane rather than a flat plant network or a directly reachable address, and eliminate vendor-default or blank administrative accounts on every instance, because the packet's product description gates the upload behind a ScadaBR login and an unrotated default credential turns that gate into a formality. The distinguishing test: from a network segment with no operational need to reach the HMI, attempt to load view_edit.shtm — reachability alone is the finding, since past that point a single valid or default login yields code execution on the process-control host.",
-        "evidence": "The packet's vector states: 'OpenPLC ScadaBR contains an unrestricted upload of file with dangerous type vulnerability that allows remote authenticated users to upload and execute arbitrary JSP files via view_edit.shtm.' cwe_refs is CWE-434, cvss 8.8, rwep_score 77, cisa_kev true with kev_date 2025-12-03, active_exploitation 'confirmed', poc_available true. The packet's own citing gaps include NIS2-Art21-network-security ('Security of network and information systems') and UK-CAF-B4 ('System security').",
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The packet locates the defect in how React decodes payloads sent to React Server Function endpoints, which means the vulnerable code is React's own and an application's exposure is set by the React build linked into it — not by any entry an installed-software inventory would hold. In most deployments React is not the dependency the team declares: the application declares the server-rendering layer it builds on, and React arrives underneath that, so a supply-chain inventory that records only direct dependencies returns a clean answer for an application that is fully exploitable. Bound to this CVE, the control means the dependency inventory resolves and records, for every deployed application build, the React version actually linked into the artifact serving traffic, and that resolved record — not the top-level manifest — is what the vulnerability and KEV process queries. The packet also records that a second identifier, CVE-2025-66478, has been rejected but is associated with this entry, which is a further reason the inventory must be able to answer by component and version rather than only by a single CVE id. Distinguishing test: pick a deployed build rather than a repository, extract the React version from the artifact that is actually answering requests, and compare it to the fixed release — an estate that has merged the framework dependency bump in source while a built and deployed artifact still carries a pre-fix React remains exploitable with a patch attestation reading clean, and that divergence between source and artifact is the specific failure this control exists to surface. Precondition and limits: an inventory identifies which builds must be rebuilt, it does not remediate any of them. The packet registers no live-patch path and a vendor patch that typically requires a service restart, so each identified build must be rebuilt on the fixed React and the serving process restarted; a fixed artifact published but not rolled out is still serving the vulnerable decoder, and counting it as remediated is the same error one layer down.",
+        "evidence": "Packet: CWE-94 remote code execution in Meta React Server Components; unauthenticated remote code execution by exploiting a flaw in how React decodes payloads sent to React Server Function endpoints. The packet notes CVE-2025-66478 has been rejected but is associated with CVE-2025-55182. cisa_kev true, kev_date 2025-12-05, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 83. patch_available true; live_patch_available false, live_patch_notes record no live-patch tool registered and a vendor patch that typically requires service restart or system reboot per the KEV requiredAction.",
         "gap_closes": [
-          "NIS2-Art21-network-security",
-          "UK-CAF-B4"
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
         ]
       },
       {
         "id": "NEW-CTRL-001",
         "name": "CISA-KEV-RESPONSE-SLA",
-        "description": "The KEV clock for this entry runs against an HMI, where 'restart the service' is a process-availability decision rather than a maintenance chore — which is exactly why an unmodified KEV SLA gets waived on OT assets and the exposure persists. From the 2025-12-03 listing, the SLA must pre-authorize a ScadaBR restart window, because the packet records no live-patch tool and a vendor patch that typically requires a service restart or reboot; there is no in-place option that leaves the HMI running. Where the restart cannot be scheduled inside the window, the required output is a declared compensating control — blocking reachability to view_edit.shtm from anything but the operator segment — carried as an open, time-bound item, not an entry marked remediated on schedule.",
-        "evidence": "The packet records cisa_kev true with kev_date 2025-12-03, active_exploitation 'confirmed', poc_available true, cvss 8.8 and rwep_score 77 for CWE-434 on OpenPLC ScadaBR, with the upload path at view_edit.shtm. patch_available is true, live_patch_available is false, and live_patch_notes reads: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
-        "gap_closes": [
-          "ISO-27001-2022-A.8.8",
-          "NIST-800-53-SI-2"
-        ]
-      }
-    ]
-  },
-  "CVE-2025-48633": {
-    "name": "Android Framework Information Disclosure Vulnerability",
-    "lesson_date": "2026-05-29",
-    "attack_vector": {
-      "description": "an out-of-bounds read information-disclosure flaw (CWE-125) in the Android Framework, used by a local app as a primitive in a privilege-escalation chain (leaking memory to defeat ASLR for a follow-on exploit). CISA KEV-listed 2025-12-02 with confirmed in-the-wild exploitation; this class forms the local-escalation half of a mobile-spyware chain.",
-      "privileges_required": "low (a local app or the foothold from an initial-access primitive)",
-      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
-      "ai_factor": "No AI involvement documented in discovery or weaponization."
-    },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Apply the Android Security Bulletin OTA update promptly; enforce update SLAs via MDM on managed fleets, deploy mobile-threat-defense, and enable hardened/locked-down configurations for high-risk users.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
-        "adequacy": "The OTA fix is definitive; the gap is OEM/carrier patch reach and managed fleets that defer mobile updates."
-      },
-      "detection": {
-        "what_would_have_worked": "Mobile-threat-defense telemetry for unprivileged-to-elevated transitions and ASLR-defeating memory disclosure; vendor threat notifications for targeted users.",
-        "was_this_required": false,
-        "framework_requiring_it": null,
-        "adequacy": "Backstops unpatched devices; mobile-spyware chains are stealthy and frequently zero-click."
-      },
-      "response": {
-        "what_would_have_worked": "Force the OTA update; for a confirmed targeted device, preserve forensic state, rotate credentials and tokens stored on the device, and consider device replacement — spyware can persist across reboots.",
-        "was_this_required": true,
-        "framework_requiring_it": "NIST 800-53 IR-4",
-        "adequacy": "Mandatory for a KEV-listed mobile RCE/LPE; the exposure is every device that processed attacker content pre-patch."
-      }
-    },
-    "framework_coverage": {
-      "NIST-800-53-SI-2": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, actively-exploited mobile flaw; commercial-surveillance and spyware chains weaponize these within days, and patch reach depends on OEM/carrier OTA cadence well beyond the vendor's release date."
-      },
-      "ISO-27001-2022-A.8.8": {
-        "covered": true,
-        "adequate": false,
-        "gap": "'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited mobile OS flaw, and the OEM/carrier OTA chain means many devices receive the fix weeks-to-never after disclosure."
-      },
-      "AU-ISM-1546": {
-        "covered": true,
-        "adequate": false,
-        "gap": "Essential 8 patch-applications (operating systems) is the right tier, but the load-bearing controls for mobile are vendor OTA cadence (Android Security Bulletin / Samsung SMR), MDM-enforced update SLAs on managed fleets, mobile-threat-defense, and hardened/locked-down configurations for high-risk users — none of which the framework names explicitly."
-      }
-    },
-    "compliance_exposure_score": {
-      "percent_audit_passing_orgs_still_exposed": 71,
-      "basis": "Android update reach depends on OEM/carrier OTA cadence; audited organizations that do not enforce mobile update SLAs via MDM remain exposed for this KEV-listed, actively-exploited flaw long after the fix is published.",
-      "theater_pattern": "patch_management"
-    },
-    "ai_discovered_zeroday": false,
-    "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none",
-    "new_control_requirements": [
-      {
-        "id": "NEW-CTRL-126",
-        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "The Android Framework out-of-bounds read is closed only by advancing the handset's security-patch level, and the packet records no live-patch path - the device has to take the update and reboot. The MDM/EMM must read each managed device's security-patch level and block or quarantine handsets below the level carrying this Framework fix from organizational data, not merely surface the stale level on a dashboard. The second half matters more than usual here: the leak is consumed by a locally running app to defeat ASLR for the follow-on exploit, so devices that cannot yet update must also be prevented from installing untrusted or side-loaded apps - denying the local app that harvests the leak is the only mitigation available while the OEM update is out of reach. It is also the control that survives triage: at CVSS 5.5 this reads as a low-priority information disclosure, while the packet scores it RWEP 77 on confirmed in-the-wild use. Distinguishing test: enroll a device pinned below the fixing patch level and confirm it is denied protected resources.",
-        "evidence": "Packet vector: Android Framework contains an unspecified vulnerability that allows for information disclosure. attack_vector records an out-of-bounds read (CWE-125) in the Android Framework used by a local app as a primitive in a privilege-escalation chain, leaking memory to defeat ASLR for a follow-on exploit, and forming the local-escalation half of a mobile-spyware chain. CISA KEV-listed 2025-12-02, active_exploitation confirmed, PoC available, CVSS 5.5, RWEP 77. patch_available true; live_patch_available false, with live_patch_notes stating no live-patch tool is registered and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "description": "For this entry the compressed tier is justified by the packet rather than by the CVSS band alone: the path needs no credential and no user interaction, a public PoC exists, exploitation is confirmed in the wild, and the flaw sits on an endpoint the application exposes to untrusted callers by design. The requirement bound to this product: from the 2025-12-05 KEV listing, every application instance that serves React Server Function endpoints is rebuilt on the fixed React and rolled out, with completion measured by the version answering traffic rather than by a merged dependency bump or an approved change record. Because the packet registers no live-patch path and states the vendor patch typically requires a service restart or system reboot, the clock ends at the restart of the serving process — an instance holding a fixed artifact it has not yet restarted onto is still running the vulnerable decoder and must be counted as exposed. On the compensating-control half the honest answer is that the packet supports none for this path, and saying otherwise would be the worse outcome: the vulnerable decode happens on the application's own public request path, which has to keep answering unauthenticated requests for the application to function, so unlike a management interface there is no segment to restrict it to and no feature flag the packet identifies as removing the surface. If a request-filtering layer is proposed as an interim measure it must be demonstrated on a staging instance to reject the payload before the decode runs; a filter that has not been shown to see the decoded payload is not a compensating control and must not be recorded as one. Taking an affected instance out of service is the only interim state the packet's facts actually support, and the remediation remains the rebuilt, restarted application.",
+        "evidence": "Packet: unauthenticated remote code execution (CWE-94) via a flaw in how React decodes payloads sent to React Server Function endpoints in Meta React Server Components. cisa_kev true with kev_date 2025-12-05, 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, and the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
         "gap_closes": [
-          "AU-Essential-8-Patch",
-          "ISO-27001-2022-A.8.8",
           "NIST-800-53-SI-2",
-          "NIS2-Art21-patch-management"
-        ]
-      }
-    ]
-  },
-  "CVE-2025-48572": {
-    "name": "Android Framework Privilege Escalation Vulnerability",
-    "lesson_date": "2026-05-29",
-    "attack_vector": {
-      "description": "a privilege-escalation flaw (CWE-269) in the Android Framework, exploited by a local app to escalate privileges on the device (the local-escalation step after an initial-access primitive). CISA KEV-listed 2025-12-02 with confirmed in-the-wild exploitation; this class forms the local-escalation half of a mobile-spyware chain.",
-      "privileges_required": "low (a local app or the foothold from an initial-access primitive)",
-      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
-      "ai_factor": "No AI involvement documented in discovery or weaponization."
-    },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Apply the Android Security Bulletin OTA update promptly; enforce update SLAs via MDM on managed fleets, deploy mobile-threat-defense, and enable hardened/locked-down configurations for high-risk users.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
-        "adequacy": "The OTA fix is definitive; the gap is OEM/carrier patch reach and managed fleets that defer mobile updates."
-      },
-      "detection": {
-        "what_would_have_worked": "Mobile-threat-defense telemetry for unprivileged-to-elevated transitions and ASLR-defeating memory disclosure; vendor threat notifications for targeted users.",
-        "was_this_required": false,
-        "framework_requiring_it": null,
-        "adequacy": "Backstops unpatched devices; mobile-spyware chains are stealthy and frequently zero-click."
-      },
-      "response": {
-        "what_would_have_worked": "Force the OTA update; for a confirmed targeted device, preserve forensic state, rotate credentials and tokens stored on the device, and consider device replacement — spyware can persist across reboots.",
-        "was_this_required": true,
-        "framework_requiring_it": "NIST 800-53 IR-4",
-        "adequacy": "Mandatory for a KEV-listed mobile RCE/LPE; the exposure is every device that processed attacker content pre-patch."
-      }
-    },
-    "framework_coverage": {
-      "NIST-800-53-SI-2": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, actively-exploited mobile flaw; commercial-surveillance and spyware chains weaponize these within days, and patch reach depends on OEM/carrier OTA cadence well beyond the vendor's release date."
-      },
-      "ISO-27001-2022-A.8.8": {
-        "covered": true,
-        "adequate": false,
-        "gap": "'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited mobile OS flaw, and the OEM/carrier OTA chain means many devices receive the fix weeks-to-never after disclosure."
-      },
-      "AU-ISM-1546": {
-        "covered": true,
-        "adequate": false,
-        "gap": "Essential 8 patch-applications (operating systems) is the right tier, but the load-bearing controls for mobile are vendor OTA cadence (Android Security Bulletin / Samsung SMR), MDM-enforced update SLAs on managed fleets, mobile-threat-defense, and hardened/locked-down configurations for high-risk users — none of which the framework names explicitly."
-      }
-    },
-    "compliance_exposure_score": {
-      "percent_audit_passing_orgs_still_exposed": 71,
-      "basis": "Android update reach depends on OEM/carrier OTA cadence; audited organizations that do not enforce mobile update SLAs via MDM remain exposed for this KEV-listed, actively-exploited flaw long after the fix is published.",
-      "theater_pattern": "patch_management"
-    },
-    "ai_discovered_zeroday": false,
-    "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none",
-    "new_control_requirements": [
-      {
-        "id": "NEW-CTRL-056",
-        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
-        "description": "The packet calls the Android Framework flaw unspecified and places the trigger in a local app escalating privileges on the device, which leaves the operator no component to disable and no setting to change — the platform update carrying the fix is the entire remediation, so the only questions are how fast it lands and whether the user can decline it. For this CVE that means the managed-device policy pushes the update inside the clock that opened with the 2025-12-02 KEV listing, with user deferral disallowed and the restart enforced, because the packet records no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction: a handset that installed the update and never rebooted is still running the vulnerable framework and must be counted as exposed. Precondition, and it is the one that breaks this control on Android specifically: the operator can force installation only of a build the device's OEM or carrier has actually released for that model, so the SLA has two failure states that need separating — handsets that could have taken the update and were allowed to defer, which policy enforcement fixes, and models for which no fixed build has shipped, which policy cannot fix and which fall to the access-condition control below or to a replacement schedule. Distinguishing test: from the management console, list handsets by model and reported security patch level and show, per model, whether a fixed build exists and how many days elapsed between its availability and the device's restart onto it — an attestation that reports policy assignment is measuring the console, not the fleet.",
-        "evidence": "Packet vector: 'Android Framework contains an unspecified vulnerability that allows for privilege escalation.' attack_vector: 'a privilege-escalation flaw (CWE-269) in the Android Framework, exploited by a local app to escalate privileges on the device (the local-escalation step after an initial-access primitive).' Fields: cisa_kev true, kev_date 2025-12-02, active_exploitation confirmed, CVSS 7.8, RWEP 77, poc_available true, ai_discovered false, patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
-        "gap_closes": [
-          "AU-Essential-8-Patch",
-          "NIST-800-53-SI-2"
+          "NIS2-Art21-vulnerability-handling"
         ]
       },
       {
-        "id": "NEW-CTRL-126",
-        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
-        "description": "Because the packet records the vulnerability itself as unspecified and the trigger as a local app escalating privilege on the handset, the operator's only remaining levers on a device that cannot yet take the fixed build are what that device is allowed to reach and what code it is allowed to run. The fixed Android security patch level therefore has to function as an access condition — mail, VPN and document access denied to any enrolled handset below it — rather than as a column on a compliance dashboard, because a device below the fix that keeps its access is exactly the device this escalation is aimed at: the packet places this CVE as the local-escalation half of a mobile-spyware chain, so the payoff is the organizational data and credentials on the handset. Precondition: restricting installs to a managed catalogue and blocking side-loading raises the bar for getting the attacker's app onto the device, but it does not evict an app already installed and it does not cover one that arrived through the normal store channel — a handset suspected of already running the escalating app belongs on the incident path with credential rotation, not on the install-policy path. Distinguishing test: enrol a device pinned below the fixed patch level and confirm the conditional-access policy actually denies it the protected resources, instead of flagging it non-compliant while its mail keeps syncing. This is a holding measure for the window before the fixed build and its required reboot land, not a substitute for them.",
-        "evidence": "The packet's own description of the flaw is 'an unspecified vulnerability that allows for privilege escalation', with the exploitation path 'exploited by a local app to escalate privileges on the device' and the framing that 'this class forms the local-escalation half of a mobile-spyware chain'. patch_available true with live_patch_available false and live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so the interval this control covers is real and reboot-gated. active_exploitation confirmed; cisa_kev true, kev_date 2025-12-02; poc_available true; RWEP 77; CVSS 7.8; CWE-269.",
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The asset this control governs for this CVE is the application instance itself, not an appliance: it is the component that terminates untrusted requests, and the packet's path needs no credential and no user interaction — only the ability to send a payload to a React Server Function endpoint the application exposes. With active exploitation confirmed, a public PoC available, and the KEV listing dating to 2025-12-05, an instance that was reachable by an untrusted network while serving a pre-fix React during that window must default to the assume-compromise path: redeploy from a known-good build rather than upgrading the running instance in place, and rotate every secret and credential that application process could read. The upgrade closes the decode path; it removes nothing the attacker already placed and nothing already read. This is precisely the requirement the cited anti-malware control cannot meet — exploitation is code execution inside the application's own process, reached through an endpoint that is supposed to answer, so no file lands for signature scanning to match and a clean endpoint-protection report says nothing about whether this path was used. Preconditions, stated because this control is routinely over-applied: the assume-compromise default belongs to instances that were network-reachable on a pre-fix build during the exposure window, and does not extend to instances that were never reachable or that were already on the fixed release. Redeployment is a remediation only if the image being deployed carries the fixed React — rebuilding from the same pre-fix artifact reinstates the vulnerability while producing a rebuild record that reads like remediation. And rebuilding does nothing about material already exfiltrated: credentials the process held remain valid until they are rotated, which is why rotation is part of the requirement rather than a follow-up.",
+        "evidence": "Packet: unauthenticated remote code execution (CWE-94) in Meta React Server Components via a flaw in how React decodes payloads sent to React Server Function endpoints; active_exploitation confirmed; poc_available true; cisa_kev true with kev_date 2025-12-05; CVSS 9.8, RWEP 83. patch_available true, live_patch_available false, with the vendor patch typically requiring service restart or system reboot per the KEV requiredAction. The entry's citing framework gaps include CIS Controls v8 10.1 (Deploy and Maintain Anti-Malware Software).",
         "gap_closes": [
-          "ISO-27001-2022-A.8.8",
-          "NIS2-Art21-vulnerability-management",
-          "UK-CAF-B4"
+          "CIS-Controls-v8-10.1"
         ]
       }
     ]
   },
-  "CVE-2021-26829": {
-    "name": "OpenPLC ScadaBR Cross-site Scripting Vulnerability",
+  "CVE-2021-26828": {
+    "name": "OpenPLC ScadaBR Unrestricted Upload of File with Dangerous Type Vulnerability",
     "lesson_date": "2026-05-29",
     "attack_vector": {
-      "description": "a cross-site scripting flaw (CWE-79) on the ScadaBR SCADA/HMI web interface, letting an attacker run script in an operator's authenticated session. CISA KEV-listed 2025-11-28 with confirmed in-the-wild exploitation.",
+      "description": "an unrestricted file-upload flaw (CWE-434) on the ScadaBR SCADA/HMI web interface, letting an unauthenticated attacker upload a file (e.g. a web shell) for code execution on the HMI server. CISA KEV-listed 2025-12-03 with confirmed in-the-wild exploitation.",
+      "privileges_required": "none (the device is reachable by an unauthenticated attacker; exposure is amplified when the OT zone is not segmented)",
+      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
+      "ai_factor": "No AI involvement documented in discovery or weaponization."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Apply the vendor firmware/update where one exists; where the device cannot be patched, isolate it in a segmented OT zone (zones-and-conduits / Purdue model), block all IT and internet reachability, and restrict access to authenticated engineering workstations.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation) + IEC 62443-3-3",
+        "adequacy": "Patching is often impossible on OT; segmentation and access restriction are the real controls, and a flat or internet-exposed OT network defeats them."
+      },
+      "detection": {
+        "what_would_have_worked": "OT-network monitoring for unauthorized connections to the ScadaBR HMI, unexpected configuration/logic changes, and access from outside the device's intended zone.",
+        "was_this_required": false,
+        "framework_requiring_it": null,
+        "adequacy": "Necessary because unpatched OT devices may stay exploitable indefinitely; behavioral detection is the backstop."
+      },
+      "response": {
+        "what_would_have_worked": "Isolate the device, validate and restore its configuration/logic from a known-good baseline, rotate any credentials/keys it held, and investigate for safety-impacting manipulation; engage OT/safety engineering before any change.",
+        "was_this_required": true,
+        "framework_requiring_it": "NIST 800-82r3 + NIST 800-53 IR-4",
+        "adequacy": "Mandatory; OT compromise can have physical/safety consequences, so response must include process-integrity validation, not just IT cleanup."
+      }
+    },
+    "framework_coverage": {
+      "NIST-800-82r3-ICS": {
+        "covered": true,
+        "adequate": false,
+        "gap": "OT/ICS devices often cannot be patched on an IT cadence (availability and safety constraints, vendor re-certification), so the exposure window for a KEV-listed flaw is months-to-years; the standard treats patching as primary but for OT the load-bearing control is network segmentation and access restriction."
+      },
+      "IEC-62443-3-3-zones-conduits": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Zones-and-conduits segmentation is required, but it is frequently unimplemented or bypassed (flat OT networks, internet-exposed HMIs/cameras/PLCs); the device itself is exploitable whenever it is reachable, and the standard does not force a compromised-device response plan."
+      },
+      "NIS2-Art21-OT": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Treats OT/ICS as essential-function infrastructure but lacks a device-level compressed remediation expectation and does not address the reality that many OT devices are end-of-life or unpatchable and must be isolated rather than fixed."
+      },
+      "ISO-27001-2022-A.8.8": {
+        "covered": true,
+        "adequate": false,
+        "gap": "'Appropriate timescales' is undefined and ill-suited to OT, where patching may be impossible; compensating controls (segmentation, monitoring, restricted engineering-workstation access) carry the load and must be explicit."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 82,
+      "basis": "OpenPLC ScadaBR is OT/ICS equipment that frequently cannot be patched on an IT cadence and is often reachable on flat or internet-exposed networks; audited organizations that rely on a patch SLA rather than enforced segmentation remain exposed for this KEV-listed, actively-exploited flaw.",
+      "theater_pattern": "patch_management"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "vendor_research",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-118",
+        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
+        "description": "ScadaBR is an HMI web front end and has to be governed like one. The packet puts the upload-and-execute path at view_edit.shtm, so anything that can reach that page can reach JSP execution on the machine operators use to drive the process — the compromise lands on the supervisory host, not on a back-office web server. Put the ScadaBR interface on a segmented management plane rather than a flat plant network or a directly reachable address, and eliminate vendor-default or blank administrative accounts on every instance, because the packet's product description gates the upload behind a ScadaBR login and an unrotated default credential turns that gate into a formality. The distinguishing test: from a network segment with no operational need to reach the HMI, attempt to load view_edit.shtm — reachability alone is the finding, since past that point a single valid or default login yields code execution on the process-control host.",
+        "evidence": "The packet's vector states: 'OpenPLC ScadaBR contains an unrestricted upload of file with dangerous type vulnerability that allows remote authenticated users to upload and execute arbitrary JSP files via view_edit.shtm.' cwe_refs is CWE-434, cvss 8.8, rwep_score 77, cisa_kev true with kev_date 2025-12-03, active_exploitation 'confirmed', poc_available true. The packet's own citing gaps include NIS2-Art21-network-security ('Security of network and information systems') and UK-CAF-B4 ('System security').",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV clock for this entry runs against an HMI, where 'restart the service' is a process-availability decision rather than a maintenance chore — which is exactly why an unmodified KEV SLA gets waived on OT assets and the exposure persists. From the 2025-12-03 listing, the SLA must pre-authorize a ScadaBR restart window, because the packet records no live-patch tool and a vendor patch that typically requires a service restart or reboot; there is no in-place option that leaves the HMI running. Where the restart cannot be scheduled inside the window, the required output is a declared compensating control — blocking reachability to view_edit.shtm from anything but the operator segment — carried as an open, time-bound item, not an entry marked remediated on schedule.",
+        "evidence": "The packet records cisa_kev true with kev_date 2025-12-03, active_exploitation 'confirmed', poc_available true, cvss 8.8 and rwep_score 77 for CWE-434 on OpenPLC ScadaBR, with the upload path at view_edit.shtm. patch_available is true, live_patch_available is false, and live_patch_notes reads: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
+  },
+  "CVE-2025-48633": {
+    "name": "Android Framework Information Disclosure Vulnerability",
+    "lesson_date": "2026-05-29",
+    "attack_vector": {
+      "description": "an out-of-bounds read information-disclosure flaw (CWE-125) in the Android Framework, used by a local app as a primitive in a privilege-escalation chain (leaking memory to defeat ASLR for a follow-on exploit). CISA KEV-listed 2025-12-02 with confirmed in-the-wild exploitation; this class forms the local-escalation half of a mobile-spyware chain.",
+      "privileges_required": "low (a local app or the foothold from an initial-access primitive)",
+      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
+      "ai_factor": "No AI involvement documented in discovery or weaponization."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Apply the Android Security Bulletin OTA update promptly; enforce update SLAs via MDM on managed fleets, deploy mobile-threat-defense, and enable hardened/locked-down configurations for high-risk users.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
+        "adequacy": "The OTA fix is definitive; the gap is OEM/carrier patch reach and managed fleets that defer mobile updates."
+      },
+      "detection": {
+        "what_would_have_worked": "Mobile-threat-defense telemetry for unprivileged-to-elevated transitions and ASLR-defeating memory disclosure; vendor threat notifications for targeted users.",
+        "was_this_required": false,
+        "framework_requiring_it": null,
+        "adequacy": "Backstops unpatched devices; mobile-spyware chains are stealthy and frequently zero-click."
+      },
+      "response": {
+        "what_would_have_worked": "Force the OTA update; for a confirmed targeted device, preserve forensic state, rotate credentials and tokens stored on the device, and consider device replacement — spyware can persist across reboots.",
+        "was_this_required": true,
+        "framework_requiring_it": "NIST 800-53 IR-4",
+        "adequacy": "Mandatory for a KEV-listed mobile RCE/LPE; the exposure is every device that processed attacker content pre-patch."
+      }
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, actively-exploited mobile flaw; commercial-surveillance and spyware chains weaponize these within days, and patch reach depends on OEM/carrier OTA cadence well beyond the vendor's release date."
+      },
+      "ISO-27001-2022-A.8.8": {
+        "covered": true,
+        "adequate": false,
+        "gap": "'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited mobile OS flaw, and the OEM/carrier OTA chain means many devices receive the fix weeks-to-never after disclosure."
+      },
+      "AU-ISM-1546": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Essential 8 patch-applications (operating systems) is the right tier, but the load-bearing controls for mobile are vendor OTA cadence (Android Security Bulletin / Samsung SMR), MDM-enforced update SLAs on managed fleets, mobile-threat-defense, and hardened/locked-down configurations for high-risk users — none of which the framework names explicitly."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 71,
+      "basis": "Android update reach depends on OEM/carrier OTA cadence; audited organizations that do not enforce mobile update SLAs via MDM remain exposed for this KEV-listed, actively-exploited flaw long after the fix is published.",
+      "theater_pattern": "patch_management"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "vendor_research",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The Android Framework out-of-bounds read is closed only by advancing the handset's security-patch level, and the packet records no live-patch path - the device has to take the update and reboot. The MDM/EMM must read each managed device's security-patch level and block or quarantine handsets below the level carrying this Framework fix from organizational data, not merely surface the stale level on a dashboard. The second half matters more than usual here: the leak is consumed by a locally running app to defeat ASLR for the follow-on exploit, so devices that cannot yet update must also be prevented from installing untrusted or side-loaded apps - denying the local app that harvests the leak is the only mitigation available while the OEM update is out of reach. It is also the control that survives triage: at CVSS 5.5 this reads as a low-priority information disclosure, while the packet scores it RWEP 77 on confirmed in-the-wild use. Distinguishing test: enroll a device pinned below the fixing patch level and confirm it is denied protected resources.",
+        "evidence": "Packet vector: Android Framework contains an unspecified vulnerability that allows for information disclosure. attack_vector records an out-of-bounds read (CWE-125) in the Android Framework used by a local app as a primitive in a privilege-escalation chain, leaking memory to defeat ASLR for a follow-on exploit, and forming the local-escalation half of a mobile-spyware chain. CISA KEV-listed 2025-12-02, active_exploitation confirmed, PoC available, CVSS 5.5, RWEP 77. patch_available true; live_patch_available false, with live_patch_notes stating no live-patch tool is registered and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
+  },
+  "CVE-2025-48572": {
+    "name": "Android Framework Privilege Escalation Vulnerability",
+    "lesson_date": "2026-05-29",
+    "attack_vector": {
+      "description": "a privilege-escalation flaw (CWE-269) in the Android Framework, exploited by a local app to escalate privileges on the device (the local-escalation step after an initial-access primitive). CISA KEV-listed 2025-12-02 with confirmed in-the-wild exploitation; this class forms the local-escalation half of a mobile-spyware chain.",
+      "privileges_required": "low (a local app or the foothold from an initial-access primitive)",
+      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
+      "ai_factor": "No AI involvement documented in discovery or weaponization."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Apply the Android Security Bulletin OTA update promptly; enforce update SLAs via MDM on managed fleets, deploy mobile-threat-defense, and enable hardened/locked-down configurations for high-risk users.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
+        "adequacy": "The OTA fix is definitive; the gap is OEM/carrier patch reach and managed fleets that defer mobile updates."
+      },
+      "detection": {
+        "what_would_have_worked": "Mobile-threat-defense telemetry for unprivileged-to-elevated transitions and ASLR-defeating memory disclosure; vendor threat notifications for targeted users.",
+        "was_this_required": false,
+        "framework_requiring_it": null,
+        "adequacy": "Backstops unpatched devices; mobile-spyware chains are stealthy and frequently zero-click."
+      },
+      "response": {
+        "what_would_have_worked": "Force the OTA update; for a confirmed targeted device, preserve forensic state, rotate credentials and tokens stored on the device, and consider device replacement — spyware can persist across reboots.",
+        "was_this_required": true,
+        "framework_requiring_it": "NIST 800-53 IR-4",
+        "adequacy": "Mandatory for a KEV-listed mobile RCE/LPE; the exposure is every device that processed attacker content pre-patch."
+      }
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, actively-exploited mobile flaw; commercial-surveillance and spyware chains weaponize these within days, and patch reach depends on OEM/carrier OTA cadence well beyond the vendor's release date."
+      },
+      "ISO-27001-2022-A.8.8": {
+        "covered": true,
+        "adequate": false,
+        "gap": "'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited mobile OS flaw, and the OEM/carrier OTA chain means many devices receive the fix weeks-to-never after disclosure."
+      },
+      "AU-ISM-1546": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Essential 8 patch-applications (operating systems) is the right tier, but the load-bearing controls for mobile are vendor OTA cadence (Android Security Bulletin / Samsung SMR), MDM-enforced update SLAs on managed fleets, mobile-threat-defense, and hardened/locked-down configurations for high-risk users — none of which the framework names explicitly."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 71,
+      "basis": "Android update reach depends on OEM/carrier OTA cadence; audited organizations that do not enforce mobile update SLAs via MDM remain exposed for this KEV-listed, actively-exploited flaw long after the fix is published.",
+      "theater_pattern": "patch_management"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "vendor_research",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet calls the Android Framework flaw unspecified and places the trigger in a local app escalating privileges on the device, which leaves the operator no component to disable and no setting to change — the platform update carrying the fix is the entire remediation, so the only questions are how fast it lands and whether the user can decline it. For this CVE that means the managed-device policy pushes the update inside the clock that opened with the 2025-12-02 KEV listing, with user deferral disallowed and the restart enforced, because the packet records no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction: a handset that installed the update and never rebooted is still running the vulnerable framework and must be counted as exposed. Precondition, and it is the one that breaks this control on Android specifically: the operator can force installation only of a build the device's OEM or carrier has actually released for that model, so the SLA has two failure states that need separating — handsets that could have taken the update and were allowed to defer, which policy enforcement fixes, and models for which no fixed build has shipped, which policy cannot fix and which fall to the access-condition control below or to a replacement schedule. Distinguishing test: from the management console, list handsets by model and reported security patch level and show, per model, whether a fixed build exists and how many days elapsed between its availability and the device's restart onto it — an attestation that reports policy assignment is measuring the console, not the fleet.",
+        "evidence": "Packet vector: 'Android Framework contains an unspecified vulnerability that allows for privilege escalation.' attack_vector: 'a privilege-escalation flaw (CWE-269) in the Android Framework, exploited by a local app to escalate privileges on the device (the local-escalation step after an initial-access primitive).' Fields: cisa_kev true, kev_date 2025-12-02, active_exploitation confirmed, CVSS 7.8, RWEP 77, poc_available true, ai_discovered false, patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Because the packet records the vulnerability itself as unspecified and the trigger as a local app escalating privilege on the handset, the operator's only remaining levers on a device that cannot yet take the fixed build are what that device is allowed to reach and what code it is allowed to run. The fixed Android security patch level therefore has to function as an access condition — mail, VPN and document access denied to any enrolled handset below it — rather than as a column on a compliance dashboard, because a device below the fix that keeps its access is exactly the device this escalation is aimed at: the packet places this CVE as the local-escalation half of a mobile-spyware chain, so the payoff is the organizational data and credentials on the handset. Precondition: restricting installs to a managed catalogue and blocking side-loading raises the bar for getting the attacker's app onto the device, but it does not evict an app already installed and it does not cover one that arrived through the normal store channel — a handset suspected of already running the escalating app belongs on the incident path with credential rotation, not on the install-policy path. Distinguishing test: enrol a device pinned below the fixed patch level and confirm the conditional-access policy actually denies it the protected resources, instead of flagging it non-compliant while its mail keeps syncing. This is a holding measure for the window before the fixed build and its required reboot land, not a substitute for them.",
+        "evidence": "The packet's own description of the flaw is 'an unspecified vulnerability that allows for privilege escalation', with the exploitation path 'exploited by a local app to escalate privileges on the device' and the framing that 'this class forms the local-escalation half of a mobile-spyware chain'. patch_available true with live_patch_available false and live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so the interval this control covers is real and reboot-gated. active_exploitation confirmed; cisa_kev true, kev_date 2025-12-02; poc_available true; RWEP 77; CVSS 7.8; CWE-269.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
+  },
+  "CVE-2021-26829": {
+    "name": "OpenPLC ScadaBR Cross-site Scripting Vulnerability",
+    "lesson_date": "2026-05-29",
+    "attack_vector": {
+      "description": "a cross-site scripting flaw (CWE-79) on the ScadaBR SCADA/HMI web interface, letting an attacker run script in an operator's authenticated session. CISA KEV-listed 2025-11-28 with confirmed in-the-wild exploitation.",
       "privileges_required": "none (the device is reachable by an unauthenticated attacker; exposure is amplified when the OT zone is not segmented)",
       "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
       "ai_factor": "No AI involvement documented in discovery or weaponization."
@@ -20024,7 +20101,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "CWP Control Web Panel is the constrained user surface this control governs, and the packet places the defect exactly where the control forbids it: shell metacharacters supplied in the t_total parameter of a filemanager changePerm request reach a shell, so a request-supplied string on the panel's file-manager surface is what selects the command the server runs. Bound to this product the control means the panel's privileged filesystem operations — changing permissions on a hosted account's files is one of them — sit behind their own authorization boundary and are invoked through an argv-array interface, so no parameter of a file-manager request can extend the command line, and the panel authorizes the caller before the operation runs rather than relying on a check the request path reaches afterwards. This is also why the least-privilege gap recorded on this entry does not close the path: the packet's stated access requirement is knowing a valid non-root username, not holding that user's session, so the attacker never authenticates as any panel account, per-account privilege scoping is never consulted, and an AC-6 attestation passes cleanly while an unauthenticated caller reaches the shell. Distinguishing test: from an unauthenticated client against a staging CWP instance, send a filemanager changePerm request whose t_total value carries shell metacharacters and confirm it is refused before any command runs. Precondition: the vendor update is what repairs the endpoint — this control states the property to verify, it does not implement it. Until that update and its restart land, restricting which networks may reach the panel's web surface bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted range, and it is unavailable where the panel must stay reachable for hosted-account administration.",
+        "evidence": "Packet vector: 'CWP Control Web Panel (formerly CentOS Web Panel) contains an OS command Injection vulnerability that allows unauthenticated remote code execution via shell metacharacters in the t_total parameter in a filemanager changePerm request. A valid non-root username must be known.' CWE-78. CISA KEV listed 2025-11-04; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. NIST SP 800-53 AC-6 (Least Privilege) is recorded among this entry's citing framework gaps. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A CWP server answers unauthenticated callers by design and the packet's path ends in command execution on it, so the control's premise holds here without any appliance framing: the exploit needs no credential, only a known non-root username, and the packet records a public PoC with confirmed in-the-wild exploitation. Any instance that was reachable by untrusted callers before the update landed therefore has to be treated as one that may already have run attacker commands. For this product the runbook is to capture the panel and server configuration and the hosted-account inventory, rebuild the host from a known-good image, and rotate everything the panel held or could reach — panel administrator credentials, hosted-account and database passwords, and any API keys stored on it — rather than applying the update in place. Patch-in-place closes the changePerm injection and removes nothing written through it: a web shell under a hosted document root, an added cron entry, or an attacker-created account survives the upgrade intact, and none of those are what a build-version check inspects. Precondition: this is the response for an instance whose reachable window overlapped the exploitation the packet records; an instance that can be shown to have been unreachable by untrusted callers throughout is a straightforward patch item. Either way the packet registers no live-patch path, so the vendor fix carries the service restart or system reboot, and a server updated but not restarted is not yet remediated.",
+        "evidence": "Packet attack vector: 'an OS command-injection flaw (CWE-78) enabling unauthenticated remote command execution on the hosting-control server. CISA KEV-listed 2025-11-04 with confirmed in-the-wild exploitation.' Vector states exploitation requires only that 'A valid non-root username must be known.' active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "CWP ships and updates on its own vendor channel, so a remediation programme whose patch obligation is written as operating-system patching never schedules this update at all — the host's OS package inventory stays current on every report while the panel that answers unauthenticated requests stays on the vulnerable build. For this CVE the clock runs from the KEV listing of 2025-11-04, with a public PoC and confirmed exploitation already in hand at that date, and completion has to be measured per host by the CWP build actually running rather than by an approved change record. The packet registers no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a server that took the update without restarting still runs the vulnerable code and must be counted as exposed until it does — on a shared hosting box that restart is also the step most likely to be deferred, because taking it interrupts every hosted site, and a deferral recorded as 'patched' is the specific way this remediation goes wrong.",
+        "evidence": "CISA KEV listed 2025-11-04; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77; CWE-78. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps on this entry include ASD Essential Eight 'Patch operating systems' and NIST SP 800-53 SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-11371": {
     "name": "Gladinet CentreStack and Triofox Files or Directories Accessible to External Parties Vulnerability",
@@ -20321,7 +20430,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "DELMIA Apriso is the manufacturing-operations server the packet names, and the packet puts unauthenticated remote code execution on it with confirmed in-the-wild exploitation and a public PoC. Applying the Dassault update closes the CWE-94 injection path and says nothing about what ran on the server while it was open, which is why the disposition for any Apriso instance that was reachable from an untrusted network on a vulnerable build is compromised-until-shown-otherwise rather than patched-therefore-clear. Applied to this product: capture and diff the Apriso application directories and configuration against known-good rather than closing on a post-update version check; hunt for content the application serves or executes that no sanctioned deployment placed there, because a web shell dropped through this path is application content rather than product code and the vendor update leaves it running; and rotate what the instance held — its application secrets and service credentials, including the accounts it uses to reach the systems on either side of it, since an MES exists to broker between the business layer and the plant floor and those credentials are the pivot code execution hands over. Extend the review to the manufacturing-operations data the server governs, because an integrity change made there survives the patch, produces no malware artefact, and is the outcome that matters on an OT-adjacent asset. Precondition: this disposition applies to instances whose exposure during the vulnerable window cannot be excluded; an instance that provably never answered an untrusted caller on a vulnerable build takes the vendor update on the KEV clock instead. Rebuilding or cleaning is not relief from the update — the instance must end up on the fixed build, and the packet records no live-patch path and a fix that typically requires a service restart or system reboot, so it is not remediated until that restart is taken.",
+        "evidence": "Packet fields for this entry: attack_vector 'a code-injection flaw (CWE-94) enabling unauthenticated remote code execution on the manufacturing-operations server. CISA KEV-listed 2025-10-28 with confirmed in-the-wild exploitation'; vector 'Dassault Systemes DELMIA Apriso contains a code injection vulnerability that could allow an attacker to execute arbitrary code'; cwe_refs CWE-94; cisa_kev true, kev_date 2025-10-28, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77; patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling) are recorded as citing gaps. The entry's own defense_chain records the cleanup requirement: prevention 'Apply the Dassault DELMIA Apriso update; hunt for web shells and rotate service credentials. DELMIA Apriso sits in the manufacturing-operations layer, so treat compromise as OT-adjacent', with adequacy 'Patch is necessary but, for these RCE/auth-bypass flaws, insufficient alone - web shells and stolen credentials survive the patch and require explicit cleanup', and response 'review data and downstream systems reachable from the DELMIA Apriso; assume compromise of accounts and managed endpoints in its reach' with adequacy 'patch-in-place without key rotation / web-shell hunting leaves the attacker resident or able to re-authenticate'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock for this entry opened on the 2025-10-28 KEV listing, and for this product the hard part is what the fix costs: the packet records a vendor patch, live_patch_available false, and live_patch_notes stating the patch typically requires a service restart or system reboot per the KEV requiredAction. A manufacturing-operations server's restarts are scheduled against the production plan rather than against a vulnerability clock, so the specific way this remediation goes wrong is an Apriso instance where the update is installed and the restart is deferred to the next planned line stoppage — that instance is still running the vulnerable code and has to be counted as exposed, not as patched. Completion is therefore measured per Apriso instance from the build actually running after restart, not from an approved or downloaded state in the deployment console. Where the restart genuinely cannot be taken inside the window, this control's own alternative applies and must be recorded as what it is: documented compensating controls carrying a dated action item, an interim state rather than an SLA exception that closes the finding. Precondition on that interim, because it is where it gets over-claimed: the packet establishes the flaw as reachable by an unauthenticated attacker, so restricting which segments can reach the Apriso application interface bounds who can deliver the injection and nothing more — anything inside a permitted segment still reaches the CWE-94 sink, and no account-side or credential-side measure applies at all, because no account is used to get there.",
+        "evidence": "Packet fields for this entry: cisa_kev true with kev_date 2025-10-28, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77; cwe_refs CWE-94; attack_vector 'a code-injection flaw (CWE-94) enabling unauthenticated remote code execution on the manufacturing-operations server'; patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and UK-CAF-B4 (System security) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-6205": {
     "name": "Dassault Systèmes DELMIA Apriso Missing Authorization Vulnerability",
@@ -20719,7 +20851,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry is the case the control exists for, and the packet states both halves. patch_available is true — a fixed build carrying this JavaScriptCore fix exists — and the vector itself states that the impacted product could be end-of-life and/or end-of-service and that users should discontinue product utilization. Those facts together define the requirement: on a unit whose hardware can still take an Apple security update, reaching the fixed build is an interim state; on a unit that can no longer take one, the terminal state is removal or replacement, because that device is exposed not only to this code-execution flaw but to everything found in that engine since its last build. Scope to what the packet names — macOS, iOS, tvOS, Safari and watchOS — and inventory those. The packet ties the CWE-94 sink to JavaScriptCore in those products and gives no mapping into other vendors' browsers or other software that embeds a web engine, so treating every renderer in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. In operational terms: enumerate every macOS, iOS, tvOS, watchOS and Safari install that renders untrusted web content, record for each whether its hardware can still receive a build carrying the fix, put those on the interim clock against the 2025-10-20 KEV listing, and put the rest on a dated replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a device that downloaded the update but has not restarted still runs the vulnerable code and is not remediated. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet fields for this entry: name 'Apple Multiple Products Unspecified Vulnerability', CWE-94. Vector: 'Apple macOS, iOS, tvOS, Safari, and watchOS contain an unspecified vulnerability in JavaScriptCore that when processing web content may lead to arbitrary code execution. The impacted product could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' cisa_kev true with kev_date 2025-10-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-patch-management (Vulnerability handling and disclosure) are recorded as citing gaps against this entry — every one of them measures whether a fix was applied within a timescale, and none of them has a terminal state for a device on which no future fix will ever be installable.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The population this control has to bite on for this entry is the one the decommission requirement produces: macOS, iOS, tvOS, watchOS and Safari installs that cannot reach a build carrying the JavaScriptCore fix. For those there is no future build that clears them, so the fixed build has to function as an access condition — organizational mail, VPN, document stores and identity access denied to a device below it — rather than as a stale row on a patch-compliance dashboard that ages indefinitely. The same condition covers the shorter window on devices that can take the fix: the packet records that the vendor patch typically requires a restart, so a device between download and restart is still in the exposed population and needs an access-side answer, not a patch-side one. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its mail and VPN has recorded the exposure rather than removed it. Precondition, and it is the reason this cannot be logged as the mitigation: an access condition bounds what an attacker gains from a compromised device, it does nothing to the device itself. It does not remove the JavaScriptCore defect, does not evict an implant on a device already compromised — and the packet's note that Apple flaws of this class are typically used in targeted-spyware chains makes that the case to plan for — and it reaches only devices the management channel enrols. Personally-owned or unenrolled Macs, iPhones, Apple TVs and Watches touching organizational data are not covered by it, and the only lever against those is removing the access path they use.",
+        "evidence": "Packet fields for this entry: CWE-94 code execution in JavaScriptCore across Apple macOS, iOS, tvOS, Safari and watchOS, with the vector stating the flaw 'when processing web content may lead to arbitrary code execution' and that the impacted product could be end-of-life and/or end-of-service. cisa_kev true, kev_date 2025-10-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' attack_vector adds that Apple zero-days of this class are typically used in targeted-spyware chains. AU-Essential-8-Patch (Patch operating systems) and UK-CAF-B4 (System security) are recorded as citing gaps against this entry; both score patch cadence and system-protection policy rather than making the fixed build a precondition of access.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The delivery path the packet records is attacker-controlled web content processed by JavaScriptCore, and its attack_vector notes that Apple flaws of this class are typically used in targeted-spyware chains. For the cohort plausibly inside that targeting set — executives, journalists, legal and security staff — the reboot-gated update is not fast enough on its own, so place their macOS and iOS devices in Apple's reduced-attack-surface mode, where untrusted web content, message attachments, link previews and fonts are not processed automatically. That narrows the path into the CWE-94 sink during the window that opened before anyone in the estate learned of the flaw: the packet records confirmed exploitation and a public PoC, so the exposure predates the 2025-10-20 KEV listing and the assignment cannot be a reaction to it. The mode only helps if it was already on when the content arrived, which makes it a standing posture assigned to the high-risk cohort ahead of the next disclosure rather than a response to this one. Preconditions, and they bound this tightly. The mode reduces what is processed automatically; it does not repair JavaScriptCore, and content the user deliberately chooses to load in a still-permitted path still reaches the engine. It gives nothing against a device already compromised — a device in this cohort that rendered untrusted content while exposed belongs on the incident path, not the hardening path. And on a device the decommission requirement identifies as unable to reach the fixed build, this is the only remaining lever and it is a holding measure until that device is replaced, not a substitute for replacing it.",
+        "evidence": "Packet fields for this entry: vector 'Apple macOS, iOS, tvOS, Safari, and watchOS contain an unspecified vulnerability in JavaScriptCore that when processing web content may lead to arbitrary code execution', CWE-94. attack_vector: 'a code-execution flaw (CWE-94) reachable via attacker-controlled web/media content. CISA KEV-listed 2025-10-20 with confirmed in-the-wild exploitation (Apple zero-days of this class are typically used in targeted-spyware chains).' cisa_kev true, kev_date 2025-10-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 77. patch_available true, live_patch_available false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot. UK-CAF-B4 (System security) is recorded as a citing gap against this entry; it addresses protection of deployed systems but names no reduced-attack-surface posture for a targeted cohort during the period before a reboot-gated fix lands.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-2746": {
     "name": "Kentico Xperience CMS Authentication Bypass Using an Alternate Path or Channel Vulnerability",
@@ -21095,7 +21260,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives AEM Forms on JEE an unauthenticated remote code-execution path, confirmed in-the-wild exploitation, a public PoC and a KEV listing dated 2025-10-15, so for any instance that was network-reachable by untrusted callers before the update landed the question remediation must answer is not whether the flaw is closed but whether something already ran. On a JEE deployment the artifacts that outlive the patch are ordinary parts of the platform: a deployed application archive, a JSP or class file written under the application server's document or work directories, a scheduled job, or a credential lifted from the server's configuration. The vendor update removes none of them and a build-version check inspects none of them. The requirement for this product is therefore to capture the AEM Forms configuration and deployed-application inventory, rebuild the server from a known-good image, and rotate the credentials that instance held — application-server administrative accounts, repository and datastore credentials, and any service identity it authenticates as — instead of updating in place. Precondition: this applies to instances whose reachable window overlapped the exploitation the packet records; where an instance can be shown to have been unreachable by untrusted callers throughout, the vendor update on its own is the proportionate response. Either way the packet registers no live-patch path, so the fix carries the service restart or system reboot the vendor requires, and an instance updated but not restarted is not yet remediated.",
+        "evidence": "Packet vector: 'Adobe Experience Manager Forms in JEE contains an unspecified vulnerability that allows for arbitrary code execution.' Attack vector: 'a code-execution flaw (CWE-94) enabling unauthenticated remote code execution on the AEM Forms server. CISA KEV-listed 2025-10-15 with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available true; CVSS 8.8; RWEP 77. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "AEM Forms on JEE runs inside an enterprise application server whose restarts are normally negotiated into a change window, and the packet states the vendor patch typically requires a service restart or system reboot with no live-patch tool registered — so the specific way this remediation fails is an instance that has taken the update but not restarted being recorded as patched while it still runs the vulnerable code. The clock for this CVE runs from the KEV listing of 2025-10-15, with a public PoC and confirmed exploitation already in hand at that date, and completion has to be measured per instance by the build running after the restart rather than by a deployment ticket being closed. Enumerate the JEE Forms instances specifically rather than treating this as an estate-wide Experience Manager item: the packet names Adobe Experience Manager Forms in JEE as the affected product and ties the code-execution path to nothing else, so widening the remediation to every Experience Manager deployment manufactures work against software this entry does not implicate — widen it only where a verified source identifies another deployment carrying the same component. Because the path needs no authentication, priority follows reachability: instances that untrusted callers can reach are the population to take first.",
+        "evidence": "Packet names the affected product as 'Adobe Experience Manager Forms in JEE' with 'an unspecified vulnerability that allows for arbitrary code execution' (CWE-94), reachable per the attack vector as 'unauthenticated remote code execution on the AEM Forms server'. CISA KEV listed 2025-10-15; active_exploitation confirmed; poc_available true; CVSS 8.8; RWEP 77. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps include ASD Essential Eight 'Patch operating systems' and NIST SP 800-53 SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-47827": {
     "name": "IGEL OS Use of a Key Past its Expiration Date Vulnerability",
@@ -21391,7 +21579,37 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The packet puts this defect in how the SKYSEA Client View management console program processes authentication on its TCP connection, and the outcome it records is an unauthenticated attacker bypassing that authentication, reaching privileged functionality and executing code. That is a fronting authentication step failing open, which is exactly the pattern this control governs: each privileged operation the management console exposes must authorize its own caller rather than inheriting a verdict from the connection-level authentication that precedes it, and the console's surface must be positioned so an untrusted caller cannot present a connection to it at all. This is also why the identity-and-access and least-privilege controls cited as insufficient on this entry can pass their attestations while the path stays wide open — the attacker never holds a SKYSEA operator account, so per-account privilege scoping is never consulted and the account model an identity review examines is bypassed rather than abused. Precondition: the per-function authorization is a property of the vendor's fixed build; this control states what to verify, it does not implement it. The packet records no live-patch path and a vendor patch that typically requires a service restart or system reboot, so a console whose package is updated but whose service has not been restarted is still running the vulnerable authentication handling and is not yet remediated. Distinguishing test: from a host with no management role, connect to a staging console and invoke each privileged function without authenticating, confirming each is refused before it runs.",
+        "evidence": "Packet: CWE-287 improper authentication; the vector states SKYSEA Client View \"contains an improper authentication vulnerability that allows remote code execution via a flaw in processing authentication on the TCP connection with the management console program\", and attack_vector describes an unauthenticated attacker bypassing authentication to reach privileged functionality. The entry cites UK CAF B2 (identity and access control) and NIST 800-53 AC-6 (least privilege) among the insufficient controls, neither of which the unauthenticated path engages. CVSS 9.8, RWEP 77, poc_available true, active_exploitation confirmed, CISA KEV-listed 2025-10-14. patch_available true; live_patch_available false, with the vendor patch typically requiring a service restart or system reboot.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The packet places the flaw on the TCP connection with the management console program — a non-HTTP listener that answers and processes authentication before the caller is authenticated, which is the class this control governs and the class a perimeter firewall and web-tier hardening never touch. For this deployment the requirement is that the SKYSEA console listener accept connections only from hosts that legitimately speak that protocol — the management servers and the endpoints they administer — enforced by network ACL or host firewall, rather than left reachable from any internal segment on the assumption that client-management software is internal by nature. With confirmed exploitation, a public exploit and a KEV listing on 2025-10-14 for an identifier issued in 2016, the vendor update and the service restart or reboot the packet says it requires belong on the KEV clock rather than in the next asset-management maintenance window. Precondition, stated plainly because it is where this control is usually over-claimed: an ACL bounds who can open the connection, it does not repair the authentication handling. Any compromised workstation, contractor laptop or jump host inside the permitted segment still reaches the vulnerable path, and on an estate where the console must accept connections from every managed endpoint, the permitted segment is effectively the estate — which leaves the update as the only measure that closes anything.",
+        "evidence": "Packet: attack_vector describes an improper-authentication flaw (CWE-287) in the SKYSEA Client View management server letting an unauthenticated attacker bypass authentication and reach privileged functionality, with the vector locating the flaw in authentication processing on the TCP connection with the management console program. CISA KEV-listed 2025-10-14 with active_exploitation confirmed and poc_available true; the entry cites NIS2 Art. 21 security of network and information systems as an insufficient control. patch_available true, live_patch_available false, vendor patch typically requiring a service restart or system reboot.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The management console administers the endpoints running Client View, so an attacker who reaches privileged functionality on it is inside the system that manages the fleet rather than on a single host. Exploitation is confirmed and a public exploit exists, and the identifier is a 2016 CVE that was only KEV-listed on 2025-10-14 — so an operator finding an unpatched console now cannot treat the listing date as the start of the exposure window; an install that never took the fix has carried this path for as long as it has been running, and the playbook has to scope the window that way rather than to the last few weeks. For this product the playbook covers rotation of the credentials the console holds and of any credential that authenticated through it, review of console configuration and of anything the console could distribute to the endpoints it administers during the window, quarantine criteria for endpoints managed by a suspect console, and validation of those endpoints' state against a source the console does not control. Precondition on the last step: it exists only if such a source exists. An estate whose sole record of endpoint state is the console's own database has nothing independent to compare against, and that has to be arranged before the incident, not during it. Applying the vendor update and taking the restart it requires closes the entry path; it does not remove access an attacker established through it beforehand, which is precisely why closing this on the patch record leaves a compromised console counted as remediated.",
+        "evidence": "Packet: active_exploitation confirmed and poc_available true on a flaw described as unauthenticated remote code execution via the management console program's authentication processing; CVE identifier issued in 2016, CISA KEV-listed 2025-10-14; RWEP 77 against CVSS 9.8. The entry cites NIST 800-53 SI-2 (flaw remediation) and ASD Essential Eight patching among the insufficient controls. patch_available true with live_patch_available false and a vendor patch that typically requires a service restart or system reboot.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2021-43798": {
     "name": "Grafana Path Traversal Vulnerability",
@@ -21700,7 +21918,35 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry states both halves of the control itself: a vendor patch is recorded as available, and the packet's own vector says the impacted product could be end-of-life and/or end-of-service and that users should discontinue product utilization. Taken together they define the requirement — a host still exposed to this after the 2025-10-06 re-listing is a host whose browser may have no ongoing update path, so reaching the vendor fix is an interim state and the terminal state is taking Internet Explorer out of service on that host, or replacing the host where the workload depends on the browser. Scope the inventory to what the packet names: Internet Explorer rendering attacker-controlled web content. The packet provides no mapping from this uninitialized-memory defect into any other browser or HTML-rendering component, so treating every renderer in the estate as an instance of this CVE manufactures findings and removal work against software no evidence implicates. In operational terms: enumerate every host that can still use Internet Explorer to render untrusted web content, record per host whether it can take the vendor update and be restarted, put those hosts on the interim clock, and put every host that cannot on a dated removal or replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed in-the-wild exploitation in service indefinitely. Precondition on the interim half, which is where this is routinely over-claimed: the packet registers no live-patch path and states the vendor patch typically requires a service restart or system reboot, so a host that received the update but was not restarted still runs the vulnerable code and is not remediated; and applying the fix for this defect says nothing about anything found in that browser since, which is why the requirement cannot end at 'every install reports the fixed build' — that phrasing marks an abandoned browser compliant while it stays exposed. Because active exploitation is confirmed and the delivery path is a page the victim visits, a host that browsed untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet vector: 'Microsoft Internet Explorer contains an uninitialized memory corruption vulnerability that could allow for remote code execution. The impacted product could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' Packet attack_vector: an uninitialized-memory / use-after-free corruption flaw (CWE-94) in Internet Explorer, exploitable by an attacker-controlled web page for code execution in the browser, and 'the legacy re-listing exists because long-tail unpatched estates remain exposed'. CISA KEV listed 2025-10-06; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a remediation clock anchored on patch availability produces no action at all. The packet describes the 2025-10-06 entry as a legacy re-listing that exists because long-tail unpatched estates remain exposed — that is, the vendor fix predates the listing by a wide margin — so a flaw-remediation programme that ages this CVE from its original patch date reads it as long since closed and nothing fires, while the KEV listing is the statement that it is being exploited now. Applied to this CVE the control means the clock starts at the KEV listing date, not the patch date, and the verified mitigation recorded per host is one of exactly two things the packet supports: the vendor update with its restart taken, or — following the packet's own instruction that users should discontinue product utilization — a documented, dated discontinuation of Internet Explorer on that host. Precondition, and it is what usually gets an SLA marked met while the flaw stays live: the packet registers no live-patch path and states the vendor patch typically requires a service restart or system reboot, so a host that has installed the update without restarting still runs the vulnerable code and must not be counted as mitigated; and on a host with no supported update path the clock can only be met by the discontinuation route, since there is no compensating rule in this packet that keeps the browser safely rendering untrusted pages. Distinguishing test: pull the remediation due-date the vulnerability-management programme actually assigned this CVE and confirm it is anchored on 2025-10-06 — an estate whose report ages this from the original fix shows it closed years ago while unrestarted and unsupported installs remain exposed to confirmed in-the-wild exploitation with a public PoC available.",
+        "evidence": "CISA KEV listed 2025-10-06; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. Packet attack_vector: 'the legacy re-listing exists because long-tail unpatched estates remain exposed'; delivery is an attacker-controlled web page giving code execution in the browser. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Packet vector: the impacted product could be end-of-life (EoL) and/or end-of-service (EoS); users should discontinue product utilization.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-43226": {
     "name": "Microsoft Windows Privilege Escalation Vulnerability",
@@ -22055,7 +22301,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where the control's 'whichever is later' clause is the whole point: the packet records a vendor patch as available and a KEV listing dated 2025-10-02, so the trigger that governs is the listing, and the requirement is that a CVE bearing a 2014 identifier re-enters the remediation queue on the expedited clock instead of being filed as historical by a vulnerability-management process that ages work by CVE year. The population to put on that clock is not every host with bash installed — it is the hosts where the packet's condition holds, namely those where attacker-controlled data reaches a bash environment, with CGI named as the example — so the first deliverable is the enumeration of those service paths, and those hosts are remediated before the general fleet. Completion is measured per host as the installed bash package plus the service restart or system reboot that the packet's live-patch note records as typically required by the KEV requiredAction, since the packet registers no live-patch tool for this entry and a host that installed the package without that restart is not the state the packet describes as remediated. Precondition: this is a scheduling control and reduces nothing by itself; it commits the clock and the ordering, and the work still has to be done. It also says nothing about a host already exploited — the packet records active exploitation as confirmed with a public exploit available, so a host that exposed a bash-reachable path during the exposure window needs triage and credential review rather than closure on a package version.",
+        "evidence": "Packet: GNU Bash contains an OS command injection vulnerability (CWE-78) in Bash environment-variable parsing, described as a Shellshock-family flaw, which allows remote attackers to execute arbitrary commands via a crafted environment, enabling remote command execution wherever attacker-controlled data reaches a Bash environment such as CGI. cisa_kev true, kev_date 2025-10-02, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false with live_patch_notes: no live-patch tool registered for this entry, and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE the paper-compliance failure is a bash package version read, and the packet gives two reasons it is not evidence. First, the packet places the flaw in the Shellshock family, so what has to be shown is that a host runs a build carrying the fix for this member — a build merely newer than the family's first fix is not the same claim, and an estate that closed its Shellshock work years ago on a family-level attestation can hold hosts this member still reaches. Second, exposure here is conditional rather than universal: the packet's condition is that attacker-controlled data reaches a bash environment, with CGI as the named example, so a scan that scores every host carrying bash identically measures neither the real exposure nor its absence. The operational test the control demands is therefore behavioural, and the packet supplies its basis — the trigger is a crafted environment and a public exploit exists: on a staging copy of each enumerated service path, deliver the crafted environment and confirm no injected command runs, then repeat it after the service restart or system reboot the packet's live-patch note records as typically required, since the check run before that restart can pass on the updated package while the exposed path still behaves as before. Scope the claim to what the scanner actually owns: a host-package scan is evidence only for the bash copies the package manager manages, so a clean result covers those copies and no others, and any copy shipped inside an image or appliance that the host scan does not enumerate has to be identified from its own vendor's build information and updated through that vendor's path rather than inferred clean. Precondition: this control changes what counts as proof, not the exposure — it neither patches a host nor detects one already exploited, and with active exploitation confirmed a path that was reachable during the window belongs on the incident path regardless of what the re-test now returns.",
+        "evidence": "Packet: OS command injection (CWE-78) in Bash environment-variable parsing, described as a Shellshock-family flaw; GNU Bash allows remote attackers to execute arbitrary commands via a crafted environment; exploitation is enabled wherever attacker-controlled data reaches a Bash environment such as CGI. poc_available true, active_exploitation confirmed, cisa_kev true with kev_date 2025-10-02, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false, live_patch_notes recording no live-patch tool for this entry and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2017-1000353": {
     "name": "Jenkins Remote Code Execution Vulnerability",
@@ -22175,7 +22446,39 @@
     },
     "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 credential this flaw turns on is inside the product, not on the operator's estate: the packet describes a hardcoded backdoor authentication credential in ScreenOS that grants administrative SSH/Telnet access to anyone presenting the planted password, reached as a supply-chain-planted backdoor. No amount of operator-side credential hygiene reduces the exposure, because the attacker never uses a firewall administrator account the operator created — per-account privilege scoping is never consulted and the account model an identity-and-access attestation examines is bypassed rather than abused, which is precisely why the identity-and-access-control and least-privilege gaps are recorded against this entry. Applied to this product, the requirement is to inventory every ScreenOS device in service with the firmware version it is actually running, gate each of those devices on the vendor's fixed release rather than on any password, multi-factor or administrator-role policy, and re-run that check after any firmware rollback, RMA replacement, or restore from an older image — those are the operations that quietly put a backdoored build back on a device that had been remediated. Distinguishing test: produce, per device, the ScreenOS version in service and show it is at or above the vendor's fixed release; an attestation that every firewall administrator holds a unique account with a rotated password and a second factor passes cleanly while this backdoor stays fully usable, because the planted credential is not one of those accounts and cannot be rotated by the operator at all. Precondition: the vendor update is what removes the embedded credential — this control is the inventory and the gate that get every device to it, and it offers nothing to a device that has not yet taken the update and the restart the packet records as required. It also detects nothing that has already happened; a device that was reachable by an untrusted network during the exposure window needs compromised-device treatment, not a version number.",
+        "evidence": "Packet: Juniper ScreenOS improper authentication (CWE-287); attack_vector describes a hardcoded backdoor authentication credential letting anyone with the planted password gain administrative SSH/Telnet access to the firewall, characterized as a supply-chain-planted backdoor; vector states the flaw could allow unauthorized remote administrative access to the device. CISA KEV-listed 2025-10-02, active_exploitation confirmed, poc_available true, CVSS 9.1, RWEP 77. patch_available true; live_patch_available false, live_patch_notes record no live-patch tool and a vendor patch that typically requires service restart or system reboot per the KEV requiredAction. Citing gaps include UK-CAF-B2 (Identity and access control) and NIST-800-53-AC-6 (Least Privilege).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This device is the perimeter, and the packet's outcome is not code execution on it but administrative control of it: unauthorized remote administrative access over SSH/Telnet to a ScreenOS firewall, with exploitation confirmed in the wild and a public proof of concept. An attacker holding the device's administrator role can add administrator accounts, alter security policy, and change VPN and management configuration — and installing the fixed ScreenOS release removes none of that. The update deletes the planted credential; it does not delete what was done with it, and an added administrator account survives the upgrade and needs no backdoor afterwards. So for any ScreenOS unit that was reachable by an untrusted network during the exposure window, remediation defaults to exporting the configuration for analysis, rebuilding the device onto the fixed release from vendor media, and rotating every credential the device held or authenticated — administrator passwords, VPN pre-shared keys, RADIUS/TACACS+ shared secrets, SNMP community strings, and any key or certificate stored on it — rather than upgrading in place and closing the ticket. Restoring the saved configuration onto the rebuilt device re-imports whatever the attacker changed, so that configuration is a forensic artifact and a reference for reconstruction, not the restore source. Distinguishing test: for each unit remediated, show the rebuild record and the credential-rotation record alongside the version evidence; a patch-cadence attestation recording the fixed release installed on every firewall is complete and passing while an attacker-added administrator account is still on the box. Precondition: rebuild bounds the device and nothing beyond it. Access the attacker gained through the firewall into the networks behind it persists after the rebuild, and every credential that transited or terminated on the device is suspect until rotated — that is an incident-response scope question, not a patching one.",
+        "evidence": "Packet: unauthorized remote administrative access to a Juniper ScreenOS firewall via a planted password (CWE-287, administrative SSH/Telnet access); active_exploitation confirmed; poc_available true; CISA KEV-listed 2025-10-02; CVSS 9.1; RWEP 77. patch_available true with live_patch_available false and live_patch_notes recording a vendor patch that typically requires service restart or system reboot per the KEV requiredAction. Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2, all of which treat installing the fixed release as remediation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "What this exploit emits is a successful administrative login. The packet describes a planted password that grants administrative SSH/Telnet access, so in the device's own record the attempt is indistinguishable from an operator signing in correctly on the first try: no failed-authentication burst, no brute-force pattern, no lockout, and no weak or expired credential for a password audit to find. The signal that survives is the authentication event correlated against who was actually working — an administrative SSH or Telnet session on a ScreenOS device that no change record, on-call roster, or jump-host session accounts for, and any administrative session sourced from outside the management network. That signal only exists off the device, because a caller who reaches the administrative role also holds the device's logging: ScreenOS must forward authentication and session logs continuously to a collector in a separate trust zone — different management plane, different credentials, different authentication path — and an interruption in that forwarding must itself raise an event rather than be written off as a collector fault. Distinguishing test: from an address outside the management network, complete an administrative SSH login against a staging ScreenOS device, then clear the device's local logs, and confirm the collector still holds the authentication record and raised the unaccounted-session alert. Alerting on failed logins, brute-force thresholds, or exploit-tool signatures would miss an attempt that behaves exactly as the packet describes, because the credential is valid on first presentation and nothing fails. Precondition, and it decides whether any of this is worth authoring: the forwarding has to have been running before the attempt. A rule written after the 2025-10-02 KEV listing against telemetry nobody was collecting produces nothing, and detection neither prevents the access nor evicts an attacker already administering the device — it bounds exposure to alert-and-response time during the window before the fixed release and its restart land.",
+        "evidence": "Packet: administrative SSH/Telnet access to the firewall granted to anyone presenting the planted password (CWE-287 improper authentication); vector states the flaw could allow unauthorized remote administrative access to the device. active_exploitation confirmed; poc_available true; CISA KEV-listed 2025-10-02. patch_available true, live_patch_available false, with the vendor patch typically requiring service restart or system reboot per the KEV requiredAction. Citing gap NIS2-Art21-network-security (Security of network and information systems).",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-21043": {
     "name": "Samsung Mobile Devices Out-of-Bounds Write Vulnerability (variant: CVE-2025-21043)",
@@ -25197,66 +25500,99 @@
     "defense_chain": {
       "prevention": {
         "what_would_have_worked": "Apply the Microsoft SharePoint security update; this is the auth-bypass half of the ToolShell chain, so confirm the RCE flaws are patched too and rotate machine keys.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
-        "adequacy": "Patch is necessary but, for these deserialization RCEs, insufficient alone — stolen machine keys and dropped web shells survive the patch and require explicit cleanup."
-      },
-      "detection": {
-        "what_would_have_worked": "Monitoring on the SharePoint Server: exploit-shaped requests, new .aspx/web-shell files under the server's web root, unexpected process execution, and anomalous use of stolen cryptographic keys.",
-        "was_this_required": false,
-        "framework_requiring_it": null,
-        "adequacy": "Necessary to catch resident persistence after patching; the ToolShell-class chains specifically steal keys for durable access."
-      },
-      "response": {
-        "what_would_have_worked": "Patch immediately, rotate machine keys, hunt and remove web shells, and review for lateral movement; assume credential compromise for any account reachable from the SharePoint Server.",
-        "was_this_required": true,
-        "framework_requiring_it": "NIST 800-53 IR-4",
-        "adequacy": "Mandatory; patch-in-place without key rotation and web-shell hunting leaves the attacker resident."
-      }
-    },
-    "framework_coverage": {
-      "NIST-800-53-SI-2": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed unauthenticated server flaw; CISA KEV due dates are days. The ToolShell SharePoint chain was mass-exploited within days of disclosure."
-      },
-      "ISO-27001-2022-A.8.8": {
-        "covered": true,
-        "adequate": false,
-        "gap": "'Appropriate timescales' is undefined; the standard 30-day reading is unsafe for an unauthenticated, actively-exploited flaw on an internet-facing enterprise server."
-      },
-      "NIS2-Art21-network-security": {
-        "covered": true,
-        "adequate": false,
-        "gap": "Treats the server class as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA, and does not require the key-rotation/web-shell-hunt cleanup these deserialization RCEs need."
-      },
-      "PCI-DSS-4.0-6.3.3": {
-        "covered": true,
-        "adequate": false,
-        "gap": "The 30-day critical-patch window is exploitation acceptance for an unauthenticated RCE on an internet-facing server in or adjacent to the CDE."
-      }
-    },
-    "compliance_exposure_score": {
-      "percent_audit_passing_orgs_still_exposed": 75,
-      "basis": "Internet-facing Microsoft SharePoint Server is business-critical and change-controlled, so emergency patching loses to change windows; the required key-rotation and web-shell hunt is rarely part of the documented patch procedure.",
-      "theater_pattern": "patch_management"
-    },
-    "ai_discovered_zeroday": false,
-    "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
-  },
-  "CVE-2025-53770": {
-    "name": "Microsoft SharePoint Deserialization of Untrusted Data Vulnerability (variant: CVE-2025-53770)",
-    "lesson_date": "2026-05-29",
-    "attack_vector": {
-      "description": "deserialization of untrusted data (CWE-502) on SharePoint Server (the ToolShell chain), yielding unauthenticated remote code execution and web-shell deployment. CISA KEV-listed 2025-07-20 with confirmed in-the-wild exploitation.",
-      "privileges_required": "none (unauthenticated network reach to the server)",
-      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
-      "ai_factor": "No AI involvement documented in discovery or weaponization."
-    },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Apply the Microsoft SharePoint security update, rotate machine keys, and hunt for web shells (e.g. spinstall0.aspx) — patching alone leaves stolen keys and shells in place.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
+        "adequacy": "Patch is necessary but, for these deserialization RCEs, insufficient alone — stolen machine keys and dropped web shells survive the patch and require explicit cleanup."
+      },
+      "detection": {
+        "what_would_have_worked": "Monitoring on the SharePoint Server: exploit-shaped requests, new .aspx/web-shell files under the server's web root, unexpected process execution, and anomalous use of stolen cryptographic keys.",
+        "was_this_required": false,
+        "framework_requiring_it": null,
+        "adequacy": "Necessary to catch resident persistence after patching; the ToolShell-class chains specifically steal keys for durable access."
+      },
+      "response": {
+        "what_would_have_worked": "Patch immediately, rotate machine keys, hunt and remove web shells, and review for lateral movement; assume credential compromise for any account reachable from the SharePoint Server.",
+        "was_this_required": true,
+        "framework_requiring_it": "NIST 800-53 IR-4",
+        "adequacy": "Mandatory; patch-in-place without key rotation and web-shell hunting leaves the attacker resident."
+      }
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed unauthenticated server flaw; CISA KEV due dates are days. The ToolShell SharePoint chain was mass-exploited within days of disclosure."
+      },
+      "ISO-27001-2022-A.8.8": {
+        "covered": true,
+        "adequate": false,
+        "gap": "'Appropriate timescales' is undefined; the standard 30-day reading is unsafe for an unauthenticated, actively-exploited flaw on an internet-facing enterprise server."
+      },
+      "NIS2-Art21-network-security": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Treats the server class as essential-function infrastructure but lacks a CISA-KEV-style compressed remediation SLA, and does not require the key-rotation/web-shell-hunt cleanup these deserialization RCEs need."
+      },
+      "PCI-DSS-4.0-6.3.3": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The 30-day critical-patch window is exploitation acceptance for an unauthenticated RCE on an internet-facing server in or adjacent to the CDE."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 75,
+      "basis": "Internet-facing Microsoft SharePoint Server is business-critical and change-controlled, so emergency patching loses to change windows; the required key-rotation and web-shell hunt is rarely part of the documented patch procedure.",
+      "theater_pattern": "patch_management"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "vendor_research",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet states it outright: CVE-2025-53771 is a patch bypass for this CVE, and the CVE-2025-53771 updates include more robust protection than the ones shipped for CVE-2025-49706. That inverts the usual reading of a remediation record — a SharePoint Server that took the CVE-2025-49706 update and closed the ticket carries a 'patched' verdict against a fix the vendor has since superseded, so the flaw-remediation attestation reads clean while the authentication path it was meant to close stays reachable through the bypass. For this CVE the remediated state is therefore defined by the later build: verify each SharePoint Server against the build carrying the CVE-2025-53771 protections rather than against the update issued for CVE-2025-49706, and hold the two as one open remediation item instead of two closed ones. The packet also names this as the ToolShell chain entry point and records it as chainable with CVE-2025-49704, so the exposure is a sequence on one authentication primitive rather than a discrete ticket — the intake expectation is that further bypasses on the same path are likely and warrant standing monitoring, not a closed record. Precondition, and it is this control's limit: it changes scoring, scheduling and record-keeping and remediates nothing by itself. The packet registers no live-patch path and a vendor patch typically requiring a service restart or system reboot, so a server that has taken the superseding update but not been restarted is still running the vulnerable code.",
+        "evidence": "Packet vector for CVE-2025-49706: 'This vulnerability could be chained with CVE-2025-49704. CVE-2025-53771 is a patch bypass for CVE-2025-49706, and the updates for CVE-2025-53771 include more robust protection than those for CVE-2025-49706.' Packet attack_vector: 'improper authentication (CWE-287) on SharePoint Server — the ToolShell chain entry point — letting an unauthenticated attacker reach the RCE primitives.' cwe_refs CWE-287; cisa_kev true; kev_date 2025-07-22; active_exploitation 'confirmed'; cvss 9.1; rwep_score 83; poc_available true; patch_available true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Cited as insufficient on this entry: NIST SP 800-53 Rev 5 SI-2 'Flaw Remediation', ISO/IEC 27001:2022 A.8.8, EU NIS2 'Cybersecurity risk-management measures (vulnerability handling and disclosure)', ASD Essential Eight 'Patch operating systems'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "SharePoint Server's authentication check is where the product decides who a caller is, and CWE-287 on this entry is that decision failing. The packet's vector records spoofing performed over a network — a caller presenting an identity it does not hold — and the packet's attack_vector records the consequence as an unauthenticated attacker reaching the RCE primitives at the ToolShell chain entry point. Under either framing the requirement is the same, and that is the point: the privileged SharePoint functions behind the check must establish their caller's authority themselves rather than inheriting a verdict settled once at the front door, and the server's surface must be segmented so a caller with no operational need cannot present the spoofed request at all. This is exactly why the least-privilege and identity-and-access controls cited as insufficient on this entry never engage — the attacker holds no SharePoint account, so no per-account privilege scoping is consulted, no credential is guessed and no second factor is ever requested; an identity-and-access review and a least-privilege attestation both pass cleanly while an unauthorized caller is inside. Distinguishing test: from a segment with no operational need to reach the server, send a staging SharePoint Server requests bearing a spoofed caller identity and confirm each privileged function refuses before it runs; confirming that every named SharePoint user authenticates correctly tests nothing on this path. Precondition: the repair to the authentication decision is the vendor's — this control names the property to verify and the segmentation that bounds who can attempt the spoof; segmentation limits the caller population and closes nothing against anything already inside the permitted segment.",
+        "evidence": "Packet vector for CVE-2025-49706: 'Microsoft SharePoint contains an improper authentication vulnerability that allows an authorized attacker to perform spoofing over a network', with the recorded impact being viewing sensitive information and making changes to disclosed information. Packet attack_vector: 'improper authentication (CWE-287) on SharePoint Server — the ToolShell chain entry point — letting an unauthenticated attacker reach the RCE primitives. CISA KEV-listed 2025-07-22 with confirmed in-the-wild exploitation.' cwe_refs CWE-287; cvss 9.1; rwep_score 83; poc_available true; patch_available true; live_patch_available false. Cited as insufficient on this entry: UK NCSC CAF v3.2 B2 'Identity and access control' and NIST SP 800-53 Rev 5 AC-6 'Least Privilege'.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet places this flaw at the entry of a chain that reaches the RCE primitives, chainable with CVE-2025-49704, with exploitation confirmed from the 2025-07-22 KEV listing and a public PoC — so a SharePoint Server that was network-reachable on an affected build across that window is a triage subject rather than a patch ticket. The update repairs the authentication decision; it revokes nothing obtained while that decision was failing. For an authentication-bypass entry point that means the credentials and cryptographic material the server's application identity holds are rotated as part of remediation rather than as a follow-up, and the content the server hosts and serves is compared against a known-good baseline rather than inferred clean from the absence of an alert. That last point is the specific reason the anti-malware control cited as insufficient on this entry cannot carry the remediation: an artifact written through the application's own request path by an attacker who authenticated as nobody is not a signature-matched sample, so a fully deployed and current anti-malware estate reports clean over it. Preconditions and limits: the rebuild-and-rotate scope is the server's own hosts and its own secrets — an identity outside that scope reached from the foothold is separate containment; and the triage is bounded by an exposure window the operator can actually establish, so a deployment without retained per-request access logs for the period cannot scope the hunt at all, in which case rebuild is the safe default rather than an evidence-driven choice. Note also that the vendor update alone does not settle the exposure here: the packet records CVE-2025-53771 as a patch bypass for this CVE, so the update must be the superseding build and the restart it requires must be completed.",
+        "evidence": "Packet attack_vector for CVE-2025-49706: 'improper authentication (CWE-287) on SharePoint Server — the ToolShell chain entry point — letting an unauthenticated attacker reach the RCE primitives. CISA KEV-listed 2025-07-22 with confirmed in-the-wild exploitation.' Packet vector: 'This vulnerability could be chained with CVE-2025-49704. CVE-2025-53771 is a patch bypass for CVE-2025-49706'. active_exploitation 'confirmed'; kev_date 2025-07-22; poc_available true; cvss 9.1; rwep_score 83; patch_available true; live_patch_available false, with live_patch_notes recording no registered live-patch tool and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction. Cited as insufficient on this entry: CIS Controls v8 10.1 'Deploy and Maintain Anti-Malware Software'.",
+        "gap_closes": [
+          "CIS-Controls-v8-10.1"
+        ]
+      }
+    ]
+  },
+  "CVE-2025-53770": {
+    "name": "Microsoft SharePoint Deserialization of Untrusted Data Vulnerability (variant: CVE-2025-53770)",
+    "lesson_date": "2026-05-29",
+    "attack_vector": {
+      "description": "deserialization of untrusted data (CWE-502) on SharePoint Server (the ToolShell chain), yielding unauthenticated remote code execution and web-shell deployment. CISA KEV-listed 2025-07-20 with confirmed in-the-wild exploitation.",
+      "privileges_required": "none (unauthenticated network reach to the server)",
+      "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
+      "ai_factor": "No AI involvement documented in discovery or weaponization."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Apply the Microsoft SharePoint security update, rotate machine keys, and hunt for web shells (e.g. spinstall0.aspx) — patching alone leaves stolen keys and shells in place.",
         "was_this_required": true,
         "framework_requiring_it": "CISA BOD 22-01 (KEV remediation)",
         "adequacy": "Patch is necessary but, for these deserialization RCEs, insufficient alone — stolen machine keys and dropped web shells survive the patch and require explicit cleanup."
@@ -26913,7 +27249,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "The vulnerable asset in this entry is the security-monitoring platform itself: the packet places a deserialization-of-untrusted-data path on the Wazuh server API and describes it as unauthenticated remote code execution on the security-monitoring server. For this product the control means the Wazuh server is enumerated and scanned as privileged, patch-prioritized software on the same clock as any other pre-auth RCE, instead of appearing in the estate's records only as a control that produces evidence about other hosts. Every Wazuh server in the deployment has to be reached, not just the one the console points at — a multi-node deployment has more than one manager, and the API surface exists on each. Because the packet records no live-patch path and notes the vendor patch typically requires a service restart or system reboot, a server whose package has been updated but whose service has not been restarted still runs the vulnerable code and must be counted as exposed rather than as remediated. Distinguishing test: from a host with no operational need to administer Wazuh, send an unauthenticated request carrying crafted serialized content at the server API on a staging manager and confirm it is refused before anything is deserialized — an estate whose vulnerability-management attestation covers the agents Wazuh watches, but never scans or tests the manager itself, passes cleanly while this path stays open.",
+        "evidence": "Packet: CWE-502 deserialization of untrusted data; vector states Wazuh \"contains a deserialization of untrusted data vulnerability that allows for remote code execution on Wazuh servers\", and attack_vector places it on the Wazuh server API as unauthenticated remote code execution on the security-monitoring server. CVSS 9.8, RWEP 77, poc_available true, active_exploitation confirmed, CISA KEV-listed 2025-06-10. patch_available true; live_patch_available false, with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "UK-CAF-C1"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The packet's framing — untrusted data deserialized on a path a caller reaches without authenticating — makes the Wazuh server's listening surface a trust boundary rather than the internal convenience most deployments treat it as. Bound to this product, the control means content arriving at the manager is not permitted to drive object reconstruction, every listener the manager exposes requires peer authentication rather than only the one the operator's console happens to use, and those listeners are bound to the management and agent segment instead of to every interface. State the preconditions plainly, because this is where the control gets over-claimed: refusing to rebuild arbitrary objects from request content is a property the vendor's fixed build establishes — this control says what to verify, it does not implement it — and until that build and its service restart land, restricting reachability only bounds who can send the payload. It closes nothing for a caller already inside the permitted segment, and it is simply unavailable for the agent-facing listeners a manager must keep open to do its job. The least-privilege control cited as insufficient on this entry is not closed by anything here either: the attacker never holds a Wazuh account, so per-account privilege scoping is never consulted. Distinguishing test: from a segment with no monitoring role, open a connection to each listener a staging manager exposes and confirm the peer is rejected before any request content is deserialized.",
+        "evidence": "Packet: CWE-502 on the Wazuh server API, described as enabling unauthenticated remote code execution; poc_available true and active_exploitation confirmed, CISA KEV-listed 2025-06-10, RWEP 77 against CVSS 9.8. The entry cites NIST 800-53 AC-6 (Least Privilege) among its framework gaps, which the packet's own unauthenticated attack path never engages. patch_available true, live_patch_available false with a vendor patch that typically requires a service restart or system reboot.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "Compromise of a Wazuh server is not an endpoint incident — it is the loss of the plane through which every other detection in the estate is reported. With exploitation confirmed and a public exploit available, an operator who reaches the fixed build still has to answer what happened before it, and for the exposure window the manager's own alerts, rule state and stored telemetry are attacker-influenceable and cannot serve as the evidence that nothing occurred. The playbook this product needs covers rotation of the credentials and agent-enrolment material the manager holds, review of rule and configuration changes and of anything the manager could push to the agents it administers during the window, quarantine criteria for agents that reported to a suspect manager, and comparison of the manager's stored telemetry against a copy kept somewhere the manager cannot write. Precondition on that last step: it exists only if such a copy exists. An estate whose only record of its own monitoring output lives on the compromised host has no baseline to compare against and no way to establish the window, and building one after the fact produces nothing. Patching does not substitute for any of this — the update removes the deserialization path, it does not remove what an attacker left on a manager exploited before it landed.",
+        "evidence": "Packet: active_exploitation confirmed with poc_available true on a flaw described as unauthenticated remote code execution on the Wazuh server, CISA KEV-listed 2025-06-10. The entry records NIS2 Art. 21 incident handling and UK CAF C1 security monitoring among the framework controls that are insufficient here. patch_available true with live_patch_available false, so remediation is the vendor update plus the service restart or reboot the packet says it typically requires — neither of which removes attacker artefacts from a server exploited beforehand.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2024-42009": {
     "name": "RoundCube Webmail Cross-Site Scripting Vulnerability",
@@ -27476,7 +27845,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries the two facts that have to be reconciled per unit before anything else: a vendor patch is recorded as available, and the entry's own vector states the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization. So the first requirement is an inventory that names every ASUS Lyra Mini and ASUS GT-AC2900 in service with its running firmware and a support status obtained from the vendor rather than assumed in either direction. Units whose model still has supported firmware are patch items on the clock that opened with the 2025-06-02 KEV listing; units with no supported firmware cannot be patched at all and are replacement items with a dated schedule, because a risk acceptance with no removal date leaves a device carrying a public PoC and confirmed in-the-wild exploitation in service indefinitely, at a position where it is the network boundary for everything behind it. Scope the inventory to the two models the packet names — no mapping from this authentication flaw into other ASUS models or other consumer routers is established here, and treating every router in the estate as an instance of this CVE manufactures replacement work against hardware no evidence implicates; widen only where a verified source identifies another model carrying the same defect. Precondition on the interim half, which is where this is normally over-claimed: the packet registers no live-patch path and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a unit that has taken the firmware but not restarted still runs the vulnerable code and is not remediated; and reaching the fixed firmware closes this defect only, saying nothing about anything found in a model since — which is exactly why the requirement cannot end at 'every unit reports the fixed firmware'. Distinguishing test: produce, per unit, the model, hardware revision, running firmware and the vendor's support status for it, and confirm each unit is either at the fixed firmware or on a dated removal schedule — a patch-compliance report that lists an unsupported model as 'no update available' and closes the item marks an abandoned device compliant while it stays exposed.",
+        "evidence": "Packet name: 'ASUS Routers Improper Authentication Vulnerability'. Vector: 'ASUS Lyra Mini and ASUS GT-AC2900 devices contain an improper authentication vulnerability that allows an attacker to gain unauthorized access to the administrative interface. The impacted products could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' cwe_refs CWE-287; cisa_kev true with kev_date 2025-06-02; active_exploitation confirmed; poc_available true; cvss 9.1; rwep_score 77; patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The trigger condition this control exists for is present here in the form the packet documents: a pre-authentication flaw on the administrative interface of the device that sits at the network boundary, with confirmed in-the-wild exploitation and a public PoC. The attacker reaches the administrative interface without holding any account, and administrative access means the device's configuration and its stored credentials are attacker-writable — which firmware does not revert. So for any ASUS Lyra Mini or GT-AC2900 that was reachable during the exposure window, the default response is capture the running configuration for analysis, reset to factory defaults and re-provision from a known-good configuration, and rotate the device's administrative credential along with any credential held in or reachable from that configuration — not an in-place firmware upgrade that leaves the attacker's settings intact underneath a version number that now reads clean. Precondition, and it is the half most often skipped: a rebuild restores configuration integrity, it does not deliver fixed code. A unit rebuilt onto firmware that still lacks the fix is exploitable again the moment it is reachable, so the rebuild has to land on the fixed firmware, and where the model has no fixed firmware the rebuild is not a remediation at all — that unit belongs on the replacement schedule rather than being cycled through factory resets. The rebuild also depends on a known-good configuration baseline recorded before the exposure window; where none exists the configuration must be re-entered by hand, because a backup taken during the window carries the attacker's settings forward into the 'clean' device. Distinguishing test: compare each unit's running configuration — administrative accounts, and whether the administrative interface answers from outside the local network — against a known-good baseline, rather than confirming only that the firmware version is current. A fleet where every unit reports fixed firmware while carrying attacker-set administrative configuration passes a patch attestation and stays compromised.",
+        "evidence": "Packet vector: 'ASUS Lyra Mini and ASUS GT-AC2900 devices contain an improper authentication vulnerability that allows an attacker to gain unauthorized access to the administrative interface.' attack_vector: 'an improper-authentication flaw (CWE-287) letting an unauthenticated attacker bypass authentication on the router's administrative interface. CISA KEV-listed 2025-06-02 with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available true; cvss 9.1; rwep_score 77; patch_available true; live_patch_available false with live_patch_notes recording that the vendor patch typically requires service restart or system reboot.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-3935": {
     "name": "ConnectWise ScreenConnect Improper Authentication Vulnerability",
@@ -27536,7 +27928,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's own conditional is why this is a rebuild-and-rotate case rather than a patch ticket: the improper-authentication flaw allows a ViewState code injection attack, which allows remote code execution if machine keys are compromised. Those keys are secret material held by the ScreenConnect server, and applying the vendor update does not change them — so an estate that patches and closes the finding has repaired the injection path while leaving in place the one condition the packet names as turning it into code execution. Bound to this product, remediation of an on-premises ScreenConnect server that was reachable and unpatched during the window opened by the 2025-06-02 KEV listing means: export the server's configuration for offline review before touching it; regenerate the machine keys the ViewState path depends on rather than carrying them across the upgrade; rotate every credential, session and access token the server issued or stored; and default to rebuilding from vendor media wherever the server's state cannot be attested. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot, so a server that has taken the update but not restarted is still running the vulnerable code and must be counted as exposed rather than remediated — a deferred restart recorded as 'patched' is the specific way this goes wrong. Precondition, and it is the one this control is most often recorded without: rotation only holds if the regenerated keys are not reinstated from a pre-incident backup or a configuration snapshot captured during the exposure window, because a rebuild that restores the old machine keys restores exactly the condition the packet names. Rotation also does not retroactively invalidate use already made of the keys before they were changed, so a server inside that window belongs on the incident path and not on the patch record.",
+        "evidence": "Packet vector: 'ConnectWise ScreenConnect contains an improper authentication vulnerability. This vulnerability could allow a ViewState code injection attack, which could allow remote code execution if machine keys are compromised.' attack_vector: an improper-authentication flaw (CWE-287) letting an unauthenticated attacker bypass authentication via ASP.NET ViewState / machine-key abuse. CISA KEV-listed 2025-06-02, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "ScreenConnect is a remote-support server and the packet's stated outcome is code execution on it, which by definition puts everything that server's process can read or write inside the attacker's reach — not the operator console alone, but the artifacts the server serves out, its session and connection configuration, and any credential material stored alongside them. Treat that content as a privileged distribution channel rather than as ordinary application data: file-integrity-monitor the ScreenConnect installation and every directory it serves artifacts from, alert on writes that do not correspond to a sanctioned administrator action or a vendor update, and track the server as a management-plane asset on KEV-priority patching rather than as an internal line-of-business application. This is the half of the response that retains value after the update lands, because the fix closes the authentication bypass but removes nothing placed through it beforehand, and a modified artifact served by a legitimate, trusted support server is not something authentication logging or signature-based endpoint tooling has an artifact to match. Precondition: the monitoring detects a change only against a baseline that predates the exposure window opened by the 2025-06-02 KEV listing — stood up afterwards it baselines whatever is already present and will report clean. Where no such baseline exists, the served content has to be compared against vendor-supplied originals or replaced from them, not certified by the monitor. Note also that the packet conditions the code-execution outcome on machine-key compromise, so this scope applies to servers where that condition cannot be excluded rather than to every install by default.",
+        "evidence": "Packet: ConnectWise ScreenConnect, CWE-287, with the vector stating the ViewState code injection 'could allow remote code execution if machine keys are compromised' and the attack_vector describing an unauthenticated attacker bypassing authentication via ASP.NET ViewState / machine-key abuse. CISA KEV-listed 2025-06-02 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 77. patch_available true; live_patch_available false, with the vendor patch typically requiring a service restart or system reboot per the KEV requiredAction. The entry's citing framework gaps include EU NIS2 Art. 21 supply-chain security measures.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain"
+        ]
+      }
+    ]
   },
   "CVE-2025-35939": {
     "name": "Craft CMS External Control of Assumed-Immutable Web Parameter Vulnerability",
@@ -27800,7 +28214,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet labels this a patch-bypass variant: the same traversal primitive on the same MagicINFO 9 Server file-handling surface, reached again after a fix was already issued for it. For this product that changes what \"remediated\" is permitted to mean. The MagicINFO server stays on an elevated review tier after the new build rather than dropping back to the generic application-patching cadence, and whatever restriction on who can reach its file-handling endpoints was put in place during the exposure window is retained rather than retired on the strength of the second fix — a primitive that has been bypassed once is evidence the class is likely to be reachable again, not evidence it is closed. The population this specifically catches is the operator whose vulnerability register shows the earlier CVE closed and whose scanner therefore reports the server compliant, while the bypass variant is the thing under confirmed exploitation. Distinguishing test: re-run the traversal the earlier fix was supposed to stop, with encoding and path-normalization variants, against a staging MagicINFO server on the new build, and confirm each is refused before any write occurs — an attestation that records \"vendor patch applied\" without re-testing the primitive cannot tell a fix from a second incomplete one.",
+        "evidence": "Packet: CWE-22 characterised in attack_vector as \"a patch-bypass variant\", letting an unauthenticated attacker write or read files outside the intended directory for code execution; the vector states Samsung MagicINFO 9 Server \"contains a path traversal vulnerability that allows an attacker to write arbitrary file as system authority\". CISA KEV-listed 2025-05-22, active_exploitation confirmed, poc_available true, RWEP 77 against CVSS 7.5. patch_available true; live_patch_available false, with the vendor patch typically requiring a service restart or system reboot.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "MagicINFO 9 Server is the management plane for the displays it drives, and the defect sits on the file-handling path of that plane: a caller-supplied path selects where a write lands, and the packet records that write executing with system authority for a caller who never authenticated. Bound to this product, the control means every MagicINFO endpoint that accepts or names a file authorizes its caller before the content is processed at all, and resolves the destination to a canonical absolute path and confirms it remains inside the intended directory before the privileged write runs — so the caller cannot choose the target file. Alongside that, no MagicINFO server is left answering from a segment with no operational need to reach it: the administration console and the display fleet need it; a general user VLAN and the public internet do not. Preconditions: the endpoint-side authorization and path normalization are properties the vendor's fixed build establishes — this control states what to verify, not what to implement — and until that build and the service restart it requires land, restricting reachability bounds who can send the request while leaving the path fully open to anything inside the permitted segment. Where displays must reach the server across untrusted or remote networks, that restriction is not available at all and the update is the only lever. Distinguishing test: from a segment with no signage-management role, send an unauthenticated request whose destination path resolves outside the intended directory and confirm it is refused before anything is written.",
+        "evidence": "Packet: CWE-22 path traversal on Samsung MagicINFO 9 Server; vector states it \"allows an attacker to write arbitrary file as system authority\" and attack_vector describes an unauthenticated attacker writing or reading files outside the intended directory for code execution. CISA KEV-listed 2025-05-22 with active_exploitation confirmed and poc_available true. patch_available true, live_patch_available false, with the packet noting the vendor patch typically requires a service restart or system reboot.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive the packet records is an arbitrary file write as system authority on the server that stores and distributes content to the display fleet, so the exposed asset is not only a web root — it is every file that server holds and every file it hands out. Treat the MagicINFO installation and the directories it serves content from as a privileged distribution channel: file-integrity-monitor them and alert on writes that do not correspond to a sanctioned administrator action or a vendor update. This is the requirement that still has value after the fixed build lands, because the update closes the write path and removes nothing already written through it — with exploitation confirmed and a public exploit available, a file placed before remediation survives both the upgrade and the restart, and neither signature-based anti-malware nor authentication logging surfaces a bespoke artefact written through a traversal that never authenticated. Preconditions: monitoring detects, it does not prevent, so it bounds the window to alert-and-response time rather than closing the path; and it is only meaningful against a known-good baseline of those directories captured before the write. A server first inventoried after the exposure window records the attacker's file as part of normal state, which is why a server that was reachable during that window needs its served content compared against a known-good copy rather than being closed out on the patch.",
+        "evidence": "Packet: the vector records a write of an arbitrary file \"as system authority\", with attack_vector describing the writer as unauthenticated; active_exploitation confirmed, poc_available true, CISA KEV-listed 2025-05-22. patch_available true and live_patch_available false, with the vendor patch typically requiring a service restart or system reboot — remediation the packet supports for the write path, and which says nothing about content already written.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-38950": {
     "name": "ZKTeco BioTime Path Traversal Vulnerability",
@@ -27860,7 +28305,30 @@
     },
     "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": "The iclock API is BioTime's device-facing management channel, and the packet places the defect there: a path traversal (CWE-22) that lets an unauthenticated caller supply a crafted payload and read arbitrary files on the server. Bound to this product, the control means the iclock API authorizes its caller before acting on a request at all, and resolves any caller-supplied path to its canonical absolute form and confirms the result is still under the intended directory before the file handle is opened, rather than filtering traversal sequences out of the request string. The read direction is the whole exposure here: the packet's outcome is arbitrary file read on the biometric time-attendance server, so anything the service can open is returned to a caller who never authenticated and against whom no account model is ever consulted — which is why an identity or access attestation on BioTime operator accounts is never even reached by this path. Distinguishing test: from a host with no terminal role, send the iclock API unauthenticated requests whose path parameter resolves outside the intended directory on a staging BioTime instance, and confirm each is refused before anything is opened; a vulnerability-management attestation that lists BioTime as inventoried and scanned reads clean while this endpoint answers. Precondition, and it binds harder here than on most appliances: the endpoint-side authorization and path canonicalization are properties the vendor update establishes — this control states what to verify, it does not implement it. Until that update and the service restart the packet records have landed, restricting which network segments can reach the iclock API bounds who can send the crafted payload but leaves the endpoint fully exploitable to anything inside the permitted segment, and that lever is largely unavailable in the normal deployment, because the iclock API exists precisely so that time-attendance terminals spread across sites can reach it — the segment that must reach it is broad by design.",
+        "evidence": "Packet: ZKTeco BioTime, path traversal (CWE-22) in the iclock API that allows an unauthenticated attacker to read arbitrary files via supplying a crafted payload; attack_vector describes an unauthenticated attacker reading arbitrary files on the biometric time-attendance server. CISA KEV-listed 2025-05-19, active_exploitation confirmed, poc_available true, CVSS 7.5, RWEP 77. patch_available true; live_patch_available false, with live_patch_notes recording no live-patch tool for this entry and a vendor patch that typically requires service restart or system reboot per the KEV requiredAction. Citing gaps include UK-CAF-B4 (System security) and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the KEV clock opened 2025-05-19 against a flaw with confirmed in-the-wild exploitation and a public proof of concept, so the standard flaw-remediation cadence the citing gaps rest on is longer than the window an unauthenticated file-read on an internet-reachable attendance server actually gets. Two things make the clock behave differently here than on a generic application patch. First, the packet registers no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a BioTime server on which the installer has run but the service has not restarted is still serving the vulnerable iclock handler; completion has to be measured per server by the build actually running and the date the service last restarted, not by the installer-run date in a patch console. Second, and this is the half no patch-timescale control asks for: the update stops further reads, it does not un-disclose a file that was already read. Because exploitation is confirmed and a working proof of concept is public, every secret the service could open on a server that was reachable during the exposure window — database and integration credentials held in configuration, service-account material, anything else within the process's read scope — is treated as disclosed and rotated, with the rotation tracked to completion as its own item rather than folded into the patch ticket. Distinguishing test: produce, per BioTime server, the running build, the service restart timestamp, and the rotation record for the credentials that server holds; a flaw-remediation SLA marked met on installer-run date with no restart evidence and no rotation is the specific way this entry gets closed while it stays exploitable. Precondition: this control is a clock and an evidence standard, not a mitigation — it changes when the fixed build arrives and how completion is proven, and it gives an operator nothing during the interval before the update and restart land.",
+        "evidence": "Packet: CISA KEV-listed 2025-05-19 with active_exploitation confirmed and poc_available true; RWEP 77 against CVSS 7.5. 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: unauthenticated arbitrary file read via the iclock API. Citing gaps include NIST-800-53-SI-2 (Flaw Remediation), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and AU-ISM-1546 (Patch operating systems and applications).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "AU-ISM-1546"
+        ]
+      }
+    ]
   },
   "CVE-2024-27443": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Vulnerability",
@@ -28003,7 +28471,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet puts this flaw within reach of an unauthenticated attacker and records the traversal being used in the wild to write to startup paths for code execution, so there is no interior authentication step between a published exploit and the Srimax Output Messenger server — the exposure is the interval between the 2025-05-19 KEV listing and the fixed build actually running. That makes it a KEV-clock item rather than an application-maintenance-window item. Where the clock has to run to is the part that matters for this product: the packet registers no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a server that has taken the update but has not been restarted is still running the vulnerable code and must be counted as exposed. That restart is also the step most likely to be deferred on a messaging server people are working in through the day, and a deferral recorded as 'patched' is indistinguishable on a compliance dashboard from a real fix — which is the specific way this remediation goes wrong. Distinguishing test: read the version off the running Output Messenger service and confirm the restart completed, rather than accepting the change record or the deployment console as evidence. Precondition: this is a deployment clock and nothing more. It settles nothing about a server that was already reachable on an affected build, where the packet's read-and-write primitive makes the question a triage one.",
+        "evidence": "Packet fields for CVE-2025-27920 ('Srimax Output Messenger Directory Traversal Vulnerability'): cwe_refs CWE-22; cisa_kev true; kev_date 2025-05-19; active_exploitation 'confirmed'; cvss 7.5; rwep_score 77; poc_available true; patch_available true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'; ai_discovered false. Packet attack_vector: 'a directory-traversal flaw (CWE-22) in Srimax Output Messenger, letting an unauthenticated attacker read or write files outside the intended directory (used in the wild to write to startup paths for code execution)'. Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8 'Management of technical vulnerabilities', UK NCSC CAF B4 'System security'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at file disclosure — it records the traversal being used in the wild to write files outside the intended directory, specifically to startup paths, for code execution. That makes patch-in-place the wrong default for any Srimax Output Messenger server that was reachable on an affected build: the update closes the traversal and removes nothing already written through it. The sequencing is what is specific to this CVE and is easy to get backwards. The packet records the vendor fix as typically requiring a service restart or system reboot, and a reboot is exactly the event that runs whatever an attacker placed in a startup or autorun location — so the enumeration has to come first: compare the server's startup and autorun set, and the filesystem regions the service can write, against a known-good baseline BEFORE taking the restart the patch needs, and rebuild from known-good where that comparison cannot be made cleanly. The read half of the primitive needs its own action rather than the same one: the packet describes access to sensitive files outside the intended directory leading to configuration leakage, so every credential and key present in the server's configuration is treated as disclosed and rotated, not inspected for evidence of use. Preconditions and limits: the packet names no implant, tool or artifact, so the trigger for this runbook is reachability during the exposure window rather than an observed indicator; and rotation reaches only material the server itself held — any credential reused elsewhere in the estate is a separate containment question this control does not cover.",
+        "evidence": "Packet attack_vector for CVE-2025-27920: an unauthenticated attacker can 'read or write files outside the intended directory (used in the wild to write to startup paths for code execution)'. Packet vector: the traversal 'allows an attacker to access sensitive files outside the intended directory, potentially leading to configuration leakage or arbitrary file access'. active_exploitation 'confirmed'; cisa_kev true with kev_date 2025-05-19; poc_available true; patch_available true — the fix exists, which is what makes 'patched' the verdict this control overrides; live_patch_available false with live_patch_notes 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Cited as insufficient on this entry: NIST SP 800-53 Rev 5 SI-2 'Flaw Remediation' and EU NIS2 Directive Art. 21 'Security of network and information systems'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-11182": {
     "name": "MDaemon Email Server Cross-Site Scripting (XSS) Vulnerability",
@@ -28063,7 +28554,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "The packet describes an attack that produces no authentication event: an attacker sends an HTML email, the victim views it in MDaemon's WorldClient webmail, and the injected JavaScript runs inside the session the victim already authenticated to, the recorded outcome being theft of session credentials and access to the mailbox. Bound to this product, the control means WorldClient's per-request access logs — not only its login and authentication records — are forwarded off the mail server to a collector the mail server's own compromise cannot reach, with retention long enough to cover a discovery lag measured in months. The detection has to key on what this exploitation actually emits, and the packet documents it: a burst of mailbox reads or message-fetch requests inside a single session immediately following the render of one message, mailbox operations attributed to a session whose source address differs from the address that authenticated it, and forwarding or filter changes made through the webmail session rather than through an administrative login. Authentication-only logging shows one ordinary successful login for all of that, and endpoint anti-malware has nothing to match, because no file is written and no process is spawned — the script executes in the browser session of a user who did exactly what webmail users do, which is why a rule keyed on process or file artifacts would miss an attempt behaving precisely as the packet describes. Distinguishing test: render a benign test message carrying an inert script in a staging WorldClient session and confirm the collector received the message-render request and the subsequent session-scoped mailbox requests as separate attributable records; if the only artifact is the login, the estate cannot reconstruct what a stolen session did. Precondition: this telemetry must already be collected and shipped before the attempt, so it is a posture held ahead of disclosure rather than a rule authored after one, and it detects rather than prevents. It does not invalidate a session token already stolen — a mailbox appearing in these records needs its sessions terminated, its credentials rotated and its forwarding rules and filters reviewed, which the packet's confirmed in-the-wild exploitation and public PoC make warranted wherever an unpatched WorldClient was reachable.",
+        "evidence": "Packet vector: 'MDaemon Email Server contains a cross-site scripting (XSS) vulnerability that allows a remote attacker to load arbitrary JavaScript code via an HTML e-mail message.' Attack vector places it in 'the MDaemon webmail (WorldClient), letting an attacker run script in a victim's authenticated session when they view a crafted email — used to steal session credentials and access the mailbox.' KEV listed 2025-05-19, active_exploitation 'confirmed', poc_available true, CVSS 6.1, RWEP 77, patch_available true, live_patch_available false. NIS2-Art21-incident-handling is recorded as a citing gap on this entry.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case the control exists for, because the number a CVSS-driven programme triages on is the wrong one here: CVSS 6.1 routes an XSS into a medium queue with a 30- or 90-day target, while the packet records CISA KEV listing on 2025-05-19, confirmed in-the-wild exploitation, a public PoC and RWEP 77. Applied to MDaemon, the clock runs from that KEV listing to the fixed WorldClient actually serving mail, and the measurement point is the one this product makes easy to miss: the packet registers no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a server where the update has been installed but the MDaemon service has not been restarted is still serving the vulnerable webmail and must be counted as exposed. On a mail server that restart is the step most likely to be pushed into a maintenance window, because taking it interrupts delivery and drops user sessions, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Distinguishing test: for each mail server, produce the installed version alongside the service start time and show the restart followed the update — a report clean on installed version alone cannot distinguish a remediated server from one still running vulnerable code from memory. Precondition: the packet offers no compensating control to stand in during the interval. The trigger is a user viewing a crafted message in the webmail, so the only interim levers reduce who can do that — restricting WorldClient reachability, or routing users to a mail client other than the vulnerable webmail — and neither removes the flaw; both are holding measures until the restart lands, and neither helps a session whose credentials were already stolen.",
+        "evidence": "Packet: CVSS 6.1 against RWEP 77, with CISA KEV listing 2025-05-19, active_exploitation 'confirmed' and poc_available true. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' The exploitation path the packet gives is a victim viewing a crafted HTML email in the MDaemon webmail (WorldClient). Citing gaps on this entry include AU-Essential-8-Patch, NIST-800-53-SI-2 (Flaw Remediation), 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"
+        ]
+      }
+    ]
   },
   "CVE-2025-4428": {
     "name": "Ivanti Endpoint Manager Mobile (EPMM) Code Injection Vulnerability (variant: CVE-2025-4428)",
@@ -28277,7 +28791,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The packet puts the sink in SAP NetWeaver's Visual Composer Metadata Uploader — a design-time upload function that answers on the same application-server surface as the business functions users must keep reaching. For this product the control means treating that upload path as a trust boundary rather than an internal convenience: content arriving there is constrained to the concrete types the metadata flow legitimately carries instead of being permitted to construct arbitrary objects, and the path answers only from segments with a design-time role rather than inheriting safety from the assumption that NetWeaver is an internal system. The packet carries two readings of who can reach it — its vector describes a privileged attacker deserializing untrusted or malicious content, its attack_vector records unauthenticated remote code execution on the application server — and the control has to hold under the broader one, which is exactly why the constraint belongs at the endpoint rather than in the surrounding session. This is also why the least-privilege gap recorded on this entry stays open under either reading: under the unauthenticated reading no account-privilege scoping is ever consulted, so an access-control attestation passes cleanly while the path is open; and under the privileged-caller reading the outcome the packet itself states is compromise of the confidentiality, integrity and availability of the host system, so SAP role scoping bounds what a user may do inside NetWeaver, not what a deserialization sink does to the host underneath it. Distinguishing test: against a staging instance, submit to the Visual Composer metadata-upload path an object of a type the metadata flow never legitimately conveys and confirm it is refused before any object is constructed. Precondition: the endpoint-side type constraint is a property the SAP update establishes — this control states what to verify, it does not implement it — and the reachability half holds only where the Visual Composer surface can be separated from the application-server surface that must stay reachable. Where they share one exposed surface, segmentation buys nothing and the update is the only remediation; the packet records that update as requiring a service restart or system reboot with no live-patch path, so an instance updated but not restarted is not yet remediated.",
+        "evidence": "Packet fields for this entry: vector 'SAP NetWeaver Visual Composer Metadata Uploader contains a deserialization vulnerability that allows a privileged attacker to compromise the confidentiality, integrity, and availability of the host system by deserializing untrusted or malicious content'; attack_vector 'a deserialization-of-untrusted-data flaw (CWE-502) on SAP NetWeaver (Visual Composer), enabling unauthenticated remote code execution on the application server. CISA KEV-listed 2025-05-15 with confirmed in-the-wild exploitation'; cwe_refs CWE-502; cisa_kev true, kev_date 2025-05-15, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77; patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' NIST-800-53-AC-6 (Least Privilege), UK-CAF-B4 (System security) and NIS2-Art21-network-security (Security of network and information systems) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "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 to code execution on the SAP NetWeaver application server, and the entry's own defense chain states the consequence directly: web shells and stolen credentials survive the patch, and patch-in-place without cleanup leaves the attacker resident or with a usable internal-access pivot. So the disposition for any NetWeaver instance that was reachable from an untrusted network on a vulnerable build is compromised-until-shown-otherwise, not patched-therefore-clear. Applied to this product: hunt in the directories the Java stack serves and executes content from for artefacts that arrived outside a transport, because a web shell dropped through this path is application content rather than product code and the SAP update leaves it in place and running; rotate what the instance held — its application service accounts, the credentials it uses to reach its databases and the adjacent SAP systems, and any keys stored on the host — because NetWeaver is the business-critical hinge of the ERP estate and those credentials are the pivot that a host-level compromise hands over; and review for lateral movement out of the instance across the exposure window. The behaviour to hunt for is what this chain produces at execution time — the NetWeaver Java process spawning a shell or interpreter child, and files appearing in served directories with no corresponding transport — rather than a generic malware signature, which does not reliably fire on an in-process deserialization chain. Precondition: this disposition applies to instances whose exposure during the vulnerable window cannot be excluded; an instance that provably never answered an untrusted caller on a vulnerable build takes the vendor update on the KEV clock instead. Cleaning or rebuilding is not relief from the update — the instance must come up on the fixed level, and the packet records no live-patch path and a fix that typically requires a service restart or system reboot, so remediation is not complete until that restart is taken.",
+        "evidence": "Packet fields for this entry: attack_vector 'a deserialization-of-untrusted-data flaw (CWE-502) on SAP NetWeaver (Visual Composer), enabling unauthenticated remote code execution on the application server'; cisa_kev true, kev_date 2025-05-15, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77; patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' NIST-800-53-SI-2 (Flaw Remediation) is recorded as a citing gap. The entry's own defense_chain supplies the cleanup requirement: prevention 'Apply the SAP NetWeaver update; hunt for web shells and rotate credentials - NetWeaver is business-critical and a compromise pivots into the ERP estate', adequacy 'Patch is necessary but insufficient alone - web shells and stolen credentials survive the patch'; detection 'Monitoring on the SAP NetWeaver: exploit-shaped requests, new web-shell files and unexpected child-process execution'; response 'Patch immediately, hunt and remove web shells, rotate application secrets/credentials, and review for lateral movement', adequacy 'patch-in-place without cleanup leaves the attacker resident or with a usable internal-access pivot'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock for this entry opened on the 2025-05-15 KEV listing, and the specific way an SAP estate misses it is the restart: the packet records a vendor patch, live_patch_available false, and live_patch_notes stating the fix typically requires a service restart or system reboot per the KEV requiredAction, while a production NetWeaver system's restarts are negotiated against business-processing windows rather than against a vulnerability clock. An instance where the SAP fix has been imported but the affected server has not been restarted is still running the vulnerable Visual Composer code and must be counted as exposed — that deferral, recorded as patched, is the failure mode this control exists to prevent, and it is more likely here than on a system whose owners can absorb an unplanned bounce. Completion is measured per NetWeaver instance running Visual Composer, from the level the instance actually reports after restart rather than from an import queue's status. Where an instance cannot take the restart inside the window, this control's alternative is documented compensating controls with a dated action item — for this CVE, restricting which callers can reach the Visual Composer metadata-upload surface — recorded as an interim state and not as an exception that closes the finding. Precondition on that interim: reachability restriction bounds who can deliver the payload and repairs nothing, and under the packet's own vector wording an attacker holding a privileged account, or one already positioned inside a permitted segment, still reaches the deserialization sink. Priority follows the packet rather than the CVSS band alone — confirmed in-the-wild exploitation and a public PoC against the server that carries the organisation's business transactions.",
+        "evidence": "Packet fields for this entry: cisa_kev true with kev_date 2025-05-15, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77; cwe_refs CWE-502; vector 'SAP NetWeaver Visual Composer Metadata Uploader contains a deserialization vulnerability that allows a privileged attacker to compromise the confidentiality, integrity, and availability of the host system by deserializing untrusted or malicious content'; patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' AU-Essential-8-Patch (Patch operating systems) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-12987": {
     "name": "DrayTek Vigor Routers OS Command Injection Vulnerability",
@@ -30192,7 +30738,28 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry is the case the control exists for, and the packet states both halves of it: a vendor fix is recorded — MS10-002, dated 2010, requiring a reboot — and the 2026-05-20 KEV re-listing exists because long-tail unpatched and end-of-life estates remain exposed. Those facts together define the requirement: a host still exposed to this in 2026 is a host with no functioning update path, so reaching MS10-002 is an interim state and the terminal state is taking Internet Explorer out of service on that host, or replacing the host where the browser cannot be removed because the workload depends on it. Scope it to what the packet names — Internet Explorer's HTML rendering — and inventory Internet Explorer installs; the packet provides no mapping from this use-after-free into other browsers or other HTML-rendering software, so treating every renderer in the estate as an instance of this CVE manufactures findings and removal work against software no evidence implicates. Requirement in operational terms: enumerate every host that can still use Internet Explorer to render untrusted web content, record for each whether it can take MS10-002 and be rebooted, put those on the interim clock, and put every host that cannot on a dated removal or replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half, which is where this is usually over-claimed: the packet's live-patch notes state MS10-002 requires a reboot, so a host that received the update but was not rebooted still runs the vulnerable code and is not remediated; and applying a 2010 patch closes this defect only, saying nothing about anything found in that browser since, which is exactly why the requirement cannot end at 'every install reports MS10-002'. Because exploitation is confirmed and the delivery path is a crafted page the victim visits, a host that browsed untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet: CWE-416 use-after-free in Internet Explorer's HTML rendering allowing remote code execution when the victim visits a crafted page — the technique used in the 2010 Operation Aurora campaign. cisa_kev true, kev_date 2026-05-20, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 70. The attack_vector states the legacy re-listing exists because long-tail unpatched/end-of-life estates remain exposed. patch_available true, live_patch_available false, live_patch_notes: 'Microsoft patch MS10-002 (2010); requires reboot.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance outcome on this entry is a fleet report showing full MS10-002 coverage, because the population the scanner can see is the managed, modern one — and the packet places the exposure in long-tail unpatched and end-of-life estates, which are precisely the hosts no management agent enrols and no credentialed scan authenticates to. A patch-coverage percentage computed over enrolled hosts is silent about unenrolled ones, and the metric improves as the exposed hosts drop out of the denominator, so the number gets better as the risk gets worse. The operational test has two halves. First, reconcile the patch-management inventory against an independent observation of what is actually on the network — DHCP leases, switch MAC tables, or network discovery — and show that every host observed there is either enrolled and reporting Internet Explorer's state, or on a dated removal schedule; an unreconciled coverage figure is the paper-compliance answer and must not be accepted as evidence. Second, for hosts that do report, confirm the reboot has actually happened, because the packet's remediation note states MS10-002 requires a reboot while most consoles mark a host patched on installation — an installed-not-rebooted host counts as compliant while still running the vulnerable code. Keep the test population to hosts running Internet Explorer as the packet names it, rather than every HTML renderer in the estate. Limits: this control makes the verdict truthful, it does not change the exposure. Hosts the reconciliation surfaces still need MS10-002 and a reboot if they can take it, and a dated removal schedule if they cannot.",
+        "evidence": "Packet: the attack_vector states the legacy re-listing exists because long-tail unpatched/end-of-life estates remain exposed; cisa_kev true with kev_date 2026-05-20 and active_exploitation confirmed; poc_available true; CWE-416 use-after-free in Internet Explorer's HTML rendering triggered when the victim visits a crafted page; CVSS 8.8, RWEP 70. patch_available true, live_patch_available false, live_patch_notes: 'Microsoft patch MS10-002 (2010); requires reboot.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2010-0806": {
     "name": "Microsoft Internet Explorer Use-After-Free (iepeers)",
@@ -30247,7 +30814,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "A vendor fix for this specific CVE exists — the packet records Microsoft patch MS10-018 (2010), requiring a reboot — but the browser carrying it has no ongoing patch path: the entry's own framework_coverage states that Internet Explorer is end-of-life and unsupported, and the packet's attack_vector explains the 2026-05-20 re-listing as existing because long-tail unpatched and end-of-life estates remain exposed. So MS10-018 plus its reboot is the interim state on any host that can still take it, and removing Internet Explorer is the terminal one. Applied here: enumerate every host on which Internet Explorer can still render attacker-supplied web content, including hosts where it survives not as the user's browser but as the renderer behind a legacy line-of-business application, and carry each to removal or replacement on a bounded, dated schedule rather than an open-ended risk acceptance. Scope it to Internet Explorer as the packet does — the packet ties the use-after-free to that browser's iepeers component and gives no mapping into other browsers or HTML renderers, so putting every browser in the estate on a removal schedule manufactures work against software no evidence implicates. Precondition, and the reason the interim measures are a holding action rather than a fix: restricting Internet Explorer to a named allowlist of internal legacy applications narrows the paths by which an attacker-controlled page reaches the vulnerable renderer, but it covers only the paths the policy actually mediates and leaves the vulnerable component installed and reachable — an allowlisted internal application that loads third-party content, or a redirect out of one, still lands on the sink. Distinguishing test: on a representative host, produce evidence that Internet Explorer is gone, not evidence that it has been demoted from default browser or configured with hardened zones — a host that keeps the renderer while the policy points users elsewhere still carries the vulnerable code.",
+        "evidence": "Packet fields for this entry: vector 'A use-after-free in Internet Explorer's iepeers.dll allows remote code execution when the victim visits a crafted page'; attack_vector 'a use-after-free (CWE-416) in the Internet Explorer iepeers component, exploitable by an attacker-controlled web page for code execution in the browser. CISA KEV-listed 2026-05-20 with confirmed in-the-wild exploitation; the legacy re-listing exists because long-tail unpatched/end-of-life estates remain exposed'; cwe_refs CWE-416; cisa_kev true, kev_date 2026-05-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 70; patch_available true, live_patch_available false, live_patch_notes 'Microsoft patch MS10-018 (2010); requires reboot.' AU-Essential-8-App-Hardening (User application hardening) and UK-CAF-B4 (System security) are recorded as citing gaps. The entry's own framework_coverage supplies the end-of-life fact: its ISO-27001-2022-A.8.8 gap states 'the legacy re-listing exists because organizations still run vulnerable browser/reader builds (Internet Explorer is end-of-life and unsupported)', its AU-ISM-1546 gap names 'retiring end-of-life software (Internet Explorer)' among the load-bearing controls, and its defense_chain prevention step reads 'retire end-of-life software such as Internet Explorer'.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV listing on this entry is dated 2026-05-20, not 2010, and this control's clock runs from the KEV listing or patch availability, whichever is later — so a sixteen-year-old CVE carries a clock that opened this year. That has to be said explicitly because of how a vulnerability programme misses this one, which is structural rather than deliberate: a KEV-driven remediation queue that filters or de-prioritises pre-2015 CVE identifiers as historical, and a scanner whose browser coverage only knows how to grade supported builds, will both stay silent while CISA is asserting confirmed in-the-wild exploitation now. The verified mitigation the clock demands for this CVE is MS10-018 with the reboot the packet records, applied to every host that can still take it; for the hosts that cannot — which per the entry's own attack_vector is the population the re-listing exists for — it is a documented compensating control carrying a dated removal plan, not an open exception. Verification has to read the state of the browser component on the host itself rather than a management console's verdict: on a long-tail or end-of-life estate the console's approved or not-applicable status is the artefact most likely to be stale, and that staleness is precisely how these hosts survived sixteen years of patch cycles while the compliance record stayed clean.",
+        "evidence": "Packet fields for this entry: cve CVE-2010-0806 with cisa_kev true and kev_date 2026-05-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 70; patch_available true, live_patch_available false, live_patch_notes 'Microsoft patch MS10-018 (2010); requires reboot.'; attack_vector records that 'the legacy re-listing exists because long-tail unpatched/end-of-life estates remain exposed'. ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIST-800-53-SI-2 (Flaw Remediation) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2009-1537": {
     "name": "Microsoft DirectShow QuickTime Parsing Memory Corruption",
@@ -32789,7 +33378,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "UniFi OS is the management plane running on the device, and this defect is its authorization decision and its routing decision being taken from two different forms of the same request: the packet has the auth-gateway classifying the raw, percent-encoded URI as a public endpoint while the normalized/decoded request is routed to an authenticated internal service, so encoded '..%2f' sequences smuggle the request out of its intended directory into arbitrary file read and write on the underlying OS. Bound to this product the control has two halves. The endpoint half is that the nginx/unifi-core flow canonicalizes the URI once and takes both the public-versus-authenticated classification and the routing decision from that same normalized form, and that any resolved filesystem path is verified to remain inside the directory the handler is entitled to serve before a file handle is opened — not by stripping traversal sequences from the request string, since the whole defect is that one layer acts on what another has already decoded differently. That half is what the vendor update establishes; this control states the property to verify, it does not implement it. The operator half is that no UniFi OS device is left with its management interface answering from a network with no management role, because the packet's only stated access requirement is network access to the device with no authentication — reachability is the entire exploit precondition. Precondition on that half, which is where it gets over-claimed: restricting reachability bounds who can send the request, it does not repair the URI-handling split, and it is unavailable where the management interface must answer the network the device administers — any host already inside the permitted segment satisfies the packet's access requirement in full. Distinguishing test: from a segment with no management role, send a public UniFi OS endpoint prefix carrying encoded traversal at a staging device and confirm it is refused before any file is read or written; an estate that passes device-account and administrator-MFA attestations still has this path open, because no credential is ever presented on it.",
+        "evidence": "Packet: 'Ubiquiti UniFi OS Path Traversal Vulnerability', CWE-22. Vector: 'The UniFi OS web management interface is reachable by any actor with network access to the device, with no authentication required... the auth-gateway classifies the raw, percent-encoded URI as a public endpoint while the normalized/decoded request is routed to an authenticated internal service, so encoded \"..%2f\" sequences smuggle the request out of its intended directory and yield arbitrary file read/write on the underlying OS', with the KEV description noting accessed files can be 'manipulated to access an underlying account'. cvss 10; rwep_score 79; poc_available true; active_exploitation 'confirmed'; CISA KEV-listed 2026-06-23. patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Citing gaps include NIST-800-53-SC-7 (Boundary Protection), UK-CAF-B4 and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The packet describes a management interface that any actor with network access reaches without authenticating, on a device that fronts the network it administers — so the ordinary appliance-patch window does not apply, and the SLA tier for this CVE is vendor firmware deployed within hours of the 2026-06-23 KEV listing, or the management interface isolated from every segment with no management role until it is. The measurement has to be the firmware each unit is actually running, not an update queued, scheduled or downloaded to it, because a device that has taken no restart into the fixed image is still serving the vulnerable request flow. Two things set the priority above the generic patch queue. The packet records CVSS 10, a public PoC and confirmed exploitation with no authentication required, and it names this flaw being combined in the wild with the access-control bypass CVE-2026-34908 and the package-update command injection CVE-2026-34910 to reach an unauthenticated root RCE chain used to drop a Mirai/Gafgyt-derived botnet — so a unit is not remediated by anything that closes this traversal alone; the remediation state to track is the device reaching a firmware level on which all three named defects are closed, tracked as one device outcome rather than three separate vulnerability tickets that can each be marked done at different times. Precondition: the packet registers no live-patch path, so there is no in-place mitigation that removes the defect ahead of the firmware — isolating the management interface is the interim state and it holds only for the segments it actually excludes, which on a device whose management interface must remain reachable to administer the network may be none.",
+        "evidence": "Packet: CISA KEV-listed 2026-06-23; active_exploitation 'confirmed'; cvss 10; rwep_score 79; poc_available true; privileges required none — 'reachable by any actor with network access to the device, with no authentication required'. 'In the wild it is combined with the access-control bypass (CVE-2026-34908) and the package-update command injection (CVE-2026-34910) to reach an unauthenticated root RCE chain used to drop a Mirai/Gafgyt-derived botnet.' patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2, all cadence-scored.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A UniFi OS device whose management interface answered untrusted requests while on a vulnerable build has to be dispositioned as compromised rather than simply updated. The packet gives the two reasons directly. The primitive is arbitrary file read and write on the underlying OS reached with no credential, so a successful exploit leaves no authentication event to find later, and the firmware update restores the request-handling behaviour while removing nothing that was already written through the write primitive. And the KEV description records that the accessed files can be 'manipulated to access an underlying account', so account access obtained through the read/write path stays valid across the update unless the credential is rotated — while the in-the-wild chain the packet names ends in a Mirai/Gafgyt-derived botnet dropped on the device itself. The response default for an exposed unit is therefore to rebuild it from vendor firmware to a factory-clean state rather than updating in place, re-provision its configuration from a known-good copy rather than preserving the running one, rotate every credential the device held or fronted — its local administrative accounts and anything recoverable from files on it — and review the device's outbound traffic for the botnet activity the packet describes. The distinguishing test is whether the remediation record shows a rebuild and credential rotation alongside the firmware version; a version check reporting the fixed build is exactly the evidence that reads clean while attacker-written content and attacker-held accounts persist, because neither is versioned.",
+        "evidence": "Packet: CWE-22 path traversal yielding 'arbitrary file read/write on the underlying OS' with 'no authentication required'; 'The KEV description notes the accessed files can be \"manipulated to access an underlying account,\" giving credential/account access'; 'In the wild it is combined with the access-control bypass (CVE-2026-34908) and the package-update command injection (CVE-2026-34910) to reach an unauthenticated root RCE chain used to drop a Mirai/Gafgyt-derived botnet.' active_exploitation 'confirmed'; poc_available true; CISA KEV-listed 2026-06-23; cvss 10; rwep_score 79. patch_available true with live_patch_available false — the vendor update is the remediation this control constrains from being applied in place on an already-exploited unit.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-34908": {
     "name": "Ubiquiti UniFi OS Improper Access Control Vulnerability",
@@ -32933,7 +33556,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The defect the packet records is CWE-306 on Splunk Enterprise's PostgreSQL sidecar recovery endpoints: the web application on port 8000 proxies backup and restore file operations to the local PostgreSQL service on port 5435, and those endpoints perform no authentication at all, so any network-reachable caller invokes them. Bound to this product, the control means every recovery, backup and restore function behind the port-8000 web tier authorizes its own caller before it runs, rather than being reachable because it sits behind a front end assumed to have authenticated somebody; and the caller-supplied 'database' parameter is validated as a database identifier instead of being passed through to pg_dump and pg_restore, where the packet shows it becomes a PostgreSQL connection string the attacker can override with his own hostaddr to make the server restore an attacker-supplied dump. This is why the least-privilege control cited as insufficient on this entry never touches the path: the attacker holds no Splunk account, so per-account privilege scoping is never consulted and an access-control attestation covering Splunk roles and capabilities passes cleanly while the endpoints stay open to an unauthenticated caller. Distinguishing test: from a segment with no operational need for Splunk administration, send unauthenticated requests to each recovery endpoint on a staging instance and confirm each is refused before any pg_dump or pg_restore process starts. Precondition, and this is where the control is normally over-claimed: endpoint-side authorization and parameter validation are properties the vendor update establishes — this control states what to verify, it does not implement it. Until that update lands the operator's only lever is limiting who can reach port 8000, and that is a weak lever here, because port 8000 is the product's own web application: restricting it to an administrative segment also removes it from the users the deployment exists to serve, and it does nothing against a caller already inside the permitted segment.",
+        "evidence": "Packet vector: the Splunk Enterprise web application (port 8000) exposes PostgreSQL sidecar recovery endpoints proxied to the local PostgreSQL service on port 5435 that 'perform no authentication, so any network-reachable, unauthenticated attacker can invoke backup/restore file operations (CWE-306)'; 'The attacker controls the database parameter passed to pg_dump/pg_restore, enabling PostgreSQL connection-string injection (e.g. overriding hostaddr) to force the server to restore an attacker-supplied database dump.' CVSS 9.8, RWEP 87, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2026-06-18. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are both recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet supplies every input this clock keys on at once: CVSS 9.8, RWEP 87, a public PoC, confirmed in-the-wild exploitation, and a KEV listing dated 2026-06-18 against a path the packet itself calls pre-auth remote code execution. For this CVE the requirement is that the Splunk Enterprise vendor update run on the KEV clock from that listing rather than being folded into the estate's normal application-patching cadence, with completion measured per instance by the version actually in service rather than by an approval recorded in a change queue. That is the half the cited framework controls do not carry — a patching programme scored on cadence and a technical-vulnerability clause that leaves timescales to the organization both pass their attestations on their own schedule while an unauthenticated network caller still reaches the recovery endpoints. Preconditions the packet sets on the interim window, which is where this control gets over-stated: live_patch_available is false and the packet states remediation is the vendor update plus the named compensating controls until it lands, so there is no mechanism that closes this without taking each instance through the update, and every interim measure is a holding action rather than a fix. Restricting who can reach the port-8000 web tier bounds the population that can send the request; it does not close the endpoint, it does nothing against a caller inside the permitted segment, and it is unavailable wherever that tier has to stay reachable for the deployment's normal use.",
+        "evidence": "Packet: CVSS 9.8, RWEP 87, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2026-06-18. Vector describes an unauthenticated attacker invoking backup/restore operations and the chain escalating 'to pre-auth remote code execution'. patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Citing gaps include AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive the packet describes is an arbitrary file create and truncate as the splunk user, reached through lo_export inside an attacker-supplied database dump, and the packet names what the chain does with it: overwriting executable Python scripts in Splunk's application directory, which run as the splunk user when subsequently invoked. That makes Splunk's application directory a code-execution channel rather than application data, and it is the part of this CVE the vendor update does not address — the update closes the unauthenticated endpoint, but a Python file already overwritten through it survives the upgrade and still runs at its next invocation. The requirement is file-integrity monitoring over Splunk's application directory and every path the instance executes from, alerting on writes that do not correspond to a sanctioned administrator action or a vendor update, plus triage of any instance that was network-reachable during the exposure window against a known-good copy rather than closing it on the patch record. The alert has to key on the behaviour the packet documents — a write or truncate to an executable file under the Splunk application directory, performed by the splunk user, outside a change window — because nothing else in this chain emits a signal: the write arrives through the product's own PostgreSQL restore path, so there is no crash, no new binary dropped by an unusual parent, and no exploit-tool signature; a rule watching for process crashes or named tooling would miss an attempt behaving exactly as the packet describes. Preconditions: this depends on a baseline of the application directory captured before the write and on the monitoring records living off-host, because the attacker holds write access as the splunk user — the same identity a locally-stored baseline sits under. An instance with no prior baseline has to be compared against a clean installation of the same version, not against itself. And detection does not prevent the write; it bounds the window to alert-and-response time.",
+        "evidence": "Packet vector: the malicious SQL uses 'lo_export to write arbitrary files as the splunk user, giving an arbitrary file create/truncate primitive. The chain escalates to pre-auth remote code execution by overwriting executable Python scripts in Splunk's application directory, which run as the splunk user when subsequently invoked.' active_exploitation 'confirmed', poc_available true, cisa_kev true with kev_date 2026-06-18. patch_available true; live_patch_available false. NIST-800-53-SI-2 (Flaw Remediation) is recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-48907": {
     "name": "Widget Factory Joomla Content Editor Improper Access Control Vulnerability",
@@ -33146,7 +33801,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Catalyst SD-WAN Manager (formerly SD-WAN vManage) is the management plane the packet names, and the defect sits in its upload handling: the network-reachable web UI/API exposes a file-upload handler that does not validate user-supplied file paths during upload processing, so ../ sequences in a crafted HTTP request select where a privileged write lands. Bound to this product, the control means every file-accepting endpoint on SD-WAN Manager normalizes the caller-supplied destination to an absolute canonical path and rejects it when the resolved result leaves the intended upload directory, with that check performed before the write executes rather than by filtering the request string; and that the endpoint authorizes the caller against what that particular account is entitled to write instead of treating an authenticated session as sufficient. The packet's access requirement is what makes the second half load-bearing on this entry rather than the first alone: the attacker holds only a low-privileged, single-task user account, so on this appliance every account that can authenticate to the web UI/API is in exploit terms a root account on the control plane, and an authorization decision that ends at 'the session is valid' never consults that difference. Distinguishing test: on a staging SD-WAN Manager, authenticate as a single-task, low-privileged user and send each file-accepting endpoint an upload whose destination path resolves outside the intended upload directory; confirm it is refused before anything is written — an instance whose user-role definitions audit cleanly still performs the write if the handler resolves the caller-supplied path. Precondition, and this is where the control is usually over-claimed: the endpoint-side path validation is a property the vendor update establishes, so this control states what to verify and does not implement it. The packet registers no live-patch path for this product class, so until that update and its restart land the only operator-side lever is restricting which segments can reach the web UI/API — which bounds who can present the upload, leaves the handler fully exploitable to anything inside the permitted segment, and is unavailable wherever the interface must stay reachable for operators to manage the fabric.",
+        "evidence": "Packet vector: the web UI/API of Cisco Catalyst SD-WAN Manager (formerly SD-WAN vManage) is network-reachable and exposes a file-upload handler that fails to validate user-supplied file paths during upload processing; an authenticated attacker holding only a low-privileged, single-task user account sends a crafted HTTP request with path-traversal (../) sequences and obtains an arbitrary file create/overwrite primitive anywhere on the underlying operating system. CWE-22. CISA KEV-listed 2026-06-15 with active_exploitation confirmed and poc_available true; RWEP 77 against CVSS 6.5. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "This appliance is a fleet control plane in the sense the control governs — the packet states that compromising it yields full compromise of the SD-WAN control plane that pushes policy and routing to every managed edge device — and the packet's escalation path is an attacker overwriting a privileged configuration, cron, or startup file to reach root. That is exactly the case where the patch record and the incident are different questions: the vendor update closes the traversal but reverts nothing already written through it, and a cron or startup file planted before remediation survives the upgrade and keeps running as root. Scoped to what this packet establishes, the playbook for any SD-WAN Manager that was reachable and unpatched during the window opened by the 2026-06-15 KEV listing is: compare the appliance's configuration, cron, and startup content against a known-good baseline instead of accepting the upgraded build as closure; treat every credential and key the controller holds or distributes as exposed and rotate it, since root on the appliance reaches all of it; review the policy and routing pushed to managed edge devices during that window for changes with no corresponding operator action; and set in advance the quarantine criteria for an edge device that accepted configuration from a suspect controller. Precondition: this is post-compromise triage and not prevention — it does nothing to stop the traversal, and it depends on a baseline captured before the exposure window, which is the part most estates do not hold. Where no such baseline exists the comparison cannot be made and the terminal action is rebuilding the controller from vendor media and re-pushing known-good policy, not inspecting it in place.",
+        "evidence": "Packet vector: the arbitrary file create/overwrite primitive is chained by overwriting a privileged configuration, cron, or startup file, or planting executable content, to elevate to root, 'yielding full compromise of the SD-WAN control plane that pushes policy and routing to every managed edge device'. active_exploitation confirmed, CISA KEV-listed 2026-06-15, poc_available true, RWEP 77. patch_available true with live_patch_available false; live_patch_notes state remediation is the vendor update plus the named compensating controls until it lands.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-34028": {
     "name": "Commvault Command Center Path Traversal Vulnerability",
@@ -34161,7 +34840,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "clfs.sys ships with Windows and the packet's path into it runs through standard CLFS APIs operating on a crafted base-log (.blf) file, available to any local user — so the affected population is every Windows host in the estate, not a role-scoped subset, and there is no feature to switch off or service to stop that takes the driver out of a normal build. For this CVE the control means driving the Microsoft update that carries the fix across that whole population on the clock that opened with the 2025-04-08 KEV listing rather than folding it into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. The packet registers no live-patch path for this product class and states that remediation is the vendor update plus compensating controls until it lands, so a host that has taken the update but not restarted still runs the vulnerable driver and must be counted as exposed. Priority follows the packet rather than the 7.8 CVSS: from the SYSTEM token this flaw produces, the packet's chain injects into winlogon.exe, dumps LSASS for credentials and launches RansomEXX from dllhost.exe, so a host where the escalation succeeds is a credential-theft and domain-wide ransomware event rather than an endpoint finding. Enumerate multi-user hosts first — session hosts, shared workstations, build agents, jump boxes — because the precondition the flaw needs, a local low-privileged authenticated user running code, is their normal operating state; they are also where the restart is most likely to be deferred because taking it evicts logged-on users, and a deferral recorded as patched is the specific way this remediation goes wrong. The privilege half of the estate's control set cannot substitute here: the attacker already holds a legitimate low-privileged account and the boundary that fails is inside the kernel driver, so tightening account privilege leaves the path intact while its attestation reads clean.",
+        "evidence": "Packet fields for this entry: name 'Microsoft Windows Common Log File System (CLFS) Driver Use-After-Free Vulnerability', CWE-416. Vector and attack_vector: 'A local, low-privileged authenticated user reaches the Common Log File System (clfs.sys) kernel driver through standard CLFS APIs operating on a crafted base-log (.blf) file, triggering a use-after-free (CWE-416) on a freed CLFS structure. The actor leaks kernel addresses to user mode via NtQuerySystemInformation, then weaponizes the dangling pointer together with the RtlSetAllBits primitive to overwrite the exploiting process's token privileges field with 0xFFFFFFFF, granting all privileges and effectively SYSTEM. With SYSTEM, the chain injects into winlogon.exe, dumps LSASS for credentials, and launches RansomEXX from dllhost.exe — turning a post-compromise foothold into domain-wide ransomware impact.' cisa_kev true with kev_date 2025-04-08, active_exploitation confirmed, poc_available true, cvss 7.8, rwep_score 81. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "On a Windows estate this control's telemetry is ETW and endpoint-agent event data rather than the auditd or eBPF form it takes on Linux hosts, and the packet describes the exploit precisely enough to key on it rather than on a stand-in. The signature is a same-process privilege transition: a low-privileged process creates or writes a CLFS base-log (.blf) file and drives the CLFS APIs against it, calls NtQuerySystemInformation to leak kernel addresses into user mode, and then keeps running under the same PID with its token privileges field set to all bits. Alert on that transition — a process whose token acquires SYSTEM-equivalent privileges with no corresponding logon, service start, or impersonation event — and correlate it with the follow-on the packet names: code injection into winlogon.exe, a handle opened to lsass.exe with memory-read access, and dllhost.exe spawning a child that is not a COM surrogate workload. The correlation is what makes the rule usable: .blf files are written by legitimate software and NtQuerySystemInformation is called by ordinary tooling, so either signal alone is noise, while the sequence inside a short window is not. Note what would miss an attempt behaving exactly as the packet describes: nothing crashes, no driver is loaded, no service is created, and no new SYSTEM-owned process appears — the escalation happens inside an already-running ordinary process — so rules keyed on crashes, driver-load events, new elevated processes, or named exploit-tool signatures see nothing. Preconditions. This requires endpoint telemetry that was already being collected and forwarded off-host before the attempt, because the moment the token flips the actor holds SYSTEM on that host and can stop or blind a locally-buffered agent, leaving an on-host-only trail under the attacker's control at exactly the point it matters. And detection prevents nothing: it bounds the interval between the escalation and the LSASS dump and ransomware launch to alert-and-response time, during the window before the vendor update and its restart land. It is the interim posture, not the remediation.",
+        "evidence": "Packet fields for this entry: the vector describes the full chain — a crafted base-log (.blf) file driving a use-after-free in clfs.sys, kernel addresses leaked to user mode via NtQuerySystemInformation, the RtlSetAllBits primitive used to overwrite the exploiting process's token privileges field with 0xFFFFFFFF for effective SYSTEM, then injection into winlogon.exe, an LSASS credential dump, and RansomEXX launched from dllhost.exe. cisa_kev true, kev_date 2025-04-08, active_exploitation confirmed, poc_available true, cvss 7.8, rwep_score 81. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands' — the packet itself names compensating controls as what holds until the update. UK-CAF-B4 (System security) is recorded as a citing gap against this entry, and its stated shortfall is precisely this: an interim compensating-control posture for an actively-exploited local privilege escalation with a public PoC is not enumerated as distinct from applying the vendor patch.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-30406": {
     "name": "Gladinet CentreStack and Triofox Use of Hard-coded Cryptographic Key Vulnerability",
@@ -34554,7 +35256,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Sitecore CMS and Experience Platform (XP) is a content-management web tier, and the packet's path into it is one HTTP POST: a ysoserial.net TypeConfuseDelegate gadget supplied as the __CSRFTOKEN parameter to any page the Sitecore.Security.AntiCsrf module guards, executing inside ObjectStateFormatter before the module ever compares that value to __CSRFCOOKIE. With a public PoC and confirmed exploitation there is no attack complexity buying time, so the clock runs from the 2025-03-26 KEV listing rather than from the next CMS release train. The packet records a vendor patch with no live-patch path and states that until it lands the remaining measures are this entry's named compensating controls — so remediation means getting every Sitecore instance onto the vendor's fixed build, with completion measured by reading the running build off each instance rather than from a deployment ticket. Two preconditions bound what meeting this SLA actually buys. First, this is the 9.x post-authentication variant: the packet records that exploitation requires a valid authenticated session, so restricting who can reach the CMS narrows the caller population during the window before the fix but closes nothing against anyone already holding a Sitecore credential, including a low-privilege content account — network restriction is a holding measure, not a substitute for the build. Second, an SLA met from the listing forward settles nothing about instances that were already reachable on an affected build, and the packet's chain ends in a reverse shell, which is a triage question rather than a patching one.",
+        "evidence": "Packet fields for CVE-2019-9875 ('Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (post-authentication)'): cwe_refs CWE-502; cisa_kev true; kev_date 2025-03-26; active_exploitation 'confirmed'; cvss 8.8; rwep_score 68; poc_available true; patch_available true; live_patch_available false; live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'; ai_discovered false. Packet attack_vector: the Sitecore.Security.AntiCsrf module 'deserializes the attacker-supplied __CSRFTOKEN HTTP POST parameter via ASP.NET's ObjectStateFormatter BEFORE comparing it to the __CSRFCOOKIE value', the formatter 'is instantiated with a null _page' so 'it performs no MAC/signature validation on the LOSFormatter stream', an attacker 'supplies a ysoserial.net TypeConfuseDelegate gadget encoded for the ObjectStateFormatter', and 'For the 9.x branch this CVE requires a valid authenticated session (PR:L)'. Cited as insufficient on this entry: ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8 'Management of technical vulnerabilities', UK NCSC CAF B4 'System security'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's path does not stop at deserialization: code runs in-process as the IIS application-pool identity, the gadget's PowerShell stager pulls a second stage and opens a reverse shell, giving arbitrary command execution on the web server and access to the underlying filesystem. Sitecore is an application tier rather than an appliance, but it occupies the position this control governs, and with exploitation confirmed a Sitecore instance that was reachable by a credential holder on an affected build during the exposure window is a triage subject rather than a patch ticket. The vendor build removes the deserialization sink and removes nothing the second stage wrote, and it revokes nothing the application-pool identity could read — connection strings and configuration secrets held by that instance stay valid across the upgrade. The requirement for this CVE is therefore: export configuration and content for review, rebuild the web tier from a known-good image on the fixed build instead of upgrading the live instance, and rotate every secret reachable from the application-pool identity. The packet supplies one triage anchor directly, and it is the one most likely to be misread: because the gadget executes 'regardless of the subsequent cookie-mismatch error', a successful exploitation leaves a CSRF cookie-versus-parameter mismatch entry in the application's own logs — a line that reads as the security control working, written after the code has already run. Precondition and honest limit: the packet records the end state as a reverse shell and names no implant, tooling or artifact, so the trigger for this runbook is reachability during the window, not an observed indicator; and if the triage is deferred, a later rebuild taken from a baseline captured after the exposure reproduces whatever was written rather than removing it.",
+        "evidence": "Packet attack_vector for CVE-2019-9875: the gadget 'executes during deserialization regardless of the subsequent cookie-mismatch error'; 'code runs in-process as the IIS app-pool identity, after which the gadget's PowerShell stager pulls a second stage and opens a reverse shell, giving arbitrary command execution on the web server and access to the underlying filesystem'; an attacker must 'reach a guarded Sitecore endpoint (e.g. CreateNewUser.aspx)'. active_exploitation 'confirmed'; cisa_kev true with kev_date 2025-03-26; poc_available true; patch_available true — the fix exists, which is what makes 'patched' the compliance verdict this control has to override; live_patch_available false. Cited as insufficient on this entry: NIST SP 800-53 Rev 5 SI-2 'Flaw Remediation' and EU NIS2 Directive (2022/2555) 'Vulnerability handling'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-9874": {
     "name": "Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (unauthenticated)",
@@ -34609,7 +35334,42 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "For Sitecore the trust boundary is inside the AntiCSRF module's own request handling: the packet has Sitecore.Security.AntiCSRF taking the value of the __CSRFTOKEN HTTP POST parameter and deserializing it with .NET BinaryFormatter without type restriction, and on affected 8.x and earlier builds doing so before authentication is enforced — so an anonymous request rebuilds an arbitrary object graph in the IIS worker process. Two properties have to hold for this product. The parameter is a CSRF token, so what arrives in it must be constrained to the concrete, primitive shape that flow legitimately carries and must never be permitted to instantiate types the module does not need — an unrestricted formatter is not a deserializer with a weak filter, it is no filter at all, which is why a published gadget chain is sufficient. And the authentication decision must precede the deserialization, because ordering is the second half of the defect: reversing it removes the anonymous reach even where the sink remains. Both are properties the vendor update establishes; this control states what to verify, it does not implement it. Precondition, and this is where the control is normally over-claimed: its network-restriction half is largely unavailable here. The packet says the sink is reachable 'on any AntiCSRF-protected page', so binding the surface to a management segment only helps an instance whose AntiCSRF-protected pages are all administrative — where such a page is part of the publicly served site, no segmentation removes the path and the update is the only closure. Constraining the IIS application-pool identity's rights and what it can reach bounds what a successful gadget chain does next, but it does not stop the deserialization, and the packet records the outcome as command execution in that identity's context with no separate privilege-escalation step needed.",
+        "evidence": "Packet: 'Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (unauthenticated)', CWE-502. Vector: 'The Sitecore.Security.AntiCSRF module accepts the value of the HTTP POST parameter __CSRFTOKEN and deserializes it with .NET BinaryFormatter without type restriction, reachable over the network on any AntiCSRF-protected page. On affected 8.x and earlier builds the deserialization occurs before authentication is enforced, so an unauthenticated remote attacker (CVSS 9.8, AV:N/PR:N) can submit a crafted serialized object... arbitrary command execution in the context of the IIS application pool identity hosting Sitecore, yielding full server compromise without needing a separate privilege-escalation step.' CISA KEV-listed 2025-03-26; active_exploitation 'confirmed'; cvss 9.8; rwep_score 68; poc_available true; patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A Sitecore instance that served AntiCSRF-protected pages to an untrusted network on an affected 8.x-or-earlier build has to be dispositioned as compromised rather than upgraded in place. Two facts from the packet make patch-in-place the wrong default. First, the deserialization occurs before authentication is enforced, so a successful exploit generates no authentication event to find afterwards — the site's login records will look clean for the intrusion. Second, the outcome is arbitrary command execution as the IIS application-pool identity with access to the underlying filesystem, and an .aspx web shell or scheduled task placed through that primitive survives the vendor upgrade untouched and keeps answering after it. The response default is therefore to treat the deployed web root and every writable media and upload directory as attacker-modifiable: diff the live tree against the known-good deployment artefact, rebuild the server from source of truth at the fixed version instead of upgrading in place, and rotate what the box held — the application-pool and service accounts, the Sitecore administrator accounts, the database connection strings in the instance configuration, and any key or certificate material stored on it. The distinguishing test is whether the remediation record carries a file-integrity comparison of the deployed tree alongside the version change; an upgrade ticket on its own cannot show that a file written through this path was removed, and a version scan reporting the fixed build is exactly the evidence that passes while an implant stays resident. Scope the exposure window honestly: the packet pairs a public PoC and confirmed exploitation with a 2019 CVE identifier carried into a 2025 KEV listing, so an instance left on an affected build was reachable across that whole interval — 'we upgraded when it reached KEV' bounds the remediation date, not the intrusion window.",
+        "evidence": "Packet: unauthenticated CWE-502 deserialization where 'the deserialization occurs before authentication is enforced', giving 'arbitrary command execution in the context of the IIS application pool identity hosting Sitecore, yielding full server compromise without needing a separate privilege-escalation step', with the 9.x-branch companion entry noting access to the underlying filesystem. active_exploitation 'confirmed'; poc_available true; CISA KEV-listed 2025-03-26 against a CVE identifier dated 2019; cvss 9.8; rwep_score 68; patch_available true, and live_patch_available false — remediation is the vendor update, which is precisely the patch-in-place action this control constrains.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a cadence-driven vulnerability programme has no event to fire on at all: the vendor fix long predates the listing, so nothing in a monthly or quarterly cycle distinguishes this from any other aged advisory, and the 2025-03-26 KEV listing is the only trigger that reflects the real risk state. The requirement for this product is that Sitecore instances on affected 8.x-and-earlier builds move to the vendor-fixed release on a clock started by that listing rather than on a CMS-upgrade roadmap, and that the SLA is measured by the instance actually serving requests on the fixed build — not by an approved change ticket or a scheduled upgrade window, which for a major Sitecore version step is where the delay accumulates. Precondition, stated plainly because this is where the SLA is usually reported as met: the packet records no live-patch path, so there is no in-product interim fix that removes the sink — the compensating controls named on the entry are what hold until the upgrade lands, and where the upgrade cannot be completed inside the clock, the only remaining lever is removing the affected instance's AntiCSRF-protected pages from untrusted network reach. That lever is unavailable for an instance whose AntiCSRF-protected pages are part of the public site, and for those an unmet clock is exposure to an unauthenticated, publicly-exploited pre-auth RCE rather than an accepted risk with a compensating control behind it.",
+        "evidence": "Packet: CISA KEV-listed 2025-03-26 with active_exploitation 'confirmed' and poc_available true on a CVE identifier dated 2019; cvss 9.8, rwep_score 68; privileges required none — 'an unauthenticated remote attacker (CVSS 9.8, AV:N/PR:N) can submit a crafted serialized object'. patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' The entry cites AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management — all cadence-based — as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2017-12637": {
     "name": "SAP NetWeaver Directory Traversal Vulnerability",
@@ -35335,7 +36095,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Win32k kernel subsystem and describes an attacker who already holds low-privilege local code execution winning a race to turn a use-after-free on the W32PROCESS structure into a controlled kernel write/execute primitive and a SYSTEM token — the escalation executes in kernel code, below every account boundary an endpoint estate is audited on. For this CVE the control means the Windows update carrying the fix is driven on the clock the 2025-03-11 KEV listing opened rather than folded into the next monthly rollup, with completion measured by the build each host is actually running rather than by 'approved' or 'downloaded' in the management console. The population to enumerate first is the one the packet names — hosts on affected builds predating 1809 — not the Windows estate at large, which the packet does not implicate. The prioritisation half is the load-bearing one here, because every routine escalation trigger points the wrong way: CVSS 7.0, a vendor rating of Important rather than Critical that the packet attributes to the race that must be won, and poc_available false. A program that accelerates on severity band or on public-exploit availability leaves this on the ordinary cycle while the packet records exploitation as confirmed and the flaw already wired into a delivery chain behind the PipeMagic backdoor. Precondition: the packet registers no live-patch path, so nothing removes the defect before the update lands — the compensating controls named on the entry are a holding measure for that window, not a substitute for the update. And because this is a second-stage escalation reached only after an initial foothold, updating a host that was already exploited closes the escalation path without removing the foothold that reached it or undoing what was done with SYSTEM; such a host belongs on the incident path, not on the patch record.",
+        "evidence": "Packet: 'Microsoft Windows Win32k Use-After-Free Vulnerability', CWE-416. Vector: 'An attacker who already has low-privilege local code execution on an affected, pre-1809 Windows build triggers a use-after-free in the Win32k kernel subsystem: by winning a race condition, the W32PROCESS structure is dereferenced one more time than its reference count allows... escalating the process token to SYSTEM', the bug 'reached only after initial foothold (here, via the PipeMagic backdoor)', a 'second-stage local privilege escalation' with follow-on 'credential theft, persistence, and ransomware staging', and 'The high attack complexity reflects the race that must be won, which is why Microsoft rated it Important rather than Critical.' CISA KEV-listed 2025-03-11; active_exploitation 'confirmed'; cvss 7; rwep_score 59; poc_available false; patch_available true; live_patch_available false with live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' The entry cites AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, NIS2-Art21-vulnerability-management and UK-CAF-B4 as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "This is a Windows kernel-mode flaw, so the rule is built on host kernel/process telemetry rather than on auditd or eBPF — and the packet describes the behaviour precisely enough to key on it. The exploit has to win a race, and a race is repetitive: a low-privileged user-mode process drives the same Win32k path in a tight loop, many attempts in a short window from one process and its threads, before the timing lands. The rule therefore keys on that shape, paired with the outcome the packet names: that same already-running low-privileged process afterwards holding a SYSTEM token — a token and integrity-level transition inside a live process with no service start, no consented elevation and no scheduled task to account for it — followed by SYSTEM-context activity from a process whose parent chain is an ordinary user session. Both halves are needed: repeated Win32k calls alone are noisy, and a SYSTEM-context process alone is normal; it is the pairing inside a short window that separates this from either. Note what will not see it. Do not key on a crash or bugcheck: the packet's chain grooms the pool to reclaim the freed allocation with attacker-controlled data and continues into credential theft, persistence and ransomware staging, which requires the host to keep running. Do not key on a driver load or a new signed binary — nothing is loaded, the vulnerable code is the operating system's own Win32k, and the exploit runs from a foothold already on the host. Do not key on a public exploit's signature: the packet records poc_available false, so there is no public tool artefact to match. Precondition: this needs kernel-level process and token telemetry already being collected and shipped off-host before the attempt; a rule written afterwards against telemetry nobody was gathering produces nothing. Detection does not prevent the escalation and does not remediate the flaw — it bounds the window between the KEV listing and the update, and because the packet places the bug after an initial foothold, an alert here is an incident already in progress: the response is host isolation and hunting the delivery-stage implant, not only applying the update.",
+        "evidence": "Packet: CWE-416 use-after-free in the Win32k kernel subsystem, exploited 'by winning a race condition' and turned into 'a controlled kernel write/execute primitive, escalating the process token to SYSTEM'; reached 'only after initial foothold (here, via the PipeMagic backdoor)' and used for 'credential theft, persistence, and ransomware staging'. active_exploitation 'confirmed'; CISA KEV-listed 2025-03-11; poc_available false; patch_available true; live_patch_available false, so every affected host carries an exposure window until the vendor update lands.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-45659": {
     "name": "Microsoft SharePoint Server Deserialization of Untrusted Data Vulnerability",
@@ -35390,7 +36173,22 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_disclosure",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's timing is the whole argument on this entry: KEV listing 2026-07-01 with a due date of 2026-07-04 — three days — against SharePoint Server, which in most estates is patched inside a scheduled farm-maintenance window measured in weeks. Applied to this CVE the control means the SharePoint update is driven on the KEV clock rather than folded into the next farm window, and completion is measured per server against the fixed build, not per farm: a farm is remediated only when every server running the SharePoint Server product has taken the update, and one that has updated some of its servers still answers requests on the rest. The population to enumerate first is any farm whose authenticated surface is open to a broad user base, because the packet describes the attacker as authorized — the account is legitimate, so the deserialization path is reachable by whoever already holds a SharePoint account rather than by an attacker who must first defeat authentication, and tightening per-account privilege does not close it. Precondition: the packet records no live-patch path for this product class and gives the vendor update as the remediation, so there is no interim measure here that removes the deserialization sink — the clock is met by the update landing on every affected server, not by a compensating rule, and a server that has taken the update but not been through the restart the product class requires has not met it. Priority follows the packet rather than the CVSS band or PoC availability: no public PoC is recorded, but exploitation is confirmed in the wild and the KEV due date is three days after listing, so the absence of a published exploit is not a reason to run the standard window. Because exploitation is confirmed, a farm reachable by any account holder during the exposure window needs triage of what ran on it rather than being closed on the patch record.",
+        "evidence": "Packet name: 'Microsoft SharePoint Server Deserialization of Untrusted Data Vulnerability' (CWE-502). Packet vector: 'Deserialization of untrusted data in Microsoft Office SharePoint allows an authorized attacker to execute code over a network.' Packet attack_vector adds: 'CISA KEV-listed 2026-07-01 (due 2026-07-04) with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available false; CVSS 8.8; RWEP 59. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update (or, for end-of-life products, decommissioning) plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-48558": {
     "name": "SimpleHelp Authentication Bypass Vulnerability",
@@ -36490,7 +37288,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The remediation-priority problem this entry poses is a timing one, and it is specific: the identifier is a 2023 CVE but the KEV listing is dated 2025-02-25, and the packet records no public proof-of-concept, which is what holds RWEP at 46 against a CVSS of 9.0. An estate that orders its Zimbra patch queue by CVE age, by disclosure date, or by whether an exploit is publicly circulating will place this behind newer and noisier items while the packet records exploitation as confirmed. The control's requirement here is that the KEV listing date, not the CVE year and not exploit-availability signal, starts the clock for every Zimbra Collaboration Suite instance in the 8.8.15 line the packet names, and that completion is measured by each instance actually running the vendor's fixed build rather than by a change ticket being approved. Scope it to the Zimbra Collaboration Suite instances the packet identifies; nothing here maps the flaw into other groupware in the estate. Preconditions. The packet records no live-patch path for this product class and names the vendor update as the remediation, so the only two states the SLA can be met in are 'fixed build running' or 'documented compensating controls in place with a dated action item' — there is no third state where the software keeps running unmodified and the requirement is satisfied. And a 4-hour clock is only real where an emergency change path exists for the mail platform that does not queue behind the monthly window; naming the SLA without pre-authorising that path produces a missed target rather than a fast one.",
+        "evidence": "Packet facts: name 'Synacor Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Vulnerability', CWE-79; CISA KEV-listed 2025-02-25 with active_exploitation 'confirmed'; CVSS 9.0, RWEP 46; poc_available false; patch_available true, live_patch_available false, with live_patch_notes stating 'No live-patch path for this product class; remediation is the vendor update ... plus the named compensating controls until it lands'. Vector: 'Cross Site Scripting vulnerability in Zimbra ZCS v.8.8.15 allows a remote authenticated attacker to execute arbitrary code via a crafted script to the /h/autoSaveDraft function.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "This control's substance is webmail per-request access logging shipped off the mail server, and the asset class it was written for is the same one this packet names — a web mail client whose exploitation stage rides an already-authenticated session. Applied to Zimbra Collaboration Suite, it means the web client's per-request access logs, not just its authentication events, are forwarded to an external collector with retention long enough to cover the window this CVE actually spent unremediated. The behaviour to key on is the one the packet documents: a request to the /h/autoSaveDraft function carrying script content, issued by an authenticated ZCS account, and the subsequent rendering of that draft in another user's session. Both halves matter — the packet's attacker is a remote authenticated attacker, so the request arrives inside a valid session and the authentication log records nothing but a normal login by an account that is entitled to log in. Nothing crashes, no privilege is requested, and no failed authentication occurs, so a detection built on login anomalies, lockouts, or availability loss misses an attempt that behaves exactly as described. This is also the only way an operator answers the question the KEV listing forces: the packet records confirmed in-the-wild exploitation with no public proof-of-concept, so the technique is not reproducible in-house and the sole evidence of whether a given instance was targeted is what its request logs preserved. Preconditions. The logging and forwarding must have been in place during the exposure window — configuring it now answers nothing about the past, and logs left on the mail server are within reach of anyone who leveraged this to act as a mailbox owner. And detection is not remediation: it bounds the response window and scopes an investigation, while the vendor update the packet names remains the fix.",
+        "evidence": "Packet facts: vector states the flaw 'allows a remote authenticated attacker to execute arbitrary code via a crafted script to the /h/autoSaveDraft function' in Zimbra ZCS v.8.8.15; CWE-79; active_exploitation 'confirmed' with CISA KEV listing 2025-02-25; poc_available false; patch_available true, live_patch_available false with the vendor update recorded as the remediation.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-49035": {
     "name": "Microsoft Partner Center Improper Access Control Vulnerability",
@@ -36917,7 +37739,29 @@
         "adequate": false,
         "gap": "Secure-by-default configuration for the CMS platform doesn't extend to an unauthenticated file-attachment feature bundled inside a calendaring extension."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "iCagenda is a Joomla extension, and that is what makes a KEV clock the missing control here rather than a redundant one: the remediation this flaw needs is an update to the extension, which does not arrive with Joomla core updates and is not what a 'the CMS is current' attestation measures. Bound to this CVE the requirement is that the clock opened by the 2026-07-10 KEV listing drives the iCagenda update on every site in the estate that has the extension installed, with completion measured as the installed iCagenda version per site rather than as a ticket closed against the platform. Because the packet's path is a single unauthenticated request to a public event-attachment feature that lands an executing PHP file, there is no authentication or authorization step for a compensating control to tighten — the only levers before the update lands are removing or disabling the attachment feature and denying script execution in the directory uploads land in. State the precondition on that interim measure rather than recording it as the mitigation: an execution-deny holds only where the operator controls the web-server configuration and where the attachment directory is the only place the upload can come to rest; it is unavailable on shared hosting where that configuration is not the operator's, and it does not remove a file already written. With exploitation confirmed and a public PoC, a site that ran the vulnerable extension while reachable may already hold an uploaded PHP file, and that file survives the update — so the update closes the path and the site still needs its attachment directory examined for content it did not put there.",
+        "evidence": "Packet: CWE-434, unrestricted upload of file with dangerous type; an unauthenticated attacker submits a crafted file through iCagenda's public event-attachment feature, the extension does not validate file type or require authentication, and a PHP payload lands in a web-accessible directory and executes. CISA KEV-listed 2026-07-10; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 63. patch_available true, live_patch_available false, with no live-patch note recorded.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Paper compliance has a specific shape on this CVE: a scan that reports the Joomla core build says nothing about iCagenda, so a site with a fully patched CMS and a vulnerable extension reports clean, and the configuration-management record backing that report is complete at the platform level and empty at the extension level. The operational test for this entry is whether the scan enumerates installed Joomla extensions with their versions and compares iCagenda's installed version against the fixed one — and, because the packet's path needs no credentials and no authentication, whether an unauthenticated probe of the site's event-attachment endpoint is part of the check rather than a credentialed inventory the scanner may not be able to obtain. That second half is what distinguishes a real test from a version-table lookup: the exploit is an unauthenticated upload to a public feature, so the check that mirrors the attacker's position is an unauthenticated one. Precondition and limits: this control determines whether the estate can see the exposure, it does not remove it, and a site the scan flags still needs the extension update the packet records. It also depends on the extension inventory being obtainable at all — sites where extensions were installed outside the operator's change process are exactly the sites a credentialed scan under-reports, so a maintained record of which extensions each Joomla site runs is what makes the scan meaningful rather than reassuring.",
+        "evidence": "Packet: the affected component is the iCagenda extension for Joomla, not the Joomla platform; the flaw is CWE-434 and the path is an unauthenticated crafted file submitted through the extension's public event-attachment feature, landing a PHP payload in a web-accessible directory where it executes. CISA KEV-listed 2026-07-10; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 63; patch_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.9",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-56290": {
     "name": "Joomlack Page Builder Improper Access Control Vulnerability",
@@ -37076,7 +37920,32 @@
         "adequate": false,
         "gap": "Technical vulnerability management requires confirming remediation efficacy, not just patch application — relevant here given the reported incomplete fix."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Every framework control cited on this entry closes on a version number, and this is the packet where that is not evidence of remediation: the live-patch note records community reports on the JoomShaper forum, post-6.6.2, that the IconsTrait.php code path may remain exploitable after the 6.6.2 patch, and states that operators should verify remediation rather than treat the version bump alone as sufficient. An extension inventory that reads SP Page Builder's reported version and marks the site patched is therefore paper compliance on this specific defect. The operational test for this product is a request rather than a version read: against a staging copy of the site, from an unauthenticated client carrying no session and no CSRF token, POST a PHP payload to SP Page Builder's asset.uploadCustomIcon task and then attempt to fetch the resulting file. The site is remediated when the upload is refused before anything is written — not when the extension reports 6.6.2. Re-run the test after every subsequent SP Page Builder update, because the packet's point is that a version bump on this exact code path has already once been reported as not closing it. Precondition: this control verifies, it does not repair. The missing session, permission and CSRF checks on the upload task are the vendor's to restore, so a site that fails the test has only the vendor's next release, or removal of the extension, as an actual fix — the test result is not itself a mitigation. And because the packet records confirmed exploitation with a public PoC, a site passing the test today establishes nothing about whether it was already exploited before the test was run.",
+        "evidence": "Packet live_patch_notes: 'Community reports (JoomShaper forum, post-6.6.2) indicate the IconsTrait.php code path may remain exploitable after the 6.6.2 patch; operators should verify remediation rather than treat the version bump alone as sufficient.' patch_available true, live_patch_available false. attack_vector: 'An unauthenticated attacker POSTs directly to SP Page Builder's asset.uploadCustomIcon task, which accepts any file type with no session, permission, or CSRF check, then requests the uploaded PHP file to execute code and create a rogue Super User account.' Vector: 'A vulnerability in SP Page Builder for Joomla allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code.' cisa_kev true, kev_date 2026-07-07, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 68, cwe_refs CWE-434. Citing gaps: ISO-27001-2022-A.8.8 Management of technical vulnerabilities, NIST-800-53-SI-2 Flaw Remediation, NIS2-Art21-vulnerability-management and AU-ISM-1546 Patch operating systems and applications.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation path ends in two artifacts that no extension update removes: a PHP file the attacker uploaded through the asset.uploadCustomIcon task and then requested in order to execute it, and a rogue Super User account created on the Joomla site. Updating SP Page Builder replaces extension code — it does not delete a file already written into the site's upload directories, and it does not touch the Joomla user table, so a site recorded as patched can still be holding an administrator account the attacker controls. Applied to this deployment the requirement is that a publicly reachable Joomla site running SP Page Builder during the exposure window is handled as compromised rather than as patched: enumerate Super User and administrator accounts against a known-good list and remove any not provisioned by the site's own administrators, rotate the credentials of the accounts that remain, search the extension's upload directories and the web root for PHP files that belong to no installed package, and restore from a known-good backup in preference to cleaning in place where the site's content allows it. This entry gives the control more weight than usual, because the packet also records that the 6.6.2 patch may not have closed the upload path — so the update can be treated as ending neither the exposure nor the persistence. Precondition: this is the incident-response default, not a preventive control. It does not close the upload endpoint — that is the vendor fix, subject to the verification requirement recorded separately on this entry — and a backup taken during the exposure window may itself already contain the rogue account or the uploaded file, so the restore point must be chosen against that window rather than by recency.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker POSTs directly to SP Page Builder's asset.uploadCustomIcon task, which accepts any file type with no session, permission, or CSRF check, then requests the uploaded PHP file to execute code and create a rogue Super User account.' Vector: 'A vulnerability in SP Page Builder for Joomla allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code.' live_patch_notes: 'Community reports (JoomShaper forum, post-6.6.2) indicate the IconsTrait.php code path may remain exploitable after the 6.6.2 patch; operators should verify remediation rather than treat the version bump alone as sufficient.' patch_available true, live_patch_available false, poc_available true, active_exploitation 'confirmed', cisa_kev true, kev_date 2026-07-07, cvss 9.8, rwep_score 68. Citing gaps include NIST-800-53-SI-2 Flaw Remediation, NIS2-Art21-vulnerability-management and UK-CAF-B4 System security.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-48282": {
     "name": "Adobe ColdFusion Path Traversal Vulnerability",
@@ -37197,7 +38066,39 @@
         "adequate": false,
         "gap": "Boundary protection guidance recommends restricting the management interface to trusted internal IPs, but this is advisory in PAN-OS deployments — it doesn't enforce network isolation by default, leaving internet-exposed interfaces reachable pre-patch."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The vulnerable surface here is the PAN-OS management web interface, and the packet records the vendor's own risk-reduction step for it: restricting access to the management web interface to only trusted internal IP addresses. Bound to this deployment the control means two things. First, every PAN-OS firewall's management web interface answers only from a named management network — not from the internet and not from a general user VLAN — with that reachability enforced by the surrounding network rather than asserted from 'the management interface is internal'. Second, the remediation clock for the vendor fix the packet records as available runs from the 2025-02-18 KEV listing on an expedited tier, because the appliance being bypassed is the boundary the rest of the estate is built behind; a standard operating-system patch window measures this device by the wrong yardstick. Scope it to PAN-OS firewalls: the packet states the issue does not affect Cloud NGFW or Prisma Access software, so those deployments are not instances of this CVE and do not belong in the remediation population. Precondition, and this is where the control is routinely over-claimed: restricting the management interface bounds who can send the crafted request, it does not repair the path confusion. An attacker already positioned inside the permitted management segment, or on a jump host or admin workstation that legitimately reaches it, still invokes the restricted PHP scripts without authenticating. Isolation is the holding measure for the window before the fix lands, not a closure, and it is unavailable where the management interface must stay reachable for an out-of-band operational path. Distinguishing test: from a general user segment and from an external address, attempt to load the PAN-OS management web interface; anything that answers is within reach of the exploit the packet records as publicly available.",
+        "evidence": "Packet facts: name 'Palo Alto Networks PAN-OS Authentication Bypass Vulnerability', CWE-306; CISA KEV-listed 2025-02-18 with active_exploitation 'confirmed'; CVSS 9.1, RWEP 81; poc_available true; patch_available true, live_patch_available false. Vector states the flaw 'enables an unauthenticated attacker with network access to the management web interface to bypass the authentication otherwise required by the PAN-OS management web interface and invoke certain PHP scripts', that it 'can negatively impact integrity and confidentiality of PAN-OS', that risk is greatly reduced 'by restricting access to the management web interface to only trusted internal IP addresses', and that the issue 'does not affect Cloud NGFW or Prisma Access software'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet is explicit that invoking the PHP scripts does not itself enable remote code execution, so the trigger for this control has to be stated precisely rather than assumed. Where a PAN-OS management web interface was reachable during the exposure window and the separate command-injection flaw the packet names — CVE-2024-9474 — was also unremediated, the device meets this control's condition exactly: the packet's attack_vector has the bypass commonly chained with that flaw to reach full remote code execution on a perimeter device under confirmed in-the-wild exploitation. For those units, applying the fix is not remediation. The response is configuration extraction for forensics, rebuild from a vendor image, and rotation of every secret the configuration held — local administrator credentials, RADIUS and TACACS+ shared secrets, IPsec pre-shared keys, API keys, and any certificate private material generated or stored on the device — because an attacker-written file, account, or script survives an upgrade untouched. Where only the bypass itself was reachable, the packet still records impact to the integrity and confidentiality of PAN-OS, which means the running configuration must be compared against a known-good copy and every secret that configuration stores treated as read, even if a full rebuild is not warranted. Precondition: this control is a response procedure, not a preventive one — it does nothing for a device that has not yet taken the fix, and rebuilding a device whose management interface is still broadly reachable simply restores an exploitable unit. Sequence it after the reachability restriction and the vendor fix, not instead of them.",
+        "evidence": "Packet facts: attack_vector states the attacker 'exploits an nginx/Apache path-confusion bug to invoke restricted PHP scripts without authenticating, then commonly chains the bypass with a separate command-injection flaw (CVE-2024-9474) to reach full remote code execution'; vector records impact to 'integrity and confidentiality of PAN-OS'; active_exploitation 'confirmed', CISA KEV 2025-02-18, poc_available true, RWEP 81, CVSS 9.1; patch_available true with live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "What an exploit doing exactly what this packet describes emits is a request to the PAN-OS management web interface that reaches a restricted PHP script and returns successfully, with no preceding successful authentication event for that source or session — the authentication step is bypassed, not defeated. That is the signal to key on, and it lives in the management-plane web request log on the firewall itself. The control requires those logs, alongside the device's system and authentication logs, to be forwarded continuously to a collector in a separate trust zone: different management plane, different credentials, and an authentication path that does not depend on anything the firewall stores. Note what will not see this. There is no failed-login burst, no lockout, no crash and no reboot, so a detection built on authentication failures, availability loss, or administrator-session anomalies misses an attempt that behaves precisely as the packet describes. Preconditions, both load-bearing. The forwarding must already be configured and the collector already outside the device's blast radius before the attempt — a rule written after the fact against telemetry nobody was shipping produces nothing, and a syslog target whose credentials live in the firewall configuration is inside the same blast radius given the confidentiality impact the packet records. And the survival half of this control only bites where the chain to CVE-2024-9474 was reachable and the attacker held the device; for the bypass alone the value is visibility, not log survival. Detection prevents nothing here — it bounds the exposure window to alert-and-response time while the reachability restriction and the vendor fix are put in place.",
+        "evidence": "Packet facts: vector states an unauthenticated attacker with network access to the management web interface can 'bypass the authentication otherwise required by the PAN-OS management web interface and invoke certain PHP scripts' with impact to 'integrity and confidentiality of PAN-OS'; attack_vector records the chain with CVE-2024-9474 'to reach full remote code execution'; active_exploitation 'confirmed', CISA KEV 2025-02-18, poc_available true.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-53704": {
     "name": "SonicWall SonicOS SSLVPN Improper Authentication Vulnerability",
@@ -38217,7 +39118,30 @@
         "adequate": false,
         "gap": "Identity-and-access controls were structurally bypassed since the vulnerability itself manufactures a valid administrator identity without authentication."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "PRTG Network Monitor's web interface is the management plane for everything it polls, and the packet places the defect at two points on it at once. /public/login.htm is a page that by design answers unauthenticated callers, and a crafted HTTP request can override the attributes of its include directive; /api/addusers, the account-creation function that request is then made to reach, performs no authentication of its own — which is why the entry is classed CWE-306, missing authentication for a critical function. Bound to this product, the control means every PRTG API function that changes state, account creation first among them, makes its own authorization decision before it executes rather than inheriting one from the authenticated pages that normally invoke it; and the attribute the pre-authentication login page uses to select what it includes is validated against a fixed allow-list rather than taken from the request. It also means no PRTG web interface is left reachable from a segment with no operational need to reach it. This is why the identity-and-access controls cited on this entry do not touch the path: the attacker never holds a PRTG account, so no credential is presented and no access decision is consulted — an attestation that every PRTG operator authenticates at login passes cleanly while the endpoint creates administrators for callers who never logged in. Distinguishing test: from an unauthenticated client on a staging instance, send the crafted request to /public/login.htm naming /api/addusers with id and users parameters, then enumerate the instance's user list and confirm it is unchanged — testing that the login page rejects bad credentials proves nothing here, because the exploit never attempts a login. Preconditions: the endpoint-side authorization and the include-attribute validation are properties the vendor fix establishes — the packet records PRTG before 18.2.40.1683 as affected with a patch available, so this control states what to verify, not what an operator can implement. Restricting which segments can reach the web interface bounds who can send the request but leaves the path fully exploitable to anything inside the permitted segment, and it is unavailable where the console must stay broadly reachable for operational use. And because exploitation is confirmed and the outcome is a persistent read-write account, upgrading closes the inclusion path but does not delete an account created through it: an instance that was reachable during the exposure window needs its user list compared against a known-good baseline rather than being closed on the version number.",
+        "evidence": "Packet vector: 'PRTG Network Monitor before 18.2.40.1683 allows remote unauthenticated attackers to create users with read-write privileges (including administrator). A remote unauthenticated user can craft an HTTP request and override attributes of the include directive in /public/login.htm and perform a Local File Inclusion attack, by including /api/addusers and executing it. By providing the id and users parameters, an unauthenticated attacker can create a user with read-write privileges (including administrator).' cwe_refs CWE-306; cisa_kev true with kev_date 2025-02-04; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 67; patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-IA-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry is unusual and that is the point: the packet places the fix at PRTG 18.2.40.1683 while CISA listed the CVE on 2025-02-04, so under this control's 'KEV listing or patch availability, whichever is later' rule the SLA runs from the listing, against a defect whose fix had been shipping for years already. The population still exposed at listing is therefore not one waiting on a vendor — it is instances that no update process has touched — which makes meeting the SLA a discovery problem before it is a patching problem. The requirement here is to find every PRTG installation, including the ones standing on a departmental server, a lab host, or a machine inherited from a team that no longer exists, and confirm each reports a version at or above 18.2.40.1683 rather than confirming that the inventoried instances were updated. Track and document mitigation state per instance, not in aggregate: with a public PoC, confirmed in-the-wild exploitation and an unauthenticated path that mints an administrator on a monitoring server, one missed install is not a percentage point on a compliance figure. Precondition: the packet records a vendor patch and no live-patch path, so there is nothing that removes this flaw short of reaching the fixed version — where an instance genuinely cannot take the upgrade inside the window, the only remaining lever is removing its reachability from segments that have no need to reach it, and that is a holding measure with a review date, not a remediation. Because exploitation is confirmed, an instance found late is a triage item as well as a patch item: the flaw's product is a persistent privileged account, and the upgrade does not remove one already created.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-02-04; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 67; patch_available true; live_patch_available false. Vector states the affected range as 'PRTG Network Monitor before 18.2.40.1683' and the outcome as remote unauthenticated attackers creating 'users with read-write privileges (including administrator)'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.9"
+        ]
+      }
+    ]
   },
   "CVE-2025-24085": {
     "name": "Apple Multiple Products Use-After-Free Vulnerability",
@@ -38259,7 +39183,33 @@
         "adequate": false,
         "gap": "Essential Eight's patch-OS timeline (48 hours for extreme-risk vulnerabilities) is difficult to meet for a distributed device fleet without forced MDM update enforcement."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet names the fixed build per platform — iOS 18.3 and iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3, watchOS 11.3 — and that list is what makes this a fleet-enforcement problem rather than a single-update problem: a real Apple estate spans several of those trains at once, and a device held on an older train is remediated only by the build named for its own train, not by the newest one. Applied to this CVE the control means the update is driven from the management plane on the KEV clock that opened 2025-01-29 with user deferral disallowed, and completion is measured per device against the fixed build for the train it is actually on — not against 'update available', 'assigned' or 'downloaded' in the management console. Deferral is the load-bearing part here because of how short the exploitation path is: once the malicious application is on the device it reaches the flaw with a small number of local XPC calls into the mediaplaybackd daemon's CoreMedia Remaker subsystem, needing no network position and no further user step, so the exposure window is exactly the time the device spends below its fixed build and a user postponing the update for a week is a week in which any application on that device holds a path to privileged code execution. Precondition: the packet records no live-patch path, so nothing short of the device reaching its fixed build removes the flaw — a device that cannot reach it is not covered by this SLA at all and belongs on the access-condition and application-restriction levers instead of being carried as an exception. Because exploitation is confirmed, a device that ran an untrusted application while below its fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet vector: 'A use after free issue was addressed with improved memory management. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3, watchOS 11.3. A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 17.2.' Packet attack_vector: 'A malicious application on the device makes a small number of XPC calls to the mediaplaybackd daemon's CoreMedia Remaker subsystem, triggering a use-after-free in FigRemakerTrack object handling that yields code execution in that privileged process and, ultimately, privilege escalation.' CWE-416; CISA KEV listed 2025-01-29; active_exploitation confirmed; poc_available true; CVSS 10; RWEP 83. patch_available true, live_patch_available false (live_patch_notes null — no interim mechanism is recorded).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Because the packet's exploitation path starts with a malicious application resident on the device, this control's two halves split cleanly for this CVE. First, the fixed build named for each train must operate as an access condition — organizational mail, VPN and document access denied to any device below iOS/iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3 or watchOS 11.3 — rather than a row on a patch-compliance report; an estate that surfaces the stale build on a dashboard while the device keeps its access has recorded the exposure rather than removed it. The distinguishing test is to enrol a device pinned below the fixed build for its train and confirm the policy actually denies it protected resources. Second, since the attacker's foothold is an installed application making XPC calls into the CoreMedia Remaker subsystem of mediaplaybackd, constraining what code is permitted to install and run at all is the only lever the operator holds on a device that cannot yet take its fixed build. Precondition, and this is where the second half gets over-claimed: restricting untrusted or side-loaded application installation raises the bar for getting the attacker's application onto the device, but it does not evict an application already installed, and it does not cover one that arrived through the normal store channel — a device suspected of already running the malicious application belongs on the incident path, not the install-policy path. The whole control is a holding measure for the window before the fixed build lands, not a substitute for it: the packet records no live-patch path, so only the build itself removes the use-after-free.",
+        "evidence": "Packet vector names the fixed builds ('iOS 18.3 and iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3, watchOS 11.3') and states 'A malicious application may be able to elevate privileges.' Packet attack_vector places the trigger in a malicious application on the device making a small number of XPC calls to the mediaplaybackd daemon's CoreMedia Remaker subsystem, triggering a use-after-free (CWE-416) in FigRemakerTrack object handling. CISA KEV listed 2025-01-29; active_exploitation confirmed; CVSS 10; RWEP 83; poc_available true. patch_available true; live_patch_available false. Citing gap NIST-800-53-CM-7 (Least Functionality) is recorded against this entry.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-23006": {
     "name": "SonicWall SMA1000 Appliances Deserialization Vulnerability",
@@ -38333,7 +39283,30 @@
         "adequate": false,
         "gap": "A five-year-old client-side library flaw remained unpatched in production long enough to appear in attacker C2 infrastructure, showing flaw-remediation tracking rarely extends to bundled front-end JS dependencies."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "jQuery is not installed software on an estate — it is a file that ships inside applications, and the packet's affected range (greater than or equal to 1.0.3 and before 3.5.0) covers effectively every copy ever vendored into a web root, emitted by a build step, or embedded in a third-party product's web interface. That is why a flaw-remediation programme keyed to installed packages reports nothing here: the vulnerable code is a dependency no manifest on the host declares, so the scan result is silence rather than a finding. The requirement is that the software inventory reach those copies — enumerate jQuery across the served content and build outputs of every web application in the estate, not only the declared direct dependencies, and record each copy's version against the packet's fixed version of 3.5.0. Two populations fall out of that scan and they have different terminal states, which is the part an inventory row alone hides. A copy the organisation builds and ships is a code change, not a patch: the packet fixes the flaw in 3.5.0, and a copy on 1.x or 2.x reaches that only through a major-version upgrade of the library, which is application work with regression risk and has to be scheduled as such. A copy bundled inside a third-party product is not substitutable by the operator at all — that item belongs on the vendor's fixed-build clock, and where the vendor ships no build carrying jQuery 3.5.0 or later, the honest terminal state is replacing or removing that product, because an inventory row left open indefinitely marks a KEV-listed flaw with a public PoC as managed while it stays exploitable. Scope the sweep to what the packet establishes — jQuery below 3.5.0 — rather than to front-end libraries in general, which the packet gives no basis for.",
+        "evidence": "Packet vector: 'In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.' CWE-79, CVSS 6.9, RWEP 65, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2025-01-23. patch_available true; live_patch_available false with live_patch_notes null. AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 (Flaw Remediation) are recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Two distinct measurements report clean on this CVE while it stays exploitable, and the control's job here is to name both. The first is version-only scanning: an inventory that reads installed operating-system packages has no row for a jQuery file served out of a web root, so the result says nothing about the flaw rather than saying it is absent — silence read as a pass. The second is specific to this defect and is the one that catches operators out. The packet states the untrusted HTML executes 'even after sanitizing it', and that the crafted <option> content survives common sanitization, so an application recording an HTML sanitizer as its compensating control has recorded something the packet says does not hold on this path. The operational test therefore has to exercise the documented behaviour rather than a version string: on a staging copy of each affected application, pass HTML containing crafted <option> elements through whatever sanitization that application applies and on into the jQuery DOM manipulation methods the packet names — .html(), .append() and the others — and confirm nothing executes in the resulting page. A copy that executes the payload is exploitable regardless of what the sanitizer is configured to strip, and an application whose primary bundle reports jQuery 3.5.0 while a second bundle on the same page still loads an older copy fails this test even though the version report reads clean. Precondition: this is a test, not a mitigation. A failing result identifies an application that must take the library upgrade to 3.5.0 or later; passing it on one application says nothing about the others, so it runs per application rather than once for the estate, and no result of it removes the need for the upgrade.",
+        "evidence": "Packet vector: untrusted HTML containing <option> elements passed to jQuery's DOM manipulation methods '(i.e. .html(), .append(), and others) may execute untrusted code', and the packet states this holds 'even after sanitizing it'; 'This problem is patched in jQuery 3.5.0.' Attack vector: the crafted <option> content 'survives common sanitization', 'causing the browser to execute attacker-controlled JavaScript in the victim's session'. CWE-79, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2025-01-23. NIS2-Art21-vulnerability-management and UK-CAF-B4 (System security) are recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-50603": {
     "name": "Aviatrix Controllers OS Command Injection Vulnerability",
@@ -38996,7 +39969,39 @@
         "adequate": false,
         "gap": "The actual breach vector was a compromised vendor SaaS API key, not a direct customer-side flaw; CAF B4 (supply chain) requires modeling vendor-side compromise blast radius for privileged remote-access providers, which most customers had not done."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "BeyondTrust Privileged Remote Access and Remote Support exist to broker privileged sessions into other systems, and the packet's path ends with command execution on that broker itself — an unauthenticated crafted WebSocket-upgrade request whose Sec-WebSocket-Protocol / X-Ns-Company header values are concatenated unsanitized into a shell command run as the appliance's site user. For this product the control means an appliance whose HTTP surface was reachable during the exposure window is handled as attacker-held rather than as a patch item: configuration and session artifacts captured for forensics first, the appliance rebuilt from vendor media, and every credential the appliance stored, brokered, or that authenticated through it during the window rotated. Applying the vendor update closes the injection sink and removes nothing the attacker wrote or read through it, and on a privileged-access appliance what it read is the credential set for the downstream estate — which is why a remediation that ends at 'the fix is deployed' understates this CVE specifically. Precondition and limits: this is an incident-response default, not a preventive measure. It presumes the operator can bound an exposure window (the packet gives the 2024-12-19 KEV listing as the anchor and no per-unit indicator of compromise), and it does not tell an operator whether a given appliance was actually reached. Where session and access logs live only on the appliance the attacker had command execution on, absence of evidence is not evidence of absence, so reachability during the window — not a confirmed detection — has to be the trigger. Rebuild-and-rotate is also not free: it interrupts the remote-support function the appliance provides, which is the reason the patch-in-place shortcut gets taken.",
+        "evidence": "Packet: CWE-77 command injection; an unauthenticated attacker sends a crafted WebSocket-upgrade HTTP request with malicious Sec-WebSocket-Protocol / X-Ns-Company header values that are concatenated unsanitized into a shell command run as the appliance's site user, yielding remote command execution on the PAM appliance itself. CISA KEV-listed 2024-12-19; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 74. patch_available true, live_patch_available false, with no live-patch note recorded — the vendor update is the only remediation the packet registers, and it is exactly the step this control says is insufficient on its own once exploitation is confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A Privileged Remote Access / Remote Support appliance is a remote-access trust boundary — it accepts connections from technicians outside the protected network — and the packet's request arrives unauthenticated over that same HTTP surface. So the remediation clock for this CVE cannot be the general application-patching SLA the AU Essential Eight and boundary-protection attestations are measured against: the requirement is the vendor fix deployed, or the vulnerable HTTP/WebSocket surface withdrawn from untrusted networks, measured from the 2024-12-19 KEV listing rather than from the next maintenance window. Precondition, and it is the whole difficulty on this product: withdrawing the surface is only available where remote technicians can still reach the appliance another way — an internal-only deployment, or an interposed VPN or authenticating proxy that terminates the connection before the appliance's own handler ever parses the upgrade headers. On an appliance published to the internet so external support staff can connect, which is the deployment this product is bought for, there is no isolation lever that preserves the function, and the vendor update is the only path; the isolation half then applies only to management and API surfaces that have no need to be publicly reachable. Note also what isolation does not do: it bounds who can send the crafted request, it does not repair the unsanitized concatenation, so any caller inside a permitted segment still reaches command execution. The packet records no live-patch mechanism, so there is no in-place option that avoids taking the vendor update.",
+        "evidence": "Packet: unauthenticated network request against the appliance's WebSocket-upgrade path yields remote command execution on the PAM appliance itself; CWE-77. CISA KEV-listed 2024-12-19; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 74. patch_available true; live_patch_available false, with no live-patch note recorded.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-046",
+        "name": "PEN-TEST-SCOPE-INCLUDES-SECURITY-PRODUCTS",
+        "description": "The vulnerable product here is itself a security control — the privileged remote access and remote support tier that brokers privileged sessions — which is precisely the class this control says must appear in test scope as attack surface rather than as a defense to work behind. Bound to this CVE that means the PRA/RS appliance's public HTTP surface, and specifically its WebSocket upgrade handling, is a tested surface in its own right: the defect lives in how attacker-supplied Sec-WebSocket-Protocol and X-Ns-Company header values are carried into a shell command, and no amount of testing the systems reached through the appliance would surface it. Scope language has to name the appliance and its API surface explicitly, because scope statements typically enumerate the estate the privileged-access tool protects and silently exclude the tool. Precondition and limits: this is an assurance control, not a mitigation. It changes the probability of finding the next defect in this surface and does nothing for an appliance already exposed to this one, and because the code is the vendor's, what it produces is a vendor report plus an operator exposure decision — not a fix the operator can write, which is the same reason a secure-coding attestation over the operator's own code passes cleanly while this path stays open. Keep the scope addition to the products the packet names, Privileged Remote Access and Remote Support; extending it to other security products is a decision to make on their own evidence, not on this entry.",
+        "evidence": "Packet: the affected product is BeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) — a privileged-access product — and the flaw is a CWE-77 command injection reached by an unauthenticated crafted WebSocket-upgrade HTTP request through the Sec-WebSocket-Protocol / X-Ns-Company headers, executing as the appliance's site user. poc_available true; active_exploitation confirmed; CISA KEV-listed 2024-12-19; CVSS 9.8; RWEP 74.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.28",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-23227": {
     "name": "NUUO NVRmini2 Devices Missing Authentication Vulnerability",
@@ -39033,7 +40038,31 @@
         "adequate": false,
         "gap": "Technical vulnerability management assumes an eventual vendor patch — NUUO has not responded to disclosure and the flaw persists in the latest firmware, so remediation-SLA-based controls cannot be satisfied and must fall back to decommissioning."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The NVRmini2 is a network video recorder, and this packet resolves the patch-versus-replace question in one direction: patch_available is false and no live-patch path is recorded, so there is no fixed build for an operator to reach. That makes each unit in service a replacement item rather than a remediation-clock item, and the requirement is an inventory naming every NVRmini2 with its firmware level - the packet scopes the defect to builds 'through 3.11' - together with a vendor-obtained answer on whether a fixed firmware exists for that hardware, rather than an assumption in either direction. Any unit for which the vendor produces a fix belongs on a remediation clock; every unit for which it does not belongs on a dated removal or replacement schedule, because a risk acceptance with no removal date leaves a KEV-listed device carrying a public PoC and confirmed exploitation in service indefinitely. Scope the inventory to what the packet names - NUUO NVRmini2 - not to every recorder or camera on the estate; the packet ties the missing authentication check to handle_import_user.php on this product and provides no mapping into other video hardware, so treating all surveillance appliances as instances of this CVE manufactures removal work against devices no evidence implicates. The distinguishing test is per unit rather than per estate: produce, for each NVRmini2 in service, its firmware level and the vendor's answer on a fix - an asset register that records the device as 'segmented' or 'monitored' with no removal date has recorded the exposure rather than removed it. Precondition, and it is why this cannot end at a segmentation entry in the risk register: the exposure being scored is an unauthenticated archive upload that creates an arbitrary account, so restricting which segments can reach the device bounds who can send that upload but repairs nothing, and with no vendor fix recorded there is no update behind which that interim state resolves. Because active_exploitation is confirmed and the primitive is account creation, a unit that was reachable during the exposure window may already carry an attacker-created account and, through the CVE-2011-5325 chain the packet names, attacker-written files under the web root; isolating that unit afterwards does not clear it, and its accounts and configuration must be treated as attacker-controlled until it is removed.",
+        "evidence": "Packet records patch_available: false, live_patch_available: false, live_patch_notes: null - no fixed build is recorded for this entry. CISA KEV-listed 2024-12-18, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 79. Vector: 'NUUO NVRmini2 through 3.11 allows an unauthenticated attacker to upload an encrypted TAR archive, which can be abused to add arbitrary users because of the lack of handle_import_user.php authentication. When combined with another flaw (CVE-2011-5325), it is possible to overwrite arbitrary files under the web root and achieve code execution as root.' Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIS2-Art21-vulnerability-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The NVRmini2's web interface is the device's configuration plane, and the defect is that plane's file-accepting endpoint making no authorization decision at all: the packet places the missing check in handle_import_user.php, which takes an encrypted TAR archive from an unauthenticated caller and imports users from it, so an attacker creates an arbitrary account without ever presenting a credential. Bound to this product, the control means a configuration endpoint that accepts an uploaded archive authorizes its caller before the archive is processed, and resolves and validates every destination path the import writes before the write executes - the chained CVE-2011-5325 step the packet names is exactly that second half failing, with archive content overwriting files under the web root and ending in code execution as root. This is also why the identification-and-authentication and identity-and-access gaps cited on this entry pass their attestations while the path stays open: the attacker never authenticates as any NVR user, so per-account authentication and privilege scoping are never consulted - the account model is bypassed rather than abused, and an attestation that every recorder administrator authenticates at login reads clean. Distinguishing test: from a segment with no operational need to administer the recorder, send an unauthenticated upload to the user-import handler on a bench unit and confirm it is refused before anything is imported or written to disk. Precondition, and it is decisive on this entry: endpoint-side authorization and path validation are properties a vendor fix would have to establish, and this packet records patch_available false with no live-patch path, so there is no update behind which this control resolves. The only operator-side lever left is reachability - restricting which segments can reach the management interface bounds the population that can send the upload, but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable wherever the recorder's web interface must stay reachable for normal viewing and administration. Treat reachability restriction as a holding measure attached to a removal date, never as closure of the endpoint.",
+        "evidence": "Packet vector: 'NUUO NVRmini2 through 3.11 allows an unauthenticated attacker to upload an encrypted TAR archive, which can be abused to add arbitrary users because of the lack of handle_import_user.php authentication. When combined with another flaw (CVE-2011-5325), it is possible to overwrite arbitrary files under the web root and achieve code execution as root.' CWE-306 (missing authentication), CVSS 9.8, RWEP 79, poc_available true, active_exploitation confirmed, CISA KEV-listed 2024-12-18. patch_available: false and live_patch_available: false, with live_patch_notes null. Citing gaps include NIST-800-53-IA-2 (Identification and Authentication), UK-CAF-B2 (Identity and access control) and NIST-800-53-CM-7 (Least Functionality).",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2021-40407": {
     "name": "Reolink RLC-410W IP Camera OS Command Injection Vulnerability",
@@ -39181,7 +40210,30 @@
         "adequate": false,
         "gap": "Application hardening (disabling unnecessary auto-execution features like Autorun-directory command execution) would have closed this vector even before the vendor patch existed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet puts the flaw in a default: 'an unauthenticated user can import and execute arbitrary Bash or PowerShell commands on the host system by leveraging the default settings of the Autorun directory', on Cleo Harmony, VLTrader and LexiCom before 5.8.0.24. That gives a Cleo estate two states a compliance verdict must not collapse into one. The first is a host on 5.8.0.24 or later, where the defect is gone. The second is a host on an earlier build with the Autorun directory's auto-execution turned off by configuration — the execution trigger is closed, and the residual risk in that state is concrete for this product: the unauthenticated import path itself is untouched, so attacker-chosen files still land on the host, and the setting is a product default, so any operation that reapplies defaults (a configuration restore, a reinstall, an upgrade path that re-writes them) silently returns the host to full exposure with nothing in the version string to show it. The requirement is that the second state is reported as a distinct compensating-control state with a dated action item to reach the fixed build, and never as 'patched per SLA'. Distinguishing test: per Cleo host, report the product build and the Autorun auto-execution setting as two separate fields, and re-read the setting after every upgrade, restore and reinstall. An inventory whose only field is 'Cleo: remediated' cannot tell a 5.8.0.24 host from one whose mitigation was reverted by a default-restoring operation, and both read compliant. Precondition: disabling the auto-execution bounds the trigger — it does not remove the defect and it evicts nothing. The packet records active_exploitation as confirmed, so a host that ran a pre-5.8.0.24 build while reachable is not made clean by the configuration change; that host belongs on the response path, and the configuration state describes only what an attacker can do to it from this point forward.",
+        "evidence": "Packet: 'Cleo Multiple Products Unauthenticated File Upload Vulnerability', cwe_refs CWE-77, cvss 9.8, rwep_score 54, poc_available false. Vector: 'In Cleo Harmony before 5.8.0.24, VLTrader before 5.8.0.24, and LexiCom before 5.8.0.24, an unauthenticated user can import and execute arbitrary Bash or PowerShell commands on the host system by leveraging the default settings of the Autorun directory.' attack_vector: 'An unauthenticated attacker imports a file that lands in the Cleo product's default Autorun directory; the platform's default configuration automatically executes files placed there as Bash or PowerShell commands, giving the attacker code execution on the host with no credentials required.' cisa_kev true, kev_date 2024-12-17, active_exploitation confirmed. patch_available true; live_patch_available false (live_patch_notes null). Citing gaps closed here: NIST-800-53-CM-7 (Least Functionality), ISO-27001-2022-A.8.9 (Configuration management), AU-Essential-8-App-Hardening (User application hardening).",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Cleo Harmony, VLTrader and LexiCom sit at the trust boundary by function — the packet's attack path requires that an unauthenticated party can reach an instance and import a file to it — and the packet's outcome is arbitrary Bash or PowerShell execution on the host with no credential required. With active exploitation recorded as confirmed, upgrading to 5.8.0.24 removes the import-to-execute path and removes nothing the executed commands already wrote or started. The control's default therefore binds here: for any instance that was reachable while running a build before 5.8.0.24, export the configuration for review, rebuild the host from a known-good image onto the fixed build rather than upgrading over the running state, and rotate every credential the instance held — a file-transfer platform's stored credentials reach outward to the partners it exchanges with, so the rotation scope does not stop at this host. This is what the flaw-remediation gap recorded on this entry is pointing at: the exposure window opened before a fix existed, so 'the host is on 5.8.0.24' answers what an attacker can do next and says nothing about what already happened. Precondition, stated rather than implied: rebuilding is a response action for an instance that was reachable during the exposure window. It prevents nothing, and it is not a substitute for the fixed build — a rebuilt instance that comes back on an earlier build is exposed again immediately, since the packet records the vendor fix as available and no live-patch path. It also reaches only artefacts on the instance itself; anything the executed commands pushed to another host is outside what rebuilding this one can undo and needs its own scope.",
+        "evidence": "Packet vector: 'In Cleo Harmony before 5.8.0.24, VLTrader before 5.8.0.24, and LexiCom before 5.8.0.24, an unauthenticated user can import and execute arbitrary Bash or PowerShell commands on the host system by leveraging the default settings of the Autorun directory.' attack_vector adds that the platform's default configuration 'automatically executes files placed there as Bash or PowerShell commands, giving the attacker code execution on the host with no credentials required'. cwe_refs CWE-77, cvss 9.8, rwep_score 54, poc_available false. cisa_kev true, kev_date 2024-12-17, active_exploitation confirmed. patch_available true; live_patch_available false (live_patch_notes null). Citing gaps closed here: NIS2-Art21-incident-handling (Incident handling) and NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-35250": {
     "name": "Microsoft Windows Kernel-Mode Driver Untrusted Pointer Dereference Vulnerability",
@@ -39680,7 +40732,30 @@
         "adequate": false,
         "gap": "Apple shipped a fix in Safari 18.1.1/iOS 17.7.2/18.1.1/macOS 15.1.1, but the flaw was exploited as a zero-day before any patch existed, so flaw remediation alone could not have prevented initial exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet's fix list is what makes this a fleet-wide push rather than one update: Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, iOS 18.1.1 and iPadOS 18.1.1, macOS Sequoia 15.1.1 and visionOS 2.1.1 all carry the same cookie-state-management fix, so remediation means every Apple device class the organization manages moves together on the clock that opened with the 2024-11-21 KEV listing — not on the next OS-upgrade window, and not in the order a severity-ranked queue would produce. That ranking is the specific failure mode here: the packet records CVSS 6.3 and poc_available false, which is precisely the profile a monthly patch queue defers, while the same packet records active exploitation as confirmed, notes Apple is aware of a report of exploitation on Intel-based Mac systems, and describes this cross-site-scripting flaw being chained with a separate code-execution flaw. The user-deferral half of the control is the load-bearing half on this fix, because on iOS, iPadOS and visionOS it arrives as an OS update whose prompt the person holding the device can dismiss indefinitely; the packet records live_patch_available false, so the fixed build is the only remediation and a dismissed prompt is untreated exposure. Distinguishing test: take an enrolled device one build below the fixed build for its track and confirm the management system installs the update inside the SLA without the holder being able to postpone it — an estate whose compliance report shows the update as available and pending user action has recorded the exposure rather than removed it. Precondition: this reaches enrolled devices only. Personally-owned Macs, iPhones and iPads used for work, and any unenrolled device, sit outside the push entirely, and the delivery path the packet describes — a user lured to attacker-controlled web content in Safari — needs nothing from the organization to work on them.",
+        "evidence": "Packet: CWE-79 cross-site scripting, with the vector stating a cookie management issue addressed with improved state management, fixed in Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, iOS 18.1.1 and iPadOS 18.1.1, macOS Sequoia 15.1.1, visionOS 2.1.1, and that Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems. cisa_kev true, kev_date 2024-11-21, active_exploitation confirmed, poc_available false, cvss 6.3, rwep_score 55. patch_available true, live_patch_available false, live_patch_notes null. The attack_vector records a targeted campaign against Intel-based Macs, chained with a separate code-execution flaw. AU-Essential-8-Patch (Patch operating systems), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet names two concurrently fixed iOS/iPadOS tracks — 17.7.2 and 18.1.1 — and that is what a single numeric minimum-version floor cannot express. Set the floor at 18.1.1 and every device correctly remediated on 17.7.2 fails the policy; set it at 17.7.2 and a device on 18.0 or 18.1 passes it, because those builds compare as newer while still carrying the unfixed cookie-state handling. For this entry the enforced floor has to be stated per track: at or above 17.7.2 on the 17.x line, at or above 18.1.1 on the 18.x line. The Mac side has the same shape for a different reason — the packet lists Safari 18.1.1 as a fixed build distinct from macOS Sequoia 15.1.1, so a check keyed only on the macOS build cannot see a Mac whose remediation is the Safari update, and the packet places the reported exploitation on Intel-based Mac systems. visionOS 2.1.1 sits on the same fix list and is the device class conditional-access policies most often do not enumerate at all. The requirement is that the per-track fixed build function as an access condition — a device below it is refused mail, VPN and document access until it is at or above it — rather than appearing as a row on a patch-compliance report. Distinguishing test: enrol one device pinned at 18.0 and one at 17.7.2 and confirm the policy denies the first and admits the second; a floor expressed as a single version number gets exactly this pair wrong, in the direction that admits the unfixed device. Precondition: withholding access bounds what a below-fix device can reach, it does not protect the device. The packet's exploitation path is a user loading attacker-controlled web content in Safari, which requires no organizational resource, so a blocked device remains fully exploitable and its user's own sessions and credentials stay in scope. Where a device cannot be brought to the fixed build, blocking it is the holding measure for the window, not the remediation.",
+        "evidence": "Packet: CWE-79 cross-site scripting reached by processing maliciously crafted web content; the vector names the fix as Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, iOS 18.1.1 and iPadOS 18.1.1, macOS Sequoia 15.1.1, visionOS 2.1.1 — two iOS/iPadOS tracks fixed concurrently, and Safari listed separately from macOS Sequoia. cisa_kev true, kev_date 2024-11-21, active_exploitation confirmed, poc_available false, cvss 6.3, rwep_score 55. patch_available true, live_patch_available false, live_patch_notes null. The vector states Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems. ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and UK-CAF-B4 (System security) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-44308": {
     "name": "Apple Multiple Products Code Execution Vulnerability",
@@ -41119,7 +42194,39 @@
         "adequate": false,
         "gap": "Patch Applications guidance assumes a supported product; CSA 4.6.x's EOL status means the compliant action is decommission, not patch."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry is a split estate and the split has to be resolved per appliance before any remediation clock means anything. The packet places the flaw in the admin web console of Ivanti CSA before version 5.0.2, so units on the 5.0.x branch have a build to reach — 5.0.2 or later — and belong on the KEV clock that opened 2024-10-09. The lesson entry's framework_coverage records the other population: CSA 4.6.x is past end-of-life with no vendor patch for that branch, so for those units there is no fixed build at all and the compliant action it names is decommission, not patch. The requirement in operational terms: enumerate every Ivanti CSA in service with its branch, put the 5.0.x units on the interim upgrade clock, and put every 4.6.x unit on a dated replacement or removal schedule — a risk acceptance with no removal date leaves a KEV-listed appliance with confirmed in-the-wild exploitation in service indefinitely. Scope it to what the packet names, Ivanti CSA units; nothing here implicates other Ivanti products, and inventorying them as instances of this CVE manufactures replacement work against software no evidence in this entry touches. Precondition, and this is where the interim half is normally over-claimed: reaching 5.0.2 closes this defect only and says nothing about anything found in the appliance since that build, which is exactly why the requirement cannot end at 'every CSA reports 5.0.2 or later'. The packet records patch_available true with live_patch_available false and no live-patch note, so each unit has to be taken through the vendor update — there is no in-place mitigation that leaves the appliance running unmodified. And because active exploitation is confirmed, a unit that was reachable during the exposure window is an incident item first: an appliance that already executed an attacker's commands is not remediated by the upgrade it later receives, and a 4.6.x unit being replaced is not remediated by the replacement either — what it held has to be treated as read.",
+        "evidence": "Packet: 'An OS command injection vulnerability in the admin web console of Ivanti CSA before version 5.0.2 allows a remote authenticated attacker with admin privileges to obtain remote code execution.' CISA KEV listing 2024-10-09; active_exploitation confirmed; poc_available false (so the absence of a public exploit is not grounds to defer — exploitation is already observed); RWEP 55; CVSS 7.2; patch_available true; live_patch_available false with live_patch_notes null. The repo lesson entry's framework_coverage for NIST-800-53-SI-2 records that 'CSA 4.6.x is past end-of-life with no vendor patch available for this branch, so flaw-remediation controls have no compliant remediation path short of migration', and its AU-Essential-8-Patch entry records that 'CSA 4.6.x's EOL status means the compliant action is decommission, not patch.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For this appliance the control's trigger conditions are met literally rather than by analogy: the packet's outcome is full remote code execution on the CSA, the admin position the flaw needs can be obtained by chaining a separate CSA authentication-bypass flaw so the effective path requires no credential, and exploitation is confirmed in the wild. What that means here is that the vendor upgrade is not the remediation decision for any CSA that was reachable while unpatched — the upgrade closes the injection sink and removes nothing an attacker executed through it. The default for those units is extraction of the running configuration for reference, rebuild from vendor media onto a build at or above 5.0.2, and rotation of every credential the appliance held or could authenticate to, before it is returned to service. This is precisely what the two vulnerability-management gaps cited here cannot express: A.8.8 and NIS2 Art 21 handling both terminate at a binary open/remediated verdict, so an appliance that was compromised and then upgraded closes as remediated on both attestations while the attacker's access persists through whatever was left on it. The distinguishing test is a question asked per unit rather than a scan: for each CSA in service before the upgrade, what evidence exists that it was not compromised? The lesson entry records that appliance-level logging on CSA is limited, so for most estates that evidence does not exist, and absence of an alert is not it. Precondition: rebuilding is only remediation if the rebuilt unit lands at or above 5.0.2 and the credentials it held are rotated — a 4.6.x unit rebuilt from its own image is reinstated with the vulnerability intact, since the lesson records no patch exists for that branch, and a rebuild without credential rotation returns a clean appliance to an attacker who already holds what it stored.",
+        "evidence": "Packet attack_vector: an attacker with admin access to the CSA administrative web console — 'obtained directly or by chaining a separate CSA authentication-bypass flaw' — injects OS commands 'passed unsanitized to the underlying operating system, yielding full remote code execution on the appliance'. CISA KEV 2024-10-09; active_exploitation confirmed; CWE-77 and CWE-78; patch_available true; live_patch_available false, live_patch_notes null. The repo lesson entry's defense_chain response section states that 'response must assume complete appliance compromise and treat any credentials it held as burned' and names isolating the appliance, hunting for implanted webshells and harvested credentials, and rotating all credentials the appliance had access to; its detection section records that 'appliance-level logging on CSA is limited'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The CSA's administrative web console is the management surface this control governs, and the defect sits on it: operator-supplied input reaches the underlying operating system unsanitized (CWE-77, CWE-78) and executes. Bound to this appliance the control means two properties. First, the console's command-invoking functions neutralize their input at the point it reaches the operating system — argument-array invocation or validation at the sink — rather than relying on the caller having authenticated as an administrator, because the packet's own path has that authentication reached by chaining a separate CSA authentication-bypass flaw, at which point the privilege verdict the sink is trusting is worthless. Second, no CSA is left with its administrative console reachable from a segment with no operational need to administer it. This is why the least-privilege gap cited on this entry does not close the path: the admin role is correctly assigned and correctly scoped, and the exploit trades that bounded application-admin position for unbounded OS execution on the appliance — an application-admin-to-host-OS bridge that a user-to-role privilege review never examines, so an AC-6 attestation passes cleanly while the console stays wired to a shell. Distinguishing test: enumerate, per CSA, which networks can reach the administrative console, and from a segment with no administrative role confirm the console does not answer — 'the appliance is behind the firewall' is a statement about topology, not a demonstration that the admin surface is unreachable. Precondition, and this is the half that gets over-claimed: the input neutralization is a property the vendor update at 5.0.2 or later establishes; this control states what to verify, it does not implement it, and the lesson records no such update exists for the end-of-life 4.6.x branch. Until the update lands, restricting reachability bounds who can present the request but leaves the console fully exploitable to anything inside the permitted segment — a compromised administrator workstation or jump host satisfies the precondition in full — and the lever is unavailable entirely where the administrative interface must stay reachable for the appliance's normal operation. It also does nothing about an appliance that already holds an implant.",
+        "evidence": "Packet: the flaw is in 'the admin web console of Ivanti CSA before version 5.0.2'; CWE-77 and CWE-78; the attack_vector describes injected OS commands 'passed unsanitized to the underlying operating system, yielding full remote code execution on the appliance', with the admin position reachable 'by chaining a separate CSA authentication-bypass flaw'. The entry cites NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) as insufficient. patch_available true with the packet's affected range ending before 5.0.2; live_patch_available false with no live-patch note recorded, so no in-place mitigation is available from the vendor.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-9379": {
     "name": "Ivanti Cloud Services Appliance (CSA) SQL Injection Vulnerability",
@@ -41834,7 +42941,31 @@
         "adequate": false,
         "gap": "The KEV due date (2026-07-18) was three days after listing, against an exploitation window that opened six weeks after the May patch — a standard flaw-remediation SLA is far too slow for an unauthenticated ERP takeover already probed in the wild."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The packet puts this defect inside one endpoint of the ERP rather than in the surrounding account model: the Oracle Payments File Transmission endpoint (ibytransmit) performs no authentication, and an unauthenticated attacker with HTTP reach sends crafted requests that read arbitrary server files and end in takeover of the Payments component. Bound to this deployment the control means that endpoint — and every other EBS servlet that performs a privileged file or payment operation — makes its own authorization decision before it acts, instead of inheriting a verdict from whatever web tier or reverse proxy fronts it, and that no EBS instance in the affected 12.2.3 through 12.2.15 range is left with that endpoint reachable from a segment with no operational need for it, which for most estates means it should not answer from the internet at all. This is precisely why the identity-and-access-control gap recorded against this entry does not close the path: the attacker never holds an EBS account, so per-account privilege scoping is never consulted, and an attestation that every EBS user is uniquely identified and least-privileged passes cleanly while the endpoint stays open. Distinguishing test: from a segment with no operational need to reach Payments, issue unauthenticated HTTP requests to the File Transmission endpoint on a staging EBS instance and confirm each is refused before the file operation runs. Preconditions. The endpoint-side authorization is a property the vendor update establishes — this control states what to verify, it does not implement it, and restricting reachability in the meantime bounds who can send the request while leaving the endpoint fully exploitable to anything inside the permitted segment; that lever is unavailable entirely where the transmission endpoint must stay reachable for a payment counterparty. And because exploitation is confirmed and the primitive the packet names is an arbitrary file read, an instance that was reachable during the exposure window must have every credential, wallet, and key readable by the EBS application-tier account treated as disclosed and rotated: the update closes the path but returns nothing already read through it.",
+        "evidence": "Packet facts: name 'Oracle E-Business Suite Improper Privilege Management Vulnerability', CWE-269, CWE-287 and CWE-306. Vector: 'Vulnerability in the Oracle Payments product of Oracle E-Business Suite (component: File Transmission). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Payments. Successful attacks of this vulnerability can result in takeover of Oracle Payments', CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. attack_vector: the attacker 'sends crafted HTTP requests to the Oracle Payments File Transmission (ibytransmit) endpoint, abusing missing authentication and improper privilege management to read arbitrary server files and ultimately take over the Payments component.' CISA KEV-listed 2026-07-15, active_exploitation 'confirmed'; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The prioritisation trap on this entry is visible in its own numbers: CVSS 9.8 for an unauthenticated network takeover of a payments component, but RWEP 53, because the packet records no public proof-of-concept. A programme that ranks by exploit availability, or that treats an ERP patch as a quarterly suite activity, will schedule this behind items with public exploit code while the packet records exploitation as confirmed. The control's requirement here is that the 2026-07-15 KEV listing starts an expedited clock for every EBS instance in the affected 12.2.3 through 12.2.15 range, and that completion is measured per instance against the vendor's fixed level for the Payments component rather than by the presence of an approved patch in the change queue — an estate that carries 'Oracle EBS 12.2' as a single inventory row cannot tell which of its instances is still exposed. The remediation the packet records is the vendor update, with no live-patching primitive for this product and no reboot required, so the usual reason an ERP security fix slips — waiting for a restart window — is not available on this entry and should not be accepted as a deferral. Preconditions. With no live-patch path there are only two states in which the SLA is met: the fixed level is running, or documented compensating controls are in place with a dated action item — restricting who can reach the File Transmission endpoint is the compensating control, and it is a holding measure, not a closure. And the internet-facing instances belong at the front of the queue, because the packet's only stated access requirement is network access via HTTP.",
+        "evidence": "Packet facts: CISA KEV-listed 2026-07-15 with active_exploitation 'confirmed'; CVSS 9.8, RWEP 53; poc_available false; patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' Vector records affected supported versions 12.2.3-12.2.15 and an 'unauthenticated attacker with network access via HTTP' able to compromise and take over Oracle Payments.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-4346": {
     "name": "KNX Association KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout Mechanism Vulnerability",
@@ -42037,7 +43168,29 @@
         "adequate": false,
         "gap": "Perimeter boundary controls do not stop an SSRF that turns the trusted appliance itself into the request origin, letting outbound calls reach internal services the firewall would otherwise block."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The SMA1000 Work Place interface is the appliance's published remote-access surface, and the packet places the defect there with a remote unauthenticated attacker able to coerce the appliance into issuing server-side requests to destinations of the attacker's choosing. Applied to this device, the control means the SMA1000 population runs on an expedited clock measured from the 2026-07-14 KEV listing to the moment each unit has both taken the vendor update and completed the reboot that update requires — not on the estate's standard appliance-patch window, because the device is the trust boundary and the flaw needs no credential to reach. The distinguishing test is per-unit: produce the running build and the last restart time and show the restart followed the update. An inventory that records the fixed release as 'applied' while the unit is still running pre-update code marks an exposed appliance compliant, and the packet registers no live-patch path that would let the fix take effect without that restart. Precondition, and it is why this control cannot fall back on the isolation alternative that normally bounds a perimeter-device defect: the vulnerable interface is the Work Place portal the appliance exists to publish to remote users, so 'restrict reachability of the affected interface' is unavailable except where the deployment can constrain the portal to known client source ranges. Where it cannot, there is no interim state — the update and its reboot are the only remediation, and the exposure runs until the restart completes. The absence of a public exploit is not a deferral argument here: the packet records no PoC available alongside confirmed in-the-wild exploitation, so the flaw is in use while defenders have nothing public to test their own exposure against.",
+        "evidence": "Packet entry 'SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability' (CWE-918), cisa_kev true with kev_date 2026-07-14 and active_exploitation 'confirmed'; cvss 10, rwep_score 61, poc_available false, ai_discovered false. Vector: 'A Server-side request forgery (SSRF) vulnerability has been identified in the SMA1000 Appliance Work Place interface. A remote unauthenticated attacker could potentially cause the appliance to make requests to unintended location.' 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-SI-2",
+          "AU-ISM-1546",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "An SSRF leaves no artifact on the attacker's side of the connection — the only observable is the SMA1000 itself originating requests it has no operational reason to make. Bound to this appliance, the control means the unit's syslog and web-request logs are forwarded to a collector in a separate trust zone (different management plane, different credentials from the appliance), and that egress records are retained for every connection whose source is the appliance, so the coerced requests are visible from the network side rather than only from the box that was coerced. The detection keys on exactly the behaviour the packet documents: requests issued by the appliance to attacker-chosen destinations, which the packet enumerates as internal reconnaissance targets, cloud-metadata endpoints, and pivot destinations. It must not key on crashes, malware artifacts, or tool signatures — an SSRF that behaves precisely as the packet describes crashes nothing, writes nothing to the appliance's filesystem, and rides the appliance's own legitimate outbound HTTP client, so a rule built on those signals would miss every attempt. Precondition: the logs and egress records have to be flowing off-box before the attempt. A rule authored afterwards against telemetry nobody was collecting produces nothing, and appliance-local logs are the first thing lost when a unit is rebuilt during remediation. And this closes nothing on its own — it bounds exposure to alert-and-response time during the window before the vendor update and its reboot land, and it does not invalidate what was already retrieved: anything the appliance's own network position could reach, including the cloud-metadata material the packet names, stays valid after the patch until it is rotated.",
+        "evidence": "Packet attack_vector: 'A remote unauthenticated attacker sends a crafted request to the SMA1000 Work Place interface that coerces the appliance into making server-side requests to attacker-chosen destinations, enabling internal reconnaissance, cloud-metadata theft, or pivoting through the trusted appliance.' active_exploitation 'confirmed'; poc_available false. Citing gap ISO-27001-2022-A.8.16 (Monitoring activities) is recorded against this entry. live_patch_available false with live_patch_notes stating the vendor update requires a reboot and is the remediation.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.16"
+        ]
+      }
+    ]
   },
   "CVE-2026-15410": {
     "name": "SonicWall SMA1000 Appliances Code Injection Vulnerability",
@@ -42291,7 +43444,30 @@
         "adequate": false,
         "gap": "The 2024-10-09 KEV due date trailed real exploitation; SI-2 flaw-remediation SLAs measured in weeks are far longer than the hours-to-days scanning window for an internet-facing preauth RCE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For HugeGraph-Server the fix is not a version number. The packet's own remediation is three simultaneous conditions — the 1.3.0 build, running on Java11, with the Auth system enabled — against an affected range that spans 1.0.0 before 1.3.0 on both Java8 and Java11. A scanner or CMDB that reports the installed HugeGraph version alone therefore marks as remediated a server sitting at the fixed build on a Java8 runtime, or at the fixed build with Auth left off, while the path the packet describes stays fully reachable: an unauthenticated crafted Gremlin script submitted to /apis/gremlin that abuses Java reflection/OGNL to escape HugeGraphSecurityManager into arbitrary OS commands. Applied to this product, the control means each HugeGraph instance produces three facts together — the running build, the JRE major version of the server process itself rather than the host's default java, and the Auth system's state read from live configuration rather than from a deployment template. The distinguishing test: stand up a staging instance at the fixed build with Auth disabled and submit an unauthenticated Gremlin script to /apis/gremlin; if it evaluates, the estate's version-only attestation is passing on an exploitable server. Precondition: this control tells you whether a server is in the fixed state, it does not put it there — the packet records the vendor update as the remediation, with no live-patching primitive for this product and no reboot required. And because active exploitation is confirmed and a public PoC exists, a server whose /apis/gremlin answered untrusted callers before remediation belongs on the triage path, not closed on the version check: reaching the fixed state removes the flaw, not what ran through it.",
+        "evidence": "Packet vector: 'RCE-Remote Command Execution vulnerability in Apache HugeGraph-Server. This issue affects Apache HugeGraph-Server: from 1.0.0 before 1.3.0 in Java8 & Java11. Users are recommended to upgrade to version 1.3.0 with Java11 & enable the Auth system, which fixes the issue.' Packet attack_vector: an unauthenticated attacker submits a crafted Gremlin script to /apis/gremlin that abuses Java reflection/OGNL to escape HugeGraphSecurityManager and run arbitrary OS commands on the server. CWE-284; CVSS 9.8; RWEP 65; poc_available true; CISA KEV-listed 2024-09-18 with active_exploitation confirmed. 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": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-060",
+        "name": "DATABASE-SERVER-SIDE-SCRIPTING-DEFAULT-DENY",
+        "description": "The /apis/gremlin endpoint is a server-side scripting interface on a datastore: it accepts a caller-supplied script and evaluates it inside the server process, and the packet's exploit is that evaluation escaping HugeGraphSecurityManager through Java reflection/OGNL into arbitrary OS commands. This control's premise — that a datastore's server-side scripting capability is not simply live in the shipped posture, and that turning it on carries a documented decision — is what the packet's own remediation reaches for when it instructs operators to enable the Auth system: the deployments in scope are running a script-evaluation endpoint with no access decision in front of it. For HugeGraph the requirement cannot be stated as 'disable scripting', because Gremlin submission is how the product is queried; the deployable form is that no instance accepts script submission with the Auth system off, that network reachability of the endpoint is limited to callers with an operational need to query the graph, and that exposing an evaluation endpoint at all is recorded as an accepted risk with a named owner rather than inherited from the default configuration. Precondition, and this is the half the control is usually over-claimed on: the in-process sandbox is not the boundary — the packet's path is an escape from HugeGraphSecurityManager, so authentication and reachability bound who can submit a script, they do not make evaluation safe. Any caller who legitimately authenticates, and any host inside the permitted segment, still reaches the same primitive until the vendor update the packet records is applied.",
+        "evidence": "Packet attack_vector: an unauthenticated attacker submits a crafted Gremlin script to /apis/gremlin that abuses Java reflection/OGNL to escape HugeGraphSecurityManager and run arbitrary OS commands on the server. Packet vector records the recommended remediation as upgrading to 1.3.0 with Java11 and enabling the Auth system. CWE-284 (improper access control); CVSS 9.8; RWEP 65; poc_available true; CISA KEV-listed 2024-09-18, active_exploitation confirmed. patch_available true; live_patch_available false with the packet note that there is no live-patching primitive for this product and the vendor update (no reboot required) is the remediation.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2014-0502": {
     "name": "Adobe Flash Player Double Free Vulnerability",
@@ -42451,7 +43627,31 @@
         "adequate": false,
         "gap": "Least-functionality/removal of the end-of-life Flash Player plugin is the only durable fix; a control that merely inventories software does not force removal of an unsupported client component."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This packet carries both halves of the control. A vendor fix is recorded — the vector names Flash Player 10.3.183.67 and, on the 11.x branch, 11.6.602.171 on Windows and Mac OS X and 11.2.202.273 on Linux — and the live-patch notes state the vendor update requires no reboot. Against that, the lesson's framework coverage records that removal of the end-of-life Flash Player plugin is the only durable fix, and that a control which merely inventories software does not force removal of an unsupported client component. Together those set the requirement: reaching a fixed Flash Player build is an interim state, and the terminal state is removing Flash Player from the host, or replacing the workload where something still depends on it. A KEV listing dated 2024-09-17 for a flaw the vector records as exploited in the wild in February 2013 is the evidence that the long tail is real — a host still exposed eleven years after the fix shipped is a host with no functioning update path for the product. Scope it to what the packet names: Adobe Flash Player, and specifically the Firefox plugin sandbox the vector identifies, on Windows, Mac OS X and Linux. The packet provides no mapping from this defect into other SWF-capable or media-runtime software, so treating every plug-in or media player in the estate as an instance of this CVE manufactures removal work against software no evidence implicates. Operationally: enumerate every host with Flash Player installed, record for each whether it can take the fixed build for its branch and platform, put those on the interim clock, and put every host on a dated removal or replacement schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with confirmed exploitation in service indefinitely. Precondition on the interim half, which is where this is usually over-claimed: applying the 2013 update closes this defect only and says nothing about anything found in Flash Player since, and because the product's patch path has ended there is no later update to take, which is exactly why the requirement cannot end at every install reporting a fixed build. And because exploitation is confirmed and the delivery path is crafted SWF content the victim's browser loads, a host that browsed untrusted web content while exposed belongs on the incident path — hunted for second-stage payloads and rebuilt if confirmed — rather than being closed on the patch record.",
+        "evidence": "Packet: CWE-269 incorrect default permissions — the vector states the Firefox sandbox in Adobe Flash Player before 10.3.183.67 and 11.x before 11.6.602.171 on Windows and Mac OS X, and before 10.3.183.67 and 11.x before 11.2.202.273 on Linux, does not properly restrict privileges, making it easier for remote attackers to execute arbitrary code via crafted SWF content, as exploited in the wild in February 2013. cisa_kev true, kev_date 2024-09-17, active_exploitation confirmed, poc_available false, cvss 8.8, rwep_score 48. patch_available true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The lesson's framework_coverage for NIST-800-53-CM-7 records that least-functionality/removal of the end-of-life Flash Player plugin is the only durable fix, and that a control which merely inventories software does not force removal of an unsupported client component; its response guidance names purging Flash from managed endpoints, hunting for post-exploitation second-stage payloads, and reimaging confirmed-compromised hosts. AU-Essential-8-App-Hardening (User application hardening), NIST-800-53-CM-7 (Least Functionality), NIST-800-53-SI-2 (Flaw Remediation) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock is the one thing a vulnerability-management program will get wrong on this entry. The packet records the fix as shipping against exploitation the vector places in February 2013, and the KEV listing as 2024-09-17, so under 'whichever is later' the deadline runs from the 2024 listing rather than from the original disclosure — an eleven-year-old finding becomes a current obligation the day CISA lists it. Two of the packet's own fields are what keep it off the queue otherwise: poc_available is false, so a triage rule gated on public exploit code never raises it, and a program that ages or deprioritizes findings by CVE year treats a 2013 identifier as historic while the packet records active_exploitation as confirmed. For this entry the documented-compensating-controls branch is the one most operators will need, because live_patch_available is false and the durable answer for an unsupported plugin is removal, which usually needs a change window longer than the deadline: block SWF content at the web gateway for the hosts that cannot be reached inside the window, and record that as a time-bound compensating state carrying a removal date, not as remediation. Distinguishing test: query the vulnerability register for items whose KEV listing date postdates their CVE year by more than a year, and confirm each carries a deadline derived from the listing date — a register whose Flash Player finding is dated 2013 and sorted to the bottom is measuring disclosure age rather than exposure. Precondition: a gateway block on SWF content bounds delivery only over the paths the gateway sees; it does nothing for content that reaches the browser without traversing it, and it does not remove the plugin, so it holds only until the removal schedule lands.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-09-17, against a vector that records exploitation in the wild in February 2013 and names the fixed builds (10.3.183.67; 11.x fixed at 11.6.602.171 on Windows and Mac OS X and 11.2.202.273 on Linux). active_exploitation confirmed, poc_available false, cvss 8.8, rwep_score 48. patch_available true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The lesson's prevention guidance names uninstalling or disabling the Flash Player plugin and blocking SWF content at the web gateway. NIS2-Art21-vulnerability-management (Vulnerability handling) and UK-CAF-B4 (System security) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2014-0497": {
     "name": "Adobe Flash Player Integer Underflow Vulnerablity",
@@ -42785,7 +43985,22 @@
         "adequate": false,
         "gap": "Least-privilege alone does not help — the flaw lets an already-present low-privileged user escalate to SYSTEM, defeating the privilege boundary the control assumes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet puts this in Windows Installer and describes a local low-privileged user triggering a repair, which briefly runs an elevated process, then either hijacking that elevated context or racing the rollback temp files with symlinks and oplocks to obtain a SYSTEM shell. Every account in that sequence is already legitimate, which is what makes the least-privilege gap cited on this entry unclosable from the account side: nothing over-broad is being abused, so an attestation showing ordinary users hold ordinary rights passes cleanly while any interactive user on the host can take SYSTEM. The remediation is therefore the Windows update itself, driven across every affected host on the clock that opened with the 2024-09-10 KEV listing rather than folded into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU - never by 'approved', 'downloaded' or 'installed' in the management console. The packet's live-patch notes are decisive on that measurement: there is no live-patching primitive for this product and the vendor update requires a reboot to be the remediation, so a host that has taken the update and not restarted is still running the vulnerable Windows Installer path and must be counted as exposed rather than compliant. Enumerate hosts where many non-administrative users hold interactive sessions first - shared workstations, terminal and jump hosts - because on those the precondition this flaw needs, an ordinary local user able to trigger an installer repair, is the normal operating state rather than an anomaly, and those are also the hosts where the required restart is most likely to be deferred because taking it evicts logged-on users. The distinguishing test pairs the build with the boot: read each host's installed build and its last restart time together, and treat any host whose last restart predates the update as unremediated - a patch report showing the update installed marks that machine compliant while the vulnerable repair path is still live in memory. Priority follows the packet rather than the CVSS band: 7.8 reads as a routine endpoint item, while confirmed exploitation plus a public PoC on a user-triggerable path to SYSTEM makes this the escalation half of a chain whose initial-access half arrives separately.",
+        "evidence": "Packet: CISA KEV-listed 2024-09-10, active_exploitation confirmed, poc_available true, CVSS 7.8, RWEP 75, CWE-269, patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Attack vector: 'A local low-privileged user triggers a Windows Installer repair, which briefly runs an elevated process; by hijacking that elevated context (or racing the rollback temp files with symlinks/oplocks) the attacker obtains a SYSTEM shell.' Citing gaps include NIST-800-53-AC-6 (Least Privilege), NIST-800-53-SI-2 (Flaw Remediation), AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIS2-Art21-patch-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2024-38226": {
     "name": "Microsoft Publisher Protection Mechanism Failure Vulnerability",
@@ -42880,7 +44095,39 @@
         "adequate": false,
         "gap": "Flaw remediation closed the access-control bug, but the observed ransomware window (<1h) and the credential-reuse follow-on mean patch-only remediation without a mandatory local-user password reset leaves the device compromisable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The firewall is the perimeter here, and the packet's chain does not end at the firewall bug: an unauthenticated remote attacker reaches SonicOS management access, and ransomware affiliates then use reused local-user credentials on SSL VPN to gain rapid internal footholds. That second half is what makes patch-in-place the wrong default for this device. Upgrading the firmware closes the improper-access-control path and leaves every local user account the appliance holds exactly as the attacker found it, and those credentials are the packet's own stated pivot into the estate. Bound to this product, the control means an appliance that was reachable on Gen 5 or Gen 6 firmware, or on Gen 7 running SonicOS 7.0.1-5035 or older, is handled as attacker-held rather than as a version-string problem: export the configuration for review, rebuild the unit onto the fixed firmware rather than upgrading over the running state, and rotate every local account the appliance stores, SSL VPN local users first, because that is the account class the packet names. Distinguishing test, and it is what separates this from paper closure: for each firewall produce the installed firmware version alongside the date each local user's password was last set, and confirm no account still carries a password that predates the upgrade. An appliance that reports the fixed build while its SSL VPN local accounts keep their pre-upgrade passwords is still exploitable by the exact chain the packet describes, and both the patch-application and flaw-remediation attestations read clean on it. Preconditions: this is the response path for a unit that was reachable during the exposure window — it prevents nothing on its own, and it does not replace the vendor update, which the packet records as the remediation with no live-patch path and a required reboot, so a rebuilt unit that has not come back on the fixed firmware is exposed again the moment it is online. Rotation also reaches only credentials this appliance holds; where the same passwords were reused on other systems, those systems are outside what rebuilding this device can fix and need their own rotation scope.",
+        "evidence": "Packet: 'SonicWall SonicOS Improper Access Control Vulnerability', cwe_refs CWE-284, cvss 9.8, rwep_score 62, poc_available false. Vector: 'An improper access control vulnerability has been identified in the SonicWall SonicOS management access, potentially leading to unauthorized resource access and in specific conditions, causing the firewall to crash. This issue affects SonicWall Firewall Gen 5 and Gen 6 devices, as well as Gen 7 devices running SonicOS 7.0.1-5035 and older versions.' attack_vector: 'An unauthenticated remote attacker reaches SonicOS management access to obtain unauthorized resource access (or crash the firewall); ransomware affiliates chained this with reused local-user credentials on SSL VPN to gain rapid internal footholds.' cisa_kev true, kev_date 2024-09-09, active_exploitation confirmed. 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 closed here: NIST-800-53-SI-2 (Flaw Remediation), AU-Essential-8-Patch (Patch operating systems), UK-CAF-D1 (Response and recovery planning).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "UK-CAF-D1"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A SonicWall firewall is the device class this tier exists for, and the packet places the defect on its management access — pre-authentication, reachable by a remote attacker holding no credential, on the box that is itself the trust boundary. For this entry the tier means the clock runs from the 2024-09-09 KEV listing rather than from the next appliance maintenance window, and that where the fixed firmware cannot be taken inside that window the alternative is not a risk acceptance but isolation of the vulnerable interface: SonicOS management answers only from a named operator source or an out-of-band path, never from the internet. The reason the ordinary schedule does not fit this device is in the packet's own vector — the flaw can crash the firewall as well as expose management resources, so the failure mode of deferring includes losing the perimeter itself, and the attack_vector records affiliates converting the access into rapid internal footholds. Precondition, and it must be stated because this is exactly where the control gets over-claimed on firewalls: restricting reachability bounds who can send the request, it does not remove the defect, and it does not cover the whole chain the packet describes. Management access can usually be pulled back to an operator segment. The SSL VPN the packet names as the pivot cannot be — it exists to answer remote clients, and the credential-reuse step needs no access to the management interface at all, so a unit whose management plane has been restricted is still reachable through the half of the chain that turns valid local credentials into a foothold. The packet records the vendor update as the remediation, with no live-patch path and a reboot required, so interface restriction is the bridge to a reboot that still has to be scheduled, never a substitute for it.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-09-09, active_exploitation confirmed, cvss 9.8, rwep_score 62, cwe_refs CWE-284. Vector states the flaw is in 'the SonicWall SonicOS management access, potentially leading to unauthorized resource access and in specific conditions, causing the firewall to crash', affecting 'SonicWall Firewall Gen 5 and Gen 6 devices, as well as Gen 7 devices running SonicOS 7.0.1-5035 and older versions'. attack_vector: 'An unauthenticated remote attacker reaches SonicOS management access ... ransomware affiliates chained this with reused local-user credentials on SSL VPN to gain rapid internal footholds.' 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 closed here: NIS2-Art21-patch-management (Vulnerability handling and disclosure) and NIST-800-53-SC-7 (Boundary Protection).",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "This control names firewalls specifically, and the packet gives two reasons it binds to this one. First, the evidence that matters on this chain is authentication data the firewall itself produces: the packet's attack_vector is reused local-user credentials on SSL VPN, so the signal is a SUCCESSFUL SSL VPN authentication on a local firewall account from a source that account has not used before, followed by internal activity — not a failed-login pattern and not a malware artefact, because on this chain the credential is valid and the login is accepted. Second, the packet's vector states the flaw can cause the firewall to crash, and a crashed or restarted appliance is precisely when on-box log retention is thinnest. Applied here, the requirement is that SonicOS syslog, authentication and VPN session logs land on a collector in a separate trust zone — different management plane, different credentials, not reachable by administering the firewall — so the record of that login survives both an attacker holding the device and the device restarting. The distinguishing test is the alert, not the pipeline: replay a successful SSL VPN authentication for a local account from an unfamiliar source and confirm the collector raises an alert. A SIEM that ingests the firewall's logs but alerts only on authentication failures and denied traffic sees nothing at all on this chain, because every step the packet describes uses credentials the device accepts. Precondition: this preserves and surfaces evidence and prevents nothing — it does not bound reachability of SonicOS management access and it does not remediate the flaw, which the packet records as requiring the vendor update and a reboot. Its value is confined to the window between an attacker reaching the device and the estate responding, and it is worth nothing if the collector authenticates through the same appliance or the same credential set the attacker has just obtained.",
+        "evidence": "Packet vector: '... potentially leading to unauthorized resource access and in specific conditions, causing the firewall to crash.' attack_vector: 'An unauthenticated remote attacker reaches SonicOS management access to obtain unauthorized resource access (or crash the firewall); ransomware affiliates chained this with reused local-user credentials on SSL VPN to gain rapid internal footholds.' cisa_kev true, kev_date 2024-09-09, active_exploitation confirmed, poc_available false, cvss 9.8, rwep_score 62, cwe_refs CWE-284. 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.' UK-CAF-D1 (Response and recovery planning) is recorded as an insufficient framework control on this entry.",
+        "gap_closes": [
+          "UK-CAF-D1"
+        ]
+      }
+    ]
   },
   "CVE-2017-1000253": {
     "name": "Linux Kernel PIE Stack Buffer Corruption Vulnerability",
@@ -42988,7 +44235,29 @@
         "adequate": false,
         "gap": "Malicious-code protection that signature-scans uploads does not catch a crafted MVG/MSL image whose payload is a delegate command-injection string rather than known malware, so the file reaches the vulnerable ImageMagick coder."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "ImageMagick is reached here as a component, not as an application anyone administers: the packet's path is a server handing an uploaded file to ImageMagick's delegate command, so the exposed copies are wherever that binary or library sits behind an image-accepting feature. The packet also names two separate fixed lines — 6.9.3-10 on the 6.x branch and 7.0.1-1 on 7.x — which is the parity trap for this CVE: a report reading 'ImageMagick updated' does not say which branch each copy is on, and a 6.x copy is not remediated by the existence of a 7.x fix. The control here means enumerating every ImageMagick copy the estate actually executes — distribution packages, copies baked into container images, and builds shipped inside an application bundle that no host package manager owns — and showing each at or above the fixed release for its own branch, rather than closing the flaw-remediation ticket when the one inventoried package updates. Scope it to ImageMagick: the packet ties these eight coders to ImageMagick and provides no mapping into other image-processing software, so instructing operators to treat every image-handling binary in the estate as an instance of this CVE manufactures findings and real removal work against software no evidence implicates. Widen only where a verified source identifies another product carrying the same coders. Precondition: this reaches only copies the inventory can see and the operator can rebuild — a copy inside a container image is remediated by rebuilding the image, not by updating the host package, and it returns silently on the next deploy of an unrebuilt image. And the two fixed releases the packet names are the floor for this defect, not a destination: an estate that pins a copy at that build and calls it compliant is holding a component fixed against this CVE alone.",
+        "evidence": "Packet vector: 'The (1) EPHEMERAL, (2) HTTPS, (3) MVG, (4) MSL, (5) TEXT, (6) SHOW, (7) WIN, and (8) PLT coders in ImageMagick before 6.9.3-10 and 7.x before 7.0.1-1 allow remote attackers to execute arbitrary code via shell metacharacters in a crafted image, aka \"ImageTragick.\"' Packet attack_vector: an attacker uploads a crafted MVG/MSL/SVG image whose coder fields contain shell metacharacters; when a server passes the file to ImageMagick's delegate command, the metacharacters are executed as an OS command, yielding remote code execution. CWE-20; CVSS 8.4; RWEP 72; poc_available true; CISA KEV-listed 2024-09-09 with active_exploitation confirmed. 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": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "This CVE has a configuration-side mitigation path that does not wait on any package update, and the packet names its surface precisely: the eight coders — EPHEMERAL, HTTPS, MVG, MSL, TEXT, SHOW, WIN, PLT — that reach a delegate command. ImageMagick's security policy configuration (policy.xml) can deny those coders on a copy that is still on a vulnerable build, so the control's requirement is that this path be inventoried, tested and deployable for every ImageMagick copy independently of when each copy's update lands, rather than researched during the incident. It matters more than usual here because of how delivery works: the exploit file is itself a legitimate image format the packet names, so an upload filter that accepts images accepts the payload, and the payload is text carrying shell metacharacters rather than a binary that a malicious-code engine has anything to match on. The distinguishing test keys on the behaviour the packet documents: submit a crafted MVG file whose coder fields carry shell metacharacters through the real upload path on a staging instance and confirm no delegate command runs — confirming that a policy file exists on disk proves nothing about the process that did the decoding, which may be a different ImageMagick copy or one pointed at another configuration directory by its environment. Preconditions, none of which this control removes: denying these coders is a functional change that breaks any workflow legitimately rendering them, so it needs a rendering test before rollout; it must be applied to every copy the upload path can reach, since one host's policy does nothing for a copy inside a container image; and it stops new attempts only — the packet records confirmed active exploitation with a public PoC, so a server that accepted uploads while exposed needs triage, because the policy evicts nothing already executed. The packet's vendor update remains the remediation.",
+        "evidence": "Packet vector names the eight vulnerable coders — EPHEMERAL, HTTPS, MVG, MSL, TEXT, SHOW, WIN, PLT — in ImageMagick before 6.9.3-10 and 7.x before 7.0.1-1, executing arbitrary code via shell metacharacters in a crafted image (aka 'ImageTragick'). Packet attack_vector: an uploaded crafted MVG/MSL/SVG image whose coder fields contain shell metacharacters is executed as an OS command when the server passes the file to ImageMagick's delegate command. CWE-20; CVSS 8.4; RWEP 72; poc_available true; CISA KEV-listed 2024-09-09, active_exploitation confirmed. patch_available true; live_patch_available false with the packet note of no live-patching primitive for this product and the vendor update (no reboot required) as the remediation.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3"
+        ]
+      }
+    ]
   },
   "CVE-2024-7262": {
     "name": "Kingsoft WPS Office Path Traversal Vulnerability",
@@ -43136,7 +44405,30 @@
         "adequate": false,
         "gap": "Even with an available patch, the interval between the emergency Chrome release and enterprise-wide browser update rollout leaves a window that observed in-the-wild exploitation can hit."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The delivery path the packet describes is a user visiting a crafted HTML page, so for this CVE the browser's own update channel is the entire remediation and the enterprise update ring is the only thing that can delay it. Bound to this product, the control means the Chrome security channel is not held in a staged or piloted ring for this release: the packet records a vendor fix (builds at or above 128.0.6613.84 no longer carry the V8 defect) with no live-patching primitive and no host reboot requirement — but a browser already running when the update lands keeps the pre-fix V8 resident, because the replaced binary is inert until the browser process itself restarts. So there is no maintenance window to schedule and no host to reboot, and there is still a relaunch to force: completion is the version V8 is actually executing, not the version deployed, and a managed record reading 128.0.6613.84 against a session nobody has restarted is a host still running the vulnerable renderer. Two things therefore keep an estate exposed — a deferral the operator configured, and a long-lived browser session the policy never forced to relaunch, which is the one most likely to have met a crafted page in the interim. The clock runs from the 2024-08-28 KEV listing, not from the next scheduled ring promotion, because exploitation is already confirmed. Note what the packet does and does not support about priority: poc_available is false, so an estate that ranks work by public exploit availability will place this below flaws with published code while it is being used in the wild — the ranking input here is the confirmed-exploitation flag, not PoC presence. Precondition: removing the ring deferral reaches only browser instances a managed update policy actually governs. A personally-installed Chrome, or one whose update policy has been overridden locally, is not covered by shortening the ring; those instances are remediated by bringing them under policy or removing them. And because the packet places the heap corruption in the renderer and describes it as typically chained with a sandbox escape, the update closes the V8 defect but says nothing about a host that was already reached through a chain built on it.",
+        "evidence": "Packet: CWE-787 and CWE-358, CVSS 8.8, RWEP 54, cisa_kev true with kev_date 2024-08-28, active_exploitation 'confirmed', poc_available false. Vector: 'Inappropriate implementation in V8 in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.' Attack vector: 'A user visits a crafted HTML page that exploits an inappropriate implementation in V8 to corrupt the heap in the renderer, typically chained with a sandbox escape for full code execution.' patch_available true, patch_required_reboot false; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The entry's framework_control_gaps state the relaunch requirement directly — NIS2-Art21-patch-management: 'Standard patch management must be augmented with forced browser relaunch, since an updated binary is inert until the browser restarts.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Chrome takes this fix through its own security channel rather than through the operating system's package inventory, so on this CVE an operating-system patching attestation is measuring something that never carried the fix — which is exactly why an OS-patching control is recorded as insufficient here. The requirement is that browser currency be measured from the version each managed Chrome instance actually reports, checked against the packet's fixed level of 128.0.6613.84, and never from a management console's 'approved' or 'pushed' state or from an OS patch report that has no row for the browser at all. Distinguishing test: pull the running browser version from every managed endpoint — Chrome against 128.0.6613.84, and each other Chromium-based product against its own vendor fixed build — and show none is below it — an estate whose OS patch compliance reads clean while its fleet report carries no browser-version column has recorded nothing whatsoever about this flaw, and that is the specific way this one is marked compliant while it stays exploitable. Scope the sweep to what the entry names, which is wider than Chrome: the defect is in V8, and the affected products are recorded as Google Chrome and other Chromium-based browsers, Edge and Opera among them, on affected V8 builds. A sweep limited to Chrome therefore reports clean across an estate standardised on Edge, and those products are checked against their own vendor fixed builds rather than against the Chrome version string, which they do not report. The Chromium lineage is also the bound: treating every browser or every JavaScript engine in the estate as an instance of this CVE manufactures remediation work against software no evidence implicates. Precondition: this check sees only instances enrolled in the reporting channel. A browser installed outside managed software distribution produces no row, and an absent row is not a pass — it is an unmeasured instance that has to be enrolled or removed before the estate figure means anything.",
+        "evidence": "Packet vector names the affected component and fixed level: 'Inappropriate implementation in V8 in Google Chrome prior to 128.0.6613.84'. The entry's affected field reads 'Google Chrome and other Chromium-based browsers: an inappropriate implementation in the V8 JavaScript engine permits heap corruption via a crafted HTML page', and affected_versions lists both 'Google Chrome prior to 128.0.6613.84' and 'Chromium-based browsers (Edge, Opera) on affected V8 builds'. patch_available true; live_patch_notes state 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' active_exploitation 'confirmed', cisa_kev true, kev_date 2024-08-28. AU-Essential-8-Patch (Patch operating systems) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are both recorded among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-38856": {
     "name": "Apache OFBiz Incorrect Authorization Vulnerability",
@@ -43843,7 +45135,31 @@
         "adequate": false,
         "gap": "Configuring Microsoft Office to block internet-origin macros is the compensating control that neutralizes this file-borne RCE, but it is only effective where the baseline is actually enforced."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "The packet conditions this exploit on delivery: an attacker-supplied Microsoft Project file, opened by a victim 'with internet-macro blocking disabled', yielding code execution in the user's context. That condition is what makes provenance the enforceable control here, and it is also what makes 'the policy is enabled' an inadequate attestation — the block-macros-from-the-internet safeguard is a provenance decision, so it only fires on a file the host recognises as externally sourced. Bound to this product, the requirement is that a Project file arriving by mail, web download or an untrusted file share still carries the Mark-of-the-Web when Project opens it, and that the mark survives the container it arrived in: a .mpp extracted from an archive by a tool that does not propagate the mark, mounted from an ISO or VHD, renamed, or re-saved onto a share the estate treats as trusted reaches Project as local content, and the safeguard the packet names as the missing one is never consulted. Scope it to what the packet establishes: it names Microsoft Project, so the population to enumerate is the Project installs and the macro and Trust Center policy state applied to them — this is not a basis for re-baselining every application in the estate. The distinguishing test: mail a Project file that would trigger the internet-macro block inside a ZIP to a managed workstation through the normal ingress path, extract it the way a user would, open it, and confirm the block still applies to the extracted copy. An application-hardening attestation that records the policy as Enabled in Group Policy passes cleanly while a provenance-stripped .mpp reaches the same parser with macro execution permitted. Precondition: this is a delivery-path control. It bounds which files reach the CWE-20 defect with macros allowed; it does not repair the defect, and it gives nothing against a file delivered through a path the estate has already marked trusted. The packet records a vendor patch as the remediation, with no live-patch path and no reboot required, which is the argument for treating provenance enforcement as the bridge to that update rather than as the fix.",
+        "evidence": "Packet: 'Microsoft Project Remote Code Execution Vulnerability', cwe_refs CWE-20, cvss 8.8, rwep_score 48, poc_available false. Vector: 'Microsoft Project Remote Code Execution Vulnerability'. attack_vector: 'An attacker delivers a malicious Microsoft Project file; when the victim opens it (with internet-macro blocking disabled) the flaw yields code execution in the user's context.' cisa_kev true, kev_date 2024-08-13, active_exploitation confirmed. 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 closed here: AU-Essential-8-App-Hardening (User application hardening), NIST-800-53-CM-7 (Least Functionality), UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet supplies the two facts that set this clock: a KEV listing on 2024-08-13 with confirmed exploitation, and a vendor update the entry records as the remediation with no reboot required. The no-reboot property is the operative one here — the usual reason an Office-component update slides into the next monthly maintenance window does not apply, so the clock runs from the KEV listing and completion is measured per install, against the build Microsoft Project actually reports, rather than against 'approved' or 'downloaded' in the management console. The specific way this remediation goes wrong on this entry is the compensating control being mistaken for the remediation. The packet's exploitation condition is that internet-macro blocking was disabled; that describes the estate where the attack succeeded and is not a statement that an estate with the policy enabled is unexploitable, because the CWE-20 defect stays in the parser for any Project file that reaches a user without an internet-origin mark. Enabling the policy buys the time to deploy; recording it as closure of a KEV item leaves the flaw in place under a clean attestation. Precondition: this control governs only installs the update path can actually reach, and it presumes the fixed build is deployable to them. Where a Project install cannot take the update, the state is the macro policy as an active mitigation and it has to be carried as an open, dated item, not as an SLA that was met.",
+        "evidence": "Packet: 'Microsoft Project Remote Code Execution Vulnerability', cwe_refs CWE-20, cisa_kev true, kev_date 2024-08-13, active_exploitation confirmed, cvss 8.8, rwep_score 48, poc_available false. attack_vector: 'An attacker delivers a malicious Microsoft Project file; when the victim opens it (with internet-macro blocking disabled) the flaw yields code execution in the user's 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.' Citing gaps closed here: NIST-800-53-SI-2 (Flaw Remediation), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIS2-Art21-vulnerability-management (Vulnerability handling).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-32113": {
     "name": "Apache OFBiz Path Traversal Vulnerability",
@@ -44168,7 +45484,33 @@
         "adequate": false,
         "gap": "Internet-facing Now Platform instances present the vulnerable UI macros pre-authentication, so boundary controls that assume login-gated access do not apply."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet splits this estate in a way a single patch SLA does not model: ServiceNow applied the update to hosted instances and released it to partners and self-hosted customers, and names specific patches and hot fixes as what addresses the vulnerability. So the operator's obligation on the KEV clock that opened 2024-07-29 is three different actions depending on who runs the instance. On a vendor-hosted instance the operator cannot apply anything and the obligation is to obtain assurance that the instance actually carries the fix — an item to raise with the supplier and record, not an assumption to inherit from a status page. On a self-hosted instance it is applying the named patch or hot fix. On a partner-run instance it is the operator's own item to chase the partner to completion, because the exposure sits on the operator's data whoever holds the console. What makes the compressed clock enforceable here rather than aspirational is a packet fact: there is no live-patching primitive for this product and the vendor update requires no reboot, so nothing about downtime stands between the operator and remediation — the real delay is instance inventory and partner coordination, and both are addressable before the next disclosure rather than during it. Priority follows the packet: an unauthenticated path to code execution in the context of the Now Platform, a public PoC, confirmed in-the-wild exploitation and RWEP 74. The completion measure is per instance — every Now Platform instance the organization has, including any a partner operates on its behalf — showing the named patch or hot fix applied, not a count of instances 'on a current release'.",
+        "evidence": "Packet: CISA KEV-listed 2024-07-29, active_exploitation 'confirmed', poc_available true, CVSS 9.3, RWEP 74. Vendor description in the packet: the input-validation vulnerability was identified in Vancouver and Washington DC Now Platform releases; it 'could enable an unauthenticated user to remotely execute code within the context of the Now Platform'; 'ServiceNow applied an update to hosted instances, and ServiceNow released the update to our partners and self-hosted customers'; and the packet refers to the patches and hot fixes that address the vulnerability. patch_available true; live_patch_available false, with the packet's note stating 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-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Paper compliance on this entry has a precise shape, and it comes straight from the packet's wording: the vulnerability was identified in the Vancouver and Washington DC releases, and specific patches and hot fixes address it. A record showing an instance is on one of those named families therefore says nothing about whether the fix is present — the family release is not the unit of remediation here, the named patch or hot fix is, and a vulnerability-management report that closes this item on 'the instance is current' has recorded the vendor's release train rather than the presence of the fix. External scanning does not rescue it either, because the operator is looking at a hosted web application with no build banner to read. The operational test is behavioural and matches the path the packet documents: on a non-production instance, submit a Jelly/Glide template expression to a public, unauthenticated UI page and confirm it comes back as inert text rather than being evaluated server-side. That is exactly what an exploit doing what the packet describes would do — an unauthenticated submission to a public UI macro that the platform evaluates — so a probe that is refused or returned uninterpreted is evidence about the actual defect, whereas an instance-version report is evidence about a label. Preconditions: the probe must run against a non-production instance or under terms the vendor has agreed, since firing crafted input at a live production instance is an exploitation attempt in its own right; and on a vendor-hosted instance the operator may have no instance they are permitted to test, in which case this control degrades to a supplier-assurance question — which is the honest answer, not a reason to fall back on the release-train report.",
+        "evidence": "Packet attack vector: 'An unauthenticated attacker submits a Jelly/Glide template expression to a public UI macro; the Now Platform evaluates it server-side, giving arbitrary expression/code execution and access to instance data.' Packet vendor text names the Vancouver and Washington DC Now Platform releases and refers to the patches and hot fixes that address the vulnerability. CISA KEV-listed 2024-07-29, active_exploitation 'confirmed', poc_available true, CWE-1287.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-39891": {
     "name": "Twilio Authy Information Disclosure Vulnerability",
@@ -45516,7 +46858,21 @@
         "adequate": false,
         "gap": "Technical-vulnerability management often omits embedded Chromium runtimes (Electron apps, WebView) that inherit the same V8 flaw but do not auto-update with the browser."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's exposure is ordinary browsing: a victim visits an attacker-controlled or compromised page whose crafted JavaScript triggers an out-of-bounds write in V8, corrupting renderer memory, which chained with a sandbox escape yields code execution on the host. There is no user decision to harden and no attachment to quarantine — every managed endpoint running Google Chrome is in the exposed population the moment such a page loads, which is why the update clock is the lever with real leverage on this entry. For this CVE the control means the estate's Chrome update ring carries the fixed build inside the no-deferral window rather than a weekly or monthly ring, with completion measured by the version each browser reports rather than by the update policy being set in a console. The packet is unusually favourable on cost here and that removes the usual excuse: it records no live-patching primitive for this product and states the vendor update is the remediation with no reboot required, so there is no maintenance window to negotiate and no user-visible outage to schedule — a deferral on this entry buys nothing and is pure exposure. What still needs verifying is the browser that never closes: the update lands without a reboot, but a Chrome process that has been running since before it keeps executing the V8 it already loaded, so the version the running browser reports after relaunch is the measurement that counts, and long-uptime machines are the population to check first. Distinguishing test: enumerate the version actually reported by the running browser across a sample of the estate against the elapsed time since the vendor build shipped, weighted toward long-uptime hosts; an update-ring policy screenshot and a management-console compliant count are attestations about configuration, not evidence that the vulnerable V8 stopped executing anywhere. Scope this to Google Chrome — the packet names Chrome builds prior to 124.0.6367.207 and gives no mapping from this V8 into any other product, so treating every browser or embedded runtime in the estate as an instance of this CVE manufactures removal and update work against software this entry does not implicate. Precondition: a no-deferral ring compresses the window between the vendor build existing and the fleet running it. It does nothing for the window before the build existed, and the packet records confirmed in-the-wild exploitation with the KEV listing on 2024-05-16 — endpoints browsing before the update reached them were exposed to a bug already in use, so a host showing other indications of compromise belongs on the incident path rather than being closed on a version number.",
+        "evidence": "Packet: out-of-bounds write (CWE-787) in V8 in Google Chrome prior to 124.0.6367.207, reachable from a crafted HTML page; attack_vector describes a victim visiting an attacker-controlled or compromised page whose crafted JavaScript corrupts renderer memory, chained with a sandbox escape for code execution on the host. CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available false, CVSS 8.8, RWEP 54. 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 include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2021-40655": {
     "name": "D-Link DIR-605 Router Information Disclosure Vulnerability",
@@ -45679,7 +47035,30 @@
         "adequate": false,
         "gap": "Malicious-code protection that relies on OLE/MSHTML mitigations is exactly what this security-feature bypass defeats, so signature/heuristic AV on the mitigation layer is insufficient."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "The packet's delivery path is an attacker-supplied document the victim opens, and what the flaw defeats is the prompt: MSHTML bypasses the OLE/mitigation prompts, loads malicious content, and executes in the user's context. That is precisely why provenance has to drive an isolated render rather than a warning on this entry — the mechanism this CVE breaks is the one that asks the user, so a policy that tightens prompt settings is hardening the thing the packet says stops firing. Bound to this entry the requirement is that every document arriving by mail, web download or untrusted file share be marked untrusted at the ingress boundary; that a marked document open in a reduced-privilege isolated view instead of the full handler path that reaches the MSHTML platform; and that the mark survive its container — extracted from an archive, mounted from a disk image, or renamed — because a document that loses it is indistinguishable from a locally authored one and takes the full path with the user's privileges. The distinguishing test is a delivery test, not a settings export: send a document through each ingress path to a managed workstation, extract it from whatever container it arrived in, and confirm it still opens isolated. An estate whose user-application-hardening and malware-protection attestations show the OLE and macro settings configured passes cleanly while the packet's exact scenario — a crafted document that bypasses those prompts — still executes, and signature-based malware protection has no artifact to match on a bespoke document. Precondition: an isolated render bounds this path, it does not remove it. A document that reaches the full handler anyway — provenance stripped in transit, delivered from an internal share the boundary does not mark, or opened out of the isolated view by the user — reaches the same code. The packet registers no live-patch path and states the vendor update requires a reboot and is the remediation, so a host that installed the update without restarting still runs the vulnerable code, and a host that already opened such a document belongs on the incident path rather than being closed on the delivery control.",
+        "evidence": "Packet: Windows MSHTML Platform Security Feature Bypass Vulnerability (CWE-20). Attack path per the packet: \"An attacker delivers a crafted document that, when opened, causes the MSHTML platform to bypass OLE/mitigation prompts and load malicious content, leading to code execution in the user's context.\" CISA KEV-listed 2024-05-14 with confirmed in-the-wild exploitation; CVSS 8.8, RWEP 57; poc_available false; patch_available true, live_patch_available false, live_patch_notes: \"No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.\" AU-Essential-8-App-Hardening (User application hardening), NIST-800-53-SI-3 (Malicious Code Protection) and ISO-27001-2022-A.8.7 (Protection against malware) are cited as insufficient on this entry.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The packet classifies this as a security feature bypass and names what fails: the OLE/mitigation prompts do not fire on the crafted document. The estate's evidence that its hardening works is evidence about settings, while the thing this CVE changes is whether the mechanism behind those settings still triggers — and nothing in a configuration report distinguishes the two. Bound to this entry the requirement is that the prompt-and-provenance class be re-exercised as a class after each patch deployment on this platform: the OLE/mitigation prompt path, the untrusted-origin mark, and whatever mail detonation and endpoint rules the estate relies on to catch a document that gets past them, driven with a document that takes the MSHTML platform down the path the packet describes — rather than tested once against this CVE and retired. The distinguishing test is a detonation result, not a policy export: a document exercising the mitigation-prompt path must be shown to be stopped on the build currently deployed; a report showing the prompt enabled is exactly the artifact that stayed green while this bypass was exploited in the wild, which is what makes the flaw-remediation and vulnerability-handling controls cited here insufficient — they record that an update was applied, not that the mechanism the update was supposed to restore now fires. Precondition: this is verification, not prevention. It tells the operator the mechanism has stopped working; it removes nothing, and the packet records the vendor update — which requires a reboot — as the remediation. A battery can also only cover primitives already known to it, so a bypass discovered after the battery was written passes it; its value is that it catches this class of mechanism failing without any setting changing or any signature firing, which is what the packet establishes happened here.",
+        "evidence": "Packet: the entry is a Windows MSHTML Platform Security Feature Bypass (CWE-20) in which the crafted document causes the MSHTML platform to bypass OLE/mitigation prompts and load malicious content. CISA KEV-listed 2024-05-14 with confirmed in-the-wild exploitation; CVSS 8.8, RWEP 57; poc_available false; patch_available true with live_patch_available false and the packet stating the vendor update requires a reboot and is the remediation. NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-handling are cited as insufficient on this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-30051": {
     "name": "Microsoft DWM Core Library Privilege Escalation Vulnerability",
@@ -46118,7 +47497,42 @@
         "adequate": false,
         "gap": "The compromised device IS the network boundary; boundary protection cannot compensate when the firewall's own preauth GlobalProtect endpoint yields root RCE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "PAN-OS running GlobalProtect is the perimeter-trust-boundary case this tier exists for, and the packet states why a generic patch SLA cannot govern it: an unauthenticated attacker sends GlobalProtect requests with a crafted SESSID cookie and ends with arbitrary code execution at root privilege on the firewall itself. The lesson's framework coverage puts it plainly — the compromised device IS the network boundary, so boundary protection cannot compensate when the firewall's pre-auth GlobalProtect endpoint yields root RCE. For this CVE the tier means the clock starts at the 2024-04-12 KEV listing, and the alternative to meeting it is taking the GlobalProtect portal and gateway interface out of service, not accepting a 14- or 30-day window. Scope the enumeration to what the packet names — PAN-OS in the affected versions with the GlobalProtect feature configured — and explicitly do not sweep Cloud NGFW, Panorama appliances or Prisma Access, which the vector states are not impacted; counting those produces emergency change work against products no evidence implicates. Precondition on the isolation half, which is where this control is most often over-claimed: the GlobalProtect portal and gateway exist to answer unauthenticated requests from the internet so remote users can connect, so isolating that interface means withdrawing remote access for the duration, and it is simply unavailable at a site where remote access is the business function. Where isolation is not available, the vendor fix on the accelerated clock is the only remaining lever. The packet records live_patch_available false and states the vendor update requires a reboot, so a firewall that has taken the fix but has not been rebooted is still running the vulnerable code and must be counted as exposed — on a device carrying production traffic that reboot is the step most likely to be deferred, because taking it interrupts the traffic the firewall is passing, and a deferral recorded as patched is the specific way this remediation goes wrong.",
+        "evidence": "Packet: CWE-20 / CWE-77 command injection arising from arbitrary file creation in the GlobalProtect feature of PAN-OS; the vector states it may enable an unauthenticated attacker to execute arbitrary code with root privileges on the firewall, for specific PAN-OS versions and distinct feature configurations, and that Cloud NGFW, Panorama appliances and Prisma Access are not impacted. cisa_kev true, kev_date 2024-04-12, active_exploitation confirmed, poc_available true, cvss 10, rwep_score 84. patch_available true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' The lesson's framework_coverage for NIST-800-53-SC-7 records that the compromised device IS the network boundary and that boundary protection cannot compensate when the firewall's pre-auth GlobalProtect endpoint yields root RCE. AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, NIST-800-53-SC-7 and UK-CAF-B4 are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records what survives the fix here: observed chains deploy the UPSTYLE Python backdoor, which reads the device error log for further commands. That implant is a file and a running process on the firewall, placed by code that executed as root — the update closes the SESSID file-creation path but removes nothing already written through it, so a device exploited before remediation comes out of the update still implanted and still reachable by its operator. For a PAN-OS firewall the default response therefore has to be: capture the configuration and support data for analysis, rebuild the device from known-good firmware, and treat every secret the firewall held as exposed — GlobalProtect and management credentials, the directory or RADIUS service accounts it authenticated with, its certificates and private keys, and any pre-shared key on a tunnel it terminated — because the packet's stated outcome is root on the device that stored all of them. This is the state a flaw-remediation or technical-vulnerability-management attestation cannot express: both close when the fixed version is installed, and an implanted-then-patched firewall satisfies them exactly while remaining under attacker control. Distinguishing test: for any device that was internet-reachable and unpatched during the exposure window, require evidence that the rebuild-and-rotation path was taken rather than the version record — an estate that can produce a fixed version for every firewall but cannot say which of them were reachable before the fix landed has not answered the question. Precondition: a rebuild removes what is on the device, it does not reach what left it. Credentials read off the firewall before the rebuild stay valid until they are rotated, and sessions or tunnels established with them stay live — so the rotation is the part that must complete, not the reimage.",
+        "evidence": "Packet: the attack_vector states that an unauthenticated attacker sends GlobalProtect requests with a crafted SESSID cookie whose value is written to disk as an attacker-controlled filename, that a later process executes that content as an OS command with root privileges, and that observed chains deploy the UPSTYLE Python backdoor which reads the device error log for further commands. cisa_kev true, kev_date 2024-04-12, active_exploitation confirmed, poc_available true, cvss 10, rwep_score 84. patch_available true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' The lesson's response guidance records assuming full device compromise, rotating all secrets and certificates on the firewall, and rebuilding from known-good firmware, on the basis that root RCE on the perimeter device means every credential and key it held must be considered exposed. NIS2-Art21-incident-handling (Incident handling), NIST-800-53-SI-2 (Flaw Remediation) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet makes the firewall's own log a component of the exploit rather than a record of it: the UPSTYLE backdoor reads the device error log for further commands, and the attacker holds root, so every log the device writes sits in the attacker's read-and-write path. Anything an investigator later asks that firewall about the incident is answered by a file the attacker could edit. For this deployment the control means the GlobalProtect authentication logs, the system and configuration logs and the traffic logs are streamed as they are written to a collector in a separate trust zone — different management plane, different credentials, different authentication path from the firewall's own — so a pre-tamper copy exists off the device. What the rules key on has to be what this chain actually emits: GlobalProtect requests carrying anomalous SESSID cookie values, files appearing under the GlobalProtect and device-telemetry temp paths that the request handling writes to, and — because the backdoor's command channel is the device's own error log rather than a network callback — outbound connections originating from the firewall's management plane to destinations it has no operational reason to reach. A rule written against appliance crashes or named exploit tooling would see none of this: the request is a well-formed GlobalProtect request, the write is performed by the device's own service, and the implant runs as a Python process on the appliance. Precondition, and it is the whole control: the off-device stream must already have been running before the compromise. A collector stood up during the investigation holds nothing from the exposure window, and root on the firewall can stop the forwarder or feed it falsified entries from that point on — so the separate-zone copy is authoritative for what it received before the attacker acted, and no further. Constrain the management plane's egress at the same time, or the same root access that reaches the log reaches the internet.",
+        "evidence": "Packet: the attack_vector states the crafted SESSID cookie value is written to disk as an attacker-controlled filename and later executed as an OS command with root privileges, and that observed chains deploy the UPSTYLE Python backdoor which reads the device error log for further commands. cisa_kev true, kev_date 2024-04-12, active_exploitation confirmed, poc_available true, cvss 10, rwep_score 84. The lesson's detection guidance records that the backdoor manipulates on-box logs, so external/network telemetry is more trustworthy than the appliance's own logs, and names anomalous files under GlobalProtect/device-telemetry temp paths, crafted SESSID cookie values, UPSTYLE artifacts and outbound connections from the management plane as the hunt indicators. NIS2-Art21-incident-handling (Incident handling) is recorded as a citing gap against this entry.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-3273": {
     "name": "D-Link Multiple NAS Devices Command Injection Vulnerability",
@@ -46155,7 +47569,31 @@
         "adequate": false,
         "gap": "No patch exists for these EoL NAS devices, so flaw remediation cannot apply; the only fix is retirement, which SI-2's patch framing does not compel."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet closes off every disposition except removal and states it in the entry's own words: the vulnerability only affects products no longer supported by the maintainer, the vendor was contacted early and confirmed immediately that the product is end-of-life, and it should be retired and replaced. patch_available is false and the live-patch note reads 'End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.' So for the DNS-320L, DNS-325, DNS-327L and DNS-340L there is no fixed build to reach at all — this is not a product where removal becomes the terminal state after an interim patch, it is one where removal is the only state, and any requirement phrased as 'every unit reports the fixed firmware' is unsatisfiable by construction. Requirement in operational terms: enumerate every unit of these four models in service, give each a dated removal or replacement schedule, and settle the migration target for the stored data first — a NAS pulled with nowhere for its contents to go is exactly how a removal date decays into an open-ended risk acceptance. Hold the scope to the four models the packet names; it ties the command-injection sink to /cgi-bin/nas_sharing.cgi on those devices and provides no mapping into other D-Link hardware, so treating the wider storage estate as an instance of this CVE manufactures replacement work against products no evidence implicates. Precondition, which is where this is routinely over-claimed on cheap appliances: because exploitation is confirmed, the exploit has been publicly disclosed, and the packet records botnets weaponizing it to drop Mirai, a unit reachable during the exposure window may already be running attacker code as root. Removing the hardware ends the exposure but does not undo it — the data the unit held and any credential stored on it are to be treated as exposed regardless of the decommission date, and a unit suspected of having been reached belongs on the incident path rather than only on the replacement schedule. Distinguishing test: for each unit, produce a removal date and the migration target for its data. A vulnerability-management record carrying these models as 'no patch available, risk accepted' with no removal date is the outcome this control exists to catch, and it is a record every patch-framed framework control on this entry will accept as complete.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes 'End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.' Vector: '** UNSUPPORTED WHEN ASSIGNED ** ... D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403. Affected is an unknown function of the file /cgi-bin/nas_sharing.cgi of the component HTTP GET Request Handler. The manipulation of the argument system leads to command injection ... The exploit has been disclosed to the public and may be used ... NOTE: This vulnerability only affects products that are no longer supported by the maintainer. NOTE: Vendor was contacted early and confirmed immediately that the product is end-of-life. It should be retired and replaced.' attack_vector: the base64-encoded command in the 'system' parameter 'is passed to a shell and executed as root, and botnets weaponized it to drop Mirai.' cisa_kev true, kev_date 2024-04-11, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 79, cwe_refs CWE-77. Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 Flaw Remediation and UK-CAF-B4 System security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "These are network-attached storage appliances whose purpose is holding the primary and backup copy of a household's, remote worker's or branch site's files, and the packet reaches root on them in a single unauthenticated HTTP GET: a base64-encoded command in the 'system' parameter of /cgi-bin/nas_sharing.cgi is passed to a shell and executed as root. Since the packet records no vendor fix and names isolation as one of only two available dispositions, reachability is the only lever the operator holds for as long as a unit remains in service. For the DNS-320L, DNS-325, DNS-327L and DNS-340L that means the device's HTTP interface answers only from an operator subnet or an authenticated VPN — not from the general user VLAN, and above all not from the internet through a router port-forward or a UPnP mapping, which is how NAS hardware at homes, remote-worker locations and small branch sites normally acquires its exposure. Constrain the outbound path too: the packet records botnets weaponizing this to drop Mirai, and a Mirai-class implant on a rooted NAS needs egress both to reach its controller and to ship what the device stores. Precondition, and it must never be recorded as closure: this bounds who can send the GET, it does not close the path. The request carries no credential the site issued, so every host inside the permitted segment already satisfies the attacker's only requirement, and the appliance exists to serve the client network it sits on — for a unit serving a general user VLAN there is no segment that removes the path, only isolation of that VLAN from anything that matters. It also does nothing for a unit already reached: root execution has already happened, no firmware update exists to displace what was left behind, and re-segmenting a compromised NAS leaves the implant resident and the stored data already exposed. Isolation here is a holding measure for the window before removal, not an alternative to it. Distinguishing test: from a general user VLAN and from an external address, request /cgi-bin/nas_sharing.cgi on the unit; anything that answers is within reach of the publicly disclosed exploit. 'The NAS is on the internal network' is a claim about topology, not a demonstration that the interface is unreachable from untrusted segments.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends a crafted HTTP GET to /cgi-bin/nas_sharing.cgi using the hardcoded messagebus backdoor account (CVE-2024-3272) with a base64-encoded command in the system parameter; the value is passed to a shell and executed as root, and botnets weaponized it to drop Mirai.' Vector names 'D-Link DNS-320L, DNS-325, DNS-327L and DNS-340L up to 20240403', the '/cgi-bin/nas_sharing.cgi of the component HTTP GET Request Handler', and states 'It is possible to launch the attack remotely.' patch_available false, live_patch_available false, live_patch_notes 'End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.' poc_available true, active_exploitation 'confirmed', cisa_kev true, kev_date 2024-04-11, cvss 9.8. Citing gaps include NIST-800-53-SC-7 Boundary Protection and NIS2-Art21-network-security (Security of network and information systems).",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-3272": {
     "name": "D-Link Multiple NAS Devices Use of Hard-Coded Credentials Vulnerability",
@@ -46665,7 +48103,30 @@
         "adequate": false,
         "gap": "Essential-Eight OS-patching maturity is scoped to workstations/servers and does not compel the same-day mobile-device update discipline this actively-exploited iOS/iPadOS flaw requires."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The remediation this packet records is not one build but a set of per-train builds — iOS 16.7.6 and iPadOS 16.7.6, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.4, macOS Sonoma 14.4, macOS Ventura 13.6.5, tvOS 17.4, visionOS 1.1 and watchOS 10.4 — so for this CVE a single minimum-version rule is the wrong instrument and 'on the latest major release' is not the test. Each device must be at or above the fixed build for the train it is actually running: a Mac held on Monterey or Ventura for application-compatibility reasons has a fix available on that train and stays exposed until it takes it, and a policy expressed only as 'Sonoma 14.4 or later' either misses those devices or reports them non-compliant for the wrong reason. Make the per-train fixed build an access condition — mail, VPN and document access denied to a device below it — rather than a stale-build row on a patch-compliance dashboard. Enumerate every train the packet names, including tvOS, visionOS and watchOS, because those are the ones that sit outside most managed-device inventories, so their exposure never reaches the report the estate reads. Precondition: the packet records no vendor live-patch mechanism and states that remediation requires applying the fixed release and rebooting, so a device that has installed the update but not restarted still runs the vulnerable kernel and must be counted as exposed, not compliant. And the access condition bounds what the estate exposes to a device below the fixed build; it does nothing for a device already compromised — this bug is reached by an attacker who already holds arbitrary kernel read and write, so a device plausibly inside the targeted chain the packet describes belongs on the incident path rather than the update path. Distinguishing test: enrol a device pinned below its own train's fixed build and confirm the policy denies it protected-resource access — an estate that surfaces the stale build on a report while the device keeps its mail and VPN access has recorded the exposure rather than removed it.",
+        "evidence": "Packet vector: 'A memory corruption issue was addressed with improved validation. This issue is fixed in iOS 16.7.6 and iPadOS 16.7.6, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.4, macOS Sonoma 14.4, macOS Ventura 13.6.5, tvOS 17.4, visionOS 1.1, watchOS 10.4. An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.' attack_vector: 'As a late stage of a targeted exploit chain, an attacker who already holds arbitrary kernel read/write uses this memory-corruption flaw to defeat kernel memory protections and gain durable kernel control.' cwe_refs CWE-787; cisa_kev true with kev_date 2024-03-06; active_exploitation confirmed; cvss 7.8; rwep_score 61; poc_available false; patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this entry the enforcement mechanism is the load-bearing part, because the packet's remediation is a reboot-gated OS update and nothing else: no live-patch mechanism is registered, and applying the fixed release and rebooting is the whole of it. On an Apple estate that update is normally offered to the user, and the restart is the step users postpone — so an estate that 'deployed' the update but permits deferral has recorded a deployment that has not happened, on a defect KEV-listed 2024-03-06 with confirmed exploitation and Apple's own note that it may have been exploited. Drive it instead through managed device configuration with a hard deadline and an enforced restart, on a KEV-tied clock rather than the estate's routine monthly ring, and measure completion by devices restarted onto the fixed build for their train rather than by updates approved, downloaded or 'available'. Precondition: this reaches only devices actually enrolled in management. Personally-owned devices carrying organizational data, and the tvOS, visionOS and watchOS units the packet names — which are frequently enrolled in nothing — are outside the enforcement path entirely, and for those the remaining lever is withholding organizational access from a device below the fixed build, not a push the estate cannot make. Enforcement also cannot help a device that is already in an attacker's hands: this bug is used by an attacker who already holds arbitrary kernel read and write, so the enforced update closes the exposure going forward and says nothing about a device that was already carried through the chain.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-03-06; active_exploitation confirmed; vector states 'Apple is aware of a report that this issue may have been exploited' and names the fixed builds across iOS/iPadOS, macOS Monterey/Sonoma/Ventura, tvOS, visionOS and watchOS; patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'; cvss 7.8; rwep_score 61; poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-23296": {
     "name": "Apple Multiple Products Memory Corruption Vulnerability",
@@ -46722,7 +48183,39 @@
         "adequate": false,
         "gap": "Essential-Eight patch maturity is workstation/server-scoped and does not compel same-day mobile OS updates for an active mobile zero-day."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet names the fixed releases across the iOS, iPadOS, macOS, tvOS, visionOS and watchOS families — iOS 16.7.8 and iPadOS 16.7.8, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.6, macOS Sonoma 14.4, macOS Ventura 13.6.7, tvOS 17.4, visionOS 1.1, watchOS 10.4 — and that list is this control's scope statement: an estate that drives the KEV clock opened 2024-03-06 across managed iPhones and Macs alone still leaves the tvOS, visionOS and watchOS builds the packet names running the vulnerable code, and those device classes typically sit outside the management channel that enforces the phone and Mac deadline. For this CVE the control means the update is pushed on that clock with user deferral disallowed, and completion is measured per device against the specific build the packet names for that device's OS family and track — not against an 'available' or 'downloaded' state in the management console. The packet records no live-patch mechanism and states that remediation requires applying the fixed release and rebooting, so a device that has staged the update but not restarted is still running the vulnerable code and must be counted as exposed; on a phone or a watch the restart is precisely the step a user defers, which is how this remediation gets recorded as complete while the exposure stands. Distinguishing test: enumerate the estate's Apple devices by OS family and installed build and confirm each is at or above the build the packet names for it, including the device classes the standard patch report does not cover. Precondition: this reaches only devices the management channel can see and compel — a personally owned or unenrolled device carrying organizational data is remediated by removing that access or that data, not by a deadline it never receives.",
+        "evidence": "Packet vector: 'A memory corruption issue was addressed with improved validation. This issue is fixed in iOS 16.7.8 and iPadOS 16.7.8, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.6, macOS Sonoma 14.4, macOS Ventura 13.6.7, tvOS 17.4, visionOS 1.1, watchOS 10.4. An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.' CWE-787, CISA KEV-listed 2024-03-06, active_exploitation confirmed, poc_available false, CVSS 7.8, RWEP 60. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet fixes this on two parallel iOS/iPadOS tracks — 16.7.8 and 17.4 — and on three separate macOS releases, Monterey 12.7.6, Sonoma 14.4 and Ventura 13.6.7. That is the condition a single minimum-version threshold cannot express, and it fails in the dangerous direction: a policy admitting anything at or above 16.7.8 admits a device running 17.0, which is numerically higher and still carries the flaw, while a policy pinned at 17.4 marks every device that correctly took 16.7.8 as non-compliant. For this CVE the control therefore means the minimum build is stated per OS family and per track, and enforced as an access condition — mail, VPN and document access withheld from a device below the build named for its own track — rather than surfaced as a row on a patch-compliance report. The distinguishing test is to enrol a device sitting above one track's fix but below its own, a 17.x device on a build under 17.4, and confirm the policy denies it access to protected resources; an estate whose compliance rule is a single version comparison passes that device while it stays exposed. Precondition: withholding access bounds what the device can reach while it is exposed, it does not remediate the device, and the packet's attack description is of a device whose attacker already holds arbitrary kernel read and write — so a device suspected of having been in that state belongs on the incident path and is not returned to service by clearing a build check. This is a holding measure for the window before the fixed release and its required reboot land, not a substitute for them.",
+        "evidence": "Packet vector names the fixed builds on parallel tracks: 'iOS 16.7.8 and iPadOS 16.7.8, iOS 17.4 and iPadOS 17.4, macOS Monterey 12.7.6, macOS Sonoma 14.4, macOS Ventura 13.6.7, tvOS 17.4, visionOS 1.1, watchOS 10.4', and states 'An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections.' attack_vector: the attacker already holds arbitrary kernel read/write and uses this RTKit memory-corruption flaw to bypass kernel memory protections, a late stage of a targeted exploit chain. CWE-787, KEV 2024-03-06, active_exploitation confirmed. patch_available true with live_patch_available false; remediation requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this flaw at a late stage of a targeted exploit chain: the attacker already holds arbitrary kernel read and write, and uses this RTKit memory-corruption bug to bypass kernel memory protections. Nothing an operator configures reduces that primitive once the chain has reached this point, and the control must not be recorded as if it did. What it means for this CVE is the earlier stage — for the cohort plausibly inside the targeting set chains of this class serve, place the device in a reduced-attack-surface posture so untrusted web content, message attachments, fonts and link previews are not processed automatically, narrowing the delivery of the stages that produce the kernel read/write this bug consumes. Two conditions have to be stated or this becomes a mitigation on paper only. First, the posture has to already be in force: assigned in response to a disclosure it gives nothing for the window that mattered, and the packet's own record is Apple aware of a report that the issue may have been exploited — that is after the fact by construction. Second, it does not evict an attacker already resident; a device believed to have carried the chain goes to the incident path rather than into a hardening rollout, and the packet's description of an attacker with arbitrary kernel read and write is the state in which no device-side setting is trustworthy. Distinguishing test: name the high-risk cohort and show the reduced-attack-surface posture was applied to each of those devices before the disclosure date, not after — a policy that exists but was assigned reactively passes an attestation while providing nothing during the exposure.",
+        "evidence": "Packet attack_vector: 'An attacker already holding arbitrary kernel read/write uses this RTKit memory-corruption flaw to bypass kernel memory protections, a late stage of a targeted exploit chain.' Packet vector: 'An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.' CWE-787, CISA KEV-listed 2024-03-06, active_exploitation confirmed, poc_available false, CVSS 7.8, RWEP 60. patch_available true, live_patch_available false — remediation requires applying the fixed release and rebooting. The entry cites NIST SP 800-53 Rev 5 CM-7 (Least Functionality) among its insufficient framework controls.",
+        "gap_closes": [
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2023-21237": {
     "name": "Android Pixel Information Disclosure Vulnerability",
@@ -47571,7 +49064,30 @@
         "adequate": false,
         "gap": "System-security assurance for a remote-access gateway is undermined when a mitigation ships and is then bypassed; point-in-time hardening does not survive an evolving exploit chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "Ivanti Connect Secure (9.x, 22.x), Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA are the remote-access trust boundary, and the packet has an unauthenticated attacker reaching the SAML component, coercing the appliance into a server-side request to its own loopback backend on 127.0.0.1:8090, and chaining CVE-2024-21887 from there to run OS commands and drop webshells. For these products the control means the remediation clock starts at the 2024-01-31 KEV listing and is measured in hours, not folded into the next appliance maintenance window, because the device being remediated is the thing that decides who gets inside. The packet is specific about what completion means: there is no vendor live-patch mechanism and remediation requires applying the fixed release and rebooting, so a unit that has taken the fixed release but not rebooted still runs the vulnerable code and must be counted as exposed — and on a VPN concentrator that reboot is the step most likely to slip, because taking it drops every active remote-access session, which is exactly how a deferral gets recorded as 'patched'. Precondition, and this is where the control is usually over-claimed: its alternative to the compressed clock is isolating the vulnerable interface, and here that lever is largely unavailable, because the SSRF is reached through the SAML component of the appliance's public-facing web interface — the service itself. Restricting reachability of that interface means denying remote access to the workforce, so it is a time-boxed business decision to be taken explicitly, not an assumed compensating control. Nor does network boundary filtering substitute: the coerced request originates on the appliance and terminates on its own loopback address, so no ACL between the appliance and any other host is on that path.",
+        "evidence": "Packet vector: SSRF (CWE-918) in the SAML component of Ivanti Connect Secure (9.x, 22.x), Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA, allowing access to restricted resources without authentication. Attack vector: forces a server-side request to the appliance's own loopback backend on 127.0.0.1:8090, then chains CVE-2024-21887 to run OS commands and drop webshells. CISA KEV listed 2024-01-31; active_exploitation confirmed; poc_available true; RWEP 84; CVSS 8.2; patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Citing gaps AU-Essential-8-Patch, NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's chain does not stop at information disclosure: it ends in OS command execution and webshells on the appliance, with confirmed in-the-wild exploitation and a public PoC running from the 2024-01-31 KEV listing. For any Connect Secure, Policy Secure or Neurons for ZTA unit that was reachable during that window, applying the fixed release is therefore not remediation — it closes the SSRF into 127.0.0.1:8090 and the chained command-injection path, and removes nothing the attacker already placed on the box, including a webshell that keeps working across the upgrade because it is attacker-written content rather than vendor code. Bound to these appliances, the control means the default incident path is configuration and evidence capture, rebuild from vendor media, and rotation of every credential the appliance stored or brokered, in place of patch-in-place. The technical-vulnerability and system-security attestations cited on this entry close on the version the appliance reports, which is exactly the state a compromised-then-patched unit is in — they read clean while an implant persists — and the ICT risk-management obligation cited here inherits the same defect when its protection measures rest on a device that may already be attacker-held. Distinguishing test: for each unit, produce the date the fixed release was applied, the date it was rebuilt, and the credential-rotation record; a fleet where the first date exists and the second does not has patched, not recovered. Precondition: rebuild returns the unit to a known-good build and nothing more — it does not establish what was read or taken during the exposure window, so the rotation half is what bounds continued access, and any account that authenticated through the appliance while it was exposed has to be treated as exposed with it.",
+        "evidence": "Packet attack vector: the unauthenticated SSRF chains CVE-2024-21887 'to run OS commands and drop webshells' on the appliance. active_exploitation confirmed; poc_available true; CISA KEV listed 2024-01-31; RWEP 84; patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Citing gaps ISO-27001-2022-A.8.8, UK-CAF-B4, DORA-Art-9.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "DORA-Art-9"
+        ]
+      }
+    ]
   },
   "CVE-2023-22527": {
     "name": "Atlassian Confluence Data Center and Server Template Injection Vulnerability",
@@ -48369,7 +49885,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management does not chain to secrets rotation, leaving leaked DB credentials valid after the Joomla update."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet establishes the fact this control exists for: the unauthenticated request returns the application configuration including the MySQL username, password and host, and those credentials are reused for deeper access. The vendor fixed release stops the endpoint from serving that configuration; it does not invalidate a credential that has already been served. With a public PoC and confirmed in-the-wild exploitation against a version range as wide as 4.0.0 through 4.2.7, any site that was reachable before it was upgraded has to be treated as having disclosed those secrets. Bound to this entry the requirement is that the response for an exposed site is upgrade plus rotation, in that order and both recorded: rotate the database credential and every other secret carried in the site configuration, then review what that database account could reach and what was done with it across the exposure window, scoping the review from the site's own request logs rather than from whether anything looks wrong in the CMS — nothing needs to look wrong, because the exploit is a well-formed GET that returns 200. Note which half of this control the packet supports: it establishes configuration disclosure and credential reuse, not code execution on the web server, so the rebuild default the control specifies for a pre-auth RCE is not what this entry calls for; the config-exfiltration and credential-rotation half is, and it is the half the cited patching and vulnerability-management controls miss entirely, because their completion criterion is the installed version. Precondition: rotation closes the disclosed credential and nothing else. If the deeper access the packet describes was already used to establish something durable — an application account, or a change to stored content — rotating the database password does not remove it, and a site that cannot account for its exposure window needs its administrative accounts and content compared against a known-good state rather than being closed on the upgrade record.",
+        "evidence": "Packet: Joomla! 4.0.0 through 4.2.7; \"An improper access check allows unauthorized access to webservice endpoints\" (CWE-284). Attack path per the packet: \"An unauthenticated attacker appends ?public=true to Joomla 4.x REST config/user endpoints; the improper access check returns the application configuration, including MySQL username, password, and host, which is reused for deeper access.\" CISA KEV-listed 2024-01-08 with confirmed in-the-wild exploitation; poc_available true; CVSS 5.3 against RWEP 68; patch_available true, live_patch_available false, live_patch_notes: \"No vendor live-patch mechanism; remediation requires applying the vendor fixed release.\"",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Read past the product class in this control's name to what it requires — a management function that authorizes its own caller instead of inheriting a verdict — because the Joomla webservice layer is where this product takes its access decision and this CVE is that decision being made from the request. The packet has an unauthenticated caller appending ?public=true to the 4.x REST config and user endpoints, and the improper access check handing back the application configuration. Bound to this product, the control means each webservice endpoint authorizes its caller itself before the handler runs and before any configuration value is serialized into a response, rather than honouring a flag the caller supplies; and the REST API surface answers only from networks with an operational need for it, so an arbitrary internet client cannot present the request at all. The access-enforcement and identity-and-access controls cited on this entry are cited precisely because they do not reach this path: the attacker never holds a Joomla account, so per-account privilege scoping is never consulted, and an attestation showing every administrator authenticates with correctly scoped roles passes cleanly while an unauthenticated GET returns the database password. Distinguishing test: from a network with no operational need for the API, issue unauthenticated requests to the config and user webservice endpoints on a staging site with the caller-supplied public flag set, and confirm each is refused before the handler runs and before anything is emitted — testing that the administrator login requires authentication demonstrates nothing about this path. Precondition: the endpoint-side check is a property the vendor fixed release establishes; this control states what to verify, it does not implement it. On a site still in the 4.0.0-4.2.7 range, restricting reachability bounds who can send the request but closes nothing — anything inside the permitted set still receives the configuration — and that restriction is unavailable where the site's own integrations consume those endpoints from outside a trusted segment.",
+        "evidence": "Packet: Joomla! 4.0.0 through 4.2.7, improper access check allowing unauthorized access to webservice endpoints (CWE-284); the unauthenticated request path is ?public=true against the Joomla 4.x REST config/user endpoints, returning the application configuration. CISA KEV-listed 2024-01-08 with confirmed in-the-wild exploitation; poc_available true; CVSS 5.3, RWEP 68; patch_available true with live_patch_available false and remediation stated as applying the vendor fixed release. NIST-800-53-AC-3 (Access Enforcement) and UK-CAF-B2 (Identity and access control) are cited as insufficient on this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2016-20017": {
     "name": "D-Link DSL-2750B Devices Command Injection Vulnerability",
@@ -50963,7 +52502,39 @@
         "adequate": false,
         "gap": "Technical-vulnerability-management closes on the CVE ticket without verifying the management-plane exposure that makes exploitation trivial was actually removed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "BIG-IP is the edge load-balancer class this control names, and the packet locates the reachable surface precisely: the Configuration utility, reached through the BIG-IP management port and/or self IP addresses. For this CVE the tier means the remediation clock runs from the 2023-10-31 KEV listing, and the alternative to the fix inside that clock is withdrawing the Configuration utility from every network that is not an administrator network — self IPs in particular, because a self IP can be reachable from data-plane segments the management port is not, and an estate that has hardened only the management port has not withdrawn the surface the packet names. The packet records no vendor live-patch mechanism and states that remediation requires applying the fixed release and rebooting, so a unit with the release staged but not rebooted still carries the vulnerable code and must not be counted as remediated; on a load-balancer carrying production traffic that reboot is the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Precondition, which is where this control is usually over-claimed: restricting reach to the Configuration utility bounds who can present the injected SQL, it does not repair the injection — and the packet pairs this CVE with CVE-2023-46747 to supply the unauthenticated reach, so an attacker who arrives through that bypass, or from a permitted administrator segment, still reaches arbitrary system-command execution. One further packet fact constrains the fix itself: the vector states that software versions which have reached End of Technical Support are not evaluated, so a unit on such a version has no evaluated fixed release to reach and its remediation is moving onto a supported branch rather than applying a hotfix to the branch it is on.",
+        "evidence": "Packet: CWE-89; an authenticated attacker with network access to the Configuration utility through the BIG-IP management port and/or self IP addresses executes arbitrary system commands, in practice paired with CVE-2023-46747 to gain the needed unauthenticated reach. CISA KEV-listed 2023-10-31; active_exploitation confirmed; poc_available true; CVSS 8.8; RWEP 75. patch_available true; live_patch_available false with the note 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The vector also states: 'Software versions which have reached End of Technical Support (EoTS) are not evaluated.'",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "AU-ISM-1546",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The BIG-IP Configuration utility is the constrained user surface this control governs. The packet describes a user authenticated to that utility injecting SQL which the utility passes to its backing database, ending in arbitrary system-command execution — a web administration surface wired straight through to system commands, which is the pattern the control forbids. Applied to this appliance it means the system-command capability sits behind its own authorization boundary that the Configuration utility can only reach through a constrained, parameterized interface, so the utility's own query handling is not the single thing standing between a low-privileged authenticated role and command execution on the device. This is exactly why the least-privilege and identity-and-access gaps cited on this entry can pass their attestations while the flaw stays fully exploitable: role assignment inside the utility is real, auditable and correctly configured, and the injection crosses it — once the SQL reaches the database the role the account holds stops being consulted. Preconditions, both load-bearing: the boundary is a property the vendor's fixed release establishes, so this control states what to verify rather than something the operator implements; and until that release and its reboot land, the only operator-side lever is limiting which accounts can authenticate to the Configuration utility, which bounds the population that can attempt it but closes nothing, because the packet's pairing with CVE-2023-46747 lets an attacker obtain the needed reach while holding no account at all. Because exploitation is confirmed, an appliance whose Configuration utility was reachable during the exposure window needs its administrative accounts and configuration examined against a known-good baseline rather than being closed out on the upgrade.",
+        "evidence": "Packet: CWE-89; 'An authenticated SQL injection vulnerability exists in the BIG-IP Configuration utility which may allow an authenticated attacker with network access to the Configuration utility through the BIG-IP management port and/or self IP addresses to execute arbitrary system commands', and the attack_vector adds that it is in practice paired with CVE-2023-46747 to gain the needed unauthenticated reach. Cited gaps on this entry include NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B2 (Identity and access control). active_exploitation confirmed; poc_available true; CISA KEV-listed 2023-10-31; CVSS 8.8; RWEP 75. patch_available true; live_patch_available false, remediation requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The outcome the packet records is arbitrary system-command execution on the BIG-IP itself — the traffic and TLS-termination boundary for whatever sits behind it — so an attacker who reached the Configuration utility read the appliance's configuration and key material before any fixed release was applied. With exploitation confirmed and a PoC public, the default for a unit whose Configuration utility was reachable during the exposure window is configuration capture for forensics, rebuild from vendor media onto a supported release, and rotation of every credential and key the appliance held, rather than upgrading the running unit and closing the ticket. Upgrading in place repairs the injection and preserves everything the attacker altered — and on this appliance that specifically includes the running configuration, which is carried forward through the upgrade, so a rogue administrative account or an altered configuration object survives the remediation that the vulnerability-management record shows as complete. Preconditions and limits: this is the conservative incident-response default and it costs an outage on a device the estate's traffic depends on. The packet gives no per-unit indicator of compromise, so the trigger has to be reachability of the Configuration utility during the window opened by the 2023-10-31 KEV listing, not a confirmed detection. Where an operator can demonstrate the utility was never reachable from any segment outside the administrator network for the whole of that window, the patch-and-reboot path the packet records is sufficient — and demonstrate means evidence from the network boundary, not the assertion that the appliance is internal.",
+        "evidence": "Packet: the injected SQL results in arbitrary system-command execution on the BIG-IP, reachable through the management port and/or self IP addresses, in practice paired with CVE-2023-46747 for unauthenticated reach. active_exploitation confirmed; poc_available true; CISA KEV-listed 2023-10-31; CVSS 8.8; RWEP 75. patch_available true; live_patch_available false with the note 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting' — the packet records the fixed release as the remediation, and this control is the statement that on a confirmed-exploited appliance the fixed release alone does not restore trust in the unit.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-46747": {
     "name": "F5 BIG-IP Configuration Utility Authentication Bypass Vulnerability",
@@ -51020,7 +52591,39 @@
         "adequate": false,
         "gap": "Essential-8 rapid-patch targets for internet-facing services are the right control but are commonly unmet for BIG-IP, leaving the preauth path open."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "BIG-IP sits on the trust boundary it protects, and the packet has an unauthenticated attacker with network access reaching endpoints that execute arbitrary system commands on it — so the appliance-patch window that treats a load balancer as infrastructure to be touched during a change weekend is the wrong tier for this defect. For this device the requirement is a clock that runs from the 2023-10-31 KEV listing to the moment each BIG-IP has both taken the fixed release and rebooted, because the packet records no vendor live-patch mechanism and states remediation requires applying the fixed release and rebooting. In an HA pair the reboot is the step that gets deferred — the standby takes the update, the failover is scheduled for a later window, and the unit carrying production traffic keeps running vulnerable code — so completion has to be measured per unit as running version plus last restart, not as a change ticket recording that the fixed release was deployed to the cluster. Public PoC and confirmed in-the-wild exploitation are both recorded on this entry, so no deferral rests on exploitation being theoretical. Precondition on the interim lever: restricting where the Configuration utility answers bounds exposure but does not remove it. The packet names the reach paths as the management port and/or self IP addresses, so removing the utility from self IPs cuts one of the two named paths while an attacker positioned on the management network still reaches it and still needs no credential.",
+        "evidence": "Packet entry 'F5 BIG-IP Configuration Utility Authentication Bypass Vulnerability' (CWE-288, CWE-306), cisa_kev true with kev_date 2023-10-31 and active_exploitation 'confirmed'; cvss 9.8, rwep_score 79, poc_available true. Vector: 'Undisclosed requests may bypass configuration utility authentication, allowing an attacker with network access to the BIG-IP system through the management port and/or self IP addresses to execute arbitrary system commands.' 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",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Configuration utility's authentication is enforced at its HTTP front end, and the packet's exploitation path goes around it: a request smuggled to the internal AJP connector reaches endpoints that execute arbitrary system commands without the authentication decision ever being taken. That is the remoting-protocol class this control governs — an internal, non-HTTP protocol endpoint that acts on requests it assumes the fronting layer already authenticated, sitting behind every perimeter and web-tier hardening measure the deployment is audited against. Bound to BIG-IP, the control means the internal connector must make its own authorization decision rather than inheriting a verdict from the layer in front of it, so a request crafted at the HTTP boundary cannot be delivered to it in a form that skips authentication. That property is what the fixed release establishes; the control states what to verify, it does not implement it. The operator-side half is the reach constraint the packet's own text supports: the Configuration utility answers only on the management network, with access via self IP addresses removed. This is also why the identity gaps recorded here are the right ones — the attacker never presents credentials, so no BIG-IP account is abused, no multi-factor prompt is ever raised, and an attestation that every administrator authenticates with unique, strongly-authenticated accounts passes cleanly while the path stays open. Precondition: the self-IP restriction removes one of the two named reach paths and not the other. An attacker with a foothold on the management segment, or on an administrator workstation inside it, satisfies the packet's stated access requirement in full, and the restriction is unavailable in deployments that must expose the utility on a self IP.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker smuggles a request to the internal AJP connector, bypassing Configuration-utility authentication and reaching endpoints that execute arbitrary system commands — typically chained with CVE-2023-46748 for the SQLi command primitive.' CWE-288 and CWE-306 are the recorded weaknesses. Vector names the reach paths as 'the management port and/or self IP addresses'. Citing gaps NIST-800-53-SC-7 (Boundary Protection), UK-CAF-B2 (Identity and access control) and NIST-800-53-IA-2 (Identification and Authentication) are recorded against this entry.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B2",
+          "NIST-800-53-IA-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's outcome is arbitrary system-command execution on the appliance by an unauthenticated attacker, with exploitation confirmed in the wild and a public PoC recorded — the exact conditions under which patch-in-place is the wrong default. Applying the fixed release and rebooting closes the smuggling path; it removes nothing an attacker ran through it beforehand, and on a BIG-IP that means the device's configuration and the credentials and keys stored on it are the exposure, not the vulnerable binary. For any BIG-IP whose Configuration utility was reachable from a position the operator cannot vouch for during the window that opened with the 2023-10-31 KEV listing, the runbook's default should be to treat the unit as attacker-held: capture and review its configuration, rebuild from a known-good baseline rather than upgrading in place, and rotate the credentials and certificates the device held. The packet's chained primitive (CVE-2023-46748) executes system commands through a path where the attacker never authenticates, so there is no failed-login or session artifact for an authentication-centric hunt to find, and a vulnerability-management control that closes on 'fixed release installed' records the device as remediated on exactly the evidence the attack does not produce. Precondition: this is an incident-response default, not a blanket instruction. It applies to units whose utility was reachable from an untrusted position during the exposure window; a unit that can be shown to have been unreachable from any untrusted segment for the whole window is a patch item. Where a rebuild genuinely cannot be absorbed by the service, the fallback is not patch-and-close — it is patch, rotate everything the device held, and carry the unit as an open triage item rather than a closed finding.",
+        "evidence": "Packet records active_exploitation 'confirmed', poc_available true, kev_date 2023-10-31, rwep_score 79. Vector states an attacker with network access can 'execute arbitrary system commands'; attack_vector states the attacker is unauthenticated and that the path is 'typically chained with CVE-2023-46748 for the SQLi command primitive'. live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' Citing gap ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) is recorded against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-5631": {
     "name": "Roundcube Webmail Persistent Cross-Site Scripting (XSS) Vulnerability",
@@ -51477,7 +53080,21 @@
         "adequate": false,
         "gap": "System-security controls do not constrain outbound requests the collaboration server is allowed to make, so the SSRF-driven internal scanning is not prevented by the existing boundary posture."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case the control exists for, because the two numbers on it point in opposite directions: CVSS 5.3 puts it in the band most vulnerability-management programs park on a routine medium-severity clock, while the packet records it KEV-listed 2023-10-10 with confirmed in-the-wild exploitation, a public PoC, and RWEP 66. For this CVE the control means the KEV listing sets the clock on every Skype for Business Server the organization runs, not the severity band — and the reason the band misleads is specific: the impact the 5.3 reflects is disclosure, but the packet describes an unauthenticated request forcing the server to make an outbound HTTP request that reveals internal IP and port information from the perimeter. That is reconnaissance feeding a later intrusion, not the end of one, and it is available continuously because the server is internet-facing by design.\n\nRemediation, per the packet: patch_available is true, live_patch_available is false, and the recorded note is that remediation requires applying the vendor fixed release. There is nothing to run in place while the change waits for the next server-maintenance window, so the interval between the KEV listing and the fixed release actually being applied is exposure rather than planning time.\n\nDistinguishing test: produce, per Skype for Business Server instance, the date the fixed release was applied measured against 2023-10-10 — not the date the finding was closed in the tracker. A program that triages by CVSS records this as within SLA on a medium-severity clock while a KEV-listed, actively exploited flaw stays live on an internet-facing server for the whole of that window, and the attestation reads clean throughout.\n\nPrecondition, and it is why this is a scheduling control rather than a closure: an expedited clock governs when the fix lands; it does not constrain what the server is permitted to request outbound, so for the whole pre-patch window the forced-request path stays fully open and no amount of prioritization narrows it. And because exploitation is confirmed and the flaw's output is internal topology rather than an artifact left on the host, applying the fixed release stops future probes but does not retract addressing and port information an attacker already collected — a server that was internet-reachable during the window should have that reconnaissance treated as attacker-held, rather than the entry being closed on the patch record.",
+        "evidence": "Packet facts only. CISA KEV-listed 2023-10-10; active_exploitation 'confirmed'; poc_available true; CVSS 5.3; RWEP 66; CWE-918; ai_discovered false. Vector: 'Skype for Business Elevation of Privilege Vulnerability'. Attack vector: 'An unauthenticated attacker sends a crafted request to an internet-facing Skype for Business Server that forces the server to make an outbound HTTP request, disclosing internal IP/port information and enabling internal-network reconnaissance from the perimeter.' patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-36563": {
     "name": "Microsoft WordPad Information Disclosure Vulnerability",
@@ -51762,7 +53379,39 @@
         "adequate": false,
         "gap": "Hardening guidance rarely covers CI/CD platforms; TeamCity admin APIs remained broadly reachable rather than restricted to trusted networks."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The packet puts the failure in a REST endpoint on the TeamCity server: an unauthenticated caller reaches it and mints an administrator access token, and from that moment on every action the attacker takes — altering build configuration, executing code on the server — is a properly authorized administrator API call that the product itself issued him the credential for. Bound to this product, the control means each administrative function on the TeamCity server authorizes its caller itself rather than inheriting a verdict from the REST layer that fronts it — token issuance first, then build-configuration and build-step modification — and that the server's REST and web surfaces answer only from segments with an actual build-system role rather than from any network that can route to them. This is why the identity-and-access-control gap is recorded against this entry rather than satisfied by it: the attacker never authenticates as any TeamCity user, so per-account privilege scoping and role assignment are never consulted, and the account model an identity attestation examines is bypassed rather than abused. The user-application-hardening gap misses it for a different reason — that control governs settings on workstation software and never examines a build server's API surface at all. Distinguishing test: from a segment with no developer, build-agent or integration role, issue unauthenticated requests to the TeamCity REST endpoints that create access tokens and modify build configuration on a staging server, and confirm each is refused before the function runs; an attestation that every TeamCity administrator authenticates at login and holds a minimally-scoped role passes cleanly while this path stays open. Precondition, and it is the half most often over-claimed: the endpoint-side authorization is a property the vendor fixed release establishes — this control states what to verify, it does not implement it. Until the server is on a release at or above 2023.05.4, restricting which segments can reach the REST surface bounds the population that can send the request but leaves the endpoint fully exploitable to anything inside a permitted segment, and it is simply unavailable where that surface must stay reachable, since serving developers, build agents and integrations is what a TeamCity server exists to do.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker abuses a REST-endpoint authentication bypass to mint an administrator access token, then uses privileged API access to alter build configuration and execute arbitrary code on the TeamCity server, pivoting into the software supply chain.' CWE-288 and CWE-306 (missing authentication for critical function). Packet vector names the fix boundary: 'In JetBrains TeamCity before 2023.05.4 authentication bypass leading to RCE on TeamCity Server was possible.' CISA KEV-listed 2023-10-04, active_exploitation confirmed, poc_available true, RWEP 72 against CVSS 9.8. Citing gaps on this entry include NIST-800-53-SC-7 (Boundary Protection), UK-CAF-B2 (Identity and access control) and AU-Essential-8-App-Hardening (User application hardening).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-SC-7",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive here does not end at code execution on one server: the packet has the attacker altering build configuration and pivoting into the software supply chain, so the exposed asset is every artifact that TeamCity builds and every credential it holds for the registries and deployment targets downstream of it. Treat the build configurations, build steps and artifact output directories as a privileged distribution channel rather than as application data — file-integrity-monitor them, alert on any change that does not correspond to a sanctioned commit or an operator change record, and inventory the access tokens the server has issued so that a token minted through the bypass can be found and revoked rather than surviving as a valid administrator credential. This is the control that still has value after the fixed release lands, because the upgrade closes the authentication bypass and removes nothing that was already written through it: an injected build step, an attacker-created administrator token, and an artifact already published to a downstream consumer all survive the upgrade untouched. None of them will surface in authentication logging either, because from the moment the token was minted every request was properly authorized, and no signature-based tooling has anything to match against a build step that is simply an extra command in a legitimate pipeline. Distinguishing test: introduce an out-of-band change to a build step on a staging TeamCity server and confirm it raises an alert with no corresponding change record. Precondition: this is detection and containment, not remediation — it does not close the bypass, and it only reaches configuration and artifact paths that were being baselined before the exposure window opened; a baseline captured after the fact records the attacker's state as normal. An estate that closes this CVE when every server reports 2023.05.4 or later has established that the door is shut, not that nobody came through it during the window that the packet's confirmed in-the-wild exploitation implies.",
+        "evidence": "Packet attack_vector states the outcome reaches beyond the host: the attacker 'uses privileged API access to alter build configuration and execute arbitrary code on the TeamCity server, pivoting into the software supply chain.' active_exploitation confirmed and poc_available true, so exploitation during the exposure window is the packet's stated condition rather than a hypothetical. live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release', so the only recorded remediation is a version change, which acts on the code path and not on state an attacker has already written. Citing gap ISO-27001-2022-A.8.8 (Management of technical vulnerabilities).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the KEV clock opened 2023-10-04 and the packet records exactly one remediation: moving the TeamCity server to the vendor fixed release, which its own vector places at 2023.05.4 or later. There is no live-patch mechanism registered and the packet names no vendor mitigation rule, so nothing else exists to deploy inside the window — the upgrade is not the preferred option among several, it is the only one. Completion therefore has to be measured as each TeamCity server reporting a version at or above 2023.05.4, not as the upgrade being approved, scheduled or downloaded, because a build server is precisely the asset whose maintenance window gets deferred to avoid interrupting in-flight pipelines, and that deferral recorded as 'remediation in progress' is how this specific flaw stays live. The packet's numbers argue against the deferral: a public PoC, confirmed in-the-wild exploitation, and an RWEP of 72 against a CVSS of 9.8 describe a flaw whose exploitation cost is already paid by someone else. Priority ordering follows reachability rather than server size, since the packet makes an unauthenticated network request the only precondition — the attacker holds no credential, so any TeamCity server a hostile caller can route to is in scope and a lightly-used one is no safer than the flagship instance. Precondition on the interim: until a server takes the upgrade, restricting who can reach its REST surface bounds the attempt but does not close it, and offers nothing on a server that must remain reachable to its agents and developers.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-10-04, active_exploitation confirmed, poc_available true, rwep_score 72, cvss 9.8. patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' Fixed-version boundary from the packet vector: 'In JetBrains TeamCity before 2023.05.4.' Packet attack_vector establishes the no-credential precondition: 'An unauthenticated attacker abuses a REST-endpoint authentication bypass...' Citing gaps NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-handling.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2023-28229": {
     "name": "Microsoft Windows CNG Key Isolation Service Privilege Escalation Vulnerability (CVE-2023-28229)",
@@ -51819,7 +53468,23 @@
         "adequate": false,
         "gap": "Patch-application timeframes for endpoint OS updates commonly exceed the window in which a public PoC enables reliable local escalation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet's path is a low-privileged local process making racing concurrent RPC calls to the CNG Key Isolation service inside lsass.exe, where flawed critical-section handling of reference counters produces a use-after-free that yields limited SYSTEM privileges. Everything the attacker needs is the ability to run code as an ordinary user on the machine, so the population to drive first is the one where that is the normal operating state rather than an anomaly — multi-user session hosts, shared and kiosk workstations, jump hosts, any machine where non-administrative interactive users are expected. For this CVE the control means the Windows update carrying the fix is driven across that population on the clock that opened with the 2023-10-04 KEV listing rather than folded into the next monthly rollup, with completion measured per host as the running build against the fixed build for its SKU rather than as 'approved', 'downloaded' or 'installed' in the management console. The packet records no live-patch mechanism and states remediation requires applying the fixed release and rebooting, so a host that has taken the update and deferred the restart is still running the vulnerable lsass.exe and must be counted exposed — and on a shared session host that restart is the step most likely to be deferred, because taking it evicts logged-on users, which is exactly how this remediation is misreported as complete. The control's second half is the load-bearing one here: the attacker is already an authorized low-privilege user, so tightening account privilege does not contain the escalation, which is why the least-privilege gap cited on this entry can attest cleanly while the flaw stays fully exploitable. Precondition, stated plainly because there is no compensating control to offer in its place: before the fixed build lands there is no operator-side lever that removes this path. The packet's only access requirement is a low-privileged local process, which every interactive user of the host satisfies; restricting who may log on bounds the population that can attempt the race but does not close it for anyone holding a legitimate session, and nothing in the packet describes a configuration, feature toggle or service state that takes the CNG Key Isolation RPC interface out of reach. Priority follows the packet rather than the 7.0 CVSS: a public PoC, confirmed in-the-wild exploitation and RWEP 75 make this the second stage of a chain — the step that converts a foothold into SYSTEM — not a standalone endpoint item to be deprioritized behind remote CVEs.",
+        "evidence": "Packet attack vector: 'A low-privileged local process makes racing concurrent RPC calls to the CNG Key Isolation service in lsass.exe; flawed critical-section handling of reference counters produces a use-after-free the attacker leverages to gain limited SYSTEM privileges.' CWE-591. CISA KEV-listed 2023-10-04, active_exploitation 'confirmed', poc_available true, CVSS 7.0, RWEP 75. patch_available true; live_patch_available false, with the packet's note stating there is no vendor live-patch mechanism and that remediation requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-4211": {
     "name": "Arm Mali GPU Kernel Driver Use-After-Free Vulnerability",
@@ -52780,7 +54445,28 @@
         "adequate": false,
         "gap": "Identity and access control expects strong authentication yet does not compel the tunnel-group hardening (no-MFA default group disabled, rate-limiting) needed to stop credential brute forcing on the appliance."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "ASA and FTD are the perimeter's remote-access authentication enforcement point, and the packet places this defect inside that enforcement rather than around it: AAA is not properly separated between the RA VPN feature and the HTTPS-management and site-to-site VPN features, so specifying a default connection profile/tunnel group lets an unauthenticated attacker run credential guessing directly against the gateway, and on ASA 9.16 and earlier lets a clientless SSL VPN session be established with an unauthorized user. Be precise about which half is which, because the packet is: it states the flaw does not allow bypassing authentication, and that valid credentials — including a valid second factor where MFA is configured — are still required to establish a remote-access VPN session. The expedited clock is therefore warranted not by a full authentication bypass but by what the gateway gives an unauthenticated attacker for free, which is unlimited credential discovery against the enforcement point itself, plus the authorization failure on 9.16 and earlier.\n\nFor this CVE the clock runs from the 2023-09-13 KEV listing through the reload of every affected ASA and FTD unit. The packet records patch_available true, live_patch_available false, and remediation as applying the fixed release and rebooting — so a unit that has taken the release but has not been reloaded still runs the vulnerable code and must be counted as exposed, not as patched. On a production VPN concentrator that reload is the step most likely to be deferred, because taking it drops live tunnels, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Enumerate units on ASA 9.16 or earlier first: those carry the clientless-session path on top of the credential-discovery path.\n\nDistinguishing test: report, per ASA and FTD unit, the software version the device is actually running and the timestamp of its last reload, rather than the version staged from the management console — a fleet where the console shows the fixed release pushed everywhere passes a patch attestation while unreloaded devices keep serving the vulnerable code.\n\nPrecondition on interim exposure, which is where this is normally over-claimed: the packet's stated exploitation requirement is reaching a default connection profile/tunnel group on the RA VPN feature. Restricting who can reach that profile bounds the population that can attempt it, but a remote-access VPN exists to answer from untrusted networks, so on any gateway serving general remote access there is no source restriction that removes the path — only the fixed release and the reload do. Interim measures narrow the attempt rate; they do not close it.\n\nAnd what the reload does not do: the flaw's product is valid username and password combinations identified by brute force, and the packet records Akira ransomware using this for initial access. Credentials harvested during the exposure window remain valid after the fixed release is applied — the update repairs the AAA separation, it does not invalidate what was already taken — so a gateway whose RA VPN was reachable during the window needs those accounts rotated and established sessions reviewed, not closed on the patch record.",
+        "evidence": "Packet facts only. CISA KEV-listed 2023-09-13; active_exploitation 'confirmed'; CVSS 9.1; RWEP 62; poc_available false; CWE-288 and CWE-863; ai_discovered false. Vector: the RA VPN feature of Cisco ASA and FTD 'could allow an unauthenticated, remote attacker to conduct a brute force attack in an attempt to identify valid username and password combinations or an authenticated, remote attacker to establish a clientless SSL VPN session with an unauthorized user'; 'due to improper separation of authentication, authorization, and accounting (AAA) between the remote access VPN feature and the HTTPS management and site-to-site VPN features'; exploited 'by specifying a default connection profile/tunnel group'; clientless SSL VPN session 'only when running Cisco ASA Software Release 9.16 or earlier'; and the packet's own notes that 'This vulnerability does not allow an attacker to bypass authentication. To successfully establish a remote access VPN session, valid credentials are required, including a valid second factor if multi-factor authentication (MFA) is configured.' Attack vector records 'Akira ransomware used this for initial access'. patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "ASA and FTD are perimeter firewalls, and for this CVE the gateway is also the only place the attack is visible before it succeeds. The packet gives the exploitation shape precisely enough to key on: an unauthenticated attacker specifies a default connection profile/tunnel group and conducts a brute-force attack to identify valid username and password combinations, then uses those credentials to establish a remote-access VPN session. The successful login is not the signal — the packet states the flaw does not bypass authentication and that valid credentials are required, so that session looks exactly like a legitimate one on the wire and in the logs. The distinguishing signal is the failed-authentication volume against the default connection profile on the RA VPN feature immediately preceding it, from a source that then authenticates successfully. That correlation — burst of failed RA VPN authentications against a default tunnel group, followed by a successful RA VPN authentication for one of the guessed accounts — is what the rule keys on.\n\nApplied to this device, the control means the gateway's authentication logs, not only its traffic and threat logs, are forwarded to a SIEM in a separate trust zone: the correlation is over time and across attempts and across units, which is not something a single appliance's local view supports, and the appliance is itself the asset under attack rather than a sensor watching one.\n\nAsk what an exploit doing exactly what the packet describes emits, because it is very little: no malware, no file write, no process crash, no exploit tooling on any host — only VPN authentication records on the gateway, then a valid VPN session. A rule keyed on endpoint telemetry, malware signatures, or appliance instability sees none of it, and an authentication-monitoring posture that only counts successes sees the intrusion but not the attack that produced it.\n\nPreconditions, and they are why this is a compensating measure rather than a fix. The logs must already be shipping and the volume rule must already exist — telemetry configured after the intrusion produces nothing, and on a perimeter gateway authentication-log forwarding is exactly what is most often left at defaults. Detection does not prevent the brute force from succeeding; it bounds the exposure to alert-and-response time during the window before the fixed release and the reload land, and it supplies the account list to rotate afterwards. It also does not cover the clientless SSL VPN path the packet attributes to ASA 9.16 and earlier, where a session is established with an unauthorized user using valid credentials — no failed-attempt burst necessarily precedes that, so this rule would not distinguish it from a normal session.",
+        "evidence": "Packet facts only. Vector and attack_vector state that an unauthenticated remote attacker can 'conduct a brute force attack in an attempt to identify valid username and password combinations' by 'specifying a default connection profile/tunnel group', that the identified credentials 'could then be used to establish an unauthorized remote access VPN session', and that on ASA Software Release 9.16 or earlier a clientless SSL VPN session can be established with an unauthorized user 'using valid credentials'; the packet's notes state the flaw 'does not allow an attacker to bypass authentication' and that valid credentials remain required. CISA KEV-listed 2023-09-13 with active_exploitation 'confirmed'; the attack_vector records Akira ransomware using this for initial access. patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2023-4863": {
     "name": "Google Chromium WebP Heap-Based Buffer Overflow Vulnerability",
@@ -53286,7 +54972,30 @@
         "adequate": false,
         "gap": "Periodic technical-vulnerability management does not compel the input-validation review of the WP_Query surface that would prevent untrusted data reaching author__not_in in the first place."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "WP_Query is WordPress core's query builder, and the packet places the defect inside it: core mishandles the author__not_in parameter, so SQL injection follows whenever untrusted input reaches that parameter. That is the exact shape this control governs — parameterization has to be verified where the query is built, not inferred from a plugin's input filtering or from a perimeter WAF sitting in front of the site, because every caller of WP_Query inherits whatever the builder does with the parameter. The reachability detail in the packet is what makes the verification non-obvious and is the reason a review can wrongly clear this: the parameter is reachable unauthenticated only when chained with CVE-2026-63030's REST batch-route desynchronization, so an assessment that exercises only authenticated code paths concludes the parameter is not attacker-reachable and the injection unexploitable, while the wp2shell chain reaches it on a default install. Distinguishing test: on a staging install, pass SQL metacharacters through author__not_in — both directly and through the REST route the chain desynchronizes — and confirm the query builder parameterizes rather than concatenates. Precondition: the parameterization repair is what the vendor releases ship; this control is the standing verification requirement and gives nothing on its own to a site still on a pre-fix build, and it does not address a site already exploited through the chain.",
+        "evidence": "Packet vector: 'WordPress Core mishandles the author__not_in parameter of WP_Query, allowing SQL injection when untrusted input reaches the parameter; chained with CVE-2026-63030 for unauthenticated remote code execution.' Attack vector: reachable unauthenticated 'only when chained with CVE-2026-63030's REST batch-route desynchronization', forming 'the data-access half of the wp2shell pre-auth RCE chain against default WordPress installs'. CWE-89; poc_available true; active_exploitation confirmed. Citing gap UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case a severity-banded patch policy handles worst. CVSS 5.9 routes it into a low or medium queue with a 30-to-90-day window under the flaw-remediation and technical-vulnerability controls cited here, while the packet records CISA KEV listing on 2026-07-21, confirmed in-the-wild exploitation, a public PoC, RWEP 78, and a role as the data-access half of a pre-auth RCE chain against default installs. The control's requirement bound to this CVE is that the clock runs from the KEV listing and the target is the core version the packet names — 6.8.6, 6.9.5 or 7.0.2 — with the CVSS band explicitly not used to defer. The packet records WordPress.org enabling forced automatic security updates, which shortens the window wherever that channel is active, but a delivery mechanism is not a completion record: the evidence an operator can defend is the core version each site actually reports, per site, not the assumption that a push landed everywhere. That distinction is the whole gap here, because a vulnerability-management programme that closes this item on 'WordPress pushed the fix' has recorded a vendor action rather than a state of its own estate. Precondition: the packet records no live-patch mechanism, so the upgrade itself is the only remediation; and because exploitation is confirmed and the chain ends in remote code execution, a site that was internet-reachable between the listing and its own upgrade needs to be examined rather than closed on the version number.",
+        "evidence": "CISA KEV listed 2026-07-21; active_exploitation confirmed; poc_available true; RWEP 78 against CVSS 5.9; patch_available true; live_patch_available false; live_patch_notes: 'No live-patch mechanism; WordPress.org enabled forced automatic security updates. Remediation is upgrading to 6.8.6 / 6.9.5 / 7.0.2.' Citing gaps AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, NIS2-Art21-vulnerability-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2026-63030": {
     "name": "WordPress Core Interpretation Conflict Vulnerability",
@@ -54179,7 +55888,33 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would flag CVE-2023-24489 only once tracked as KEV; the low-key May release meant many asset owners had no ticket until August, so the padding-oracle-to-web-shell chain stayed live on unpatched controllers."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation path does not end at code execution, it ends at a file on disk: an unauthenticated attacker exploits the AES-CBC padding oracle in the StorageZones Controller, forges valid-padding encrypted parameters, chains a path traversal, and uploads an .aspx web shell into the IIS webroot via /documentum/upload.aspx. The remediation the packet records — upgrading the ShareFile StorageZones Controller to 5.11.24 or later and recycling the IIS application pool — replaces product code and restarts the worker process. Neither step deletes an .aspx file an attacker already wrote into the webroot, and neither invalidates any credential the application-pool identity holds, so the upgraded controller keeps serving the shell through the patched application. Applied to this product the requirement is that any customer-managed StorageZones Controller reachable during the exposure window is handled as compromised rather than as patched: export and preserve its configuration, rebuild the host at the fixed build from a known-good image instead of upgrading in place, rotate the credentials the controller's service identity holds, and enumerate the IIS webroot and the directories it serves against a known-good installation for .aspx files that are not part of the product. Distinguishing test: on a controller that has already been upgraded, list the webroot's .aspx files and account for each one — an attestation that every StorageZones Controller reports 5.11.24 or later passes cleanly with a web shell dropped before the upgrade still present. Precondition, and this is where the control gets over-claimed: it is an incident-response default, not a preventive measure. It does nothing for a controller still running a vulnerable build, since only the upgrade closes the padding oracle, and a rebuild helps only if the restore point predates the exposure window — where the stored content forces a later restore point, the artifact hunt above is the remaining lever, not the rebuild.",
+        "evidence": "Packet attack_vector: 'Unauthenticated attacker exploits an unauthenticated-AES-CBC padding oracle in the StorageZones Controller, forges valid-padding encrypted parameters, and chains a path traversal to upload an .aspx web shell to the IIS webroot via /documentum/upload.aspx, achieving remote code execution.' Packet live_patch_notes: 'No live-patch mechanism; remediation is upgrading the ShareFile StorageZones Controller to version 5.11.24 or later and recycling the IIS application pool.' patch_available true, live_patch_available false. Vector: 'A vulnerability has been discovered in the customer-managed ShareFile storage zones controller which, if exploited, could allow an unauthenticated attacker to remotely compromise the customer-managed ShareFile storage zones controller.' cisa_kev true, kev_date 2023-08-16, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 74, cwe_refs CWE-284. Citing gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 Management of technical vulnerabilities, NIST-800-53-SI-2 Flaw Remediation and NIS2-Art21-patch-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's vector names the customer-managed ShareFile storage zones controller, which is the fact that decides who owns the clock: none of this fix arrives through the vendor's cloud service, so the operator takes the upgrade to 5.11.24 or later and the IIS application-pool recycle themselves, on every controller they run, and the packet records no live-patch path that would let them defer the restart. Applied to this CVE the control means that clock runs from the 2023-08-16 KEV listing rather than from the next scheduled application-patch window: the flaw needs no credential, the PoC is public, exploitation is confirmed, and /documentum/upload.aspx answers an unauthenticated request, so a controller left on a vulnerable build across even a standard two-week application SLA is exposed for the whole window with no authentication step in front of it. The control's 'whichever is later' clause is the part that matters on this entry — the vendor's fixed build and the KEV listing are separate events, and an SLA keyed only to a vendor release starts counting from a build an operator may never have registered as security-relevant, whereas the KEV date is an unambiguous trigger. Distinguishing test: produce, per controller, the installed StorageZones Controller version and the timestamp of the application-pool recycle that followed it, measured against 2023-08-16. A patch report showing the fixed build with no recorded recycle does not demonstrate that the patched code is the code running, because the packet makes the recycle part of the remediation and offers no live-patch alternative. Precondition: meeting this SLA closes the exploit path forward only. It says nothing about a controller that was already reached during the window, which is the separate incident-response requirement recorded against this entry.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-08-16, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 74. patch_available true, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation is upgrading the ShareFile StorageZones Controller to version 5.11.24 or later and recycling the IIS application pool.' Vector: 'A vulnerability has been discovered in the customer-managed ShareFile storage zones controller which, if exploited, could allow an unauthenticated attacker to remotely compromise the customer-managed ShareFile storage zones controller.' attack_vector places the unauthenticated upload at '/documentum/upload.aspx'. Citing gaps include AU-Essential-8-Patch (ASD Essential Eight), NIS2-Art21-patch-management, NIST-800-53-SI-2 Flaw Remediation and UK-CAF-B4 System security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-38180": {
     "name": "Microsoft .NET Core and Visual Studio Denial-of-Service Vulnerability",
@@ -56114,7 +57849,38 @@
         "adequate": false,
         "gap": "A.8.8 would rank CVE-2023-32439 critical once KEV-listed, yet technical-vulnerability management is reactive here — the exploit predates the advisory, so only prompt Rapid Security Response deployment closes the WebKit RCE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet's fixed builds span two iOS majors and two platforms at once — iOS 16.5.1 and iPadOS 16.5.1, iOS 15.7.7 and iPadOS 15.7.7, macOS Ventura 13.4.1, and Safari 16.5.1 — so 'the estate is current' is not a statement about this CVE. A device held on the 15.x branch needs 15.7.7 specifically, and a Mac not moving to Ventura 13.4.1 needs the standalone Safari 16.5.1 as its own item. Applied here, the control means the management platform pushes and enforces each of those builds against the population it applies to, on a clock tied to the 2023-06-23 KEV listing rather than a monthly ring, with user deferral disallowed — because the packet records the fix as arriving in an OS/Safari update (or Rapid Security Response) that requires a device restart to apply, and the restart is the step a user postpones indefinitely on a phone they are carrying. Completion is measured as the restarted build the device reports, not as a profile marked installed or an update marked downloaded. This cannot be folded into an ordinary application-update policy for one browser: the defect is in WebKit, and the packet's attack vector names Safari or any WebKit-based HTML parser as the trigger, so on these platforms every app that renders web content is a delivery path and the OS update is the only action that reaches all of them together. Precondition: this reaches only enrolled devices. A personally-owned or unenrolled iPhone, iPad or Mac rendering the same WebKit content is untouched by the policy, and for that population this control delivers nothing — closing that half needs an access condition, not an update push.",
+        "evidence": "Packet entry 'Apple Multiple Products WebKit Type Confusion Vulnerability (CVE-2023-32439)' (CWE-843), cisa_kev true with kev_date 2023-06-23 and active_exploitation 'confirmed'; cvss 8.8, rwep_score 52, poc_available false. Vector: 'This issue is fixed in iOS 16.5.1 and iPadOS 16.5.1, iOS 15.7.7 and iPadOS 15.7.7, macOS Ventura 13.4.1, Safari 16.5.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.' attack_vector names 'Safari (or any WebKit-based HTML parser)'. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch mechanism; Apple ships the fix in an OS/Safari update (or Rapid Security Response) that requires a device restart to apply.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The population that stays exposed after the push is the one the push cannot reach or the user keeps deferring, and this packet's fix list makes that population concrete: devices sitting on the iOS/iPadOS 15.7.7 branch are typically there because they cannot take 16.5.1, and macOS hosts that will not move to Ventura 13.4.1 need Safari 16.5.1 tracked separately. The requirement here is that the fixed build works as an access condition rather than a dashboard row — a device below iOS/iPadOS 16.5.1 or 15.7.7, or a Mac below macOS Ventura 13.4.1 that has not taken Safari 16.5.1, is denied mail, VPN and document access until it reports at or above the fix. The distinguishing test is to enrol a device pinned below those builds and confirm the policy actually refuses 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 rather than removed it. Because the packet records the fix as requiring a device restart, a device that has downloaded the update but not restarted must be treated by the policy as below the build, not above it. Scope it to what the packet names — iOS, iPadOS, macOS and Safari. The fixed-version list is Apple's, and the packet gives no basis for treating non-Apple browsers in the estate as instances of this CVE. Precondition: an access condition bounds what a device can reach next, it does not protect the device itself. The trigger is processing maliciously crafted web content leading to arbitrary code execution in the renderer, so a device that already rendered the attacker's page is compromised whether or not it holds corporate data, and it belongs on the incident path rather than the enrolment path.",
+        "evidence": "Packet vector lists the fixed builds as iOS 16.5.1 and iPadOS 16.5.1, iOS 15.7.7 and iPadOS 15.7.7, macOS Ventura 13.4.1, Safari 16.5.1, and states 'Processing maliciously crafted web content may lead to arbitrary code execution.' live_patch_available false with live_patch_notes recording that the fix ships in an OS/Safari update (or Rapid Security Response) 'that requires a device restart to apply'. active_exploitation 'confirmed'; citing gap ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) is recorded against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet records confirmed exploitation with no public PoC, and describes the bug as a stage in a browser-based exploit chain — code execution in the renderer that a following stage has to escalate. That combination points at limited, targeted use rather than commodity mass exploitation, and for the cohort plausibly inside that targeting set the reboot-gated OS update is not fast enough on its own: the window between the 2023-06-23 KEV listing and a completed restart across the fleet is exactly when such a chain is worth spending. The requirement is that those users are already in the platform's reduced-attack-surface mode — untrusted web content not taken through the full WebKit path, message-borne content and link previews not rendered automatically — assigned before the next disclosure rather than switched on in response to this one, because the mode only helps if it was already active when the page was served. Precondition, and it is why this is never a substitute for the update: the mode narrows the delivery path into the WebKit parser, it does not repair the type confusion, and it does nothing for a device that has already processed the attacker's content. It applies only to the cohort it is assigned to and only where the platform offers it, so the rest of the estate stays on the update-and-restart path, which the packet records as the only remediation with no live-patch mechanism available.",
+        "evidence": "Packet attack_vector: 'A type-confusion bug in WebKit is triggered when Safari (or any WebKit-based HTML parser) processes maliciously crafted web content, corrupting object typing to achieve arbitrary code execution in the renderer as a stage in a browser-based exploit chain.' active_exploitation 'confirmed' with poc_available false; kev_date 2023-06-23. Vector: 'Apple is aware of a report that this issue may have been actively exploited.' live_patch_available false; live_patch_notes: 'No live-patch mechanism; Apple ships the fix in an OS/Safari update (or Rapid Security Response) that requires a device restart to apply.' Citing gap UK-CAF-B4 (System security) is recorded against this entry.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-20867": {
     "name": "VMware Tools Authentication Bypass Vulnerability",
@@ -56480,7 +58246,38 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management should have flagged the Roundcube advisory, but organisations running webmail as a secondary service frequently omit it from the asset/patch register, so CVE-2021-44026 stayed open on exactly the mail servers APT28 targeted."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "The packet puts the defect exactly where this control requires verification: crafted values submitted in Roundcube's mail search and search_params are concatenated into a SQL query without proper escaping. The property to establish is therefore at the layer that builds the search query — the search terms bound as parameters rather than interpolated into the statement — and it must be established by reading that layer's behaviour, not inferred from an input filter in front of it or from a WAF on the webmail host. That substitution is the specific failure the CAF B4 citation on this entry describes: securely configuring the host, its TLS and its service accounts leaves the injection reachable, because the malformed value is carried inside a request the application is supposed to accept. Remediation per the packet is upgrading Roundcube Webmail to 1.3.17 or 1.4.12 or later, and the packet records this as an application update with no host reboot required — so on this entry the reason a KEV item usually slips its window, a reboot that has to be scheduled against a mail outage, does not apply. Distinguishing test, run against the version actually in service rather than the version on the asset register: submit a search request whose search / search_params values carry SQL metacharacters to a staging instance and confirm the query layer binds them as values instead of concatenating them into the statement. An instance sitting behind a rule that blocks the obvious payload shapes still concatenates, and the next encoding the rule does not match reaches the same sink. Preconditions: parameterization is a property of the shipped code, so the upgrade is what establishes it — this control is the verification and the gate, and it gives nothing on its own to an instance that has not been upgraded. A WAF rule on the search endpoint is a holding measure bounded to the request shapes it recognizes and to traffic that traverses it, and it does nothing for a request reaching the application by another route. Neither the upgrade nor the rule undoes a read that already happened: the packet has the injection reading the webmail database including mail, contacts and credentials, and those credentials stay valid on every service they were reused against until they are rotated.",
+        "evidence": "Packet attack_vector: 'An attacker submits crafted values in Roundcube's mail search / search_params, which are concatenated into a SQL query without proper escaping, allowing injection that reads or manipulates the webmail database (mail, contacts, credentials).' CWE-89; CVSS 9.8; RWEP 66; poc_available true; active_exploitation confirmed; CISA KEV 2023-06-22. Packet live_patch_notes: 'No live-patch mechanism; remediation is upgrading Roundcube Webmail to 1.3.17 or 1.4.12 (or later), an application update with no host reboot required.' The repo lesson entry's framework_coverage for UK-CAF-B4 records that 'CAF B4 secure-configuration would not stop a code-level SQLi in Roundcube's search: the injection is in the application's query construction, so hardening the host or TLS does nothing against the malformed _search/search_params input.'",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "The requirement this control carries is webmail request-level telemetry rather than authentication telemetry, and Roundcube's search flow is where it has to be applied for this CVE. The packet's exploitation is a crafted search request: the attacker's content sits in the search / search_params values of a request the webmail application is built to serve, so nothing appears in the authentication record — no failed login, no privilege change, no new session anomaly — and the lesson records that the campaign reached the search flow through legitimate sessions. What must be forwarded off the webmail host, to a collector the webmail service cannot write to, is the per-request web-tier access record including the search parameter values, together with query-level logging from the Roundcube database, retained long enough to cover the interval between exposure and discovery rather than the days a default web-server log rotation keeps. Detection keys on what the packet documents and nothing else: search requests whose parameter values carry SQL syntax, and queries against the mail store whose scope exceeds the requesting session's own mailbox. Both halves matter — SQL-shaped text in a search box can be a user typing a quotation mark, and a broad query can be a maintenance job; it is the pairing inside one session that distinguishes the exploit. Note what will not see it: no file is written, no process is spawned, no authentication fails, and a successful injection returns an ordinary response — so file-integrity monitoring, endpoint anti-malware and failed-login alerting have no artifact to match, and a rule keyed on server errors would miss a read that succeeds. This closes the incident-handling gap directly, because the notification clock starts at awareness and a quiet database read produces no awareness at all. Preconditions: the telemetry has to be collected and shipped off-host before the attempt — a query written afterwards against logs nobody retained produces nothing, and self-hosted webmail is exactly where request-level logging is least often exported. And this detects; it does not prevent. Mail and contacts read during the window stay read, and credentials the packet places in that database stay usable until they are rotated.",
+        "evidence": "Packet attack_vector: the attacker 'submits crafted values in Roundcube's mail search / search_params', and the injection 'reads or manipulates the webmail database (mail, contacts, credentials)'. CISA KEV 2023-06-22; active_exploitation confirmed; poc_available true. The repo lesson entry records privileges_required as 'none per CVSS scoring (PR:N)' while noting the operators reached the search flow through spearphishing-driven sessions; its defense_chain detection section names 'Query-level logging/alerting on the Roundcube database and web-tier detection of SQL fragments in _search/search_params' as what would have worked, with the adequacy note that 'Detection is what most ... victims lacked, letting the espionage read go unnoticed', and its framework_coverage for NIS2-Art21-incident-handling records that 'a successful SQLi read of the Roundcube mail store is quiet exfiltration; without query-level logging on the webmail DB ... leaves little trace to trigger the incident process.'",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the KEV clock is both the cheapest control to satisfy and the one the estate most often fails, and the packet says why in its own remediation note. The fix is an application upgrade to 1.3.17 or 1.4.12 or later with no host reboot required, so the mitigation this control demands within the KEV window is an in-place application update on an internet-facing service — not a firmware cycle, not a maintenance window negotiated against a mail outage. That removes the usual justification for a 30-day interpretation of 'appropriate timescales', which is the undefined interval the ISO A.8.8 citation on this entry rests on, and it is why a 4-hour-class response is realistic here rather than aspirational. The Essential Eight patch citation fails for a different reason worth stating separately: Roundcube is an application running on the host, frequently maintained outside whatever pipeline pushes operating-system updates, so an attestation that measures OS patch level reads clean on a host whose webmail has been years behind since the fix shipped. Verified mitigation means the version read from the running instance is at or above 1.3.17 on the 1.3 branch or 1.4.12 on the 1.4 branch, or a later release — read from the instance, not from an inventory record, because the register omission is the documented failure mode for this class of asset. Precondition: reaching the minimum build named in the packet closes this defect only and says nothing about anything found in Roundcube since, so the requirement is a current supported release rather than the floor, and a site that was exposed while unpatched still needs its stored mail credentials rotated — the clock governs how fast the injection path closes, not what was read through it.",
+        "evidence": "Packet: CISA KEV listing 2023-06-22; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 66; patch_available true; live_patch_available false. Packet live_patch_notes: 'No live-patch mechanism; remediation is upgrading Roundcube Webmail to 1.3.17 or 1.4.12 (or later), an application update with no host reboot required.' The repo lesson entry's framework_coverage records for ISO-27001-2022-A.8.8 that 'organisations running webmail as a secondary service frequently omit it from the asset/patch register', and for AU-Essential-8-Patch that 'Essential 8 patch cadence targets vendor-supplied fixes, but internet-facing webmail is often community-maintained and slips patch windows'; its defense_chain prevention adequacy note records that 'the recurring failure was operational — webmail left off the patch inventory.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2016-9079": {
     "name": "Mozilla Firefox, Firefox ESR, and Thunderbird Use-After-Free Vulnerability",
@@ -56663,7 +58460,43 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management often under-inventories network appliances versus servers, so a vulnerable FortiGate can miss the remediation cycle even after FG-IR-23-097 and KEV listing."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The packet puts the defect in the FortiOS/FortiProxy SSL-VPN web interface and reaches it with a crafted pre-authentication request that overflows a heap buffer for code execution on the appliance with no credentials — the device terminating remote access is itself the vulnerable software, which is why an ordinary network-device patch window is the wrong tier for it. Bound to this CVE, the tier means the clock runs from the 2023-06-13 KEV listing to the completed reboot of every FortiGate and FortiProxy unit whose running build falls inside the packet's affected list (FortiOS 7.2.4 and below, 7.0.11 and below, 6.4.12 and below, 6.0.16 and below; FortiProxy 7.2.3 and below, 7.0.9 and below, 2.0.12 and below, and 1.2 and 1.1 in all versions), with the only permitted alternative being isolation of the SSL-VPN interface rather than a later change window. Two packet facts make the standard window unusable here. First, the fix is a build upgrade that reboots the appliance and there is no live-patch mechanism, so a unit with the image staged but the reboot deferred is still running the vulnerable code and must be counted exposed — on an edge appliance that reboot is precisely the step that gets deferred, because taking it drops every live VPN session, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Second, FortiProxy 1.2 and 1.1 are listed as affected in all versions, so for a unit on either train there is no fixed build to reach inside the train and remediation is a move to a train that has one — a distinction any compliance check that only asks 'is the build newer than the one installed' will not make. The distinguishing test: produce, per unit, the running build and the time of its last restart and show the build is outside the packet's affected list; a fleet report showing an approved or downloaded upgrade against a unit that has not restarted records an intention, not a remediation. Precondition on the isolation alternative: interface isolation is available only on a unit whose SSL-VPN is not carrying production remote access; where it is the organization's remote-access path, that lever does not exist and the reboot-bearing upgrade is the only remediation, taken early rather than at the next window. Priority follows the packet rather than the CVSS band — pre-authentication reach, a public PoC, and confirmed in-the-wild exploitation.",
+        "evidence": "Packet: CISA KEV-listed 2023-06-13, active_exploitation 'confirmed', poc_available true, CVSS 9.8, RWEP 79. Attack vector: a crafted pre-authentication request to the FortiOS/FortiProxy SSL-VPN web interface overflows a heap buffer (CWE-122, CWE-787), giving remote code execution on the appliance with no credentials. patch_available true; live_patch_available false, with the packet's live-patch note stating there is no live-patch mechanism for FortiOS and that remediation requires upgrading to a fixed FortiOS/FortiProxy build, which reboots the appliance. Affected list per the packet: FortiOS 7.2.4 and below, 7.0.11 and below, 6.4.12 and below, 6.0.16 and below; FortiProxy 7.2.3 and below, 7.0.9 and below, 2.0.12 and below, 1.2 all versions, 1.1 all versions.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "This entry has a configuration-side mitigation path that does not wait on the reboot-bearing upgrade — the packet names disabling SSL-VPN as the interim mitigation — and the control's requirement is that the path be inventoried and rehearsed before the disclosure rather than discovered during it. Applied to this fleet, that means knowing per unit whether SSL-VPN is carrying production remote access or is enabled-but-unused, because those two populations have entirely different options: the second can be taken out of reach in minutes with a configuration change and no restart, while the first cannot be touched without removing remote access and must go straight to the upgrade. An estate that cannot answer that question per unit spends the exposure window scheduling a maintenance slot for units that never needed one. The distinguishing test is behavioural, not a configuration read: after applying the change on a unit, confirm the SSL-VPN web interface no longer answers on the interfaces that previously served it — a checkbox in a saved configuration is not evidence that the pre-authentication listener is gone. Preconditions, both load-bearing and neither optional to state. This lever exists only where the SSL-VPN service is not the operational remote-access path; the packet's own framing is that it is an interim mitigation, not the remediation, and the remediation remains the fixed build and its reboot. And because the packet records exploitation confirmed in the wild from the 2023-06-13 KEV listing with a public PoC, disabling the service on a unit that was already exploited closes the entry path without removing anything the attacker left behind — such a unit belongs on the incident path, not the configuration path.",
+        "evidence": "Packet live-patch note, verbatim: 'No live-patch mechanism for FortiOS; remediation requires upgrading to a fixed FortiOS/FortiProxy build, which reboots the appliance. Disabling SSL-VPN removes the attack surface as an interim mitigation.' patch_available true, live_patch_available false. The packet locates the flaw in the SSL-VPN interface of FortiOS/FortiProxy and describes the triggering request as pre-authentication. CISA KEV-listed 2023-06-13, active_exploitation 'confirmed', poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives this entry both halves of the condition this control exists for: a pre-authentication remote-code-execution path on the appliance itself, and exploitation confirmed in the wild with a public PoC. The upgrade closes the heap overflow; it removes nothing an attacker placed on a unit that was exploited before the upgrade landed. So for any FortiGate or FortiProxy whose SSL-VPN interface was reachable during the exposure window that opened at the 2023-06-13 KEV listing, the default response is configuration extraction, rebuild from a known-good baseline on a fixed build, and rotation of the credentials the unit held — not patch-in-place followed by closing the ticket. Precondition, and it is the half most often skipped: this presumes the operator can determine whether a given unit was exploited, and the packet's own attack path makes that hard by construction — the request arrives before any credential check, so there is no failed or anomalous authentication event to find, and a unit whose only record of the window is its own local log cannot answer the question at all, because a successful exploit runs on the device holding that log. Where the evidence to exclude compromise does not exist, the default has to be rebuild rather than 'no evidence of compromise found'. The precondition also bounds the control honestly: rebuilding restores the device, it does not undo use already made of anything the unit stored, which is why the credential rotation is part of the same action rather than a follow-up item.",
+        "evidence": "Packet: active_exploitation 'confirmed', poc_available true, CISA KEV-listed 2023-06-13, RWEP 79, CVSS 9.8. Attack vector: a crafted pre-authentication request to the SSL-VPN web interface overflowing a heap buffer to gain remote code execution on the appliance with no credentials. patch_available true, live_patch_available false, with the packet stating remediation requires upgrading to a fixed FortiOS/FortiProxy build, which reboots the appliance.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-3079": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2023-3079)",
@@ -56724,7 +58557,21 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management scores by CVSS/priority, but an 8.8 rating understates a confirmed zero-day under active exploitation; teams deprioritising 'High (not Critical)' browser CVEs left the type-confusion exploitable while it was already being used."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The exploitation path here is a crafted HTML/JavaScript page — no install, no attachment, no privilege — so every managed workstation is exposed the moment a user browses, and the only variable an operator controls is which build the browser process is executing. Bound to this CVE, the control means the enterprise update ring carries Chrome to 114.0.5735.110 on Windows and 114.0.5735.106 on macOS/Linux without sitting in a pilot or staging tier: the packet records patch_available true but live_patch_available false, so there is no interim protected state and no vendor mitigation rule to run while a ring soaks — a machine is either on the fixed build or fully exposed to the page.\n\nThe second half is where this remediation is routinely recorded as complete while the estate stays exposed, and the packet states it outright: remediation is the auto-update 'followed by a browser restart to load the patched build'. The update lands on disk without the running process taking it, so a software inventory that reads the installed version reports the fixed build while every already-running browser keeps executing the vulnerable V8. The machines this misses are precisely the worst ones — the long-lived sessions that are never closed and never rebooted. Completion must therefore be measured on the build the live browser process reports, and the relaunch has to be forced by policy rather than left to a dismissible prompt.\n\nDistinguishing test: on a workstation that has been running since before the update, read the version the live browser process reports rather than the version on disk, and confirm it is at or above the fixed build. A fleet whose software inventory shows 114.0.5735.110 everywhere while running processes report a pre-fix build satisfies a patch-cadence attestation and still executes the crafted page.\n\nScope: the packet ties the type confusion to V8 in Chrome/Chromium and names no other product, so this covers the Chrome and Chromium installs in the estate. Extending it to other browsers or to embedded renderers would manufacture removal and update work against software no evidence in this packet implicates.\n\nWhat it does not do: forcing the relaunch closes this defect only. It does not reduce the renderer attack surface the page reaches, and the packet describes the heap corruption as being chained with a renderer sandbox escape — so a workstation that browsed untrusted content while below the fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet facts only. CISA KEV-listed 2023-06-07; active_exploitation 'confirmed'; poc_available true; CVSS 8.8; RWEP 66; ai_discovered false. Vector: 'Type confusion in V8 in Google Chrome prior to 114.0.5735.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)'. Attack vector: 'A crafted HTML/JavaScript page forces V8 to misinterpret an object's type, corrupting the heap into read/write primitives that, chained with a renderer sandbox escape, yield code execution.' patch_available true; live_patch_available false; live_patch_notes: 'No live-patch mechanism; remediation is Chrome/Chromium auto-update to 114.0.5735.110 (Windows) or 114.0.5735.106 (macOS/Linux) followed by a browser restart to load the patched build.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-33009": {
     "name": "Zyxel Multiple Firewalls Buffer Overflow Vulnerability (CVE-2023-33009)",
@@ -56980,7 +58827,32 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management prioritizes by score, but the EPSS ~0.999 preauth SQLi with confirmed ransomware use and supply-chain reach means only removing internet exposure of MOVEit before the fix could have helped; risk-rated scheduling was too slow for a zero-day mass-exploitation event."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The MOVEit Transfer web application answers unauthenticated callers over HTTP or HTTPS, and the packet's exploitation path does not stop at the SQL injection: the attacker writes the LEMURLOOT web shell (human2.aspx) into the application and uses it to enumerate and exfiltrate the files the transfer server holds together with its Azure storage keys. Bound to this product, the control means an instance that was network-reachable during the exploitation window is handled as a compromised host rather than as a patch ticket — hunt the web root for human2.aspx and any other file written through the injection, rebuild from a known-good baseline where one is found, and rotate everything the instance held or brokered: the Azure storage keys the packet names, the credentials the web application uses against its MySQL, Microsoft SQL Server or Azure SQL back end, and the accounts of counterparties whose files it stored. The packet's own remediation note states both halves in order — upgrade to a fixed release, hunt for the LEMURLOOT web shell, then restart the service — and it is the second half the cited flaw-remediation and technical-vulnerability-management controls do not carry: each of them closes when the installed version reaches the fixed build, so a server reporting a fixed release while human2.aspx still answers passes those attestations with the attacker's access intact. Distinguishing test: for each MOVEit Transfer instance produce the web-root file listing and its change history covering the exposure window and show no unaccounted .aspx file was written, instead of producing the upgrade record. Precondition, and this is where the control is usually over-claimed: it is a response requirement and removes nothing preventively — it does not close the injection, and it applies only to instances exposed before the fixed release landed. The packet places exploitation in May and June 2023, so an instance first stood up on a fixed release and never reachable before it is a patch case, not an incident case; conversely, an instance that took the upgrade without the hunt has not been cleared, because the fix removes the write path and not what was already written through it.",
+        "evidence": "Packet: an unauthenticated attacker sends crafted requests to the MOVEit Transfer web app to trigger SQL injection, then writes the LEMURLOOT (human2.aspx) web shell to enumerate and exfiltrate stored files and Azure storage keys; exploitation of unpatched systems can occur via HTTP or HTTPS; exploited in the wild in May and June 2023; depending on the database engine (MySQL, Microsoft SQL Server, or Azure SQL) an attacker may execute SQL statements that alter or delete database elements. cisa_kev true, kev_date 2023-06-02, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 76. patch_available true; live_patch_available false with live_patch_notes: no vendor live-patch mechanism, remediation requires upgrading MOVEit Transfer to a fixed release (2021.0.6 / 2021.1.4 / 2022.0.4 / 2022.1.5 / 2023.0.1 or later) and hunting for the LEMURLOOT web shell, then restarting the service.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "The defect the packet describes is SQL injection in the MOVEit Transfer web application reachable by an unauthenticated caller, with impact varying by the database engine behind it — the packet names MySQL, Microsoft SQL Server and Azure SQL — and extending past inference of structure and contents to executing SQL statements that alter or delete database elements. For a product the operator does not build, this control's requirement lands on what is accepted as evidence that the injection is closed: the parameterization must hold inside the shipped query layer, not in a filter placed in front of it. A WAF or request-inspection rule at the MOVEit boundary is therefore not a remediation state for this CVE and must not be recorded as one; the only state that closes it is the instance running one of the fixed releases the packet names — 2021.0.6, 2021.1.4, 2022.0.4, 2022.1.5 or 2023.0.1 or later — with the service restart the packet's remediation note requires, so an instance upgraded but not restarted is not yet remediated. Scope this to MOVEit Transfer, which is the product the packet names. The packet also states that all versions before those five are affected including older unsupported versions, naming 2020.0 and 2019x, so an instance on a branch with no fixed release in that list cannot reach a fixed build in place and has to be moved onto a supported branch — a migration decision that a patch ticket keyed to 'latest available for the installed branch' will never surface, and one that the cited flaw-remediation and system-security controls do not distinguish from routine patching. Precondition: reaching a fixed release closes this injection and says nothing about anything found in the product since, and it does not undo a database that was already read or altered through the injection during the exposure window — that remains an incident-response question, not a version question.",
+        "evidence": "Packet: a SQL injection vulnerability in the MOVEit Transfer web application could allow an unauthenticated attacker to gain access to MOVEit Transfer's database; depending on the database engine being used (MySQL, Microsoft SQL Server, or Azure SQL), an attacker may be able to infer information about the structure and contents of the database and execute SQL statements that alter or delete database elements; all versions before 2021.0.6, 2021.1.4, 2022.0.4, 2022.1.5 and 2023.0.1 are affected, including older unsupported versions (e.g. 2020.0 and 2019x); exploitation can occur via HTTP or HTTPS. patch_available true; live_patch_available false with live_patch_notes recording remediation as upgrading to a fixed release then restarting the service. CVSS 9.8, RWEP 76, poc_available true, active_exploitation confirmed, KEV-listed 2023-06-02.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-28771": {
     "name": "Zyxel Multiple Firewalls OS Command Injection Vulnerability",
@@ -57370,7 +59242,29 @@
         "adequate": false,
         "gap": "Network segregation (out-of-band management, VTY source ACLs) is the real mitigation; an organization relying on A.8.8-style patch tracking for a 2004 advisory on legacy IOS would not close the reachable Telnet management plane."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives two remediations for this router flaw with very different clocks, and the SLA has to name both. The fixed IOS train is the closure, but the packet records no live-patch path and a device reload to apply it, so the reload -- not the image copy -- is what the clock runs to; a device with the new image staged but not reloaded still allocates VTY lines the old way when the crafted TCP connections arrive and must be counted as exposed. The second remediation the packet names, disabling or ACL-restricting Telnet/VTY, is the one an operator can actually deploy inside a KEV-listing window on a router whose reload needs a change window, so the SLA is met by recording that compensating control as active with the fixed train dated to the next reload -- not by letting the interim state stand indefinitely as 'mitigated'. The deployment path itself is what this CVE breaks, which is why it cannot be run as a routine patch item: the packet's stated outcome is that the device refuses further Telnet, SSH, RSH and in some cases HTTP management access, so a device already under the attack cannot be reached in-band to receive either the ACL or the new image. The mitigation has to be pre-staged and the out-of-band console path proven working before it is needed, rather than pushed reactively once the lines are consumed. Distinguishing test: per device, produce the running image, the VTY transport and access-class configuration, and evidence that the reload carrying the fixed train actually happened -- a patch report that reads 'current' off a scheduled image push marks a router compliant while it is still executing the pre-reload code.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-05-19, active_exploitation 'confirmed'. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch for classic Cisco IOS; remediation is upgrading to a fixed IOS train (or disabling/ACL-restricting Telnet/VTY), which requires a device reload.' attack_vector: after all VTY lines are consumed 'the device refuses further Telnet, SSH, RSH and (in some cases) HTTP management access' -- the in-band path an operator would otherwise use to deploy either mitigation. rwep_score 42 against cvss 5.9 with poc_available false: the KEV listing and confirmed exploitation, not the severity band, are what put this on a clock.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The listener this control governs on a Cisco IOS device is the VTY line pool reached through the Telnet and reverse-Telnet ports: a non-HTTP endpoint that answers a TCP connection and allocates a line before any credential is presented, which is why an unauthenticated attacker can exhaust it and why perimeter and web-tier hardening never touch the path. Applied to the affected devices, the requirement is that those ports answer only from the management and jump networks that legitimately drive them -- enforced by an access class on the VTY lines and by upstream ACLs, not assumed from 'the router is internal' -- and that Telnet be removed where the device is administered over SSH, since the packet places the entry point on the Telnet/reverse-Telnet port specifically. Two preconditions have to be stated rather than glossed. First, restricting the source ranges bounds who can open the crafted connections; it does not repair the VTY allocation the flaw abuses, so any host inside the permitted management segment -- a compromised jump host, a contractor laptop -- can still consume every line and lock the operators out of the device. Second, on a unit doing terminal-server/console-server duty the reverse-Telnet listener has to stay reachable from the segments it serves, so for those units restriction narrows the source set and nothing more; there is no configuration that removes the path while the function is in use. Scope this to devices running the affected IOS with those listeners enabled, not to network equipment generally. Distinguishing test: from a general user VLAN, open a TCP connection to the device's Telnet and reverse-Telnet ports and confirm it is dropped before a VTY line is allocated -- a configuration review that shows SSH is enabled and Telnet 'not used' passes cleanly while the port still answers and still consumes a line.",
+        "evidence": "Packet vector: 'Cisco IOS 12.2(15) and earlier allows remote attackers to cause a denial of service (refused VTY (virtual terminal) connections), via a crafted TCP connection to the Telnet or reverse Telnet port.' attack_vector: 'An unauthenticated attacker opens a series of crafted TCP connections to the device's Telnet/reverse-Telnet port until all VTY lines are consumed.' live_patch_notes names 'disabling/ACL-restricting Telnet/VTY' as the alternative to the fixed IOS train. Citing gaps on this entry include ISO-27001-2022-A.8.22 (Segregation of networks), NIS2-Art21-network-security and UK-CAF-B4 (System security). cwe_refs CWE-400.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.22",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2016-6415": {
     "name": "Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure Vulnerability",
@@ -58425,7 +60319,30 @@
         "adequate": false,
         "gap": "A.5.15 access-control policy is defeated at the root: MinIO discloses the root credential itself pre-auth, so any access-control matrix built on that secret is bypassed the moment the bootstrap endpoint is queried."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "MinIO's remediation has three parts and only one of them is a patch, which is why a version-only SLA closes this ticket while the cluster stays owned. The packet's fixed release stops /minio/bootstrap/v1/verify returning process environment variables, but MINIO_ROOT_PASSWORD and MINIO_SECRET_KEY left the process before the upgrade and remain valid after it -- an attacker who read them authenticates as admin against the patched build exactly as they did against the vulnerable one. For this deployment the mitigation the SLA measures is all three of the packet's steps: the upgrade to RELEASE.2023-03-20T20-16-18Z or later, rotation of the exposed MINIO_ROOT_PASSWORD and MINIO_SECRET_KEY, and the service restart that puts the rotated values into the running process. The packet records no live-patch path, so that restart is unavoidable and every node takes it. Scope is the whole cluster rather than a representative node: the packet states the flaw affects cluster deployments and that all users of distributed deployment are impacted, and the disclosure endpoint answers per node, so a rolling upgrade that leaves one node on an affected release leaves the disclosure reachable and the rotation pointless. Distinguishing test: after the upgrade, POST to /minio/bootstrap/v1/verify on each node and confirm no environment content is returned, and separately confirm the pre-incident root credential no longer authenticates -- a flaw-remediation attestation that records the release string and stops there marks the cluster compliant while the leaked credential still works.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-04-21, active_exploitation 'confirmed', poc_available true, rwep_score 66, cvss 7.5. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch; remediation requires upgrading to MinIO RELEASE.2023-03-20T20-16-18Z or later, rotating the exposed MINIO_ROOT_PASSWORD / MINIO_SECRET_KEY, and restarting the service.' vector: 'In a cluster deployment starting with RELEASE.2019-12-17T23-16-33Z and prior to RELEASE.2023-03-20T20-16-18Z, MinIO returns all environment variables, including MINIO_SECRET_KEY and MINIO_ROOT_PASSWORD... All users of distributed deployment are impacted.' attack_vector places the disclosure at an unauthenticated POST to /minio/bootstrap/v1/verify on a distributed MinIO node.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The packet's chain does not end at disclosure. With MINIO_ROOT_PASSWORD in hand the attacker authenticates as admin and uses mc admin update to push a malicious binary, so MinIO's administrative API is a code-distribution channel for the server binary itself and a single disclosed credential is the whole gate on it. Treat it as that rather than as storage administration: file-integrity-monitor the MinIO binary and the service configuration on every node of the distributed deployment, alert on any replacement that does not correspond to a sanctioned operator action or a vendor upgrade, and restrict which identities may invoke the administrative update path at all. This is the half that still has value after the fixed release lands, because the upgrade closes the environment-variable disclosure but removes nothing that was pushed through the update path while the credential was exposed -- a node reachable during the exposure window has to be compared against a known-good binary rather than closed on its version string. It is also precisely what the access-control gaps recorded against this entry miss: an attestation that MinIO's admin accounts are controlled examines who is issued the root credential, not that holding it confers replacement of the running server, and rotating the credential afterwards does not evict a binary already installed. Precondition: integrity monitoring detects the substitution, it does not prevent it, and it is worth nothing on a node whose baseline was taken after the deployment was already exposed -- there the attacker's binary is what gets recorded as normal, and the comparison has to be against vendor-published artifacts rather than against the node's own history.",
+        "evidence": "Packet attack_vector: the disclosed MINIO_ROOT_PASSWORD and MINIO_SECRET_KEY are what 'the attacker uses to authenticate as admin and (via mc admin update) push a malicious binary for code execution.' live_patch_notes records remediation as the upgrade plus rotation of MINIO_ROOT_PASSWORD / MINIO_SECRET_KEY plus a service restart -- none of which reverses a binary already pushed. active_exploitation 'confirmed' with poc_available true and kev_date 2023-04-21. Citing gaps include UK-CAF-B2 (Identity and access control) and ISO-27001-2022-A.5.15 (Access control).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.5.15"
+        ]
+      }
+    ]
   },
   "CVE-2023-27350": {
     "name": "PaperCut MF/NG Improper Access Control Vulnerability",
@@ -58776,7 +60693,21 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management ranking by CVSS treats 8.8 as High-not-Critical, understating a zero-day with a public exploit; deprioritising it left the type confusion open while it was actively used."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet records no live-patch mechanism for this flaw and states the remediation exactly: Chrome/Chromium auto-update to 112.0.5615.121 or later, followed by a browser restart to load the patched build. That places the whole residual exposure in the gap between the update arriving on disk and the user relaunching the browser, which is why this control has to bind both halves for this CVE. On a managed estate it means the security update channel is not deferred by the update ring at all for a KEV-listed renderer defect, and the relaunch is forced by policy rather than left to the user's convenience — the delivery path here is an ordinary page visit (the packet's path is a crafted JavaScript page passing a JSGlobalProxy to Error.captureStackTrace, confusing V8's object typing and corrupting the heap into read/write primitives usable for renderer code execution), and the browser session least likely to be restarted, an instance left open for weeks, is exactly the one most likely to meet such a page. Completion must be measured on the version V8 is actually executing, not the version deployed: a host whose management record shows 112.0.5615.121 while the running browser has never been relaunched is still executing the pre-fix renderer, and every framework control citing this CVE closes on the deployed version. Distinguishing test: collect the running browser's version from managed hosts and confirm it is at or above 112.0.5615.121 — an estate reporting package-level compliance while long-lived sessions keep the old build resident is exposed to a defect the packet records as KEV-listed since 2023-04-17, with a public exploit and confirmed in-the-wild use. Precondition: forcing the relaunch bounds the window, it does not undo a visit that already happened; a host that rendered untrusted web content while below the fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet: type confusion in V8 in Google Chrome prior to 112.0.5615.121 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page; a crafted JavaScript page passes a JSGlobalProxy to Error.captureStackTrace, confusing V8's object typing and corrupting the heap into read/write primitives usable for renderer code execution. cisa_kev true, kev_date 2023-04-17, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 66. patch_available true; live_patch_available false with live_patch_notes: no live-patch mechanism, remediation is Chrome/Chromium auto-update to 112.0.5615.121 or later followed by a browser restart to load the patched build.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-20963": {
     "name": "Android Framework Privilege Escalation Vulnerability (CVE-2023-20963)",
@@ -58981,7 +60912,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management may rank a local 7.8 EoP below internet-facing criticals, but its confirmed ransomware use as the privilege-escalation link means the CVSS score understated real risk and only prompt OS patching removed the SYSTEM path."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in clfs.sys, the Windows Common Log File System driver, and describes a local attacker crafting a malicious CLFS base log (.BLF) to drive a heap overflow and out-of-bounds write in kernel memory, taking a low-privileged process to SYSTEM. For this CVE the control means the April 2023 Windows cumulative security update is driven across the affected estate on the KEV clock that opened 2023-04-11 rather than folded into the next monthly maintenance cycle, with completion measured per host against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. The reboot is the load-bearing detail: the packet records no live-patch mechanism and states the update requires a reboot to load the fixed clfs.sys, so a host that has installed the update and not restarted is still executing the vulnerable driver and must be counted as exposed. On servers and always-on workstations that pending reboot is precisely the step deferred to protect uptime, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. There is also no lever to trade against the update here, which is what separates this entry from a vulnerable third-party driver: the packet names no compensating configuration, no live-patch path and no way to prevent the driver loading, so a driver-blocklist or load-prevention posture is not an interim mitigation for this flaw — the update that replaces clfs.sys is the whole remediation. Note finally what the control cannot be substituted with: the attacker in this packet is already executing locally as a low-privileged user, so tightening account privilege does not contain the escalation. That is the entire value of the bug to an intruder — it converts access he already holds into SYSTEM — and it is why account-hardening evidence reads clean on a host that is fully exploitable. Priority follows the packet rather than the CVSS band: 7.8 is a local-privilege score, but a public PoC plus confirmed in-the-wild exploitation put the RWEP at 70, and a flaw of this class is the escalation link in a chain rather than a standalone endpoint item.",
+        "evidence": "Packet attack_vector: 'A local attacker crafts a malicious CLFS base log (.BLF) file to trigger a heap overflow / out-of-bounds write in clfs.sys, corrupting kernel memory to elevate a low-privileged process to SYSTEM.' CWE-122 and CWE-787. patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation is the April 2023 Windows cumulative security update, which requires a reboot to load the fixed clfs.sys.' CISA KEV-listed 2023-04-11, active_exploitation confirmed, poc_available true, rwep_score 70 against cvss 7.8. Citing gaps AU-Essential-8-Patch, NIS2-Art21-patch-management, NIST-800-53-SI-2, ISO-27001-2022-A.8.8.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Between the 2023-04-11 KEV listing and the reboot that actually loads the fixed clfs.sys, detection is the only lever an operator holds, and the packet describes the exploitation behaviour precisely enough to key a rule on it rather than on an assumed signal. The rule needs both halves the packet names. First the input: a CLFS base log — a .BLF file — being created or written by a process that is not running with administrative rights, and outside the locations where the operating system's own components keep their CLFS logs. Second the outcome: a low-privileged process becoming SYSTEM, observable as a SYSTEM-integrity process whose parent was running as a standard user, or as a privilege transition on a process that started unprivileged. Neither half stands alone — legitimate software does write CLFS logs, and SYSTEM processes are created constantly by the service control manager — and it is the pairing inside a short window, the same standard-user context supplying a base-log file and then holding SYSTEM, that distinguishes this exploit from either in isolation. Be clear about what will not see it: nothing is installed, no third-party driver is loaded, no service is created, and the process need not crash, so file-integrity monitoring, driver-load auditing and signature-based endpoint tooling have no artifact to match, and a rule that alerts on kernel crashes or on named exploit tooling would miss an attempt behaving exactly as the packet describes. Preconditions, stated rather than assumed: this requires kernel-level file-creation, process-creation and token telemetry already being collected and shipped off-host before the attempt — a rule authored afterwards against telemetry nobody was recording produces nothing — and detection does not prevent the escalation. Once it succeeds the attacker holds SYSTEM, so the alert buys response time and nothing more; a host that fired this rule goes to incident response and credential rotation, and is not closed out by the cumulative update that arrives later.",
+        "evidence": "The behaviour keyed on is the packet's own attack_vector: 'A local attacker crafts a malicious CLFS base log (.BLF) file to trigger a heap overflow / out-of-bounds write in clfs.sys, corrupting kernel memory to elevate a low-privileged process to SYSTEM' — the .BLF artifact and the low-privileged-to-SYSTEM transition are both stated there. poc_available true and active_exploitation confirmed, so attempts against unremediated hosts are the packet's stated condition. The detection window exists because live_patch_available is false and live_patch_notes require 'the April 2023 Windows cumulative security update, which requires a reboot to load the fixed clfs.sys' — remediation cannot be instantaneous across an estate. Citing gap UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-28205": {
     "name": "Apple Multiple Products WebKit Use-After-Free Vulnerability (CVE-2023-28205)",
@@ -59677,7 +61631,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management depends on the tool being inventoried and vendor-tracked; Cobalt Strike clients are often ad-hoc installs, so the incomplete-fix RCE was easy to miss until Fortra shipped 4.7.2 and CISA listed it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "Cobalt Strike is security tooling that a team installs and runs for itself, which is exactly why every patch-shaped control cited on this entry can pass while a 4.7.1 client keeps rendering implant data: the client is a per-operator install that managed software distribution typically never sees, so the estate's patch report has no row for it and its absence reads as compliance rather than as a gap. The requirement here is that the Cobalt Strike client be carried in the same vulnerability-management inventory and on the same SLA as any other privileged software, counted per operator workstation and not per team server -- the packet's fix is client-side, Fortra shipped 4.7.2 out of band to escape HTML in the Swing components, and remediation is upgrading that client and restarting it, with no live-patch path available. The trust-anchor-inversion test this control demands is available verbatim from the behaviour the packet documents: in a lab, have a controlled implant return data containing an HTML <object> tag, display it in the console, and confirm it renders as inert text instead of instantiating a Java object and calling its setters. Re-run that after every client rebuild, because a re-imaged operator workstation is where a 4.7.1 JAR comes back onto a team that had finished remediating. Precondition: the escaping is a property of the 4.7.2 build. This control is the inventory, the SLA and the test that establish each client actually reached it -- it gives nothing to an operator still running 4.7.1, and a console that displayed attacker-controlled implant data before the upgrade already executed whatever it was sent, so that workstation and the credentials it held belong on the incident path rather than on the patch list.",
+        "evidence": "Packet vector: 'Cobalt Strike 4.7.1 fails to properly escape HTML tags when they are displayed on Swing components. By injecting crafted HTML code, it is possible to remotely execute code in the Cobalt Strike UI.' live_patch_notes: 'No live-patch mechanism; Fortra released Cobalt Strike 4.7.2 as an out-of-band fix that properly escapes HTML in Swing components - remediation is upgrading the client and restarting it.' cisa_kev true, kev_date 2023-03-30, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 62, patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-046",
+        "name": "PEN-TEST-SCOPE-INCLUDES-SECURITY-PRODUCTS",
+        "description": "This CVE runs the engagement's data flow backwards, and that is the part scoping documents do not anticipate. The packet has attacker-controlled implant data carrying an HTML <object> tag rendered by the Cobalt Strike client's Java Swing UI, which instantiates arbitrary Java objects and calls their setters, executing code in the operator's console -- so every host the team implants is an input source into the team's own console, and the console is reachable by whoever controls what that host returns. Scope and threat-model language must therefore name the engagement toolchain itself, the team server and each operator client, as attack surface with an untrusted input path, with the client's rendering of implant-returned data enumerated as the specific surface rather than left as instrumentation assumed to sit outside the tested boundary. Keep the scope to those components: the packet ties the defect to the Cobalt Strike client's Swing rendering and gives no basis for treating other consoles or agents in the estate as instances of it. Precondition, and it is the whole limit of this control: scoping and testing describe the surface, they do not remove it. On a team still running the affected client the only closure is the packet's fix -- Cobalt Strike 4.7.2, client upgraded and restarted, with no live-patch path -- and until that lands, any implant on a host the team does not fully control is a live path into the operator's console regardless of how the engagement is scoped.",
+        "evidence": "Packet attack_vector: 'Attacker-controlled implant data containing an HTML <object> tag is rendered by the Cobalt Strike client's Java Swing UI, which instantiates arbitrary Java objects and calls their setters, executing code in the operator's console.' cwe_refs CWE-116. live_patch_notes gives the fix as Cobalt Strike 4.7.2 with the client upgraded and restarted; live_patch_available false. cisa_kev true, kev_date 2023-03-30, active_exploitation 'confirmed', poc_available true. Citing gaps include UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-39197": {
     "name": "Fortra Cobalt Strike Teamserver Cross-Site Scripting (XSS) Vulnerability",
@@ -60043,7 +62020,31 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management could not remediate a driver whose fix was withheld by the device supply chain; the kernel write primitive persisted on inventoried mobile assets despite being a known, KEV-listed exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's remediation is an OEM firmware/security update that ships the fixed Mali driver and reboots the device — the operator does not build that update and cannot accelerate it, so the only lever they actually hold is whether a device still carrying an affected driver keeps its access. For this CVE the enforced minimum has to be expressed as the OEM build that carries a Mali kernel driver outside the affected revision ranges (Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, Valhall r19p0 through r35p0), and it must function as an access condition — mail, VPN and document access denied to a device below it — not as a row on a patch-compliance dashboard. Distinguishing test: enrol a device whose Mali driver is still inside an affected range and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition, and this is where the control is usually over-claimed: the packet's path starts with an unprivileged local app, so restricting which applications may be installed raises the bar for getting that app onto the device but does not evict one already installed and does not cover one that arrived through the normal store channel — a device suspected of having run it belongs on the incident path, because the escalation ends at root and the packet records this as the local-escalation stage of a spyware chain. The update also reboots the device, so a device that has downloaded it but not restarted still runs the vulnerable driver and is not remediated.",
+        "evidence": "Packet vector: 'Arm Mali GPU Kernel Driver allows a non-privileged user to achieve write access to read-only memory pages. This affects Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, and Valhall r19p0 through r35p0.' Attack vector: 'An unprivileged local app abuses the Mali GPU kernel driver to obtain host-writable mappings of read-only imported pages, corrupting kernel memory to escalate privileges to root (used as the local-escalation stage of a spyware chain).' CISA KEV listed 2023-03-30; active_exploitation confirmed; poc_available true; CVSS 7.8; RWEP 72. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch mechanism for the Mali GPU kernel driver on affected devices; remediation requires the OEM firmware/security update that ships the fixed driver, which reboots the device.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet scopes this vulnerability by Mali kernel driver revision — Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, Valhall r19p0 through r35p0 — and not by an OS version or a reported patch-level string, while the fixed driver arrives inside an OEM firmware/security update rather than as a package the operator installs. So a fleet report that reads a device's OS build or patch-level date and marks it compliant has tested nothing about this CVE: the driver revision is chosen by the OEM's build, so two devices reporting the same patch level from different vendors can ship different Mali revisions, and one of them can still be inside an affected range. The operational test is to read the Mali driver revision actually loaded on a representative device of each OEM and model in the estate, check it against the three affected ranges, and re-run that check after every OEM update — because the update that moves the patch-level string is not necessarily the one that moves the driver, and that mismatch is exactly what a version-only scan cannot see. Precondition: this establishes exposure or its absence, it does not remediate. The packet records no live-patch mechanism, so a device found inside an affected range stays exposed until the OEM update lands and the device reboots, and a device the check clears today can regress if a later OEM build ships a driver revision back inside the range.",
+        "evidence": "Packet vector names the affected component by driver revision: 'This affects Midgard r26p0 through r31p0, Bifrost r0p0 through r35p0, and Valhall r19p0 through r35p0.' live_patch_available false with live_patch_notes: 'No live-patch mechanism for the Mali GPU kernel driver on affected devices; remediation requires the OEM firmware/security update that ships the fixed driver, which reboots the device.' CISA KEV listed 2023-03-30; active_exploitation confirmed; poc_available true; CVSS 7.8; RWEP 72; patch_available true. Citing gaps on this entry include ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) and UK CAF B4 (System security).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-26360": {
     "name": "Adobe ColdFusion Deserialization of Untrusted Data Vulnerability (CVE-2023-26360)",
@@ -60226,7 +62227,30 @@
         "adequate": false,
         "gap": "A.8.7 anti-malware posture that depends on OS reputation warnings is defeated by the fail-open MOTW bypass; the control passes the ransomware installer without an alert."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "SmartScreen is exactly the protection-mechanism class this control governs, and the packet describes the mechanism failing open rather than an application being exploited: an MSI or PE carrying a malformed Authenticode signature is delivered by drive-by download, SmartScreen errors while parsing that signature, the Mark-of-the-Web reputation check is skipped, and the file runs with no warning and installs Magniber ransomware. Bound to this estate, the control means every layer credited with covering the MOTW/SmartScreen class — the detonation chamber, the EDR rules written against 'unknown executable downloaded from the internet', and any AppLocker or WDAC policy an attestation leans on — carries a regression battery containing this primitive and runs it on every patch deployment, not once at remediation. The distinguishing test keys on the behaviour the packet documents rather than on a malware sample or a policy read-back: put an MSI and a PE with a deliberately malformed Authenticode signature and a Mark-of-the-Web tag on a test host, open them the way a drive-by download would, and confirm the reputation check actually runs and the file is warned on or blocked. Confirming that SmartScreen is 'enabled' in policy proves nothing here — the setting was enabled on every host this CVE was exploited against; the bypass is the check being skipped, not turned off. Precondition: this is a test regime and not a mitigation. It tells the operator whether the class is genuinely covered on a given build; it does not close the bypass. The packet records the March 2023 Windows security update as what makes SmartScreen fail closed on malformed signatures, with no live-patch path and a reboot required, so on a host that has not restarted the battery will still show the file executing silently — which is the correct result, and means that host is exposed rather than that the test failed.",
+        "evidence": "Packet fields for CVE-2023-24880 (Microsoft Windows SmartScreen Security Feature Bypass Vulnerability, CWE-863): CISA KEV listed 2023-03-14, active_exploitation confirmed, poc_available true, CVSS 4.4, rwep_score 66. The attack_vector states the attacker crafts an MSI/PE with a malformed Authenticode signature and delivers it via drive-by download; when the target opens it, SmartScreen errors while parsing the signature and skips the Mark-of-the-Web reputation check, so the file runs without the usual warning and installs Magniber ransomware. patch_available true, live_patch_available false, with live_patch_notes stating remediation requires the March 2023 Windows security update that makes SmartScreen fail closed on malformed signatures, followed by a reboot. The entry's citing gaps are the malicious-code-protection, anti-malware and user-application-hardening controls that credit SmartScreen as the covering mechanism.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case the control exists for, because its severity band and its real-world priority point in opposite directions: the packet records CVSS 4.4 — below the threshold at which most patch policies open an expedited clock — against confirmed in-the-wild exploitation, a public PoC, a KEV listing dated 2023-03-14 and an RWEP of 66, with the observed outcome being ransomware installation. A programme that schedules by CVSS band puts this update in the routine monthly stream while the exploitation it is listed for is already running. For this CVE the requirement is that the clock starts at the KEV listing and that completion is measured per host as the March 2023 Windows security update installed and the machine restarted, not as 'approved', 'downloaded' or 'pending reboot' in the management console — the packet registers no live-patch path and states the fix takes effect only after that reboot, so a host holding the update without a restart is still running the code that skips the reputation check. Precondition, stated rather than glossed: the packet names no interim vendor mitigation for this entry, so there is nothing to deploy in place of the update. During the window before each host restarts, the only cover is on the delivery and execution side — which is a different control, and it must not be recorded as though it satisfied this one. Nor does the SLA reach a host already compromised: the packet's outcome is ransomware installed by a file that ran silently, and installing the update afterwards does not undo an execution that already happened.",
+        "evidence": "Packet fields for CVE-2023-24880: cisa_kev true with kev_date 2023-03-14, active_exploitation confirmed, poc_available true, cvss 4.4, rwep_score 66. patch_available true, live_patch_available false, live_patch_notes stating remediation requires the March 2023 Windows security update that makes SmartScreen fail closed on malformed signatures, followed by a reboot. The attack_vector records the exploitation outcome as the crafted MSI/PE running without the usual warning and installing Magniber ransomware. The entry's citing gaps include the EU NIS2 vulnerability-handling/patch-management control and the UK CAF system-security control, both of which an estate can attest while scheduling this CVE by its 4.4 severity band.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-41328": {
     "name": "Fortinet FortiOS Path Traversal Vulnerability",