@blamejs/exceptd-skills 0.19.14 → 0.19.16

package/data/zeroday-lessons.json

@@ -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",
@@ -16257,7 +16279,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "FreePBX Endpoint Manager is the control-panel module this control governs, and the packet's vector is the forbidden pattern in a single line: a testconnection feature in the administration UI reaches check_ssh_connect(), which composes an OS command from caller-supplied input (CWE-78), so a form field on a user-facing surface is the only thing standing between a panel operator and command execution on the telephony server as the asterisk user. Applied to this product, the requirement is that the connection-test path pass its parameters to the SSH invocation as arguments rather than as a shell string, and that any privileged operation the module needs sit behind its own validated interface, so the module's own input handling is not the single boundary. The stake is not reduced by the outcome being the asterisk account rather than root: asterisk is the service identity the PBX runs as, so the packet's stated outcome — remote access to the system as an asterisk user — is control of the telephony service and everything it holds, not a low-privilege shell. Distinguishing test: on a staging FreePBX, submit an Endpoint Manager connection test whose host or credential field carries shell metacharacters and confirm no subcommand executes — a patch attestation taken against the FreePBX core that never enumerates installed modules reads clean while an unpatched Endpoint Manager keeps the sink. Precondition, and this is where the control is most likely to be over-claimed on this entry: the packet's detailed vector requires an authenticated known user, but the packet's own summary of the same flaw describes unauthenticated remote command execution, so restricting who holds a FreePBX administrative account bounds the population that can reach testconnection only if the authenticated precondition is the true one — it does nothing if the summary is. Constrain the module's reachability rather than the account list until the vendor update lands, and note that this control states the property the vendor fix must establish; it does not implement it.",
+        "evidence": "Packet: CWE-78, CVSS 9.8, RWEP 77, poc_available true, active_exploitation 'confirmed', cisa_kev true with kev_date 2026-02-03. Vector: 'Sangoma FreePBX Endpoint Manager contains an OS command injection vulnerability that could allow for a post-authentication command injection by an authenticated known user via the testconnection -> check_ssh_connect() function. An attacker can leverage this vulnerability to potentially obtain remote access to the system as an asterisk user.' The packet's attack_vector field summarises the same entry as 'an OS command-injection flaw (CWE-78) enabling unauthenticated remote command execution on the telephony server' — the two disagree on whether authentication is required, and this description does not resolve that disagreement in the operator's favour. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On a PBX the usual patch-window argument inverts. The packet records patch_available true, live_patch_available false, and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction — and a service restart on a production telephony server drops every call in progress, which is the specific reason this remediation gets marked done when the module update is installed rather than when the service comes back. Per the packet's own live_patch_notes, a host that has taken the update without the restart is still running the vulnerable code, so 'updated' and 'remediated' are different states here and only the second one counts. Applied to this entry, the clock starts at the 2026-02-03 KEV listing, the maintenance window is scheduled as part of the response rather than deferred into the next telephony change window, and completion is measured per host by the Endpoint Manager version actually loaded after restart rather than by an 'update applied' flag in a console. The compensating-control branch covers the interval: restrict which network segments can reach the FreePBX administration interface at all, since with a public PoC and confirmed exploitation the reachability of that interface is the remaining precondition an operator can act on. State its limits plainly — that bounds who can send the request, it does not close the injection, and it is unavailable wherever the administration interface must stay reachable for normal operation. It also does nothing for a host already reached: the packet marks exploitation confirmed, and an attacker who obtained the asterisk service identity survives the module update, so a server that was reachable during the exposure window needs its stored telephony credentials treated as disclosed and rotated rather than closed out on the patch.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-02-03, active_exploitation 'confirmed', poc_available true, CVSS 9.8, RWEP 77, ai_discovered false. patch_available true, live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Vector states the outcome as an attacker potentially obtaining 'remote access to the system as an asterisk user' via the Endpoint Manager testconnection -> check_ssh_connect() function.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-19006": {
     "name": " Sangoma FreePBX Improper Authentication Vulnerability",
@@ -17846,7 +17892,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "HPE OneView is the management plane for the server infrastructure it administers, and the packet places the defect on a path a remote unauthenticated user can reach: code injection (CWE-94) ending in remote code execution on the appliance itself. Bound to this product, the control means every endpoint the OneView appliance exposes authorizes its caller before the request reaches anything that evaluates content, and that caller-supplied content is neutralized rather than passed into an interpreter — and that no OneView instance is left answering from a segment with no operational need to manage infrastructure. This is also why the least-privilege gap cited on this entry does not close the path: the attacker never holds a OneView operator account, so per-account privilege scoping is never consulted and an access-review attestation passes cleanly while the injection path stays open. Distinguishing test: from a segment with no operational need to reach the management plane, send unauthenticated requests to each endpoint on a staging OneView appliance and confirm each is refused before any supplied content is evaluated. Precondition: the endpoint-side authorization and input neutralization are properties the vendor update establishes — this control states what to verify, it does not implement it. Until that update and its restart land, restricting which segments can reach the appliance bounds who can send the request but leaves it fully exploitable from anything inside the permitted segment, and that lever is unavailable for the management network the appliance must keep answering in order to administer the hardware it exists to manage.",
+        "evidence": "Packet: HPE OneView contains a code injection vulnerability (CWE-94) that allows a remote unauthenticated user to perform remote code execution on the infrastructure-management appliance; CVSS 9.8, RWEP 77; poc_available true; CISA KEV-listed 2026-01-07 with active_exploitation confirmed; NIST-800-53-AC-6 (Least Privilege) is one of the framework controls this entry cites as insufficient; patch_available true with live_patch_available false and live_patch_notes recording that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "OneView is a fleet control plane for server infrastructure, and the packet gives a pre-auth RCE with a public PoC and confirmed in-the-wild exploitation — so an appliance that was reachable between the 2026-01-07 KEV listing and its restart has to be triaged as possibly already compromised, because the vendor update closes the injection path and removes nothing an attacker executed, placed or read through it beforehand. For this CVE the playbook means: rotating every credential the appliance holds or brokers for the hardware it manages and every account that authenticated through it during that window; auditing the appliance's configuration and profile changes across the window; and having stated quarantine criteria for managed hardware whose configuration OneView could have altered while under attacker control. Precondition: this is a response control, not a preventive one — it does not lower the chance of exploitation, it bounds what an already-executed compromise retains, and it is only worth running where the exposure window can be established. Since the flaw yields code execution on the appliance, an attacker is above the appliance's own logging, so the window has to be reconstructed from network-side and collector-side records rather than trusted from the appliance's local logs.",
+        "evidence": "Packet: remote unauthenticated code execution (CWE-94) on the HPE OneView infrastructure-management appliance; CISA KEV-listed 2026-01-07 with active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 77; patch_available true, live_patch_available false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "An infrastructure-management appliance is usually inventoried as the tool an estate patches its servers with rather than as an asset carrying its own patch clock, which is exactly how a KEV-listed pre-auth RCE on OneView ends up riding the next infrastructure maintenance window while the operating-system patching attestation reads clean. For this CVE the control means the appliance's own update runs on the KEV clock that opened 2026-01-07, not on the cadence of the fleet updates OneView distributes, with completion measured by the version the appliance is actually running rather than by a staged or downloaded update. The packet records no live-patch path and a fix that typically requires a service restart or system reboot, so an appliance that has taken the update but not restarted still carries the vulnerable code and must be counted as exposed — and on a management appliance that restart is the step most likely to be deferred, because it interrupts the console the estate's operators depend on. Priority follows the packet: unauthenticated remote code execution with a public PoC and confirmed exploitation, on the plane that administers the hardware underneath it.",
+        "evidence": "Packet: CISA KEV-listed 2026-01-07 with active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 77; unauthenticated remote code execution (CWE-94) on the HPE OneView management appliance; patch_available true, live_patch_available false, live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction; the entry cites AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-52163": {
     "name": "Digiever DS-2105 Pro Missing Authorization Vulnerability",
@@ -18900,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",
@@ -18960,7 +19063,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The packet 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": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "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": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "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": [
+          "CIS-Controls-v8-10.1"
+        ]
+      }
+    ]
   },
   "CVE-2021-26828": {
     "name": "OpenPLC ScadaBR Unrestricted Upload of File with Dangerous Type Vulnerability",
@@ -20264,7 +20398,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",
@@ -21334,7 +21491,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",
@@ -22118,7 +22305,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)",
@@ -23766,7 +23985,21 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet puts the attacker inside the trust boundary before the flaw is touched: exploitation requires an authenticated user in the same Windows Active Directory domain as the Session Recording server, and the outcome is escalation to the NetworkService account on that server (CWE-269). For this CVE the control means the Citrix Session Recording update is driven across every Session Recording server on the clock that opened with the 2025-08-25 KEV listing rather than folded into the next Citrix maintenance window, with completion measured per server by the code actually running rather than by 'approved' or 'deployed' in a change record. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot, so a server that has taken the update but not restarted still carries the vulnerable code and must be counted as exposed; on a recording server that restart is the step most likely to be deferred, because taking it interrupts recording of live sessions, and a deferral logged as 'patched' is the specific way this remediation goes wrong. The control's second half is the load-bearing one here: every framework control cited against this entry is a patch-timeline control, and none of them can contain an escalation whose only precondition is holding an ordinary domain account — the attacker is already authenticated, so entitlement review and account-privilege tightening leave the path fully intact while their attestations pass. Enumerate first the Session Recording servers joined to a domain whose ordinary users are not administrators of them, because there the exploit's precondition is the normal operating state rather than an anomaly. Distinguishing test: produce, per server, the running Session Recording build and the service start time, and confirm the start time is later than the update install time — a fleet report showing the fixed package installed on every server, with services still running from before the install, is a fleet that is still exploitable. Precondition: with a public PoC and confirmed in-the-wild exploitation, the update remediates the flaw but establishes nothing about whether it was used first; a server that ordinary domain accounts could reach through the exposure window needs its post-exploitation state examined rather than closed on the patch record.",
+        "evidence": "Packet fields for CVE-2024-8068 (Citrix Session Recording Improper Privilege Management Vulnerability): cwe_refs CWE-269; vector 'Citrix Session Recording contains an improper privilege management vulnerability that could allow for privilege escalation to NetworkService Account access. An attacker must be an authenticated user in the same Windows Active Directory domain as the session recording server domain.'; attack_vector records escalation of an authenticated user's privileges on the recording server. cisa_kev true with kev_date 2025-08-25; active_exploitation confirmed; poc_available true; cvss 7.8; rwep_score 77. patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps recorded on this entry: AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIS2-Art21-patch-management (Vulnerability handling and disclosure), NIST-800-53-SI-2 (Flaw Remediation) and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-8069": {
     "name": "Citrix Session Recording Deserialization of Untrusted Data Vulnerability",
@@ -25232,7 +25465,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet states outright that this CVE is a patch bypass for CVE-2025-49704 and that its updates carry more robust protection than 49704's did. That means an on-premises SharePoint farm which took the 49704 update and was recorded as remediated sat on the vulnerability-management ledger as 'patched' while remaining fully exploitable through the same CWE-502 sink — the earlier fix is the thing that failed, not the operator's SLA. Bound to this farm, the control requires that a SharePoint deserialization CVE which supersedes an earlier fix on the same sink is scored and scheduled above what its CVSS band alone implies, and that the superseded CVE's remediation record is reopened rather than left closed. It also sets the intake expectation for what follows: the packet already names a second CVE (CVE-2025-53771) this one can be chained with, so the farm's exposure is a sequence on one primitive, not a discrete ticket that closes. Precondition, and it is the limit of this control: it changes priority, scoring and record-keeping only — it remediates nothing. The vendor update plus the service restart or system reboot the packet records as typically required is what removes the code path, and a farm server that has taken the update but not the restart is still running the vulnerable code.",
+        "evidence": "Packet vector: 'CVE-2025-53770 is a patch bypass for CVE-2025-49704, and the updates for CVE-2025-53770 include more robust protection than those for CVE-2025-49704' and 'This vulnerability could be chained with CVE-2025-53771'. cwe_refs CWE-502; cisa_kev true, kev_date 2025-07-20; active_exploitation confirmed; rwep_score 83, cvss 9.8; poc_available true; patch_available true; live_patch_available false with live_patch_notes 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's attack path does not end at code execution — it ends at web-shell deployment on an on-premises SharePoint Server reached over the network by an attacker holding no credential. For this CVE that makes the farm an already-compromised host to be triaged, not a patch target to be closed. Applied to a SharePoint deployment: every front-end and application server that was network-reachable across the exposure window is examined for attacker-written content in the directories the web application serves, and every secret the farm's application identity holds — service accounts, application credentials, and the farm's own cryptographic material — is rotated, because the update closes the deserialization sink but removes nothing already written through it or read out of it. This is also the specific reason the anti-malware control cited against this entry cannot carry the remediation: a bespoke .aspx file dropped through the application's own request path is not a signature-matched sample, so a fully deployed and current anti-malware estate reports clean over a live web shell. Preconditions: rebuild-and-rotate reaches only the farm's own hosts and its own credentials — if the foothold was used to move to an identity outside the farm, that account is out of scope here and needs separate containment; and the triage is bounded by an exposure window the operator can actually establish, so a farm without retained per-request access logs for the period cannot scope the hunt at all, in which case rebuild is the safe default rather than an evidence-driven choice.",
+        "evidence": "Packet vector: 'Microsoft SharePoint Server on-premises contains a deserialization of untrusted data vulnerability that could allow an unauthorized attacker to execute code over a network.' Packet attack_vector: 'deserialization of untrusted data (CWE-502) on SharePoint Server (the ToolShell chain), yielding unauthenticated remote code execution and web-shell deployment. CISA KEV-listed 2025-07-20 with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available true; patch_available true; citing gap CIS-Controls-v8-10.1 'Deploy and Maintain Anti-Malware Software'.",
+        "gap_closes": [
+          "CIS-Controls-v8-10.1",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "An unauthenticated network RCE on an on-premises SharePoint farm, KEV-listed 2025-07-20 with confirmed in-the-wild exploitation, a public PoC and an RWEP of 83, is the case a KEV clock exists for — and the clock has to run to the completed restart rather than to the installed update. The packet registers no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a farm with more than one server is remediated only when every server has both taken the update and been restarted; completion is measured per server against the fixed build, not from a deployment console reporting 'approved' or 'applied'. That distinction is where this remediation goes wrong in practice, because the restart is the step a farm operator defers to avoid taking the site offline, and a deferral recorded as patched is indistinguishable on the dashboard from a real fix. Precondition: this is a deployment clock and nothing more. It says nothing about whether the farm was exploited before the clock started — which, for a KEV-listed pre-auth RCE with confirmed exploitation and web-shell deployment, is the likely case — so meeting the SLA is not a statement that the farm is clean.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-07-20; active_exploitation confirmed; rwep_score 83; cvss 9.8; poc_available true; patch_available true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Vector: 'could allow an unauthorized attacker to execute code over a network.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-25257": {
     "name": "Fortinet FortiWeb SQL Injection Vulnerability",
@@ -26329,7 +26594,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries two facts that have to be held together: patch_available is recorded true, and the vector states that all associated hardware revisions of the DIR-859 have reached end-of-life or end-of-service and should be retired and replaced per vendor instructions. Both are real, and together they settle the terminal state — whatever fixed firmware exists is an interim step on hardware with no ongoing patch path, so removal and replacement is the end state for every unit, not an option to weigh against patching. The requirement here is therefore an inventory that names each DIR-859 in service with its location and hardware revision and carries a dated replacement commitment, rather than a firmware-version column that turns green and stays green. A remediation record that ends at 'every DIR-859 reports the fixed build' marks the estate compliant while each unit remains exposed to everything found in that platform after the build shipped, with no vendor left to fix it — and the packet's confirmed exploitation and public PoC mean this device class is under active attention now, not hypothetically. Precondition on the interim measure, which is where this control is usually over-claimed: restricting who can reach the device's HTTP interface bounds who can send the POST, but the packet places the flaw in the router's own HTTP POST request handler, and a router exists to serve the clients behind it. Every host on the network it serves can reach that interface, so for a unit serving a general user or guest network there is no segment that removes the path — only isolation of that served network from anything else that matters, and replacement on the dated schedule.",
+        "evidence": "Packet vector: 'D-Link DIR-859 routers contain a path traversal vulnerability in the file /hedwig.cgi of the component HTTP POST Request Handler... This vulnerability affects legacy D-Link products. All associated hardware revisions have reached their end-of-life (EOL) or end-of-service (EOS) life cycle and should be retired and replaced per vendor instructions.' patch_available true; live_patch_available false; cisa_kev true, kev_date 2025-06-25; active_exploitation confirmed; poc_available true; rwep_score 77; cvss 7.8; cwe_refs CWE-22.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive the packet describes is a read, not a write: manipulating the service argument with ../../../../htdocs/webinc/getcfg/DHCPS6.BRIDGE-1.xml leaks session data from the device configuration, which the packet says potentially enables privilege escalation and unauthorized control of the device. Everything that leaked stays valid after firmware is applied — the update stops further reads, it does not invalidate what an attacker already holds, and it does not undo configuration an attacker with device control has already changed. Bound to this router: a DIR-859 that was reachable during the exposure window is treated as having had its configuration read, so the device administrative credential, the wireless keys, and any WAN or dynamic-DNS credential the configuration carries are rotated, and the unit is re-provisioned from a known-good configuration rather than left running the settings that were exposed. Preconditions, both load-bearing. First, re-provisioning is not the terminal state for this device: the packet's own vector directs retirement and replacement, so the rebuilt unit is a bridge to its replacement and any credential rotated onto it is rotated again at decommission — a rebuild recorded as closure leaves an unsupported router in service. Second, the rotation scope is only as good as the exposure window the operator can establish; a consumer-class router that retains no request logs cannot bound it, and in that case every deployed unit's configuration is treated as read.",
+        "evidence": "Packet vector: 'Manipulation of the argument service with the input ../../../../htdocs/webinc/getcfg/DHCPS6.BRIDGE-1.xml allows for the leakage of session data potentially enabling privilege escalation and unauthorized control of the device.' Packet attack_vector: 'letting an attacker read sensitive files including credentials from the device configuration. CISA KEV-listed 2025-06-25 with confirmed in-the-wild exploitation.' active_exploitation confirmed; poc_available true; patch_available true; vector's retirement-and-replacement instruction for all hardware revisions.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-54085": {
     "name": "AMI MegaRAC SPx Authentication Bypass by Spoofing Vulnerability",
@@ -26787,7 +27075,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",
@@ -27674,7 +27995,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",
@@ -27734,7 +28086,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",
@@ -27937,7 +28312,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)",
@@ -28151,7 +28549,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",
@@ -28586,7 +29016,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Common Log File System driver and describes an authorized attacker elevating privileges locally through a use-after-free — the account is already legitimate, so no account model is being abused; a kernel privilege boundary is failing. For this CVE the control means the Windows update carrying the CLFS fix is driven across the affected estate on the KEV clock that opened 2025-05-13 rather than folded into the next monthly rollup, with completion measured per host by installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. CLFS is a driver that ships with Windows and loads on every install, so there is no subset to carve out, no module to blacklist and no feature to disable as an interim measure — the update is the only remediation available, which is precisely why measuring it accurately is the whole of the control. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot, so a host that has installed the update but not rebooted still runs the vulnerable driver and must be counted as exposed; shared and multi-user hosts are where that reboot is deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Priority follows the packet rather than the CVSS band: at CVSS 7.8 this sorts below the 9.x remote flaws in a severity-ordered queue, while the packet records RWEP 77, a public PoC, confirmed exploitation, and that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators — making it the containment step for a chain rather than a standalone endpoint item.",
+        "evidence": "Packet: use-after-free (CWE-416) in the Windows Common Log File System (CLFS) Driver allowing an authorized attacker to elevate privileges locally, exploited by a local foothold to escalate to SYSTEM; CISA KEV-listed 2025-05-13 with active_exploitation confirmed; poc_available true; CVSS 7.8 against RWEP 77; the packet describes CLFS as a recurring kernel-LPE target and notes LPEs of this class are routinely paired with an initial-access flaw by ransomware operators; patch_available true, live_patch_available false, live_patch_notes recording that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Every framework control cited on this entry is a patch or vulnerability-handling control, and none of them observe anything during the interval between the 2025-05-13 KEV listing and the reboot that completes the fix — which is the interval in which the packet says this flaw is being exploited. For this CVE the control means kernel-privilege-escalation telemetry on Windows endpoints keyed on the transition the packet actually describes: a process running under an already-authorized non-administrative account that ends up holding SYSTEM privileges, or spawning a SYSTEM-integrity child, without passing through a legitimate elevation path — correlated with that same process driving the CLFS driver from user mode. Alert within 60 seconds. What not to key on, because it would miss this exploit entirely: the packet describes a use-after-free that succeeds in escalating, not one that faults, so a rule watching for driver crashes or bugchecks never fires on a working exploit; and the packet records a public PoC, so a rule keyed on a named tool or a file hash misses the derived variant an operator will meet. The distinguishing test has to exercise the real transition rather than a stand-in: on a staging host, have a standard user account run a local escalation that ends with a SYSTEM-integrity process and confirm the rule alerts on the privilege transition itself. Preconditions: this detects, it does not prevent — its value is bounding dwell time on hosts that have not yet taken the reboot, and it does not make an unrebooted host remediated. And because the escalation's own outcome is SYSTEM, a successful attacker ends up above the agent that would report the alert, so telemetry has to reach an off-host collector to be a control at all.",
+        "evidence": "Packet: use-after-free (CWE-416) in the Windows CLFS driver exploited by a local foothold to escalate to SYSTEM, with the attacker described as an authorized user elevating privileges locally; CISA KEV-listed 2025-05-13 with active_exploitation confirmed; poc_available true; CVSS 7.8, RWEP 77; the packet notes LPEs of this class are routinely paired with an initial-access flaw by ransomware operators; patch_available true, live_patch_available false, live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction; the framework controls this entry cites are all patch or vulnerability-handling controls.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-12450": {
     "name": "RAGFlow web_crawl Full-Read SSRF + Arbitrary File Read",
@@ -30042,7 +30496,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)",
@@ -30097,7 +30572,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",
@@ -36261,7 +36758,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet forecloses the remediation this entry's framework gaps assume: Cisco has not and will not release software updates that address this vulnerability, and the entry records no patch and no live-patch path. For the RV016, RV042, RV042G, RV082, RV320 and RV325 routers the packet names, remediation therefore means removal from service on a dated schedule, and the interim state is the vendor's own workaround — disabling the affected feature described in the Workarounds section — together with restricting which segments can reach the web-based management interface at all. Scope it to those six models: the packet ties the flaw to that management interface on those routers and gives no basis for treating other Cisco equipment as an instance of it. The precondition is sharp here and must be stated rather than glossed — segmentation and the feature workaround bound who can send the crafted HTTP request, they do not remove the defect, and the packet's stated access requirement is valid administrative credentials on the device, so an attacker holding or replaying those credentials from a permitted management segment still reaches the root-level command execution. Because active exploitation is confirmed and the outcome is root-level privileges plus access to unauthorized data, a unit that was reachable during the exposure window has to be treated as attacker-held: its configuration and every credential it stored are suspect, and re-provisioning it returns it to a state where no fix exists — which is why the terminal state is replacement rather than a hardened surviving unit. A requirement that ends at 'the workaround is applied' marks a device the vendor has permanently declined to fix as compliant while it stays exposed to this flaw and to anything found in it later.",
+        "evidence": "Packet: patch_available false; the vector states 'Cisco has not and will not release software updates that address this vulnerability' and directs administrators to disable the affected feature per the Workarounds section. live_patch_available false, with live_patch_notes recording no live-patch path for this product class and decommissioning as the remediation for end-of-life products. CISA KEV-listed 2025-03-03 (due 2025-03-24), active_exploitation confirmed, poc_available true, RWEP 83 against CVSS 6.5. Affected models named in the packet: RV016, RV042, RV042G, RV082, RV320, RV325. The documented path is a crafted HTTP request to the web-based management interface exploiting improper validation of user input (CWE-77); the packet states the attacker must hold valid administrative credentials on the affected device and that a successful exploit yields root-level privileges.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this entry the control's middle verdict state is not a temporary one, because nothing is pending behind it: the packet records that no software update addressing this vulnerability will be released, so the feature-disable workaround is the only technical measure that will ever exist. Any RV-series unit still in service must therefore be recorded as 'vendor workaround active, no fix, none forthcoming' with a dated removal action attached, and never as satisfying a patch-cadence control. The distinguishing test is on the register rather than the device: pull the vulnerability-management record for each RV016, RV042, RV042G, RV082, RV320 and RV325 in service and read what it reports once the workaround is applied — if it reads 'remediated' or 'patched per SLA', the record has lost both the fact that a KEV-listed, actively-exploited flaw with a public PoC is still present in the device and the fact that the residual risk is now bounded only by whatever the workaround itself is worth. Precondition: this control changes what the record says, not what the device does. It reduces no exposure on its own; its whole value is preventing the workaround from closing the item and removing the schedule pressure that decommissioning depends on.",
+        "evidence": "Packet: patch_available false and the vector states Cisco has not and will not release software updates that address this vulnerability, offering only that 'administrators may disable the affected feature as described in the Workarounds section'. live_patch_available false. CISA KEV-listed 2025-03-03 (due 2025-03-24) with active_exploitation confirmed and poc_available true; RWEP 83, CVSS 6.5.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-34192": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Vulnerability",
@@ -36316,7 +36837,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",
@@ -36678,7 +37223,30 @@
         "adequate": false,
         "gap": "Patch-applications control assumes a known-vulnerable window between disclosure and exploitation; here the window was negative, so patch cadence alone can't be the only control."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The vulnerable code here is a Joomla extension rather than Joomla itself, and that is precisely where this entry's patch-cadence gaps fail: a site whose CMS core is current, and whose operating-system patching attests clean, can still be serving the unauthenticated Balbooa Forms attachment endpoint the packet describes. Applied to this CVE, the KEV clock that opened 2026-07-10 runs against an inventory of every Joomla site in the estate carrying the Balbooa Forms extension — including sites where the form sits on a low-traffic marketing page nobody treats as an application, which is the population that goes uncounted when the inventory unit is 'the website' rather than 'the extensions this website loads'. Completion is measured by the extension version each installation reports against the vendor's fixed release, not by the Joomla core version and not by a 'site updated' line in the change record. The packet records a vendor patch as available and no live-patch path, so the fixed extension release applied per installation is the remediation; the packet registers no restart requirement for this entry, so nothing in it supports treating this as a maintenance-window item. Priority follows the packet rather than the CVSS band alone: an unauthenticated upload requiring no user interaction, a public PoC, and confirmed in-the-wild exploitation mean the interval between listing and update is an interval in which the endpoint is being used. Scope: the packet ties this to the Balbooa Forms extension and to nothing else — it is a reason to know which sites carry that extension, not a reason to treat every Joomla extension in the estate as an instance of this flaw.",
+        "evidence": "Packet: CISA KEV-listed 2026-07-10, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 65. patch_available true; live_patch_available false; live_patch_notes null (no restart or live-patch detail recorded for this entry). The affected product is the Joomla extension Balbooa Forms (CWE-434, unrestricted upload of file with dangerous type); the packet's documented path is an unauthenticated attacker submitting a .php file to a Balbooa Forms attachment field, which the extension stores in a public uploads folder with no file-type or authentication check, and which the attacker then requests directly to execute — the packet records the outcome as full RCE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet describes a flaw that does not stop mattering when the extension is updated: the attacker's artifact is a .php file already written into a public uploads folder, and requesting that URL executes it whether or not the upload path has since been repaired. On an internet-facing Joomla site, with exploitation confirmed in the wild and a public PoC, applying the fixed extension release is the first step and the compromise assessment is the rest — enumerate the Balbooa Forms upload directory and the site's web-served tree against a known-good baseline, rebuild the site from source and known-good content rather than trusting an in-place clean, and rotate every credential the web process could reach: the site database credentials, Joomla administrator accounts, keys held in site configuration, and any of those reused elsewhere. The trigger for this playbook has to be exposure rather than an alert, and the detection has to key on what the packet's path actually emits: a file with an executable extension appearing in the uploads directory outside any sanctioned change, and web-server log entries requesting a file under that uploads path directly. It will not arrive as an anti-malware hit — a small bespoke PHP file delivered through an endpoint whose purpose is accepting uploads has no signature to match — and it produces no failed-authentication event, because the packet's attacker never authenticates. Precondition: this control bounds the damage of an intrusion that already occurred. It prevents nothing on a site that has not yet been reached, and it is not a substitute for the vendor's fixed extension release, which is the only thing that closes the upload path itself.",
+        "evidence": "Packet: active_exploitation confirmed, poc_available true, CISA KEV-listed 2026-07-10, CVSS 9.8, RWEP 65. The documented exploitation path is an unauthenticated .php upload through a Balbooa Forms attachment field into a public uploads folder, which the attacker then requests directly to execute the code — the file's persistence is independent of the extension's (absent) file-type and authentication checks. patch_available true; live_patch_available false; live_patch_notes null. The packet's vector records the result as full RCE.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-48939": {
     "name": "iCagenda Unrestricted Upload of File with Dangerous Type Vulnerability",
@@ -36720,7 +37288,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",
@@ -37000,7 +37590,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",
@@ -37517,7 +38139,31 @@
         "adequate": false,
         "gap": "Boundary protection blocking outbound SMB (445) to arbitrary external hosts would have prevented NTLM hash relay/capture even where the client-side Protected View bypass succeeded."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The mechanism this CVE defeats is Office Protected View itself: per the packet, a crafted 'file://' moniker hyperlink carrying the '!' new-window parameter makes Outlook bypass Protected View and open the linked remote document in edit mode when the recipient clicks it. That makes an attestation of the form 'Protected View is enforced by policy' simultaneously true and worthless — the policy is enforced and the document opens outside it, so a user-application-hardening review that inspects the policy finds nothing wrong. For this CVE the control means the moniker-link primitive becomes a permanent case in the estate's Protected-View / untrusted-document test battery, re-executed on every Office and Outlook update rather than exercised once while remediating this CVE, because a mechanism that has been bypassed once is a mechanism whose future updates need proving rather than assuming. Distinguishing test, keyed to the behaviour the packet documents rather than to a stand-in: send a managed workstation at the fixed build an email whose body carries a 'file://' moniker hyperlink with the '!' new-window parameter pointing at a share you control, click it, and check two observables — that the linked document opens in Protected View rather than edit mode, and that the workstation makes no authentication attempt to that share. The second observable is the one a naive test drops: the packet records NTLM hash leakage to an attacker SMB share as an outcome distinct from code execution, so an outbound authentication attempt is the signal that the primitive still works even when the document render looks contained, and a test that watches only the render will pass over it. Precondition: this is a verification control, not a mitigation. It tells an operator whether the protection class is actually restored on a given build; it restores nothing itself, and it gives nothing to a client that has not yet taken the vendor update. A battery that runs only at remediation time also cannot see a later regression, which is the entire reason for tying it to every update rather than to this ticket.",
+        "evidence": "Packet fields for CVE-2024-21413 (Microsoft Outlook Improper Input Validation Vulnerability): cwe_refs CWE-20; vector 'Microsoft Outlook Remote Code Execution Vulnerability'; attack_vector 'An attacker sends an email containing a crafted file:// moniker hyperlink with a ! new-window parameter; when the recipient clicks it, Outlook bypasses Office Protected View and opens the linked remote document in edit mode, enabling NTLM hash leakage via an attacker SMB share or remote code execution.' cisa_kev true with kev_date 2025-02-06; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 74. patch_available true, live_patch_available false, live_patch_notes null. Citing gaps recorded on this entry: AU-Essential-8-Patch, ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIS2-Art21-patch-management, NIST-800-53-SC-7 (Boundary Protection), NIST-800-53-SI-2 (Flaw Remediation) and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "What the clock governs on this entry is distribution, not availability: the packet records patch_available true against a CVE from the 2024 identifier series that CISA did not list until 2025-02-06, with exploitation confirmed and a public PoC. The remediation unit is also unusual for a KEV item — the vulnerable code is the Outlook client on every user's machine, not a server or an appliance, so the SLA has to be measured as the count of Outlook installs reporting the fixed build and closed against the estate's install inventory, not against a change ticket for a single system. The packet registers no live-patch path and carries no live-patch note for this entry, so each install reaches remediation only by taking the vendor update; there is no interim state in which the client is running fixed code. Precondition on the compensating-control branch, which is where this gets over-claimed: for the window before the update lands, the outbound leg the packet names — NTLM authentication to an attacker-controlled SMB share — can be restricted at the boundary, and that is what the entry's boundary-protection gap points at, but it bounds only the credential-leak half. The packet records remote code execution as a separate outcome that this restriction does not address, and it does nothing where the link's destination is reachable inside the estate rather than across the boundary being filtered, so it is a bound on one outcome for one class of destination, not a substitute for the update. Second precondition: the update closes the client path forward and recovers nothing backward. Credential material already leaked during the exposure window stays valid after every client is patched, so any account whose workstation authenticated outward to an untrusted host in that window is a rotation item and a hunt item, not a line that clears when the install count reaches 100 percent.",
+        "evidence": "Packet fields for CVE-2024-21413: attack_vector 'An attacker sends an email containing a crafted file:// moniker hyperlink with a ! new-window parameter; when the recipient clicks it, Outlook bypasses Office Protected View and opens the linked remote document in edit mode, enabling NTLM hash leakage via an attacker SMB share or remote code execution.' cisa_kev true with kev_date 2025-02-06 against a CVE in the 2024 identifier series; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 74; cwe_refs CWE-20. patch_available true, live_patch_available false, live_patch_notes null — no live-patch path and no live-patch note is recorded for this entry. The citing gaps are dominated by patch-timeline controls (AU-Essential-8-Patch, NIS2-Art21-patch-management, NIST-800-53-SI-2, ISO-27001-2022-A.8.8), with NIST-800-53-SC-7 (Boundary Protection) recorded alongside them.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2022-23748": {
     "name": "Dante Discovery Process Control Vulnerability",
@@ -38775,7 +39421,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",
@@ -38960,7 +39638,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",
@@ -39072,7 +39773,30 @@
         "adequate": false,
         "gap": "Vulnerability handling processes did not flag an internet-facing admin interface as an unacceptable exposure ahead of exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The ColdFusion Administrator is the management surface on this entry, and the packet places the defect behind it: an unauthenticated attacker sends crafted requests to the ColdFusion admin API / PMS servlet and reads arbitrary files on the server filesystem, with no user interaction required. Bound to this product, the control means each administrative endpoint on that admin API decides its own caller's authorization before performing the file operation — an unauthenticated request is refused by the endpoint itself, not by whatever fronts it — and the Administrator surface is segmented so an untrusted caller cannot present the request in the first place. The packet makes that second half unusually concrete for a KEV entry: it states that exploitation requires the admin panel be exposed to the internet, so on a deployment where the Administrator answers only from an internal or VPN-reached segment, the published path has no origin to come from. The access-control gap recorded against this entry is cited precisely because no account is authenticated anywhere on this path: the attacker holds no ColdFusion administrator credential, so per-account access rules are never consulted, and an access-control attestation showing every ColdFusion administrator named, provisioned and reviewed passes cleanly while the read succeeds. Distinguishing test: from an untrusted network segment, issue unauthenticated requests to the admin API / PMS servlet paths on a staging ColdFusion instance and confirm each is refused before any file is read. Preconditions: the endpoint-side authorization is a property the vendor update establishes — this control states what to verify, it does not implement it. Removing internet reachability bounds who can send the request, and the packet gives that reachability as the exploit's stated prerequisite, but it does not repair the access control: any caller inside the permitted segment still reaches it, so a compromised internal host, a jump box or a partner-network path satisfies the precondition in full, and the measure is unavailable where the Administrator must stay reachable for operational reasons. And because the primitive is an arbitrary file read with exploitation confirmed, an instance that was internet-reachable before remediation has to have the secrets held in the files it could serve treated as read and rotated — neither the update nor the segmentation recovers what already left.",
+        "evidence": "Packet fields for CVE-2024-20767 (Adobe ColdFusion Improper Access Control Vulnerability): cwe_refs CWE-284; vector 'ColdFusion versions 2023.6, 2021.12 and earlier are affected by an Improper Access Control vulnerability that could result in arbitrary file system read. An attacker could leverage this vulnerability to access or modify restricted files. Exploitation of this issue does not require user interaction. Exploitation of this issue requires the admin panel be exposed to the internet.'; attack_vector 'An unauthenticated attacker sends crafted requests to the ColdFusion admin API/PMS servlet to read arbitrary files on the server filesystem, exposed only because the admin panel itself was reachable from the internet.' cisa_kev true with kev_date 2024-12-16; active_exploitation confirmed; poc_available true; cvss 7.4; rwep_score 70. patch_available true, live_patch_available false, live_patch_notes null. Citing gaps recorded on this entry include ISO-27001-2022-A.5.15 (Access control) and NIST-800-53-SC-7 (Boundary Protection), alongside AU-Essential-8-Patch, NIST-800-53-SI-2, NIS2-Art21-vulnerability-management and UK-CAF-B4.",
+        "gap_closes": [
+          "ISO-27001-2022-A.5.15",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "This entry carries two independent conditions, and a scan verdict that checks only the first is paper compliance: the packet names the affected levels (ColdFusion 2023.6, 2021.12 and earlier) and separately states that exploitation requires the admin panel be exposed to the internet. Those two checks fail in opposite directions — a host at a fixed build whose Administrator still answers from the internet keeps every subsequent admin-surface defect on the published path, and a host below the fixed build that no untrusted network can route to is not on that path at all — so a vulnerability-management program that reports ColdFusion remediation as a build number has scored the wrong condition. The operational test this entry requires runs from outside: from each untrusted origin the panel could be reachable from, request the admin API / PMS servlet paths against every ColdFusion host and record whether anything answers, and report that result alongside the build level rather than in place of it. Precondition, and it is the one that makes this test worth anything: a reachability check proves only what is unreachable from the vantage point actually used. A host that one scan origin cannot route to may still answer through a cloud load-balancer rule, a partner link, a management VPN, or a hostname the scan never resolved, so a clean result from a single origin is not an exposure verdict — and an exposure check that has never returned a positive against a host known to be published is a broken check rather than a clean estate, and must be proven against a known-reachable instance before any absence is believed. The check also has to be applied retrospectively: the primitive is an arbitrary file read and exploitation is confirmed, so a host that answered externally at any point in the exposure window has to be handled as having served its files, which no version-based verdict will ever surface.",
+        "evidence": "Packet fields for CVE-2024-20767: the vector states 'ColdFusion versions 2023.6, 2021.12 and earlier are affected by an Improper Access Control vulnerability that could result in arbitrary file system read' and, separately, 'Exploitation of this issue requires the admin panel be exposed to the internet'; attack_vector records an unauthenticated attacker reading arbitrary files via the ColdFusion admin API/PMS servlet, 'exposed only because the admin panel itself was reachable from the internet'. cisa_kev true with kev_date 2024-12-16; active_exploitation confirmed; poc_available true; cvss 7.4; rwep_score 70; patch_available true. The citing gaps this addresses are the remediation-and-handling ones recorded on the entry: AU-Essential-8-Patch (Patch operating systems), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-management (Vulnerability handling).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-50623": {
     "name": "Cleo Multiple Products Unrestricted File Upload Vulnerability",
@@ -41590,7 +42314,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",
@@ -41793,7 +42541,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",
@@ -42047,7 +42817,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",
@@ -42146,7 +42939,31 @@
         "adequate": false,
         "gap": "Least-functionality controls that still permit the Flash browser plugin leave this client-side RCE reachable; the plugin must be removed, not merely patched."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "A vendor fix for this specific CVE exists — the packet's vector names the fixed Flash Player builds per platform — but the product carrying it has no ongoing patch path, so reaching a fixed build is an interim state and removing the Flash Player runtime is the terminal one. Applied here: enumerate every host that still has an Adobe Flash Player runtime installed and carry each to uninstall on a bounded, dated schedule rather than an open-ended risk acceptance. Until removal completes, block Flash content at the browser and the web gateway, because the packet's path begins with a user loading a page that serves a crafted SWF — an SWF that never reaches the runtime never reaches the ExternalInterface memory-corruption sink. Precondition, and the reason the block is a holding measure and not the fix: it covers only the browsing paths it actually mediates, and the vulnerable runtime stays installed and reachable by any SWF that gets to it through a path the policy does not sit on. Scope this to the Adobe Flash Player runtime the packet names; the packet ties the ExternalInterface sink to that product and gives no mapping into other browser plugins or media runtimes, so treating every plugin in the estate as an instance of this CVE manufactures removal work against software no evidence implicates. Distinguishing test: on a representative host, confirm the Flash runtime is absent rather than confirming the browser is configured to block it — a machine whose browser blocks Flash while the runtime remains installed still carries the vulnerable code, and a record that stops at 'this host is on the fixed build' marks a product that will receive no fix for anything found after that build as compliant.",
+        "evidence": "The packet places the flaw in the ExternalInterface ActionScript functionality of Adobe Flash Player (CWE-787, CWE-119) and describes the attack as luring a user to a page serving a malicious SWF, corrupting memory and executing arbitrary code in the Flash Player process; CVSS 8.8, RWEP 48, poc_available false, active_exploitation confirmed, CISA KEV-listed 2024-09-17. The entry cites NIST-800-53-CM-7 (Least Functionality) and AU-Essential-8-App-Hardening as insufficient, and its own framework_coverage for CM-7 records least-functionality controls that still permit the Flash browser plugin as leaving this client-side RCE reachable, with the plugin needing to be removed rather than merely patched. Its defense chain records the product as end-of-life and states that only decommissioning removes the exposure.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock for this entry opened on the 2024-09-17 KEV listing, and the 'verified mitigation' it demands cannot be a version bump: the entry records the product as end-of-life with no ongoing patch path, so the mitigation that satisfies the clock is removal of the Flash Player runtime from the host, or — where removal cannot complete inside the window — a documented, time-bound block of Flash content at the browser and gateway carrying a removal date. Why this has to be stated explicitly for a 2013 CVE is visible in the packet's own dates: the vector records exploitation in the wild in February 2013 and names the builds that fixed it, and CISA still listed the flaw in 2024 with confirmed in-the-wild exploitation — which only happens against installs that never reached those builds and were never removed. A vulnerability-management programme that reads this entry as 'get to the fixed build within the SLA' closes its ticket on a runtime that is frozen at a decade-old security state. Distinguishing test: for each host the KEV clock covers, produce evidence the runtime is gone, or that the content block is in force with a dated removal plan attached, rather than evidence that an installed version number is at or above the fixed build.",
+        "evidence": "The packet records CISA KEV listing on 2024-09-17 with active_exploitation confirmed, while its vector states the flaw was exploited in the wild in February 2013 and names the builds that fix it. patch_available is true and live_patch_notes records 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' RWEP 48 against CVSS 8.8, poc_available false. The entry cites ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management as insufficient, and its defense chain records removal — not patching — as the prevention step because the product is end-of-life.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2013-0643": {
     "name": "Adobe Flash Player Incorrect Default Permissions Vulnerability",
@@ -42612,7 +43429,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",
@@ -42720,7 +43569,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",
@@ -43575,7 +44446,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",
@@ -43900,7 +44795,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",
@@ -45248,7 +46169,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",
@@ -46227,7 +47162,40 @@
         "adequate": false,
         "gap": "Boundary protection frequently leaves the EMS FmDatabaseServer TCP/8013 reachable; exposing that service to untrusted networks is the precondition for exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The vulnerable surface on this product is not the EMS web console but FmDatabaseServer on TCP/8013: a non-HTTP listener that answers before any authentication and whose own input handling is the defect, which is exactly why a deployment audited on web-tier hardening and perimeter firewall rules can be fully exposed. Applied to FortiClient EMS, the control means TCP/8013 on every EMS host accepts connections only from hosts with an operational need to speak that protocol to it — the endpoint population EMS serves and the management network — enforced by a host firewall on the EMS server or a network ACL in front of it, rather than inherited from the assumption that EMS sits on an internal network. The least-privilege gap recorded against this entry is not closable on this path and should not be attempted: the packet's attacker is unauthenticated and never holds an EMS account, so per-account privilege scoping is never consulted and that attestation passes cleanly while the injection runs to SYSTEM. Distinguishing test: from a general user or server VLAN with no endpoint-registration or administrative role, open a TCP connection to 8013 on a staging EMS and confirm it is refused before the listener parses anything — an estate that can show every EMS administrator authenticates, and that the appliance is filtered at the perimeter, still hands this listener to anything that can route to it internally. Precondition: reachability restriction bounds who can send the crafted packet, it does not repair the SQL handling. Any host inside the permitted set — including a compromised endpoint that legitimately talks to EMS — still reaches the injection, and the restriction is unavailable across the part of the path where endpoints must reach the listener for the product to function. Repairing the parsing itself is what the vendor update does; the packet records that update as available and as requiring no reboot.",
+        "evidence": "Packet: an unauthenticated attacker sends specially crafted packets to the FortiClient EMS FmDatabaseServer (TCP/8013) with SQL injected into the FCTUID field (CWE-89), enabling and invoking xp_cmdshell to run arbitrary commands as SYSTEM on the EMS host. Affected versions named in the packet: FortiClientEMS 7.2.0 through 7.2.2 and FortiClientEMS 7.0.1 through 7.0.10. CISA KEV-listed 2024-03-25, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 74. patch_available true; live_patch_available false, with live_patch_notes stating there is no live-patching primitive for this product and that the vendor update (no reboot required) is the remediation. NIST-800-53-AC-6 (Least Privilege) appears among the citing gaps for this entry, while the packet's path requires no authentication.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "The affected asset here is a security product's own management server, and this CVE is the case the control exists for: compromise of that server yields SYSTEM on the host that administers endpoints, and the builds the packet names (FortiClientEMS 7.2.0-7.2.2 and 7.0.1-7.0.10) sit on a vendor product track that most estates patch on a product cadence rather than on the KEV cadence they apply to operating systems — which is why the flaw-remediation and technical-vulnerability-management attestations on this entry can read clean while an affected EMS stays in service. The requirement for this product is that every EMS instance is enumerated in the vulnerability-management inventory as privileged software with an operating-system-grade SLA, treated as an asset with attack surface rather than as a defense that is assumed sound, and that each instance's reported version is compared against the vendor's fixed release with the clock running from the 2024-03-25 KEV listing. The packet leaves little room for deferral: it records a vendor update as available, no live-patching primitive, and no reboot required, so remediation is a service-level update on the EMS host rather than a fleet-wide maintenance event. Precondition: this control gets the fixed code onto the host and nothing more. It says nothing about what happened during the exposure window, so on any EMS whose 8013 listener was reachable while the flaw was unpatched the update has to be paired with a compromise assessment — SYSTEM-level command execution leaves artifacts that installing the fixed build does not remove.",
+        "evidence": "Packet: the product is Fortinet FortiClient EMS, affected in versions 7.2.0 through 7.2.2 and 7.0.1 through 7.0.10; the documented chain ends in arbitrary commands executing as SYSTEM on the EMS host. CISA KEV-listed 2024-03-25, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 74. patch_available true; live_patch_available false, with live_patch_notes recording no live-patching primitive for this product and the vendor update (no reboot required) as the remediation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "SYSTEM on an EMS host is control of the console that administers endpoints, so response to this CVE cannot end at the EMS server. The playbook's trigger has to be exposure rather than an alert: any EMS on an affected build (7.2.0-7.2.2, 7.0.1-7.0.10) whose TCP/8013 listener was reachable between the 2024-03-25 KEV listing and the update landing gets triaged, because the packet's path produces no failed logon and no account event at all — the attacker never authenticates, which is exactly why monitoring built around identity telemetry sees nothing. The detection that does key on the documented behaviour has three signals: connections to 8013 on the EMS host from sources outside the population that legitimately speaks to it, the database service's configuration being changed to enable xp_cmdshell, and process creation as SYSTEM parented by the EMS database service. Where any of those are present, the playbook has to cover what SYSTEM on that host reaches: the EMS database contents and any credentials held in them, the deployment and configuration actions the console issued during the window, the endpoint-facing artifacts it distributes, and rotation of every credential the EMS host held or could reach. Precondition: this is a post-exposure control. It prevents no injection and does not substitute for the vendor update the packet records as available, and its triage list only reaches the endpoints and credentials the inventory can name — anything the console administers that is missing from that inventory stays unexamined.",
+        "evidence": "Packet: the chain ends with arbitrary commands executing as SYSTEM on the EMS host, reached by an unauthenticated attacker who injects SQL into the FCTUID field on FmDatabaseServer (TCP/8013) and thereby enables and invokes xp_cmdshell. active_exploitation confirmed, poc_available true, CISA KEV-listed 2024-03-25, CVSS 9.8, RWEP 74. Affected builds per the packet: FortiClientEMS 7.2.0 through 7.2.2 and 7.0.1 through 7.0.10. patch_available true, live_patch_available false, live_patch_notes recording the vendor update (no reboot required) as the remediation.",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-27198": {
     "name": "JetBrains TeamCity Authentication Bypass Vulnerability",
@@ -47270,7 +48238,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",
@@ -47408,7 +48399,30 @@
         "adequate": false,
         "gap": "System-security assurance credits the WebKit/Safari sandbox; a renderer type-confusion undermines that assumption absent additional exploit-mitigation controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet's fix list is nine parallel builds, not one — Safari 17.3, iOS/iPadOS 15.8.7, iOS/iPadOS 16.7.5, iOS/iPadOS 17.3, macOS Monterey 12.7.3, macOS Ventura 13.6.4, macOS Sonoma 14.3, tvOS 17.3 and visionOS 1.0.2 — so for this CVE the control means the management platform drives each enrolled device to the fixed build for the OS major that device is actually on, on the clock that opened with the 2024-01-23 KEV listing, with user deferral disabled rather than discouraged. Two properties of this entry decide whether that succeeds. First, the packet records no vendor live-patch mechanism and states remediation requires applying the fixed release and rebooting: a device that has downloaded or even installed the update but has not restarted is still running the vulnerable WebKit and must be counted as exposed. On user-carried handsets the restart is the step most often deferred, and a deferral recorded as 'updated' is the specific way this remediation goes wrong. Second, tvOS 17.3 and visionOS 1.0.2 sit in the same fix list as the phones and laptops; an update SLA scoped to iPhone, iPad and Mac leaves those two builds unaddressed while the flaw-remediation attestation reads clean. Distinguishing test: enumerate the installed build and the last-restart time per enrolled device and compare each against the fixed build for that device's own OS major — not against 'latest available' and not against the console's 'deployed' or 'approved' state, both of which report success on a host that has never restarted. Precondition: this lever reaches only enrolled devices the platform can compel, which is why it is paired here with the access-condition control rather than presented as complete coverage; a personally-owned or unenrolled device carrying organizational data is outside it entirely.",
+        "evidence": "Packet: CISA KEV-listed 2024-01-23, active_exploitation confirmed, CVSS 8.8, RWEP 60, poc_available false. patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The packet's vector names the fixed builds as 'Safari 17.3, iOS 15.8.7 and iPadOS 15.8.7, iOS 16.7.5 and iPadOS 16.7.5, iOS 17.3 and iPadOS 17.3, macOS Monterey 12.7.3, macOS Sonoma 14.3, macOS Ventura 13.6.4, tvOS 17.3, visionOS 1.0.2' and states 'Processing maliciously crafted web content may lead to arbitrary code execution.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet states the update 'brings that fix to devices that cannot update to the latest iOS version', so this estate provably contains hardware that will not reach the current OS major. The compliance floor for this CVE is therefore a per-major table — iOS/iPadOS 15.8.7, 16.7.5 and 17.3; macOS 12.7.3, 13.6.4 and 14.3; Safari 17.3; tvOS 17.3; visionOS 1.0.2 — not a single number. A policy keyed to 'latest iOS' marks a correctly-remediated 15.8.7 device permanently non-compliant and buries the devices that actually matter; a policy keyed only to major version passes an unpatched 17.x device. The control's requirement is that this per-major floor operate as an access condition — mail, VPN and document access refused to a device below the floor for its own major — rather than as a row on a patch-compliance report, because the packet's attack path needs only that the user open attacker-controlled web content in Safari or any WebKit-based renderer, which is ordinary daily use on exactly the devices least likely to be current. Distinguishing test: enrol a device pinned one build below the floor for its major and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its mail and VPN has recorded the exposure rather than removed it. Preconditions, stated rather than assumed: denying access bounds what organizational data an exploited device can reach — it does not remove the vulnerable renderer from the device, so the user's personal browsing on that handset still reaches the sink, and it does nothing for a device compromised during the exposure window, which belongs on the incident path. It is also a holding measure only until the fixed release and its required restart land on that device. And for hardware that cannot take the current major, reaching the backported build is the ceiling that hardware allows for this CVE, not a resting state: those units need a dated replacement schedule, because a floor that can only ever name backported builds marks aging hardware compliant while everything not backported accumulates against it.",
+        "evidence": "Packet: vector states 'This fix associated with the Coruna exploit was shipped in iOS 17.3 on January 22, 2024. This update brings that fix to devices that cannot update to the latest iOS version,' and lists fixed builds across Safari 17.3, iOS/iPadOS 15.8.7, 16.7.5 and 17.3, macOS Monterey 12.7.3, Sonoma 14.3, Ventura 13.6.4, tvOS 17.3 and visionOS 1.0.2. Attack vector: 'A victim opens attacker-controlled web content in Safari or any WebKit-based renderer; the content triggers a type confusion in WebKit, letting the attacker execute arbitrary code in the browser process as a foothold on the device.' CWE-843; CISA KEV-listed 2024-01-23 with active_exploitation confirmed; poc_available false, so there is no public exploit artifact for a signature to key on and prevention carries the weight; patch_available true with live_patch_available false and live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-34048": {
     "name": "VMware vCenter Server Out-of-Bounds Write Vulnerability",
@@ -48423,7 +49437,31 @@
         "adequate": false,
         "gap": "Application-hardening guidance focuses on macro/Office hardening on endpoints, not on server-side spreadsheet parsers that eval format strings."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The vulnerable code here is a third-party Perl module, and the packet's exploitation path is 'a service embedding Spreadsheet::ParseExcel' — so an operator's exposure is a property of software it bought or built on, not of anything its own package list names. Bound to this CVE, the requirement is that the component inventory resolve to the depth at which Spreadsheet::ParseExcel actually sits — inside an appliance image, a container layer, or a vendor product that ingests spreadsheets — and record the module version, obtained from the supplier's SBOM or a direct written answer wherever the operator cannot inspect the image itself. Hold the scope there: the packet ties the string-eval sink to this module and the services embedding it, and provides no mapping from the defect into other spreadsheet-parsing code, so widening the sweep to every library in the estate that reads Excel files manufactures findings and rework against components no evidence implicates. The vulnerability-management and flaw-remediation controls cited as insufficient for this entry fail at their input rather than in their process: both act on an asset register, and a module bundled three levels down never reaches one, so the programme can be fully conformant and never open a ticket for a KEV-listed remote code execution it is running every day. Distinguishing test: for each product in the estate that ingests spreadsheets, ask whether it embeds Spreadsheet::ParseExcel and at what version, and require the answer to come from the supplier — because querying the operator's own package manager returns 'not installed' on a fully exposed system, which is the specific way this check gets recorded as clean. Precondition and limit: inventory is visibility, not remediation. The packet records a vendor fixed release as available and no live-patch mechanism, so every copy the inventory surfaces still has to be taken to that release by whoever controls it; for a bundled copy that is the embedding vendor, and until they ship it the operator's position is a known-exposed parsing path to be constrained, not a closed finding.",
+        "evidence": "Packet: 'Spreadsheet::ParseExcel version 0.65 is a Perl module used for parsing Excel files. Spreadsheet::ParseExcel is vulnerable to an arbitrary code execution (ACE) vulnerability due to passing unvalidated input from a file into a string-type \"eval\"', with the issue stemming from evaluation of Number format strings within the Excel parsing logic; attack vector records that the code executes when 'a service embedding Spreadsheet::ParseExcel parses the file'; CWE-95 and CWE-94; CISA KEV-listed 2024-01-02 with active_exploitation confirmed and poc_available true; RWEP 66 / CVSS 7.8; patch_available true and live_patch_available false, with the live-patch note recording that 'remediation requires applying the vendor fixed release'. ISO 27001:2022 A.8.8, NIST 800-53 SI-2 and DORA Art.9 are the framework controls recorded as insufficient for this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-116",
+        "name": "MULTI-TRIGGER-DEPENDENCY-EXECUTION-POLICY",
+        "description": "This CVE adds a dependency-execution trigger that no policy enumerates: document-parse time. The packet has the module passing a Number-format string out of an attacker-crafted Excel file into a Perl string eval, so the attacker's code runs when a service performs an ordinary data-processing operation on a business document — not when the dependency is installed, imported, or built. Every safeguard an estate is likely to hold is keyed to a moment that is never reached: ignore-scripts defaults and lockfile pinning govern install time, build sandboxes govern compile time, and none of them is consulted when a mail-handling service, a reporting job, or an upload handler opens the attachment. Applied here, the policy must list document/data-parse time alongside install, import and build time as an execution trigger, and every service that feeds files into Spreadsheet::ParseExcel must run under an identity scoped to that job alone — no credentials the parse itself does not need, no interactive shell, and constrained egress — so that code executed out of a format string lands somewhere that cannot reach the estate's secrets or call outward. The user-application-hardening control cited as insufficient here is aimed at a different machine entirely: it governs macro, OLE and add-in behaviour in an Office client on a user's endpoint, while this code executes inside a server-side Perl process with that service's privileges, on a file no person may ever open. Distinguishing test: feed a file whose Number-format string carries a Perl payload to a staging instance of each service that parses spreadsheets through this module, and confirm from the service account's own context that the payload can neither read credentials nor open an outbound connection — an attestation covering endpoint Office hardening passes cleanly while the server-side parse path executes attacker code unimpeded. Precondition: this constrains what the executed code can reach; it does not stop the execution. The packet records a vendor fixed release with no live-patch path, so every copy still has to be taken to that release, and the least-privilege identity is worth nothing on a service whose parse job simply inherited the application's main credentials — which is the normal case, and the thing to change first.",
+        "evidence": "Packet: the flaw stems from 'the evaluation of Number format strings (not to be confused with printf-style format strings) within the Excel parsing logic', passing unvalidated input from a file into a string-type eval; attack vector records that an attacker crafts an Excel file whose Number-format string contains Perl code and the module executes it when a service embedding Spreadsheet::ParseExcel parses the file; CWE-95 and CWE-94; KEV 2024-01-02, active_exploitation confirmed, poc_available true; patch_available true, live_patch_available false, remediation is applying the vendor fixed release. AU Essential Eight user application hardening, NIS2 Art.21 security of network and information systems, and UK CAF B4 (System security) are the framework controls recorded as insufficient for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-7024": {
     "name": "Google Chromium WebRTC Heap Buffer Overflow Vulnerability",
@@ -49747,7 +50785,32 @@
         "adequate": false,
         "gap": "Applying vendor patches within the ISM timeframe still leaves the zero-day window uncovered; the control does not mandate the EDR/exploit-guard telemetry that would catch DWM token abuse."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Desktop Window Manager (DWM) Core Library and describes an attacker who already holds a low-privilege foothold abusing an untrusted-pointer / memory-corruption flaw to move from the Window Manager\\DWM context the packet names to SYSTEM. The escalation starts from an account the host already accepts, so nothing in the account model is being abused — a privilege boundary inside the component is failing. For this CVE the control means driving the Windows update carrying the DWM Core Library fix across every affected host on the clock that opened with the 2023-11-14 KEV listing rather than folding it into the next monthly rollup, with completion measured per host by the installed build against the fixed build for that Windows release, not by 'approved' or 'downloaded' in the management console. The packet records no vendor live-patch mechanism and remediation requiring the fixed release plus a reboot, so a host that has installed the update but not restarted is still running the vulnerable library and has to be counted as exposed; on a shared workstation or session host that restart is the step most likely to be deferred because taking it evicts logged-on users, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Enumerate first the hosts where an unprivileged interactive logon is the normal operating state, because that is where the exploit's stated precondition — an existing low-privilege foothold — is met continuously rather than exceptionally. The control's second half is the load-bearing one here: the entry cites NIST-800-53-AC-6 as insufficient and it is, because the attacker is a local user by precondition and tightening what that account may do does not contain a flaw that hands it SYSTEM, which is why a least-privilege attestation passes cleanly while the escalation stays fully available.",
+        "evidence": "Packet: CISA KEV-listed 2023-11-14, active_exploitation confirmed, CVSS 7.8, RWEP 59, CWE-822 / CWE-119. attack_vector: 'After gaining a low-privilege foothold, an attacker abuses a memory-corruption / untrusted-pointer flaw in the DWM Core Library to escalate from the Window Manager\\DWM context to SYSTEM.' patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' NIST-800-53-AC-6 (Least Privilege), NIST-800-53-SI-2 (Flaw Remediation), ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, AU-ISM-1546 and UK-CAF-B4 are all recorded as insufficient controls on this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-ISM-1546",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Bound to this CVE, the signal to instrument is the one transition the packet actually documents: a process running in the Window Manager\\DWM context, or under an ordinary interactive user, obtaining SYSTEM on a host where no legitimate elevation path — an operator-consented UAC elevation, a service start by the Service Control Manager, a scheduled-task launch — accounts for it. Alerting keys on that token/integrity-level transition and on the SYSTEM-integrity child processes that follow it. Two other signals are the wrong answer and both are worth naming, because they are the ones a rule-writer reaches for by default. A rule keyed on an exploit artifact's hash, command line or loaded-module set cannot exist honestly here: the packet records poc_available false, so there is no public exploit to derive a signature from and any such rule would be built from an assumption. A rule keyed on dwm.exe crashing is worse than useless, because the packet describes the untrusted-pointer flaw being abused to escalate, not to fault — a working exploit produces a privilege transition and no crash, so the rule stays silent through exactly the case it was written for. Instrumentation is user-mode process and token telemetry: the packet places the flaw in the DWM Core Library, not in a kernel driver, so driver-load and kernel-callback signals do not observe this path. The distinguishing test is to force a benign SYSTEM-token acquisition from an unprivileged interactive process on a staging host and confirm the alert fires from the transition alone, with no exploit sample present. Preconditions: this detects, it does not prevent — by the time the alert exists the escalation has already happened, so it cannot be recorded as this CVE's mitigation, which the packet gives as the vendor fixed release plus a reboot. And it covers only hosts where the telemetry is deployed and reporting, a smaller population on any real estate than the one the patch report counts.",
+        "evidence": "Packet: attack_vector documents the escalation 'from the Window Manager\\DWM context to SYSTEM' following a low-privilege foothold, and locates the flaw in the DWM Core Library. poc_available is false. active_exploitation is confirmed and the entry is CISA KEV-listed 2023-11-14. NIST-800-53-SI-4 (System Monitoring) is recorded as an insufficient control on this entry. Remediation per live_patch_notes is applying the fixed release and rebooting; live_patch_available is false.",
+        "gap_closes": [
+          "NIST-800-53-SI-4"
+        ]
+      }
+    ]
   },
   "CVE-2023-36025": {
     "name": "Windows SmartScreen Security Feature Bypass",
@@ -49873,7 +50936,32 @@
         "adequate": false,
         "gap": "The 48-hour patch-exploited-flaw target still leaves the zero-day window open, and the control does not mandate the kernel/EDR telemetry that would surface driver-level escalation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet puts the attacker on the host already — from a low-privilege foothold, driving crafted placeholder and reparse-point operations into the Cloud Files Mini Filter Driver to reach a heap-based buffer overflow and land as SYSTEM. The account is legitimate throughout and no boundary between users is crossed, so nothing in the account model is being abused: a privilege boundary inside a Windows driver is failing. For this CVE the control means the Windows update carrying the fix is driven across the affected estate on the clock that opened with the 2023-11-14 KEV listing rather than folded into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU — not by 'approved', 'downloaded' or 'deployed' in the management console. The packet records no vendor live-patch mechanism and states remediation requires applying the fixed release and rebooting, so a host that has installed the update but not restarted is still running the vulnerable driver and must be counted as exposed; a pending-reboot host reported as patched is the specific way this remediation goes wrong. The population to enumerate is the general Windows workstation estate rather than one server role: the packet names a Windows driver component and states only one precondition — a low-privilege foothold — which is the normal operating state of any machine where ordinary users hold interactive sessions. The control's second half is the load-bearing one here. Because the attacker is already an authorized local user, tightening per-account privilege does not contain the escalation, which is exactly why the least-privilege gap cited on this entry can pass a clean attestation while the flaw remains fully exploitable. Priority follows the packet rather than the 7.8 CVSS band: confirmed in-the-wild exploitation of a foothold-to-SYSTEM step makes this a chain-containment item, not a routine endpoint ticket.",
+        "evidence": "Packet: CWE-122 and CWE-787; CISA KEV-listed 2023-11-14 with active_exploitation confirmed; CVSS 7.8, RWEP 59; poc_available false. Attack vector: 'From a low-privilege foothold, an attacker triggers a heap-based buffer overflow in the Cloud Files Mini Filter Driver via crafted placeholder/reparse-point operations, escalating to SYSTEM.' patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' NIST-800-53-AC-6 (Least Privilege) is among the framework control gaps citing this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "The monitoring gap cited on this entry is the one the patch clock does not close, and its shape here is set by a specific packet fact: poc_available is false while active exploitation is confirmed, so there is no public exploit for a tool signature or hash to key on and only the behaviour the packet describes is available to detect. Two signals follow from it directly. First the operation: repeated crafted placeholder and reparse-point operations against the Cloud Files Mini Filter Driver issued by a process with no cloud-sync role — the processes that legitimately drive the cloud-files placeholder path on a host are its sync clients and the shell, so the same operations arriving from an unrelated user process are the anomaly, and a heap-overflow attempt against a driver is far likelier to be repeated than single-shot, which makes the repetition itself part of the signal. Second the outcome: a privilege transition with no corresponding authorized elevation — an already-running non-elevated process coming to hold a SYSTEM token, or a SYSTEM-level child spawned by a non-elevated parent — correlated back to the process that issued those driver operations, which is what turns an alert into the initial-access foothold a responder can pivot from. The control's 60-second alerting requirement is what makes this useful, because the escalation exists to precede the attacker's next action rather than to be the action. Preconditions and limits, stated because they change what this control can be recorded as achieving: it is post-hoc — it fires after SYSTEM has already been obtained, so it bounds dwell time rather than preventing the escalation, and it is not a substitute for the reboot-gated update. It also misses an exploit that uses the acquired token in-process without spawning anything, which is why the driver-operation signal must be collected in its own right and not merely as context attached to a process-spawn alert. And a host whose endpoint telemetry is not collected at kernel-object and process-token granularity produces neither signal at all, so estate coverage has to be verified on a sample rather than assumed from the agent's install count.",
+        "evidence": "Packet: poc_available false with active_exploitation confirmed and CISA KEV listing 2023-11-14 — exploitation is occurring without a public exploit artifact to signature. Attack vector: 'From a low-privilege foothold, an attacker triggers a heap-based buffer overflow in the Cloud Files Mini Filter Driver via crafted placeholder/reparse-point operations, escalating to SYSTEM' — the driver operations and the privilege transition are both stated behaviours. CWE-122 (heap-based buffer overflow) and CWE-787. NIST-800-53-SI-4 (System Monitoring) is among the framework control gaps citing this CVE. patch_available true with live_patch_available false and live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting,' so detection covers the window until each host has been restarted onto the fixed build.",
+        "gap_closes": [
+          "NIST-800-53-SI-4"
+        ]
+      }
+    ]
   },
   "CVE-2023-47246": {
     "name": "SysAid Server Path Traversal to Code Execution",
@@ -50565,7 +51653,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",
@@ -50622,7 +51742,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",
@@ -51364,7 +52516,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)",
@@ -51421,7 +52605,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",
@@ -52888,7 +54088,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",
@@ -52949,7 +54172,39 @@
         "adequate": false,
         "gap": "Periodic technical-vulnerability management cannot compel the emergency out-of-band upgrade to 6.9.5 / 7.0.2 that a KEV-listed unauthenticated RCE with a 3-day remediation window demands."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives an unauthenticated path from the open internet to remote code execution on a default WordPress install, so the clock this control sets is what stands between the 2026-07-21 KEV listing and a site being taken. The remediation the packet names is upgrading to 6.9.5 or 7.0.2, and the specific failure mode for this CVE is treating the forced automatic security update WordPress.org enabled as coverage. That push is a delivery mechanism, not an inventory: completion has to be measured per site by the core version each install actually reports, so that sites with core auto-updates disabled, deployed on a read-only filesystem, or built through a pipeline that pins core are surfaced as still vulnerable instead of assumed carried by the vendor. Scope the enumeration to the WordPress installs the organisation operates — including the ones that never reached an application inventory, such as campaign microsites, documentation and event sites, and multisite networks where one core version serves many hostnames — and not to web software generally; the packet ties this defect to the WordPress REST batch endpoint and implicates nothing else. The distinguishing test: pull the reported core version from every site the organisation serves and confirm each is at or above the fixed release, rather than confirming that automatic updates are enabled in policy — a policy attestation reads clean on an install whose updater has been disabled for years. Precondition: reaching the fixed version closes the dispatch defect for requests arriving afterwards and nothing more. Exploitation is confirmed and a public exploit exists, so for a site that was internet-reachable before the upgrade landed, the version bump is the start of the response, not the end of it.",
+        "evidence": "Packet: CISA KEV-listed 2026-07-21, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 79, CWE-436. vector: 'WordPress Core REST API batch endpoint (/wp-json/batch/v1) has an array-desynchronization interpretation conflict that misroutes handler dispatch, letting an unauthenticated attacker bypass validation to perform SQL injection and achieve remote code execution.' patch_available true; live_patch_available false; live_patch_notes: 'No live-patch mechanism; WordPress.org enabled forced automatic security updates. Remediation is upgrading to 6.9.5 / 7.0.2; interim mitigation is WAF-blocking /wp-json/batch/v1.' AU-Essential-8-Patch, NIST-800-53-SI-2, ISO-27001-2022-A.8.8 and UK-CAF-B4 are recorded as insufficient controls on this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet names an interim mitigation — WAF-blocking /wp-json/batch/v1 — alongside the fixed releases 6.9.5 and 7.0.2, and this control exists to stop the first being recorded as the second. A site running the WAF rule on a pre-fix core is in state (b): the batch endpoint's array-desynchronization defect is untouched and what stands between an attacker and it is a request-matching rule, whose failure reopens unauthenticated remote code execution in full. Carry that on the compliance record as its own state with a dated action item to reach the upgrade, rather than closing the finding as remediated. The preconditions that must travel with the rule, stated rather than assumed: it covers only requests that actually traverse the WAF, and only those its pattern matches. An origin reachable directly by IP or by a hostname that does not resolve through the proxy is unprotected; so is any route to the same REST handler that the pattern does not anticipate. And the reason that second precondition is sharper here than for an ordinary WAF-mitigated CVE is the defect itself — an interpretation conflict that desynchronizes handler dispatch is a disagreement about what a request means, which is precisely the assumption a request matcher in front of the handler depends on. Treat the rule as bounding exposure, never as removing the endpoint. The distinguishing test: from outside the network, send a batch-endpoint request to the site's origin address rather than through the WAF-fronted hostname, and confirm it is refused — a site whose audit record reads 'mitigated' while the origin answers directly is in state (c) and does not know it.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism; WordPress.org enabled forced automatic security updates. Remediation is upgrading to 6.9.5 / 7.0.2; interim mitigation is WAF-blocking /wp-json/batch/v1.' live_patch_available false; patch_available true. vector and attack_vector describe an 'interpretation conflict' / 'array-desynchronization' in the /wp-json/batch/v1 endpoint that 'misroutes handler dispatch', letting an unauthenticated attacker bypass validation. CVSS 9.8, RWEP 79, poc_available true, active_exploitation confirmed, KEV-listed 2026-07-21. NIST-800-53-SI-2 (Flaw Remediation) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as insufficient controls on this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's chain does not stop at code execution: the attacker bypasses validation, smuggles the CVE-2026-60137 SQL injection, forges an administrator account, and uploads a malicious plugin. Each of those is persistence that lives in the site's own database and filesystem, and upgrading to 6.9.5 or 7.0.2 removes none of them — a forged administrator is still a valid account after the upgrade, and an uploaded plugin is still loaded on the next request. An internet-facing WordPress install that takes a pre-auth RCE is in the same position this control was written for even though it is not a network appliance: the system that was breached is the system whose own records would have to be trusted to report the breach. So with exploitation confirmed and a public exploit available, an install that was serving before the fix landed is handled as possibly-compromised rather than closed on the version bump. Enumerate administrator and other privileged accounts with their creation times, compare the installed plugin set against a known-good manifest, and rotate what the exposed install held — database credentials, the site's authentication keys and salts, and any API keys or tokens stored in its configuration, since the SQL injection in the chain reaches the same database that holds them. Where those checks cannot be made conclusive, rebuild from a known-good baseline and re-import content instead of inheriting the running filesystem. Precondition, and the sequencing matters: this is the response for an install exposed during the window, not a substitute for the upgrade. Running the eviction work while the site is still on a pre-fix core hands the attacker the same path straight back in, so the upgrade — or, failing that, the packet's interim WAF block on /wp-json/batch/v1 with its own limits understood — goes first, and the account, plugin and credential work follows it.",
+        "evidence": "Packet attack_vector: 'An interpretation conflict in the WordPress REST batch endpoint desynchronizes handler dispatch, letting an unauthenticated attacker bypass validation, smuggle the CVE-2026-60137 SQLi, forge an administrator, and upload a malicious plugin for RCE on default installs (wp2shell).' active_exploitation confirmed; poc_available true; CISA KEV-listed 2026-07-21; CVSS 9.8, RWEP 79. patch_available true with live_patch_notes naming 6.9.5 / 7.0.2 as the remediation and WAF-blocking /wp-json/batch/v1 as the interim mitigation. NIS2-Art21-incident-handling (Incident handling) is recorded as an insufficient control on this entry.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2026-0770": {
     "name": "Langflow Inclusion of Functionality from Untrusted Control Sphere Vulnerability",
@@ -53010,7 +54265,42 @@
         "adequate": false,
         "gap": "Technical-vulnerability management cannot drive a patch that the vendor has not shipped; without a fixed release it does not compel the compensating network isolation and endpoint removal that actually stop exploitation of this unauthenticated exec() surface."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-103",
+        "name": "AI-APP-BUILDER-EXECUTION-ENDPOINT-AUTH-AND-SANDBOX",
+        "description": "Langflow is the visual LLM app/agent builder this control names, and CVE-2026-0770 is the precise defect it forbids: /api/v1/validate/code answers an unauthenticated POST and validate_code() hands the request body straight to exec(), with an exec_globals context that still exposes importlib and builtins, so attacker-supplied Python runs as the Langflow process — root in a default container. Bound to this product the requirement is that no route reaching that exec() sink answers an unauthenticated caller, and that any code the platform evaluates on a user's behalf runs with no filesystem, network or process reach beyond the flow's intent, instead of inside the server's own interpreter. Precondition, which is where this control is normally over-claimed: the packet records no patched version, so an operator cannot establish that property by updating. What they can do is what the packet names — block or remove exposure of /api/v1/validate/code at the reverse proxy, network-isolate the instance, and keep port 7860 off untrusted networks. That bounds who can send the POST; it does not repair the sink, it holds only for the routes the proxy actually fronts, and it is unavailable wherever the builder must stay reachable for normal use. It also does nothing for an instance already exploited: because exploitation is confirmed and the observed activity steals AWS credentials and cloud metadata, an instance that was reachable during the exposure window needs the container's cloud identity rotated and the flows and container rebuilt, not merely fronted with a new proxy rule. Distinguishing test: from an unauthenticated client against a staging instance, POST to /api/v1/validate/code a payload that imports a module and opens a network connection, and confirm it is refused before any code runs — an attestation that the AI platform is 'hardened' passes cleanly while a reachable 7860 keeps an unauthenticated exec() live.",
+        "evidence": "Packet vector: Langflow exposes an unauthenticated /api/v1/validate/code endpoint whose validate_code() passes attacker-supplied Python to exec() with an exec_globals context exposing importlib and builtins, yielding remote code execution as the Langflow process; attack_vector adds 'root in default containers' and that observed exploitation steals AWS credentials and cloud metadata. CWE-829, CVSS 9.8, RWEP 82, poc_available true, active_exploitation confirmed, CISA KEV-listed 2026-07-21. patch_available false and live_patch_available false; live_patch_notes record GHSA-g22f-v6f7-2hrh with first_patched_version: null, that ZDI published this as a zero-day, that a fixed release could not be confirmed from a primary source, that the CISA KEV required action is vendor mitigation or product discontinuation, and that the compensating controls are blocking/removing /api/v1/validate/code exposure, network-isolating Langflow, and not exposing port 7860 to untrusted networks.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this CVE the three-state distinction is not a refinement, it is the whole finding: state (a) is unreachable. The packet records patch_available false, GHSA-g22f-v6f7-2hrh carrying first_patched_version: null, and a fixed release that could not be confirmed from a primary source — so no Langflow deployment can legitimately be recorded as 'patched per SLA' for CVE-2026-0770, and a remediation register that closes this row on a patch is recording an event that has not happened. The verdict every instance must carry instead is state (b): compensating controls active, no binary patch, with the specific set named on the record — /api/v1/validate/code exposure blocked or removed, the instance network-isolated, port 7860 not reachable from untrusted networks — and the residual risk stated as what it is, that any gap in the proxy rule or any alternate route into the same exec() sink reopens unauthenticated RCE. Because the CISA KEV required action offers only vendor mitigation or product discontinuation, the time-bound action item this control demands cannot be 'apply the patch when it ships'; it has to be a dated decision point at which continuing to run Langflow is re-authorised against discontinuing it, so that an instance with no patch path does not sit under an open-ended risk acceptance while the ISMS reads clean. Distinguishing test: pull the vulnerability register's row for this CVE and confirm it shows a compensating-control state with a named review date and a discontinuation decision point, not a closed 'remediated' verdict — an SI-2 flaw-remediation attestation that treats the mitigation as a patch marks a confirmed-exploited, no-fix RCE compliant.",
+        "evidence": "Packet records patch_available false, live_patch_available false, and live_patch_notes stating GHSA-g22f-v6f7-2hrh has first_patched_version: null, that ZDI published this as a zero-day, that a fixed release could not be confirmed from a primary source, and that the CISA KEV required action is vendor mitigation or product discontinuation, with the compensating controls enumerated as blocking/removing /api/v1/validate/code exposure, network-isolating Langflow, and not exposing port 7860 to untrusted networks. active_exploitation confirmed; CISA KEV-listed 2026-07-21; RWEP 82; CVSS 9.8.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-033",
+        "name": "AI-ML-DEVELOPER-TOOLING-INVENTORY",
+        "description": "Langflow is an agent-framework control plane of exactly the kind this inventory exists to capture, and with no patched version recorded the inventory is the precondition for every other action on this CVE: the compensating controls the packet names can only be applied to instances someone knows about. Scoped to this product, the inventory must name every Langflow deployment with its listening endpoint (port 7860 by default), whether /api/v1/validate/code is reachable and from which networks, and the blast radius — which for CVE-2026-0770 is concrete rather than abstract, because the process runs as root in default containers and the observed in-the-wild activity takes AWS credentials and cloud metadata, so the blast radius is the cloud identity and instance-metadata reach the container holds. The control's patch-SLA-tier element cannot be exercised here and should not be recorded as though it were: the packet registers no fixed version, so the tier this asset class sits in is a compensating-control review clock, not a patch clock. Precondition: an inventory assembled from managed software distribution will miss the instances that matter, because self-hosted LLM builders are typically stood up by an application or data-science team outside it — the enumeration has to be done from the network side and reconciled, and it must be repeated, since a new instance stood up after the sweep is unprotected by definition. Distinguishing test: scan every environment for services answering on 7860 and on Langflow's API routes, reconcile the result against the asset register, and confirm each hit carries a recorded exposure decision — an ISMS asset register that lists no Langflow at all makes the technical-vulnerability-management attestation vacuous rather than clean.",
+        "evidence": "Packet attack_vector states the unauthenticated POST reaches exec() and gives remote code execution as the Langflow process, 'root in default containers', and that observed exploitation steals AWS credentials and cloud metadata. live_patch_notes name the compensating controls as blocking/removing /api/v1/validate/code exposure, network-isolating Langflow, and not exposing port 7860 to untrusted networks, and record that no patched version exists (GHSA-g22f-v6f7-2hrh, first_patched_version: null) with the CISA KEV required action being vendor mitigation or product discontinuation. CWE-829; poc_available true; active_exploitation confirmed; CISA KEV-listed 2026-07-21.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-27137": {
     "name": "DD-WRT Stack-Based Buffer Overflow Vulnerability",
@@ -53071,7 +54361,34 @@
         "adequate": false,
         "gap": "Technical-vulnerability management depends on an asset inventory that enumerates the firmware build; embedded UPnP services on edge routers are routinely outside that inventory, so the fixed changeset is never applied."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A DD-WRT router is the WAN/LAN trust boundary, and this CVE reaches it with a single unauthenticated UDP datagram: an M-SEARCH to SSDP/1900 whose oversized ST header is strcpy'd unbounded into a fixed 128-byte stack buffer in ssdp.c's ssdp_msearch, giving code execution with no credential, no session and no user interaction in the path. A generic operating-system patch window is the wrong instrument for it twice over — the device is usually not an OS line item on the estate at all, and the remediation the packet records is flashing a DD-WRT build at or after change set 45724, which needs a device reboot and, on most fleets, a hands-on flash per unit that no monthly cycle can absorb. So the tier requirement has to be met by the isolation half while the flash schedule runs: disable UPnP and block UDP/1900 at the WAN edge, as the packet's interim mitigation states. Precondition, stated because this control is routinely recorded as though it closed the surface: the WAN-edge block stops only the internet-side attacker. UPnP exists to serve the client network, so on a unit where the service stays enabled the vulnerable handler remains reachable from every host on the LAN, including an already-compromised IoT device — the filter bounds the attacker population, it does not remove the path. Where UPnP is not operationally needed, disabling it removes the listener and is the stronger action; where a LAN service depends on UPnP port mapping, neither lever applies and reaching change set 45724 is the only remedy for that unit. Distinguishing test: from the WAN side and again from a client on the LAN, send an M-SEARCH whose ST value exceeds 128 bytes and confirm no SSDP handler answers either — a patch attestation covering servers and workstations reports green while the boundary device itself still parses attacker-controlled datagrams.",
+        "evidence": "Packet vector: the DD-WRT UPnP/SSDP handler (ssdp.c, ssdp_msearch) performs an unbounded strcpy of a user-supplied oversized ST-header value into a fixed 128-byte stack buffer, allowing an unauthenticated attacker to overflow the buffer and achieve code execution; attack_vector confirms the trigger is an unauthenticated UDP M-SEARCH to SSDP/1900. CWE-121, CVSS 8.1, RWEP 70, poc_available true, active_exploitation confirmed, CISA KEV-listed 2026-07-21. live_patch_available false, with live_patch_notes stating there is no live-patch mechanism for router firmware, that remediation is flashing a DD-WRT build at or after change set 45724 which requires a device reboot, and that the interim mitigation is to disable UPnP and block UDP/1900 at the WAN edge.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not leave post-exploitation hypothetical: exploitation is confirmed and it names both the weaponizer and its objective — the Gafgyt/C0XMO botnet, weaponizing this overflow in 2026 to recruit routers as DDoS bots. On any DD-WRT unit whose SSDP/1900 was reachable during the exposure window, flashing change set 45724 is a patch and not a remediation, because the attacker already held code execution on the device. Flashing router firmware normally preserves the stored configuration, so an attacker-set administrative credential, DNS server, port forward or startup script carries across the upgrade untouched and the operator finishes with a device that reports the fixed build and is still attacker-held. The runbook for this device must therefore default to capturing the running configuration for analysis, reflashing to the fixed build with the stored configuration erased rather than migrated, re-entering settings from a known-good record, and rotating the administrative credential and any wireless or upstream credential the unit held — patch-in-place is the failure mode, not the plan. Detection, keyed to what an exploit doing exactly what this packet describes actually emits: inbound SSDP M-SEARCH datagrams to UDP/1900 whose ST header runs past the 128-byte buffer, and sustained outbound flood traffic sourced from the router itself, which is what recruitment as a DDoS bot produces. Precondition: both signals need the router's WAN-side traffic visible to something upstream, and a branch or home-office unit with no upstream telemetry produces no such record — there the safe default is to treat any unit that was exposed as compromised and rebuild it rather than to read the absence of an alert as evidence it was not hit.",
+        "evidence": "Packet attack_vector: an unauthenticated UDP M-SEARCH to SSDP/1900 with an oversized ST header overflows a 128-byte stack buffer in DD-WRT's UPnP handler via unbounded strcpy, enabling code execution; 'weaponized in 2026 by the Gafgyt/C0XMO botnet to recruit routers as DDoS bots'. active_exploitation confirmed; CISA KEV-listed 2026-07-21; poc_available true; CWE-121; RWEP 70. live_patch_notes record no live-patch mechanism for router firmware and that remediation is flashing a DD-WRT build at or after change set 45724, requiring a device reboot.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-68686": {
     "name": "Fortinet FortiOS Exposure of Sensitive Information to an Unauthorized Actor Vulnerability",
@@ -54527,7 +55844,33 @@
         "adequate": false,
         "gap": "A.8.7 protection against malware assumes reputation/warning controls raise friction on downloaded payloads, but this bypass removed the SmartScreen prompt entirely, letting Magniber-style loaders execute on first click until the fix was deployed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation of this CVE needs the victim to open the file, and the whole trick sits in the delivery: the payload is wrapped so the Mark-of-the-Web is stripped or evaded, and with no untrusted-origin mark on the file SmartScreen's Open File - Security Warning never appears, so the download executes on the first open with no reputation check in the path. On an estate that has not yet taken the July 2023 Windows cumulative security update and restarted, the enforceable control is upstream of the handler: the mail gateway, the web proxy and the untrusted file-share boundary apply the untrusted-origin tag themselves, rather than leaving the marking to whatever container the attacker chose, and that tag must survive extraction from an archive, mounting from an ISO or VHD, and renaming, so the wrapper cannot launder a downloaded payload into looking locally originated. Precondition, and it has two halves that both have to be said. First, boundary-applied provenance reaches only the ingress paths those boundaries actually control: a payload written to disk by a cloud-sync client, arriving on removable media, or delivered over any channel that never applies the tag lands unmarked regardless of policy, and on that host the cumulative update and its reboot is the only thing that closes the path. Second, this addresses the strip variant — where the crafted wrapper causes the marked file to be mishandled rather than unmarked, the tag is present and the check still fails, and again only the update closes it. Distinguishing test: deliver the payload through each ingress path nested inside an archive, extract it on a managed workstation, and confirm the extracted file still carries the untrusted-origin mark and still raises the warning — a user-application-hardening attestation covering macro and add-in settings says nothing about whether provenance survived the container.",
+        "evidence": "Packet attack_vector: 'A crafted file wrapped to strip or evade the Mark-of-the-Web bypasses SmartScreen's Open File - Security Warning, so a downloaded payload executes without the reputation prompt once the user opens it.' Vector and name identify it as a Microsoft Windows Defender SmartScreen security-feature-bypass vulnerability; CWE-693; CVSS 8.8; RWEP 65; poc_available true; active_exploitation confirmed; CISA KEV-listed 2023-07-11. patch_available true with live_patch_available false, and live_patch_notes stating there is no vendor live-patch mechanism and that remediation is the July 2023 Windows cumulative security update, which requires a reboot to take effect.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "What failed here is a defense rather than a parser: CWE-693, a SmartScreen security-feature bypass, where the file is wrapped so the Mark-of-the-Web is stripped or evaded and the Open File - Security Warning simply does not appear. That changes what counts as proof of remediation — for a memory-safety bug the build number is reasonable evidence, but for a bypassed protection mechanism the only evidence the July 2023 Windows cumulative security update fixed anything is that the warning now fires for the wrapping that previously suppressed it. Applied to this CVE, the MotW/SmartScreen class needs a standing battery in the detonation chamber that replays the wrapper forms which strip or evade the mark, executed on every cumulative-update deployment rather than once against this CVE, and held alongside the EDR and AppLocker/WDAC rules that have to carry the load whenever the prompt does not fire — because a reputation prompt the user can be walked past was never an execution control to begin with. Precondition: the battery proves only what it replays, so a wrapper form nobody added to it is untested no matter how green the run looks; and because this update takes effect only after a reboot, a host that installed it and has not restarted will pass a patch-inventory query while still executing the payload silently. Distinguishing test: after the update lands and the host has restarted, open the wrapped payload on a managed workstation and confirm the Open File - Security Warning is raised — a patch register showing the July 2023 cumulative update deployed is a record of an install, not evidence that the bypass class is closed.",
+        "evidence": "Packet name and vector: Microsoft Windows Defender SmartScreen Security Feature Bypass Vulnerability / 'Windows SmartScreen Security Feature Bypass Vulnerability', CWE-693. attack_vector: a crafted file wrapped to strip or evade the Mark-of-the-Web bypasses SmartScreen's Open File - Security Warning, so a downloaded payload executes without the reputation prompt once the user opens it. active_exploitation confirmed; CISA KEV-listed 2023-07-11; poc_available true; CVSS 8.8; RWEP 65. live_patch_available false and live_patch_notes record no vendor live-patch mechanism, with remediation being the July 2023 Windows cumulative security update, which requires a reboot to take effect.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-35311": {
     "name": "Microsoft Outlook Security Feature Bypass Vulnerability",
@@ -54588,7 +55931,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would prioritize CVE-2023-35311 on its KEV listing, but until the Office update is applied the compensating control (user heeding the security prompt) is exactly what the flaw neutralizes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The thing this CVE defeats is itself a protective control: a time-of-check-time-of-use race suppresses the Outlook Security Notice, the prompt that normally precedes activation of risky content in a message. Bound to Outlook, the control means that prompt is treated as a protection-mechanism class with its own regression battery — every known primitive that has suppressed or bypassed the Security Notice is replayed against a staged Outlook build on each Office and Windows update deployment, and the outcome is recorded as a pass/fail on the mechanism itself rather than inferred from the build number. That distinction is the whole point here: the compliance record for this entry is a patch level, while the thing an operator actually depends on is whether the warning still appears, and nothing in a flaw-remediation attestation exercises the prompt. The same applies downward — any phishing or user-awareness control in the estate that assumes the user is warned before activating message content must be recorded as not operative on clients below the fix, because the packet's exploitation path is precisely that the warning is not shown. Distinguishing test: on a staged client at or above the July 2023 update, deliver the crafted-message primitive and confirm the Security Notice is displayed before any risky content can be activated; recording the update as installed is not a demonstration that the prompt returned. Precondition, and it is a real limit: a regression battery can only replay bypass primitives that are already known and reproducible, so it will pass against a novel suppression of the same prompt. It also verifies rather than remediates — it gives an operator nothing during the window before the July 2023 Microsoft security update is applied and Outlook is restarted.",
+        "evidence": "The packet's attack vector is a time-of-check-time-of-use race (cwe_refs: CWE-367) in Outlook that lets a maliciously crafted message bypass the Outlook Security Notice prompt, 'so the protective warning that normally precedes activation of risky content is not shown, easing execution of a phished payload' — the bypassed item is a protection mechanism, which is what puts this entry in that class. The entry is CISA KEV-listed 2023-07-11 with active_exploitation 'confirmed' (rwep_score 47, cvss 8.8); poc_available is false, so prioritization rests on the KEV listing and confirmed exploitation rather than on a public exploit. patch_available is true and live_patch_available is false, with live_patch_notes stating the fix ships in the July 2023 Microsoft security update and applies on the next Office/Windows update cycle, typically requiring an application restart or reboot.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the KEV clock opened 2023-07-11 and the packet records no live-patch path, so the only remediation is the July 2023 Microsoft security update — which the packet says applies on the next Office/Windows update cycle and typically requires an application restart or reboot. Bound to Outlook, that makes the completion definition the load-bearing half: the clock runs to a restarted Outlook client on every mailbox, not to an update marked approved, downloaded or installed in the management console. A workstation that took the July 2023 update while Outlook stayed running continuously still carries the vulnerable code, and a long-uptime desktop with a never-closed mail client is exactly where that deferral hides from a patch report. Standard 14- and 30-day patch SLAs miss this twice: the window is wrong for a KEV-listed flaw under confirmed exploitation, and the completion measure is wrong for a fix that only takes effect on client restart. Distinguishing test: report, per mailbox client, whether the Outlook process has been restarted since the update was applied, not merely which Office build is present on disk. Precondition: this control is a clock and a completion definition, not a mitigation. It does not reduce exposure during the window, and the packet names no vendor mitigation and no compensating control for this entry — until the update lands and Outlook restarts, nothing operator-side restores the suppressed prompt, so any process that treats the Security Notice as a barrier should be assumed to have none.",
+        "evidence": "cisa_kev is true with kev_date 2023-07-11 and active_exploitation 'confirmed' (rwep_score 47, cvss 8.8). patch_available is true; live_patch_available is false; live_patch_notes: 'No live-patch mechanism; the fix ships in the July 2023 Microsoft security update and applies on the next Office/Windows update cycle, typically requiring an application restart or reboot.' The packet records no vendor mitigation or compensating control for this entry. The gaps cited against it are patch- and vulnerability-management controls (ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8, NIST SP 800-53 SI-2 Flaw Remediation, NIS2 Art. 21 vulnerability handling and disclosure).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-36874": {
     "name": "Microsoft Windows Error Reporting Service Privilege Escalation Vulnerability",
@@ -54649,7 +56016,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management may downgrade a 7.8 local-only LPE versus network CVEs, yet as a live-exploited escalation link in intrusion chains it warranted emergency patching that a CVSS-vector-only triage would delay."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet puts the attacker at ordinary standard-user privilege on the host: they plant a malicious wermgr.exe and use NTFS junctions or hard links in a WER-controlled path so the Windows Error Reporting service, which trusts the link target, launches that binary as SYSTEM. For this CVE the control means the July 2023 Windows cumulative update is driven across every affected host on the clock that opened with the 2023-07-11 KEV listing rather than folded into the next monthly rollup, with completion measured per host as installed build at or above the fixed build AND the reboot actually taken — the packet records no live-patch path and a fix applied through the standard servicing stack that requires a reboot, so a host that staged the update and has not restarted still runs the vulnerable code and must be counted as exposed. Enumerate first the hosts where non-administrative users hold interactive local sessions — shared workstations, session hosts, jump boxes, build and developer machines — because on those the exploit's only stated precondition, an ordinary local user, is the normal operating state rather than an anomaly. The control's second half is the load-bearing one here, and it is exactly why the least-privilege gap is recorded against this entry: the attacker holds no privilege they were not legitimately granted, so removing local-administrator rights or tightening per-account scoping does not contain the escalation, and an AC-6 attestation passes cleanly while the flaw stays fully exploitable. Precondition on the interim lever: restricting which accounts may log on interactively bounds the population that can attempt this, but it does not close the path — any account that legitimately reaches the desktop satisfies the precondition in full, and on a shared session host that is every user. And because active exploitation is confirmed and a public PoC exists, a host that carried untrusted local users during the exposure window needs forensic triage and credential rotation rather than closure on the patch: the update repairs the link handling but removes nothing an attacker already installed while holding SYSTEM.",
+        "evidence": "The packet's attack vector: 'A standard user plants a malicious wermgr.exe and uses NTFS junctions/hard links in a WER-controlled path so the Windows Error Reporting service, which trusts the link target (CWE-59), launches the attacker binary as NT AUTHORITY SYSTEM.' cwe_refs is CWE-59. cisa_kev true, kev_date 2023-07-11, active_exploitation 'confirmed', poc_available true, rwep_score 68, cvss 7.8. patch_available is true and live_patch_available is false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires the July 2023 Windows cumulative update, which is applied via the standard servicing stack and requires a reboot.' NIST SP 800-53 AC-6 (Least Privilege) is among the framework gaps citing this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scan that reports this host 'patched' because the July 2023 cumulative update appears in its servicing record is paper compliance twice over. First, the packet states the update is applied through the standard servicing stack and requires a reboot, so a host with the update staged and no restart reports patched while still running the vulnerable Windows Error Reporting path — reboot-pending state has to be reported alongside installed build for every host in the remediation population, or the dashboard converts an exposed host into a compliant one. Second, and more fundamental for this CVE, the exploitable condition is a filesystem-link behaviour rather than a version: a standard user creating an NTFS junction or hard link in a WER-controlled path so the service launches a planted binary from a location that user can write. No version query observes that. The operational test, keyed to the behaviour the packet documents: on a staging host at or above the fixed build and rebooted, run as a standard user, plant a binary, redirect a WER-controlled path at it through a junction or hard link, and confirm the Error Reporting service does not launch the linked target with SYSTEM privileges. Precondition: this is a verification method, not a mitigation. It tells the operator whether remediation actually landed on the build they tested and nothing about hosts on a different build, it requires a staging host on which the plant can be attempted safely, and it says nothing about a host already compromised before the test was run — confirmed exploitation means the estate can hold hosts where the answer is 'the primitive worked, weeks ago'.",
+        "evidence": "live_patch_notes record the fix as 'the July 2023 Windows cumulative update, which is applied via the standard servicing stack and requires a reboot', with live_patch_available false — so an installed-but-unrebooted host is still vulnerable. The attack vector describes the exploitable condition as a standard user planting a malicious wermgr.exe and using NTFS junctions/hard links in a WER-controlled path that the Windows Error Reporting service trusts (CWE-59) to launch the binary as SYSTEM, which is a behaviour rather than a version state. active_exploitation is 'confirmed' and poc_available is true (kev_date 2023-07-11). The entry's cited gaps include ISO/IEC 27001:2022 A.8.8 (management of technical vulnerabilities) and ASD Essential Eight patching.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2022-31199": {
     "name": "Netwrix Auditor Insecure Object Deserialization Vulnerability",
@@ -55248,7 +56639,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management struggles with mobile-baseband/DSP components an organisation cannot directly patch; the ELF-into-DSP capability was an OEM-only fix, leaving a coverage gap until the SMR propagated to each device."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's exploitation path is local: a process already running on the handset abuses the Samsung DSP driver's missing ELF validation to load arbitrary libraries into the DSP, gaining code execution in DSP context as a step in an on-device privilege-escalation chain. Remediation is the SMR Mar-2021 Release 1 or later firmware update, which reboots the device. Bound to this estate, the control means the fixed security-patch level is enforced as an access condition rather than published as a statistic: a managed Samsung handset below SMR Mar-2021 Release 1 is denied mail, VPN and document access by policy until it reaches that level, so the exposure is removed from the organization's data instead of being recorded against it. Enrolment has to read the device's actual security-patch level, because that — not the Android version and not the model — is what distinguishes a handset still carrying the vulnerable DSP driver. For any handset that cannot be brought to SMR Mar-2021 Release 1 or later, reaching a fixed build is not available at all: the terminal state is replacement and removal from the estate on a dated schedule, and a requirement that ends at 'every device reports the fixed level' would mark such a handset compliant only by leaving it out of the count. Distinguishing test: enrol a handset pinned below SMR Mar-2021 Release 1 and confirm policy actually denies it access to protected resources — an estate that surfaces the stale patch level on a report while the device keeps its mail and VPN sessions has recorded the exposure, not removed it. Precondition, and it is the limit that matters here: this is an access condition on organizational data, and the packet's exploitation path presupposes a local process already running on the device. It therefore neither removes that process nor reverses code already loaded into the DSP on a handset exploited before enrolment — a device suspected of that belongs on the incident path, not the access-policy path — and it is a holding measure only for the window before the firmware update and its reboot land.",
+        "evidence": "The packet's vector: 'A vulnerability in DSP driver prior to SMR Mar-2021 Release 1 allows attackers load arbitrary ELF libraries inside DSP', and its attack vector: 'A local process abuses the Samsung DSP driver's missing ELF validation to load arbitrary libraries into the DSP, gaining code execution in the DSP context as a stepping stone in an on-device privilege-escalation chain.' cwe_refs is CWE-912. cisa_kev true with kev_date 2023-06-29 and active_exploitation 'confirmed'; poc_available false; rwep_score 48, cvss 6.7. patch_available is true and live_patch_available is false; live_patch_notes: 'No live-patch mechanism for the Samsung DSP driver; remediation is applying the SMR Mar-2021 Release 1 (or later) firmware update, which reboots the device.' The packet states no end-of-support status for the affected handsets, so whether a given unit can reach the fixed level is a per-device question the inventory has to answer.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The KEV clock on this entry opened 2023-06-29 under confirmed exploitation, and the packet records no live-patch mechanism for the Samsung DSP driver — the only remediation is the SMR Mar-2021 Release 1 or later firmware update, which reboots the device. The control means that update is driven from the MDM/EMM managing the handset on the KEV clock with user deferral disallowed, and completion measured per device as the security-patch level the handset itself reports after it restarts. The restart is the step this particular remediation loses: a firmware update that reboots a phone someone carries is the update a user postpones indefinitely, and a handset that has downloaded it without restarting still runs the vulnerable driver while appearing actioned in the console. Priority should follow the packet rather than the 6.7 CVSS band — the packet describes DSP-context code execution as a stepping stone in an on-device privilege-escalation chain, so this is a chain link on a device holding organizational mail, tokens and credentials rather than a standalone low-severity item, and confirmed in-the-wild exploitation is what sets the clock, not the score. Precondition: enforcement reaches only handsets the MDM/EMM actually enrols and can drive to a firmware level. An unenrolled or personally-managed device is outside this control entirely and has to be handled by conditional access instead, and a handset for which SMR Mar-2021 Release 1 or later is not obtainable cannot be remediated by this control at all — that unit belongs on the replacement path, since there is no build the operator can drive it to.",
+        "evidence": "cisa_kev true, kev_date 2023-06-29, active_exploitation 'confirmed' (rwep_score 48 against cvss 6.7). live_patch_available is false with live_patch_notes: 'No live-patch mechanism for the Samsung DSP driver; remediation is applying the SMR Mar-2021 Release 1 (or later) firmware update, which reboots the device.' The attack vector describes the DSP-context code execution as 'a stepping stone in an on-device privilege-escalation chain'. The gaps citing this entry are patch- and vulnerability-management controls (ASD Essential Eight 'Patch operating systems', NIST SP 800-53 SI-2 Flaw Remediation, NIS2 Art. 21 vulnerability handling).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-25372": {
     "name": "Samsung Mobile Devices Improper Boundary Check Vulnerability",
@@ -55524,7 +56939,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",
@@ -56073,7 +57519,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)",
@@ -56292,7 +57774,44 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management for network appliances often lacks asset visibility into edge firewalls, so the unauthenticated RCE persisted on unpatched Zyxel devices well past the vendor's 2023-05-24 fix while botnet enrollment proceeded."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The affected units are the trust boundary itself — Zyxel ATP, USG FLEX, USG FLEX 50(W), USG20(W)-VPN, VPN series and ZyWALL/USG firewalls — and the packet places the overflow in the ID-processing function reachable by an unauthenticated attacker, so the device that terminates the perimeter is the device that runs the attacker's code. For these units the control means the fixed firmware branch (above 5.36 Patch 1, or above 4.73 Patch 1 on the ZyWALL/USG line) is driven on the KEV clock that opened 2023-06-05 rather than into the next appliance-maintenance window, and completion is measured per unit by the firmware version actually running after the reboot the flash requires. The packet records no live-patch path, so a unit with the image staged but not yet rebooted is still running the vulnerable ID-processing code and must be counted exposed. Where the reboot cannot be taken immediately, the control's alternative is isolation of the vulnerable interface, which the packet identifies as restricting WAN-side management and VPN access. Precondition, and this is where that interim mitigation is routinely over-claimed: restricting WAN-side reachability bounds who can send the crafted request, but on a USG20(W)-VPN or VPN-series unit whose function is terminating remote-access VPN from the internet, the VPN service must keep answering untrusted sources, so for that interface the restriction removes nothing and only the firmware flash does. A unit in that state is on the accelerated clock, not on a compensating control.",
+        "evidence": "Packet: CWE-120 buffer overflow in the ID-processing function, reachable by an unauthenticated attacker for DoS or remote code execution. Affected branches ATP 4.32–5.36 Patch 1, USG FLEX 4.50–5.36 Patch 1, USG FLEX 50(W) 4.25–5.36 Patch 1, USG20(W)-VPN 4.25–5.36 Patch 1, VPN 4.30–5.36 Patch 1, ZyWALL/USG 4.25–4.73 Patch 1. CISA KEV 2023-06-05, active_exploitation confirmed, CVSS 9.8, RWEP 57. patch_available true; live_patch_available false, with live_patch_notes stating remediation requires flashing fixed firmware above the affected 5.36 Patch 1 / 4.73 Patch 1 branches, which reboots the device, and naming restriction of WAN-side management/VPN access as the recommended interim mitigation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives unauthenticated code execution on the firewall with confirmed in-the-wild exploitation from the 2023-06-05 KEV listing, so for any unit that was internet-reachable during the exposure window the open question is not whether the vulnerable function is still present but whether the device is still the operator's. Flashing the fixed firmware replaces the vulnerable ID-processing code; it does not remove configuration an attacker wrote, accounts an attacker added, or credentials an attacker read out of the device — and on an ATP / USG FLEX / USG20(W)-VPN / VPN-series / ZyWALL unit that means VPN pre-shared keys, remote-access user credentials and administrator passwords. For this CVE the control means any such unit that answered from the WAN during the window is handled as suspected-compromised: its configuration exported for comparison against a known-good baseline rather than carried forward, the device rebuilt onto the fixed firmware from a clean configuration, and every credential the device held rotated. Precondition: the rebuild is only as good as the baseline it restores from — a configuration exported after the exposure window and re-imported unchanged reinstates whatever the attacker left in it — and the reboot the flash requires is not a compromise-recovery step on its own. The packet records poc_available false; that is not a triage input here, because active exploitation is separately recorded as confirmed, so absence of a public exploit is not evidence a given unit was untouched.",
+        "evidence": "Packet: unauthenticated attacker sends a crafted request that overflows the buffer in the firewall's ID-processing function, causing a crash or executing attacker-controlled code on the device. CISA KEV 2023-06-05; active_exploitation confirmed; poc_available false; CVSS 9.8; RWEP 57. patch_available true, live_patch_available false, with the vendor fix being a firmware flash that reboots the device.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry has two remediation states that a vulnerability register normally collapses into one. State (a) is the Zyxel firmware above the 5.36 Patch 1 / 4.73 Patch 1 branches, flashed and rebooted, which removes the overflow. State (b) is the packet's own named interim mitigation — WAN-side management and VPN access restricted — with the vulnerable firmware still running, so the ID-processing overflow is intact and reachable by anything still inside the permitted scope. For these firewalls the control means state (b) is recorded as a time-bound compensating control with a dated action item to reach the flash, never as 'patched within SLA', and the register carries the firmware version running on each unit rather than a remediation flag. The distinguishing test is per unit and keys on what the device reports rather than on what the register asserts: read back the firmware version actually running and the current WAN access rules, and confirm the recorded verdict matches. An estate whose report shows the KEV item closed while units still run 5.36 Patch 1 behind an access rule has recorded a mitigation as a fix. Precondition: this is accounting, not defence — it changes nothing on the device. Its value is that it stops the interim state ageing out of view, which on unmanaged edge units is how the exposure outlives the availability of the fix.",
+        "evidence": "Packet: patch_available true and live_patch_available false, with live_patch_notes stating that remediation requires flashing fixed firmware above the affected 5.36 Patch 1 / 4.73 Patch 1 branches (which reboots the device) and that restricting WAN-side management/VPN access is the recommended interim mitigation — two distinct states named in the same entry. CISA KEV 2023-06-05, active_exploitation confirmed, CVSS 9.8.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-34362": {
     "name": "Progress MOVEit Transfer SQL Injection Vulnerability",
@@ -56597,7 +58116,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management struggles to enforce timely WebKit updates on personally-owned or embedded devices that rely on WebKit for HTML processing, leaving a known-exploited info-disclosure flaw unremediated past the KEV due date."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The fix for this WebKit read does not ship as one update — the packet names watchOS 9.5, tvOS 16.5, macOS Ventura 13.4, iOS and iPadOS 16.5, iOS and iPadOS 15.7.6, and Safari 16.5. An enforcement policy written only against iOS/iPadOS and current macOS therefore leaves the Apple TVs, the Watches, and any Mac taking Safari 16.5 as a separate update outside the SLA entirely, while the compliance view reads clean. For this CVE the control means the enforced minimum is expressed per train against the specific fixed build rather than as 'latest major version': a device on the 15.x line is remediated by 15.7.6 and must be driven there rather than written off as unsupportable, and a Mac left on an older macOS is remediated by Safari 16.5. The packet records no live-patch path and states the fix requires installing the update and restarting the device, so the completion signal is the post-restart build each device reports — an update downloaded or sitting at 'pending restart' still runs the vulnerable HTML-processing path and is not remediated. Precondition: this reaches only devices the management channel actually enrols and can compel. Hardware in the estate that no management channel holds is not covered by this control at all, and the remaining lever there is withholding access to organizational data until the device reports a fixed build — not carrying it as a standing exception.",
+        "evidence": "Packet: CWE-125 out-of-bounds read; the vector states the issue is fixed in watchOS 9.5, tvOS 16.5, macOS Ventura 13.4, iOS 15.7.6 and iPadOS 15.7.6, Safari 16.5, iOS 16.5 and iPadOS 16.5, and that processing web content may disclose sensitive information. CISA KEV 2023-05-22; active_exploitation confirmed; CVSS 6.5; RWEP 45. patch_available true; live_patch_available false, with live_patch_notes stating there is no live-patch mechanism and that the listed fixes require installing the update and restarting the device.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet's outcome is an information disclosure — sensitive memory including pointers usable to defeat ASLR — not code execution, and the CVSS of 6.5 reflects that. Read as a chain input rather than a standalone bug, the priority inverts: the leak is what makes a following memory-corruption step reliable, so the population that matters is the cohort the operator has already designated as high-risk. For those users the control means a standing reduced-attack-surface posture on their Apple devices, so untrusted web content is not processed automatically by WebKit, narrowing the delivery path into the out-of-bounds read during the window between the 2023-05-22 KEV listing and the completed install-and-restart of watchOS 9.5 / tvOS 16.5 / macOS Ventura 13.4 / iOS and iPadOS 16.5 or 15.7.6 / Safari 16.5. Two preconditions, both load-bearing. The posture narrows what reaches the parser; it does not remove the flaw — content the user deliberately opens still reaches WebKit's HTML processing — so this is a holding measure for the pre-update window, not a substitute for the fixed build and its restart. And it only helps if it was already on when the content arrived: assigning it after a device has rendered the attacker's page changes nothing about what was already read out of that process, which is an incident-response matter rather than a configuration one. Scope it to the designated cohort and to the Apple products the packet names; extending it estate-wide is a usability cost that adds no coverage of this CVE.",
+        "evidence": "Packet: maliciously crafted web content drives WebKit's HTML processing past a buffer boundary, reading out-of-bounds memory and disclosing sensitive information such as pointers used to defeat ASLR (CWE-125). Vector states processing web content may disclose sensitive information and that Apple is aware of a report the issue may have been actively exploited; active_exploitation recorded as confirmed. CISA KEV 2023-05-22; CVSS 6.5; RWEP 45. live_patch_available false, with the fix requiring installation of the listed builds and a device restart.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-32373": {
     "name": "Apple Multiple Products WebKit Use-After-Free Vulnerability (CVE-2023-32373)",
@@ -56719,7 +58262,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",
@@ -56872,7 +58437,30 @@
         "adequate": false,
         "gap": "A.8.15 logging controls require logs not to expose sensitive data and to be access-protected; here the kernel writes raw pointers into a log a privileged process can read, so the logging control as implemented leaks the exact addresses that defeat ASLR."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet pins remediation to one named build level: kernel pointers are printed in the log file prior to SMR May-2023 Release 1, and the only remediation it records is Samsung SMR May-2023 Release 1 or later delivered by device OTA, which reboots the handset. Bound to this estate, the control means that SMR level is enforced as an access condition on every managed Samsung handset — a device reporting below SMR May-2023 Release 1 is refused organizational mail, VPN and document access until it reports at or above it — rather than appearing as a stale row on a patch-compliance report. Enforcement rather than reporting is the point here because this entry's own severity signals argue for deferral: the packet gives CVSS 4.4, RWEP 44 and poc_available false, while the flaw's function is to hand a privileged local process the kernel addresses that defeat ASLR, which is an enabling step whose value to an attacker never shows up in its own score. Distinguishing test: enrol a handset pinned below SMR May-2023 Release 1 and confirm the policy actually denies it protected resources; an estate that surfaces the stale patch level on a dashboard while the device keeps mail and VPN has recorded the exposure rather than removed it. Preconditions, all of which are ways this control is over-claimed: it reaches only enrolled, managed handsets, so an unenrolled or personally-owned device is bounded solely by withholding organizational data from it; the packet records live_patch_available false, so a handset that has downloaded the OTA but not completed it and its reboot is still running the logging kernel and must be counted as exposed, not remediated; and where the OTA carrying SMR May-2023 Release 1 or later is not offered for a given model, no enforcement action produces the fixed build at all — for those models the terminal state is withdrawal of organizational data and replacement of the handset, not an access-policy exception. Because active_exploitation is confirmed, a device suspected of having already been through the chain this disclosure primitive feeds belongs on the incident path; reaching the fixed build does not evict what a prior compromise established.",
+        "evidence": "Packet vector: \"Kernel pointers are printed in the log file prior to SMR May-2023 Release 1 allows a privileged local attacker to bypass ASLR.\" Packet live_patch_notes: \"No live-patch mechanism; remediation requires Samsung SMR May-2023 Release 1 or later via the device OTA update, which reboots the handset\" — with patch_available true and live_patch_available false. CISA KEV listed 2023-05-19 with active_exploitation confirmed, against CVSS 4.4, RWEP 44 and poc_available false, which is the deprioritization pressure the packet records. The packet's attack_vector states the addresses are used to defeat KASLR and provide the address-disclosure primitive needed for reliable follow-on kernel exploitation in a spyware chain. The entry cites NIST-800-53-SI-2, NIS2-Art21-patch-management and UK-CAF-B4 as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-059",
+        "name": "SENSITIVE-DATA-IN-LOGS-LINT",
+        "description": "On this CVE the disclosure is the log's content. The CWE is CWE-532 and the packet's vector says kernel pointers are printed in the log file, which a privileged local process then reads to learn kernel addresses. That is precisely the question a logging control does not ask: an A.8.15-style attestation verifies that logs are produced, retained, time-referenced and access-protected, and every one of those passes on a handset whose log is itself the address-disclosure primitive, because the defect is what the platform chose to write rather than who may read it. Bound to this product, the requirement is that log content be treated as an output classified by what it reveals. On the platform side that is a supplier requirement, since only the OEM build stops the pointers being written: mobile-platform acceptance and re-acceptance must ask whether kernel and diagnostic logs carry raw kernel addresses, not only whether logging is enabled and protected. On the operator side, every pipeline that collects these device logs — MDM diagnostic capture, crash and bug-report upload, log-forwarding agents — inherits those addresses off the handset, so on any device below SMR May-2023 Release 1 those captures widen the set of readers and must be scoped, access-restricted and retention-bounded as sensitive material rather than handled as routine telemetry. Distinguishing test: on a handset below SMR May-2023 Release 1, read the log through the privileged local path the packet describes and confirm whether raw kernel pointers appear; a logging attestation reporting collection coverage, retention period and log access control passes cleanly while the pointers sit in the file. Precondition: this control governs what is written and who receives it — it does not repair the kernel. Nothing operator-side prevents the pointers being logged on a device below the fixed build, so restricting log handling bounds readership without removing the primitive, and the privileged local process the packet describes is already inside that boundary by definition. It is a holding measure for the window before SMR May-2023 Release 1 and its reboot land, not a substitute for them.",
+        "evidence": "Packet cwe_refs: CWE-532 (Insertion of Sensitive Information Into Log File), matching the entry name \"Samsung Mobile Devices Insertion of Sensitive Information Into Log File Vulnerability\". Packet vector: kernel pointers are printed in the log file prior to SMR May-2023 Release 1, allowing a privileged local attacker to bypass ASLR. Packet attack_vector: \"The kernel writes raw kernel pointers into a log file; a privileged local process reads those entries to learn kernel addresses and defeat KASLR.\" The entry cites ISO-27001-2022-A.8.15 (Logging) and AU-Essential-8-App-Hardening (User application hardening) as insufficient. CISA KEV listed 2023-05-19 with active_exploitation confirmed; patch_available true with live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.15",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2023-25717": {
     "name": "Multiple Ruckus Wireless Products CSRF and RCE Vulnerability",
@@ -56994,7 +58582,42 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management often deprioritizes local-only CVEs, yet this one converts any low-privilege foothold into root, so treating it as low-urgency (no network vector) misjudges its post-compromise value."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "polkit arbitrates privileged D-Bus operations on effectively every Linux install, and the packet's path needs nothing but an unprivileged local account: repeatedly call a privileged D-Bus method and kill the client mid-request until polkit races, treats the disconnected caller as root, authorizes the action, and lets the caller create a new local administrator. For this CVE the control means the distribution's fixed polkit package is driven across every Linux host on the clock that opened with the 2023-05-12 KEV listing, with completion measured per host against the polkit that is actually running rather than against 'deployed' in a management console. The packet makes that measurement both cheap and easy to skip: there is no kernel live-patch to consider because polkit is a userspace daemon, and the flaw closes once polkitd restarts with no full reboot — so there is no maintenance window to schedule and no user-visible outage to defer, and a host that took the package but never restarted polkitd is still running the vulnerable daemon and must be counted exposed. Enumerate first the hosts where this exploit's precondition is the normal operating state rather than an anomaly: multi-user shell servers, jump hosts, shared build machines and CI runners, where every interactive account already satisfies 'unprivileged local user'. The least-privilege gap cited on this entry cannot contain the escalation — the attacker is a legitimately authorized user, the privilege transition happens inside polkit's credential check, and an attestation that every account holds only the rights it needs passes cleanly while the flaw stays fully exploitable. Because active exploitation is confirmed and a PoC is public, remediation also has to look backwards: the outcome the packet names is a new local administrator account, and that account survives the package update untouched. Reconcile local accounts and administrative group membership on hosts that were exposed instead of closing the finding on the package version.",
+        "evidence": "Packet: CWE-863 / CWE-754, CISA KEV 2023-05-12, active_exploitation confirmed, poc_available true, CVSS 7.8, RWEP 64. attack_vector: 'An unprivileged local user repeatedly calls a privileged D-Bus method and kills the client mid-request; polkit races and treats the disconnected caller as root, authorizing the action and allowing creation of a new administrator account.' Vector: the flaw 'could be used by an unprivileged local attacker to, for example, create a new local administrator.' patch_available true; live_patch_available false with live_patch_notes 'No kernel live-patch applies — polkit is a userspace daemon; remediation is the distribution's fixed polkit package, after which restarting polkitd (no full reboot) closes the flaw.' NIST-800-53-AC-6 (Least Privilege) is recorded among the citing gaps.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-146",
+        "name": "USERSPACE-PRIVILEGED-DBUS-RACE-DETECTION",
+        "description": "polkit is a userspace daemon, so what this control means for this CVE is host audit or eBPF rules on the privilege-escalation behaviour rather than kernel-exploit indicators — and the packet describes that behaviour precisely enough to key on it. The exploit is a race, and a race is repetitive: an unprivileged local user calls a privileged D-Bus method over and over and kills the client mid-request until the timing lands. The rule therefore keys on that shape — bursts of short-lived invocations of privileged D-Bus methods from a non-root uid that terminate before the call completes — paired with the privilege transition the packet names as the result: a new local account appearing with administrative rights, seen as writes to the local account and group files or as account-management utilities running outside a change window. Both halves are needed. Repeated D-Bus calls alone can be benign; an account creation alone arrives with no context, and it is the pairing inside a short window that distinguishes this exploit from either. Note what will not see it: nothing is compiled, no module is loaded, no setuid binary changes, no process crashes, and the work is done by an ordinary user session calling a system daemon through its normal interface — so file-integrity monitoring and signature-based endpoint tooling have no artifact to match, and alerting on crashes or on named exploit tooling would miss an attempt that behaves exactly as the packet describes. Precondition: this requires host audit or eBPF telemetry already collected and shipped off-host before the attempt, which on the multi-user and shared hosts most exposed to this flaw is precisely where it is least often enabled; a rule authored after the fact against telemetry nobody was collecting produces nothing. And detection does not prevent the escalation and does not remove an administrator account already created — it bounds the window to alert-and-response time during the period before the fixed polkit package and the polkitd restart land.",
+        "evidence": "Packet attack_vector: 'An unprivileged local user repeatedly calls a privileged D-Bus method and kills the client mid-request; polkit races and treats the disconnected caller as root, authorizing the action and allowing creation of a new administrator account.' Vector: 'polkit could be tricked into bypassing the credential checks for D-Bus requests, elevating the privileges of the requestor to the root user'; the stated example outcome is creating 'a new local administrator'. active_exploitation confirmed, poc_available true, CISA KEV 2023-05-12. live_patch_notes states polkit is a userspace daemon and no kernel live-patch applies.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE the paper-compliance failure has one exact shape: a scanner reads the installed polkit package version, finds it at or above the distribution's fixed build, and reports the host remediated — while the polkitd process that actually arbitrates D-Bus authorization is still the pre-update binary, because the packet states the flaw closes only after polkitd restarts. A package-version query cannot tell those two hosts apart, and on a long-uptime multi-user server — the same population where any interactive account already satisfies this exploit's 'unprivileged local user' precondition — they diverge as a matter of routine, since installing the package does not by itself take the daemon down. The operational test is therefore not the package query but the running daemon: for every host reported patched, show that the polkitd currently running was started after the fixed package was installed, or verify the running daemon's on-disk image directly. Anything that stops at the package version is an attestation about the filesystem, not about the process making the authorization decision. Precondition: this test verifies remediation, it does not perform it — a host that fails it is remediated by restarting polkitd, which the packet records as needing no full reboot — and it says nothing about whether the host was already exploited. With exploitation confirmed in the wild and the documented outcome being a new local administrator account that the package update does not remove, that is a separate question answered by reconciling local accounts, not by any version check.",
+        "evidence": "Packet live_patch_notes: 'No kernel live-patch applies — polkit is a userspace daemon; remediation is the distribution's fixed polkit package, after which restarting polkitd (no full reboot) closes the flaw.' patch_available true, live_patch_available false. active_exploitation confirmed, poc_available true, CISA KEV 2023-05-12. attack_vector places the attacker as an unprivileged local user; the vector's stated outcome is creation of a new local administrator.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2014-0196": {
     "name": "Linux Kernel Race Condition Vulnerability",
@@ -57055,7 +58678,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management that scores by CVSS treated this 5.5 issue as low urgency, understating that it yields reliable local root; the low base score let it linger unpatched despite a public exploit and KEV listing."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this CVE the distance between \"patched\" and \"not vulnerable\" is exactly one reboot, and that is where the compliance record goes wrong. The packet's remediation is upgrading to a fixed Linux kernel past 3.14.3 and rebooting, with live_patch_available false. A scanner that reads the installed kernel package version marks a host compliant the moment the fixed package lands, while the kernel actually executing — the one still carrying the vulnerable n_tty_write path in the LECHO and !OPOST case — is unchanged until the machine restarts. The requirement for this entry is that the vulnerability verdict be taken from the running kernel, comparing the live release against the fixed build, and that \"fixed package installed, reboot pending\" be reported as its own exposed state with a dated restart rather than as a pass. The entry's compliance risk is the compound of two ordinary program behaviours: the packet gives CVSS 5.5 against RWEP 71 with poc_available true and confirmed exploitation, so a program that prioritises by base score defers the kernel update, and a program that then measures by package version closes the deferral without the reboot ever happening. Enumerate the population where the deferral matters most first — hosts where unprivileged users hold interactive shell sessions, since the exploit needs a local account and a pty, which on a shared or multi-user host is the normal operating state rather than an anomaly. Distinguishing test: take a host that has installed the fixed kernel package but has not restarted, run the scan, and confirm it reports that host as still exposed; a scan returning \"patched\" there is measuring the package rather than the kernel in memory, and the fleet's remediation count for this CVE is inflated by every host in that state. Precondition: this control corrects what is measured and what action is scheduled — it removes nothing on its own, and a host it correctly reports as exposed stays exploitable until the restart is taken.",
+        "evidence": "Packet live_patch_notes: \"Standard remediation is upgrading to a fixed Linux kernel (past 3.14.3) and rebooting,\" with patch_available true and live_patch_available false; the same note records that no specific vendor live-patch for this CVE is confirmed. Packet vector: the n_tty_write function in drivers/tty/n_tty.c in the Linux kernel through 3.14.3 does not properly manage tty driver access in the \"LECHO & !OPOST\" case. Packet scoring: CVSS 5.5 against rwep_score 71, with poc_available true, CISA KEV listing 2023-05-12 and active_exploitation confirmed. Packet attack_vector: a local user races writes to a pty to escalate to root. The entry cites NIST-800-53-SI-2, AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIS2-Art21-patch-management as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "This is the control for the window the reboot deferral leaves open, and for this CVE it has to key on the two behaviours the packet actually documents. First, the race itself: an unprivileged process opens a pty, puts the line discipline into the echo-on with output-processing-off configuration the packet names, and then drives sustained concurrent long writes to it from more than one thread. An interactive session does not produce that — a human-driven terminal does not emit multi-threaded bulk writes to its own pty — so the write pattern is the signal that fires while the exploit is looping, which matters because a race is attempted many times before it wins. Second, the transition it is racing toward: a euid change to 0 in a process descended from an unprivileged login session with no preceding setuid execution or authorization event to account for it. Both halves are required — the write-storm rule sees the attempts, the uid-transition rule sees a success — and the alert has to reach an operator inside 60 seconds because the response to a win is isolating the host, not queueing a ticket. Do not build the rule around the crash. The packet does record memory corruption and system crash as the alternative outcome, but the run that wins the race produces no crash at all, so a rule keyed on kernel oops volume alone is blind to exactly the case that matters and would read as clean during a successful escalation. Distinguishing test: the packet records poc_available true, so run the public exploit against a staging host on an unfixed kernel and confirm the write-storm rule fires during the attempt loop and the uid-transition rule fires on success — a rule set validated only against a synthetic uid change or a forced panic has not been shown to see this exploit. Precondition: detection does not restore the containment this flaw breaks; it tells you the boundary failed. It requires a low-privilege foothold to be visible to the sensor in the first place, and it is a compensating measure for hosts awaiting the restart, not a reason to extend the deferral.",
+        "evidence": "Packet attack_vector: \"Two threads race concurrent long writes to a pty in the n_tty_write LECHO/!OPOST path, overflowing the tty buffer to corrupt kernel memory and escalate a local user to root (or crash the machine).\" Packet vector: the flaw allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings; cwe_refs CWE-362. Packet poc_available true supports a runnable validation. Packet live_patch_available false with remediation requiring a reboot establishes the deferral window this covers. CISA KEV listed 2023-05-12, active_exploitation confirmed, rwep_score 71. The entry cites UK-CAF-B4 (System security) as insufficient, and the lesson's framework_coverage records the B4 gap as the least-privilege containment assumption failing on shared and multi-tenant Linux hosts that skipped the kernel bump.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2010-3904": {
     "name": "Linux Kernel Improper Input Validation Vulnerability (CVE-2010-3904)",
@@ -57116,7 +58762,41 @@
         "adequate": false,
         "gap": "A.8.9 configuration management should enforce a hardened kernel-module baseline, but default configurations that leave the rarely-used RDS module loadable let a local user reach the unvalidated rds_page_copy_user copy, so configuration drift/default-on modules sustained the root-escalation exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The packet names this mitigation itself: the RDS module can be blacklisted or unloaded on hosts that do not use it, removing the reachable code path without an immediate kernel update. Bound to this CVE, the control means resolving, per host, which of three states net/rds is actually in — already loaded, loadable on demand, or built into the running kernel image — and blacklisting it everywhere RDS carries no business function, because the exploit's first move is an unprivileged user opening an AF_RDS socket, and on a host where rds is merely auto-loadable that socket call is what pulls the unvalidated rds_page_copy_user path into the kernel in the first place. The inventory is the load-bearing half, because \"we blacklisted rds\" is a fleet-level assertion and the three states behave nothing alike. Preconditions, which is exactly where this control gets over-claimed as removing the surface outright: a blacklist prevents the on-demand load and does nothing on a host where rds is already loaded — that host also needs the module unloaded, and the unload fails while anything holds an RDS socket open, so a host that cannot be quiesced enough to unload is a reboot rather than a blacklist. A blacklist does nothing at all where RDS is built into the kernel image rather than shipped as a module: there is no module to refuse, the AF_RDS path exists from boot, and the only remediation there is the fixed kernel — address validation in rds_page_copy_user, in 2.6.36 or a distro backport — with the reboot the packet says it requires. And hosts that genuinely use RDS cannot take this mitigation in any form; they are patch-and-reboot items with no interim compensating control from this direction. Distinguishing test: on a representative host, as an unprivileged user, attempt to open an AF_RDS socket and confirm it fails, and confirm rds is absent from the loaded module set — not merely that a blacklist file is present in configuration. A configuration-management attestation showing the blacklist deployed passes on a host that loaded rds before the file landed and on a host whose kernel has RDS built in, and on both the arbitrary-kernel-write path is still fully reachable by any local account.",
+        "evidence": "Packet live_patch_notes: \"the kernel fix (address validation in rds_page_copy_user, in 2.6.36 or a distro backport) requires a reboot to take effect. As a non-reboot mitigation, the RDS module can be blacklisted/unloaded on hosts that do not use it, removing the reachable code path without an immediate kernel update,\" with patch_available true and live_patch_available false. Packet vector: rds_page_copy_user in net/rds/page.c in the RDS implementation in the Linux kernel before 2.6.36 does not properly validate addresses obtained from user space, allowing local users to gain privileges via crafted use of sendmsg and recvmsg. Packet attack_vector: \"A local user opens an AF_RDS socket and issues crafted sendmsg/recvmsg calls,\" giving an arbitrary kernel write leveraged to escalate to root. poc_available true; CISA KEV listed 2023-05-12; active_exploitation confirmed; rwep_score 70. The entry cites NIST-800-53-CM-7, ISO-27001-2022-A.8.9, AU-Essential-8-App-Hardening and UK-CAF-B4 as insufficient; the lesson's framework_coverage records that stock distributions left the module auto-loadable and that only patching to 2.6.36+ or disabling the module closes it.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9",
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry produces the middle state the control exists to name, and produces it by design rather than by accident. The packet records no vendor live patch, a kernel fix that requires a reboot, and a module blacklist or unload as the interim mitigation — so a host with rds blacklisted is not patched: the unvalidated rds_page_copy_user copy is still present in the running kernel and becomes reachable again the instant anything loads the module. The requirement is that compliance records for this CVE carry that as its own verdict — mitigation active, vulnerable kernel running, reboot pending, with a dated action item for the fixed kernel — and never merge it into the same remediated bucket as a host actually running 2.6.36 or a backported kernel. The distinction is operational rather than clerical, because the events that silently return a mitigated host to full exposure are all routine maintenance: a kernel package upgrade or image rebuild that reinstates a default module configuration, a host restored from a baseline predating the blacklist, or a new host provisioned from an older image. None of those generate a vulnerability event, because from the scanner's point of view nothing about the host changed, so a fleet can drift back toward exposure while its remediation count for this CVE holds steady. Distinguishing test: take any host recorded as remediated on CVE-2010-3904 and check whether its record distinguishes \"module blacklisted\" from \"running a fixed kernel\"; if the report cannot tell those apart, the remediation count includes hosts that are one configuration-management run from exploitable by any local account. Precondition: this control changes what is recorded and what action is scheduled — it removes no code path itself, and a host sitting in the mitigated state carries the residual risk for as long as the reboot is deferred, which on a long-lived server is the entire point of the deferral.",
+        "evidence": "Packet live_patch_notes records both states explicitly: no vendor-provided live patch is published for this CVE, the kernel fix requires a reboot to take effect, and the RDS module can be blacklisted/unloaded as a non-reboot mitigation on hosts that do not use it. patch_available true with live_patch_available false. Packet attack_vector: a local user opens an AF_RDS socket and issues crafted sendmsg/recvmsg calls for an arbitrary kernel write leveraged to root; poc_available true and active_exploitation confirmed, CISA KEV listed 2023-05-12. The entry cites NIS2-Art21-vulnerability-management and ISO-27001-2022-A.8.9 as insufficient; the lesson's framework_coverage records the A.8.9 gap as configuration drift and default-on modules sustaining the exposure.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The blacklist and the patch are not equivalent removals here, which is why dropping the blacklist once the fixed kernel lands is a net loss of posture on hosts that never used RDS. The packet's fix is address validation in rds_page_copy_user — one function, one missing check. Refusing to load net/rds removes reachability of the whole subsystem, of which the unvalidated copy is one defect. So on any host where the inventory established that RDS carries no business function, the blacklist should be treated as a permanent least-functionality decision that survives the kernel upgrade, not as a temporary measure to be reverted when the patched kernel boots. The concrete failure this prevents is a rollback framed as cleanup: an operator reversing the modprobe configuration as part of closing the CVE ticket, restoring an unprivileged-reachable protocol implementation to a host that had no use for it, and doing so at exactly the moment the change looks safest. Distinguishing test: after the fixed kernel is deployed and the host has restarted, confirm the blacklist entry is still in place and that an unprivileged AF_RDS socket open still fails — a remediation workflow that reverts compensating configuration on patch confirmation will show a host that is patched for this CVE and once again carrying the full net/rds surface. Precondition: this governs retention of a control that was available in the first place. It gives nothing to a host where RDS is in genuine use or is built into the kernel image, since no blacklist existed there to retain, and it is not a reason to defer the fixed kernel — the retention applies after the patch lands, not instead of it.",
+        "evidence": "Packet live_patch_notes names both the fix and the mitigation: \"the kernel fix (address validation in rds_page_copy_user, in 2.6.36 or a distro backport) requires a reboot to take effect. As a non-reboot mitigation, the RDS module can be blacklisted/unloaded on hosts that do not use it, removing the reachable code path.\" Packet vector scopes the defect to rds_page_copy_user in net/rds/page.c failing to validate addresses obtained from user space. Packet attack_vector: an unprivileged local user reaches it by opening an AF_RDS socket. The entry cites NIST-800-53-CM-7 (Least Functionality) and ISO-27001-2022-A.8.9 (Configuration management) as insufficient; the lesson's framework_coverage records the CM-7 gap as stock distributions leaving the module auto-loadable so hosts that never used RDS still exposed the arbitrary-kernel-write path.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9"
+        ]
+      }
+    ]
   },
   "CVE-2015-5317": {
     "name": "Jenkins User Interface (UI) Information Disclosure Vulnerability",
@@ -57177,7 +58857,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management may rank a 2015 info-disclosure as low priority, yet its KEV status means the leak of otherwise-restricted job/build names remains a live reconnaissance vector on any Jenkins below 1.638 / LTS 1.625.2."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Jenkins enforces per-item access control at the view layer, and this CVE is one view not enforcing it: the packet has a direct request to the Fingerprints pages returning the names of jobs and builds the requester is not authorized to see. Bound to this product, the control means every Jenkins page and endpoint resolves the caller's permission on the specific item it is about to name — the fingerprint record, the job, the build — before it renders, rather than inheriting the verdict that allowed the caller to reach Jenkins at all; and the Jenkins web surface is segmented so callers with no operational need cannot issue that direct request in the first place. This is exactly why the access-enforcement gap recorded on this entry passes its attestation while the path stays open: the deployment's authorization matrix can be configured precisely as intended, reviewed, and evidenced, and this page still never consults it, so the finding is invisible to any audit that inspects the permission configuration rather than the response body. Precondition: the per-page authorization behaviour is what upgrading to 1.638 or later (LTS 1.625.2 or later) establishes — this control states the property to verify, it does not implement it — and the packet records no live-patch mechanism, so until that release and the Jenkins service restart land, restricting who can reach the controller (removing anonymous read, fronting it with authenticated access, taking it off any internet-reachable path) bounds the population that can issue the request and leaves it fully effective for every developer, contractor and service account that legitimately reaches Jenkins, which on a shared controller is most of the organization. Distinguishing test: with an account authorized to read exactly one job, request the Fingerprints pages on a staging controller and confirm no job or build name outside that account's authorization appears in the response — an attestation that Jenkins role-based authorization is configured and reviewed passes cleanly while this page keeps answering.",
+        "evidence": "Packet: CWE-200. Vector: 'The Fingerprints pages in Jenkins before 1.638 and LTS before 1.625.2 might allow remote attackers to obtain sensitive job and build name information via a direct request.' attack_vector: 'A direct request to the Jenkins Fingerprints pages returns names of jobs and builds the user is not authorized to see, disclosing CI/CD pipeline structure for reconnaissance.' NIST-800-53-AC-3 (Access Enforcement) is recorded among the citing gaps. patch_available true; live_patch_available false with live_patch_notes requiring the upgrade to 1.638 or later (LTS 1.625.2 or later) and a Jenkins service restart.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The remediation this packet records is narrow and fully specified: upgrade Jenkins to 1.638 or later (LTS 1.625.2 or later) and restart the Jenkins service. There is no live-patch mechanism, so a controller whose WAR was replaced but whose service was never restarted is still serving the vulnerable pages and has to be counted exposed rather than patched. What puts this on the KEV clock is not the score — RWEP 36, CVSS 7.5, and the packet records no public PoC — but that exploitation is confirmed in the wild while the technique the packet describes is a direct request to a page, so the absence of published exploit code is no barrier to its use and no reason to let the item sit in a low-severity queue. The population this control has to reach is precisely the one a severity-ordered backlog deprioritizes: a controller still on a pre-1.638 line at the 2023-05-12 KEV listing is not a host waiting on a vendor, it is a host nobody owns — a team-run build server, an instance left behind after a migration to another CI system, a controller inside a project VM. So the first obligation here is enumeration: every Jenkins controller reachable on the estate, with its reported version and its service start time, discovered from the network rather than taken from the CI team's inventory. Precondition: the compensating-control branch of this SLA is weaker than usual for this CVE. The disclosure happens on an ordinary page request, so there is no distinctive request pattern for a proxy or WAF rule to key on, and restricting reachability only narrows who can ask — it does not stop the page answering. Remediation is also not restorative: job and build names disclosed before the upgrade stay disclosed, and the packet identifies the value of that disclosure as reconnaissance on CI/CD pipeline structure, so a controller with confirmed exposure warrants review of what that structure reveals rather than closure on the version bump alone.",
+        "evidence": "Packet: CISA KEV 2023-05-12, active_exploitation confirmed, poc_available false, CVSS 7.5, RWEP 36, CWE-200. patch_available true, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation requires upgrading Jenkins to 1.638 or later (LTS 1.625.2 or later) and restarting the Jenkins service.' Vector names the affected versions ('before 1.638 and LTS before 1.625.2') and the technique ('via a direct request'); attack_vector states the disclosure is of 'CI/CD pipeline structure for reconnaissance'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2016-3427": {
     "name": "Oracle Java SE and JRockit Unspecified Vulnerability",
@@ -57482,7 +59185,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management relies on an accurate component inventory (SBOM); without one, organizations could not enumerate where the vulnerable Log4j library ran, leaving a ransomware-associated RCE unremediated well past the KEV due date."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This CVE exists because a prior remediation was incomplete: the packet's vector states the fix that addressed CVE-2021-44228 in Log4j 2.15.0 was incomplete in certain non-default configurations, leaving the same JNDI-lookup primitive reachable through attacker-controlled Thread Context Map data. That makes the operator's problem a records problem as much as a code problem — the version move to 2.15.0 is already closed on the flaw-remediation ledger, so the follow-on step reads as a routine minor bump rather than as an unremediated actively-exploited flaw. Applied to this CVE, an application on 2.15.0 must be scored as unremediated for this primitive and driven to 2.16.0 (Java 8) or 2.12.2 (Java 7) with the affected Java application restarted, on the clock that opened with the 2023-05-01 KEV listing. The sequence position also sets the standard for what counts as a fix: the packet credits the fixed releases with removing support for message lookup patterns and disabling JNDI functionality by default — a capability removal — so a narrower fix on this same primitive should be treated as provisionally incomplete until the capability-removing version is in service. Distinguishing test: pull the remediation evidence for this CVE and check what it points at; if it points at the December 2021 Log4Shell response rather than at a per-application version reading of 2.16.0 or 2.12.2 on the runtime classpath, the attestation is recording the first CVE's closure as this one's.",
+        "evidence": "Packet vector: the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations, allowing attackers with control over Thread Context Map (MDC) input data to craft a JNDI Lookup pattern; the packet states Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix the issue by removing support for message lookup patterns and disabling JNDI functionality by default. live_patch_notes: remediation requires upgrading Log4j to 2.16.0 (Java 8) or 2.12.2 (Java 7) and restarting the affected Java application. CISA KEV-listed 2023-05-01, active_exploitation confirmed, PoC available, CVSS 9.0, RWEP 74, patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet itself separates the two states this control requires an audit to distinguish: removing the JndiLookup class from the classpath is recorded as a stopgap mitigation, not a vendor live-patch, while remediation is upgrading to 2.16.0 (Java 8) or 2.12.2 (Java 7) and restarting the affected Java application. Applied to this estate, every Java application carrying Log4j needs an explicit verdict of (a) fixed version resolved on the runtime classpath and the application restarted, (b) still on an affected version with the JndiLookup class stripped, or (c) neither — and (b) has to appear as a time-bound compensating-control state with a dated action item, never as a patched-per-SLA outcome. Preconditions on (b), which are the reason it cannot be recorded as closure: the stopgap holds only while that class stays absent from the artifact, so a redeploy, a dependency re-resolution, a rollback to an earlier build, or a restore that reinstates the original library returns the application to full exposure silently, and the removal is applied per artifact rather than centrally, so it has to be re-verified on every build rather than once. It also leaves the affected version in place, so the capability changes the packet credits the fixed releases with — removal of message lookup patterns and JNDI disabled by default — are not in effect for anything else that reaches the same code. And because the fix takes effect only on restart, an application whose dependency was upgraded but whose process has not been restarted is still state (c) dressed as state (a). Distinguishing test: for each application recorded in state (b), rebuild it from its own pipeline and inspect the produced artifact for the JndiLookup class; if it comes back, the mitigation was a one-off edit to a deployed artifact and the next deployment reopens the flaw.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism; remediation requires upgrading Log4j to 2.16.0 (Java 8) or 2.12.2 (Java 7) and restarting the affected Java application. The stopgap of removing the JndiLookup class from the classpath is a mitigation, not a vendor live-patch.' patch_available true, live_patch_available false. Packet vector states the fixed releases remove support for message lookup patterns and disable JNDI functionality by default. CISA KEV-listed 2023-05-01, active_exploitation confirmed, PoC available, CVSS 9.0, RWEP 74.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "Log4j is not an installed product on this estate but a library reached through Java applications — the packet's remediation is expressed per application (upgrade Log4j and restart the affected Java application), so how much of the estate is remediated is exactly how much of it the dependency inventory can see. Applied to this CVE, the inventory has to record per application: the Log4j version actually resolved onto the runtime classpath rather than only the version named as a direct dependency; the Java track, because the packet gives different fixed releases for Java 8 (2.16.0) and Java 7 (2.12.2), so a single target version applied estate-wide leaves one track wrong; and whether the logging configuration uses a non-default PatternLayout with a Context Lookup or a Thread Context Map pattern (%X, %mdc, %MDC), which the packet gives as the condition under which attacker-controlled MDC data reaches the JNDI lookup. That last item is a configuration property rather than a code property, so an application marked not-exploitable on configuration grounds is re-exposed the moment someone adds a correlation-id pattern to a log format, with no dependency change to trigger a re-scan — it has to be re-checked on logging-configuration change, not only on dependency change. Distinguishing test: take applications whose declared direct dependencies name no Log4j at all and enumerate their resolved runtime classpath; an inventory built from declared direct dependencies reports full coverage while transitively-included copies sit on an affected version.",
+        "evidence": "Packet live_patch_notes: remediation requires upgrading Log4j to 2.16.0 (Java 8) or 2.12.2 (Java 7) and restarting the affected Java application — two fixed releases on two Java tracks, applied per application. Packet vector conditions exploitation on a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) plus attacker control over MDC input data. The entry cites NIS2 Art. 21 supply-chain security measures as a framework gap. CISA KEV-listed 2023-05-01, active_exploitation confirmed, PoC available, CVSS 9.0, RWEP 74.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-21839": {
     "name": "Oracle WebLogic Server Unspecified Vulnerability (CVE-2023-21839)",
@@ -57604,7 +59339,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",
@@ -57726,7 +59484,30 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management could only react — the sandbox escape was a zero-day, so remediation depended on rapidly deploying Chrome 112.0.5615.137 across all managed endpoints."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet gives a fixed build — Chrome/Chromium 112.0.5615.137 — and a KEV-listed sandbox escape under confirmed exploitation, which is the case a staged enterprise update ring is worst at: the ring exists to soak a release across a validation window, and the window is the exposure. For this CVE the control means the security-channel update to 112.0.5615.137 or later is pushed to every managed Chrome/Chromium install on the clock that opened with the 2023-04-21 KEV listing, with user deferral disabled, and completion measured by the build each browser instance is actually running rather than by the version approved or staged in the management console; the packet records no live-patch mechanism, so an instance still executing a pre-112.0.5615.137 build carries the vulnerable Skia even once the newer build is on disk. This is also the control that carries the exposure the user-application-hardening gap cited on this entry cannot: hardening settings govern what content the renderer is allowed to process, whereas the packet places this defect at the step after that — reached from a renderer the attacker already controls — so no hardening setting narrows the Skia integer overflow, and a hardening attestation passes cleanly while the escape stays available. Priority follows the packet rather than the absence of a public exploit: no PoC is recorded, but exploitation is confirmed, so waiting for a public PoC to raise the priority inverts the evidence. Precondition: this reaches only installs the browser update channel manages; a Chromium build shipped inside another product does not take the Chrome update and is not covered here — it belongs to the embedded-component inventory and parity requirement instead.",
+        "evidence": "Packet vector: 'Integer overflow in Skia in Google Chrome prior to 112.0.5615.137 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.' attack_vector: from a renderer process the attacker already controls, the crafted page drives the overflow to break out of the sandbox and execute in the higher-privileged browser process. live_patch_notes: no live-patch mechanism; remediation requires updating Chrome/Chromium to 112.0.5615.137 or later. CISA KEV-listed 2023-04-21, active_exploitation confirmed, poc_available false, patch_available true, live_patch_available false, CVSS 9.6, RWEP 45. The entry cites ASD Essential Eight user application hardening as a framework gap.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet puts the defect in Skia — an embedded rendering component, not a separately installed product — and states remediation as two distinct actions: update Chrome/Chromium to 112.0.5615.137 or later, and rebuild the downstream products that embed the affected Skia, which it names as ChromeOS, Android and Flutter. Those are separate update tracks, so an attestation built on the browser fleet closes only the first action while shipped copies of the same vulnerable code stay in service. Applied here, the control means enumerating, alongside managed Chrome installs, the packet-named downstream products actually in service — ChromeOS devices, Android builds, and applications built with Flutter — and confirming each is on a build produced after the Skia fix, since each carries its own copy that the Chrome update never touches. Scope it to those products: the packet ties the affected Skia to Chrome/Chromium and to ChromeOS, Android and Flutter and provides no mapping into other software embedding Skia, so instructing operators to treat every graphics-rendering binary in the estate as an instance of this CVE manufactures rebuild and removal work against products no evidence here implicates; widen only where a verified source names another product carrying the affected component. Distinguishing test: after the Chrome fleet reports 112.0.5615.137, take one in-service Flutter-built application and one Android or ChromeOS image and show each was produced after the Skia fix — an estate whose flaw-remediation evidence is the browser inventory alone reads clean while shipped software still embeds the vulnerable code. Precondition: rebuilding is available only for products the operator builds, or for which a fixed build can be obtained; a downstream product whose supplier ships no rebuilt version is not remediated by this control and stays on the exposure register rather than being closed by it.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism; remediation requires updating Chrome/Chromium to 112.0.5615.137 or later and rebuilding downstream products (ChromeOS, Android, Flutter) that embed the affected Skia.' Packet vector places the integer overflow in Skia in Google Chrome prior to 112.0.5615.137, reachable via a crafted HTML page from a compromised renderer process to escape the sandbox. CISA KEV-listed 2023-04-21, active_exploitation confirmed, poc_available false, patch_available true, live_patch_available false, CVSS 9.6, RWEP 45.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2017-6742": {
     "name": "Cisco IOS and IOS XE Software SNMP Remote Code Execution Vulnerability",
@@ -57787,7 +59568,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management frequently omits network-device firmware from the vulnerability program; organizations without an inventory of IOS/IOS XE SNMP exposure could not identify or remediate the vulnerable routers before state-sponsored exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Bound to a Cisco IOS / IOS XE device that was SNMP-reachable from untrusted space while this flaw was unpatched, this control needs re-scoping rather than restating, because its usual premise does not hold here: the packet's implant is in-memory (Jaguar Tooth) and the packet's remediation is a fixed Cisco software release that reboots the device, so the upgrade itself clears memory-resident code. What the upgrade does not touch is the exploit's own precondition. The packet requires the attacker to already know the device's SNMP read-only community string (v1/v2c) or its SNMPv3 user credentials, and an image upgrade rotates neither — so the same access that produced the first implant works against the rebooted device, and the second run costs the attacker nothing. It also does not surface anything the attacker changed while resident. Applied to this device, remediation is three steps, not one: before the reload discards volatile state, capture and diff the running and startup configuration against a known-good baseline (SNMP community and user definitions, ACLs, any added local accounts, any configuration that would restore attacker access after reboot); rotate every SNMP community string and SNMPv3 credential the device carries and every device that shares them, since a community string is a per-device shared secret rather than a per-operator one; then bring the device up on the fixed release from the baseline configuration rather than from the configuration the compromised device saved for itself. Distinguishing test: after the upgrade, show that the device's SNMP credentials differ from the pre-incident values and that its running configuration matches the baseline — an estate that records the fixed IOS release against the asset and closes the ticket has remediated the overflow and preserved the credential. Preconditions and limits: the configuration diff assumes a known-good baseline exists to diff against; where none does, the step degrades to an engineer reviewing the configuration line by line and is weaker for it. And rebuilding the device does not tell you what the resident implant read or reached from that position, so a device confirmed compromised still owes downstream credential rotation for anything it held or could authenticate to.",
+        "evidence": "Packet: CWE-119 buffer overflow in the SNMP implementation of Cisco IOS and IOS XE; the attacker 'must know the SNMP read only community string (SNMP version 2c or earlier) or the user credentials (SNMPv3)'; attack vector records that APT28 used it to inject the in-memory Jaguar Tooth implant; CISA KEV-listed 2023-04-19 with active_exploitation confirmed and poc_available true; RWEP 73 / CVSS 8.8; patch_available true and live_patch_available false, with the live-patch note stating remediation requires upgrading to a Cisco fixed software release per advisory cisco-sa-20170629-snmp, which reboots the device. AU-Essential-8-Patch and ISO 27001:2022 A.8.8 are recorded as insufficient for this entry — both are satisfied the moment the fixed release is installed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The SNMP agent on IOS / IOS XE is the listener class this control governs, on a router rather than an application server: a non-HTTP management protocol that answers on the device itself, whose parser is the vulnerable code, and which the packet says is exploitable only by traffic directed at the affected system. The requirement for these devices is that the SNMP agent answers only the management hosts that legitimately poll it — enforced with an SNMP access list and view on the device plus infrastructure ACLs on the paths that reach it, rather than assumed from 'the management VLAN is internal' — and that the affected MIBs and OIDs the packet's mitigation names are removed from the served view wherever the estate does not poll them, which is the least-functionality step the CM-7 gap is about. Distinguishing test: from a general user VLAN and from external transit, send SNMP requests at a staging device and confirm they are dropped before the agent parses them; a device that passes a configuration audit for 'SNMPv3 with authentication enabled' while its agent still answers packets sourced from anywhere has satisfied the audit and left the overflow reachable. Preconditions, and this is where the control is easy to over-claim: restricting reachability bounds who can send the crafted packet, it does not repair the parser, and the packet states the flaw affects all versions of SNMP (1, 2c and 3) — so moving the estate to SNMPv3 with strong credentials raises the cost of obtaining a valid credential but leaves the overflow fully reachable by anyone holding one, and a leaked v1/v2c community string is a single shared secret rather than a per-operator account. The monitoring platform that must poll the device is by definition inside the permitted set, so its compromise satisfies the exploit's stated access precondition in full. This is the holding measure for the window before the fixed software release lands, and taking that release reboots the device.",
+        "evidence": "Packet: 'The vulnerability is due to a buffer overflow in the affected code area. The vulnerability affects all versions of SNMP (versions 1, 2c, and 3)'; 'Only traffic directed to the affected system can be used to exploit this vulnerability'; the live-patch note records Cisco's recommended mitigations as restricting SNMP access to trusted management hosts, disabling affected MIBs/OIDs, and enforcing SNMPv3 with strong credentials, with the fixed software release (which reboots the device) as the remediation; live_patch_available false; KEV 2023-04-19, active_exploitation confirmed, poc_available true. NIST 800-53 CM-7 (Least Functionality), NIS2 Art.21 security of network and information systems, and UK CAF B4 (System security) are the framework controls recorded as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2019-8526": {
     "name": "Apple macOS Use-After-Free Vulnerability",
@@ -57970,7 +59774,29 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management presumes remediation can be scheduled, but the availability of the fix for this Framework LPE is gated by Android security-patch-level delivery per OEM, so vulnerability-management SLAs cannot guarantee closure of the privilege-escalation path on affected fleets."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's precondition is an app already on the device, and the outcome is local privilege escalation with no additional execution privileges needed and no user interaction — so on a handset below the 2023-03-01 Android security patch level there is no prompt to decline, no permission grant to review and no user decision in the path, and the only lever left is what organizational data that handset is permitted to hold. Applied to this CVE, the 2023-03-01 or later patch level must operate as an access condition across the affected Android 11, 12, 12L and 13 population — mail, VPN and document access denied to a device below it — rather than as a reported field on a patch-compliance dashboard. Distinguishing test: enrol an Android device pinned below the 2023-03-01 patch level and confirm the policy actually refuses it access to protected resources; an estate that surfaces the stale patch level on a report while the device keeps its mail and VPN access has recorded the exposure rather than removed it. Precondition, and this is where the control gets over-claimed: restricting installs to a managed catalogue and blocking sideloading raises the bar for getting the attacker's app onto the device, but it evicts nothing already installed and does not cover an app that arrived through the normal store channel, so a device suspected of already running such an app belongs on the incident path rather than the install-policy path. And because the packet frames remediation as the device receiving the 2023-03-01 or later patch level as a system update, a device model that is never offered that patch level cannot be brought into compliance by any policy the operator holds: for those handsets the access condition is a standing posture, not a bridge, and replacement is the terminal state — leaving them enrolled with an open exception marks them compliant while they stay exposed to everything found since.",
+        "evidence": "Packet vector: 'In WorkSource, there is a possible parcel mismatch. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android Versions: Android-11 Android-12 Android-12L Android-13 Android ID: A-220302519'. attack_vector: a malicious app already on the device triggers the Parcel serialization mismatch in WorkSource, causing the system to grant the app elevated privileges without extra permissions or user interaction. live_patch_notes: no live-patch mechanism for the Android Framework; remediation requires the device receiving the 2023-03-01 (or later) Android security patch level, installed as a system update that reboots the device. CISA KEV-listed 2023-04-13, active_exploitation confirmed, poc_available false, patch_available true, live_patch_available false, CVSS 7.8, RWEP 49.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this CVE remediation is a single event per handset — the device takes the 2023-03-01 or later Android security patch level as a system update and reboots — so the control is about driving that event across the enrolled Android 11, 12, 12L and 13 population on the clock that opened with the 2023-04-13 KEV listing, with user deferral prohibited and the restart forced rather than left to the user's convenience. Completion is counted per device from the security patch level reported after the restart, because the packet records no live-patch mechanism for the Android Framework: a handset that has downloaded and staged the update but not rebooted is still running the affected framework, and on a personal-feeling device the reboot is precisely the step users postpone, which is the specific way this remediation is recorded as done while remaining undone. Precondition, stated because this is where a mobile patch SLA is routinely over-claimed: the management policy can prohibit deferral and force installation of an update the device has already been offered, but it cannot produce a patch level that the device's OEM or carrier update channel has not shipped for that model. The SLA therefore has to be measured against per-model availability, and models with no 2023-03-01 or later build available fail this control by definition — they must be surfaced as unremediated devices carrying a replacement decision, not counted as compliant on the grounds that the policy was applied to them.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism for the Android Framework; remediation requires the device receiving the 2023-03-01 (or later) Android security patch level, which is installed as a system update and reboots the device.' Packet vector names the affected versions as Android-11, Android-12, Android-12L and Android-13 and states the escalation needs no additional execution privileges and no user interaction. CISA KEV-listed 2023-04-13, active_exploitation confirmed, poc_available false, patch_available true, live_patch_available false, CVSS 7.8, RWEP 49.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-29492": {
     "name": "Novi Survey Insecure Deserialization Vulnerability",
@@ -58092,7 +59918,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)",
@@ -58519,7 +60368,32 @@
         "adequate": false,
         "gap": "A.8.8 would score this 'low' on CVSS alone and defer it, but the KEV listing and spyware chain show the leak's real weight as an exploitation primitive; assessing it purely by base severity mis-prioritises the mobile-fleet patch it actually needs."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's exploit precondition is a non-privileged application performing valid Mali GPU operations — nothing malformed, nothing that fails — and the packet records the fix reaching devices only as the Arm-fixed Mali driver bundled into an OEM/Android security update that reboots the handset. Applied to this driver, the control means each enrolled handset's security-patch level is evaluated as an access condition on what the device may reach — mail, VPN, document and MDM-brokered data withheld from any device below the level that carried the fixed driver — rather than surfaced as a red row on a patch-compliance report while the device keeps its access. The driver-version half is load-bearing here because the affected ranges are per-architecture (Midgard r6p0-r32p0, Bifrost r0p0-r42p0, Valhall r19p0-r42p0, Avalon r41p0-r42p0), so a fleet policy keyed on OS version alone will pass a device still running an in-range driver. The distinguishing test is to enrol a handset pinned below the bulletin level that carried the fixed driver and confirm the policy actually denies it protected-resource access — an estate that lists the stale device on a report while it keeps its mailbox has recorded the exposure rather than removed it. Precondition, stated because it is where this control is usually over-claimed: restricting installation to vetted store applications raises the bar for getting the attacker's non-privileged app onto the handset, but it does not evict an app already installed and does not cover one delivered through the normal store channel, so a device suspected of already running it belongs on the incident path, not the install-policy path. Terminal state: the entry's framework_coverage records that handsets past their Android security-update window keep this leak with no available fix, so for those models the fixed build is unreachable and the requirement ends in removing the device from the estate on a dated schedule — a rule that ends at 'every handset reports the fixed driver' marks a model whose OEM has stopped shipping bulletins as compliant while it stays exposed.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-04-07, active_exploitation 'confirmed', poc_available true; CVSS 3.3, RWEP 66; ai_discovered false. Vector: 'Memory leak vulnerability in Mali GPU Kernel Driver in Midgard GPU Kernel Driver all versions from r6p0 - r32p0, Bifrost GPU Kernel Driver all versions from r0p0 - r42p0, Valhall GPU Kernel Driver all versions from r19p0 - r42p0, and Avalon GPU Kernel Driver all versions from r41p0 - r42p0 allows a non-privileged user to make valid GPU processing operations that expose sensitive kernel metadata.' attack_vector: a non-privileged app performs valid Mali GPU operations that cause the driver to expose raw kernel pointers via a user-readable timeline-stream ring buffer, leaking kernel metadata that defeats KASLR and enables the next stage of a kernel exploit chain. patch_available true, live_patch_available false; live_patch_notes: 'No live-patch mechanism; remediation is the Arm-fixed Mali GPU driver delivered via the OEM/Android security update, applied through a device update that reboots the handset.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "A CVSS 3.3 information disclosure does not survive a severity-threshold patch queue. Most estates set the intake bar at high or critical, so this entry is filtered out of the remediation backlog before a human reads it — which is exactly how a KASLR-defeat primitive stays resident on a handset fleet. Applied to this CVE, the control means the 2023-04-07 KEV listing rather than the 3.3 base score starts the clock on the Mali driver, and queue position follows the packet's RWEP of 66 with confirmed exploitation and a public PoC. The distinguishing test is to reconstruct the remediation queue as it stood on the KEV date and look for this CVE: on a CVSS-banded triage it will be absent rather than deferred, and absent is the failure this control exists to catch — a deferred item at least has an owner. Precondition, and it is the whole difficulty on a handset estate: the operator does not control when an OEM ships the Arm-fixed driver, so for a model whose bulletin has not landed the requirement cannot resolve to the patch branch at all. It resolves instead to the control's documented-compensating-control branch, and on this CVE that branch can only be an access decision, because the packet has the leak occurring during valid GPU processing operations that user space is entitled to perform — there is no on-device setting, driver option or monitoring rule that removes the read, so a compensating control recorded as 'hardened' or 'monitored' here is a compensating control that does not exist.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-04-07, active_exploitation 'confirmed', poc_available true. CVSS 3.3 against RWEP 66 — the packet's attack_vector states why the two disagree: the exposed kernel metadata is what 'defeats KASLR and enables the next stage of a kernel exploit chain'. The vector states the exposure occurs when a non-privileged user makes valid GPU processing operations. patch_available true, live_patch_available false; live_patch_notes: 'No live-patch mechanism; remediation is the Arm-fixed Mali GPU driver delivered via the OEM/Android security update, applied through a device update that reboots the handset.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2022-27926": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Vulnerability (CVE-2022-27926)",
@@ -58763,7 +60637,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",
@@ -59312,7 +61209,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",