@blamejs/exceptd-skills 0.19.18 → 0.19.20

package/data/zeroday-lessons.json

@@ -22530,7 +22530,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Jenkins CLI's remoting channel is exactly the binary remoting-protocol class this control governs: the packet describes a serialized Java SignedObject transferred to the remoting-based Jenkins CLI and deserialized with a new ObjectInputStream, so the endpoint reconstructs attacker-supplied objects before any authentication decision and the parser is itself the vulnerable code — which is why a perimeter firewall and the web-tier hardening most Jenkins deployments are audited against never touch it. Bound to this deployment, the control means the controller's remoting endpoint accepts connections only from hosts that legitimately speak it (build agents, and the administrator jump hosts where the CLI is genuinely used), enforced by network ACL or host firewall rather than inherited from 'Jenkins is internal', with any internet-reachable controller taken first. The UK CAF gap on this entry is the assumption being corrected — an internal build server scored as low-exposure while an unauthenticated RCE on it hands over the pipeline's signing and deploy keys — and the NIS2 gap is the same point at directive level: the compromise is a software-supply-chain event across every downstream build, so the controller's segmentation has to be justified by blast radius, not by where the box sits. Distinguishing test: from a general developer VLAN and from an external address, open a connection to the remoting port of a staging controller and send a serialized object; anything that reaches the deserialization path is exposed to the published exploit, while a clean Jenkins role-and-permission audit says nothing about whether that port answers. Precondition: reachability restriction bounds who can send the object, it does not repair the deserialization path, it is unavailable wherever agents must reach the controller, and it gives nothing on a controller already exploited — the packet records a vendor fix with no live-patch path and a service restart or system reboot required, so until that restart the controller is still executing the vulnerable code.",
+        "evidence": "Packet fields: cwe_refs CWE-94; vector states attackers transfer a serialized Java SignedObject to the remoting-based Jenkins CLI, deserialized using a new ObjectInputStream, bypassing the existing blocklist-based protection mechanism; attack_vector records unauthenticated remote code execution on the CI server; cisa_kev true, kev_date 2025-10-02; active_exploitation confirmed; poc_available true; cvss 9.8, rwep_score 77; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes recording a service restart or system reboot per the KEV requiredAction. The UK-CAF-B4 gap states that system-security controls treat an internal build server as low-exposure while this deserialization RCE hands attackers the signing and deploy keys of the whole pipeline; the NIS2-Art21-network-security gap states Jenkins is a CI/CD control point whose compromise poisons every downstream build and that the measures focus on perimeter and segmentation rather than on an internal unauthenticated-RCE build server.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "This CVE is the exact failure this control exists to prevent: the packet records that the serialized SignedObject was deserialized with a new ObjectInputStream and that this bypassed the existing blocklist-based protection mechanism — so an enumeration of classes known to be dangerous was the only thing between an unauthenticated peer and code execution, and wrapping the payload in a permitted type defeated it. For Jenkins the requirement is that the remoting endpoint authenticate its peer before any object is reconstructed, and that what arrives on that channel be constrained by what the protocol legitimately conveys rather than by a denylist, which is only ever as current as its last update. This is also the control that answers the least-privilege gap recorded on this entry: the attacker holds no Jenkins account, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the endpoint deserializes for anyone who can reach it — the decision point has to move to the endpoint's own peer authentication rather than to the account model behind it. Distinguishing test: from an unauthenticated host that can route to the remoting port of a staging controller, send a serialized object wrapped in a type the blocklist permits, and confirm the peer is rejected before the object is reconstructed. Precondition: this endpoint-side property is what the vendor fix establishes — the control states what to verify, not what the operator implements — so until the fixed release named in the vendor advisory is deployed and the service restarted, the only operator-side lever is who can reach the port, and that bounds the attacker population rather than closing the path.",
+        "evidence": "Packet fields: vector states the serialized Java SignedObject sent to the remoting-based Jenkins CLI is deserialized using a new ObjectInputStream, bypassing the existing blocklist-based protection mechanism; cwe_refs CWE-94; attack_vector records unauthenticated remote code execution on the CI server; poc_available true; active_exploitation confirmed; patch_available true with patch_required_reboot true and live_patch_available false; affected_versions recorded only as 'Jenkins Jenkins — versions per vendor advisory'. The NIST-800-53-AC-6 gap states that least privilege presumes a working authentication/authorization boundary and that the KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is a 2017-era flaw that CISA listed on 2025-10-02, so the population it addresses is not controllers that missed one patch window but controllers that have not been upgraded in years — which is why the routine 30-day flaw-remediation clock the SI-2 gap describes never reaches them, and why the undefined 'appropriate timescales' reading in ISO A.8.8 and the Essential-Eight cadence the AU gap names can all be satisfied while the instance stays unauthenticated-RCE-exploitable. For this CVE the control means the KEV listing date, not the CVE's disclosure age, starts the clock on every Jenkins controller in the estate, and completion is measured by the version the running controller process reports after its restart rather than by a package or archive having been replaced: the packet records patch_available true with no live-patch path and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, so a staged upgrade that has not been restarted into is not remediation. Take the fixed version from the vendor advisory — the packet records affected versions only as 'Jenkins Jenkins — versions per vendor advisory', so a sweep keyed on a guessed build string will mark instances clean that are not. Distinguishing test: enumerate every Jenkins controller including the ones stood up by teams outside the platform group, and produce for each the version its running process reports; the instances this flaw survives on are the ones no patch programme knows about, and an inventory-scoped attestation reads clean while they run.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2025-10-02 for a CVE identified as CVE-2017-1000353; active_exploitation confirmed with active_exploitation_notes stating the KEV listing is CISA's confirmed-exploitation attestation and in-wild observation may predate the dateAdded; poc_available true; cvss 9.8, rwep_score 77; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes recording a service restart or system reboot per the KEV requiredAction; affected_versions 'Jenkins Jenkins — versions per vendor advisory'. The NIST-800-53-SI-2 gap records the 30-day SLA as inadequate for a KEV-listed actively-exploited CVE and names the CISA due date as the operationally-meaningful clock; the ISO-27001-2022-A.8.8 gap records that the standard does not differentiate routinely-disclosed CVEs from KEV-listed ones; the AU-Essential-8-Patch gap records that the patch cadence lags the long-public exploit for this Jenkins CLI deserialization bug.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2015-7755": {
     "name": "Juniper ScreenOS Improper Authentication Vulnerability",
@@ -24551,7 +24583,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "N-able N-Central is the MSP's management server, and the packet's own coverage text calls it an internet-facing management platform whose compromise is fleet-wide, so the clock on this command-injection flaw runs from the KEV listing of 2025-08-13 rather than from the next maintenance window that suits a platform every technician depends on. Bound to this product the control means: the N-Central server reaches the fixed build named in the vendor advisory — the packet gives affected versions only as 'per vendor advisory', so the target build must be taken from that advisory for the deployed release rather than assumed — and completion is measured on the version the running N-Central service reports after the restart, not on the update being downloaded or marked approved. The packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a server that has taken the update but has not restarted is still executing the vulnerable code and counts as exposed; on an RMM that restart is the step most likely to slip, because taking it interrupts every managed endpoint's check-in, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Limit of this control: it governs the operator's own N-Central server and says nothing about downstream client systems already reached through it while the flaw was live.",
+        "evidence": "Packet: CISA KEV-listed 2025-08-13, active_exploitation confirmed, CVSS 9.8, RWEP 77, poc_available true. Vector: command injection via improper sanitization of user input (CWE-94); attack_vector records unauthenticated remote command execution on the RMM server. patch_available true, live_patch_available false, patch_required_reboot true, live_patch_notes: no live-patch tool registered and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction. affected and affected_versions give the fixed level only as 'per vendor advisory'. AU-Essential-8-Patch gap records the 48h patch target trailing same-day exploitation of a KEV-listed RMM command injection; SI-2 and A.8.8 gaps record the 30-day/undefined-timescale readings as unsafe for an actively-exploited internet-facing management platform.",
+        "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": "The packet records that command injection on N-Central reaches every downstream client the MSP manages, well beyond the operator's own boundary, and turns one server into managed-fleet-wide code execution across every client estate. A compromised N-Central is therefore not a single-server incident, and the playbook has to treat every endpoint the platform administers as having been under attacker control for the exposure window: rotate every credential the platform can use or that technicians used through it to reach managed devices, invalidate technician sessions and API tokens, audit the scripts, scheduled jobs and automation policies pushed since the start of the window, and set quarantine criteria for downstream client devices that executed anything in that period. The audit half is where this differs from ordinary server IR — remote script execution is the product's normal function, so attacker actions appear in the managed agent's logs as legitimate platform use, and there is no anomalous binary or unsigned process to pivot from. Patch-only closure is the specific failure this control prevents: the packet's coverage text records that compressed-SLA controls do not require the web-shell-hunt, credential-rotation and downstream-review cleanup these RCEs need given their managed-estate reach, and the vendor update removes the injection path but nothing already installed through it. Precondition: this depends on the platform's job history and agent telemetry being retained off the N-Central server itself — an attacker holding command execution on that server can alter what its console reports, so a playbook keyed only on N-Central's own records has no independent account of the window to reconstruct.",
+        "evidence": "Packet: NIS2-Art21-patch-management gap records that patch-management obligations do not capture the supply-chain blast of an RMM platform, and that command injection on N-Central reaches every downstream client the MSP manages, well beyond the operator's own boundary. UK-CAF-B4 gap records that CAF scoping treats N-Central as an internal admin tool while command injection on an RMM turns one server into managed-fleet-wide code execution across every client estate. AU-Essential-8-Patch gap names the multi-tenant blast radius from an owned N-Central server. framework_coverage records that the framework does not require the web-shell-hunt / credential-rotation / downstream-review cleanup these RCEs need given their managed-estate reach. active_exploitation confirmed with poc_available true.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "N-Central is the device-management gateway this control governs and the packet places the defect on its request-handling surface: improper sanitization of user input reaching a command-execution path, exploitable without authentication. Bound to this product the requirement is that every N-Central endpoint carrying operator- or agent-supplied values into a command path authorizes its caller before the value is processed at all, and passes that value as an argument to the invoked program rather than composing it into a shell string, so a caller-supplied metacharacter cannot select what runs. Precondition, and it is the half that gets over-claimed: the vendor update is what establishes that property — this control states what to verify, not how to implement it — and until it lands the only operator-side lever is restricting which networks can reach the N-Central administration surface. On an RMM that lever is weak by construction, because agents at every client site check in to this server and technicians reach it remotely; the packet's own coverage text describes it as internet-facing, so for a deployment that must answer from the internet the restriction bounds nothing meaningful, and for one reachable only over a VPN it bounds the population to VPN-authenticated hosts and no further. It never closes the path. Note also why the least-privilege control cited as insufficient on this entry cannot substitute: the attack_vector places execution before authentication, so the attacker never holds an N-Central operator account, per-account privilege scoping is never consulted, and an AC-6 attestation passes cleanly while the injection path stays open.",
+        "evidence": "Packet vector: 'N-able N-Central contains a command injection vulnerability via improper sanitization of user input.' attack_vector: a command-injection flaw (CWE-94) enabling unauthenticated remote command execution on the RMM server. framework_coverage describes an actively-exploited, internet-facing management platform whose compromise is fleet-wide. NIST-800-53-AC-6 gap records that least privilege presumes a working authentication/authorization boundary and that the KEV-listed exploit demonstrates the boundary is breakable. UK-CAF-B4 gap records CAF system-security scoping treating N-Central as an internal admin tool. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-8875": {
     "name": "N-able N-Central Insecure Deserialization Vulnerability",
@@ -24611,7 +24675,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "N-Central is the console a managed-service provider runs its customers' estates from, so this is not an application-patching item on the server's normal cycle. The packet records the defect as insecure deserialization (CWE-94) reaching command execution, with the entry's attack vector describing it as unauthenticated remote code execution on the RMM server, a public proof of concept available, CVSS 9.8, and confirmed exploitation with a KEV listing on 2025-08-13 — and the entry's own note that the KEV dateAdded is the formal listing date while in-wild observation may predate it by weeks, so the exposure window opened before the clock did. The requirement here is that the N-Central server is remediated against that listing rather than folded into the next maintenance window, and that completion is measured on the version the running N-Central service is executing rather than on 'update downloaded' or 'change approved' in the change record. The packet gives no live-patch path and states the vendor patch typically requires a service restart or system reboot, so an instance that has staged the update but not restarted is still serving the vulnerable deserialization path and must be counted as exposed — on a console that is doing continuous work for customers, that restart is the step most likely to be deferred and is the specific way this remediation gets recorded as done while the server stays exploitable. Precondition on verification: this entry names no build. affected_versions reads only 'N-able N-Central — versions per vendor advisory', so the target version has to be taken from that advisory for the deployed release line; an operator working from this entry alone cannot demonstrate remediation. Note what buys no time: the least-privilege gap cited on this entry is not a mitigation for this path, because the attack vector places the attacker at the server without authenticating, so no operator account is presented and per-account privilege scoping is never consulted.",
+        "evidence": "Packet name: 'N-able N-Central Insecure Deserialization Vulnerability'; CWE-94; cisa_kev true, kev_date 2025-08-13, active_exploitation 'confirmed'; cvss 9.8; rwep_score 77; poc_available true. vector: 'N-able N-Central contains an insecure deserialization vulnerability that could lead to command execution.' attack_vector: 'an insecure-deserialization flaw (CWE-94) enabling unauthenticated remote code execution on the RMM server.' affected_versions: 'N-able N-Central — versions per vendor advisory'. patch_available true, patch_required_reboot 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.' active_exploitation_notes: 'The dateAdded is the formal KEV listing date; the actual in-wild observation may predate it by weeks.' The NIST-800-53-AC-6 gap records that least privilege 'presumes a working authentication / authorization boundary'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "What separates this from an ordinary server RCE is what the server does for a living. The packet's own gap analysis states that N-Central is MSP RMM tooling and that a deserialization RCE on the platform cascades to every managed downstream estate, projecting command execution into every client network it manages. Code execution on the N-Central server is therefore control of the channel that ships scripts, agent updates and remote-execution jobs to managed endpoints — the exposed asset is not the console's own data but everything the console distributes and runs on other networks. Applied to this product, the control means the N-Central installation and every directory from which it stages or serves content to agents are file-integrity-monitored, with alerts on writes that do not correspond to a sanctioned administrator action or a vendor update; the server is held to management-plane patch priority rather than to general server cadence; and the record of what the platform distributed and executed downstream — job, script and automation history — is retained off the N-Central server, so the question 'what did this console push during the exposure window' is answerable from something an attacker on that console could not edit. This is the control that retains value after the vendor update lands, which is why it sits alongside the remediation clock rather than being replaced by it: the fix closes the deserialization sink but removes nothing already written through it, and a script or agent payload staged before remediation survives the upgrade and keeps reaching managed endpoints down the platform's legitimate distribution path — where anti-malware on those endpoints sees a change delivered by their own management agent and the console's authentication log shows no anomalous login, because the attacker never needed one.",
+        "evidence": "Packet attack_vector: 'an insecure-deserialization flaw (CWE-94) enabling unauthenticated remote code execution on the RMM server.' The NIS2-Art21-vulnerability-management gap states: 'N-Central is MSP RMM tooling, so a deserialization RCE on the platform cascades to every managed downstream estate — a supply-chain blast radius NIS2 vulnerability-management treats as a single-entity flaw rather than a multi-customer incident.' The UK-CAF-B4 gap states: 'an RMM server compromise via insecure deserialization projects command execution into every client network it manages, well beyond the assessed system.' cisa_kev true, kev_date 2025-08-13, active_exploitation 'confirmed', poc_available true, cvss 9.8. patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The blast radius the packet describes for this CVE — every managed downstream estate, command execution projected into every client network the console manages — is a multi-customer incident, and almost all of the response consists of actions taken on networks the entity running the N-Central server does not own. That has to be rehearsed before it is needed, because it cannot be negotiated during the incident. For this platform the playbook is: revoke and reissue the agent-to-server trust material so managed endpoints stop honouring the compromised console, invalidate and rotate every credential the console holds for managed environments (domain and local administrator accounts, remote-access credentials, integration API keys, and credentials for the backup and monitoring tooling N-Central drives), audit every automation policy, scheduled task and script run through the console back to the start of the exposure window, define the criteria under which a managed endpoint that executed console-delivered content in that window is quarantined, and pre-agree the customer notification path since the parties who need to act are not the ones holding the server. Precondition on scoping, and it is the reason this cannot be improvised: the start of the exposure window is not derivable from this entry — the packet states the KEV dateAdded of 2025-08-13 is the formal listing date and the actual in-wild observation may predate it by weeks — so the downstream review has to run to a conservatively earlier boundary rather than to the listing date, and a playbook written during the incident will default to the listing date because it is the only number to hand. This control governs the response. It neither prevents the deserialization RCE nor substitutes for taking the vendor update and its restart.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-08-13, active_exploitation 'confirmed'; active_exploitation_notes: 'KEV listing is CISA's confirmed-exploitation attestation. The dateAdded is the formal KEV listing date; the actual in-wild observation may predate it by weeks.' attack_vector: unauthenticated remote code execution on the RMM server via an insecure-deserialization flaw (CWE-94). The NIS2-Art21-vulnerability-management gap records the cascade to 'every managed downstream estate' as 'a multi-customer incident'; the UK-CAF-B4 gap records that CAF system-security scoping 'stops at the entity boundary'; the AU-Essential-8-Patch gap records that the maturity model 'has no concept of the downstream managed fleet a single RMM RCE simultaneously exposes'. The NIST-800-53-SI-2 framework_coverage gap notes that 'RMM/ITSM/endpoint-management compromise reaches the entire managed estate'.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-8088": {
     "name": "RARLAB WinRAR Path Traversal Vulnerability (variant: CVE-2025-8088)",
@@ -24747,7 +24844,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation here requires a user to open the attacker's spreadsheet: the packet's vector has the specially crafted Excel file delivered as an email attachment or hosted on a malicious website, with code execution following when it is opened. On any Microsoft Office install that has not reached the fixed build, the delivery path is therefore the enforceable control. Require the untrusted-origin marking (Mark-of-the-Web) on every Office file arriving by mail, web download, or untrusted file share, and require marked documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink. That render is also the only least-privilege boundary available on this path: the least-privilege gap cited on this entry concerns account scoping, but the code here executes as whichever user opened the attachment, so privilege containment has to happen at the render rather than in the account model, and an account-privilege attestation passes cleanly while the parser runs with the target's full rights. Provenance must survive the container the attachment arrives in — a file extracted from a ZIP, mounted from an ISO or VHD, or renamed must inherit the marking rather than lose it — and 'Enable Editing' on externally sourced spreadsheets must be blocked by policy rather than left to the person the mail was aimed at. Distinguishing test: mail a marked spreadsheet nested inside an archive to a managed workstation, extract it, and confirm the extracted file still opens in Protected View; an Office-hardening attestation covering macro and add-in settings reads clean while a provenance-stripped spreadsheet reaches the vulnerable parser. Precondition: this constrains the render, it does not remove the sink. A user permitted to click through to editing, or a file that arrives by a path which never applies the marking — removable media, a share configured as a trusted location — is back on the full parsing path, so this is the control for the window before the fixed build and its restart land, not a substitute for them.",
+        "evidence": "Packet fields for CVE-2007-0671 (Microsoft Office Excel Remote Code Execution Vulnerability): cwe_refs CWE-94; cisa_kev true, kev_date 2025-08-12, active_exploitation confirmed; rwep_score 77, cvss 9.8; poc_available true. The vector states the vulnerability can be exploited when a specially crafted Excel file is opened, that the malicious file could be delivered as an email attachment or hosted on a malicious website, and that opening it allows an attacker to execute remote code on the affected system. Cited gaps: AU-Essential-8-App-Hardening ('Essential Eight Office hardening that blocks untrusted content is the control that neutralizes this email-delivered malicious-Excel RCE, and it is not guaranteed enabled'), UK-CAF-B4 ('System-security hardening should block file-borne execution, yet a crafted Excel document delivered by email or web link still reaches code execution on under-hardened clients'), NIST-800-53-AC-6 ('Least-privilege presumes a working authentication / authorization boundary').",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock this control anchors is unusual on this entry, and that is the point: the packet records a 2025-08-12 KEV listing on a 2007 CVE with confirmed in-the-wild exploitation, and states that the legacy re-listing exists because long-tail unpatched estates remain exposed. So the population is not the hosts a recent patch cycle touched — it is the Microsoft Office installs a routine cycle never reaches: unmanaged and per-user copies outside managed software distribution, machines rebuilt from old images or restored from backup, long-offline and air-gapped workstations, and the estates the packet's own gaps describe as still running vulnerable builds. Enumerate those against the vendor advisory the packet defers to, since affected_versions gives the range only as 'per vendor advisory' and the fixed build has to come from that advisory per install rather than from an assumed version. Completion is measured on the build the running Office process is executing, not on an 'approved' or 'downloaded' status in the management console: the packet records a vendor patch requiring a reboot with no live-patch path, so a workstation where the update installed while the restart is still pending — and an Excel process that stayed open across the update — is still running the pre-fix parser and is not remediated. Priority follows the packet rather than the age of the CVE: a public PoC, confirmed exploitation and a current KEV listing make this an active item on the KEV clock, and treating a 2007 identifier as historical is precisely the triage error that produced the long-tail estate the re-listing documents.",
+        "evidence": "Packet fields for CVE-2007-0671: patch_available true; patch_required_reboot 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.'; affected 'Microsoft Office — see vendor advisory linked in verification_sources for affected version ranges'; affected_versions 'Microsoft Office — versions per vendor advisory'; cisa_kev true with kev_date 2025-08-12; active_exploitation confirmed; poc_available true; rwep_score 77. attack_vector states the CISA KEV listing is 2025-08-12 with confirmed in-the-wild exploitation and that 'the legacy re-listing exists because long-tail unpatched estates remain exposed'. Cited gaps: NIST-800-53-SI-2 (30-day flaw-remediation SLA inadequate for a KEV-listed actively-exploited client RCE; 'legacy KEV re-listings document organizations still running unpatched builds') and ISO-27001-2022-A.8.8 (''Appropriate timescales' is undefined ... the legacy KEV re-listing exists because organizations still run vulnerable Office/IE/Windows builds').",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This applies to one slice of the exposed population and has to be scoped to it. The packet's patch-management gap records that this Excel RCE persists wherever unpatched or end-of-life Office builds still open attachments, and patch_available true means a fix exists for this CVE — not that every install carrying the flaw can still receive one. The determination is therefore per install rather than per product: for each Microsoft Office install the packet's affected field names, establish from the vendor advisory whether that version can still be driven to the build carrying this fix. Installs that can are remediation items on the KEV clock that opened 2025-08-12, and because the packet records a reboot requirement with no live-patch path, they are not complete until that restart is taken. Installs on an Office version past end-of-support cannot reach a fixed build at all; for those the terminal state is removal or replacement on a dated schedule, because such a copy is exposed not only to this parser flaw but to everything found in Office since its last servicing, and it will keep opening mailed spreadsheets in the meantime. The failure this prevents is a compliance record that reads clean while the exposure stands: an estate whose supported installs all report the fixed build closes the flaw-remediation ticket, while the out-of-support copies — precisely where the packet says this legacy CVE lives — are carried as an accepted risk with no removal date. Scope this to the Microsoft Office installs the packet names; a crafted spreadsheet opened in some other vendor's application is not this CVE, and treating every out-of-support office suite in the estate as an instance of it manufactures replacement work no evidence in this packet supports. Precondition: this reaches only the installs an inventory can see, and an unmanaged per-user copy is remediated by removing it, not by recording it as accepted.",
+        "evidence": "Packet fields for CVE-2007-0671: patch_available true; patch_required_reboot 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; affected 'Microsoft Office — see vendor advisory linked in verification_sources for affected version ranges'; affected_versions 'Microsoft Office — versions per vendor advisory'; kev_date 2025-08-12; active_exploitation confirmed; poc_available true. The NIS2-Art21-patch-management gap states: 'Patch-management duties assume the Office fleet is current, but this legacy Excel RCE persists wherever unpatched or end-of-life Office builds still open attachments.' The vector records delivery as an email attachment or a malicious website, with code execution when the crafted Excel file is opened.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2013-3893": {
     "name": "Microsoft Internet Explorer Resource Management Errors Vulnerability",
@@ -24831,7 +24960,7 @@
     "name": "D-Link DCS-2530L and DCS-2670L Devices Unspecified Vulnerability",
     "lesson_date": "2026-05-29",
     "attack_vector": {
-      "description": "an unauthenticated code-execution flaw (CWE-94) on the D-Link DCS-2530L/2670L network cameras. CISA KEV-listed 2025-08-05 with confirmed in-the-wild exploitation.",
+      "description": "an unauthenticated information-disclosure flaw on the D-Link DCS-2530L/2670L network cameras: the /config/getuser endpoint answers without authentication and returns the administrator password. CISA KEV-listed 2025-08-05 with confirmed in-the-wild exploitation.",
       "privileges_required": "none (unauthenticated network reach to the device/service)",
       "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
       "ai_factor": "No AI involvement documented in discovery or weaponization."
@@ -24844,7 +24973,7 @@
         "adequacy": "Patch/replace is definitive; the gap is that the affected class is internet-exposed by function and (for consumer/EoL devices) often unpatchable, so network isolation is the load-bearing control."
       },
       "detection": {
-        "what_would_have_worked": "Monitoring for the IP camera web interface: exploit-shaped requests, device crashes/reboots, malicious firmware, and outbound botnet/C2 traffic from the device.",
+        "what_would_have_worked": "Monitoring the IP camera web interface for unauthenticated requests to /config/getuser from anything other than a known administration host, and for use of the camera administrator password on other systems — the flaw returns that credential without authentication, so its reuse elsewhere is the observable consequence.",
         "was_this_required": false,
         "framework_requiring_it": null,
         "adequacy": "Necessary to catch exploitation of devices not yet patched/replaced; edge devices are frequently recruited into botnets."
@@ -24885,7 +25014,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Both framework gaps recorded against this D-Link camera entry are timing gaps — a 30-day flaw-remediation SLA, and an \"appropriate timescales\" phrase the packet calls undefined — applied to an internet-facing device whose flaw discloses the remote administrator password and which CISA KEV-listed on 2025-08-05 with confirmed exploitation and a public proof of concept. This control binds the response to the KEV clock instead of the patch cycle: from the listing date, every DCS-2530L and DCS-2670L must carry a verified mitigation, meaning the vendor firmware for that model and hardware revision where one exists, or documented isolation of the camera from untrusted networks where it does not. The packet gives affected_versions only as \"versions per vendor advisory\", so the fixed level has to be read from the vendor advisory this entry references for that exact model rather than inferred from a version comparison — there is no version string in the packet to compare against. Completion is measured on the running unit, not on the management console: live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a camera that has received firmware but has not restarted onto it is still executing the vulnerable code and counts as exposed. Distinguishing test: for each camera produce the firmware version the unit itself reports after its restart, alongside the fixed level named in the vendor advisory — a fleet report showing the update as pushed or scheduled satisfies a 30-day SLA attestation while cameras that never restarted keep the administrator-password disclosure path open.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2025-08-05, active_exploitation confirmed, poc_available true, cvss 7.5, rwep_score 67, CWE-200; patch_available true, patch_required_reboot 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.\" affected/affected_versions: \"D-Link DCS-2530L and DCS-2670L Devices — versions per vendor advisory\". vector: the devices contain a vulnerability that could allow for remote administrator password disclosure. framework_control_gaps: NIST-800-53-SI-2 — \"30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE. CISA due date is the operationally-meaningful clock — typically 14-21 days for new KEV listings\"; ISO-27001-2022-A.8.8 — the standard \"does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs\", and framework_coverage records \"'Appropriate timescales' is undefined; the standard 30-day reading is unsafe for an unauthenticated, actively-exploited flaw on an internet-facing device\".",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet states both halves this control turns on. patch_available is true, so a fixed firmware exists for this flaw; and the entry's own vector states the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization, with the Essential Eight, UK CAF and NIS2 gaps all recording these D-Link cameras as end-of-life hardware for which retirement or isolation, not patching, is the complete action. Together those define the requirement: on a DCS-2530L or DCS-2670L whose hardware revision still has firmware carrying this fix, reaching that build is an interim state; on a unit with no fixed firmware, and on every unit once the model leaves vendor service, the terminal state is removal or replacement, because the camera then stands exposed not only to this administrator-password disclosure but to everything found in that firmware since its last build. Scope to what the packet names — DCS-2530L and DCS-2670L — and inventory those two models; the packet ties this credential-disclosure flaw to them and gives no mapping into other D-Link camera lines or other vendors' cameras, so treating every IP camera in the estate as an instance of this CVE manufactures replacement work against hardware no evidence implicates. Operationally: enumerate both models, record per unit whether the vendor advisory lists a fixed firmware for that hardware revision, put those units on the interim clock that opened with the 2025-08-05 KEV listing, and put the rest on a dated replacement schedule — a risk acceptance with no removal date leaves a device with a public proof of concept and confirmed exploitation in service indefinitely. Precondition on the interim half: no live-patch path is registered and the vendor fix typically requires a service restart or system reboot, so a unit updated but not restarted is not remediated. Precondition on the isolation half, which is the compensating measure the network-security gap describes: reachability has to be verified from an untrusted network and from outside, because a consumer camera commonly acquires its exposure through a port forward or UPnP mapping the topology diagram does not show, and \"the cameras are on the internal network\" is an assertion rather than a demonstration.",
+        "evidence": "Packet fields: vector — \"D-Link DCS-2530L and DCS-2670L devices contains an unspecified vulnerability that could allow for remote administrator password disclosure. The impacted products could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.\" patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes records the vendor patch typically requires service restart or system reboot per the KEV requiredAction; affected_versions only \"versions per vendor advisory\"; CWE-200; poc_available true; cisa_kev true with kev_date 2025-08-05 and active_exploitation confirmed. framework_control_gaps: AU-Essential-8-Patch — \"The patch pillar is moot for EoL/EoS D-Link cameras with no available firmware; only device replacement remediates, which Essential-Eight patching does not mandate\"; UK-CAF-B4 — \"Hardening cannot patch an end-of-life camera; the only compliant action is retirement\"; NIS2-Art21-network-security — \"Network-security measures must compensate for an end-of-life IP camera with no vendor fix, yet Article 21 doesn't compel decommissioning or isolating the internet-exposed DCS-2530L/2670L whose admin password is remotely disclosable.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Scope what this control is for on this entry, because the primitive bounds it: the verified flaw is administrator-password disclosure from an unauthenticated endpoint on the DCS-2530L/2670L cameras, not code execution on them, so reachability during the exposure window is evidence that the credential could have been taken — not evidence that anything ran on the device. The framework gaps record the devices as internet-facing and internet-exposed, exploitation is confirmed and a proof of concept is public. What makes the control load-bearing rather than redundant here is the outcome the vector names — remote administrator password disclosure. Firmware that closes the disclosure path does not invalidate a credential already taken, so patch-in-place is the wrong default for any camera that was reachable from an untrusted network during the exposure window that opened before the 2025-08-05 KEV listing. Such a unit is handled as compromised rather than updated: reset it to a factory state and rebuild the configuration from a known-good record instead of carrying the existing configuration across the update, set a new administrative credential rather than restoring the previous one, and where the same administrative password was configured on other units, treat the disclosure from one as a credential for the rest and rotate accordingly. This is also why the least-privilege control cited against this entry passes its attestation while the exposure stands: the attacker never authenticates as any camera operator, so per-account privilege scoping is never consulted and the account model an access-control attestation examines is bypassed rather than abused; what failed is the authentication boundary itself, and the operator-side repair for that is credential replacement, not privilege reduction. Preconditions: rebuild presupposes a fixed firmware for that hardware revision to rebuild onto — where the packet's end-of-life statement means none exists for the model, the unit is a removal item and the credential rotation still has to happen; and a factory reset removes the device's own state, not an attacker's continued access to whatever the disclosed credential opens elsewhere, which has to be scoped and revoked separately. What follows from the disclosed credential rather than from execution: rotate the administrator password on every reachable unit and everywhere that password was reused, and treat the camera as replaceable rather than recoverable where its firmware cannot be brought to a build carrying the fix. A full rebuild is warranted where separately verified indicators of compromise exist on the unit — this CVE alone does not supply them, and recording it as though it did would spend replacement budget on evidence the entry does not carry.",
+        "evidence": "Packet fields: attack_vector — \"an unauthenticated information-disclosure flaw on the D-Link DCS-2530L/2670L network cameras: the /config/getuser endpoint answers without authentication and returns the administrator password. CISA KEV-listed 2025-08-05 with confirmed in-the-wild exploitation.\" vector — the devices contain a vulnerability that could allow for remote administrator password disclosure, and the impacted products could be end-of-life and/or end-of-service with users advised to discontinue product utilization. poc_available true; active_exploitation confirmed; patch_available true with patch_required_reboot true and live_patch_available false. framework_control_gaps: NIST-800-53-AC-6 — \"Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context\"; NIS2-Art21-network-security and ISO-27001-2022-A.8.8 both describe the affected units as internet-exposed / internet-facing devices.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2020-25079": {
     "name": "D-Link DCS-2530L and DCS-2670L Command Injection Vulnerability",
@@ -25694,7 +25855,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 states the sequence outright: CVE-2025-53770 is a patch bypass for this CVE, and the updates for CVE-2025-53770 include more robust protection than the ones shipped for CVE-2025-49704. That makes this the first fix in an incomplete-patch sequence on the same SharePoint code-injection sink, and it explains the outcome the packet's Essential Eight gap records — an estate that met its patch cadence was still exposed, because the cadence was measured against a fix that had been defeated. Bound to this product, the requirement is that the vulnerability-management record for a SharePoint farm is not closed on the 49704 update: the target state is the build carrying the hardened 53770 protection, the risk score carried against the farm reflects that a bypass of the first fix already exists rather than the discrete rating of one entry, and any further defect announced against the same injection sink is triaged on the assumption that the sink rather than the individual entry point is the defect. The chain feeds the same judgement — the packet records this CVE as chainable with CVE-2025-49706, and its own attack-vector summary describes the chained result as unauthenticated remote code execution, so the 'authorized attacker' framing in the vendor text understates what the farm is actually exposed to and should not be used to down-rank it. Precondition: this control governs how the flaw is scored and tracked and deploys nothing. It reduces no exposure on a farm that has taken neither update, and it says nothing about what happened during the window — a farm that was reachable while exploitation was confirmed belongs on the incident path regardless of which update it now holds.",
+        "evidence": "Packet vector: 'Microsoft SharePoint contains a code injection vulnerability that could allow an authorized attacker to execute code over a network. This vulnerability could be chained with CVE-2025-49706. 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.' attack_vector: code injection (CWE-94) on SharePoint Server as part of the ToolShell chain, yielding unauthenticated remote code execution, KEV-listed 2025-07-22 with confirmed in-the-wild exploitation. CVSS 9.8, RWEP 83, poc_available true. The AU-Essential-8-Patch gap states patch cadence was actively defeated here because the initial fix was bypassed by CVE-2025-53770, so meeting the SLA still left KEV-listed, ransomware-linked exploitation live until the hardened update landed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry opened with the KEV listing on 2025-07-22 against confirmed in-the-wild exploitation, and the packet's own coverage records the standard 30-day reading of 'appropriate timescales' as exploitation acceptance for an actively-exploited flaw on an internet-facing enterprise server. Applied to SharePoint, the first operational consequence is a sourcing rule: the fixed build for each on-premises farm server must be taken from the vendor advisory this entry links, because the packet gives affected versions only as 'per vendor advisory' — the version range is not something to infer, and not something to carry over from another SharePoint entry. The second is where completion is measured. live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV required action, so a farm server that has installed the update but has not been restarted is still serving requests from pre-fix code; on a farm that restart is also the step most likely to be deferred into a maintenance window, and a deferral recorded as patched is the specific way this remediation goes wrong. Precondition, and it is what makes this control insufficient on its own here: satisfying the clock with the 49704 update alone does not end exposure, because the packet records CVE-2025-53770 as a bypass of exactly that fix with more robust protection in its updates — so the state this control drives toward is the hardened update, and the interim hardening the packet names for on-premises SharePoint (AMSI enforcement) bounds exploitation rather than removing the injection path.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-07-22, active_exploitation confirmed ('KEV listing is CISA's confirmed-exploitation attestation'), CVSS 9.8, RWEP 83, poc_available true. patch_available true, patch_required_reboot 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.' affected and affected_versions: 'Microsoft SharePoint — see vendor advisory linked in verification_sources for affected version ranges' / 'versions per vendor advisory'. The NIST-800-53-SI-2 gap states the 30-day flaw-remediation SLA is far longer than the observed exploitation window and that the ToolShell SharePoint chain was mass-exploited within days of disclosure; the ISO-27001-2022-A.8.8 gap states 'appropriate timescales' is undefined and the standard 30-day reading is unsafe for an actively-exploited flaw on an internet-facing enterprise server; the UK-CAF-B4 gap names AMSI enforcement as compensating hardening the baseline does not mandate.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This control was written for perimeter appliances, and an on-premises SharePoint farm is not one — but the packet places this flaw on an internet-facing enterprise server under confirmed exploitation with a public PoC, which puts the farm in the same position the control exists to address: the update closes the code-injection sink and removes nothing an attacker installed through it. The packet's gaps name the residue directly — machine-key rotation and a web-shell hunt are recorded as the cleanup this class needs and as hardening the CAF baseline does not mandate — and the machine keys are why patch-in-place specifically fails here: an attacker who took them during the exposure window can keep presenting forged authenticated payloads to a fully patched farm, so reaching the fixed build closes the entry point while leaving the access intact. For this product the requirement is therefore that a farm reachable while exploitation was live is triaged as a compromise — forensic capture, web-shell hunt across the front ends, machine-key rotation, rebuild of anything that cannot be cleared, and rotation of credentials the farm held or that authenticated through it — rather than being closed on the patch record. It also settles which process owns the finding: the packet records ransomware-linked exploitation of this chain, so an exposed farm is an incident to classify and report on the jurisdictional clocks, not a patch ticket. Preconditions: this is the response half and prevents nothing — it depends on the update to stop re-entry through the same sink, and it applies only to farms reachable during the window. Rotating machine keys does not evict an attacker who already holds a web shell or other persistence on the host, which is why the rebuild half is stated rather than rotation alone; and a farm whose request and process logs for the window were not retained cannot demonstrate it was untouched, so a clean hunt against absent telemetry is not evidence of absence.",
+        "evidence": "Packet: active_exploitation confirmed, kev_date 2025-07-22, poc_available true, CWE-94, RWEP 83. attack_vector places the flaw on SharePoint Server as part of the ToolShell chain yielding unauthenticated remote code execution. The UK-CAF-B4 gap states CAF system-security baselines don't mandate the compensating hardening (AMSI enforcement, machine-key rotation) on-prem SharePoint needed once this code-injection was chained and its first patch bypassed, and that patch-alone left the ToolShell path open. The entry's NIS2-Art21-network-security coverage states the framework 'does not require the key-rotation/web-shell-hunt cleanup' this class needs. The NIS2-Art21-vulnerability-handling gap states that known ransomware-campaign use elevates this from routine vulnerability handling to a Significant Incident class under NIS2 Art.23(4), engaging disclosure clocks. The entry's ISO-27001-2022-A.8.8 and PCI-DSS-4.0-6.3.3 coverage both describe the exposure as an internet-facing server.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2025-49706": {
     "name": "Microsoft SharePoint Improper Authentication Vulnerability",
@@ -27318,7 +27510,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet's vector puts this in Apple iOS, iPadOS, macOS, watchOS and visionOS processing a maliciously crafted photo or video shared via an iCloud Link, and its NIS2 gap records the flaw as zero-click, compromising the device with no victim action, used for Paragon mercenary spyware. There is therefore no user decision anywhere on the delivery path to train, warn or gate — which is precisely why the cited system-security configuration control is recorded as unable to block it. Applied to this entry, the control means the cohort plausibly inside a mercenary-spyware targeting set runs in a reduced-attack-surface mode in which shared media, link previews and attachments are not rendered automatically, so a crafted photo or video arriving over an iCloud share does not reach the media-processing path without an explicit user action. Scope it to the five Apple families the entry names and to the high-risk cohort rather than the whole estate, since the mode costs normal functionality. Preconditions, and they are what make this a holding measure rather than a fix: the mode only helps if it was already on when the share arrived, so it must be a standing posture assigned before the next disclosure — turning it on after the 2025-06-16 KEV listing does nothing for a device already implanted during the window; it narrows the delivery path and removes nothing from the underlying flaw, which closes only when a device is running the vendor's fixed build and has restarted onto it (patch_required_reboot is true and live_patch_available is false); and it does not evict an implant already resident, so a device suspected of exposure is an incident, not a configuration item.",
+        "evidence": "Packet vector: \"Apple iOS, iPadOS, macOS, watchOS, and visionOS, contain an unspecified vulnerability when processing a maliciously crafted photo or video shared via an iCloud Link.\" NIS2-Art21-incident-handling gap: \"this zero-click flaw delivered via a crafted photo or video in an iCloud Link — used for Paragon mercenary spyware — compromises the device with no victim action\". UK-CAF-B4 gap: \"System-security configuration of a managed Apple fleet cannot block a zero-click media-processing exploit arriving over an iCloud share; the exposure closes only when Apple's patch reaches every device.\" cisa_kev true, kev_date 2025-06-16, active_exploitation confirmed, poc_available true, patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this entry the control means the update carrying the fix is driven across every Apple device in the estate on the clock that opened with the 2025-06-16 KEV listing, with user deferral disallowed, rather than folded into a normal update ring — the packet's own flaw-remediation gap states the 30-day SLA is far longer than the observed exploitation window for a client flaw delivered by attacker-controlled content. Two details decide whether this actually lands. First, the population is the five Apple families the entry names — iOS, iPadOS, macOS, watchOS and visionOS — and the fixed build for each has to be read from the vendor advisory the packet points to, because the entry records affected versions only as \"Apple Multiple Products — versions per vendor advisory\"; an estate that enforces this on phones and laptops while the watch and headset families sit outside the managed-update path has not covered what the vector names. Second, completion is measured on the build each device is actually running, not on \"update pushed\" or \"downloaded\" in the management console: patch_required_reboot is true and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, with no live-patch path, so a device that took the update and has not restarted is still executing vulnerable code and must be counted as exposed. Precondition: this control reaches only devices the management channel enrolls and can update. A personally-owned or unenrolled device carrying organizational data has the same completion measure and no enforcement lever, and belongs on the access-condition or removal path instead of on this one.",
+        "evidence": "NIST-800-53-SI-2 framework_coverage gap: \"The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, actively-exploited client memory-corruption flaw delivered by attacker-controlled content.\" ISO-27001-2022-A.8.8 gap: \"'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited mobile/desktop OS flaw, often part of a targeted-spyware chain against high-risk users.\" AU-Essential-8-Patch gap: \"Essential-Eight patch targets exceed the exploitation window for a KEV-listed zero-click Apple flaw already weaponised for targeted spyware before public disclosure.\" patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: \"Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" affected_versions: \"Apple Multiple Products — versions per vendor advisory\". Vector names iOS, iPadOS, macOS, watchOS and visionOS.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet records this flaw as used for Paragon mercenary spyware and delivered zero-click through a crafted photo or video in an iCloud Link, so the intrusion it produces is a targeted implant, not a commodity malware infection — which is the distinction this control exists to force, and the reason the entry's incident-handling gap says response begins only after covert implantation. The hard part for this CVE is the trigger: the packet states there is no victim action, so there is no user report, no click to reconstruct and no user-visible artifact to escalate on. The runbook must therefore key on the exposure fact the packet does supply rather than on a detection signal it does not: any device in the targeted cohort that was running a build below the vendor fix at any point after the 2025-06-16 KEV listing is handled as a suspected targeted-implant case — forensic acquisition and evidence preservation, review of what the device's credentials and sessions could reach, and rotation of those credentials — instead of being closed the moment the update installs. Preconditions. Escalation prevents nothing; it bounds dwell time and scope after the fact. It pulls directly against the update clock, because the packet records that remediation requires a restart, and restarting or wiping a suspected device destroys volatile state — so the runbook has to decide acquisition-before-update per device, which is a decision that has to exist in writing before a disclosure, not be composed while the fleet is mid-update. And where the organization has no defensible list of who is inside the targeting set, this control has no population to run against and the cohort definition is the prerequisite work.",
+        "evidence": "NIS2-Art21-incident-handling gap: \"Incident-handling obligations assume a detectable trigger, but this zero-click flaw delivered via a crafted photo or video in an iCloud Link — used for Paragon mercenary spyware — compromises the device with no victim action, so response begins only after covert implantation.\" active_exploitation_notes records CISA KEV listing as the confirmed-exploitation attestation with in-wild observation possibly predating the 2025-06-16 dateAdded. attack_vector: \"a code-execution flaw (CWE-94, variant) reachable via attacker-controlled content (a zero-click delivery path in the documented in-the-wild use)\". patch_required_reboot true; live_patch_available false; active_exploitation confirmed.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2025-33053": {
     "name": " Microsoft Windows External Control of File Name or Path Vulnerability",
@@ -28302,7 +28525,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "Craft CMS is the product, and this entry is unusual in that the packet names the configuration setting exploitation depends on: an install is vulnerable to remote code execution when the php.ini configuration serving it has register_argc_argv enabled. That makes a configuration-side mitigation path available which is independent of the Craft upgrade — and the upgrade is the slow path here, since the packet records patch_required_reboot true with the vendor fix typically requiring a service restart or system reboot per the KEV requiredAction. The control's requirement for this deployment: inventory every Craft CMS install with the effective register_argc_argv value of the PHP runtime that serves it, disable it on the web-serving runtime, and treat that as a deployable, tested mitigation held ready rather than something discovered during an incident. Distinguishing test: read the effective value back from the PHP process actually serving Craft on every host in the pool — not from a php.ini file on disk, and not from a configuration-management template — and confirm it is off; a secure-configuration attestation covering the operating system and web-server baseline passes cleanly while this flag stays on, which is precisely what the UK-CAF and Essential-Eight hardening gaps record. Preconditions, both load-bearing. The mitigation holds only where nothing in the deployment depends on the setting: command-line PHP tooling reads $argv, so the change must be scoped to the runtime handling web requests and verified there rather than cleared globally, or scheduled jobs break and the change gets reverted under pressure. And clearing the flag does not evict an attacker already resident — active exploitation is confirmed and the flaw is unauthenticated code execution on the web server, so an install that ran with the flag enabled while reachable needs a compromise assessment and rotation of the secrets that install holds, not a flag flip recorded as remediation. This is the holding measure for the window before the vendor release and its restart land; the least-privilege control cited on this entry gives nothing here, because the attacker never holds a Craft account and no privilege decision is ever consulted.",
+        "evidence": "Packet vector: 'Craft CMS contains a code injection vulnerability. Users with affected versions are vulnerable to remote code execution if their php.ini configuration has register_argc_argv enabled.' patch_required_reboot 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.' active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. Cited gaps: NIS2-Art21-vulnerability-management ('exploitability here hinges on the register_argc_argv PHP runtime setting — a config-hardening step the process doesn't enumerate, so a patched-elsewhere host stays an unauthenticated RCE target'), UK-CAF-B4 ('secure-configuration baselines for the PHP runtime rarely flag register_argc_argv'), AU-Essential-8-App-Hardening ('application-hardening doesn't reach web-runtime php.ini flags'). NIST-800-53-AC-6 gap records that the exploit demonstrates the boundary is breakable from a baseline context.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For Craft CMS the packet gives an unauthenticated code-execution flaw on an internet-facing web application with a public proof of concept, KEV-listed 2025-06-02 with confirmed in-the-wild exploitation — the profile the cited 30-day flaw-remediation reading is least safe for. The control means the Craft upgrade runs on the KEV clock rather than the site's normal release train, and it means one specific piece of care with the fixed level: the packet records affected versions only as 'per vendor advisory', so the target build has to be taken from the vendor advisory linked in this entry's verification sources rather than assumed from a version the operator has to hand. Completion is measured on what the running site is executing, not on what was deployed. patch_required_reboot is true and the packet records the vendor fix as typically requiring a service restart or system reboot, so a host whose Craft files were updated while the PHP and web service kept running is still executing pre-fix code and must be counted as exposed — on a busy site that restart is the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Distinguishing test: enumerate every Craft CMS install the organisation runs — production, staging and the marketing or campaign sites that tend to sit outside the main asset register — and produce the version each is serving; an attestation covering the primary site passes cleanly while a forgotten install keeps an unauthenticated RCE reachable from the internet. Precondition: this control governs the speed and completeness of reaching the fixed release. It does nothing for an install already exploited, and it does not reach the runtime setting the same exploit depends on, which is a separate control on this entry.",
+        "evidence": "Packet: CISA KEV 2025-06-02, active_exploitation confirmed, CVSS 9.8, RWEP 77, poc_available true. attack_vector: 'a code-injection flaw (CWE-94, the related earlier variant) enabling unauthenticated remote code execution on the web server.' patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes records the vendor patch typically requiring service restart or system reboot per the KEV requiredAction. affected / affected_versions given only as 'Craft CMS — see vendor advisory linked in verification_sources for affected version ranges'. Cited gaps: NIST-800-53-SI-2 ('30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE'), ISO-27001-2022-A.8.8 (standard does not differentiate routinely-disclosed CVEs from actively-exploited KEV-listed ones).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-39780": {
     "name": "ASUS RT-AX55 Routers OS Command Injection Vulnerability",
@@ -28877,7 +29123,39 @@
     },
     "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": "Ivanti Endpoint Manager Mobile is the trust boundary for the mobile fleet in the sense this tier exists for: the packet's own gaps record its API as internet-facing and the manager as controlling every enrolled device, and its attack_vector records the exploited form as unauthenticated remote code execution on the EPMM management surface once this code injection is chained with the authentication bypass. That makes EPMM not a system sitting behind a perimeter but the thing the fleet authenticates to, which is why the standard cadence fails: the packet's own gaps name a 30-day flaw-remediation SLA and a 48-hour internet-facing target, both longer than the interval in which a public proof of concept against a 9.8 pre-auth remote code execution gets used. The requirement for this CVE is that EPMM sits in its own SLA tier whose clock started with the 2025-05-19 KEV listing and is counted in hours. One scoping caution the packet forces: it carries the affected range only as 'versions per vendor advisory', so the fixed level must be read from that advisory for the EPMM release actually in service rather than assumed, and the sweep covers every EPMM instance the estate runs — widen beyond EPMM only where a verified source identifies another product carrying the same Hibernate Validator implementation. The packet records no live-patch path and states that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so an EPMM that has taken the update but has not restarted onto it is still executing the vulnerable code and is not remediated; completion is the version the running service reports. Precondition on the tier's isolation alternative, which is where this control is over-claimed on a device manager: isolating the vulnerable interface is only partly available here, because the packet's gap records the EPMM API as internet-facing and the device-facing paths that make it so are the ones the enrolled fleet depends on. Restricting the administrative surfaces and the source ranges permitted to reach the device API bounds who can attempt the chain; it does not remove the device-facing path, so it is a holding measure for the window before the update and its restart land, not a substitute for either.",
+        "evidence": "Packet: CWE-94; CVSS 9.8; RWEP 77; poc_available true; active_exploitation confirmed; cisa_kev true with kev_date 2025-05-19. attack_vector: 'code injection (CWE-94) yielding unauthenticated remote code execution on the EPMM management surface (chained with the authentication bypass). CISA KEV-listed 2025-05-19 with confirmed in-the-wild exploitation.' patch_available true; patch_required_reboot 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.' affected and affected_versions both give the product as 'Ivanti Endpoint Manager Mobile (EPMM)' with versions 'per vendor advisory'. NIST-800-53-SI-2 gap: '30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE.' AU-Essential-8-Patch gap: 'The 48h internet-facing patch target trails active chaining of this EPMM RCE, whose compromise pivots to every mobile device the manager controls.' ISO-27001-2022-A.8.8 gap: the standard 'does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs'. NIS2-Art21-network-security gap names the 'internet-facing EPMM API'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "EPMM is the device-management gateway this control governs, and the defect sits on its API interface: the packet places a code-injection sink in the API component reachable through crafted API requests, arising from an insecure implementation of the Hibernate Validator open-source library as represented by CVE-2025-35036 — a request-supplied value reaching an expression-evaluation path. Bound to this product the control asks for two properties on that API. Each endpoint decides its caller's authorization itself, before the request body is processed at all, rather than inheriting a verdict from a front-end filter — which is exactly the arrangement that collapses when this injection is chained with the authentication bypass and the request arrives with no valid session; and request-supplied values never reach an evaluation path as expression text, so a parameter cannot select what the server evaluates. It also means no EPMM instance is left with its administrative API paths reachable from segments that have no operational need to reach them. This is why the least-privilege gap cited on this entry does not close the path: the packet's vector describes an authenticated attacker, but the exploited form it records is unauthenticated once chained, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the endpoint stays reachable and evaluating. Distinguishing test on a staging EPMM: send each API endpoint an unauthenticated request whose parameter values carry expression syntax and confirm it is refused before the value is evaluated — not that EPMM administrators are correctly scoped, which this attacker never needed to be. Precondition: the endpoint-side authorization decision and the input handling are properties the vendor update establishes; this control states what to verify and does not implement it. Until that update and its restart land, restricting reachability bounds the population that can send the request while leaving the endpoint exploitable to anything within reach, and for the device-facing API that population includes any client that can present itself to it.",
+        "evidence": "Packet vector: 'Ivanti Endpoint Manager Mobile (EPMM) contains a code injection vulnerability in the API component that allows an authenticated attacker to remotely execute arbitrary code via crafted API requests. This vulnerability results from an insecure implementation of the Hibernate Validator open-source library, as represented by CVE-2025-35036.' attack_vector records the exploited form as unauthenticated remote code execution on the EPMM management surface when chained with the authentication bypass. NIST-800-53-AC-6 gap: 'Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.' NIS2-Art21-network-security gap: 'Network-security controls do not compel restricting the internet-facing EPMM API whose expression-language injection RCE, chained with an auth bypass, hands over the MDM controlling an entire mobile fleet.' patch_available true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet states the consequence plainly in its UK-CAF gap: a compromised EPMM becomes a fleet-wide command channel to every enrolled device. Code execution on the management surface means the attacker inherits the manager's own authority over that fleet — configuration profiles, certificates, application deployment and device-trust state — so the response has to be written for the enrolled devices and not only for the appliance. For this product the pre-rehearsed playbook is: revoke and reissue the certificates EPMM issued; invalidate device-trust state and re-enroll; diff every configuration profile and application-deployment policy against a known-good baseline across the window in which the instance was exposed, which opens no later than the 2025-05-19 KEV listing and earlier if the instance was reachable before it; set quarantine criteria for enrolled devices that took a profile or package during that window; and rotate credentials for every account that authenticated through EPMM. Applying the vendor update answers none of these questions. The fix removes the injection sink and leaves in place whatever was pushed to handsets through it, and a profile or certificate delivered by a compromised manager stays trusted by the fleet until it is explicitly revoked — which is the specific way this remediation is recorded as complete while the fleet is still carrying attacker-supplied configuration. Precondition: this is a response measure and not a preventive one, and it depends on the exposure window being establishable from records the compromised appliance itself may hold. Where EPMM's logging was local to the instance, the window cannot be bounded from the appliance alone and has to be reconstructed from an independent source, which is the argument for treating the enrolled fleet as in scope by default rather than scoping the response to the manager.",
+        "evidence": "Packet UK-CAF-B4 gap: 'Hardening the EPMM appliance does not remove an expression-language injection in its API, and the compromised MDM becomes a fleet-wide command channel to every enrolled device.' NIS2-Art21-network-security gap describes the chained RCE as handing over 'the MDM controlling an entire mobile fleet'; AU-Essential-8-Patch gap notes the compromise 'pivots to every mobile device the manager controls'. active_exploitation confirmed with poc_available true and cisa_kev true, kev_date 2025-05-19. patch_available true; live_patch_available false; live_patch_notes records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-4427": {
     "name": "Ivanti Endpoint Manager Mobile (EPMM) Authentication Bypass Vulnerability",
@@ -29123,7 +29401,39 @@
     },
     "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": "A DrayTek Vigor router is the trust boundary for the site it fronts, and this defect sits on that boundary device's own web management interface: the packet places the OS command injection in /cgi-bin/mainfunction.cgi/apmcfgupload and records unauthenticated remote command execution on the router itself. For this CVE the control means affected Vigor units run on a perimeter-tier clock that opened with the 2025-05-15 KEV listing rather than on the ordinary appliance patch window, and that the web management interface is taken off every untrusted-reachable path for the duration of that clock. Scope the sweep from the affected fields, not the vector's headline models: the vector names Vigor2960, Vigor300B and Vigor3900, but affected and affected_versions record the scope only as DrayTek Vigor Routers with versions per vendor advisory, so the model and firmware list must be read from that advisory — a sweep restricted to the three models the vector happens to name reports clean across an estate standardised on another Vigor model. Completion is measured on the firmware the unit is executing: the packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so a unit that has taken firmware but has not restarted onto it still runs the vulnerable code. Distinguishing test: from an external address and from a client segment with no administrative role, request the router's web management interface including the /cgi-bin/mainfunction.cgi path — anything that answers is within reach of the published exploit, and 'management is LAN-side only' is a statement of intent, not a demonstration. Precondition on the isolation half: blocking WAN-side administration removes the internet path, but a Vigor unit exists to serve the client network attached to it and every client on that network still reaches the management interface, so on a unit fronting a general user network isolation bounds the attacker population rather than closing the path, and it removes nothing from a unit that was already exploited.",
+        "evidence": "Packet fields: cwe_refs CWE-78; vector places the OS command injection in /cgi-bin/mainfunction.cgi/apmcfgupload of the web management interface on DrayTek Vigor2960, Vigor300B and Vigor3900; attack_vector records unauthenticated remote command execution on the router; cisa_kev true with kev_date 2025-05-15; active_exploitation confirmed; poc_available true; cvss 9.8, rwep_score 77; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction; affected and affected_versions give the scope only as 'DrayTek Vigor Routers — versions per vendor advisory'. The UK-CAF-B4 gap names removing the DrayTek web-management interface from WAN exposure as the single reliable compensating control; the NIST-800-53-SI-2 gap records the 30-day flaw-remediation SLA as far longer than the observed exploitation window for this KEV-listed unauthenticated flaw on an internet-facing network device.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The Essential-Eight gap on this entry states where this starts: SOHO-grade Vigor routers are seldom in the patch inventory at all, so the first requirement is an inventory naming every DrayTek Vigor unit in service with its model, hardware revision and running firmware version. The packet gives affected versions only as 'DrayTek Vigor Routers — versions per vendor advisory', so both the affected-model list and the fixed firmware level have to be read from that advisory per model rather than inferred from the three models the vector names, and each unit's end-of-support status must be obtained from the vendor rather than assumed in either direction — patch_available true says a fix exists for this CVE, not that every Vigor model in service can still receive one. Units whose model and revision have fixed firmware are remediation items on the clock that opened with the 2025-05-15 KEV listing; because the packet registers no live-patch path and a fix that typically requires a service restart or system reboot, a unit that has taken firmware but not restarted onto it still executes the vulnerable code and counts as exposed. Units whose model has no fixed firmware per the advisory cannot be patched at all and are replacement items needing a dated schedule — closing this entry at 'every unit reports the fixed build' leaves an unsupported Vigor with a public PoC and confirmed exploitation in service indefinitely, which is precisely what this entry's ISO A.8.8 coverage records when it notes that unmanaged and end-of-life devices fall outside most patch programs entirely and that such devices can only be replaced, not patched. Precondition: an inventory reaches only units the operator knows about, and home-office and small-branch Vigor units bought outside procurement are the population this class is mass-exploited through — they are remediated by being found and then updated or removed, not by being absent from the report.",
+        "evidence": "Packet fields: affected 'DrayTek Vigor Routers — see vendor advisory linked in verification_sources for affected version ranges' and affected_versions 'DrayTek Vigor Routers — versions per vendor advisory'; patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes recording a service restart or system reboot per the KEV requiredAction; cisa_kev true, kev_date 2025-05-15; active_exploitation confirmed; poc_available true. The AU-Essential-8-Patch gap states SOHO-grade Vigor routers are seldom in the patch inventory, leaving this KEV-listed edge-device RCE exposed on the internet. This entry's framework_coverage records for ISO-27001-2022-A.8.8 that unmanaged/EOL devices fall outside most patch programs entirely, for NIST-800-53-SI-2 that many such devices run end-of-life firmware with no available fix, and for NIS2 that end-of-life devices can only be replaced, not patched.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives confirmed active exploitation, a public PoC and unauthenticated command execution on the router, so for any Vigor unit whose web management interface was reachable from an untrusted network during the exposure window, firmware alone is not remediation: the update replaces the vulnerable code and removes nothing the attacker executed through it. Applied to this device the runbook means exporting the unit's configuration for off-box review, rebuilding it from a known-good baseline rather than carrying the running configuration across the update, and comparing that configuration for attacker-added administrative accounts, port forwards, remote-access and tunnel settings before the unit returns to service — then rotating the administrative credential and every credential the configuration held or that transited the router. This is the only part of the response that speaks to the least-privilege gap recorded on this entry: the attacker never authenticates as any Vigor operator, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the path stays open; what least privilege can still do is bound what the credentials recovered from a compromised router unlock elsewhere, which is a rotation-and-scoping exercise off the device. It is also the answer to the network-security gap on this entry, which records that the duties assume the router is the boundary rather than the target — this control treats it as the target. Precondition: the rebuild is only meaningful against a baseline held off the device, because a configuration exported from a unit that was already exploited carries whatever was added to it, and 'the configuration looks normal' is not a compromise assessment for a device that executed attacker-supplied commands.",
+        "evidence": "Packet fields: active_exploitation confirmed with active_exploitation_notes stating the KEV listing is CISA's confirmed-exploitation attestation and that in-wild observation may predate the dateAdded by weeks; poc_available true; attack_vector records unauthenticated remote command execution on the router via the CWE-78 flaw; patch_available true with patch_required_reboot true and live_patch_available false. The NIS2-Art21-network-security gap states that network-security duties assume the router is the boundary, not the target, and that a command injection on the internet-facing Vigor management CGI turns the perimeter device itself into the attacker's entry point. The NIST-800-53-AC-6 gap states that least privilege presumes a working authentication/authorization boundary and that the KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2025-32756": {
     "name": "Fortinet Multiple Products Stack-Based Buffer Overflow Vulnerability",
@@ -34380,7 +34690,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The SMA100 is an SSL-VPN remote-access appliance — the trust boundary itself — and this entry is the case where a CVSS-driven SLA sends it down the wrong lane: CVSS 7.2 sits below most frameworks' emergency band while the packet records RWEP 77, a public PoC, KEV listing on 2025-05-01 with a CISA due date of 2025-05-22, and SonicWall confirming in-the-wild exploitation around 2025-04-29. The tier requirement for this device: the firmware upgrade runs on the KEV clock rather than in the appliance-maintenance window, across every model the packet names — SMA 200, 210, 400, 410 and 500v running 10.2.1.9-57sv or earlier — to a minimum of 10.2.1.10-62sv and to SonicWall's recommended 10.2.1.14-75sv or later. Completion is measured on the firmware the running appliance reports: patch_required_reboot is true and live_patch_available is false, so a unit that has staged firmware but not rebooted onto it is still executing the vulnerable code and counts as exposed, and on a remote-access appliance that reboot is the step most likely to be deferred because taking it drops every connected user session — a deferral recorded as patched is the specific way this remediation goes wrong. Precondition on the alternative the tier permits: isolating the vulnerable interface. The packet states only that the SSL-VPN management interface is network-reachable, so where the deployment can restrict that interface to an operator network, doing so bounds who can submit the crafted request; where it cannot be separated from the internet-facing service the appliance exists to provide, that half of the tier is unavailable and the reboot onto fixed firmware is the only remediation. Neither form neutralizes the metacharacter handling.",
+        "evidence": "cvss 7.2 against rwep_score 77; cisa_kev true with kev_date 2025-05-01; the NIST-800-53-SI-2 gap records the CISA due date as 2025-05-22 and states the operationally-meaningful clock is days, not the standard patch cycle; active_exploitation confirmed, with active_exploitation_notes recording SonicWall publicly confirming active in-the-wild exploitation around 2025-04-29 and no vendor or CISA threat-actor attribution; poc_available true; affected_versions: 'SonicWall SMA 100 series (SMA 200, 210, 400, 410, 500v) running firmware 10.2.1.9-57sv and earlier — affected', 'Fixed in firmware 10.2.1.10-62sv (released 2023-12-04) and later', 'SonicWall recommends upgrading to 10.2.1.14-75sv or later'; patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes stating remediation is the vendor update plus the named compensating controls until it lands; the NIST-800-53-SC-7 gap states that when the boundary device itself carries the injection, boundary protection protects nothing in front of it; the AU-Essential-8-Patch gap states Essential Eight maturity is scored on cadence, not KEV-anchored emergency response.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "The packet is explicit that this flaw's stated precondition is administrative privilege, and equally explicit that in observed activity the precondition is not a barrier: attackers chain CVE-2024-38475, an Apache mod_rewrite path-mapping flaw in the same SMA100, to leak a logged-in administrator's session token, eliminating the need for valid credentials, and then use this CVE for command execution. Two requirements follow for this appliance. First, remediation is scoped to the chain rather than to this CVE alone: reaching 10.2.1.10-62sv establishes that the metacharacter-handling fix is present, but it is not by itself evidence that the path-mapping flaw supplying the session token is also fixed on that unit, so the firmware level chosen must be verified against the vendor advisory for CVE-2024-38475 as well, with the packet's recommended 10.2.1.14-75sv or later as the floor. Second, exposure during the window is bounded by enumerating which SMA100 units have their administrative surface reachable from untrusted networks and restricting it until the reboot onto fixed firmware completes. Precondition, and the reason this control is here rather than an identity control: because the observed path is session-token theft from a flaw on the same appliance, administrator credential strength, password rotation and MFA on the administrator account do not bound this — no authentication event occurs for them to gate, which is why an identity attestation on the appliance passes cleanly while the path stays open. Restricting administrative-surface reachability bounds the population that can submit the crafted request; it does not repair the neutralization, and any host inside the permitted segment still reaches the sink.",
+        "evidence": "vector and attack_vector: the SMA100 SSL-VPN management interface is network-reachable and an attacker holding administrative privilege submits a crafted request whose shell metacharacters are not neutralized (CWE-78), executing OS commands as the low-privileged 'nobody' user; both fields record that in observed in-the-wild activity the post-authentication precondition is met by chaining CVE-2024-38475 — an Apache mod_rewrite path-mapping flaw in the SMA100 — to leak a logged-in administrator's session token, 'eliminating the need for valid credentials'; active_exploitation_notes repeats the chain and notes watchTowr Labs' 'SonicBoom' is a researcher codename, not an adversary; affected_versions gives 10.2.1.10-62sv (released 2023-12-04) as fixed and 10.2.1.14-75sv or later as the vendor recommendation; the NIS2-Art21-network-security gap states perimeter and segmentation obligations assume the appliance is trustworthy and that a command injection in the network device itself defeats that assumption; patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at command execution: it records that the injected commands are used to stage tooling and obtain interactive remote shells on the appliance, after which further on-box privilege escalation can target root, with exploitation confirmed in the wild. Firmware upgrade plus reboot restores the code; it evicts nothing that was staged, and the appliance's configuration and local administrative accounts carry across the upgrade untouched. For any SMA 200, 210, 400, 410 or 500v that was reachable while running 10.2.1.9-57sv or earlier during the exposure window, the requirement is therefore to treat the unit as compromised rather than as behind: export the configuration for review instead of restoring it wholesale onto the new build, rebuild at the vendor-recommended firmware, invalidate administrator sessions and rotate administrator credentials, and rotate credentials for users who authenticated through the appliance during the window. This is the complement of a managed patch cycle, which is exactly what the packet's CAF B4 gap describes being recorded as compliance — a cycle whose closure condition is 'firmware current' marks an appliance clean on which an attacker held an interactive shell. Preconditions and limits: the rebuild decision depends on establishing per unit whether it was reachable and at which firmware during the window, and where that cannot be evidenced the unit is treated as exposed rather than clean; the rebuild removes appliance-resident persistence only, so anything reached from the appliance into the internal network during the shell access the packet describes is incident-response scope that rebuilding the appliance does not recover; and rebuilding a remote-access concentrator drops every user session it serves, so it needs a scheduled path rather than being assumed free.",
+        "evidence": "vector and attack_vector: 'The injected commands are then used to stage tooling and obtain interactive remote shells on the appliance, after which further on-box privilege escalation can target root'; command injection executes as the low-privileged 'nobody' user per the same fields; active_exploitation confirmed, cisa_kev true with kev_date 2025-05-01 and SonicWall confirming active in-the-wild exploitation around 2025-04-29 per active_exploitation_notes; poc_available true, rwep_score 77; affected_versions names SMA 200, 210, 400, 410 and 500v on 10.2.1.9-57sv and earlier as affected, with 10.2.1.14-75sv or later recommended; the UK-CAF-B4 gap states CAF B4 is recorded as met by 'patches applied in a managed cycle' and that the managed cycle itself is the gap; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-1976": {
     "name": "Broadcom Brocade Fabric OS Code Injection Vulnerability",
@@ -34884,7 +35226,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet's exploitation record is why this control leads on this entry rather than a patch-cadence one: UNC6148 chained stolen admin credentials and OTP seeds with this injection on SMA 100 appliances the packet describes as fully patched but end-of-life. Reaching the fixed build is therefore an interim state on this product, not the finish line — a unit that is current but out of support is exposed to everything found in SMA 100 firmware since its last build, and this entry shows that is not a hypothetical. The requirement is an inventory naming every SMA 100 in service by the models the packet names — 200, 210, 400, 410 and 500v — with its running firmware, resolving two things per unit. First, whether it is above the vulnerable ranges the packet records (9.0.0.10-28sv and earlier, 10.2.0.7-34sv and earlier, 10.2.1.0-17sv and earlier); anything at or below is a remediation item on the clock that opened with the 2025-04-16 KEV listing, against the 2025-05-07 CISA due date the entry's flaw-remediation and technical-vulnerability gaps both cite. Second, whether that unit still has a support path at all, obtained from the vendor for that exact model rather than assumed in either direction; units without one cannot be carried by any patch programme and are replacement items needing a dated schedule, because a risk acceptance with no removal date leaves a KEV-listed appliance with confirmed exploitation terminating the estate's remote access indefinitely. Scope the sweep to the SMA 100 series the packet names — the entry ties this CWE-78 sink to the SMA 100 web management interface and gives no mapping into other SonicWall remote-access lines, so folding them in manufactures replacement work against products no evidence here implicates. Precondition on the interim half: live_patch_available is false and the packet states remediation is the vendor update plus the named compensating controls until it lands, with a reboot required — so a unit that has taken firmware but has not restarted onto it is still executing the vulnerable code and counts as exposed, and completion must be measured on the build the appliance is running rather than on the firmware file having been uploaded.",
+        "evidence": "Packet name: 'SonicWall SMA100 Appliances OS Command Injection Vulnerability'; CWE-78; cisa_kev true with kev_date 2025-04-16 and active_exploitation 'confirmed'. active_exploitation_notes: UNC6148 'chains stolen admin credentials/OTP seeds with CVE-2021-20035 on fully-patched but end-of-life SMA 100 appliances to deploy the OVERSTEP persistent backdoor/user-mode rootkit (GTIG/Mandiant, July 2025)', an actor active since at least October 2024 with tradecraft overlapping historical Abyss-branded ransomware deployments. affected_versions: 'SMA 100 series (models 200, 210, 400, 410, 500v): 9.0.0.10-28sv and earlier', '10.2.0.7-34sv and earlier', '10.2.1.0-17sv and earlier'. The NIST-800-53-SI-2 and ISO-27001-2022-A.8.8 gap statements both record a CISA due date of 2025-05-07. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' rwep_score 57, cvss 6.5, poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For an SMA 100 that was actually exploited, the vendor firmware is not the fix. The packet describes the actor using this injection as the on-box code-execution primitive to repack the INITRD boot image and install the OVERSTEP rootkit via /etc/ld.so.preload, producing persistent, reboot-surviving, log-tampering control of the appliance and a credential-exfiltration foothold for lateral movement. Each of those properties defeats patch-in-place specifically: the implant sits in the boot image and the preload path rather than in the vulnerable web-management component, and it survives the reboot the update itself requires, so an appliance can come back from the upgrade on a fixed build and still be under the actor's control. The requirement is that any SMA 100 which was reachable and running an affected build during the exposure window is handled as compromised until shown otherwise — configuration exported and reviewed off the appliance, the unit rebuilt from vendor media rather than upgraded in place (or replaced outright where the retirement control applies), and every credential that lived on or transited it rotated, including the administrator accounts and the OTP seeds, since the packet places both in the actor's hands already and describes the appliance as a credential-exfiltration foothold. Precondition, and it is the one operators get wrong here: the appliance's own logs cannot support a 'we were not affected' conclusion, because the packet records the implant as giving log-tampering control of the box — absence of evidence on-box is not evidence of absence, and that judgement has to rest on records held elsewhere. This is a response requirement only. It does nothing about the injection itself, which needs the vendor update the packet records, and it does not reduce the window before that update lands.",
+        "evidence": "Packet vector: the actor 'uses this injection as the on-box code-execution primitive to repack the INITRD boot image and install the OVERSTEP rootkit via /etc/ld.so.preload — converting a limited \"nobody\" command run into persistent, reboot-surviving, log-tampering control of the appliance and a credential-exfiltration foothold for lateral movement', after first obtaining 'valid admin credentials/OTP seeds (likely harvested in earlier intrusions)'. Injected commands execute as the low-privilege 'nobody' account. active_exploitation 'confirmed'; kev_date 2025-04-16; active_exploitation_notes attribute the campaign to UNC6148 with tradecraft overlapping historical Abyss-branded ransomware deployments (GTIG/Mandiant, July 2025). patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The only signal this campaign generates on the appliance is an authentication event, and it is exactly the record the implant can edit. The packet has UNC6148 arriving with valid admin credentials and OTP seeds harvested in earlier intrusions, so on the SMA 100 the exploitation looks like a legitimate administrator authenticating to the management plane and the appliance then doing something — and it has OVERSTEP giving log-tampering control of that same box. Applied to this appliance, the control means every SMA 100 forwards its management-plane authentication, administrative-action and system logs to a collector in a separate trust zone: different credentials, different management plane, and no administrative path from the appliance to the collector, so an admin login from an unfamiliar source or outside an operator's working hours is recorded somewhere the appliance cannot reach. Include the appliance's outbound connection records, because the packet describes the foothold as a credential-exfiltration platform for lateral movement, and egress from a remote-access appliance to an unfamiliar destination is observable from the network even when the on-box record is not. This is also what stops the estate's assurance about its boundary from depending on the boundary device's own integrity — the premise the cited boundary-protection and network-security gaps both rest on. Precondition, stated plainly because it is easy to overclaim: forwarding preserves what reached the collector before the implant landed and gives an independent view afterward, but the packet describes an actor with log-tampering control of the appliance, so what the appliance chooses to emit after compromise is not trustworthy either. Treat the post-compromise stream as suspect and lean on the pre-compromise record and network-side observation. It is detection only: it neither prevents the injection nor evicts OVERSTEP, and on an appliance already carrying the implant it bounds discovery time rather than exposure.",
+        "evidence": "Packet vector: the actor 'first obtains valid admin credentials/OTP seeds (likely harvested in earlier intrusions)' and the resulting control of the appliance is 'persistent, reboot-surviving, log-tampering ... and a credential-exfiltration foothold for lateral movement'. The NIST-800-53-SC-7 gap records that boundary protection treats this appliance as the boundary and protects nothing in front of it once the boundary device itself carries the flaw; the NIS2-Art21-network-security gap records that network-security obligations are met by perimeter and segmentation controls that assume the appliance is trustworthy. active_exploitation 'confirmed', kev_date 2025-04-16, attributed to UNC6148 (GTIG/Mandiant, July 2025). poc_available false.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-53150": {
     "name": "Linux Kernel Out-of-Bounds Read Vulnerability",
@@ -35864,7 +36240,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "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 leaves no interim state to reach. patch_available is false, and affected_versions records every firmware version of the Edimax IC-7100 as affected with no fixed version existing, because the product is end-of-life / end-of-service and will not receive a security patch; the vector states the same conclusion directly — the only durable remediation is network isolation or hardware replacement. So unlike a device where reaching the fixed build is an interim step, here there is no build any unit can be driven to, and the requirement is an inventory naming every IC-7100 in service with its location and its network reachability, with each unit placed on a dated replacement schedule. A risk acceptance carrying no removal date leaves a KEV-listed camera with a PoC public since June 2023 and confirmed enrollment into DDoS botnets in service indefinitely, which is the outcome this control exists to prevent. Scope the sweep to the model the packet names — the IC-7100 — and widen it only where a verified source identifies another product carrying the same /camera-cgi/admin/param.cgi handling. Precondition on the isolation that bridges the gap until replacement: the injection sits in the camera's own web management interface, so removing internet reachability — typically a router port-forward or a UPnP mapping, which is how these cameras acquire exposure — bounds who can send the request from outside, but the camera exists to be viewed from the network attached to it, and every host on that segment still reaches the CGI. Isolation therefore means placing the camera in a segment that can reach nothing else, not removing the path. And because exploitation is confirmed and the injected command stages and runs an architecture-matched Mirai ELF binary on the device, a unit that was internet-reachable is not returned to service by a configuration change: it is a removal item, and the segment and credentials it sat on belong on the incident path.",
+        "evidence": "Packet fields for CVE-2025-1316 (Edimax IC-7100 IP Camera OS Command Injection Vulnerability): cwe_refs CWE-78; cisa_kev true, kev_date 2025-03-19, active_exploitation confirmed; rwep_score 85, cvss 9.8; poc_available true; patch_available false; live_patch_available false. affected_versions records 'Edimax IC-7100 IP camera — all firmware versions (no fixed version exists; product is end-of-life / end-of-service and will not receive a security patch)'. The vector names the /camera-cgi/admin/param.cgi endpoint of the web management interface, the failure to neutralize OS shell metacharacters in the NTP_serverName field of the ipcamSource option, cameras commonly internet-exposed, an injected command that downloads a curl.sh/wget.sh stager pulling architecture-matched Mirai ELF payloads into a world-writable directory and running them to enroll the camera into a DDoS botnet, and states that because the device is end-of-life with no patch the only durable remediation is network isolation or hardware replacement. active_exploitation_notes record a public PoC available since June 2023 and Akamai SIRT honeypot activity from May 2024.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-118",
+        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
+        "description": "This entry's own citing gaps place the camera inside a zone-and-conduit model — IEC 62443-3-3 segmentation as the compensating control, and NIST SP 800-82r3 treating the device as a trusted endpoint inside a segmented cell — so both halves of this control have purchase here, but they carry different weight. The credential half is a lever the operator genuinely holds, unlike cases where the key is discoverable from the vendor's own software: the packet names unchanged default credentials admin:1234 as the route by which attackers commonly reach /camera-cgi/admin/param.cgi, so every IC-7100 in service should have that vendor default rotated. It must not be recorded as closing the path, because this entry's framework gaps describe the flaw as an unauthenticated OS command injection — rotating the password removes the commonly-observed access route without demonstrating that the endpoint requires a credential at all. The segmentation half is therefore load-bearing. Applied to this camera it means the IC-7100's web management interface answers only from the operator segment that legitimately views and administers it, not from the internet through a port-forward or UPnP mapping and not from a general user VLAN, and that the camera's outbound path is constrained as well — the packet's exploitation path is outbound by design, since the injected command fetches a curl.sh/wget.sh stager, pulls architecture-matched Mirai ELF payloads, and then beacons to C2 (angela.spklove.com:3093 for the strain Akamai labels 'Unstable Mirai'; merisprivate.net / ziparchive.xyz for the second, anti-debugging variant). An egress policy permitting the camera only the destinations its operation requires — including the NTP server named by the very field that carries the injection — breaks the stager fetch and the beacon. Distinguishing test: from a general user VLAN and from an external address, request /camera-cgi/admin/param.cgi on an IC-7100; anything that answers is within reach of a PoC public since June 2023, and 'the cameras are on the internal network' is a statement about topology rather than a demonstration that the CGI is unreachable. Preconditions: segmentation bounds who can send the request and egress control bounds what an injected command can retrieve; neither repairs the missing metacharacter neutralization, and any compromised host inside the permitted segment reaches the CGI in full. Because patch_available is false these are permanent compensating measures rather than a holding action before a fix, which is why the dated replacement schedule has to run alongside them.",
+        "evidence": "Packet fields for CVE-2025-1316: the vector states that an attacker who reaches /camera-cgi/admin/param.cgi — commonly via unchanged default credentials admin:1234, often on internet-exposed cameras — injects a shell command string executed as the CGI's privileged context, and that in observed campaigns the injected command downloads a curl.sh/wget.sh stager pulling architecture-matched Mirai ELF payloads into a world-writable directory. The endpoint's vulnerable field is NTP_serverName of the ipcamSource option. active_exploitation_notes name the Akamai-labelled 'Unstable Mirai' strain beaconing to angela.spklove.com:3093 and a second anti-debugging variant using merisprivate.net / ziparchive.xyz C2, with a public PoC since June 2023. Cited gaps: IEC-62443-3-3 ('zone-and-conduit segmentation is the compensating control, but an internet-reachable device ... bridges the IT and OT zones it is supposed to keep apart'), NIST-800-82r3 ('treats the device as a trusted endpoint inside a segmented cell; compromise ... turns it into an OT pivot'), NIS2-Art21-network-security ('perimeter and segmentation controls that assume the appliance is trustworthy'). patch_available is false and affected_versions records no fixed version because the product is end-of-life.",
+        "gap_closes": [
+          "IEC-62443-3-3",
+          "NIST-800-82r3",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This control's three-state distinction is what an IC-7100 estate needs, because the first state — binary patch deployed, vulnerability eliminated — is unreachable for this CVE and always will be: patch_available is false, every firmware version is affected, and affected_versions records that no fixed version exists because the product is end-of-life and will not receive a security patch. A camera whose management CGI has been isolated therefore sits permanently in the compensating-control state, and the audit record must show it as that, with the dated replacement action attached, rather than as remediated or as a closed flaw-remediation ticket. The failure this prevents is specific to a device with no patch path: a vulnerability-management report keyed on patched-versus-unpatched has no true state to move an IC-7100 into, so the finding either stays open forever and is eventually suppressed as stale noise, or it is closed on the isolation change — at which point the camera leaves the estate's exposure view while still running a CGI with a PoC public since June 2023 and confirmed exploitation into Mirai botnets. The same record must also distinguish the isolated units from the third state the control names, full exposure, since the packet's exploitation set is internet-reachable cameras and an unisolated unit is in that state today. Precondition: this is a reporting requirement, not a mitigation. It changes nothing on the device, and it is only meaningful if the compensating-control entry carries the removal date — an isolation record with no expiry is the same permanent open exposure written in different words, which is exactly the outcome a KEV due date of 2025-04-09 was meant to force.",
+        "evidence": "Packet fields for CVE-2025-1316: patch_available false; live_patch_available false; affected_versions 'all firmware versions (no fixed version exists; product is end-of-life / end-of-service and will not receive a security patch)'; cisa_kev true with kev_date 2025-03-19; active_exploitation confirmed; poc_available true, with active_exploitation_notes recording a public PoC since June 2023 and exploitation by at least two Mirai-variant botnets. The NIST-800-53-SI-2 gap records that the routine 30-day flaw-remediation SLA is far longer than the in-the-wild exploitation window for this KEV-listed unauthenticated OS command injection and that CISA set a 2025-04-09 due date. The vector records the device as end-of-life with no patch, leaving network isolation or hardware replacement as the only durable remediation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-24472": {
     "name": "Fortinet FortiOS and FortiProxy Authentication Bypass Vulnerability",
@@ -37219,7 +37628,41 @@
     },
     "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": "For Progress WhatsUp Gold the packet shows why the trigger for this SLA cannot be the KEV listing alone. Exploitation began 2024-08-30, within hours of the public PoC release, against internet-exposed instances; CISA listed it 2025-03-03 with a 2025-03-24 due date; and the fixed build, 2023.1.3, predates both. An organization whose emergency clock starts at KEV listing was therefore roughly six months late by construction, while one that started at patch availability had the fix on the shelf the whole time. Bound to this product, the requirement is that the four-hour clock start at the first observable of {fixed build published, working PoC public, KEV listing} for any internet-reachable WhatsUp Gold instance, and that the 2025-03-24 CISA due date be treated as the outer bound rather than the target. Remediation is the vendor update to 2023.1.3 or later; live_patch_available is false, so there is no in-place hot fix and no configuration change stands in for the update indefinitely. Note precisely what patch_required_reboot: false buys — it removes a host reboot from the change window, but the vulnerable code is the WhatsUp Gold web application served under the iisapppool\\nmconsole identity the packet names, so completion is measured on the build the running application reports after the update, not on the installer's exit status. Distinguishing test: confirm each instance's running application reports 2023.1.3 or later, and separately establish whether it was reachable from an untrusted network at any point after 2024-08-30 — that second question is an incident question, and a clean version check does not answer it.",
+        "evidence": "Packet: 'In WhatsUp Gold versions released before 2023.1.3, an unauthenticated Remote Code Execution vulnerability in Progress WhatsUpGold. The WhatsUp.ExportUtilities.Export.GetFileWithoutZip allows execution of commands with iisapppool\\nmconsole privileges' (CWE-22, CVSS 9.8, RWEP 68, poc_available true). active_exploitation_notes: 'Actively exploited beginning Aug 30, 2024 — within hours of the public PoC release... Added to CISA KEV March 3, 2025.' The NIST-800-53-SI-2 gap records the CISA due date as 2025-03-24. affected_versions: 'Affected: WhatsUp Gold before 2023.1.3', 'Fixed: 2023.1.3'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update... plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "WhatsUp Gold is not a firewall, but the packet puts it in exactly the position this runbook governs — an internet-exposed service taking unauthenticated remote code execution while under active exploitation — and it names the post-exploitation behaviour that makes patch-in-place insufficient. Trend Micro's MXDR team observed attacks abusing the legitimate WhatsUp Gold process, in the iisapppool\\nmconsole context, to download and stage multiple remote-management tools (Atera, Radmin) as an initial-access foothold. Those are ordinary remote-administration agents installed on the host: updating WhatsUp Gold to 2023.1.3 removes the traversal path and leaves them running and reachable by whoever installed them, and they survive the update, an application restart and a host reboot alike. So for any instance that was internet-reachable between 2024-08-30 and the date it was actually serving 2023.1.3, the disposition is host-level — enumerate installed remote-management agents, services and scheduled tasks against a known-good baseline, rebuild where one is found rather than uninstalling in place, and rotate the credentials the host and its service identity used. Precondition: this is scoped by exposure window and reachability, not applied to every install; an instance that was never reachable from an untrusted network during that window is a patch item. The signal to hunt is the one the packet documents — the WhatsUp Gold application process initiating downloads or installer activity, and RMM agents present on a monitoring server that has no operational reason to run them. Absence of that signal is weak evidence wherever process-level telemetry was not retained on the host, which on a monitoring server is common.",
+        "evidence": "Packet active_exploitation_notes: 'Trend Micro's MXDR team observed attacks abusing the legitimate WhatsUp Gold process (the iisapppool\\nmconsole context) to download and stage multiple remote-management tools (Atera, Radmin) as an initial-access foothold on internet-exposed instances. Unauthenticated, so mass opportunistic scanning followed.' Exploitation began 2024-08-30 within hours of the public PoC release; CISA KEV 2025-03-03. Fixed build 2023.1.3; patch_required_reboot false; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The version boundary in this entry is one point release wide — affected is everything before 2023.1.3, fixed is 2023.1.3 — so any attestation that records the product at marketing-version granularity cannot answer whether the host is exposed, and a scanner or CMDB comparison that treats an install on the 2023.1 line as satisfying '2023.1' reports a vulnerable monitoring server as compliant. Bound to this product the operational test has two parts. Does the inventory carry the full point release for every WhatsUp Gold install? And is that value read from the running application rather than from an installer log or a change ticket — because patch_required_reboot is false, which removes the host reboot that would otherwise force the question, and live_patch_available is false, so nothing about the running instance changes until the updated application is actually serving. The second part is what makes the difference here: an organization can hold a true statement that the update was applied while the instance an attacker reaches is still the pre-fix build. Precondition: this is a verification control, not a remediation. It catches the false-clean report; it does not shorten the exposure, and on a host that was internet-reachable while exposed a clean version check says nothing about whether the host was already reached — that question is answered by hunting the staged remote-management agents, not by a build number.",
+        "evidence": "Packet affected_versions: 'Affected: WhatsUp Gold before 2023.1.3' and 'Fixed: 2023.1.3'. patch_required_reboot false; live_patch_available false. The AU-Essential-8-Patch gap records that Essential Eight patch maturity 'is scored on cadence, not on KEV-anchored emergency response'; the ISO-27001-2022-A.8.8 gap records that 'appropriate timescales' is left undefined while the operative clock is the CISA due date of 2025-03-24.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2018-8639": {
     "name": "Microsoft Windows Win32k Improper Resource Shutdown or Release Vulnerability",
@@ -38402,7 +38845,40 @@
         "adequate": false,
         "gap": "Adobe's patch existed before the exploitation wave, but the ~24-hour gap between WatchTowr's public technical analysis and CISA's KEV addition shows flaw-remediation timelines can't outrun a public write-up that doubles as an exploitation guide."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For ColdFusion this CVE sets the clock at disclosure, not at the next application-patch window: the packet records honeypots seeing the first in-the-wild attempt within roughly two hours of the public technical write-up on 2026-07-06, CISA listing on 2026-07-07, and a due date of 2026-07-10. The population is both release trains the packet names — every ColdFusion 2025 install at or below Update 9 and every 2023 install at or below Update 20 — driven above those update levels on that clock. Completion is measured on the update level the running ColdFusion instance reports, not on an update downloaded or approved in a management console: patch_required_reboot is false, so no host reboot is recorded, but the packet registers no live-patch path, so nothing about this fix lands on an instance that is not actually executing the newer build. For an instance that genuinely cannot take the update inside the window, the SLA's compensating-control branch is removing external reach to the RDS FILEIO endpoint — and that branch must be recorded as a time-bound holding measure, with the precondition that the instance's users do not need to reach /CFIDE/main/ide.cfm, and with no claim that it remediates an instance already exploited during the window.",
+        "evidence": "Packet: CISA KEV 2026-07-07, due 2026-07-10; active_exploitation confirmed; active_exploitation_notes record the first in-the-wild exploitation attempt within roughly two hours of the public technical write-up on 2026-07-06, using C:\\Windows\\win.ini as a canary, with Canadian and Belgian national CERT alerts. CVSS 10, RWEP 74, poc_available true. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions: 2025 <= Update 9, 2023 <= Update 20. The AU-Essential-8-Patch gap states the internet-facing patch target was outpaced by the ~24-hour gap between the public write-up and the KEV listing; the SI-2 gap states flaw-remediation timelines cannot outrun a public write-up that doubles as an exploitation guide.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "ColdFusion's Remote Development Services is exactly the application-server remoting surface this control governs: the packet places the defect in the RDS FILEIO handler at /CFIDE/main/ide.cfm, which insufficiently validates the FILE path parameter and answers an unauthenticated caller with arbitrary file read and write anywhere on the filesystem, including the webroot. For this product the requirement is that a production ColdFusion instance does not expose RDS at all — disabled in the server configuration on any deployment that does not do remote development — and that where it must stay enabled, the endpoint answers only from a development or management segment enforced by network ACL or host firewall, rather than inherited from the assumption that the app server sits behind a load balancer. Distinguishing test for this product: from an untrusted user segment and from an external address, request /CFIDE/main/ide.cfm with ACTION=FILEIO against a staging instance; anything that answers is within reach of the published path, and an instance that passes a boundary-protection review because its HTTPS listener is fronted by a proxy is still exposed if that proxy forwards this path. Precondition: this bounds who can send the request, it does not repair the FILE parameter validation — the vendor update does that — and it is unavailable where the deployment legitimately requires remote development access, which is why it is an interim measure against the KEV clock rather than a substitute for the update.",
+        "evidence": "Packet: affected states the RDS FILEIO handler at /CFIDE/main/ide.cfm insufficiently validates the FILE path parameter, allowing unauthenticated arbitrary file read/write anywhere on the filesystem including the webroot; attack_vector describes an unauthenticated crafted request to /CFIDE/main/ide.cfm?ACTION=FILEIO with a path-traversal payload in the FILE parameter. The NIST-800-53-SC-7 gap states RDS endpoints like /CFIDE/main/ide.cfm are development tooling that should be blocked at the network boundary in production, not internet-reachable; the UK-CAF-B4 gap states secure-by-default guidance should disable RDS in production ColdFusion instances, which many long-lived installs leave enabled from initial setup.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive here is an arbitrary write into the ColdFusion webroot and the packet's own attack path is dropping a .cfm webshell there for code execution, so the update closes the write path and removes nothing already written through it — a webshell placed before remediation keeps serving from an instance that now reports an update level above 2025 Update 9 / 2023 Update 20. Because exploitation began roughly two hours after the public write-up and CISA's due date was three days after listing, any instance that was internet-reachable across that window has to be assessed rather than closed on the patch record: compare the webroot and the ColdFusion installation against a known-good deployment artifact, treat any .cfm present that no sanctioned deployment produced as an implant, and treat every secret stored on that filesystem as read, since the same handler gave unauthenticated arbitrary file read anywhere on disk. Distinguishing test keyed to the behaviour the packet documents rather than to tool signatures or crashes — this exploit produces neither: search web logs for requests to /CFIDE/main/ide.cfm carrying ACTION=FILEIO with traversal sequences in the FILE parameter, and for reads of C:\\Windows\\win.ini, the canary the packet records honeypots observing, then correlate against files appearing under the webroot outside a deployment window. A flaw-remediation attestation showing every instance above the fixed update level reads clean while a pre-patch webshell is still reachable.",
+        "evidence": "Packet: attack_vector describes writing an arbitrary file (e.g. a .cfm webshell) into the webroot for RCE, or reading sensitive files as reconnaissance; affected records unauthenticated arbitrary file read/write anywhere on the filesystem including the webroot. active_exploitation confirmed, with the first attempt recorded within roughly two hours of the 2026-07-06 write-up, reading C:\\Windows\\win.ini as a canary; KEV 2026-07-07 due 2026-07-10. The NIST-800-53-SI-2 gap states Adobe's patch existed before the exploitation wave and that flaw-remediation timelines cannot outrun a public write-up that doubles as an exploitation guide — i.e. exploitation preceded remediation on exposed instances, which is the condition under which patch-in-place is not an end state.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-23209": {
     "name": "Craft CMS Code Injection Vulnerability",
@@ -38610,7 +39086,38 @@
         "adequate": false,
         "gap": "Access enforcement assumed authentication was required before file retrieval; the traversal bug let the toolbox handler serve files outside any access-control check."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the control means every SimpleHelp server is moved past 5.5.7 on the clock that opened with the 2025-02-13 KEV listing, and it has two SimpleHelp-specific requirements that a generic patch SLA does not produce. First, the clock cannot be driven by advisory-feed ingestion: the packet records that the vendor's fix was published as release notes rather than a CVE-tagged bulletin, so a vulnerability-management pipeline that waits for a CVE-tagged vendor advisory to raise a ticket never starts counting on this one — the trigger has to be the KEV listing itself plus the vendor's release notes watched as a patch source in their own right. Second, the inventory has to extend past self-operated servers. The packet's own gaps record third-party remote-support and RMM tooling as routinely outside an operator's vulnerability program while being a direct pivot into customer networks, so an estate that enumerates only the SimpleHelp servers it runs itself reports clean while a managed-service provider's unpatched server holds the path into the same network. Scope stays where the packet puts it: the SimpleHelp server component at 5.5.7 and earlier — the packet gives no mapping into other remote-support products, so this is not licence to sweep every RMM tool in the estate as an instance of this CVE. patch_required_reboot is false, which records no machine reboot, and live_patch_available is false; completion is therefore measured on the version the running SimpleHelp server reports, not on a build being staged on the host. The urgency is set by the packet rather than the 7.5 CVSS: a public proof-of-concept, confirmed exploitation from January 2025, and a KEV entry flagged for confirmed ransomware use.",
+        "evidence": "affected_versions: 'SimpleHelp <= 5.5.7'; patch_available true; patch_required_reboot false; live_patch_available false. CISA KEV listing 2025-02-13; active_exploitation 'confirmed'; poc_available true; CVSS 7.5; RWEP 70. The packet's NIS2-Art21-vulnerability-management gap: 'Third-party RMM software supply-chain risk (MSP and utility exposure) isn't covered by an operator's own patch cadence when the vendor's fix was published as release notes rather than a CVE-tagged bulletin.' The AU-Essential-8-Patch gap: 'Extreme-risk patch timeframe (48h) was not met broadly — thousands of internet-facing SimpleHelp instances remained unpatched into the DragonForce ransomware campaign.' The ISO-27001-2022-A.8.8 gap records third-party RMM/remote-support tooling as 'frequently out of scope for an operator's own vulnerability program, even though it's a direct pivot point into customer networks.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "A SimpleHelp server is the remote-management plane for every machine its technicians reach, and the packet puts the defect on one of its resource handlers by name: respondToolboxResource serves files selected by a crafted HTTP request, and the traversal walks the selection out of the intended root. Bound to this product the control means that handler authorizes its caller before it resolves anything at all, and resolves the requested path to a canonical absolute form and verifies the result still sits under the intended resource root before the file is opened — a check on the resolved path rather than a filter applied to the request string, and applied to the read direction, since the unauthorized operation here is a download rather than an upload. The access-enforcement control cited as insufficient on this entry cannot reach this path for a structural reason worth stating: the attacker never authenticates, so no access-control decision is ever consulted, and an attestation that every SimpleHelp technician account is authenticated and scoped passes cleanly while the handler hands configuration files to anonymous callers. Distinguishing test: from an unauthenticated client, request paths carrying traversal sequences against each resource handler on a staging SimpleHelp server and confirm each is refused before any file handle is opened. Precondition: the containment check is a property the vendor build above 5.5.7 establishes — this control states what to verify, it does not implement it. Restricting which networks can reach the server bounds who can send the request, but SimpleHelp exists to be reachable by remote technicians and remote client machines, so on any instance serving that purpose there is no segment that removes the path; network restriction is a real lever only for instances whose reachable population can genuinely be narrowed, and it is not available as the answer for an internet-facing support server.",
+        "evidence": "affected: 'SimpleHelp remote support/RMM software server component, toolbox resource handler (respondToolboxResource), versions 5.5.7 and earlier.' vector: 'SimpleHelp remote support software v5.5.7 and before is vulnerable to multiple path traversal vulnerabilities that enable unauthenticated remote attackers to download arbitrary files from the SimpleHelp host via crafted HTTP requests.' The packet's NIST-800-53-AC-3 gap: 'Access enforcement assumed authentication was required before file retrieval; the traversal bug let the toolbox handler serve files outside any access-control check.' patch_available is true.",
+        "gap_closes": [
+          "NIST-800-53-AC-3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "What this traversal returned is why the upgrade alone does not end the incident: the packet states the downloadable files include server configuration files containing various secrets and hashed user passwords, and that DragonForce affiliates used the flaw as an initial-access vector against unpatched servers from January 2025. Moving a server past 5.5.7 closes the read path and invalidates nothing already read. Bound to this product the requirement is that any SimpleHelp server which was reachable by untrusted callers while running 5.5.7 or earlier is handled as a configuration-exfiltration event rather than a patching item: rotate every secret the server's configuration held and every credential it stored, and treat the technician accounts and the downstream machines that server could reach as in scope, because that reach into customer networks is exactly what the ransomware affiliates were acquiring. Scope note, stated rather than glossed: this control is written around pre-authentication remote code execution on a boundary system, and the primitive the packet records here is an unauthenticated read, not execution — so the rebuild half applies to hosts where follow-on access or execution is evidenced, while the configuration-exfiltration-and-rotation half is what the packet documents directly and applies to every exposed instance. Precondition: rotation is only complete if it covers material that is not obviously credential-shaped, because the packet says 'various secrets' rather than naming them, so anything the server used to authenticate outward is in scope; and hashed passwords remain usable for offline cracking and for replay wherever those accounts reused them, so rotation has to follow those accounts onto their other systems rather than stopping at SimpleHelp's own login.",
+        "evidence": "vector: 'These files include server configuration files containing various secrets and hashed user passwords.' active_exploitation_notes: 'Actively exploited since January 2025 by ransomware affiliates (DragonForce) as an initial-access vector against unpatched SimpleHelp servers, most notably a utility billing software provider per CISA advisory AA25-163A; CISA KEV flags confirmed ransomware use.' The packet's UK-CAF-B2 gap: 'Identity and access management control assumes credentials in config files stay secret; path traversal defeats that assumption entirely regardless of IAM posture.' patch_available true with affected_versions 'SimpleHelp <= 5.5.7'.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-24200": {
     "name": "Apple iOS and iPadOS Incorrect Authorization Vulnerability",
@@ -38873,7 +39380,31 @@
         "adequate": false,
         "gap": "Flaw remediation is structurally impossible: Zyxel has declared these DSL CPE devices end-of-life/end-of-service with no patch planned, so the standard remediate-within-SLA control has no path to closure short of hardware replacement."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet forecloses the interim half of this control before it begins: patch_available is false, the vector opens with the UNSUPPORTED WHEN ASSIGNED marker, and live_patch_notes records that no live-patch path exists for this EOL firmware and that the vendor's only guidance is to discontinue use of the device if it cannot be isolated from untrusted networks. So for these legacy Zyxel DSL CPE units there is no fixed build to reach and no patched state to record — every unit in service is a replacement item, and the requirement is an inventory naming each VMG4325-B10A and each related legacy Zyxel DSL CPE running firmware 1.00(AAFR.4)C0_20170615, with a dated removal date per unit rather than a remediation ticket that waits on firmware. Scope it to what the packet's affected and affected_versions name — VMG4325-B10A and the related legacy Zyxel DSL CPE builds sharing the same management-command codebase — because the packet maps this command-injection sink to that codebase and to no other Zyxel line, and sweeping every Zyxel device in the estate as an instance of this CVE manufactures replacement work against hardware no evidence implicates. Until a unit is gone, the only lever the packet leaves is the isolation the vendor names, and its precondition has to be stated rather than assumed: the injection is reached through the Telnet-exposed management command interface, so blocking Telnet at the WAN interface removes the path Censys observed on 1,500+ of these devices and the path GreyNoise saw scanned from January 2025 — but a DSL CPE exists to serve the LAN attached to it, and every client on that LAN still reaches the management interface with the default or service-account credentials the packet describes the attack using. For a unit serving a general user network there is no filter that removes the path, only isolation of that network from anything that matters. And because active exploitation is confirmed and Mirai variants recruited these routers into botnet infrastructure, a unit that was WAN-reachable during the exposure window is not made safe by filtering it now: the flaw yields OS command execution on the device itself, so it is a removal item rather than a reconfiguration item, and any credential that transited it should be rotated.",
+        "evidence": "Packet fields: patch_available false, live_patch_available false, patch_required_reboot true with no patch to apply; live_patch_notes — \"No live-patch path exists for this EOL firmware; the vendor's only guidance is to discontinue use of the device if it cannot be isolated from untrusted networks.\" The vector carries the UNSUPPORTED WHEN ASSIGNED marker and describes a post-authentication command injection in the management commands of the legacy DSL CPE Zyxel VMG4325-B10A firmware version 1.00(AAFR.4)C0_20170615, executed via Telnet; affected/affected_versions scope to VMG4325-B10A and related legacy Zyxel DSL CPE firmware builds sharing the same management-command codebase; CWE-78; cvss 8.8, rwep_score 70; poc_available false; cisa_kev true with kev_date 2025-02-11 and active_exploitation confirmed. active_exploitation_notes: GreyNoise observed mass scanning and exploitation attempts beginning January 2025 and Mirai botnet variants incorporated exploitation of this Telnet-based command injection, using it alongside CVE-2024-40890 to recruit EOL routers. framework_control_gaps: NIST-800-53-SI-2 records Zyxel declaring these devices end-of-life/end-of-service with no patch planned and no closure short of hardware replacement; NIST-800-53-CM-7 records Censys observing 1,500+ of these EOL devices with the Telnet management interface reachable directly from the WAN; UK-CAF-B4 records the Telnet management plane exposed to the untrusted WAN interface; ISO-27001-2022-A.8.8 records these units sitting outside the ISMS asset register.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry only the control's third branch is reachable. Its requirement is a verified mitigation — patch, live patch, or documented compensating controls — on the KEV clock, and the packet records patch_available false and live_patch_available false with no live-patch path for this EOL firmware, so the clock that opened with the 2025-02-11 KEV listing can only be answered by the compensating action the vendor names: isolate the device from untrusted networks, or discontinue use. That is precisely what the two frameworks cited here cannot express — Essential Eight's patch-within-48-hours-of-active-exploitation expectation is unmeetable because no patch exists, and NIS2 vulnerability handling assumes an eventual vendor fix that will never ship for this hardware — so the compensating action has to be recorded as the terminal deliverable against the KEV date, not as a temporary state pending firmware. Operationally, every affected unit needs a dated, evidenced record of either its removal or its Telnet management interface being unreachable from the WAN, produced against the listing date rather than left as an open remediation ticket. Distinguishing test, keyed on the exploitation path the packet documents: from outside the device's WAN interface, attempt a Telnet connection to each unit and issue a management command; anything that answers is within reach of the scanning and exploitation GreyNoise observed from January 2025, and a vulnerability-management report carrying this CVE as \"no patch available, risk accepted\" while the interface answers has recorded the exposure rather than mitigated it. Precondition: the isolation is a mitigation only while it holds, and it depends on a WAN-side filter surviving firmware resets, ISP re-provisioning and user reconfiguration on hardware the operator generally does not manage — which is why the vendor's own guidance ends at discontinuing use rather than at isolation.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2025-02-11 and active_exploitation confirmed; patch_available false; live_patch_available false; live_patch_notes — \"No live-patch path exists for this EOL firmware; the vendor's only guidance is to discontinue use of the device if it cannot be isolated from untrusted networks.\" attack_vector: an attacker with a Telnet session to a legacy Zyxel DSL CPE device, using default or otherwise-obtained service-account credentials, sends management commands containing embedded shell metacharacters that are passed unsanitized to the underlying OS shell. active_exploitation_notes: GreyNoise observed mass scanning and exploitation attempts against exposed Zyxel legacy DSL CPE devices beginning January 2025. framework_control_gaps: AU-Essential-8-Patch — \"Essential 8's patch-within-48-hours-of-active-exploitation guidance is unmeetable since no patch exists; the only compensating action is decommissioning or isolating the device from the internet\"; NIS2-Art21-vulnerability-management — \"NIS2 operators relying on this hardware have no vendor remediation SLA at all post-EOL; typical vulnerability-management timelines assume an eventual vendor fix that will never ship.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-40890": {
     "name": "Zyxel DSL CPE OS Command Injection Vulnerability (CGI)",
@@ -38910,7 +39441,31 @@
         "adequate": false,
         "gap": "Boundary protection is absent by design: the CGI management program is reachable via HTTP POST from the untrusted WAN interface with no network-layer restriction."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet settles the patch question before the control begins: patch_available is false, the CVE text is marked UNSUPPORTED WHEN ASSIGNED, and the vendor's only recorded guidance is to discontinue use of the device if it cannot be isolated from untrusted networks. There is no fixed firmware to reach and therefore no interim state — for these units the terminal state is removal or replacement, and the enumeration half is what makes that actionable: inventory every Zyxel legacy DSL CPE in service with its model and running firmware, covering the related legacy models sharing the same CGI codebase that the packet's affected_versions name rather than only the VMG4325-B10A the vector headlines, since an estate that standardised on a sibling model would otherwise report clean. Each unit becomes a dated replacement item; a risk acceptance with no removal date leaves a KEV-listed device under confirmed mass exploitation in service indefinitely, and it stays exposed to everything else found in that abandoned firmware, not only this command injection. Precondition on the isolation half, which the vendor guidance itself makes conditional: the flaw is reached by an HTTP POST to the CGI management program, so removing WAN-side reachability of that interface takes the unit out of the internet-facing path the trackers observed from January 2025 — but a DSL CPE exists to serve the client network behind it, and every client on that network still reaches the CGI management surface, so for a unit serving a general user network isolation bounds who can reach the path rather than removing it. The post-authentication framing is not a barrier either: the packet places the session on a default or service account, so the precondition is credentials that ship with the device rather than anything an attacker must first steal. And because active exploitation is confirmed and the outcome is OS command execution on the device itself, a unit that was reachable during the window is not made safe by reconfiguration — it is replaced, and credentials that transited it are rotated.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes 'No live-patch path exists for this EOL firmware; the vendor's only guidance is to discontinue use of the device if it cannot be isolated from untrusted networks.' vector begins '**UNSUPPORTED WHEN ASSIGNED**' and describes post-authentication command injection in the CGI program of the legacy DSL CPE Zyxel VMG4325-B10A firmware 1.00(AAFR.4)C0_20170615 via a crafted HTTP POST request; affected_versions extends to 'related legacy Zyxel DSL CPE firmware builds sharing the same CGI codebase'; affected records the session as an 'authenticated (default/service-account) session'. cisa_kev true, kev_date 2025-02-11, active_exploitation confirmed, CVSS 8.8, RWEP 70, CWE-78. active_exploitation_notes: GreyNoise and Mirai botnet trackers observed mass scanning/exploitation of exposed devices via crafted HTTP POST requests against the CGI management program beginning January 2025. The NIST-800-53-SI-2 gap states remediation is structurally impossible with no path to closure short of hardware replacement; the NIST-800-53-SC-7 gap states the CGI management program is reachable via HTTP POST from the untrusted WAN interface with no network-layer restriction; the ISO-27001-2022-A.5.21 gap states the devices are vendor-abandoned with no patch path.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.5.21"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This control's three states resolve unusually on this entry, and that is the point of attaching it: state (a), binary patch deployed, is permanently unreachable. patch_available is false and live_patch_available is false with no live-patch path recorded for the abandoned firmware, so a Zyxel legacy DSL CPE that has been isolated from untrusted networks sits permanently in state (b) — compensating control active, no binary patch — and one that has not sits in state (c), full exposure, while its CGI management program answers HTTP POSTs from the WAN. The requirement here is that the compliance record says exactly that: an isolated VMG4325-B10A or sibling legacy unit must appear as a compensating-control state carrying a dated replacement action, never as remediated and never as an open-ended accepted risk, because unlike a patch-pending entry there is no future vendor event that converts the state — the only thing that closes it is the device leaving the estate. Precondition on what may be recorded as the compensating control: it has to be isolation actually in force and verified from outside, since 'the router sits behind the ISP connection' is an assertion about topology rather than evidence that the CGI interface is unreachable. The residual-risk statement attached to state (b) must also carry the two facts that bound it — LAN-side clients still reach the management surface, and the authenticating credential is a device default or service account — otherwise the record reads as containment while the exploited path remains available to anything on the client network.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes recording no live-patch path for this EOL firmware and vendor guidance to discontinue use of the device if it cannot be isolated from untrusted networks; poc_available false but active_exploitation confirmed with kev_date 2025-02-11 (KEV ransomware use flagged Unknown). The NIS2-Art21-vulnerability-management gap states that operators relying on this hardware have no vendor remediation SLA at all post-EOL and that typical vulnerability-management timelines assume an eventual vendor fix that will never ship; the AU-Essential-8-Patch gap states the patch-within-48-hours-of-active-exploitation guidance is unmeetable since no patch exists and the only compensating action is decommissioning or isolating the device from the internet.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-0994": {
     "name": "Trimble Cityworks Deserialization Vulnerability",
@@ -39537,7 +40092,38 @@
         "adequate": false,
         "gap": "Exploitation depends on obtaining admin credentials, frequently via the paired CVE-2018-19410 flaw; stronger identity-and-access controls (MFA, credential rotation) would blunt the chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "PRTG's sensor and notification management is the configuration surface this control governs, and the packet places the defect exactly there: parameters submitted through sensor or notification management — the packet names EXE/Script sensor parameters and notification 'Execute Program' actions — are passed unsanitized into an OS command, yielding execution on the PRTG core server and on any device the server manages. The missing boundary is not between an anonymous caller and the console; it is between holding PRTG System Administrator inside the application and running arbitrary OS commands as the account the PRTG core service runs under, across the monitored estate. Applied to this product, the control means the configuration fields that feed command execution accept a selection from an operator-curated set of programs and argument shapes rather than a free-form string composed at the console, and the process that executes them holds only the privileges monitoring genuinely requires rather than inheriting the reach of the monitoring platform. Distinguishing test: on a staging PRTG instance below 18.2.39, submit shell metacharacters in an EXE/Script sensor parameter and in a notification Execute Program action while authenticated as System Administrator, and observe whether an OS command runs — an attestation that every PRTG administrator is named, approved and periodically reviewed passes cleanly while this path is wide open, because the caller here is a legitimate administrator and no account model is being abused. That is the same reason the least-privilege gap recorded on this entry cannot be closed by tightening who holds the role. Precondition: the parameter handling itself is repaired by the vendor release — the packet records versions before 18.2.39 as affected — so this control states the property to verify and does not implement it. Until an instance is at or above that version, restricting who holds System Administrator bounds the population that can submit the parameters but does not close the path, because the packet's own exploitation account has attackers arriving with those credentials already in hand, frequently obtained through the companion pre-auth flaw CVE-2018-19410.",
+        "evidence": "Packet vector: 'An attacker who has access to the PRTG System Administrator web console with administrative privileges can exploit an OS command injection vulnerability (both on the server and on devices) by sending malformed parameters in sensor or notification management scenarios.' attack_vector names 'EXE/Script sensor parameters, notification \"Execute Program\" actions' passed unsanitized to an OS command 'yielding command execution on the PRTG core server or a monitored device'. affected_versions: '< 18.2.39'; patch_available true. The NIST-800-53-AC-6 gap: the console 'over-trusts authenticated administrators, allowing free-form OS-level parameter strings in sensor/notification configuration without least-privilege sandboxing of the executed command.' The AU-Essential-8-App-Hardening gap: those features 'are inherently high-risk command-execution surfaces that application-hardening guidance would restrict or disable where not required.' The ISO-27001-2022-A.8.9 gap: configuration management 'should validate/sanitize sensor and notification parameter fields rather than passing them unsanitized to OS command execution.' active_exploitation_notes place credential acquisition, 'often via the companion pre-auth flaw CVE-2018-19410', ahead of the injection.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The interval this control exists to compress is unusually visible on this entry: the flaw was disclosed against PRTG Network Monitor versions before 18.2.39 in 2018, and CISA added it to KEV on 2025-02-04, which the packet attributes to continued abuse of legacy, unpatched PRTG deployments. A KEV listing on a seven-year-old flaw is a statement that the population still running the vulnerable build is large enough to be worth an attacker's time, so the action here is an enumeration before it is a patch cycle: find every PRTG core server in service and record the version each runs, taking instances reachable from the internet first, since the packet's own vulnerability-management gap places the multi-year unpatched population in internet-exposed deployments. Every instance below 18.2.39 is on the clock that opened 2025-02-04. Measure completion on the version the running PRTG core service reports rather than on an installer having been executed; the packet records no live-patch path for this product, so the running service is the only thing whose version answers the question. Distinguishing test: query each PRTG core server for the version it is actually serving and confirm it is at or above 18.2.39 — a vulnerability-management report showing no PRTG findings because no PRTG server appears in it is the state this entry describes, not a clean result. Precondition: a public PoC exists and exploitation is confirmed, and the packet places command execution on the core server and on any device it manages, so an instance that ran a vulnerable build while its console was reachable by anyone holding or able to obtain System Administrator credentials is not remediated by the upgrade alone. Its configured sensors and notification actions are the objects the attacker writes to and should be compared against a known-good baseline rather than carried forward through the upgrade, and the devices the server manages belong in the blast radius rather than being assumed clean.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-02-04, active_exploitation confirmed, poc_available true, rwep_score 63 against cvss 7.2. affected_versions '< 18.2.39'; the vector records the issue as 'discovered in PRTG Network Monitor before 18.2.39'. active_exploitation_notes: attackers 'inject OS commands through sensor or notification configuration parameters for full RCE on the PRTG core server and any device it manages. Added to CISA KEV Feb 2025, reflecting continued abuse of legacy, unpatched PRTG deployments.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. The NIS2-Art21-vulnerability-management gap: 'A 2018-disclosed flaw remained unpatched and exploitable in internet-exposed PRTG deployments as of the 2025 KEV addition — patch-management processes failed over a multi-year window.'",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "PRTG Network Monitor is a monitoring control plane whose administrative account, on the packet's own account of this exploit, converts into command execution on the core server and on every device the server manages. That places PRTG System Administrator in the tier this control exists to name rather than in the application-admin tier where a monitoring tool is usually filed, and the difference is the whole point: an identity-and-access attestation that treats it as one more application admin is measuring the wrong thing. For this deployment the requirement is that the PRTG console is reached through a privileged-access path rather than from an operator's daily workstation, that holding System Administrator is a separate identity from the same person's ordinary account and other administrative roles, and that the session is step-up authenticated rather than opened with a reusable password — because the packet's exploitation account is a credential-theft chain, in which attackers first obtain PRTG System Administrator credentials, frequently via the companion pre-auth flaw CVE-2018-19410, and only then reach the injection sink. Distinguishing test: from a general workstation segment, attempt to reach the PRTG console with a password alone and confirm it is refused; an estate where the monitoring platform's admin credential is a reusable password reachable from any desk already satisfies the precondition this exploit needs. Precondition, stated plainly because this is where the control is over-claimed: raising the bar at the console login bounds credential reuse, it does not repair the unsanitized parameter handling, and it is never consulted by a chain step that yields a live session or an API token rather than a password. It also does nothing against an administrator who is legitimately authenticated, since the packet's caller holds the role by design. It bounds the population that can attempt the escalation; it is not a substitute for reaching 18.2.39.",
+        "evidence": "Packet active_exploitation_notes: 'Actively exploited by attackers who first obtain PRTG System Administrator credentials (often via the companion pre-auth flaw CVE-2018-19410) and then inject OS commands through sensor or notification configuration parameters for full RCE on the PRTG core server and any device it manages.' vector requires 'access to the PRTG System Administrator web console with administrative privileges'. The UK-CAF-B2 gap: 'Exploitation depends on obtaining admin credentials, frequently via the paired CVE-2018-19410 flaw; stronger identity-and-access controls (MFA, credential rotation) would blunt the chain.' patch_available true with affected_versions '< 18.2.39'.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2018-19410": {
     "name": "Paessler PRTG Network Monitor Local File Inclusion Vulnerability",
@@ -39707,7 +40293,40 @@
         "adequate": false,
         "gap": "Patch was released only after MSTIC flagged in-the-wild zero-day exploitation; a standard flaw-remediation SLA does not cover a pre-auth appliance flaw already being exploited before the fix shipped."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The SMA1000 is a remote-access appliance and its AMC/CMC management console is the surface this tier exists for: the packet's boundary-protection gap records that the console is intentionally internet-reachable for remote administration, so a request carrying a serialized object reaches a pre-authentication code path by design. Bound to this product, the tier means an SMA1000 defect of this class runs on a clock measured from the 2025-01-24 KEV listing rather than on the appliance-maintenance window — and the clock does not stop at 'hotfix downloaded'. The packet records live_patch_available as false and patch_required_reboot as true, so a unit that has taken the January 22, 2025 hotfix but has not been restarted is still executing the vulnerable code and is not remediated. Scope by the affected ceiling the packet gives — 12.4.3-02804 (platform-hotfix) and earlier — across every SMA1000 series unit, AMC and CMC alike, and take the exact fixed build from the vendor's advisory for that hotfix rather than assuming a later-looking version carries it. Precondition, and this is where the tier is most often over-claimed: its alternative of isolating the vulnerable interface is not available on a unit whose AMC/CMC must stay reachable for remote administration. For those units, restricting source networks bounds who can send the object but leaves the path fully exploitable from every permitted source; only the restart-completed hotfix closes it. Distinguishing test: for each SMA1000, compare the build the console reports after its last restart against the fixed build, not the build recorded in the change ticket.",
+        "evidence": "Packet: pre-authentication deserialization of untrusted data (CWE-502) in the SMA1000 AMC and CMC enabling a remote unauthenticated attacker to execute arbitrary OS commands; CVSS 9.8, RWEP 81, poc_available true, active_exploitation confirmed, CISA KEV 2025-01-24. Microsoft Threat Intelligence Center notified SonicWall of possible active exploitation as a zero-day before the January 22, 2025 hotfix; CISA added it to KEV two days later flagging known ransomware use. patch_available true, patch_required_reboot true, live_patch_available false. affected_versions: '12.4.3-02804 (platform-hotfix) and earlier'. The NIST-800-53-SC-7 gap states the AMC/CMC is intentionally internet-reachable for remote administration.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This entry is the case the runbook exists for. The packet records the flaw as exploited in the wild before a fix existed — Microsoft Threat Intelligence Center notified SonicWall of possible active exploitation ahead of the January 22, 2025 hotfix — so every SMA1000 whose AMC/CMC was reachable during that window has to be dispositioned as possibly-already-executed, not merely as unpatched. Applying the hotfix and restarting closes the deserialization path; it does not undo OS commands that already ran, and the packet records that threat actors later chained this with CVE-2025-40602 to obtain full root-level RCE, so on a unit that was reached the attacker's privilege is not bounded by what the management console normally holds. Default the disposition to capturing the configuration for analysis, rebuilding from vendor media onto the fixed build, and rotating the administrator credentials and every secret the appliance held or brokered — rather than restoring the pre-incident configuration wholesale, which carries any attacker-added account or setting straight onto the rebuilt unit. Precondition: this is scoped to units whose AMC/CMC was reachable from an untrusted network during the exposure window, and it does not identify which units were actually reached — the packet documents no indicator for that. Treat it as the default disposition to be argued down with evidence, not a finding raised only after evidence appears; CISA's KEV entry flags known ransomware use, which is precisely the outcome a patch-only disposition would leave in place.",
+        "evidence": "Packet active_exploitation_notes: 'Microsoft Threat Intelligence Center notified SonicWall of possible active exploitation of this pre-auth deserialization flaw as a zero-day before the January 22, 2025 hotfix; CISA added it to KEV two days later flagging known ransomware use. Threat actors later chained it with CVE-2025-40602 to obtain full root-level RCE on SMA1000 appliances.' The NIST-800-53-SI-2 gap records that the patch was released only after MSTIC flagged in-the-wild zero-day exploitation. active_exploitation confirmed; poc_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The AMC and the CMC are the device-management consoles this control governs, and the packet places the defect exactly where the control binds: the console accepts an untrusted serialized object and acts on it before any authentication decision is made, so an unauthenticated caller's input reaches a deserialization sink that ends in arbitrary OS command execution. Bound to this product the requirement is twofold — every AMC and CMC request path authorizes its caller before the request body is parsed at all, and the console does not reconstruct arbitrary object types from request-supplied data, so a crafted object cannot select what gets executed. This is also why the identity and least-privilege controls an audit examines never engage: the attacker holds no SMA1000 operator account, so per-account scoping is never consulted and an access-control attestation passes cleanly while the path stays open. Distinguishing test: on a staging SMA1000, send the AMC and the CMC an unauthenticated request carrying a serialized object of a type the console never legitimately receives, and confirm it is rejected before any deserialization runs. Precondition, stated plainly: the endpoint-side authorization and the deserialization restriction are properties of the vendor's fixed build — this control states what to verify, it does not implement it. Until the hotfix and its reboot land, restricting which networks may reach the AMC/CMC bounds who can send the object but leaves the sink fully reachable from every permitted source, and that bound is unavailable where the console must stay internet-reachable for remote administration, which the packet records as the deployed posture.",
+        "evidence": "Packet vector: 'Pre-authentication deserialization of untrusted data vulnerability has been identified in the SMA1000 Appliance Management Console (AMC) and Central Management Console (CMC), which in specific conditions could potentially enable a remote unauthenticated attacker to execute arbitrary OS commands' (CWE-502, CVSS 9.8). The ISO-27001-2022-A.8.28 gap records this as 'an unsafe-deserialization sink on a pre-auth remote-access console' whose deserialization-hygiene expectations 'were never met in the shipped product'. The NIST-800-53-SC-7 gap records that the AMC/CMC is intentionally internet-reachable for remote administration, so boundary protection alone cannot stop the request reaching the vulnerable endpoint. patch_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.28",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2020-11023": {
     "name": "JQuery Cross-Site Scripting (XSS) Vulnerability",
@@ -39804,7 +40423,40 @@
         "adequate": false,
         "gap": "Aviatrix Controller instances left reachable from the internet had no boundary protection to stop unauthenticated command injection against a cloud-network control plane."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Aviatrix Controller is a multi-cloud network control plane, and the packet's timeline is what makes a KEV-tied clock the requirement rather than a cloud-infrastructure change window: exploitation ran January 7-10 2025 and surged after a public Nuclei detection template was released, with CISA listing the flaw on 2025-01-16. For this product the control means the upgrade to the fixed build — 7.1.4191 for the 7.1 line, 7.2.4996 for 7.2.x — is driven from the KEV listing, with completion measured per instance on the version the running controller reports. patch_required_reboot is false, which means no host reboot; it does not mean the fix is live the moment an upgrade is pushed, and a controller still answering /v1/api on a pre-fix version is exposed regardless of what the deployment record says. live_patch_available is false and live_patch_notes is empty, so there is no interim in-place fix to fall back on: reaching the fixed version is the only remediation the packet records. Distinguishing test: enumerate every Aviatrix Controller instance in the organisation — including any stood up by an application team outside the central cloud-platform inventory — and produce its running version; a patch attestation covering only the controllers the platform team already tracks passes cleanly while an unlisted instance keeps an unauthenticated command-injection endpoint reachable. Precondition: this control governs the speed and completeness of the upgrade only. It says nothing about an instance that was already exploited during the window the packet records, which is a separate response path.",
+        "evidence": "Packet: CISA KEV 2025-01-16, active_exploitation confirmed, CVSS 10, RWEP 75, poc_available true. Exploited in the wild from January 7-10 2025 with a sharp surge after a public Nuclei detection template was released. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions: before 7.1.4191; 7.2.x before 7.2.4996. Cited gaps: SI-2 (exploitation surged faster than routine remediation SLAs), ISO A.8.8 (periodic vuln-review cycles far slower than the days-long window), AU-Essential-8-Patch (mass exploitation within days, driven by public tooling).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The defect sits on Aviatrix Controller's own management API: /v1/api accepts list_flightpath_destination_instances and flightpath_connection_test, and the cloud_type and src_cloud_type parameters reach an OS command with shell metacharacters unneutralized, for a caller that never authenticates. Bound to this product the control means two things. First, each /v1/api operation authorizes its caller and neutralizes parameter content before the value reaches the command, so a caller-supplied string cannot select what the controller executes — this is the property the fixed build establishes, and the control states what to verify rather than implementing it. Second, no controller is left with that API reachable from a segment with no operational need to reach it; the packet's boundary gap records instances left reachable from the internet with nothing in front of them, and the NIS2 gap records segmentation isolating the controller's management API as frequently absent in this incident. Distinguishing test: from a general workstation VLAN and from an external address, attempt to reach /v1/api on a staging controller and confirm the connection is refused before the endpoint parses anything — 'the controller is in our cloud account' is a statement about topology, not a demonstration that the management API is unreachable from untrusted callers. Precondition, and this is where the reachability half is routinely over-claimed: restricting which segments can reach /v1/api bounds who can send the request, it does not close the injection. Any host inside a permitted segment still drives the endpoint to full unauthenticated command execution, and the lever is simply unavailable where the controller API must stay reachable for normal operation. It is a holding measure for the window before the fixed build lands, not a substitute for it.",
+        "evidence": "Packet vector/affected: shell metacharacters sent to /v1/api in cloud_type for list_flightpath_destination_instances, or src_cloud_type for flightpath_connection_test, fail neutralization and yield unauthenticated OS command execution (CWE-78). Cited gaps: NIST-800-53-SC-7 ('instances left reachable from the internet had no boundary protection to stop unauthenticated command injection against a cloud-network control plane'), UK-CAF-B4 ('secure configuration guidance for cloud-network control planes did not prevent an unauthenticated OS command injection sink from being internet-reachable'), NIS2-Art21-network-security (EU operators 'needed network segmentation isolating the controller's management API, which this incident showed was frequently absent').",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This is the case the control exists for, and the packet supplies both halves: an unauthenticated pre-auth command-execution flaw on a network control-plane device, and confirmed exploitation in which threat actors deployed XMRig cryptominers and Sliver C2 backdoors for persistence. Upgrading an Aviatrix Controller to 7.1.4191 or 7.2.4996 closes the injection sink; it removes nothing an attacker installed through it, so an instance that was reachable during the January 7-10 2025 window is not remediated by the upgrade and must not be closed on the patch record. For this product the response is to export and review the controller configuration, rebuild the instance from a known-good image, and rotate the cloud credentials and role trust the controller holds — the packet records Wiz Research finding that 65% of organisations running Aviatrix Controller have a lateral-movement path from it to administrative cloud control-plane permissions, which is the blast radius a resident Sliver implant inherits. Distinguishing test: for each controller, establish whether its /v1/api was reachable from an untrusted network at any point before the upgrade; where it was, treat it as an incident rather than a patch item. Precondition: rebuild-not-patch presupposes a known-good image and a configuration export the operator trusts, and it applies to instances with exposure during the window — it is not a blanket instruction to rebuild every controller. Where a rebuild genuinely cannot be scheduled, the honest state is a compromised-until-proven-otherwise instance under monitoring with its cloud credentials rotated, not a remediated one.",
+        "evidence": "Packet active_exploitation_notes: exploited in the wild from January 7-10 2025; 'threat actors used unauthenticated command injection to deploy XMRig cryptominers and Sliver C2 backdoors for persistence'; 'Wiz Research notes 65% of organizations running Aviatrix Controller have a lateral-movement path to administrative cloud control-plane permissions'. active_exploitation confirmed; poc_available true; patch_available true (before 7.1.4191 / 7.2.x before 7.2.4996). Cited gap NIST-800-53-SI-2 treats remediation as flaw removal on a clock, which does not reach attacker-installed persistence.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-21335": {
     "name": "Microsoft Windows Hyper-V NT Kernel Integration VSP Use-After-Free Vulnerability (CVE-2025-21335)",
@@ -40102,7 +40754,39 @@
         "adequate": false,
         "gap": "EU operators relying on BeyondTrust PRA/RS as a privileged-access gateway need vendor-supply-chain risk monitoring, not just internal patch cadence, since the compromise originated at the vendor."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "BeyondTrust Privileged Remote Access and Remote Support are themselves the privileged-access control plane — the product exists so technicians reach other people's systems — and the packet's exploit precondition is an attacker who already holds administrative privileges on a PRA/RS site and uploads a crafted file the backend processes without OS-command sanitization, so commands run as the site user. Bound to this product the control means PRA/RS site administration is classified as its own privilege tier above application admin rather than collapsed into 'admin': a separate identity from any other administrative role, access only through a PAM jump host, per-session step-up, and just-in-time elevation with an approval workflow, so that holding an administrative session on the remote-support platform is a deliberately granted, time-bounded and individually attributable state instead of a standing role. What this incident adds to the tier is that it cannot enumerate human administrators only: the packet records the access arriving through a stolen BeyondTrust cloud API key used to reach 17 Remote Support SaaS tenants, so every API key carrying site-administrative capability — including keys the vendor holds against the customer's own tenant — needs a named owner, a scope, an expiry and a revocation path inside the same tier. Precondition, and it is the half this control is most often over-claimed on: jump-host routing, per-session step-up and just-in-time elevation constrain interactive administrator logons and do nothing to a machine-to-machine key presenting valid credentials to the API, because no session is ever opened for a step-up to interrupt. For that identity class the control reduces to enumeration, scoping and rotation, and a tenant that has recorded the vendor's key as simply 'vendor-managed' holds no lever at all until that key is listed as an administrative identity in its own right. Distinguishing test: produce the list of identities that can administer the PRA/RS site and confirm every non-human key on it has an owner and a revocation path — an attestation that every named BeyondTrust administrator authenticates with MFA passes cleanly while the documented access path stays open.",
+        "evidence": "Packet vector: 'A vulnerability has been discovered in Privileged Remote Access (PRA) and Remote Support (RS) which can allow an attacker with existing administrative privileges to inject commands and run as a site user.' affected: PRA and RS on-premises and SaaS deployments, where an attacker with existing administrative privileges uploads a malicious file processed without OS-command sanitization, executing commands as the site user. active_exploitation_notes: 'Exploited as a zero-day by the Chinese state-sponsored group Silk Typhoon in December 2024, chained with CVE-2024-12356 to steal a BeyondTrust API key and pivot into 17 Remote Support SaaS tenants, including the U.S. Treasury Department.' NIST-800-53-AC-6 gap: 'Least-privilege scoping alone does not stop an attacker who already holds legitimate admin credentials (via a stolen vendor API key) from injecting OS commands through the file-upload handler.' UK-CAF-B4 gap: 'Supply-chain and third-party PAM tooling assurance is insufficient when the vendor's own cloud API key can be silently compromised and used to reach customer tenants.'",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive on this entry is OS command execution as the site user on a remote-support server, reached by uploading a file the backend processes without neutralizing embedded command sequences — so the exposed asset is the whole PRA/RS installation and everything it stores and hands out: session artifacts, technician-facing client downloads, and the site's own service configuration. Treat that content as a privileged distribution channel rather than as application data: file-integrity-monitor the PRA/RS installation and every directory from which it serves artifacts, alert on writes that do not reconcile to a recorded, approved administrator change or a vendor update, and hold the support server to KEV-priority patching as a management-plane asset in its own right. That patching half is concrete here rather than generic: the packet records the December 2024 fix in BT24-11 with all cloud instances patched by 2024-12-16 while self-hosted instances required manual patching, so a self-hosted site is remediated only by an operator action someone has to schedule, and an estate that read the vendor's cloud-side completion as its own is unpatched. This is also the control that still carries value after that fix lands, because the fix closes the injection path and removes nothing that was written or executed through it during the zero-day window. Precondition, and it decides whether the monitoring is worth anything on this product: the upload arrives inside an authenticated administrative session, so the presence of an administrator login is not evidence the write was sanctioned — the alert only distinguishes attacker activity when it is reconciled against change records, and a site with no change record to reconcile against produces an alert it cannot adjudicate. On remediation status, the packet registers no live-patch path, and its host-reboot flag says nothing about the service being restarted onto the fix, so completion is measured on the version the running PRA/RS site reports rather than on the update having been applied.",
+        "evidence": "Packet: CWE-78; CVSS 6.6; RWEP 50; poc_available false; active_exploitation confirmed; cisa_kev true with kev_date 2025-01-13. attack_vector: the attacker 'uploads a specially crafted file through the admin console; the backend fails to neutralize embedded OS command sequences, so the commands execute with the privileges of the site user.' affected_versions: 'RS/PRA 22.1.x and later prior to the December 2024 fix in BT24-11 (all cloud instances patched by 2024-12-16; self-hosted instances required manual patching)'. patch_available true; live_patch_available false; live_patch_notes null; patch_required_reboot false. NIST-800-53-SI-2 gap: 'This flaw was exploited as a zero-day by a nation-state actor before a patch existed, so patch-SLA-based remediation could not have prevented the initial Treasury compromise.' ISO-27001-2022-A.8.16 gap: 'Monitoring keyed to failed-auth and anomalous logins does not flag command injection issued through a legitimately-authenticated session riding a stolen vendor API key, so A.8.16 telemetry read the Treasury intrusion as normal privileged use.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.16",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "A Remote Support / Privileged Remote Access site is a fleet control plane in the exact sense this control means — it holds standing access into every system its technicians support — and the packet documents the compromise propagating along that shape: a stolen BeyondTrust cloud API key reaching 17 Remote Support SaaS tenants, including the U.S. Treasury Department. Written in this product's terms and before it is needed, the playbook is: revoke and reissue every API key and site credential on notification of a vendor-side or tenant-side compromise; enumerate the support sessions, jump items and file transfers the site recorded across the suspected exposure window; rotate credentials for every account a technician used through the platform in that window, because those credentials transited a system on which an attacker was running commands as the site user; and fix quarantine criteria for the downstream endpoints that had a session in the window rather than negotiating them under time pressure. The trigger matters as much as the content here. The packet's compromise originated at the vendor and arrived at customers through a legitimately issued key, so the playbook has to be startable from a vendor advisory or a tenant notification and not only from the customer's own alerting — the customer-side telemetry, as the monitoring gap on this entry records, read the activity as normal privileged use. Precondition: this control bounds the damage of an intrusion that has already happened. It neither detects the command injection nor prevents it, and the rotation step is only complete if it covers the vendor-held key alongside the customer's own credentials — a rotation that reissues site passwords while leaving the vendor's cloud key in place leaves the documented access path intact.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited as a zero-day by the Chinese state-sponsored group Silk Typhoon in December 2024, chained with CVE-2024-12356 to steal a BeyondTrust API key and pivot into 17 Remote Support SaaS tenants, including the U.S. Treasury Department. Ransomware status is unflagged in KEV for this entry.' affected: PRA and RS on-premises and SaaS deployments; commands execute as the site user. AU-Essential-8-Patch gap: 'Application patching alone does not address a vendor-side API key compromise; requires companion API-key rotation and access-anomaly monitoring.' NIS2-Art21-vulnerability-management gap: 'EU operators relying on BeyondTrust PRA/RS as a privileged-access gateway need vendor-supply-chain risk monitoring, not just internal patch cadence, since the compromise originated at the vendor.' ISO-27001-2022-A.8.16 gap records that the customer-side telemetry 'read the Treasury intrusion as normal privileged use'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-48365": {
     "name": "Qlik Sense HTTP Tunneling Vulnerability",
@@ -40217,7 +40901,30 @@
         "adequate": false,
         "gap": "EU operators of MiCollab UC platforms need to treat chained low/critical CVE pairs as a single high-severity remediation item, not two independent low-priority tickets."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Every prioritization mechanism the citing gaps name would put this Mitel MiCollab fix near the bottom of the queue: cvss is 2.7, the packet's own vector caps the impact at reading non-sensitive system information with no modification and no privilege escalation, and the appliance is a telephony box rather than a tracked application server. The packet also records rwep_score 60, a CISA KEV listing on 2025-01-07 with a ransomware association, and live exploitation chained with CVE-2024-41713 against internet-facing MiCollab servers around the December 2024 disclosure window. Applied here, the control means the KEV listing sets the clock and the CVSS band does not enter the decision — the MiCollab update is driven across every instance from the 2025-01-07 listing, and the queue position is not recomputed downward when someone notices the score. The population to enumerate is every MiCollab server, with the internet-reachable ones first, because that is the population the packet says was actually exploited. The remediation target has to be resolved per install rather than by range arithmetic: the packet gives affected as 'through 9.8 SP2' and full mitigation as '9.8.2.12 / 9.8 SP2 and later', so the build the appliance reports must be checked against the vendor advisory for that exact release. patch_required_reboot is false, so the packet records no host reboot — but live_patch_available is false, so nothing fixes a running MiCollab instance short of taking it through the update, and completion is measured on the build the appliance reports afterwards rather than on the maintenance record. Treat this as one remediation item with its chain partner rather than as an isolated low-severity ticket; the packet describes the two being used together, and closing only the higher-scoring half leaves the chain's other step in place.",
+        "evidence": "Packet: name 'Mitel MiCollab Path Traversal Vulnerability (CVE-2024-55550)'; cisa_kev true, kev_date 2025-01-07, active_exploitation 'confirmed'; cvss 2.7 against rwep_score 60; poc_available true; active_exploitation_notes 'Chained with CVE-2024-41713 in live exploitation against internet-facing MiCollab servers around the December 2024 disclosure window. CISA KEV flags a ransomware association for this entry.'; affected_versions 'Mitel MiCollab through 9.8 SP2 (fully mitigated only in 9.8.2.12 / 9.8 SP2 and later)'; patch_available true, patch_required_reboot false, live_patch_available false; AU-Essential-8-Patch gap 'Patch prioritization by CVSS score alone would deprioritize this fix relative to its actual exploitation risk when chained'; NIS2-Art21-vulnerability-management gap 'EU operators of MiCollab UC platforms need to treat chained low/critical CVE pairs as a single high-severity remediation item, not two independent low-priority tickets.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this entry the paper-compliance failure happens twice, and the packet supplies both. First, coverage: the technical-vulnerability inventory classifies the MiCollab UC appliance as a low-risk telephony box, so it is not in the scanned estate at all — and a vulnerability report containing no MiCollab row reads identically to one showing MiCollab clean. The operational test is to confirm the appliance appears as a scanned asset with a reported build, before any conclusion is drawn from the absence of a finding; on a telephony platform this usually means the scan has to reach the admin console rather than only the SIP and media services that a network sweep discovers. Second, version resolution: the packet's own strings place the same release on both sides — affected 'through 9.8 SP2', fully mitigated in '9.8.2.12 / 9.8 SP2 and later' — so a check that compares a reported version against 'SP2' can return affected and fixed for one install, and either answer looks authoritative in a report. The check must resolve the exact build the appliance reports against the vendor advisory for this CVE rather than performing a range comparison on a service-pack label. Third, and this is what makes it a compliance-theater test rather than a scan-hygiene one: confirm the recorded severity for this asset reflects the KEV listing rather than the 2.7 score, because an inventory that carries the appliance, resolves the build correctly, and then files the finding as low-priority has produced a clean-looking programme while leaving the exploited path open. Precondition: this verifies that the estate can see and correctly classify the flaw; it removes nothing on its own — the vendor update does that.",
+        "evidence": "Packet: ISO-27001-2022-A.8.8 gap 'Technical-vulnerability inventories classify the MiCollab UC appliance as a low-risk telephony box, so its admin-readable traversal — the file-read half of a chain completed by the unauthenticated CVE-2024-41713 — goes untracked and unpatched'; UK-CAF-B4 gap 'Vulnerability management processes scoring this CVE alone as low severity (CVSS 2.7) understate its real-world impact when chained with CVE-2024-41713'; affected_versions 'Mitel MiCollab through 9.8 SP2 (fully mitigated only in 9.8.2.12 / 9.8 SP2 and later)'; affected 'Mitel MiCollab admin console — an authenticated administrative attacker can read local files outside the intended admin-access scope due to insufficient input sanitization on a file-read parameter'; cisa_kev true with kev_date 2025-01-07; cvss 2.7.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-41713": {
     "name": "Mitel MiCollab Path Traversal Vulnerability (CVE-2024-41713)",
@@ -40259,7 +40966,31 @@
         "adequate": false,
         "gap": "EU operators of MiCollab as unified-communications infrastructure need emergency out-of-cycle patch processes for unauthenticated critical flaws, not standard change-management timelines."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The interval this control has to compress on MiCollab is the one the packet measures: watchTowr's disclosure in December 2024, active exploitation of internet-facing NuPoint Unified Messaging endpoints within days of it, and the KEV listing on 2025-01-07 — days, against the change-management cycle a unified-communications platform is normally patched on, which is what this entry's flaw-remediation, internet-facing-patching and vulnerability-handling gaps each record. Applied here the requirement is an out-of-cycle emergency window rather than the next UC maintenance slot, and the population is every instance publishing the NuPoint Unified Messaging component, not only the one the asset register lists as the UC platform. The packet gives the vulnerable range as the NPM component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) and does not name a fixed build, so the target level has to be taken from the vendor advisory for the deployed release rather than assumed. patch_required_reboot is false, meaning no host reboot — not that the fixed code is live: live_patch_available is false and no live-patch path is recorded, so an instance counts as remediated only once the running NuPoint service is executing the fixed build. Priority follows the packet rather than the CVSS band alone — a public proof-of-concept, confirmed exploitation, a KEV ransomware association, and the packet's note that this traversal is frequently chained with CVE-2024-55550 make it a chain-entry item rather than a standalone UC patch ticket. And the update is not the whole of remediation: an instance that was internet-facing while the exploit was public has already had provisioning and configuration data read by an unauthenticated caller, and applying the fix closes the path without recalling what was taken, so material held there needs rotation rather than being closed on the patch record.",
+        "evidence": "Packet: patch_available true; affected_versions 'NuPoint Unified Messaging (NPM) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201)' with no fixed build named; cisa_kev true with kev_date 2025-01-07; active_exploitation confirmed, notes record exploitation against internet-facing MiCollab NuPoint Unified Messaging endpoints shortly after watchTowr's December 2024 disclosure, frequent chaining with CVE-2024-55550, and a CISA KEV ransomware association; poc_available true; cvss 9.1, rwep_score 72. patch_required_reboot false, live_patch_available false, live_patch_notes null. The NIST-800-53-SI-2 gap records the disclosure-to-KEV window as days, far shorter than typical enterprise patch-SLA cycles for UC platforms; AU-ISM-1546 records exploitation within days of disclosure. The vector states the exploit allows an attacker to view, corrupt, or delete users' data and system configurations.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-ISM-1546",
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The path-sanitization boundary in front of MiCollab's NuPoint Unified Messaging component is where the product makes its access decision for everything behind it, and this CVE is that boundary failing: the packet has an unauthenticated caller sending a novel '..;/' sequence the sanitizer does not recognise, escaping the intended directory scope to reach internal AXIS2 SOAP services and read provisioning and configuration data or trigger limited administrative actions. Bound to this product, the control means those internal services — the AXIS2 SOAP endpoints and each administrative function reachable through them — authorize their own caller before acting rather than inheriting a verdict from the front-end path scoping, so that defeating the sanitizer yields a reachable endpoint instead of an executed administrative action; and that the NuPoint Unified Messaging component is not published to unauthenticated internet traffic, which this entry's own system-security gap names as the root cause. Distinguishing test: from an unauthenticated position outside the deployment, send the traversal sequence against a staging MiCollab and confirm the internal SOAP service refuses the caller rather than answering — an instance that passes a MiCollab user-account and role review still answers this request, because the attacker never authenticates as any MiCollab user and no account model is ever consulted. Preconditions, and they are load-bearing here. The caller-side authorization is a property the vendor update establishes; this control states what to verify, it does not implement it. Restricting reachability bounds who can send the sequence but closes nothing for anything inside the permitted segment, and that lever is unavailable where NuPoint Unified Messaging must stay published for remote users — which is precisely the deployment the packet describes as the exploited population — so it is a holding measure for the days between disclosure and the fix, not a closure. And because exploitation is confirmed and this read primitive is frequently chained with CVE-2024-55550, an instance reachable while the exploit was public has already disclosed provisioning data; restricting access afterwards does not recall it, so credentials and configuration held there need rotation.",
+        "evidence": "Packet vector: 'A vulnerability in the NuPoint Unified Messaging (NPM) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) could allow an unauthenticated attacker to conduct a path traversal attack, due to insufficient input validation.' attack_vector: an unauthenticated attacker sends a request containing a novel '..;/' traversal bypass to the NuPoint Unified Messaging endpoint, escaping the intended directory scope to reach internal AXIS2 SOAP services and read provisioning/configuration data or trigger limited administrative actions. The NIST-800-53-SC-7 gap states the vulnerability is itself a boundary-bypass primitive whose traversal sequence was unrecognized by the application's path-sanitization boundary, so standard boundary-protection assumptions failed to hold; the UK-CAF-B4 gap states internet exposure of the NuPoint Unified Messaging component to unauthenticated traffic is itself the root cause and that segmentation should have limited exposure regardless of patch status. poc_available true; active_exploitation confirmed and frequently chained with CVE-2024-55550.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2020-2883": {
     "name": "Oracle WebLogic Server Unspecified Vulnerability (CVE-2020-2883)",
@@ -40301,7 +41032,31 @@
         "adequate": false,
         "gap": "EU operators running WebLogic as middleware need network-layer segmentation of T3/IIOP as a standing control, independent of patch status."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "Oracle WebLogic Server's T3 and IIOP listeners are precisely the binary remoting-protocol class this control governs: non-HTTP endpoints that answer an unauthenticated peer and whose object-handling path is itself the vulnerable code, so the HTTP-tier hardening and web application firewalling most WebLogic estates are audited against never touch them. For this deployment the requirement is that T3 and IIOP accept connections only from hosts that legitimately speak them — the application tier, cluster peers and management hosts — enforced at the network layer or by the server's own connection filtering rather than inferred from 'WebLogic is internal', and that whichever of the two protocols nothing legitimately uses is not listening at all; the packet names both as attack paths, and an estate that firewalls T3 while leaving IIOP answering has moved the exploit, not removed it. Distinguishing test for this product: from a general user or workstation VLAN, and from an external address, attempt to open a T3 connection and an IIOP connection to a staging WebLogic instance — anything that answers is within reach of an exploit that needs no credential, and 'the middleware is on the internal network' is a claim about topology rather than a demonstration that the listener is unreachable. Precondition, which is the whole reason the boundary-protection gap is recorded on this entry: restricting reachability bounds who can send the serialized object and does not repair the deserialization, so any host inside the permitted segment — a compromised application server, a jump host, a workstation with a legitimate T3 need — still reaches the Coherence sink in full; and where a cluster or a legacy client genuinely requires T3 across a wider segment, the lever is unavailable and only the vendor patch remains. Because the packet records continuous cryptomining and webshell campaigns against exposed T3/IIOP interfaces, an instance that answered from an untrusted network needs examining for an already-planted webshell or miner rather than being closed on the patch record.",
+        "evidence": "Packet: affected records that an unauthenticated attacker with network access to the T3 or IIOP protocol can send a malicious serialized object deserialized by the Oracle Coherence library, resulting in full server takeover; CVSS 9.8 with vector AV:N/AC:L/PR:N/UI:N. NIST-800-53-SC-7 gap: the most effective compensating control — disabling or firewalling T3/IIOP from untrusted networks — is a boundary-protection measure, not a patch, and many affected servers left T3/IIOP internet-reachable long after patching. NIS2-Art21-network-security gap: EU operators running WebLogic as middleware need network-layer segmentation of T3/IIOP as a standing control, independent of patch status. active_exploitation_notes: exploited in the wild almost immediately after the April 2020 patch and the May 2020 public PoC release, and still targeted by opportunistic scanners and cryptomining/webshell campaigns against exposed WebLogic T3/IIOP interfaces, prompting the CISA KEV addition in January 2025. poc_available true; active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet states the divergence this control exists to test: technical vulnerability management marks the control satisfied once the April 2020 patch is recorded as applied, yet CISA added this to KEV in January 2025 — 'patched in inventory' and 'not exploitable' are different statements wherever a shadow WebLogic instance was missed. A scan that reports this closed by reading a patch level from the hosts already in the asset register is paper compliance for exactly this CVE, because the instances driving a five-year exploitation tail are the ones the register does not contain: WebLogic embedded inside a vendor product or appliance, a dev or DR clone of production, an instance stood up for a migration and never retired. The operational test that separates the two is to discover by protocol response rather than by asset record — sweep the internal estate, the cloud ranges and the external perimeter for anything answering T3 or IIOP, and for every responder establish which release it is running against the four the packet names as affected (10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0) and whether the Oracle Coherence deserialization path it is executing carries the fix. A programme that reports zero vulnerable WebLogic hosts while a T3 listener answers somewhere has measured its inventory, not its estate. Preconditions: this finds instances, it does not remediate them — each responder still needs the vendor patch, and while the packet records no host reboot as required and no live-patch path, completion has to be read from the release the running server process reports, since the process holding the listener is the one executing the vulnerable deserialization path and a patch applied on disk under a still-running server is not yet in force. And because a public PoC has existed since May 2020 and campaigns have been continuous, a newly discovered exposed instance should be triaged as potentially already compromised rather than merely unpatched.",
+        "evidence": "Packet ISO-27001-2022-A.8.8 gap: technical vulnerability management marks A.8.8 satisfied once the April-2020 patch is recorded as applied, yet KEV addition in 2025 proves 'patched in inventory' and 'not exploitable' diverge for this T3/IIOP deserialization flaw wherever a shadow WebLogic instance was missed. UK-CAF-B2 gap: asset inventories that fail to track exposed middleware protocol ports (T3/IIOP) leave legacy WebLogic deployments exploitable years after a patch exists. AU-Essential-8-Patch gap: patch-application timelines alone do not explain multi-year persistence of exploitation against a patched vulnerability — unpatched shadow/legacy instances are the likely driver. NIST-800-53-SI-2 gap: patched in April 2020 yet CISA found active in-the-wild exploitation warranting KEV addition in January 2025. affected_versions: 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. poc_available true, with the public PoC recorded as released May 2020.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B2",
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-3393": {
     "name": "Palo Alto Networks PAN-OS Malicious DNS Packet Vulnerability",
@@ -40921,7 +41676,40 @@
         "adequate": false,
         "gap": "Financial-sector file-transfer exposure via MFT appliances was not adequately tested for resilience against this exploitation chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This entry is the incomplete-patch sequence the control exists for, and the packet states it outright: the fix shipped in 5.8.0.21 was itself incomplete and was bypassed, tracked separately as CVE-2024-55956, with the products recorded fully patched only in 5.8.0.24. Applied to Cleo, the requirement has three parts. The remediation target is 5.8.0.24 or later, not the first fix — an estate that closed this CVE at 5.8.0.21 recorded remediation while the arbitrary-write path into the autorun directory stayed open through the December 2024 ransomware campaign. The scope is all three products the packet names: Harmony, VLTrader and LexiCom are each recorded affected before 5.8.0.21, so an inventory built around the Harmony servers leaves the VLTrader and LexiCom installs on the identical write path, and each must be enumerated and shown at the fixed build in its own right. And the verdict on a first fix in a sequence is 'unproven', not 'closed': the second CVE on the same primitive raises rather than lowers the expectation of a third, so a vendor's assertion that a build closes the flaw is evidence to be tested, not accepted, which is precisely what the packet's ICT-supply-chain gap says no framework requires. Completion is measured on the version the running Cleo service reports rather than on the installer having been executed. Distinguishing test: against a staging install left at 5.8.0.21, replay the unauthenticated crafted POST carrying a traversal filename at the Synchronization endpoint and confirm nothing is written into the autorun directory — a patch metric that went green at 5.8.0.21 passes every cadence attestation while the write path remains exploitable.",
+        "evidence": "affected_versions: 'Harmony before 5.8.0.21 (initial fix incomplete)', 'VLTrader before 5.8.0.21', 'LexiCom before 5.8.0.21', 'fully patched in 5.8.0.24'; the NIST-800-53-SI-2 gap states the initial fix in 5.8.0.21 was itself incomplete and was bypassed (tracked separately as CVE-2024-55956), so patch-SLA compliance alone did not close the exposure window; the AU-Essential-8-Patch gap states patch-compliance was met by applying 5.8.0.21 yet that fix was bypassable and the appliances were mass-exploited by ransomware anyway; the ISO-27001-2022-A.5.21 gap states the ICT-supply-chain control does not require validating that a vendor's fix actually closes the flaw; the UK-CAF-B4 gap states system-security lifecycle management did not catch that the patched version remained exploitable; attack_vector describes an unauthenticated crafted POST with a path-traversal filename to the Cleo Synchronization endpoint writing into the autorun directory; CVSS 9.8, RWEP 74, poc_available true, cisa_kev true (2024-12-13); patch_available true, live_patch_available false, patch_required_reboot false, live_patch_notes null.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling",
+          "ISO-27001-2022-A.5.21",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive the packet describes is an arbitrary file write that lands in the Cleo autorun directory — a directory whose contents the product executes automatically — so on Harmony, VLTrader and LexiCom the directories the server holds and acts on are a privileged execution channel, not application data, and must be monitored as one. The requirement: file-integrity monitoring on the Cleo installation and on the autorun directory in particular, alerting on any file appearing there that does not correspond to a sanctioned operator action or a vendor update, together with alerting on child processes spawned by the Cleo service. The detection has to key on that shape and no other, because the shape is all the exploit produces. An attacker doing exactly what the packet describes sends a well-formed POST, causes a file to be written, and then lets the product run it through its ordinary autorun behaviour: nothing crashes, no exploit tooling signature is present on the host, and the execution is performed by the legitimate service. A rule keyed on service crashes, on known-bad hashes, or on anomalous inbound request volume would miss it; a rule keyed on unexpected writes into autorun plus the service's subsequent child process would not. This is also the control that retains value after 5.8.0.24 lands, since the upgrade closes the write path but removes nothing already written through it. Precondition: it requires the file-integrity and process telemetry to have been collected and forwarded off the server before the drop — against an actor holding code execution on that host, an alert stream retained only on the host is not evidence, and a rule authored afterwards against telemetry nobody was collecting produces nothing.",
+        "evidence": "attack_vector: 'An unauthenticated attacker sends a crafted POST request with a path-traversal filename to the Cleo Synchronization endpoint, writing an arbitrary file into the autorun directory that Cleo executes automatically, yielding remote code execution'; affected names Cleo Harmony, VLTrader and LexiCom and records unauthenticated upload/download leading to RCE through the autorun feature; active_exploitation_notes records at least ten businesses' Cleo servers confirmed compromised via arbitrary file write leading to RCE, with activity dating to 2024-12-03 and spiking 2024-12-08; DORA-Art10 is cited on this entry as 'Detection of anomalous activities and ICT-related incidents'; patch_available true with the fully-patched level recorded as 5.8.0.24.",
+        "gap_closes": [
+          "DORA-Art10"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records confirmed compromise, not merely exposure: at least ten businesses' Cleo servers compromised via arbitrary file write leading to RCE, mass exploitation from 3 December 2024 spiking on 8 December by a Termite-affiliated ransomware actor, and a KEV entry flagged ransomware Known. Upgrading Harmony, VLTrader and LexiCom to 5.8.0.24 closes the write path and leaves intact whatever was written into the autorun directory and executed before the upgrade. So for any Cleo server that was internet-reachable while running a build at or below 5.8.0.21 during that window, the default response is exporting the configuration for review, rebuilding at 5.8.0.24, and rotating every credential configured on the server — not upgrading in place and closing the ticket on the version number. Preconditions this control must not be recorded without. The rebuild decision depends on establishing whether the server was reachable and at which build during the window; where that cannot be evidenced, it is treated as exposed rather than clean. Taking an MFT server out of service for rebuild interrupts the partner transfers it exists to perform, so the action needs a scheduled path with the transfer partners rather than being assumed free — an unscheduled rebuild requirement is the one most likely to be quietly downgraded to an in-place upgrade. And the rebuild removes server-resident persistence only: files the actor moved through the server, and any encryptor deployment that already reached hosts beyond it, are incident-response scope that rebuilding the Cleo server does not recover.",
+        "evidence": "active_exploitation confirmed; active_exploitation_notes: 'Mass-exploited from early December 2024 (activity dating to Dec 3, spiking Dec 8) by a Termite-affiliated ransomware actor; at least ten businesses' Cleo servers were confirmed compromised via arbitrary file write leading to RCE. CISA KEV flags ransomware use as Known.'; attack_vector records the arbitrary file write into the autorun directory that Cleo executes automatically; affected_versions records the products affected before 5.8.0.21 and fully patched in 5.8.0.24; the NIST-800-53-SC-7 gap records the MFT appliances as directly internet-reachable with no additional network segmentation; the NIST-800-53-SI-2 gap records that patch-SLA compliance alone did not close the exposure window; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-49138": {
     "name": "Microsoft Windows Common Log File System (CLFS) Driver Heap-Based Buffer Overflow Vulnerability",
@@ -41145,7 +41933,39 @@
         "adequate": false,
         "gap": "Network security controls did not restrict firewall management-plane access to trusted administrative networks only."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "These units are perimeter firewalls and VPN concentrators — the device is the trust boundary, which is why a standard firmware-patch window is the wrong instrument for a traversal in their web management interface that a ransomware group was already using for initial access. For this CVE the tier requirement is that within the clock opened by the 2024-12-03 KEV listing, every affected unit either runs ZLD V5.39 or has its web management interface isolated from untrusted networks until it does. Scope is all four series the packet names, at each one's own affected range — ATP V5.00 through V5.38, USG FLEX V5.00 through V5.38, USG FLEX 50(W) V5.10 through V5.38 and USG20(W)-VPN V5.10 through V5.38 — because an estate standardised on the USG20(W)-VPN or the USG FLEX 50(W) reports clean against a sweep scoped to the ATP series the summary leads with. Completion is measured on the firmware version the unit is executing: the packet records patch_required_reboot true and live_patch_available false, so a unit that has had V5.39 uploaded but has not restarted onto it is still running the traversal-vulnerable code and counts as exposed, and a management console showing the firmware as staged is not evidence of remediation. The isolation branch is the one that needs its condition stated: pulling the web management interface off the internet removes the internet-reachable path the packet identifies as the exploitation precondition, but it does not fix the traversal — any caller inside whatever segment retains access still reaches it — and it is unavailable where administrators must reach the interface remotely, in which case the permitted set is a named administrative or jump network rather than 'reduced exposure'.",
+        "evidence": "Packet affected: 'Zyxel ATP, USG FLEX, USG FLEX 50(W), and USG20(W)-VPN series firewalls running ZLD firmware; the web management interface allows directory traversal to download or upload files via a crafted URL.' affected_versions: 'ATP series V5.00-V5.38', 'USG FLEX series V5.00-V5.38', 'USG FLEX 50(W) series V5.10-V5.38', 'USG20(W)-VPN series V5.10-V5.38', 'fixed in ZLD V5.39'. cisa_kev true with kev_date 2024-12-03; active_exploitation confirmed; poc_available true; rwep_score 77; cvss 7.5; patch_available true; patch_required_reboot true; live_patch_available false. The NIST-800-53-SI-2 gap records that 'Firmware patch-SLA cadence did not close the window before Helldown began using this flaw for initial access'; the AU-Essential-8-Patch gap records that 'Patch-applications control alone does not compensate for internet-exposed firewall management planes.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet says the crafted URL both downloads and uploads files, and that Helldown affiliates used this traversal as initial access into victim networks from around November-December 2024 — before and during the period operators were still scheduling firmware. That combination is what this control exists for: upgrading an ATP, USG FLEX, USG FLEX 50(W) or USG20(W)-VPN unit to ZLD V5.39 closes the traversal, but it does not delete a file that was already written to the device and does not invalidate a credential or configuration item that was already read off it. For these firewalls the control means any unit whose web management interface was reachable from an untrusted network while it ran an affected V5.00-V5.38 build is handled as a compromise rather than as a patch item: its configuration exported for offline review before anything is changed, the unit rebuilt from a known-good image and a known-good configuration instead of upgraded in place, and every credential the device held or brokered rotated at its source — local administrator accounts, VPN and remote-access users, directory bind accounts, pre-shared keys and device certificates. Distinguishing test: instead of asking whether the unit now reports V5.39, ask its filesystem and configuration whether anything was added or altered during the window it ran an affected build, and whether each credential it held carries a rotation date later than the end of that window. Precondition, and the reason this is a branch of the incident path rather than a replacement for it: rebuilding the device removes on-device persistence only. It does not evict an attacker who already used what the traversal yielded to move into the network — the packet records ransomware deployment into victim networks as the objective — so the internal investigation proceeds regardless of what state the firewall is in.",
+        "evidence": "Packet vector: the traversal in the web management interface 'could allow an attacker to download or upload files via a crafted URL'. attack_vector: 'An attacker sends a crafted URL to the ZLD web management interface that traverses outside the intended directory scope, allowing arbitrary file download or upload — used by Helldown ransomware affiliates as initial access into victim networks.' active_exploitation_notes: 'Used as an initial-access vector by the Helldown ransomware group from around November-December 2024 to compromise internet-exposed Zyxel firewall/VPN management interfaces before deploying ransomware into victim networks. CISA KEV flags ransomware use as Known.' active_exploitation confirmed; kev_date 2024-12-03; patch_available true with fixed build ZLD V5.39; patch_required_reboot true; live_patch_available false. The ISO-27001-2022-A.8.8 gap records that 'Technical vulnerability management on firewall firmware assumes scheduled updates, but Helldown ransomware operators used this directory-traversal for initial access within the patch window, so the standard's cadence-based timescale left the internet-exposed management interface exploitable.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The management plane the packet names is the ZLD web management interface on these Zyxel firewalls, and the defect sits on it: a crafted URL escapes the intended directory scope and drives a file download or upload. Bound to this product, the control means every file-serving and file-accepting path on that interface authorizes its caller before the file operation is performed at all, and normalizes and validates the resolved path before any read or write executes, so a caller-supplied URL cannot select which file is served or overwritten; and that no ATP, USG FLEX, USG FLEX 50(W) or USG20(W)-VPN unit is left with that interface reachable from a network that has no operational need to reach it. The reachability half is the one the packet ties directly to exploitation — internet-exposed management interfaces are what Helldown affiliates compromised — so the administrative surface belongs on an administrative or jump network, with the WAN side of the management interface closed, rather than on the internet with a strong administrator password standing in for a boundary. Distinguishing test: on a staging unit, request each file path the management interface serves and submit each upload it accepts, from an unauthenticated caller on a segment with no administrative role, using a URL whose path resolves outside the intended directory, and confirm it is refused before anything is read or written. Precondition, and it is the one most often skipped: the caller authorization and path normalization are properties the vendor establishes in ZLD V5.39 — this control states what to verify, it does not implement it. Until a unit has restarted onto V5.39, restricting which segments can reach the management interface bounds who can send the crafted URL but leaves the endpoint fully exploitable to anything inside the permitted segment, and that restriction is unavailable wherever the interface must remain reachable for remote administration.",
+        "evidence": "Packet vector: 'A directory traversal vulnerability in the web management interface of Zyxel ATP series firmware versions V5.00 through V5.38, USG FLEX series firmware versions V5.00 through V5.38, USG FLEX 50(W) series firmware versions V5.10 through V5.38, and USG20(W)-VPN series firmware versions V5.10 through V5.38 could allow an attacker to download or upload files via a crafted URL.' cwe_refs CWE-22; affected_versions record the fix as 'fixed in ZLD V5.39'; patch_available true, patch_required_reboot true, live_patch_available false. The NIST-800-53-SC-7 gap records that 'Boundary protection was insufficient — the ZLD web management interface was reachable from the internet, the precondition for this exploitation chain'; the NIS2-Art21-network-security gap that 'Network security controls did not restrict firewall management-plane access to trusted administrative networks only'; the UK-CAF-B4 gap that 'System security lifecycle management allowed perimeter firewall management interfaces to remain internet-exposed.' active_exploitation_notes records Helldown compromising 'internet-exposed Zyxel firewall/VPN management interfaces'.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-45727": {
     "name": "North Grid Proself Improper Restriction of XML External Entity (XXE) Reference Vulnerability",
@@ -42043,7 +42863,31 @@
         "adequate": false,
         "gap": "Essential Eight patch-applications guidance targets prompt remediation for exploited internet-facing services; a years-old MEDIUM CVE quietly returning to active-exploitation status falls outside routine patch-cadence triage."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this Jira entry the control means the remediation clock starts at the 2024-11-12 KEV listing, not at the CVSS 5.3 band that kept the CVE off high-severity-only remediation queues for the years the fixes had already existed. The mechanics are branch-specific and this is where the SLA is usually missed on Jira: the packet gives three separate fixed builds — before 8.5.14, 8.6.0-8.13.5 fixed in 8.13.6, and 8.14.0-8.16.0 fixed in 8.16.1 — so an estate pinned to the 8.5.x line closes this by reaching 8.5.14, and 'upgrade to the newest release' is a different change with a different approval path that instances on a long-term branch will not take inside the window. Completion is measured on the build the running instance reports, per Server instance and per Data Center node, not on the installer having run: live_patch_available is false, so there is no way to close the traversal on a process that is still executing pre-fix code, and patch_required_reboot false records only that no host reboot is needed — it does not mean the fix is live before the Jira process comes up on the new build. Speed matters beyond the patch record because of what the flaw yields: the packet has the unauthenticated read used to harvest servlet-mapping and configuration detail from web.xml ahead of follow-on attacks, and that material stays useful to the attacker after the upgrade lands, so an instance that was internet-facing during the exposure window needs the disclosed configuration reviewed rather than being closed on the version alone.",
+        "evidence": "Packet fields for CVE-2021-26086: cisa_kev true with kev_date 2024-11-12, active_exploitation confirmed, poc_available true, cvss 5.3 against rwep_score 67, patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions gives the three fixed branches: before 8.5.14; 8.6.0 - 8.13.5 (fixed in 8.13.6); 8.14.0 - 8.16.0 (fixed in 8.16.1). The NIST-800-53-SI-2 gap states fixes existed years before the November 2024 KEV listing and that SI-2 SLAs commonly track vendor severity rather than active-exploitation status. active_exploitation_notes records active exploitation of unauthenticated file-read against internet-facing Jira Server/Data Center instances, used to harvest servlet-mapping and configuration detail from web.xml ahead of follow-on attacks, and that the entry is not flagged as ransomware-associated.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-074",
+        "name": "CVE-REGRESSION-WATCHER",
+        "description": "This entry is the case the watcher's trigger condition is written for, and it fires cleanly here: a CVE identifier assigned in 2021 appearing in current exploitation reporting and carrying a public proof-of-concept, three years after the fixed Jira branches shipped. What the triage must then resolve is specific to this product rather than the regression case the control was first written against — the finding is not a re-introduced defect but a Jira estate still running a pre-8.5.14, pre-8.13.6 or pre-8.16.1 branch, so the intake hit must be closed by resolving each instance's running branch against those three fixed builds rather than by checking whether the vendor shipped a fix. The distinguishing test is on the intake pipeline, not the host: replay a threat feed containing the 2024 exploitation reporting for this 2021 identifier and confirm it lands on the remediation queue. A pipeline that ingests only advisories for identifiers assigned in the current cycle, or that filters intake by CVSS band, never surfaces it at all — which is exactly how a fix that had been available for years went unapplied on internet-facing instances until CISA listed the CVE.",
+        "evidence": "Packet fields for CVE-2021-26086: the identifier is a 2021 assignment, kev_date is 2024-11-12, poc_available is true and active_exploitation is confirmed. The AU-Essential-8-Patch gap states that a years-old MEDIUM CVE quietly returning to active-exploitation status falls outside routine patch-cadence triage. The ISO-27001-2022-A.8.8 gap states that Jira's low CVSS kept it off many high-severity-only remediation queues despite the later KEV listing. affected_versions supplies the fixed branches the triage resolves against: 8.5.14, 8.13.6 and 8.16.1.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2014-2120": {
     "name": "Cisco Adaptive Security Appliance (ASA) Cross-Site Scripting (XSS) Vulnerability",
@@ -42231,7 +43075,38 @@
         "adequate": false,
         "gap": "CAF D1 response-and-recovery planning is what actually determined outcomes for the 22,000 compromised instances — patching alone doesn't undo an existing PSAUX ransomware infection."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "CyberPanel is the hosting control panel this control governs, and the packet places the defect exactly where the control forbids it: a request-reachable view, upgrademysqlstatus in databases/views.py, whose statusfile property flows into OS command execution as root, with the only thing in front of it — secMiddleware — validating the request method rather than who is making it. That is CWE-306 at the precise function performing privileged database operations. Bound to this product the control means each CyberPanel view that performs a privileged operation authorizes its own caller instead of inheriting a verdict from a middleware layer that fronts it, and the statusfile value reaches the underlying operation as data rather than as text composed into a command line. Note which cited gap this does and does not touch: the access-enforcement gap is the one it closes, and per-account privilege scoping is never consulted on this path at all, because the attacker holds no CyberPanel account — the account model an access review examines is bypassed rather than abused, so an attestation that every panel administrator authenticates at login passes cleanly while this path stays open. Distinguishing test: against a staging CyberPanel, send unauthenticated requests to /dataBases/upgrademysqlstatus carrying shell metacharacters in statusfile, including with HTTP methods other than POST, and confirm each is refused before any command runs. Precondition: the caller-side authorization is a property the fix at commit 5b08cd6 establishes — this control states what to verify, it does not implement it, and it gives nothing to an instance still running 2.3.6 or unpatched 2.3.7.",
+        "evidence": "Packet: cvss 10, rwep_score 74, poc_available true, cisa_kev true with kev_date 2024-11-07, active_exploitation confirmed, cwe_refs CWE-306. vector: 'upgrademysqlstatus in databases/views.py in CyberPanel (aka Cyber Panel) before 5b08cd6 allows remote attackers to bypass authentication and execute arbitrary commands via /dataBases/upgrademysqlstatus by bypassing secMiddleware (which is only for a POST request) and using shell metacharacters in the statusfile property, as exploited in the wild in October 2024 by PSAUX. Versions through 2.3.6 and (unpatched) 2.3.7 are affected.' The NIST-800-53-AC-3 gap records that 'secMiddleware only validated the HTTP method (POST), not caller identity — an AC-3 access-enforcement gap at the exact function performing privileged database operations.'",
+        "gap_closes": [
+          "NIST-800-53-AC-3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This entry is the case the control's premise describes — an internet-facing pre-auth path to code execution under confirmed exploitation — and it is the case where patch-in-place is demonstrably not remediation. The packet records the PSAUX ransomware operation using an automated script (ak47.py) against over 22,000 internet-facing CyberPanel instances, deploying a custom encryptor (actually.sh) and dropping ransom notes system-wide, with the KEV entry flagged ransomware: Known. Updating past 2.3.6 / unpatched 2.3.7 closes the endpoint; it removes nothing an attacker already executed as root through it. So for any instance that was reachable from an untrusted network during the exposure window the requirement is the compromise path, not the patch path: capture configuration and evidence before touching the host, rebuild from a known-good baseline rather than repairing in place, and rotate every credential the host held or that root on it could read — the panel's own administrative credentials and the database credentials it manages, since the injection sits in the database-management view and runs as root. The response-and-recovery gap on this entry states the same conclusion in framework terms: recovery planning, not patching, determined outcomes for the compromised population. Precondition and scope: this applies to instances with exposure during the window, and absence of a ransom note is not a clean bill — the packet's campaign encrypted loudly, but the same unauthenticated root primitive is equally usable quietly on a panel that administers other people's hosting. An instance that can be shown never to have been reachable from an untrusted network during the window is a patch item, not a rebuild item.",
+        "evidence": "Packet: active_exploitation confirmed; active_exploitation_notes 'Actively exploited in the wild since October 2024 by the PSAUX ransomware operation, which used an automated script (ak47.py) to compromise over 22,000 internet-facing CyberPanel instances, deploy a custom encryptor (actually.sh), and drop ransom notes system-wide. CISA flags this KEV entry as ransomware-associated (ransomware: Known).' affected: unauthenticated root remote code execution via the upgrademysqlstatus function. framework_coverage for UK-CAF-D1: 'CAF D1 response-and-recovery planning is what actually determined outcomes for the 22,000 compromised instances — patching alone doesn't undo an existing PSAUX ransomware infection.'",
+        "gap_closes": [
+          "UK-CAF-D1",
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For CyberPanel the hard part of this SLA is not applying the fix, it is finding the instances. The packet's technical-vulnerability-management gap states that CyberPanel deployments are frequently unmanaged, forgotten hosting infrastructure that missed the emergency patch before the PSAUX campaign, and the campaign reached over 22,000 internet-facing instances — so the control's requirement here begins with an enumeration step ahead of the clock: identify every CyberPanel install the organisation or its hosting tenants run, including instances stood up outside change management and instances nobody currently owns, and drive each from 2.3.6 or unpatched 2.3.7 to the fixed code on the KEV clock rather than the routine application-patch cadence. Completion is measured on the version the running CyberPanel process is serving. patch_required_reboot is false, which means no host reboot is needed — not that a process already running has picked up a replaced databases/views.py — so verify the running instance rather than the files on disk. Preconditions, both of which bound what this control can claim. An emergency SLA is only as good as the inventory it runs against; attested against a known-instance list it marks the estate compliant while the untracked hosts, which are the exposed population for this product, stay on vulnerable code. And the KEV listing of 2024-11-07 postdates the start of exploitation in October 2024, so on this entry the SLA governs the population not yet hit — for an instance already compromised the applicable path is rebuild and credential rotation, not the patch record.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-11-07, active_exploitation confirmed, poc_available true, cvss 10. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions: through 2.3.6 and 2.3.7 (unpatched). The ISO-27001-2022-A.8.8 gap records that 'CyberPanel deployments are frequently unmanaged, forgotten hosting infrastructure that missed the emergency patch before PSAUX's mass campaign'; the AU-Essential-8-Patch gap records that the Essential Eight patch-applications target for internet-facing services is far tighter than the roughly one month between disclosure and the ransomware wave that hit 22,000 instances. active_exploitation_notes places exploitation in the wild since October 2024.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-43093": {
     "name": "Android Framework Privilege Escalation Vulnerability",
@@ -42338,7 +43213,30 @@
         "adequate": false,
         "gap": "CAF B4 secure configuration explicitly expects removal of unsupported internet-facing software; the real fix here is decommissioning, not patching."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry is the case the control exists for and the packet states both halves. patch_available is true, so a build past the affected 'through 1.9.6' range exists and reaching it is available — but the packet's gaps describe an EOL, unmaintained web server that least-functionality controls should have listed as prohibited software, and the UK-CAF-B4 gap says the real fix is decommissioning rather than patching. Those facts define the requirement: on a host that must keep serving until it can be replaced, moving past 1.9.6 is an interim state; the terminal state is removal, because an unmaintained daemon is exposed not only to this traversal but to whatever is found in it next, and the packet records five years between disclosure and the 2024-11-07 KEV listing that finally forced attention. Scope to what the packet names — Nostromo nhttpd instances at or below 1.9.6 — and do not extend the removal work to other small HTTP daemons; the packet ties the traversal to the http_verify() authentication path in nhttpd on a non-chrooted instance and gives no mapping into any other server, so treating every lightweight web daemon in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. Operationally: enumerate every nhttpd instance reachable from an untrusted network with its version, put each on a dated replacement schedule onto a maintained HTTP server, and for any instance that must stay in service in the meantime take the fixed build from the project rather than assuming a version number, and remove its reachability from untrusted networks. Precondition on the interim half: the packet registers no live-patch path, so replacing the binary on disk does not change what the listening process serves — the running daemon keeps executing the old image until it is restarted, and completion is the version the listener reports, not the version on the filesystem. And because active exploitation is confirmed and the outcome is remote code execution on a non-chrooted server, a host that was exposed is not remediated by the upgrade alone: what the web-server account could reach needs triage rather than being closed on the version record.",
+        "evidence": "Packet name: 'Nostromo nhttpd Directory Traversal Vulnerability'. affected: 'Nostromo nhttpd web server; directory traversal in the http_verify() authentication function of a non-chrooted server instance allows unauthenticated remote code execution.' affected_versions: 'through 1.9.6'. cwe_refs: CWE-22. cvss 9.8, rwep_score 63, poc_available true, active_exploitation confirmed, cisa_kev true with kev_date 2024-11-07. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. The NIST-800-53-CM-7 gap: 'Least-functionality controls should have flagged an EOL, non-chrooted web server as prohibited software years before the 2024 KEV listing.' The UK-CAF-B4 gap: 'CAF B4 secure configuration explicitly expects removal of unsupported internet-facing software; the real fix here is decommissioning, not patching.' The NIS2-Art21-vulnerability-handling gap: 'requires an inventory that catches unsupported software still exposed to the internet; EOL nhttpd instances are exactly the blind spot this control targets.' The AU-Essential-8-App-Hardening gap: 'Application-hardening guidance would flag an unmaintained, non-chrooted HTTP daemon as prohibited attack surface.'",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-vulnerability-handling",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The A.8.8 gap on this entry records the paper-compliance outcome precisely: an EOL, unmaintained nhttpd instance evaded routine vulnerability-scanning cadences for five years before the KEV listing forced attention. The scans ran the whole time and reported clean — that clean report is what the ISMS recorded as conformance, and it is the artefact this control tests. For this CVE the operational test is whether the estate's scanning can name a running nhttpd at all: stand up an nhttpd instance at or below 1.9.6 on a staging host, run the exact scan profile the estate is attested with, and require the report to identify the daemon, its version, and this CVE. A scan cycle built around managed-package inventory and expected service ports produces nothing against a host serving nhttpd outside that inventory, and the absence of a finding is indistinguishable in the report from the absence of the software — which is the whole failure. Make the pass condition the positive identification, not the absence of an alert. Precondition and limit: this is a detection test, not a remediation. Finding the daemon does not remove it, and a finding that lands in a scanner queue rather than on the dated replacement schedule reproduces the five-year outcome in a different system of record. It also only covers hosts the scan can reach and is authorised to inspect; an nhttpd instance on a segment or a host outside the scan's scope is invisible to the test as well as to the scan, so scope coverage has to be demonstrated separately rather than assumed from a clean estate-wide result.",
+        "evidence": "The ISO-27001-2022-A.8.8 gap on this entry: 'A.8.8 technical vulnerability management requires ongoing visibility into internet-facing software; an EOL, unmaintained nhttpd instance evaded routine vulnerability-scanning cadences for five years before KEV listing forced attention.' Packet affected_versions: 'through 1.9.6'. affected: 'Nostromo nhttpd web server; directory traversal in the http_verify() authentication function of a non-chrooted server instance allows unauthenticated remote code execution.' cisa_kev true, kev_date 2024-11-07, active_exploitation confirmed with active_exploitation_notes citing 'ongoing internet-wide scanning and exploitation of exposed Nostromo nhttpd servers for remote code execution'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-8957": {
     "name": "PTZOptics PT30X-SDI/NDI Cameras OS Command Injection Vulnerability",
@@ -42417,7 +43315,40 @@
         "adequate": false,
         "gap": "The device relies on the presence of an HTTP Authorization header rather than server-side session validation; simply omitting the header bypasses identification and authentication entirely."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Bound to the PTZOptics PT30X-SDI/NDI camera, this means /cgi-bin/param.cgi — and every other endpoint on the camera's lighttpd-based CGI management interface that reads or writes configuration — makes its own server-side authorization decision on every request, instead of treating the presence of an HTTP Authorization header as the decision. The packet's defect is the absence of that decision in both directions: a request sent with no Authorization header is answered, returning usernames, password hashes and configuration details, and is also accepted for writes that change individual configuration values or overwrite the whole configuration file. The second half of the control is reachability: no camera's management interface should answer from a segment with no operational need to configure it, which in a broadcast or remote-production deployment means reaching the cameras through an authenticated path onto the production VLAN rather than port-forwarding the CGI interface to the internet. Scope the sweep from the packet's affected field, not from the headline brand: PT30X-SDI/NDI-xx units below firmware 6.3.40 AND the OEM-rebadged Multicam Systems SAS and SMTAV Corporation devices that share the same Hisilicon Hi3516A V600 SoC firmware — an inventory keyed on the PTZOptics name alone reports clean across a fleet bought under a rebadge while every unit still answers the same unauthenticated request. The packet records the fixed level as firmware 6.3.40 for PT30X-SDI/NDI-xx only, so the fixed level for a rebadged unit has to come from that vendor rather than be assumed to be the same string. Distinguishing test: from an untrusted segment, issue a request to /cgi-bin/param.cgi on a staging camera with no Authorization header and confirm it is refused before any value is returned or written — an attestation that every camera has an administrator password with a rotation policy passes cleanly while this path stays open, because the attacker never presents a credential for that policy to govern. Precondition: the endpoint-side authorization is a property firmware 6.3.40 establishes; this control states what to verify, it does not implement it. Until a unit is on 6.3.40 and has been restarted onto it, restricting reachability only bounds who can send the request — it leaves the endpoint fully exploitable to anything inside the permitted segment, and it is not available at all where the camera must stay internet-reachable for remote production, which the packet records as the normal deployment. And because exploitation is confirmed and the read returns usernames and password hashes, a camera that was reachable during the window is not remediated by firmware alone: its configuration has to be rebuilt from a known-good baseline rather than inherited through the update, and every credential it held rotated.",
+        "evidence": "The packet's vector states the camera does not properly enforce authentication to /cgi-bin/param.cgi when requests are sent without an HTTP Authorization header, that a remote unauthenticated attacker can leak sensitive data such as usernames, password hashes and configuration details, and that the attacker can update individual configuration values or overwrite the whole file. `affected` names PTZOptics PT30X-SDI/NDI-xx PTZ cameras and OEM-rebadged Multicam Systems SAS / SMTAV Corporation devices sharing the Hisilicon Hi3516A V600 SoC firmware, running the lighttpd-based CGI management interface prior to firmware 6.3.40; affected_versions records PT30X-SDI/NDI-xx firmware < 6.3.40. CWE-306 and CWE-287, CVSS 9.1, RWEP 86, poc_available true, active_exploitation confirmed, CISA KEV dated 2024-11-04, with GreyNoise observing active scanning and exploitation attempts against the vulnerable /cgi-bin/param.cgi endpoint shortly after disclosure. The cited boundary-protection gap records that PTZ cameras are frequently exposed directly to the internet for remote production/broadcast use, so boundary protection is the only backstop once the CGI endpoint's own auth check fails; the identity gap records that the device relies on the presence of an HTTP Authorization header rather than server-side session validation; the configuration-management gap records that /cgi-bin/param.cgi ships accepting requests with no Authorization header and that this chains to root RCE via CVE-2024-8957. patch_available is true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.8.9",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry opens with the 2024-11-04 KEV listing and the deliverable is firmware 6.3.40 running on every affected camera — not approved, not staged, running. Embedded camera fleets are the population where a KEV clock usually fails to start at all: the packet's own Essential-Eight gap records that embedded/IoT device patching is rarely covered by standard patch-management tooling, so these units are absent from the inventory the SLA is measured against and the deadline passes over an estate nobody is counting. The first action the SLA requires here is therefore enumeration — every PT30X-SDI/NDI-xx unit and every OEM-rebadged Multicam Systems SAS or SMTAV unit sharing the Hisilicon Hi3516A V600 SoC firmware, each with its running firmware version and, for a rebadged unit, a fixed-firmware level obtained from that vendor rather than assumed in either direction, since the packet publishes 6.3.40 only for the PTZOptics part number. Completion is measured per camera on the firmware the device reports after it has restarted onto it: the packet records a vendor patch requiring reboot and no live-patch path, so a camera that has taken 6.3.40 but has not been restarted is still executing the vulnerable CGI and counts as exposed. Where a rebadged unit's vendor publishes no firmware carrying the fix, there is nothing for the SLA to land against and the response is entirely the compensating half — removing that unit's management interface from any untrusted-reachable path, or removing the unit — recorded with a dated review rather than an open-ended acceptance. Priority follows the packet rather than the CVSS band alone: a public PoC, confirmed exploitation, and observed scanning against this exact endpoint within days of disclosure put this ahead of the routine firmware cycle an AV estate normally runs.",
+        "evidence": "cisa_kev true with kev_date 2024-11-04; active_exploitation confirmed; poc_available true; CVSS 9.1 and RWEP 86. active_exploitation_notes records GreyNoise observing active scanning and exploitation attempts against the vulnerable /cgi-bin/param.cgi endpoint on live-streaming PTZ cameras shortly after disclosure, and that CISA did not flag it ransomware-associated. patch_available true, patch_required_reboot true, live_patch_available false, with the fixed level recorded in the vector and affected fields as firmware 6.3.40 for PT30X-SDI/NDI-xx; `affected` additionally names OEM-rebadged Multicam Systems SAS / SMTAV Corporation devices sharing the Hisilicon Hi3516A V600 SoC firmware. The cited Essential-Eight gap states embedded/IoT device patching is rarely covered by standard patch-management tooling, delaying rollout of firmware 6.3.40 across affected fleets; the cited NIS2 vulnerability-management gap states firmware-update SLAs for embedded camera fleets routinely exceed the observed exploitation window, with active scanning beginning within days of public disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-024",
+        "name": "AI-DISCOVERY-RESPONSE-SLA",
+        "description": "This is one of the entries where the packet's ai_discovered flag is set, and the control's premise is that the flag is a scheduling input rather than trivia: a defect found by automated analysis is one an adversary's automated analysis can reach too, so the interval between disclosure and weaponisation compresses relative to a hand-found bug carrying the same CVSS. The record here is what that compression looks like — a public PoC, and scanning and exploitation attempts against /cgi-bin/param.cgi observed shortly after disclosure, well inside the firmware cycle an embedded camera fleet normally runs, which is the packet's stated NIS2 gap. Operationally the control is an intake rule: an advisory carrying an AI-discovery attribution for any device class in the estate enters the compressed-response queue at disclosure rather than waiting for a KEV listing to promote it. For this CVE the KEV listing arrived 2024-11-04 and would have been the only trigger most programmes had, while the exploitation the packet records was already under way. Preconditions and limits: this changes when the firmware work starts and nothing about what it consists of — the remediation is still 6.3.40 and the restart onto it on every PT30X-SDI/NDI-xx unit and every rebadged Multicam Systems SAS / SMTAV unit sharing the same SoC firmware — and starting earlier does not create a fixed build where a rebadging vendor has published none. It also depends on the discovery modality being present in the intake feed at all: an advisory that does not say how the bug was found cannot be triaged this way, which is the reason to capture the modality as a recorded field rather than leave it in the prose of a writeup.",
+        "evidence": "The packet sets ai_discovered true for this entry. It also records poc_available true, active_exploitation confirmed, cisa_kev true with kev_date 2024-11-04, CVSS 9.1 and RWEP 86, and active_exploitation_notes describing GreyNoise-observed active scanning and exploitation attempts against the vulnerable /cgi-bin/param.cgi endpoint shortly after disclosure. The cited NIS2 vulnerability-management gap states that firmware-update SLAs for embedded camera fleets routinely exceed the observed exploitation window because active scanning began within days of public disclosure. patch_available true, patch_required_reboot true, live_patch_available false; fixed level recorded as firmware 6.3.40 for PT30X-SDI/NDI-xx, with `affected` also naming OEM-rebadged Multicam Systems SAS / SMTAV Corporation devices on the same Hisilicon Hi3516A V600 SoC firmware.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-37383": {
     "name": "RoundCube Webmail Cross-Site Scripting (XSS) Vulnerability",
@@ -42454,7 +43385,39 @@
         "adequate": false,
         "gap": "Malicious-code/content filtering at the email gateway rarely sanitized SVG animate attributes, so the payload reached the webmail client unfiltered."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "Roundcube's HTML/SVG sanitizer is the protection mechanism here, and this CVE is a bypass of it rather than a defect elsewhere in the client: the packet locates the failure in the handling of <animate> element attributes when rendering message previews, reached by a crafted, whitespace-padded attribute the sanitizer does not strip. Applied to this product the control means that sanitizer is treated as a tested protection-mechanism class rather than an assumed property of the platform — a bypass battery re-run against every Roundcube instance on every upgrade and configuration change, carrying the historic primitives for this class including the SVG animate-attribute form this CVE used and attribute-whitespace padding, instead of a one-off confirmation that 1.5.7 / 1.6.7 rejects this one input. That is exactly what the cited gaps describe: configuration management for the input-sanitization library did not surface the animate-attribute hole until active phishing exploitation did, and the secure-configuration assurance recorded for the webmail platform assumed the sanitization was complete. Distinguishing test: deliver the SVG animate payload class to a staging Roundcube instance by email and open the message in the reading pane, confirming it renders as inert markup — an application-hardening attestation scoped to office macros and browser plugins never reaches the webmail client's sanitizer and passes cleanly while this path is open. Precondition: a regression battery finds only the primitives it contains. It does not make the sanitizer correct and will not anticipate the next attribute the parser mishandles; it bounds recurrence of a known class and gives a signal when an upgrade or a configuration change reopens one.",
+        "evidence": "Packet: vector 'Roundcube Webmail before 1.5.7 and 1.6.x before 1.6.7 allows XSS via SVG animate attributes'; affected identifies 'Roundcube Webmail's HTML/SVG sanitizer, specifically its handling of <animate> element attributes when rendering email message previews'; attack_vector describes a crafted, whitespace-padded <animate> attribute that Roundcube's HTML sanitizer fails to strip. The ISO-27001-2022-A.8.9 gap records that 'Configuration management for the input-sanitization library didn't catch the animate-attribute gap until active phishing exploitation surfaced it'; the UK-CAF-B4 gap records that secure configuration of the webmail platform assumed complete HTML/SVG sanitization; the AU-Essential-8-App-Hardening gap records that application hardening targets office macros and browser plugins, not the webmail client's HTML/SVG sanitisation.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.9",
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Rebound to Roundcube, this control's stated rationale is this CVE exactly: the malicious activity flows over a session that is already authenticated, so authentication-event logging records nothing. Roundcube per-request access logs — not just login events — must be forwarded to a collector outside the webmail host and retained long enough to reconstruct a campaign. The detection keys on what the packet documents: the payload arrives as an SVG in a message, executes when the victim opens or previews it, and injects a fake login form to harvest credentials. So the observable shape is requests issued from a user's authenticated webmail session while a specific message is being previewed that the reading pane does not otherwise generate, and above all a credential submission going somewhere other than the instance's own login endpoint, with no new authentication event anywhere in the timeline. Correlate the same message reaching multiple mailboxes, since the packet describes a campaign against an organisation rather than a single victim. Note what will not see it: nothing is installed or written to the endpoint — the payload is script inside a rendered page — so signature-based endpoint tooling has no artifact to match, and by the packet's own account the gateway content filter already failed to strip the animate attribute on the way in. The credential theft itself surfaces later as a valid login that looks like the user. Preconditions: per-request logging has to be collected and shipped off-host before the message arrives, and a rule written afterwards against telemetry nobody retained produces nothing. And detection does not prevent the harvest — it bounds it to alert-and-response time and identifies whose credentials and sessions must be invalidated.",
+        "evidence": "Packet: attack_vector states that when the victim opens or previews the message, injected JavaScript executes in their authenticated session and can inject a fake login form to harvest credentials. active_exploitation_notes: 'Exploited in June 2024 phishing campaigns (reported by Positive Technologies) targeting government organizations in the CIS region, using SVG-embedded payloads in email attachments to inject fake login forms and steal credentials.' The NIST-800-53-SI-3 gap records that 'Malicious-code/content filtering at the email gateway rarely sanitized SVG animate attributes, so the payload reached the webmail client unfiltered'; the GDPR-Art32 gap records that technical measures protecting session/credential data were undermined by the XSS-driven fake-login-form credential theft. cisa_kev true, kev_date 2024-10-24, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "GDPR-Art32"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For Roundcube the SLA has to be expressed per instance and per release line, because the packet gives two distinct fixed builds: 1.5.7 on the 1.5 line and 1.6.7 on the 1.6.x line. An estate that upgraded its 1.6 instances while a 1.5.x instance sits below 1.5.7 is still serving the vulnerable sanitizer, and a single 'Roundcube patched' entry on a vulnerability register hides that. Completion is measured on the version the running Roundcube instance is actually serving: patch_required_reboot is false, which means no host reboot is required — not that a running instance is executing the replaced sanitizer code — so verify the served version per instance rather than the package state on disk. The vulnerability-handling gap on this entry names the underlying cause of the delay: webmail platforms are deprioritised in patch cadence, which is why this needs to be on the KEV clock rather than the normal application cycle. Preconditions: the KEV listing is 2024-10-24 while the packet places exploitation in June 2024 phishing campaigns, so this SLA governs the residual population and cannot be presented as having covered the campaign window; and because the exploitation outcome recorded here is credential theft rather than server compromise, upgrading an instance that was exposed does not invalidate credentials already harvested from it — those accounts need password reset and session invalidation independently of the version record.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-10-24, active_exploitation confirmed, poc_available true, cvss 6.1, rwep_score 68. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions: '< 1.5.7' and '1.6.x < 1.6.7'. active_exploitation_notes places exploitation in June 2024 phishing campaigns targeting government organizations in the CIS region, stealing credentials via fake login forms. The NIS2-Art21-vulnerability-handling gap records that 'Webmail platforms are often deprioritized in patch cadence; the June 2024 exploitation window against government targets preceded widescale patching.'",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-20481": {
     "name": "Cisco ASA and FTD Denial-of-Service Vulnerability",
@@ -42550,7 +43513,40 @@
         "adequate": false,
         "gap": "fgfmd accepted device-registration requests presenting a self-signed certificate/serial number without verifying prior trust establishment, defeating device-level authentication entirely."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "FortiManager is the device-management gateway this control governs and fgfmd is its registration endpoint: the packet describes the daemon accepting FortiGate Manager Protocol device-registration requests without verifying the requesting device's authenticity, so an unauthenticated remote attacker presents a crafted certificate and serial number, registers a rogue device, and then drives management-protocol requests into arbitrary code or command execution on the FortiManager server. Bound to this product, the control means fgfmd decides for itself whether the registering device matches previously established trust before it processes any management-protocol request from it, rather than treating presentation of a self-signed certificate and a serial number as the trust establishment; and no FortiManager or FortiManager Cloud instance is left with its FGFM interface answering from a segment that holds none of the FortiGates it administers. This is also why the least-privilege-style attestations on this entry pass while the path stays open: the attacker never holds a FortiManager operator account, so per-account access enforcement and organizational-user authentication are never consulted. Distinguishing test: from a segment containing no managed FortiGate, present a crafted certificate and serial number to fgfmd on a staging FortiManager and confirm the registration is refused before any management request is acted on. Preconditions, and they are where this gets over-claimed. The endpoint-side verification is a property the vendor update establishes — this control states what to verify, it does not implement it, and patch_required_reboot is true with live_patch_available false, so a unit that has taken the image but has not rebooted is still running the vulnerable fgfmd and counts as exposed. Until that reboot the operator holds two partial levers. The first is the interim setting the packet records, `set fgfm-deny-unknown enable`, published for FortiManager 7.0.12+, 7.2.5+ and 7.4.3+ — a unit on 6.2.x, 6.4.x, 7.0.0 through 7.0.11, 7.2.0 through 7.2.4, or 7.6.0 is outside the builds the packet names for that setting and has no recorded interim configuration at all; and even where it applies it blocks unknown-device registration, so it neither removes a device the attacker already registered nor helps a unit compromised during the pre-disclosure zero-day window. The second is restricting which segments reach FGFM, which bounds who can attempt registration but leaves the endpoint fully exploitable to anything inside the permitted segment, and is unavailable where FGFM must stay reachable for the managed fleet to check in. The packet lists FortiManager Cloud releases among the affected versions, so Cloud tenancies belong in the same inventory as on-premises appliances; the packet records the interim setting for FortiManager builds and states no Cloud equivalent.",
+        "evidence": "Packet affected: 'Fortinet FortiManager and FortiManager Cloud fgfmd daemon, which handles FortiGate Manager Protocol (FGFM) device-registration requests without verifying the requesting device's authenticity.' attack_vector: 'An unauthenticated remote attacker registers a rogue device against the fgfmd daemon using a crafted certificate/serial number, bypassing FGFM protocol authentication, then sends crafted management-protocol requests to execute arbitrary code or commands on the FortiManager server.' NIST-800-53-IA-2 gap: 'fgfmd accepted device-registration requests presenting a self-signed certificate/serial number without verifying prior trust establishment, defeating device-level authentication entirely.' NIST-800-53-AC-3 gap: 'Access enforcement for the FGFM management protocol didn't validate device identity before granting management-plane command execution.' UK-CAF-B4 gap: 'Secure configuration guidance assumed FGFM device registration required prior trust establishment; the missing-authentication flaw broke that assumption.' ISO-27001-2022-A.8.22 gap names segregation of networks as the compensating control the flaw demands. live_patch_notes: 'Fortinet published an interim mitigation (set fgfm-deny-unknown enable) for FortiManager 7.0.12+/7.2.5+/7.4.3+ to block unknown-device registration ahead of the full patch.' affected_versions include FortiManager 7.6.0, 7.4.0-7.4.4, 7.2.0-7.2.7, 7.0.0-7.0.12, 6.4.0-6.4.14, 6.2.0-6.2.12 and FortiManager Cloud 7.4.1-7.4.4, 7.2.1-7.2.7, 7.0.1-7.0.12, 6.4.1-6.4.7. patch_available true, patch_required_reboot true, live_patch_available false. CWE-306, CVSS 9.8, RWEP 83, poc_available true, CISA KEV 2024-10-23, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.22"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "FortiManager is the fleet control plane for a FortiGate estate, and the packet states the consequence plainly: because it centrally manages fleets of FortiGate firewalls, compromise of the management plane can cascade to every managed device. That makes this the exact scenario the playbook exists for, and the exploit's first act — registering a rogue device against fgfmd — is literally a device-trust-state problem, so the playbook's trust-invalidation step is not a generic gesture here but the specific remediation. Bound to this product, the playbook must enumerate every device registered to each FortiManager and FortiManager Cloud tenancy and revoke and re-establish trust for any registration that does not correspond to a known unit; audit the configuration and policy pushed to managed FortiGates across the whole exposure window rather than since the patch; define quarantine criteria for downstream FortiGates that received a push during that window, since a rogue registration on the manager is a supply route into devices that were never themselves vulnerable; and rotate the credentials and API material held on or distributed through the manager. Precondition on the window, which is where this playbook is usually mis-scoped: the packet records exploitation in the wild both prior to and following Fortinet's disclosure, so the window opens before the 2024-10-23 KEV listing and before the operator's own patch, not at either of them — a review that starts at the patch date examines the period after the attacker had already finished. This is response work; it does not repair the missing authentication, which the vendor update and its reboot do, and a manager whose fgfmd was reachable during the window needs both.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited as a zero-day in the wild prior to and following Fortinet's disclosure; because FortiManager centrally manages fleets of FortiGate firewalls, compromise of the management plane can cascade to every managed device.' NIS2-Art21-vulnerability-handling gap: 'FortiManager centrally manages fleets of FortiGate firewalls; a missed patch window converts a single flaw into fleet-wide compromise, exceeding standard vulnerability-handling SLAs.' DORA-Art-9 gap: 'ICT third-party risk management for centralized network-management platforms didn't anticipate a preauth RCE in the management plane itself.' attack_vector describes the attacker registering a rogue device against fgfmd, then executing arbitrary code or commands on the FortiManager server. affected covers both FortiManager and FortiManager Cloud. CISA KEV 2024-10-23; active_exploitation confirmed; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records this as a zero-day exploited in the wild before Fortinet's disclosure, and the packet's own Essential Eight gap draws the conclusion the control encodes: patching alone could not prevent initial compromise, because exploitation preceded patch availability. For a FortiManager or FortiManager Cloud instance whose FGFM interface was reachable during that window, the vendor update is therefore not the finish line. The attacker's path ends in arbitrary code and command execution on the FortiManager server, and the update replaces the vulnerable fgfmd without removing anything already placed through it — including the rogue device registration itself, which survives the upgrade as configuration rather than as a file an update would overwrite. The requirement for this appliance is the default the control names: export and preserve the configuration for analysis, rebuild the unit from vendor media, restore only reviewed configuration rather than the running config wholesale, and rotate every credential and API key the appliance held or distributed, before it resumes managing the FortiGate fleet. Precondition on which units this applies to: rebuild is the default for a unit with evidence of exploitation and equally for a unit where the evidence would not exist either way, because the exposure window opened before disclosure and most operators have no telemetry covering it; a unit that can be demonstrated unreachable on FGFM for the entire window is a patch-and-reboot item rather than a rebuild item, and that demonstration is a positive finding about reachability, not an assumption from topology. patch_required_reboot is true and live_patch_available is false, so the reboot is part of the remediation on every unit either way — an image staged but not rebooted onto is still the vulnerable build.",
+        "evidence": "Packet AU-Essential-8-Patch gap: 'Zero-day exploitation preceded patch availability, so patching alone couldn't prevent initial compromise; the fgfm-deny-unknown workaround required separate, deliberate deployment.' active_exploitation_notes: 'Exploited as a zero-day in the wild prior to and following Fortinet's disclosure.' attack_vector ends in 'execute arbitrary code or commands on the FortiManager server' after the attacker 'registers a rogue device against the fgfmd daemon'. patch_available true, patch_required_reboot true, live_patch_available false; live_patch_notes records the interim `set fgfm-deny-unknown enable` mitigation for FortiManager 7.0.12+/7.2.5+/7.4.3+ ahead of the full patch. CISA KEV 2024-10-23, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 83.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-38094": {
     "name": "Microsoft SharePoint Deserialization Vulnerability",
@@ -42661,7 +43657,40 @@
         "adequate": false,
         "gap": "Backup servers are frequently granted broad domain-trust/administrative reach; least-privilege segmentation wasn't enforced, letting a single RCE cascade into domain and backup-destruction access."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "The sink on this product is specific and the packet locates it: Veeam.Backup.MountService, reachable on the Veeam Backup & Replication server's backend service on TCP/8000, deserializing untrusted .NET objects with no credential presented. Applied to this deployment, the control means that port answers only from the backup-administration segment and the hosts Veeam has an operational need to speak to — not from the general user VLAN, and not from the internet. It also means constraining the server's outbound path, because the packet records rclone-based exfiltration from this same access, and a backup server that can reach arbitrary destinations is a server that can carry the entire protected data set out. The precondition is where this control is most often over-claimed on this CVE, and the packet states it outright: the affiliates typically chained the RCE with compromised VPN credentials to gain initial network access first. So an isolation policy that admits the general remote-access client pool into the backup segment does not bound this at all — the attacker satisfies the reachability precondition in full before sending the request, using credentials that belong to a legitimate user. Isolation has to exclude the ordinary VPN pool, with administrative reach to Veeam coming through a separately controlled path; where that separation is not in place, this control is not a mitigation for this CVE and should not be recorded as one. Distinguishing test for this product: from the general user VLAN and from a standard remote-access VPN session, attempt to open TCP/8000 on a staging Veeam Backup & Replication server — anything that answers is within reach of the published technique, and poc_available is true. This bounds who can present the payload; it does not repair the deserialization sink, which only the vendor upgrade does.",
+        "evidence": "Packet: affected 'Veeam Backup & Replication server component (Veeam.Backup.MountService) deserialization of untrusted data reachable via the backend service on TCP/8000'; attack_vector 'An attacker who has gained network access (commonly via compromised VPN credentials) sends a crafted request to the Veeam.Backup.MountService on TCP/8000 ... ransomware affiliates chained this with local-account creation and rclone-based exfiltration before deploying ransomware'; UK-CAF-B4 gap 'Secure configuration baselines for backup servers didn't isolate the Veeam management service (TCP/8000, the deserialization-reachable endpoint) from general network reachability'; NIST-800-53-AC-6 gap 'Backup servers are frequently granted broad domain-trust/administrative reach; least-privilege segmentation wasn't enforced'; poc_available true; cvss 9.8; cwe_refs CWE-502.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "What failed on this CVE was not the availability of a fix but the priority the backup tier was given: the packet records the patch as 12.2 in September 2024, roughly six weeks ahead of the observed Akira and Fog exploitation, with many organizations still not having patched backup infrastructure by that campaign window. Applied to this product, the control means any Veeam Backup & Replication server at 12.1.2.172 or earlier is driven on the clock that opened with the 2024-10-17 KEV listing, on the tier an internet-facing service would get, rather than riding the change window that backup and recovery infrastructure normally sits in — which is the window that produced the six-week gap. The population to enumerate is every Veeam Backup & Replication server including the ones outside the primary datacentre inventory, since a backup server that no one lists is a backup server no one patches. On the restart question the packet is specific and easy to misread: patch_required_reboot is false, so no host reboot is recorded — but the vulnerable code runs inside the Veeam.Backup.MountService process, and live_patch_available is false, so nothing fixes that service while it keeps running. Completion is therefore measured on the build the running Veeam backup services report after the upgrade, not on the upgrade package having been staged or the installer having been launched. Priority also should not be taken from severity banding alone: the packet's exploitation window opened within days of the public technical write-up, which is shorter than any routine cycle.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-10-17, active_exploitation 'confirmed'; affected_versions '12.1.2.172 and earlier'; NIST-800-53-SI-2 gap 'The patch (12.2, September 2024) predated in-the-wild ransomware exploitation by roughly six weeks, but many organizations had not yet patched backup infrastructure by the observed Akira/Fog campaign window'; active_exploitation_notes 'Exploited at scale by Akira and Fog ransomware affiliates within days of watchTowr Labs' public technical write-up'; patch_available true, patch_required_reboot false, live_patch_available false; AU-Essential-8-Patch gap 'Rapid patching of VPN/network-reachable backup software wasn't achieved within the Essential Eight target timeframe given the compressed time-to-exploitation after PoC release.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Scope this honestly: the Veeam Backup & Replication server is not a perimeter device — the packet places the attacker inside the network first, commonly with compromised VPN credentials — but the trigger condition this control exists for is met exactly, an unauthenticated remote code execution under confirmed in-the-wild exploitation. What the packet then names is precisely what an upgrade does not undo: affiliates created local accounts on the compromised server and staged rclone-based exfiltration before deploying ransomware. Upgrading such a server from 12.1.2.172 to the fixed build closes the deserialization sink and leaves every account, credential and artifact placed through it in service. So for any Veeam server whose TCP/8000 service was reachable from a segment an attacker could occupy during the exposure window, the default response is to capture the configuration, rebuild the server from a known-good baseline rather than inherit its state through the upgrade, enumerate and remove local accounts not accounted for by change records, and rotate every credential the server held or that transited it — which on a backup server means the service accounts carrying its domain and hypervisor reach, not only the console logins. This is also the control that answers what the backup tier is actually for: a recovery mechanism run from a host the attacker owned is not a recovery mechanism, so the runbook has to be rehearsed against the case where the backup infrastructure is the compromised asset rather than the tool used to recover from compromise. Precondition: this is an incident-response requirement, not a preventive one — it applies only to servers assessed as having been reachable during the window, and it does nothing to protect a server that has not yet been upgraded.",
+        "evidence": "Packet: attack_vector 'ransomware affiliates chained this with local-account creation and rclone-based exfiltration before deploying ransomware'; active_exploitation 'confirmed'; active_exploitation_notes 'Exploited at scale by Akira and Fog ransomware affiliates ... typically chained with compromised VPN credentials to gain initial network access before exploiting the Veeam RCE for domain/backup-infrastructure compromise'; vector 'A deserialization of untrusted data vulnerability with a malicious payload can allow an unauthenticated remote code execution (RCE)'; ISO-27001-2022-A.8.13 gap 'this unauthenticated deserialization RCE makes the backup infrastructure itself the entry point that Akira/Fog crews used to destroy recovery capability'; DORA-Art10 gap 'ICT resilience testing didn't validate that backup infrastructure itself could become the ransomware entry point rather than the recovery mechanism.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.13",
+          "DORA-Art10"
+        ]
+      }
+    ]
   },
   "CVE-2024-9680": {
     "name": "Mozilla Firefox Use-After-Free Vulnerability",
@@ -43233,7 +44262,31 @@
         "adequate": false,
         "gap": "OEM/carrier patch propagation for Android chipset firmware routinely lags the Qualcomm bulletin by months, leaving a long exploitation window for exactly this class of targeted attack."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The gaps on this entry reduce to one operational fact: the fix is in Qualcomm chipset firmware and reaches a handset only when its OEM and carrier ship it, which the SI-2 gap records as routinely lagging the Qualcomm bulletin by months and the Essential-Eight gap records as making a 48-hour patch target unenforceable. No management console can install a build the OEM has not released, so the enforceable half of this control is the access-condition half: enumerate the issued Android fleet by SoC and by the security-patch level each device actually reports, and make the October 2024 bulletin level a condition of access to mail, VPN and document stores rather than a column on a compliance dashboard. A handset below the line keeps working as a phone and loses the organisation's data — that is the only lever the operator holds while the OEM queue runs. Scope the enumeration from the affected fields rather than from one handset vendor: the packet records the scope as multiple Qualcomm chipsets' DSP Services component and gives affected versions only as the chipsets covered by the October 2024 security bulletin, with the full SoC and DSP-driver list in the vendor advisory, so a sweep keyed on a single OEM's handsets reports clean across a fleet built by another OEM on the same SoC. Distinguishing test: enrol a device whose reported patch level is below the bulletin 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 mailbox has recorded the exposure rather than removed it. Preconditions: patch_required_reboot is true with no live-patch path, so a handset that downloaded the OEM update but has not restarted onto it is still executing the vulnerable DSP code and must be counted below the line; and this control does not touch the exploitation path the packet describes — a handset physically seized and unlocked with forensic tooling is outside the operator's control at the moment of attack, so the access condition limits what a returned device can reach, it does not prevent the escalation.",
+        "evidence": "Packet fields: cwe_refs CWE-416; affected records multiple Qualcomm chipsets' DSP Services component mismanaging memory maps of HLOS memory, causing a use-after-free exploitable for local privilege escalation; affected_versions 'Qualcomm chipsets covered by the October 2024 security bulletin — see vendor advisory for the full SoC/DSP-driver list'; cisa_kev true, kev_date 2024-10-08; active_exploitation confirmed; poc_available false; cvss 7.8, rwep_score 55; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. The NIST-800-53-SI-2 gap states OEM/carrier patch propagation for Android chipset firmware routinely lags the Qualcomm bulletin by months; the AU-Essential-8-Patch gap states the 48-hour guidance is unenforceable for OEM-gated chipset firmware shipping on a multi-month cadence; the ISO-27001-2022-A.8.8 gap states this DSP-Services use-after-free escalates below the MDM and OS layer inside the Qualcomm chipset.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet's exploitation notes give this entry a trigger most mobile incident plans do not carry: the escalation was chained after physical access — Cellebrite forensic-extraction tooling used to unlock seized Android devices, then this Qualcomm DSP use-after-free used to escalate privilege and install NoviSpy spyware on journalists' and activists' handsets, per the Amnesty International Security Lab reporting the packet cites. The NIS2 gap names the missing control outright: entities issuing Qualcomm-based devices to at-risk personnel had no compensating control once a device left custody. This playbook is what fills it — loss of custody (seizure, border inspection, repair, or any interval the holder cannot account for) is declared a compromise event for that handset, with its device-trust state invalidated, its certificates and enrolment revoked, every credential it held or that authenticated through it rotated, and the handset quarantined from the fleet rather than silently re-enrolled. The handset itself goes to off-device forensic examination and is replaced rather than returned on the strength of looking normal, which is also the honest answer to the malicious-code-protection gap recorded here: on-device protection does not observe DSP-level memory-map corruption, so no scan clears the handset and the trust decision has to be made off it. It is likewise the answer to the device-hardening gap, whose configuration baselines assume the attacker never holds the hardware. Preconditions: this is a pre-arranged playbook or it is nothing — the cohort it protects must be identified and briefed on what to report before a seizure, not after; and it is a response control, bounding what a compromised handset reaches once custody is lost rather than preventing an escalation that happens on hardware the operator no longer holds.",
+        "evidence": "Packet fields: active_exploitation confirmed, with active_exploitation_notes recording exploitation as part of a targeted spyware chain in which Serbian authorities used Cellebrite forensic-extraction tooling to unlock seized Android devices, then chained this Qualcomm DSP use-after-free for privilege escalation to install the 'NoviSpy' spyware against journalists and activists (Amnesty International Security Lab, Dec 2024), not flagged as ransomware; poc_available false; cisa_kev true, kev_date 2024-10-08. The NIS2-Art21-vulnerability-management gap states entities issuing Qualcomm-based devices to at-risk personnel had no compensating control once a device left custody (e.g. lawful seizure) pending OEM patch rollout; the UK-CAF-B4 gap states device configuration/hardening baselines do not address firmware-level chipset flaws exploited during physical forensic-extraction access; the NIST-800-53-SI-3 gap states mobile endpoint protection rarely inspects DSP/kernel-level memory-map handling, so this class of use-after-free is invisible to conventional malware detection.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4",
+          "NIST-800-53-SI-3"
+        ]
+      }
+    ]
   },
   "CVE-2024-45519": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Command Execution Vulnerability",
@@ -43450,7 +44503,39 @@
         "adequate": false,
         "gap": "SAP shipped a fix in 2019, but KEV addition in 2024 shows five years of unpatched exposure among internet-facing instances — patch-SLA enforcement failed long-term, not just at disclosure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-133",
+        "name": "ECOMMERCE-PLATFORM-EXTENSION-UNTRUSTED-DESERIALIZATION-GUARD",
+        "description": "SAP Commerce Cloud (formerly Hybris) is the e-commerce platform this control governs, and the packet places the sink where the control says to look: not in core storefront code but in the platform's extensions — the packet's affected field names both the mediaconversion and virtualjdbc extensions, while the vector text mentions only virtualjdbc, so a review scoped to the vector's headline extension leaves the other one live. For this deployment the requirement is that neither extension passes request-supplied data to Java deserialization on any path an untrusted caller can reach, and that the patch and asset programmes enumerate the enabled extension set of each Commerce Cloud node as part of its code-execution surface rather than recording only the platform release. That enumeration is the load-bearing half here: exploitation yields arbitrary code execution with the 'Hybris' OS user's rights, so the blast radius is the application account that owns the storefront's data and integrations, and an inventory that lists 'SAP Commerce Cloud 1811' without listing which extensions that node loads cannot tell an assessor whether the vulnerable code is deployed. Distinguishing test: on a staging node of each affected release in the estate (6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905), send a crafted serialized gadget-chain object to each interface the virtualjdbc and mediaconversion extensions expose, from a caller with no credentials, and confirm it is rejected before any deserialization runs — a paper attestation that the platform is patched, taken from a release banner while the extension set is never enumerated, passes cleanly while the object-injection sink stays reachable. Remediation is the SAP fix for the affected release, which the packet records as available; completion is measured on the extension code the running platform process is serving, since patch_required_reboot false records only that the host needs no reboot, not that a rebuilt artifact on disk is what the live process has loaded.",
+        "evidence": "Packet affected: 'SAP Commerce Cloud (formerly Hybris), mediaconversion and virtualjdbc extensions, vulnerable to unsafe Java deserialization enabling arbitrary code execution with \"Hybris\" OS user rights.' affected_versions: 6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905. cwe_refs CWE-502; cvss 9.8; rwep_score 70; poc_available true; cisa_kev true with kev_date 2024-09-30; active_exploitation confirmed. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. The ISO-27001-2022-A.8.8 gap records that 'Technical vulnerability management (asset + patch tracking) failed to catch a five-year-old vendor-patched flaw still present in production Commerce Cloud deployments'; the AU-Essential-8-Patch gap records that 'Essential Eight patch-application maturity presumes an asset inventory tracking the virtualjdbc extension that long-tail Commerce Cloud deployments plainly lacked.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The packet's attack vector puts this CVE squarely in the binary remoting-protocol class this control governs: the virtualjdbc extension exposes Java serialization over HTTP, RMI and JMXMP, the listener answers a caller that never authenticates, and the deserializer behind it is the vulnerable code — so a storefront WAF, TLS termination and web-tier hardening, which is what a Commerce Cloud deployment is usually audited against, never sit in front of the path that gets exploited. For this deployment the requirement is that the virtualjdbc and mediaconversion listeners accept connections only from the hosts that legitimately speak those protocols — the application-tier nodes and the administrative or integration hosts that actually use them — enforced by network ACL or host firewall rather than inferred from 'the Hybris cluster is internal', and that where an extension is not required by the deployment it is removed from the enabled extension set rather than left listening. Distinguishing test for this product: from a general user VLAN or an internet-facing segment against a staging node, open a connection to each RMI/JMXMP/HTTP serialization endpoint the two extensions expose and confirm the peer is dropped before the node reads any serialized content — an estate that passes storefront penetration tests and Commerce Cloud role audits while leaving the serialization listener reachable from any internal segment is still exposed to the unauthenticated gadget-chain path. Precondition, which is where this control is most often over-claimed: restricting reachability bounds who can send the payload, it does not remove the deserialization sink. Any host inside the permitted set still reaches it, so this is interim to applying the SAP fix on the affected release — and it is unavailable where an integration genuinely requires the listener to answer, in which case the permitted set is the named integration hosts and nothing else.",
+        "evidence": "Packet attack_vector: 'SAP Commerce Cloud's virtualjdbc extension exposes Java serialization over HTTP/RMI/JMXMP; an attacker sends a crafted gadget-chain serialized payload directly to the exposed listener to achieve remote code execution as the \"Hybris\" OS user.' The vector text records the flaw as 'unsafe deserialization used in SAP Commerce Cloud (virtualjdbc extension), versions 6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905', and affected additionally names the mediaconversion extension. The NIST-800-53-SC-7 gap records that 'The virtualjdbc/JMXMP listener should never be reachable from untrusted networks, yet exploitation presumes direct network access to it — boundary protection was not enforced'; the UK-CAF-B4 gap records that 'Secure configuration guidance should have disabled or firewalled the legacy virtualjdbc extension where unused; long-tail exposure suggests this was not audited.' cvss 9.8, poc_available true, active_exploitation confirmed, patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "What the packet documents is not a patch decision that went wrong but five years in which nobody's tooling reported the exposure: SAP shipped the fix in 2019 and the entry reached KEV in September 2024 against internet-facing Commerce Cloud instances that were never patched. For this CVE the control means a scan result of 'patched' derived from the Commerce Cloud platform release banner is paper compliance, because the vulnerable code lives in the virtualjdbc and mediaconversion extensions and exposure is decided by two facts a banner cannot carry — whether those extensions are in the node's enabled extension set, and whether their Java serialization listener answers from a segment the node should not be answering. The operational test has both parts: an authenticated inventory of the enabled extension set on every Commerce Cloud node, compared against the affected releases the packet names (6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905) and against the version of the extension code the running platform process is actually serving rather than the artifact sitting on disk; and an unauthenticated reachability probe of the HTTP/RMI/JMXMP serialization listener from outside the application tier. A node that passes on its release string while the extension is loaded and the listener answers counts as unverified, not as compliant. This is also the test that distinguishes an asset register from an inventory: the packet's own gap describes long-lived deployments that no patch-verification process ever saw, and a scanner that cannot reach or authenticate to the Hybris node will report the same clean result for a node that does not exist, a node that is patched, and a node that has been exploitable since 2019.",
+        "evidence": "Packet active_exploitation_notes: 'An aged (2019) flaw added to CISA KEV in September 2024, indicating renewed/ongoing active exploitation against internet-facing SAP Commerce Cloud (Hybris) instances that were never patched — likely opportunistic scanning against long-lived unpatched deployments rather than a fresh campaign. Not flagged as ransomware.' kev_date 2024-09-30; cisa_kev true; active_exploitation confirmed; poc_available true; patch_available true; patch_required_reboot false; live_patch_notes null. The NIST-800-53-SI-2 gap records that 'SAP shipped a fix in 2019, but KEV addition in 2024 shows five years of unpatched exposure among internet-facing instances — patch-SLA enforcement failed long-term, not just at disclosure'; the NIS2-Art21-vulnerability-management gap records that 'A five-year-old known-fixed flaw remaining exploitable at scale indicates an absent asset-inventory/patch-verification process for SAP e-commerce infrastructure.' Extension scope from affected (mediaconversion and virtualjdbc) and affected_versions.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-7593": {
     "name": "Ivanti Virtual Traffic Manager Authentication Bypass Vulnerability",
@@ -43487,7 +44572,39 @@
         "adequate": false,
         "gap": "IA-2 assumes the identification/authentication mechanism itself is sound; CVE-2024-7593 is a flaw IN the authentication algorithm, so identity verification is bypassed regardless of IA-2 policy configuration."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "Ivanti vTM is a traffic manager rather than a VPN concentrator, but the reason this control applies is unchanged: its admin panel is the authentication enforcement point for an internet-facing appliance, and the packet describes that enforcement failing open — an incorrect implementation of the authentication algorithm that lets a remote unauthenticated attacker past the admin-panel login entirely. That is not an appliance-patch-window item. Scope from the packet's version list rather than its headline: the fix is per release branch — before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2 — so every branch in service has its own fixed build, and an estate standardised on the 22.5 or 22.6 line is not covered by knowing that 22.2R1 and 22.7R2 exist. The expedited clock runs from the 2024-09-24 KEV listing, against the 2024-10-15 CISA due date, through the reboot of each unit: live_patch_available is false and patch_required_reboot is true, so a unit that has taken its branch fix but has not restarted is still running the broken authentication path and is not remediated. Precondition on the interim half: the packet records that Ivanti's mitigation guidance shipped ahead of a full patch, so during the mitigation-only period exposure is bounded, not removed — restricting which networks can reach the admin panel limits who can send the bypass but leaves it fully exploitable from every permitted source, and that bound is unavailable wherever the admin panel is reached over the internet, which is the deployment the packet says was mass-scanned.",
+        "evidence": "Packet vector: 'Incorrect implementation of an authentication algorithm in Ivanti vTM other than versions 22.2R1 or 22.7R2 allows a remote unauthenticated attacker to bypass authentication of the admin panel' (CWE-287, CWE-303, CVSS 9.8, RWEP 79, poc_available true). affected_versions lists five branch boundaries: before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2. active_exploitation_notes: 'CISA KEV added 2024-09-24 (due 2024-10-15) after mass scanning and exploitation of internet-exposed vTM admin panels.' patch_available true, patch_required_reboot true, live_patch_available false. The NIS2-Art21-vulnerability-management gap records that 'Ivanti's mitigation guidance shipped ahead of a full patch', and the AU-Essential-8-Patch gap that 'Ivanti initially published mitigations only, leaving a window where patch promptly had no patch to apply'.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet names the post-exploitation artifact precisely, and it is one no patch can reach: attackers bypassed the admin-panel login, POSTed a crafted user-creation request, and planted a rogue administrator account they then used to log in with full admin privileges. Upgrading a vTM unit to its branch fix repairs the authentication algorithm and leaves that account in place — afterwards it authenticates legitimately, which is exactly why an identity attestation and a least-privilege review both pass cleanly on an appliance the attacker still administers, and why the account survives the reboot the fix requires. So for every vTM that was reachable from an untrusted network between public disclosure and the moment its branch fix was running, the disposition is: enumerate the appliance's administrator accounts against a known-good roster and the change record, treat any account not accounted for as confirmation rather than as an oddity, and rebuild from vendor media with the configuration reviewed rather than restored wholesale — a wholesale restore carries the planted account back onto the rebuilt unit. Rotate the administrator credentials and the secrets the unit held, since the packet has the attacker operating the panel with full admin privileges. Precondition: this is scoped to units exposed during that window, and account enumeration is confirmation, not exclusion — an attacker holding admin can delete the account they added, so a clean roster on an exposed unit is weak evidence and does not on its own downgrade the disposition. Detection must key on what the packet describes: an administrator account appearing on the appliance outside a change window and an admin-panel session for it — not on failed-login volume, which this bypass never generates because authentication is never evaluated.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker exploits a flaw in vTM's authentication algorithm to bypass the admin-panel login entirely and POST a crafted user-creation request, planting a rogue administrator account they then use to log in with full admin privileges.' active_exploitation_notes: KEV added 2024-09-24 'after mass scanning and exploitation of internet-exposed vTM admin panels to plant rogue administrator accounts within days of public disclosure. Ransomware use is unknown/unconfirmed.' patch_required_reboot true; live_patch_available false. The UK-CAF-B2 gap records that CAF B2 'assumes access decisions are enforceable once presented'.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The version data in this entry is the trap this control exists to catch. The vector states the flaw affects vTM 'other than versions 22.2R1 or 22.7R2', and affected_versions expands that into five separate branch boundaries — before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2. A scanner or attestation that compares an installed version against a single fixed version marks a unit on the 22.3, 22.5 or 22.6 branch clean because it is numerically newer than 22.2R1, while that unit has not reached its own branch's fixed build. The operational test is therefore branch-aware: for each vTM instance, resolve its release branch first, then compare against that branch's fixed build, and require the value to be read from the running appliance after its last restart — patch_required_reboot is true and live_patch_available is false, so a unit that has staged the fix without rebooting reports an installed version its running authentication code does not reflect. Precondition: this is a verification control. It finds the false-clean report; it does not shorten the exposure, and it says nothing about whether a unit that was exposed already carries an attacker-created administrator — that question is answered by enumerating the appliance's admin accounts and rebuilding, never by a version comparison.",
+        "evidence": "Packet affected_versions: 'versions before 22.2R1', 'versions before 22.3R3', 'versions before 22.5R2', 'versions before 22.6R2', 'versions before 22.7R2'. The vector states the flaw is present in vTM 'other than versions 22.2R1 or 22.7R2', and affected records it as present on 'all release branches except the already-fixed 22.2R1 and 22.7R2 lines'. patch_required_reboot true; live_patch_available false; CISA KEV 2024-09-24 with a 2024-10-15 due date. The ISO-27001-2022-A.8.8 gap records that this unauthenticated CVSS 9.8 flaw 'was mass-exploited within the CISA-mandated remediation window'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-8963": {
     "name": "Ivanti Cloud Services Appliance (CSA) Path Traversal Vulnerability",
@@ -43566,7 +44683,30 @@
         "adequate": false,
         "gap": "The KEV due date is 3 days; a standard 30-day flaw-remediation SLA leaves internet-facing SharePoint exploitable for weeks after weaponization."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this SharePoint Server deserialization flaw the packet gives a 3-day KEV clock opening 2026-07-16 against the 30-day flaw-remediation SLA the entry records as inadequate, an available vendor update, and no live-patch path — so the requirement is that the update is driven as an out-of-band emergency change on the KEV clock rather than scheduled into the next maintenance window. Two things decide whether the deployment is real. The fixed build has to be taken per version from the MSRC guide the packet points to, because the entry carries affected versions only as \"Microsoft SharePoint Server (see MSRC guide for supported-version build numbers)\" — there is no single build number to compare against across an estate running more than one SharePoint version. And completion is measured on the build the running SharePoint service reports, not on the installer's exit code or an \"approved\" state in the management console: patch_required_reboot is false, which means no host reboot is demanded, not that the fix is live the moment the package installs — the entry's own Essential Eight gap records a deploy-and-reboot interval through which the pre-auth deserialization path on ports 80/443 stays open, so a server whose update is installed but whose SharePoint services have not been restarted onto the new build is still executing vulnerable code and must be counted as exposed until it has. Order the estate by internet reachability first, since that is where the packet records exploitation, but do not stop there: the flaw needs no authentication, and the packet records this class being chained into hands-on-keyboard intrusion, which puts internal instances within reach of an attacker who is already inside. Precondition: this control only compresses the clock. It does nothing for a server exploited before the update landed, which confirmed exploitation and a 3-day due date make a live possibility rather than a hypothetical — that case belongs to the rebuild control below.",
+        "evidence": "NIST-800-53-SI-2 gap: \"The KEV due date is 3 days (2026-07-16 to 2026-07-19); a standard 30-day flaw-remediation SLA leaves internet-facing SharePoint exploitable for weeks after weaponization.\" NIS2-Art21-patch-management gap: \"Routine patch cadence is insufficient against a 3-day KEV clock; emergency out-of-band patching is required.\" ISO-27001-2022-A.8.8 gap: \"Periodic technical-vulnerability review cannot match the same-day exploitation window observed for critical SharePoint RCE.\" AU-Essential-8-Patch gap: \"...patch maturity alone leaves the pre-auth deserialization path on ports 80/443 open through the deploy-and-reboot interval.\" affected_versions: \"Microsoft SharePoint Server (see MSRC guide for supported-version build numbers)\". patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" active_exploitation_notes: KEV 2026-07-16 with a 3-day due date, confirmed active exploitation of internet-facing SharePoint servers, historically chained into web-shell drops and hands-on-keyboard intrusion.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's attack path for this CVE ends in code execution as the SharePoint service account, typically followed by a web-shell drop, with exploitation confirmed and a 3-day KEV due date — so for any SharePoint Server that was internet-reachable and below the fixed build during the exposure window, compromise is the default working assumption and the update is not the end of the response. The update closes the deserialization path; it removes nothing an attacker already wrote through it and it does not invalidate credentials or session material taken from the box. Applied here that means: preserve configuration and content for evidence, rebuild the server from a known-good baseline rather than patching in place, and rotate the SharePoint service account credential along with anything else that account could reach. The hunt keys on what the packet actually documents rather than on assumed signals — a web shell placed in the content the server serves, and code running under the SharePoint service identity — so look for files newly written into the server's web-serving directories during the window and for child processes spawned by the SharePoint service identity, not for exploit-tool signatures or process crashes. The exploit is a single crafted serialized request that the server processes through its normal request path: it produces no crash to alert on, and because the attacker never authenticates, it produces no authentication event either, so an estate whose logging is sign-in-centric has no record that it happened. Preconditions, and they are the ones this control is most often over-claimed past: rebuild-not-patch presumes a known-good baseline and a content restore point predating the exposure window — where the earliest backup falls inside that window, restoring reinstates whatever was planted and the artifact hunt is the only remaining check; and it presumes the estate can say which servers were reachable, and on which build, during the window. Where that record does not exist, the scope is every internet-facing instance, not the ones someone remembers.",
+        "evidence": "Packet attack_vector: \"An unauthenticated attacker sends a crafted serialized .NET payload to an internet-facing SharePoint endpoint; unsafe deserialization triggers a gadget chain that executes attacker code as the SharePoint service account, typically followed by a web-shell drop.\" active_exploitation_notes: \"Added to CISA KEV 2026-07-16 with a 3-day due date, indicating confirmed active exploitation of internet-facing SharePoint servers. Ransomware use is not yet confirmed but deserialization RCE on SharePoint has historically been chained into web-shell drops and hands-on-keyboard intrusion.\" UK-CAF-B4 gap: \"System-security assurance based on scheduled hardening reviews will not detect exploitation of an unauthenticated code-execution path in real time.\" AU-Essential-8-Patch gap: \"...patch maturity alone leaves the pre-auth deserialization path on ports 80/443 open through the deploy-and-reboot interval.\" active_exploitation confirmed; cvss 9.8; patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2026-25089": {
     "name": "Fortinet FortiSandbox OS Command Injection Vulnerability (CVE-2026-25089)",
@@ -43867,7 +45007,30 @@
         "adequate": false,
         "gap": "The 3-day KEV due date reflects that this was exploited as a zero-day before any patch existed; a standard 30-day flaw-remediation SLA is far longer than the observed exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The packet places this defect at exactly the layer this control governs: a missing authentication check (CWE-306) on a critical User Profiles administrative function in on-premises Microsoft SharePoint Server, reachable unauthenticated over the network via /_vti_bin/client.svc. The attack_vector shows the request-validation layer being stepped around rather than defeated — a crafted SOAP payload that omits the X-RequestDigest header and adds routing headers to reach an unvalidated code path — which is the pattern this control forbids: an administrative operation inheriting its authorization verdict from a validation layer that fronts it instead of deciding for itself. Bound to this product, the requirement is that each User Profiles administrative operation authorizes its caller inside its own code path, so a request that presents neither a digest nor a session cannot reach the operation at all, and that the farm's administrative surface is separated from the general-purpose client endpoint rather than sharing one entry point with it. This is also why the access-control gap cited on this entry cannot be closed operationally: the attacker never authenticates as any SharePoint principal, so per-account permission scoping is never consulted, and an access-control attestation showing every SharePoint administrator correctly assigned passes cleanly while this path stays open. Distinguishing test: on a staging farm at each of the three affected versions, issue unauthenticated SOAP requests to the User Profiles administrative endpoints through /_vti_bin/client.svc with the X-RequestDigest header omitted and the routing headers the packet describes added, and confirm each is refused before the 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 the packet records that update, which requires a reboot, as the remediation with no live-patching primitive available. Restricting which networks can reach the endpoint bounds the caller population only where the deployment permits it, and the packet's own boundary-protection gap records /_vti_bin/client.svc as an intended internet-facing service, so on a farm published to the internet that lever is unavailable and nothing stands between an untrusted caller and the missing check until the update and its reboot land.",
+        "evidence": "Packet fields: name = 'Microsoft SharePoint Server Missing Authentication for Critical Function Vulnerability'; cwe_refs = CWE-306; affected = 'On-premises Microsoft SharePoint Server: a missing authentication check on a critical User Profiles administrative function reachable unauthenticated via /_vti_bin/client.svc'; affected_versions = SharePoint Enterprise Server 2016, SharePoint Server 2019, SharePoint Server Subscription Edition; attack_vector = 'An unauthenticated attacker sends a crafted SOAP payload to /_vti_bin/client.svc targeting User Profiles administrative endpoints, omitting the X-RequestDigest header and adding routing headers to reach an unvalidated code path, elevating privileges over the network'; vector = 'Missing authentication for critical function in Microsoft Office SharePoint allows an unauthorized attacker to elevate privileges over a network'. Gap text used: ISO-27001-2022-A.5.15 = 'access control presumes authorisation is enforced at the function, but this flaw is a missing authentication check on a critical SharePoint operation reachable pre-auth over the network... a code defect A.5.15 cannot compensate for operationally'; UK-CAF-B4 = 'System security hardening cannot compensate for a code-level missing-authentication check on a critical administrative function reachable pre-auth'; NIST-800-53-SC-7 = 'Boundary protection does not help when the vulnerable /_vti_bin/client.svc endpoint is an intended internet-facing service'. Remediation state: patch_available true, patch_required_reboot 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": [
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the KEV listing and the patch arrived together: the packet records confirmed in-the-wild exploitation as a zero-day before the July 14 2026 patch, and CISA adding it to KEV the same day with a three-day due date. The control's 'whichever is later' trigger therefore fires at patch availability, and its four-hour requirement is the only reading that matches an unauthenticated network privilege-elevation reachable pre-auth on an internet-facing service at CVSS 9.8. Applied to this product: every on-premises SharePoint Enterprise Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition install is driven to its fixed build on the clock that opened 2026-07-14, counted per server rather than per farm, since a farm's patch record is not evidence about each server running the affected software. The packet records a vendor update that requires a reboot with no live-patching primitive, so a server that has installed the update but not completed its reboot is still executing the vulnerable code and must be counted as exposed rather than remediated; on servers carrying user-facing workloads the reboot is the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Completion is measured on the build each server is actually running. Two things this control does not do, and both matter here. It gives nothing for the window before the fix: the flaw was exploited before any patch existed, so the 30-day flaw-remediation SLA the packet's gap describes was not merely slow, it had nothing to apply, and the coordinated-handling assumption of a disclosure-then-patch window that the EU gap names simply did not hold. And it does not evict an attacker already resident — the packet credits discovery to Mandiant incident responders and Google's FLARE team, stating the flaw was found inside active intrusions rather than routine research, so a farm that was network-reachable before the patch is a compromise-assessment and credential-rotation question, not something closed on the patch record.",
+        "evidence": "Packet fields: cisa_kev true, kev_date 2026-07-14; cvss 9.8; rwep_score 61; active_exploitation confirmed with active_exploitation_notes 'Confirmed exploited in the wild as a zero-day before the July 14 2026 patch; discovery credited to Mandiant incident responders and Google's FLARE team, indicating the flaw was found inside active intrusions rather than routine research. CISA added it to KEV the same day with a 3-day due date.'; affected_versions = SharePoint Enterprise Server 2016, SharePoint Server 2019, SharePoint Server Subscription Edition; patch_available true, patch_required_reboot 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 text used: NIST-800-53-SI-2 = 'The 3-day KEV due date reflects that this was exploited as a zero-day before any patch existed; a standard 30-day flaw-remediation SLA is far longer than the observed exploitation window'; AU-Essential-8-Patch = 'Essential 8 patch timelines (48 hours for internet-facing critical) still trail same-day active exploitation of an unpatched zero-day'; NIS2-Art21-vulnerability-handling = 'Coordinated vulnerability handling assumes a disclosure-then-patch window; an actively-exploited pre-patch zero-day gives operators no lead time to close exposure'. poc_available is false on this entry, so no public exploit code is claimed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2026-15409": {
     "name": "SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability",
@@ -44069,7 +45232,40 @@
         "adequate": false,
         "gap": "Boundary protection does not help when T3/IIOP management ports are exposed to the app tier or internet, which is common for WebLogic; the deserialization sink stays reachable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "WebLogic's T3 and IIOP listeners are exactly the binary remoting-protocol class this control governs: non-HTTP endpoints that answer and begin reconstructing an object before any authentication happens, on the same server whose HTTP tier is the only part most WebLogic deployments are audited against. The packet places the flaw in the Fusion Middleware Core component and has an unauthenticated network attacker reaching it over T3 or IIOP for full server takeover, so the operative question is not whether the deployed application enforces its roles but which hosts can open a T3 or IIOP connection at all. Bound to this product it means enumerating every WebLogic Server instance at 12.2.1.3.0, 12.2.1.4.0 or 14.1.1.0.0 — the three versions the packet names, including any the estate does not carry under the WebLogic name because it was installed as part of a larger Oracle deployment — and for each restricting the T3/IIOP listen ports to the admin server, cluster peers and application hosts that legitimately speak those protocols, enforced by network ACL or host firewall rather than inferred from 'WebLogic is internal', with the protocol disabled outright on instances that use neither. The distinguishing test for this product: from a general application or user VLAN on a staging deployment, open a T3 connection to the managed server's listen port and confirm it is dropped before the server reads the serialized payload — an estate that passes WebLogic account, role and password audits still exposes this path in full, because no credential is presented anywhere in the attack the packet describes. Precondition, and it is where this control is most often over-claimed: restricting reachability bounds who can send the object, it does not repair the deserializer. Any host inside the permitted set reaches the sink unchanged, and the measure is unavailable on instances where T3 or IIOP must remain reachable for clustering or remote clients — for those the only lever is the Oracle update.",
+        "evidence": "Packet affected: 'Oracle WebLogic Server (Fusion Middleware, Core component) reachable over the T3 or IIOP protocols by an unauthenticated network attacker; exploitation yields full server takeover.' affected_versions: 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0. cwe_refs: CWE-502. The NIST-800-53-SC-7 gap records that boundary protection 'does not stop the flaw if the T3/IIOP admin ports are reachable from the app tier or internet; WebLogic management protocols are frequently left exposed, so segmentation alone leaves the deserialization sink live'. The ISO-27001-2022-A.8.8 gap records that technical-vulnerability management 'does not enforce protocol-level allowlisting of T3/IIOP', and the NIS2-Art21-vulnerability-management gap that the requirement 'does not mandate disabling or filtering the T3/IIOP protocols that carry the exploit, which is the only reliable compensating control when patching lags'. The UK-CAF-B4 gap names 'the exposed T3 port as the live entry point'. CISA KEV listed 2024-09-18, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 75.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "This is the half of the problem that survives after network placement has been fixed as far as it can be. The packet's attack path is a crafted serialized Java object arriving over T3 or IIOP which WebLogic deserializes through a vulnerable gadget chain, executing attacker code as the server process — so the listener is a trust boundary, and treating it as an internal convenience is what makes a routable path into a takeover. Applied to this deployment the control means the T3/IIOP handler does not inherit its safety from where the server sits: constrain which types the protocol path is permitted to reconstruct so that content arriving on the port cannot select the gadget chain, and require peer authentication on every remoting protocol the instance has enabled rather than only the one the applications happen to use — a deployment that authenticates its T3 clients but leaves IIOP enabled and open has not closed the packet's stated path, which names both. The distinguishing test: from an unauthenticated host that can route to the T3 port of a staging instance, send a serialized object of a type the application protocol never legitimately conveys and confirm the connection is refused before the object is reconstructed — a WebLogic instance that passes a patch-level and role audit while reconstructing arbitrary types from unauthenticated peers still exposes this sink and the next one found in the same class libraries. Precondition, stated plainly because the corpus keeps getting this wrong: an operator-side type constraint bounds the chains already known. The packet says exploitation runs through 'a vulnerable gadget chain', and a constraint expressed as known-bad chains is defeated by the next chain in the same libraries — so this reduces what can be sent at the sink, it does not make the port safe to expose, and it is not a substitute for the Oracle update, which is what removes this chain.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends a crafted serialized Java object over the WebLogic T3 or IIOP protocol; WebLogic deserializes it through a vulnerable gadget chain and executes attacker code as the server process, resulting in full takeover.' cwe_refs: CWE-502. Vector text: 'Easily exploitable vulnerability allows unauthenticated attacker with network access via IIOP, T3 to compromise Oracle WebLogic Server.' The NIST-800-53-SC-7 gap records that segmentation alone 'leaves the deserialization sink live'. poc_available true, active_exploitation confirmed, CISA KEV 2024-09-18, CVSS 9.8.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock runs from the 2024-09-18 KEV listing, because the population that matters is the WebLogic instances still sitting at 12.2.1.3.0, 12.2.1.4.0 or 14.1.1.0.0 long after the Oracle fix shipped — the packet's own SI-2 gap describes monthly and quarterly enterprise-middleware remediation cycles against a class mass-scanned within days of an Oracle CPU, and its Essential-Eight gap the same mismatch at a two-week to one-month cadence. The packet records a vendor fix available, no host reboot required, and no live-patch primitive, which is the exact combination that makes this remediation look finished before it is: with no in-process patching path, a managed server that is running has already loaded the pre-fix classes and keeps executing them until that server process is restarted onto the updated libraries. Completion is therefore measured on the version each running WebLogic process reports, never on a patch-inventory row and never on the 'no reboot required' note — the absence of a machine reboot is not the fix being live in the JVM. Where a managed server cannot be restarted inside the SLA, the interim state is restricting reachability of its T3 and IIOP listeners, recorded as an open item with a dated restart rather than as remediation. And because active exploitation is confirmed, a public PoC exists and the outcome the packet states is full server takeover, an instance whose T3 or IIOP listeners were reachable during the exposure window belongs on the incident path — the update does not remove what was already placed on the server.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-09-18, active_exploitation confirmed, poc_available true, rwep_score 75, cvss 9.8. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The NIST-800-53-SI-2 gap: 'Flaw-remediation SLAs run monthly/quarterly for enterprise middleware, but this class is mass-scanned within days of a Oracle CPU; the patch window vastly exceeds the observed exploitation window.' The AU-Essential-8-Patch gap: 'Application-patch maturity targets a 2-week/1-month cadence for internet-facing servers, still slower than the same-week weaponization seen for WebLogic deserialization chains.' affected states exploitation 'yields full server takeover'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2022-21445": {
     "name": "Oracle ADF Faces Deserialization of Untrusted Data Vulnerability",
@@ -45500,7 +46696,28 @@
         "adequate": false,
         "gap": "Boundary protection is routinely absent for cameras placed directly on the internet or in flat networks; the auth bypass reaches the device's login service with no perimeter mediation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries both halves that this control exists to separate. A vendor fix exists and the entry records that there is no live-patching primitive for this product, that the vendor update requires a reboot, and that it is the remediation — while the A.8.8 and SI-2 gaps state that a large part of the affected fleet is end-of-support with no remediation path at all. So the first requirement is a per-unit inventory naming every Dahua IP camera, NVR and related product in service, and every OEM-rebranded Dahua-based device the packet's affected_versions call out, each recorded with its model, its running firmware baseline, and a supported-or-end-of-support answer obtained from the Dahua PSIRT advisory for that exact model rather than assumed in either direction — the packet gives affected versions only as firmware baselines prior to the vendor's 2021 fix, with per-model builds left to that advisory. Units whose model has fixed firmware are remediation items on the clock that opened with the 2024-08-21 KEV listing, and because the update requires a reboot with no live-patch path, a unit that has taken firmware but has not rebooted onto it is still running the bypassable login path and counts as exposed. Units whose model has no fixed firmware — the end-of-support population the A.8.8 gap names, which on an OEM rebrand may mean no vendor is shipping firmware at all — cannot be patched and belong on a dated replacement schedule; a risk acceptance with no removal date leaves a device with a public PoC, confirmed exploitation and 99.9th-percentile EPSS in service indefinitely, exposed not only to this bypass but to everything found in that firmware line since. And because exploitation is confirmed and the packet records recruitment into IoT botnets, a unit that was internet-exposed before remediation is not closed by firmware alone: its configuration and administrative credential must be rebuilt from a known-good baseline rather than inherited through the update, and credentials that transited it rotated.",
+        "evidence": "Packet: affected names Dahua IP cameras, NVRs and related products; affected_versions name multiple Dahua IPC/SD/NVR firmware baselines prior to the vendor's 2021 fix (per-model builds per the Dahua PSIRT advisory) and numerous OEM-rebranded Dahua-based devices. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' CISA KEV 2024-08-21, active_exploitation confirmed, poc_available true, RWEP 73, CVSS 9.8; active_exploitation_notes record broad exploitation of internet-exposed Dahua cameras and NVRs including recruitment into IoT botnets, with EPSS at the 99.9th percentile. The ISO-27001-2022-A.8.8 gap states there is no remediation path for end-of-support Dahua/OEM camera firmware and that the control cannot compel operators to patch or retire; the NIST-800-53-SI-2 gap states many affected Dahua/OEM cameras are end-of-support so the patch SLA effectively never closes on a large installed base.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For the Dahua units that do have fixed firmware, this is the clock the SI-2 gap says never closes on this fleet: firmware flashed and the device rebooted onto it, measured from the 2024-08-21 KEV listing rather than from a camera-refresh or building-maintenance cycle, with completion recorded per unit against the running firmware baseline. Two limits have to be stated rather than assumed for this product. The packet registers no live-patching primitive, so there is no mitigation that lands ahead of the reboot — a unit scheduled for firmware is exposed until it restarts. And for units with no fixed firmware, the SLA's compensating-control branch is the only branch available, which here means removing the device from any internet-reachable path — a holding measure with a hard precondition: the bypass sits inside the login process itself, triggered by a packet that names the loopback device as the client, so any caller that can open a session to the device still reaches it. Taking a camera off a port-forward or UPnP mapping does nothing about a caller already on the network segment that reaches it, so those units belong on the replacement schedule with a date, not on an indefinite compensating-control record.",
+        "evidence": "Packet: CISA KEV 2024-08-21, active_exploitation confirmed, EPSS at the 99.9th percentile, poc_available true, RWEP 73, CVSS 9.8. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes state the vendor update requires a reboot and is the remediation. vector and affected describe the login process being bypassed by constructing a packet that specifies the loopback device as the client, skipping identity authentication. The NIST-800-53-SI-2 gap states firmware flaw-remediation is chronically slow for IoT fleets and that many affected devices are end-of-support, so the patch SLA effectively never closes.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-33044": {
     "name": "Dahua IP Camera Authentication Bypass Vulnerability (CVE-2021-33044)",
@@ -45537,7 +46754,31 @@
         "adequate": false,
         "gap": "The authentication mechanism itself is bypassable via the NetKeyboard packet type, so an identification/authentication control that assumes credentials are checked provides no protection."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The remediation for this entry is the Dahua firmware fix, and the packet is explicit that it cannot be applied live: live_patch_available is false and live_patch_notes record that the vendor update requires a reboot and is the remediation. A camera or NVR that has received firmware but has not restarted onto it is still running the bypassable login path and is counted as exposed, not as patched — on camera fleets that restart is the step most often skipped, because taking it drops recording and live view, and a deferral recorded as patched is the specific way this remediation goes wrong. Scope comes from the affected field rather than the CVE's headline product: Dahua IP cameras, NVRs and OEM-rebranded devices are all in scope, so an inventory keyed on the vendor name reports clean across an estate standardised on a rebrand, and the recorders are as much in scope as the cameras they hold. The fixed level is per-model — the packet gives affected versions as the builds prior to the fixes listed in Dahua advisory 957 — so each model, and each rebranded equivalent, is checked against the fixed build for that model rather than against one estate-wide firmware number, and for a rebranded unit the fixed build has to be obtained from whoever ships that unit's firmware rather than assumed from the Dahua model it derives from. The clock is the 2024-08-21 KEV listing, and the packet's exposure note is why this cannot ride the normal cadence: EPSS near 0.999 with mass scanning and botnet exploitation of internet-exposed units, against a flaw whose fix has been available since well before the listing. The patch requirement is also the only closure for the authentication side: an alternate login path built into the firmware is not something gateway or authentication hardening guidance can compensate for, so reaching the fixed build is the control, not a supplement to it.",
+        "evidence": "live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' patch_required_reboot true; live_patch_available false; patch_available true. affected: 'Dahua IP cameras, NVRs and OEM-rebranded devices — authentication bypass during login when the client specifies the NetKeyboard type argument.' affected_versions: 'Multiple Dahua camera/NVR firmware builds prior to the fixes listed in Dahua advisory 957.' CISA KEV listing 2024-08-21; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 77. active_exploitation_notes: 'EPSS ~0.999 reflects mass scanning and botnet exploitation of internet-exposed Dahua cameras and OEM-rebranded devices.' The packet's ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management often excludes long-lived IP-camera firmware from the patch scope, so the flaw persists for years.' The AU-ISM-1546 gap: 'Gateway/authentication hardening guidance does not account for firmware that ships an alternate auth path bypassing the primary check.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The login handler is where a Dahua camera or NVR makes its authentication decision, and this CVE is that decision failing open: the packet has an attacker constructing a login packet that specifies the NetKeyboard type argument, which bypasses the credential check and returns an authenticated session to the device. Bound to this product the control means the device's functions do not inherit their authorization from that single login verdict, and — the half an operator holds today — that the camera and NVR login and management surfaces answer only from the segment that operates them, because a caller who cannot present the crafted packet cannot use the bypass. This is the specific reason the identity controls cited against this entry give nothing: no credential is ever presented, so no password policy, rotation schedule or account model is consulted, and an attestation that every camera carries a unique administrator password passes cleanly while the whole fleet is open. It also means the cameras, the recorders and the rebranded units belong in an identity-endpoint inventory rather than being carried as fixtures, since the packet's framing is that a bypassed camera becomes a foothold onto whatever network it shares. Distinguishing test: from a general corporate VLAN and from an external address, attempt to open a session to a staging camera and to a staging NVR; anything that answers is within reach of the published bypass, and 'the cameras are on the internal network' is a statement about topology rather than a demonstration that the login surface is unreachable from untrusted segments. Precondition: segmentation bounds who can send the packet, it does not repair the login path. Any host already inside the permitted segment — the video-management server that legitimately talks to the fleet, an operator workstation, a maintenance contractor's laptop — still reaches it, and the lever is unavailable entirely for a unit deliberately published for remote viewing. Those units stay exposed until the firmware fix and its reboot land, and because exploitation is confirmed and mass-scale, a unit that was internet-reachable while unpatched needs its configuration and credentials rebuilt from a known-good baseline rather than inherited through the firmware update.",
+        "evidence": "vector: 'The identity authentication bypass vulnerability found in some Dahua products during the login process. Attackers can bypass device identity authentication by constructing malicious data packets.' affected: 'authentication bypass during login when the client specifies the NetKeyboard type argument', covering 'Dahua IP cameras, NVRs and OEM-rebranded devices'. attack_vector: 'An unauthenticated remote attacker sends a crafted login packet specifying the NetKeyboard authentication type, which bypasses the credential check and grants an authenticated session to the camera or NVR.' The packet's NIST-800-53-IA-2 gap: 'The authentication mechanism itself is bypassable via the NetKeyboard packet type, so an identification/authentication control that assumes credentials are checked provides no protection.' The NIST-800-53-SC-7 gap: 'IoT cameras are routinely exposed directly to the internet; boundary controls are frequently absent for these devices, leaving the preauth bypass reachable at scale.' The NIS2-Art21-network-security gap: 'Network-security duties rarely segment CCTV/IoT VLANs from the corporate network, so a bypassed camera becomes a foothold.' The UK-CAF-B2 gap: the bypass 'defeats it across an entire fleet of internet-exposed Dahua cameras that B2 controls seldom inventory as identity endpoints.' active_exploitation confirmed; patch_available true with a reboot required per live_patch_notes.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-23897": {
     "name": "Jenkins Command Line Interface (CLI) Path Traversal Vulnerability",
@@ -45648,7 +46889,31 @@
         "adequate": false,
         "gap": "Staged monthly Windows patching leaves endpoints exposed for weeks after the KEV add, during which the SYSTEM-grade LPE is already being used post-foothold."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Power Dependency Coordinator (pdc.sys) kernel component and describes a local authenticated attacker driving a use-after-free from standard user to SYSTEM — 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 August 2024 Windows security update is driven across every affected host on the KEV clock that opened 2024-08-13 rather than riding the staged monthly ring rollout the packet records as leaving endpoints exposed for weeks, with completion measured by each host's installed build against the fixed build for its SKU. Enumerate the whole population the packet names — Windows 10 and Windows 11 clients alongside Windows Server 2016, 2019 and 2022 — and do not let the server fleet go first: this is a post-foothold escalation step, so the machines where an attacker lands initially are ordinary user workstations, and an estate that patches servers first leaves the primitive available exactly where initial access happens. The packet records patch_required_reboot true, no live-patch path, and that the vendor update requires a reboot and is the remediation, so a host that has installed the update but not rebooted is still executing the vulnerable driver and must be counted as exposed; measure on the running build rather than on 'installed' in the management console. What is not available here matters as much: the packet records this as an in-box driver that system-security hardening cannot remove or disable, so unlike an optional service or a third-party signed driver there is no disable, unload or blocklist interim measure — the update is the removal, which is why compressing its rollout is the whole control.",
+        "evidence": "Packet: CISA KEV-listed 2024-08-13, active_exploitation confirmed, CVSS 7.8, RWEP 61, poc_available false, CWE-416. affected: Windows Power Dependency Coordinator (pdc.sys) kernel component, local authenticated attacker exploits a use-after-free to elevate from standard user to SYSTEM, fixed in the August 2024 security updates across supported Windows client and server builds. affected_versions: Windows 10 (all supported builds pre-Aug 2024 update), Windows 11 (pre-Aug 2024 update), Windows Server 2016/2019/2022 (pre-Aug 2024 update). patch_available true, patch_required_reboot 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. NIST-800-53-SI-2 gap: monthly cadence plus staged enterprise ring rollout means the August 2024 fix reaches many endpoints weeks after the KEV add while the LPE is already weaponized. UK-CAF-B4 gap: an in-box driver B4 hardening cannot remove or disable. active_exploitation_notes: used as a post-exploitation escalation step; ransomware use unconfirmed but SYSTEM-grade LPEs are common in ransomware and hands-on-keyboard intrusions.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "pdc.sys is a Windows kernel driver, so for this CVE the control is Windows privilege-transition telemetry rather than the auditd/eBPF form it takes on Linux hosts — and the packet describes the behaviour precisely enough to key on it. The exploit is a local authenticated user's process corrupting kernel memory through the Power Dependency Coordinator and emerging as SYSTEM, run after an initial foothold. The rule therefore keys on that transition in that direction: a process running under a standard user account, inside an interactive user session, that acquires a SYSTEM-integrity token or spawns a SYSTEM-context child without having passed through a legitimate elevation path — no service-control-manager start, no scheduled task registered to run as SYSTEM, no consent prompt, no management-agent installer. Pair it with the driver-interaction half the packet names, a non-elevated user process opening a handle to the Power Dependency Coordinator driver, which ordinary user code has no reason to do; either signal alone is noisy, and it is the pairing inside a short window that separates this exploit from a benign elevation. Note what will not see it, because this is exactly where the anomaly-detection gap bites: the packet records no public PoC, so there is no tool signature to match; nothing is written to disk for a file-integrity monitor to catch; and the component being exercised is a signed in-box Microsoft driver, so driver-load and code-signing telemetry stay clean by construction — a rule keyed on process crashes, unsigned drivers or named exploit tooling would miss an attempt behaving exactly as the packet describes. Preconditions: this needs privilege-transition telemetry already collected and shipped off-host before the attempt, and a rule authored afterwards against telemetry nobody was collecting produces nothing. And detection prevents nothing — it bounds dwell time during the weeks the staged rollout takes; a host on which SYSTEM was reached is a rebuild-and-credential-rotation case, not one closed by the August 2024 update landing later.",
+        "evidence": "Packet SOC2-CC7-anomaly-detection gap: anomaly-detection controls rarely flag a same-host token-elevation from a legitimate driver interaction, so the escalation is easily missed without EDR tuned to privilege-transition events. attack_vector: a local, authenticated attacker triggers a use-after-free in the Windows Power Dependency Coordinator driver to corrupt kernel memory and elevate to SYSTEM, chaining it after an initial foothold to gain full host control. ISO-27001-2022-A.8.8 gap describes local exploitation of a signed in-box driver between assessment cycles. poc_available false. NIST-800-53-SI-2 gap records the weeks-long staged-rollout exposure window. active_exploitation confirmed, KEV 2024-08-13.",
+        "gap_closes": [
+          "SOC2-CC7-anomaly-detection"
+        ]
+      }
+    ]
   },
   "CVE-2024-38106": {
     "name": "Microsoft Windows Kernel Privilege Escalation Vulnerability",
@@ -45745,7 +47010,39 @@
         "adequate": false,
         "gap": "Signature-based malicious-code protection is precisely what FudModule disables post-escalation, so it cannot be relied on to catch this chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet's affected list is what scopes this sweep and it is broad — Windows 10, Windows 11 and Windows Server 2016, 2019 and 2022, each in its pre-August-2024-patch state — and the vector names no optional role or feature that would narrow it, so there is no 'does this host run the component' question to filter on. Treating a local privilege escalation as a workstation concern therefore leaves the entire server population the packet names unremediated, on machines where reaching SYSTEM is worth more to the attacker than it is on a laptop. The requirement is that the August 2024 Windows update carrying the afd.sys fix is driven across every host in that list on the clock that opened with the 2024-08-13 KEV listing rather than folded into the next monthly rollup, with completion measured per host against the build the machine is actually running for its SKU rather than against 'approved', 'downloaded' or 'deployed' in the management console. The packet records no live-patching primitive and states the vendor update requires a reboot and is the remediation, so a host that has installed the update and not rebooted is still executing the vulnerable driver and must be counted as exposed; on servers that pending reboot is the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Priority has to follow the packet rather than the CVSS band: the entry carries a 7.8 CVSS but an RWEP of 81, a public proof of concept, and exploitation as a zero-day by Lazarus Group to reach SYSTEM and install the FudModule rootkit — the 7.8 is exactly what drops this below an internet-facing fast lane and onto the routine cadence, which is the gap the cited patch and technical-vulnerability controls describe. The control's second half is load-bearing here too: the attacker is already a local low-privileged process, so tightening account privilege does not contain the escalation.",
+        "evidence": "Packet name: 'Microsoft Windows Ancillary Function Driver for WinSock Privilege Escalation Vulnerability'; CWE-416; affected: 'Microsoft Windows Ancillary Function Driver for WinSock (afd.sys) contains a use-after-free that a local attacker exploits to elevate privileges to SYSTEM.' affected_versions: 'Windows 10 (pre-August 2024 patch)', 'Windows 11 (pre-August 2024 patch)', 'Windows Server 2016/2019/2022 (pre-August 2024 patch)'. cisa_kev true, kev_date 2024-08-13, active_exploitation 'confirmed'; cvss 7.8; rwep_score 81; poc_available true. patch_available true, patch_required_reboot 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.' active_exploitation_notes: 'Exploited as a zero-day by North Korea's Lazarus Group to escalate to SYSTEM and install the FudModule rootkit'. The NIST-800-53-SI-2 gap records that 'kernel-driver patching requires a reboot cycle that lags an in-the-wild zero-day already chained to a rootkit installer'; the AU-Essential-8-Patch gap records that 'OS-patch timelines for driver updates lag the observed zero-day exploitation by a nation-state actor'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-079",
+        "name": "AV-EDR-AVAILABILITY-MONITORING",
+        "description": "The packet says what the attacker does in the seconds after the escalation: installs the FudModule rootkit to disable security monitoring — and the entry's own gap analysis adds that signature-based malicious-code protection is precisely what FudModule disables, and that the security-monitoring control assumes an intact telemetry pipeline the post-escalation rootkit tears down. A detection built on what that pipeline reports is therefore built on the thing being switched off, so the rule has to key on the pipeline going dark. Applied to this chain: an endpoint that stops reporting EDR or anti-malware telemetry, or whose protection service stops, restarts abnormally, or has its protections turned off, is itself a security event — raised by the off-host management console or SIEM that notices the absence, never by a rule running on the endpoint, since an on-host rule sits inside exactly what the packet says the rootkit disables. Pair that silence with the escalation the packet describes on the same host in the preceding interval: a local low-privileged process obtaining SYSTEM. The pairing is what makes it a finding — silence alone has ordinary causes (a shut-down machine, a laptop off the network, an agent upgrade), and an isolated SYSTEM transition arrives without context. Note what this deliberately does not key on, because those are the rules that would be written by reflex and would miss this: the packet records no process crash, no ransomware association and no named tooling artifact for the escalation itself, so detections anchored on crash telemetry, ransomware indicators or exploit-tool signatures will not fire on an intrusion that behaves exactly as the packet describes. Precondition: this needs the off-host control plane to be already tracking agent check-in state, with a staleness threshold short enough to matter, before the attempt. And it is detection only — by the time the telemetry stops, SYSTEM has already been obtained and the rootkit is loaded; the rule bounds dwell time, it does not prevent the escalation or remove what is resident.",
+        "evidence": "Packet attack_vector: 'A local, low-privileged process abuses a use-after-free in afd.sys (the WinSock Ancillary Function Driver) to corrupt kernel memory and elevate to SYSTEM, after which Lazarus installs the FudModule rootkit to disable security monitoring.' The NIST-800-53-SI-3 gap: 'Signature-based malicious-code protection is precisely what FudModule disables post-escalation, so it cannot be relied on to catch this chain.' The UK-CAF-C1 gap: 'CAF security monitoring is the exact control FudModule neutralises after this AFD.sys use-after-free grants SYSTEM; C1 detection assumes an intact telemetry pipeline that the post-escalation rootkit tears down.' The NIS2-Art21-incident-handling gap records that incident-handling controls 'trigger only after the rootkit blinds monitoring, leaving a detection gap during the escalation window.' active_exploitation_notes record 'no ransomware association reported'; the packet describes no crash and names no exploit tooling for the escalation.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "UK-CAF-C1"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "This entry is the case the control exists for — the packet attributes the zero-day exploitation to North Korea's Lazarus Group and records the payload as the FudModule rootkit — and the escalation path matters precisely because standard endpoint IR treats a rootkit as a commodity infection to be cleaned and closed. For this chain the requirement is that a confirmed SYSTEM escalation on a host in the populations the packet names — personnel working on cryptocurrency and aerospace — routes to the nation-state path rather than to routine endpoint remediation: the host is preserved for forensic acquisition instead of being reimaged first, every credential and key reachable from a SYSTEM context on it is treated as taken rather than as potentially exposed, and the review extends to what that identity could reach rather than terminating at the machine. The trigger cannot be the attribution: the packet records this as a zero-day discovered in the wild by Gen Digital, so the Lazarus and FudModule naming became available only after the exploitation, and a runbook waiting for a named actor never fires during the window it exists to cover. Trigger on the observable instead — a local low-privileged process obtaining SYSTEM, followed by security monitoring going down on that same host — and de-escalate afterwards if triage clears it. Note also that the packet records no ransomware association for this activity, so an escalation ladder anchored on ransomware indicators has nothing to trip and the intrusion is handled at commodity severity throughout. Precondition and limit: this governs the response only. It does not prevent the escalation, which needs the vendor update and the reboot the packet records, and preserving a host for forensics is compatible with isolating it but not with leaving it in service.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited as a zero-day by North Korea's Lazarus Group to escalate to SYSTEM and install the FudModule rootkit, targeting cryptocurrency and aerospace personnel. Discovered in-the-wild by Gen Digital; no ransomware association reported.' attack_vector: a local low-privileged process elevates to SYSTEM via the afd.sys use-after-free, 'after which Lazarus installs the FudModule rootkit to disable security monitoring.' The NIS2-Art21-incident-handling gap: 'Incident-handling controls trigger only after the rootkit blinds monitoring, leaving a detection gap during the escalation window.' cisa_kev true, kev_date 2024-08-13, active_exploitation 'confirmed'; rwep_score 81; poc_available true; patch_available true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-38213": {
     "name": "Microsoft Windows SmartScreen Security Feature Bypass Vulnerability",
@@ -46002,7 +47299,39 @@
         "adequate": false,
         "gap": "Kernel flaw remediation on mobile/embedded fleets depends on OEM backport cadence; the observed targeted exploitation preceded broad OTA availability, outrunning any patch SLA."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is two remediation populations, and the packet names both: `affected` puts the use-after-free in Linux kernel networking — __dst_negative_advice() clearing sk->dst_cache out of RCU order — and states it impacts Linux and Android (Pixel and other) kernels, while `affected_versions` gives the stable backports 5.10.218, 5.15.160, 6.1.94, 6.6.34 and 6.9.5 alongside 'Android kernels prior to the September 2024 Android Security Bulletin patch level'. Scoping the sweep to the entry's headline product name would leave every Linux server, container host and workstation in the estate reporting clean while running a kernel carrying the same defect, so the control binds to both: each Linux host taken to the backport for its own stable series, each Android device to the September 2024 bulletin patch level or later, both on the clock that opened with the 2024-08-07 KEV listing rather than on the next kernel maintenance window. Completion is measured on the kernel the machine is actually executing. patch_required_reboot is true and live_patch_available is false, with live_patch_notes recording that the vendor update requires a reboot and is the remediation — so a host whose package manager has installed the fixed kernel but has not rebooted onto it is still executing the vulnerable code and counts as exposed, and the running-kernel version, not the installed-package version, is the evidence. That distinction is where this remediation usually goes wrong: on the production hosts least willing to take an unplanned reboot, the update lands and the reboot is deferred, and the deferral is recorded as patched. Because there is no live-patch path, there is no interim state that removes the flaw from a host that cannot yet reboot — only the compensating controls on this entry.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-08-07, active_exploitation 'confirmed'; patch_available true, patch_required_reboot 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.'; affected 'Linux kernel networking (__dst_negative_advice) clears sk->dst_cache in the wrong RCU order, producing a use-after-free reachable via UDP sockets; impacts Linux and Android (Pixel and other) kernels prior to the fix'; affected_versions lists 'stable backports: 5.10.218, 5.15.160, 6.1.94, 6.6.34, 6.9.5' and 'Android kernels prior to the September 2024 Android Security Bulletin patch level'; NIST-800-53-SI-2 gap records that observed targeted exploitation preceded broad OTA availability.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The Android half of this entry is the half the operator does not control: the packet's flaw-remediation gap records that kernel remediation on mobile fleets depends on OEM backport cadence and that the observed targeted exploitation preceded broad OTA availability, so for any device whose OEM has not yet shipped the September 2024 Android Security Bulletin patch level there is no patch action available at all. On that population the fixed patch level has to function as an access condition rather than a compliance row — organizational mail, VPN and document access denied to any enrolled Android device reporting a security patch level below September 2024, enforced by the access policy itself. The distinguishing test is to enrol a device pinned below that level and confirm it is actually refused the protected resources; an estate that surfaces the stale patch level on a dashboard while the device keeps its access has recorded the exposure rather than bounded it. Two preconditions, both load-bearing here. First, this bounds what organizational data an exposed handset can reach; it does not remove the use-after-free from the device, and the device's own contents stay exposed to a local escalation. Second, the packet records limited, targeted exploitation on Android confirmed by Google's Threat Analysis Group — a device that sat below the patch level during that window and belongs to the population such campaigns target is an incident item, not a patch item, because an access condition does not evict an attacker who already reached kernel context. The patch level counts only once the update has been applied and the device restarted onto it, since patch_required_reboot is true.",
+        "evidence": "Packet: affected_versions 'Android kernels prior to the September 2024 Android Security Bulletin patch level'; affected states impact on 'Linux and Android (Pixel and other) kernels prior to the fix'; active_exploitation_notes 'Reported by Clement Lecigne of Google Threat Analysis Group and flagged by Google as under limited, targeted exploitation on Android'; NIST-800-53-SI-2 gap 'Kernel flaw remediation on mobile/embedded fleets depends on OEM backport cadence; the observed targeted exploitation preceded broad OTA availability'; AU-Essential-8-Patch gap 'Essential Eight OS-patching maturity is defined for managed desktops/servers and under-covers fragmented Android OEM patch delivery'; UK-CAF-B4 gap 'System-hardening baselines are written for managed desktops and servers and don't reach fragmented Android OEM kernels'; patch_required_reboot true.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "The packet describes the exploitation precisely enough to key on it, and precisely enough to rule out the signals that would otherwise be reached for. A local attacker manipulates UDP-socket destination-cache state so that __dst_negative_advice() releases a dst entry out of RCU order, then grooms the resulting use-after-free into kernel memory corruption and privilege escalation. On Linux hosts the rule therefore keys on that shape: an unprivileged local process driving repeated UDP socket create/connect/send and teardown against destinations that provoke route-cache negative advice — the repetition is inherent, because the operation being exploited is a race that has to be re-attempted until the timing lands — paired with the outcome the packet names, a privilege transition to kernel or root context in a process lineage that never executed a setuid binary. Both halves are required: UDP socket churn alone is ordinary on a networked host, and a credential change alone arrives with no context; it is the pairing inside a short window that separates this from either. What will not see it: poc_available is false, so there is no public exploit binary or tool name for a signature to match; nothing is compiled, no module is loaded and no on-disk file changes, so file-integrity monitoring has no artifact; and a rule that alerts on kernel panics assumes a failed attempt rather than the successful grooming the packet describes. Preconditions: this needs host audit or eBPF telemetry that was already being collected and shipped off-host before the attempt, which on shared multi-user Linux hosts is exactly where it is least often enabled, and it is generally unavailable to the operator on the Android devices in scope — which is why that population depends on the access-condition control on this entry instead. Detection does not restore the privilege boundary this flaw defeats and does not undo an escalation; it bounds the exposure to alert-and-response time in the interval before the fixed kernel and its reboot land.",
+        "evidence": "Packet: attack_vector 'A local attacker manipulates UDP-socket destination-cache state so that __dst_negative_advice() releases a dst entry out of RCU order, causing a use-after-free that is groomed into kernel memory corruption and privilege escalation'; vector text 'RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst)' and 'This old bug became visible after the blamed commit, using UDP sockets'; cwe_refs CWE-416; poc_available false; active_exploitation 'confirmed'; NIST-800-53-AC-6 gap 'Least-privilege controls do not prevent a local UAF that escalates to kernel context, since the flaw itself defeats the privilege boundary.'",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2018-0824": {
     "name": "Microsoft COM for Windows Deserialization of Untrusted Data Vulnerability",
@@ -46076,7 +47405,37 @@
         "adequate": false,
         "gap": "Account-management controls do not detect that ESXi re-authorizes an AD group purely by name; deleting and re-creating 'ESXi Admins' re-grants full admin outside normal account provisioning review."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "On an AD-integrated ESXi host the packet's grant path makes an ordinary directory operation equivalent to hypervisor root: the host gives full administrative access to members of a configured Active Directory group ('ESXi Admins' by default) matched by name, so whoever holds the AD permission to create a group with that name holds ESXi administration — which is what the packet describes the named actors doing, deleting and re-creating the group once they hold sufficient AD permissions. The control means that permission is classified and administered as a hypervisor-control-plane privilege in its own tier — just-in-time and approval-gated, held by an identity separate from routine directory administration, and enumerated explicitly rather than collapsed into 'admin' — instead of sitting inside general group-management delegation, where account-provisioning review never connects the operation to hypervisor access. That disconnect is the account-management gap this entry records. Scope the population from affected_versions, not from the headline product: ESXi 8.0 hosts reach the fix at ESXi 8.0 U3, ESXi 7.0 is recorded as having no patch with mitigation required, and VMware Cloud Foundation 4.x and 5.x AD-integrated ESXi is in scope on the same terms, so an estate that rolls 8.0 U3 and reports itself remediated leaves every 7.0 and Cloud Foundation host on the pre-fix grant path. Two preconditions decide whether this holds. patch_required_reboot is true and the packet records no live-patch path, with the vendor update requiring a reboot and being the remediation, so an 8.0 host that has taken the update but not rebooted is still running the name-matching code and must be counted as exposed. And on 7.0, where the packet states mitigation is required, repointing the host's configured admin group to a different name does not close the path — the host still matches by name, so an actor holding the AD permissions this attack already requires can create the new name just as easily. Only removing the host-administration grant from AD group membership removes the precondition, and a host that must retain AD user management stays exposed until it reaches a fixed build and reboots.",
+        "evidence": "Packet vector: a malicious actor with sufficient Active Directory permissions can gain full access to an ESXi host previously configured to use AD for user management by re-creating the configured AD group ('ESXi Admins' by default) after it was deleted from AD. affected: VMware ESXi (and vCenter-managed hosts) configured to use AD for user management, where the host grants full admin to members of a configured AD group matched by name. affected_versions: 'VMware ESXi 8.0 (fixed in ESXi 8.0 U3)', 'VMware ESXi 7.0 (no patch; mitigation required)', 'VMware Cloud Foundation 4.x / 5.x (AD-integrated ESXi)'. patch_required_reboot true; live_patch_available false; live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' The NIST-800-53-AC-2 gap states account-management controls do not detect that ESXi re-authorizes an AD group purely by name, so deleting and re-creating 'ESXi Admins' re-grants full admin outside normal account provisioning review. active_exploitation confirmed; Microsoft observed Storm-0506, Storm-1175, Octo Tempest and Manatee Tempest.",
+        "gap_closes": [
+          "NIST-800-53-AC-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet gives this entry an outcome, not just a flaw: Microsoft observed Storm-0506, Storm-1175, Octo Tempest and Manatee Tempest abusing it post-compromise to seize domain-joined ESXi hypervisors, ending in Akira and Black Basta deployment and mass-VM encryption, with CISA KEV flagging it 'Known' for ransomware. That is a hypervisor-control-plane compromise and the playbook has to exist before it happens, which is what the incident-handling and response-and-recovery gaps on this entry record as absent. Key the detection half on the behaviour the packet documents rather than on ransomware artefacts, which arrive after the encryption: deletion of the Active Directory group the host is configured to trust ('ESXi Admins' by default) followed by its re-creation, correlated with members of that group obtaining full administrative access on AD-integrated ESXi hosts. The pairing inside a short window is the distinguishing signal, because neither half is conclusive alone and nothing else is emitted — no exploit binary runs, no service crashes and no memory-corruption artefact appears; the host performs its configured group lookup and grants access exactly as designed, so file-integrity and signature-based endpoint tooling have nothing to match and a rule keyed on crashes or tool signatures would miss an attack behaving precisely as the packet describes. Size the response half to the blast radius the packet names — every VM on a seized host rather than one endpoint: invalidate the granted access and the host's AD integration, rotate credentials for every account that authenticated through an affected host during the exposure window, and rehearse recovery at fleet scale. Preconditions: this depends on directory security-event and ESXi host telemetry being collected and shipped off-host before the event, which is where a playbook written after the fact fails; and detection prevents nothing — it bounds the interval between the regrant and the encryption, and against the actors the packet names that interval is short.",
+        "evidence": "Packet active_exploitation_notes: flagged 'Known' for ransomware use in CISA KEV (added 2024-07-30); Microsoft observed Storm-0506, Storm-1175, Octo Tempest and Manatee Tempest abusing it post-compromise to seize domain-joined ESXi hypervisors, leading to Akira and Black Basta ransomware deployments and mass-VM encryption. attack_vector: after gaining a foothold with sufficient AD permissions, operators delete and re-create the 'ESXi Admins' group in Active Directory and the AD-joined host re-grants full administrative access by group name, giving hypervisor control to encrypt all hosted VMs. The NIS2-Art21-incident-handling gap states incident-handling controls do not flag AD-group re-creation as a hypervisor-takeover precursor, so the escalation goes unnoticed until ransomware fires; the UK-CAF-D1 gap states response-and-recovery planning does not anticipate hypervisor-layer admin regrant cascading into fleet-wide VM encryption, so no recovery path is pre-staged. rwep_score 79.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-D1"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "This entry's backup gap states the failure directly: backups stored on the same hypervisor datastore are encrypted alongside the VMs when this ransomware-linked bypass fires, and the outcome the packet records is Akira and Black Basta mass-VM encryption once the actor holds full administrative access on an AD-integrated ESXi host. Applied here, the control means backup copies for VMs running on AD-integrated ESXi do not live on datastores those hosts present, and the backup tier's management and storage paths are not reachable using ESXi host administration — a separate credential path and a network position the hypervisor administrator does not inherit — so that seizing the hypervisor by re-creating the trusted AD group does not also hand over the recovery. Distinguishing test: from an account holding full administrative access on a staging AD-integrated host, attempt to enumerate, mount, alter or delete the backup repository for the VMs that host runs; anything reachable from that position is inside this CVE's blast radius, and a backup attestation showing only that jobs complete on schedule passes cleanly while every copy sits where the takeover reaches. Preconditions: this preserves a recovery path, it does not prevent the takeover and it does not repair the name-based grant that causes it. It also does nothing for a VM whose only protection is a snapshot on the datastore it runs from — that copy is inside the encrypted set by definition — and its value is bounded by whether restore has been exercised at the scale this flaw implies, an entire hypervisor's VM population rather than a single file.",
+        "evidence": "Packet AU-Essential-8-Backup gap: 'Essential-Eight backup guidance does not require offline/immutable copies resilient to an ESXi admin-takeover, so backups stored on the same hypervisor datastore are encrypted alongside the VMs when this ransomware-linked bypass fires.' active_exploitation_notes record Akira and Black Basta ransomware deployments and mass-VM encryption after actors seized domain-joined ESXi hypervisors; attack_vector ends in the attacker holding hypervisor control to encrypt all hosted VMs. cisa_kev true with kev_date 2024-07-30 and ransomware use flagged 'Known'; rwep_score 79. affected covers VMware ESXi (and vCenter-managed hosts) configured to use Active Directory for user management.",
+        "gap_closes": [
+          "AU-Essential-8-Backup"
+        ]
+      }
+    ]
   },
   "CVE-2023-45249": {
     "name": "Acronis Cyber Infrastructure (ACI) Insecure Default Password Vulnerability",
@@ -46364,7 +47723,22 @@
         "adequate": false,
         "gap": "Flaw remediation shipped as MS13-008, but the impacted IE is end-of-life; SI-2 does not force retirement of the unsupported browser that still renders attacker HTML."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "Both halves this control turns on are stated in the packet. patch_available is true — the flaw-remediation gap names MS13-008 as the fix that shipped — and the exploitation notes state that the impacted Internet Explorer is end-of-life and should be disconnected. So on a host still running Internet Explorer 6, 7 or 8, taking the update carrying this fix is an interim state; the terminal state is removing that browser from the host, because it remains exposed not only to this CDwnBindInfo use-after-free but to everything found in that rendering engine since its last servicing. Scope to what affected and affected_versions name: Internet Explorer 6, 7 and 8. The packet ties the use-after-free to the IE 6-8 rendering engine and gives no mapping into any other product, so treating every browser or HTML-rendering component in the estate as an instance of this CVE manufactures removal work against software no evidence implicates. Operationally: enumerate every host with IE 6, 7 or 8 installed, put each on a dated removal schedule measured against the 2024-07-23 KEV listing, and — because delivery here is a crafted page served from a site the victim trusts, which is how the December 2012 watering-hole compromise reached its targets — ensure that until removal completes IE 6-8 is not the browser handling untrusted web content, with browsing moved to a maintained one. That interim restriction is the disable-or-limit-legacy-browsers action the application-hardening gap names as missing, and its precondition must be stated: changing which browser is the default does not remove IE 6-8 from the host, so any application or workflow that launches it directly still reaches the same engine, and the restriction holds only where policy enforces it rather than user habit. Completion on the interim patch half is measured on the running host, not the update record: live_patch_available is false and the packet records that the vendor update requires a reboot and is the remediation, so a host that installed it without rebooting is still executing the vulnerable code. And because exploitation is confirmed with a public proof of concept and delivery is attacker-controlled web content, a host that browsed with IE 6-8 during the exposure window belongs on the incident path rather than being closed on the patch record — an update applied after the fact does not remove what a successful drive-by left behind.",
+        "evidence": "Packet fields: vector — \"Use-after-free vulnerability in Microsoft Internet Explorer 6 through 8 allows remote attackers to execute arbitrary code via a crafted web site that triggers access to an object that (1) was not properly allocated or (2) is deleted, as demonstrated by a CDwnBindInfo object, and exploited in the wild in December 2012.\" affected_versions: Internet Explorer 6, Internet Explorer 7, Internet Explorer 8; CWE-416; cvss 8.8, rwep_score 77; poc_available true; cisa_kev true with kev_date 2024-07-23 and active_exploitation confirmed. active_exploitation_notes — \"Exploited in the wild in December 2012 via watering-hole drive-by pages (notably the Council on Foreign Relations compromise) using a CDwnBindInfo use-after-free; re-added to CISA KEV 2024-07-23. The impacted Internet Explorer is end-of-life and should be disconnected.\" patch_available true, patch_required_reboot 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.\" framework_control_gaps: NIST-800-53-SI-2 — \"Flaw remediation shipped as MS13-008, but the impacted IE is end-of-life; SI-2 does not force retirement of the unsupported browser that still renders attacker HTML\"; ISO-27001-2022-A.8.8 — \"does not compel removal of legacy IE 6-8 clients, leaving a client-side RCE surface active\"; NIS2-Art21-vulnerability-management — duties \"do not specifically mandate decommissioning end-of-life browsers that remain drive-by exploitable\"; UK-CAF-B4 — the principle \"lacks a control forcing retirement of end-of-life clients, so IE 6-8 keeps rendering attacker HTML from watering-hole sites long after MS13-008\"; AU-Essential-8-App-Hardening — \"Application-hardening (disable/limit legacy browsers, block untrusted script) is exactly the missing control that would have blunted the drive-by.\"",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2022-22948": {
     "name": "VMware vCenter Server Incorrect Default File Permissions Vulnerability",
@@ -46873,7 +48247,39 @@
         "adequate": false,
         "gap": "Security monitoring focused on network indicators misses client-side script execution within the webmail DOM, delaying detection of mailbox exfiltration."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The distinguishing fact on this entry is the interval. The packet records the fix in Roundcube Webmail 1.3.12 and 1.4.5 and a KEV listing dated 2024-06-26, so the KEV clock opens on a fix that has been available for years — which makes the work here discovery rather than scheduling. The packet's own flaw-remediation gap names it: self-hosted Roundcube instances go long-unpatched, and the flaw reached KEV four years after the fix shipped. So the SLA's first deliverable is an enumeration of every Roundcube deployment the organisation's users can reach, including the instances that arrived with a hosting package, run on a departmental or project server, or survived a mail migration as a fallback interface — an SLA measured against a list that contains only the sanctioned webmail host will report complete while the exposed instance is one nobody owns. Record the running version of each against 1.3.12 or 1.4.5 and later, and measure completion on the version the instance actually serves to a browser rather than the version in a package manifest or a change ticket; the packet registers no live-patch path, so an instance whose files were replaced while the old code is still being served has not been remediated. Because the packet records confirmed exploitation with a public PoC, and describes the outcome as mail, contacts and session tokens taken from the authenticated session, an instance found below the fixed version is an incident question as well as a patch item: updating the code closes the preview path but tells you nothing about what was read from the mailboxes while it was open, so the sessions and credentials that instance carried need invalidating and rotating rather than being closed on the version number.",
+        "evidence": "The packet's vector records an issue in Roundcube Webmail before 1.3.12 and 1.4.x before 1.4.5, with XSS via a malicious XML attachment because text/xml is among the allowed types for a preview; affected_versions lists < 1.3.12 and 1.4.0 through 1.4.4. cisa_kev true with kev_date 2024-06-26, active_exploitation confirmed, poc_available true, CVSS 6.1, RWEP 64. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes stating there is no live-patching primitive for this product and the vendor update is the remediation. The cited flaw-remediation gap states the fix shipped in 2020 but the flaw reached KEV in 2024, showing self-hosted Roundcube instances go long-unpatched; the cited technical-vulnerability-management gap states a 'medium' XSS is often deprioritized but in webmail yields full mailbox compromise for high-value diplomatic targets. attack_vector states attacker JavaScript runs in the authenticated webmail session and can steal mail, contacts and session tokens; active_exploitation_notes records Roundcube XSS flaws being chained by espionage actors against government and diplomatic targets, with KEV ransomware status Unknown.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Applied to Roundcube, this control requires the webmail tier's per-request access logs — the web-server request log for the webmail vhost plus the application's own action log, not the login events — to be forwarded to a SIEM off the webmail host, with retention long enough to cover an instance discovered years after the fix shipped. The reason is the exact shape of this exploit: the packet has attacker JavaScript executing when the victim previews a text/xml attachment, running inside the victim's own already-authenticated session. So the requests that steal the mailbox are indistinguishable at the authentication layer from the victim working — one successful login is recorded, and everything after it belongs to a valid session. What an exploit doing exactly what the packet describes emits is a request stream: a fetch of an attachment part whose declared type is text/xml as the message is previewed, followed within that same session by a run of message-fetch, contact and attachment requests at a pace and breadth that does not match a person reading mail, which is the packet's own stated outcome of mail, contacts and session tokens taken from the session. That pairing — the preview of an XML part, then bulk reads in the same session — is the rule; either half alone is ordinary webmail traffic. Note what will not see it: no file lands on the host and no process is spawned, so signature-based endpoint tooling has no artifact to match; the traffic is TLS to the organisation's own webmail from the user's normal client, so network-indicator monitoring sees nothing anomalous, which is precisely the security-monitoring gap the packet records; and alerting on failed logins or on new authentications would miss an attempt that behaves exactly as described. Precondition: per-request logging has to be enabled and shipped off-host before the attempt. A deployment that logs only authentication, or that keeps its request log locally on the very webmail server the attacker's script is operating inside, produces nothing for an after-the-fact rule to run against. And detection does not prevent the theft — the script runs the moment the message is previewed — so this bounds the exposure to alert-and-response time (session invalidation, credential rotation, mailbox review) during the period before the 1.3.12 / 1.4.5 update removes the preview path.",
+        "evidence": "The packet's attack_vector states an attacker emails a crafted text/xml attachment and that when the victim previews it in a vulnerable Roundcube version attacker JavaScript runs in the authenticated webmail session and can steal mail, contacts and session tokens; the vector records that text/xml is among the allowed types for a preview. The cited security-monitoring gap states that monitoring focused on network indicators misses client-side script execution within the webmail DOM, delaying detection of mailbox exfiltration; the cited network-security gap states that network-security measures do not inspect authenticated in-app script execution, so an XSS running inside the trusted webmail session evades perimeter controls. active_exploitation is confirmed with poc_available true, kev_date 2024-06-26, and active_exploitation_notes recording Roundcube XSS being chained by espionage actors to steal mail and session data from government and diplomatic targets. patch_available true with the fixed releases recorded as 1.3.12 and 1.4.5, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-119",
+        "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
+        "description": "The decision this flaw turns on is a rendering decision taken from attacker-supplied metadata: the packet states plainly that text/xml is among the allowed types for a preview, so the attachment's declared content type is what selects the inline-preview path that carries the payload, and the sender controls that value. Applied to this product, the control requires that whether an email attachment is treated as inert or as active content be established outside the message — by the mail boundary inspecting what the attachment actually is — rather than inherited from the type the sender declared, and that the resulting classification survive the container the attachment arrives in, so an XML document nested in an archive or renamed is still handled as active content. The mail boundary is where this is enforceable, because it is the only point that sees the message before it is stored in a mailbox where the victim can preview it. The two gaps this closes are exactly that omission: the packet records that malicious-code and attachment inspection typically does not treat a benign-looking XML attachment as active content, and that Essential-Eight user-application hardening does not treat a text/xml email attachment as active content — so both attest clean while the script-bearing preview reaches the reading pane. Distinguishing test: send an XML attachment carrying a script payload through each mail ingress path to a test mailbox, once plain and once inside an archive, and confirm it arrives classified as active content — quarantined, stripped, or marked so the client will not inline it — rather than confirming only that an attachment policy exists in the console. Precondition, and it is the load-bearing one: this bounds delivery, it does not repair the sanitizer. A gateway rule applied today does nothing about messages already sitting in mailboxes, and this flaw fires when a stored message is previewed, so with confirmed exploitation and a public PoC on the record, mailboxes served by a vulnerable instance need reviewing rather than being closed on the new rule. It also does not cover mail arriving by a path the gateway does not front. Only the update to 1.3.12 or 1.4.5 removes the preview path itself.",
+        "evidence": "The packet's vector states the XSS occurs via a malicious XML attachment because text/xml is among the allowed types for a preview, in Roundcube Webmail before 1.3.12 and 1.4.x before 1.4.5. The cited malicious-code-protection gap states that malicious-code / attachment inspection typically does not treat a benign-looking XML attachment as active content, so the script-bearing preview slips past content filtering; the cited user-application-hardening gap states Essential-Eight hardening does not treat a text/xml email attachment as active content, so the script-bearing XML previews in Roundcube despite hardening. attack_vector records that the payload executes when the victim previews the attachment, running in the authenticated webmail session. active_exploitation confirmed, poc_available true, kev_date 2024-06-26, CVSS 6.1, RWEP 64. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes recording the vendor update as the remediation.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2022-2586": {
     "name": "Linux Kernel Use-After-Free Vulnerability (CVE-2022-2586)",
@@ -46910,7 +48316,40 @@
         "adequate": false,
         "gap": "Least-functionality controls rarely disable unprivileged user namespaces (kernel.unprivileged_userns_clone), which is what grants the CAP_NET_ADMIN needed to reach the nf_tables path."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-130",
+        "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "description": "The packet states this flaw's precondition rather than leaving it implicit: the local attacker needs CAP_NET_ADMIN before the netfilter nf_tables configuration path is reachable at all, and the packet's attack vector says that capability is often obtained through an unprivileged user namespace. For this CVE the control means unprivileged user-namespace creation (kernel.unprivileged_userns_clone) is disabled on every Linux host whose workloads do not genuinely require it, and each container is confined with an LSM profile plus a seccomp profile that does not hand it CAP_NET_ADMIN — because on a host still running a kernel without the nf_tables fix, that combination removes the entry condition while the reboot onto the fixed kernel is pending. On a container host the boundary claim itself is what is at stake: a confined workload able to create a user namespace holds CAP_NET_ADMIN inside it, creates an nft object referencing a set in a different table, deletes that table to free the set, and reclaims the dangling object as host root, so the confinement is not a boundary and the kernel is the only thing left. Distinguishing test: from a representative unprivileged container or an ordinary user session on a staging host running an affected kernel, create a user namespace and attempt the cross-table nft object/set configuration the packet describes, and confirm it is refused before the set can be freed. Two preconditions, both routinely skipped when this control is claimed. It closes only the user-namespace route — a process that already holds CAP_NET_ADMIN in the host's initial namespace (a container deliberately granted NET_ADMIN, a firewall or network-management daemon, a service account carrying the capability) reaches the identical path with unprivileged userns disabled, so that population must have the capability withdrawn or be counted as exposed until it reboots onto the fixed kernel. And it is unavailable on hosts that need unprivileged user namespaces to function — rootless container runtimes, build and CI hosts, sandboxes built on the same primitive — where the interim measure is detection plus the reboot, not this. Note also what is not available here: nf_tables is the host's own packet-filtering path, so unloading or blacklisting the subsystem is not the least-functionality answer the way an unused driver would be.",
+        "evidence": "Packet attack_vector: 'A local user obtains CAP_NET_ADMIN (often via an unprivileged user namespace), creates an nft object referencing a set in another table, deletes that table to free the set, and reclaims the dangling object to corrupt kernel memory and escalate to root.' The NIST-800-53-CM-7 gap records that 'Least-functionality controls rarely disable unprivileged user namespaces (kernel.unprivileged_userns_clone), which is what grants the CAP_NET_ADMIN needed to reach the nf_tables path'; the UK-CAF-B4 gap records that 'System-security assurance for Linux hosts seldom disables unprivileged user namespaces, the very setting that grants the CAP_NET_ADMIN this nf_tables use-after-free needs; CAF sets no requirement for that compensating control while the KEV-listed kernel LPE awaits a reboot'; the NIS2-Art21-patch-management gap records that patch-management obligations 'do not mandate the compensating control (disabling unprivileged userns) while kernel updates are pending.' An interim measure is needed because patch_available is true but patch_required_reboot is true and live_patch_available is false, with live_patch_notes stating 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' cisa_kev true (kev_date 2024-06-26), active_exploitation confirmed, poc_available true, rwep_score 73, cvss 7.8.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "This is a local privilege escalation in the Linux kernel's netfilter nf_tables subsystem, so for this CVE the control means the distro kernel update carrying the backported nf_tables fix is driven across every affected host on the clock that opened with the 2024-06-26 KEV listing, rather than folded into the next quarterly maintenance window — with completion measured against the kernel the host is actually executing, not against the kernel package a configuration-management console reports as installed. The packet makes that distinction load-bearing: patch_required_reboot is true and live_patch_available is false, with the entry recording that the vendor update requires a reboot and is the remediation, so a host that has taken the new kernel package but has not rebooted onto it still runs the vulnerable code and must be counted as exposed. On the multi-user and long-uptime hosts most exposed to a local escalation the reboot is precisely the step that gets deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Scoping cannot be done by kernel version number alone: the packet records the defect as present since v3.16-rc1 and lists distro kernels prior to the backported nf_tables patch (RHEL/Ubuntu/SUSE) as a separate affected population, so a vendor kernel with a lower upstream base may already carry the backport while a higher-numbered one does not — each host has to be compared against the fixed build its own distro published for that kernel line. Enumerate first the hosts where the flaw's precondition is the normal operating state rather than an anomaly: shared and multi-user systems, CI and build runners, and container hosts, anywhere unprivileged local code runs by design. Priority follows the packet rather than the CVSS band — a 7.8 with a local vector reads as a deferrable endpoint item, while the packet records confirmed active exploitation, a public PoC and a KEV listing for a primitive that converts any code execution as a local user into root, which is what makes it a containment step for a chain rather than a standalone item.",
+        "evidence": "Packet fields: patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' cisa_kev true with kev_date 2024-06-26; active_exploitation confirmed; active_exploitation_notes 'Added to CISA KEV 2024-06-26 as actively exploited. A use-after-free in the Linux kernel nf_tables (nft_object cross-table set reference) lets a local attacker with CAP_NET_ADMIN escalate to root. Ransomware association is unconfirmed.' poc_available true; cvss 7.8; rwep_score 73. Scope from affected ('Present since v3.16-rc1') and affected_versions ('Linux kernel >= 3.16-rc1 prior to the netfilter fix', 'distro kernels prior to the backported nf_tables patch (RHEL/Ubuntu/SUSE)'). The NIST-800-53-SI-2 gap records that 'Kernel patch-deployment cadence and reboot windows leave hosts exposed long after a working public LPE exists'; the AU-Essential-8-Patch gap that 'Patch-application timeframes for OS/kernel are measured in weeks, exceeding the exploitation window for a KEV-listed kernel LPE'; the ISO-27001-2022-A.8.8 gap that vulnerability management 'typically prioritizes remote flaws, deprioritizing a local kernel UAF that is in fact a ready root primitive for post-exploitation.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "On hosts that cannot yet take the reboot, and on the hosts where unprivileged user namespaces must stay enabled for rootless containers or build sandboxes, detection is the only interim measure left — and the packet describes the exploitation behaviour precisely enough to key on it instead of on a guess. The rule keys on the sequence the packet's attack vector states: an unprivileged uid creating a user namespace, followed within the same session lineage by nf_tables netlink configuration traffic that creates an nft object referencing a set belonging to a different table and then deletes that table, paired with the outcome the packet names — a privilege transition to uid 0 in a process descended from that non-root session. Both halves are needed. Netlink nf_tables configuration on its own is what ordinary firewall tooling does all day on a firewall or container host, and a uid-0 transition on its own arrives with no context; it is the pairing inside a short window, from a session that began unprivileged, that separates this exploit from routine administration. Note what will not see it: nothing is compiled, no kernel module is loaded, no setuid binary changes, and the attacker uses the kernel's normal configuration interface, so file-integrity monitoring and signature-matching endpoint tooling have no artifact to match, and a rule written against process crashes or named exploit tooling would miss an attempt that behaves exactly as the packet describes — with poc_available true, the exact sequence is public and need not resemble any particular tool. Preconditions: this requires host audit or eBPF telemetry already being collected and shipped off-host before the attempt, which on shared multi-user hosts is exactly where it is least often enabled, and a rule authored after the fact against telemetry nobody collected produces nothing. Detection also does not prevent the escalation and does not undo root already obtained — it bounds the window to alert-and-response time during the period before the host reboots onto the fixed kernel.",
+        "evidence": "Packet attack_vector: 'A local user obtains CAP_NET_ADMIN (often via an unprivileged user namespace), creates an nft object referencing a set in another table, deletes that table to free the set, and reclaims the dangling object to corrupt kernel memory and escalate to root.' active_exploitation confirmed and poc_available true. The interim window exists because patch_required_reboot is true and live_patch_available is false ('No live-patching primitive for this product; the vendor update requires a reboot and is the remediation'). The NIS2-Art21-patch-management gap records that 'Patch-management obligations do not mandate the compensating control (disabling unprivileged userns) while kernel updates are pending' — this control covers that pending window on the hosts where disabling unprivileged user namespaces is not available.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2022-24816": {
     "name": "OSGeo GeoServer JAI-EXT Code Injection Vulnerability",
@@ -47280,7 +48719,39 @@
         "adequate": false,
         "gap": "Least-functionality controls rarely disable unprivileged user namespaces (user.max_user_namespaces), leaving the nf_tables attack surface reachable to any local user."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-002",
+        "name": "LIVE-PATCH-CAPABILITY",
+        "description": "Four of the framework gaps cited on this entry say the same thing in four vocabularies: the nf_tables fix requires a reboot and Linux fleets do not take reboots on a KEV clock, so a ransomware-associated privilege escalation with a reliable public exploit stays live between assessment cycles. This packet is one of the few where that gap has a direct answer, because live_patch_available is true — the notes record that distributions shipping kernel livepatch (Ubuntu Livepatch, Oracle Ksplice, kpatch) can apply the nf_tables fix without reboot. For this CVE the control means the livepatch capability is deployed and exercised on production Linux hosts before the next kernel KEV listing, not procured in response to one: a capability first attempted during an incident is not a capability. Completion must be measured on the kernel that is running, since the whole point of the control is decoupling remediation from the reboot — a host whose fixed kernel package is installed but which is still executing the pre-fix image is exposed, and a host carrying the livepatch is remediated even though its package version has not moved. Preconditions, and both matter operationally. The livepatch path exists only where the distribution ships a livepatch stream carrying this specific nf_tables fix; a custom-built kernel, an unsupported release, or a host without the livepatch service has no such path and must take the reboot the packet records, so the fleet has to be split into those two populations rather than assumed uniform. And a livepatch covers the kernel running now — the on-disk kernel still has to reach a build carrying the fix (upstream commit f342de4e2f33e0e39165d8639387aa6c19dff660), so the reboot is deferred by this control, not cancelled by it.",
+        "evidence": "Packet: live_patch_available true; live_patch_notes: 'Distributions shipping kernel livepatch (Ubuntu Livepatch, Oracle Ksplice, kpatch) can apply the nf_tables fix without reboot; disabling unprivileged user namespaces is an immediate mitigation.' patch_available true, patch_required_reboot true. CISA KEV 2024-05-30; active_exploitation confirmed with CISA flagging known ransomware use; poc_available true with a widely-shared public exploit described as a reliable post-compromise privilege-escalation primitive across many distributions. affected_versions: Linux kernel 3.15 through 6.8-rc1 (prior to commit f342de4e2f33e0e39165d8639387aa6c19dff660). Cited gaps: SI-2 (kernel patching lags a public exploit within the KEV window), AU-Essential-8-Patch (OS-patch timelines do not match rapid weaponization), NIS2-Art21-patch-management (SLAs lag observed ransomware-linked exploitation), UK-CAF-B4 (patch expectations assume a maintenance-reboot window fleets rarely hit promptly).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-130",
+        "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "description": "The packet states the reach path rather than leaving it implicit: an unprivileged local user, often via an unprivileged user namespace, crafts nf_tables rules that make nf_hook_slow() double-free on an NF_DROP verdict carrying a drop error resembling NF_ACCEPT, and lands as root. On a container host that is the escape case — a confined workload able to create a user namespace reaches the kernel's netfilter code and becomes host root, so the isolation the deployment is designed around is not a boundary and the kernel is the only thing left. For this CVE the control means unprivileged user-namespace creation is disabled on every host whose workloads do not genuinely require it (the least-functionality gap on this entry names user.max_user_namespaces as the setting nobody sets), and each container is confined by three separate mechanisms that are not substitutes for one another: a mandatory-access-control profile (AppArmor or SELinux), a seccomp profile restricting the syscalls the workload may issue, and the runtime capability policy that drops the capabilities it does not need. The third is the one that bears on this path and the one most often assumed to be covered by the second — seccomp filters syscalls and cannot drop a capability, so a workload can satisfy a MAC-plus-seccomp requirement and still hold the network-admin capability that the precondition below records as retaining the primitive. Drop it explicitly in the capability policy for every workload that does not administer networking. Distinguishing test: from inside a representative unprivileged container on a staging host, attempt to create a user namespace and then program an nf_tables rule set, and confirm the attempt is refused before any verdict reaches the vulnerable path — a fleet that passes image-scanning and RBAC audits while permitting unprivileged user-namespace creation is still handing every confined workload this primitive. Preconditions, stated plainly because this control is easy to over-claim. The packet says 'often via an unprivileged user namespace', not always: disabling the namespace removes the usual reach path, it does not repair nft_verdict_init(), so any local context that still reaches nf_tables rule creation — a workload that legitimately requires user namespaces, or one holding network-admin capability by design — retains the primitive. It also does nothing about an attacker already resident, and nothing about one who has already escalated. Treat it as the immediate mitigation the packet names for the window before the livepatch or the fixed kernel and its reboot land, not as closure.",
+        "evidence": "Packet attack_vector: 'An unprivileged local user (often via an unprivileged user namespace) crafts nf_tables rules that make nf_hook_slow() double-free on an NF_DROP verdict carrying a drop error resembling NF_ACCEPT, corrupting kernel memory to escalate to root.' live_patch_notes: 'disabling unprivileged user namespaces is an immediate mitigation'. Cited gap NIST-800-53-CM-7: 'Least-functionality controls rarely disable unprivileged user namespaces (user.max_user_namespaces), leaving the nf_tables attack surface reachable to any local user.' active_exploitation confirmed with known ransomware use; poc_available true; patch_required_reboot true; live_patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-CM-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this CVE the usual vulnerability-management evidence — a scan reporting the installed kernel package version — is wrong in both directions at once, which is why the technical-vulnerability-management gap here is about under-tracking rather than about speed. patch_required_reboot is true, so a host that installed the fixed kernel package and has not rebooted reads as patched while it is still executing the vulnerable nf_tables code and is fully exploitable by any local user. live_patch_available is true, so a host carrying the Ubuntu Livepatch, Ksplice or kpatch fix reads as unpatched while its running kernel is actually fixed. An A.8.8 attestation built on either reading describes something other than the fleet's exposure. For this CVE the control means the scan is taken against the running kernel and its livepatch state, and the version judgement is made against the distribution's build carrying the backport of commit f342de4e2f33e0e39165d8639387aa6c19dff660 — not against upstream 6.8-rc1, because distribution kernels carry the fix on their own version numbers and an 'older than 6.8-rc1' rule misjudges every one of them. It must also treat a host that has only the mitigation the packet names, unprivileged user namespaces disabled, as mitigated rather than remediated, so the two states stay distinguishable on the report. Distinguishing test: stage one host with the fixed package installed but not rebooted and one host livepatched without the package upgrade, run the scan against both, and confirm the first is reported exposed and the second remediated; a scanner that gets either backwards is generating the compliance record while real exposure is unknown. Precondition: this is a measurement control. It remediates nothing on its own — its whole value is that the livepatch and reboot work driven by the other controls on this entry can be verified rather than assumed.",
+        "evidence": "Packet: patch_available true, patch_required_reboot true, live_patch_available true, live_patch_notes naming Ubuntu Livepatch, Oracle Ksplice and kpatch as able to apply the nf_tables fix without reboot and disabling unprivileged user namespaces as an immediate mitigation. affected_versions: Linux kernel 3.15 through 6.8-rc1 (prior to commit f342de4e2f33e0e39165d8639387aa6c19dff660). Cited gap ISO-27001-2022-A.8.8: 'Technical-vulnerability management on Linux fleets under-tracks kernel LPE flaws that require reboots to remediate.' CISA KEV 2024-05-30; active_exploitation confirmed with known ransomware use; poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-24919": {
     "name": "Check Point Quantum Security Gateways Information Disclosure Vulnerability",
@@ -48254,7 +49725,32 @@
         "adequate": false,
         "gap": "Print Spooler should be disabled on servers that do not print; leaving the service enabled by default preserves the escalation surface this control is meant to remove."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The remediation for this CVE is the Windows cumulative update, and the population to sweep comes from affected_versions rather than from the gap prose: Windows 10, Windows 11 and Windows Server with the Print Spooler service enabled on a build predating the October 2022 cumulative update. A sweep scoped to servers alone, which is how the least-functionality gap phrases the problem, reports clean across an estate whose exposure is mostly Windows 10 and Windows 11 endpoints. Completion is measured per host on the build the machine is actually executing after its restart, never on approved or downloaded in the management console: the packet registers no live-patching primitive for this product and states the vendor update requires a reboot and is the remediation, so a host that installed the update and has not rebooted still runs the vulnerable Spooler and must be counted as exposed. The clock is the 2024-04-23 KEV listing, roughly eighteen months after the fix shipped, and the reason for the lag is recorded in the packet itself: a 7.8 local elevation fell below the internet-facing fast lane and rode the routine cadence, which is the window the packet says was exploited. The control's second half is the load-bearing one here. GooseEgg is a post-compromise tool, so the attacker already holds a foothold when the escalation runs; tightening account privilege does not contain it, which is precisely why the least-privilege gap cited on this entry can pass its attestation while the flaw stays fully exploitable to SYSTEM. Priority follows the packet rather than the CVSS band: confirmed exploitation by a named state actor over more than a year makes this a containment step for an intrusion chain, not a routine endpoint item.",
+        "evidence": "Packet: CWE-269 improper privilege management in the Windows Print Spooler service, where an attacker modifies a JavaScript constraints file and the service executes it with SYSTEM-level permissions. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' cisa_kev true, kev_date 2024-04-23, active_exploitation confirmed, cvss 7.8, rwep_score 55, poc_available false. affected_versions: 'Windows 10, Windows 11, and Windows Server with the Print Spooler service enabled (pre-October 2022 cumulative update)'. NIST-800-53-SI-2 gap: 'The flaw was patched in October 2022 yet was exploited into 2024; environments that deferred the Print Spooler update remained vulnerable long past the fix'. AU-Essential-8-Patch gap: this 7.8 local EoP 'fell below the internet-facing fast lane and rode the routine cadence'. NIST-800-53-AC-6 gap: 'Least-privilege cannot stop GooseEgg escalating a foothold to SYSTEM once the vulnerable Print Spooler is reachable'. active_exploitation_notes: exploited by Forest Blizzard (APT28/STRONTIUM) using a custom post-compromise tool named GooseEgg, per Microsoft Threat Intelligence in April 2024.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scan that marks a Windows host compliant because the October 2022 or later cumulative update is present is paper compliance for this CVE in two distinct ways the packet names. First, the packet records no live-patching primitive and a vendor update that requires a reboot, so a host carrying the update but not yet restarted still executes the vulnerable Spooler; the test must read the running build after restart, not the approved-update list. Second, the packet's own least-functionality and system-security gaps state that Print Spooler should be disabled on servers that do not print and that assurance must include disabling unnecessary services, not only patch tracking. So the operational test has to report, per host, whether the Spooler service is running on a machine with no print role alongside its running build. The distinguishing test: take a Windows Server with no print role that the scan reports compliant, then query the Spooler service state and the executing build on that same host; a least-functionality attestation recorded as met and a patch report showing the update approved both read clean while an enabled Spooler sits on a pre-restart build. Precondition, and it is the half most often over-claimed: disabling the service removes the escalation path only on hosts that genuinely do not print. On print servers and on the Windows 10 and Windows 11 endpoints that print, the service must stay enabled, and there the update plus its reboot is the only remediation, not the service-state check. And because the packet describes GooseEgg as a post-compromise tool run after an initial foothold, stopping the Spooler does not evict an attacker who already reached SYSTEM on that host: a host that was exposed while the service ran belongs on the incident path rather than being closed on a service-state report.",
+        "evidence": "Packet NIST-800-53-CM-7 gap: 'Print Spooler should be disabled on servers that do not print; leaving the service enabled by default preserves the escalation surface this control is meant to remove.' UK-CAF-B4 gap: 'System-security assurance must include disabling unnecessary services like Print Spooler, not only patch tracking, to remove APT28's post-compromise escalation path.' live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' patch_required_reboot true, live_patch_available false. affected_versions: 'Windows 10, Windows 11, and Windows Server with the Print Spooler service enabled (pre-October 2022 cumulative update)'. attack_vector: 'After gaining an initial foothold, APT28's GooseEgg tool modifies a Print Spooler JavaScript constraints file and causes the Spooler service to execute it with SYSTEM permissions, spawning attacker-chosen applications, backdoors, and credential-theft tooling.' active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-3400": {
     "name": "Palo Alto Networks PAN-OS Command Injection Vulnerability",
@@ -49435,7 +50931,31 @@
         "adequate": false,
         "gap": "Identity-management control does not, by itself, mandate channel binding / EPA for legacy NTLM, leaving relayed authentication to Exchange viable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "For Microsoft Exchange Server the configuration-side path this control names is Extended Protection, and the packet makes it the load-bearing half rather than an optional extra: the affected condition is stated as Exchange Server where Extended Protection is not enforced, and the flaw-remediation gap records that applying the Exchange update is not enough on its own because Extended Protection must be actively enabled. Bound to this deployment that means every Exchange Server 2016 and 2019 host is inventoried by whether Extended Protection is enforced on the web endpoints that terminate authentication — Exchange Web Services first, because EWS is the endpoint the packet names as the relay target — and that this state is tracked, tested and driven as its own item rather than riding along with the CU14 upgrade project, since the packet describes CU14 as enabling Extended Protection by default rather than as the only route to it. Extended Protection is also exactly what the identity controls cited on this entry are missing: the packet's federated identity-management gap says the control does not by itself mandate channel binding for legacy NTLM, and channel binding at the EWS endpoint is what makes a relayed NetNTLM authentication fail instead of succeeding as the victim. Read the control's name carefully against this packet: live_patch_available is false, so enabling Extended Protection is a configuration change, not a vendor live-patch primitive, and it does not substitute for the remediation the packet records — applying the fixed release and rebooting. That is the precondition on treating this as closure: patch_required_reboot is true, so a server that took the February 2024 update but has not restarted is still running the vulnerable code. A second precondition is that Extended Protection bounds the relay into Exchange and does nothing about the step the attack begins with; the packet's network-security gap names disabling or segmenting NTLM and blocking authentication-coercion RPC as separate measures this control does not supply. And because active exploitation against internet-facing Exchange is confirmed, a server that was reachable while Extended Protection was off belongs on the incident path rather than being closed on the configuration change.",
+        "evidence": "Packet affected: 'Microsoft Exchange Server; when Extended Protection is not enforced, an attacker can relay a coerced NTLM authentication to Exchange Web Services and act as the victim (privilege escalation). Fixed by CU14 enabling Extended Protection by default.' affected_versions: 'Exchange Server 2016 and 2019 without Extended Protection (prior to Feb 2024 update / CU14)'. NIST-800-53-SI-2 gap: 'Applying the Exchange update is not enough on its own — Extended Protection must be actively enabled — so a standard patch-and-reboot SLA leaves the relay path open even on \"patched\" servers.' ISO-27001-2022-A.5.16-Federated gap: 'Identity-management control does not, by itself, mandate channel binding / EPA for legacy NTLM, leaving relayed authentication to Exchange viable.' NIS2-Art21-network-security gap names disabling/segmenting NTLM and blocking authentication-coercion RPC as what stops the relay chain. attack_vector: an attacker coerces a privileged account to authenticate (e.g. PetitPotam) then relays the NTLM credential to the Exchange EWS endpoint. Remediation state: patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' CWE-287, CISA KEV listed 2024-02-15, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 80.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-IA-2",
+          "ISO-27001-2022-A.5.16-Federated",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance shape this control exists to catch is precisely the failure the packet records for this CVE. A scanner that reads the Exchange build, sees the February 2024 update present and reports the server remediated has measured the one thing that does not settle the question: the condition the packet ties exploitation to is Extended Protection not being enforced, and that is a configuration state the build number does not carry. The operational test for this product is therefore per-server and per-endpoint — for every Exchange Server 2016 and 2019 host, produce the enforced/not-enforced state of Extended Protection on the web endpoints that accept authenticated traffic, Exchange Web Services first because the packet names EWS as the relay target, and treat a host that cannot produce that state as unverified rather than as compliant. The distinguishing test keys on the behaviour the packet documents rather than on a version string or a tool signature: on a staging Exchange server, coerce an account to authenticate and relay that NetNTLM authentication to the EWS endpoint — the exact sequence in the packet's attack vector, using the publicly available coercion and relay tooling its application-hardening gap names — and confirm the relayed authentication is refused rather than accepted as the victim. An estate whose patch report is green and whose user-application-hardening attestation covers Exchange passes both checks while that relay still succeeds, which is what makes the version-only scan and the hardening attestation paper compliance here. The same inventory must carry restart state alongside configuration state: the packet gives patch_required_reboot true with no live-patch path and states remediation requires applying the fixed release and rebooting, so a host that has installed the update and not restarted onto it is not remediated no matter what either check reports.",
+        "evidence": "Packet NIST-800-53-SI-2 gap: 'Applying the Exchange update is not enough on its own — Extended Protection must be actively enabled — so a standard patch-and-reboot SLA leaves the relay path open even on \"patched\" servers.' AU-Essential-8-App-Hardening gap: 'Application-hardening maturity does not enumerate Exchange Extended Protection or NTLM channel-binding, so a \"hardened\" server still relays a coerced NetNTLM authentication to EWS via public impacket/PetitPotam tooling; patching without enabling EPA leaves the relay path open.' affected_versions: 'Exchange Server 2016 and 2019 without Extended Protection (prior to Feb 2024 update / CU14)'. attack_vector: coerce a privileged account to authenticate (e.g. PetitPotam), relay the NTLM credential to the Exchange EWS endpoint; without Extended Protection the relay succeeds. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' CISA KEV 2024-02-15, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 80.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2024-21412": {
     "name": "Microsoft Windows Internet Shortcut Files Security Feature Bypass Vulnerability",
@@ -49630,7 +51150,39 @@
         "adequate": false,
         "gap": "System-security expectations assume webmail rendering is trustworthy; they do not mandate a content-security-policy / output-encoding control that would neutralize the stored-XSS payload."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The CVSS 6.1 on this entry is precisely what makes it go wrong in practice. Read as a medium-severity webmail XSS it sorts into a routine queue, while the packet records it as a zero-day used by the Winter Vivern (TA473) espionage group against European governmental webmail from at least October 2023 to steal mail and credentials, with a public proof of concept available. For Roundcube the requirement is that the KEV listing rather than the severity band sets the clock, and that the clock runs against the Roundcube install itself — a self-hosted third-party webmail server that typically sits outside the operating-system patch pipeline that Essential Eight maturity and most flaw-remediation programmes actually measure, which is why an organisation can be fully compliant on OS patching while the vulnerable rcube_string_replacer.php parser keeps rendering crafted links. The fixed levels are the ones the packet's own vector gives: 1.4.14, 1.5.4 on the 1.5.x line, and 1.6.3 on the 1.6.x line; anything below those on any line is in scope regardless of how current the host operating system is. Precondition on remediation and measurement: live_patch_available is false and the packet records no vendor live-patch mechanism, so the vendor fixed release is the only remediation available — there is no configuration setting or filter in the packet to reach for in the interim. patch_required_reboot is false, which means no host reboot to schedule and not that the fix is live on deployment; count an instance remediated on the version the running Roundcube reports, not on the package version staged on disk. And because exploitation against this exact parser path is confirmed, an instance that was serving mail below the fixed version during the exposure window is an incident item as well as a patch item — the upgrade removes the sink but returns nothing about what was already read out of the mailboxes.",
+        "evidence": "Packet vector: 'Roundcube before 1.4.14, 1.5.x before 1.5.4, and 1.6.x before 1.6.3 allows XSS via text/plain e-mail messages with crafted links because of program/lib/Roundcube/rcube_string_replacer.php behavior.' active_exploitation_notes: 'Exploited as a zero-day by the Winter Vivern (TA473) espionage group against European governmental webmail from at least October 2023; a crafted plain-text email link executed script in the victim's Roundcube session to steal mail and credentials.' NIST-800-53-SI-2 gap: 'The fix shipped in September 2023 but the flaw was already an operational zero-day against targeted governments; a routine SI-2 timeline is slower than the observed espionage exploitation.' AU-Essential-8-Patch gap: 'Essential-Eight patch maturity is oriented to OS and Office endpoints, not to timely upgrade of a third-party webmail server whose rcube_string_replacer.php parser is the stored-XSS sink.' PCI-DSS-4.0-6.2.4 gap: 'Injection-flaw handling in 6.2.4 targets first-party code review; it does not force timely upgrade of a third-party webmail component whose parser is the injection sink.' CISA KEV 2024-02-12; active_exploitation confirmed; poc_available true; CVSS 6.1; RWEP 67; patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "PCI-DSS-4.0-6.2.4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet attributes exploitation of this Roundcube flaw to the Winter Vivern (TA473) espionage group operating against European governmental webmail, which is exactly the attribution trigger this control exists to act on and exactly the case where commodity handling gets it wrong: a CVSS 6.1 cross-site scripting finding routed through standard malware-infection response is treated as a browser-session nuisance, when the packet describes it as a nation-state credential-theft primitive. For this CVE the trigger condition is concrete — a Roundcube instance below 1.4.14, 1.5.4 or 1.6.3 together with any evidence of the crafted plain-text link arriving or being rendered — and the escalated response has to be scoped to what the packet says the actor actually took: mail and credentials out of the victim's authenticated webmail session. That makes mailbox-content exposure assessment and credential rotation for every account whose session rendered a message during the window the substance of the response, rather than the endpoint reimaging a commodity playbook would reach for; the payload runs in the webmail session, so the user's workstation is not where the compromise lives. Preconditions: attribution of this kind arrives after the fact, so the escalation only changes an outcome if the mail-server and webmail telemetry it needs was already being retained across a window the packet dates to at least October 2023, months before the 2024-02-12 KEV listing. And escalation is a response posture — it does not remove the parser defect, which only the vendor fixed release does, and it does not invalidate credentials that were taken; those stay usable until they are rotated.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited as a zero-day by the Winter Vivern (TA473) espionage group against European governmental webmail from at least October 2023; a crafted plain-text email link executed script in the victim's Roundcube session to steal mail and credentials. KEV ransomware use unconfirmed.' NIS2-Art21-vulnerability-management gap: 'Vulnerability-management obligations do not by themselves prioritize a CVSS-medium XSS that is, in practice, a nation-state credential-theft primitive.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management is present but under-weights an internet-facing webmail XSS as a targeted-intrusion vector rather than a low-severity nuisance.' Fixed levels per vector: 1.4.14, 1.5.x before 1.5.4, 1.6.x before 1.6.3. CVSS 6.1; RWEP 67; CISA KEV 2024-02-12; active_exploitation confirmed; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Applied to Roundcube, this control addresses why the Winter Vivern activity the packet describes leaves no authentication-layer trace. The script executes inside the victim's already-authenticated webmail session at the moment the crafted plain-text message is viewed, so there is no failed login, no new session establishment and no client-side artifact to match — an authentication-event log is complete and silent while the mailbox is being read. Detection therefore has to key on the behaviour the packet actually documents: a message view followed, within the same authenticated session, by message-fetch and search activity whose volume and ordering no human reading pattern produces, and by outbound requests carrying session or credential material to a destination outside the deployment. The requirement is that Roundcube per-request access logs — message view, search, message fetch, and requests the application issues on the session's behalf — are forwarded to a SIEM off the webmail host and retained long enough to answer a question that arrives late, which for this CVE means spanning from at least October 2023, when the packet dates exploitation, to the 2024-02-12 KEV listing and beyond. Preconditions, and the second one is the limit that must not be glossed. This is detection, not neutralization: it does not stop the payload, and it supplies only the monitoring half of the system-security expectation — the CAF B4 gap on this entry names a content-security-policy or output-encoding control as what would neutralize the stored payload, and this control does not provide that; the vendor upgrade to 1.4.14, 1.5.4 or 1.6.3 is what removes the sink in rcube_string_replacer.php. And a rule written after the attribution lands, against per-request logs nobody was shipping off the host, returns nothing at all.",
+        "evidence": "Packet attack_vector: 'The attacker emails a plain-text message containing a crafted link; Roundcube's link-replacer converts it into HTML with attacker-controlled attributes/script, so JavaScript runs in the victim's authenticated webmail session when the message is viewed.' active_exploitation_notes: exploited by Winter Vivern (TA473) against European governmental webmail 'from at least October 2023; a crafted plain-text email link executed script in the victim's Roundcube session to steal mail and credentials.' UK-CAF-B4 gap: 'System-security expectations assume webmail rendering is trustworthy; they do not mandate a content-security-policy / output-encoding control that would neutralize the stored-XSS payload.' Fixed levels per vector: 1.4.14, 1.5.4, 1.6.3. CISA KEV 2024-02-12; active_exploitation confirmed; patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-4762": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2023-4762)",
@@ -50188,7 +51740,38 @@
         "adequate": false,
         "gap": "Identity-and-access-control assurance is undermined when authentication can be skipped entirely; B2 assumes the auth gate is reached for protected functions."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Bound to this Ivanti EPMM and MobileIron Core entry, the control's clock opens at the 2024-01-18 KEV listing and closes only when each affected server has come up on the fixed release. Two things make that harder than the usual appliance ticket. First, the population is two separately-branded product lines: the packet gives Ivanti EPMM 11.10 and older on one side and MobileIron Core 11.7 and below on the other, so an inventory that queries for 'Ivanti EPMM' misses MobileIron Core-branded servers still in service, and those are the instances most likely to sit outside the current vendor-support relationship that drives patch notifications. Second, the packet records that remediation requires applying the fixed release and rebooting, with no live-patch mechanism available, so a server holding the fixed release staged but not yet restarted is still serving the bypass and must be counted as exposed rather than as patched — on an MDM server that reboot is the step most likely to be deferred, because taking it interrupts device check-in and enrollment. Priority follows the packet rather than a queue position: a public proof-of-concept, EPSS near 1.0, a KEV ransomware flag, and exploitation that began shortly after the public technical details make this a containment step whose delay is measured against attackers already operating, not a scheduled maintenance item.",
+        "evidence": "Packet fields for CVE-2023-35082: cisa_kev true with kev_date 2024-01-18, active_exploitation confirmed, cvss 9.8, rwep_score 82, poc_available true, patch_available true, patch_required_reboot true, live_patch_available false, and live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' affected_versions names both product lines: 'Ivanti EPMM 11.10 and older (11.9, 11.8, ...)' and 'MobileIron Core 11.7 and below'. active_exploitation_notes records CISA-confirmed exploitation in January 2024 against internet-facing EPMM / MobileIron Core MDM servers, a KEV ransomware flag, and EPSS ~1.0. The NIST-800-53-SI-2 gap states the flaw was exploited shortly after Rapid7's public details, faster than a routine flaw-remediation SLA closes an internet-facing MDM server.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "EPMM's authentication filter is where the product makes its authentication decision, and this CVE is that layer failing open: the packet has an unauthenticated attacker sending a request whose URI prefix bypasses the filter, so the restricted management-API functions behind it run without any access-control decision ever being taken for that request. Bound to this product, the control means each management-API function on EPMM and MobileIron Core authorizes its own caller rather than inheriting a verdict from the filter that fronts it, and the administrative portion of the surface is separated from the enrollment portion so an untrusted caller cannot present a request to that filter for administrative functions at all. This is also why the least-privilege and identity-side attestations an estate carries do not reduce this flaw: the attacker never authenticates as any EPMM operator, so per-account privilege scoping is never consulted and the account model an identity-and-access attestation examines is bypassed rather than abused. Distinguishing test: from a segment with no administrative need for the MDM console, send unauthenticated requests carrying the URI-prefix form to each management-API endpoint on a staging EPMM and confirm each is refused before the function runs — an attestation that every EPMM administrator authenticates at login passes cleanly while this path stays open. Precondition, and it is a hard one on this product: the endpoint-side authorization is a property the vendor fixed release establishes, not something an operator can add, and the packet records that the platform must by design remain internet-reachable for mobile enrollment. So restricting reachability bounds only the administrative portion of the surface; it cannot cover the enrollment path, and it gives nothing against a caller that can reach whatever must stay exposed. Until the fixed release and its reboot land, this control states what to verify rather than what to deploy.",
+        "evidence": "Packet fields for CVE-2023-35082: cwe_refs CWE-287, and attack_vector states that an unauthenticated attacker sends a crafted request whose URI prefix bypasses the authentication filter, reaching MDM management-API endpoints to read user PII and alter server configuration. The NIST-800-53-AC-3 gap states that access enforcement is defeated at the source — a crafted URI prefix bypasses the authentication filter, so the access-control decision point never runs for the sensitive API. The UK-CAF-B2 gap states that identity-and-access-control assurance is undermined when authentication can be skipped entirely, because B2 assumes the auth gate is reached for protected functions. The NIS2-Art21-network-security gap records that the device must be internet-reachable by design for mobile enrollment. patch_available is true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "EPMM and MobileIron Core are the control plane for every mobile device they manage, and the packet places the attacker inside that control plane rather than merely at its door: unauthenticated access to restricted management-API endpoints, reading user PII and altering server configuration, chainable toward remote code execution, on a KEV entry flagged for known ransomware use. That is why the fixed release and its reboot do not by themselves resolve an instance that was internet-reachable during the exposure window — configuration the attacker changed through the bypass is carried forward by the upgrade, and PII already read is gone regardless of what version the server later reports. Bound to this platform, the playbook items are: audit EPMM server configuration and every configuration profile pushed to the fleet since the start of the exposure window against a known-good baseline; invalidate device-trust state and revoke certificates issued or pushed through the platform during that window; rotate credentials for any account that authenticated through the platform; and define, in advance, the criteria under which downstream managed devices are quarantined. This is the half of the response that still has value after the patch record reads clean, and it is what turns a technical-vulnerability finding on one server into the fleet-wide isolation decision the compromise actually requires.",
+        "evidence": "Packet fields for CVE-2023-35082: active_exploitation confirmed, kev_date 2024-01-18, and active_exploitation_notes stating that unauthenticated attackers reach restricted API endpoints to read user PII and make server changes, that it can be chained toward RCE, and that KEV flags known ransomware use. attack_vector describes the result as a foothold on the control plane for the entire managed mobile fleet. The ISO-27001-2022-A.8.8 gap states that technical-vulnerability management does not by itself force emergency isolation of an MDM control plane whose compromise exposes the entire managed fleet. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-0519": {
     "name": "Google Chromium V8 Out-of-Bounds Memory Access Vulnerability",
@@ -50620,7 +52203,38 @@
         "adequate": false,
         "gap": "Technical-vulnerability management provides no play for a KEV appliance zero-day with only a temporary mitigation, so exposed devices stayed reachable during active exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "Ivanti Connect Secure and Policy Secure are the VPN-concentrator class this tier names, and the defect is in the web component that faces unauthenticated internet clients by design — the device is the trust boundary, which is why a standard 14- or 30-day application SLA is the wrong instrument regardless of the 8.2 base score. For this CVE the tier means the clock opened at the 2024-01-10 KEV listing and closes only at the reboot of every affected unit, covering Connect Secure 9.x and 22.x and Policy Secure 9.x and 22.x — the packet names all four, and an estate standardised on Policy Secure while treating this as a Connect Secure advisory will sweep clean and stay exposed. The packet records a vendor fix with no live-patch mechanism and a reboot requirement, so a unit that has taken the fixed release but has not been rebooted onto it is still running the vulnerable web component and must be counted as exposed; on a remote-access gateway that reboot is also the step most likely to be deferred, because taking it drops every live session, and a deferral recorded as patched is the specific way this remediation goes wrong. The tier's alternative limb — isolation of the vulnerable interface — needs its precondition stated for this product rather than inherited from the firewall case: the vulnerable web component IS the remote-access service, so there is no segment to move it behind. The only forms isolation takes here are withdrawing remote access for the duration, or restricting the source addresses permitted to reach the gateway, and on a device whose purpose is terminating arbitrary remote workers the second is usually unavailable. Where neither is possible the honest record is an accepted exposure with the reboot dated, not a compensating control marked in place.",
+        "evidence": "Packet name: 'Ivanti Connect Secure and Policy Secure Authentication Bypass Vulnerability'. affected: 'Web component of Ivanti Connect Secure (ICS, formerly Pulse Connect Secure) 9.x and 22.x and Ivanti Policy Secure; directory traversal lets a remote attacker bypass control checks and access restricted resources without authentication.' affected_versions lists Connect Secure 9.x, Connect Secure 22.x, Policy Secure 9.x and Policy Secure 22.x. cisa_kev true, kev_date 2024-01-10, active_exploitation confirmed, poc_available true, rwep_score 82, cvss 8.2. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The NIST-800-53-SC-7 gap: 'Boundary protection does not prevent the appliance itself, which is the boundary, from being bypassed via path traversal; the flaw lives in the very device meant to enforce the perimeter.' active_exploitation_notes records a mass-exploited zero-day chaining with CVE-2024-21887 for unauthenticated RCE.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry is the case the three-state verdict exists for, and the packet supplies the evidence in its own gap text: the Essential-Eight objective was overtaken by zero-day mass exploitation before a patch existed, and the initial vendor guidance was a mitigation release file rather than a fix, while ISO A.8.8 had no play at all for a KEV-listed appliance zero-day carrying only a temporary mitigation. An estate in that condition is in state (b) — vendor mitigation loaded, no fixed build installed — and it must be reported as its own compensating-control state with a dated action item, never folded into a green 'patched per SLA' row. The residual risk in state (b) is specific rather than theoretical here: the mitigation is a rule applied to the same request path the flaw lives in, so a defect in it or an incomplete application on any unit reopens the pre-auth traversal, and it does nothing whatever about an appliance already exploited before the file was loaded — which, for a flaw the packet describes as mass-exploited as a zero-day, is a live possibility on any unit that was internet-reachable. State (a) for this CVE is reached only when the unit is on the fixed release and has been rebooted onto it, because the packet records no live-patch mechanism and a reboot requirement; a unit showing the fixed release with the reboot outstanding is still state (b) at best. Distinguishing test: pull the current verdict for every Connect Secure and Policy Secure unit and require each to name which of the three states it is in and the evidence for that state — an appliance register showing green flaw-remediation rows for units carrying only the mitigation file is recording compliance for an exposure under active mass exploitation.",
+        "evidence": "The AU-Essential-8-Patch gap on this entry: 'The patch objective was overtaken by zero-day mass exploitation before a patch existed — initial guidance was a mitigation.release XML, not a fix, leaving a control gap the SLA cannot cover.' The ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management provides no play for a KEV appliance zero-day with only a temporary mitigation, so exposed devices stayed reachable during active exploitation.' Packet: patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' active_exploitation confirmed; active_exploitation_notes: 'Mass-exploited zero-day (CISA-flagged ransomware-associated)'. cisa_kev true, kev_date 2024-01-10, rwep_score 82.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet describes exactly the conditions under which patch-in-place is the wrong default: a mass-exploited zero-day on an internet-facing gateway, CISA-flagged ransomware-associated, with the traversal chaining to CVE-2024-21887 command injection for unauthenticated RCE across the Connect Secure and Policy Secure fleet. The runbook for these appliances must therefore assume that any Connect Secure 9.x or 22.x or Policy Secure 9.x or 22.x unit reachable from the internet during the exposure window was compromised until evidence says otherwise, and default to capturing the running configuration for analysis, rebuilding the appliance onto the fixed release, and rotating every credential and certificate the device held or brokered — VPN user credentials and session material, the appliance's own administrative accounts, any directory or authentication-service account it bound with, and its device certificates. This is precisely what the two network-security gaps on the entry miss: NIS2's obligations and CAF's resilient-network expectations both treat the remote-access gateway as a trusted enforcement point, so once it reports the fixed version the framework's questions are answered — while an implant installed through the RCE chain survives the upgrade untouched and keeps the position the gateway grants. Preconditions, all three load-bearing: the rebuild only helps if the unit comes up on the fixed release and is rebooted onto it, since the packet records no live-patch path and a reboot requirement; a configuration restored wholesale from a backup taken after the exposure began can carry the attacker's changes back in, so it is reviewed rather than replayed; and rebuilding the appliance does nothing about access the attacker already converted into a foothold behind it, so the internal follow-on investigation and the credential rotation are part of this runbook rather than a later phase.",
+        "evidence": "Packet active_exploitation_notes: 'Mass-exploited zero-day (CISA-flagged ransomware-associated); a remote unauthenticated attacker uses directory traversal in the web component to bypass control checks and reach restricted endpoints, and chains with CVE-2024-21887 command injection for unauthenticated RCE across the Ivanti Connect Secure / Policy Secure fleet.' attack_vector: the traversal 'slips past the authentication/control checks, exposing restricted endpoints and priming the paired CVE-2024-21887 command injection for full RCE'. affected_versions: Connect Secure 9.x and 22.x, Policy Secure 9.x and 22.x. The NIS2-Art21-network-security gap: 'Network-security obligations treat the VPN concentrator as a trusted control, but this pre-auth bypass turns the enforcement point into the entry point, which the control does not anticipate.' The UK-CAF-B4 gap: 'Resilient-network expectations assume the remote-access gateway is trustworthy; they do not require compensating segmentation for a gateway that is itself the vulnerable, internet-facing asset.' patch_required_reboot true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' rwep_score 82, poc_available true, cisa_kev true, kev_date 2024-01-10.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-21887": {
     "name": "Ivanti Connect Secure and Policy Secure Command Injection Vulnerability",
@@ -51932,7 +53546,40 @@
         "adequate": false,
         "gap": "Technical vulnerability management reacts to known advisories, but this was weaponized as an unknown zero-day, defeating advisory-driven prioritization."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Bound to this CVE the control governs the residual Apple fleet after the fix shipped: every enrolled device driven to iOS/iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2, or the 16.7.2 backport on the 16.x line, on the clock that opened with the 2023-12-04 KEV listing, with user deferral disallowed rather than left to the device holder. Two scoping points decide whether the sweep is real. Safari carries its own version in affected_versions, so a Mac held on an older macOS line whose Safari is below 17.1.2 stays exposed while the Sonoma track shows nothing to do — enumerate the Safari build per Mac, not only the OS build. And the packet records patch_required_reboot true, live_patch_available false, and an update that requires a device restart, so a device that has downloaded the update and not restarted is still executing the vulnerable WebKit code: measure completion on the build the device is actually running, never on 'approved' or 'downloaded' in the management console. Scope the inventory to the products the packet names — iOS, iPadOS, macOS and Safari — and widen only where a verified source identifies another product carrying the same WebKit build. Precondition, and it is the reason this control cannot stand alone here: it reaches only devices the management platform enrols and can compel. The packet's UK-CAF-B4 gap names jailbroken, MDM-deferred and end-of-support devices as the population that remains exposed, and tightening a deferral policy does not touch a device that is not enrolled or cannot receive the build at all. It also does nothing for the window before the fix existed, which is the window this CVE was exploited in.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-12-04, active_exploitation confirmed, rwep_score 60, cvss 8.8. patch_available true, patch_required_reboot true, live_patch_available false, and live_patch_notes 'No live patch; requires the iOS/iPadOS/macOS/Safari update (17.1.2 / 14.1.2, backported to 16.7.2) and a device restart.' affected names Apple WebKit across iOS, iPadOS, macOS and Safari; affected_versions lists iOS/iPadOS < 17.1.2, macOS Sonoma < 14.1.2, Safari < 17.1.2, and iOS 16.x before the 16.7.2 backport. The UK-CAF-B4 gap records that secure-maintenance controls presume auto-update coverage and that jailbroken, MDM-deferred or end-of-support Apple devices remain exposed to malicious web content; the NIS2-Art21-patch-management gap records that timely patching addresses only the residual fleet after Apple shipped 17.1.2/16.7.2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "This is the control for the window the patch clock never covered. The packet records that Apple is aware of a report the issue may have been exploited against iOS versions earlier than 16.7.1 — exploitation preceding the advisory — and characterises it as a targeted-spyware pattern with delivery through attacker-served web content that needs nothing from the victim but viewing the page. For the population plausibly inside that targeting set, the requirement is a standing reduced-attack-surface posture on their iPhones, iPads and Macs in which untrusted web content is not fetched and processed automatically, narrowing the path into the WebKit out-of-bounds write for devices that have not yet reached 17.1.2 / 14.1.2 / Safari 17.1.2 or the 16.7.2 backport and taken the restart the fix requires. Preconditions, all three load-bearing here. The posture only helps if it was already assigned before the disclosure — a mode switched on after a KEV listing was not on when a pre-disclosure exploit arrived, and this entry is the case where that timing is the whole point. It narrows the delivery path, it does not repair the WebKit defect and does not evict code already executing on a device compromised during the exposure window; a device in the targeted cohort that rendered untrusted content while exposed belongs on the incident path, not the configuration path. And it is a holding measure for the interval before the fixed build and its restart land, not a substitute for them.",
+        "evidence": "Packet: vector states 'Processing web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been exploited against versions of iOS before iOS 16.7.1.' active_exploitation confirmed; active_exploitation_notes describes a targeted-spyware exploitation pattern with no ransomware association. attack_vector: an attacker serves crafted web content triggering an out-of-bounds write in WebKit's WebContent process, yielding arbitrary code execution when the victim merely views the page. The ISO-27001-2022-A.8.8 gap records that technical vulnerability management reacts to known advisories but this was weaponized as an unknown zero-day, defeating advisory-driven prioritization; the AU-Essential-8-Patch gap records that the patch target starts the clock at disclosure while targeted exploitation preceded it.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet carries both halves this control exists to separate. patch_available is true — fixed builds exist at iOS/iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2, with a 16.7.2 backport for the 16.x line — and the packet's own UK-CAF-B4 gap records that end-of-support Apple devices remain exposed to malicious web content. So the first requirement is a per-unit determination rather than a fleet-wide patch percentage: for every iPhone, iPad, Mac and Safari install in service, establish from Apple whether that hardware can still receive a build carrying this fix. Units that can are interim items on the clock that opened with the 2023-12-04 KEV listing, and because live_patch_available is false and the fix requires a device restart, a unit that took the update without restarting is still running the vulnerable code and is not remediated. Units that cannot receive any of those builds have no patch path at all, and for them reaching a fixed build is not an available state: the terminal state is removal or replacement on a dated schedule, because such a device is exposed not only to this out-of-bounds write but to everything found in WebKit since its last build. A risk acceptance with no removal date records a device as compliant while it keeps rendering untrusted web content with a confirmed-exploited flaw. Scope the inventory to the products the packet names — iOS, iPadOS, macOS and Safari — and widen only where a verified source identifies another product carrying the same WebKit build; treating every renderer in the estate as an instance of this CVE manufactures replacement work against software no evidence here implicates.",
+        "evidence": "Packet: patch_available true with affected_versions iOS/iPadOS < 17.1.2, macOS Sonoma < 14.1.2, Safari < 17.1.2, and iOS 16.x before the 16.7.2 backport; live_patch_available false and live_patch_notes 'No live patch; requires the iOS/iPadOS/macOS/Safari update (17.1.2 / 14.1.2, backported to 16.7.2) and a device restart.' framework_coverage for UK-CAF-B4 states 'Secure-maintenance controls presume auto-update coverage; jailbroken, MDM-deferred, or end-of-support Apple devices remain exposed to malicious web content.' cisa_kev true, kev_date 2023-12-04, active_exploitation confirmed.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-42916": {
     "name": "Apple Multiple Products WebKit Out-of-Bounds Read Vulnerability",
@@ -53162,7 +54809,41 @@
         "adequate": false,
         "gap": "System-security outcomes assume management interfaces enforce authentication; an unauthenticated file upload/download endpoint defeats that assumption without dedicated management-plane isolation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The SRX Series is a perimeter firewall — the trust boundary itself — and the packet describes an unauthenticated request to webauth_operation.php uploading and downloading arbitrary files through J-Web, with the write primitive chaining into pre-auth remote code execution via the PHPRC flaw the packet names as its chaining partner. That is the case this tier exists for, and this entry is also a clean demonstration of why a CVSS-keyed SLA misfiles it: the base score is 5.3, which routes the item to a routine queue, while the packet's own flaw-remediation gap records that the medium score understates a pre-auth upload/download primitive documented as part of a public RCE chain, and the entry's RWEP is 77. For this device the requirement is that remediation runs on the tier clock opened by the 2023-11-13 KEV listing — the fixed Junos release for whichever train is in service (21.2R3-S8, 21.4R3-S6, 22.1R3-S5, 22.2R3-S3, 22.3R3-S2, 22.4R2-S2 or 22.4R3, 23.2R1-S2 or 23.2R2) — or, where the maintenance window cannot be taken inside it, J-Web is made unreachable from untrusted networks until it can. Cover every train the packet names: an estate standardised on 22.4 or 23.2 is exposed at a different fixed build than one on 21.2, and a sweep scoped to a single train reports clean across the rest. Completion is measured on the release each chassis is actually running: the packet records no live-patch mechanism and remediation requiring the fixed release plus a reboot, so a device staged with the image but not rebooted onto it is still serving the unauthenticated endpoint. Precondition on the isolation alternative: restricting or disabling J-Web bounds who can reach webauth_operation.php, it does not repair the missing authentication check — anything inside a permitted management segment still reaches it unauthenticated — and it is unavailable where J-Web is the operational management path for the device. It is a holding measure for the window before the fixed release and its reboot land, not a closure.",
+        "evidence": "The packet records CISA KEV 2023-11-13, active_exploitation confirmed, poc_available true, CVSS 5.3 against RWEP 77. The NIST-800-53-SI-2 gap states the medium base score understates a preauth upload/download primitive documented as part of a public RCE chain and that CVSS-keyed patch SLAs deprioritize it wrongly; the AU-ISM-1546 gap states patching within the ISM window does not mandate restricting the exposed webauth_operation.php endpoint; the ISO-27001-2022-A.8.8 gap states technical-vulnerability management under CVSS-medium scoring deprioritizes this endpoint, delaying remediation of an actively-exploited preauth flaw. patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes recording that remediation requires applying the fixed release and rebooting. affected_versions lists 21.2 prior to 21.2R3-S8, 21.4 prior to 21.4R3-S6, 22.1 prior to 22.1R3-S5, 22.2 prior to 22.2R3-S3, 22.3 prior to 22.3R3-S2, 22.4 prior to 22.4R2-S2 / 22.4R3, and 23.2 prior to 23.2R1-S2 / 23.2R2.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "J-Web is the device-management gateway on the SRX Series, and webauth_operation.php is the file-accepting endpoint on it that makes no authorization decision at all — the packet's access-enforcement gap states outright that access enforcement is exactly what is missing, and that it is missing for both the upload and the download direction. Bound to this product, the control means that endpoint authorizes its caller before the request is processed at all, in both directions, so an unauthenticated caller can neither write a file onto the firewall nor read one off it; and that no SRX is left with J-Web reachable from a segment with no operational need to manage the device, least of all from the internet. The read direction deserves separate attention on a firewall and is the half most often dropped: the same unauthenticated endpoint returns arbitrary files from the device that holds the configuration, and the packet records the read primitive as exposing sensitive files, so treating this purely as an upload bug leaves the disclosure path uncounted and closes the finding while the configuration is still readable. Distinguishing test: from a segment with no management role, issue an unauthenticated upload and an unauthenticated download request against webauth_operation.php on a staging SRX and confirm each is refused before any file is written or returned — an estate that attests every J-Web administrator authenticates at login passes cleanly while this path stays wide open, because the attacker never presents a J-Web account and no access decision is ever consulted. Precondition: the endpoint-side authorization is a property the fixed Junos release establishes — this control states what to verify, it does not implement it. Until that release and its reboot land, restricting which segments reach J-Web bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, so a compromised jump host or workstation already in the management network satisfies the exploit's only precondition in full.",
+        "evidence": "The packet's affected field records the J-Web interface on Juniper Junos OS SRX Series with unauthenticated arbitrary file upload and download via webauth_operation.php, and the attack_vector states the request lacks an authentication check, that the write primitive chains with the PHPRC flaw for pre-auth RCE, and that the read primitive exposes sensitive files. The NIST-800-53-AC-3 gap states access enforcement is exactly what is missing — webauth_operation.php requires no authentication for both upload and download of files — and that until patching, no access policy compensates. The NIST-800-53-SC-7 gap states boundary protection that exposes J-Web is the precondition and that segmenting or disabling the management interface is the durable mitigation patch-only remediation ignores. The NIS2-Art21-network-security gap states network-security duties do not mandate management-plane isolation, so an exposed J-Web keeps the unauthenticated upload/download reachable, and the UK-CAF-B4 gap states an unauthenticated file upload/download endpoint defeats the assumption that management interfaces enforce authentication. patch_available true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "NIST-800-53-AC-3",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive here is an unauthenticated arbitrary file write onto a perimeter firewall, and the fixed Junos release removes the write path without removing anything already written through it. So for any SRX whose J-Web was reachable from an untrusted network during the exposure window, the default disposition is configuration extraction, rebuild from a known-good image, and rotation of the credentials and keys the device's configuration held or that transited it — not upgrade-in-place followed by closing the flaw-remediation ticket. Both primitives argue for it: the write half means a file placed on the device survives the upgrade intact, and the read half means the configuration was retrievable unauthenticated, so the material inside it must be treated as disclosed rather than as protected by reaching the fixed release. The packet records confirmed active exploitation, a public proof-of-concept, and this CVE as part of the J-Web pre-auth chain, which is what makes the upgrade-only disposition insufficient rather than merely conservative. Scoping precondition, which is where this control is most often over-applied: this disposition attaches to units whose J-Web was actually reachable during the window, not to every SRX in the estate — the packet's own note that this entry's EPSS is far below its sibling CVEs, reflecting narrower standalone weaponization, is a reason to establish reachability per unit rather than to rebuild a whole fleet. It is also worth stating what cannot be leaned on when establishing that: because the flaw itself grants an unauthenticated write to the device's filesystem, records held only on the device are not a trustworthy basis for concluding a unit was untouched, so absence of local evidence on a reachable unit is inconclusive rather than exculpatory. Rebuild does not prevent the exploitation and does nothing for a unit still on a vulnerable release; it is what makes the fixed release a genuine end-state on a unit that was exposed.",
+        "evidence": "The packet's attack_vector records an unauthenticated attacker uploading and downloading arbitrary files via J-Web, giving both a file-write primitive for RCE chaining and arbitrary-file read, and the vector records the resulting loss of integrity or confidentiality with possible chaining to other vulnerabilities. active_exploitation is confirmed with poc_available true, the entry is described as part of the Juniper J-Web pre-auth chain, and it was CISA KEV-listed 2023-11-13. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes recording that remediation requires applying the fixed release and rebooting. The packet also records EPSS 0.011 (61.7th percentile), far lower than the sibling CVEs, reflecting narrower standalone weaponization, and the NIST-800-53-SI-2 gap frames remediation of this entry purely in patch-SLA terms.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-29552": {
     "name": "Service Location Protocol (SLP) Denial-of-Service Vulnerability",
@@ -53614,7 +55295,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability-management deprioritizes a 'medium' XSS, so the KEV-listed, actively-exploited flaw lingers unpatched on internet-facing webmail."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a severity-keyed patch queue and a KEV-keyed one give opposite answers, and the packet says so three times. It scores the flaw at CVSS 5.4, and its technical-vulnerability-management, flaw-remediation and Essential Eight patch gaps all record the same failure: a 'medium' stored XSS is deprioritized on score while the same packet carries a CISA KEV listing dated 2023-10-26 and exploitation by the Winter Vivern (TA473) espionage group against government webmail. The requirement here is that the KEV listing, not the CVSS band, sets the clock for every Roundcube Webmail installation the organization runs, and that the upgrade is to the fixed release on each installation's own branch — 1.4.15 for installs below 1.4.15, 1.5.5 for 1.5.x, 1.6.4 for 1.6.x — rather than letting a medium score route the ticket into a routine maintenance queue. The branch split is operationally load-bearing because an estate hosting several Roundcube instances will have them at different branch levels, and an instance left on a pre-1.5.5 1.5.x build is still serving the vulnerable rcube_washtml.php sanitizer no matter what the 1.6.x instance was upgraded to. The packet records no live-patch mechanism and states that remediation requires applying the vendor fixed release, so completion is measured on the release the running webmail actually serves rather than on a package or repository state: where long-lived PHP worker processes or a bytecode cache continue serving previously deployed code, the fixed sanitizer is not yet in effect for the sessions being served, and that instance is not remediated. Distinguishing test: query every Roundcube instance in the estate for the release it is serving and confirm each is at or above its own branch's fixed release; an attestation satisfied by upgrading one instance leaves the rest exposed to a flaw with confirmed in-the-wild use and, on this entry, public exploit code. Precondition: this bounds future exposure only. The packet has the attacker's JavaScript running inside the victim's authenticated Roundcube session to read and exfiltrate mail, so upgrading recalls nothing already taken, and a mailbox whose owner rendered a crafted message during the exposure window is an incident-response question rather than a patch-record one.",
+        "evidence": "Packet fields: name = 'Roundcube Webmail Persistent Cross-Site Scripting (XSS) Vulnerability'; cvss 5.4 against rwep_score 64; cisa_kev true, kev_date 2023-10-26; active_exploitation confirmed with active_exploitation_notes 'Exploited in the wild by the Winter Vivern (TA473) espionage group against government webmail targets: a crafted SVG in an HTML email ran JavaScript in the victim's Roundcube session to exfiltrate mail'; vector = 'Roundcube before 1.4.15, 1.5.x before 1.5.5, and 1.6.x before 1.6.4 allows stored XSS via an HTML e-mail message with a crafted SVG document because of program/lib/Roundcube/rcube_washtml.php behavior'; affected_versions = '< 1.4.15', '1.5.x < 1.5.5', '1.6.x < 1.6.4'; poc_available true; patch_available true, patch_required_reboot false (no host reboot recorded), live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release'. Gap text used: ISO-27001-2022-A.8.8 = 'Technical-vulnerability-management deprioritizes a medium XSS, so the KEV-listed, actively-exploited flaw lingers unpatched on internet-facing webmail'; NIST-800-53-SI-2 = 'Flaw-remediation timelines for webmail are often relaxed given the medium CVSS, yet a targeted APT exploited it promptly — the severity-driven patch prioritization under-weights active exploitation'; AU-Essential-8-Patch = 'Essential-Eight patch prioritization keyed to CVSS under-weights a medium stored-XSS, yet Winter Vivern weaponized this SVG-sanitizer bypass promptly against internet-facing Roundcube'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "The premise this control rests on holds in its strongest form on this entry: the packet's attack path generates no authentication event at all. The victim logs into Roundcube Webmail normally, views an HTML message whose crafted SVG bypasses the rcube_washtml.php sanitizer, and the attacker's JavaScript then reads and exfiltrates mail across that same already-authenticated session — so an authentication-event log shows one ordinary login and nothing else, which is precisely why the monitoring and incident-handling gaps on this entry describe the exfiltration as unobserved and late-detected. For this product the requirement is that Roundcube's per-request access logs — which mail-retrieval actions ran, against which message identifiers, in what order, at what rate, and on which session — are forwarded to a SIEM outside the webmail host and retained long enough to cover a campaign rather than a shift. The rule has to key on what an exploit doing exactly what the packet describes emits: a burst of message-fetch requests inside a single authenticated session beginning when a message is rendered, sequenced by mailbox contents rather than by anything a person clicked, with no new login and no credential event anywhere in the sequence. That is the observable; a rule keyed to failed logins, server process anomalies, or host-level file changes would see nothing here, because the server is not compromised — the session is, which is exactly the incident-handling gap the packet records. Preconditions. This is detection, not prevention: it does not repair the sanitizer, does not stop the script executing in the session, and does not recall mail already exfiltrated; what it bounds is the interval between the message being viewed and someone knowing. It works only on telemetry already being collected and shipped off-host before the message arrives, and per-request access logging on an internet-facing webmail host is the collection most often left rotating locally, so a query written after the fact returns nothing. Retention has to be sized against the threat the packet names — a targeted espionage group working government webmail is a campaign that outlasts a short local rotation window — and the control is a complement to reaching the fixed release on each branch, not a substitute for it.",
+        "evidence": "Packet fields: attack_vector = 'An attacker sends an HTML email whose crafted SVG document bypasses Roundcube's HTML sanitizer; when the victim views the message, attacker-controlled JavaScript executes in the webmail session and can read/exfiltrate mail'; affected = 'Roundcube Webmail — stored XSS via a crafted SVG in an HTML email due to rcube_washtml.php sanitizer behavior, allowing attacker JavaScript to run in the victim's session'; active_exploitation_notes = 'Exploited in the wild by the Winter Vivern (TA473) espionage group against government webmail targets: a crafted SVG in an HTML email ran JavaScript in the victim's Roundcube session to exfiltrate mail'. Gap text used: UK-CAF-C1 = 'Security-monitoring expectations focus on host/network telemetry, not on anomalous webmail DOM/script behavior, leaving this XSS-driven exfiltration unobserved'; NIS2-Art21-incident-handling = 'Incident-handling processes centered on server compromise miss session-level mail exfiltration triggered purely by viewing an email, so the breach is detected late or not at all'. That the weaponized message reaches the mailbox in the first place is the packet's NIST-800-53-SI-3 gap: 'Malicious-code protection (mail AV/anti-spam) does not inspect for sanitizer-bypassing SVG/HTML that yields client-side script execution, so the weaponized email passes content filtering.'",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2023-20273": {
     "name": "Cisco IOS XE Web UI Command Injection Vulnerability",
@@ -53957,7 +55661,39 @@
         "adequate": false,
         "gap": "Patch-application timeframes for network appliances are routinely exceeded because of change-freeze and maintenance-window constraints on core routing gear."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The population here is not the router estate: it is every Cisco IOS device and every Cisco IOS XE device with the GET VPN feature enabled, in both roles, since the packet's path reaches the out-of-bounds write from a compromised key server or from a group member reconfigured to register against an attacker-controlled one. Producing that list is part of the requirement rather than a precursor to it, because the A.8.8 gap records that host and web-application scanning rarely enumerates IOS/IOS XE feature-level CVEs, so a GET VPN router will not surface as vulnerable unless the GET VPN configuration itself is what gets inventoried. For each device the 2023-10-10 KEV listing sets the clock rather than the change-freeze calendar the SI-2 and AU-ISM-1546 gaps describe. Fixed releases are per-train and the packet points at the Cisco advisory for them rather than naming one, so the per-device check is that the running image is at or above the advisory's fixed release for that train. The packet records no live-patch mechanism and states that remediation requires applying the fixed release and rebooting, so completion is measured on the image the device is executing after the reload — a fixed image copied to flash and set as the boot image is not remediation, and on core routing gear that pending reload is precisely the step that gets deferred into the next window and then recorded as patched.",
+        "evidence": "Packet: CISA KEV 2023-10-10, active_exploitation confirmed; active_exploitation_notes state Cisco PSIRT observed attempted exploitation of the GET VPN feature in the wild and discovered this out-of-bounds write during the ensuing code review. CVSS 6.6, RWEP 55, poc_available false. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' affected_versions: Cisco IOS with GET VPN enabled and Cisco IOS XE with GET VPN enabled, fixed releases per the Cisco advisory. The SI-2 gap states GET VPN routers are change-controlled infrastructure operators reboot infrequently so the patch window far exceeds the exploitation window; AU-ISM-1546 states patch timeframes are routinely exceeded because of change-freeze and maintenance-window constraints; A.8.8 states vulnerability management rarely enumerates IOS/IOS XE feature-level CVEs on GET VPN routers.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The precondition the packet states outright is administrative control of either a group member or a key server — the attacker is already authorized, which is why the AC-6 gap records that least-privilege on the control plane does not help and a compromised-but-authorized key server or group member still weaponizes the out-of-bounds write. A GET VPN key server is a control plane for every router in its group: it distributes the group policy and keys the members act on, and the packet's second path is simply reconfiguring a group member so it registers against a key server the attacker controls. Applied to this deployment, the control means key-server administration and group-member configuration authority are classified as a tier above general network-operations access — reached only through a privileged-access path with step-up authentication and time-bound elevation, on identities used for nothing else — and that any change to a group member's key-server registration is an audited, reviewed change rather than a routine configuration push. The distinguishing test sits on the change path rather than on the device: on a staging group, attempt to repoint a group member at a different key server using an ordinary network-operations account, and confirm the change is refused or held for review before it takes effect. An estate that passes an AC-6 attestation because each router account carries scoped command privileges still hands this flaw to anyone who legitimately administers a key server. Precondition: this raises the bar on obtaining the administrative position the exploit needs and creates a record when it changes hands; it does nothing once that position is held, and it does not repair the attribute validation, which only the fixed IOS/IOS XE release does.",
+        "evidence": "Packet: vector states the vulnerability could allow an authenticated, remote attacker who has administrative control of either a group member or a key server to execute arbitrary code or crash the device, and that an attacker could exploit it by either compromising an installed key server or modifying the configuration of a group member to point to a key server controlled by the attacker. attack_vector repeats both paths. The NIST-800-53-AC-6 gap states least-privilege on the control plane does not help because the attack presupposes an attacker who already holds legitimate administrative control of a key server or group member, so a compromised-but-authorized KS/GM still weaponizes the out-of-bounds write.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The GDOI and G-IKEv2 exchange between a key server and its group members is the service-internal protocol this control governs, and the packet places the defect there: insufficient validation of attributes in those protocols, so a group member accepts group-policy attributes from its key server and parses them into an out-of-bounds write ending in code execution or a device reload. Both cited gaps make the same point from different frameworks — the GET VPN group is treated as an internal trust domain, and nothing validates the integrity of the group-policy attributes crossing it. Bound to this deployment, the requirement is that a group member registers only with key servers named in an operator-controlled configuration whose integrity is monitored for change, that the GDOI/G-IKEv2 registration interface on both roles answers only from the addresses of that group's own members and key servers rather than from any routable peer, and that 'the group sits inside our network' stops being accepted as the validation step for what the parser receives. Distinguishing test: from a host outside the group's member and key-server set on a staging deployment, attempt a GDOI/G-IKEv2 registration against a group member and against a key server, and confirm it is refused before any group-policy attribute is parsed. Precondition, and it is the load-bearing one: the attribute validation itself is a property of the fixed IOS/IOS XE release — this control bounds which peers can present attributes, it does not make the parser safe, and it gives nothing against a genuinely compromised key server that is already inside the permitted set, which is the packet's primary path. Until the fixed release and its reload land, that residual path stays fully open.",
+        "evidence": "Packet: vector states the vulnerability is due to insufficient validation of attributes in the Group Domain of Interpretation (GDOI) and G-IKEv2 protocols of the GET VPN feature, and that exploitation is either by compromising an installed key server or by modifying a group member's configuration to point to an attacker-controlled key server; attack_vector describes malformed GDOI/G-IKEv2 group-policy attributes triggering an out-of-bounds write, yielding code execution or a device reload. The NIS2-Art21-network-security gap states baseline controls treat the GET VPN trust domain as internal and do not validate the integrity of GDOI/G-IKEv2 group-policy attributes exchanged between KS and GM; the UK-CAF-B4 gap states the flaw is reached from a compromised-yet-authorized key server or group member, so integrity of the GDOI/G-IKEv2 group attributes — not perimeter defense — is what the control must assure.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-41763": {
     "name": "Microsoft Skype for Business Privilege Escalation Vulnerability",
@@ -54311,7 +56047,38 @@
         "adequate": false,
         "gap": "Patch-application controls provide no protection during the zero-day window and depend on mobile-fleet update enforcement that is weaker than for managed workstations."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this entry the deliverable is iOS 16.7.1 / iPadOS 16.7.1 installed and the device restarted onto it, driven from the 2023-10-05 KEV listing rather than left to the user's own update prompt. The packet's flaw-remediation gap names the mechanism that fails: mobile-OS remediation depends on user-driven or MDM-pushed updates, and fleet update compliance is slower than the timelines targeted exploitation runs on. So the substance of the control here is removing user deferral from the path — the update goes out through declarative device management with an enforced deadline instead of a notification the holder can dismiss indefinitely. Measure completion on the build each enrolled device reports after the restart, not on the state of the deployment in the management console: the packet records a fix that requires applying the release and rebooting, with no vendor live-patch mechanism, so a device that downloaded 16.7.1 and postponed the restart is still running the vulnerable kernel and must be counted as exposed. On a phone that restart is the step most reliably postponed, and a postponement recorded as patched is the specific way this remediation goes wrong. Scope the population from the packet's own fields — iOS and iPadOS below 16.7.1 — and note the boundary of this control: devices that cannot enrol, and enrolled devices sitting past the deadline, are not reached by a push at all and are the population the access-condition control has to catch instead.",
+        "evidence": "The packet's vector states the issue was addressed with improved checks and is fixed in iOS 16.7.1 and iPadOS 16.7.1, that a local attacker may be able to elevate their privileges, and that Apple is aware of a report that it may have been actively exploited against versions of iOS before iOS 16.6. affected_versions records iOS < 16.7.1 and iPadOS < 16.7.1. cisa_kev true with kev_date 2023-10-05, active_exploitation confirmed, CVSS 7.8, RWEP 61, poc_available false. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes stating there is no vendor live-patch mechanism and remediation requires applying the fixed release and rebooting. The cited flaw-remediation gap states mobile-OS flaw remediation depends on user-driven or MDM-pushed updates, that devices on iOS < 16.6 remain exploitable until the 16.7.1 update is installed, and that fleet update compliance is typically slower than targeted-exploitation timelines; the cited Essential-Eight gap states patch-application controls depend on mobile-fleet update enforcement that is weaker than for managed workstations.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's least-privilege gap makes the case for turning the build into an access condition: once a local process reaches kernel on iOS or iPadOS, the app-sandbox boundary that every on-device control is built on no longer holds, so nothing installed on the device can be relied on to constrain what the attacker does with organisational data. The lever that survives is on the other side of the connection — what the device is allowed to reach. For this CVE that means iOS/iPadOS 16.7.1 functions as a condition of access: a device below it is denied mail, VPN and document access until it reports the fixed build, rather than appearing as a red row on an update-compliance report while keeping every session it already holds. This is also the control that catches the population an MDM push cannot: the packet's system-security gap names slow-updating and unmanaged devices as where a local process could already reach kernel during the pre-16.7.1 window, and an unmanaged device is by definition not going to take a pushed update. Because the fix requires applying the release and rebooting with no live-patch path, the condition must be evaluated on the build the device is running after restart, not on the build it has downloaded. Distinguishing test: present a device pinned below 16.7.1 to each protected resource and confirm access is refused — an estate that surfaces the stale build on a dashboard while the device keeps its mail session has recorded the exposure rather than removed it. Precondition: this withholds data from an exposed device; it does not repair the device. A device that already ran the escalation is an incident, and denying it new access does not remove what was taken or evict an implant already installed — which, for a flaw the packet describes as exploited before iOS 16.6 in a manner consistent with targeted mobile surveillance, is the likelier state for anyone actually in the targeting set. Scope to what the packet names: iOS and iPadOS below 16.7.1.",
+        "evidence": "The cited least-privilege gap states that least-privilege at the app layer is bypassed by a kernel privilege escalation and that once kernel is reached the app-sandbox boundary the control relies on no longer holds. The cited system-security gap states that system-security assurance for mobile fleets presumes timely vendor patching yet offers no compensating control during the pre-16.7.1 zero-day window, when a local process could already reach kernel on slow-updating or unmanaged devices. The vector records the fix in iOS 16.7.1 and iPadOS 16.7.1 and exploitation reported against versions of iOS before iOS 16.6; affected_versions records iOS < 16.7.1 and iPadOS < 16.7.1. attack_vector describes a local attacker — typically a sandboxed app or an earlier stage of an exploit chain — elevating to kernel privileges, enabling implant installation on targeted devices; active_exploitation_notes records this as consistent with targeted mobile-surveillance use with no ransomware association. patch_available true, patch_required_reboot true, live_patch_available false, remediation requiring the fixed release plus a reboot. kev_date 2023-10-05, CVSS 7.8, RWEP 61.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this flaw inside a chain rather than at its start: the attack path is a local attacker — typically a sandboxed app or an earlier stage of an exploit chain — reaching kernel, with exploitation acknowledged against versions of iOS before 16.6, which is to say before the fix existed. That is the window the cited technical-vulnerability-management gap describes as impossible to enumerate: a control that reacts to advisories has nothing to act on until Apple discloses. The answer that exists before disclosure is a standing posture on the cohort plausibly inside the targeting set for a mobile-surveillance chain — the people whose devices hold the estate's most sensitive material and whose exposure would be worth a chain of this cost — placed in Apple's reduced-attack-surface mode as a default assignment, so that the automatic processing of untrusted web content, message attachments, fonts and link previews that an earlier chain stage relies on is already narrowed when the next undisclosed flaw arrives. Preconditions, and they bound this control tightly. The mode narrows delivery paths into a chain; it does nothing to this kernel flaw itself, and a stage that has already executed locally still reaches the kernel. It gives nothing against a malicious application already installed on the device, which the packet names as one of the two ways this local attacker arrives. And it only helps if it was enabled before the chain arrived — assigning it in reaction to this CVE protects nobody who was already targeted, so a device suspected of having been targeted belongs on a forensic path rather than a configuration path. It is a holding measure for the window before iOS/iPadOS 16.7.1 and the reboot it requires land, not a substitute for either.",
+        "evidence": "The packet's attack_vector states that a local attacker, typically a sandboxed app or an earlier stage of an exploit chain, leverages a kernel flaw fixed by improved checks to elevate to kernel privileges on iOS/iPadOS before 16.6, enabling implant installation on targeted devices. The vector records that Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.6, and that it is fixed in iOS 16.7.1 and iPadOS 16.7.1; active_exploitation_notes records this as consistent with targeted mobile-surveillance use. The cited technical-vulnerability-management gap states that vulnerability management cannot enumerate an unknown kernel zero-day and that coverage begins only after Apple's disclosure. cisa_kev true with kev_date 2023-10-05, active_exploitation confirmed, poc_available false, CVSS 7.8, RWEP 61. patch_available true, patch_required_reboot true, live_patch_available false, with remediation recorded as applying the fixed release and rebooting.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-42793": {
     "name": "JetBrains TeamCity Authentication Bypass Vulnerability",
@@ -54587,7 +56354,41 @@
         "adequate": false,
         "gap": "Browser/application hardening does not prevent exploitation of a zero-day codec bug; only patching the underlying libvpx closes it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The vector names Google Chrome, but the scope of this CVE lives in `affected` and `affected_versions`: the defect is in libvpx's VP8 encoding path prior to 1.13.1, bundled in Chrome prior to 117.0.5938.132 and in other browsers and applications that embed the codec, with Firefox named as one of them. A sweep scoped to the vector's headline product reports an estate standardised on Firefox — or on any other libvpx-embedding application — as clean while every one of those installs still carries the vulnerable encoder, and it is wrong to say no mapping into other products exists here because the packet states the mapping outright. For this CVE the control means one inventory line per product that carries the component, each closed at that product's own fixed level rather than at Chrome's: Chrome at 117.0.5938.132 or later, Firefox at the build its own vendor states carries libvpx 1.13.1 or later, a directly installed libvpx at 1.13.1 or later, and any other embedding application held open until its vendor ships a rebuild against the fixed codec, because those products move on their own update tracks and a browser-update report says nothing about them. Keep the sweep to what the packet establishes: it ties the overflow to libvpx and to software embedding libvpx, so an application enters the inventory when composition data actually shows the component inside it, not because it happens to play video — instructing operators to treat every media-handling binary as an instance of this CVE manufactures findings against software no evidence implicates. Precondition on how completion is measured: patch_required_reboot is false, which means no machine reboot, and it does not mean the fix is live. libvpx is mapped into the host application's own process, so a browser or application that has downloaded and staged the fixed build keeps executing the vulnerable encode path until that process is relaunched; count an install remediated on the version the running process reports, not on the version sitting on disk. live_patch_available is false and the packet records no vendor live-patch mechanism, so applying the vendor fixed release is the whole of the remediation and a long-running session has no in-place alternative. Distinguishing test: after the browser fleet reports updated, query each managed host for every artifact whose composition data lists libvpx and confirm none resolves below 1.13.1 — a flaw-remediation attestation that closes on 'Chrome is current' reads clean while a second embedding application keeps serving the same actively exploited heap overflow to crafted web content.",
+        "evidence": "Packet vector: 'Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.' Packet affected: 'libvpx VP8 encoding as bundled in Google Chrome prior to 117.0.5938.132 and libvpx prior to 1.13.1; also affects other browsers/applications (e.g. Firefox) and software embedding vulnerable libvpx.' affected_versions lists 'Google Chrome < 117.0.5938.132', 'libvpx < 1.13.1' and 'Applications bundling libvpx < 1.13.1 (e.g. Firefox and others)'. NIST-800-53-SI-2 gap: 'flaw remediation must reach not just Chrome/Firefox but every embedding app, so SI-2 tracking of a single browser CVE under-scopes the true exposure.' UK-CAF-B4 gap: 'System-security inventories track named browsers, but libvpx is a bundled codec inside many applications, so patching only Chrome/Firefox leaves the same actively-exploited zero-day live in every other embedding app.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' CISA KEV 2023-10-02, active_exploitation confirmed, CWE-787, CVSS 8.8, RWEP 54.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "This CVE is only findable through composition data. libvpx is not a product an operator installs or an inventory names — it arrives inside Chrome, inside Firefox, and inside whatever else bundles it, which is why the packet's own vulnerability-management gaps record that inventories rarely enumerate a transitive library like this one and that named-product tracking misses the software-composition dimension entirely. The requirement for this CVE is that the estate's SBOM or composition data resolve to the bundled and statically linked level, so that the query 'which artifacts here contain libvpx below 1.13.1' returns a list at all rather than returning nothing because no inventory row is called libvpx. That list, not the browser inventory, is the population for the patch-parity work; without it the operator cannot even tell whether an application is in scope, and the KEV clock that opened 2023-10-02 runs against an unknown denominator. Precondition, and it is the one that gets skipped: this reaches only components the composition data actually records. An application shipped as an opaque vendor binary with no SBOM answers nothing and does not become safe by being absent from the query — for those the question goes to the vendor as a direct request for the libvpx level in that build, and the artifact stays open until the vendor answers. This control produces the scope; it remediates nothing on its own, and each artifact it surfaces still needs its vendor's fixed release, since the packet records no live-patch mechanism.",
+        "evidence": "Packet NIS2-Art21-vulnerability-management gap: 'Vulnerability-management inventories rarely enumerate transitive/bundled libraries like libvpx, so many affected applications are not flagged as needing the fix.' Packet ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management focused on named products misses the software-composition dimension (SBOM) needed to find every libvpx-embedding artifact.' affected_versions includes 'Applications bundling libvpx < 1.13.1 (e.g. Firefox and others)'. active_exploitation_notes: 'the vulnerable libvpx codec is embedded far beyond Chrome, including Firefox and many applications that bundle it.' CISA KEV 2023-10-02; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "Delivery for this CVE is a crafted HTML page, so the victim's only required action is visiting one, and the packet records the flaw being used as a zero-day to deliver commercial spyware attributed by Google TAG to a surveillance vendor. Against that delivery path the enterprise update ring is the thing that actually sets the exposure window on the two browsers the packet names: a security-channel release held back for a staged rollout leaves managed Chrome and Firefox rendering attacker-supplied media through the vulnerable VP8 encode path for the length of the deferral. The requirement here is that the Chrome and Firefox security-channel updates carrying libvpx 1.13.1 or later are not deferred behind a ring, and that relaunch is enforced rather than left to the user — patch_required_reboot is false, so there is no machine reboot to schedule, but the codec is loaded into the browser's own process and a browser left running for days after the update stages is still executing the pre-fix code. Measure the ring's completion on the version the running browser reports. Two preconditions bound this control. It covers only the browsers the update ring manages, and the packet places the same vulnerable codec inside other applications that update on separate vendor tracks — those are outside this control entirely and need the inventory-and-parity work instead. And it does nothing during the window before the fixed build reaches a host: live_patch_available is false, the packet records no live-patch mechanism, and the AU Essential Eight application-hardening gap on this entry states the position directly — hardening does not prevent exploitation of the codec bug, only reaching the fixed libvpx does.",
+        "evidence": "Packet vector: exploitation of heap corruption 'via a crafted HTML page'. active_exploitation_notes: 'Exploited as a zero-day to deliver commercial spyware (attributed by Google TAG to a surveillance vendor)'. AU-Essential-8-App-Hardening gap: 'Browser/application hardening does not prevent exploitation of a zero-day codec bug; only patching the underlying libvpx closes it.' affected_versions: 'Google Chrome < 117.0.5938.132', 'libvpx < 1.13.1', 'Applications bundling libvpx < 1.13.1 (e.g. Firefox and others)'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' poc_available false, active_exploitation confirmed, CISA KEV 2023-10-02.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2018-14667": {
     "name": "Red Hat JBoss RichFaces Framework Expression Language Injection Vulnerability",
@@ -55011,7 +56812,29 @@
         "adequate": false,
         "gap": "Patch-application maturity is the real fix; the control is unmet on the many self-hosted MinIO deployments that lag releases."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For MinIO the clock runs backwards from the usual shape, and the packet gives both ends of it: the fixed release is RELEASE.2023-03-20T20-16-18Z and the KEV listing is 2023-09-19, so the fix was reachable roughly six months before CISA attested exploitation. On this entry the control is therefore not 'compress the patch window' — there was no window to compress — it is that the KEV listing must force an upgrade that every self-hosted MinIO deployment could already have taken. The half that decides whether this lands is measurement: completion is the RELEASE string the running MinIO server process reports, not the package, chart or container image on disk. The packet records patch_required_reboot false and live_patch_available false, with remediation stated as applying the vendor fixed release — so no host reboot is owed, but a server whose new image is staged while the process still executes a pre-RELEASE.2023-03-20T20-16-18Z build is still serving the vulnerable PostPolicyBucket path, and a deployment that was updated but never restarted onto the new binary reads current on an inventory while remaining fully exploitable. Scope from what affected and affected_versions name: MinIO before RELEASE.2023-03-20T20-16-18Z, which on a real estate means the standalone clusters, the operator-deployed StatefulSets and the copies bundled inside other stacks that an application inventory records under the surrounding product's name rather than MinIO's. Widen the sweep to any further product only where a verified source identifies it as carrying the same MinIO code; do not silently assume the vulnerable path is confined to instances someone has already labelled MinIO.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-09-19, active_exploitation 'confirmed', poc_available true, cvss 8.8, rwep_score 67. patch_available true; the vector names the fix as 'This issue has been patched in RELEASE.2023-03-20T20-16-18Z', which precedes the KEV date the same packet records. affected_versions: 'MinIO before RELEASE.2023-03-20T20-16-18Z'. patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' active_exploitation_notes: 'exploited in the wild and frequently chained with CVE-2023-28432 to escalate from limited credentials to arbitrary object writes on internet-exposed MinIO consoles. KEV ransomware status: unknown.' AU-Essential-8-Patch gap: 'Patch-application maturity is the real fix; the control is unmet on the many self-hosted MinIO deployments that lag releases.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management assumes prompt upgrade to RELEASE.2023-03-20T20-16-18Z; unpatched, internet-exposed MinIO instances remain exploitable.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This CVE has two stated exploit preconditions rather than one — the packet requires credentials carrying arn:aws:s3:::* and Console API access enabled — and the vector also records a MINIO_BROWSER workaround, so a MinIO instance can sit in a state that is neither exploitable-as-shipped nor upgraded. That state has to be recorded as its own verdict with a dated action to reach RELEASE.2023-03-20T20-16-18Z, not folded into 'patched per SLA'. Two cautions bind the mitigation half here. First, the workaround sentence as recorded in the packet reads 'As a workaround, enable browser API access and turn off `MINIO_BROWSER=off`', which is self-contradictory as written, so the exact setting must be taken from the vendor advisory and not from that line; what the packet does state unambiguously is that the attack requires Console API access enabled, so removing Console API reachability removes one named precondition. Second, that removal holds only while it stays in force and only where operators do not need the console: it does not repair the metadata bucket-name check, and it evicts nothing already written. The exploitation primitive the packet describes is writing objects into arbitrary buckets, so objects placed before the mitigation went on remain in those buckets — an instance that was internet-exposed with the console enabled needs its bucket contents compared against a known-good baseline rather than being closed on a configuration change. The second precondition, the wildcard arn:aws:s3:::* grant, is not something this control touches at all; the least-privilege and access-enforcement gaps cited on this entry stay open, and a network-security attestation continues to pass cleanly while a deliberately exposed console is reached with valid over-privileged credentials, which is precisely why the exposed-with-mitigation state must be visible as residual risk instead of as a green row.",
+        "evidence": "Packet vector: 'an attacker can use crafted requests to bypass metadata bucket name checking and put an object into any bucket while processing `PostPolicyBucket`. To carry out this attack, the attacker requires credentials with `arn:aws:s3:::*` permission, as well as enabled Console API access.' and 'As a workaround, enable browser API access and turn off `MINIO_BROWSER=off`.' live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' NIS2-Art21-network-security gap: 'Network-security measures do not help when the Console API is deliberately exposed and reached with valid (over-privileged) credentials.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management assumes prompt upgrade to RELEASE.2023-03-20T20-16-18Z; unpatched, internet-exposed MinIO instances remain exploitable.' NIST-800-53-AC-6 gap records the wildcard grant as 'a common default'. cisa_kev true (2023-09-19), active_exploitation 'confirmed', poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2022-22265": {
     "name": "Samsung Mobile Devices Use-After-Free Vulnerability",
@@ -55344,7 +57167,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management is periodic; a client-side zero-day exploited on open needs continuous endpoint monitoring beyond A.8.8's assessment cadence."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet names the affected product as Adobe Acrobat and Adobe Acrobat Reader on Windows and macOS, and its affected_versions splits that into three separate update tracks: Acrobat/Reader DC at or below 23.003.20284, Acrobat/Reader 2020 at or below 20.005.30516, and Acrobat/Reader 2020 (Classic) at or below 20.005.30514. On a real estate those are separate products on separate update mechanisms, and per-user copies land outside managed software distribution, so this control means enumerating every Acrobat and every Reader install across all three tracks and both operating systems and confirming each reports a build above its own track's affected ceiling, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope stops there. The packet ties the CWE-787 out-of-bounds write to Acrobat and Reader and gives no mapping into other PDF-handling software, so treating every PDF-capable binary on the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates; widen the inventory only where a verified source identifies another product carrying the same code. Drive the sweep on the clock that opened with the 2023-09-14 KEV listing rather than on the 2023-10-05 due date the packet's flaw-remediation gap records, because the packet states the flaw was exploited in the wild before Adobe's September 2023 fix existed, so the due date trails the exploitation it is supposed to bound. Distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs and produce each one's build, confirming none still sits at or below its own track's affected version. An estate that updates the inventoried Reader DC copy while a 2020 Classic install stays at 20.005.30514 still opens crafted PDFs into the out-of-bounds write, with a flaw-remediation attestation that reads clean. Preconditions: this reaches only copies the inventory can see and the operator can update, so an unmanaged per-user install is remediated by removing it, not by recording it as patched. The packet records no live-patch mechanism and states that remediation requires applying the vendor fixed release, so completion has to be measured on the build each install is actually executing rather than on a deployment task marked successful; a copy where the update is staged but the Acrobat or Reader process has not come up on the new build is still running the vulnerable parser. And because active exploitation is confirmed and delivery is an attacker-supplied file, a user who opened an untrusted PDF while their install was at or below the affected version belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet fields: affected = 'Adobe Acrobat and Adobe Acrobat Reader (Windows and macOS) processing a maliciously crafted PDF; out-of-bounds write reachable when the victim opens the file'; affected_versions = 'Acrobat/Reader DC <= 23.003.20284', 'Acrobat/Reader 2020 <= 20.005.30516', 'Acrobat/Reader 2020 (Classic) <= 20.005.30514'; cwe_refs = CWE-787; cisa_kev = true with kev_date 2023-09-14; active_exploitation = confirmed, with active_exploitation_notes 'Exploited in the wild as a zero-day before Adobe's September 2023 fix'; patch_available = true, live_patch_available = false, live_patch_notes = 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release'; patch_required_reboot = false (no host reboot recorded). The 2023-10-05 KEV due date is the figure recorded in the packet's NIST-800-53-SI-2 gap ('the KEV due date (2023-10-05) trailed active exploitation, so SI-2 SLAs alone do not close the exposure'), which is also the ISO-27001-2022-A.8.8 gap's point that periodic technical-vulnerability management does not match a client-side zero-day exploited on open. poc_available is false on this entry, so no public exploit code is claimed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation of this CVE requires the victim to open an attacker-supplied PDF: the packet's vector states that exploitation requires user interaction in that a victim must open a malicious file, and its attack_vector has the attacker delivering a crafted PDF whose opening triggers the out-of-bounds write and code execution in the current user's context. On any Acrobat or Reader install not yet above its track's fixed build, the delivery path is therefore the only lever the operator holds. Require an untrusted-origin marking on every PDF arriving by mail, web download, or untrusted file share, and require marked PDFs to open in Acrobat's reduced-privilege isolated render rather than the full parsing path that carries the CWE-787 write at the user's own privilege; the packet's application-hardening gap names exactly this pairing, disabling Acrobat's embedded JavaScript and opening untrusted PDFs in Protected View, as the compensating control the KEV entry does not mandate, and its EU vulnerability-handling gap names the attachment sandboxing and mail filtering that keeps the file from reaching the parser at all. The marking must survive the container: a PDF extracted from an archive, mounted from an image, or renamed has to still reach Acrobat marked untrusted, and the user-facing escape from the isolated render has to be blocked by policy rather than left as a click, since the whole exploit precondition is one user action. Distinguishing test: mail a PDF nested inside an archive to a managed workstation, extract it, open it, and confirm it lands in the isolated render rather than the full parser; an attestation that records the hardening policy as configured still lets a provenance-stripped PDF reach the vulnerable parser with full user privileges. Preconditions, and they are the load-bearing half here. This contains the render, it does not repair the write: the out-of-bounds write is still present in the binary, so this is a holding measure for the window before the fixed build lands, which on this entry is precisely the window that mattered because the packet records exploitation in the wild before Adobe's September 2023 fix existed. It holds only where the ingress path actually applies the marking, so a PDF arriving on removable media, pulled from an internal share the policy treats as trusted, or re-saved by the user loses the tag and opens into the full parser, and those paths need to be enumerated rather than assumed covered. And it does nothing for a workstation on which a crafted PDF has already been opened: active exploitation is confirmed and the outcome is code execution in the user's context, so that machine is an incident, not a configuration item.",
+        "evidence": "Packet fields: vector = 'Exploitation of this issue requires user interaction in that a victim must open a malicious file'; attack_vector = 'An attacker delivers a crafted PDF; opening it in a vulnerable Acrobat/Reader build triggers an out-of-bounds write and arbitrary code execution in the current user's context'; cwe_refs = CWE-787; active_exploitation = confirmed with active_exploitation_notes 'Exploited in the wild as a zero-day before Adobe's September 2023 fix'. The named compensating measures are taken from the packet's own gap text: AU-Essential-8-App-Hardening = 'Hardening endpoint applications (disabling Acrobat's embedded JavaScript / opening untrusted PDFs in Protected View) is the compensating control the KEV entry does not mandate; patch cadence alone left users exposed at open-time'; NIS2-Art21-vulnerability-handling = 'Requires timely handling but not the user-interaction-blocking controls (attachment sandboxing, mail filtering) needed to stop a document-delivered client RCE between disclosure and patch'; UK-CAF-B4 = 'System security expects patched software but does not force the endpoint isolation/EDR detection required for a memory-corruption RCE that fires on document open'. patch_available is true with live_patch_available false, so this control is stated as interim to the fixed release rather than as an alternative to it.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIS2-Art21-vulnerability-handling",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-35674": {
     "name": "Android Framework Privilege Escalation Vulnerability",
@@ -55536,7 +57382,31 @@
         "adequate": false,
         "gap": "System security expects patched software but gives no mechanism to inventory and update a codec vendored into dozens of applications."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet refuses to scope this to a browser and the inventory must not either. It records the flaw in libwebp below 1.3.2, states that everything embedding it is reachable through a crafted WebP image, and names Google Chrome below 116.0.5845.187 alongside Chromium-based browsers and Electron and native applications that bundle their own copy. That is the population this control requires enumerated, each install held to its own fixed build rather than to the browser's: Chrome at 116.0.5845.187 or later, each Chromium-based browser at the build its own vendor ships carrying the fix, and each Electron or native application at a build carrying libwebp 1.3.2 or later. Scoping the sweep to Chrome is the specific failure the packet's gaps describe — flaw remediation keyed to the browser misses the sprawl of applications shipping their own libwebp, and a vulnerability-management process scoped to OS and browser inventories never enumerates the embedded copies at all — so an estate standardised on a Chromium-based browser other than Chrome, or one whose desktop applications are Electron, produces a clean patch report while the decoder stays reachable from any rendered image. Do not widen past what the packet establishes: it ties the overflow to libwebp's VP8L Huffman-table decoding, so treating every image-handling or media-parsing binary in the estate as an instance of this CVE manufactures findings and update work against software no evidence implicates; widen only where a verified source names another product carrying this component. Precondition on completion, and it is the one most often mis-read here: patch_required_reboot is false, which means no machine reboot — it does not mean the fix is live. libwebp is mapped into a running process, so a browser or application that has received the new build keeps decoding through the copy already loaded until that process restarts, and the packet records no live-patch path. Measure each install on the version the running process is executing, not on what the software-distribution console reports as delivered. And because exploitation is confirmed and delivery is attacker-controlled content — a crafted HTML page, or any WebP image a vulnerable decoder renders — a host that rendered untrusted content while below the fixed build belongs on the incident path rather than being closed on the inventory.",
+        "evidence": "Packet affected: 'libwebp < 1.3.2 (and everything embedding it), reached via a crafted WebP image; Google Chrome prior to 116.0.5845.187 and numerous Chromium/Electron and native applications that decode WebP.' affected_versions: 'libwebp < 1.3.2', 'Google Chrome < 116.0.5845.187', 'Chromium-based browsers and Electron/native apps bundling libwebp < 1.3.2'. attack_vector: a crafted WebP image with malformed lossless (VP8L) Huffman coding tables overflows libwebp's BuildHuffmanTable, reachable via a crafted HTML page or any app that renders WebP. NIST-800-53-SI-2 gap: 'Flaw remediation must reach every application that statically or dynamically links libwebp, not just the browser; SI-2 patch tracking keyed to Chrome misses the sprawl of Electron/native apps that ship their own libwebp.' UK-CAF-B4 gap: 'System security expects patched software but gives no mechanism to inventory and update a codec vendored into dozens of applications.' AU-Essential-8-Patch gap: 'Patch maturity assumes a single vendor update path.' ISO-27001-2022-A.8.8 gap: technical-vulnerability management scoped to OS/browser inventories does not enumerate embedded libwebp. Remediation state: patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' CWE-787, CISA KEV 2023-09-13, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 79, EPSS ~0.997.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The reason the install inventory above cannot be built from an application list alone is the problem this control addresses. libwebp is not something an operator installs; it is a component vendored beneath products, and the packet's vulnerability-handling gap states outright that vulnerability management does not by itself require the SBOM or component inventory needed to find every product bundling the vulnerable codec. For this CVE that means component inventory has to reach the depth at which libwebp actually sits — statically linked into a native application, bundled inside an Electron runtime, or pulled in transitively by a framework the application depends on — and has to resolve to a version, because the only question that matters per artifact is whether the copy it ships is below 1.3.2. An SBOM that stops at the dependencies an application declares directly will not name libwebp at all for most of the affected population, which is how an estate can hold a complete and current application inventory and still not know where the vulnerable decoder is. Precondition, and it bounds what this control can be credited with: it produces knowledge, not remediation. It tells the operator which artifacts carry a copy below 1.3.2; each of those still has to reach a build carrying libwebp 1.3.2 or later from a vendor who may ship on a slower track than the browser, and the packet records no live-patch path, so each of those updated processes still has to be restarted before the fix is executing. Where a bundling application ships no updated build at all, the component inventory is what converts an invisible exposure into a decision the operator can actually take about that application rather than one they never knew they were carrying.",
+        "evidence": "Packet NIS2-Art21-vulnerability-management gap: 'Vulnerability management does not by itself require an SBOM/component inventory to find every product bundling the vulnerable codec, leaving unmanaged copies exposed to a crafted image.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management scoped to OS/browser inventories does not enumerate embedded libwebp in third-party software, so a supply-chain-wide image-decoder flaw stays unpatched in bundled copies.' affected: 'libwebp < 1.3.2 (and everything embedding it)'; affected_versions includes 'Chromium-based browsers and Electron/native apps bundling libwebp < 1.3.2'. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' CISA KEV 2023-09-13, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 79.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-36761": {
     "name": "Microsoft Word Information Disclosure Vulnerability",
@@ -55818,7 +57688,39 @@
         "adequate": false,
         "gap": "Response and recovery planning is not scoped for targeted commercial-spyware zero-click intrusions that demand vendor-assisted forensics."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The delivery path the packet records for this Wallet flaw is a maliciously crafted attachment processed for arbitrary code execution with no user interaction, as the second half of the BLASTPASS chain with CVE-2023-41064 that installed Pegasus. Nothing about that path involves a user decision, so on this entry the reduced-attack-surface half of the control is the only lever that operates before the fixed build lands. For the population the organisation assesses as plausibly inside the targeting set for a mercenary-spyware chain, place devices in Apple's reduced-attack-surface mode so message attachments and link previews are not processed automatically, narrowing the route into the Wallet validation flaw during the window that opened before disclosure and closed only when the fixed release and its reboot completed across those devices. Scope by the packet's affected list rather than by handset: iOS and iPadOS below 16.6.1 and watchOS below 9.6.2. This has to be a standing posture assigned before the next disclosure, not a reaction to the 2023-09-11 KEV listing, because the mode only helps if it was already on when the chain arrived, and this chain was in use before Apple shipped the fix. Precondition, stated plainly: the mode narrows delivery, it does not repair the validation flaw and it does not evict an implant on a device that was already exploited. The packet records execution with no user interaction and Citizen Lab discovering the chain in the wild, so a device assessed as having received the attachment belongs on the forensic path, and the fixed release plus the reboot the packet requires remains the remediation for every device regardless of the mode.",
+        "evidence": "Packet vector: 'A validation issue was addressed with improved logic. This issue is fixed in watchOS 9.6.2, iOS 16.6.1 and iPadOS 16.6.1. A maliciously crafted attachment may result in arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.' active_exploitation_notes: 'Zero-click zero-day discovered by The Citizen Lab as the second half of the BLASTPASS chain (with CVE-2023-41064) delivering NSO Group's Pegasus.' AU-Essential-8-Patch gap: 'Patch maturity cannot cover a flaw exploited before a fix exists; Apple's Lockdown Mode was the effective pre-patch mitigation and is not framework-mandated.' ISO-27001-2022-A.8.8 gap: the periodic control 'offers no protection during in-the-wild use and does not mandate the Lockdown-Mode mitigation that actually blunts it.' NIST-800-53-SI-2 gap: 'the Wallet validation fix shipped only after in-the-wild use, so SI-2 SLAs offer no protection during exploitation.' affected_versions: 'iOS/iPadOS < 16.6.1', 'watchOS < 9.6.2'. cisa_kev true, kev_date 2023-09-11, cvss 7.8, rwep_score 60, poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The enforced target for this CVE is the packet's own fixed builds, iOS and iPadOS 16.6.1 and watchOS 9.6.2, driven from the 2023-09-11 KEV listing with user deferral disallowed. Two scoping details decide whether the enforcement is real. First, the packet names watchOS as an affected platform alongside iOS and iPadOS and gives watchOS 9.6.2 as its own fixed build, so an estate that measures only iPhone and iPad builds reports itself clean while the watch population is unmeasured; each platform must be counted against its own fixed build. Second, the packet records no vendor live-patch mechanism and remediation that requires applying the fixed release and rebooting, so completion is the build a device reports after that restart. A device that downloaded 16.6.1 and has not restarted is still executing the vulnerable Wallet code, and on personal-feeling devices the restart is exactly the step users defer, so a deferral recorded as patched is the specific way this remediation goes wrong. Precondition: this control addresses only the residual population after Apple shipped the fix. It cannot close the pre-disclosure window that the flaw-remediation gap on this entry actually names, because the chain was in use before the release existed, and it reaches only enrolled devices. It is also a remediation control and not a containment one: pushing 16.6.1 to a device that was already exploited closes the entry path without addressing what was installed through it, which is why that device needs the forensic route instead of being closed on its build number.",
+        "evidence": "Packet affected_versions: 'iOS/iPadOS < 16.6.1', 'watchOS < 9.6.2'. live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' patch_available true, patch_required_reboot true, live_patch_available false. cisa_kev true, kev_date 2023-09-11, active_exploitation confirmed. NIST-800-53-SI-2 gap: 'Flaw remediation cannot pre-empt a zero-click zero-day used to deliver Pegasus; the Wallet validation fix shipped only after in-the-wild use, so SI-2 SLAs offer no protection during exploitation.' affected: 'Apple Wallet on iOS, iPadOS and watchOS; a maliciously crafted attachment exploits a validation flaw to execute code. Chained with CVE-2023-41064 (BLASTPASS).'",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet records this as a zero-click zero-day found by The Citizen Lab as the second half of the BLASTPASS chain delivering NSO Group's Pegasus, and it records why ordinary handling fails on it: incident handling assumes detectable telemetry, a zero-click spyware chain leaves minimal evidence and requires specialised forensic acquisition to trigger the process at all, and response and recovery planning is not scoped for targeted commercial-spyware intrusions that demand vendor-assisted forensics. So what this CVE demonstrates is the need for an explicit escalation trigger on the mobile estate that routes a suspected commercial-spyware chain to specialised acquisition and vendor engagement rather than to a reimage or a wipe-and-reissue ticket, which destroys the only evidence such a chain leaves. The trigger cannot be a device-side alert, and the packet is the reason: the monitoring gap on this entry states that mobile endpoint monitoring yields little signal from a zero-click Wallet exploit. It has to be an external one, such as attribution of a chain by a research organisation, of the kind that surfaced this CVE, against a device in the packet's affected range, or an organisational assessment that a specific user is plausibly inside a mercenary-spyware targeting set. Precondition: this is a response control. It does nothing to prevent the execution and nothing to shorten the pre-fix window, and it is only actionable if the path exists before the trigger fires, which means naming in advance who performs the acquisition, with what tooling, and under what authority when the device may be personally owned rather than organisational. Escalation with no pre-arranged acquisition capability produces a wipe, and a wipe on this chain ends the investigation.",
+        "evidence": "Packet active_exploitation_notes: 'Zero-click zero-day discovered by The Citizen Lab as the second half of the BLASTPASS chain (with CVE-2023-41064) delivering NSO Group's Pegasus.' NIS2-Art21-incident-handling gap: 'Incident handling assumes detectable telemetry; a zero-click spyware chain leaves minimal evidence, requiring specialized forensic acquisition to trigger the process.' UK-CAF-D1 gap: 'Response and recovery planning is not scoped for targeted commercial-spyware zero-click intrusions that demand vendor-assisted forensics.' NIST-800-53-SI-4 gap: 'System monitoring on mobile endpoints yields little signal from a zero-click Wallet exploit, so SI-4 detection cannot reliably surface the intrusion.' attack_vector: 'A maliciously crafted attachment processed by Wallet exploits a validation flaw for code execution with no user interaction.' affected_versions: 'iOS/iPadOS < 16.6.1', 'watchOS < 9.6.2'. active_exploitation confirmed, kev_date 2023-09-11.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-D1"
+        ]
+      }
+    ]
   },
   "CVE-2023-33246": {
     "name": "Apache RocketMQ Command Execution Vulnerability",
@@ -57205,7 +59107,30 @@
         "adequate": false,
         "gap": "A.8.28 secure-coding controls should have caught the unescaped reflection of user-controlled URL parameters into the Classic Web Client; because the sink shipped to production and was exploited before the patch, the control failed at the code level rather than the deployment level."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock has two starts and the estate has to be driven against the earlier one. Zimbra Collaboration 8 installs below 8.8.15 Patch 41 carry the Classic Web Client sink the packet describes — an unescaped URL parameter reflected into rendered HTML inside the authenticated webmail origin — and the packet places exploitation at 2023-06-29, roughly four weeks before the 2023-07-27 KEV listing and ahead of the vendor advisory. A KEV-tied SLA measured from 2023-07-27 alone therefore produces a remediation record for the tail of the campaign, not for the campaign. Applied to this product: enumerate every Zimbra Collaboration 8 mail server in service, drive each to 8.8.15 Patch 41, and measure completion on the version the running Zimbra services report after they restart. The packet records no live-patch path and states that applying Patch 41 restarts the Zimbra services though not the host, so an instance where the package landed but the webmail service was never restarted is still serving the vulnerable Classic Web Client and counts as exposed — patch_required_reboot being false says only that the machine stays up. Distinguishing test: request the Classic Web Client from each server and confirm the build it actually serves is at or above 8.8.15 Patch 41; an inventory row reading 'Patch 41 applied' beside a running service still answering on the prior build is precisely how this remediation gets recorded complete while the sink is live. Precondition, and the one most often missed here: the packet states the exploit steals mailbox data, cookies and auth tokens from the victim's session, and Patch 41 does nothing to a token already taken — a server reachable during the exposure window needs its webmail sessions invalidated and the credentials of users who could have clicked a crafted link rotated, rather than being closed on the patch record. Steering users toward a different client is not a substitute either: the Classic Web Client endpoint stays served by the same instance until the build carries the fix.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-07-27, active_exploitation confirmed, poc_available true, rwep_score 62 against cvss 6.1. active_exploitation_notes: 'Google TAG observed four distinct groups — including the Russia-aligned Winter Vivern — exploiting the flaw against government targets in Moldova and Tunisia starting 2023-06-29, at least two weeks before Zimbra's advisory.' affected: the ZCS Classic Web Client 'which reflects an unescaped URL parameter into rendered HTML, enabling cross-site scripting in the authenticated webmail origin'; affected_versions: 'Zimbra Collaboration 8 before 8.8.15 Patch 41'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying Zimbra 8.8.15 Patch 41, which restarts Zimbra services but not the host.' attack_vector: attacker JavaScript runs in the webmail origin when an authenticated victim clicks a crafted link, 'allowing theft of mailbox data, cookies, and auth tokens'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-072",
+        "name": "PRIMARY-SOURCE-INTAKE-VENDOR-BLOG-COVERAGE",
+        "description": "This entry extends the control's premise past vendor blogs to the vendor's own public source repository. The packet records that Zimbra's fix landed in public source on 2023-07-05 and that a later wave of attackers harvested it from there and exploited the flaw before 8.8.15 Patch 41 shipped — so for the interval between that push and the released patch, the authoritative signal that Zimbra 8 webmail was exploitable existed in a primary source while every advisory-driven feed the estate subscribes to was still silent. For an operator running Zimbra Collaboration 8 the requirement is concrete: treat the vendor's public commit stream for that product as a monitored intake source alongside the advisory page; make a security-relevant commit touching the webmail rendering path, with no accompanying advisory, open a case rather than wait for the bulletin; and start the internal remediation clock at the earlier of the two signals rather than at the advisory. Distinguishing test: take a fix the vendor published in source ahead of its own advisory and check whether the intake pipeline raised anything on the commit date — a pipeline whose Zimbra coverage is the advisory page alone produces nothing, which is exactly the result it produced in July 2023 while a second wave was already exploiting the harvested fix. Precondition, stated because this control is easy to over-credit: it shortens the interval between a public fix and the operator knowing, and it gives nothing at all for the first window the packet describes — 2023-06-29 through the 2023-07-05 push — during which the flaw was a zero-day with no fix in any source. That window is bounded by response and by session/credential invalidation after the fact, not by intake coverage.",
+        "evidence": "Packet active_exploitation_notes: 'A later wave harvested the fix from Zimbra's public GitHub (pushed 2023-07-05) and exploited it before the official 8.8.15 Patch 41 shipped', with initial exploitation from 2023-06-29 'at least two weeks before Zimbra's advisory'. The NIST-800-53-SI-10 gap in framework_control_gaps states that 'because the fix landed in public source on 2023-07-05 before the advisory, an SI-10 review keyed to vendor bulletins had no signal until attackers were already stealing tokens'. The NIS2-Art21-patch-management gap states 'a bulletin-driven patch process left webmail exploitable through the KEV 2023-07-27 window and until 8.8.15 Patch 41'. The AU-Essential-8-Patch gap states the two-week clock 'starts at fix availability' and that the flaw was exploited 'via the leaked commit before 8.8.15 Patch 41, so an on-time patcher was still exposed during the active campaign'.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-38606": {
     "name": "Apple Multiple Products Kernel Unspecified Vulnerability",
@@ -57753,7 +59678,39 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management presumes a triage-and-schedule flow, but an exploited WebKit zero-day demands emergency out-of-cycle patching; standard prioritization SLAs would leave a code-execution-on-page-load bug open far too long."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this WebKit entry the control means the KEV-class update is driven onto managed Apple endpoints from the 2023-07-13 listing with user deferral disallowed, because user-side deferral is precisely the failure the packet records: devices with automatic Rapid Security Response or updates disabled stayed exploitable through ordinary browsing until the fix was installed by hand. Completion has to be measured on the build the device is actually running after its restart, not on the update being approved, downloaded, or reported as applied — the packet registers no live-patch mechanism for WebKit and states the fixed release or the corresponding Rapid Security Response requires a device restart, so a device holding the update but not yet restarted is still executing vulnerable WebKit and still renders attacker-controlled web content through it. Scope the enforcement to every product the packet names rather than to the device classes this control's estate definition covers: iOS and iPadOS at 16.6, macOS Ventura at 13.5 and Safari at 16.5.2 fall inside a normal Apple device-management ring, but tvOS 16.6 and watchOS 9.6 are separate fixed builds in the same affected list and need enumerating on their own rather than being assumed covered by the ring that reports on phones and Macs. The packet's affected field further extends the same WebKit defect to non-Apple products embedding WebKit for HTML processing; it names no specific one, so widen the inventory to a given third-party product only where a verified source identifies it as carrying the component, and reach that product's own fixed build rather than treating the Apple builds as covering it.",
+        "evidence": "Packet fields for CVE-2023-37450: cisa_kev true with kev_date 2023-07-13, active_exploitation confirmed, cvss 8.8, cwe_refs CWE-787, patch_available true, patch_required_reboot true, live_patch_available false. live_patch_notes: 'No live-patch mechanism for WebKit; remediation is installing the Apple fixed release (iOS/iPadOS 16.6, Safari 16.5.2, macOS Ventura 13.5, tvOS 16.6, watchOS 9.6) or the corresponding Rapid Security Response, which requires a device restart.' affected_versions lists iOS/iPadOS < 16.6, Safari < 16.5.2, macOS Ventura < 13.5, tvOS < 16.6, watchOS < 9.6; the affected field covers iOS, iPadOS, macOS, Safari, tvOS and watchOS and non-Apple products embedding WebKit for HTML processing. The NIST-800-53-SI-2 gap states that devices with automatic RSR/updates disabled remained exploitable through simple web browsing until the fix was manually installed after the 2023-07-13 KEV listing. The AU-Essential-8-Patch gap states that fleets of iPhones, iPads and Macs are hard to force-update within the 48-hour target.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "This CVE is a defect in the web engine itself, and the packet treats Safari as its own fixed build — Safari 16.5.2 is listed separately from macOS Ventura 13.5 — so on a managed Mac estate the browser has an update path that an OS-scoped deferral does not carry. The requirement here is that the channel delivering the Safari update and Apple's out-of-band Rapid Security Response is exempt from ring staging: the packet records that the fix shipped out of band rather than on the scheduled release cadence, and that organizations relying on managed update rings could not push it fast enough to close a bug reachable by any browsed page. A ring configured to hold releases for change-control review, with no security-channel exemption, keeps the estate on vulnerable WebKit for the duration of that hold while the rendering path stays fully exposed. Two preconditions on this control, both of which are how it gets over-recorded as the mitigation: it is an administrator-side lever only, so it does nothing on a device where the user has switched automatic updates off — the packet names that as a separate failure, and it belongs to the device-management enforcement path rather than to this one. And releasing the update into the ring is not the completion state: the packet records a required device restart with no live-patch mechanism, so a Mac that has taken Safari 16.5.2 or the Rapid Security Response but has not restarted is still running the pre-fix engine.",
+        "evidence": "Packet fields for CVE-2023-37450: affected_versions lists 'Safari < 16.5.2' and 'macOS Ventura < 13.5' as separate entries; live_patch_notes names both the fixed releases and 'the corresponding Rapid Security Response, which requires a device restart', with live_patch_available false and patch_required_reboot true. active_exploitation_notes records that Apple shipped the fix as an out-of-band Rapid Security Response and that CISA added the CVE to KEV on 2023-07-13. The NIS2-Art21-patch-management gap states that patch-management processes geared to scheduled vendor releases were outpaced by this actively-exploited WebKit zero-day, and that organizations relying on managed update rings could not push the emergency RSR fast enough to close a bug reachable by any browsed page. The NIST-800-53-SI-2 gap separately records devices with automatic RSR/updates disabled as remaining exploitable.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "For the Apple devices in an estate that cannot yet reach iOS/iPadOS 16.6, Safari 16.5.2 or macOS Ventura 13.5, the fixed build has to function as an access condition — mail, VPN and document access denied to a device below it — rather than as a row on a patch-compliance dashboard, because until that device restarts onto the fixed build any page it renders reaches the WebKit defect. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its mail and document access has recorded the exposure rather than removed it. The precondition that matters on this CVE is which half of the control is load-bearing, and it is not the usual one: the packet's delivery path is a target lured to attacker-controlled web content, not a malicious application, so restricting untrusted or side-loaded application installation — the half this control normally leans on for the pre-fix window — does nothing here, and ordinary browsing on a fully compliant device reaches the flaw. The access condition therefore bounds what a compromised device can reach; it does not prevent the code execution, and it is a holding measure for the window before the fixed build and its required restart land. Because active exploitation is confirmed and the content is attacker-controlled, a device that browsed while below the fixed build belongs on the incident path rather than being closed when it later reports the fixed build.",
+        "evidence": "Packet fields for CVE-2023-37450: active_exploitation confirmed with kev_date 2023-07-13, patch_available true, patch_required_reboot true, live_patch_available false, and live_patch_notes naming iOS/iPadOS 16.6, Safari 16.5.2, macOS Ventura 13.5, tvOS 16.6 and watchOS 9.6 or the corresponding Rapid Security Response, which requires a device restart. attack_vector states that a target is lured to attacker-controlled web content and that processing it in WebKit triggers memory corruption leading to arbitrary code execution; active_exploitation_notes adds that exploitation requires luring a target to attacker-controlled web content (UI:R), consistent with targeted mobile-device attacks rather than mass exploitation, and that no detailed public PoC or technical writeup was released (poc_available false). The AU-Essential-8-Patch gap states that fleets of iPhones, iPads and Macs are hard to force-update within the 48-hour window. The ISO-27001-2022-A.8.8 gap states that standard prioritization SLAs would leave a code-execution-on-page-load bug open far too long.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-32046": {
     "name": "Microsoft Windows MSHTML Platform Privilege Escalation Vulnerability",
@@ -57814,7 +59771,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management presumes a known fix to prioritize; for a zero-day EoP shipped and exploited on 2023-07-11, the control has nothing to act on until the update exists, so the exposure predates any compliant vulnerability-handling cycle."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "The packet gives one delivery path for this flaw and nothing else: a user opens a crafted file delivered by email or the web, and the Windows MSHTML platform elevates the attacker to that user's privileges as one link in a wider chain. On an estate that has not yet taken the July 2023 cumulative update and its reboot, controlling how externally sourced files arrive and are handled is the only lever the operator holds, because the defective component is a Windows platform component sitting behind whatever handler opens the file. Apply the untrusted-origin marking at ingress — mail gateway, web download, untrusted file share — rather than relying on the handling application to infer origin, and require the marking to survive the container the file arrives in: extraction from an archive, mounting from an ISO or VHD, and renaming must all preserve it. Two scoping points matter here and both come from the packet rather than from habit. It does not name a file type, only 'a crafted file', so the marking has to cover externally sourced files generally instead of one application's document format. And affected_versions names Windows and Windows Server editions below the July 2023 update, so the population is both — a server where an administrator opens an attachment is in scope exactly as a workstation is. Distinguishing test: send an externally sourced file through each ingress path, nested inside an archive, and confirm it still reaches the endpoint marked untrusted; a policy attestation that the marking is enabled says nothing about whether it survived the archive, and a provenance-stripped file reaches the handler with the user's full privileges. Precondition, and it is why this is a holding measure rather than a fix: the marking bounds how an externally sourced file is treated, it does not repair the MSHTML platform defect, and it is never consulted where a user is permitted to clear the marking, where an ingress path applies none, or where the file arrives by a route the estate does not mediate. The vulnerable component stays in-path on every affected host until the update and its reboot land.",
+        "evidence": "Packet active_exploitation_notes: 'Exploitation is via a crafted file (e.g. delivered by email or web) that the user opens; opening it triggers the MSHTML platform flaw and elevates the attacker to the privileges of the current user, chaining into fuller compromise.' attack_vector repeats the crafted-file open as the trigger. affected: 'Microsoft Windows MSHTML platform — a flaw in the MSHTML component allows an attacker to elevate to the privileges of the current user when a crafted file is opened'; affected_versions: 'Windows and Windows Server editions prior to the July 2023 (2023-07-11) cumulative security update'. patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patch mechanism for the MSHTML platform component; remediation requires installing the July 2023 Windows cumulative security update, which requires a reboot to complete.' The UK-CAF-B4 gap: hardening 'does not neutralize an MSHTML platform elevation reached by opening an attacker-supplied file; standard Windows hardening leaves the vulnerable component in-path until the July 2023 update lands.' The ISO-27001-2022-A.8.8 gap: 'for a zero-day EoP shipped and exploited on 2023-07-11, the control has nothing to act on until the update exists'.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This is the case where the KEV clock and the patch clock open on the same day: the packet records Microsoft flagging CVE-2023-32046 as exploited in the wild when it shipped the fix on 2023-07-11 Patch Tuesday, and CISA adding it to KEV on 2023-07-11. No operator could have acted before the vendor, so the entire value of this control lies after that date — driving the July 2023 Windows cumulative security update across every affected Windows and Windows Server edition on the KEV clock rather than folding it into the next monthly rollup, which is the cadence the Essential Eight and the standard flaw-remediation SLA both permit. Completion is measured per host by the installed build against the fixed build for that SKU and by the restart having been taken: the packet records no live-patch mechanism for the MSHTML platform component and states the update requires a reboot to complete, so a host that installed the update and has not restarted is still executing the vulnerable MSHTML platform and must be counted as exposed. On servers that restart is the step most likely to be deferred into a maintenance window and then recorded as patched, which is the specific failure mode for this entry. Note also that poc_available is false here and it should not lower the priority — exploitation is confirmed, so the absence of a public exploit means only that the operator cannot reproduce what an attacker is already doing. Distinguishing test: for a sample of hosts reporting the July 2023 update as installed, compare uptime against the install time and confirm each has restarted since; a management-console row reading 'installed' against a host that has not rebooted is a compliance record written over a still-exploitable component. Precondition: this control compresses only the post-disclosure half of the exposure. The packet describes a flaw already being exploited on the day the fix shipped, so no remediation SLA — this one included — reaches the period before 2023-07-11; the delivery-path control is what bounds that half.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-07-11, active_exploitation confirmed, poc_available false, rwep_score 47 against cvss 7.8. active_exploitation_notes: 'Microsoft flagged CVE-2023-32046 as exploited in the wild when it shipped the fix on 2023-07-11 Patch Tuesday... No public PoC has been released. Added to KEV 2023-07-11.' patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patch mechanism for the MSHTML platform component; remediation requires installing the July 2023 Windows cumulative security update, which requires a reboot to complete.' The AU-Essential-8-Patch gap: 'Essential Eight patch-OS timelines allow up to a month for such updates, but this was an exploited-in-the-wild zero-day on release day.' The NIST-800-53-SI-2 gap: 'because CVE-2023-32046 was a zero-day already exploited on the 2023-07-11 patch-release date, any SI-2 remediation window at all left an exposure the vendor could not have pre-empted.' The NIS2-Art21-patch-management gap: patch measures 'cannot compress the interval between weaponization and the July 2023 fix'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-32049": {
     "name": "Microsoft Windows Defender SmartScreen Security Feature Bypass Vulnerability",
@@ -58460,7 +60440,30 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management for a mobile estate cannot force the modem-driver fix onto devices lacking SMR Oct-2021; the input-validation flaw remains a local DoS until the OEM update lands on each handset."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "On Samsung handsets the fix for this flaw is not a component update but a whole OEM security-maintenance release: the packet's remediation is Samsung SMR Oct-2021 Release 1 or later installed via the device OTA, which reboots the handset, with no live-patch mechanism for the modem interface driver. Enterprise levers stop at that OTA boundary, so the fixed maintenance level has to function as an access condition — a handset reporting a security-maintenance level below SMR Oct-2021 Release 1 is denied mail, VPN and document access — rather than surfacing as a stale row on a patch-compliance report while the device keeps its access. The distinguishing test is to enrol a Samsung device pinned below SMR Oct-2021 Release 1 and confirm the policy actually refuses it protected resources; an estate that reports the level without enforcing it has recorded the exposure rather than removed it. Precondition: the packet states the exploit needs a local process holding the radio permission, so restricting which applications may be installed and which hold that permission narrows who can reach the modem interface driver — but it does not remove an application already installed and already holding it, and a handset suspected of running one belongs on the incident path, not the install-policy path. Second precondition: this access condition does not repair the driver. patch_required_reboot is true and the packet's own remediation path reboots the handset, so a device that has downloaded the OTA but not restarted onto it is still executing the unvalidated format-string path and must be counted as exposed.",
+        "evidence": "Packet fields for this entry: vector — 'Assuming radio permission is gained, missing input validation in modem interface driver prior to SMR Oct-2021 Release 1 results in format string bug leading to kernel panic'; affected_versions 'Samsung mobile devices prior to SMR Oct-2021 Release 1'; patch_available true with patch_required_reboot true and live_patch_available false; live_patch_notes 'No live-patch mechanism for the modem interface driver; remediation requires installing Samsung SMR Oct-2021 Release 1 or later via the device OTA update, which reboots the handset'; active_exploitation confirmed, CISA KEV 2023-06-29; active_exploitation_notes 'Requires a local process holding the radio permission; exploitation produces a kernel panic (device crash/DoS) rather than code execution'. The ISO-27001-2022-A.8.8 gap records that vulnerability management 'cannot force the modem-driver fix onto devices lacking SMR Oct-2021', and the UK-CAF-B4 gap records that the hardening baseline 'assumes drivers validate their input'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The two dates on this entry make the enforcement case unusually plain: the fixed release is SMR Oct-2021 Release 1 and the KEV listing is 2023-06-29, so across most of a fleet the OEM update had been publishable for a long stretch before the KEV clock opened, and what stayed exposed were handsets on which the OTA was simply never taken. Bound to this CVE the control means the device-management policy drives the security-maintenance level itself on the KEV clock — the available OTA installed and the handset restarted inside the enforced window, user deferral disallowed — with completion measured by the maintenance level each device reports after restart rather than by an 'update pushed' status, because patch_required_reboot is true and the packet's remediation path reboots the handset. Precondition, and it is the whole reason this entry's flaw-remediation gap exists: enforcement can only install what the OEM and carrier have actually published for that model. The packet records the fix as sitting outside the enterprise's direct patch control and the flaw as staying exploitable on any device that never received SMR Oct-2021, so where no OTA carrying that release exists for a handset there is nothing for the policy to install, and the minimum-maintenance-level access condition is the only lever left on that device. An enforced-SLA dashboard that shows such a handset as 'pending' is describing a device the policy will never remediate.",
+        "evidence": "Packet fields for this entry: kev_date 2023-06-29 with active_exploitation 'confirmed'; affected_versions 'Samsung mobile devices prior to SMR Oct-2021 Release 1'; patch_required_reboot true, live_patch_available false, live_patch_notes naming the SMR Oct-2021 Release 1 OTA that reboots the handset. The NIST-800-53-SI-2 gap records 'the multi-month gap between the October 2021 fix and the 2023-06-29 KEV listing shows how long unpatched Samsung devices remained exposed', and the NIS2-Art21-patch-management gap records that the flaw 'stayed exploitable on any device that never received SMR Oct-2021, outside the enterprise's direct patch control'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2021-25394": {
     "name": "Samsung Mobile Devices Race Condition Vulnerability (CVE-2021-25394)",
@@ -58755,7 +60758,30 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management presumes a fix can be scheduled and applied, but for this DSP-driver OOB write on Samsung devices the fix availability depends on OEM SMR rollout, so vulnerability-management SLAs cannot guarantee remediation of the kernel escalation path."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet puts this flaw in Samsung's DSP kernel driver and puts remediation in the Samsung Mobile security maintenance release SMR Mar-2021 Release 1 or later — a build whose delivery the operator does not control, since it reaches a handset only through the OEM/carrier update channel. That is why every cited gap here is a patch-SLA gap: an estate can be fully compliant with its own patch policy and still be holding Samsung handsets running the vulnerable driver. Bound to this product, the control means the Samsung security-patch level functions as an access condition — mail, VPN and document access denied to any enrolled Samsung handset reporting a patch level below SMR Mar-2021 Release 1 — rather than as a row on a compliance report that stays red while the handset keeps its access. Completion is measured on the level the device is actually running: the packet records no live-patch mechanism for the DSP driver and an update that reboots the device, so a handset that has taken the SMR package but has not restarted onto it is still executing the vulnerable driver and counts as exposed. Scope to what the packet names — Samsung mobile devices prior to SMR Mar-2021 Release 1 — and widen to another vendor's handsets only where a verified source identifies a device carrying the same driver; the packet supplies no such mapping. Distinguishing test: enrol a Samsung handset pinned below SMR Mar-2021 Release 1 and confirm the policy actually denies it the protected resources, rather than confirming only that the stale patch level appears on a dashboard. Precondition, and it is the half most often over-claimed: withholding access bounds what a handset stuck below the fix can reach, it does not remove the out-of-bounds write. The packet's attack path is a local, already-privileged process issuing crafted requests to the driver, so the escalation happens entirely on the device — access gating neither prevents it nor evicts code already resident, and a handset suspected of running attacker code belongs on the incident path rather than the patch-level path. The gate also reaches only enrolled devices; an unenrolled or personally-owned Samsung handset touching organizational mail sits outside it entirely. And for a model or carrier variant the update channel never delivers an SMR build to, the packet records no remediation path at all — those handsets are replacement items on a dated schedule, not indefinite exception rows.",
+        "evidence": "The packet records patch_available true, live_patch_available false, patch_required_reboot true, and live_patch_notes stating that remediation requires installing the Samsung Mobile security maintenance release (SMR Mar-2021 Release 1 or later), which reboots the device; affected_versions is 'Samsung mobile devices prior to SMR Mar-2021 Release 1'. The NIS2-Art21-patch-management gap states that MDM update policies could not compel these handsets to update; the AU-Essential-8-Patch gap states the March 2021 fix was not universally deployable within any defined SLA because Samsung mobile firmware patching is gated by OEM/carrier delivery; the ISO-27001-2022-A.8.8 gap states A.8.8 presumes a fix can be scheduled and applied while here fix availability depends on OEM SMR rollout. CISA KEV listed 2023-06-29 with active_exploitation confirmed; RWEP 47, CVSS 6.7, poc_available false. The attack_vector records a local, already-privileged process issuing crafted requests to the DSP driver to corrupt kernel memory and escalate privileges.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "This is the delivery half of the same problem. The moment the OEM/carrier channel makes a build at or above SMR Mar-2021 Release 1 available for a given Samsung model variant, the management channel drives it on the KEV clock that opened 2023-06-29 rather than leaving it to whenever the handset's user acts on an update prompt, and deferral of the restart is disallowed by policy rather than left to the user. The restart is the load-bearing step and the one most often deferred: the packet records no live-patch mechanism for the DSP driver and an update that reboots the device, so a handset that has downloaded the SMR package and not restarted is still running the vulnerable driver, and a fleet report counting it as updated has recorded the exposure rather than removed it. Enforcement must therefore read the patch level the handset reports after restart, not the deployment state in the management console. The system-security gap on this entry is what makes this the whole of the remediation rather than one control among several: the packet states that no user-space hardening constrains a flaw inside the kernel-mode DSP driver and that only the Samsung SMR patch removes the out-of-bounds memory access — there is no configuration change, no permission tightening and no on-device setting that narrows this path, so getting the build installed and restarted is the only thing that closes it. Precondition: the management channel can only drive a build the OEM or carrier has actually released for that model variant. Where none has been released the SLA has nothing to enforce and the exposure stays open — that is the case the patch-level access condition has to cover instead, and treating the SLA as satisfied because no update was offered would mark an exposed handset compliant. It also assumes the handset is enrolled; devices outside enrolment are invisible to it.",
+        "evidence": "The packet records CISA KEV listing 2023-06-29 with active_exploitation confirmed, patch_available true, patch_required_reboot true, and live_patch_available false, with live_patch_notes recording no live-patch mechanism for the Samsung DSP kernel driver and remediation requiring the Samsung Mobile security maintenance release SMR Mar-2021 Release 1 or later, which reboots the device. The UK-CAF-B4 gap states that no user-space hardening constrains a flaw inside the kernel-mode DSP driver and that only the Samsung SMR patch removes the out-of-bounds memory access exploited as an LPE. The NIST-800-53-SI-2 gap states that SI-2 assumes timely vendor patch uptake but the SMR Mar-2021 fix reaches devices only through carrier/OEM update pipelines with long tails, leaving devices that never received it exposed long after the 2023-06-29 KEV listing.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-32434": {
     "name": "Apple Multiple Products Integer Overflow Vulnerability",
@@ -59184,7 +61210,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management often omits infrastructure-monitoring appliances from the primary asset inventory, so CVE-2023-20887 could remain unpatched on a 9.8 preauth-RCE path well after the KEV due date."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives two dates and the clock must run from the earlier: VMSA-2023-0012 shipped 2023-06-07 and CISA listed the CVE on 2023-06-22, with public PoCs and a Metasploit module in between. For VMware Aria Operations for Networks that means the appliance is remediated on patch availability rather than entering a queue at the KEV listing, because for this entry the exploitation was already underway when the listing arrived. Two details decide whether the requirement is actually met. First, scope: the packet's affected range is 6.x prior to the VMSA-2023-0012 patches under both product names, so an inventory keyed only to 'Aria Operations for Networks' misses installs still recorded as vRealize Network Insight, and per the packet's A.8.8 gap infrastructure-monitoring appliances are routinely absent from the primary asset inventory altogether — the appliance has to be an inventoried asset before any SLA can be applied to it. Second, completion: live_patch_available is false and the packet records that remediation requires applying the patch to the appliance, which restarts appliance services, so an appliance where the patch was staged but the services never restarted is still executing the vulnerable code and must be counted exposed. Distinguishing test: produce, per appliance, the build the running appliance reports and show it is at or above the VMSA-2023-0012 level — an estate reporting 'patch approved' or 'downloaded' passes a flaw-remediation attestation while the Thrift path stays live.",
+        "evidence": "cisa_kev true with kev_date 2023-06-22; active_exploitation confirmed; active_exploitation_notes records the KEV listing two weeks after VMSA-2023-0012 (2023-06-07) with public PoCs and a Metasploit module driving rapid opportunistic exploitation of exposed vRNI/Aria appliances; CVSS 9.8, RWEP 77, poc_available true; patch_available true, live_patch_available false, and live_patch_notes states remediation requires applying the VMSA-2023-0012 patch to the appliance, which restarts appliance services; affected_versions names 'VMware Aria Operations for Networks (vRealize Network Insight) 6.x prior to the VMSA-2023-0012 patches'; the ISO-27001-2022-A.8.8 gap records that monitoring appliances are often omitted from the primary asset inventory.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Apache Thrift servlet on Aria Operations for Networks is exactly the binary remoting endpoint this control governs: per the packet it answers without authentication, and the vulnerable code is a support-bundle path that concatenates the request's input into a shell command executed as the vRNI service account. Bound to this appliance, the requirement is that the Thrift listener accepts connections only from hosts with an operational need to speak it — the platform and collector nodes and the management network the appliance is administered from — enforced by network ACL or host firewall rather than inferred from 'the appliance is internal', and that a KEV-listed defect in that servlet is driven on an emergency clock with the appliance-service restart taken, instead of riding the routine cadence a network-monitoring appliance normally gets. The web UI is the surface operators check for exposure; the Thrift port is the one the exploit uses, and they are not the same reachability question. Distinguishing test: from a general user or server VLAN with no vRNI administration role, send Thrift requests at a staging appliance and confirm they are dropped before the servlet answers — an estate that passes vRNI role-and-permission review and keeps the appliance off the internet is still exposed if any internal segment can open that port, which is the assumption the packet's CAF B4 gap identifies as broken. Precondition: restricting reachability bounds who can send the request; it does not repair the concatenation, and every host inside the permitted segment still reaches an unauthenticated command-execution sink. It is a holding measure for the window before the VMSA-2023-0012 patch and its service restart land, not a closure.",
+        "evidence": "attack_vector: 'An unauthenticated Apache Thrift request reaches a support-bundle code path that concatenates user input into a shell command executed as the vRNI service account, giving remote code execution on the appliance'; affected records the Thrift servlet passing attacker-controlled input into an OS command reachable without authentication; the UK-CAF-B4 gap states CAF B4 assumes internal management appliances sit behind a trust boundary yet the servlet was reachable and the injection required no authentication; the NIS2-Art21-patch-management gap states network-monitoring appliances are treated as low-urgency infrastructure while this gave full RCE on a collector with broad network visibility; patch_available true, live_patch_available false, patch restarts appliance services per live_patch_notes.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Aria Operations for Networks is not a perimeter device, but the condition this control keys on is present in full: a pre-auth RCE under confirmed exploitation, with the packet recording public PoCs and a Metasploit module driving opportunistic exploitation of exposed vRNI/Aria appliances. The injection runs shell commands as the vRNI service account on the appliance itself, so the VMSA-2023-0012 patch restores the code path but removes nothing an attacker wrote to that appliance beforehand. The requirement here: for any Aria Operations for Networks / vRealize Network Insight appliance whose Thrift listener was reachable from an untrusted or semi-trusted segment during the window between the 2023-06-07 advisory and the completed patch plus appliance-service restart, the default response is exporting the configuration for review, rebuilding the appliance at the patched build, and rotating every credential configured on it — not patching in place. Where reachability during that window cannot be evidenced, the appliance is treated as exposed rather than as clean, because the absence of a record is not a record of absence. Preconditions and limits: an appliance that was genuinely unreachable from any untrusted segment throughout the window is a patch item, not a rebuild item, so this control depends on the reachability determination being made from evidence rather than assumption. And the rebuild removes appliance-resident persistence only — the packet describes this collector as already holding broad visibility into the network, so whatever an attacker learned or reached from it during the window is not undone by rebuilding it and belongs on the incident path.",
+        "evidence": "active_exploitation confirmed; active_exploitation_notes: 'Public PoCs and a Metasploit module drove rapid opportunistic scanning and exploitation of exposed vRNI/Aria appliances', with KEV listing 2023-06-22, two weeks after VMSA-2023-0012 (2023-06-07); attack_vector places command execution as the vRNI service account on the appliance; the NIS2-Art21-patch-management gap describes full RCE on 'the collector that already has broad visibility into the network'; patch_available true, live_patch_available false, and the patch restarts appliance services per live_patch_notes; the NIST-800-53-SI-2 gap records that mass exploitation was underway by the KEV listing, far inside a typical 30-day patch SLA.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2020-35730": {
     "name": "Roundcube Webmail Cross-Site Scripting (XSS) Vulnerability (CVE-2020-35730)",
@@ -60095,7 +62153,29 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management presumes a known CVE to remediate, but this was an unknown zero-day with no signature; and once known, remediation exceeded patching (appliance replacement), which a standard vuln-management workflow does not prescribe."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The Barracuda Email Security Gateway is the case this control exists for, and the packet states both halves outright: patch_available is true and Barracuda auto-applied the BNSF-36456 patch to all customer appliances, yet because implants persisted the vendor's guidance was full replacement of compromised ESG units rather than patch-in-place, with no mechanism that restores integrity of an already-backdoored appliance. So the operator's decision on an ESG is not 'is the fix applied' — the vendor applied it without them — it is 'was this unit compromised during the exposure window, and if it was, or if that cannot be shown either way, when is it being replaced'. Terminal state for an affected unit is a replaced appliance; a patched unit that carried an implant is not remediated, and recording it as patched marks a backdoored device inside the mail path compliant. Operationally: enumerate every ESG appliance that ran firmware in the 5.1.3.001 through 9.2.0.006 range (appliance form factor only, per the vector), preserve each unit's configuration and logs for forensic review before it is touched, treat credentials the appliance held or that transited it as disclosed and rotate them, and put the unit on a dated replacement schedule — a risk acceptance with no removal date leaves a device with confirmed nation-state implants brokering inbound mail indefinitely. The precondition that is most often over-claimed here: the auto-applied patch closes the .tar member-filename injection sink, but it removes nothing already installed through that sink, and the packet supplies no signature or artifact list, so 'nothing alerted' is not evidence of cleanliness. An appliance whose own telemetry the attacker controlled cannot attest to its own integrity, which is what makes replacement rather than inspection the default.",
+        "evidence": "live_patch_notes verbatim: 'Barracuda auto-applied the BNSF-36456 patch to all appliances, but because implants persisted the vendor's guidance was full replacement of compromised ESG units rather than patch-in-place; there is no live-patch mechanism that restores integrity of an already-backdoored appliance.' active_exploitation_notes: 'Exploited as a zero-day by the Chinese-nexus espionage actor UNC4841 from as early as October 2022 — roughly seven months before disclosure ... Compromise was so deep and persistent that Barracuda advised customers to fully replace affected appliances rather than rely on the patch, since implants survived remediation.' cisa_kev true, kev_date 2023-05-26, active_exploitation 'confirmed', cvss 9.8, rwep_score 74, poc_available true, live_patch_available false. affected_versions: 'Barracuda Email Security Gateway (ESG) appliance firmware 5.1.3.001 through 9.2.0.006'; the vector states 'appliance form factor only'. NIS2-Art21-patch-management gap: 'NIS2 patch-management assumes patching restores integrity ... so a patch-only SLA left compromised gateways trusted.' ISO-27001-2022-A.8.8 gap: 'once known, remediation exceeded patching (appliance replacement), which a standard vuln-management workflow does not prescribe.' AU-Essential-8-Patch gap: 'even flawless patch velocity from 2023-05-26 could not recover appliances already backdoored by UNC4841.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "UNC4841 held ESG appliances from as early as October 2022 until disclosure in May 2023 with command execution at the product's privileges, which means every log the appliance kept about that period was written on a box the attacker controlled. For an ESG the requirement is that its syslog, mail-processing records and administrative-authentication events are forwarded continuously to a collector in a separate trust zone — different management plane, different credentials — so the record of what the appliance did during an exposure window outlives the appliance. This is the control that produces the evidence the replacement decision needs: without off-appliance telemetry, 'was this unit compromised' has no answer other than replacing it. What the rule keys on has to match what the packet actually describes an exploit emitting: inbound email carrying .tar attachments whose member filenames embed shell metacharacters, and command execution through Perl's qx operator at the product's privileges, followed by persistent backdoors. So retain and alert on the gateway's own record of processed archive attachments and on outbound connections from the appliance that do not match its mail-delivery and vendor-update baseline. Do not key on the appliance crashing or on named tooling: the packet describes implants that survived remediation over roughly seven months, so a crash-oriented or signature-oriented rule would have stayed silent through the entire intrusion, and its silence would have been read as health. The precondition, stated plainly because it decides whether this control is worth anything: forwarding must have been configured before the intrusion. Telemetry cannot be retro-collected — an ESG that was never shipping logs off-box has no record of the October-2022-to-May-2023 window no matter what is enabled today, which is exactly the situation that leaves replacement as the only defensible verdict.",
+        "evidence": "attack_vector: 'An unauthenticated remote attacker emails a malformed .tar attachment whose member filenames embed shell metacharacters; the ESG fails to sanitize them (CWE-20) and passes them to Perl's qx() operator, executing arbitrary OS commands (CWE-77) with the product's privileges and installing persistent backdoors.' active_exploitation_notes place UNC4841 on the appliances 'from as early as October 2022 — roughly seven months before disclosure' through the 2023-05-26 KEV listing, with compromise 'so deep and persistent that Barracuda advised customers to fully replace affected appliances'. UK-CAF-B4 gap: 'CAF B4 secure maintenance of a network appliance did not help because the flaw is preauth (PR:N) on an internet-facing email gateway and was exploited for months before a fix existed; secure configuration cannot close a zero-day command-injection sink.' ISO-27001-2022-A.8.8 gap records it as 'an unknown zero-day with no signature'. live_patch_notes records that implants persisted through the vendor-applied patch.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-32409": {
     "name": "Apple Multiple Products WebKit Sandbox Escape Vulnerability",
@@ -61042,7 +63122,38 @@
         "adequate": false,
         "gap": "A.8.9 configuration management is undercut when default JMX/RMI remote monitoring is left on and internet-reachable; without a hardened baseline that disables or firewalls JMX, this deserialization flaw remained an unauthenticated RCE path on affected Java runtimes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "JMX over RMI is precisely the binary remoting listener this control governs: the packet places the defect in the Oracle Java SE and JRockit JMX RMI server component, which deserializes untrusted classes while handling authentication credentials, so the listener parses attacker-supplied content before any credential is validated and neither the perimeter firewall nor web-tier hardening touches it. The requirement for this entry is that the JMX/RMI port on every affected runtime is bound to loopback or reachable only from the management hosts that legitimately poll it, enforced by host firewall or network ACL rather than inferred from the application server being internal. Scope comes from affected_versions and not from the headline product name: Oracle Java SE 6u113, 7u99 and 8u77, Java SE Embedded 8u77 and Oracle JRockit R28.3.9, wherever they are installed, which the packet says includes inside the many Java middleware products that embed JMX. Distinguishing test: from a general application or user segment, open a connection to the JMX/RMI port on a staging instance of each Java product in the estate and confirm it is refused before the endpoint parses anything. A configuration baseline recorded as met while remote JMX answers from any internal segment still exposes the pre-auth deserialization path. Precondition: restricting reachability bounds who can send the serialized object, it does not repair the deserialization, so any host inside the permitted management segment, including a compromised monitoring server or jump host, still reaches the sink, and where remote JMX must stay enabled for production monitoring this control is unavailable and the runtime upgrade is the only closure. The packet records the remediation as Oracle's April 2016 Critical Patch Update applied by upgrading the Java runtime and restarting the affected JVM or application, with no live-patch mechanism; patch_required_reboot is false, but that restart is not optional, and a long-running application server keeps executing the affected runtime until it is taken through it.",
+        "evidence": "Packet affected: 'Oracle Java SE / JRockit JMX (RMI server) component, which deserializes untrusted classes when handling authentication credentials, allowing a remote attacker to affect confidentiality, integrity, and availability.' NIST-800-53-CM-7 gap: 'JMX remote monitoring over RMI is frequently left enabled and network-reachable when it need not be, and CVE-2016-3427 turns that exposed management surface into an unauthenticated deserialization RCE - disabling or localhost-binding JMX would have removed the vector entirely.' ISO-27001-2022-A.8.9 gap: 'A.8.9 configuration management is undercut when default JMX/RMI remote monitoring is left on and internet-reachable.' affected_versions: Oracle Java SE 6u113, 7u99, 8u77; Java SE Embedded 8u77; JRockit R28.3.9. active_exploitation_notes: 'because JMX is embedded in many Java middleware products, the same primitive was reused across numerous downstream products' RCE chains.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation is Oracle's April 2016 Critical Patch Update (and the JEP 290 serialization filtering in later JDK builds), applied by upgrading the Java runtime and restarting the affected JVM/application.' cvss 9.8, rwep_score 70, poc_available true, kev_date 2023-05-12.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The packet's attack path is content-level rather than reachability-level: a remote unauthenticated attacker who can connect to an exposed JMX port sends a malicious serialized object, the packet names ysoserial gadget chains as the delivery form, and the RMI server deserializes untrusted classes while handling authentication credentials. That makes the JMX port a trust boundary rather than an internal monitoring convenience, and the requirement is that the endpoint constrain what arriving content is permitted to construct instead of inheriting safety from the assumption that the management network is trusted. For this runtime the concrete expression is the serialization class filtering the packet names as part of the remediation, applied to the JMX/RMI endpoint so classes outside the expected set are refused before construction, with authentication required on the endpoint itself rather than treated as satisfied by the credential handling that is the vulnerable code here. Distinguishing test: from an unauthenticated host that can route to the JMX port on a staging instance, send a serialized object of a class the management protocol never legitimately conveys and confirm the peer is rejected before the object is constructed. A system-security attestation that records management interfaces as hardened passes cleanly while the endpoint still deserializes whatever it is handed. Precondition, and it is decisive on this entry: that filtering ships with the newer runtime the packet points at. On Java SE 6u113, 7u99, 8u77, Java SE Embedded 8u77 and JRockit R28.3.9 there is nothing to switch on, so until the runtime is upgraded and the JVM or application restarted this control states what to verify after the upgrade rather than offering a mitigation available on the affected build; the reachability restriction is the only operator-side lever in that window.",
+        "evidence": "Packet attack_vector: 'The JMX/RMI server deserializes untrusted classes when handling authentication credentials, so a remote unauthenticated attacker connecting to an exposed JMX port can send a malicious serialized object (e.g. via ysoserial gadget chains) to affect confidentiality, integrity, and availability.' UK-CAF-B4 gap: 'an exposed JMX/RMI endpoint deserializing authentication credentials without class filtering is a preauth code-execution surface that generic system-security baselines rarely close unless JMX exposure is explicitly restricted.' live_patch_notes: 'No vendor live-patch mechanism; remediation is Oracle's April 2016 Critical Patch Update (and the JEP 290 serialization filtering in later JDK builds), applied by upgrading the Java runtime and restarting the affected JVM/application.' affected_versions: Oracle Java SE 6u113, 7u99, 8u77; Java SE Embedded 8u77; JRockit R28.3.9. cwe_refs CWE-284, poc_available true, active_exploitation confirmed.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "Both patch-tracking gaps on this entry describe the same operational failure, and it is an inventory failure rather than an SLA failure: the vulnerable JMX/RMI stack is embedded inside many third-party Java products, operators cannot patch Java independently of each bundling vendor, and per-application patch tracking left hosts running 6u113, 7u99 and 8u77 long past the April 2016 Critical Patch Update, with CISA still listing the flaw as exploited when it added it to KEV on 2023-05-12. So the inventory has to record, for every Java application in the estate, the runtime it actually executes on: the private or bundled JRE shipped inside the product as well as the system-wide installation, plus Java SE Embedded and JRockit R28.3.9 deployments, which are routinely absent from an application-level software list altogether. A product-level inventory cannot answer whether an affected build is present, and that is the specific reason a patch programme scored as compliant kept running affected runtimes for years. Each recorded runtime then carries its own remediation state and its own owner: where the runtime is the operator's, upgrading it and restarting the JVM or application closes it; where the runtime is bundled by a vendor, the operator upgrading the system JRE does not remediate that product, and the entry stays open against the vendor's build. Precondition: this control makes the exposure countable, it does not reduce it. For every runtime the inventory finds that has no vendor build carrying the fix, the reachability restriction on the JMX/RMI port is what bounds the window, and the packet gives a public proof-of-concept and confirmed exploitation, so an entry left open with no dated vendor commitment is an accepted exposure rather than a pending patch.",
+        "evidence": "Packet NIS2-Art21-patch-management gap: 'the vulnerable JMX/RMI stack is embedded inside many third-party Java products; operators cannot patch Java independently of each bundling vendor, so the April 2016 fix reached fielded systems slowly and CISA still listed it as exploited in 2023.' AU-Essential-8-Patch gap: 'because the vulnerable JMX component ships inside diverse Java applications, patch tracking per application meant many hosts ran the affected 6u113/7u99/8u77 builds long past the April 2016 CPU.' active_exploitation_notes: 'because JMX is embedded in many Java middleware products, the same primitive was reused across numerous downstream products' RCE chains'; CISA added it to KEV on 2023-05-12. affected_versions: Oracle Java SE 6u113, 7u99, 8u77; Java SE Embedded 8u77; JRockit R28.3.9. patch_available true, live_patch_available false, poc_available true, active_exploitation confirmed, cvss 9.8, rwep_score 70.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2016-8735": {
     "name": "Apache Tomcat Remote Code Execution Vulnerability",
@@ -61225,7 +63336,29 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management cannot enumerate SOHO routers outside the asset inventory, so the CWE-77 root command injection on the Archer AX21 is an untracked, actively-exploited exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The TP-Link Archer AX21 (AX1800) is the edge gateway for whatever network sits behind it, and the packet's defect is a pre-auth root remote code execution on that gateway: the country parameter of the write operation on /cgi-bin/luci;stok=/locale is passed to popen() without sanitization, so one unauthenticated POST executes commands as root on the device that is the trust boundary. A remediation tier measured in the weeks a general patch SLA allows does not fit that shape, and the packet says why in its own numbers — confirmed mass exploitation by Mirai variants, Condi and AndroxGh0st recruiting the router as root, a public proof of concept, and EPSS around 0.99999. For this device the control means a distinct tier: firmware 1.1.4 Build 20230219 or later deployed on the clock that opened with the 2023-05-01 KEV listing and its 2023-05-22 due date, or the vulnerable interface isolated until it is. Completion is measured per unit on the firmware version the router reports after it comes back up — live_patch_available is false and the packet records that installing 1.1.4 Build 20230219 reboots the device, so a unit that has taken the image but not restarted onto it is still executing the popen() sink and counts as exposed. Scope from what the packet's affected and affected_versions name: Archer AX21 (AX1800) below firmware 1.1.4 Build 20230219; widen only where a verified source identifies another model carrying the same vulnerable handler. Precondition on the isolation alternative, which is where this control is most often over-claimed: the vulnerable parameter sits on the router's web administration surface, so disabling WAN-side administration bounds who can reach it from the internet — but the packet records exploitation over the adjacent network as well as through an exposed web interface, and every client on the network this router exists to serve reaches that surface from the inside. For a unit serving a general user or household network there is no segment that removes the path, only isolation of that network from anything that matters, so isolation is a holding measure for the window before the firmware lands and not a closure. That is also why the enterprise-side expression of this tier is a reachability and firmware-version question asked of remote-work gateways, not a ticket that closes when a central console reports the push.",
+        "evidence": "Packet: CWE-77, vector states the country parameter of the write operation on the /cgi-bin/luci;stok=/locale endpoint 'was not sanitized before being used in a call to popen(), allowing an unauthenticated attacker to inject commands, which would be run as root, with a simple POST request'. affected_versions: TP-Link Archer AX21 (AX1800) firmware < 1.1.4 Build 20230219. cisa_kev true, kev_date 2023-05-01 with due 2023-05-22; active_exploitation confirmed, active_exploitation_notes record 'mass exploitation by multiple botnets (Mirai variants, Condi, AndroxGh0st) that recruit the router as root; EPSS ~0.99999' and that 'Exploitation over the adjacent/management network or an exposed web interface begins within days of PoC availability'. poc_available true, CVSS 8.8, RWEP 76. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patch mechanism for the router firmware; remediation requires installing firmware 1.1.4 Build 20230219 or later, which reboots the device.' The AU-Essential-8-Patch gap records that the internet-facing patch SLA 'cannot be met on unmanaged home routers'; the UK-CAF-B4 gap records that the hardening baseline 'leaves a preauth root-RCE path open'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The outcome the packet records for the Archer AX21 is command execution as root, and confirmed recruitment of the device into botnets — Mirai variants, Condi and AndroxGh0st — at an EPSS of roughly 0.99999. That combination is what makes patch-in-place the wrong default here. Installing firmware 1.1.4 Build 20230219 closes the popen() injection and reboots the unit, but the update is applied on top of a device an attacker held as root: the stored configuration and the administrative credential are carried across the upgrade, and root command execution was sufficient to alter either. For this router the control means a unit whose administration surface was reachable by an untrusted client or from the internet during the exposure window is handled as an incident case rather than a patch ticket — after the firmware update, reset it to factory defaults and rebuild the configuration from a known-good baseline instead of restoring the saved configuration file, set a new administrative credential, and rotate credentials and keys belonging to the network behind it. Preconditions and limits, stated because this control is the half that is easy to overstate: it does not close the injection — the firmware level and the reboot do that, and a rebuilt unit still running a pre-1.1.4 image is fully exploitable again on the next request. It applies to units that were exposed; a unit whose administration surface was never reachable by an untrusted party during the window is an ordinary patch item, and the packet gives no basis for treating every Archer AX21 as compromised. And a factory reset recovers nothing already exfiltrated and closes no session already intercepted, which is why the credential rotation rather than the reset is the load-bearing step. Scope to the model the packet names, Archer AX21 (AX1800) below firmware 1.1.4 Build 20230219, and widen only where a verified source identifies another model carrying the same handler.",
+        "evidence": "Packet: attack_vector 'An unauthenticated attacker sends a POST to /cgi-bin/luci;stok=/locale (country write operation); the country parameter is passed to popen() unsanitized, executing injected commands as root.' active_exploitation confirmed; active_exploitation_notes record 'Confirmed mass exploitation by multiple botnets (Mirai variants, Condi, AndroxGh0st) that recruit the router as root; EPSS ~0.99999 reflects near-certain ongoing exploitation.' poc_available true. patch_available true with live_patch_available false and live_patch_notes 'remediation requires installing firmware 1.1.4 Build 20230219 or later, which reboots the device'. The NIST-800-53-SI-2 gap records that the injection 'stayed exploitable across the fleet during the botnet surge that followed the 2023-05-01 KEV listing' — the population this control addresses. RWEP 76, CVSS 8.8, kev_date 2023-05-01.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-45046": {
     "name": "Apache Log4j2 Deserialization of Untrusted Data Vulnerability",
@@ -61524,7 +63657,36 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would rank this critical, but print-management servers are frequently absent from the asset register and internet-exposed on 9191/9192, so the control never scheduled the urgent patch that mass ransomware exploitation demanded."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The SetupCompleted class is where PaperCut MF/NG makes its access-control decision on this CVE, and the packet is that decision failing open: a remote unauthenticated attacker reaches the setup-wizard page through it and comes out holding an authenticated administrative session. Bound to this product, the control means each administrative function on the PaperCut application server authorizes its own caller rather than inheriting a verdict from a setup-state check that fronts it, and the administrative surface — the packet records these servers internet-exposed on 9191/9192 — answers only from a segment with an operational need to administer printing. The identity-and-access control cited as insufficient on this entry is never consulted: the attacker authenticates as no PaperCut operator, so per-account privilege scoping is bypassed rather than abused, and an attestation that every PaperCut administrator authenticates at login passes cleanly while this path stays open. Distinguishing test: from a segment with no print-administration role, issue unauthenticated requests to each administrative endpoint on a staging PaperCut instance and confirm each is refused before the function runs. Precondition: the endpoint-side authorization is a property the vendor upgrade to 20.1.7, 21.2.11 or 22.0.9 (or later) establishes — this control states what to verify, it does not implement it. Restricting admin-interface network access is the packet's documented interim mitigation and it bounds who can present the request, but it leaves the bypass fully exploitable to anything inside the permitted segment and is unavailable where the console must stay broadly reachable. patch_required_reboot is false, which means no host reboot is needed, not that the fix takes effect on an already-running service: the packet describes a service upgrade, so measure completion by the version the running PaperCut service reports, not by the installer having been run.",
+        "evidence": "Packet fields for this entry: vector — 'The specific flaw exists within the SetupCompleted class. The issue results from improper access control. An attacker can leverage this vulnerability to bypass authentication and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-18987'; attack_vector describing the unauthenticated attacker reaching the SetupCompleted setup-wizard page and obtaining an authenticated admin session; affected_versions '< 20.1.7', '21.x < 21.2.11', '22.x < 22.0.9'; patch_required_reboot false; live_patch_notes 'remediation is upgrading PaperCut MF/NG to 20.1.7, 21.2.11, or 22.0.9 (or later), a service upgrade rather than a host reboot; restricting admin-interface network access is a documented interim mitigation'. The UK-CAF-B2 gap records that the control 'presumes the admin console enforces authentication... so B2's privileged-account controls never engage before code execution'; the ISO-27001-2022-A.8.8 gap records these servers 'internet-exposed on 9191/9192'.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "PaperCut's built-in print/device scripting is the constrained user surface this control governs, and on this CVE it is the second half of the chain: the packet does not stop at the authentication bypass — having obtained an administrative session, the attacker uses the product's own scripting capability to execute arbitrary OS commands as SYSTEM. That is an administrative console feature wired directly to a SYSTEM-level operation, which is the pattern the control forbids. Applied to this product it means the command-executing operations sit behind their own authorization boundary that the console can only reach through a constrained, validated interface, so that obtaining an admin session is not the same as obtaining SYSTEM; and operationally, that the scripting capability is enabled only on servers whose printing workflow genuinely requires it. The application-hardening control cited on this entry cannot reach this: the primitive is a legitimate shipped product feature rather than malware, a macro or a browser plugin, so allow-listing and hardening leave it enabled by design. Precondition, and it is a severe one here: by the time the scripting feature is invoked the attacker already holds an administrative session, so a configuration toggle is within their reach to reverse — disabling the feature raises the cost of the SYSTEM step but does not close it, and it gives nothing at all on a server already compromised, which for this CVE is a live possibility rather than a hypothetical given the packet's record of mass exploitation within weeks by Cl0p and LockBit ransomware affiliates and the Bl00dy gang. The closure is the vendor upgrade plus restricting which networks can reach the console; this control names the architectural property the product was missing and the interim reduction, not a substitute for either.",
+        "evidence": "Packet fields for this entry: attack_vector — the attacker 'obtain[s] an authenticated admin session, then uses PaperCut's built-in print/device scripting to execute arbitrary OS commands as SYSTEM'; vector recording code execution 'in the context of SYSTEM'; active_exploitation_notes 'Mass-exploited within weeks of disclosure; used by Cl0p and LockBit ransomware affiliates and the Bl00dy gang, plus nation-state activity'. The AU-Essential-8-App-Hardening gap records that hardening 'does not contemplate disabling PaperCut's legitimate print/device-scripting feature, which is the exact primitive the exploit abuses to run commands as SYSTEM after the auth bypass — a built-in capability, not malware, so allow-listing/hardening leaves it enabled'.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This is the internet-facing pre-auth-RCE-under-active-exploitation case the control exists for, arriving on a print server rather than a firewall: the packet has PaperCut MF/NG servers exposed on 9191/9192 taking unauthenticated code execution as SYSTEM, mass-exploited within weeks of disclosure by Cl0p and LockBit ransomware affiliates, the Bl00dy gang and nation-state activity, KEV-listed 2023-04-21 with ransomware use recorded as Known. The requirement for this product is that the default incident response for any PaperCut server that was reachable during that window is configuration capture, rebuild and credential rotation — the print-system service account, the administrative credentials the bypass hands over, and any credential the server held or that transited it — rather than upgrading in place to 20.1.7/21.2.11/22.0.9 and closing the remediation ticket. This is precisely the shape of the flaw-remediation gap recorded on this entry: the packet states that organisations patching on a normal monthly cadence were breached before they applied the fix, so for those servers 'patched' and 'not compromised' are two different findings, and because the primitive is code execution as SYSTEM, nothing the upgrade performs removes what was installed beforehand. Precondition: the upgrade here is a service upgrade rather than a host reboot, which makes patch-in-place cheap and fast — that low cost is exactly what makes it the reflexive default that skips the compromise assessment, so the rebuild decision has to be taken deliberately and written into the runbook in advance rather than weighed per incident.",
+        "evidence": "Packet fields for this entry: cisa_kev true with kev_date 2023-04-21; active_exploitation 'confirmed'; active_exploitation_notes 'Mass-exploited within weeks of disclosure; used by Cl0p and LockBit ransomware affiliates and the Bl00dy gang, plus nation-state activity. KEV-listed 2023-04-21 with ransomware use recorded (Known). Preauth RCE as SYSTEM on internet-exposed print servers'; poc_available true; patch_required_reboot false with live_patch_notes describing 'a service upgrade rather than a host reboot'. The NIST-800-53-SI-2 gap records 'PaperCut servers were compromised within days of the 2023-03 fix, so organisations that patched on a normal monthly SI-2 cadence were breached before they applied 20.1.7/21.2.11/22.0.9'; the ISO-27001-2022-A.8.8 gap records these servers internet-exposed on 9191/9192.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-2136": {
     "name": "Google Chrome Skia Integer Overflow Vulnerability",
@@ -62239,7 +64401,30 @@
         "adequate": false,
         "gap": "A.5.15 access control is nullified because the SHA authentication scheme can be satisfied without valid credentials; identity gating on the Agent provides no barrier to the arbitrary-file read with System privileges."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "The packet puts thousands of Veritas Backup Exec Agents on the internet and describes an attacker completing the Agent's SHA authentication without valid credentials and then reading arbitrary files with System privileges through crafted data-management-protocol parameters — so on this product reachability is effectively the whole precondition, because the credential check is not a barrier. Applied to Backup Exec, the control means the Agent's DMP listener answers only from the media servers that legitimately back that host up, enforced by host firewall or network ACL rather than inferred from 'the agent is on the internal network', and never from the internet directly or through a port forward or published NAT rule. The distinguishing test is to attempt an Agent connection from an external address and from a general user VLAN against a staging host and confirm both are refused before the DMP handshake completes; an estate that passes an identity-and-access attestation because 'the Agent authenticates its callers' is still fully exposed, since that assumption is exactly what the cited access-control gaps record as broken. Preconditions, which is where this control gets over-claimed: isolation bounds who can reach the Agent, it does not repair the SHA authentication scheme. Any host inside the permitted segment — a compromised media server, a jump host, a backup admin's workstation — still completes the bypass and reads files as System, and the Agent exists to be reachable by its backup server, so no segmentation removes the path outright. It is a holding measure for the window before Backup Exec 21.2 or later and the Agent service restart land, not a substitute for them. And because the packet records confirmed ransomware exploitation from 2022-10-22 against internet-exposed agents, a host that was reachable during that period is an incident to triage, not an item to close on a firewall rule.",
+        "evidence": "vector: 'due to a vulnerability in the SHA Authentication scheme, an attacker is able to gain unauthorized access and complete the authentication process. Subsequently, the client can execute data management protocol commands on the authenticated connection. By using crafted input parameters in one of these commands, an attacker can access an arbitrary file on the system using System privileges.' active_exploitation_notes: 'Mandiant attributes exploitation of the Veritas Backup Exec flaws (including CVE-2021-27876) to ALPHV/BlackCat affiliate UNC4466, first observed 2022-10-22, using them for initial access before ransomware deployment. CISA lists ransomware use as Known and added it to KEV 2023-04-07 (due 2023-04-28). Thousands of Backup Exec agents were internet-exposed.' poc_available true, cvss 8.1, rwep_score 66. UK-CAF-B2 gap: 'the flawed SHA scheme lets an attacker complete authentication without credentials, defeating the access-control assumption entirely.' ISO-27001-2022-A.5.15 gap: 'A.5.15 access control is nullified because the SHA authentication scheme can be satisfied without valid credentials; identity gating on the Agent provides no barrier to the arbitrary-file read with System privileges.' live_patch_available false; live_patch_notes gives the fix as 'upgrading Veritas Backup Exec to 21.2 or later and restarting the affected Agent service.'",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.5.15"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The timeline on this entry is the argument for the control, and the packet supplies all of it: the fix shipped in Backup Exec 21.2 in 2021, UNC4466 began exploiting it 2022-10-22, and CISA listed it 2023-04-07 with a 2023-04-28 due date — more than a year of live exploitation against a fix that already existed. For Backup Exec the control means the KEV listing, not the backup platform's own upgrade window, drives the move to 21.2 or later across every agent-bearing host. The measurement half decides whether that actually happens: completion is the version the running Agent service reports on each protected host, not the media-server console showing an upgrade pushed. The packet records patch_required_reboot false alongside live_patch_available false and remediation stated as upgrading to 21.2 or later and restarting the affected Agent service — so no machine reboot is owed, but a host whose Agent service was never restarted is still executing pre-21.2 code and must be counted as exposed. On a backup estate that restart is also the step most likely to be deferred, because it lands on production servers during business hours, and a deferral recorded as upgraded is the specific way this remediation goes wrong. The population to enumerate is every server carrying an Agent rather than the backup servers themselves, including hosts whose backup coverage predates the current asset inventory — an Agent nobody tracks is an Agent nobody upgrades, and the packet's thousands of internet-exposed agents are drawn from exactly that set. Priority follows the packet rather than the 8.1 CVSS: CISA records ransomware use as Known, Mandiant ties exploitation to an ALPHV/BlackCat affiliate using it for initial access, and a public PoC exists, which makes this a ransomware entry point rather than a file-disclosure item to schedule.",
+        "evidence": "live_patch_notes: 'No vendor live-patch mechanism; remediation requires upgrading Veritas Backup Exec to 21.2 or later and restarting the affected Agent service.' patch_available true, patch_required_reboot false, live_patch_available false, affected_versions 'Veritas Backup Exec < 21.2'. cisa_kev true, kev_date 2023-04-07, and active_exploitation_notes record the CISA due date 2023-04-28, ransomware use 'Known', and first observed exploitation 2022-10-22 by UNC4466. poc_available true, cvss 8.1, rwep_score 66. NIST-800-53-SI-2 gap: 'SI-2 flaw remediation was available (Backup Exec 21.2, 2021) more than a year before UNC4466 began exploiting it in October 2022, so organizations on a slow SI-2 cadence still exposed the SHA-auth-bypass file-read path when it drove the 2023-04-07 KEV listing.' NIS2-Art21-patch-management gap: 'NIS2 patch-management often deprioritizes backup infrastructure, yet the Backup Exec Agent's auth-bypass grants System-level file access that ALPHV used for initial access; a routine patch window left the ransomware entry point open for months.' AU-Essential-8-Patch gap: 'Essential 8 patch prioritization keyed to obvious internet-facing apps under-weighted the Backup Exec Agent.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-27877": {
     "name": "Veritas Backup Exec Agent Improper Authentication Vulnerability",
@@ -62361,7 +64546,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management should have prioritized the Backup Exec 21.2 upgrade, but the flaw persisted on unpatched agents into 2023; because backup infrastructure is often excluded from aggressive patch windows, the known auth-bypass stayed exploitable well past disclosure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Veritas Backup Exec Agent is exactly the binary remoting-protocol class this control governs. The packet describes a client-to-Agent channel that carries Data Management Protocol commands and is gated by the Agent's own SHA authentication scheme over TLS — and that scheme is itself the vulnerable code, since the attacker completes authentication without valid credentials and then issues a DMP command that executes an arbitrary command with system privileges. Bound to this product, the control means each Agent's listener accepts connections only from the Backup Exec servers that legitimately drive it, enforced by host firewall or network ACL on every protected host, rather than inferred from 'the agent is on the internal network' — the packet places an ALPHV/BlackCat affiliate against internet-exposed agents, so reachability of that listener is the entire access precondition. It also means a KEV-listed defect in that authentication path runs on an accelerated clock instead of the backup product's usual maintenance window. Distinguishing test for this product: from a segment with no backup role — a general user VLAN, and an external address — open a connection to the Backup Exec Agent port on a staging host and confirm it is refused before the SHA handshake is offered; an estate that passes a Backup Exec role-and-permission audit still fails this, because the attacker never presents a Backup Exec credential and no account model is ever consulted. Preconditions: this bounds who can reach the handshake, it does not repair it. The backup servers must keep reaching every agent, so a compromised backup server or any host inside the permitted segment satisfies the exploit's access requirement in full, and the restriction is unavailable where an agent must remain reachable from a wide segment for normal operation. It also gives nothing to an agent that was already reachable during the exposure window — with a public Metasploit module and confirmed ransomware staging, such a host needs forensic triage and rotation of credentials that transited it, not closure on the upgrade record.",
+        "evidence": "Packet fields for CVE-2021-27878 (Veritas Backup Exec Agent Command Execution Vulnerability): cwe_refs CWE-77; cisa_kev true, kev_date 2023-04-07, active_exploitation confirmed; rwep_score 71, cvss 8.8; poc_available true. The vector states that communication between a client and an Agent requires successful authentication typically completed over secure TLS, that a vulnerability in the SHA Authentication scheme lets an attacker gain unauthorized access and complete the authentication process, and that the client can then execute data management protocol commands on the authenticated connection, one of which executes an arbitrary command on the system using system privileges. active_exploitation_notes record CISA KEV as known ransomware-associated and an ALPHV/BlackCat affiliate leveraging the Backup Exec auth-bypass flaws against internet-exposed agents to gain a foothold and stage ransomware, following public release of a Metasploit module in 2023. Cited gaps: NIST-800-53-IA-2 ('the attacker is authenticated by the flawed scheme itself'), UK-CAF-B2 ('B2 access policy cannot help once the authentication mechanism it depends on can be satisfied without credentials'), AU-Essential-8-Backup ('this flaw turns the Backup Exec Agent itself into the entry point for system-privilege command execution').",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "AU-Essential-8-Backup"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock for this entry is the 2023-04-07 KEV listing, not the disclosure. The packet records that the fix shipped in Backup Exec 21.2 in 2021 and that many agents still ran older builds when the flaw was weaponized — a two-year lag that the ordinary vulnerability-management cadence produced and would produce again on the next backup-infrastructure CVE, because backup systems are routinely excluded from aggressive patch windows. Remediation is the upgrade of every Veritas Backup Exec install to 21.2 or later, and the population to enumerate is the Agent installs on protected hosts rather than the console version on the backup server: the agent is pushed onto each protected machine and stays behind on hosts that dropped out of the backup selection, were rebuilt from an older image, or were restored from backup. Completion is measured on the version the Backup Exec Agent service is actually executing. The packet records no host reboot requirement, but it also records that the upgrade restarts the Agent service — so an agent whose installer ran while the service has not restarted onto 21.2 or later is still executing the vulnerable authentication path and must be counted as exposed, not as patched. Priority follows the packet rather than the 8.8 CVSS band: a public PoC with a Metasploit module, confirmed exploitation, and a ransomware-associated KEV flag make this the entry point to a ransomware event, so it belongs on the emergency clock alongside internet-facing services rather than in the backup product's own maintenance cycle.",
+        "evidence": "Packet fields for CVE-2021-27878: patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires upgrading Veritas Backup Exec to 21.2 or later, which restarts the Backup Exec Agent service (no host reboot required)'; affected_versions 'Veritas Backup Exec < 21.2'; cisa_kev true with kev_date 2023-04-07; poc_available true with a Metasploit module publicly released in 2023 per active_exploitation_notes, which also flag the KEV entry as known ransomware-associated. The NIS2-Art21-patch-management gap records that the fix shipped in Backup Exec 21.2 (2021) but many agents ran older builds when ALPHV weaponized it, and that the 2023-04-07 KEV listing marks a two-year lag; the ISO-27001-2022-A.8.8 gap records that backup infrastructure is often excluded from aggressive patch windows, so the known auth-bypass stayed exploitable well past disclosure.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-1388": {
     "name": "Microsoft Windows Certificate Dialog Privilege Escalation Vulnerability",
@@ -62422,7 +64630,21 @@
         "adequate": false,
         "gap": "Technical vulnerability management must prioritize local-privilege-escalation CVEs used by ransomware; scoring this 7.8 LPE below internet-facing RCEs leaves the SYSTEM-escalation path open across the endpoint fleet."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows UAC certificate/consent dialog, which fails to enforce user privileges when a standard user views a publisher certificate, and the path it documents is entirely user-interface: trigger a consent dialog, open the publisher-certificate details, follow the certificate hyperlink to launch a browser as NT AUTHORITY\\\\SYSTEM, and spawn a SYSTEM shell from that browser, escalating without any exploit code. For this CVE the control means the November 2019 (or later) Windows cumulative security update is driven across the whole affected population the packet names — Windows 7, 8.1, 10 and Windows Server 2008, 2012, 2016 and 2019 — on the clock that opened with the 2023-04-07 KEV listing rather than folded into an ordinary monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. The packet records no Microsoft hotpatch for this class and a remediation that requires that cumulative update and a reboot, so a host that has taken the update but has not restarted still presents the vulnerable dialog and must be counted as exposed. The second half of the control is the load-bearing one here: the escalation runs from an ordinary standard-user session through a dialog the operating system itself presents, so tightening account privilege does not contain it — which is exactly why the least-privilege gap cited on this entry can pass its attestation while the flaw stays fully exploitable, and why an endpoint baseline that treats UAC as the boundary is measuring something the packet says does not hold. Priority follows the packet rather than the CVSS band: a public PoC, confirmed exploitation, and a KEV ransomware:Known flag with documented post-compromise use to reach SYSTEM before payload deployment make this a containment step inside a ransomware chain, not a routine 7.8 endpoint item. Because the flaw requires local interactive access and is not remotely exploitable on its own, the population to enumerate first is hosts where non-administrative users log on interactively, since there the precondition the escalation needs is the normal operating state rather than an anomaly.",
+        "evidence": "Packet fields for this entry: CWE-269; CVSS 7.8; RWEP 68; poc_available true; active_exploitation confirmed; cisa_kev true with kev_date 2023-04-07. active_exploitation_notes: 'Added to CISA KEV on 2023-04-07 and flagged ransomware:Known. Used post-compromise by ransomware operators to escalate from a low-privileged foothold to SYSTEM before deploying payloads. Requires local interactive access; not remotely exploitable on its own.' patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: 'No Microsoft hotpatch for this class at the time; remediation requires the November 2019 (or later) Windows cumulative security update and a reboot.' affected_versions: 'Windows 7 / 8.1 / 10 and Windows Server 2008/2012/2016/2019 without the November 2019 cumulative update'. attack_vector describes the standard user following the certificate hyperlink to launch a browser as NT AUTHORITY\\\\SYSTEM and spawning a SYSTEM-level shell 'without any exploit code'. The NIST-800-53-AC-6 gap records that least-privilege enforcement 'assumes the UAC boundary holds'; the UK-CAF-B4 gap records that Microsoft treats UAC as not a security boundary; the ISO-27001-2022-A.8.8 gap records that scoring this 7.8 LPE below internet-facing RCEs leaves the SYSTEM-escalation path open across the endpoint fleet.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-26083": {
     "name": "Arm Mali GPU Kernel Driver Information Disclosure Vulnerability",
@@ -62569,7 +64791,29 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management had a fix available (Patch 24), but the ongoing TA473 campaign shows the real exposure was the gap between the released patch and its application on internet-facing webmail."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This Zimbra entry is a case where CVSS-keyed and KEV-keyed prioritization give opposite answers. The base score is 6.1 — a reflected XSS, the shape of finding that lands in a quarterly web-application queue — while the packet records Winter Vivern / TA473 using it across 2022 and 2023 against European government and military Zimbra webmail to steal credentials and mailbox contents, with CISA listing it on 2023-04-03. Bound to this product, the control means the clock on an internet-facing Zimbra Collaboration Suite instance starts at the KEV listing or patch availability, whichever is later, and stops when the mailbox service is actually running 9.0.0 Patch 24 or later — not when a change ticket is raised or a package is staged. The packet is precise about what running means here and it is easy to get wrong in both directions: patch_required_reboot is false, so no host reboot is being coordinated, but the recorded remediation is a mailbox-service restart, so an instance where the package was applied and the mailbox service never restarted is still reflecting the parameter unsanitized and is not remediated. Scope to what the packet names — Zimbra Collaboration Suite 9.0 prior to 9.0.0 Patch 24 — rather than to webmail generally. The two patch-window gaps on this entry say the same thing from different sides: the fix existed and the exposure was the interval before it was applied on internet-facing webmail. The application-hardening gap matters here as an exclusion — it rules out the control a framework would otherwise reach for, since browser and webmail hardening does not stop script the server itself reflects from the trusted origin, which is why the response clock rather than endpoint hardening is the control that carries this entry. Precondition: nothing available to the operator short of Patch 24 removes the unsanitized reflection, so this SLA governs how fast the estate gets there and offers nothing during the window before it does. And because exploitation is confirmed and the payload runs inside the victim's own authenticated session, an instance that was internet-reachable while unpatched is not closed by the upgrade — the packet records credential and mailbox theft as the outcome, so session invalidation, credential rotation for users who could have followed such a link, and a review of what those mailboxes held belong inside remediation rather than being deferred to a separate incident question.",
+        "evidence": "The packet records CVSS 6.1 against RWEP 61, CISA KEV 2023-04-03, active_exploitation confirmed and poc_available true; active_exploitation_notes record Winter Vivern / TA473 using the reflected XSS through 2022-2023 against unpatched Zimbra webmail at European government and military organizations, sending targeted emails whose links ran JavaScript to steal webmail credentials and messages. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes recording remediation as updating to Zimbra Collaboration Suite 9.0.0 Patch 24 or later — a mailbox-service restart, not a host reboot; affected_versions is Zimbra Collaboration Suite 9.0 prior to 9.0.0 Patch 24. The AU-Essential-8-App-Hardening gap states application hardening does not stop server-reflected XSS delivered from the trusted webmail origin and that only the Zimbra patch removes the unsanitized reflection; the ISO-27001-2022-A.8.8 gap states the real exposure was the gap between the released patch and its application on internet-facing webmail; the NIS2-Art21-patch-management gap states the XSS was exploited against European government Zimbra instances that stayed unpatched after 9.0.0 Patch 24 shipped.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "This control's name comes from Exchange but its subject is webmail per-request telemetry, and the Zimbra campaign in this packet is the same shape it was written against. The packet describes a logged-in user following a link to their own Zimbra /public/launchNewWindow.jsp, the server reflecting the script into the trusted origin, and attacker JavaScript then reading and exfiltrating mail inside that user's existing session. None of that generates an authentication event — the user logged in normally, and everything afterwards is that user's own session issuing ordinary webmail requests — so an estate whose Zimbra logging is authentication-only holds no record of the intrusion at all. The requirement is that the Zimbra webmail tier forward per-request access logs, not just authentication events, to a collector off the mail server, with retention spanning a campaign the packet records as running across 2022 and 2023. What to key on is what the packet actually describes: requests to /public/launchNewWindow.jsp carrying script in their parameters, paired with the mailbox reads and message retrieval that follow in the same session from the same source. Both halves are needed. A script-shaped parameter on that endpoint alone may be a scanner probing it, and mailbox reads alone are what webmail does all day; it is the pairing inside one session that matches the path the packet documents. Note what will not see this: the request arrives over a valid session and no login anomaly, no malware artifact and no server-side process change accompanies it, so authentication-event alerting and host anti-malware have nothing to match, and a rule written against failed logins or unusual sign-in geography would miss an attempt behaving exactly as the packet describes. Precondition: this is detection, not prevention — it does not stop the script executing and does not recover mail already exfiltrated. It also depends on the telemetry having been collected and shipped off the mail server before the campaign arrived; a rule authored afterwards against logs nobody retained produces nothing. It bounds the window to alert-and-response time during the interval before 9.0.0 Patch 24 and its mailbox-service restart land, and complements reaching that build rather than substituting for it.",
+        "evidence": "The packet's attack_vector records an attacker sending a logged-in webmail user a link to their own Zimbra /public/launchNewWindow.jsp with a script payload in the parameters, the server reflecting it unsanitized into the trusted origin, and the attacker's JavaScript stealing credentials and mailbox contents; the affected field places the unsanitized reflection at /public/launchNewWindow.jsp and describes the result as unauthenticated reflected XSS in the webmail origin. active_exploitation_notes record TA473 running this against European government and military organizations through 2022-2023 to steal webmail credentials and messages, with poc_available true and CISA KEV listing 2023-04-03. The ISO-27001-2022-A.8.8 gap states the real exposure was the gap between the released patch and its application on internet-facing webmail. live_patch_notes record remediation as Zimbra Collaboration Suite 9.0.0 Patch 24 or later with a mailbox-service restart.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2013-3163": {
     "name": "Microsoft Internet Explorer Memory Corruption Vulnerability",
@@ -63226,7 +65470,28 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management often leaves aging ColdFusion deployments off the actively-tracked inventory, so this known-exploited deserialization RCE could sit unpatched on a public server past the KEV due date."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For Adobe ColdFusion the two clocks a normal remediation process keeps apart collapsed onto one day: the packet records CISA adding this to KEV on 2023-03-15, the same day Adobe shipped the fix, and notes that this indicates exploitation was already underway. A response measured in hours from that day is the only patch-side clock that had any window at all, and it is precisely what the cited routine cadences do not carry. Bound to this product, completion means the fixed update is the code actually running: ColdFusion 2018 Update 16 for instances at or below 2018 Update 15, and ColdFusion 2021 Update 6 for instances at or below 2021 Update 5, with the ColdFusion service restarted afterwards. Read patch_required_reboot carefully here — it is false, which means no host reboot is needed, not that the fix is live on install. The packet's own remediation note requires restarting the ColdFusion service, and live_patch_available is false, so there is no path that avoids that restart; an instance that installed the update and left the service running is still executing the pre-fix code and must be counted exposed until the restart. Measure per ColdFusion installation rather than per site: a host serving several applications through one ColdFusion instance is one remediation, and an application inventory that tracks web properties rather than ColdFusion installations will miss instances on both the 2018 and 2021 tracks, which update independently. Scope from what the packet's affected and affected_versions name — ColdFusion 2018 at or below Update 15 and ColdFusion 2021 at or below Update 5 — and widen only where a verified source identifies another product carrying the same code path. Residual to state plainly rather than let the SLA imply otherwise: this compresses the post-patch window only. The packet records exploitation preceding the fix, so even a same-day clock from 2023-03-15 covers nothing before it, and an internet-facing instance that was reachable before that date is a compromise-assessment case rather than a clean patch record.",
+        "evidence": "Packet: CWE-284, vector 'Adobe ColdFusion versions 2018 Update 15 (and earlier) and 2021 Update 5 (and earlier) are affected by an Improper Access Control vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue does not require user interaction.' affected_versions: 'Adobe ColdFusion 2018 <= Update 15 (fixed in Update 16)', 'Adobe ColdFusion 2021 <= Update 5 (fixed in Update 6)'. cisa_kev true, kev_date 2023-03-15; active_exploitation_notes state the entry was 'Added to CISA KEV 2023-03-15, the same day as the Adobe fix, indicating exploitation was already underway.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation requires applying Adobe ColdFusion 2018 Update 16 or 2021 Update 6 and restarting the ColdFusion service.' CVSS 8.6, RWEP 72, poc_available true. The NIST-800-53-SI-2 gap records that a routine cadence 'was too slow' and that 'any multi-week patch SLA left an internet-facing ColdFusion server open to unauthenticated RCE'; the NIS2-Art21-patch-management gap records that routine patch management 'does not force emergency patching of legacy web-application servers... warranting out-of-band action the routine process omits'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records that CISA documented a federal agency's public-facing ColdFusion servers compromised through this flaw, and it names both halves of the primitive: unauthenticated arbitrary code execution and arbitrary file read in the ColdFusion service context. Both halves determine what remediation has to mean. The execution half is what leaves a persistent artifact written through a path the application legitimately exposes; the read half hands over datasource credentials, configuration and any key material the ColdFusion service account can read, and nothing about applying an update reverses a read. Applying ColdFusion 2018 Update 16 or 2021 Update 6 and restarting the service closes the improper-access-control path to the deserialization sink, and removes nothing already written through it. So for an internet-facing ColdFusion instance that was reachable during the pre-patch window — which on this entry's own timeline is a broad population, since the KEV listing and the vendor fix landed together on 2023-03-15 with exploitation already underway — the default response is a compromise assessment and rebuild rather than patch-in-place: inventory the files under the web root and the ColdFusion installation against what a deployment accounts for, rebuild from a known-good image where one exists, and rotate every credential the service account could read, including datasource passwords. Preconditions and limits. This does not close the flaw; the update plus the service restart does, and the packet records no live-patch path, so an instance assessed but left on 2018 Update 15 or 2021 Update 5 is exploitable again immediately. It applies to instances that were internet-facing or otherwise reachable by an untrusted caller during the window, not to every ColdFusion installation in the estate. And the assessment has to be a file-inventory-against-deployment exercise rather than a scan: an artifact written through a legitimate application path is bespoke, so signature-based anti-malware and authentication logging have nothing to match, and an authentication log is silent by construction for a flaw whose whole point is that no authentication took place.",
+        "evidence": "Packet: affected records 'an improper-access-control flaw permits deserialization of untrusted data, allowing unauthenticated arbitrary code execution and arbitrary file read in the ColdFusion service context'; attack_vector repeats the unauthenticated deserialization path 'yielding arbitrary code execution and file read in the service context'. active_exploitation confirmed; active_exploitation_notes state 'CISA later documented (in a June 2023 advisory) that a federal agency's public-facing ColdFusion servers were compromised via this flaw' and that the KEV listing on 2023-03-15 landed the same day as the Adobe fix, indicating exploitation was already underway. poc_available true, CVSS 8.6, RWEP 72. patch_available true, live_patch_available false, live_patch_notes 'remediation requires applying Adobe ColdFusion 2018 Update 16 or 2021 Update 6 and restarting the ColdFusion service'. The AU-Essential-8-Patch gap records that the 48-hour window 'was already breached on release: exploitation preceded the fix, so patch-timeliness alone could not protect exposed ColdFusion servers by the 2023-03-15 KEV date.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-23397": {
     "name": "Microsoft Office Outlook Privilege Escalation Vulnerability",
@@ -63287,7 +65552,30 @@
         "adequate": false,
         "gap": "A.8.22 network segregation would have isolated user endpoints so a coerced SMB connection could not exit to an attacker server, but flat networks allow the outbound authentication; without segregation and SMB egress control, A.8.8 patching alone left the forced-auth leak reachable on unpatched clients."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the mitigation the clock runs against is not one artifact. The KEV listing and the Microsoft March 2023 Outlook security update arrived together, so the patch arm is available from hour zero — but the packet's remediation note pairs that update with three named mitigations (block outbound TCP 445, add users to the Protected Users group, enforce SMB signing), and this control is what makes those the deployable alternative for any client that cannot take the update inside the clock. Scope is the Outlook for Windows estate the packet's affected_versions name — Microsoft 365 Apps and Office 2013, 2016, 2019 and LTSC 2021 below the March 2023 build — not Microsoft 365 Apps alone, since an estate standardised on a perpetual Office release is affected at its own pre-update build. Completion must be measured on Outlook itself: patch_required_reboot false means no machine reboot, and the packet states the Office update requires restarting Outlook, so a workstation that installed it while Outlook stayed open is still running the vulnerable reminder-processing path and is not remediated. Preconditions on the compensating half, which is where this gets recorded as done while the path stays open: blocking outbound TCP 445 stops the coerced authentication reaching an SMB server on the internet, but the UNC path in the reminder can name any destination the client can route to, so an attacker with an interior foothold still collects the hash — that internal case is the segregation problem, not something the egress rule covers. Protected Users membership removes NTLM only for the accounts placed in it, so the general user population keeps leaking Net-NTLMv2 until the update lands or SMB signing is enforced on the services that would accept the relay. And none of the three, nor the update, recovers a hash captured before they were in place.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-03-14, active_exploitation confirmed, CVSS 9.8, RWEP 65, poc_available true. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes stating 'No live-patch mechanism; remediation requires the Microsoft March 2023 Outlook security update, plus recommended mitigations (block outbound TCP 445, add users to Protected Users group, enforce SMB signing). Applying the Office update requires restarting Outlook but not the host.' affected_versions: 'Microsoft Outlook for Windows (Microsoft 365 Apps, Office 2013/2016/2019/LTSC 2021) before the March 2023 security update'. attack_vector: a crafted reminder with a UNC path in PidLidReminderFileParameter forces the client to send the user's Net-NTLMv2 hash to an attacker SMB server with no interaction. The NIST-800-53-SC-7 gap records that blocking outbound SMB (TCP 445) is Microsoft's primary mitigation but that default enterprise egress rules rarely deny 445; the UK-CAF-B2 gap records that B2 cannot distinguish the relayed session from the legitimate user without disabling NTLM or enforcing MFA/signing.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet's attribution is the trigger this control names by actor: confirmed in-the-wild zero-day exploitation from as early as April 2022 by APT28 (Fancy Bear / Forest Blizzard) against government, military, energy and transportation targets in Europe — roughly eleven months of collection before the KEV listing on 2023-03-14. Bound to Outlook, that changes what remediation means: the flaw's output is the user's Net-NTLMv2 hash delivered to an attacker-controlled SMB server with no interaction and then relayed to impersonate the victim, so what survives the March 2023 update is authentication material already taken, not a code path still open. The runbook must therefore treat a mailbox that received a message whose reminder carried a UNC path in PidLidReminderFileParameter during the exposure window as an intrusion lead rather than a patch-compliance exception: rotate credentials for the affected accounts, and hunt for authentication that arrived by relay rather than from the user's own workstation. Escalating under the nation-state path rather than a commodity-malware path is the packet's own justification — a state-aligned espionage group operating against those sectors uses a relayed session to move, so the commodity path's expectation of a malware artifact to find produces a clean result on a compromised estate. Preconditions: this is the response half and it prevents nothing — further leaks stop only when the update and the packet's named mitigations land. It also depends on mail retention covering the exposure window and on authentication telemetry that was already being collected when the relay happened; where neither survives, the honest output is that the exposure cannot be bounded, which is the finding rather than an all-clear.",
+        "evidence": "Packet: active_exploitation confirmed, with active_exploitation_notes stating exploitation in the wild as a zero-day from as early as April 2022 by the Russia-aligned APT28 (Fancy Bear / Forest Blizzard) against government, military, energy and transportation targets in Europe, CISA KEV addition 2023-03-14, and PoCs released immediately (poc_available true). attack_vector: the hash is relayed to impersonate the victim. The AU-Essential-8-Patch gap states that even the March 2023 patch does not retroactively protect credentials leaked before it; the NIS2-Art21-network-security gap states that a patch-only response around the KEV 2023-03-14 date misses the credentials already captured by APT28.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-24880": {
     "name": "Microsoft Windows SmartScreen Security Feature Bypass Vulnerability (CVE-2023-24880)",