@blamejs/exceptd-skills 0.19.10 → 0.19.12

package/data/zeroday-lessons.json

@@ -7690,7 +7690,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": "Catalyst SD-WAN Manager is the management plane the packet names, and the defect sits on its API interface: improper file handling lets an uploaded file drive a privileged API into overwriting arbitrary files on the system, ending in vmanage user privileges. Bound to this product, the control means every file-accepting API endpoint on SD-WAN Manager authorizes its caller before the upload is processed at all, and normalizes and validates the destination path before the privileged write executes, so a caller-supplied name cannot select which file gets overwritten; and no SD-WAN Manager instance is left with that API interface reachable from a segment with no operational need to reach it. The packet's own summary describes the path as reachable by an unauthenticated attacker, which is why the endpoint's own authorization decision — not the surrounding account model — is the only thing standing between an untrusted caller and a privileged file write. This is also why the cited least-privilege gap does not close this path: the attacker never holds a vManage operator account, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the path stays open. Distinguishing test: on a staging SD-WAN Manager, send each file-accepting API endpoint an unauthenticated upload whose destination path resolves outside the intended upload directory, and confirm it is refused before anything is written. Precondition: the endpoint-side authorization and path validation are properties the vendor update establishes — this control states what to verify, it does not implement it. Until that update and its restart land, restricting which segments can reach the API interface bounds who can send the upload but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable where the API interface must stay reachable for normal operation.",
+        "evidence": "Packet vector: 'Cisco Catalyst SD-WAN Manager contains an incorrect use of privileged APIs vulnerability due to improper file handling on the API interface of an affected system. An attacker could exploit this vulnerability by uploading a malicious file on the local file system. A successful exploit could allow the attacker to overwrite arbitrary files on the affected system and gain vmanage user privileges.' Packet attack_vector: 'an incorrect use of privileged APIs (CWE-648) reachable by an unauthenticated attacker, enabling privileged actions on the management plane.' Citing gaps record NIST-800-53-AC-6 (Least Privilege) against this entry. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive the packet records is an arbitrary file overwrite on the SD-WAN Manager host carried out with vmanage privileges — so the exposed asset is not one upload directory but every file that management plane holds. Applied to this product, the control means treating the SD-WAN Manager installation as privileged content rather than as application data: file-integrity-monitor the installation and the directories its API writes into, and alert on any write that does not correspond to a sanctioned administrator action or a vendor update. This is the control that still has value after the update lands, because the fix closes the write path but removes nothing already written through it — a file overwritten or planted before remediation survives the upgrade and the restart. With exploitation confirmed and a public exploit recorded in the packet, an instance whose API interface was reachable before remediation needs forensic triage of what was written rather than being closed on the patch. Precondition: integrity monitoring is a detection and triage control, not a preventive one — it does not stop the overwrite, and it only yields an answer where a known-good baseline of the installation predates the exposure window. Where no such baseline exists, the honest position is that the overwritten set is unknown and the instance is a rebuild candidate, not a patched-and-cleared one.",
+        "evidence": "Packet vector: a successful exploit 'could allow the attacker to overwrite arbitrary files on the affected system and gain vmanage user privileges.' Packet: active_exploitation confirmed, poc_available true, CISA KEV listed 2026-04-20, RWEP 77, CVSS 8.8. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is KEV-listed with confirmed exploitation and a public exploit recorded, and the packet gives a vendor patch, no live-patch path, and a fix that per the KEV requiredAction typically requires a service restart or system reboot. For this CVE the SLA's completion criterion is therefore each SD-WAN Manager instance running the fixed build after that restart has been taken — not 'update staged', 'change request raised', or a KEV due-date row marked closed on the management console. Where the restart cannot be taken inside the window, the documented compensating control this SLA permits is restricting reachability of the API interface to the operator segments with an operational need for it, and that restriction has to be written down as the active mitigation with a dated action item tied to the restart, not silently counted as remediation. Precondition: the reachability restriction bounds who can send the upload the packet describes; it does not repair the file-handling defect. Any host inside the permitted segment still reaches the vulnerable endpoint with the full primitive, so the restriction is a holding measure for the window before the restart, never a substitute for it.",
+        "evidence": "Packet: CISA KEV listed 2026-04-20, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 8.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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-20133": {
     "name": "Cisco Catalyst SD-WAN Manager Exposure of Sensitive Information to an Unauthorized Actor Vulnerability",
@@ -13585,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",
@@ -13645,7 +13698,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-118",
+        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
+        "description": "The packet states this exploit's only access requirement outright: an unauthorized user would require network access to the controller. So on this entry the segmentation half of this control is the load-bearing half, and the credential-elimination half is not a lever the operator holds — the key that authenticates design software to Logix controllers is discoverable from Studio 5000 itself rather than set per site, so there is no vendor-default or blank administrative account for the operator to rotate away. Applied here, it means the Logix controllers' network interfaces answer only from a segmented engineering and management plane — the engineering workstations and servers with an operational need to program them — and not from a flat plant network, a general business VLAN, or any routable path from outside. Distinguishing test: from a segment with no programming role, attempt to open a connection to a Logix controller on a staging cell; anything that answers is within reach of the published exploit, because past that point the attacker supplies the key from the design software rather than obtaining anything from the target. Precondition: segmentation bounds the population that can reach the controller, it does not repair the key handling. The packet's stated requirement is only network access to the controller, so any compromised engineering workstation, contractor laptop or jump host already inside the permitted segment satisfies that precondition in full, and the segmentation does nothing against an unauthorized application running on a host that legitimately talks to the controller. It is a holding measure for the window before the vendor update, not a closure.",
+        "evidence": "Packet vector: 'This key is used to verify Logix controllers are communicating with Rockwell Automation design software. If successfully exploited, this vulnerability could allow an unauthorized application to connect with Logix controllers. To leverage this vulnerability, an unauthorized user would require network access to the controller.' Packet: CISA KEV listed 2026-03-05, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 8.8.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The packet puts the secret inside the product: Studio 5000 Logix Designer 'may allow a key to be discovered', and that key is what verifies Logix controllers are communicating with Rockwell design software. Because the constant an attacker needs is obtainable from the design software rather than from the target site, no amount of operator-side credential hygiene reduces the exposure — which is exactly why the least-privilege and identity-and-access-control gaps are recorded against this entry: the attacker never authenticates as any engineer, so per-account privilege scoping is never consulted and the account model an identity attestation examines is bypassed rather than abused. The control's requirement here is to inventory every Studio 5000 installation and every Logix controller in the estate as depending on a product-shipped verification key, gate each of those deployments on the vendor update rather than on a password or account policy, and re-run that check after any engineering-workstation rebuild, image restore or controller replacement, since those are the operations that quietly reintroduce an unpatched pairing at a site that had been remediated. Distinguishing test: produce, per cell, the Studio 5000 version and the controller firmware actually in service and show each is at or above the vendor's fixed level — an attestation that every engineer holds a unique Studio 5000 account passes cleanly while this flaw stays fully exploitable. Precondition: the vendor update is what removes the dependence on the discoverable key; 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. It also does not detect a controller an unauthorized application has already connected to, so a cell that was reachable during the exposure window needs its controller configuration and control logic compared against a known-good copy rather than being closed on the patch.",
+        "evidence": "Packet vector: 'Studio 5000 Logix Designer software may allow a key to be discovered. This key is used to verify Logix controllers are communicating with Rockwell Automation design software.' CWE-522. Citing gaps record NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B2 (Identity and access control) against this entry. patch_available true; active_exploitation confirmed; poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet records a vendor patch, no live-patch path, and a fix that per the KEV requiredAction typically requires a service restart or system reboot. On Logix controllers driving a live process, that restart is scheduled against the process rather than against the 2026-03-05 KEV clock, which produces a long interval in which the estate's real state is 'reachability restricted, patch pending' — not remediated. This control requires that state to be recorded distinctly for each affected cell: the compensating control actually in force (the controller-reachability restriction), the residual risk it leaves (any host already inside the permitted segment still meets the exploit's only stated precondition, network access to the controller), and a dated action item tied to the next outage window in which the restart can be taken. It must not be reported as 'patched per SLA' and the KEV row must not be closed on the basis of the update having been obtained. Precondition and limit: this is a reporting-integrity control, not a technical mitigation — it changes what the audit sees, not what the attacker can reach, and it is only honest if the compensating control it records has been tested against a staging cell rather than asserted from a network diagram.",
+        "evidence": "Packet: 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.' CISA KEV listed 2026-03-05, active_exploitation confirmed. Packet vector: 'To leverage this vulnerability, an unauthorized user would require network access to the controller.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-43000": {
     "name": "Apple Multiple products Use-After-Free Vulnerability",
@@ -14256,7 +14342,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",
@@ -15631,7 +15749,23 @@
     },
     "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's vector places this in Windows Remote Desktop Services and describes an authorized attacker elevating privileges locally (CWE-269) — the account is already legitimate, so no account model is being abused; a privilege boundary inside the service is failing. For this CVE the control means the Windows update carrying the fix is driven across every affected host on the KEV clock that opened 2026-02-10 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 running the Remote Desktop Services role are the population to enumerate first, because a machine where many non-administrative users hold interactive sessions is a machine where the precondition this flaw needs — an already-authorized local user — is the normal operating state 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, so a host that has taken the update but not restarted still carries the vulnerable code and must be counted as exposed; on a session host that restart is also the step most likely to be deferred, because taking it evicts logged-on users, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. The control's second half is the load-bearing one here: since the attacker is already authorized, tightening account privilege does not contain the escalation, which is exactly why the least-privilege and identity-and-access controls cited on this entry can pass their attestations while the flaw stays fully exploitable. Priority follows the packet rather than the CVSS band: a public PoC, confirmed 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 for a chain, not a standalone endpoint item.",
+        "evidence": "Packet: 'Microsoft Windows Improper Privilege Management Vulnerability', CWE-269; vector 'Microsoft Windows Remote Desktop Services contains an improper privilege management vulnerability that could allow an authorized attacker to elevate privileges locally.' CISA KEV-listed 2026-02-10, active_exploitation confirmed, CVSS 8.8, RWEP 77, poc_available true. patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' attack_vector adds that 'LPEs of this class are routinely paired with an initial-access flaw by ransomware operators.' The entry cites AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2, UK-CAF-B2 and NIST-800-53-AC-6 as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2026-21519": {
     "name": "Microsoft Windows Type Confusion Vulnerability",
@@ -16279,7 +16413,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",
@@ -18871,7 +19037,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",
@@ -19228,7 +19417,32 @@
     },
     "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": "FortiWeb is a web application firewall — it sits on the trust boundary and is the thing other systems are protected by, which is the device class this control is written for. The packet's vector puts administrative command execution on the appliance in the hands of an unauthenticated attacker sending crafted HTTP or HTTPS requests, so the remediation clock has to run from the 2025-11-14 KEV listing, not from the next appliance maintenance window under a 14- or 30-day vulnerability-management SLA. Completion must be measured per unit by the firmware actually running after restart: the packet records patch_available true but live_patch_available false, with live_patch_notes stating no live-patch tool and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so a FortiWeb where the image is staged but the service has not been restarted is still running the vulnerable code and must be counted as exposed, not as remediated. The isolation half of this tier has a precondition that must be stated rather than assumed: restricting which networks can reach a unit's HTTP/HTTPS listeners bounds who can send the crafted request, but a FortiWeb deployed to front internet-facing applications has to keep HTTP/HTTPS reachable from untrusted clients to do its job, so for those units isolation is not available at all and only the restarted vendor update closes the path — those units must be sequenced first rather than treated as covered by a network control. Distinguishing test: on a staging FortiWeb, send crafted HTTP/HTTPS requests carrying relative-traversal sequences to the same listeners production units expose and confirm no administrative command runs; then report fleet remediation as the number of units whose running firmware is the fixed build post-restart. An attestation of 'critical patches applied within SLA' passes cleanly while an unauthenticated administrative-command path stays reachable for the whole SLA period.",
+        "evidence": "Packet fields for CVE-2025-64446 (Fortinet FortiWeb Path Traversal Vulnerability): cwe_refs CWE-23; vector 'Fortinet FortiWeb contains a relative path traversal vulnerability that may allow an unauthenticated attacker to execute administrative commands on the system via crafted HTTP or HTTPS requests'; cisa_kev true with kev_date 2025-11-14; active_exploitation confirmed; poc_available true; cvss 7.5; rwep_score 77; patch_available true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps recorded on this entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records active_exploitation as confirmed and poc_available as true for a path that needs no credentials and executes administrative commands on the FortiWeb itself, so for any unit whose HTTP/HTTPS listeners were reachable before the fixed firmware was running, the working assumption has to be that administrative commands may already have run — and installing the vendor update does not undo them. Applied to this appliance, the runbook default is to capture and examine the configuration off the box, rebuild onto the fixed firmware, and rotate every credential and certificate the unit held or could observe, rather than to record the upgrade as closure. Preconditions, stated plainly: this does not apply to units that were never reachable by an untrusted client during the exposure window, and rebuilding does not by itself remove anything — restoring the rebuilt unit's configuration from a backup taken during the exposure window reintroduces any administrative account, policy change or scheduled task an attacker created, so the restored configuration has to be diffed against a known-good baseline before it is loaded, and credential rotation has to extend to anything the appliance authenticated to, because rotation on the device alone leaves harvested secrets valid elsewhere. Distinguishing test: take a production FortiWeb and compare its current administrator list, and its configuration change record, against a baseline captured before the exposure window. If no such pre-exposure baseline exists, the organization cannot distinguish an untouched appliance from a modified one, and 'patched per SLA' is being recorded as remediation on faith — which is exactly what the patch-shaped framework controls cited against this entry accept as sufficient.",
+        "evidence": "Packet fields for CVE-2025-64446: active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-11-14; rwep_score 77; vector states an unauthenticated attacker may 'execute administrative commands on the system via crafted HTTP or HTTPS requests'; patch_available true and live_patch_available false, with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include AU-Essential-8-Patch, NIST-800-53-SI-2 and UK-CAF-B4.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-12480": {
     "name": "Gladinet Triofox Improper Access Control Vulnerability",
@@ -19762,7 +19976,32 @@
     },
     "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's vector has a malicious local actor with non-administrative privileges escalating to root on the same VM, through VMware Tools and Aria Operations rather than through anything the guest's own account model governs. For this entry the control means the fixed VMware Tools and Aria Operations builds are driven across every managed guest on the clock that opened with the 2025-10-30 KEV listing, and that completion is measured per guest by the VMware Tools build actually installed and the Aria Operations version actually running — not by 'update approved' or 'package pushed' in the management console, and not by a hypervisor-level rollup that reports host currency while guests lag. Because the packet records patch_available true, live_patch_available false, and live_patch_notes stating no live-patch tool with a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, a guest that has received the update but not restarted the affected components still carries the vulnerable path and has to be counted as exposed. The second half of the control is the load-bearing half here and is why NIST-800-53-AC-6 is cited as insufficient on this entry: the attacker is already a legitimate, non-administrative local user, so removing administrative rights from ordinary guest accounts — the thing a least-privilege attestation measures — does not stand between that account and root. Distinguishing test: on a staging guest running the same VMware Tools version, managed by Aria Operations with SDMP enabled, attempt the escalation from an ordinary non-administrative account and confirm root is not reached; then report fleet coverage as guests at the fixed build post-restart. A least-privilege attestation and a 'patch compliance' percentage both pass while this path stays open.",
+        "evidence": "Packet fields for CVE-2025-41244 (Broadcom VMware Aria Operations and VMware Tools Privilege Defined with Unsafe Actions Vulnerability): cwe_refs CWE-267; vector 'A malicious local actor with non-administrative privileges having access to a VM with VMware Tools installed and managed by Aria Operations with SDMP enabled may exploit this vulnerability to escalate privileges to root on the same VM'; cisa_kev true with kev_date 2025-10-30; active_exploitation confirmed; poc_available true; cvss 8.8; rwep_score 77; patch_available true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps recorded on this entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management, NIST-800-53-SI-2 and NIST-800-53-AC-6.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "CWE-267 (privilege defined with unsafe actions) plus a vector in which a non-administrative local account reaches root on the same VM is this control's pattern: an operation that carries root authority inside the managed guest is reachable from an account that holds no administrative privilege, so the only thing standing between an ordinary guest user and root is the correctness of that privileged path. Bound to this product, the control means the privileged work that Aria Operations and VMware Tools perform inside a guest authorizes what it acts on for itself, at its own boundary, instead of inheriting trust from the fact that the request or the state originated inside the guest it manages — and that this property is verified on the managed-guest configuration the packet names, not assumed from the guest OS's account model. Preconditions, stated plainly: the vendor update is what repairs the boundary — this control states the property to verify, it does not implement it. Until that update is installed and the affected components restarted (the packet records no live-patch path and a restart-or-reboot requirement), the only operator-side lever is the exploit condition the packet itself names — a VM with VMware Tools installed, managed by Aria Operations, with SDMP enabled — so guests outside that configuration are not in the described condition, but where SDMP is operationally required nothing short of the update closes the path, and changing that setting does not evict an attacker who already reached root or remove what root access created on a guest that was in the vulnerable configuration during the exposure window (active_exploitation is confirmed and a PoC is public). Distinguishing test: enumerate which guests are managed with SDMP enabled and, on a staging guest matching that configuration, confirm a non-administrative local account cannot drive the privileged path to root — an attestation that no ordinary guest user holds administrative rights never tests this path.",
+        "evidence": "Packet fields for CVE-2025-41244: cwe_refs CWE-267 ('Privilege Defined with Unsafe Actions' per the entry name); vector names the exploit condition as a VM 'with VMware Tools installed and managed by Aria Operations with SDMP enabled' and the outcome as escalation 'to root on the same VM' by 'a malicious local actor with non-administrative privileges'; attack_vector adds that escalation flaws of this class form the second half of an intrusion chain; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-10-30; patch_available true; live_patch_available false with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include NIST-800-53-AC-6 and UK-CAF-B4.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-24893": {
     "name": "XWiki Platform Eval Injection Vulnerability",
@@ -20215,7 +20454,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": "LANSCOPE Endpoint Manager is the device-management platform itself, and CWE-940 places the defect precisely at the trust decision: the receiving component decides whether to act on a packet by judging where it appears to have come from rather than by verifying who sent it, so an unauthenticated attacker's crafted packets are processed as trusted commands and reach arbitrary code execution. Applied to this product, the control means every service on the LANSCOPE management agent and server that accepts commands authenticates its caller cryptographically before the command is parsed or executed — a verdict that cannot be satisfied by source address, network position, or any other property the sender controls — and that those listening services are not reachable from networks with no managed endpoints on them. The precondition on the network half has to be stated rather than left implied: managed endpoints must be able to reach the management server for the product to function, so restricting reachability shrinks the population that can send crafted packets to hosts inside the managed network but does not close the path — any compromised workstation in that population still has it, and for a deployment where agents span the whole estate the reduction is small. Closure is the vendor update, and the packet records no live-patch tool with a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, so a server or agent that has taken the update without restarting is not remediated. Distinguishing test: on a staging LANSCOPE instance, send crafted command packets from an unauthenticated host and confirm refusal before execution — then repeat from a host inside the managed address range and confirm the command is still refused. If the second attempt succeeds, the product is still authenticating the channel rather than the caller, which is the defect itself; the least-privilege control cited against this entry is never consulted on this path because the attacker holds no LANSCOPE account to scope.",
+        "evidence": "Packet fields for CVE-2025-61932 (Motex LANSCOPE Endpoint Manager Improper Verification of Source of a Communication Channel Vulnerability): cwe_refs CWE-940; vector 'Motex LANSCOPE Endpoint Manager contains an improper verification of source of a communication channel vulnerability allowing an attacker to execute arbitrary code by sending specially crafted packets'; attack_vector describes an unauthenticated attacker sending trusted commands to the management agent/server for remote code execution; cisa_kev true with kev_date 2025-10-22; 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.' Citing gaps recorded on this entry include NIST-800-53-AC-6, UK-CAF-B4 and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The packet puts arbitrary code execution on the LANSCOPE management agent and server — the component that holds the management relationship with the endpoints it administers — and records active_exploitation as confirmed with a public PoC. That makes the installation and, wherever the deployment uses it to distribute software or run commands on managed endpoints, the content it hands to its agents a privileged distribution channel rather than ordinary application data. Bound to this product, the control means file-integrity monitoring across the LANSCOPE installation and the directories it serves content from, with alerts on any write that does not correspond to a sanctioned administrator action or a vendor update, and holding the LANSCOPE server to KEV-priority patching as a management-plane asset in its own right. This is the control that retains value after the vendor update lands, which is why the update-shaped framework controls cited on this entry are insufficient on their own: the fix closes the path by which crafted packets became trusted commands, but it removes nothing that was already written or already executed through that path, and an artifact placed on the server before remediation survives the upgrade and keeps whatever reach the server has. Preconditions: monitoring neither prevents exploitation nor reconstructs the period before it was enabled — a monitor stood up after the exposure window has no baseline for what changed during it, so the comparison must be made against a record captured before that window or against vendor-shipped file state, and where neither exists the honest verdict is that server integrity is unestablished rather than clean. Distinguishing test: enumerate the content the LANSCOPE server would currently distribute or execute and reconcile it item by item against the change record of sanctioned administrator actions since before the exposure window; unreconciled items are the finding. An attestation that the LANSCOPE server is running the fixed build passes cleanly while a payload placed pre-update continues to reach managed endpoints.",
+        "evidence": "Packet fields for CVE-2025-61932: attack_vector describes an unauthenticated attacker sending trusted commands to the LANSCOPE 'management agent/server' for remote code execution; vector confirms arbitrary code execution via specially crafted packets; active_exploitation confirmed; poc_available true; cisa_kev true, kev_date 2025-10-22; cvss 9.8; rwep_score 77; patch_available true; live_patch_available false, with live_patch_notes recording no live-patch tool and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction. Citing gaps on this entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2022-48503": {
     "name": "Apple Multiple Products Unspecified Vulnerability",
@@ -20701,7 +20964,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's chain runs entirely below the operating system: igel-flash-driver mis-verifies the image signature, so a crafted root filesystem mounts from an unverified SquashFS image and the device runs an attacker's OS. Nothing inside the booted session can detect or contain that, so the vendor update is the only closure, driven across every IGEL OS endpoint on the clock that opened with the 2025-10-14 KEV listing rather than folded into the next scheduled image-refresh cycle. Completion must be measured by the build each device actually booted, not by 'update assigned' or 'update downloaded' in the management console: the packet records a vendor patch with no live-patch path and a fix that requires a service restart or system reboot, so a device that has taken the update but not rebooted is still running an image the unfixed verification path admitted and has to be counted as exposed, not remediated. Scope this to IGEL OS, which is the product the packet names; it gives no mapping from igel-flash-driver into any other boot chain.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-10-14, active_exploitation confirmed, poc_available true, RWEP 77 against CVSS 8.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.' Vector: 'IGEL OS contains a use of a key past its expiration date vulnerability that allows for Secure Boot bypass. The igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image.' (CWE-324).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The mechanism that failed on this entry is boot-image signature verification itself: per the packet igel-flash-driver accepts a signature made with a key past its expiration date, so Secure Boot reports enforcement while an unverified SquashFS root filesystem mounts. A version-number attestation cannot separate 'verification restored' from 'verification still failing open', because the version string is exactly what the mechanism was already reporting while it admitted the image. For this CVE the control means the boot-verification path is re-tested as a class on every IGEL OS image deployment, keyed on the behaviour the packet documents: on a staging device, present the boot chain with a modified or unverified SquashFS root filesystem image and confirm it refuses to mount it — and keep that test in the battery for subsequent images instead of retiring it once this CVE is closed, since the defect is in the check rather than in one image. Precondition: the test needs a staging device the operator can attempt an unverified boot on and a way to observe the refusal. Where that does not exist the mechanism's state is unverified, and the device must be treated as exposed until it boots a build the vendor names as fixed rather than passing because a scanner read the version.",
+        "evidence": "Packet vector: 'The igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image', classed CWE-324 (use of a key past its expiration date) and described in the attack vector as a Secure Boot / boot-trust bypass letting an attacker boot a modified or unverified OS image. cisa_kev true with kev_date 2025-10-14, active_exploitation confirmed and poc_available true, so the failing check is being exercised rather than theoretical. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-24990": {
     "name": "Microsoft Windows Untrusted Pointer Dereference Vulnerability",
@@ -22072,7 +22359,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The packet puts the sink in the GoAnywhere MFT license servlet and names the entry condition as a validly forged license response signature: the product's trust decision is that a signature-checked license response is safe to deserialize into an arbitrary actor-controlled object, and from there CWE-502 becomes the CWE-77 command injection the packet records. For this product the control means the license servlet is treated as an unauthenticated trust boundary rather than a vendor-to-product internal convenience. Two requirements follow. First, the servlet must constrain what an arriving license response is permitted to construct or evaluate — an allowlist of the concrete types the licensing flow legitimately carries — instead of inheriting safety from the signature check, which is precisely the check the packet says the actor forges. Second, the servlet path must answer only from the management segment rather than from arbitrary internet callers. Distinguishing test: against a staging instance, submit to the license servlet a response object of a type the licensing flow never legitimately conveys and confirm it is refused before any object is constructed — an instance that passes a patch-level audit while the servlet answers unauthenticated internet callers still carries the deserialization path the moment the next parsing defect lands. Precondition: the reachability half holds only where the deployment can separate the licensing and administrative surface from the partner-facing file-transfer listeners. Where partners and the servlet share one exposed surface, segmentation buys nothing and the vendor update is the only remediation — and the packet records that update as requiring a service restart or system reboot with no live-patch path, so an instance updated but not restarted is not yet remediated. Second precondition: on an instance that was internet-reachable on a vulnerable build this control does not remove what an operator with command execution already placed there; that is a separate disposition, not something the hardening covers.",
+        "evidence": "Packet fields for this entry: attack_vector records \"a deserialization-of-untrusted-data flaw (CWE-502/CWE-77) in the GoAnywhere MFT license servlet, enabling unauthenticated remote code execution on the managed-file-transfer server\"; the vector records \"an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object, possibly leading to command injection\". cwe_refs CWE-502 and CWE-77. cisa_kev true, kev_date 2025-09-29, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 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.\" UK-CAF-B4 (System security) and ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records this entry as mass-exploited in data-theft extortion campaigns with confirmed in-the-wild exploitation, and the flaw yields unauthenticated command execution on the managed-file-transfer server itself — the host that holds and moves the organisation's files. Applying the Fortra update closes the deserialization path and says nothing about what ran on the box while it was open. Applied to this product: any GoAnywhere MFT instance that was reachable from an untrusted network on a vulnerable build is dispositioned as compromised regardless of what a post-update version check reports. Capture and diff the running configuration and the directories the service serves content from against known-good, rebuild from vendor media at the fixed version rather than updating in place, and rotate what the server held — the MFT service and administrative account credentials, the trading-partner keys and passwords it authenticated with, and any TLS private key stored on it. Then review which transferred files were exposed, because the campaign class the packet names is data-theft extortion: the files are the objective, not a side effect, and no amount of post-hoc patching un-exfiltrates them. The behaviour to hunt for is the one the packet's own chain produces — the MFT service process spawning a shell or interpreter child, which is what a deserialization sink reaching a command-injection sink looks like at execution time — rather than a generic malware signature, which is exactly what the anti-malware control this entry cites does not reliably produce for an in-process injection chain. Precondition: this disposition applies to instances whose exposure during the vulnerable window cannot be excluded; an instance that provably never answered an untrusted network on a vulnerable build takes the vendor update on the KEV clock instead. Rebuilding is not relief from the update — the rebuilt instance must come up on the fixed version, with the service restart or reboot the packet records as required.",
+        "evidence": "Packet fields for this entry: attack_vector records \"unauthenticated remote code execution on the managed-file-transfer server (mass-exploited in data-theft extortion campaigns)\" arising from the CWE-502/CWE-77 flaw in the GoAnywhere MFT license servlet. cisa_kev true, kev_date 2025-09-29, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 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.\" CIS-Controls-v8-10.1 (Deploy and Maintain Anti-Malware Software) and NIS2-Art21-vulnerability-handling (Cybersecurity risk-management measures (vulnerability handling and disclosure)) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "CIS-Controls-v8-10.1",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the control's \"KEV listing or patch availability, whichever is later\" clause sets a clock the operator can actually run: the packet records patch_available true and a KEV listing dated 2025-09-29, and the flaw is a pre-authentication path to command execution on an internet-facing managed-file-transfer server at CVSS 9.8 and RWEP 83 that is already mass-exploited. A month-scale critical-patch window is exploitation acceptance against that profile, and an operating-system patch programme never reaches this server's application build at all — the vulnerable code is the GoAnywhere license servlet, not the host OS, so an estate can be fully current on OS updates while every MFT instance stays open. Applied here, the SLA governs the GoAnywhere application build specifically, and completion is measured by each instance reporting the fixed version after it has been restarted, not by \"update downloaded\" or \"change request raised\": the packet registers no live-patch path and states the vendor patch requires a service restart or system reboot, so the restart sits inside the clock rather than after it. Precondition for anything done inside the open window: narrowing who can reach the license servlet reduces exposure but does not remediate the entry, and it must be recorded as an interim compensating measure with the update date attached, not as satisfaction of the SLA. An instance that cannot be restarted inside the window is a named, dated exception carrying that restriction, not a silently open item.",
+        "evidence": "Packet fields for this entry: \"Fortra GoAnywhere MFT contains a deserialization of untrusted data vulnerability allows an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object, possibly leading to command injection\"; attack_vector adds \"unauthenticated remote code execution on the managed-file-transfer server (mass-exploited in data-theft extortion campaigns)\". cisa_kev true, kev_date 2025-09-29, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 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.\" AU-Essential-8-Patch (Patch operating systems) and NIST-800-53-SI-2 (Flaw Remediation) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-20352": {
     "name": "Cisco IOS and IOS XE Software SNMP Denial of Service and Remote Code Execution Vulnerability",
@@ -22297,7 +22616,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 affected component per the packet is the VPN web server on Cisco Secure Firewall ASA and Secure Firewall Threat Defense — the device is the perimeter trust boundary, so a missing-authorization flaw letting an unauthenticated caller reach restricted URL endpoints cannot sit in an ordinary appliance-maintenance window. A 14- or 30-day remediation SLA applied here is being applied to the thing that enforces the boundary. For this CVE the tier means the fixed release is driven onto every ASA and FTD unit whose VPN web server is reachable, on a clock that opened with the 2025-09-25 KEV listing, or the VPN web-services interface is withdrawn from untrusted reachability until it is. The packet records a vendor patch with no live-patch path and a service-restart-or-reboot requirement, so the clock does not stop at 'image loaded' — it stops when the unit has reloaded onto the fixed release, because a unit staged but not reloaded still serves the vulnerable path. Precondition on the interim half: restricting reachability bounds exposure only where the VPN web server can actually be withdrawn from the untrusted side. A unit that must keep terminating remote-access VPN from the internet cannot use that lever at all and has only the expedited reload, and pairing it with a reachability restriction it cannot apply would record a mitigation it does not have.",
+        "evidence": "Packet: 'Cisco Secure Firewall Adaptive Security (ASA) Appliance and Secure Firewall Threat Defense (FTD) Software VPN Web Server contain a missing authorization vulnerability. This vulnerability could be chained with CVE-2025-20333.' Attack vector: a missing-authorization flaw (CWE-862) allowing an unauthenticated attacker to reach restricted URL endpoints. cisa_kev true, kev_date 2025-09-25, active_exploitation confirmed, poc_available true, RWEP 77 against CVSS 8.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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records confirmed in-the-wild exploitation from the 2025-09-25 KEV listing and states the flaw could be chained with CVE-2025-20333, so for any ASA or FTD unit whose VPN web server was reachable during that window the operative question is not whether it now runs the fixed release but whether it was already reached. Upgrading closes the missing-authorization path; the packet gives no basis for treating the upgrade as removing anything an attacker may have left on the box beforehand. The control means those units default to the compromise path rather than the patch path: capture the running and startup configuration and diff it against a known-good baseline before touching the unit, rebuild from vendor image instead of upgrading in place, and rotate every credential and key the device held or terminated — device administrative accounts, remote-access VPN credentials, and any shared secret configured on it. Precondition, and it decides which units this applies to: the default is for units whose VPN web server was actually reachable from an untrusted network during the exposure window. A unit that was never so exposed can take the ordinary expedited upgrade, but that determination has to come from configuration and network evidence rather than from assumption — an untested assumption of non-reachability is how a compromised unit gets upgraded in place and returned to service.",
+        "evidence": "Packet: active_exploitation confirmed with cisa_kev true and kev_date 2025-09-25, poc_available true. Vector: 'Cisco Secure Firewall Adaptive Security (ASA) Appliance and Secure Firewall Threat Defense (FTD) Software VPN Web Server contain a missing authorization vulnerability. This vulnerability could be chained with CVE-2025-20333.' patch_available true, live_patch_available false. The packet establishes that the update closes the flaw; it records nothing indicating the update remediates a unit already reached through it.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "Because the packet's path is an unauthenticated caller reaching restricted URL endpoints on the ASA/FTD VPN web server, the signal that a unit was touched is a web-services request to a restricted VPN web-server path with no successful prior authentication on that session — the exact behaviour the packet documents, and something an exploit doing only what the packet describes necessarily emits at the web-services layer. That record lives on the device an attacker reaching those endpoints is in a position to alter, so ASA/FTD web-services, syslog and authentication records must be forwarded as they are produced to a collector in a separate trust zone, with different credentials and a different management path from the firewall itself. Precondition, and the reason this is a standing posture rather than an incident action: forwarding only produces evidence for the period it was already running. A unit that logged locally through the window opened by the 2025-09-25 KEV listing cannot have its history reconstructed afterwards, and for that unit the compromise-assumption path is the answer instead of a log review. Forwarding also prevents nothing — it makes the access visible and makes the record survive the device; it is not a substitute for the reload onto the fixed release.",
+        "evidence": "Packet attack vector: a missing-authorization flaw (CWE-862) allowing an unauthenticated attacker to reach restricted URL endpoints on the ASA web-services chain, chainable with CVE-2025-20333 per the vector text. cisa_kev true, kev_date 2025-09-25, active_exploitation confirmed, poc_available true. patch_available true with live_patch_available false and a restart-or-reboot requirement, so units carry the exposure until they reload.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-20333": {
     "name": "Cisco Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD) Buffer Overflow Vulnerability",
@@ -22450,7 +22803,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",
@@ -23470,7 +23847,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",
@@ -23580,7 +23983,30 @@
     },
     "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 vulnerable component is the browser itself and the delivery is an attacker-controlled web page — the packet describes the SetMouseCapture flaw used in watering-hole attacks, so the victim reaches the CWE-399 use-after-free by visiting a site: there is no attachment to strip, no file to inspect, and no user action to train against beyond browsing. Applied to this CVE the control means Internet Explorer's servicing is driven on its own accelerated channel rather than deferred into an enterprise update ring or folded into a monthly workstation rollup, and that completion is measured per host against the installed build rather than by 'update approved' in the management console. The packet records a vendor patch, no live-patch path, and a fix that requires a service restart or system reboot, so a host that has taken the update but has not restarted is still running the vulnerable renderer and must be counted as exposed rather than remediated. Precondition: an update-ring policy only reaches copies a managed channel can see and drive. The packet notes the impacted products could be end-of-life or end-of-service, so part of the exposed population sits outside managed servicing entirely; for those hosts the policy changes nothing and the exposure is closed only by applying the update by hand or by taking the product out of use, per the packet's own instruction that users should discontinue product utilization. Recording such a host as covered because a ring policy exists leaves it fully exploitable. The distinguishing test: take a host the update-ring report shows as compliant and read its installed Internet Explorer build and its last restart time — a fleet reporting 100% approved while hosts sit un-restarted has measured the console's state, not the renderer's.",
+        "evidence": "Packet: CWE-399 resource-management memory-corruption use-after-free in Internet Explorer, recorded as the SetMouseCapture flaw used in watering-hole attacks and exploitable by an attacker-controlled web page for code execution in the browser. CISA KEV-listed 2025-08-12 with active_exploitation confirmed and poc_available true; RWEP 77 against CVSS 9.8. patch_available true, live_patch_available false, with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The packet also records that the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV listing on this entry is dated 2025-08-12 against a CVE assigned in 2013, and that mismatch is the operative problem for a vulnerability-management program. Nothing here is newly disclosed, no advisory feed re-publishes it, and a program that opens work items from disclosure feeds — or that triages by CVE age — creates no ticket at all, while the packet records exploitation as confirmed now and a PoC as available. Applied to this CVE the control means the KEV listing date starts the remediation clock independently of the CVE's age: the estate is re-queried in 2025 for Internet Explorer installs still on a pre-fix build, rather than consulted for a 2013 remediation record asserting the flaw was closed against the estate that existed then. The verified-mitigation state the SLA demands is per-host — the packet gives a vendor patch, no live-patch path, and a restart-or-reboot requirement, so 'fixed build installed and the host restarted' is the only state that counts, not 'the bulletin was deployed'. Precondition: the clock is only meetable against hosts the estate can still enumerate and service. The packet's note that impacted products could be end-of-life or end-of-service means some of the exposed population has no patch pipeline pointed at it; for that population the SLA is satisfied by removing the exposure on a dated schedule, and carrying an unreachable host as perpetually 'pending' converts the clock into a record of the omission. The distinguishing test: query the vulnerability-management system for an open item on this CVE carrying a due date derived from 2025-08-12 — a program whose only record is a closed 2013 ticket has no active work item while KEV states the flaw is being exploited today.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-08-12 on CVE-2013-3893, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 9.8. attack_vector records that the legacy re-listing exists because long-tail unpatched/end-of-life estates remain exposed. patch_available true, live_patch_available false, with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. Citing framework gaps include EU NIS2 vulnerability handling and NIST SP 800-53 SI-2 Flaw Remediation.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2020-25078": {
     "name": "D-Link DCS-2530L and DCS-2670L Devices Unspecified Vulnerability",
@@ -23783,7 +24209,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-132",
+        "name": "INDEPENDENT-INTEGRITY-VERIFICATION-OF-SIGNED-VENDOR-INSTALLERS",
+        "description": "The DNR-322L accepts and runs code it downloads without checking its integrity (CWE-494), so nothing on the device distinguishes a genuine D-Link image from one an attacker substitutes — the packet's path is precisely that: an attacker supplies a malicious update and obtains OS-level command execution on the device. Applied to this product the control means the operator, not the device, makes the integrity decision: obtain the DNR-322L firmware through a controlled path, verify it against a vendor-published integrity value obtained over a channel separate from the download itself, and load the verified image deliberately rather than letting the device pull and run whatever an update endpoint offers it. This is the harder form of the control's premise — the original case was a client trusting a signature it should not have, whereas this device performs no verification step at all, so an out-of-band check is the only thing standing between a substituted image and code execution on the box. Precondition, and it is load-bearing: operator-side verification governs only the images the operator supplies. The packet places the attack behind device authentication, so an attacker holding or obtaining a DNR-322L credential feeds the device an image directly, and no verification discipline applied to the operator's own images intercepts that path. Bounding who can authenticate to the device's management surface is the other half of the control, and it is not substituted for by loading a verified image. The distinguishing test: for the image you are about to load, confirm you can match it to a vendor-published integrity value obtained independently of the file you downloaded — the fact that the device accepted the image tells you nothing, because it accepts unverified code by construction.",
+        "evidence": "Packet: CWE-494, download of code without an integrity check, on the D-Link DNR-322L. vector states an authenticated attacker could execute OS-level commands on the device; attack_vector states an attacker can supply a malicious update for code execution. CISA KEV-listed 2025-08-05 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Two things separate the KEV clock on this entry from an ordinary server patch item. First, the DNR-322L is not reached by the estate's operating-system patching program — the cited Essential Eight 'patch operating systems' control is measured against machines carrying a patch agent, and this device carries none, so the 2025-08-05 listing produces no work item at all unless the SLA is written against the named asset rather than against the pipeline that happens to cover it. Second, the remediation action itself travels the vulnerable path: the defect is in how the device ingests code, so every image the device takes — the remediation image included — is accepted without an integrity check. Meeting the clock therefore means loading an image the operator has verified out of band and then confirming the unit came back on the fixed version; the packet records a vendor patch, no live-patch path, and a fix requiring a service restart or system reboot, so a device handed the image but not restarted onto it is not yet remediated. Precondition: this is only actionable for units the operator can physically or administratively reach and re-verify. The packet notes the impacted products could be end-of-life or end-of-service, so where no reachable fixed image exists the clock is closed by removing the unit from service on a dated schedule, not by carrying it indefinitely as pending. The distinguishing test: pull the KEV-derived due date for this CVE and ask which named DNR-322L units it is tracked against — an SLA reporting 'no affected assets' because the patch console cannot see the device has measured the console, not the estate.",
+        "evidence": "Packet: CISA KEV-listed 2025-08-05 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8; CWE-494 with attack_vector recording that an attacker can supply a malicious update for code execution. Citing framework gaps include ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8 and EU NIS2 vulnerability handling. patch_available true, live_patch_available false, with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The packet also records that the impacted products could be end-of-life and/or end-of-service.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-2533": {
     "name": "PaperCut NG/MF Cross-Site Request Forgery (CSRF) Vulnerability",
@@ -24697,7 +25146,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet supplies every precondition this control keys on: an unauthenticated attacker reaches remote code execution on Wing FTP Server, exploitation is confirmed in the wild, a PoC is available, and the injected Lua executes with the privileges of the FTP service — root or SYSTEM by default. That last fact is what makes patch-in-place the wrong default here: a successful exploit owns the host, not merely the FTP application, so the vendor update closes the null-byte injection path while leaving intact whatever was installed through it — added accounts, scheduled tasks, altered service configuration, or attacker Lua left in the session-file tree the product itself evaluates. Applied to this product, an exploited or suspected-exploited instance is dispositioned by exporting configuration, rebuilding the host, and rotating every credential the service held or handled: Wing FTP account passwords, any service or database credentials in its configuration, and any key material stored on the host — not by upgrading in place and closing the ticket. Precondition: this disposition is for instances that were reachable by untrusted clients during the exposure window, which the packet opens at the 2025-07-14 KEV listing and which closes only when the fix is actually in service. For an instance demonstrably unreachable across that window, the vendor update plus the restart it requires is sufficient; the packet records a vendor patch with no live-patch path and a service-restart-or-reboot requirement, so an instance updated but not restarted has not closed the window at all. Which case a host is in has to be established from reachability evidence — 'the server is internal' is a statement about topology, not a demonstration that no untrusted client could reach the listener. The distinguishing test: on a host that has taken the update, look for artefacts the update does not remove — accounts and session files created during the exposure window, and service-configuration changes not traceable to an administrator action; an upgrade record alone does not distinguish a clean host from an occupied one.",
+        "evidence": "Packet: CWE-158, improper neutralization of a null byte or NUL character, allowing injection of arbitrary Lua code into user session files, used to execute arbitrary system commands with the privileges of the FTP service (root or SYSTEM by default). attack_vector records an unauthenticated attacker achieving remote code execution, exploitable even via anonymous login. CISA KEV-listed 2025-07-14 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8. patch_available true, live_patch_available false, with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "Wing FTP's pre-authentication login and session-file handling is the unprivileged user surface this control governs, and the packet has it wired straight to a root operation: a NUL character that is not neutralized carries attacker-controlled text into a user session file, that file is evaluated as Lua, and the interpreter runs as the FTP service — root or SYSTEM by default. Applied to this product the property to verify is that nothing arriving on the pre-authentication surface can reach an interpreter holding host authority: content the login path writes into a session file is consumed as data rather than evaluated, and the service's privileged operations sit behind their own boundary instead of being reachable by anything that can present a username. The vendor update is what repairs the neutralization — the control states the property to verify, it does not implement it. The operator-side lever in the meantime is the authority the interpreter inherits: where the product permits it, run Wing FTP under a dedicated account without host-level administrative rights, so injected Lua executes without root or SYSTEM authority. Two preconditions, and the first is the one most likely to be recorded as the mitigation when it is not one. Disabling anonymous login does not close this path: the packet states the attacker is unauthenticated and names anonymous login only as the easiest route, so the injection is reached before any account decision is made and an instance with anonymous access turned off remains exploitable. And the service-account change does not stop the injection — it bounds what the injected code can do, and it does nothing at all on a deployment that must retain root or SYSTEM. This is why the cited least-privilege gap is recorded against this entry: per-account privilege scoping is never consulted, because the attacker holds no account. The distinguishing test: on a staging instance with anonymous login disabled, submit NUL-bearing input to the pre-authentication surface and confirm nothing is written into a session file the Lua interpreter will later evaluate — an attestation that every Wing FTP account has a strong password tests the account model this attack never touches.",
+        "evidence": "Packet: CWE-158, improper neutralization of null byte or NUL character, allowing injection of arbitrary Lua code into user session files, which can be used to execute arbitrary system commands with the privileges of the FTP service (root or SYSTEM by default). attack_vector records an unauthenticated attacker and notes it is exploitable even via anonymous login. NIST SP 800-53 AC-6 (Least Privilege) is one of the framework control gaps citing this CVE. CISA KEV-listed 2025-07-14 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8. patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry pairs the three conditions that collapse a normal patch window: the packet records exploitation as confirmed, a PoC as available, and code execution at root or SYSTEM from an attacker holding no credential — so the interval between the 2025-07-14 KEV listing and the fix being in service is time during which any reachable instance can be taken at host level by anyone who can send it traffic. Applied to this product the control means Wing FTP is remediated on the KEV clock rather than in the next application-maintenance window, and that completion is measured per instance by the running version after restart. The packet gives a vendor patch, no live-patch path, and a fix requiring a service restart or system reboot, so an instance whose files were replaced but whose service still holds the old code in memory is exposed, not remediated — on a file-transfer service that is the common case, because restarting it interrupts transfers and gets deferred. Precondition: the clock covers only instances the operator knows about. Wing FTP is the kind of service that gets stood up by a business unit for a partner file exchange and never enters the application inventory, and a KEV SLA cannot be met against an instance nobody has listed — enumerating who is running it is the first action the clock demands, not the last. The distinguishing test: for each Wing FTP instance, compare the running service's version and its process start time against the time the fix was applied; a compliance record showing the package updated within the SLA, on a service that has not restarted since, records the file copy rather than the remediation.",
+        "evidence": "Packet: CISA KEV-listed 2025-07-14 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.8. vector records that the injected Lua executes arbitrary system commands with the privileges of the FTP service (root or SYSTEM by default), and attack_vector records an unauthenticated attacker, exploitable even via anonymous login. patch_available true, live_patch_available false, with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. Citing framework gaps 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",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-5777": {
     "name": "Citrix NetScaler ADC and Gateway Out-of-Bounds Read Vulnerability",
@@ -24852,7 +25334,21 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This is a 2019-identified flaw that entered CISA KEV on 2025-07-07 with confirmed in-the-wild exploitation and a public proof-of-concept, which is what makes an exploitation-driven SLA the operative control instead of the age- or score-ordered queue most vulnerability-management programs run: at CVSS 7.5 and six years old, this entry sorts near the bottom of a queue ordered by severity and disclosure date while being actively exploited, and the packet's RWEP of 77 against that CVSS is the size of the mis-ranking. Applied to this product, the clock runs from the KEV listing to a Zimbra Collaboration Suite instance actually running the fixed code, and the packet's remediation note is where that goes wrong: it records a vendor patch with no live-patch tool registered and states the patch typically requires a service restart or system reboot per the KEV requiredAction, so a ZCS host where the package was applied but the services were never restarted is still serving the vulnerable ProxyServlet and must be counted as exposed rather than remediated. No compensating control is offered here that removes the path, and inventing one would be worse than saying so: the SSRF is reachable by an unauthenticated attacker through ProxyServlet on the ZCS web surface, and on a mail and collaboration server that surface is reachable by design. Source-restricting it is available only for an instance whose web client serves a bounded, known user population; for an internet-facing deployment it is not, and there the completed, restarted update is the only action that closes the path. Distinguishing test: query each ZCS host for the version of the running services rather than the installed package version, and confirm the restart has happened — a patch-deployment report that closes the ticket at package install leaves an actively exploited path open on a host that reports as patched.",
+        "evidence": "Packet: Synacor Zimbra Collaboration Suite (ZCS) contains a server-side request forgery vulnerability via the ProxyServlet component (CWE-918, CWE-807), letting an unauthenticated attacker coerce server-side requests — described as a known chain toward RCE on ZCS. CISA KEV-listed 2025-07-07; active_exploitation confirmed; poc_available true; CVSS 7.5; RWEP 77. patch_available true; live_patch_available false; live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-5418": {
     "name": "Rails Ruby on Rails Path Traversal Vulnerability",
@@ -24912,7 +25408,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The packet places the traversal in Action View, a component inside the Ruby on Rails framework rather than a dependency a deployed application declares for itself — an application declares Rails, or declares a gem that declares Rails, and Action View arrives underneath. That is why the framework control this entry cites, patching operating systems, cannot reach it: a host package inventory and an OS patch report can both read clean across the whole estate while every Rails application on it still renders arbitrary files in response to a crafted Accept header. Applied here, the inventory has to resolve to the framework-component level: enumerate the resolved Action View version behind every deployed application — internal tools, vendor-supplied Rails applications, and containers built from base images the platform team does not rebuild — from the application's own lockfile, and drive flaw-remediation tickets from that list instead of from the host patch report. Distinguishing test: ask the estate's inventory for the resolved Action View version behind each deployed Rails application; any application whose framework component version the inventory cannot produce is unremediated by default, not compliant, because nothing in the OS-scoped evidence would ever have shown otherwise. Precondition: this finds the exposure, it does not close it. The packet records a vendor patch with no live-patch path and a service restart requirement, so each application must be moved onto the fixed framework version and restarted before it counts as remediated. An application whose lockfile the operator does not control — a vendor-supplied appliance shipping its own Rails build — is remediated by the vendor's update or by removing its exposure, not by recording it as inventoried. And because the packet says the read reaches configuration and secrets, an application found exposed after the fact needs those secrets rotated; the framework update does not un-disclose what was already read.",
+        "evidence": "Packet fields for this entry: \"Rails Ruby on Rails contains a path traversal vulnerability in Action View. Specially crafted accept headers in combination with calls to `render file:` can cause arbitrary files on the target server to be rendered, disclosing the file contents\"; attack_vector adds that this lets \"an unauthenticated attacker read arbitrary files including configuration and secrets\". cwe_refs CWE-22. cisa_kev true, kev_date 2025-07-07, active_exploitation confirmed, poc_available true, cvss 7.5, rwep_score 77. patch_available true, live_patch_available false, live_patch_notes: \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" AU-Essential-8-Patch (Patch operating systems) and NIST-800-53-SI-2 (Flaw Remediation) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A vulnerability-management verdict of \"patched\" reached from a host package version is paper compliance for this entry twice over: the defect lives in the application's bundled framework rather than in a host package, and the attacker's input is somewhere most detection never looks. The packet is explicit that the crafted content rides in the Accept header, in combination with a `render file:` call — the request path and query string are unremarkable. So a scanner rule, WAF signature or SIEM query written against traversal sequences in URLs sees a clean request and stays silent through actual exploitation, and the resulting green report is the compliance-theater artefact. Operational test for this entry: from an unauthenticated client against a staging deployment, issue a request carrying a crafted Accept header to a route that reaches `render file:`, and confirm the response body does not contain a file from outside the application's view root — a real behavioural result, not a version comparison. Two supporting checks belong with it: confirm the request-logging pipeline actually retains the Accept header, since a pipeline that drops it cannot evidence exploitation afterwards; and write the detection against the behaviour the packet documents, which is inbound Accept header values carrying traversal sequences or absolute paths, together with the application returning file content of a type that route does not otherwise serve. Precondition and limit: a passing test proves this route is closed, nothing more — it does not survey the estate, and it does not undo disclosure. Because the packet records the read as reaching configuration and secrets, any application where the test fails or where exploitation is evidenced needs every secret reachable through that read rotated, and the vendor update applied with the service restart the packet requires, before the finding is closed.",
+        "evidence": "Packet fields for this entry: \"Specially crafted accept headers in combination with calls to `render file:` can cause arbitrary files on the target server to be rendered, disclosing the file contents\"; attack_vector records \"a path-traversal flaw (CWE-22) in Ruby on Rails Action View (crafted Accept header), letting an unauthenticated attacker read arbitrary files including configuration and secrets\". cisa_kev true, kev_date 2025-07-07, active_exploitation confirmed, poc_available true, cvss 7.5, 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.\" ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIS2-Art21-vulnerability-management (Vulnerability handling) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2016-10033": {
     "name": "PHPMailer Command Injection Vulnerability",
@@ -25231,7 +25749,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-138",
+        "name": "VERIFY-MESSAGING-BACKEND-DATA-HANDLING-AGAINST-E2E-CLAIM",
+        "description": "TM SGNL is a messaging-archiving backend, and this defect is only catastrophic because of what that backend was holding. The packet describes a JSP application whose heap content is 'roughly equivalent to a core dump', states that a password previously sent over HTTP is included in that dump, and records the exposure as disclosing plaintext messages and credentials from the TeleMessage server. A memory-disclosure bug in an archive that genuinely could not read message contents would return ciphertext; here it returned the messages themselves, so what this CVE demonstrates is the end-to-end claim failing rather than the dump primitive being unusually powerful. Bound to this product, the control means the archiving tier is not accepted on the strength of its encryption datasheet: require evidence — independent cryptographic review, a documented key-custody model that excludes the vendor, or a controlled test — that the backend cannot produce the plaintext of a stored message without the endpoint's keys, and put the same question to the credentials the web tier receives, since the packet places a password submitted over HTTP inside the process heap. The distinguishing test is a procurement-and-onboarding test rather than a scan: ask the vendor to produce the plaintext of a message you stored, and ask whether the account credential you submitted is recoverable from the running process. If either answer is yes, any memory-exposure defect in the product is a full-content breach, and the multi-factor and identity-and-access attestations the estate carries do not reduce it — the credential leaves the server without any authentication event taking place, so a second factor is never presented and no access decision is ever consulted. This control governs whether the product is trusted with the data; it does not remediate the disclosure path itself. The packet records a vendor patch for that, and material already read out of an exposed instance stays valid until it is rotated.",
+        "evidence": "Packet: CISA KEV-listed 2025-07-01 with active_exploitation 'confirmed'; CVSS 8.8, RWEP 77; poc_available true; patch_available true; live_patch_available false. Vector: 'TeleMessage TM SGNL contains an exposure of core dump file to an unauthorized control sphere Vulnerability. This vulnerability is based on a JSP application in which the heap content is roughly equivalent to a \"core dump\" in which a password previously sent over HTTP would be included in this dump.' attack_vector: 'exposure of a core-dump file to an unauthorized control sphere (CWE-528), disclosing memory contents including plaintext messages and credentials from the TeleMessage server.' Citing gaps recorded against this entry include AU-Essential-8-MFA (multi-factor authentication) and UK-CAF-B2 (identity and access control).",
+        "gap_closes": [
+          "AU-Essential-8-MFA",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records a vendor patch, no live-patch path, and live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so on this product remediation is not complete when the fixed build is installed, only when the archiving service has been restarted onto it. Until that restart the JSP application is still the process serving the heap-equivalent dump. For this entry the control means the fixed release lands on a KEV-tied clock opened 2025-07-01 rather than in the next maintenance window, and that completion is measured per instance by the version actually running after restart, not by 'update applied' in a change record. The second half is specific to a disclosure defect under confirmed in-the-wild exploitation with a public PoC: the patch stops the dump being served from that moment forward and does nothing about what was already read. Every instance that was reachable before the restart therefore has to be treated as having leaked the message content and the credentials the packet places in that dump, with those credentials rotated inside the same SLA rather than as a later follow-up — patching an information-disclosure flaw is not a containment step. Distinguishing test: for each TM SGNL instance, measure elapsed time from the KEV listing to the fixed build running post-restart, and check whether the remediation record carries a rotation decision for the credentials that were resident in the process heap. A vulnerability-management programme that closes the ticket at patch deployment reports this entry as remediated while the disclosed credentials remain usable.",
+        "evidence": "Packet: CISA KEV-listed 2025-07-01, active_exploitation 'confirmed', poc_available true, CVSS 8.8, RWEP 77. patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' The vector places 'a password previously sent over HTTP' inside the dump, and the attack_vector describes 'disclosing memory contents including plaintext messages and credentials from the TeleMessage server' (CWE-528).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-48927": {
     "name": "TeleMessage TM SGNL Initialization of a Resource with an Insecure Default Vulnerability",
@@ -25291,7 +25832,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "/heapdump is a framework diagnostic function, not part of the archiving product's user-facing surface, and the packet puts the defect exactly there: TM SGNL ships with the Spring Boot Actuator configured so the heap-dump endpoint is exposed at a /heapdump URI, and an unauthenticated caller retrieves a heap dump containing plaintext messages and credentials. Bound to this deployment, the control means each Actuator management endpoint on the TM SGNL server authorizes its own caller before the function runs rather than inheriting reachability from the shipped default; that every diagnostic endpoint with no operational need — the heap-dump path first — is turned off rather than merely fronted; and that the management surface is segmented so a caller from an untrusted network cannot present the request at all. The least-privilege gap cited against this entry does not touch this path: the attacker never authenticates as any TM SGNL user, so per-account privilege scoping is never consulted and an access-review attestation passes cleanly while the endpoint answers anyone who can route to it. Two preconditions have to be stated rather than assumed. First, the configuration-side fix requires the operator to control the instance's Actuator endpoint-exposure settings; on a vendor-hosted or vendor-managed instance that lever belongs to the vendor, and the operator's only available actions are written confirmation that the endpoint is closed plus the network restriction below. Second, a reverse-proxy or WAF rule that blocks the /heapdump path constrains only requests that traverse the proxy — it does nothing for a caller that reaches the application's listener directly, so the restriction must be enforced at the listener bind address or by a host/network ACL, not at a filtering layer that can be routed around. Neither measure evicts an attacker who already pulled a dump: the messages and credentials inside it stay readable and valid until rotated. Distinguishing test: from a segment with no operational need for TM SGNL diagnostics, request /heapdump unauthenticated against a staging instance both through the normal proxy path and directly against the application listener, and confirm both are refused before a dump is generated.",
+        "evidence": "Packet vector: 'TeleMessage TM SGNL contains an initialization of a resource with an insecure default vulnerability. This vulnerability relies on how the Spring Boot Actuator is configured with an exposed heap dump endpoint at a /heapdump URI.' attack_vector: 'an insecure-default initialization (CWE-1188) that leaves a Spring Boot Actuator diagnostic endpoint (/heapdump) exposed, letting an unauthenticated attacker retrieve a heap dump containing plaintext messages and credentials.' CISA KEV-listed 2025-07-01 with active_exploitation 'confirmed'; CVSS 9.8, RWEP 77; poc_available true. Citing gaps recorded against this entry include AU-Essential-8-App-Hardening (user application hardening), NIST-800-53-AC-6 (least privilege), UK-CAF-B4 (system security) and NIS2-Art21-network-security.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records a vendor patch with no live-patch path and live_patch_notes stating that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so an instance that has taken the fixed build but has not restarted is still running the process whose Actuator configuration exposes /heapdump, and must be counted as exposed rather than remediated. For this entry the control means the fix lands on a KEV-tied clock opened 2025-07-01, with completion measured per instance by the build actually running after restart. What makes the SLA unusual on this entry is that a configuration-side action exists ahead of the vendor build: the packet attributes the exposure to how the Actuator is configured, so removing the endpoint's exposure closes the path immediately on any instance whose configuration the operator controls, and that action belongs on the KEV clock. It is not a reason to defer the patch — a configuration change can be reverted by a redeploy, a template rebuild, or a vendor update that restores the shipped default, and on a vendor-managed instance the operator may not hold that lever at all. Distinguishing test: re-request /heapdump on each instance after the service restart and again after any redeploy or image rebuild, and confirm it is still refused. A vulnerability-management programme that verifies once at patch time will not notice the shipped default returning on the next deployment.",
+        "evidence": "Packet: CISA KEV-listed 2025-07-01 with active_exploitation 'confirmed'; CVSS 9.8, RWEP 77; poc_available true; patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' The vector attributes the exposure to configuration: 'This vulnerability relies on how the Spring Boot Actuator is configured with an exposed heap dump endpoint at a /heapdump URI.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-6543": {
     "name": "Citrix NetScaler ADC and Gateway Buffer Overflow Vulnerability",
@@ -25675,7 +26240,40 @@
     },
     "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's vector puts the defect in the Linux kernel's OverlayFS subsystem — a uid-mapping bug in how a user copies a capable file from a nosuid mount into another mount — and says a local user escalates privileges on the system, so the flaw executes below every account boundary the Linux estate is audited on. For this CVE the control means the distribution kernel carrying the fix is driven across the whole affected fleet on the KEV clock that opened 2025-06-17 rather than folded into the next quarterly kernel window, and that completion is measured by the kernel each host is actually running, not by the kernel package version the inventory reports as installed. That distinction is the load-bearing one on Linux: the packet records no live-patch path and a fix that requires a service restart or system reboot, so a host that has installed the fixed kernel package but is still booted on the old image carries the vulnerable OverlayFS code in memory and must be counted as exposed, not as remediated. A patch-compliance report built on installed-package version alone will show this fleet green while every un-rebooted host remains fully exploitable. The control's second half is why the least-privilege gap is cited against this entry: the attacker is already an ordinary local user by the packet's own description, so tightening account privilege, sudo policy or group membership does not contain the escalation to root — a least-privilege attestation passes cleanly while the flaw stays fully exploitable. With a public PoC and confirmed in-the-wild exploitation, the pre-reboot window is contested rather than theoretical, which is what makes the reboot part of the remediation rather than a scheduling detail.",
+        "evidence": "Packet: CISA KEV-listed 2025-06-17 with active_exploitation 'confirmed'; CVSS 8.8, RWEP 77; poc_available true. Vector: 'Linux Kernel contains an improper ownership management vulnerability, where unauthorized access to the execution of the setuid file with capabilities was found in the Linux kernel's OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid mapping bug allows a local user to escalate their privileges on the system.' (CWE-282). patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps recorded against this entry include NIST-800-53-AC-6 (Least Privilege).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "With no live-patch path and a fix that only takes effect after reboot, every Linux host in the estate runs the vulnerable OverlayFS code until it restarts, and the packet records a public PoC alongside confirmed in-the-wild exploitation — so that window needs telemetry, not only a patch ticket. The auditd or eBPF rule has to key on what the packet says the exploit does rather than on what an exploit tool looks like: a non-root user assembling an overlay mount; a file carrying the setuid bit or file capabilities appearing in the writable upper layer after a copy-up from a nosuid lower mount; and then an execve of that file followed by the process transitioning to uid 0 while its audit login uid remains that of an ordinary user. Those three events are the mandatory emissions of the sequence the vector describes — mount, copy the capable file across, run it — so a rule built on them fires on any implementation of that sequence. Rules built on the usual alternatives do not fire at all here: this path completes successfully and produces no crash, so oops- or segfault-based kernel-exploit heuristics never trigger, and name- or hash-matching a published PoC binary misses a rebuild under any other name, which is the expected form given the packet records PoC availability. Alerting must be measured in seconds and routed as an active-intrusion signal rather than a hygiene finding, because the packet notes LPEs of this class are routinely paired with an initial-access primitive: by the time this rule fires the earlier step has already been missed, and the transition to root is the last observable event before the operator owns the host.",
+        "evidence": "Packet: poc_available true with active_exploitation 'confirmed'; CISA KEV-listed 2025-06-17; CVSS 8.8, RWEP 77. Vector describes 'unauthorized access to the execution of the setuid file with capabilities ... in the Linux kernel's OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid mapping bug allows a local user to escalate their privileges on the system.' attack_vector: 'an improper-ownership-management flaw (CWE-282) in the Linux kernel OverlayFS, exploited by a local user to copy a SUID file across mounts and gain root ... LPEs of this class are routinely paired with an initial-access primitive.' live_patch_available false, with live_patch_notes stating no live-patch tool is registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. UK-CAF-B4 (system security) is among the citing gaps.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The vulnerable code the packet names is the OverlayFS subsystem, so on hosts that do not use it the escalation path can be removed before the reboot the kernel fix requires — that is what this control buys on this CVE, and the precondition has to be stated precisely because it fails on a large share of a modern Linux estate. Where overlay is built as a loadable module and is not currently loaded, blacklisting it in modprobe configuration prevents the autoload that a user's mount attempt would otherwise trigger, and the escalation path is gone for that host. Where overlay is compiled into the kernel image rather than built as a module, a modprobe blacklist has no effect whatsoever, because there is no load to prevent. Where it is already loaded — any host whose container runtime uses an overlay filesystem for image layers, and any host with a live overlay mount — the blacklist changes nothing for the running kernel: the module cannot be unloaded while mounts reference it, and the host would have to reboot to come up without it, which is the same reboot the kernel fix needs, and on those hosts overlay usually cannot be removed at all because the runtime depends on it. Both of those cases fall back to the patch-and-reboot path plus kernel-escalation detection, and the blacklist must not be recorded as their mitigation. Verify per host rather than per policy: check the loaded-module list and the kernel's registered-filesystem list for overlay, and enumerate active overlay mounts. A non-empty result in any of the three means this control does not apply to that host — recording a fleet-wide blacklist as deployed would credit a mitigation that never took effect on exactly the hosts most likely to be running untrusted local workloads.",
+        "evidence": "Packet vector locates the flaw 'in the Linux kernel's OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount', with 'a local user' escalating privileges on the system (CWE-282). CISA KEV-listed 2025-06-17, active_exploitation 'confirmed', poc_available true, CVSS 8.8, RWEP 77. patch_available true; live_patch_available false with live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' — that reboot requirement is what creates the window this least-functionality control covers. UK-CAF-B4 (system security) is among the citing gaps.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-33538": {
     "name": "TP-Link Multiple Routers Command Injection Vulnerability",
@@ -25735,7 +26333,30 @@
     },
     "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": "On the small sites these units serve, the router is the trust boundary itself, and the packet's flaw is unauthenticated command execution reached through the /userRpm/WlanNetworkRpm component on the device's own web management surface — so the device that would enforce any network-layer control is the thing running the attacker's command. Scope the tier to the revisions the packet names and no further: TL-WR940N V2/V4, TL-WR841N V8/V10, TL-WR740N V1/V2. Nothing in the packet ties this component to other TP-Link models, so widening it to the vendor's line manufactures replacement work against hardware no evidence implicates. The tier requirement for this entry: firmware for the affected revision is deployed on the clock that opened with the 2025-06-16 KEV listing, not on the branch- or home-equipment cadence these devices normally sit on, and until it is, reachability of the HTTP management surface is the only lever an operator holds — the exploit needs nothing except the ability to put a request on that path, since the attacker never authenticates. Two preconditions have to be stated or the isolation gets recorded as the mitigation: restricting reach bounds who can send the request but leaves the vulnerable handler intact, and on a device whose LAN side is where its own users sit, \"internal only\" is a statement about topology rather than a demonstration that the surface is unreachable. It also does nothing for a unit already executing attacker commands. The distinguishing test: from every segment the device serves and from an external address, attempt to load its HTTP management surface — anything that answers is within reach of the published exploit. One caveat the packet forces: it records patch_available true while also stating the impacted products could be end-of-life and/or end-of-service with CISA advising users discontinue product utilization, so the per-revision support status decides whether fixed firmware exists for a given unit at all, and a revision for which it does not is replaced rather than carried forward on a patch report.",
+        "evidence": "Packet fields for CVE-2023-33538 (TP-Link Multiple Routers Command Injection Vulnerability): cwe_refs CWE-77; cisa_kev true, kev_date 2025-06-16; active_exploitation confirmed; cvss 9.8; rwep_score 77; poc_available true; patch_available true; live_patch_available false; live_patch_notes \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" Vector: \"TP-Link TL-WR940N V2/V4, TL-WR841N V8/V10, and TL-WR740N V1/V2 contain a command injection vulnerability via the component /userRpm/WlanNetworkRpm. The impacted products could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.\" attack_vector: \"a command-injection flaw (CWE-77) enabling unauthenticated remote command execution on the router.\" Citing gaps recorded on the entry include AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2, NIST-800-53-AC-6, UK-CAF-B4, NIS2-Art21-network-security.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Applied to these routers: exploitation is confirmed in the wild and a PoC is public for a path that reaches command execution with no credential at all, so a TL-WR940N, TL-WR841N or TL-WR740N unit that was reachable on /userRpm/WlanNetworkRpm before its firmware was updated cannot be returned to service on the strength of a version string. The runbook for such a unit defaults to capturing the running configuration as evidence first, flashing the fixed firmware from vendor media rather than upgrading in place from the running system, re-entering settings by hand instead of restoring a backup taken after the exposure window opened, and rotating everything the device held — the administrative credential, the wireless pre-shared key, and any credential reused on it. The limit is the point of the control: the firmware update closes the injection path, it does not undo a configuration change made through that path, so the operator still has to diff the items command execution can reach — administrative accounts, DNS settings, forwarding rules — against a known-good record, and a configuration restore from the exposure window reinstates exactly those changes under the fixed firmware. The cited least-privilege gap stays open in both directions on this path and no operator-side account scoping closes it: the attacker never authenticates, so no per-account privilege decision is ever consulted, and an attestation that every router administrator holds a scoped account passes cleanly while the unauthenticated path runs.",
+        "evidence": "Packet fields for CVE-2023-33538: active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 77; cisa_kev true with kev_date 2025-06-16. attack_vector: \"a command-injection flaw (CWE-77) enabling unauthenticated remote command execution on the router.\" Vector names the affected revisions TL-WR940N V2/V4, TL-WR841N V8/V10, TL-WR740N V1/V2 and the component /userRpm/WlanNetworkRpm. patch_available true; live_patch_available false, with live_patch_notes recording no registered live-patch tool and a vendor patch that typically requires service restart or system reboot per the KEV requiredAction. NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B4 (System security) are both recorded as citing gaps on the entry.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-43200": {
     "name": "Apple Multiple Products Unspecified Vulnerability (variant: CVE-2025-43200)",
@@ -26383,7 +27004,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The defect is a use-after-free in the Qualcomm Adreno GPU driver, and the packet records the trigger as memory corruption while rendering graphics using Adreno GPU drivers in Chrome, with the attack path a local foothold escalating privilege on the device. That combination is what makes the access-condition half of this control the load-bearing half: the operator cannot patch the driver directly, because the fixed driver code reaches a device only inside the build its hardware vendor ships for that chipset. The fixed build therefore has to act as a condition of access — organizational mail, VPN and document access denied to any device below it — rather than as a row on a patch-compliance dashboard. Scope it to the population the packet establishes: devices carrying the affected Qualcomm chipsets and the Adreno GPU driver. The packet ties the flaw to that driver and provides no mapping into other GPU stacks or renderers, so extending this to every graphics-accelerated endpoint in the estate would manufacture findings and denial-of-access work against hardware no evidence implicates. Distinguishing test: enrol a device pinned below the fixed build and confirm the policy actually refuses it access to protected resources — an estate that surfaces the stale build on a report while the device keeps its mail and VPN has recorded the exposure rather than removed it. Preconditions, stated: a device whose hardware vendor has not shipped a build containing this fix cannot be remediated by this control at all, and for those units the remaining levers are constraining what code the device is permitted to run, withholding organizational data from it, and — where no fixed build is coming — replacement. Restricting what runs on a device also does not evict code already resident on one, so a device suspected of already holding the local foothold the packet describes belongs on the incident path, not the policy path. And because the packet records no live-patch path and a fix requiring service restart or system reboot, a device that has downloaded the vendor build but not restarted is still running the vulnerable driver.",
+        "evidence": "Packet facts: CWE-416 use-after-free affecting multiple Qualcomm chipsets; the recorded vector is memory corruption while rendering graphics using Adreno GPU drivers in Chrome, and the recorded attack path is a local foothold escalating privilege on the device, with the packet noting that LPEs of this class are routinely paired with an initial-access primitive. CISA KEV-listed 2025-06-03, active_exploitation=confirmed, poc_available=true, CVSS 8.8, RWEP 77. patch_available=true, live_patch_available=false, with the note that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. Citing gaps include ASD Essential Eight 'Patch operating systems', ISO/IEC 27001:2022 A.8.8, NIST SP 800-53 SI-2 and UK CAF B4.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the KEV clock that opened 2025-06-03 runs against a fix the operator does not publish: the Adreno driver correction arrives inside a device-vendor build, so the SLA has to be written as 'fixed build installed and the device restarted, or a recorded time-bounded access restriction for that device', with the clock starting at the KEV listing or at availability of the build for that device model, whichever is later. Measuring the SLA as 'patches approved' or 'update pushed' is vacuous on this path, because the packet records no live-patch path and a fix requiring restart or reboot — a device that has taken the update and not restarted is still running the vulnerable driver and must be counted against the SLA as exposed. The state that has to be reported distinctly, rather than folded into a pass, is the device that is inside the window with no fixed build available for its model: that is not a deferral, it is an unremediated device, and the only lever left is the access restriction, which bounds what the device can reach and does not repair the driver.",
+        "evidence": "Packet facts: CISA KEV-listed 2025-06-03 with active_exploitation=confirmed and poc_available=true; CVSS 8.8, RWEP 77; CWE-416 in the Qualcomm Adreno GPU driver. patch_available=true, live_patch_available=false, with the recorded note 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Citing gaps include ASD Essential Eight 'Patch operating systems', NIST SP 800-53 SI-2 and EU NIS2 Art.21 vulnerability handling and disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2021-32030": {
     "name": "ASUS Routers Improper Authentication Vulnerability",
@@ -26563,7 +27209,31 @@
     },
     "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 primitive the packet records is a write, not a read: an unauthenticated client introduces arbitrary values — the packet names PHP code — into a known local file location on the Craft CMS server. That is the distinction this control exists for, because the vendor update repairs the parameter-handling path and reverts nothing already written through it. Applied to this product: any internet-reachable Craft install that was serving before the fixed release landed is triaged as a possibly-compromised host rather than closed out on the upgrade — the deployed tree is compared against the source of record for files the web server can execute but that no deployment put there, and the credentials and keys that install held are rotated. The packet also records this flaw as chainable with CVE-2024-58136 (as represented by CVE-2025-32432), so the exposure to assess is the chain's outcome on the host, not a single tampered parameter. Precondition, and it is the load-bearing one: this comparison only decides anything if the operator holds a reference the install can be diffed against — a version-controlled deployment or a known-good image from before the exposure window. A Craft install whose web root has been edited in place over its life has no such reference; inspection cannot clear it, and redeployment from the source of record is the remaining option rather than an optional stronger step. Distinguishing test: after upgrading a formerly exposed install, diff the deployed tree against the source of record and confirm no unaccounted PHP file — a flaw-remediation attestation recording that Craft was upgraded to the fixed release reads clean over a file written before the upgrade.",
+        "evidence": "The packet's vector states that the vulnerability could allow an unauthenticated client to introduce arbitrary values, such as PHP code, to a known local file location on the server, and that it could be chained with CVE-2024-58136 as represented by CVE-2025-32432 (CWE-472). active_exploitation is confirmed and poc_available is true; the entry is CISA KEV-listed 2025-06-02 with CVSS 8.8 and RWEP 77. patch_available is true and live_patch_available is false, with live_patch_notes recording that no live-patch tool is registered for this entry and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "A CVSS 8.8 web-application flaw normally enters a routine application-patch queue, but the packet pairs it with confirmed in-the-wild exploitation and a public PoC against a path that needs no credential — which is the condition the compressed clock exists for. For Craft CMS the control means the fixed release is driven across every Craft install the organization operates, on the clock that opened with the 2025-06-02 KEV listing, and completion is measured by each site reporting the fixed Craft version rather than by 'update scheduled' on a release board. The installs that decide the outcome are the ones an application inventory tends not to hold — sites standing up under an agency or contractor deployment — because a copy nobody is tracking keeps serving the unauthenticated write path on the same schedule as one that is. The packet registers no live-patch path and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a site whose files carry the fixed release but whose service has not been cycled is counted as exposed, not as remediated. Precondition on any interim measure: the packet records no vendor workaround or compensating mitigation for this flaw, so anything an operator puts in front of a site that cannot take the update inside the window — restricted reachability, a maintenance page, a filtering layer — is unvalidated against this specific parameter and reduces exposure rather than removing it; the site is still counted against the SLA until it reports the fixed version.",
+        "evidence": "CISA KEV-listed 2025-06-02 with active_exploitation confirmed and poc_available true; CVSS 8.8, RWEP 77. The vector describes an unauthenticated client introducing arbitrary values, such as PHP code, to a known local file location on the server. patch_available is true; live_patch_available is false, and live_patch_notes records that no live-patch tool is registered for this entry and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction. The packet records no vendor-supplied workaround or compensating mitigation for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-56145": {
     "name": "Craft CMS Code Injection Vulnerability (variant: CVE-2024-56145)",
@@ -27317,7 +27987,32 @@
     },
     "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 puts remote code or command execution behind a crafted HTTP request to four named Fortinet appliances — FortiFone, FortiVoice, FortiNDR and FortiMail — with no credential and no user interaction anywhere in the path, so the appliance's own request-handling surface is what fails. That is the tier's premise, and it is why the standard 14/30-day appliance-patch window does not apply here: the fixed firmware has to be driven across every affected unit of those four product families on the clock that opened with the 2025-05-14 KEV listing. The packet registers no live-patch path and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so completion is measured per unit as 'running the fixed build and restarted since', not as 'image pushed' or 'update approved' in a management console — a unit that has staged the firmware without restarting is still executing the vulnerable code. The tier's alternative branch, isolating the vulnerable interface, carries a precondition that must be stated rather than assumed: the packet says 'crafted HTTP requests' without distinguishing an administrative interface from a user-facing web surface, so any reachability restriction has to cover every HTTP listener each unit exposes, and on a unit that must answer HTTP from untrusted networks to perform its function isolation is not available at all — for those, the update plus the restart is the only path and no interim control substitutes for it. Distinguishing test: query each affected unit directly for its running firmware and its uptime since the update, rather than accepting a fleet report that lists the four product families as patched to policy.",
+        "evidence": "The packet's vector: 'Fortinet FortiFone, FortiVoice, FortiNDR and FortiMail contain a stack-based overflow vulnerability that may allow a remote unauthenticated attacker to execute arbitrary code or commands via crafted HTTP requests' (CWE-124). CISA KEV-listed 2025-05-14 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 77. patch_available is true; live_patch_available is false, with live_patch_notes recording that no live-patch tool is registered for this entry and 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",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Exploitation is confirmed and a PoC is public, so on these four Fortinet products the question the firmware update does not answer is what executed before it landed. The packet's outcome is arbitrary code or command execution on the appliance by a caller who never authenticated, which means anything left behind — an added administrative account, an altered configuration, a placed file — survives an in-place upgrade, because the upgrade replaces the vulnerable code and not the unit's configuration and stored state. For any FortiFone, FortiVoice, FortiNDR or FortiMail unit whose HTTP surface was reachable from an untrusted network between the 2025-05-14 KEV listing and its restart on the fixed build, the default response is to export and diff the configuration against a known-good baseline, rebuild the unit from that baseline rather than upgrading in place, and rotate every credential the unit held or that authenticated through it. Precondition, and it decides whether this is usable at all: the diff is only meaningful against a configuration baseline captured before the exposure window, and 'we found nothing on the appliance' is not evidence of anything when the only record of the unauthenticated HTTP requests sits on the same device that the packet says an attacker can execute code on. Where no pre-exposure baseline and no off-box record of what the unit served exist, the honest position is that the unit's state is undecidable and rebuilding is faster than proving it clean — not that the upgrade closed the matter.",
+        "evidence": "The packet's vector records a remote unauthenticated attacker executing arbitrary code or commands via crafted HTTP requests against FortiFone, FortiVoice, FortiNDR and FortiMail (CWE-124, stack-based overflow). active_exploitation is confirmed and poc_available is true; CISA KEV-listed 2025-05-14, CVSS 9.8, RWEP 77. patch_available is true and live_patch_available is false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — so the fixed build is reached through a restart, and it replaces the vulnerable code rather than the unit's configuration.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-32709": {
     "name": "Microsoft Windows Ancillary Function Driver for WinSock Use-After-Free Vulnerability",
@@ -28880,7 +29575,34 @@
     },
     "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": "CrushFTP is the file-transfer server that faces external counterparties, and the packet's defect is its authentication path failing open: a crafted HTTP Authorization header assumes crushadmin or another known account and hands over administrative control of the server. Nothing is stolen and no privilege is misused first, so the tier's premise holds exactly — a defect in the component that decides who is authenticated on an internet-reachable server does not belong in a standard application-patch window, and the fixed release has to land on the clock that opened with the 2025-04-07 KEV listing rather than at the next scheduled maintenance. The tier's second branch, isolating the vulnerable interface, has a precondition the packet states outright: the takeover grants administrative control unless the instance is fronted by a DMZ proxy instance. That deployment mode bounds this specific path and a directly exposed instance has no such buffer — so it is a per-instance condition to verify, not a control to record once for the product. It also does not hold retroactively: an instance that was directly exposed before a proxy was placed in front of it is an incident to work, not an instance the proxy has protected, and the proxy does not undo an administrative session an attacker already opened. Distinguishing test: enumerate every CrushFTP instance the organization runs and record, per instance, whether it answers HTTP directly from untrusted networks or only through the DMZ proxy instance, and whether it is on the fixed release — a patch-management attestation reporting the product as covered does not distinguish the two deployment shapes, and it is the directly exposed instances that carry the whole exposure.",
+        "evidence": "The packet's vector: a crafted HTTP Authorization header exploits a flaw in the authentication path to bypass authentication and assume the crushadmin (or other known) account, granting administrative control of the file-transfer server (CWE-305). The attack_vector adds that this holds 'unless fronted by a DMZ proxy instance', that it was exploited in the wild March-April 2025, and that the managed-file-transfer class is a proven ransomware/data-extortion initial-access vector (MOVEit lineage). CISA KEV-listed 2025-04-07 with active_exploitation confirmed and poc_available true; CVSS 9.8, RWEP 76. patch_available is true; live_patch_available is false and live_patch_notes is null, so the packet records the vendor update as the remediation and registers no live-patch path.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3",
+          "AU-ISM-1546",
+          "NIS2-Art21-network-security",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records exploitation in the wild in March-April 2025 against a flaw that hands an unauthenticated caller the crushadmin account on a server whose purpose is holding and moving files with external counterparties, and it ties this product class to ransomware and data-extortion initial access through the MOVEit lineage. The update repairs the authentication path and reverts nothing done through it while it was open: accounts and permissions added or altered, server and job configuration changed, credentials readable from the administrative surface, and data already copied out. For any instance that answered HTTP from untrusted networks before the fixed release landed, the default is to treat the server as compromised until shown otherwise — diff the current account list and configuration against a copy captured before the exposure window, rotate every account the server holds including counterparty credentials, and scope the data-exposure question across everything the server could reach, because the packet's outcome is administrative control rather than a single file read. Precondition and scope limit: the packet describes administrative takeover, not code execution, so the justification for rebuilding is that the account and configuration state is untrustworthy — not that the binary is. Whether that is decidable turns on holding a pre-exposure configuration baseline and access records kept off the server; where neither exists, redeploying the fixed release onto a known-good configuration is the shorter path, and the absence of alerts is not a substitute for the diff. Distinguishing test: compare the current CrushFTP account list against the pre-exposure baseline and account for every difference.",
+        "evidence": "The packet's vector places the bypass in the authentication path via a crafted HTTP Authorization header, with the attacker assuming crushadmin or another known account and gaining administrative control of the file-transfer server (CWE-305). active_exploitation is confirmed, and the attack_vector records exploitation in the wild March-April 2025 plus the managed-file-transfer class as a proven ransomware/data-extortion initial-access vector (MOVEit lineage); poc_available is true. CISA KEV-listed 2025-04-07; CVSS 9.8, RWEP 76. patch_available is true, live_patch_available is false and live_patch_notes is null — the packet records the vendor update as the remediation, and that update addresses the authentication path rather than any account or configuration change made through it.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3",
+          "AU-ISM-1546"
+        ]
+      }
+    ]
   },
   "CVE-2009-3459": {
     "name": "Adobe Acrobat and Reader Heap-Based Buffer Overflow",
@@ -29123,7 +29845,28 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet names the sink as the QuickTime parsing path inside Microsoft DirectShow and dates the fix to MS09-028 in 2009, while the KEV listing is dated 2026-05-20 — and that pairing is the whole finding. The remediation question here is not whether a fix exists but which hosts never received one that has been available for that long. On a real estate those hosts are precisely the ones a monthly update report does not describe: hosts built from an old image and never re-baselined, hosts restored from backup, hosts held offline, and hosts embedded in an appliance or process-control system whose vendor owns the Windows build. The control here means enumerating the hosts on which the DirectShow media stack is present and confirming each reports the MS09-028-fixed state of that component directly, rather than accepting a \"fully patched\" verdict from a scan whose baseline begins at a modern build and never asks about a 2009 bulletin. Scope it to what the packet establishes: the packet ties the CWE-787 sink to Microsoft DirectShow's QuickTime parsing path and provides no mapping from that code into Apple QuickTime Player or any other media application, so instructing operators to inventory and strip every media-handling binary on the estate manufactures findings and real removal work against software no evidence implicates — widen only where a verified source identifies another product carrying the same parser. Distinguishing test: select the hosts least likely to sit in the managed update channel — restored, imaged, appliance-embedded — and verify the DirectShow component's patch state on each directly; an estate whose flaw-remediation attestation reads clean because the scanner only reports on the updates it currently tracks still opens crafted QuickTime media straight into the sink. Precondition: this reaches only hosts the inventory can see and the operator can update. The packet records no live-patch path and states MS09-028 requires a reboot, so a host that has taken the update but not rebooted is not yet remediated, and a host whose build the operator cannot change — a vendor-owned appliance image — is remediated by the vendor or by removing its exposure to attacker-supplied media, not by recording it as patched.",
+        "evidence": "Packet fields for this entry: \"Parsing a maliciously crafted QuickTime media file in Microsoft DirectShow corrupts memory (NULL-byte overwrite class), allowing remote code execution when a user opens the file\"; attack_vector records \"a memory-corruption flaw (CWE-787) in the Windows DirectShow QuickTime parser, exploitable by an attacker-controlled media file for code execution when the victim opens it\". cwe_refs CWE-787. cisa_kev true, kev_date 2026-05-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 70. patch_available true, live_patch_available false, live_patch_notes: \"Microsoft patch MS09-028 (2009); requires reboot.\" ISO-27001-2022-A.8.8 (Management of technical vulnerabilities) and NIST-800-53-SI-2 (Flaw Remediation) are recorded as citing gaps against this entry.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The control's \"KEV listing or patch availability, whichever is later\" clause resolves unusually cleanly for this entry: the packet dates the vendor fix to MS09-028 in 2009 and the KEV listing to 2026-05-20, so the clock starts at the listing and there is no patch-development wait to absorb. The entire remediation window is the operator's own discovery-and-reboot time, which turns the SLA from a deployment obligation into a hunt-and-reboot obligation — find the hosts still missing MS09-028 and get them restarted onto the fix inside the clock, and measure completion by the DirectShow component's state on each host after restart rather than by \"update approved\" in a management console. The packet records the fix as reboot-required with no live-patch path, so the restart sits inside the window, not after it. Precondition and honest limit: the clock does not shorten the discovery problem — a host the estate does not know about cannot be counted against it, so this SLA only means anything when it is paired with the direct per-host enumeration this entry's inventory control describes. A host that genuinely cannot be rebooted inside the window — a production-control or vendor-owned appliance host — is a named, dated exception whose exposure to attacker-supplied media is restricted in the interim, not a silently open item. That restriction narrows the delivery path, since the packet requires a user to open the crafted file, but it does not remove the sink: the exception must carry a reboot date, or it is a risk acceptance wearing a mitigation's name.",
+        "evidence": "Packet fields for this entry: the vector records remote code execution \"when a user opens the file\" after Microsoft DirectShow parses a maliciously crafted QuickTime media file (CWE-787). cisa_kev true, kev_date 2026-05-20, active_exploitation confirmed, poc_available true, cvss 8.8, rwep_score 70. patch_available true, live_patch_available false, live_patch_notes: \"Microsoft patch MS09-028 (2009); requires reboot.\" NIS2-Art21-patch-management (Vulnerability handling and disclosure) is recorded as a citing gap against this entry.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2008-4250": {
     "name": "Microsoft Windows Server Service RPC Buffer Overflow (MS08-067)",
@@ -29682,7 +30425,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)",
@@ -29815,7 +30582,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)",
@@ -29930,7 +30718,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)",
@@ -31207,7 +32008,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",
@@ -31705,7 +32531,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",
@@ -31870,7 +32720,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",
@@ -32443,7 +33316,31 @@
     },
     "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 delivery path in this packet removes every user-side gate: a crafted media file arrives over iMessage and CoreAudio decodes the embedded audio stream with no user interaction, so nothing the device holder does or declines to do changes their exposure, and an update ring that permits holder deferral is itself the exposure window. Push the Apple update carrying the CoreAudio fix across the iOS, iPadOS and macOS estate under declarative device management with deferral disallowed, on a clock started at the 2025-04-17 KEV listing, and measure completion by the build each device reports rather than by the update policy having been assigned. The packet records a vendor update and no live-patch path for this product class, so a device that has downloaded but not completed the update still runs the vulnerable CoreAudio parser and counts as exposed. Precondition: this reaches only devices the management channel actually controls — personal and unenrolled devices carrying organizational mail or messaging sit outside the push, and for those the fixed build has to become a condition of that access instead, because there is no user-behaviour guidance that helps against a path requiring no user interaction.",
+        "evidence": "Packet: vector states CoreAudio \"parses audio streams embedded in media files without adequate bounds checking (CWE-119)\" and that the crafted file is \"reachable with no user interaction via zero-click iMessage delivery\", triggering an out-of-bounds write during audio-stream decoding (network attack vector, no privileges, no UI: CVSS 9.8). CISA KEV 2025-04-17, active_exploitation confirmed, RWEP 81, patch_available true, live_patch_available false, live_patch_notes: \"No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this bug inside a chain used in a spyware operation — the CoreAudio out-of-bounds write supplies code execution in the media-processing context and was paired with CVE-2025-31201 to defeat pointer-authentication and escalate toward fuller device compromise — which is a targeted profile rather than opportunistic exploitation. For the cohort plausibly inside that targeting set, the update alone is not fast enough: the packet gives no live-patch path, so every device has to be carried through the vendor update individually. Place that cohort in the platform's reduced-attack-surface mode so message attachments and other untrusted media are not decoded automatically on receipt, which narrows the no-interaction route into the CoreAudio parser during the window between the 2025-04-17 listing and the completed update. The preconditions are the substance of this control, not a footnote. The mode only helps if it was already enabled when the message arrived, so it has to be a standing posture assigned to the high-risk cohort ahead of the next disclosure rather than a response to this one. It constrains automatic decoding only — it does not make the parser unreachable, and a media file the holder deliberately opens from another channel still reaches it. And it evicts nothing already resident: a device suspected of having received this chain belongs on the incident path with the second-stage compromise the packet describes treated as assumed, since enabling the mode afterwards neither removes an implant nor disproves one.",
+        "evidence": "Packet: vector states the out-of-bounds write yields \"the primitive for arbitrary code execution in the media-processing context\" and that \"in observed in-the-wild use it was chained with CVE-2025-31201 (Pointer Authentication / RPAC bypass with arbitrary read-write) to defeat memory-safety mitigations and escalate toward fuller device compromise as part of a sophisticated spyware operation\"; zero-click iMessage delivery with no user interaction; CISA KEV 2025-04-17; active_exploitation confirmed; poc_available true; live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-20035": {
     "name": "SonicWall SMA100 Appliances OS Command Injection Vulnerability",
@@ -32642,7 +33539,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",
@@ -32752,7 +33680,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",
@@ -32807,7 +33760,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",
@@ -33304,7 +34292,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "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 defect is that enforcement failing open on a second channel: authentication is enforced on the primary path but not consistently on the Security Fabric (CSF) proxy path served by the Node.js websocket and CSF request handler, so a crafted CSF proxy request is processed with downstream-device super-admin authority. For this CVE the expedited clock runs from the KEV listing of 2025-03-18 through the completed vendor update of every affected FortiGate and FortiProxy unit. The packet records a vendor patch with no live-patch path and states that remediation is the vendor update plus the named compensating controls until it lands, so a unit not yet taken through that update is exposed regardless of how well its administrator accounts are governed. Precondition on the interim measure, stated plainly because it is the part that gets recorded as the mitigation: the packet makes reachability conditional on the Security Fabric being enabled and the HTTP/HTTPS admin interface (or the CSF proxy) being exposed, so the window can be bounded — bounded, not closed — by enumerating which units have Security Fabric enabled and restricting which sources can reach their administrative surfaces. It does not remove the path. A unit that must keep Security Fabric enabled to do its job, and any source already able to route to the admin interface or CSF proxy, still reaches the alternate channel; the packet's only other stated requirement is that the attacker know the upstream and downstream CSF device serial numbers. Distinguishing test: from a segment with no fabric role and no administrative role, attempt to reach the CSF proxy and the HTTP/HTTPS admin interface of a staging unit and confirm both are refused before any request is processed — a patch-compliance report showing the fleet on a supported release says nothing about which of those units still accept CSF proxy requests from arbitrary sources.",
+        "evidence": "Packet: CWE-288, authentication bypass using an alternate path or channel, on Fortinet FortiOS and FortiProxy. A remote, unauthenticated attacker who can reach the FortiGate/FortiProxy management plane and who knows the serial numbers of the upstream and downstream Security Fabric (CSF) devices sends crafted CSF proxy requests over the Node.js websocket and CSF request handler; because authentication is enforced on the primary path but not consistently on this alternate channel, the request is processed with downstream-device super-admin authority. Reachability requires the Security Fabric to be enabled and the HTTP/HTTPS admin interface (or CSF proxy) to be exposed. CISA KEV-listed 2025-03-18, active_exploitation confirmed, CVSS 8.1, RWEP 59. patch_available true; live_patch_available false; live_patch_notes: \"No live-patch path for this product class; remediation is the vendor update 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",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at the bypass — it records what the operator does with the super-admin authority it grants: creates persistent admin and SSL-VPN accounts, alters firewall policy, and pivots into the internal network, with exploitation confirmed in the wild. The vendor update undoes none of that. Applied to this device, the control means any FortiGate or FortiProxy unit that met the packet's reachability conditions during the exposure window — Security Fabric enabled and the admin interface or CSF proxy exposed — is handled as a compromised device rather than an unpatched one: export the configuration and diff it against a known-good baseline for administrator and SSL-VPN accounts and policy entries that no change record accounts for, rotate every credential the device holds or terminates, and restore from a verified baseline rather than patching in place. The flaw is an authentication bypass rather than code execution, so the persistence the packet documents is configuration-resident — accounts and policy — which is precisely what a configuration diff and credential rotation address and what a firmware upgrade preserves. Scope limit: this is the response for units whose stated reachability conditions held; a unit where the Security Fabric was never enabled does not meet the packet's precondition for the attack and belongs on the update path, not the rebuild path. The distinguishing test runs against account and policy state, not build number: on a unit already taken through the update, enumerate the administrator and SSL-VPN accounts and the policy table and confirm every entry maps to an authorized change — a fleet reporting the fixed build while carrying an attacker-created super-admin or SSL-VPN account is still under attacker control, and the flaw-remediation attestation reads clean the whole time.",
+        "evidence": "Packet: \"The bypass yields full super-admin on the downstream device, from which the operator creates persistent admin and SSL-VPN accounts, alters firewall policy, and pivots into the internal network.\" Reachability requires the Security Fabric to be enabled and the HTTP/HTTPS admin interface (or CSF proxy) to be exposed. active_exploitation confirmed; CISA KEV-listed 2025-03-18. patch_available true, live_patch_available false — remediation is the vendor update, which changes device code and not device configuration state.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-21590": {
     "name": "Juniper Junos OS Improper Isolation or Compartmentalization Vulnerability",
@@ -33359,7 +34372,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",
@@ -34060,7 +35105,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Ivanti EPM is the endpoint-management server itself, and this defect is an absolute path traversal (CWE-36) that a remote unauthenticated attacker uses to leak sensitive information — the file-read sink is reached before any authentication decision is taken, so the caller's identity is never consulted and no account-side control is in the path. Bound to this product the requirement is twofold: the EPM endpoint must authenticate the caller before it processes the request at all, and it must resolve a caller-supplied path to its canonical absolute form and confirm the result still sits inside the directory the endpoint is meant to serve, before any file handle is opened — rejecting absolute paths outright rather than filtering the request string. Preconditions: that repair lives in the vendor update — the 2024 January-2025 Security Update, or the 2022 SU6 January-2025 Security Update on the 2022 branch — so this control states the property to verify, it does not implement it. Until the update lands the operator's only lever is reachability: no EPM instance should present that endpoint to a network with no operational need to reach it. That bounds who can send the traversal; it does not close it for anyone who legitimately reaches the console, so it is a compensating restriction with an end date, not a fix. The packet records no live-patch path, so remediation is the vendor update plus those compensating controls until it lands. Distinguishing test: from an unauthenticated client on a staging instance, request an absolute path outside the served directory and confirm refusal before the file is opened.",
+        "evidence": "Packet: cwe_refs CWE-36; 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.' cvss 9.8, poc_available true, active_exploitation confirmed, kev_date 2025-03-10. live_patch_available false with live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update (or, for end-of-life products, decommissioning) plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the fix predates the listing — the packet places the vulnerability in builds before the 2024 January-2025 Security Update and the 2022 SU6 January-2025 Security Update, while CISA listed on 2025-03-10 with a due date of 2025-03-31 — so the control's 'whichever is later' clock runs from the KEV listing, and the operator-visible question is what happens in the 21 days the KEV due date permits and the framework patch cadences permit on top of that. The packet's facts do not survive that window: a remote, unauthenticated, CVSS 9.8 disclosure flaw on a fleet-management server, with a public PoC and confirmed in-the-wild exploitation, needs no target-specific reconnaissance to fire. For this CVE the requirement is that the January-2025 Security Update (or 2022 SU6 January-2025 Security Update) is deployed within 4 hours of the 2025-03-10 listing, or that the reachability restriction is recorded as an active compensating mitigation with a bounded end date rather than as SLA compliance. Precondition on the measurement: 'deployed' means each EPM server's own reported version, not an approved or downloaded state in the update console — the packet gives no live-patch path, so nothing is remediated until the server is actually running the updated build.",
+        "evidence": "Packet: kev_date 2025-03-10, with attack_vector recording 'CISA KEV-listed 2025-03-10 (due 2025-03-31) with confirmed in-the-wild exploitation.' The vector places the fix in the 2024 January-2025 Security Update and the 2022 SU6 January-2025 Security Update. cvss 9.8, poc_available true, patch_available true, live_patch_available false, active_exploitation confirmed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "EPM administers the endpoint fleet, and the outcome the packet records is disclosure: an unauthenticated remote attacker leaking sensitive information off that server, with exploitation confirmed in the wild and a public PoC. Patching a disclosure flaw does not un-disclose it — an instance that was reachable and below the January-2025 Security Update during the exposure window has to be handled as having returned whatever an arbitrary-file read from that host would return, which on a fleet-management server is service-account and configuration material the rest of the estate trusts. The playbook for this product: enumerate what the EPM service account and the server's on-disk configuration can reach, rotate the secrets held there, and review agent and policy changes pushed through the console during the window — all before the vulnerability ticket closes. Preconditions and limits: the packet does not enumerate which files the traversal returns, so the rotation scope is derived from what the host holds rather than from confirmed exfiltration; and the packet records information disclosure with no code-execution outcome, so this is a disclosure-scoped response — credential rotation and change review are warranted, a rebuild is not implied by these facts alone. The playbook is also bounded by exposure evidence: an instance you cannot show was unreachable during the window is in scope by default.",
+        "evidence": "Packet: vector states 'a remote unauthenticated attacker to leak sensitive information'; active_exploitation confirmed, poc_available true, cisa_kev true with kev_date 2025-03-10, rwep_score 73. The packet enumerates no specific files returned by the traversal and records no code-execution impact.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-13159": {
     "name": "Ivanti Endpoint Manager (EPM) Absolute Path Traversal Vulnerability (GetHashForWildcardRecursive)",
@@ -34115,7 +35193,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",
@@ -34449,7 +35559,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",
@@ -34590,7 +35723,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",
@@ -35174,7 +36330,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",
@@ -35507,7 +36696,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",
@@ -35870,7 +37080,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",
@@ -36080,7 +37311,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",
@@ -36122,7 +37376,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",
@@ -36532,7 +37817,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",
@@ -37333,7 +38651,32 @@
         "adequate": false,
         "gap": "Patch-operating-system control is necessarily reactive to a pre-disclosure zero-day exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "CLFS is a kernel-mode driver of Windows itself, so the heap overflow the packet describes executes below every account boundary the endpoint estate is audited on: the attacker begins as a low-privileged local user who is legitimately entitled to be on the host and ends as SYSTEM. That is why AC-6 and UK-CAF-B2 are recorded as insufficient against this entry — constraining what the user's account may do never contains an escalation that does not consult the account model, and a least-privilege or identity-and-access attestation reads clean while the path stays fully open. The enforceable lever is the remediation window: drive the Windows update carrying the CLFS fix across the whole affected fleet on the clock that opened with the 2024-12-10 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 records a vendor patch and no live-patch path, so the fix does not reach the driver already resident in a running kernel — a host on which the update is pending completion still runs the vulnerable CLFS driver and counts as exposed, not remediated. Sequence the fleet by where a low-privileged foothold is most likely to already exist: the packet describes this escalation as a step commonly taken before ransomware deployment, so ordinary user endpoints where initial-access payloads land are the priority, not only servers.",
+        "evidence": "Packet: CWE-122 heap-based buffer overflow in the Windows CLFS driver. attack_vector: \"A local attacker with low privileges triggers a heap-based buffer overflow in the CLFS kernel driver via crafted log-file structures, escalating to SYSTEM privileges — commonly used as a precursor step before ransomware deployment.\" CISA KEV 2024-12-10, active_exploitation confirmed, RWEP 81, CVSS 7.8, patch_available true, live_patch_available false. Citing gaps include NIST-800-53-AC-6 (Least Privilege) and UK-CAF-B2 (Identity and access control).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Because the escalation runs inside a kernel driver and never consults the account model, the transition itself is the only place it becomes visible — and the packet states precisely what an exploit doing this emits: a low-privileged local process driving the CLFS logging path with crafted log structures, and then that process or its lineage acting with SYSTEM authority. Build the rule on that pairing: CLFS log creation or manipulation by a process running as an ordinary user, followed within a short window by a SYSTEM-authority token on that process or a SYSTEM-integrity child in the same lineage. Explicitly do not key it on the driver or host faulting — a working exploit corrupts the heap without crashing, so a crash-derived rule is blind on exactly the runs that succeed — and do not key it on the name or hash of a known tool, because the packet records a public proof-of-concept and a recompiled binary defeats that on the first attempt. Distinguishing test: detonate the available proof-of-concept on an instrumented staging host and confirm the rule fires on the log-manipulation-then-SYSTEM sequence, rather than confirming only that kernel telemetry is being collected. Preconditions: this detects, it does not prevent — the escalation completes, and the value is the dwell time removed before the ransomware step the packet names; and the alert must leave the host, because a process that has just reached SYSTEM can stop a local agent and clear a local log, so a rule whose only evidence stays on the compromised endpoint is silent at the moment it fires.",
+        "evidence": "Packet: attack_vector describes a low-privileged local attacker triggering the CLFS heap overflow \"via crafted log-file structures, escalating to SYSTEM privileges — commonly used as a precursor step before ransomware deployment\"; poc_available true; active_exploitation confirmed; CISA KEV 2024-12-10; CWE-122.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2024-51378": {
     "name": "CyberPanel Incorrect Default Permissions Vulnerability",
@@ -37760,7 +39103,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",
@@ -37908,7 +39275,30 @@
         "adequate": false,
         "gap": "Least-privilege wasn't enforced at the Expedition database layer, which stored recoverable firewall credentials and API keys reachable via a single unauthenticated SQLi."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Expedition is not itself a firewall, but the packet has its database holding PAN-OS password hashes, usernames, device configurations and device API keys — so an unauthenticated SQL-injection read against Expedition hands over the credentials to the perimeter, not merely to Expedition. The vendor update stops further extraction and does nothing about material already extracted, which is why patch-in-place is the wrong default here. Applied to this product: every PAN-OS credential and every device API key the instance held is treated as disclosed and rotated on the firewalls themselves, and the Expedition host is rebuilt rather than patched in place — the same flaw lets the attacker create arbitrary files on the Expedition system, and a file written before the update survives it. Scope the rotation to every device whose configuration was ever imported into that instance rather than to the current project only, because the packet describes disclosure of the database contents rather than of one record; where the import history cannot be reconstructed, the rotation scope is the whole estate the instance was ever used for. Precondition on the sequencing: rotating firewall credentials while the Expedition host is still standing and unrebuilt re-exposes the new material the moment the estate is re-imported, so rebuild precedes re-import. patch_available is true and no live-patch path is registered for this entry, so the instance goes through the vendor update — but an estate with rotated credentials and an unrebuilt Expedition host is half-remediated, not remediated.",
+        "evidence": "Packet: Palo Alto Networks Expedition SQL Injection Vulnerability, CWE-89, CISA KEV-listed 2024-11-14, active_exploitation confirmed, CVSS 9.1, RWEP 66, poc_available true. Vector: 'An SQL injection vulnerability in Palo Alto Networks Expedition allows an unauthenticated attacker to reveal Expedition database contents, such as password hashes, usernames, device configurations, and device API keys. With this, attackers can also create and read arbitrary files on the Expedition system.' The attack_vector identifies the dumped hashes as PAN-OS firewall password hashes and the keys as device API keys. patch_available is true; live_patch_available is false with no live-patch entry recorded for this CVE.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-046",
+        "name": "PEN-TEST-SCOPE-INCLUDES-SECURITY-PRODUCTS",
+        "description": "Expedition is a security vendor's own product and, on the packet's description of what its database holds, it functions as a credential store for the firewall estate — the category this control says must be attacked rather than assumed to be a defense. The defect is a pre-authentication SQL injection in its web application: the single most-tested class of web finding, reachable by anyone who can route to the interface, sitting in a product that testing programs routinely classify as tooling and leave out of scope. For this CVE the control means the Expedition web application is named explicitly in test and red-team scope with its unauthenticated request surface in scope, and that the PCI-DSS software-engineering requirement cited against this entry is read for what it covers — the entity's own bespoke code. Expedition is purchased software, so no secure-coding attestation the operator signs ever inspects the query carrying this injection, and the requirement can be fully met while this path stays open. Distinguishing test: direct the same unauthenticated injection testing the programme applies to its bespoke applications at a staging Expedition instance; if the scope document contains no line item under which that test could be authorized, the product has been treated as a defense rather than as attack surface. Precondition and limit: this control changes when the operator finds such a defect, not whether it exists — it produces no remediation on its own, and the vendor update plus the credential rotation and host rebuild remain the remediation for this CVE.",
+        "evidence": "Packet: Palo Alto Networks Expedition SQL Injection Vulnerability, CWE-89, CISA KEV-listed 2024-11-14, active_exploitation confirmed, CVSS 9.1, RWEP 66, poc_available true. The vector states the attacker is unauthenticated and that the injection reveals Expedition database contents including password hashes, usernames, device configurations and device API keys, and permits creating and reading arbitrary files on the Expedition system — a security-vendor product holding the estate's privileged material. The citing gap PCI-DSS-4.0-6.2.4 is recorded in the packet as 'Software engineering techniques or other methods are defined and used by personnel to prevent or mitigate common software attacks'.",
+        "gap_closes": [
+          "PCI-DSS-4.0-6.2.4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-9463": {
     "name": "Palo Alto Networks Expedition OS Command Injection Vulnerability",
@@ -38799,7 +40189,32 @@
         "adequate": false,
         "gap": "Authenticator-management guidance assumes operator-issued credentials that can be rotated; a compiled-in credential cannot be rotated by the operator at all."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "SolarWinds Web Help Desk ships a developer login credential compiled into the application rather than read from configuration, so the authenticator an attacker needs comes out of the product itself and is identical on every install — the packet records it being recovered by decompilation. That is precisely why the identity controls cited against this entry cannot reduce the exposure: the account does not exist in the operator's account store, so account-management review, authenticator-strength policy and identity-assurance requirements never examine it, and no password rotation, MFA rollout or joiner-mover-leaver process an operator runs touches it. Gate the instance on the absence of that shipped authenticator instead: after applying the vendor update, attempt authentication to the WHD instance with the built-in credential and require refusal before the instance returns to service; then re-run the same check after any restore-from-image, template clone or appliance rebuild, since those are the operations that quietly reinstate a pre-update build on a host that had already been remediated. Preconditions: the check proves only that this one shipped credential is closed, on the instance you actually tested — it says nothing about other secrets embedded in the same build, and it cannot be run against an instance whose version you cannot establish. And because exploitation is confirmed and the credential grants read and write over help-desk ticket data, an instance that was reachable before the update also needs its ticket contents treated as disclosed — the packet notes tickets carrying reset passwords — rather than closed on the update alone.",
+        "evidence": "Packet: cwe_refs CWE-798; attack_vector states WHD 'ships with a developer login credential hardcoded directly into application code rather than pulled from configuration; any remote attacker who knows the credential (recovered via decompilation, as Horizon3.ai did) can authenticate and read or modify all help-desk ticket data, including tickets carrying reset passwords.' vector: 'allowing remote unauthenticated user to access internal functionality and modify data.' cvss 9.1, poc_available true, active_exploitation confirmed, kev_date 2024-10-15, patch_available true; live_patch_notes is null, so the packet records no live-patch path and no reboot detail.",
+        "gap_closes": [
+          "NIST-800-53-AC-2",
+          "NIST-800-53-IA-2",
+          "NIST-800-63B-rev4",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Exposure on this entry is not gated on any target-specific work. The credential is a constant inside the shipped binary, so once it is recovered from any one copy — the packet records exactly that, by decompilation — every unpatched, reachable Web Help Desk instance is authenticable by anyone holding it: no brute force, no user interaction, no phishing step. The attacker also arrives as a valid built-in account, so the instance's authentication log records a successful login rather than a failure, and volumetric or lockout-based signals have nothing to fire on. A vulnerability-management cadence that schedules a 9.1 application flaw into the next maintenance window is therefore counting a window whose only precondition is reachability. The requirement for this CVE: the vendor update deployed within 4 hours of the 2024-10-15 KEV listing, or the WHD web surface withdrawn from any network the operator cannot vouch for until it is — with that withdrawal recorded as an active compensating mitigation carrying an end date, not as SLA compliance. Precondition on the interim step: restricting reachability bounds who can present the credential, it does not invalidate the credential, so anyone who still legitimately reaches the instance retains the path until the update is applied.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-10-15, active_exploitation confirmed, poc_available true, cvss 9.1, rwep_score 70, patch_available true. attack_vector records the credential as hardcoded in application code and recovered via decompilation (Horizon3.ai), and the vector records access by a 'remote unauthenticated user to access internal functionality and modify data.' live_patch_notes is null.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-ISM-1546"
+        ]
+      }
+    ]
   },
   "CVE-2024-9380": {
     "name": "Ivanti Cloud Services Appliance (CSA) OS Command Injection Vulnerability",
@@ -38883,7 +40298,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",
@@ -40376,7 +41814,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",
@@ -41146,7 +42618,31 @@
         "adequate": false,
         "gap": "Malicious-code protection leans on SmartScreen/Protected View reputation checks that this bypass specifically defeats, so SI-3 controls that assume MotW is enforced are silently undermined."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "This CVE is the protection mechanism itself failing rather than a flaw in what it protects: the packet's path stages a payload on a WebDAV share and lures the user into copy-pasting it locally, and because the copied file lacks Mark-of-the-Web, opening it skips SmartScreen and Protected View and runs with no reputation check. Nothing about the file's content differs — only its origin metadata. For a Windows estate the control means the MOTW/SmartScreen class gets a standing regression battery re-run on every Windows update rather than a one-off check closed with this CVE's ticket: stage a benign marker file on a WebDAV share, bring it to a managed workstation by exactly the copy-paste path the packet describes, and confirm the resulting local file carries the zone marking and that opening it triggers the reputation check. The EDR half of the battery matters as much, because the packet's behaviour is quiet: a rule keyed on a suppressed SmartScreen prompt, a blocked-execution event, or a known tool signature will never fire here — there is no prompt to suppress and no unusual tooling, just an ordinary copy and an ordinary open. The signal that matches what the packet documents is the pairing of an outbound WebDAV mount to a host outside the estate with subsequent execution of a file copied from that mount carrying no zone marking; a battery that does not replay that pairing is validating a synthetic stand-in rather than the real bypass. Precondition: this is a verification control, not a fix — it tells you whether the mechanism holds on the build a host is currently running. The packet gives the vendor update as the remediation with a required reboot, so a host that installed the update but has not restarted must still be tested and counted as exposed.",
+        "evidence": "Packet vector: 'Windows Mark of the Web Security Feature Bypass Vulnerability' (CWE-693, Protection Mechanism Failure). Attack path per the packet: an attacker stages a payload on a WebDAV share and lures the user to copy-paste it locally; the copied file lacks Mark-of-the-Web, so opening it skips SmartScreen and Protected View, executing without reputation checks. CISA KEV-listed 2024-08-13, active_exploitation confirmed, poc_available false, RWEP 57 / CVSS 6.5. 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.'",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "NIST-800-53-SI-4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "On a Windows build that has not yet taken the fix, the endpoint will not attach the untrusted-origin marking on this path at all — that omission is the vulnerability — so 'require Mark-of-the-Web' cannot be enforced from inside the endpoint and the enforceable expression of the control moves to the ingress path. The packet's staging path is a WebDAV share the user browses to and copies from, so restrict outbound WebDAV from managed workstations to hosts inside the estate, and route externally-sourced files through the mail-gateway and download paths that do apply and preserve the marking, so the SmartScreen and Protected View decision rests on provenance established at the boundary rather than on metadata the copy silently dropped. Precondition, and it is the load-bearing half: this removes the one staging path the packet documents. It does not cover a file reaching the workstation by another route that also loses the marking, it does not help where the estate legitimately mounts an external share, and it does nothing on a workstation where the copy and the open have already happened — active_exploitation is confirmed, so a host that copied and ran a file from an external WebDAV mount during the exposure window belongs on the incident path rather than on a configuration-change list. The vendor update, with the reboot the packet says it needs, remains the remediation; this is the measure that bounds exposure until the reboot lands. Distinguishing test: from a managed workstation, attempt to mount an external WebDAV share and copy a file from it — if the mount succeeds, the documented delivery path is open no matter what a user-application-hardening attestation says about macro and reputation settings, because those settings are never consulted for a file that arrives unmarked.",
+        "evidence": "Packet attack path: an attacker stages a payload on a WebDAV share and lures the user to copy-paste it locally; the copied file lacks Mark-of-the-Web, so opening it skips SmartScreen and Protected View, executing without reputation checks. Vector: 'Windows Mark of the Web Security Feature Bypass Vulnerability' (CWE-693). 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.' CISA KEV-listed 2024-08-13, active_exploitation confirmed, RWEP 57 / CVSS 6.5. Citing gaps include AU Essential Eight user application hardening and ISO/IEC 27001:2022 A.8.7 (Protection against malware).",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.7"
+        ]
+      }
+    ]
   },
   "CVE-2024-38178": {
     "name": "Microsoft Windows Scripting Engine Memory Corruption Vulnerability",
@@ -41183,7 +42679,31 @@
         "adequate": false,
         "gap": "App-hardening maturity leaves Edge IE mode / legacy WebView enabled by default, keeping the JScript9 engine reachable even on patched systems."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The exploited path needs the victim to be in Edge's Internet Explorer mode, where the JScript9 JIT performs the incorrect type optimization the packet describes; the fix is a Windows update and the packet records that no live-patching primitive exists and that the update requires a reboot to be the remediation. So for this CVE the KEV clock that opened 2024-08-13 runs to completed restart, not to 'update approved' or 'update installed' — a workstation that took the update and has not restarted still loads the vulnerable engine the next time a site opens in IE mode, and must be counted as exposed rather than done. The documented-compensating-control branch this control permits is the only lever for the interval before those restarts land, and for this CVE it is specific: cut the routes into IE mode by pruning the enterprise site list to sites with a current business need and disabling user-initiated reload-in-IE-mode, so attacker-controlled JavaScript arriving through a compromised ad service is rendered by the modern engine instead of JScript9. Precondition: that measure holds only where no legacy application genuinely requires IE mode — for the users who do require it, IE mode stays reachable and they remain exposed until the restart, so they are the population to sequence first rather than the population the site-list change covers. It also evicts nothing: the packet's exploitation outcome is RokRAT deployment, which survives both the site-list change and the update, so a host that browsed in IE mode during the exposure window belongs on the incident path, not on the patch dashboard.",
+        "evidence": "Packet: Microsoft Windows Scripting Engine Memory Corruption Vulnerability, CWE-843, CISA KEV-listed 2024-08-13, active_exploitation confirmed, CVSS 7.5, RWEP 59. attack_vector: 'A victim using Edge in Internet Explorer mode loads attacker-controlled JavaScript (delivered via a compromised ad service); the JScript9 JIT performs an incorrect type optimization, producing a type confusion that leads to remote code execution and RokRAT deployment.' patch_available is true, live_patch_available is false, and the packet's live-patch note reads 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' poc_available is false, so exploitation is confirmed with no public exploit from which signature coverage could be derived. The cited AU-Essential-8-App-Hardening gap is recorded as 'User application hardening'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry produces exactly the middle state the control exists to name, and on an endpoint fleet it is the state most hosts occupy for the longest. Constraining IE mode — pruning the enterprise site list, disabling user-initiated reload-in-IE-mode — is a configuration mitigation with the vulnerable JScript9 code still present and still reachable through any site the list continues to admit; and because the packet's update requires a reboot, a host that has installed but not restarted is likewise mitigated-at-best rather than fixed. Both states have to appear in the compliance record as time-bound compensating states rather than as remediation. For this CVE that means the fleet report separates three populations: hosts on the fixed build and restarted, hosts updated and awaiting restart, and hosts still on the pre-fix build with IE mode constrained — the last two carrying dated action items. Distinguishing test: take a host the report marks compliant, confirm it has actually restarted since the update landed, then open a site the enterprise site list still routes to IE mode and confirm which engine renders it. A report that cannot separate the three states will show a fleet at full compliance while an ordinary reboot deferral leaves the type-confusion path live behind an ad service the operator does not control.",
+        "evidence": "Packet: Microsoft Windows Scripting Engine Memory Corruption Vulnerability, CWE-843, CISA KEV-listed 2024-08-13, active_exploitation confirmed, CVSS 7.5, RWEP 59, poc_available false. patch_available is true with live_patch_available false and the note 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation' — establishing an installed-but-not-restarted state distinct from remediated. The attack_vector places the vulnerable code in the JScript9 JIT reached through Edge in Internet Explorer mode, which is a configuration-reachable surface, so restricting that reachability is a mitigation with the flawed code still resident. The gaps cited against this entry — ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities), EU NIS2 Art. 21 vulnerability handling, and NIST SP 800-53 SI-2 (Flaw Remediation) — are the process controls whose verdicts collapse these states into one.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-38189": {
     "name": "Microsoft Project Remote Code Execution Vulnerability",
@@ -42444,7 +43964,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",
@@ -42629,7 +44163,34 @@
         "adequate": false,
         "gap": "Access enforcement fails at the endpoint: /getcfg.php returns sensitive account data without authenticating or authorizing the requester."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet records no fix for this router — the affected DIR-605 hardware revisions are end-of-life/end-of-service and the recorded guidance is to retire and replace — so for this CVE remediation means taking the unit out of service, and every other measure is a holding action that needs a date on it. Applied to this device: each surviving DIR-605 goes onto a dated replacement schedule rather than an open-ended risk acceptance, and until it is pulled its HTTP surface must not be reachable from any position an untrusted party can occupy, because the whole exploit is one unauthenticated POST to /getcfg.php that returns the administrator user name and password in cleartext. Reachability is the entire precondition, and that is also where this control's limit sits: a DIR-605 acting as the gateway for the clients behind it cannot be segmented away from those clients, so a unit in that role is remediated only by replacement — an ACL is not available to it, and recording one is recording a control that does not exist on that path. Because exploitation is confirmed and a public exploit exists, treat the administrator credential the device hands out as already known: any password reused from that router on another system is rotated as part of the decommission rather than after it. The distinguishing test: from every segment that can route to the device, send an unauthenticated POST to /getcfg.php and see whether credentials come back — a vulnerability record that reads 'no patch available, risk accepted' with no removal date leaves a KEV-listed no-fix router in service indefinitely.",
+        "evidence": "Packet records patch_available: false and live_patch_available: false, with live_patch_notes 'No fix available — affected DIR-605 hardware revisions are end-of-life/end-of-service; CISA guidance is to retire and replace.' Attack path per the packet: an unauthenticated attacker forges a POST request to /getcfg.php requesting the device account service; the router returns the administrator credentials in cleartext, which are then reused to take over the device. Weakness CWE-863; product D-LINK-DIR-605 B2 Firmware Version 2.01MT. CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available true, RWEP 79 / CVSS 7.5.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-AC-3",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "A vulnerability-management program keyed on whether a fix is installed has no state to record for this entry, because the packet says no fix exists and the affected DIR-605 revisions are end-of-life/end-of-service. The requirement this CVE demonstrates is that network-attached embedded devices carry an end-of-support date in the asset inventory, so a DIR-605 resolves to a replace-or-formally-decide finding with an owner rather than reappearing every cycle as an unresolvable scanner result. Precondition, and it is the half that decides whether this works: consumer-grade D-Link extender and router hardware of this class normally sits at branch and remote-worker sites that were never enrolled in managed inventory, so an inventory query alone will return nothing and read as clean. Discovery has to be an active sweep for the device's HTTP management surface across every segment the estate reaches, including remote-worker links, repeated after site changes — and the removal decision applies to the DIR-605 units that sweep surfaces, not to embedded devices the packet does not implicate. The distinguishing test: ask the inventory which network-attached devices have an end-of-support date recorded at all; if the field does not exist, the program cannot distinguish 'fix not yet applied' from 'no fix will ever exist', which is the exact state this KEV-listed, actively-exploited router is in.",
+        "evidence": "Packet records patch_available: false with live_patch_notes 'No fix available — affected DIR-605 hardware revisions are end-of-life/end-of-service; CISA guidance is to retire and replace.' The exposed surface is the device's HTTP interface: an unauthenticated forged POST to /getcfg.php returns the administrator user name and password (CWE-863, D-LINK-DIR-605 B2 Firmware Version 2.01MT). CISA KEV-listed 2024-05-16, active_exploitation confirmed, poc_available true, RWEP 79 / CVSS 7.5. Citing gaps include AU-Essential-8-Patch (Patch operating systems) and ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities), both of which assume a vendor fix exists.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2014-100005": {
     "name": "D-Link DIR-600 Router Cross-Site Request Forgery (CSRF) Vulnerability",
@@ -42851,7 +44412,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",
@@ -43847,7 +45431,32 @@
         "adequate": false,
         "gap": "Essential-Eight patching targets do not specifically drive perimeter-appliance firmware updates, leaving a years-old ASA/FTD fix unapplied on exposed devices."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The affected asset is a Cisco ASA / FTD unit terminating AnyConnect and WebVPN — a VPN concentrator sitting on the trust boundary — and the packet's primitive is reached with no credential: a crafted GET request carrying an invalid URL to the web services interface returns device memory contents through a buffer-tracking flaw. The isolation alternative this tier normally offers is largely unavailable here, and that is the precondition to state rather than skip: the web services interface carrying AnyConnect and WebVPN is reachable by remote users by design, so \"restrict the vulnerable interface\" means withdrawing remote access, not hardening it, and it is an option only for units whose remote-access population is small enough to source-restrict. What is left is the clock. The packet records a vendor fix and states there is no vendor live-patch mechanism — remediation requires applying the fixed release and rebooting — so the tier's requirement is that the fixed release and the reload are driven from the 2024-02-15 KEV listing rather than folded into the next maintenance window, and a unit that has taken the image but not reloaded is still running the vulnerable parser and counts as exposed, not as remediated. The packet also scopes the population for the operator: only specific AnyConnect and WebVPN configurations are affected, so the enumeration step is which units run those configurations — an asset inventory that lists ASA/FTD units without that configuration detail cannot say which are in scope. Distinguishing test: for each unit in the affected configuration set, compare the running image against the fixed release and confirm the reload has occurred; an \"update deployed\" entry in the management console is not evidence that the running device stopped serving the vulnerable web services parser.",
+        "evidence": "Packet: a vulnerability in the web services interface of Cisco ASA and FTD Software allows an unauthenticated, remote attacker to retrieve memory contents; the flaw is a buffer-tracking issue when the software parses invalid URLs requested from the web services interface, exploited by sending a crafted GET request. The packet states the vulnerability affects only specific AnyConnect and WebVPN configurations. CWE-200; CISA KEV-listed 2024-02-15; active_exploitation confirmed; CVSS 7.5; RWEP 60; poc_available false. 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",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's outcome is a read primitive, not code execution: an unauthenticated crafted GET request returns ASA/FTD memory contents, which the packet says can include cleartext VPN credentials later used for ransomware entry. That makes one half of this control load-bearing here and the other inapplicable, and saying which is which matters. The packet documents no implant and no write to the device, so a rebuild is not what this CVE demands; credential rotation is — and it is exactly the step the fixed release does not perform. Applied to these units: every credential that could have been resident in the memory of an affected AnyConnect/WebVPN unit during the exposure window is treated as disclosed and rotated — remote-access VPN user credentials, the upstream directory or RADIUS accounts those users authenticate against, administrator credentials used on the device, and any shared secret the device holds — and the remote-access session and account history is reviewed for logins that used credentials valid before the rotation. Precondition: rotation reaches only credentials the operator can enumerate and change. A credential held by a third party, or embedded in a partner or appliance configuration outside the operator's control, keeps working after the fixed release lands, and that residual belongs in the record rather than assumed closed. The distinguishing test is not on the device: after the fixed release and reload, confirm that remote-access authentication for the affected units rejects the pre-remediation credential set — an identity-and-access attestation showing every VPN user authenticating correctly passes cleanly while an attacker holds a credential that also authenticates correctly.",
+        "evidence": "Packet: \"An unauthenticated attacker sends a crafted GET request with an invalid URL to the ASA/FTD web services interface; a buffer-tracking flaw returns device memory contents, which can include cleartext VPN credentials later used for ransomware entry.\" active_exploitation confirmed; CISA KEV-listed 2024-02-15. patch_available true; live_patch_available false; live_patch_notes: \"No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.\" The packet describes retrieval of memory contents only — no code execution, implant, or device write.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-21410": {
     "name": "Microsoft Exchange Server Privilege Escalation Vulnerability (CVE-2024-21410)",
@@ -46108,7 +47717,32 @@
         "adequate": false,
         "gap": "Advisory-driven vulnerability management cannot prioritize an unknown zero-day used to leak memory and defeat mitigations like ASLR."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this CVE the control means the iOS, iPadOS, macOS and Safari update carrying the fix is driven across the whole Apple estate on the KEV clock that opened 2023-12-04 with user deferral disabled, and completion measured by each device's running build after the restart the packet says the fix requires — a device that has downloaded the update but not restarted is still executing the vulnerable WebKit and is counted as exposed, not as remediated. The reason this entry needs the compressed tier rather than the estate's ordinary update ring is that its own numbers argue for deferring it: CVSS 6.5 and 'processing web content may disclose sensitive information' read as a medium-severity information leak, while the packet's actual exploitation path is a memory disclosure used to defeat ASLR and stabilise a companion code-execution exploit. The value of the bug to an attacker sits in the chain, not in this CVE's impact score, and the packet records a report of exploitation against versions before iOS 16.7.1. Precondition: management-enforced updates reach only enrolled devices — personally-owned and unenrolled devices that touch organizational data sit outside this control entirely and are covered, if at all, by the access-condition control paired with it here. Enforcement is also forward-looking only: the update does not make clean a device that ran a vulnerable build through the exposure window, and because exploitation is confirmed for this CVE a device with reason to suspect it belongs on the incident path rather than the compliance report.",
+        "evidence": "Packet gives patch_available true, live_patch_available false, with live_patch_notes 'No live patch; requires the iOS/iPadOS/macOS/Safari update (17.1.2 / 14.1.2, backported to 16.7.2) and a device restart.' Vector: 'An out-of-bounds read was addressed with improved input validation. This issue is fixed in iOS 17.1.2 and iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2. Processing web content may disclose sensitive information. Apple is aware of a report that this issue may have been exploited against versions of iOS before iOS 16.7.1.' Attack path: crafted web content triggers an out-of-bounds read in WebKit (CWE-125) that leaks process memory, typically used to defeat ASLR and stabilize a companion code-execution exploit. CISA KEV-listed 2023-12-04, active_exploitation confirmed, RWEP 57 / CVSS 6.5, poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The fixed build has to act as an access condition on this flaw, not as a row on a patch-compliance dashboard: an iPhone, iPad or Mac below 17.1.2 / 14.1.2 — or below the 16.7.2 backport on the older track — is refused organizational mail, VPN and document access until it is at or above the fix and has taken the restart the packet says the update needs. The delivery path is why the access-condition half is the load-bearing one here: the trigger is crafted web content processed by WebKit, which is the engine behind every browser and in-app web view on the device, so there is no setting the operator can apply that keeps the vulnerable parser away from attacker-controlled content while the device stays in service on an old build. Withholding the data is the only remaining lever for a device that has not yet updated and restarted. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it mail, VPN and document access — an estate that shows the stale build on a report while the device keeps working has recorded the exposure rather than removed it. Precondition: the gate binds only where the resource consults device state at access time, so a service reachable from a browser session or an app that does not check device compliance stays reachable from a device below the fixed build. And it is a containment measure, not a cleanup one — it does not evict an attacker already resident on a device exploited before the update, which matters because the packet records confirmed exploitation and a report of use against versions before iOS 16.7.1.",
+        "evidence": "Packet live_patch_notes: 'No live patch; requires the iOS/iPadOS/macOS/Safari update (17.1.2 / 14.1.2, backported to 16.7.2) and a device restart.' Vector states the issue is fixed in iOS 17.1.2 and iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2, that processing web content may disclose sensitive information, and that Apple is aware of a report that the issue may have been exploited against versions of iOS before iOS 16.7.1. Attack path: crafted web content triggers an out-of-bounds read in WebKit (CWE-125) leaking process memory. CISA KEV-listed 2023-12-04, active_exploitation confirmed, RWEP 57 / CVSS 6.5.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-6345": {
     "name": "Google Skia Integer Overflow Vulnerability",
@@ -46246,7 +47880,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)",
@@ -47176,7 +48844,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",
@@ -49230,7 +50922,41 @@
         "adequate": false,
         "gap": "Response and recovery planning is not scoped for targeted commercial-spyware zero-click intrusions that leave little evidence and demand vendor-assisted forensics."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The packet's fix is a whole OS build, and it lands on five separate release trains at once: iOS/iPadOS 16.6.1, iOS/iPadOS 15.7.9, macOS Ventura 13.5.2, macOS Monterey 12.6.9 and macOS Big Sur 11.7.10. For this CVE the control means the update is driven across the Apple estate from the management plane on the KEV clock that opened 2023-09-11, with user deferral disallowed, and that completion is measured per device as the build it actually reports against the fixed build for its own train — a device held on the 15.x train is remediated at 15.7.9, and an estate that measures 'latest major OS installed' will read that whole population as stale or unknown rather than as fixed. Preconditions: the packet records no vendor live-patch mechanism, so remediation requires applying the fixed release and rebooting — a device that has downloaded the update but not restarted still runs the vulnerable ImageIO and must be counted as exposed, not as patched. And management-plane enforcement reaches only enrolled devices; an unenrolled personal device belonging to someone in the targeted population is not covered by this control at all, which is why the standing posture below is assigned per user rather than per enrollment.",
+        "evidence": "Packet fields: patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The vector names the fixed releases (iOS 16.6.1 and iPadOS 16.6.1, macOS Monterey 12.6.9, macOS Ventura 13.5.2, iOS 15.7.9 and iPadOS 15.7.9, macOS Big Sur 11.7.10). cisa_kev true with kev_date 2023-09-11; active_exploitation confirmed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "Delivery for this CVE is a crafted image arriving as a PassKit attachment over iMessage and parsed by ImageIO with no user interaction — there is no click to withhold and no user decision to train, so awareness controls and attachment-handling guidance have nothing to act on. Between the 2023-09-11 KEV listing and the completed restart of every device, the only remaining lever is narrowing what the device parses automatically: place the plausibly targeted cohort — executives, journalists, legal and security staff — into Apple's reduced-attack-surface mode for at-risk users so message attachments and untrusted web content are not processed on arrival. This has to be a standing assignment made before the next disclosure, because the mode only helps if it was already on when the message landed. Preconditions, stated plainly: it narrows the delivery path, it does not repair the ImageIO overflow and does not remove the surface outright — any other route that reaches the same parser is unaffected; and it does nothing for a device on which the chain has already run, which belongs on the incident path rather than the hardening path. It is a holding measure for the window before the fixed build and its reboot land, not a substitute for them.",
+        "evidence": "Packet attack_vector: 'A maliciously crafted image sent as a PassKit attachment over iMessage is processed by ImageIO with no user interaction, overflowing a buffer and executing code; combined with CVE-2023-41061 (BLASTPASS) to install Pegasus.' active_exploitation confirmed; kev_date 2023-09-11; live_patch_available false with remediation recorded as the fixed release plus a reboot.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet records a confirmed chain — this overflow combined with CVE-2023-41061 (BLASTPASS) — whose end state is a Pegasus implant delivered with no user interaction. Commodity-malware IR under-escalates that outcome by treating a phone as clean once it takes an update, and the packet's own remediation shows why that is wrong: the fix is applying the fixed release and rebooting, and a build upgrade evicts nothing that executed before it. For this CVE the escalation path triggers on the chain and implant outcome, not on an actor attribution — the packet names no threat group — so the operational rule is that any device in the plausibly targeted population that was below the fixed build during the exposure window is handled as a suspected targeted-implant case: preserved for forensic examination, and the accounts, tokens and mail/VPN sessions reachable from it rotated, before the vulnerability ticket is closed. This is also the substitute for the system-monitoring gap cited on this entry: the affected Apple platforms give the estate no endpoint telemetry that would emit on a zero-click ImageIO parse, so the trigger has to be build-state during the window plus forensic examination rather than a detection rule keyed on process or crash behaviour, which for this delivery path would fire on nothing. Precondition: it covers only the devices whose build history during the window you can establish; a device with no such history cannot be cleared by this path and stays in scope until evidence says otherwise.",
+        "evidence": "Packet: active_exploitation confirmed, cisa_kev true, kev_date 2023-09-11; attack_vector records the combination with CVE-2023-41061 (BLASTPASS) to install Pegasus, processed with no user interaction. live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' poc_available false. The packet names no threat-actor group, so the trigger asserted here is the confirmed chain and its implant outcome, not an attribution.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-D1",
+          "NIST-800-53-SI-4"
+        ]
+      }
+    ]
   },
   "CVE-2023-41061": {
     "name": "Apple iOS, iPadOS, and watchOS Wallet Code Execution Vulnerability",
@@ -51473,7 +53199,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",
@@ -51866,7 +53615,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management depends on a published fix to prioritize; for a kernel integer overflow used as an in-the-wild zero-day the control had nothing to act on until Apple's 2023-06-21 releases, so the exposure preceded any compliant handling cycle."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "On the Apple estate this CVE affects, the fix ships only as an OS build and the build differs per platform and per generation — the packet names iOS/iPadOS 16.5.1 and 15.7.7, macOS Ventura 13.4.1, macOS Monterey 12.6.7, macOS Big Sur 11.7.8, and watchOS 9.5.2 and 8.8.1. The enforcement object therefore has to be a per-SKU target build, not a generic 'latest update installed' policy, because a device sitting on the newest build for its generation can still be below the listed fix for a different generation in the same fleet. The packet records no live-patch mechanism and states the update requires a device restart, so the SLA's completion criterion is the restart having been taken, not 'update pushed', 'update downloaded' or 'update approved' in the management console. Precondition: this control's enforcement channel covers enrolled iOS, iPadOS and macOS devices, while the packet's fix list also carries watchOS 9.5.2 and 8.8.1 — those devices fall outside that enforcement scope and have to be tracked and driven to the listed build explicitly, or the estate will report full compliance while a build named in the fix list stays behind. Distinguishing test: after the enforcement window closes, read the actually-installed build from enrolled devices at each OS generation in the packet's fix list; any device below its generation's listed build, or above it but not yet restarted, is the finding.",
+        "evidence": "Packet: CISA KEV listed 2023-06-23, active_exploitation confirmed, CVSS 7.8, RWEP 51, patch_available true, live_patch_available false. live_patch_notes: 'No live-patch mechanism for the affected kernel; remediation requires the Apple OS update (iOS/iPadOS 16.5.1 or 15.7.7, macOS Ventura 13.4.1, macOS Monterey 12.6.7, macOS Big Sur 11.7.8, watchOS 9.5.2/8.8.1), which requires a device restart.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's trigger is an application on the device reaching arbitrary code execution with kernel privileges, so once that application runs, no account-level boundary on the device contains it — the defect executes below every boundary the endpoint estate is audited on. For this entry the control means the per-generation fixed build named in the packet functions as an access condition: a device below its generation's listed build is denied mail, VPN and document access, rather than appearing as a stale row on a patch-compliance report while keeping its access. Because the packet records a required device restart and no live-patch path, the bar is the restarted state — a device that has installed the update but not restarted is still running the vulnerable kernel and must be counted below the bar, not as remediated. Distinguishing test: hold an enrolled device at a build below its generation's listed fix and confirm the policy actually refuses it access to protected resources; an estate that surfaces the stale build on a dashboard while the device keeps its access has recorded the exposure rather than removed it. Precondition: restricting which applications may be installed raises the bar for getting the attacker's application onto the device, but it does not evict an application already installed, and the packet places this CVE inside a zero-click chain, so an install-policy is not the containment for a device suspected of having already run the chain — that device belongs on the incident path, not the install-policy path.",
+        "evidence": "Packet vector: 'An app may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.7.' CWE-190; active_exploitation confirmed. live_patch_available false; live_patch_notes names the per-generation fixed builds and states the update 'requires a device restart'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this CVE as the kernel-execution stage of the Operation Triangulation zero-click chain, and Apple's own note in the packet is that the issue may have been actively exploited against versions of iOS released before iOS 15.7 — a delivery path that requires no user action, so no amount of user-awareness training or click-discipline is in the loop. For the high-risk cohort this control governs, the reboot-gated OS update is not fast enough on its own: place those devices in a reduced-attack-surface mode so message attachments, web content, fonts and link previews are not processed automatically, narrowing the delivery path for the chain stage that precedes this one during the window between the 2023-06-23 KEV listing and the completed fleet restart. Precondition, and this is the load-bearing sentence: the posture narrows delivery of the chain, it does not touch the integer overflow itself. The packet's trigger is an application already executing on the device, so once the chain has landed the mode changes nothing, it does not evict anything already resident, and a device suspected of having run the chain goes to the incident path rather than being closed on a posture change. It also only helps if it was already enabled when the chain arrived. Distinguishing test: confirm the posture is assigned as a standing profile to the named cohort ahead of the next disclosure — a mode switched on in reaction to a KEV listing was, by construction, off during the in-the-wild exploitation the packet records.",
+        "evidence": "Packet attack_vector: 'An application triggers an integer overflow in the Apple kernel to execute arbitrary code with kernel privileges; in the wild it was the kernel-execution stage of the Operation Triangulation zero-click chain.' Packet vector: 'Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.7.' CISA KEV 2023-06-23, active_exploitation confirmed; live_patch_notes records that remediation 'requires a device restart'.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-32435": {
     "name": "Apple Multiple Products WebKit Memory Corruption Vulnerability (CVE-2023-32435)",
@@ -52659,7 +54440,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)",