@blamejs/exceptd-skills 0.19.18 → 0.19.19

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",
@@ -29123,7 +29252,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 +34541,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 +35077,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 +36091,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 +37479,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 +38696,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 +38937,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",
@@ -39707,7 +40065,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",
@@ -40217,7 +40608,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)",
@@ -40301,7 +40715,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 +41359,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",
@@ -42231,7 +42702,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",
@@ -42417,7 +42919,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 +42989,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 +43117,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 +43261,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 +43866,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",
@@ -43487,7 +44144,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",
@@ -45500,7 +46189,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 +46247,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 +46382,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 +46503,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 +46792,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",
@@ -46873,7 +47695,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)",
@@ -48254,7 +49108,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",
@@ -49630,7 +50509,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)",
@@ -51932,7 +52843,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",
@@ -53957,7 +54901,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 +55287,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 +55594,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 +56052,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",
@@ -55818,7 +56881,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",
@@ -58460,7 +59555,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)",
@@ -59184,7 +60302,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 +61245,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 +62214,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",
@@ -61524,7 +62727,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 +63471,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 +63616,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",