@blamejs/exceptd-skills 0.19.11 → 0.19.13

package/data/zeroday-lessons.json

@@ -13617,7 +13617,28 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The interval in this entry is itself the finding: a 2017 CVE reached the KEV on 2026-03-05 with exploitation confirmed and a public PoC, which means Hikvision devices have been carrying an improper-authentication flaw that hands an unauthenticated caller administrator on the device and access to its video feed for as long as the estate has been unable to say what firmware those devices run. Applied here, the KEV clock governs a population that surveillance estates normally refresh on a physical-security cycle rather than a patch cycle: enumerate the Hikvision devices in service, take each to the vendor's fixed firmware, and measure completion by the firmware level the device reports over its own interface. The packet's title records the flaw against multiple Hikvision products while its attack-vector text names IP cameras, so the enumeration covers the Hikvision devices actually deployed and the vendor's affected-product list decides which of them must take the firmware — neither assume the exposure stops at cameras nor extend it to equipment the vendor does not list. The packet records no live-patch path and a fix that typically requires a service restart or system reboot, so a device that has had the firmware image pushed but has not restarted is still running the vulnerable code and is not yet remediated.",
+        "evidence": "Packet: 'Multiple Hikvision products contain an improper authentication vulnerability that could allow a malicious user to escalate privileges on the system and gain access to sensitive information'; attack_vector places an unauthenticated attacker at administrator on Hikvision IP cameras with access to the device and its video feed (CWE-287); CISA KEV-listed 2026-03-05; active_exploitation confirmed; poc_available true; CVSS 9.1; RWEP 77; patch_available true; live_patch_available false with the note that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A nine-year-old unauthenticated-administrator flaw surviving to a 2026 KEV listing is what a vulnerability-management program looks like when its scanning coverage stops at servers and workstations. Bound to this entry, the test is whether the estate's scan actually reaches each Hikvision device and reads the firmware it is running, and whether the verdict is derived from a build known to contain the fix rather than from an asset record, a VMS inventory page, or the installer's handover document — all of which describe what was deployed at commissioning, not what is executing now. A camera subnet excluded from scanning, or scanned only for open ports without ever interrogating the device, returns a clean result that is indistinguishable from a compliant one, and that clean result is what an operator would otherwise present as evidence of managing technical vulnerabilities. Distinguishing test: produce, per Hikvision device, the firmware version the device itself reports and the date that scan ran, and confirm the version carries the vendor fix; any device for which the program can produce a compliance verdict but not a device-reported firmware string has been counted as compliant without being examined.",
+        "evidence": "Packet: CVE published against Hikvision products in 2017 and CISA KEV-listed 2026-03-05 with active_exploitation confirmed and poc_available true; improper authentication (CWE-287) allowing an unauthenticated attacker to escalate to administrator; patch_available true; citing gaps include ISO/IEC 27001:2022 A.8.8 management of technical vulnerabilities.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2021-22681": {
     "name": "Rockwell Multiple Products Insufficient Protected Credentials Vulnerability",
@@ -14261,7 +14282,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Cisco Catalyst SD-WAN Controller (formerly SD-WAN vSmart) and Catalyst SD-WAN Manager (formerly SD-WAN vManage) are the management plane the packet names, and the defect sits on the interface where they authenticate fabric peers: the packet states the peering authentication mechanism in an affected system is not working properly, so crafted requests let an unauthenticated remote attacker log in as an internal, high-privileged, non-root user account, access NETCONF from it, and manipulate network configuration for the SD-WAN fabric. Bound to these two products the control means the peering interface takes its own authorization decision on every request before a session exists — a peer's asserted identity is verified rather than accepted — and that no Controller or Manager instance is left with its peering and NETCONF interfaces reachable from a segment holding no fabric role. This is also why the cited least-privilege and identity-and-access gaps cannot close the path: the account the attacker lands in is internal to the product rather than one the operator provisioned, so per-account privilege scoping is never consulted and an attestation covering administrator accounts passes cleanly while an unauthenticated caller holds administrative privileges on the system. Distinguishing test: from a segment carrying no SD-WAN fabric role, send unauthenticated peering requests to a staging Controller and Manager and confirm each is refused before any session is issued, then attempt a NETCONF session from that same origin and confirm it is refused too — an estate that audits vManage operator roles and passes remains fully exposed to the path the packet describes, because the path never touches those roles. Precondition: repairing the peering authentication mechanism is what the vendor update does; this control states the property to verify and does not implement it. Until that update and the restart the packet's live-patch note requires have landed, restricting which segments can present requests bounds who can attempt the bypass but leaves it fully available to anything inside the permitted segment — and because a fabric's peers are distributed by design, the peering interface must stay reachable to those peers for the overlay to work, so the restriction is partial by construction rather than a closure.",
+        "evidence": "Packet vector: Catalyst SD-WAN Controller, formerly SD-WAN vSmart, and Catalyst SD-WAN Manager, formerly SD-WAN vManage, \"contain an authentication bypass vulnerability could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system. This vulnerability exists because the peering authentication mechanism in an affected system is not working properly... A successful exploit could allow the attacker to log in to an affected Cisco Catalyst SD-WAN Controller as an internal, high-privileged, non-root user account. Using this account, the attacker could access NETCONF, which would then allow the attacker to manipulate network configuration for the SD-WAN fabric.\" CWE-287. CISA KEV-listed 2026-02-25, active_exploitation confirmed, poc_available true, CVSS 9.1, RWEP 77. patch_available true; live_patch_available false with the note that no live-patch tool is registered and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock this control sets opens on this entry at the 2026-02-25 KEV listing, and what counts as verified mitigation has to be stated in these products' own terms. The packet records a vendor fix with no live-patch path and a note that the patch typically requires a service restart or system reboot, so completion is measured by each Catalyst SD-WAN Controller and Manager having taken the fixed image and come back from that restart — an instance carrying the image but not yet restarted still runs the vulnerable peering authentication code and counts as exposed, and on a fabric controller the restart is the step most likely to be deferred because taking it disturbs the overlay it serves. Where the restart cannot be scheduled inside the window, the documented-compensating-control branch is the only one this SLA leaves, and it has to be written down as a compensating control with its residual stated rather than recorded as compliant: restricting which segments can present requests to the peering and NETCONF interfaces bounds who can attempt the bypass, but it does not repair the mechanism, and every legitimate fabric peer's network remains a permitted origin. Priority follows the packet rather than the CVSS band — confirmed in-the-wild exploitation and a public PoC against a system whose compromise yields NETCONF-level authority over the fabric's configuration makes this a control-plane containment item, not a scheduled network-device update. Precondition: because exploitation is confirmed, the update does not close an instance that was reachable during the window. The packet's end state is an attacker manipulating SD-WAN fabric configuration, so a Controller or Manager exposed before the fix landed needs its fabric configuration and the accounts defined on it compared against a known-good copy; an update applied to a system that already issued an administrative session removes the entry path and nothing the attacker did through it.",
+        "evidence": "Packet: CISA KEV-listed 2026-02-25 with active_exploitation confirmed and poc_available true; CVSS 9.1, RWEP 77; CWE-287. patch_available true, live_patch_available false, with live_patch_notes stating \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" Vector: an unauthenticated remote attacker can \"bypass authentication and obtain administrative privileges on an affected system,\" log in \"as an internal, high-privileged, non-root user account,\" and \"access NETCONF, which would then allow the attacker to manipulate network configuration for the SD-WAN fabric.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-25108": {
     "name": "Soliton Systems K.K FileZen OS Command Injection Vulnerability",
@@ -14321,7 +14366,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": "FileZen's KEV listing opened 2026-02-24 and the packet already carries a public PoC alongside confirmed in-the-wild exploitation, so an appliance-patch cadence measured in weeks is the wrong instrument for this entry: the CWE-78 command sink is reached through an ordinary HTTP request to the product's own web surface, so exposure is continuous for as long as a unit runs pre-fix code. Applied to this product, the control means the Soliton vendor fix is driven across every FileZen unit on the KEV clock, with completion measured per unit by the software level actually running on it — not by an update being approved, downloaded, or staged in a change queue. The precondition is the part that decides whether this remediation is real: the packet records patch_available true, live_patch_available false, and a fix that per the KEV requiredAction typically requires a service restart or system reboot, so a unit that has taken the update but not restarted is still running the vulnerable code and must be counted as exposed. On a file-transfer appliance that restart is exactly the step operators defer, because taking it interrupts in-flight transfers, and a deferral recorded as 'patched' is the specific way this goes wrong. Where the restart genuinely cannot be taken inside the window, the only remaining lever is restricting which networks can reach the FileZen web surface; that bounds who can send the crafted request and leaves the command sink fully reachable from anything inside the permitted segment, so it is a holding measure with a dated end, not a closure. Distinguishing test: produce, per appliance, the running software level and the timestamp of the restart that activated it — a patch-compliance report listing the update as deployed without evidencing the restart cannot tell a remediated unit from an exposed one.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-02-24, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77, patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'; vector describes the OS command injection (CWE-78) being reached by a specially crafted HTTP request to the product. AU-Essential-8-Patch and ISO-27001-2022-A.8.8 are recorded as insufficient for this entry.",
+        "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 does not place FileZen at a network perimeter, so what triggers this control here is not topology but the exploitation facts the packet does record: the defect executes operating-system commands on the appliance itself (CWE-78), exploitation is confirmed in the wild, and a PoC is public. For any unit that untrusted callers could reach before its fix and restart landed — and the KEV listing dates confirmed exploitation to at least 2026-02-24 — the vendor update restores the code and nothing else: an added account, a scheduled job, an altered configuration, or any file written through the command sink survives the upgrade untouched, because the fix closes the path and does not undo what already traversed it. The default disposition for such a unit is therefore configuration capture, rebuild, and credential rotation rather than patch-in-place. Two preconditions are load-bearing. The rebuild only yields a clean appliance if it is built at or above the vendor's fixed level — rebuilding to the pre-fix level puts the identical vulnerable HTTP path straight back on the network — and the credentials the appliance held (its administrative accounts, any directory-integration or service accounts, any keys shared with transfer partners) must be rotated after the rebuild completes rather than before, or the clean unit is handed the same secrets. This control also does not establish what left the appliance: files that transited FileZen during the exposure window need their own disclosure assessment, which no amount of rebuilding performs. Distinguishing test: for each unit, ask what evidence excludes exploitation during the window rather than what evidence proves it — a flaw-remediation record showing the fixed version installed reads clean on an appliance that was executing attacker-supplied commands the week before.",
+        "evidence": "Packet: cwe_refs CWE-78, described as OS command injection giving command execution on the managed-file-transfer appliance; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2026-02-24; rwep_score 77; patch_available true with live_patch_available false and a fix that 'typically requires service restart or system reboot per the KEV requiredAction'. NIST-800-53-SI-2 (Flaw Remediation) is recorded as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The packet's vector conditions this exploit on a product login: FileZen 'contains an OS command injection vulnerability when an user logs-in to the affected product and sends a specially crafted HTTP request'. That is the shape this control forbids — a constrained user surface, here the web interface of a file-transfer product, wired through to an operating-system command interpreter on the appliance host, so that holding a FileZen account amounts to holding command execution on the box. Bound to this product, the requirement is that no FileZen request handler composes an OS command from request-supplied content, and that the transfer functions reach the operating system only through a constrained, validated interface. This is why the least-privilege gap cited on this entry stays open however carefully FileZen accounts are scoped: the request crosses out of the application into the OS regardless of which directories or transfer rights the account carries, so an access-control attestation passes cleanly while the path is fully reachable. Preconditions: handler-side neutralization is a property the vendor update establishes — this control names what to verify, it does not implement it. Until the update and its restart land, the operator's levers are reducing which accounts can log in to the appliance and restricting which networks can reach its web surface; each bounds the population that can send the request and neither closes the sink. And the packet's own attack-vector summary describes the attacker as unauthenticated, contradicting the login precondition in its vector text — under that reading the account-side lever gives nothing at all and reachability restriction is the only interim measure, so reducing accounts must not be recorded as the mitigation without first settling which reading holds. Distinguishing test: on a staging FileZen, authenticate as an ordinary transfer user and send shell metacharacters through each web handler's parameters, confirming none reach a command interpreter — an attestation that every FileZen account is confined to its own transfer directories passes while this path stays open.",
+        "evidence": "Packet vector: 'Soliton Systems K.K FileZen contains an OS command injection vulnerability when an user logs-in to the affected product and sends a specially crafted HTTP request'; the packet's attack_vector summary instead describes 'an unauthenticated attacker' with 'command execution on the managed-file-transfer appliance'. cwe_refs CWE-78; cvss 9.8; active_exploitation confirmed; poc_available true. NIST-800-53-AC-6 (Least Privilege), UK-CAF-B4 (System security) and NIS2-Art21-network-security (Security of network and information systems) are recorded as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-49113": {
     "name": "RoundCube Webmail Deserialization of Untrusted Data Vulnerability",
@@ -15047,7 +15124,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The packet's path into BeyondTrust Remote Support and Privileged Remote Access needs no credential and no user interaction — an unauthenticated remote attacker reaches the product and executes operating system commands in the context of the site user — so these systems are not servers sitting behind an access boundary, they are the boundary the exploit crosses, which is what puts them in this control's distinct SLA tier rather than in the general server population. For these two products the control means the remediation clock runs from the 2026-02-13 KEV listing rather than from the next scheduled maintenance window, and that completion is measured per system by the version actually running against the vendor's fixed version, not by 'update approved', 'update downloaded' or a closed change ticket. The packet registers no live-patch path and records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a system that has taken the update but not restarted still runs the vulnerable code and has to be counted as exposed for the whole interval until it restarts. The control's alternative branch — isolating the vulnerable interface instead of meeting the clock — carries a precondition that frequently does not hold for this product: Remote Support and Privileged Remote Access exist in order to be reachable, so isolation is only available where the operator can name a user and technician population whose access can be suspended for the duration, and where it cannot, the update plus its restart is the only lever and there is no compensating control to record in its place. Priority follows the packet rather than the CVSS band alone: confirmed in-the-wild exploitation plus a public PoC against a no-authentication path means the window is being actively worked. Distinguishing test: produce, per affected system, the running version and the timestamp of the restart that activated it, set against the vendor's fixed version — a patch-management attestation that reports an SLA-compliance percentage over a 14- or 30-day window passes cleanly while a system sits updated-but-unrestarted on a KEV-listed no-authentication remote command-execution flaw.",
+        "evidence": "Packet: BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA); CWE-78 OS command injection. Vector: 'Successful exploitation could allow an unauthenticated remote attacker to execute operating system commands in the context of the site user. Successful exploitation requires no authentication or user interaction.' cisa_kev true, kev_date 2026-02-13, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 83. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps closed here: AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation), NIS2-Art21-vulnerability-handling.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records confirmed in-the-wild exploitation and a public PoC against a path that requires no authentication and no user interaction, which changes what the response has to cover: any Remote Support or Privileged Remote Access system that was reachable before it was updated is possibly already executed against, not merely possibly vulnerable. Bound to this product, the control means the answer to the 2026-02-13 KEV listing is not the vendor update alone — for each system reachable during the exposure window, export the configuration off the box, rebuild from vendor media rather than patching in place, and rotate the credentials and key material the system held. The packet's own outcome statement is the reason: command execution in the context of the site user, with the vendor stating exploitation may lead to system compromise including unauthorized access, data exfiltration and service disruption. An attacker who reached that before the update keeps everything they wrote after it. This is also precisely why the anti-malware control cited against this entry does not close the path: an anti-malware attestation covers the hosts the agent is installed on and the content it has signatures for, whereas an operating-system command-execution foothold on this product typically leaves an added account, an altered configuration entry, or a script the platform itself executes on schedule — content with nothing to match. Distinguishing test: take a system that was reachable before remediation and diff its accounts, automated tasks and on-disk content against a freshly built system at the same fixed version; a clean anti-malware scan and a version number at or above the fixed release are both fully consistent with a system that is still implanted. Preconditions: the vendor update is what closes the injection path and this control does not substitute for it; the control applies only to systems that were actually reachable during the window, not to every unit in the inventory; and where a rebuild genuinely cannot be scheduled, the honest record is an accepted exposure with a dated review, because the system continues to be trusted with no evidence it is clean — not a remediation entry.",
+        "evidence": "Packet: BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA); CWE-78 OS command injection; unauthenticated remote attacker executes operating system commands 'in the context of the site user'; vector states exploitation 'may lead to system compromise, including unauthorized access, data exfiltration, and service disruption'. active_exploitation confirmed; cisa_kev true, kev_date 2026-02-13; poc_available true; RWEP 83; CVSS 9.8. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps closed here: CIS-Controls-v8-10.1 (Deploy and Maintain Anti-Malware Software), NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "CIS-Controls-v8-10.1",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "Remote Support and Privileged Remote Access are, by what the packet names them, the products through which support sessions into other systems are established, so command execution on them is not bounded by the systems themselves. Applied to this CVE, the control means the response includes an accounting of what passed through each affected system during the exposure window — the accounts that authenticated to or through it, the credential and session material it held for the systems it serves, and the trust those serviced systems extend to it — with each of those rotated or re-established rather than left standing because the system now reports a fixed version. Two preconditions must be stated rather than assumed. First, the scope list cannot be drawn solely from the affected system's own records: the packet gives an attacker executing operating system commands in the context of the site user, and records written on a system in that state are attacker-influenceable, so an off-system record of sessions is the authoritative source where one exists, and where it does not, the defensible scope is every account that used the service during the window. Second, this control assumes the deployment actually brokers access to other systems — the packet establishes the products and the exploitation outcome, not any particular site's session inventory, so the rotation list is a deployment fact the operator has to produce and it may be narrower or wider than the product name suggests. Rotation is also not containment on its own: it invalidates what the attacker took, it does not remove what the attacker left, which is the rebuild half of the response, and it gives nothing back to a system that was never reachable during the window. Distinguishing test: name the accounts whose sessions traversed each affected system between the earliest plausible compromise and completion of its rebuild, and show a rotation timestamp after that completion for each — an identity-and-access attestation showing that every technician holds a unique account with MFA passes cleanly here, because the packet's path never authenticates as any of them and no per-account privilege decision is ever consulted.",
+        "evidence": "Packet: BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA); CWE-78; vector states successful exploitation 'requires no authentication or user interaction' and that the attacker executes operating system commands 'in the context of the site user', which 'may lead to system compromise, including unauthorized access, data exfiltration, and service disruption'. cisa_kev true, kev_date 2026-02-13; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 83; patch_available true; live_patch_available false (vendor patch typically requires service restart or system reboot per the KEV requiredAction). Citing gaps closed here: UK-CAF-B2 (Identity and access control), NIST-800-53-AC-6 (Least Privilege).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2026-20700": {
     "name": "Apple Multiple Buffer Overflow Vulnerability",
@@ -16360,7 +16471,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "EPMM is the device-management gateway this control governs, and the packet places the defect squarely on its management surface: a code injection that 'could allow attackers to achieve unauthenticated remote code execution' (CWE-94). Bound to this product, the control means every request handler on the EPMM management surface makes its own authorization decision before any request content is interpreted, and never turns request-supplied content into executable code — the endpoint's own decision, not the surrounding operator account model, is what stands between an untrusted caller and code execution on the appliance. This is why the least-privilege gap cited here cannot be closed by tightening EPMM roles: the attacker holds no EPMM account, so per-account privilege scoping is never consulted and the account model an access-control attestation examines is bypassed rather than abused. Preconditions: endpoint-side authorization and input neutralization are properties the vendor update establishes — this control states what to verify, not how to build it. Until that update and the restart the packet says it typically requires have both landed, restricting which segments can reach the EPMM management surface bounds who can send the request but leaves the injection sink fully exploitable to any caller inside the permitted segment, and that lever is unavailable wherever the surface must stay reachable for normal operation. Distinguishing test: on a staging EPMM, send unauthenticated requests to each management endpoint carrying content shaped to be interpreted rather than stored, and confirm each is refused before interpretation — an estate that evidences unique, role-scoped accounts for every EPMM administrator passes its access-control review while this path stays wide open.",
+        "evidence": "Packet vector: 'Ivanti Endpoint Manager Mobile (EPMM) contains a code injection vulnerability that could allow attackers to achieve unauthenticated remote code execution'; attack_vector: 'code injection (CWE-94) yielding unauthenticated remote code execution on the EPMM management surface'. cwe_refs CWE-94; cvss 9.8; rwep_score 77; patch_available true, live_patch_available false, with the fix typically requiring 'service restart or system reboot per the KEV requiredAction'. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are recorded as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "Unauthenticated RCE on EPMM is not an appliance incident: EPMM is the control plane the managed fleet derives its configuration and trust state from, so code execution on that box is authority over everything downstream of it — and the packet records that exploitation as confirmed in the wild with a public PoC. The playbook this CVE demands, rehearsed before the next disclosure rather than drafted during one, covers the half no patch-shaped control reaches: certificate revocation issued from a control plane whose integrity has been re-established, device-trust-state invalidation, an audit of every configuration profile pushed since the earliest point at which exploitation cannot be excluded, quarantine criteria for downstream devices, and rotation of every credential the EPMM instance held or that authenticated through it during that window. The vendor update stops further exploitation of the code path; it removes nothing an attacker already pushed to the fleet or read out of the appliance, which is precisely the residue a flaw-remediation control records as closed. Precondition: the fleet-side steps sequence after the EPMM instance itself has been rebuilt or otherwise established as trustworthy — running them from the instance that was exploited re-signs the fleet from a box of unknown integrity, so the appliance work gates the fleet work and the fleet stays in its pre-incident trust state until that completes. Distinguishing test: for one managed device chosen at random, name the certificate that would be revoked, the profile history that would be audited, and the credential set that would be rotated, and time how long producing that answer takes — an incident-response policy that cannot produce it for a single device will not produce it for the fleet under an active compromise.",
+        "evidence": "Packet: unauthenticated remote code execution on the EPMM management surface (CWE-94); cisa_kev true, kev_date 2026-01-29; active_exploitation confirmed; poc_available true; rwep_score 77; cvss 9.8; patch_available true, live_patch_available false. NIST-800-53-SI-2 (Flaw Remediation) is recorded as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV clock for EPMM opened 2026-01-29, and the packet pairs that with confirmed in-the-wild exploitation, a public PoC and unauthenticated remote code execution at CVSS 9.8 — the profile a routine infrastructure-patch cadence is least able to absorb, on a management appliance whose compromise is the fleet's compromise rather than one host's. Applied here, the control means the Ivanti fix is driven across every EPMM instance on that clock, with completion measured per instance by the version actually running and the restart having been taken, not by an approval sitting in a change queue. Precondition: the packet records no live-patch path and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so an instance that has taken the update but not restarted is still running the vulnerable code and must be counted as exposed — on a management appliance that restart is deferred because taking it interrupts device management, which is exactly how an instance ends up recorded as patched while it is not. Where the restart cannot be taken inside the window, restricting reachability of the EPMM management surface is the only remaining lever; it bounds who can send the request and does not remove the injection path, so it carries a dated end rather than closing the item. Distinguishing test: for each EPMM instance produce the running version and the restart timestamp that activated it — a vulnerability-management report showing the update deployed without the restart cannot distinguish a remediated instance from an exposed one.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-01-29, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77, patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIS2-Art21-patch-management are recorded as insufficient for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2026-24858": {
     "name": "Fortinet Multiple Products Authentication Bypass Using an Alternate Path or Channel Vulnerability",
@@ -17363,7 +17506,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet names five separately shipped products — Cisco Unified Communications Manager, Unified CM Session Management Edition, Unified CM IM & Presence Service, Unity Connection, and Webex Calling Dedicated Instance — each carrying its own version and its own upgrade, so a remediation record showing Unified CM at the fixed version says nothing about the IM & Presence Service or Unity Connection instances standing beside it. For this CVE the control's clock therefore has to be tracked per named product and per instance, running from the 2026-01-21 KEV listing. The mitigation the clock demands here is the vendor update and nothing else: the packet records patch_available true, live_patch_available false, and a note that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so there is no in-place mitigation to deploy while the update waits, and an instance that has taken the update but not restarted still runs the vulnerable code and must be counted as exposed rather than as met. Keep the sweep to the five products the packet names: it ties the CWE-94 sink to those and provides no mapping into other Cisco software, so treating every Cisco system in the estate as an instance of this CVE manufactures findings and upgrade work against products no evidence implicates. Priority follows the packet rather than the CVSS band on its own — confirmed in-the-wild exploitation, a public PoC, and an outcome the packet describes as user-level access to the underlying operating system followed by elevation to root, which means the end state is control of the platform, not degradation of a service. Distinguishing test: produce, per named product and per instance, the running version and the restart timestamp against the vendor's fixed version — a vulnerability-management attestation that records the estate as compliant because the change tickets closed inside the window passes cleanly while an unrestarted instance keeps serving.",
+        "evidence": "Packet: 'Cisco Unified Communications Manager (Unified CM), Cisco Unified Communications Manager Session Management Edition (Unified CM SME), Cisco Unified Communications Manager IM & Presence Service (Unified CM IM&P), Cisco Unity Connection, and Cisco Webex Calling Dedicated Instance contain a code injection vulnerability that could allow the attacker to obtain user-level access to the underlying operating system and then elevate privileges to root.' CWE-94. cisa_kev true, kev_date 2026-01-21, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps closed here: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The packet's escalation has two stages, and the second is the one this control governs: code injection gives the attacker user-level access to the underlying operating system of the Unified Communications product, and from that user-level context privileges are elevated to root. A constrained context reaching root operations on the platform beneath it is exactly the pattern the control forbids. Bound to these five products, it means the platform's privileged operations sit behind their own authorization boundary that the application tier can only reach through a constrained, validated interface, so that a defect in the application's input handling does not leave an attacker one step from root on the call-control and messaging platform. This is why the least-privilege gap cited on this entry cannot close the path: the escalation happens inside the product, between an operating-system user context the attacker obtained through injection and root — there is no operator-assignable account whose privileges could be narrowed to prevent it, so an attestation covering administrator accounts on these products passes while the path stays open. Preconditions, stated rather than implied: the boundary is a property the vendor update establishes, so this control names what to verify and does not implement it, and the packet records no live-patch path, meaning each instance carries the service restart or system reboot the fix requires before it is remediated. Until that lands, the operator-side lever is restricting which segments can reach the affected products' interfaces — that bounds who can attempt the injection but leaves the path fully exploitable to anything inside a permitted segment, and it is simply unavailable where the interface must stay reachable for the products to carry calls, voicemail and presence. And because active_exploitation is confirmed with a public PoC, any instance reachable during the exposure window needs forensic triage and credential rotation: an update applied to a system that already granted root does not remove what the attacker left behind.",
+        "evidence": "Packet: CWE-94 code injection in Cisco Unified CM, Unified CM SME, Unified CM IM&P, Cisco Unity Connection and Cisco Webex Calling Dedicated Instance; vector states the flaw 'could allow the attacker to obtain user-level access to the underlying operating system and then elevate privileges to root'. active_exploitation confirmed; cisa_kev true, kev_date 2026-01-21; poc_available true; CVSS 9.8; RWEP 77. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps closed here: NIST-800-53-AC-6 (Least Privilege), UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-20805": {
     "name": "Microsoft Windows Information Disclosure Vulnerability",
@@ -18952,7 +19119,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet calls the Android Framework flaw unspecified and places the trigger in a local app escalating privileges on the device, which leaves the operator no component to disable and no setting to change — the platform update carrying the fix is the entire remediation, so the only questions are how fast it lands and whether the user can decline it. For this CVE that means the managed-device policy pushes the update inside the clock that opened with the 2025-12-02 KEV listing, with user deferral disallowed and the restart enforced, because the packet records no live-patch tool and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction: a handset that installed the update and never rebooted is still running the vulnerable framework and must be counted as exposed. Precondition, and it is the one that breaks this control on Android specifically: the operator can force installation only of a build the device's OEM or carrier has actually released for that model, so the SLA has two failure states that need separating — handsets that could have taken the update and were allowed to defer, which policy enforcement fixes, and models for which no fixed build has shipped, which policy cannot fix and which fall to the access-condition control below or to a replacement schedule. Distinguishing test: from the management console, list handsets by model and reported security patch level and show, per model, whether a fixed build exists and how many days elapsed between its availability and the device's restart onto it — an attestation that reports policy assignment is measuring the console, not the fleet.",
+        "evidence": "Packet vector: 'Android Framework contains an unspecified vulnerability that allows for privilege escalation.' attack_vector: 'a privilege-escalation flaw (CWE-269) in the Android Framework, exploited by a local app to escalate privileges on the device (the local-escalation step after an initial-access primitive).' Fields: cisa_kev true, kev_date 2025-12-02, active_exploitation confirmed, CVSS 7.8, RWEP 77, poc_available true, ai_discovered false, patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Because the packet records the vulnerability itself as unspecified and the trigger as a local app escalating privilege on the handset, the operator's only remaining levers on a device that cannot yet take the fixed build are what that device is allowed to reach and what code it is allowed to run. The fixed Android security patch level therefore has to function as an access condition — mail, VPN and document access denied to any enrolled handset below it — rather than as a column on a compliance dashboard, because a device below the fix that keeps its access is exactly the device this escalation is aimed at: the packet places this CVE as the local-escalation half of a mobile-spyware chain, so the payoff is the organizational data and credentials on the handset. Precondition: restricting installs to a managed catalogue and blocking side-loading raises the bar for getting the attacker's app onto the device, but it does not evict an app already installed and it does not cover one that arrived through the normal store channel — a handset suspected of already running the escalating app belongs on the incident path with credential rotation, not on the install-policy path. Distinguishing test: enrol a device pinned below the fixed patch level and confirm the conditional-access policy actually denies it the protected resources, instead of flagging it non-compliant while its mail keeps syncing. This is a holding measure for the window before the fixed build and its required reboot land, not a substitute for them.",
+        "evidence": "The packet's own description of the flaw is 'an unspecified vulnerability that allows for privilege escalation', with the exploitation path 'exploited by a local app to escalate privileges on the device' and the framing that 'this class forms the local-escalation half of a mobile-spyware chain'. patch_available true with live_patch_available false and live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so the interval this control covers is real and reboot-gated. active_exploitation confirmed; cisa_kev true, kev_date 2025-12-02; poc_available true; RWEP 77; CVSS 7.8; CWE-269.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-26829": {
     "name": "OpenPLC ScadaBR Cross-site Scripting Vulnerability",
@@ -21461,7 +21651,22 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Common Log File System Driver and describes a local, privileged attacker bypassing certain security mechanisms (CWE-269) — the attacker already holds a legitimate account on the host, so no account model is being abused and no credential is being guessed; a privilege boundary inside an operating-system driver is failing. For this CVE the control means the Windows update carrying the CLFS fix is driven across every affected host on the KEV clock that opened 2025-10-06 rather than folded into the next routine rollup, with completion measured per host by the installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot per the KEV required action, so a host that has taken the update but not restarted is still running the vulnerable driver and must be counted as exposed, not as patched-pending-reboot. That distinction is load-bearing here because there is no interim lever to hold the exposure down while the restart is deferred: the flaw is in a driver Windows ships as part of the operating system and loads on the running system, so unlike a vulnerable third-party driver there is nothing to blocklist and no module an operator can disable, and unlike a network-reachable flaw there is no segment to restrict — the restart is what puts the fixed code in service. The second half of the control is the half the citing gaps miss: because the attacker is already a local, privileged user, tightening account privilege or access control does not contain the escalation, which is why patch and vulnerability-management attestations are the ones that actually have to move on this entry. Priority follows the packet rather than the CVSS 7.8 band — a public PoC, confirmed in-the-wild exploitation, and the packet's own note that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators make this the containment step in a chain rather than a standalone endpoint hygiene item, and a host that was reachable to an untrusted local account during the exposure window warrants triage rather than being closed on the patch alone.",
+        "evidence": "The packet's vector states that Microsoft Windows Common Log File System Driver contains a privilege escalation vulnerability that could allow a local, privileged attacker to bypass certain security mechanisms, classified CWE-269. CISA KEV-listed 2025-10-06 with active_exploitation confirmed and poc_available true; CVSS 7.8, RWEP 77. patch_available true; live_patch_available false, with the packet noting no live-patch tool registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The packet's attack_vector adds that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators. The framework controls this entry already cites as insufficient are ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8, EU NIS2 Article 21 vulnerability handling and disclosure, NIST SP 800-53 SI-2 Flaw Remediation, and UK NCSC CAF B4 System security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2013-3918": {
     "name": "Microsoft Windows Out-of-Bounds Write Vulnerability",
@@ -22695,7 +22900,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "DELMIA Apriso is a manufacturing-operations platform whose downtime is scheduled against production runs, which is exactly why the clock this control imposes has to be the KEV clock and not the next planned maintenance window. The packet places an unauthenticated remote caller at code execution through a deserialization sink, with exploitation already confirmed and a public PoC at the 2025-09-11 listing, so the population to drive is every Apriso instance in service — including integration, staging and disaster-recovery copies, which run the same request path and are commonly reachable from the same segments as production — taken to the vendor's fixed release and measured by the build each instance actually reports rather than by a change ticket marked approved. The packet records no live-patch path and states the vendor fix typically requires a service restart or system reboot, so an instance where the fix has been staged but the service has not been restarted still carries the vulnerable code and must be counted as exposed; on an MES tied to a running line that restart is the step most likely to be deferred, and a deferral recorded as 'patched' is the specific way this remediation fails. Distinguishing test: list every Apriso instance with its reported build and the time of its last service restart — an instance reporting the fixed build whose service has been up continuously since before the update was applied has not taken the fix.",
+        "evidence": "Packet: Dassault Systemes DELMIA Apriso, deserialization of untrusted data (CWE-502) leading to remote code execution, unauthenticated; CISA KEV-listed 2025-09-11; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77; patch_available true; live_patch_available false with the note that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The defect the packet describes is a request reaching Apriso's deserializer before any authentication decision has been made: a remote attacker who holds no account at all reconstructs an attacker-supplied object and executes code. Bound to this product, the control means the Apriso request path decides whether its caller is authorized before the request body is deserialized at all — a serialized object arriving from an unauthenticated caller is refused rather than reconstructed — and the platform's HTTP surface answers only from segments with an operational need to reach it (plant-floor clients, integration middleware, the operator workstations that use it), not from a flat corporate network or a routable path from outside. This is why the least-privilege gap recorded against this entry does not touch the path: the attacker never holds an Apriso account, so per-account privilege scoping is never consulted and an attestation showing correctly scoped Apriso roles passes cleanly while the pre-auth path stays fully open. Distinguishing test: from a segment with no operational need to reach the MES, send a crafted serialized payload to a staging Apriso instance without credentials and confirm it is refused before deserialization runs. Precondition: the 'authorize before deserialize' property is established by the vendor's fixed release — this control states what to verify, it does not implement it. Until that release and its restart land, restricting which segments can reach the Apriso HTTP surface bounds who can send the request but leaves the sink fully reachable to anything inside the permitted segment, including a compromised workstation or integration host, and the lever is unavailable wherever that interface must stay reachable for normal production operation.",
+        "evidence": "Packet: DELMIA Apriso deserialization-of-untrusted-data flaw (CWE-502) enabling unauthenticated remote code execution; citing gaps include NIST SP 800-53 AC-6 (Least Privilege) and NIS2 Art. 21 security of network and information systems; CISA KEV 2025-09-11; active_exploitation confirmed; poc_available true; patch_available true; live_patch_available false, vendor patch typically requires service restart or system reboot.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-48543": {
     "name": "Android Runtime Use-After-Free Vulnerability",
@@ -22810,7 +23039,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The packet puts the secret inside the product rather than in the operator's configuration: Sitecore Experience Manager, Experience Platform, Experience Commerce and Managed Cloud carry a deserialization-of-untrusted-data flaw involving the use of default machine keys, and the exploitation path is a known/static ASP.NET machine key abused through ViewState to reach unauthenticated remote code execution. Because the ViewState key is a value the attacker already holds rather than one they must obtain from the target, no amount of operator-side password or account hygiene reduces the exposure — which is exactly why the least-privilege gap is recorded against this entry: the attacker never authenticates as any Sitecore user, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the path stays open. Bound to these products, the control means enumerating every XM, XP, XC and Managed Cloud instance in the estate as depending on a product-supplied machineKey, then for each one reading the key actually in effect at runtime and confirming it is unique to that instance rather than a product-default or template-inherited value. Re-run that check after any deployment clone, image restore, environment refresh or scale-out of a content-delivery role, since those are the operations that quietly reintroduce one shared key across a set of instances that had already been rotated — the unit of remediation is the key, so a farm whose nodes share one configuration is one key, not many. Precondition: the packet records a vendor patch with no live-patch path, and its live-patch note states the fix typically requires a service restart or system reboot per the KEV requiredAction, so an instance that has taken the update but not restarted is not yet remediated. Replacing the key also removes only future forgery — with exploitation confirmed in the wild and a public PoC, an instance that served a default key while reachable needs its deployed assemblies, content tree and administrator accounts compared against a known-good state and any credential material handled during the exposure window rotated. This control governs whether the key is unique; it does not evict a foothold established before it was changed.",
+        "evidence": "Packet vector: Sitecore XM, XP, XC and Managed Cloud \"contain a deserialization of untrusted data vulnerability involving the use of default machine keys. This flaw allows attackers to exploit exposed ASP.NET machine keys to achieve remote code execution.\" Attack vector records CWE-502 \"abusing a known/static ASP.NET machine key via ViewState, enabling unauthenticated remote code execution.\" CISA KEV-listed 2025-09-04, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. patch_available true; live_patch_available false with the note that no live-patch tool is registered and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A version-based verdict is the specific way remediation goes wrong on this CVE. The packet's exploitation path is a known/static ASP.NET machine key abused through ViewState, so a Sitecore instance can sit at the vendor's fixed release and stay fully exploitable if the default machine key the packet names was never replaced — a scanner reads the product version, and the product version is not where this vulnerability lives. The operational test that separates paper compliance from remediation, per instance of XM, XP, XC and Managed Cloud: produce the machineKey in effect at runtime and show that it is not a product-default or template-inherited value, that it differs between instances built from the same deployment template, and that it was generated after that instance's exposure window rather than carried across the update unchanged. A vulnerability-management report listing the instance as patched on version evidence alone has recorded the update and not the fix, and the same report will keep reading clean on every instance the deployment pipeline recreates from the pre-rotation template. Precondition: this is a verification control — it tells the operator whether the exposure is actually gone, it does not remove it, and neither the version check nor the key check speaks to whether the instance was already exploited. With the packet recording confirmed in-the-wild exploitation and a public PoC, an instance that fails this test on first run has to be treated as having been reachable with a known key, which is an incident-triage question rather than a scan-and-close one.",
+        "evidence": "Packet vector: the flaw \"involv[es] the use of default machine keys\" and \"allows attackers to exploit exposed ASP.NET machine keys to achieve remote code execution\" across Sitecore XM, XP, XC and Managed Cloud. Attack vector: CWE-502 deserialization \"abusing a known/static ASP.NET machine key via ViewState, enabling unauthenticated remote code execution.\" CISA KEV-listed 2025-09-04 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 77. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-50224": {
     "name": "TP-Link TL-WR841N Authentication Bypass by Spoofing Vulnerability",
@@ -23015,7 +23268,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries two facts that have to be resolved per unit before anything else: a vendor patch is recorded as available, and the entry's own vector states the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization. So the first requirement is an inventory that names every TL-WA855RE in service with its hardware revision and an end-of-support date obtained from the vendor, not an assumption in either direction. Units whose revision still has supported firmware are patch items and belong on the remediation clock; units whose revision has none cannot be patched at all and are replacement items with a dated schedule, because a risk acceptance with no removal date leaves a KEV-listed device with a public exploit in service indefinitely. The exposure the inventory is scoring is specific: a single unauthenticated TDDP_RESET POST factory-resets and reboots the extender, after which the attacker sets a new administrative password and holds the device. Precondition on the reachability half, which is where this control is usually over-claimed: restricting the management surface bounds who can send that POST, but the packet's only stated access requirement is being on the same network, and a range extender exists to serve the client network it sits on — every client associated to it satisfies that condition, so for a unit extending a general user WLAN there is no segment that removes the path, only isolation of the extended WLAN itself from anything that matters. And because active exploitation is confirmed, a unit that was already reset and re-provisioned by an attacker is not remediated by firmware: its configuration and administrative credential are attacker-set and must be rebuilt from a known-good baseline rather than inherited through the update.",
+        "evidence": "The packet's vector states that TP-Link TL-WA855RE contains a missing authentication for critical function vulnerability allowing an unauthenticated attacker on the same network to submit a TDDP_RESET POST request for a factory reset and reboot, after which the attacker can obtain incorrect access control by setting a new administrative password; it further states the impacted products could be end-of-life (EoL) and/or end-of-service (EoS) and that users should discontinue product utilization. CWE-306; CISA KEV-listed 2025-09-02 with active_exploitation confirmed; poc_available true; CVSS 9.1, RWEP 77; patch_available true, live_patch_available false. ISO/IEC 27001:2022 A.8.8 and EU NIS2 Article 21 network and information system security are recorded among the framework controls insufficient for this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock is not the hard part on this entry; delivery is. The packet records a vendor patch with no live-patch path and a note that the vendor patch typically requires a service restart or system reboot per the KEV required action, so remediating a TL-WA855RE means each physical unit is taken through a firmware update and a reboot by hand. A consumer-grade Wi-Fi range extender is on no managed patch console, which means the KEV clock that opened 2025-09-02 can only be discharged against a hand-maintained inventory of where these units are actually deployed, and completion has to be measured by the firmware version the unit reports after it comes back up — not by an update having been pushed or a ticket closed. Urgency follows what the packet records rather than the CVSS band alone: exploitation is confirmed in the wild, a PoC is public, and the exploit is a single unauthenticated request that needs nothing but network adjacency. Precondition and limit: the packet also states the impacted products could be end-of-life or end-of-service with users advised to discontinue use, so for any unit whose hardware revision has no supported firmware this SLA cannot be met by patching at all and the item is discharged only by replacement — the two controls on this entry are read together, not as alternatives.",
+        "evidence": "CISA KEV-listed 2025-09-02 with active_exploitation confirmed and poc_available true. patch_available true; live_patch_available false, with the packet noting no live-patch tool registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The exploit path recorded is an unauthenticated TDDP_RESET POST from an attacker on the same network. ASD Essential Eight 'Patch operating systems' and NIST SP 800-53 SI-2 Flaw Remediation are recorded among the framework controls insufficient for this entry. CVSS 9.1, RWEP 77.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-55177": {
     "name": "Meta Platforms WhatsApp Incorrect Authorization Vulnerability",
@@ -23715,7 +23990,33 @@
     },
     "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": "Scope this to the Windows WinRAR installs the packet names rather than to archive handling in general: the defect is in WinRAR's archive extraction on Windows, and the fixed build is what removes it. Run the KEV-tied clock from the 2025-08-12 listing across every Windows workstation carrying WinRAR — including per-user and portable copies that sit outside managed software distribution and that an inventory-driven patch report never asks about, since a workstation only needs one unpatched copy for a delivered archive to extract through the vulnerable path. The packet registers no live-patch path and notes the vendor fix typically requires a service restart or system reboot per the KEV required action, so a copy updated but not restarted is not yet remediated. Precondition: an SLA reaches only copies the inventory can see — a portable WinRAR the operator cannot enumerate is remediated by removing it, not by recording the estate as patched, and until it is found the archive-borne path stays open on that host. The distinguishing test: after the update lands, enumerate WinRAR installs across managed and per-user paths and confirm none report a pre-fix build; a user-application-hardening attestation covering browsers and document handlers says nothing about the version of the archive utility that opens the attachment.",
+        "evidence": "Packet: RARLAB WinRAR path traversal (CWE-35) 'affecting the Windows version of WinRAR', where a crafted archive lets an attacker execute arbitrary code; the attack vector records the crafted archive writing to autorun locations for code execution on extraction, used in the wild by espionage actors. CISA KEV-listed 2025-08-12 with active_exploitation confirmed, poc_available true, CVSS 7.5, RWEP 77. patch_available true, live_patch_available false, with the packet noting no live-patch tool registered for this entry and that the vendor patch typically requires a service restart or system reboot per the KEV required action.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet records this entry as a variant — another path-traversal defect in the same WinRAR archive-extraction path — so an estate that scored it as a discrete finding scored it wrong. On the 7.5 base alone it queues into a routine third-party-application update window; the packet's own priority for it is RWEP 77, with a public PoC and in-the-wild use by espionage actors. The requirement is to carry WinRAR's extraction path handling as a primitive with a demonstrated repeat, so that the next defect disclosed against it inherits the elevated tier at disclosure rather than waiting for a KEV listing to force the escalation — the interval that matters is the one where a PoC is public and the fixed build is not yet deployed across per-user copies. The distinguishing test: check what due date the vulnerability-management process produced for this CVE, and whether the 2025-08-12 KEV listing is what moved it out of a routine window; if it is, the multiplier is not implemented and the following variant on this primitive will get the same routine window.",
+        "evidence": "Packet: the entry is named as a variant ('variant: CVE-2025-8088') and the attack vector describes 'a path-traversal flaw (CWE-35) in WinRAR's archive extraction (a variant)'. CVSS 7.5 against RWEP 77; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-08-12; used in the wild by espionage actors per the packet. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2007-0671": {
     "name": "Microsoft Office Excel Remote Code Execution Vulnerability",
@@ -27909,7 +28210,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Ancillary Function Driver for WinSock (afd.sys) and describes an authorized attacker escalating to administrator — the account is legitimate, so no account model is being abused; a privilege boundary inside a kernel driver is failing. For this CVE the control means the Windows update carrying the afd.sys fix is driven across every affected host on the clock that opened with the 2025-05-13 KEV listing rather than folded into the next monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. Hosts where non-administrative users hold interactive sessions are the population to enumerate first, because the precondition this flaw needs — an already-authorized local user — is the normal operating state there rather than an anomaly. The packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so a host that has installed the update but not restarted still runs the vulnerable driver and must be counted as exposed; the restart is also the step most likely to be deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. The load-bearing half is that tightening account privilege does not contain this escalation at all: the attacker already holds an authorized local session, which is exactly why a patch-cadence attestation can report the estate compliant while the flaw stays fully exploitable on every host that has not restarted. Priority follows the packet rather than the 8.8 band — a public PoC, confirmed in-the-wild exploitation, and the packet's own note that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators make this the containment step in a chain rather than a standalone endpoint ticket. Distinguishing test: report installed build plus last-restart time per host against the fixed build, and confirm the reboot-pending population is counted as exposed rather than as remediated.",
+        "evidence": "Packet: 'Microsoft Windows Ancillary Function Driver for WinSock contains a use-after-free vulnerability that allows an authorized attacker to escalate privileges to administrator' (CWE-416); attack_vector: 'a use-after-free (CWE-416) in the Windows Ancillary Function Driver for WinSock (afd.sys), exploited by a local foothold to escalate privileges to SYSTEM ... LPEs of this class are routinely paired with an initial-access flaw by ransomware operators'. cisa_kev true, kev_date 2025-05-13, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 77. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps closed here: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Detection for this CVE has to key on what the packet says the exploit achieves: an already-authorized local user context becoming administrator or SYSTEM through the afd.sys use-after-free. The signal is that privilege transition itself — a process owned by a standard interactive user acquiring a SYSTEM-level token, or spawning a child running as SYSTEM, without having passed through a sanctioned elevation path (a consented UAC elevation, a service-control-manager start, a task registered by an administrator) — with the alert raised inside the control's stated window. An exploit doing exactly what the packet describes emits that transition, which is why it is the right anchor: a rule built instead on afd.sys crash or bugcheck telemetry would miss the case that matters, because a working exploit escalates rather than faults, and a rule built on named tooling or file hashes misses any re-implementation of the same use-after-free by a different operator. Because the packet gives no live-patch path and a restart-gated fix, this is the control that covers the interval between the 2025-05-13 KEV listing and the last host's restart, and it is worth weighting toward the hosts where that restart is most deferred and where non-administrative users hold interactive sessions. Distinguishing test: on a staging host, have a benign program running as a standard user obtain a SYSTEM token by a route the elevation allowlist does not cover, and confirm the alert actually fires — verifying that the agent is installed and its policy reads 'enabled' proves nothing about whether the transition is detected. Preconditions: this is a dwell-time control, not a mitigation — it fires after the escalation has already happened and reduces none of the exposure the reboot-pending hosts carry; telemetry from a host where an attacker reached SYSTEM is attacker-influenceable, so the alert has to leave the host and be evaluated off-box to survive the event it exists to catch; and sanctioned elevation is routine on administrator and developer workstations, so the allowlist of legitimate transition paths must be built per host population before the rule is enabled, or it will be tuned off within a week.",
+        "evidence": "Packet: CWE-416 use-after-free in the Windows Ancillary Function Driver for WinSock (afd.sys); vector: 'allows an authorized attacker to escalate privileges to administrator'; attack_vector: 'exploited by a local foothold to escalate privileges to SYSTEM'; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-05-13; CVSS 8.8; RWEP 77. patch_available true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gap closed here: UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-30397": {
     "name": "Microsoft Windows Scripting Engine Type Confusion Vulnerability",
@@ -30267,7 +30591,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scanner that reports Exim at 4.97.1 or later and closes the finding has tested the half of the remediation the packet calls a software update and none of the half it calls a server configuration change. The defect is that the MTA accepts <LF>.<CR><LF> as end-of-data where RFC 5321 requires <CR><LF>.<CR><LF>, and the packet ties that acceptance to PIPELINING/CHUNKING configurations — so the property that has to be established is behavioural, against the running configuration, not a build string. The distinguishing test: against a staging Exim, open a connection using PIPELINING/CHUNKING, terminate a message's data with the non-standard sequence, follow it with what would be the smuggled message, and confirm the server does not treat the non-standard sequence as end-of-data and does not deliver the second message as separately submitted mail. Precondition: this validates the instance under test in its current configuration and nothing else — the verdict has to be re-established for every Exim host in the inbound path and re-run after any configuration change or package upgrade that could restore the tolerant parse. It also does not speak for other MTA software in that path; the packet establishes this defect for Exim, and other products in the chain need their own test rather than an assumption inherited from this one.",
+        "evidence": "Packet: 'Exim accepts <LF>.<CR><LF> as end-of-data in PIPELINING/CHUNKING configurations, differing from the RFC 5321 <CR><LF>.<CR><LF>, enabling a smuggled second message that inherits the outer SPF/DKIM/DMARC pass. Fix: upgrade to 4.97.1.' CWE-345 and CWE-93; poc_available true; CVSS 5.3, RWEP 33; cisa_kev false and active_exploitation suspected. patch_available true, live_patch_available false, with the packet stating remediation is a software update and, for the smuggling/STARTTLS classes, a server configuration change, requiring a service restart rather than a host reboot.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet gives two remediation components for this class — the 4.97.1 update and a server configuration change — so an Exim host carrying one but not the other is neither patched nor unmitigated, and the report has to say which. A host still on a pre-4.97.1 build whose configuration has been changed is running a compensating control with the tolerant end-of-data parse still present in the binary; it belongs in a distinct state with a dated action item for the update, not in the same column as a host that took the fixed build. The packet notes the update needs a service restart rather than a host reboot, so that action item is a service-restart window, not a maintenance outage — which removes the usual justification for leaving the host parked. Precondition: the compensating state holds only while that configuration remains in force, and a package upgrade, a configuration-management push, or a restore that reinstates defaults returns the host to full exposure with no signal, so the state has to be re-verified behaviourally on a schedule rather than recorded once. This matters most for this CVE because the packet records no KEV listing, only suspected exploitation and a CVSS of 5.3: nothing in a severity-ordered queue will resurface a host left in the compensating state.",
+        "evidence": "Packet: patch_available true with the fix given as upgrade to 4.97.1; live_patch_available false; live_patch_notes state remediation is a software update and, for the smuggling/STARTTLS classes, a server configuration change, with no live-patch primitive applicable and a service restart rather than a host reboot. cisa_kev false, kev_date null, active_exploitation suspected, CVSS 5.3, RWEP 33, poc_available true. The vulnerable behaviour is tied by the packet to PIPELINING/CHUNKING configurations.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3"
+        ]
+      }
+    ]
   },
   "CVE-2021-38371": {
     "name": "Exim STARTTLS response injection (pre-handshake buffer not drained on the sending MTA path)",
@@ -30400,7 +30748,28 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-008",
+        "name": "CRYPTO-SUBSYSTEM-CVE-DISCLOSURE",
+        "description": "The subsystem at fault here is the one the estate's transport-protection claim for mail submission rests on. The packet has the Dovecot submission service failing to discard commands buffered before the TLS handshake, so a prebuilt plaintext sequence is executed after the handshake and an on-path attacker redirects sensitive data to an attacker-controlled destination — the session is encrypted and the attacker's commands are inside it. Applied to this entry, the control means that while a submission service is below 2.3.15, any control recorded as satisfied by 'mail submission is protected by STARTTLS' is documented as not a compensating control for this CVE, and the risk assessment states that explicitly instead of carrying the encrypted-in-transit attestation forward. That is precisely the network-security gap cited on this entry: an attestation that submission traffic is encrypted passes cleanly, while the flaw's entire effect is that the encryption no longer excludes the on-path attacker's injected commands. Preconditions and limits: this is a bookkeeping control — it changes what the estate is permitted to claim, not what the server does. What removes the flaw is the fix the packet names, upgrading to 2.3.15, which the packet records as a software update needing a service restart rather than a host reboot, with no live-patch primitive applicable. The exploit's own precondition is an on-path position, so a submission service whose clients never traverse a network an attacker can occupy is less exposed — but 'the traffic stays internal' is an assertion about topology, and it is the assertion STARTTLS was deployed so the estate would not have to rely on.",
+        "evidence": "Packet vector: 'The submission service in Dovecot before 2.3.15 allows STARTTLS command injection in lib-smtp: a prebuilt sequence of commands sent before the TLS handshake is executed after the handshake, allowing an on-path attacker to redirect sensitive data to an attacker-controlled destination. Fix: upgrade to 2.3.15.' attack_vector: 'the server/client does not discard bytes buffered before the TLS handshake, so an on-path attacker injects plaintext SMTP commands/responses that are processed inside the encrypted session.' cisa_kev false, active_exploitation 'none', poc_available true, cvss 4.8, rwep_score 19. patch_available true, live_patch_available false, live_patch_notes 'Remediation is a software update (and, for the smuggling/STARTTLS classes, a server configuration change); no live-patch primitive applies. Service restart, not host reboot.' Citing gap NIS2-Art21-network-security (Security of network and information systems).",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The packet's remediation note names two halves for this class — a software update and, for the smuggling/STARTTLS classes, a server configuration change — and this control governs what happens to the second half once the first lands. The packet also places the entry in a lineage rather than treating it as a one-off: the same pre-handshake-buffer primitive runs from 2011 Postfix to the 2021 multi-MTA round that produced this CVE, which is the pattern this control was written for, a primitive class that reappears rather than a defect that ends with its own patch. For this Dovecot deployment it means the configuration-side change made while waiting for 2.3.15 is kept in place after the upgrade and through a stated review period, instead of being reverted the moment the package version satisfies the vulnerability-management check. Distinguishing test: once the submission service reports 2.3.15 or later, re-read its live configuration and confirm the hardening applied during the exposure window is still set — a vulnerability-management record showing the fixed version says nothing about whether the configuration was rolled back to the pre-incident default as soon as it did. Preconditions: this control preserves a mitigation, it does not supply one. A deployment that never made a configuration change during the window has nothing to retain, and for it the packet's fix — the upgrade to 2.3.15 with the service restart it needs — is the entire remediation. Retention is also not protection against a future sibling defect on its own; it holds ground the operator already took while that possibility is live. The packet records active_exploitation 'none' and no KEV listing, so this is hygiene against a recurring class, not a response to observed attack.",
+        "evidence": "Packet live_patch_notes: 'Remediation is a software update (and, for the smuggling/STARTTLS classes, a server configuration change); no live-patch primitive applies. Service restart, not host reboot.' attack_vector: 'STARTTLS command/response injection: the server/client does not discard bytes buffered before the TLS handshake... Part of the NO STARTTLS research lineage (2011 Postfix → 2021 multi-MTA).' vector states the fix as 'upgrade to 2.3.15'. cisa_kev false, active_exploitation 'none', poc_available true, cvss 4.8, rwep_score 19, patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2011-0411": {
     "name": "Postfix STARTTLS plaintext command injection (I/O buffering not reset across TLS handshake)",
@@ -30455,7 +30824,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "This entry is the case the control exists for, because the remediation the packet records for Postfix has two halves and only one of them is a package version: a software update, and — the packet names it explicitly for the STARTTLS class — a server configuration change. The vulnerable behaviour is not a memory-corruption bug that a binary replaces but an acceptance decision about bytes that arrived before the TLS handshake, and that decision is also governed by how the MTA is configured to offer and require transport security. Applied to this deployment: enumerate every Postfix instance together with its transport-security configuration, and hold the configuration change as a tested, deployable artifact maintained independently of the maintenance-release rollout, so an instance whose package cannot move immediately still has a lever. Distinguishing test, keyed on the behaviour the packet describes rather than on a version string: from an on-path position against a staging instance, deliver plaintext SMTP command bytes after the STARTTLS response and before the handshake, then confirm they are not executed in the encrypted session that follows — a scan that reads the Postfix package version cannot tell a fixed instance from one that still carries the buffering defect. Precondition, and it is a real limit: the configuration lever only removes the in-band upgrade for peers that can be moved off it. A peer that can only negotiate opportunistically still performs the in-band upgrade against the buffering defect, and for those sessions nothing but the patched 2.x maintenance release the packet names closes the path. The packet records no live-patch primitive and a service restart rather than a host reboot, so an instance whose package was replaced without that restart is still running the vulnerable code; the configuration change is a holding measure for the window before the restart, not a substitute for it.",
+        "evidence": "Packet vector: Postfix's STARTTLS implementation 'does not properly restrict I/O buffering, so plaintext SMTP commands inserted by a man-in-the-middle before the TLS handshake are executed within the encrypted session afterward. Fix: upgrade to the patched 2.x maintenance release.' live_patch_notes: 'Remediation is a software update (and, for the smuggling/STARTTLS classes, a server configuration change); no live-patch primitive applies. Service restart, not host reboot.' patch_available true, live_patch_available false. CWE-77 / CWE-264; CVSS 4.8, RWEP 17; poc_available true; cisa_kev false; active_exploitation none.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The packet places this Postfix defect at the head of a lineage rather than treating it as a closed 2011 item: it records the entry as part of the NO STARTTLS research lineage running from 2011 Postfix to a 2021 multi-MTA round — the same failure to discard bytes buffered before the handshake resurfacing in other mail transfer agents a decade later. For this entry the control means the transport-security configuration change the packet names as part of remediation is not reverted the moment the patched 2.x maintenance release lands and the service restarts; it stays in place through a stated review period, because the primitive it constrains has already demonstrated that it reappears in implementations previously considered fixed. Precondition: retention only helps for the sessions the configuration actually governs — it does nothing for a peer that can only negotiate the in-band upgrade, and it does not detect an injection that already succeeded, because the packet has the injected commands executing inside the encrypted session, carried on the same channel as the legitimate peer's traffic. Retention is also not grounds to defer the update: patch_available is true and the packet registers no live-patch primitive, so every instance still has to take the maintenance release and the service restart. Priority follows the packet rather than the CWE severity: cisa_kev is false and active_exploitation is none, so this belongs on the scheduled maintenance path, and the reason to keep the compensating configuration is the recurrence the packet documents, not an active-exploitation clock.",
+        "evidence": "Packet attack_vector: 'STARTTLS command/response injection: the server/client does not discard bytes buffered before the TLS handshake, so an on-path attacker injects plaintext SMTP commands/responses that are processed inside the encrypted session. Part of the NO STARTTLS research lineage (2011 Postfix → 2021 multi-MTA).' live_patch_notes names a server configuration change for the smuggling/STARTTLS classes alongside the software update, with no live-patch primitive and a service restart rather than a host reboot. cisa_kev false; active_exploitation none; RWEP 17; CVSS 4.8; poc_available true; patch_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-50387": {
     "name": "KeyTrap — DNSSEC validating-resolver CPU exhaustion via crafted DNSKEY/RRSIG combinations",
@@ -30515,7 +30907,20 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "academic_ai_fuzzing",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For KeyTrap the paper-compliance trap is version-only scanning of the validating-resolver estate, and this entry is unusually exposed to it: the packet records cisa_kev false and active_exploitation only 'suspected', so no KEV-triggered clock ever fires and a package-version scan is the entire visible compliance signal. The fix is also entirely internal — the packet states vendor patches cap the validation work — so nothing about a patched resolver's external behaviour changes for ordinary queries, and the packet explicitly scopes remediation as a service restart, not a host reboot. That combination produces the specific false-pass this control exists to catch: a resolver host whose package has been upgraded but whose validating daemon was never restarted keeps executing the pre-patch uncapped signature-evaluation path in memory while the scanner reads the on-disk package version and reports the host remediated. Applied here, the control means an operator's remediation evidence for this CVE is the running daemon's state, not the installed package version. Distinguishing test, keyed on the behaviour the packet documents: against a staging validating resolver, serve a zone presenting many DNSKEY and RRSIG records with colliding key tags, and confirm the signature-evaluation work is bounded and the resolver keeps answering other clients' queries rather than stalling for all of them; pair that with confirming the running validator process start time postdates the package upgrade. Precondition, stated plainly: this control verifies the cap is in force — it does not itself bound the work. Until the updated build is the running build, a crafted response still forces the worst-case O(n*m) evaluation, and the packet offers no operator-side substitute: it records no live-patch primitive for this entry, and the configuration-side change its live-patch note mentions is attached to the smuggling/STARTTLS classes, not to this one.",
+        "evidence": "Packet: CWE-770, CVSS 7.5, RWEP 39, poc_available true, patch_available true, live_patch_available false. cisa_kev false, kev_date null, active_exploitation 'suspected'. Vector: 'A validating resolver must evaluate all combinations of DNSKEY and RRSIG records when a zone presents many of them (colliding key tags)... forces worst-case O(n*m) signature evaluations, consuming CPU and stalling the resolver for all clients. Fix: vendor patches cap the validation work.' live_patch_notes: 'Remediation is a software update (and, for the smuggling/STARTTLS classes, a server configuration change); no live-patch primitive applies. Service restart, not host reboot.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-50868": {
     "name": "DNSSEC NSEC3 closest-encloser proof CPU exhaustion (excessive SHA-1 iterations)",
@@ -31792,7 +32197,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives a remote, unauthenticated request path into a deserialization sink that ends in arbitrary code execution on PTC Windchill and FlexPLM, KEV-listed 2026-06-25, with confirmed exploitation and a public PoC. For this entry the control means the PTC update is scheduled off that KEV listing rather than folded into the next platform maintenance window, with completion measured per instance against the fixed build rather than by 'approved' or 'downloaded' in a change record. Because the request requires no authentication, there is no account model to tighten and no privilege scoping that shortens the exposure — the interval between listing and fixed build is the entire mitigation surface, which is why the flaw-remediation and vulnerability-handling controls cited here can pass their attestations on a 30-day cadence while the instance stays exploitable for that whole period. Precondition: the packet records patch_available true, live_patch_available false, and a note that remediation is the vendor update plus the named compensating controls until it lands, so there is no in-place mitigation that closes the sink; every instance carries the update and the service restart it needs, and an instance updated but not restarted is not yet remediated. The clock is also not the whole remediation on this entry — the packet documents webshells dropped in the wild, so an instance that was reachable during the window is not made clean by reaching the fixed build.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-06-25, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 72. patch_available true, live_patch_available false, live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Vector: 'A remote, unauthenticated attacker sends a specially crafted request whose untrusted data is deserialized by Windchill/FlexPLM (CWE-20 leading to CWE-502), yielding arbitrary code execution.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Windchill and FlexPLM are not perimeter appliances, but the packet gives this entry the exact condition the control turns on and does not leave the post-exploitation state to inference: pre-authentication remote code execution under confirmed exploitation, observed in the wild dropping persistent JSP webshells that provide ongoing remote command execution and data exfiltration. A JSP webshell is a file inside the deployed web application; the PTC update repairs the input-validation-into-deserialization path the attacker arrived through and removes nothing that was written through it, so an instance patched in place can keep serving the attacker's shell while carrying a flaw-remediation record that reads clean. For this product the control therefore means the default response for any instance reachable during the window opened by the 2026-06-25 KEV listing is: preserve the running deployment for forensics, compare the served application against a known-good build, rebuild rather than clean in place, and rotate every credential the platform held or brokered — with exfiltration scoped against what the packet names as being at stake, the product designs and manufacturing IP the PLM platform stores. Distinguishing test: on a staging instance, place a JSP file into the deployed application, apply the vendor update, and check whether the file is still served afterwards; an upgrade procedure that leaves it in place is a procedure that leaves a webshell in place, and that is the property the flaw-remediation attestation never examines. Preconditions: rebuilding requires a restore point predating the exposure window and a source of truth for the deployment's configuration — where neither exists, the honest position is that the instance's integrity cannot be established from the patch alone, not that patching settled it. Rebuilding also does not close the vulnerability: the rebuilt instance must come up on the fixed build, because the packet records no live-patch path and the crafted request needs no credential.",
+        "evidence": "Packet vector: 'Observed in the wild dropping persistent JSP webshells that provide ongoing remote command execution and data exfiltration from the PLM platform, which holds product designs and manufacturing IP', reached by 'a remote, unauthenticated attacker' via CWE-20 leading to CWE-502. cisa_kev true (2026-06-25), active_exploitation 'confirmed', poc_available true, cvss 9.8. patch_available true, live_patch_available false, live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-20230": {
     "name": "Cisco Unified Communications Manager Server-Side Request Forgery (SSRF) Vulnerability",
@@ -32290,7 +32720,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The tenant-writable filesystem of one account on a shared CloudLinux/CageFS host is the constrained user surface here, and the LiteSpeed cPanel plugin's generateEcCert and packageUserSize JSON-API operations are the root operations wired straight to it. Because the plugin follows an attacker-planted symlink without validating its target, a path a jailed tenant fully controls decides what a root-privileged process opens — the pattern this control forbids, and the reason the CVSS carries S:C with full CIA impact. Applied to this plugin, the control means the two named root operations resolve every path to its canonical target and verify it still sits under the invoking account's CageFS root before the privileged open, refusing a target that resolves outside the jail, rather than inheriting safety from the assumption that a jailed account cannot influence what root touches. Distinguishing test, keyed on the behaviour the packet documents rather than on a proxy signal: from an unprivileged tenant account on a staging shared host, plant a symlink in a path generateEcCert or packageUserSize will operate on whose target resolves outside that account's CageFS root, drive the JSON-API operation repeatedly to work the timing window the AC:H rating reflects, and confirm the privileged process refuses the target instead of reading or writing through it; on the defensive side, a root-privileged plugin operation resolving a path outside the invoking tenant's jail, and repeated attempts against the same operation from one account, are the observable emissions of exactly this exploit. Preconditions, stated plainly: the packet's own precondition is that the attacker already holds FTP or web-shell access to one account on the host — which is the access every paying tenant has by design — so restricting who can obtain a shell does not bound the attacker population and is not a mitigation here. The path-validation property is established by the vendor update; this control states what to verify, it does not implement it, and the packet records no live-patch path for this product class. And because exploitation is confirmed and scope is changed, the update does not undo what was already read: a host that ran the plugin during the exposure window needs cross-tenant triage and rotation of the other customers' database credentials and configuration the packet says this escape reaches.",
+        "evidence": "Packet: CWE-61, CVSS:3.1 8.5 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H), RWEP 68, poc_available true, cisa_kev true, kev_date 2026-06-15, active_exploitation confirmed. Vector: 'A low-privileged tenant who already holds FTP or web-shell access to one account on a shared CloudLinux/CageFS host plants a malicious symlink in a path the LiteSpeed cPanel plugin subsequently operates on with root privilege (during the generateEcCert / packageUserSize JSON-API operations). Because the plugin follows the attacker-controlled symlink without validating its target (CWE-61/CWE-59), the privileged process reads or writes files outside the tenant's CageFS jail. This escapes the per-account sandbox to reach other customers' database credentials, config, and source — or system files... gated behind pre-existing low-privilege access and high attack complexity (a timing/race window characteristic of symlink TOCTOU).' 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-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is KEV-listed 2026-06-15 with confirmed in-the-wild exploitation, a public PoC, and an available vendor update, so it meets every trigger for an expedited clock — but the shared-hosting deployment changes what 'mitigated' has to mean before the clock can be stopped. The unit an operator patches is one shared host, while the blast radius the packet describes is every tenant on it: a single jailed account reaching root reaches the other customers' database credentials, config and source. Applied here, the control means the KEV response for a CloudLinux/CageFS fleet is scheduled per host across the whole fleet rather than per affected customer ticket, and the completion criterion includes rotating the cross-tenant secrets exposed on any host that stayed unpatched through the window — not just recording the plugin version. Precondition and the honest limit: the packet records live_patch_available false and states that remediation is the vendor update plus the named compensating controls until it lands, so there is no no-downtime path that stops this clock; and because exploitation is confirmed, meeting the SLA closes the path forward but does not evict an attacker who already used it, which is why the credential rotation belongs inside the SLA rather than after it.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-06-15, active_exploitation confirmed, poc_available true, patch_available true, live_patch_available false, RWEP 68, CVSS 8.5. live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Vector: the escape 'reach[es] other customers' database credentials, config, and source — or system files — escalating a single jailed account to root-level, server-wide cross-tenant compromise.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2026-20262": {
     "name": "Cisco Catalyst SD-WAN Manager Directory or Path Traversal Vulnerability",
@@ -32455,7 +32909,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This CVE is the second entry on one primitive, and the packet says so directly: the `__class`-key instantiation path is 'reintroduced as a regression of CVE-2024-4990 (incompletely fixed in 2.0.50)'. That produces the exact condition this control governs — an operator who applied 2.0.50 holds a closed, attested remediation record on the very primitive that is now KEV-listed and exploited in the wild, and a vulnerability-management program that scores each CVE discretely will treat that record as evidence of safety rather than as the reason to look again. Applied to Yii 2, the multiplier means the framework's behaviour/configuration attachment logic is registered as a known incomplete-patch primitive, this CVE is scored above its base severity because it is the second on that primitive, and the remediation record from the first fix is reopened and re-tested rather than credited — with the standing expectation that a third bypass of the same attachment path is likely and should be watched for, not treated as a surprise. Distinguishing test: on a staging application running the current build, replay the original primitive's input shape — an attacker-supplied array carrying a `__class` key routed into behaviour/configuration attachment over an unauthenticated request path — and confirm no class is instantiated from the request-named value. A build attested as at or above 2.0.50 with CVE-2024-4990 recorded remediated, which nonetheless instantiates from `__class`, is precisely the state the packet describes and the state a discrete-CVE scoring model cannot see. Precondition: this is a scoring and re-test discipline, not a runtime mitigation. It changes which builds get retested and how urgently; it does not stop the instantiation. Only the vendor update does that, and the packet records live_patch_available false with no live-patch path for this product class.",
+        "evidence": "Packet: CWE-424, CVSS 9.0, RWEP 72, poc_available true, cisa_kev true, kev_date 2025-05-02, active_exploitation confirmed. Vector: 'When the supplied array contains a `__class` key, Yii instantiates the named class with attacker-chosen parameters — an unsafe-reflection / object-injection primitive reintroduced as a regression of CVE-2024-4990 (incompletely fixed in 2.0.50). By selecting a class whose constructor or destructor performs file writes or command execution, the attacker converts that instantiation into remote code execution.' 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": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "KEV-listed 2025-05-02 with confirmed exploitation, a public PoC and an available vendor update, so the expedited clock applies — but for this CVE the harder problem is naming the asset the clock attaches to. The vulnerable component is the Yii 2 framework underneath a deployed application, and the packet's observed campaign delivered the input by chaining Craft CMS pre-auth RCE CVE-2025-32432; an estate whose asset inventory records the CMS product and version but not the framework version beneath it has nothing for this KEV entry to match against, and will report full KEV compliance while the exploited component goes untracked. Applied here, the control means the framework version underneath every internet-reachable PHP application is a first-class inventoried asset with its own SLA clock, so a KEV entry naming the framework rather than the application still lands on a host. Precondition and the honest limit: the packet records live_patch_available false with no live-patch path for this product class, so the update is the only thing that closes the instantiation path — and because exploitation is confirmed and the packet's observed outcome is web-shell deployment and data theft on the host, meeting the SLA by upgrading is necessary but not sufficient. An application reachable during the exposure window needs the host searched for a dropped web shell and the stolen-data question answered; the upgrade removes the way in, not what an attacker already left behind or already took.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-05-02, active_exploitation confirmed, poc_available true, patch_available true, live_patch_available false, RWEP 72, CVSS 9.0, CWE-424. Vector: 'A Yii 2 application that lets attacker-controlled array input reach Yii's behavior/configuration attachment logic is reachable over the network with no authentication... In the observed campaign the input was delivered by chaining Craft CMS pre-auth RCE CVE-2025-32432, so a single unauthenticated request escalated straight to web-shell deployment and data theft on the host.' 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": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-38475": {
     "name": "Apache HTTP Server Improper Escaping of Output Vulnerability",
@@ -33251,7 +33728,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The vulnerable code is in the kernel itself — the ALSA USB-audio driver's Extigy/Mbox quirk path, where a device-advertised bNumConfigurations larger than the array usb_get_configuration() allocated turns indexed access into a read and write past the dev->config allocation. For this CVE the control means the kernel update is driven across every Linux and Android device the estate holds on the clock that opened with the 2025-04-09 KEV listing, with completion measured per device by the kernel build actually running (on handsets, the reported security patch level) rather than by 'approved' or 'downloaded' in a management console. The packet records a vendor patch and live_patch_available false, so nothing repairs this in place: a device that has staged the update but has not restarted onto the new kernel is still running the vulnerable quirk path and must be counted as exposed — and the restart is the step a user defers. Enumerate first the population that physically leaves the operator's control — laptops and handsets that get lost, seized, or left unattended — because the packet's precondition is brief physical access to a locked device, not a network position and not a user account. That same property is why account-side hardening cannot stand in for the update: the escalation begins inside the kernel's own USB enumeration path before anyone authenticates, so no privilege model is ever consulted.",
+        "evidence": "Packet vector: 'An attacker with brief physical access plugs a malicious USB gadget into the target's locked Linux/Android device, reaching the kernel's ALSA USB-audio driver through normal USB enumeration. The crafted device matches the Extigy/Mbox quirk path and advertises a bNumConfigurations value larger than the configuration array actually allocated by usb_get_configuration(), so subsequent indexed access (e.g. in usb_destroy_configuration / snd_usb_create_quirk) reads and writes past the dev->config allocation — an out-of-bounds primitive (CWE-787).' The chain outcome the packet records is lockscreen bypass and escalation 'from the unprivileged USB-handling context to kernel/root code execution, giving full device compromise.' Fields: cisa_kev true, kev_date 2025-04-09, active_exploitation confirmed, CVSS 7.8, RWEP 59, poc_available false, ai_discovered false, patch_available true, live_patch_available false, live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The exploit's entry point is a driver bind: a hostile gadget enumerates and the kernel brings up the ALSA USB-audio driver for it because the advertised device identity matches the Extigy/Mbox quirk entry. On Linux hosts with no business reason to carry audio over USB — servers, kiosks, fixed-function and appliance workstations — inventorying that driver and denying its autoload (blacklist plus an install-override, so a matching hotplug cannot pull it in) removes the reachability the crafted descriptor needs during the window before the kernel update lands. State the precondition rather than recording this as the fix: a blacklist only prevents an autoload. It does nothing where the ALSA USB-audio driver is built into the kernel image, which is the normal case on vendor Android and many appliance kernels, and nothing where the module is already resident because a USB-audio device was used earlier in the boot. For those cases the remaining levers are refusing unknown USB devices by default (deny-by-default USB device authorization / allowlisting) and the platform's no-USB-data-while-locked setting; where the driver is merely loaded rather than built in, unloading it or powering the device down so it does not survive to the next boot. On managed handsets where the operator cannot alter module or USB policy at all, none of these are available and the vendor update is the only path. Distinguishing test: with the policy in force, attach an unknown USB-audio-class gadget to a locked staging device and confirm no ALSA USB-audio bind occurs — an inventory that lists the module as 'not required' while the kernel still binds it on hotplug has recorded the exposure rather than removed it.",
+        "evidence": "The packet makes driver reachability the precondition: the gadget is reaching 'the kernel's ALSA USB-audio driver through normal USB enumeration' and 'matches the Extigy/Mbox quirk path', with the out-of-bounds access occurring in usb_destroy_configuration / snd_usb_create_quirk. live_patch_available is false and live_patch_notes states remediation is 'the vendor update plus the named compensating controls until it lands', which is the role this control fills. Attack requires brief physical access to a locked device; active_exploitation confirmed, kev_date 2025-04-09, poc_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The packet does not describe this bug acting alone: the out-of-bounds primitive is combined with the other USB-driver bugs in the same chain to bypass the lockscreen and reach root. That makes the USB-side measures taken for this CVE — ALSA USB-audio autoload denial, deny-by-default USB device authorization, no-USB-data-while-locked — controls against a class reached by one physical enumeration path, not against one CVE, and it makes retiring them the moment the kernel update is marked deployed the specific mistake to avoid: the sibling drivers on that same path keep answering a hostile descriptor, and the next defect in the class then arrives at a device whose only protection is its patch level. Keep the USB restrictions in force through a stated soak period after the updated kernel is running, and re-verify them after any kernel upgrade, image rebuild, or factory reset, since those are the operations that quietly restore autoload and default device authorization. Precondition: these restrictions bound which devices can present a crafted descriptor, they do not repair the quirk path, and they are unavailable on handsets where module and USB policy are not the operator's to set. They also give nothing to a device already exploited — with confirmed in-the-wild exploitation and full device compromise as the packet's stated outcome, a device that was plugged into an unknown gadget while locked belongs on the incident path, not on the hardening path.",
+        "evidence": "Packet vector: 'Combined with the other USB-driver bugs in the Cellebrite chain, this memory corruption is leveraged to bypass the lockscreen and escalate from the unprivileged USB-handling context to kernel/root code execution, giving full device compromise.' live_patch_notes names the interim posture explicitly — 'remediation is the vendor update plus the named compensating controls until it lands' — with live_patch_available false and patch_available true. active_exploitation confirmed; cisa_kev true, kev_date 2025-04-09; CWE-787; RWEP 59; CVSS 7.8.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-29824": {
     "name": "Microsoft Windows Common Log File System (CLFS) Driver Use-After-Free Vulnerability",
@@ -33361,7 +33869,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The secret is inside the product. The packet states CentreStack/Triofox ship a hard-coded ASP.NET machineKey in their IIS web.config and that it is the same across installs, so the value an attacker needs to forge a MAC-signed __VIEWSTATE is obtained from the product rather than from the target site. Nothing an operator sets, rotates or scopes touches it, and the attacker never authenticates to the portal, so account hygiene is never consulted on this path. Bound to this product, the control means every Gladinet CentreStack and Triofox portal in the estate is inventoried as depending on a product-shipped cryptographic key, each deployment is gated on the vendor update rather than on any password or account measure, and that check is re-run after any portal reinstall, image restore or rebuild — those operations restore the shipped web.config and quietly reintroduce the static key on a server that had been remediated. Distinguishing test: per portal, produce the deployed CentreStack/Triofox version and show the machineKey that IIS is using to validate ViewState is unique to that install rather than the value common to every install; an attestation that every portal administrator holds unique credentials passes cleanly while an unauthenticated attacker forges a signed ViewState against the same server. Precondition: the vendor update is what removes the dependence on a shipped key — this control is the inventory and the gate that ensure every install reaches it, and it gives nothing on its own to a portal that has not yet taken the update. The packet records a vendor patch and no live-patch path, so a portal keeps the vulnerable key handling until that update is actually applied. It also does not tell you whether a portal was already exploited, so a server that was internet-reachable before the update needs triage rather than a version check alone.",
+        "evidence": "Packet: 'The CentreStack/Triofox web portal ships a hard-coded ASP.NET machineKey in its IIS web.config, so any unauthenticated remote attacker who knows that static key (it is the same across installs) can forge a valid, MAC-signed __VIEWSTATE payload.' CWE-321 (hard-coded cryptographic key) and CWE-798. IIS trusts the signed ViewState and deserializes it server-side, executing a .NET gadget chain at deserialization time. CISA KEV-listed 2025-04-08, active_exploitation confirmed, poc_available true, CVSS 9.0, RWEP 70. patch_available true; live_patch_available false, with live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "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": "The packet puts the entry point at an internet-exposed portal endpoint reachable without authentication, and the end state at code execution as the IIS application-pool identity escalating toward NT AUTHORITY\\SYSTEM with lateral movement — with exploitation confirmed in the wild and a public PoC available. Applied to CentreStack/Triofox, that makes the default disposition for any portal that was internet-reachable during the exposure window a suspected-compromise case rather than an update ticket: capture the portal configuration and IIS request logs before touching the host, rebuild the server, and rotate every credential the app-pool identity could reach — portal administrator accounts, the storage back-end credentials the portal holds, and any domain credential used by or stored on that host — instead of applying the vendor update in place and closing the finding. Installing the update replaces the vulnerable key handling; it removes nothing an attacker already wrote to or started on the server, and this particular path leaves no failed-authentication trail to look for, because a forged ViewState is a valid signed request rather than a login attempt. Precondition: this is the disposition for a portal reachable during the exposure window. Where reachability across that window can be positively excluded from evidence — the portal was never published, or network records show no requests reached it — patch-in-place is the correct call; 'no alerts fired' is not that evidence, for exactly the reason above.",
+        "evidence": "Packet: 'Reachability is the internet-exposed portal endpoint; the primitive is signed-ViewState deserialization RCE; escalation is app-pool-to-SYSTEM plus lateral movement.' Code runs as the IIS application-pool identity (IISAPPPOOL\\portaluser / portal app pool) and is 'trivially escalated toward NT AUTHORITY\\SYSTEM for full server compromise'. Any unauthenticated remote attacker who knows the static key can forge the payload. CISA KEV-listed 2025-04-08, active_exploitation confirmed, poc_available true, RWEP 70, CVSS 9.0. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-24813": {
     "name": "Apache Tomcat Path Equivalence Vulnerability",
@@ -33416,7 +33949,42 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "This CVE's exposure is configuration-determined, and the packet names each lever: the path needs the default servlet's write support enabled (the packet notes it is off by default) and partial PUT supported (on by default), and the escalation from file-write to code execution additionally needs Tomcat's file-based session persistence at the default storage location plus a deserialization-exploitable library on the classpath. Every one of those is a Tomcat configuration setting the operator can change without waiting for the vendor upgrade, which is exactly what this control requires be inventoried, tested and deployable on its own clock: know per instance whether default-servlet write support is on, turn it off wherever nothing depends on HTTP writes through that servlet, and move file-based session persistence off the default storage location where write support must stay. That matters here because the packet records a vendor update with no live-patch path, so an instance keeps running the vulnerable partial-PUT implementation until the fixed build is the one actually executing. Distinguishing test: on a staging instance carrying the production configuration, issue an unauthenticated partial PUT whose target path exercises the separator-to-dot equivalence, and confirm no attacker-controlled bytes land at a predictable location outside the intended upload target — an inventory row asserting 'write support is off by default' describes the shipped default, not the configuration this instance is running. Preconditions, both load-bearing: disabling write support is not available to an application that genuinely serves HTTP writes through the default servlet, and there the remaining levers are the session-persistence location and the upgrade. Moving session persistence off the default location removes the packet's stated route to code execution but not the write primitive itself — the packet says that absent the deserialization preconditions the same primitive still yields read or injection of security-sensitive uploaded files, so the instance stays exposed to disclosure and content tampering. And neither change evicts anything already written through the path before it was made; with exploitation confirmed in the wild and a public PoC, an instance reachable during the exposure window needs its session-persistence directory and its served content compared against a known-good state, not just a configuration diff.",
+        "evidence": "Packet: write support on Tomcat's default servlet is 'enabled (off by default)' and 'partial PUT is supported (on by default)'; the original partial-PUT implementation 'wrote the request body to a temporary file whose name was derived from the user-supplied path with the path separator replaced by a dot (\"internal dot\" path equivalence, CWE-706/CWE-44), letting an attacker place attacker-controlled bytes at a predictable filesystem location outside the intended upload target.' The RCE step requires that 'the application uses Tomcat's file-based session persistence at the default storage location and ships a deserialization-exploitable library on the classpath', staged via partial PUT then triggered 'with a crafted JSESSIONID request (CWE-502)'; 'absent the deserialization preconditions the same primitive yields read/inject of security-sensitive uploaded files'. CISA KEV-listed 2025-04-01, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 76. patch_available true; live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scan that reads the Tomcat version banner and stops cannot tell an operator which of this CVE's two documented outcomes each instance faces, and the packet makes that difference the entire triage question: with default-servlet write support enabled, partial PUT available, file-based session persistence at the default storage location and a deserialization-exploitable library on the classpath, the result is remote code execution; without the deserialization preconditions the same primitive yields read or injection of security-sensitive uploaded files. The operational test for this CVE is therefore whether the assessment reports, per Tomcat instance, (a) whether write support on the default servlet is enabled, (b) whether partial PUT is available, (c) where file-based session persistence stores its files, and (d) whether the build actually running carries the fix — or whether it emits one CVSS 9.8 row per version banner. A version-only result is paper compliance in both directions at once: it raises instances that cannot reach the code-execution chain, and it marks compliant an instance whose configuration does reach it as soon as the banner reports a fixed build, even though the packet records no live-patch path and the process may still be executing the previous one. Precondition: this control changes what the assessment reports; it changes nothing about the instance. An accurate inventory that finds write support enabled on a Tomcat still leaves that instance fully exposed until the configuration is changed or the fixed build is running.",
+        "evidence": "Packet: the code-execution path is conditional on write support being 'enabled (off by default)', partial PUT being 'supported (on by default)', 'file-based session persistence at the default storage location' and 'a deserialization-exploitable library on the classpath'; 'absent the deserialization preconditions the same primitive yields read/inject of security-sensitive uploaded files (information disclosure / content tampering).' CWE-44, CWE-502, CWE-706. CISA KEV-listed 2025-04-01, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 76. live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The packet makes a transitive dependency the switch between information disclosure and remote code execution on this CVE: the code-execution path requires that the application 'ships a deserialization-exploitable library on the classpath', alongside file-based session persistence at the default storage location. A gadget-capable library is almost never something an application declares directly — it arrives underneath a framework, a connector or a driver — so a dependency inventory that stops at declared dependencies cannot answer whether a given Tomcat-hosted application belongs to the RCE population or the disclosure population, which is the question that decides how urgently each instance is handled. Applied here: the inventory for every application deployed on an affected Tomcat must resolve the full transitive classpath, and the triage decision for this CVE must be taken from that resolved classpath rather than from the application's declared dependency list. Preconditions: resolving the classpath does not change it — an application found to carry a gadget-capable library on a Tomcat that also has write support and default-location session persistence is in the code-execution population and still needs the configuration lever or the fixed build; the inventory only identifies which instances those are. And the classpath is a property of what is deployed, so it has to be re-resolved on each application deployment rather than captured once, or the answer goes stale the next time a dependency is added underneath.",
+        "evidence": "Packet: the escalation to RCE requires that the application 'uses Tomcat's file-based session persistence at the default storage location and ships a deserialization-exploitable library on the classpath', after which the attacker 'stages a malicious serialized session object via partial PUT, then forces Tomcat to deserialize it with a crafted JSESSIONID request (CWE-502)'. Without those preconditions the packet records the outcome as read/inject of security-sensitive uploaded files. CISA KEV-listed 2025-04-01, active_exploitation confirmed, poc_available true, RWEP 76.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-20439": {
     "name": "Cisco Smart Licensing Utility Static Credential Vulnerability",
@@ -33560,7 +34128,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's delivery is a spear-phished link to an attacker-controlled page, so every Chrome/Chromium install in the estate is in scope the moment a user can open a link — there is no server-side surface to isolate, and the packet names no configuration-side mitigation, recording remediation as the vendor update plus the named compensating controls until it lands. For this CVE the control means the managed update ring for Chrome/Chromium carries no deferral: the fixed build is driven out on the KEV clock that opened 2025-03-27 rather than held for a ring's soak period, and completion is measured by the build the browser is actually running on each host, not by the update being approved or downloaded in the management console, because the packet registers no live-patch path. Enumerate the Windows population first — the packet's primitive is the Windows sentinel handle (the -2 pseudo-handle) being supplied and used without validation while the broker duplicates handles across the renderer-to-broker boundary. Precondition, and it is the important one on this entry: the update removes the escape primitive, it does not evict an attacker who already used it. The packet has ForumTroll operators staging the Dante spyware loader through this chain into the medium-integrity browser/broker context with no user interaction beyond opening the link, so a host whose user opened the lure during the exposure window needs host-level triage; updating that host closes the door behind whatever is already inside it, and an estate that reports 100% on the fixed build has evidence about the primitive, not about residency.",
+        "evidence": "Packet: CWE-501 sandbox escape in Chrome/Chromium on Windows. 'A victim ... visits an attacker-controlled page (delivered via spear-phishing), giving the compromised renderer a reachable path to the Mojo IPC layer. A logic error causes an incorrect/sentinel OS handle (the -2 pseudo-handle) to be supplied and used without validation when the broker process duplicates handles across the renderer-to-broker boundary ... escalates the constrained, sandboxed renderer to arbitrary code execution in the medium-integrity browser/broker context, from which the ForumTroll operators staged the Dante spyware loader — all with no user interaction beyond opening the link.' CISA KEV 2025-03-27, active_exploitation confirmed, CVSS 8.3, RWEP 56, poc_available false. patch_available true, live_patch_available false; live-patch note: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' Cited gaps include AU-Essential-8-Patch, NIST-800-53-SI-2, ISO-27001-2022-A.8.8 and UK-CAF-B4.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet's remediation note defines the interval this control governs in its own words — remediation is the vendor update plus the named compensating controls until it lands, with no live-patch path for this product class. On this entry that interval is unusually exposed, because the trigger is a user opening a link and the packet records the chain completing with no user interaction beyond that: a Chrome/Chromium host waiting on the fixed build is not carrying a reduced-probability version of the risk, it is carrying the full one behind measures that never touch the Mojo handle-duplication path. The requirement here is that such a host be recorded as a distinct, time-bound compensating-control state with an owner and a date — not folded into a 'patched per SLA' percentage — and that the evidence for the remediated state be the build the browser is actually running, since a console reporting the update approved, downloaded or pushed is reporting a deployment step rather than a remediation. Precondition: this control is bookkeeping. It makes the exposure visible and removes none of it, and it is worth attaching precisely because this exposure is the one most likely to be closed on paper: CVSS 8.3 on a browser reads as endpoint hygiene, while the packet records confirmed in-the-wild exploitation delivering a spyware loader. It also says nothing about a host that was already exploited during the window — that host belongs on the incident path regardless of which state the register shows.",
+        "evidence": "Packet: live_patch_available false with the note 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands'; patch_available true. Exploitation requires only that the victim open the attacker-controlled page — 'no user interaction beyond opening the link' — with active_exploitation confirmed and a CISA KEV listing of 2025-03-27. CVSS 8.3 against RWEP 56; poc_available false. Cited gaps include ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-9875": {
     "name": "Sitecore CMS and Experience Platform (XP) Deserialization Vulnerability (post-authentication)",
@@ -33993,7 +34585,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The Junos update repairs the isolation defect and removes nothing that ran through it. What this CVE produces, per the packet, is unsigned code executing inside the memory of a legitimate process on the router while Veriexec — the device's own verified-execution integrity protection — is circumvented, so the artifact a post-incident check normally looks for is precisely what the technique avoids leaving: PIC TINYSHELL backdoors running despite file-integrity controls. Applied to this device, the control means any Junos router where unauthorized root/shell access during the window opened by the 2025-03-13 KEV listing cannot be excluded is dispositioned as compromised rather than upgraded in place — running configuration captured and diffed against the last known-good, the device rebuilt from vendor image at the fixed release, and the credentials the router held or authenticated against rotated. This differs from the pre-authentication perimeter cases in one way that changes scoping and only that: the packet's reachability requirement is an attacker who already holds root/shell and can drop from the Junos CLI into the underlying FreeBSD shell, so the population to disposition is the set of devices where that access cannot be ruled out, not every device on an affected release. The reason for rebuilding is unchanged — the implant predates the update and survives it. Distinguishing test: state what evidence would separate a clean router from one carrying this implant. If the answer is that Veriexec reports no integrity violation or that the on-box file hashes match, the estate's remediation record rests on exactly the assurance the packet says this technique defeats. Precondition: rebuilding removes what is resident on the device and nothing else. It does not address how root/shell was obtained — which the packet does not establish for any given device — so a rebuilt router re-entered through the same credential, jump host or chained flaw returns to the same state, and the rebuild has to be paired with answering that question rather than substituted for it.",
+        "evidence": "Juniper Junos OS improper isolation or compartmentalization (CWE-653). Packet: CISA KEV-listed 2025-03-13, active_exploitation confirmed, RWEP 57 / CVSS 4.4, poc_available false, patch_available true, live_patch_available false (\"No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands\"). Vector: the attacker must already hold high (root/shell) privileges and drop from the Junos CLI into the underlying FreeBSD shell — explicitly not exploitable from the Junos CLI itself — then writes attacker-controlled shellcode into the memory of a legitimate hung process via /proc/<pid>/mem and overwrites the GOT entry for fclose, so triggering EOF executes the loader. This circumvents Junos OS Veriexec verified-execution integrity protection, allowing arbitrary unsigned code (PIC TINYSHELL backdoors) to run despite file-integrity controls, converting existing root shell access into persistent, signature-evading implant execution on the router.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "CVSS 4.4 is low here for a reason that does not reduce the consequence: the packet discounts the score for the precondition — an attacker who already holds root/shell — while the outcome it records is unsigned code running on a production router despite Veriexec. A severity-band remediation queue therefore sorts this Junos defect beneath routine medium findings, which is the specific mechanism by which it goes unremediated on core routing infrastructure. The control's requirement for this entry is that the clock runs from the 2025-03-13 KEV listing and the packet's confirmed in-the-wild exploitation rather than from the CVSS band, and that it runs against devices rather than against tickets: the packet records a vendor patch and no live-patch path for this product class, so the fixed Junos release must actually be carried onto each affected router, and completion is measured by the release the device is running — not by an image staged or a change request raised. Distinguishing test: sort the vulnerability register by severity and find where this CVE lands against the program's SLA tiers. If a 4.4 that CISA lists as exploited inherits a medium-severity window, the program is scoring the exploit's precondition instead of its exposure, and it will do the same to the next low-base-score KEV entry. Precondition: this control governs scheduling only. It gives nothing to a router already carrying the implant the packet describes — that device is dispositioned under the rebuild path, because applying the update to it changes the running release and leaves the resident code in place.",
+        "evidence": "Packet: CISA KEV-listed 2025-03-13 with active_exploitation confirmed; RWEP 57 against CVSS 4.4; poc_available false; patch_available true; live_patch_available false with the note that remediation is the vendor update plus the named compensating controls until it lands. The vector states the low reachability bar is the requirement for pre-existing root/shell and the ability to drop from the Junos CLI into the FreeBSD shell, while the recorded outcome is arbitrary unsigned code executing despite Junos OS Veriexec.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet gives this exploit a required step that is not the memory corruption and that the device records: the attacker must leave the Junos CLI for the underlying FreeBSD shell, because the packet states the flaw is explicitly not exploitable from the Junos CLI itself. Everything after that — the write into a hung process via /proc/<pid>/mem, the fclose GOT overwrite, the unsigned loader — happens on a platform the attacker holds root on, which is also the platform holding the record of the shell transition that preceded it. Bound to this device, the control means Junos syslog and authentication events leave the router for a collector in a separate trust zone with its own credentials and its own authentication path, and that entry into the FreeBSD shell on a production router is an alerting condition there rather than a line read on-box during an investigation. This is the signal that survives the primitive the packet describes: the Veriexec verdict, the on-disk hashes and the local logs are all produced by the compromised platform, whereas a record already shipped off it is not. Distinguishing test: take the FreeBSD shell on a lab router, clear the local log, and confirm the event is still present and alertable on the off-device collector. Precondition: this preserves and surfaces evidence, it prevents nothing, and it covers only the window in which forwarding was already configured and reaching the collector — an attacker at root can stop the device shipping logs from the moment of compromise, so what survives is what shipped before that point, and a router's feed going quiet is itself an event to treat as a signal rather than as a collector fault. It also gives nothing on an estate where administrators enter the FreeBSD shell routinely and the event carries no alert, which is the condition to check before recording this as a detection.",
+        "evidence": "Packet vector: reachability requires a local attacker who already holds root/shell and can drop from the Junos CLI into the underlying FreeBSD shell, and the flaw is explicitly not exploitable from the Junos CLI itself; the subsequent steps are a /proc/<pid>/mem write into a legitimate hung process and a GOT overwrite of fclose, circumventing Junos OS Veriexec so unsigned code runs despite file-integrity controls. CISA KEV-listed 2025-03-13, active_exploitation confirmed, RWEP 57 / CVSS 4.4.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-24993": {
     "name": "Microsoft Windows NTFS Heap-Based Buffer Overflow Vulnerability",
@@ -34474,7 +35098,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "SimpleHelp is a remote-support server and the packet gives the bypass no cost: an unauthenticated remote caller submits an identity token whose cryptographic signature is never verified and receives a fully authenticated technician session, with no user interaction. For this entry the control means the vendor update is driven across every SimpleHelp server instance on the KEV clock that opened 2026-06-29 against a 2026-07-02 due date — a three-day window, not a monthly cycle — with completion measured by each server's running version against the fixed one rather than by an approved change ticket, since the packet places the defect in versions 5.5.15 and prior and in 6.0 pre-release builds. The packet records a vendor patch and no live-patch path, so nothing mitigates a running instance short of taking it through that update. The population to enumerate first is the servers that have OIDC authentication configured: the packet conditions the bypass on that configuration ('When OIDC authentication is configured'), so that enumeration is what bounds the exposed set while the update rolls. Precondition, and it is narrow: taking the OIDC login path out of service removes the stated precondition only on an instance whose technicians hold another login method, it is unavailable where OIDC is the organization's only route into the console, and it does nothing about a session an attacker already holds — the forged token yields the session directly, so an instance that was reachable with OIDC configured during the window belongs on the incident path, not the configuration path. Priority follows the packet rather than the RWEP band: the absence of a public PoC is the only thing holding the score below the CVSS 10 and confirmed-exploitation signals, and it is not a reason to let a three-day due date slip.",
+        "evidence": "Packet: CWE-347; 'SimpleHelp versions 5.5.15 and prior and 6.0 pre-release versions contain an authentication bypass vulnerability in the OIDC authentication flow. When OIDC authentication is configured, identity tokens submitted during login are accepted without verifying their cryptographic signature'; 'a remote, unauthenticated attacker can submit a forged token containing arbitrary identity claims to obtain a fully authenticated technician session'; 'No user interaction is required'; CISA KEV-listed 2026-06-29 (due 2026-07-02) with confirmed in-the-wild exploitation; CVSS 10, RWEP 50, poc_available false; patch_available true, live_patch_available false with the note 'No live-patch path for this product class; remediation is the vendor update ... plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The asset at risk here is not the SimpleHelp server's own files but what a technician session on it can do to the endpoints that server administers, and the packet hands an attacker that session outright: a forged token carrying arbitrary identity claims, accepted without signature verification, and in some configurations without the second factor. Applied to this product, the control means the SimpleHelp installation and every directory it serves artifacts from are file-integrity-monitored, and every technician session in the exposure window is reconciled against a sanctioned administrator action rather than read off the session's own identity — the claims in that session are attacker-chosen, so the username attached to it is not evidence of who opened it. The distinguishing test keys on precisely what the packet describes the exploit producing, a session created from a token the identity provider never issued: list SimpleHelp technician sessions across the window and match each against a sign-in record at the configured OIDC provider; a technician session with no corresponding provider authentication event is the signal, while an authentication log that records only 'technician logged in' shows the forged session as a clean login. This is the control that retains value after the update lands, because the fix restores signature verification and removes nothing that was pushed, run, or created through a session obtained before it. Precondition: this is detection and eviction, not prevention — it does not stop the forged token, only the vendor update does, and the reconciliation depends on session and identity-provider logs retained from before the update. Where those logs have rolled or the server has already been rebuilt, the comparison cannot be made and the endpoints that server administered must be handled as attacker-reachable rather than recorded as clean.",
+        "evidence": "Packet: 'a remote, unauthenticated attacker can submit a forged token containing arbitrary identity claims to obtain a fully authenticated technician session. In some configurations, this may also allow bypass of multi-factor authentication'; 'identity tokens submitted during login are accepted without verifying their cryptographic signature'; CWE-347; active_exploitation confirmed, CISA KEV-listed 2026-06-29; patch_available true, live_patch_available false. Existing inventory entry NEW-CTRL-078 already governs the SimpleHelp server as a privileged distribution channel.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-26633": {
     "name": "Microsoft Windows Management Console (MMC) Improper Neutralization Vulnerability",
@@ -34782,7 +35431,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet names two distinct fixed lines for this defect — the 2024 January-2025 Security Update and the 2022 SU6 January-2025 Security Update — so an estate running both Ivanti EPM branches carries two remediation targets on a single CVE, and the KEV clock covers both. Applied here, the control means the clock runs from the 2025-03-10 KEV listing, against CISA's 2025-03-31 due date on this entry, rather than from the next scheduled EPM maintenance window, and that it is measured by the build each EPM server is actually running rather than by an update approved or downloaded in the console. The packet's combination of confirmed in-the-wild exploitation and a public PoC against a defect that requires no authentication is what removes the usual argument for a longer window on a management server: there is no credential an attacker has to obtain first, so the interval between listing and update is exposure with no other gate on it. Distinguishing test: enumerate every EPM server in service, including any 2022-branch server retained for older agents, and show each is at or above its own branch's January-2025 security update. A remediation record that closes on the 2024-branch core while a 2022 SU6 server keeps serving has not remediated this CVE — the packet lists the two updates separately precisely because neither covers the other. Precondition: the packet records a vendor patch and no live-patch path, so there is no way to close this without carrying each server through its update; and this control governs the schedule only — it does nothing about a read that already succeeded against a server exposed before the update landed.",
+        "evidence": "Ivanti Endpoint Manager (EPM) absolute path traversal (CWE-36); the packet's entry name places it at GetHashForWildcardRecursive. Packet: CISA KEV-listed 2025-03-10 with a 2025-03-31 due date and active_exploitation confirmed; RWEP 73 / CVSS 9.8; poc_available true; patch_available true; live_patch_available false, with the note that remediation is the vendor update plus the named compensating controls until it lands. Vector: absolute path traversal in Ivanti EPM before the 2024 January-2025 Security Update and 2022 SU6 January-2025 Security Update allows a remote unauthenticated attacker to leak sensitive information.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Ivanti EPM is the endpoint-management plane, and this defect sits on one of its request-handling endpoints — the packet's entry name places it at GetHashForWildcardRecursive — where a caller-supplied path selects what gets read. Bound to this product, the control means two properties on that class of endpoint: it authorizes its caller before the supplied path is acted on at all, and it resolves the path and verifies the result lies inside the intended root before the read executes. The second is where an absolute-path defect differs from the case operators usually test for. CWE-36 traverses nothing — the caller names the target outright — so a filter that strips or counts relative segments passes the payload through untouched, and a control described as 'path traversal protection' can be in place and irrelevant. The packet's own summary is that a remote unauthenticated attacker leaks sensitive information, which means the endpoint's own authorization decision is the only thing standing between an untrusted caller and that read; no EPM account is consulted at any point, so an access review of EPM administrators can come back clean while the path is fully open. The deployment-side half of the control is that no EPM server keeps those endpoints reachable from a segment with no operational need to reach them. Distinguishing test: on a staging EPM server, send each path-accepting endpoint an unauthenticated request naming an absolute path outside the intended content root, and confirm it is refused before anything is read — confirming that a ../ payload is rejected does not test this defect. Precondition: caller authorization and path resolution are properties the vendor update establishes; this control states what to verify, not how to implement it. Until the update lands, restricting which segments can reach the server bounds who can send the request and leaves the endpoint fully exploitable to anything inside the permitted segment — and that restriction is unavailable to the extent the server must stay reachable for the estate it manages.",
+        "evidence": "Packet vector: absolute path traversal (CWE-36) in Ivanti EPM before the 2024 January-2025 Security Update and 2022 SU6 January-2025 Security Update allows a remote unauthenticated attacker to leak sensitive information; the entry name locates the defect at GetHashForWildcardRecursive. CISA KEV-listed 2025-03-10 (due 2025-03-31), active_exploitation confirmed, poc_available true, RWEP 73 / CVSS 9.8, patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "A read cannot be undone by an update. The packet's recorded outcome is an unauthenticated remote leak of sensitive information from the endpoint-management server, with exploitation confirmed and a public PoC in circulation, so for any EPM server reachable by untrusted callers before its January-2025 security update landed the operative question is what left it, not whether the build is now current. Applied to this product, the playbook means establishing what the path-accepting endpoint could return on this specific deployment — the packet records that sensitive information is leaked and does not enumerate it, so this is scoping work against the actual server rather than a conclusion to inherit — and then rotating anything in that set that functions as a credential, key or token on the assumption it was retrieved. The reason for assuming rather than confirming is in the packet: the attacker never authenticates, so there is no failed-login trail to search, no account to disable, and no session to trace; the absence of evidence of retrieval is not evidence against it. The fleet half of the playbook applies because of the server's role — rotation scope is set by what the EPM server itself held or could return, which is wider than its own administrator accounts, and building that inventory is a step of the playbook rather than an assumption inside it. Precondition: this addresses disclosure that has already occurred and closes nothing; the vendor update closes the path. It is scoped to servers whose reachability by untrusted callers during the window cannot be excluded, and where request logs covering that window were not retained, the exposure belongs in the risk record as unresolved rather than closed on the version bump.",
+        "evidence": "Packet: absolute path traversal (CWE-36) allowing a remote unauthenticated attacker to leak sensitive information from Ivanti EPM before the 2024 January-2025 Security Update and 2022 SU6 January-2025 Security Update; CISA KEV-listed 2025-03-10 with a 2025-03-31 due date, active_exploitation confirmed, poc_available true, RWEP 73 / CVSS 9.8, patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-57968": {
     "name": "Advantive VeraCore Unrestricted File Upload Vulnerability",
@@ -35116,7 +35797,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "unknown",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Win32k component failing to properly handle objects in memory (CWE-404) and frames the outcome as elevation of privilege, so what this flaw supplies an attacker is the escalation step after a foothold rather than the foothold itself — which makes the remediation window the whole of the defence. For this CVE the control means the Windows update carrying the Win32k fix is driven on the clock that opened with the 2025-03-03 KEV listing and its 2025-03-24 due date, not on the queue position a 2018 CVE with a 7.8 base score earns in a backlog ordered by disclosure date or CVSS band. Enumeration is the hard half here, and it has to follow the packet's own affected list rather than a workstation-only or current-server scope: Windows 7, Windows 8.1, Windows RT 8.1, Windows 10 and Windows 10 Servers alongside Windows Server 2008, Server 2008 R2, Server 2012, Server 2012 R2, Server 2016 and Server 2019 — one defect reaching across essentially every Windows product version an estate is likely to hold. Completion therefore has to be measured as each host's installed build against the fix for that host's own product version; a management console reporting 'update approved' or an estate-level claim of 'supported builds, current rollups' has not answered that question for a single machine. Distinguishing test: produce, per product version named above, the list of hosts and their installed builds and show each carries the fix — an attestation that the estate is patched to policy reads clean while a Server 2008 R2 or Windows 7 host that never took the update stays fully exploitable. Precondition: the packet records a vendor patch and no live-patch path, so a host carries the vulnerable Win32k code until that update is actually installed on it, and the packet's own remediation note is that the named compensating controls are what hold until it lands. This control reduces exposure on no host it cannot enumerate and no host it cannot update.",
+        "evidence": "Packet: \"Microsoft Windows Win32k Improper Resource Shutdown or Release Vulnerability\", CWE-404. Vector: \"An elevation of privilege vulnerability exists in Windows when the Win32k component fails to properly handle objects in memory, aka 'Win32k Elevation of Privilege Vulnerability.' This affects Windows 7, Windows Server 2012 R2, Windows RT 8.1, Windows Server 2008, Windows Server 2019, Windows Server 2012, Windows 8.1, Windows Server 2016, Windows Server 2008 R2, Windows 10, Windows 10 Servers.\" CISA KEV-listed 2025-03-03 (due 2025-03-24), active_exploitation confirmed. CVSS 7.8, RWEP 79. patch_available true; live_patch_available false, with the packet's note that remediation is the vendor update plus the named compensating controls until it lands.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "The packet gives a public PoC, confirmed in-the-wild exploitation, and no live-patch path, so every affected host has an interval between the 2025-03-03 KEV listing and the moment the vendor update is installed on it during which detection is the only lever the operator holds — the packet's own remediation note names compensating controls as what covers that interval. Key the rule on the behaviour the packet actually documents: Win32k mishandling objects in memory to elevate privilege means the observable event is a process acquiring privileges it did not start with, i.e. a token or integrity-level transition on an already-running process that did not originate from a service start, a scheduled-task launch, or an interactive elevation. Do not key it on process crashes or on exploit-tool file signatures — an exploit doing exactly what this packet describes produces the privilege transition and need not produce either, so a rule built on those signals misses it. Distinguishing test: on a staging host of one of the Windows product versions the packet names, cause a standard-user process to acquire SYSTEM privileges and confirm the rule fires on the token transition itself rather than on the tool that produced it. Two preconditions, both load-bearing. First, this detects and does not prevent: it bounds dwell time on a host that remains fully exploitable, and it yields nothing on a host with no sensor deployed. Second, the flaw's end state is kernel-level privilege, and that same privilege lets an attacker stop or blind a host-resident sensor — so the alert has to reach a collector off the host, and a sensor going quiet has to alarm on its own rather than read as a clean host.",
+        "evidence": "Packet: vector \"An elevation of privilege vulnerability exists in Windows when the Win32k component fails to properly handle objects in memory\"; CWE-404; poc_available true; active_exploitation confirmed; CISA KEV-listed 2025-03-03; live_patch_available false with live_patch_notes \"No live-patch path for this product class; remediation is the vendor update ... plus the named compensating controls until it lands.\"; RWEP 79, CVSS 7.8.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-43769": {
     "name": "Hitachi Vantara Pentaho BA Server Special Element Injection Vulnerability",
@@ -35257,7 +35961,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The packet puts the defect inside the Pentaho BA Server's own authorization decision: the server's security restrictions are expressed against URL paths, and a non-canonical form of the same path circumvents them (CWE-647). The restriction layer and the resource that ultimately serves the request disagree about which path was asked for, and the resource serves it anyway — the configuration is not what fails, the matching of a request to that configuration is. Bound to this product, the control means every resource sitting behind those restrictions makes its own authorization decision, after the path has been canonicalized, instead of inheriting a verdict from the URL-pattern layer fronting it; and the BA Server's HTTP surface answers only from segments with an operational need to reach it. Distinguishing test: on a staging BA Server, request each restricted resource in path forms that differ from its canonical form and confirm each is refused by the resource itself before it acts — a review-based attestation that the server's security restrictions are defined and approved passes cleanly while this path stays open, because the restriction set is intact and simply never matched. Precondition: canonicalization-before-authorization is a property the vendor release supplies; this control states what to verify, it does not implement it. Until an instance is on 9.4.0.1 or 9.3.0.2 — the fixed versions the packet names — restricting which segments can reach the server bounds who is able to send a non-canonical request but leaves the decision itself broken for every caller inside the permitted segment, and that restriction is unavailable wherever the server has to remain reachable by its normal user population.",
+        "evidence": "Packet: \"Hitachi Vantara Pentaho BA Server Authorization Bypass Vulnerability\", CWE-647. Vector: \"Hitachi Vantara Pentaho Business Analytics Server versions before 9.4.0.1 and 9.3.0.2, including 8.3.x contain security restrictions using non-canonical URLs which can be circumvented.\" CISA KEV-listed 2025-03-03 (due 2025-03-24), active_exploitation confirmed, poc_available true. CVSS 8.6, RWEP 65. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry is not the disclosure date. The packet records a 2022 CVE that CISA listed on 2025-03-03 with a 2025-03-24 due date, confirmed in-the-wild exploitation and a public PoC — so a queue ordered by CVE age, or by an 8.6 base score filed below that month's criticals, puts it behind work that matters less. Two things make the SLA product-specific here. First, the defect is in an application: the framework gap cited on this entry is 'Patch operating systems', and an OS-patch attestation never reports on a Pentaho BA Server at all, so the SLA has to be owned by whoever tracks the analytics platform rather than by the OS-patching cadence. Second, the SLA has to be satisfiable by something other than the upgrade for part of the estate, because the upgrade is not always a maintenance window: the packet names 9.4.0.1 and 9.3.0.2 as the fixed versions and names 8.3.x among the affected, so an 8.3.x deployment has no fixed release on its own branch and reaches remediation only by moving branches — a migration project, not a patch. For that population the control's 'documented compensating controls' arm is the load-bearing one, and what it has to document is which callers can reach the BA Server's HTTP surface, carried on a dated commitment to the version move rather than an open-ended risk acceptance. Precondition: that reachability restriction bounds the population able to send a crafted request; it does not repair the authorization decision, so any caller legitimately inside the permitted segment still reaches the circumventable path, and the packet records no live-patch route for this product class — the vendor release is the only thing that closes it.",
+        "evidence": "Packet: CISA KEV-listed 2025-03-03 (due 2025-03-24) with active_exploitation confirmed and poc_available true; CVSS 8.6, RWEP 65; vector names fixed versions 9.4.0.1 and 9.3.0.2 and names 8.3.x among affected versions; product is Hitachi Vantara Pentaho Business Analytics Server; patch_available true, live_patch_available false with live_patch_notes \"No live-patch path for this product class; remediation is the vendor update ... plus the named compensating controls until it lands.\"; the citing framework gap AU-Essential-8-Patch is recorded with control text \"Patch operating systems\".",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-20118": {
     "name": "Cisco Small Business RV Series Routers Command Injection Vulnerability",
@@ -35841,7 +36568,40 @@
         "adequate": false,
         "gap": "Security-of-processing obligations are undermined when embedded API keys/credentials inside a 'flow' are exfiltratable by any authenticated user of the same multi-tenant deployment."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-106",
+        "name": "AI-APP-API-OBJECT-AUTHORIZATION-AND-FIELD-EXPOSURE",
+        "description": "The packet describes both halves of this control failing on the same platform. The read half: an authenticated low-privilege attacker enumerates flow UUIDs through /api/v1/flows/, so the listing endpoint returns object identifiers belonging to other accounts instead of scoping the query to the caller's own flows. The act half: /api/v1/responses accepts a caller-supplied flow ID and runs it without checking that the caller owns it (CWE-639) — the user-controlled key is the authorization decision. Bound to Langflow, the requirement is that every endpoint taking a flow ID scopes it to the calling account before doing anything with it, and that listing endpoints return only the caller's own objects, so possession of a UUID never grants anything. The distinguishing test is the packet's own attack path run deliberately: on a staging instance with two ordinary accounts, list flows as account A and confirm B's flow IDs do not appear, then submit a known B flow ID to /api/v1/responses as A and confirm it is refused before the flow runs. This is also why the identity and access-control attestations recorded against this entry pass while the flaw is fully exploitable — the attacker holds a genuine Langflow account and authenticates normally, so unique accounts, role assignment and login controls are all exercised as designed; nothing in that model is consulted for an object whose ownership the API never checks. Precondition and aftermath: the ownership check is what the 1.9.1 release the packet names supplies, and until an instance is on it the only operator lever is reducing who holds an account on a shared instance at all — which does not help against an account that is legitimately there. And because the packet describes the executed flow carrying its owner's embedded credentials, with 'leak api keys' as the injected instruction, any instance that ran multi-user before the upgrade must treat every credential embedded in a flow as exposed and rotate it. Upgrading closes the path; it does not un-disclose a key already read out.",
+        "evidence": "Packet: \"Langflow Authorization Bypass Through User-Controlled Key Vulnerability\", CWE-639. Vector: \"Prior to 1.9.1, an Insecure Direct Object Reference (IDOR) vulnerability in /api/v1/responses endpoint allows an authenticated attacker to execute any flow belonging to another user by specifying the victim's flow ID in the request. This vulnerability is fixed in 1.9.1.\" Attack vector: \"An authenticated low-privilege attacker enumerates flow UUIDs via /api/v1/flows/, then submits a victim's flow ID to /api/v1/responses along with an injected instruction (e.g. 'leak api keys'), causing the platform to execute the victim's flow — including any embedded credentials — under the attacker's control.\" CISA KEV-listed 2026-07-07, active_exploitation confirmed, poc_available true. CVSS 8.4, RWEP 65. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B2",
+          "GDPR-Art32"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-103",
+        "name": "AI-APP-BUILDER-EXECUTION-ENDPOINT-AUTH-AND-SANDBOX",
+        "description": "Langflow is the product class this control governs, but this entry exercises its second half rather than its first: /api/v1/responses is an authenticated endpoint and the packet's attacker holds a valid low-privilege account, so 'authenticate every endpoint that can reach a code-execution path' is already satisfied and contributes nothing here. What the packet describes is the run path itself — the platform executes the flow graph including any credentials embedded in it, and the attacker supplies an instruction ('leak api keys' is the packet's own example) that the run then carries out. Bound to this deployment, the requirement is that a flow run is confined to the capability the requesting principal is entitled to rather than to whatever the flow's owner accumulated: request-supplied instruction text must not be able to drive the run into filesystem access, network egress or credential reads that the flow's declared purpose does not need, and credentials a flow uses should be resolved at execution time from a store bound to the entitled principal rather than held inline in the graph where any execution of it hands them over. This is the least-privilege lever on this entry, and it is worth stating why the privilege model that already exists does not provide it: the flow runs with its owner's accumulated capability regardless of who asked for the run, so per-account privilege scoping is never the thing that decides what the execution can reach. Distinguishing test: on a staging instance, run a flow holding a provider key with an appended instruction to emit that key, and confirm the key does not appear in the response. Precondition, and it is the decisive one: confinement bounds what an instruction achieves once a run has started — it does not decide who may start a run against whose flow, which is the actual defect and is closed by the object-authorization control on this entry and by the 1.9.1 release the packet names. No sandbox can withhold from a flow the credentials its own steps legitimately need, so this is a damage-bounding measure, never the fix.",
+        "evidence": "Packet: attack vector states the attacker is \"authenticated low-privilege\" and submits a victim's flow ID \"along with an injected instruction (e.g. 'leak api keys'), causing the platform to execute the victim's flow — including any embedded credentials — under the attacker's control\"; product is Langflow, \"a tool for building and deploying AI-powered agents and workflows\"; fixed in 1.9.1; CWE-639; CVSS 8.4; active_exploitation confirmed; poc_available true; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-033",
+        "name": "AI-ML-DEVELOPER-TOOLING-INVENTORY",
+        "description": "The patch gap cited against this entry reads 'Patch operating systems', and that is the problem in one line: Langflow is a self-hosted agent-and-workflow builder, not an operating system, so an estate whose patch attestation covers OS builds never reports on it at all — the 2026-07-07 KEV listing lands against software that no OS-patching cadence, and frequently no software inventory, has ever enumerated. Applied here, the control requires Langflow instances to appear in a developer-tooling inventory in their own right, each row carrying the instance's exposed endpoints, who holds accounts on it, the running version measured against the 1.9.1 fixed release the packet names, and — the field that matters most for this CVE — a blast-radius entry recording which provider credentials are embedded in flows on that instance. The packet's attack converts one ordinary account into execution of any other user's flow with that flow's credentials, so blast radius on a shared instance is every key any user has embedded in it, and that figure is only knowable if someone wrote it down before the incident. Distinguishing test: ask for the list of Langflow instances in the estate with their versions and their per-instance embedded-credential inventory; if the answer has to be assembled by polling teams, that is the finding, because it is the same answer the operator will need under time pressure to scope key rotation after an exposure window. Precondition: an inventory reduces no exposure by itself. It is what makes the upgrade to 1.9.1 and the post-exposure rotation reach every instance rather than the ones the security team already knew about, and it is worth nothing for an instance a team stood up outside the process that maintains it.",
+        "evidence": "Packet: product is Langflow, \"a tool for building and deploying AI-powered agents and workflows\"; fixed in 1.9.1; CISA KEV-listed 2026-07-07 with active_exploitation confirmed; the executed flow includes \"any embedded credentials\" and the injected instruction example is \"leak api keys\"; the attacker is an authenticated low-privilege account on the same instance; patch_available true, live_patch_available false; the citing framework gap AU-Essential-8-Patch is recorded with control text \"Patch operating systems\".",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2026-48908": {
     "name": "JoomShaper SP Page Builder Unrestricted Upload of File with Dangerous Type Vulnerability",
@@ -36174,7 +36934,28 @@
         "adequate": false,
         "gap": "Least-privilege control is undermined because the flaw is reachable by any admin-privileged account — a compromised or over-provisioned VoIP admin credential is sufficient to pivot to full command execution."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The Mitel phone's administrative management interface is the constrained user surface this control governs. The packet places the defect in a boot-process parameter the product fails to sanitize, and describes an attacker who already holds administrative privilege on that interface injecting shell metacharacters to escape the parameter context and execute arbitrary commands in the phone's underlying OS — a device-configuration surface wired straight through to an OS command context, which is the pattern the control forbids. Bound to this product, it means a value an administrator sets on a 6800, 6900 or 6900w Series handset or the 6970 Conference Unit is consumed by the boot process as data and never reaches a command interpreter, so that a phone-administration role stays a configuration role instead of becoming a shell on the handset. This is also why the least-privilege control cited as insufficient on this entry does not cover the path: the attacker uses a legitimate administrative account, so per-account privilege scoping is never the thing that fails — the failure is that the administrator role, correctly held, reaches arbitrary command execution. Preconditions: the vendor firmware update that moves a handset past the affected range is what repairs that boundary; this control states the property to verify, it does not implement it. Until that update lands on a given handset, the only operator-side lever is limiting which accounts and which network segments can reach the phones' management interface — that bounds who can present the injected parameter but does not close the path, because any account that legitimately administers a phone still reaches it, and it gives nothing at all once an administrator credential is in an attacker's hands. And because exploitation is confirmed, a handset whose management interface was reachable during the exposure window needs its running configuration compared against a known-good baseline rather than being closed on the update: commands that already executed in the phone's system context are not undone by loading new firmware.",
+        "evidence": "Packet vector: a vulnerability in the Mitel 6800 Series, 6900 Series and 6900w Series SIP Phones, including the 6970 Conference Unit, through R6.4.0.HF1 (R6.4.0.136), could allow an authenticated attacker with administrative privilege to conduct an argument injection attack due to insufficient parameter sanitization during the boot process, with a successful exploit allowing execution of arbitrary commands within the context of the system (CWE-88). Packet attack_vector: the attacker already holds administrative access to the phone's management interface and injects shell metacharacters into a boot-process parameter to escape the intended parameter context. CISA KEV-listed 2025-02-12 with active_exploitation confirmed; poc_available true; RWEP 64 against CVSS 7.2. The packet records NIST-800-53-AC-6 (Least Privilege) and ISO/IEC 27001:2022 A.8.9 (Configuration management) among the framework controls already cited as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the expedited clock runs from the 2025-02-12 KEV listing, and the population it has to be measured against is the handsets themselves: every 6800, 6900 and 6900w Series phone and every 6970 Conference Unit whose running load falls in the affected range the packet names, through R6.4.0.HF1 (R6.4.0.136). Completion has to be counted per device against its reported firmware load, not as a site-level or platform-level statement that the phones were updated — a telephony estate is distributed across sites and the individual handset is precisely the asset class a server-and-workstation patch program has no row for, so an SLA measured on anything coarser than the per-device load will report green over handsets still running affected firmware. The distinguishing test: enumerate the handsets and conference units in service and confirm none reports a load at or below R6.4.0.HF1 (R6.4.0.136); a device absent from that enumeration is unmeasured, not compliant. Preconditions and limits: the packet records a vendor patch and registers no live-patch path, so the firmware update itself is the only remediation available — there is nothing to apply to a running handset in the meantime. Where a handset cannot be taken to the fixed load inside the window, the control's compensating-control branch must be written down explicitly rather than assumed, and for this flaw the honest compensating control is restricting which accounts and segments can reach the management interface; that bounds who can attempt the injection, it does not remove the unsanitized boot parameter, and it does not help where the administrative credential is already compromised.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2025-02-12; active_exploitation confirmed; poc_available true; patch_available true; live_patch_available false with no live-patch notes recorded for this entry; RWEP 64 against CVSS 7.2. Affected range from the packet vector: Mitel 6800 Series, 6900 Series and 6900w Series SIP Phones, including the 6970 Conference Unit, through R6.4.0.HF1 (R6.4.0.136). The packet cites EU NIS2 Directive Art. 21 vulnerability handling as a framework control insufficient for this entry.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-21418": {
     "name": "Microsoft Windows Ancillary Function Driver for WinSock Heap-Based Buffer Overflow Vulnerability",
@@ -36537,7 +37318,28 @@
         "adequate": false,
         "gap": "Least-functionality/secure-configuration baselines should prevent a signed executable from loading DLLs out of a user-writable application directory; safe DLL search-order hardening wasn't applied."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The vulnerable executable here is not something an operator installs by name. The packet identifies mDNSResponder.exe as part of Audinate's Dante Application Library for Windows, so the binary an attacker abuses arrives on a Windows host as a component of whatever product embeds that library, under that product's name in the installed-software list. Applied to this CVE, the control means the software inventory and SBOM carry the Dante Application Library and the mDNSResponder.exe it installs as components in their own right — each with its own version and its own fix state, recorded separately from the product that shipped them — because a remediation program that enumerates only installed applications has no row to act on when the KEV entry names the library rather than the application. Scope this to what the packet establishes: locate copies of that named library and executable. The packet ties the defect to mDNSResponder.exe improperly specifying how, and from which folder, it loads a DLL, and to a malicious dal_keepalives.dll dropped in that executable's own application directory; it provides no mapping of the defect into other signed binaries, so treating every DLL-loading signed executable in the estate as an instance of this CVE would manufacture findings against software no evidence implicates. The distinguishing test: search the estate's Windows hosts for mDNSResponder.exe on disk and reconcile every hit against an inventory record naming the Dante Application Library and its version; hits with no matching record are exactly the population the flaw-remediation process cannot currently reach, and they will not appear on any patch report. Precondition and limit: an inventory locates the component, it does not remediate it. The packet records that a vendor patch exists, so each located copy still has to be carried to the fixed library; a copy installed by software that is not under management is remediated by removing that software, not by recording the component as inventoried.",
+        "evidence": "Packet vector: mDNSResponder.exe is vulnerable to DLL sideloading — the executable improperly specifies how to load the DLL, from which folder and under what conditions, so a malicious attacker can use the valid and legitimate executable to load malicious files (CWE-114, CWE-426). Packet attack_vector: an attacker with local access places a malicious dal_keepalives.dll in the application directory of the legitimate, signed mDNSResponder.exe, part of Audinate's Dante Application Library for Windows; the trusted binary then loads the attacker's DLL and executes code in the context of the trusted process. CISA KEV-listed 2025-02-06 with active_exploitation confirmed; patch_available true; RWEP 40 against CVSS 7.8. The packet cites EU NIS2 Art. 21 supply chain security measures and NIST SP 800-53 SI-2 (Flaw Remediation) among the framework controls insufficient for this entry.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case the control's 'whichever is later' wording exists for. The CVE identifier is from 2022 and the packet records a vendor patch as available, but the KEV listing — and with it the evidence of confirmed in-the-wild exploitation — did not arrive until 2025-02-06. A risk-based vulnerability-management cycle that triaged this at disclosure saw a local-access DLL sideload with no public proof-of-concept, which is precisely the profile such a cycle files below its action threshold and never revisits; the packet still carries poc_available false today, so a triage weighted on public exploit code would deprioritize it while it is in fact being exploited. Applied to this product, the control means the KEV listing date reopens the item and starts an expedited clock over every located copy of the Dante Application Library and its mDNSResponder.exe, with the verified state being the library version present on each host rather than the currency of the application that bundled it. Preconditions and limits: the packet registers no live-patch path, so there is no interim fix to apply — a copy is either carried to the fixed library or it is exposed. Where that cannot happen inside the window, the control's compensating-control branch has to be documented rather than implied, and for this flaw the defensible compensating control follows directly from the packet's own exploitation step: constrain write access to mDNSResponder.exe's application directory so that no identity other than one performing a vendor update can place a DLL there. State its bounds honestly — it does nothing on a host where the attacker already holds the privilege needed to rewrite that directory or its permissions, and it does not remove a dal_keepalives.dll planted before the restriction was applied, so a host that ran the vulnerable configuration during the exposure window needs that directory's contents compared against the vendor's file set rather than being closed on the update.",
+        "evidence": "Packet fields: cve id CVE-2022-23748 with cisa_kev true and kev_date 2025-02-06; active_exploitation confirmed; poc_available false; patch_available true; live_patch_available false with no live-patch notes recorded; RWEP 40 against CVSS 7.8. Packet attack_vector establishes the exploitation step as an attacker with local access placing a malicious dal_keepalives.dll in the application directory of the legitimate, signed mDNSResponder.exe. The packet cites ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) among the framework controls insufficient for this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2020-29574": {
     "name": "CyberoamOS (CROS) SQL Injection Vulnerability",
@@ -36705,7 +37507,38 @@
         "adequate": false,
         "gap": "Essential Eight patch-OS timelines are typically prioritized by remote exploitability; physical-access LPE bugs used in real device-seizure scenarios need equivalent urgency."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The vulnerable code is uvcvideo's descriptor parsing: uvc_parse_format does not skip frames of type UVC_VS_UNDEFINED, and frames of that type were never counted when uvc_parse_streaming sized the frames buffer, so a crafted UVC device presented to a host drives an out-of-bounds kernel write while the host enumerates it. Bound to this driver, least functionality means splitting the estate by whether uvcvideo has any business function: on servers, virtual machines, appliances and fixed-function hosts that never use a webcam, uvcvideo belongs on a modprobe blacklist so presenting a USB video-class device does not autoload the vulnerable parser, and the loaded-module inventory is what identifies which hosts those are. Precondition, and this is where the control is routinely over-claimed: a blacklist only suppresses autoload. It does nothing on a host where the video class is built into the kernel image rather than built as a module, and nothing on a host where uvcvideo is already loaded — that module has to be unloaded, or the host has to be running the patched kernel, before the blacklist entry means anything. Where uvcvideo cannot be removed because the host genuinely uses a camera, the remaining lever is device authorization: refuse enumeration of USB devices that are not already authorized, so an attacker-presented device never reaches uvc_parse_format. The packet's access condition includes emulated or virtual device presentation, so an argument that the host's physical ports are inaccessible does not by itself remove the path on a virtualized host.",
+        "evidence": "The packet's vector is the upstream fix text: 'media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format', stating that out-of-bounds writes arise because frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. The recorded attack path is an attacker with physical (or emulated/virtual) access presenting a malicious or specially crafted UVC device, with the mis-sized frame buffer causing an out-of-bounds kernel write leveraged for privilege escalation. NIST SP 800-53 CM-7 Least Functionality and UK CAF B4 System security are among the framework controls this entry already cites as insufficient. CWE-787; CISA KEV-listed 2025-02-05 with active_exploitation confirmed; CVSS 7.8, RWEP 51; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "The packet records no public PoC for this flaw, so there is no exploit-tool signature to match and detection has to key on the behaviour the packet actually describes: a UVC device being presented to the host, uvcvideo parsing its format and frame descriptors during enumeration, and an out-of-bounds kernel write leveraged for privilege escalation. The rule is therefore a pairing, not a single event — a kernel device-enumeration event binding uvcvideo to a newly presented USB video-class device, correlated within a short window against a process on that host acquiring root/uid 0 or new capabilities without passing a sanctioned setuid or service-manager path. Take the attach half of the signal from the kernel's own enumeration events rather than from physical-port or badge-style monitoring, because the packet's access condition explicitly includes emulated and virtual device presentation, which produces no physical event to observe. Limits worth stating rather than leaving implied: this is an after-the-fact control — it surfaces the attempt and shortens dwell time, it does not prevent the write — and on hosts that legitimately use cameras the attach event is routine, which is exactly why the alarm must be the attach-plus-privilege-transition pairing and not either half alone. Anti-malware scanning, which is the control this entry cites as insufficient, has no view of either half: nothing is written to disk and no file is scanned.",
+        "evidence": "The packet describes an attacker with physical (or emulated/virtual) access presenting a malicious or specially crafted UVC device, the uvcvideo driver mis-sizing its frame buffer for UVC_VS_UNDEFINED frame types, and an out-of-bounds kernel write (CWE-787) that can be leveraged for privilege escalation. poc_available is false. ISO/IEC 27001:2022 A.8.7 Protection against malware is recorded as one of the framework controls insufficient for this entry. CISA KEV-listed 2025-02-05, active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Two distinct states on this entry are invisible to a version-based scan. First, the packet records a vendor patch with live_patch_available false, so the fixed uvc_parse_format is not in effect on a host until the patched kernel is the kernel actually running — an inventory field showing a patched kernel package installed does not establish that, and the gap between the two is exactly where a fleet reports itself remediated while still running the vulnerable parser. Second, on hosts whose recorded mitigation is the uvcvideo blacklist rather than the patch, no kernel version number describes that state at all, so the scan reports on something other than the thing protecting the host. The scan therefore has to answer both questions: is the running kernel at or past the build carrying this fix, and on every host where the mitigation of record is 'uvcvideo disabled', is uvcvideo genuinely absent when a USB video-class device is attached. Distinguishing test, keyed to the real exploit trigger rather than a stand-in: attach a USB video-class device to a host recorded as mitigated and read the loaded-module list. If uvcvideo binds, the mitigation exists on paper only and the parser is reachable, while a scan that cleared the host from package metadata never looked at the surface that mattered.",
+        "evidence": "patch_available true and live_patch_available false are recorded on this entry, with no live-patch note. The defect is in uvcvideo descriptor parsing (uvc_parse_format / uvc_parse_streaming frame-buffer sizing) reached by presenting a crafted UVC device. ASD Essential Eight 'Patch operating systems' and EU NIS2 Article 21 vulnerability handling are both recorded as framework controls insufficient for this entry. CISA KEV-listed 2025-02-05, active_exploitation confirmed, CVSS 7.8, RWEP 51.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-45195": {
     "name": "Apache OFBiz Forced Browsing Vulnerability",
@@ -36747,7 +37580,30 @@
         "adequate": false,
         "gap": "Given a near-1.0 EPSS score, Essential Eight's most urgent patch-applications timeline (extreme-risk, days) was necessary but adoption still lagged for many self-hosted OFBiz instances."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "OFBiz's view-controller is where this product makes its authorization decision, and the CVE is that decision being skipped rather than being made wrongly: the packet describes an unauthenticated attacker directly requesting a view-controller endpoint — forced browsing, CWE-425 — that bypasses OFBiz's view-authorization checks, and then reaching the file-import functionality sitting behind it to plant and execute a malicious server-side file for full remote code execution. Bound to this product, the control means the functions behind those endpoints authorize their caller themselves instead of inheriting a verdict from the view-controller mapping that fronts them, with the file-import path first in line because that is the specific function the packet shows converting a missed authorization check into code execution on the server; and it means an instance's back-office surface is segmented so an untrusted caller cannot present the request at all. This is why the identity-and-access and access-enforcement controls cited as insufficient here do not touch the path: the attacker never authenticates as any OFBiz user, so no account, role or permission is ever consulted, and an attestation that every OFBiz user authenticates and is least-privileged passes cleanly while the endpoint stays reachable. The distinguishing test: from a segment with no operational need for OFBiz's back-office functions, issue unauthenticated requests directly to each view-controller endpoint on a staging instance — every endpoint capable of writing a file to the server especially — and confirm each is refused before the function executes, rather than confirming only that the login screen appears for the normal navigation route. Precondition: endpoint-side authorization is a property the 18.12.16 release establishes inside the product; this control states what to verify and what to segment, it does not implement it. Segmentation bounds which callers can reach the endpoint and closes nothing for anything inside the permitted segment, and it is unavailable wherever the instance must remain reachable from untrusted networks for normal operation.",
+        "evidence": "Packet vector: Direct Request ('Forced Browsing') vulnerability in Apache OFBiz, affecting versions before 18.12.16, with users recommended to upgrade to version 18.12.16 (CWE-425). Packet attack_vector: an unauthenticated attacker directly requests a view-controller endpoint that bypasses OFBiz's view-authorization checks, then abuses the reachable file-import functionality to plant and execute a malicious server-side file for full remote code execution. CISA KEV-listed 2025-02-04 with active_exploitation confirmed; poc_available true; patch_available true; RWEP 72 against CVSS 7.5. The packet cites UK NCSC CAF v3.2 B2 (Identity and access control), NIST SP 800-53 AC-3 (Access Enforcement) and ISO/IEC 27001:2022 A.8.9 (Configuration management) among the framework controls insufficient for this entry.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-3",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation path does not stop at code execution — it ends with a malicious server-side file planted on the OFBiz host and executed, under confirmed in-the-wild exploitation with a public proof-of-concept. Upgrading to 18.12.16 removes the forced-browsing route into the file-import function; it deletes nothing already written through that route and invalidates nothing the executed code obtained. Applied to this product, the control means an OFBiz instance that could be reached by an unauthenticated caller during the exposure window is handled as a suspected compromise rather than as a patch ticket: preserve the instance's state for analysis before changing it, compare the deployed application tree against a known-good build to surface files no deployment produced, rebuild the instance rather than upgrading in place where such a file is found, and treat every credential held in the instance's configuration as exposed and rotate it, since code running on the host reads whatever the OFBiz process can read. Preconditions and limits: this is the incident-response branch, not a replacement for remediation — the packet records a vendor fix at 18.12.16 and no live-patch path, so the instance must still reach that release either way. The branch is conditioned on unauthenticated reachability during the window, which has to be demonstrated from the network's actual paths rather than asserted from 'OFBiz is internal'; an instance that genuinely could not be reached without a credential does not need the rebuild. And the rebuild is bounded by the quality of the known-good build it restores from — restoring an image that already contained a planted file reinstates it.",
+        "evidence": "Packet attack_vector: after bypassing OFBiz's view-authorization checks, the attacker abuses the reachable file-import functionality to plant and execute a malicious server-side file for full remote code execution. Packet fields: cisa_kev true with kev_date 2025-02-04; active_exploitation confirmed; poc_available true; patch_available true; live_patch_available false with no live-patch notes recorded; RWEP 72 against CVSS 7.5. Packet vector names 18.12.16 as the release users are recommended to upgrade to. The packet cites ASD Essential Eight patching and EU NIS2 Art. 21 vulnerability handling among the framework controls insufficient for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-29059": {
     "name": "Microsoft .NET Framework Information Disclosure Vulnerability",
@@ -36789,7 +37645,38 @@
         "adequate": false,
         "gap": "Essential Eight application-hardening guidance calls for removing/disabling legacy, high-risk application features such as BinaryFormatter-based .NET Remoting."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The packet's chain has two legs and only the first rides HTTP: a crafted HTTP request to a .NET Remoting-over-HTTP endpoint returns a serialized ObjRef URI, and the attacker then opens a raw remoting channel to what that reference names and drives it into unsafe deserialization for code execution. That second leg is what this control governs on a .NET application server — a remoting channel that answers before any application authentication and whose object-reference handling is itself the vulnerable code, so the web-tier controls a .NET app server is normally audited against see the first request and never see the channel the exploit actually lands on. Bound to this product, the requirement is to enumerate which .NET applications in the estate still register a remoting endpoint at all, remove the registration where the hosted application no longer depends on it, and where it must stay, restrict the remoting channel to the hosts that legitimately speak it by host firewall or network ACL rather than inferring safety from the server sitting on an internal network. Distinguishing test: from a general user or workstation segment on a staging deployment, send a request to each .NET application's remoting endpoint and confirm it is dropped before the endpoint answers — an application that passes a web-tier hardening review while its remoting channel answers from any internal segment is still reachable by the packet's chain. Precondition: this bounds who can request the ObjRef; it does not repair the error handling that discloses it or the deserialization at the end of the chain, so any host inside the permitted segment reaches the full chain and a compromised workstation with a legitimate path to the app server satisfies the packet's precondition in full. The packet records a vendor patch and no live-patch path, so each affected host still has to be taken through the update — this is a holding measure for the window before that, not a closure.",
+        "evidence": "Packet attack_vector: an attacker sends a crafted HTTP request to a vulnerable .NET Remoting-over-HTTP endpoint to leak a serialized ObjRef URI, then uses that reference to open a raw remoting channel and trigger unsafe deserialization for remote code execution. Product: Microsoft .NET Framework Information Disclosure Vulnerability; cwe_refs CWE-209. cisa_kev true, kev_date 2025-02-04, active_exploitation confirmed, poc_available true, cvss 7.5, rwep_score 73. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The chain the packet describes does not end at the disclosure — the leaked ObjRef is the address of a remoting channel, and what makes the leak fatal is that the channel then deserializes whatever the attacker sends it. For this CVE the control means treating that .NET Remoting channel as a trust boundary rather than an internal convenience: the channel authenticates its peer instead of serving any caller that knows the object reference, and what an inbound remoting message is permitted to construct is constrained rather than left to a formatter that instantiates whatever types the payload names. Remediating this as 'an information leak' — suppressing the error detail and moving on — leaves the exploitable half of the packet's chain in place for the next object reference an attacker obtains by another route. The user-application-hardening control cited as insufficient on this entry governs the browser, document-reader and plug-in surface on user endpoints; there is no user application anywhere in this path, the exploited surface is a server-side remoting channel, which is why that attestation passes cleanly while this chain stays open. Distinguishing test: on a staging instance, open a remoting channel from an unauthenticated host and send a message carrying an object graph the application never legitimately receives, and confirm the peer is rejected before the content is deserialized. Precondition: peer authentication and type constraint on the channel are properties of how the application configures and consumes .NET Remoting — this control states what to verify and does not implement it, and it gives an operator nothing on an application whose remoting configuration they do not control. The packet records a vendor patch with no live-patch path, so the update remains the remediation for the disclosure primitive itself.",
+        "evidence": "Packet attack_vector: the leaked ObjRef URI is used to open a raw remoting channel and trigger unsafe deserialization for remote code execution; the initial leak is a crafted HTTP request against a .NET Remoting-over-HTTP endpoint (CWE-209). poc_available true, active_exploitation confirmed, cisa_kev true (2025-02-04), cvss 7.5, rwep_score 73. patch_available true, live_patch_available false. The entry's citing gaps record AU-Essential-8-App-Hardening (User application hardening) as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry reaches a vulnerability-management queue labelled an information-disclosure flaw with a 7.5 base and a confidentiality-only shape, which sorts it below the code-execution items in the same cycle — while the packet's own vector ends in remote code execution, carries a public PoC and is KEV-listed with confirmed in-the-wild exploitation. For this CVE the control means the .NET Framework update is driven on the KEV clock that opened 2025-02-04 rather than on the severity band the CVE title implies, with completion measured by the framework build installed on each host rather than by an update marked approved or downloaded in a management console. Hosts running a .NET application that registers a remoting endpoint are the population to enumerate first, because the packet's precondition is a reachable remoting endpoint and nothing the user does. Precondition and residual: the packet records a vendor patch and no live-patch path, so a host is not remediated until it has actually taken the update; and because exploitation is confirmed and the chain ends in code execution, a host whose remoting endpoint was reachable during the exposure window belongs on the incident path rather than being closed on the patch — the update stops the disclosure, it does not remove anything an attacker already executed through the channel.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-02-04, active_exploitation confirmed, poc_available true, rwep_score 73 against cvss 7.5. attack_vector ends in remote code execution via unsafe deserialization on the remoting channel, while the entry name is 'Microsoft .NET Framework Information Disclosure Vulnerability' (CWE-209). patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2018-9276": {
     "name": "Paessler PRTG Network Monitor OS Command Injection Vulnerability",
@@ -37199,7 +38086,40 @@
         "adequate": false,
         "gap": "The Node.js websocket module's local_access_token path allowed session validation to be bypassed entirely, defeating identification-and-authentication controls that assume the standard admin login path is the only route to privileged access."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "FortiOS and FortiProxy are the authentication enforcement point for the perimeter, and this CVE is that point failing open: the packet has an unauthenticated attacker open a WebSocket connection to the Node.js console (jsconsole), present a crafted local_access_token that bypasses session validation, and then issue CLI commands as super-admin. That is not an appliance-patch-window item, so for this CVE the control means an expedited clock running from the 2025-01-14 KEV listing across every unit inside the ranges the packet names — FortiOS 7.0.0 through 7.0.16, FortiProxy 7.0.0 through 7.0.19 and 7.2.0 through 7.2.12 — with completion measured by the firmware version each unit reports as running, not by a change ticket closed or an image staged. Scope the sweep to those two products: the packet ties this bypass to FortiOS and FortiProxy at those versions and supplies no evidence implicating other Fortinet management appliances, so widening the emergency window across the whole vendor estate spends the outage budget on devices no evidence here puts in scope. Interim exposure is bounded by enumerating which units expose an administrative surface reachable from untrusted networks and restricting who can reach it, since reachability of the jsconsole WebSocket is the packet's only stated precondition. Preconditions on that interim measure: it bounds who can open the WebSocket and nothing more. It does not repair the token validation, it is unavailable where the management interface must stay reachable for operations, it gives nothing against a source inside the permitted segment, and — because active_exploitation is confirmed and a PoC is public — it does not remove a super-admin account an attacker already created on a unit during the exposure window. A unit that was reachable before the firmware landed goes down the compromise path below; firmware alone closes the door behind an attacker who already holds an account.",
+        "evidence": "Packet facts for CVE-2024-55591: cisa_kev true with kev_date 2025-01-14; active_exploitation confirmed; cvss 9.8; rwep_score 83 (the highest in this batch); poc_available true; patch_available true; live_patch_available false with live_patch_notes null; ai_discovered false; CWE-288. Vector: 'An Authentication Bypass Using an Alternate Path or Channel vulnerability [CWE-288] affecting FortiOS version 7.0.0 through 7.0.16 and FortiProxy version 7.0.0 through 7.0.19 and 7.2.0 through 7.2.12 allows a remote attacker to gain super-admin privileges via crafted requests to Node.js websocket module.' Attack vector: 'An unauthenticated attacker opens a WebSocket connection to the FortiOS/FortiProxy Node.js console (jsconsole) and supplies a crafted local_access_token that bypasses normal session validation, then issues CLI commands to create a new super-admin account and take full control of the device.' Cited as insufficient on this entry: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SC-7 and UK-CAF-B4.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's end state is not code execution that a reboot clears — it is a new super-admin account standing on the FortiOS or FortiProxy unit, created through the CLI by an attacker who never authenticated. Firmware closes the jsconsole token path and leaves that account exactly where it is, which is why patch-in-place is the wrong default for this CVE. Bound to this device, the control means any unit whose administrative surface was reachable from an untrusted network during the exposure window is handled as compromised rather than as patched: enumerate every administrative account on the unit and reconcile it against the change record, since account creation is the packet's own final exploitation step; export the running configuration and diff it against a known-good copy; rotate every administrative credential and every secret held in that configuration on the assumption the attacker read them, because super-admin CLI access means configuration access; and rebuild the unit from a trusted image where the account and configuration audit cannot be made conclusive. This is also the reason the identification-and-authentication control cited on this entry passes its attestation while the device is fully owned: the attacker presents no organizational credential, so IA-2 is never consulted, and the identity that matters is the one minted after the bypass — only an administrative account audit against the change record surfaces it, never a review of how legitimate operators authenticate. Preconditions: this is a post-exploitation control. It prevents nothing, it does not substitute for the firmware update, and it is only conclusive about state still on the device — anything that left the unit (administrative passwords, configuration secrets) must be treated as known to the attacker and rotated regardless of what the configuration diff shows.",
+        "evidence": "Packet facts for CVE-2024-55591: active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-01-14; rwep_score 83; cvss 9.8; patch_available true; live_patch_available false, live_patch_notes null. The attack_vector states the attacker 'issues CLI commands to create a new super-admin account and take full control of the device' after bypassing session validation with a crafted local_access_token over an unauthenticated WebSocket connection to the jsconsole; the vector states the flaw 'allows a remote attacker to gain super-admin privileges'. Cited as insufficient on this entry: NIS2-Art21-incident-handling and NIST-800-53-IA-2 (Identification and Authentication, Organizational Users).",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "NIST-800-53-IA-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet's attacker finishes with super-admin CLI on the FortiOS or FortiProxy unit, which means the device's own event log — the only place its jsconsole session and its administrative account creation are recorded — is under the attacker's control before any responder reads it. For this CVE the control means administrative and system event logs from every unit in the affected FortiOS and FortiProxy ranges are forwarded to a collector in a separate trust zone, with its own credentials and its own authentication path, so the record survives the device. The detection keys on the two behaviours the packet documents and nothing else: a WebSocket session against the Node.js console (jsconsole) administrative surface, and the creation of an administrative account with no corresponding change record. An exploit doing exactly what the packet describes emits both — the crafted local_access_token arrives over a jsconsole WebSocket connection, and the attacker's stated objective is a new super-admin account — so a rule built on those two signals fires on the real path rather than on assumed crash, malware or scanner artifacts, which this bypass never produces. Preconditions: forwarding only helps if it was in place before the exposure window. A unit that has only ever logged locally has no off-box record to consult, and configuring forwarding after the fact produces evidence about the future rather than about the intrusion. It also prevents nothing — it makes the packet's path observable and answers whether a given unit was hit, while the token validation stays broken until the firmware update lands.",
+        "evidence": "Packet facts for CVE-2024-55591: attack_vector records an unauthenticated WebSocket connection to the FortiOS/FortiProxy Node.js console (jsconsole) with a crafted local_access_token, followed by CLI commands creating a new super-admin account and full control of the device; vector names crafted requests to the Node.js websocket module yielding super-admin privileges on FortiOS 7.0.0 through 7.0.16 and FortiProxy 7.0.0 through 7.0.19 and 7.2.0 through 7.2.12. cisa_kev true (kev_date 2025-01-14), active_exploitation confirmed, poc_available true, rwep_score 83, patch_available true, live_patch_available false with live_patch_notes null. Cited as insufficient on this entry: NIS2-Art21-incident-handling.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-12686": {
     "name": "BeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) OS Command Injection Vulnerability",
@@ -38415,7 +39335,31 @@
         "adequate": false,
         "gap": "Least-privilege enforcement within vCenter's own service architecture failed due to the improper privilege-drop condition, which is a defect in the product itself rather than a misconfiguration operators can fully compensate for."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "vCenter Server is the listener this control governs on this estate, and the packet states the entire exploit precondition as reachability: a malicious actor with network access to vCenter Server triggers the flaw by sending a specially crafted network packet, escalating to root. No account appears anywhere in that path, which is why the least-privilege control cited as insufficient on this entry cannot close it — the attacker holds no vCenter role, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the packet's path stays open. Applied to this deployment, the requirement is that vCenter's network listeners accept connections only from management and jump networks and the hosts vCenter administers, enforced by network ACL or host firewall rather than inferred from 'vCenter is internal'. The distinguishing test: from a general user or workstation VLAN against a staging deployment, attempt to open each vCenter listening port and confirm the connection is dropped before it reaches the service. Scope note, because the packet is specific about what it does and does not establish: it names the product, the crafted network packet, and the observed chain with the CVE-2024-38812 heap overflow that turns this into a full unauthenticated-to-root compromise, but it does not name the protocol this particular packet arrives on — so the restriction is written against vCenter's listeners as a set rather than against one named port. Precondition: restricting reachability bounds who can send the packet, it does not repair the privilege-drop check, so any host already inside a permitted management segment — a compromised administrator workstation or jump host — reaches root exactly as before, and the control is unavailable for the segments that must reach vCenter for normal operation. The packet records a vendor patch and no live-patch path; the update is the fix, and this is what bounds exposure until each instance takes it.",
+        "evidence": "Packet: 'The vCenter Server contains a privilege escalation vulnerability. A malicious actor with network access to vCenter Server may trigger this vulnerability to escalate privileges to root by sending a specially crafted network packet'; attack_vector adds 'abuses an improper privilege-drop check ... observed chained with the CVE-2024-38812 heap overflow for a full unauthenticated-to-root compromise'; CWE-250 and CWE-273; NIST-800-53-AC-6 (Least Privilege) is a citing gap on this entry; patch_available true, live_patch_available false, live_patch_notes null. Existing inventory entry NEW-CTRL-128 already governs vCenter's pre-authentication protocol listeners.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's own signals argue against handling this as a routine 7.5-band item: RWEP 75, a public PoC, confirmed in-the-wild exploitation, and an observed chain with CVE-2024-38812 that converts 'escalate to root' into a full unauthenticated-to-root compromise of the virtualization control plane. For this entry the control means the vendor update is driven across every vCenter Server instance from the 2024-11-20 KEV listing rather than folded into the next quarterly virtualization maintenance window, with completion measured by each appliance's running build against the vendor's fixed build — an update staged on the appliance but not applied leaves the vulnerable code answering the crafted packet, and 'approved' in a change queue is not the same measurement. The packet records a vendor patch and registers no live-patch path, so there is no in-place mitigation: each instance has to be taken through the vendor update, following the vendor's own procedure rather than assuming the service stays available, since the packet carries no live-patch note that would say otherwise. Ordering inside the estate follows the chain the packet names: an instance whose listeners are reachable from segments that also carry the unauthenticated CVE-2024-38812 path is where the escalation completes with no credential at all, so it goes first.",
+        "evidence": "Packet: CISA KEV-listed 2024-11-20, active_exploitation confirmed, poc_available true, RWEP 75 against CVSS 7.5; 'observed chained with the CVE-2024-38812 heap overflow for a full unauthenticated-to-root compromise'; patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-38812": {
     "name": "VMware vCenter Server Heap-Based Buffer Overflow Vulnerability",
@@ -38452,7 +39396,31 @@
         "adequate": false,
         "gap": "Boundary protection/network segmentation should isolate the vCenter management network (including TCP/2012) from untrusted or general-purpose network segments, but this is frequently under-enforced in practice."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The packet places the defect in vCenter Server's DCERPC implementation and has an unauthenticated attacker with network access reaching it directly on TCP/2012 with a malformed DCE/RPC request whose crafted ndr_cstring field overflows the heap — a binary remoting listener that answers before authentication and whose parser is itself the vulnerable code. For this deployment the control means TCP/2012 on every vCenter Server instance accepts connections only from the management and jump segments and from the hosts vCenter administers, enforced by network ACL or host firewall and demonstrated rather than inferred from 'vCenter is on the internal network'. This is the reachability half of the exposure and it is the only lever available before the vendor update lands, because the attacker holds no vCenter role — the packet's path yields code execution as the vpxd user without any authentication step, so vCenter's permission model is never consulted and a boundary-protection attestation built on the perimeter firewall and the web tier never touches port 2012 at all. Distinguishing test: from a general user or workstation VLAN on a staging deployment, send crafted DCE/RPC traffic at TCP/2012 and confirm it is dropped before the listener parses it — an estate that passes vCenter role-and-permission and web-tier audits while leaving 2012 answerable from any internal segment is still fully exposed to the unauthenticated packet path. Preconditions, stated plainly: the ACL bounds who can send the malformed request, it does not repair the parser, and it gives nothing against a source that legitimately sits inside the permitted segment — a compromised administrator workstation or an ESXi host in the management plane satisfies the packet's stated requirement of network access in full. It is also unavailable wherever DCERPC must stay reachable for normal operation. And because active_exploitation is confirmed and a public PoC exists, restricting reachability now does not evict anything placed on an instance that was reachable earlier: a vCenter exposed during that window needs compromise assessment of the appliance and of the credentials it holds, not a firewall rule recorded as remediation.",
+        "evidence": "Packet facts for CVE-2024-38812: cisa_kev true with kev_date 2024-11-20; active_exploitation confirmed; cvss 9.8; rwep_score 81; poc_available true; patch_available true; live_patch_available false with live_patch_notes null; ai_discovered false; CWE-122 and CWE-787. Vector: 'The vCenter Server contains a heap-overflow vulnerability in the implementation of the DCERPC protocol. A malicious actor with network access to vCenter Server may trigger this vulnerability by sending a specially crafted network packet potentially leading to remote code execution.' Attack vector: 'An unauthenticated attacker with network access to vCenter Server sends a malformed DCE/RPC request (crafted ndr_cstring field) to the DCERPC service on TCP/2012, triggering a heap overflow that yields remote code execution as the vpxd user.' Cited as insufficient on this entry: NIST-800-53-SC-7 (Boundary Protection), NIS2-Art21-network-security and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the clock is the vCenter Server appliance update itself, and the packet gives every input that should compress it: KEV listing 2024-11-20, exploitation confirmed in the wild, a public PoC, and RWEP 81 against the CVSS 9.8 — an unauthenticated network path to code execution as the vpxd user with no credential, no user interaction and no chained precondition. The control means that update is driven from the KEV listing rather than folded into the next quarterly virtualization maintenance window, which is where a vCenter upgrade normally sits precisely because taking it interrupts the management plane for the estate. Completion is measured per instance by the build actually in service, not by the update being staged, approved or downloaded in the lifecycle manager. The packet records live_patch_available false with no live-patch notes, so there is no way to close the DCERPC parser short of taking each vCenter instance through the vendor update — every hour of deferral is an hour in which the only thing standing between the internal network and vpxd-level execution is which segments can reach TCP/2012. The patch-cadence controls cited on this entry are the ones this misses: an operating-system patching attestation covers the Windows and Linux servers in the estate and does not enumerate the vCenter appliance's own update train, so an estate can report full patch compliance while the appliance carrying this flaw stays on its pre-fix build. Precondition: the reachability restriction above is what bounds exposure until the update lands, and it bounds the attacker population without closing the flaw — it is a holding measure for the window, not a substitute for the update, and it does not remediate an instance already exploited during the window.",
+        "evidence": "Packet facts for CVE-2024-38812: cisa_kev true, kev_date 2024-11-20, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 81, patch_available true, live_patch_available false, live_patch_notes null. The vector records network-triggered heap overflow in the vCenter Server DCERPC implementation 'potentially leading to remote code execution'; the attack_vector records remote code execution as the vpxd user from an unauthenticated request to TCP/2012. Cited as insufficient on this entry: AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-9474": {
     "name": "Palo Alto Networks PAN-OS Management Interface OS Command Injection Vulnerability",
@@ -38734,7 +39702,19 @@
         "adequate": false,
         "gap": "Boundary/egress filtering didn't block outbound SMB (445) to external IPs, which is what let the forced-authentication hash-leak succeed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "What makes the update the whole of the remediation here is the trigger the packet documents: the malicious .url shortcut arrives by phishing mail, and right-clicking, deleting, or moving it is enough to force the victim's machine into an SMB authentication handshake with the attacker's server. Nothing the user is normally told to do — don't open it, delete it — avoids the handshake, and no application sandbox is ever entered, so the ordinary holding measures for a mailed file give nothing and this packet contains no compensating control to run a clock against. The control therefore means the Windows update is driven across the estate from the 2024-11-12 KEV listing rather than the next monthly rollup, with completion measured by each host's installed build rather than by 'approved' or 'downloaded' in the management console; the packet records a vendor patch and registers no live-patch path. Priority should not be read off the 6.5 base or the RWEP 51 — the packet records no public PoC, which is what holds that score down, alongside confirmed in-the-wild exploitation and an outcome the packet states plainly: the user's NTLMv2 hash in the attacker's hands for pass-the-hash reuse or offline cracking, which is a credential compromise rather than the information disclosure the CVSS band suggests. Hosts whose users are inside the phishing target set complete first, because the packet's delivery path is mail and the exposure begins at delivery, not at execution. Precondition on the ordering, not on the fix: a user who already received and handled such a file before the update landed has already leaked the hash, and the update does not invalidate what left the host.",
+        "evidence": "Packet: 'A phishing email delivers a malicious .url shortcut file; minimal interaction (even right-clicking, deleting, or moving it) forces the victim's machine to initiate an SMB authentication handshake to an attacker server, leaking the user's NTLMv2 hash for pass-the-hash reuse or offline cracking'; CWE-73; CISA KEV-listed 2024-11-12, active_exploitation confirmed; CVSS 6.5, RWEP 51, poc_available false; patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-41277": {
     "name": "Metabase GeoJSON API Local File Inclusion Vulnerability",
@@ -39013,7 +39993,30 @@
         "adequate": false,
         "gap": "The ISM's patch-timeframe control for extreme-risk vulnerabilities is difficult to meet given fragmented Android OEM patch-distribution timelines."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The defect is in the Android Framework's own filter: shouldHideDocument() in ExternalStorageProvider.java decides which directories a document request may reach, and incorrect Unicode normalization lets a normalized path walk past that decision. There is no provider to disable and no setting that re-closes the filter, so a handset is either on a build carrying the fix or it is exposed. On an Android estate that makes the Android security patch level an access condition rather than a dashboard column: an enrolled handset below the level carrying this Framework fix is denied mail, VPN and document access, instead of being flagged non-compliant while its mail keeps syncing. The install-restriction half of this control carries unusual weight for this CVE, because the packet puts the entire exploitation path behind an application the attacker controls - the crafted path arrives at shouldHideDocument() from a malicious or compromised app already on the device - so restricting installs to a managed catalogue and blocking side-loading removes the most common way that app arrives. Precondition, and it must be stated rather than assumed: install policy does not evict an app already on the handset, and the packet's own wording covers a compromised app, one that arrived legitimately and turned, which no install allowlist would have stopped. A handset suspected of already running such an app belongs on the incident path, with rotation of any credential reachable through the directories the filter was protecting, not on the install-policy path; and the lever is unavailable entirely on an estate that permits personal-profile installs. Distinguishing test: enrol a handset pinned below the fixing security patch level and confirm the access policy actually denies it the protected resources - an estate that surfaces the stale patch level in a report while the device keeps its access has recorded the exposure, not removed it. This is a holding measure for the window before the fixed build reaches the model; the packet registers a vendor patch and no live-patch path, so nothing short of the device taking that build closes the filter.",
+        "evidence": "Packet vector: 'In shouldHideDocument of ExternalStorageProvider.java, there is a possible bypass of a file path filter designed to prevent access to sensitive directories due to incorrect unicode normalization. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.' attack_vector: 'A malicious or compromised app on the device supplies a Unicode-normalized path to ExternalStorageProvider's shouldHideDocument() filter, bypassing the restricted-directory check to reach files it should not be able to access, escalating local privileges with user interaction required.' CWE-176. cisa_kev true, kev_date 2024-11-07, active_exploitation confirmed, CVSS 7.3, RWEP 57, poc_available false, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null - the packet records a vendor fix and no live-patch path, and states no restart or reboot requirement.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "ISO-27001-2022-A.8.9",
+          "NIST-800-53-CM-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this CVE the remediation is the platform build carrying the ExternalStorageProvider fix and nothing else, so the only variables an operator controls are how fast that build lands on each handset and whether the user may decline it. The managed-device policy must drive the update on the clock that opened with the 2024-11-07 KEV listing rather than on the estate's ordinary monthly cadence, with user deferral disallowed, and completion measured per handset by its reported Android security patch level rather than by an 'assigned' or 'downloaded' state in the management console. The urgency does not come from the score: at CVSS 7.3, with no public PoC recorded and user interaction required for exploitation, this reads as a routine local privilege escalation and lands in a normal patch queue, while the packet records KEV listing with confirmed in-the-wild exploitation and RWEP 57. Precondition, and it is the one that breaks this SLA on Android specifically: policy can force only a build the model's OEM or carrier has actually released, so the fleet report has to separate two failure states that a single compliance percentage hides - handsets that could have taken the fixed build and were allowed to defer, which policy enforcement closes, and models for which no fixed build has shipped, which policy cannot close and which fall to the access-condition control above or to a replacement schedule. Distinguishing test: list enrolled handsets by model against reported security patch level and the days elapsed since the fixed level became available for that model; a report showing policy assignment rather than per-model patch level is measuring the console, not the estate.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2024-11-07, active_exploitation confirmed, RWEP 57 against CVSS 7.3, poc_available false, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null. Packet vector states 'User interaction is needed for exploitation' and that the bypass 'could lead to local escalation of privilege with no additional execution privileges needed'; attack_vector names the affected component as ExternalStorageProvider's shouldHideDocument() filter in the Android Framework.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2019-16278": {
     "name": "Nostromo nhttpd Directory Traversal Vulnerability",
@@ -39208,7 +40211,29 @@
         "adequate": false,
         "gap": "Boundary protection assumed the RAVPN authentication path had rate-limiting; resource exhaustion from bulk auth requests bypassed standard perimeter controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The affected device is the remote-access concentrator itself - Cisco ASA and FTD terminating the RAVPN service - so what fails is the trust boundary's availability rather than code execution on it, and that is precisely what routes this CVE into the wrong tier. At CVSS 5.8 it lands in the medium queue most estates service on a 30- or 90-day cycle, while the packet records CISA KEV listing on 2024-10-24, confirmed in-the-wild exploitation, and RWEP 57. Bound to this product, the tier means the Cisco software update is scheduled against the KEV clock and not the next appliance-maintenance window, because an unauthenticated attacker who exhausts RAVPN resources removes remote access for the entire remote workforce and, per the packet, may leave the device requiring a reload before that service returns. Precondition, and it removes the alternative this tier normally offers: the tier permits isolating the vulnerable interface in place of patching to the clock, and that option does not exist here - the RAVPN service exists to accept connections from unauthenticated clients on the public internet, so there is no source restriction that leaves the service usable. Narrowing which addresses may reach it is available only to an estate whose remote users all originate from a fixed set of ranges; for everyone else the clock is the only lever. The packet's note that services unrelated to VPN are unaffected should not be read as bounding the impact either, because for a remote workforce the VPN service is the access path. Distinguishing test: pull the remediation date recorded against this CVE and compare it to 2024-10-24 rather than to the ticket's CVSS-derived due date - a vulnerability-management attestation reporting that the medium-severity SLA was met is the specific way this one is missed.",
+        "evidence": "Packet vector: 'A vulnerability in the Remote Access VPN (RAVPN) service of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) of the RAVPN service... This vulnerability is due to resource exhaustion... Depending on the impact of the attack, a reload of the device may be required to restore the RAVPN service. Services that are not related to VPN are not affected.' CWE-772. cisa_kev true, kev_date 2024-10-24, active_exploitation confirmed, CVSS 5.8, RWEP 57, poc_available false, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The device that would record this attack is the device the attack exhausts, and the packet says restoring the RAVPN service may require reloading it - so the record of what happened is held on the one component least likely to survive the event. For ASA and FTD units terminating RAVPN this control means syslog and VPN authentication logs are forwarded to a collector outside the appliance, on a separate management plane with its own credentials, before the exposure rather than after it. The rationale differs from the compromise case the control usually covers: nothing here says an attacker gains control of the appliance, so the load-bearing property is simply that the record survives the reload; keep the separate trust zone anyway, because the same collector is what makes the compromise case answerable. The alerting must key on the behaviour the packet documents and not on the outcome: a rising rate of VPN authentication requests to the RAVPN service from unauthenticated sources, correlated with the RAVPN service's own resource consumption - the packet ties this CVE to the Cisco Talos reporting on large-scale brute-force activity against VPN and SSH services, which is the same high-volume authentication signal. A rule that fires on the device becoming unreachable, or on a service restart, detects the end state after remote access is already gone. Precondition: this control does not prevent the exhaustion and does not shorten it - it is detection and post-event reconstruction only, and it holds only while the appliance can still export logs. Because resource exhaustion can degrade that export, the collector's loss of signal from an ASA or FTD unit has to be an alerting condition in its own right rather than a silent gap in the timeline. Distinguishing test: on a staging appliance, generate a sustained burst of RAVPN authentication requests, then reload the device and confirm the off-box collector still holds the request-rate record for the period before the reload.",
+        "evidence": "Packet attack_vector: 'An unauthenticated remote attacker sends a large number of VPN authentication requests to the RAVPN service, exhausting device resources and causing a denial of service that may require a device reload to fully restore.' Packet vector adds: 'An attacker could exploit this vulnerability by sending a large number of VPN authentication requests to an affected device... Depending on the impact of the attack, a reload of the device may be required to restore the RAVPN service' and 'Cisco Talos discussed these attacks in the blog post Large-scale brute-force activity targeting VPNs, SSH services with commonly used login credentials.' CWE-772; cisa_kev true, kev_date 2024-10-24; active_exploitation confirmed; CVSS 5.8; RWEP 57; poc_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-4",
+          "UK-CAF-D1"
+        ]
+      }
+    ]
   },
   "CVE-2024-47575": {
     "name": "Fortinet FortiManager Missing Authentication Vulnerability",
@@ -39623,7 +40648,30 @@
         "adequate": false,
         "gap": "Public-facing application patching requirements don't cover an appliance whose vulnerable branch has no vendor-supplied fix."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet pairs a CVSS of 6.5 with a precondition stated plainly — \"a remote authenticated attacker with admin privileges\" — which is the shape a vulnerability programme defers: a medium-band defect on a management appliance that on paper only an existing administrator can reach. The packet's own attack path removes that comfort, recording the admin access as \"obtained directly or by chaining a separate CSA authentication-bypass flaw\", so on this appliance the privilege precondition is something an attacker supplies from another defect on the same box rather than something the operator's account model withholds. Applied to this CVE, the control's clock runs from the later of the KEV listing of 2024-10-09 and availability of the fixed release the packet names (Ivanti CSA 5.0.2 or later), at the tempo the estate reserves for a critical, with each CSA instance taken through that upgrade rather than the item folded into the next routine appliance window on the strength of its 6.5 rating. The distinguishing test: produce the rule the programme used to schedule this entry, and the deployed version string from each CSA instance. If the scheduling rule read the CVSS band or the \"requires admin privileges\" precondition, it scheduled an actively-exploited path as routine — the packet records active_exploitation as confirmed and an RWEP of 53 against that 6.5, and the two patch controls cited as gaps here are stated in the packet as patch-installation requirements, which an appliance upgraded inside a routine window satisfies while the KEV clock has already run out. Precondition: this control governs the schedule, not the outcome. patch_available is true and live_patch_available is false with no live-patch note, so there is no mechanism to close this short of taking the appliance through the vendor upgrade; and because exploitation is confirmed, an instance that was reachable during the exposure window still needs the post-exploitation review of what the SQL access could reach, however fast the upgrade lands.",
+        "evidence": "The packet gives CVSS 6.5 with RWEP 53, CISA KEV listing 2024-10-09, active_exploitation \"confirmed\", poc_available false, patch_available true, live_patch_available false and live_patch_notes null. The vector reads \"SQL injection in the admin web console of Ivanti CSA before version 5.0.2 allows a remote authenticated attacker with admin privileges to run arbitrary SQL statements\", and the attack_vector records the required admin access as \"obtained directly or by chaining a separate CSA authentication-bypass flaw\". The citing gaps include the ASD Essential Eight \"Patch operating systems\" control, PCI DSS 4.0 6.3.3 (\"All system components are protected from known vulnerabilities by installing applicable security patches/updates\"), and the EU NIS2 Directive Art. 21 vulnerability-handling control.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "PCI-DSS-4.0-6.3.3",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The outcome the packet records on the CSA is not code execution but arbitrary SQL against the appliance's own database, \"allowing extraction or modification of appliance database contents including stored credentials\", with active_exploitation confirmed. Upgrading to the release the packet names as the fix boundary (Ivanti CSA 5.0.2 or later) closes the injection point; it does not invalidate a credential already read out of that database, and it does not revert a row an attacker wrote into it. Applied to this appliance the control means an instance that was reachable and exploitable during the exposure window is not closed on the upgrade: capture its configuration, rebuild the appliance from vendor media rather than patching the running instance, and rotate every credential the packet says that database holds — including any credential the CSA stores on behalf of another system, since those stay valid on the systems they authenticate to long after the CSA itself is clean. The trigger named in the control's own wording is a pre-auth RCE on a perimeter device; the trigger that applies here is narrower and comes from the packet — confirmed in-the-wild exploitation of an appliance whose database holds credentials, reached through a chained authentication bypass rather than through an administrator account the operator issued. The distinguishing test: after remediation, show that the credentials held in the CSA database have been rotated at the systems that accept them, and that the appliance's database contents were compared against a known-good state rather than assumed intact. An entry closed on \"upgraded to 5.0.2\" answers the flaw-remediation question and leaves the extracted-credential question unasked. Precondition: rebuild-and-rotate is the response for an instance that was exploitable during the window; it is not a substitute for the upgrade and gives nothing to an instance still running a pre-5.0.2 release, which stays exploitable until it is upgraded. The packet records poc_available false and carries no per-instance exploitation indicator, so the criterion for invoking this is that an instance was reachable during the window — not proof that a successful injection occurred, which this packet cannot supply either way.",
+        "evidence": "The packet's attack_vector states the attacker \"injects arbitrary SQL statements through the console, allowing extraction or modification of appliance database contents including stored credentials\", and that the admin access is \"obtained directly or by chaining a separate CSA authentication-bypass flaw\". active_exploitation is \"confirmed\" and the entry is CISA KEV-listed 2024-10-09. The vector names the fix boundary — \"Ivanti CSA before version 5.0.2\". patch_available is true, live_patch_available is false, live_patch_notes is null, and poc_available is false. NIST SP 800-53 SI-2 (Flaw Remediation) and ISO/IEC 27001:2022 A.8.9 (Configuration management) are both cited as gaps on this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.9"
+        ]
+      }
+    ]
   },
   "CVE-2024-23113": {
     "name": "Fortinet Multiple Products Format String Vulnerability",
@@ -39665,7 +40713,32 @@
         "adequate": false,
         "gap": "Patch Applications extreme-risk timelines (48 hours) are routinely missed for appliance firmware requiring scheduled maintenance windows."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "This is the tier's core case: an unauthenticated attacker reaching a perimeter device's management daemon and executing code on it. Bound to this packet, the affected estate is FortiOS, FortiProxy, FortiPAM and FortiSwitchManager within the version ranges the packet lists - four separate products, so an inventory keyed only on FortiGate firewalls will report clean while FortiProxy, FortiPAM or FortiSwitchManager units stay exposed. The vendor fixed release must be scheduled against the 2024-10-09 KEV listing, not the appliance-maintenance window, and completion measured per unit by its running version against the fixed release rather than by the change ticket being approved. Unlike most entries in this tier, the isolation alternative is genuinely available here and should run in parallel with the upgrade rather than instead of it: the packet places the attack on the FGFM FortiGate-to-FortiManager management service on TCP/541, whose only legitimate peer is the FortiManager that manages the unit, so restricting which sources may reach TCP/541 - or closing the service on units that are not centrally managed at all - bounds who can deliver the crafted packets during the window before the upgrade lands. Precondition: that restriction holds only where the legitimate peer set is actually enumerable and enforceable at the network edge. A unit whose FortiManager reaches it across untrusted transit still exposes fgfmd to anything that can route to it along that path, and the restriction does nothing for a unit that was already exploited - it bounds future delivery, it does not remove the surface. Distinguishing test: from an address outside the FortiManager peer set, attempt to open TCP/541 on each unit in the affected products and confirm it is refused; a patch-management attestation that records the fixed release as scheduled says nothing about which units are still answering the FGFM port in the meantime.",
+        "evidence": "Packet vector: 'A use of externally-controlled format string in Fortinet FortiOS versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.6, 7.0.0 through 7.0.13, FortiProxy versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.8, 7.0.0 through 7.0.14, FortiPAM versions 1.2.0, 1.1.0 through 1.1.2, 1.0.0 through 1.0.3, FortiSwitchManager versions 7.2.0 through 7.2.3, 7.0.0 through 7.0.3 allows attacker to execute unauthorized code or commands via specially crafted packets.' attack_vector: 'An unauthenticated attacker sends crafted packets to the FGFM (FortiGate-to-FortiManager) management service on TCP/541 that contain externally-controlled format-string specifiers, corrupting memory in the fgfmd daemon to achieve remote code execution or crash the service.' CWE-134. cisa_kev true, kev_date 2024-10-09, active_exploitation confirmed, CVSS 9.8, RWEP 83, poc_available true, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives an unauthenticated attacker code execution in the fgfmd daemon on the appliance, a public PoC, and confirmed in-the-wild exploitation from the 2024-10-09 KEV listing - which means that for any FortiOS, FortiProxy, FortiPAM or FortiSwitchManager unit that was answering TCP/541 to untrusted sources during that window, installing the fixed release answers the wrong question. The upgrade replaces the vulnerable binary; it does not establish that nothing was left behind by an attacker who already ran code on the unit. For this CVE the IR default is therefore configuration extraction, rebuild from a known-good image, and rotation of the secrets the unit held - administrative accounts and any credentials or keys it stored for authenticating users or upstream services - because code execution on the appliance places all of them in reach. Precondition, and it decides which units this applies to: rebuild-not-patch is scoped to units whose FGFM service was reachable from an untrusted source during the exposure window, and the running firmware version cannot tell you which those were. The reachability evidence has to come from records the appliance is not the sole holder of - edge ACL and flow data, management-network topology, or an off-box log collector - and where no such record exists for the window, the unit is treated as in scope rather than assumed clean. A unit whose TCP/541 was demonstrably never reachable from an untrusted source is a patch-in-place case. Distinguishing test: for each affected unit, produce the evidence that answers whether TCP/541 was reachable from outside the FortiManager peer set between the KEV listing and the upgrade; a flaw-remediation record showing the fixed release installed, with no answer to that question, has closed the ticket without deciding whether the device is trustworthy.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends crafted packets to the FGFM (FortiGate-to-FortiManager) management service on TCP/541 that contain externally-controlled format-string specifiers, corrupting memory in the fgfmd daemon to achieve remote code execution or crash the service.' Packet vector names the affected products as Fortinet FortiOS, FortiProxy, FortiPAM and FortiSwitchManager and states the flaw 'allows attacker to execute unauthorized code or commands via specially crafted packets'. CWE-134; cisa_kev true with kev_date 2024-10-09; active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 83; patch_available true; live_patch_available false; live_patch_notes null.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-43573": {
     "name": "Microsoft Windows MSHTML Platform Spoofing Vulnerability",
@@ -39744,7 +40817,30 @@
         "adequate": false,
         "gap": "Least-functionality/least-privilege baselines rarely block execution of attacker-supplied .msc files by default prior to this patch — MMC did not treat untrusted console files as high-risk content."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The execution path the packet records runs at the opening user's own privilege inside mmc.exe — a crafted .msc console file references the apds.dll ActiveX control through the file's StringTable section and runs attacker JScript when the victim opens it — so the population to drive the Windows update across is the general workstation estate where users open files, not a server tier, and the estate's own inventory of who opens files is the enumeration that matters. Run that update on the clock that opened with the 2024-10-08 KEV listing rather than folding it into the next monthly rollup, and measure completion by each host's installed build rather than by 'approved' or 'downloaded' in the management console. The packet registers a vendor patch, live_patch_available false, and no live-patch note at all, so there is no vendor-mitigation state to fall back into and no rule to deploy while the rollout runs: every host either takes the update or is exposed, and the only other lever is the delivery-path control recorded alongside this one, which is the 'documented compensating controls' branch this SLA allows and must be recorded with a dated end rather than as a patched outcome. Priority follows the packet rather than the 7.8 base — a public PoC, confirmed in-the-wild exploitation and RWEP 81 put this above other 7.8-band Windows items in the same cycle, because the vulnerability-management and flaw-remediation controls cited as insufficient here are the ones that set the cadence, and a monthly-rollup cadence is exactly what leaves a KEV-listed, publicly-exploited file-open RCE reachable for weeks after the fix ships.",
+        "evidence": "Packet entry 'Microsoft Windows Management Console Remote Code Execution Vulnerability' (CWE-707): cisa_kev true with kev_date 2024-10-08, active_exploitation 'confirmed', cvss 7.8, rwep_score 81, poc_available true, patch_available true, live_patch_available false, live_patch_notes null. Attack vector as recorded: \"An attacker crafts a malicious .msc console file referencing a vulnerable ActiveX control (apds.dll) via the file's StringTable section, smuggling in an old XSS flaw that executes arbitrary JScript inside mmc.exe when the victim opens the file — the 'GrimResource' technique.\" Framework gaps citing this CVE include NIST-800-53-SI-2 (Flaw Remediation), ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) and EU NIS2 Art. 21 vulnerability handling.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation here requires the victim to open an attacker-crafted .msc console file, so on an estate that has not yet taken the update the delivery path is the only enforceable lever. Require the untrusted-origin marking on every file arriving by mail, web download or untrusted file share, and require it to survive the container: a .msc extracted from an archive, mounted from an ISO or VHD, or renamed must inherit the marking rather than lose it, because a provenance-stripped copy reaches mmc.exe indistinguishable from a console an administrator authored locally. Pair the marking with an ingress rule that quarantines .msc content at the mail and web boundary — a saved console file is not a document type a user has an ordinary reason to receive from outside the organization, which makes this one of the few cases where restricting the file type outright costs the business nothing. Distinguishing test: deliver a .msc nested inside a ZIP through each ingress path to a managed workstation, extract it, and confirm the extracted file still carries the untrusted-origin marking and is refused by policy — a user-application-hardening attestation that enumerates Office macro and ActiveX settings passes cleanly while a provenance-stripped console file opens straight into the apds.dll path with the user's own privileges, and a least-functionality attestation that never names .msc as a restricted type passes with it. Precondition: the marking produces a warning the user can accept, not a block, so it raises the bar on casual delivery rather than removing the path; it gives nothing for a copy already resident on disk, nothing for one delivered before enforcement was turned on, and nothing for a host where the file has already been opened — that host is an incident-response case, not an ingress-policy case. This is a holding measure for the window before the vendor update reaches the workstation, not a substitute for it.",
+        "evidence": "Packet attack vector: the .msc file executes arbitrary JScript inside mmc.exe \"when the victim opens the file\", establishing victim-opened delivery as the exploitation precondition; poc_available true and active_exploitation 'confirmed' with kev_date 2024-10-08; patch_available true with live_patch_available false, so the pre-update window is real. Framework gaps citing this CVE include ASD Essential Eight 'User application hardening' and NIST SP 800-53 CM-7 (Least Functionality).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2024-43047": {
     "name": "Qualcomm Multiple Chipsets Use-After-Free Vulnerability",
@@ -39855,7 +40951,39 @@
         "adequate": false,
         "gap": "Ivanti's fix shipped in May 2024 but active exploitation was still being observed and added to KEV in October 2024 — a five-month unpatched-fleet exposure window well beyond a reasonable SLA."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "The injection sink the packet names sits inside a shipped Ivanti binary — SQL injection in RecordGoodApp (PatchBiz.dll) on the Ivanti Endpoint Manager Core server, reached by a crafted goodApp.md5 value sent to /WSStatusEvents/EventHandler — so the parameterization this control requires is a property of the vendor's query construction, not of anything the operator writes. That makes the operator-side expression a verification duty: require the fixed Ivanti release on any Core server running EPM 2022 SU5 or prior, and prove the injection path is closed by exercising it rather than by reading a version. Distinguishing test, taken straight from the packet's own path: on a staging Core server, send a goodApp.md5 value carrying a SQL metacharacter to /WSStatusEvents/EventHandler and confirm it is parameterized rather than concatenated into a query. The control's second premise is the load-bearing one here — the packet's attacker is unauthenticated and on the same network, so a perimeter WAF and an assumption that the Core server is internal never see the request, leaving the query layer as the only place the input is neutralized. Precondition: this control states the property to verify, it does not implement it; the repair is the vendor's. The packet records no live-patch path, so each Core server has to be taken through the vendor update, and until that update lands the only operator-side lever is restricting which network segments can reach /WSStatusEvents/EventHandler — which bounds who can send the request but leaves the endpoint fully exploitable to anything inside a permitted segment, and is unavailable where managed endpoints must keep reaching that service for normal operation.",
+        "evidence": "Packet vector: 'An unspecified SQL Injection vulnerability in Core server of Ivanti EPM 2022 SU5 and prior allows an unauthenticated attacker within the same network to execute arbitrary code.' Packet attack_vector: 'An unauthenticated attacker on the same network sends a crafted goodApp.md5 value to the EPM Core server's /WSStatusEvents/EventHandler endpoint, exploiting SQL injection in RecordGoodApp (PatchBiz.dll) to reach xp_cmdshell and execute arbitrary commands.' CWE-89; cisa_kev true, kev_date 2024-10-02, active_exploitation confirmed; poc_available true; CVSS 8.8, RWEP 70; patch_available true; live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-060",
+        "name": "DATABASE-SERVER-SIDE-SCRIPTING-DEFAULT-DENY",
+        "description": "The packet's chain does not stop at data access: the injection in RecordGoodApp reaches xp_cmdshell and from there executes arbitrary commands on the EPM Core server. That final step is a database-engine feature that runs operating-system commands, and it is what converts an injection into the arbitrary code execution the packet's vector describes. Bound to this deployment, the control means the database instance behind the Ivanti EPM Core server carries no enabled OS-command path, and the login the Core server authenticates with cannot invoke one — with any enabled state carrying a documented, dated threat-model acceptance that names the function requiring it, rather than being inherited from an installation choice or a troubleshooting session nobody reverted. Distinguishing test: on a staging Core server, attempt an operating-system command through the database engine using the login the EPM Core server itself uses, and confirm it is refused — an application patch-level attestation says nothing about whether that path is open. Precondition, and it decides whether the control is available at all: denying the command path does not repair the injection. An unauthenticated attacker on the same network still reaches the vulnerable query through /WSStatusEvents/EventHandler and still reads and writes the EPM database, and the packet gives no basis for treating that as harmless. If the Ivanti deployment genuinely requires the privilege for a product function, this lever is unavailable and the vendor update is the only closure — establish which of those two states each Core server is in rather than assuming a default.",
+        "evidence": "Packet attack_vector: the crafted goodApp.md5 value sent to '/WSStatusEvents/EventHandler' exploits 'SQL injection in RecordGoodApp (PatchBiz.dll) to reach xp_cmdshell and execute arbitrary commands.' Packet vector: the flaw 'allows an unauthenticated attacker within the same network to execute arbitrary code' against 'Core server of Ivanti EPM 2022 SU5 and prior.' CWE-89; CVSS 8.8, RWEP 70; poc_available true; patch_available true; live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet's end state is arbitrary command execution on the Core server of Ivanti Endpoint Manager — the management server of an endpoint-management product — so the exposure is the estate of endpoints that server administers, not the one host, and the response has to be scoped that way. The window matters here more than on most entries: KEV listing is 2024-10-02, active_exploitation is confirmed, and poc_available is true, so a working exploit was in circulation across whatever interval separated the listing from each operator's update. Applied to this product, the playbook covers what the Core server distributed or instructed to managed endpoints during that window, a defined quarantine criterion for endpoints that acted on those instructions, and rotation of credentials that were used or authenticated through the Core server while it was exposed. Precondition: this is response, not prevention. It stops no injection, and it applies specifically to Core servers that were reachable by an unauthenticated party on the same network during the exposure window — which, given the packet places the attacker on the same network rather than across the perimeter, includes instances an operator considers internal-only. Applying the vendor update to a Core server that already executed attacker commands neither removes what was left behind nor re-validates what it pushed downstream, and closing the finding on the patch is exactly the failure this control exists to prevent.",
+        "evidence": "Packet: CWE-89 SQL injection in 'Core server of Ivanti EPM 2022 SU5 and prior' allowing 'an unauthenticated attacker within the same network to execute arbitrary code'; attack_vector ends in 'xp_cmdshell and execute arbitrary commands.' cisa_kev true, kev_date 2024-10-02; active_exploitation confirmed; poc_available true; CVSS 8.8, RWEP 70; patch_available true; live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-25280": {
     "name": "D-Link DIR-820 Router OS Command Injection Vulnerability",
@@ -40230,7 +41358,31 @@
         "adequate": false,
         "gap": "Network-security measures for essential entities seldom treat the building-automation/OT bus as in-scope, leaving the KNX segment flat and reachable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-118",
+        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
+        "description": "The packet states this exploit's access requirement outright: a device configured to interface with a network can be reached by an attacker with access to that network, who then interfaces with the KNX installation, purges devices without additional security options enabled, and sets a BCU key. So the segmentation half of this control is the load-bearing half here — the KNX installation's network interface must answer only from a segmented building-automation management plane holding the commissioning workstations and servers with an operational need to program the bus, not from a general office VLAN, a tenant or guest network, or any routable path from outside. The credential half is not a vendor default the operator can rotate away: the BCU key is the device's own password mechanism, and because the packet records that it often cannot be reset without entering the current key, it behaves as a first-mover control — a reachable device with no BCU key set is an unlocked device, and whoever sets one first holds it. Where the implementation supports the additional security options the packet names, enable them and set the BCU key under operator control, then escrow that key, because the same irreversibility that blocks the attacker locks the operator out of every device whose key is lost. Distinguishing test: from a segment with no commissioning role, attempt to reach the KNX installation's network interface; anything that answers is within reach of the path the packet describes, and 'the bus is on the internal network' is an assertion about topology rather than a demonstration that the interface is unreachable from untrusted segments. Preconditions: segmentation bounds who can reach the bus over the network and repairs nothing about the reset defect, and the packet is explicit that it does not close the surface — an attacker with physical access to a device exploits it the same way with no network involved at all, so device enclosure and cabinet access control belong inside this control rather than beside it. Neither half restores a device an attacker has already locked; that device falls to the vendor path the packet records, and a site that was reachable during the exposure window should be inventoried for devices that no longer accept the operator's key.",
+        "evidence": "Packet entry 'KNX Association KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout Mechanism Vulnerability' (CWE-645), vector as recorded: \"If the device is configured to interface with a network, an attacker with access to that network could interface with the KNX installation, purge all devices without additional security options enabled, and set a BCU key, locking the device. Even if a device is not connected to a network, an attacker with physical access to the device could also exploit this vulnerability in the same way.\" Also recorded: \"The BCU key feature on the devices can be used to create a password for the device, but this password can often not be reset without entering the current password\", and the implementation-dependent qualifier \"depending on the implementation\". active_exploitation 'confirmed'; cisa_kev true, kev_date 2026-07-15. Framework gaps citing this CVE include NIST SP 800-53 SC-7 (Boundary Protection), EU NIS2 Art. 21 security of network and information systems, and UK CAF B4 (System security).",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "A 2023 CVE that entered the KEV catalogue on 2026-07-15 with confirmed exploitation is the case this SLA exists for: an entry closed years earlier as a low-impact building-automation issue has to be reopened on the KEV clock, and the affected population — KNX devices that use Connection Authorization and support Option 1, which the packet qualifies as implementation-dependent — is one that normally lives in a facilities asset register rather than in the vulnerability-management system that runs the clock, so the first action this control forces is producing that list at all. The packet records a vendor update, no live-patch primitive, and a remediation that requires a reboot, so closing this means taking each affected device through the update and its restart; on a building's lighting, HVAC or access-control bus that is a maintenance window rather than a four-hour push, which is exactly why this control's third branch is the operative one here — until the update lands, the documented compensating state is the reachability restriction recorded alongside it, logged as an active mitigation with a dated end rather than reported as 'patched per SLA'. Distinguishing test is inventory-side rather than scan-side: produce the list of Option 1 KNX devices in service and show a firmware level and a dated remediation decision for each. An operating-system patch attestation and a technical-vulnerability-management attestation both pass cleanly over this estate, because no operating-system agent reports a KNX device and nothing in the scanner's coverage will ever raise it.",
+        "evidence": "Packet: cisa_kev true with kev_date 2026-07-15 against CVE-2023-4346, active_exploitation 'confirmed', cvss 7.5, rwep_score 47, poc_available false, patch_available true, live_patch_available false with live_patch_notes \"No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.\" Affected population per the vector: \"KNX devices that use KNX Connection Authorization and support Option 1 are, depending on the implementation, vulnerable\". Framework gaps citing this CVE include ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8 and NIST SP 800-53 SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-56155": {
     "name": "Microsoft Active Directory Federation Services Insufficient Granularity of Access Control Vulnerability",
@@ -40267,7 +41419,38 @@
         "adequate": false,
         "gap": "Federated-identity management guidance assumes the token-signing key material is protected; it does not detect the insufficiently-granular ACL that exposes the AD FS DKM key to lateral privilege elevation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in Active Directory Federation Services and describes an authorized attacker elevating privileges locally: a low-privileged local principal abuses an over-permissive DKM container ACL to reach the federation master key or elevate to administrator. The account is already legitimate, so no account model is being abused — an access-control boundary inside AD FS is failing, which is precisely why the least-privilege gap and the identity-and-access-control gap recorded on this entry can pass their attestations while the flaw stays fully exploitable, and why tightening account privilege does not contain the escalation. For this CVE the control means driving the Windows update across every AD FS server in the estate on the clock that opened with the 2026-07-14 KEV listing rather than folding it into the next monthly rollup, with completion measured by each server's installed build rather than by an approval or download state in the management console. The packet records a vendor patch, no live-patch path, and an update whose remediation requires a reboot, so a server that has taken the update but not restarted still carries the vulnerable code and must be counted as exposed — and on a federation farm that restart is the step most likely to be deferred, because taking a node out interrupts every authentication depending on it. A deferral recorded as 'patched' is the specific way this remediation goes wrong here: drain and restart nodes in rotation and hold the farm open on the exposure report until the last one is back, rather than closing the ticket when the update is approved. Priority follows the packet rather than the 7.8 base — confirmed in-the-wild exploitation on the component that signs the estate's federated tokens, with the packet recording the chain from the stolen key into token-signing forgery and ransomware-style intrusion, makes this a containment step for an intrusion chain rather than a standalone endpoint item.",
+        "evidence": "Packet entry 'Microsoft Active Directory Federation Services Insufficient Granularity of Access Control Vulnerability' (CWE-1220). Vector as recorded: \"Insufficient granularity of access control in Active Directory Federation Services (AD FS) allows an authorized attacker to elevate privileges locally.\" Attack vector as recorded: \"A low-privileged local principal abuses an over-permissive DKM container ACL in AD FS to access the federation master key or elevate to administrator, enabling token-signing forgery that can be chained with an RCE in ransomware-style intrusions.\" cisa_kev true with kev_date 2026-07-14, active_exploitation 'confirmed', cvss 7.8, rwep_score 57, poc_available false, patch_available true, live_patch_available false with live_patch_notes \"No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.\" Framework gaps citing this CVE include ASD Essential Eight 'Patch operating systems' and EU NIS2 Art. 21 vulnerability handling.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "AD FS is an identity provider — the class this control names explicitly — and the packet's precondition is a low-privileged local principal on that system, so the tier question here is not who holds domain administrator but who holds any local presence on a federation server at all. Applied to this deployment: AD FS servers are administered only from a privileged access workstation through a jumphost, under an identity separate from every other admin role, with just-in-time elevation and step-up authentication, and every other principal that can obtain a logon on the box is enumerated and either removed or justified in writing. The accounts that matter are the unglamorous ones — backup and monitoring agents, helpdesk groups, and service accounts inherited from a general-purpose server build — because each of them quietly satisfies the packet's 'low-privileged local principal' on a host holding the federation master key, and none of them appears in an attestation that lists AD FS administrators. Distinguishing test: enumerate every principal that can obtain an interactive or service logon on each AD FS server together with every principal holding read access to the DKM container, and show each one inside the federation tier; a least-privilege attestation showing a short list of named AD FS administrators passes cleanly while a general-purpose server build grants a dozen non-federation principals local presence on the same host. Precondition: this bounds the population that can reach the over-permissive ACL and repairs nothing about the ACL itself — the vendor update does that, and any principal legitimately inside the tier still reaches the flaw. It also evicts no one already resident: with active exploitation confirmed on this entry, a federation server that carried extra local principals during the exposure window belongs on the incident path, not the hardening path.",
+        "evidence": "Packet attack vector: \"A low-privileged local principal abuses an over-permissive DKM container ACL in AD FS to access the federation master key or elevate to administrator\" — the exploitation precondition is local presence by a principal that need not be privileged. vector: \"allows an authorized attacker to elevate privileges locally\". active_exploitation 'confirmed', cisa_kev true, kev_date 2026-07-14. Framework gaps citing this CVE include NIST SP 800-53 AC-6 (Least Privilege) and UK NCSC CAF B2 (Identity and access control), both recorded as insufficient for this entry.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The asset the packet names is the federation master key, and the end state it names is token-signing forgery — material the vendor update does not invalidate, because a key read before the patch stays valid after it. The playbook for this CVE is therefore keyed to the key rather than to the host: rotate the AD FS token-signing material and drive every relying party onto the new signing key, invalidate issued sessions and refresh tokens across the federated applications, and rotate credentials for any account whose access was obtained through federated sign-in during the exposure window. The review that goes with it is the one this attack actually permits: compare assertions accepted at the relying parties against authentication events recorded on the federation servers for the window preceding the 2026-07-14 KEV listing, and treat a cryptographically valid assertion with no matching federation-server authentication event as the finding — a token forged with the stolen signing key never transits the sign-in path, so it produces no failed authentication, no anomalous logon at the identity provider, and nothing for a rule keyed on brute-force or credential-stuffing patterns to fire on. Trigger and precondition: run this on any AD FS server where a non-federation local principal existed during the exposure window, not only where an alert fired, because waiting for detection evidence before rotating is waiting for a signal this path does not emit by construction. The rotation is also not free — every relying party must consume the new signing key, so the playbook has to name the relying-party inventory and the re-consumption step in advance rather than discovering it mid-incident. This control governs what is done after the key may have been read; the vendor update the packet records is what closes the read path itself.",
+        "evidence": "Packet attack vector: the low-privileged local principal reaches \"the federation master key\", \"enabling token-signing forgery that can be chained with an RCE in ransomware-style intrusions\". active_exploitation 'confirmed'; cisa_kev true with kev_date 2026-07-14; patch_available true, live_patch_available false with live_patch_notes \"No live-patching primitive for this product; the vendor update requires a reboot and is the remediation\" — the packet records the update as remediation of the flaw, not as invalidation of material already read. Framework gap citing this CVE: ISO/IEC 27001:2022 'Identity Management + Authentication Information — federated-state extension'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.5.16-Federated"
+        ]
+      }
+    ]
   },
   "CVE-2026-56164": {
     "name": "Microsoft SharePoint Server Missing Authentication for Critical Function Vulnerability",
@@ -40743,7 +41926,29 @@
         "adequate": false,
         "gap": "Least-functionality controls that still permit the Flash Player browser plugin leave a memory-corruption RCE surface exposed; the plugin should have been disabled/removed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this entry the fixed builds do not sort into one threshold, so a scan that compares a single version string is paper compliance regardless of how many hosts it covers. The packet gives 11.7.700.261 for the 11.7 branch, 12.0.0.44 for the 11.8.x-through-12.0.x range on Windows and Mac OS X, and 11.2.202.336 on Linux. A scanner set to 12.0.0.44 marks a correctly remediated 11.7.700.261 host and every correctly remediated Linux host at 11.2.202.336 as vulnerable, generating remediation work against systems already fixed; a scanner set to 11.7.700.261 passes every build in the 11.8.x-through-12.0.x range, all of which sort above that string while remaining affected until 12.0.0.44 — the direction that matters, because those hosts stay exposed with a clean report. The operational test for this entry is whether the scan resolves each install's branch and platform first and compares against the fixed build for that branch, rather than against any build merely newer than one of the three. Precondition: the check only reports on installs the scanner authenticates to and identifies by product. A per-user copy the scan does not resolve yields no finding, and no finding is indistinguishable from a clean host, so coverage has to be demonstrated by reconciling scan output against an independently built install inventory rather than by the absence of results. This control validates the comparison logic; it does not itself update anything.",
+        "evidence": "Packet vector: 'Integer underflow in Adobe Flash Player before 11.7.700.261 and 11.8.x through 12.0.x before 12.0.0.44 on Windows and Mac OS X, and before 11.2.202.336 on Linux, allows remote attackers to execute arbitrary code via unspecified vectors.' CWE-191. patch_available=true; live_patch_available=false; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' CISA KEV-listed 2024-09-17, active_exploitation=confirmed, CVSS 9.8, RWEP 50.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Two things about this entry defeat the usual prioritisation inputs, and this control's 'later of KEV listing or patch availability' rule is what corrects both. First, the fixed builds date from 2014 while CISA listed the CVE on 2024-09-17, so the SLA clock opens at the listing — a Flash Player install still in service on that date is inside a same-day mitigation window, not a ten-year-old backlog item that age-sorting pushes below current work. Second, the packet records poc_available=false alongside active_exploitation=confirmed: an intake rule that starts its clock on public exploit-code publication never starts at all on this entry, even though the packet states the flaw is being exploited. The listing date, not PoC availability and not the CVE year, is the trigger. Applied here that means driving the fixed build for each branch — 11.7.700.261, 12.0.0.44 for the 11.8.x-through-12.0.x range, 11.2.202.336 on Linux — across every install on the KEV clock, with completion measured by each install reporting the fixed build for its own branch rather than by the update being approved or downloaded in a management console. Precondition: the control permits documented compensating controls in place of the binary fix, but the packet registers no vendor mitigation and no live-patch path for this product, so there is nothing to substitute — the vendor update, which the packet states requires no reboot, is the remediation. An install that cannot take it inside the window is an open, dated exception carried as exposed, not an SLA closure.",
+        "evidence": "Packet: cisa_kev=true, kev_date 2024-09-17, active_exploitation=confirmed, poc_available=false, CVSS 9.8, RWEP 50. Vector gives fixed builds before 11.7.700.261, 11.8.x through 12.0.x before 12.0.0.44 on Windows and Mac OS X, and before 11.2.202.336 on Linux. attack_vector: 'An integer underflow during SWF parsing corrupts heap memory; a victim who loads an attacker-controlled Flash object (drive-by or malvertising) triggers arbitrary code execution in the browser context.' patch_available=true; live_patch_available=false; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-6670": {
     "name": "Progress WhatsUp Gold SQL Injection Vulnerability",
@@ -41116,7 +42321,41 @@
         "adequate": false,
         "gap": "The fix was upstreamed without a security classification, so advisory-driven flaw remediation did not backport it to long-term kernels for over two years, leaving a durable local-root LPE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-002",
+        "name": "LIVE-PATCH-CAPABILITY",
+        "description": "This is the uncommon kernel LPE where the packet records a real live-patch path, and that changes what the operator's options actually are: kpatch on RHEL, Oracle Ksplice and SUSE kGraft can apply the load_elf_binary fix without a reboot, so a host running production workloads is not forced to choose between leaving the vulnerable load_elf_binary in place and taking an unplanned restart. Applied to this CVE, the control means the live-patch client, entitlement and rollout procedure are already installed and exercised on every long-term-kernel host before the disclosure, so that on the KEV clock the operator's task is applying the load_elf_binary patch rather than standing up live patching for the first time; and that the reboot-gated kernel swap is still scheduled afterwards, because the live patch closes this local escalation while leaving the host booted on the old on-disk kernel. Precondition, and it is the one that decides whether this control is available at all: the packet qualifies live patching as working on supported kernels. A host on a self-built kernel, an out-of-support minor release, or a distribution with no live-patch product gets nothing here and has only the reboot-gated vendor update, so the estate must be enumerated by live-patch eligibility rather than assumed uniform, with the ineligible hosts carried on the reboot path explicitly. Live patching also gives nothing to a host where a local user has already escalated: it removes the primitive, not the result, and this entry carries confirmed in-the-wild exploitation and a public PoC.",
+        "evidence": "The packet sets live_patch_available true with notes naming kpatch on RHEL, Oracle Ksplice and SUSE kGraft as able to apply the load_elf_binary fix without a reboot on supported kernels, 'closing the LPE while deferring the reboot-gated kernel swap'; patch_available is also true. The attack_vector is a local user executing a specially-linked PIE binary, with the resulting stack corruption leveraged to escalate to root on unpatched long-term kernels. CISA KEV-listed 2024-09-09, active_exploitation confirmed, poc_available true, RWEP 67, CVSS 7.8.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet's own account of this bug is a compliance-theater case rather than a slow-patching case: the fix went in on April 14, 2015 as commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 and was backported to Linux 3.10.77 in May 2015, but it was not recognized as a security threat at the time, so it never travelled through the distributions' security-backport pipelines into their long-term kernels. A scanner that calls a host patched because its kernel package is the vendor's current build for that long-term branch is therefore not answering the question this CVE poses — whether that specific commit is present in the branch the host is running, and whether the kernel was built with CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE, which the packet names alongside a normal top-down allocation strategy as the condition under which load_elf_binary maps the later PT_LOAD segments into the stack gap. The operational test for this entry: for each long-term-kernel host, produce evidence that the running kernel's source lineage carries a87938b2e246b81b4fb713edb371a9fa3c5c3c86 or the distribution's named backport of it, instead of evidence that the package version is newer than some date. An estate where every host is on the latest long-term package and none carries that commit passes a technical-vulnerability-management attestation cleanly while every host still maps segments above mm->mmap_base. Precondition: this is an assurance check on the evidence behind the patch verdict — it identifies which hosts are genuinely exposed, it changes none of them. Remediation remains the vendor update or, per the packet, live application of the load_elf_binary fix on supported kernels.",
+        "evidence": "The packet's vector states the flaw affects 'Linux distributions that have not patched their long-term kernels with' commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86, 'committed on April 14, 2015', 'backported to Linux 3.10.77 in May 2015', and that 'it was not recognized as a security threat'. The same vector names the exposure condition: 'With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base' without accounting for the whole binary, so subsequent PT_LOAD segments land above mm->mmap_base in the stack gap. KEV-listed 2024-09-09 with active_exploitation confirmed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Every host on this entry's exposed population is one where the operator either cannot reboot yet or is not live-patch eligible, and for that window host-level detection is all that is left. The rule has to key on what the packet's path actually emits, which is a pair of events rather than a crash: an unprivileged execve of a specially-linked PIE ELF — a binary the attacker supplies, so it is not part of the package-managed inventory and typically sits in a user-writable path — followed, inside that same process lineage, by a transition to uid 0 that no sudo, su, pkexec or other authentication record accounts for. Both halves are needed; the execve alone is ordinary developer activity and the uid-0 transition alone is what every legitimate setuid binary does. Do not key on segfaults, kernel oops messages or named exploit binaries: a working exploit of this flaw need not crash anything, the packet documents no crash behaviour, and a filename or hash is a signature for one public PoC rather than for the technique. The distinguishing test is to reproduce that pair on a staging host of the same kernel build — an unprivileged process executing a locally written PIE ELF, and a uid-0 transition in its lineage with no matching authentication event — and confirm the rule fires on the pair; a rule validated by dropping a named public exploit on the host has tested the filename, not the behaviour. Preconditions: this is a detection, not a mitigation — it fires after the escalation has already happened, so it buys response time rather than preventing root. And because the outcome of the technique is root on the host writing the records, the audit events have to reach an off-host collector to be worth anything; a rule whose only evidence stays in local auditd on a machine the attacker now owns is not a control.",
+        "evidence": "The packet's attack_vector: 'A local user executes a specially-linked PIE binary so that its later PT_LOAD segments are mapped above mm->mmap_base into the stack gap; the resulting stack corruption is leveraged to escalate to root on unpatched long-term kernels.' poc_available true, active_exploitation confirmed, KEV-listed 2024-09-09, RWEP 67. The packet's live_patch_notes limit the no-reboot fix to supported kernels, so a population of hosts stays exposed until the reboot-gated kernel swap.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2016-3714": {
     "name": "ImageMagick Improper Input Validation Vulnerability",
@@ -42193,7 +43432,41 @@
         "adequate": false,
         "gap": "The vendor-default-account requirement is exactly the gap: the appliance shipped with a usable default password that operators did not change, yielding unauthenticated RCE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The packet puts the credential inside the product: remote command execution due to use of default passwords, with a remote unauthenticated attacker using the shipped default password to reach the ACI web portal and the PostgreSQL database. Because the password the attacker needs ships with ACI rather than being set per site, no amount of operator-side account hygiene reduces the exposure — which is precisely why the identity-and-access-control and IA-2 gaps are recorded against this entry: the attacker never authenticates as any named ACI administrator, so per-account privilege scoping is never consulted and the account model an identity attestation examines is bypassed rather than abused. Applied to this product the control means inventorying every ACI installation as depending on a product-shipped credential and gating each one on the fixed build for its own branch. The packet gives five separate branch lines — 5.0.1-61, 5.1.1-71, 5.2.1-69, 5.3.1-53 and 5.4.4-132 — so an installation on the 5.2 line is remediated at 5.2.1-69 and is not made safe by any build number that merely sorts higher than one of the other four. The check must be re-run after any appliance rebuild, image restore or node replacement, since those are the operations that quietly reinstate a pre-fix ACI carrying the shipped default at a site that had already been remediated. Distinguishing test: against a staging ACI at the build the estate intends to run, attempt authentication to the web portal and to the PostgreSQL service using the vendor's shipped default credential from a host holding no administrative role; anything that accepts it is exploitable, while an attestation showing every ACI administrator holds a unique named account passes cleanly the whole time. Precondition: the vendor update is what removes the dependence on the shipped default — this control is the inventory and the gate that ensure every installation reaches it, and it gives nothing on its own to a site that has not yet taken the update. The packet records no live-patch path and a vendor update that requires a reboot, so an installation that has staged the fixed build but not restarted still carries the default and must be counted as exposed. It also does not detect an installation an attacker already reached, so anything reachable during the exposure window is closed out through the rebuild-and-rotation path, not on the update.",
+        "evidence": "Packet: CWE-1393; vector 'Remote command execution due to use of default passwords. The following products are affected: Acronis Cyber Infrastructure (ACI) before build 5.0.1-61, ... before build 5.1.1-71, ... before build 5.2.1-69, ... before build 5.3.1-53, ... before build 5.4.4-132.' attack_vector: 'A remote unauthenticated attacker uses the shipped default password to access the ACI web portal / PostgreSQL database, then uploads SSH keys to gain root on the appliance and execute arbitrary commands.' CISA KEV-listed 2024-07-29, active_exploitation=confirmed, poc_available=true, CVSS 9.8, RWEP 75. patch_available=true; live_patch_available=false; live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's attack path does not end at code execution — it ends at installed persistence: the attacker uses the shipped default password to reach the ACI web portal and PostgreSQL, then uploads SSH keys to gain root on the appliance. A key written into the appliance's authorized-keys material survives the vendor update, because the update removes the default credential that let the attacker in, not the key that keeps them in. On this entry, therefore, 'updated to the fixed build' is not a statement about whether the appliance is still attacker-accessible, and the packet's confirmed active exploitation plus public PoC mean that distinction is operational, not theoretical. Applied here the control means any ACI installation that was reachable by an unauthenticated caller during the exposure window is handled as a suspected compromise rather than a patch ticket: capture the configuration, the SSH authorized-keys material and the local account state for analysis first; rebuild the appliance from the fixed build rather than updating in place; and rotate every credential the appliance held or could reach, including the database credentials and any keys or tokens stored for the systems it serves. Distinguishing test: on an installation that has already taken the update, enumerate the SSH authorized keys and the local accounts on the appliance and reconcile every entry against an operator-owned record of what belongs there — an unexplained key is standing root access that both the patch and the flaw-remediation attestations record as closed. Precondition: rebuilding is remediation only if the rebuild source is the fixed build for that branch. Re-imaging from the installer media the site already had reinstates the same shipped default password and returns the appliance to the exploitable state — that is the specific way this recovery goes wrong. The rebuild also requires the reboot the packet's remediation note describes, and it recovers nothing the attacker took while resident: data reachable from the appliance and credentials it stored must be treated as disclosed however cleanly the appliance comes back.",
+        "evidence": "Packet attack_vector: 'A remote unauthenticated attacker uses the shipped default password to access the ACI web portal / PostgreSQL database, then uploads SSH keys to gain root on the appliance and execute arbitrary commands.' Vector: 'Remote command execution due to use of default passwords', fixed builds 5.0.1-61 / 5.1.1-71 / 5.2.1-69 / 5.3.1-53 / 5.4.4-132. CISA KEV-listed 2024-07-29, active_exploitation=confirmed, poc_available=true, CVSS 9.8, RWEP 75. patch_available=true; live_patch_available=false; live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The packet names two surfaces the remote unauthenticated attacker reaches with the shipped default password, and one of them is not a web surface: the PostgreSQL database on the appliance. A database remoting endpoint that answers callers before any site-controlled authentication decision is the class this control governs, and it is the surface that web-tier hardening and role-and-permission audits of ACI never touch. The requirement for this deployment is that the ACI PostgreSQL listener accepts connections only from the hosts that legitimately speak to it — the appliance's own components and the management hosts with an operational need — enforced by network ACL or host firewall, rather than assumed from 'ACI is on the internal network'. Distinguishing test: from a general user or workstation VLAN on a staging deployment, open a connection to the ACI PostgreSQL port and confirm it is dropped before the service answers; a deployment that passes its ACI administrator-account review while leaving that listener reachable from any internal segment still hands the shipped default credential a live target. Preconditions, and they are severe enough that this must never be recorded as the remediation. It bounds who can present the default password; it does not change the fact that the password is valid, which only the vendor update does. It covers the PostgreSQL half only — the packet also names the ACI web portal, which is an HTTP surface outside this control and remains reachable to everyone the portal is meant to serve, so the exposure is reduced rather than removed. It does nothing against a caller already inside the permitted segment: a compromised management host or jump box satisfies the reachability precondition in full. And it does not evict an attacker who is already resident — an SSH key uploaded during the exposure window keeps working from wherever that key is used. This is a holding measure for the window before the update and its required reboot land, not a closure.",
+        "evidence": "Packet attack_vector: 'A remote unauthenticated attacker uses the shipped default password to access the ACI web portal / PostgreSQL database, then uploads SSH keys to gain root on the appliance and execute arbitrary commands.' Vector: 'Remote command execution due to use of default passwords', CWE-1393. CISA KEV-listed 2024-07-29, active_exploitation=confirmed, poc_available=true, CVSS 9.8, RWEP 75. patch_available=true; live_patch_available=false; live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "PCI-DSS-4.0-2.2.3"
+        ]
+      }
+    ]
   },
   "CVE-2024-5217": {
     "name": "ServiceNow Incomplete List of Disallowed Inputs Vulnerability",
@@ -42230,7 +43503,39 @@
         "adequate": false,
         "gap": "Input-validation control expectations were not met by the GlideExpression sanitizer's incomplete disallowed-input list, allowing template-injection payloads through."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The protection mechanism that failed here is a denylist inside the Now Platform itself: the packet places the bypass in the GlideExpression sanitizer, whose incomplete list of disallowed inputs lets a crafted jvar_page_title value submitted to /login.do carry Glide/Jelly expression syntax through to server-side template evaluation. A list that omitted one expression form is evidence about the form of the defence, not about that one payload. Bound to this product, the control means the verification battery for the Now Platform's expression sanitizer covers the family of Glide/Jelly expression encodings that can reach it, and is re-run on each Now Platform patch and hot fix rather than run once against the published jvar_page_title payload. Distinguishing test, keyed on the behaviour the packet documents: on a staging instance at the fixed patch level, submit each encoding variant of a Glide/Jelly expression in jvar_page_title to /login.do as an unauthenticated caller and confirm none reaches template evaluation — a check that replays only the one published payload passes while a sibling encoding still evaluates, which is precisely the failure CWE-184 names. Preconditions: this is a verification control and it repairs nothing — the sanitizer itself is fixed only by the vendor's June 2024 patch or hot fix, and the battery catches a re-opened form only if that form is in it, so an instance that passes a thin battery is not thereby patched. It is also a staging control: the packet records confirmed in-the-wild exploitation and a public exploit, so firing expression payloads at a production instance to 'confirm' the fix is not a substitute for applying it.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker submits a crafted jvar_page_title value to /login.do containing Glide/Jelly expression syntax; the GlideExpression sanitizer's incomplete disallowed-input list lets the payload reach server-side template evaluation, yielding remote code execution and data exfiltration.' Packet cwe_refs: CWE-184, CWE-697. Packet vector: the vulnerability 'is addressed in the listed patches and hot fixes below, which were released during the June 2024 patching cycle.' Packet: poc_available true; active_exploitation confirmed; cvss 9.2; rwep_score 74. Citing gaps record PCI-DSS-4.0-6.2.4 ('Software engineering techniques or other methods are defined and used by personnel to prevent or mitigate common software attacks') and UK-CAF-B4 (System security) against this entry.",
+        "gap_closes": [
+          "PCI-DSS-4.0-6.2.4",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet names the affected population by release family — Washington DC, Vancouver, and earlier Now Platform releases — but records the fix as patches and hot fixes shipped during the June 2024 patching cycle. Those two facts do not line up inside an asset inventory: an instance recorded as 'Washington DC' or 'Vancouver' is both the vulnerable and the fixed state depending on whether the June 2024 patch or hot fix has been applied, so a scan or CMDB field carrying only the family name cannot answer the question and will read as compliant on an unpatched instance. Bound to this product, the control means the vulnerability-management record for each Now Platform instance carries the applied patch and hot-fix level rather than the release family, and that the level is read from the instance rather than inherited from a change ticket asserting it. Operational test: for every instance, pull the applied patch/hot-fix level and confirm it is at or past the June 2024 fix for its family, then on staging submit the jvar_page_title expression payload the packet describes to /login.do and confirm it does not evaluate. An estate whose scanner reports every instance as a supported release family, while none has taken the June 2024 hot fix, passes the scan and stays exploitable. Precondition: this control finds an unremediated instance, it does not remediate one — a confirmed-unpatched instance still needs the vendor patch. And because the packet records confirmed exploitation with a public exploit, an instance found unpatched now was reachable and unpatched through the exposure window, so it warrants triage of what the instance served rather than a silent patch-and-close.",
+        "evidence": "Packet vector: 'ServiceNow has addressed an input validation vulnerability that was identified in the Washington DC, Vancouver, and earlier Now Platform releases. This vulnerability could enable an unauthenticated user to remotely execute code within the context of the Now Platform. The vulnerability is addressed in the listed patches and hot fixes below, which were released during the June 2024 patching cycle.' Packet: cisa_kev true, kev_date 2024-07-29, active_exploitation confirmed, poc_available true, rwep_score 74, cvss 9.2, patch_available true. Citing gaps record ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling) against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is KEV-listed 2024-07-29 with exploitation confirmed and a public exploit recorded, and it is one of the cases where the usual reason a KEV clock slips does not exist: the packet records no live-patching primitive but states that the vendor update is the remediation and needs no reboot, so there is no restart to schedule and no outage window to wait on. The SLA's completion criterion for this CVE is therefore each Now Platform instance running the June 2024 patch or hot fix for its release family — not a change request raised, not a KEV due-date row closed, not 'the update is staged'. The compensating-control half is where this entry differs from a typical appliance CVE: the packet places the payload on /login.do, the platform's login page, which has to answer unauthenticated callers for the platform to be usable, so restricting reachability is simply not available as the documented interim mitigation for any instance serving remote or customer traffic — which is why the boundary-protection gap cited on this entry cannot be written up as the mitigation while the patch waits. Where an instance's login page genuinely is reachable only from a private segment, that bounds who can send the payload and does nothing else: the endpoint stays fully exploitable to anything inside that segment, so it is a holding measure for hours, never a substitute for the patch.",
+        "evidence": "Packet: cisa_kev true; kev_date 2024-07-29; active_exploitation confirmed; poc_available true; rwep_score 74; cvss 9.2; patch_available true; live_patch_available false; live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' Packet attack_vector places the crafted jvar_page_title value on /login.do, submitted by an unauthenticated attacker. Citing gaps record AU-Essential-8-Patch, NIST-800-53-SI-2 (Flaw Remediation) and NIST-800-53-SC-7 (Boundary Protection) against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-4879": {
     "name": "ServiceNow Improper Input Validation Vulnerability",
@@ -42304,7 +43609,18 @@
         "adequate": false,
         "gap": "Security-of-processing obligations were unmet because personal data (phone-number registration status) was disclosable without authentication or abuse-rate controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "What the packet records is not a flaw in the operator's own systems: the enumeration ran against an unauthenticated Twilio Authy API endpoint that answered whether each submitted phone number was registered, and the packet notes Authy accounts themselves were not compromised. The one operator-side surface the packet does name is the client build — the endpoint is described as accessed by Authy Android before 25.1.0 and Authy iOS before 26.1.0, and the packet records a vendor update, requiring no reboot, as the remediation. Bound to this entry, the control means managed devices on both platforms are driven to at least those builds under the KEV-class clock that opened 2024-07-23, enforced by the MDM as a required minimum app version with user deferral disallowed, rather than left to each user's store-update habits — an authenticator is exactly the app a user hesitates to touch, so a policy that merely offers the update leaves a long tail sitting below the fix. Distinguishing test: query the MDM for installed Authy versions across enrolled Android and iOS devices and confirm none sits below 25.1.0 and 26.1.0 respectively; an estate whose mobile attestation covers only the OS build reports fully compliant while the authenticator app stays below the fixed version. Preconditions, and they carry more weight than the rollout itself: moving devices to the fixed builds does not retract phone numbers already enumerated — the packet records exploitation in the wild in June 2024, and numbers read then stay in the attacker's hands as targeting data for exactly the phishing and SIM-swap activity the packet names as the downstream use. Nor is there operator-side detection to fall back on, because the requests went to the vendor's API: no telemetry inside the estate observed them and the exposed population cannot be derived locally. For that half of the exposure the remaining lever is treating the staff who hold Authy as a known-targeted set, which is a briefing and factor-choice decision this control does not deliver.",
+        "evidence": "Packet vector: 'In the Twilio Authy API, accessed by Authy Android before 25.1.0 and Authy iOS before 26.1.0, an unauthenticated endpoint provided access to certain phone-number data, as exploited in the wild in June 2024. Specifically, the endpoint accepted a stream of requests containing phone numbers, and responded with information about whether each phone number was registered with Authy. (Authy accounts were not compromised, however.)' Packet attack_vector: 'An attacker submitted large batches of phone numbers to an unauthenticated Authy API endpoint, which replied indicating whether each number was registered, enabling mass enumeration of Authy users for downstream phishing and SIM-swap targeting.' Packet: cisa_kev true; kev_date 2024-07-23; active_exploitation confirmed; poc_available false; cvss 5.3; rwep_score 40; patch_available true; live_patch_available false; live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' Citing gaps record UK-CAF-B4 (System security) against this entry.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2012-4792": {
     "name": "Microsoft Internet Explorer Use-After-Free Vulnerability",
@@ -42378,7 +43694,39 @@
         "adequate": false,
         "gap": "Least-privilege role design cannot remediate a vendor-shipped incorrect-default-permission that exposes secrets to non-administrative accounts; only the vendor patch or an explicit ACL fix closes it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records a vendor update as the remediation for these over-permissioned vCenter files, with no live-patch path and a fix that requires a reboot — so on this appliance the KEV clock that opened 2024-07-17 runs to the completed restart of every vCenter Server instance, not to the point the update is staged or a console reports it applied. A vCenter that has taken the update but not been restarted still carries the readable files, and restarting the management appliance is the step most likely to be deferred into the next virtualization maintenance window, which is the specific way this remediation gets recorded as done while the exposure stands. Priority has to come from the packet rather than the 6.5 base score: exploitation is confirmed in the wild, and the payoff the packet names is configuration data and secrets that enable privilege escalation and lateral movement in the virtualization estate, not the read-only outcome an information-disclosure severity band implies. poc_available is false, and that is not grounds to schedule this as routine — the packet records no public exploit alongside confirmed in-the-wild use. Distinguishing test: measure elapsed time from the KEV listing to each instance's post-update restart and report the tail per instance; a patch-compliance report counting deployed updates passes while instances await the restart that makes the fix effective.",
+        "evidence": "Packet: CWE-276; CISA KEV-listed 2024-07-17 with active_exploitation confirmed; RWEP 53, CVSS 6.5, poc_available false, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Packet attack_vector: 'A user with non-administrative access to vCenter Server reads sensitive files exposed by incorrect default file permissions, harvesting configuration data and secrets that enable privilege escalation and lateral movement in the virtualization estate.' Citing gaps name ASD Essential Eight 'Patch operating systems' and NIST SP 800-53 SI-2 (Flaw Remediation) as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "vCenter Server is the control plane for the virtualization estate the packet says this flaw enables lateral movement across, and the actor who exploits it is not an administrator — the packet's attacker holds non-administrative access to vCenter and reads secrets straight off the appliance's files. Bound to this product, the control means the privileged tier is drawn at every identity that can authenticate to vCenter at all — read-only, operator, integration and service accounts included — rather than at the vCenter administrator role: those sessions come through the privileged-access path with step-up authentication and just-in-time grant, held separately from identities used for ordinary application administration. That is exactly what the cited least-privilege and identity-and-access-control gaps do not reach here: role scoping inside vCenter is the thing the attacker is already inside of, so an estate can demonstrate that non-administrative roles carry no administrative permissions and still hand those same roles the configuration data and secrets the file permissions expose. Precondition: this bounds and instruments the population that can reach the files — it does not repair the permissions, which per the packet is the vendor update with the restart taken, and it gives nothing to an instance whose low-privilege accounts are already provisioned and in use. Distinguishing test: enumerate every principal that can open a session against vCenter, service and integration accounts included, and show each reaches it only through the tiered path; an attestation that vCenter administrators are separately tiered passes cleanly while a low-privilege role sits within reach of the same files.",
+        "evidence": "Packet vector: 'The vCenter Server contains an information disclosure vulnerability due to improper permission of files. A malicious actor with non-administrative access to the vCenter Server may exploit this issue to gain access to sensitive information.' CWE-276; CISA KEV-listed 2024-07-17 with active_exploitation confirmed; RWEP 53, CVSS 6.5. patch_available true, live_patch_available false. Citing gaps name UK NCSC CAF v3.2 B2 (Identity and access control) and NIST SP 800-53 AC-6 (Least Privilege) as insufficient.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "What this flaw yields, per the packet, is configuration data and secrets — so the moment a patched-and-restarted vCenter is clean is not the moment the estate is. The requirement here is a rehearsed sequence for any instance that was reachable by a non-administrative account while unpatched: rotate the credentials and keys carried in the files the packet says those accounts could read, re-issue whatever those secrets authenticate, review privileged authentications made with those identities across the window, and set quarantine criteria for the systems vCenter administers, because the packet's stated payoff is lateral movement in the virtualization estate rather than compromise of the appliance alone. The window closes at the restart, not at the KEV date, and on this entry it can be long — the listing is 2024-07-17 against a defect carrying a CVE-2022 identifier. Preconditions: rotation covers only secrets the operator can enumerate, so the list must be derived from what the appliance actually holds on disk rather than from a general credential inventory; and rotation is not detection — the packet's exploitation step is a read by an account authorized to be on the appliance, with poc_available false, so there is no distinct exploit artifact to hunt and misuse has to be looked for downstream in the authentications those secrets enable. Distinguishing test: for each vCenter that ran unpatched past the KEV listing, produce the list of secrets its readable files held and show each has been rotated after the restart; an incident record closed on 'update applied' passes flaw-remediation review with every one of those secrets still valid.",
+        "evidence": "Packet attack_vector: 'A user with non-administrative access to vCenter Server reads sensitive files exposed by incorrect default file permissions, harvesting configuration data and secrets that enable privilege escalation and lateral movement in the virtualization estate.' CWE-276; CISA KEV-listed 2024-07-17 with active_exploitation confirmed; RWEP 53, CVSS 6.5, poc_available false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gaps name NIST SP 800-53 SI-2 (Flaw Remediation) and UK NCSC CAF v3.2 B2 (Identity and access control) as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2024-28995": {
     "name": "SolarWinds Serv-U Path Traversal Vulnerability",
@@ -42682,7 +44030,38 @@
         "adequate": false,
         "gap": "Least-functionality that fully removes/disables the legacy Internet Explorer/MSHTML rendering path would have blunted the technique; leaving the retired engine reachable kept the attack surface alive."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation starts with a file the user opens: the packet's lure is a crafted .url internet shortcut whose content is the URL it points at, using the 'mhtml:' scheme and an '!x-usc:' directive so Windows hands the target to the retired Internet Explorer/MSHTML engine and the perceived file type is not what actually renders. Because the endpoint's decision is made from what the shortcut says, the enforceable control on an estate that has not completed the update is the ingress boundary: the mail gateway and file-share boundary apply the untrusted-origin marking themselves rather than leaving the endpoint to infer it, internet shortcut files arriving from outside the organization are held rather than delivered, and the marking survives the container — a shortcut extracted from an archive, mounted from an image, or renamed inherits the tag instead of losing it. Precondition: this narrows the delivery path, it does not close the flaw. A .url reaching the user through any path the boundary does not mark — removable media, an unmanaged share, a link followed directly in a browser — still resolves the mhtml:/!x-usc: handler chain into MSHTML, and per the packet only the vendor update, on a host that has since been restarted, removes that. Distinguishing test: deliver a .url whose displayed name and invoked handler disagree through each ingress path onto a managed workstation and confirm it arrives marked untrusted or is held; the user-application-hardening attestation cited on this entry covers macro and ActiveX settings and guidance to check file extensions, which is precisely what a file-type-spoofing lure defeats.",
+        "evidence": "Packet attack_vector: 'A victim opens a crafted .url internet-shortcut whose URL uses the \"mhtml:\" scheme and an \"!x-usc:\" directive; Windows invokes the retired Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA, spoofing the perceived file type and executing code (Void Banshee delivered the Atlantida stealer this way).' CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gap names ASD Essential Eight 'User application hardening' as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Per the packet this is a vendor update with no live-patch path and a fix that requires a reboot, so the clock opened by the 2024-07-09 KEV listing runs to the completed restart of every affected Windows endpoint, not to update-deployment counts. An endpoint that has taken the update but not restarted still resolves the packet's mhtml:/!x-usc: shortcut into the retired engine, and user-workstation restarts are exactly what deployment reporting conceals — 'installed, pending restart' is the state in which this remediation is recorded as complete while the path stays live. Urgency comes from the packet's own fields rather than the 7.5 base score: poc_available is true, active_exploitation is confirmed, and the packet ties the technique to the Void Banshee delivery of the Atlantida stealer, so every hour of the window on a user endpoint is an hour of potential credential loss rather than only of exposure. Distinguishing test: measure elapsed time from the KEV listing to each endpoint's post-update restart and report the tail rather than the mean; a fleet reported compliant on installed-update counts while endpoints await restart has not closed the window.",
+        "evidence": "Packet: CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true, ai_discovered false. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Packet attack_vector records that 'Void Banshee delivered the Atlantida stealer this way'. Citing gaps name NIST SP 800-53 SI-2 (Flaw Remediation), EU NIS2 Art.21 vulnerability handling and disclosure, and ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The component this flaw executes through is a retired one the OS still carries: the packet has Windows invoking the Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA because a shortcut asked for it by scheme. The vendor update fixes this defect; it does not take the engine off the host, and the invocation path that reached it is a handler the OS still resolves. The requirement here is that the compensating control an operator stands up before the update lands — an application-control policy that blocks the retired rendering path, and the HTA execution the packet describes, from being invoked out of an internet shortcut — is retained after the update with a stated review period, rather than rolled back as redundant once the fix is deployed. That is the cited least-functionality gap in operational form: least functionality reads as met because Internet Explorer is retired, while the engine behind it stays reachable to anything that names it. Preconditions: application control binds only where it is deployed and running in enforce rather than audit mode, and it governs the invocation, not the parsing — a host without that policy is carried by the update and its restart alone, and on a host where the policy is in audit mode the invocation still succeeds and is merely logged. Distinguishing test: on a fully updated managed workstation, open a test .url that uses the mhtml: scheme and confirm the policy refuses the invocation rather than the engine rendering the content; a least-functionality attestation recording that Internet Explorer is not installed passes cleanly while this path resolves.",
+        "evidence": "Packet attack_vector: 'A victim opens a crafted .url internet-shortcut whose URL uses the \"mhtml:\" scheme and an \"!x-usc:\" directive; Windows invokes the retired Internet Explorer/MSHTML engine to render attacker-hosted HTML/HTA, spoofing the perceived file type and executing code.' CWE-451; CISA KEV-listed 2024-07-09 with active_exploitation confirmed; RWEP 79, CVSS 7.5, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Citing gap names NIST SP 800-53 CM-7 (Least Functionality) as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-CM-7"
+        ]
+      }
+    ]
   },
   "CVE-2024-20399": {
     "name": "Cisco NX-OS Command Injection Vulnerability",
@@ -42867,7 +44246,32 @@
         "adequate": false,
         "gap": "Access enforcement failed at the application layer: the registration endpoint remained reachable and trusted a spoofed identity, so no downstream authorization control was consulted."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The registration endpoint is where Telerik Report Server decides whether a caller may hold an account, and this CVE is that decision failing open: the packet has an unauthenticated caller reach the endpoint on an already-configured instance and create an administrator through a spoofed request. Bound to this product, the control means the account-creation function on the Report Server authorizes its caller itself — an instance past initial setup refusing to enrol any account, and above all an administrator account, for a caller it has not authenticated — rather than deriving that verdict from attacker-supplied request content; and the Report Server's IIS-hosted surface is segmented so a caller with no operational need to reach it cannot present the spoofed request at all. The access-enforcement and identity-and-access controls cited as insufficient on this entry never engage on this path: the attacker holds no Report Server account, so per-account authorization is never consulted and the account model an identity attestation examines is bypassed rather than abused — the attacker supplies the account rather than abusing one. Distinguishing test: from a segment with no operational need for report administration, send unauthenticated account-creation requests to a staging Report Server that has already completed its initial setup, and confirm each is refused before any account exists; an attestation that every Report Server administrator authenticates at login passes cleanly while this path stays open. Precondition: the endpoint-side authorization is a property the vendor update establishes — this control states what to verify, it does not implement it. Until that update lands, restricting which segments can reach the Report Server bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable wherever report consumers must reach the server over the network. Segmentation also says nothing about an administrator account already created through this path: such an account survives both the segmentation change and the update, so an instance reachable during the exposure window needs its administrator accounts and account-creation events reviewed rather than being closed on the patch.",
+        "evidence": "The packet places the flaw in Progress Telerik Report Server, version 2024 Q1 (10.0.24.305) or earlier, on IIS, and describes an unauthenticated attacker gaining access to restricted functionality via authentication bypass by spoofing (CWE-290). The recorded attack path: an unauthenticated attacker reaches the Report Server registration endpoint on an already-configured instance and, via a spoofed request, creates a new administrator account, then commonly chains CVE-2024-1800 deserialization for remote code execution. CISA KEV-listed 2024-06-13 with confirmed in-the-wild exploitation, a public PoC, CVSS 9.8 and RWEP 68. The packet cites NIST-800-53-AC-3 (Access Enforcement), UK-CAF-B2 (Identity and access control), NIST-800-53-SC-7 (Boundary Protection) and NIS2-Art21-network-security as the framework controls this entry demonstrates are insufficient. It records a vendor patch, no live-patch path, and notes the vendor update as the remediation.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B2",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the cost argument that normally justifies a slow patch queue is absent: the packet records a vendor update with no live-patch path and states the update requires no reboot, so nothing about applying it needs a host outage window, which removes the usual reason a reporting server sits behind a 30-day application-patching cycle. Applied here the control means every Telerik Report Server instance is enumerated and taken past the affected build on the clock that opened with the 2024-06-13 KEV listing rather than on the next quarterly application cycle, with completion measured by the build each instance actually reports — the packet names version 2024 Q1 (10.0.24.305) or earlier as affected, so an instance still reporting that build or earlier is exposed regardless of what its patch-status field says. Enumerate instances by reachability first: the exploit precondition the packet states is simply reaching the registration endpoint of an already-configured instance, so an instance answering to a broad network population is where the KEV clock matters most. Priority follows the packet rather than the CVSS band alone: confirmed in-the-wild exploitation, a public PoC and the packet's note that the bypass is commonly chained into CVE-2024-1800 deserialization make this a remote-code-execution precursor, not a standalone account-creation defect. Precondition: the update closes the bypass, it does not remove an administrator account an attacker created before it landed and it does not undo anything executed through the chained deserialization step. An instance that was reachable during the exposure window needs an administrator-account and credential review alongside the upgrade, not instead of it — flaw-remediation and technical-vulnerability-management attestations both read clean on a server that is now patched and still carries the attacker's administrator.",
+        "evidence": "The packet records CISA KEV listing on 2024-06-13, active_exploitation confirmed, poc_available true, CVSS 9.8 and RWEP 68 for Progress Telerik Report Server, version 2024 Q1 (10.0.24.305) or earlier, on IIS. patch_available is true, live_patch_available is false, and live_patch_notes states: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" The packet's attack path is an unauthenticated spoofed request to the registration endpoint of an already-configured instance creating a new administrator account, commonly chained with CVE-2024-1800 deserialization for remote code execution. AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are cited as the insufficient controls.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-26169": {
     "name": "Microsoft Windows Error Reporting Service Improper Privilege Management Vulnerability",
@@ -42941,7 +44345,31 @@
         "adequate": false,
         "gap": "Mobile-device patching guidance cannot close a firmware logic flaw until the OEM update lands, so the control is insufficient against active zero-day use."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Pixel handsets take this fix as a vendor update that the packet says requires a reboot, with no live-patch path, so remediation is the update plus a restart on every affected device — and on a handset both steps sit with the user unless enrolment makes them mandatory. For this CVE the control means the update policy on managed Pixel devices is enforced rather than advisory: automatic installation of the security update, a mandated restart window, user deferral disallowed, and completion measured by the security patch level each device reports after it has restarted rather than by 'update pushed' or 'update downloaded'. The restart is the specific step that goes wrong here — the packet ties remediation to a reboot, so a Pixel that has taken the update and not restarted still runs the vulnerable code, and counting it as patched is how this remediation is recorded complete while the exposure stands. Priority follows the packet rather than the 7.8 base score: confirmed in-the-wild exploitation and a public PoC against an escalation that needs no additional execution privileges, on a device class that leaves the managed network every day. Precondition: enforcement reaches only devices the estate actually manages. An unenrolled or personally-owned Pixel carrying organizational data is outside this control's reach entirely, and is remediated by enrolling it or withdrawing the data from it, not by leaving it uncounted on a compliance report. And the update does nothing about a device already exploited during the window before it landed — with exploitation confirmed, a device on which the crafted application ran belongs on the incident path rather than being closed on its new patch level.",
+        "evidence": "The packet describes a logic-error bypass leading to local escalation of privilege with no additional execution privileges needed, and states that user interaction is needed for exploitation; the attack path is a locally present, crafted application escalating from an unprivileged context to system-level privileges on Pixel firmware / the Android Framework (CWE-670, CWE-783). CISA KEV-listed 2024-06-13, active_exploitation confirmed, poc_available true, CVSS 7.8, RWEP 73. patch_available is true, live_patch_available is false, and live_patch_notes states: \"No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.\" NIS2-Art21-patch-management, NIST-800-53-SI-2, AU-ISM-1546 and ISO-27001-2022-A.8.8 are cited as the insufficient controls.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "AU-ISM-1546",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records is a locally present, crafted application, and the escalation runs from an unprivileged context to system-level privileges with no additional execution privileges needed — so for this entry the control's access-condition half is the load-bearing one. Applied to the Pixel devices in the estate, the build carrying the fix has to function as an access condition: mail, VPN and document access denied to a Pixel below it, not the stale patch level surfacing as a row on a compliance dashboard while the device keeps its access. Because the packet ties remediation to a reboot, the condition must be evaluated against the patch level the device reports after restarting; a device that has installed but not restarted sits below the bar. Distinguishing test: enrol a Pixel pinned below the fixed build and confirm the policy actually denies it access to protected resources — an estate that reports the stale build while the handset keeps syncing mail has recorded the exposure rather than removed it. The least-privilege control cited as insufficient here is not the lever it appears to be: the escalation begins in an unprivileged context and crosses a privilege boundary inside the platform, so per-application privilege scoping is never the thing that fails and an AC-6 attestation passes cleanly while the flaw stays fully exploitable. Precondition: restricting untrusted or side-loaded application installation raises the bar for getting the attacker's application onto a device, but it does not evict an application already installed, and it does not cover one that arrived through the normal store channel; the packet's requirement of user interaction also means the delivery step runs through a user, which policy narrows but does not eliminate. A device suspected of already running the crafted application belongs on the incident path, not the install-policy path. This is a holding measure for the window before the update and its restart land, not a substitute for them.",
+        "evidence": "The packet's vector states there is a possible way to bypass due to a logic error in the code, leading to local escalation of privilege with no additional execution privileges needed, and that user interaction is needed for exploitation; the attack path is a locally present, crafted application bypassing a privilege boundary in Pixel firmware / the Android Framework to reach system-level privileges. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are cited as insufficient controls on this entry. The packet records patch_available true, live_patch_available false, and live_patch_notes stating the vendor update requires a reboot and is the remediation. It names no affected Pixel model or Android release, so no build or version is asserted here beyond \"the build carrying the vendor fix\".",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-4577": {
     "name": "PHP-CGI OS Command Injection Vulnerability",
@@ -43232,7 +44660,21 @@
         "adequate": false,
         "gap": "The gap between Google's emergency release and enterprise browser-relaunch rollout leaves a window that TAG-observed in-the-wild exploitation targets."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's delivery path is a user visiting a crafted HTML page, so nothing in the estate stands between a browsing user and the V8 type confusion except the build the browser is actually executing. For this CVE the control means the managed Chrome release channel is driven to 125.0.6422.112 or later on the clock that opened with the 2024-05-28 KEV listing, instead of riding an enterprise update ring that defers the security channel behind a validation soak — the ring's deferral is the whole exposure, because the packet gives the attacker a drive-by path that needs no credential, no attachment and no user decision beyond loading a page. Completion must be measured from the Chrome version each host actually reports in endpoint inventory, not from the update policy being configured or the package being marked approved or deployed in the management console; the packet records no live-patch primitive and names the vendor update (no reboot required) as the remediation, so a host that has fetched the fixed build while its browser is still running the old one is still exposed and must be counted as such. Scope this to the product the packet names — Google Chrome prior to 125.0.6422.112. The packet ties the type confusion to V8 in Chrome and provides no mapping into other software that embeds the same engine, so instructing operators to hunt every Chromium-derived or Electron-packaged binary in the estate manufactures findings and removal work against products no evidence here implicates; widen the inventory only where a verified source identifies another product shipping the affected V8 build. Distinguishing test: query the fleet for the Chrome version in service per host and confirm none reports below 125.0.6422.112 — an estate whose patch-compliance report reads clean because the update was approved, while hosts still report an earlier build, has recorded the exposure rather than removed it. Precondition: this control reaches only browsers the management channel can see and update. A per-user or unmanaged Chrome install outside managed software distribution is remediated by bringing it under management or removing it, not by recording the managed copy as patched.",
+        "evidence": "Packet facts for CVE-2024-5274: cisa_kev true with kev_date 2024-05-28; active_exploitation confirmed; cvss 9.6; rwep_score 54; poc_available false; patch_available true; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.'; ai_discovered false. Vector: 'Type Confusion in V8 in Google Chrome prior to 125.0.6422.112 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)'. Attack vector: 'A user visits a crafted HTML page that triggers a type confusion in V8; the attacker gains code execution and, per the scope-changed CVSS, can affect resources beyond the renderer sandbox.' CWE-843. Citing gaps include AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8, NIS2-Art21-patch-management and NIST-800-53-SI-2 — all patch-cadence controls that an OS/application patching attestation can pass while the browser's own release channel sits deferred.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2020-17519": {
     "name": "Apache Flink Improper Access Control Vulnerability",
@@ -43306,7 +44748,30 @@
         "adequate": false,
         "gap": "Endpoint malicious-code protection does not reliably stop in-renderer memory-corruption execution delivered from a legitimate-looking site."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's fix boundary for this CVE is a browser build number, not a configuration change: the vector states the type confusion is present in V8 in Google Chrome prior to 125.0.6422.60. Bound to that, the control means every managed Chrome/Chromium install on the estate is driven onto a build at or above 125.0.6422.60 on the security channel, with completion measured per endpoint by the version the browser actually reports rather than by the update policy showing as applied in the management console. The deferral question is the whole control here because the packet removes the usual excuse for it: live_patch_available is false but live_patch_notes record that the vendor update requires no reboot, so nothing about this remediation needs a user's machine taken out of service. What holds an endpoint on a vulnerable build is a pinned or extended-stable ring, a staged rollout percentage, or a user-deferrable relaunch — all policy, not constraint. The user-application-hardening measure cited as insufficient on this entry does not touch the path: the packet's trigger is a victim loading a crafted HTML page whose ordinary JavaScript reaches V8, so there is no plugin to disable, no macro to block and no download to gate, and a hardening attestation covering those settings passes cleanly while the browser build stays below the fix. Distinguishing test: enumerate the reported browser version on every managed endpoint and confirm none is below 125.0.6422.60; a fleet whose console shows the update approved and pushed while endpoints still report a pre-125.0.6422.60 build is not remediated. Scope this to the Chrome/Chromium installs the packet names — it identifies V8 in Google Chrome and gives no mapping from the vulnerable build into other JavaScript-executing software, so treating every browser or embedded web view in the estate as an instance of this CVE manufactures work against software no evidence in the packet implicates. Precondition: this reaches only installs under managed update policy; an unmanaged or per-user copy is remediated by bringing it under management or removing it, not by recording the fleet as patched.",
+        "evidence": "Packet facts only. vector: 'Type Confusion in V8 in Google Chrome prior to 125.0.6422.60 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)'. attack_vector: 'A victim visits an attacker-controlled page (a fake blockchain/game site in the observed campaign) that runs crafted JavaScript triggering a V8 type confusion, corrupting the heap and executing code inside the renderer sandbox.' cisa_kev true, kev_date 2024-05-20, active_exploitation 'confirmed', CVSS 9.6, RWEP 56, CWE-843, poc_available false, ai_discovered false. patch_available true; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' Cited as insufficient on this entry: AU-Essential-8-App-Hardening (User application hardening), ISO-27001-2022-A.8.8, NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the control fixes when the browser build has to land and what an operator is allowed to count as holding the line until it does. The clock opens at the 2026-era-agnostic fact the packet records: KEV listing 2024-05-20 with active_exploitation 'confirmed', against a product whose fix the packet says needs no reboot — so the interval between listing and a fleet-wide build at or above 125.0.6422.60 is measured in the estate's update-ring latency and nothing else. Where an endpoint genuinely cannot take the build inside that window, the packet supports exactly one compensating lever, and it is the delivery path rather than the vulnerable code: exploitation requires the victim's browser to load the attacker's crafted page, which in the observed campaign the packet describes as a fake blockchain/game site. Restricting which sites managed browsers may load — denying uncategorized and newly-observed destinations for the affected population — bounds who can be brought to the page. Precondition, and it must be written down as one rather than recorded as the mitigation: this bounds reach, it does not repair the type confusion. It gives nothing against a crafted page served from a domain the filter permits, and nothing at all for an endpoint that has already loaded one — with exploitation confirmed in the wild and no PoC needed by the attacker, a browser that ran the crafted script belongs on the incident path, not the filtering path. The packet registers no live-patch primitive and no vendor mitigation rule, so there is no third state to claim: an endpoint is either on the fixed build or it is running the vulnerable one behind a holding measure with a dated expiry. Distinguishing test: for every endpoint still below the fixed build, produce the named compensating measure and its removal date; an entry on the risk register with no build target and no expiry is deferral recorded as compliance.",
+        "evidence": "Packet facts only. cisa_kev true, kev_date 2024-05-20; active_exploitation 'confirmed'; poc_available false; ai_discovered false; RWEP 56, CVSS 9.6. patch_available true; live_patch_available false; live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' vector names the fixed boundary as Google Chrome prior to 125.0.6422.60. attack_vector: 'A victim visits an attacker-controlled page (a fake blockchain/game site in the observed campaign) that runs crafted JavaScript triggering a V8 type confusion, corrupting the heap and executing code inside the renderer sandbox.' Cited as insufficient on this entry: ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-43208": {
     "name": "NextGen Healthcare Mirth Connect Deserialization of Untrusted Data Vulnerability",
@@ -43555,7 +45020,22 @@
         "adequate": false,
         "gap": "This was an actively exploited zero-day at patch release; any remediation cadence slower than the May 2024 Patch Tuesday left endpoints escalatable to SYSTEM during live QakBot campaigns."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows DWM Core Library and describes local code triggering a heap buffer overflow — an integer-division size miscalculation in CCommandBuffer::Initialize — to corrupt heap memory and reach SYSTEM. The attacker is already executing on the host, so nothing about this escalation consults an account model; a memory-safety boundary inside a shipped OS component is failing. For this CVE the control means the Windows update carrying the DWM Core Library fix is driven across every affected host on the clock that opened with the 2024-05-14 KEV listing rather than folded into the next monthly rollup, and that completion is measured per host against the installed build rather than by 'approved' or 'downloaded' in the management console. The packet makes the restart the load-bearing step and the specific way this remediation gets recorded wrongly: live_patch_available is false and live_patch_notes state the vendor update requires a reboot and is the remediation, so a host that has installed the update and not yet restarted is still running the vulnerable DWM Core Library and must be counted as exposed. On a general desktop estate the restart is the step users defer indefinitely, which is exactly how a patch dashboard reads compliant over a fleet that still carries the flaw. Priority follows the packet rather than the 7.8 base score: a public PoC, confirmed in-the-wild exploitation, and the packet's record that QakBot chained this after initial access make it the containment step in an intrusion chain, not a routine endpoint item — every host that has taken an initial-access stage already satisfies this flaw's only precondition, which is local code execution. Distinguishing test: join the fleet's patch state to each host's last boot time and confirm no host reports the fix installed with a boot time preceding the install; any host in that set is exposed while the compliance report is green. Precondition and limit: this is a remediation-window control and nothing more. It does not detect exploitation, and on a host where the chain already ran, the reboot removes the vulnerable code but not the SYSTEM-level access the attacker established through it — with exploitation confirmed and the packet naming a chain after initial access, a host with corroborating intrusion evidence belongs on the incident path in parallel with, not after, the update.",
+        "evidence": "Packet facts only. attack_vector: 'Local code triggers a heap buffer overflow in the DWM Core Library caused by an integer-division size miscalculation in CCommandBuffer::Initialize, corrupting heap memory to gain SYSTEM privileges; QakBot chained it after initial access.' vector: 'Windows DWM Core Library Elevation of Privilege Vulnerability'. CWE-122 and CWE-787; cisa_kev true, kev_date 2024-05-14; active_exploitation 'confirmed'; poc_available true; ai_discovered false; RWEP 79, CVSS 7.8. patch_available true; live_patch_available false; live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' Cited as insufficient on this entry: AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2, UK-CAF-B4.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-4671": {
     "name": "Google Chromium Visuals Use-After-Free Vulnerability",
@@ -43666,7 +45146,30 @@
         "adequate": false,
         "gap": "Malicious-code protection that relies on SmartScreen/MotW mediation is defeated by a bypass that suppresses the very prompt operators expect to warn on internet-origin files."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "This is a protection-mechanism failure (CWE-693) in precisely the class the control names: the packet describes a file crafted so Windows fails to apply or honor the Mark-of-the-Web, and when the user extracts and runs it SmartScreen does not prompt and the payload executes. Applied here, the control means the estate's MOTW/SmartScreen battery is run as a regression suite on every Windows update deployment rather than once against this CVE — deliver the archive-borne sample through each ingress path to a managed test workstation, extract it, run it, and confirm both that the prompt fires and that the detonation chamber and EDR rules produce a record. The signal to assert on is the one the packet documents: a payload that runs with no prompt and an extracted file carrying no origin mark. A rule keyed on a process crash or on a named exploitation tool would miss this entirely, because nothing crashes and nothing anomalous runs — the payload executes through the ordinary user-launch path with the security prompt simply absent. This is what closes the cited malware-protection gaps: SmartScreen and the anti-malware stack being present and enabled is exactly what an SI-3 or A.8.7 attestation checks, and both pass on a host where the prompt is enabled and silently not firing. The incident-handling gap is that same defect seen from the response side — the bypass removes the user-visible and SmartScreen-side record of the execution, so unless the EDR and detonation-chamber rules are inside the regression battery there is no event for the process to handle. Precondition: the packet records a vendor update with no live-patching primitive and a reboot requirement, so a host that installed the update but has not restarted still carries the bypass and must be counted as exposed; this battery identifies which hosts still fail, it does not remediate them, and on a fleet where restart is routinely deferred that gap is where the residual exposure sits.",
+        "evidence": "Packet fields for CVE-2024-29988: cwe_refs CWE-693; name 'Microsoft SmartScreen Prompt Security Feature Bypass Vulnerability'; attack_vector 'An attacker delivers a file (often inside an archive) crafted so that Windows fails to apply or honor the Mark-of-the-Web; when the user extracts and runs it, SmartScreen does not prompt, and the payload executes. It is chained with WinRAR CVE-2023-38831 and CVE-2024-21412 for full delivery.'; cisa_kev true, kev_date 2024-04-30; active_exploitation confirmed; poc_available true; cvss 8.8; rwep_score 75; patch_available true; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'; citing_gaps include NIST-800-53-SI-3 (Malicious Code Protection), ISO-27001-2022-A.8.7 (Protection against malware) and NIS2-Art21-incident-handling.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-119",
+        "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
+        "description": "The packet puts the payload inside an archive and the failure at extraction: the file the user ends up running does not carry the untrusted-origin marking, so SmartScreen has nothing to prompt on. Applied to this CVE, the control means the mail gateway and file-share boundary apply the untrusted-origin marking themselves at ingress, and the archive handlers in the standard build are configured and tested so that marking is propagated to every file they write out — rather than the decision being derived from metadata that travels inside the attacker's own archive. This is what closes the user-application-hardening gap the packet cites: an Essential Eight hardening record covering macro, OLE, browser and PDF settings says nothing about whether an extracted executable arrives marked, and the delivery path the packet describes never touches a macro, so the attestation reads clean while the path stays open. Distinguishing test, keyed on the documented behaviour: deliver the archive through each ingress path — mail, web download, untrusted file share — to a managed workstation, extract it with each archive tool present in the build, and confirm every extracted file carries the untrusted-origin mark and that launching it produces the SmartScreen prompt. Precondition, and it is the load-bearing half: the packet says Windows fails to apply OR honor the mark. Boundary-applied provenance addresses the apply half by putting the mark on files that would otherwise arrive unmarked; it does nothing for the honor half, where the mark is present and the prompt still does not fire. Only the vendor update and its reboot close that half. This is therefore a holding measure that narrows the delivery path during the window before the reboot lands, not a substitute for it, and it reaches nothing delivered by a path the boundary does not mediate — removable media, or a device receiving files outside managed ingress.",
+        "evidence": "Packet fields for CVE-2024-29988: attack_vector 'An attacker delivers a file (often inside an archive) crafted so that Windows fails to apply or honor the Mark-of-the-Web; when the user extracts and runs it, SmartScreen does not prompt, and the payload executes. It is chained with WinRAR CVE-2023-38831 and CVE-2024-21412 for full delivery.'; cwe_refs CWE-693; cisa_kev true, kev_date 2024-04-30; active_exploitation confirmed; poc_available true; rwep_score 75; cvss 8.8; patch_available true; live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'; citing_gaps include AU-Essential-8-App-Hardening (User application hardening) and UK-CAF-B4 (System security). No fixed build number is asserted — the packet names none.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-4040": {
     "name": "CrushFTP VFS Sandbox Escape Vulnerability",
@@ -45486,7 +46989,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management as written does not elevate a KEV-listed, actively-exploited appliance flaw above routine CVEs, so it under-prioritises the emergency reboot window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A NetScaler ADC or Gateway configured as a Gateway or AAA virtual server is the remote-access trust boundary itself, and the packet's requests arrive at that boundary with no authentication, crash the packet engine and can read adjacent memory. The tier the frameworks lack is what applies here: remediation measured from the 2024-01-17 KEV listing rather than from the next appliance maintenance window, and completion measured per appliance rather than per version approved in a change record. The packet's own precondition scopes the work — the flaw is reached on an appliance configured as a Gateway or AAA virtual server, so the enumeration that gates remediation is which units carry that configuration, not how many NetScaler units exist. That distinction also determines whether the control's isolation half is available at all: where a unit carries an unused Gateway or AAA virtual server, removing that vserver removes the reachable path; where the vserver is in service, isolation is not a lever, because it is published to untrusted networks by design, and the fixed release is then the only remediation. State that plainly rather than recording 'restrict access to the management interface' as the interim mitigation — the exploited surface here is the user-facing remote-access vserver, not the management plane. The packet records no live-patch mechanism and states remediation requires applying the fixed release and rebooting, so an appliance that has taken the release without the reboot still runs the vulnerable code and must be counted as exposed. Distinguishing test: produce, per appliance, whether a Gateway or AAA virtual server is configured and the build actually running since its last restart; a fleet-wide change record showing the fixed release approved, against an appliance still serving on a pre-fix build, is a paper close.",
+        "evidence": "Packet: CISA KEV-listed 2024-01-17, active_exploitation confirmed, CVSS 7.5, RWEP 60, poc_available false. Vector: 'Improper Restriction of Operations within the Bounds of a Memory Buffer in NetScaler ADC and NetScaler Gateway allows Unauthenticated Denial of Service and Out-Of-Bounds Memory Read'. attack_vector: 'An unauthenticated attacker sends crafted requests to a NetScaler appliance configured as a Gateway or AAA virtual server, triggering an out-of-bounds memory operation that crashes the packet engine (denial of service) and can leak adjacent memory.' patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "What this exploitation emits is documented in the packet: unauthenticated requests to a Gateway or AAA virtual server, followed by packet-engine crashes, with adjacent memory read out. A packet-engine crash on its own is indistinguishable from a fault; it becomes evidence only when it can be correlated with the unauthenticated request that preceded it, and that correlation needs both records — the vserver access record and the crash/restart record — side by side. The appliance is the component failing, so its own storage is the least dependable place to hold them. For this device the control means NetScaler syslog together with the Gateway and AAA vserver access records forwarding to a SIEM in a separate trust zone with its own management plane and credentials, retained across the window between the 2024-01-17 KEV listing and the completion of the reboot each appliance requires. Precondition, stated rather than implied: this is a detection-and-evidence control, not a mitigation — it does not prevent the out-of-bounds read or the crash, it does not reduce the exposure of a unit serving a Gateway vserver, and it must never be the reason an appliance's fixed release and reboot are deferred. It also depends on the forwarding path being up: while the packet engine is down the stream stops, so a gap in the stream that brackets a restart is itself the signal to investigate, not an absence of one, and the collector has to alarm on an appliance that goes quiet rather than only on the events it sends.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends crafted requests to a NetScaler appliance configured as a Gateway or AAA virtual server, triggering an out-of-bounds memory operation that crashes the packet engine (denial of service) and can leak adjacent memory.' CISA KEV-listed 2024-01-17, active_exploitation confirmed, poc_available false, CVSS 7.5, RWEP 60. live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting' — the reboot is what bounds the window this retention has to cover. Citing gaps include UK-CAF-B4 (System security) and NIS2-Art21-network-security, neither of which requires appliance data-plane events to be retained off the appliance.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2023-6548": {
     "name": "Citrix NetScaler ADC and NetScaler Gateway Code Injection Vulnerability",
@@ -47111,7 +48637,41 @@
         "adequate": false,
         "gap": "Configuration management failed to strip a debug library from production, and mitigation requires re-securing configuration (remove file, disable phpinfo, rotate secrets), not just a version bump."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The disclosing endpoint here is neither ownCloud code nor a direct dependency of it: the packet places GetPhpInfo.php in a third-party library that the graphapi app bundles, at owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php — a test fixture, inside a vendored library, inside an application app, served by the same webserver as the product and reachable with no authentication. For this deployment the control means the inventory of an ownCloud installation reaches into apps/*/vendor/** rather than stopping at the enabled-app list or the top-level dependency manifest, records which of those bundled paths the webserver will actually serve, and treats a bundled tests/ directory as shipped web surface rather than as developer material that merely happens to be on disk. Without that reach, an operator cannot answer 'am I affected' at all, because no manifest they maintain names the file, and the affected range the packet gives is stated against the graphapi app version (0.2.x before 0.2.1, 0.3.x before 0.3.1) rather than against the bundled library. Precondition, stated by the packet directly: finding the file does not stop it answering, and neither does turning the app off — simply disabling the graphapi app does not eliminate the vulnerability. An inventory hit has to be routed into the removal-and-update path the packet names (delete the file, move graphapi to 0.2.1 or 0.3.1), not filed as a recorded dependency.",
+        "evidence": "The packet's vector: 'The graphapi app relies on a third-party GetPhpInfo.php library that provides a URL. When this URL is accessed, it reveals the configuration details of the PHP environment (phpinfo)', affecting 'owncloud/graphapi 0.2.x before 0.2.1 and 0.3.x before 0.3.1', and states that 'Simply disabling the graphapi app does not eliminate the vulnerability.' The full path owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php is given in the packet's live_patch_notes. attack_vector: an unauthenticated attacker requests the graphapi-bundled GetPhpInfo.php endpoint. KEV-listed 2023-11-30, active_exploitation confirmed, poc_available true, RWEP 69, CVSS 7.5.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "The packet records no live patch for this flaw, and the remediation it names is not one vendor step but four: delete owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php, update graphapi to 0.2.1 or 0.3.1, disable the container phpinfo function, and rotate all exposed credentials. The first and third are configuration-side actions the operator can take immediately on their own schedule, without waiting for an app update to be packaged, tested and rolled through the estate — which is exactly the path this control asks to be inventoried and rehearsed before a disclosure rather than improvised on a KEV clock. For this product that means knowing in advance where the app's vendored tree lives in each deployment, how a file is removed from it in a way that survives the next container start, and how the phpinfo function is disabled in the PHP configuration the ownCloud image ships. Preconditions: removing the file and disabling phpinfo close the path a new request takes; they retract nothing already returned, which is why the packet's own remediation list ends in rotating all exposed credentials — in containerized deployments those are the ownCloud admin password, the mail server credentials and the license key. Nor is the file removal durable on its own: a redeploy of an unpatched graphapi restores it, so the configuration-side path is a holding measure that has to be either baked into the image or superseded by the update to 0.2.1/0.3.1. And a deployment whose container predates February 2023 is out of scope for the credential disclosure per the packet, but not out of scope for the rest of the phpinfo output.",
+        "evidence": "The packet's live_patch_notes: 'No live patch; remove owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php, update graphapi to 0.2.1/0.3.1, disable the container phpinfo function, and rotate all exposed credentials.' live_patch_available is false; patch_available is true. The vector states that in containerized deployments the exposed environment variables 'may include sensitive data such as the ownCloud admin password, mail server credentials, and license key', that 'phpinfo exposes various other potentially sensitive configuration details' so the issue is a concern even outside a containerized environment, and that 'Docker containers from before February 2023 are not vulnerable to the credential disclosure.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This CVE produces a state worse than any of the three the control enumerates, and the packet calls it out explicitly: the action operators reach for first — disabling the graphapi app — does not eliminate the vulnerability, so a deployment recorded as mitigated on that basis is in the no-mitigation state while its compliance record says otherwise. For this entry the control means the vulnerability record for each ownCloud deployment separates the graphapi update to 0.2.1/0.3.1 (defect removed) from the configuration-side steps the packet names — removing the bundled GetPhpInfo.php and disabling the container phpinfo function — which are compensating controls a redeploy or image rebuild can silently revert and which therefore carry a dated action item to reach the update; and that 'graphapi disabled' is refused as a state at all rather than being filed under compensating control. The distinguishing test is to request the GetPhpInfo.php endpoint against each deployment the record calls remediated and confirm it does not return phpinfo output; a status field asserting the app is switched off is a claim about configuration, not evidence about what the webserver still serves to an unauthenticated request. Precondition: none of these verdict states speak to what was already read. The packet's remediation list ends with rotating all exposed credentials, so a deployment can be correctly recorded as patched while the admin password, mail server credentials and license key exposed during the window remain valid — the credential rotation needs its own record and its own closure.",
+        "evidence": "The packet's vector states 'Simply disabling the graphapi app does not eliminate the vulnerability.' live_patch_notes enumerate four distinct remediation actions — file removal, update to graphapi 0.2.1/0.3.1, disabling the container phpinfo function, and rotating all exposed credentials — with live_patch_available false and patch_available true. attack_vector: 'An unauthenticated attacker requests the graphapi-bundled GetPhpInfo.php endpoint, which returns full phpinfo() output.' KEV-listed 2023-11-30 with confirmed active exploitation and a public PoC.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-4911": {
     "name": "GNU C Library Buffer Overflow Vulnerability (Looney Tunables)",
@@ -47225,7 +48785,40 @@
         "adequate": false,
         "gap": "Protection-against-malware controls that depend on the OS trust prompt are insufficient when the file arrives without the MOTW marking that would trigger scanning/warnings."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "This CVE is the Mark-of-the-Web tag failing to be applied at all: the packet describes an attacker crafting a delivered file so Windows does not tag it, after which SmartScreen and Office Protected View do not trigger when the victim opens it. That makes half of this control inert here — requiring MOTW-tagged documents to open in Protected View does nothing for a file that carries no tag. The load-bearing half is the delivery boundary applying and preserving the untrusted-origin marking itself: the mail gateway, the web proxy and the untrusted file-share boundary mark externally-sourced files as they cross into the estate, so the sandbox decision is taken from provenance the operator established rather than from the OS tagging path this CVE defeats, and the marking survives the container it arrives in so extraction or renaming does not drop it. Distinguishing test keyed on the behaviour the packet documents: send, through each ingress path, a file constructed so Windows does not apply the tag, and confirm it still reaches the handler marked untrusted and opens in the reduced-privilege render — an attestation that Protected View and SmartScreen are enabled in policy passes cleanly against this CVE, because that policy is never consulted for a file that was never tagged. Precondition: this covers only channels that cross a boundary the operator controls. A file arriving on removable media, through a personal sync client, or over a channel the gateway cannot inspect still reaches the handler untagged, and for that population the only remaining lever is the Microsoft Windows October 2023 cumulative update the packet names — the packet records no live-patch path, so nothing restores the tagging behaviour on the host short of that update.",
+        "evidence": "Packet: CWE-693, 'Windows Mark of the Web Security Feature Bypass Vulnerability'. Attack path: 'An attacker crafts a delivered file so Windows fails to apply the Mark-of-the-Web tag; when the victim opens it, SmartScreen and Office Protected View do not trigger, smoothing execution of the next stage in a phishing chain.' CISA KEV 2023-11-16, active_exploitation confirmed, CVSS 5.4, RWEP 55, poc_available false. patch_available true, live_patch_available false; live-patch note: 'No live patch; requires the Microsoft Windows October 2023 cumulative update.' Cited gaps include AU-Essential-8-App-Hardening (User application hardening) and ISO-27001-2022-A.8.7 (Protection against malware).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "Mark-of-the-Web is one of the protection-mechanism classes this control names, and this entry is that class failing by construction — CWE-693, with the packet describing SmartScreen and Protected View not triggering because the tag was never applied. For this estate the control means the detonation chamber, the EDR rules and the application-control policy are regression-tested against the MOTW class on every patch deployment, with the battery built from the behaviour the packet documents rather than from tool signatures or process-crash indicators: deliver a file that arrives without the tag, confirm the estate still detonates and evaluates it, and confirm an alert fires when the handler that opened it launches the next stage of the chain. A battery that only shows SmartScreen prompting on a normally-tagged download validates the one path this CVE avoids, and will pass while the estate stays exposed. Precondition: this is a verification and detection control. It reveals that the class is still bypassable and gives a second signal when it is; it does not restore the tagging behaviour, which only the Microsoft Windows October 2023 cumulative update the packet names does. Because the packet records no live-patch path, an unpatched host stays bypassable however well the battery performs, and a behavioural alert that fires once the next stage has executed is a detection rather than a prevention — it shortens dwell time, it does not stop the chain.",
+        "evidence": "Packet: CWE-693 protection-mechanism failure; the attack path states that with the tag absent 'SmartScreen and Office Protected View do not trigger, smoothing execution of the next stage in a phishing chain.' active_exploitation confirmed; CISA KEV 2023-11-16; poc_available false. patch_available true, live_patch_available false; live-patch note names the Microsoft Windows October 2023 cumulative update as the requirement. Cited gaps include ISO-27001-2022-A.8.7 (Protection against malware), NIST-800-53-SI-4 (System Monitoring) and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.7",
+          "NIST-800-53-SI-4",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's own numbers are the argument for this control on this entry: CVSS 5.4 is the band most vulnerability-management programs schedule into a routine monthly cycle, while the packet records RWEP 55, a CISA KEV listing on 2023-11-16 and confirmed in-the-wild exploitation — because the bypass is a step that smooths a phishing chain rather than an impact in itself, and severity scoring of the step under-reads the chain. The control's clock is unusual here in a way worth stating: the fix the packet names, the Microsoft Windows October 2023 cumulative update, was already available when CISA listed the CVE, so on this entry the SLA is not waiting on a vendor — the measured quantity is the estate's own deployment lag, and hosts count as remediated by the build actually installed rather than by the update showing approved or downloaded in the management console. Precondition: this control governs deployment speed and nothing else. It says nothing about a file that already arrived untagged before the update landed, so the delivery-boundary and class-regression controls on this entry are not superseded by it; and because the packet records no live-patch path, there is no way to shorten the exposure window other than deploying the update itself.",
+        "evidence": "Packet: CISA KEV listed 2023-11-16 with active_exploitation confirmed; CVSS 5.4 against RWEP 55; poc_available false. patch_available true, live_patch_available false; live-patch note: 'No live patch; requires the Microsoft Windows October 2023 cumulative update' — an October 2023 update against a 2023-11-16 KEV listing. Cited gaps include NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-patch-management (Vulnerability handling and disclosure).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-1671": {
     "name": "Sophos Web Appliance Command Injection Vulnerability",
@@ -48041,7 +49634,31 @@
         "adequate": false,
         "gap": "Technical-vulnerability-management evidence (a CVE ticket) satisfies the audit without proving the reachable setup-restore endpoints were actually blocked or the instance patched."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The packet locates the failure on Confluence's setup-restore endpoints: they do not enforce authorization, so an unauthenticated caller reaches a function that resets the instance and creates an instance-administrator account. Bound to this product, the control means every administrative and setup/restore function on a self-hosted Confluence Data Center or Server node makes its own authorization decision before it acts, instead of inheriting a verdict from the request layer that fronts it, and those setup/restore paths are segmented so an untrusted caller cannot present a request to them at all. This is what closes the access-enforcement and identity-and-access gaps the packet cites, because neither is consulted on this path: the attacker holds no Confluence account when the reset runs, and holds an administrator account of their own making afterwards, so an attestation that every Confluence administrator is provisioned, reviewed and authenticated at login passes cleanly while the endpoint stays open. Distinguishing test: from a segment with no operational need to administer the wiki, issue unauthenticated requests to the setup and restore endpoints on a staging Data Center/Server instance and confirm each is refused before the function runs — confirming that the login page demands credentials tests a different path and passes regardless. Precondition: endpoint-side authorization is a property the vendor fixed release establishes; this control states what to verify, it does not implement it. Until that release is applied, restricting which segments can reach the instance bounds who can send the request but leaves the endpoints fully exploitable to anything inside the permitted segment, and that lever is unavailable where the wiki must stay broadly reachable to be useful. Scope is self-hosted only — the packet states Atlassian Cloud sites accessed via an atlassian.net domain are not affected, so this is not an instruction to audit a Cloud tenant.",
+        "evidence": "Packet fields for CVE-2023-22518: cwe_refs CWE-863; vector 'All versions of Confluence Data Center and Server are affected... This Improper Authorization vulnerability allows an unauthenticated attacker to reset Confluence and create a Confluence instance administrator account. Using this account, an attacker can then perform all administrative actions that are available to Confluence instance administrator leading to - but not limited to - full loss of confidentiality, integrity and availability', and 'Atlassian Cloud sites are not affected by this vulnerability. If your Confluence site is accessed via an atlassian.net domain, it is hosted by Atlassian and is not vulnerable to this issue'; attack_vector 'An unauthenticated attacker reaches the setup-restore endpoints, which fail to enforce authorization, resetting the Confluence instance and letting the attacker create an instance-administrator account and take full control'; cisa_kev true, kev_date 2023-11-07; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 70; citing_gaps include NIST-800-53-AC-3 (Access Enforcement) and UK-CAF-B2 (Identity and access control).",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the SLA can only run to the vendor fixed release, because the packet records no vendor live-patch mechanism: there is no interim binary mitigation to deploy, so between the 2023-11-07 KEV listing and the upgrade the operator's only levers are cutting untrusted reachability to the setup/restore endpoints and taking the release. Completion must be measured per Confluence node against a fixed version, not per estate, because the packet states all versions of Data Center and Server are affected — an organization that upgraded its primary wiki while a departmental, archived or staging node kept an older build has an unmitigated instance, and that node is reachable by exactly the same unauthenticated request. Precondition, and the reason this control does not end the incident: the exploit's product is a persistent instance-administrator account. Applying the fixed release restores authorization on the endpoint but does not delete an account created through it before the upgrade landed, and does not undo the instance reset the packet describes. Any node that was reachable by untrusted callers during the exposure window therefore needs its administrator list and instance audit history compared against a known-good baseline and its credentials rotated, rather than being closed out on the version bump — active exploitation is confirmed and a public PoC is recorded, so an exposed node should be treated as having been reached until evidence says otherwise.",
+        "evidence": "Packet fields for CVE-2023-22518: cisa_kev true with kev_date 2023-11-07; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 70; patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'; vector states all versions of Confluence Data Center and Server are affected and that the unauthenticated attacker resets Confluence and creates an instance administrator account able to perform all administrative actions; citing_gaps include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-handling. The packet names no fixed version string, so none is asserted here.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2023-46604": {
     "name": "Apache ActiveMQ Deserialization of Untrusted Data Vulnerability",
@@ -50617,7 +52234,41 @@
         "adequate": false,
         "gap": "A.8.8 would surface FG-IR-25-934 as a vulnerability to patch, but because exploitation requires an existing filesystem-level compromise, A.8.8's patch-centric remedy never triggers the compromise-recovery process needed to remove the attacker's symlink foothold."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This CVE is the case the control exists for, stated by the advisory text itself: the flaw bypasses the patch developed for the symbolic-link persistency mechanism observed in some post-exploit cases, and its stated precondition is an attacker who has already compromised the product via another vulnerability, at filesystem level. On a FortiOS unit with evidence of that prior compromise, the upgrade is not eviction — it closes the current bypass while leaving whatever the attacker placed on the filesystem, and the packet shows this is the second time a patch has been asked to do that job and the second time it did not hold. For such a unit the default response is configuration extraction for review, rebuild from vendor image, and rotation of the credentials the device held or handled — administrative accounts first, then the SSL-VPN user credentials, since the packet's outcome is re-exposure of sensitive files on the device and restoration of the attacker's foothold through the SSL-VPN web surface. Preconditions, both directions: the rebuild path applies only to units with evidence of prior filesystem-level compromise; for every other affected unit the vendor upgrade is the remediation and is still mandatory. And the upgrade is required on the rebuilt unit too — the packet records no live-patch mechanism and states remediation requires upgrading to FortiOS 7.6.2 / 7.4.7, or migrating 7.2 / 7.0 / 6.4 to a supported fixed release, which reboots the appliance, so an image restored to a pre-fix build reopens the same path. What this control refuses is the reverse substitution: treating the upgrade as eviction on a device whose filesystem an attacker already reached.",
+        "evidence": "Packet vector: the flaw in FortiOS 7.6.0-7.6.1, 7.4.0-7.4.6, 7.2 all versions, 7.0 all versions and 6.4 all versions 'may allow a remote unauthenticated attacker to bypass the patch developed for the symbolic link persistency mechanism observed in some post-exploit cases, via crafted HTTP requests. An attacker would need first to have compromised the product via another vulnerability, at filesystem level.' attack_vector: an attacker who has already compromised a FortiOS device at the filesystem level 're-create[s] the symbolic-link read Fortinet's earlier patch was designed to block, re-exposing sensitive files and restoring post-exploit persistence.' CISA KEV-listed 2026-07-27, active_exploitation confirmed. patch_available true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism for FortiOS; remediation requires upgrading to FortiOS 7.6.2 / 7.4.7 (or migrating 7.2/7.0/6.4 to a supported fixed release), which reboots the appliance.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet names this defect's position in a sequence rather than leaving it to be inferred: it bypasses the patch developed for the symbolic-link persistency mechanism, so it is at minimum the second entry on that same primitive and the earlier fix is now demonstrated incomplete. Two consequences for how a FortiOS vulnerability queue treats it. Its own ranking first: the packet records CVSS 5.9 and RWEP 46, a mid-band pair that a severity-sorted queue places behind higher-scored appliance items, against a KEV listing of 2026-07-27 and confirmed in-the-wild exploitation of a mechanism whose entire function is restoring an attacker's foothold on a device that was already compromised. The multiplier is what corrects that ordering, and on this entry it is the difference between the upgrade landing in the current cycle and landing in the next one. Its forward implication second: a primitive that has now been patched once and bypassed once should be carried as likely to be bypassed again, so the symbolic-link read path reachable through the FortiOS SSL-VPN belongs on a standing watch list for the next advisory rather than being closed out when 7.6.2 / 7.4.7 is deployed. Distinguishing test: ask the vulnerability-management program to produce, for this CVE, the record linking it to the earlier symlink-persistency fix it bypasses; a program that scores each Fortinet advisory as a discrete mid-band item cannot produce that link, and will rank the next bypass on the same primitive exactly the same way. Precondition: this control changes prioritization and tracking only — it schedules the upgrade sooner, it does not remediate anything on its own.",
+        "evidence": "Packet vector: the flaw 'may allow a remote unauthenticated attacker to bypass the patch developed for the symbolic link persistency mechanism observed in some post-exploit cases, via crafted HTTP requests' — the packet identifies the bypassed prior patch on the same primitive. CVSS 5.9, RWEP 46, poc_available false, CISA KEV-listed 2026-07-27, active_exploitation confirmed. live_patch_notes: remediation requires upgrading to FortiOS 7.6.2 / 7.4.7 (or migrating 7.2/7.0/6.4 to a supported fixed release), which reboots the appliance; live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet's stated precondition settles where this appliance's logs can be trusted: the attacker already holds the device at filesystem level, so on-box records are attacker-writable, and the exact events that matter — the crafted HTTP requests to the SSL-VPN that re-create the symbolic-link read, and the file reads that follow — are the ones an attacker on the box has both motive and access to remove. Those requests also arrive through the same web surface that serves legitimate SSL-VPN users, so they are separable in the record rather than at the connection. For this appliance the control means FortiOS event and traffic logs, including SSL-VPN web request and file-access events, forwarding to a collector in a separate trust zone with its own credentials and management path, retained across the whole exposure window rather than the appliance's local rotation. Preconditions, and they are the load-bearing part here: this preserves evidence and makes the re-persistence visible, it does not block the symbolic-link read and it does not substitute for the upgrade to FortiOS 7.6.2 / 7.4.7 (or migration off 7.2 / 7.0 / 6.4) and the reboot that upgrade requires. On a device already compromised at filesystem level the attacker can also stop the forwarder, so the collector must alarm on a FortiOS unit that goes silent and a silent unit must be treated as an incident rather than a logging fault. And it gives nothing retroactively: a device compromised before forwarding was configured has no off-box record to consult, which is why this has to be standing configuration rather than a response to this advisory.",
+        "evidence": "Packet attack_vector: 'An attacker who has already compromised a FortiOS device at the filesystem level sends crafted HTTP requests to the SSL-VPN that re-create the symbolic-link read Fortinet's earlier patch was designed to block, re-exposing sensitive files and restoring post-exploit persistence.' Vector states the attacker 'would need first to have compromised the product via another vulnerability, at filesystem level.' CISA KEV-listed 2026-07-27, active_exploitation confirmed, poc_available false. live_patch_available false; live_patch_notes: remediation requires upgrading to FortiOS 7.6.2 / 7.4.7 (or migrating 7.2/7.0/6.4 to a supported fixed release), which reboots the appliance. Citing gap UK-CAF-B4 (System security) does not require appliance logs to be held outside the appliance.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-16812": {
     "name": "Arista VeloCloud Orchestrator On-Prem OS Command Injection Vulnerability",
@@ -50922,7 +52573,40 @@
         "adequate": false,
         "gap": "A.5.15 access control relies on an enforced authorization model; the insufficiently restrictive HTTPD configuration in Sentry <= 9.18.0 bypasses that model on the admin API, so documented access-control policy does not prevent the unauthenticated administrative takeover exploited in 2023."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Ivanti MobileIron Sentry is the device-management gateway this control governs, and only the authorization half of it is load-bearing here — this flaw carries no attacker-supplied file or path, so the input-neutralization half has nothing to act on. The packet places the defect in an insufficiently restrictive Apache HTTPD configuration fronting the MICS Admin Portal: the administrative interface takes its authentication verdict from that fronting configuration instead of deciding it at the function, so an unauthenticated request to TCP/8443 reaches the System Manager API behind it and runs commands as root. Bound to this product, the control means each MICS administrative function on Sentry authorizes its own caller before the function executes, and no Sentry appliance is left with TCP/8443 reachable from a segment with no operational need to administer it. This is also why the access-control and identity gaps recorded against this entry cannot close the path: the attacker never authenticates as any Sentry administrator, so per-account privilege scoping is never consulted and the account model those attestations examine is bypassed rather than abused. Distinguishing test: from a segment with no Sentry administration role, send an unauthenticated request to the MICS Admin Portal on TCP/8443 of a staging appliance and confirm it is refused before the System Manager API is reached — an attestation that every Sentry administrator authenticates at login passes cleanly while this path stays open. Precondition: the endpoint-side authorization is a property the Ivanti fixed release establishes; this control states what to verify, it does not implement it. The packet records a vendor patch with no live-patch path, so remediation is upgrading Sentry 9.18.0 and below to the Ivanti fixed release and restarting the appliance. Until that lands, restricting which segments can reach TCP/8443 bounds who can send the request but leaves the portal fully exploitable to anything inside the permitted segment, and it is unavailable wherever the administrative interface must stay reachable for normal operation.",
+        "evidence": "Packet: CWE-863 in the MICS Admin Portal of Ivanti MobileIron Sentry 'versions 9.18.0 and below, which may allow an attacker to bypass authentication controls on the administrative interface due to an insufficiently restrictive Apache HTTPD configuration'. Attack path: 'An unauthenticated request to the MICS admin portal on TCP/8443 bypasses authentication ... then abuses the System Manager API to execute commands as root and drop a webshell.' CVSS 9.8, RWEP 76, poc_available true, CISA KEV 2023-08-22, active_exploitation confirmed. patch_available true, live_patch_available false; live-patch note: 'remediation requires upgrading Sentry to the Ivanti fixed release (RPM/appliance update) and restarting the appliance'. Cited gaps on this entry include boundary protection (NIST-800-53-SC-7) and access control / identity management (ISO-27001-2022-A.5.15, UK-CAF-B2, NIS2-Art21-identity-management).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.5.15",
+          "NIS2-Art21-identity-management",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's chain does not stop at authentication bypass: it ends in command execution as root and a webshell dropped on the Sentry appliance, with exploitation confirmed in the wild since the 2023-08-22 KEV listing. Applying the Ivanti fixed release to an appliance that was reachable during that window replaces the permissive Apache HTTPD configuration but leaves in place anything the attacker wrote with root privilege — the webshell the packet names is the first artifact to expect, not the only one that fits the primitive. Bound to this product, the control means any Sentry whose MICS Admin Portal on TCP/8443 was reachable during the exposure window is handled as compromised until shown otherwise: configuration and logs pulled off for analysis, the appliance rebuilt onto the fixed release from vendor media rather than upgraded in place, and every credential the MDM handled rotated — which is the packet's own remediation instruction, not an addition to it. Distinguishing test: for each remediated appliance, show the build in service came from a rebuild or vendor-media restore and that MDM-handled credentials were rotated; an appliance whose upgrade completed while its filesystem was never examined satisfies a flaw-remediation attestation and still carries the webshell. Precondition: a rebuild removes only what is on the appliance. It does not invalidate credentials or trust material the attacker already read, which is why rotation belongs in the same action rather than as a follow-up; and restoring a configuration backup taken inside the exposure window can carry attacker-modified configuration back onto the clean build, so configuration is re-applied selectively rather than wholesale.",
+        "evidence": "Packet: attack path is 'An unauthenticated request to the MICS admin portal on TCP/8443 ... then abuses the System Manager API to execute commands as root and drop a webshell.' active_exploitation confirmed; CISA KEV 2023-08-22; RWEP 76; poc_available true. patch_available true, live_patch_available false, with the live-patch note requiring 'upgrading Sentry to the Ivanti fixed release (RPM/appliance update) and restarting the appliance, plus rotating any credentials handled by a potentially compromised MDM'. The entry's cited patch gap is AU-Essential-8-Patch (Patch operating systems).",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet ties this appliance to an MDM — its remediation note requires rotating any credentials handled by a potentially compromised MDM — so a root-level compromise of Sentry has a blast radius measured in managed devices and the credentials that flowed through them, not in one appliance. The playbook for this product hunts what the packet documents rather than a generic malware signature sweep: requests to the MICS Admin Portal on TCP/8443 with no preceding authentication event, command execution in root context originating from the System Manager API, and content written into the paths the appliance serves (the webshell). The window opens at the earliest date the portal was reachable, and inside it the playbook's actions are the identity ones frameworks do not prescribe post-compromise: rotate every credential the MDM handled, invalidate device-trust state, and review configuration profiles pushed to managed devices during the window. Precondition: these actions must be issued from a control plane the attacker does not hold. Pushing revocations or profiles from a Sentry that is still compromised routes them through the attacker's foothold, so the appliance rebuild precedes them. And this is a response capability, not a fix — it repairs nothing in the authorization path, and it only helps if it was rehearsed before the 2023-08-22 listing rather than drafted during the incident.",
+        "evidence": "Packet: live_patch_notes states remediation includes 'rotating any credentials handled by a potentially compromised MDM'; the product is Ivanti MobileIron Sentry. Attack path reaches 'execute commands as root and drop a webshell' from an unauthenticated request to the MICS admin portal on TCP/8443. active_exploitation confirmed; CISA KEV 2023-08-22; CVSS 9.8; RWEP 76. Cited gaps include NIS2-Art21-identity-management (Identity and access management) and ISO-27001-2022-A.5.15 (Access control).",
+        "gap_closes": [
+          "NIS2-Art21-identity-management",
+          "ISO-27001-2022-A.5.15"
+        ]
+      }
+    ]
   },
   "CVE-2023-27532": {
     "name": "Veeam Backup & Replication Cloud Connect Missing Authentication for Critical Function Vulnerability",
@@ -52372,7 +54056,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would rank this high (RCE, KEV), but on mobile endpoints the only remediation is the SMR Oct-2021 firmware update, so A.8.8's assessment is meaningless without an enforced mobile-patch/EOL policy that retires handsets past support."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The Samsung fix the packet names, SMR Oct-2021 Release 1, predates the 2023-06-29 KEV listing by well over a year, so what this control manages on this entry is uptake rather than availability: handsets sat below a build that had shipped long before CISA listed the flaw as exploited. Applied to a Samsung estate, it means enrolled devices are driven to a reported security-patch level at or above SMR Oct-2021 Release 1 on the KEV clock through the management platform, with the handset user unable to defer indefinitely — the packet records remediation as a device update that reboots the handset, and a reboot the user keeps postponing is the specific way this one goes unremediated while the management console shows the update as delivered. Completion must therefore be measured by each device reporting its actual security-patch level, never by 'pushed', 'downloaded' or 'approved'. Precondition: this reaches only handsets the management platform enrols. A personally-owned Samsung device carrying corporate mail without enrolment sits entirely outside the control, and a handset whose model or carrier channel no longer receives Samsung maintenance releases cannot be driven to the fixed level at all — those two populations belong on an access-denial or replacement path, and counting them as 'pending update' is how they stay in service unremediated. The packet records no live-patch mechanism for the modem driver, so there is no interim binary mitigation this SLA could substitute for the firmware update.",
+        "evidence": "Packet fields for CVE-2021-25487: name 'Samsung Mobile Devices Out-of-Bounds Read Vulnerability'; cwe_refs CWE-125; vector 'Lack of boundary checking of a buffer in set_skb_priv() of modem interface driver prior to SMR Oct-2021 Release 1 allows OOB read and it results in arbitrary code execution by dereference of invalid function pointer.'; cisa_kev true with kev_date 2023-06-29; active_exploitation confirmed; poc_available false; cvss 7.8; rwep_score 48; patch_available true; live_patch_available false with live_patch_notes 'No live-patch mechanism for the modem driver; remediation is the Samsung SMR Oct-2021 Release 1 (or later) firmware update, applied via a device update that reboots the handset.'; citing_gaps include AU-Essential-8-Patch, NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-patch-management.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records is a local, low-privileged application on the handset reaching set_skb_priv() in the modem interface driver and obtaining arbitrary code execution in a privileged kernel/driver context. On a device still below SMR Oct-2021 Release 1 the only levers the operator holds are what code is allowed to run on it and what organizational data it is permitted to hold, so the fixed security-patch level has to function as an access condition — corporate mail, VPN and document access refused to a Samsung handset reporting a level below SMR Oct-2021 Release 1 — rather than as a row on a patch-compliance report. The distinguishing test is to enrol a handset pinned below that level and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale patch level on a dashboard while the device keeps its mail and VPN sessions has recorded the exposure rather than removed it. Precondition: restricting side-loaded and untrusted application installation raises the bar for getting the attacker's app onto the handset, but it does not remove an app already installed and it does not cover one that arrived through the normal store channel — a device suspected of already running such an app belongs on the incident path, not the install-policy path. And because the flaw yields execution in a privileged kernel/driver context, no on-device application-level restriction contains the escalation once that app runs; the access condition limits what a compromised handset can reach and hold, it does not stop the compromise. This is a holding measure for the window before the SMR Oct-2021 Release 1 firmware update and its handset reboot land, not a substitute for them. Prioritisation follows the confirmed in-the-wild exploitation and the 2023-06-29 KEV listing rather than exploit availability — the packet records no public proof-of-concept for this entry.",
+        "evidence": "Packet fields for CVE-2021-25487: attack_vector 'A local, low-privileged app triggers an out-of-bounds read in the modem interface driver's set_skb_priv(); the OOB access results in dereferencing an invalid function pointer, giving arbitrary code execution in a privileged kernel/driver context.'; vector names the buffer boundary-check failure in set_skb_priv() prior to SMR Oct-2021 Release 1; cwe_refs CWE-125; cisa_kev true, kev_date 2023-06-29; active_exploitation confirmed; poc_available false; cvss 7.8; rwep_score 48; ai_discovered false; patch_available true; live_patch_available false with live_patch_notes 'No live-patch mechanism for the modem driver; remediation is the Samsung SMR Oct-2021 Release 1 (or later) firmware update, applied via a device update that reboots the handset.'; citing_gaps include ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and UK-CAF-B4 (System security).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-25489": {
     "name": "Samsung Mobile Devices Improper Input Validation Vulnerability",
@@ -53590,7 +55297,43 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management assumes staged remediation, but for an unauthenticated RCE on the network boundary device, standard triage SLAs left the perimeter firewall exploitable during the very window mass-scanning targeted."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The vulnerable notification function runs on the appliance that terminates the perimeter itself — the packet names the ATP, USG FLEX, USG FLEX 50(W), USG20(W)-VPN, VPN and ZyWALL/USG series — and the overflow is reachable without authentication, so a routine firewall-firmware maintenance window is the wrong tier for it. Run the clock from the 2023-06-05 KEV listing through the fixed firmware on every affected unit, and treat the reboot the packet requires as part of remediation rather than as a follow-up: a unit with the image staged but not restarted is still running the vulnerable build. Precondition on the interim measure: the packet names restricting any exposed management interface as a step to take after the upgrade and never states that the notification function is reachable only through that interface, so management-access restriction is a reachability reduction, not a substitute for the firmware upgrade — a unit left on an affected build with management locked down must still be carried as exposed, not as mitigated. The distinguishing test: enumerate every affected series in the estate and confirm each unit reports a build past its own series' affected range; the packet's ranges end at 5.36 Patch 1 for the ATP, USG FLEX, USG FLEX 50(W), USG20(W)-VPN and VPN series but at 4.73 Patch 1 for ZyWALL/USG, so one target build applied estate-wide is not evidence that each series is remediated.",
+        "evidence": "Packet: buffer overflow (CWE-120) in the notification function that 'could allow an unauthenticated attacker to cause denial-of-service (DoS) conditions and even a remote code execution on an affected device'; CVSS 9.8, RWEP 77, poc_available true, active_exploitation confirmed, CISA KEV-listed 2023-06-05. Affected firmware per the packet: ATP, USG FLEX, USG FLEX 50(W), USG20(W)-VPN and VPN series 4.60 through 5.36 Patch 1; ZyWALL/USG series 4.60 through 4.73 Patch 1. patch_available true, live_patch_available false; the packet's remediation note is upgrading to the Zyxel fixed firmware (5.36 Patch 2 or later for the affected series) and rebooting the appliance, after which any exposed management interface should be restricted.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records confirmed in-the-wild exploitation of an unauthenticated path that reaches code execution on the appliance, which makes 'upgraded to the fixed firmware' the wrong closure test for any Zyxel unit that was reachable while it sat on an affected build. Default the runbook for those units to exporting the configuration for analysis, rebuilding from the vendor image, and rotating the secrets the appliance held — its administrative accounts and the credentials and keys it used for the VPN services these series terminate, the packet naming the VPN series and USG20(W)-VPN among the affected products — rather than upgrading in place and closing the ticket. Precondition: a rebuild removes only what lives in the configuration and firmware the vendor image replaces, and rotation only reaches secrets the operator can actually enumerate; where neither holds for a given unit, the honest outcome is that the unit is carried as suspect rather than recorded as remediated. Scope: this default applies to units that were reachable on an affected build — a unit that can be shown from off-box evidence never to have been exposed is an upgrade case, and separating the two populations is what that evidence is for.",
+        "evidence": "Packet: active_exploitation confirmed and CISA KEV-listed 2023-06-05, with poc_available true; the flaw allows an unauthenticated attacker to reach remote code execution on the affected device. Affected products include the VPN series and USG20(W)-VPN alongside ATP, USG FLEX, USG FLEX 50(W) and ZyWALL/USG. patch_available true and live_patch_available false, with remediation given as upgrading to the fixed firmware and rebooting the appliance — an action the packet describes as a firmware change, with nothing in it addressing state an attacker left behind.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "Deciding which Zyxel units get rebuilt and which merely get upgraded needs evidence the appliance itself cannot be trusted to hold: the packet's flaw produces both denial-of-service conditions and code execution on the device, so the record of the request that caused either is within reach of the exploit. Forward syslog and authentication logs from every ATP, USG FLEX, USG FLEX 50(W), USG20(W)-VPN, VPN-series and ZyWALL/USG unit to a collector in a separate trust zone with its own credentials and management path, and key review on what this specific exploitation emits — unauthenticated requests reaching the notification function, and unexplained appliance crashes or restarts correlated with them, since the packet gives denial of service as an outcome of the same crafted request that carries the code-execution case. Precondition: this covers only events emitted after forwarding was configured, and only where the collector is not administered from the same management plane and credentials as the firewall — a collector an attacker reaches with the appliance's own admin credentials preserves nothing. It therefore cannot reconstruct exposure predating the forwarding, which is why units already exposed on an affected build default to rebuild rather than to a log-based clean verdict.",
+        "evidence": "Packet: the crafted request to the notification function 'could allow an unauthenticated attacker to cause denial-of-service (DoS) conditions and even a remote code execution on an affected device' — both the crash and the code-execution outcome originate from the same unauthenticated path. active_exploitation confirmed, CISA KEV-listed 2023-06-05, poc_available true, RWEP 77. Affected series per the packet: ATP, USG FLEX, USG FLEX 50(W), USG20(W)-VPN, VPN and ZyWALL/USG.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2023-33010": {
     "name": "Zyxel Multiple Firewalls Buffer Overflow Vulnerability (CVE-2023-33010)",