@blamejs/exceptd-skills 0.19.7 → 0.19.9

package/data/zeroday-lessons.json

@@ -452,7 +452,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-008",
+        "id": "NEW-CTRL-139",
         "name": "CI-WORKFLOW-TRUST-BOUNDARY-ISOLATION",
         "description": "Forbid pull_request_target co-residency with id-token:write workflows in the same repository. If co-residency is required, isolate actions/cache namespaces per trigger class.",
         "evidence": "CVE-2026-45321 — chained primitives required exactly this co-residency to succeed",
@@ -462,7 +462,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-009",
+        "id": "NEW-CTRL-140",
         "name": "REGISTRY-COOLDOWN-POLICY",
         "description": "Consumer-side registry cooldown (.npmrc before=72h or minimumReleaseAge=4320 minutes) refuses to install any version published within the last 72 hours.",
         "evidence": "CVE-2026-45321 — caught publicly within 20 minutes; 72h is overkill-safe",
@@ -1912,7 +1912,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-048",
+        "id": "NEW-CTRL-141",
         "name": "KERNEL-EXIT-RACE-CVE-CLASS-MONITORING",
         "description": "When a CVE is disclosed in the kernel ptrace / pidfd / fd-table lifecycle class, audit rules SHOULD enable pidfd_getfd / pidfd_open / pidfd_send_signal tracking for auid>=1000 within 24h. The syscall is rare in normal operation; spike volume after a same-class disclosure is high-confidence exploitation signal.",
         "evidence": "CVE-2026-46333: the 100-2000-attempt exploit loop is loud in audit but most default rule sets do not monitor pidfd_getfd.",
@@ -1922,7 +1922,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-049",
+        "id": "NEW-CTRL-142",
         "name": "SUID-MINIMIZATION-FOR-KERNEL-LPE-CARRIER-BINARIES",
         "description": "Hosts that do not use SSH host-based authentication SHOULD have ssh-keysign de-suid-ed. Hosts that do not use age-warn login UX SHOULD have chage de-suid-ed. Removes the privileged-process carrier even before the kernel patch lands.",
         "evidence": "CVE-2026-46333: ssh-keysign + chage are the canonical carriers; SUID-removal blocks the exploit at the carrier layer regardless of kernel patch state.",
@@ -7893,7 +7893,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": "PaperCut NG/MF is bought and audited as back-office print-management software, so it sits in the slow lane of most patch programs — but this packet makes it an authentication enforcement point that is failing open under confirmed exploitation, which is why the KEV clock and not the application-patch cadence has to govern it. Meeting the SLA on this product means the PaperCut application service is actually restarted onto the fixed build on every instance: the packet records a vendor patch but no live-patch path, and its live_patch_notes state the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a staged package on a still-running instance has not moved the exposure at all. Until that restart lands on a given server, the bypass reachable through the SecurityRequestFilter class is still available to an unauthenticated caller, so the interim action the SLA has to record is constraining who can reach that instance's admin surface — not a scheduled maintenance window with the server left reachable in the meantime.",
+        "evidence": "Packet records cisa_kev true with kev_date 2026-04-20 and active_exploitation confirmed, RWEP 83 / CVSS 9.1, poc_available true. patch_available is true, live_patch_available is false, and live_patch_notes read: '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 citing framework gaps record AU-Essential-8-Patch (Patch operating systems), ISO-27001-2022-A.8.8 (Management of technical vulnerabilities), NIST-800-53-SI-2 (Flaw Remediation) and NIS2-Art21-vulnerability-handling as insufficient for this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "PaperCut's request-filter layer is where the product makes its authentication decision, and this CVE is that layer failing open: the packet places the bypass in the SecurityRequestFilter class and has a remote unauthenticated attacker reaching administrative functionality behind it. Bound to this product, the control means each administrative function on the PaperCut server authorizes its caller itself rather than inheriting a verdict from the filter that fronts it, and the admin surface is segmented so an untrusted network caller cannot present a request to that filter in the first place. The least-privilege control cited as insufficient here does not touch this path — the attacker never authenticates as any PaperCut operator, so per-account privilege scoping is never consulted, and the account model that an identity-and-access attestation examines is bypassed rather than abused. Distinguishing test: from a segment with no operational need for the print-administration console, issue unauthenticated requests to each administrative endpoint on a staging PaperCut instance and confirm each is refused before the function runs — an attestation that every PaperCut administrator authenticates at login passes cleanly while this path stays open.",
+        "evidence": "Packet vector: 'PaperCut NG/MF contains an improper authentication vulnerability that could allow remote attackers to bypass authentication on affected installations via the SecurityRequestFilter class.' cwe_refs is CWE-287; attack_vector states the flaw lets an unauthenticated attacker bypass authentication and reach administrative functionality, KEV-listed 2026-04-20 with confirmed in-the-wild exploitation and poc_available true. UK-CAF-B2 (Identity and access control) and NIST-800-53-AC-6 (Least Privilege) are both recorded among the citing gaps.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2025-48700": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Cross-site Scripting Vulnerability",
@@ -8976,7 +9000,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-MDM-GATEWAY-UNAUTH-CONFIG-ENDPOINT-NEUTRALIZE-AND-CONTAIN",
+        "id": "NEW-CTRL-134",
         "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
         "description": "Ivanti EPMM is the device-management gateway itself, and this flaw reaches remote code execution on its management surface with no credentials at all - the injected code is interpreted before any authentication decision is made. Every EPMM message and configuration endpoint has to authenticate the caller before processing, neutralize injected code ahead of any interpreter or command sink, and no EPMM instance may be left with those endpoints reachable from an untrusted network. Distinguishing test: from an unauthenticated client on a staging EPMM, send each endpoint a payload that attempts code execution and confirm refusal before any interpreter runs. Because exploitation is confirmed, an instance whose endpoints were exposed before remediation also needs forensic triage rather than a patch-and-close.",
         "evidence": "Packet: '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'; cvss 9.8; poc_available true; cisa_kev true, kev_date 2026-04-08, active_exploitation confirmed.",
@@ -9163,7 +9187,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-SUPPLYCHAIN-SIGNED-INSTALLER-INTEGRITY",
+        "id": "NEW-CTRL-132",
         "name": "INDEPENDENT-INTEGRITY-VERIFICATION-OF-SIGNED-VENDOR-INSTALLERS",
         "description": "TrueConf Client fetches update code without verifying its integrity, so nothing on the client side distinguishes the vendor's build from one substituted by an attacker who has gained influence over the delivery path. The operator response is to stop letting the in-app updater be the trust decision: pull TrueConf Client builds through managed software distribution, verify each build against an integrity source independent of the download itself — vendor-published per-release hashes obtained over a separate channel, or a behavioural baseline of the installed binaries — and only then push it to endpoints. This is the harder form of the control's premise: the original lesson was that a valid signature is not proof of integrity, whereas here the client performs no verification step at all, so an out-of-band check is the only thing standing between a tampered payload and execution in the updating process's context.",
         "evidence": "The packet records a \"download of code without integrity check vulnerability\" (CWE-494) in which \"An attacker who is able to influence the update delivery path can substitute a tampered update payload. If the payload is executed or installed by the updater, this may result in arbitrary code execution in the context of the updating process or user,\" and identifies the delivery-path influence as \"a hijacked update endpoint or machine-in-the-middle.\" CISA KEV-listed 2026-04-02 with active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 77.",
@@ -9514,7 +9538,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-SUPPLYCHAIN-SIGNED-INSTALLER-INTEGRITY",
+        "id": "NEW-CTRL-132",
         "name": "INDEPENDENT-INTEGRITY-VERIFICATION-OF-SIGNED-VENDOR-INSTALLERS",
         "description": "The defect here is not a coding mistake in Trivy that a newer release fixes by accident — per the packet the malicious code was embedded in what shipped as a Trivy distribution/component. Every downstream check that derives its verdict from the distribution channel itself (publisher signature, registry provenance, an \"official\" designation) returns valid on that artifact, so a pipeline that gates promotion on signature validity promotes the payload. The control means the Trivy release a pipeline is about to adopt must be verified against an integrity source independent of the channel that delivered it: per-release hashes obtained through a separate channel, a reproducible-build attestation, or a behavioural baseline of the scanner binary — a scan step that begins reading credential paths and opening outbound connections beyond its vulnerability-database fetch is an integrity diff, not scanner noise. Gate promotion on that independent check, and treat any Trivy version bump as a supply-chain change requiring it. Remediation shape per the packet: patch_available true, live_patch_available false, with the vendor patch requiring a service restart or system reboot per the KEV requiredAction.",
         "evidence": "Packet CVE-2026-33634, cwe_refs CWE-506 (embedded malicious code) with attack_vector \"a Trivy distribution/component contained embedded malicious code (CWE-506), executing in the trusted context of the vulnerability scanner across every environment it runs in\"; cisa_kev true, kev_date 2026-03-26; active_exploitation confirmed; poc_available true; rwep_score 77; cvss 8.8; 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.\"",
@@ -12164,7 +12188,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": "A Craft CMS instance is a public web head and the flaw is unauthenticated code injection on that surface, so the mitigation clock starts at the KEV listing (2026-03-20), not at the next site-maintenance window. The packet records no live-patch path and states the vendor fix requires a service restart per the KEV requiredAction — meaning SLA compliance here depends on the web-tier restart authorization being pre-granted rather than requested through change approval after the listing. Where a restart genuinely cannot happen inside the window, the accepted outcome is a documented, time-bound compensating control (take the affected head out of rotation and keep it out) — not a deferral note against an instance still serving the vulnerable path.",
+        "evidence": "Packet fields for CVE-2025-32432: cisa_kev true; kev_date 2026-03-20; 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.'; attack_vector 'a code-injection flaw (CWE-94) enabling unauthenticated remote code execution on the web server.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "With confirmed in-the-wild exploitation of an unauthenticated CWE-94 flaw, every Craft CMS head that was internet-reachable before the update landed must be treated as already executed against, not merely as having been vulnerable. Installing the vendor release closes the injection path but leaves whatever the attacker wrote through it — files in the web root, template or plugin code, database-resident content, added administrative accounts — and leaves every credential the web process could read still valid. The runbook for this CVE must default to: export configuration and content for review, rebuild the web head from a known-good image on the fixed release rather than upgrading the live instance, restore content through inspection instead of restoring the running filesystem, and rotate every secret reachable from the web process.",
+        "evidence": "Packet fields for CVE-2025-32432: active_exploitation 'confirmed'; cisa_kev true with kev_date 2026-03-20; poc_available true; attack_vector 'a code-injection flaw (CWE-94) enabling unauthenticated remote code execution on the web server'; patch_available true — the fix is available, which is what makes 'patched' the compliance verdict this control has to override.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-54068": {
     "name": "Laravel Livewire Code Injection Vulnerability",
@@ -12224,7 +12272,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 remediation unit here is not an OS package but a Composer-managed component living inside every Laravel application that uses Livewire, so the KEV clock has to be run against an inventory of applications rather than an inventory of hosts. For this CVE that means: enumerate every Laravel deployment whose lockfile resolves Livewire, bump the package to the fixed release, redeploy the built artifact, and restart the PHP-FPM and queue workers so long-lived processes stop serving the old code — the packet records no live-patch path and a vendor patch that typically requires a service restart or system reboot per the KEV required action, so the restart is part of the remediation rather than a deferral point. The packet qualifies the flaw as reaching unauthenticated remote command execution in specific scenarios, which is the reason a host-level scan is not sufficient evidence of closure: an operator cannot tell from a server inventory which applications sit in the exposed configuration. With confirmed in-the-wild exploitation from the 2026-03-20 listing, the four-hour target starts at KEV listing / patch availability rather than at the next release train, and a Laravel estate whose deploys are gated on a weekly window has no way to meet it without an out-of-band path for a single dependency bump. The distinguishing test: on a production host, confirm the Livewire version actually loaded by the running PHP workers is the fixed one — not the version declared in the repository lockfile, which says what the next deploy will ship, not what is serving traffic now.",
+        "evidence": "Packet: CWE-94 code injection enabling unauthenticated remote command execution on the web server, described as reachable in specific scenarios. CISA KEV-listed 2026-03-20 with active_exploitation confirmed; CVSS 9.8, RWEP 77, poc_available true. patch_available true, live_patch_available false, and live_patch_notes records that no live-patch tool is registered and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Livewire's defect runs attacker-supplied code inside the PHP process that serves the request, with no credential required, and the packet records confirmed in-the-wild exploitation from the 2026-03-20 listing. Any internet-reachable Laravel application that was serving traffic during that window therefore has to be triaged as possibly compromised rather than closed out when the dependency is bumped: updating the package removes the injection sink but removes nothing the injected code already did — a PHP file written under the application's public or storage tree, a poisoned compiled view or cached container file, a queued job, an added administrative user, or a read of the application's environment file that handed over its database, cache, mail and third-party API credentials in one request. The control for this deployment: redeploy the application from the build pipeline onto a clean host image rather than patching the running one, restore the code tree from version control rather than editing in place, and rotate every secret the application process could read, since the exploit path could read all of them. The distinguishing test after remediation: diff the deployed file tree against the artifact the build pipeline produced, and treat any file the pipeline did not emit as the finding — a \"patched per SLA\" verdict recorded against the Livewire version attests to what is running now and says nothing about what ran during the exposure window.",
+        "evidence": "Packet: CWE-94 code injection giving unauthenticated remote command execution on the web server; CISA KEV-listed 2026-03-20 with active_exploitation confirmed; poc_available true; RWEP 77 against CVSS 9.8; patch_available true with live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-43510": {
     "name": "Apple Multiple Products Improper Locking Vulnerability",
@@ -12349,7 +12421,7 @@
         ]
       },
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "The Apple fleet must treat the OS build that fixes this flaw as an access condition, not a reporting metric: a device below it is denied or quarantined from organizational data rather than listed on a patch-compliance dashboard. The packet's vector makes the second half of this control the load-bearing half — the trigger is a malicious application writing kernel memory, so on any device that cannot yet take the fixed build the operator's remaining lever is constraining what code gets to run at all, which means restricting installation of untrusted or side-loaded applications and holding the device outside the trust boundary until it updates. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its mail, VPN and document access has recorded the exposure rather than removed it.",
         "evidence": "The packet's vector states the flaw could allow a malicious application to cause unexpected system termination or write kernel memory across watchOS, iOS, iPadOS, macOS, visionOS and tvOS — an application-driven kernel write, so the code is running locally and the boundary it crosses is below the application privilege model. That is why the least-privilege control cited against this entry is insufficient: no privilege assignment on the app constrains a kernel memory write, and the UK CAF system-security expectation likewise assumes an OS boundary the packet shows is defective. active_exploitation is confirmed, poc_available is true, cisa_kev is true with kev_date 2026-03-20, and rwep_score is 77. patch_available is true but live_patch_available is false with live_patch_notes stating the vendor patch typically requires a service restart or system reboot, so devices awaiting a reboot window remain in the exposed population and need an access-side control rather than a patch-side one.",
@@ -12918,7 +12990,7 @@
         ]
       },
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "The packet lists Android as separately affected from Chrome, so pushing a browser update to the fleet does not settle the Android exposure — the platform copy of the graphics component travels with the OS security-patch level. The enrolled-fleet policy therefore has to gate access to organizational data on the security-patch level that carries this fix, not merely report patch level on a compliance dashboard. Handsets that cannot yet receive that level — vendor-abandoned or carrier-delayed models — must be quarantined rather than risk-accepted, because the trigger is attacker-controlled web content that a user cannot reasonably avoid encountering.",
         "evidence": "Packet's vector states the flaw 'affects Google Chrome and ChromeOS, Android, Flutter, and possibly other products' and is reachable 'via a crafted HTML page'. CISA KEV listing 2026-03-13 with active_exploitation 'confirmed'; RWEP 77, CVSS 9.8, poc_available true, patch_available true.",
@@ -13756,7 +13828,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "The defect is in Qualcomm chipset code — memory corruption while using alignments for memory allocation — so no operator patches it directly. The fix reaches a device only inside the device maker's firmware/OS build, and the device's reported security-patch level is the only observable that tells an operator whether that build is actually installed. For a fleet containing devices on the affected chipsets, this control means the MDM/EMM must read the security-patch level and block or quarantine devices below the build carrying the Qualcomm fix as a condition of access to organizational data, rather than reporting the stale level on a dashboard. Because the packet's exploitation path is a local foothold escalating privilege on the device, devices that cannot yet receive an updated build must additionally be constrained against installing untrusted or side-loaded code, since that is what supplies the local execution the escalation needs. The distinguishing test: enroll a device pinned below the fixed build and confirm the policy denies it access to protected resources — a fleet that only records patch level leaves exploitable devices in production against a confirmed-exploited chipset flaw.",
         "evidence": "Packet: cisa_kev true, kev_date 2026-03-03, active_exploitation \"confirmed\", RWEP 77, CVSS 8.8, poc_available true. Vector: \"Multiple Qualcomm chipsets contain a memory corruption vulnerability while using alignments for memory allocation.\" Attack vector: an integer-overflow memory-corruption flaw (CWE-190) in Qualcomm chipset firmware/driver code, exploited by a local foothold to escalate privileges on the device. patch_available true; live_patch_available false. Every citing gap is a patch-policy control — ASD Essential Eight \"Patch operating systems\", ISO/IEC 27001:2022 A.8.8, NIST SP 800-53 SI-2, NIS2 Art.21 vulnerability handling and disclosure, UK CAF B4 — and each measures OS-level patch policy rather than enforcing a device's chipset-fix patch level as a precondition of access.",
@@ -14587,7 +14659,32 @@
     },
     "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": "Exploitation is a crafted HTML page reaching a use-after-free in Chromium's CSS handling, so exposure is continuous for every user who browses and the browser's own update channel is the only control between the estate and an exploit already confirmed in the wild. Two enforcement details are specific to this CVE. First, delivery is not effect: the packet records that the fix requires a restart, so a browser process left running for days is still exploitable after the package is reported deployed — the update ring must force the relaunch, and compliance evidence must be the fixed build observed running, not the build delivered. Second, the policy cannot be Chrome-only: the packet names Microsoft Edge and Opera among the Chromium-based browsers affected, each shipping the fix on its own channel, so an estate that pins its no-deferral rule to a single browser leaves the same use-after-free reachable through the others it has installed.",
+        "evidence": "Packet fields for CVE-2026-2441: cwe_refs CWE-416; cisa_kev true with kev_date 2026-02-17; active_exploitation 'confirmed'; cvss 8.8; rwep_score 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.'; vector 'Google Chromium CSS contains a use-after-free vulnerability that could allow a remote attacker to potentially exploit heap corruption via a crafted HTML page. This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV listing on 2026-02-17 with confirmed exploitation puts this on the expedited mitigation clock, which for a browser estate means pushing the fixed release out-of-band on the day of listing rather than folding it into the monthly workstation cycle. The clock is satisfied only by verified mitigation, and for this CVE that verification has to reach endpoints the update channel does not promptly cover — long-offline laptops and any image or non-persistent desktop template that would otherwise reintroduce the vulnerable build after the fleet reports green. For those, the documented compensating control (keeping the endpoint or image off untrusted browsing until it carries the fixed build) is what the SLA accepts; a pending-update record is not.",
+        "evidence": "Packet fields for CVE-2026-2441: cisa_kev true; kev_date 2026-02-17; active_exploitation 'confirmed'; rwep_score 77; cvss 8.8; poc_available true; patch_available true; live_patch_available false. attack_vector notes the flaw is 'exploitable by an attacker-controlled web page for code execution in the renderer' and that 'browser zero-days of this class are typically used in targeted-spyware or watering-hole chains.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2026-1731": {
     "name": "BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA) OS Command Injection Vulnerability",
@@ -14893,7 +14990,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-SUPPLYCHAIN-SIGNED-INSTALLER-INTEGRITY",
+        "id": "NEW-CTRL-132",
         "name": "INDEPENDENT-INTEGRITY-VERIFICATION-OF-SIGNED-VENDOR-INSTALLERS",
         "description": "The Notepad++ update path makes the delivery channel the trust anchor: whatever WinGUp retrieves is executed. The organization must therefore verify the Notepad++ installer against an integrity source independent of the channel that delivered it — a published per-release hash fetched over a separate path — and deploy only the verified artifact, instead of allowing endpoints to accept whatever the updater fetches. The distinguishing test for this CVE: on a staging workstation, serve a substituted installer from an operator-controlled endpoint in place of the real update host and confirm the deployment tooling refuses the artifact on hash mismatch before it runs. A software-supply-chain policy that only asserts 'we install vendor software from the vendor' passes while this exact substitution succeeds.",
         "evidence": "The packet's CWE is CWE-494 (download of code without integrity check), and the vector states the WinGUp updater downloads code without an integrity check so that intercepted or redirected update traffic results in an attacker-controlled installer being downloaded and executed. KEV-listed 2026-02-12 with confirmed active exploitation and poc_available true.",
@@ -15634,7 +15731,20 @@
     },
     "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": "Self-managed GitLab CE/EE instances must be scheduled for upgrade from the KEV listing date rather than queued behind the next planned platform-maintenance window. The scheduling detail is the whole point for this entry: the packet records no live-patch path and notes the vendor fix typically requires a service restart or system reboot, so remediation inherently consumes a maintenance window on a system the whole engineering organization depends on — which is exactly the friction that pushes GitLab upgrades into a later slot than a KEV-listed, actively exploited flaw can tolerate. Until it lands, the CI Lint API remains an unauthenticated request-forgery pivot into whatever internal resources the GitLab server itself can reach, so any deferral needs a documented containment decision about that server-side reachability, not merely a revised date.",
+        "evidence": "cisa_kev is true with kev_date 2026-02-03 and active_exploitation confirmed; rwep_score is 77 against a cvss of 7.5, with poc_available true. patch_available is true and live_patch_available is false; live_patch_notes states '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 records that GitLab Community and Enterprise Editions 'contain a server-side request forgery vulnerability which could allow unauthorized external users to perform Server Side Requests via the CI Lint API.' AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are among the framework gaps citing this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-64328": {
     "name": "Sangoma FreePBX OS Command Injection Vulnerability",
@@ -15814,7 +15924,41 @@
     },
     "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": "Web Help Desk is an always-on IT-operations server, so the KEV clock for this CVE runs against a small number of high-value hosts rather than a fleet — which makes the four-hour target achievable and makes missing it hard to justify. For this entry the action is to apply the vendor update to each Web Help Desk instance and restart the service: the packet records no live-patch path and a vendor patch that typically requires a service restart or system reboot per the KEV required action, so the service interruption is part of remediation rather than the reason to hold the fix for the next maintenance window. What makes the standard cadence indefensible here is the combination the packet records: the deserialization path reaches command execution on the host machine and can be exploited without authentication, and exploitation is confirmed rather than theoretical as of the 2026-02-03 listing — meaning the window between listing and restart is a window in which instances are being reached, not merely a window in which they could be. The distinguishing test: measure the elapsed time between the 2026-02-03 KEV listing and the completed restart of each Web Help Desk instance. A change-management process that routes an actively exploited unauthenticated RCE on an IT-management server through a standard weekly or monthly window has documented the exposure rather than removed it, even though every instance eventually reports the fixed build.",
+        "evidence": "Packet: SolarWinds Web Help Desk deserialization of untrusted data (CWE-502) that could lead to remote code execution allowing an attacker to run commands on the host machine, exploitable without authentication. CISA KEV-listed 2026-02-03 with active_exploitation confirmed; CVSS 9.8, RWEP 77, poc_available true. patch_available true, live_patch_available false, and live_patch_notes records that no live-patch tool is registered and that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A help-desk server is where an IT organization's operational secrets accumulate: the service accounts wired into directory and asset-discovery integrations, the database and mail-integration credentials, and the ticket bodies in which staff paste passwords and access instructions. The packet's path hands an unauthenticated attacker command execution on that host, and exploitation is confirmed, so an instance that was reachable before the update landed has to be handled as an incident rather than as a patch record: preserve the application and configuration state for review, rebuild the server rather than updating it in place, and rotate every credential the instance held or could reach — the directory and integration service accounts first, since those are what convert a single-host compromise into access across the estate. Applying the update to a running instance closes the deserialization path but removes nothing already placed through it: a web shell in the application's served tree, a scheduled task, an added administrative account, or a modified application file all survive the upgrade and none of them are visible to a version check. The distinguishing test: after remediation, reconcile the instance's file tree, service accounts and administrative user list against a known-good baseline; if the only evidence of closure is that the version now reports fixed, the compromise question has not been asked.",
+        "evidence": "Packet: CWE-502 deserialization of untrusted data leading to remote code execution allowing an attacker to run commands on the host machine, exploitable without authentication; CISA KEV-listed 2026-02-03 with active_exploitation confirmed; poc_available true; RWEP 77 against CVSS 9.8; patch_available true with live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "For Web Help Desk this control means treating the service's own request listener as a trust boundary instead of an internal convenience: the defect is untrusted deserialization reaching command execution for a peer that never authenticates, and the deployment assumption that normally protects it — \"the help desk is an internal ticketing system\" — is not a control, it is a statement about where the box sits. The requirement for this product is that the Web Help Desk listener accepts connections only from the segments that legitimately raise and service tickets (staff networks, the management/jump network), enforced by network ACL or host firewall rather than inherited from network topology, and that no instance is published to the internet for remote-staff convenience without an authenticating gateway in front of it, since an unauthenticated request body is all the packet's path requires to reach the deserializer. Content arriving on that listener must not be permitted to construct arbitrary objects, rather than being trusted because of where it appears to come from. The distinguishing test: from a general user or guest VLAN, and from an external address, attempt to reach the Web Help Desk service port on a staging deployment and confirm the connection is refused before the application processes the request body — an instance that passes a patch-level audit while answering unauthenticated requests from any segment is exposed again the moment the next deserialization defect in this product lands.",
+        "evidence": "Packet: CWE-502 deserialization of untrusted data in SolarWinds Web Help Desk, exploitable without authentication, leading to remote code execution on the host machine; active_exploitation confirmed with CISA KEV listing 2026-02-03; CVSS 9.8, RWEP 77, poc_available true; patch_available true, live_patch_available false with a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2026-1281": {
     "name": "Ivanti Endpoint Manager Mobile (EPMM) Code Injection Vulnerability (variant: CVE-2026-1281)",
@@ -15946,7 +16090,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-PERIMETER-VPN-AUTH-BYPASS-EXPEDITED-PATCH",
+        "id": "NEW-CTRL-131",
         "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
         "description": "FortiOS and FortiProxy are the authentication enforcement point for the perimeter, so an authentication bypass on them is not an appliance-patch-window item — it is the enforcement point failing open. The packet gives a vendor patch with no live-patch path and a restart-or-reboot requirement, so the expedited clock has to run from the 2026-01-27 KEV listing through the reboot of every affected FortiAnalyzer, FortiManager, FortiOS and FortiProxy unit. Because the packet names FortiCloud SSO authentication being enabled on the device as the condition under which the bypass works, interim exposure is bounded by enumerating which units have that path enabled and restricting reachability of their administrative surfaces until the reboot completes.",
         "evidence": "Packet name: 'Fortinet Multiple Products Authentication Bypass Using an Alternate Path or Channel Vulnerability'; cwe_refs CWE-288; CVSS 9.1, RWEP 77; cisa_kev true, kev_date 2026-01-27, active_exploitation 'confirmed', 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.'",
@@ -16433,7 +16577,7 @@
         ]
       },
       {
-        "id": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "id": "NEW-CTRL-128",
         "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
         "description": "vCenter's DCE/RPC listener is exactly the binary remoting-protocol class this control governs: a non-HTTP protocol endpoint that answers before authentication and whose parser is itself the vulnerable code, so the perimeter firewall and the web-tier hardening that most vCenter deployments are audited against never touch it. The requirement for this deployment is that DCE/RPC on vCenter accepts connections only from hosts that legitimately speak it — management and jump networks and the hosts vCenter administers — enforced by network ACL or host firewall rather than assumed from 'vCenter is internal', and that a KEV-listed defect in that parser is patched on an accelerated clock with the service restart taken rather than folded into the next quarterly virtualization window. The distinguishing test for this product: from a general user or workstation VLAN on a staging deployment, send crafted DCE/RPC packets at vCenter and confirm they are dropped before reaching the listener — an estate that passes vCenter role-and-permission audits while leaving the DCE/RPC port reachable from any internal segment is still exposed to the unauthenticated packet path.",
         "evidence": "The catalog attack_vector records 'an out-of-bounds write (CWE-787) in the vCenter Server DCE/RPC protocol implementation, exploitable by an unauthenticated attacker for remote code execution', and the vector states the trigger is 'a malicious actor with network access to vCenter Server' sending 'specially crafted network packets' — network reach to the protocol endpoint is the sole precondition. KEV-listed 2026-01-23, active_exploitation 'confirmed', poc_available true, CVSS 9.8, RWEP 77. The gaps this entry cites include NIS2 Art. 21 security of network and information systems and UK CAF B4 system security.",
@@ -16731,7 +16875,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-026",
+        "name": "NPM-CI-IGNORE-SCRIPTS-DEFAULT",
+        "description": "CI and developer installs that resolve eslint-config-prettier must run with lifecycle scripts disabled (npm/pnpm/yarn install --ignore-scripts), because the payload in the tainted releases is an install.js that the package manager executes automatically the moment the tarball is unpacked — no import, no build step, no developer action required. eslint-config-prettier is a lint-configuration package with no legitimate native build, so it belongs in the deny-by-default set with no postinstall allowlist entry; a formatting/lint dependency that suddenly requires an install hook is itself the detection signal. With scripts off, the tainted tarball can land in node_modules without ever launching the Windows node-gyp.dll payload, which converts a code-execution event on every build machine into an inert file on disk.",
+        "evidence": "The packet records the exploitation path as \"Installing an affected package executes an install.js file that launches the node-gyp.dll malware on Windows,\" running on developer and CI machines that installed the tainted versions. CWE-506 (embedded malicious code), CVSS 8.8, RWEP 77, PoC available, CISA KEV-listed 2026-01-22 with confirmed in-the-wild exploitation.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-049",
+        "name": "LOCKFILE-INTEGRITY-VERIFIED-AT-CI-BOOT",
+        "description": "The compromise arrives as new versions of a package the build already trusts, so the only consumer-side control that stops the tainted eslint-config-prettier tarball being fetched at all is a strict-lockfile install: npm ci / --frozen-lockfile / --immutable refuses to resolve any version not already pinned, so a CI run that starts after the malicious publish still installs the pre-compromise pinned release and never touches install.js. Pair it with a tarball integrity-hash check against a known-good cache snapshot at CI boot — for a lint config whose declared purpose has not changed, an integrity hash that moved without a deliberate version bump is the signal. Remediation here is dependency-side: a clean release exists, so move off the tainted versions and re-pin the lockfile; there is no live-patch path to buy time.",
+        "evidence": "Packet attack_vector: \"embedded malicious code (CWE-506) published in compromised versions of the eslint-config-prettier npm package (maintainer-account compromise), executing on developer and CI machines that installed the tainted versions.\" patch_available is true and live_patch_available is false. KEV-listed 2026-01-22, confirmed in-the-wild exploitation, RWEP 77.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-048",
+        "name": "NPM-MAINTAINER-MFA-ENFORCEMENT",
+        "description": "The root cause the packet records is maintainer-account compromise, not a coding defect in eslint-config-prettier — the attacker published under the legitimate maintainer identity, so every publisher-identity and signature check on the release passes and no vulnerability scanner has anything to flag. For a lint config with reach across essentially every JavaScript build, consuming organizations should make MFA-on-publish attestation from critical-path maintainers a precondition of accepting a version bump, and refuse to upgrade where the attestation is absent; upstream, registry-side MFA enforcement on publish-enabled accounts at this download volume is the structural fix. This is the control that addresses the compromise itself rather than its blast radius.",
+        "evidence": "Packet attack_vector attributes the tainted releases to \"(maintainer-account compromise)\" of the eslint-config-prettier npm package. CWE-506, CVSS 8.8, RWEP 77, PoC available, KEV-listed 2026-01-22 with confirmed in-the-wild exploitation.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain"
+        ]
+      }
+    ]
   },
   "CVE-2026-20045": {
     "name": "Cisco Unified Communications Products Code Injection Vulnerability",
@@ -16931,7 +17108,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": "The Gogs Git server must be moved to the fixed build on the KEV clock, not on the informal cadence self-hosted developer tooling usually gets. A Git service is treated as internal infrastructure and patched when someone has time, but this flaw is confirmed exploited in the wild and lets an attacker write outside the intended directory on the Git server through the PutContents API and reach code execution. No live-patch path exists for this entry, so the SLA must budget for the service restart or system reboot the KEV requiredAction calls for -- a self-hosted Git server frequently has no standing restart window at all, which is precisely how a KEV-listed build survives in production past its due date.",
+        "evidence": "Packet: CISA KEV-listed 2026-01-12 with active_exploitation 'confirmed'; CVSS 7.5, 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.' Vector: 'Gogs contains a path traversal vulnerability affecting improper Symbolic link handling in the PutContents API that could allow for code execution.' attack_vector: 'a path-traversal flaw (CWE-22) letting an attacker read or write files outside the intended directory on the Git server.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2009-0556": {
     "name": "Microsoft Office PowerPoint Code Injection Vulnerability",
@@ -17272,7 +17463,31 @@
     },
     "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": "This is the sharpest form of the control's premise: the packet does not describe a coding defect that a vendor build fixes, it describes ASUS Live Update clients that were themselves distributed with unauthorized modifications introduced through a supply chain compromise, executing on the endpoint in the trusted context of the vendor update utility. Every downstream check that resolves to 'it arrived through ASUS Live Update' therefore fails open, and so does an update-hygiene posture whose whole content is keeping the utility current. On managed ASUS hardware the in-app updater must stop being the trust decision: pull Live Update builds through managed software distribution, verify each build against an integrity reference obtained independently of the download itself — vendor-published per-release integrity values fetched over a separate channel, or a behavioural baseline of the installed binaries — and only then push it to endpoints. The packet's targeting detail makes one shortcut unusable: because only devices meeting specific conditions perform the unintended actions, a build that behaves benignly on a test bench is not evidence of a clean build, so verification has to be against a per-release integrity reference rather than against observed behaviour on one machine. The distinguishing test: take the build the endpoint's own updater would install and confirm it can be matched to an integrity value obtained over a channel other than that updater — a build whose only validation is that the updater fetched it is precisely the case this CVE describes.",
+        "evidence": "CWE-506 embedded malicious code. The packet states ASUS Live Update clients 'were distributed with unauthorized modifications introduced through a supply chain compromise' and that 'the modified builds could cause devices meeting specific targeting conditions to perform unintended actions'; the attack vector places execution on the ASUS endpoint in the trusted context of the vendor update utility. CISA KEV-listed 2025-12-17, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 77.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV clock here does not buy a code fix, it buys removal of a tampered build. The packet records the defect as embedded malicious code introduced through a supply chain compromise rather than a flaw in the software's logic, so remediating an affected endpoint means getting the modified ASUS Live Update client off it and a known-good build — or nothing — in its place, and the packet's live-patch note puts that behind a service restart or system reboot per the KEV required action rather than anything applied in place. Scope the clock to the ASUS endpoint population rather than to a server: the packet places execution on the endpoint in the trusted context of the update utility, so the first task inside the SLA is enumerating which endpoints carry the affected Live Update client at all, and an estate that cannot answer that question has not started the clock regardless of what its patch dashboard reports. The packet also records the product statement that the impacted build could be end-of-life or end-of-service, with users directed to discontinue product utilization — so for any endpoint where no clean build applies, removing the utility is the action this SLA covers, recorded as a documented compensating control rather than as a deferral.",
+        "evidence": "CISA KEV-listed 2025-12-17 with active_exploitation confirmed and poc_available true. patch_available true; live_patch_available false, with the packet stating no live-patch tool was registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. The packet's product statement records that the impacted product could be end-of-life (EoL) and/or end-of-service (EoS) and that users should discontinue product utilization.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-40602": {
     "name": "SonicWall SMA1000 Missing Authorization Vulnerability",
@@ -17415,7 +17630,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": "Cisco Secure Email Gateway, Secure Email, AsyncOS Software and Web Manager appliances sit on the mail-flow trust boundary, and this input-validation flaw hands an unauthenticated attacker arbitrary command execution with root privileges on the appliance's underlying operating system. That is precisely the pre-auth-RCE-on-a-trust-boundary-device profile the distinct SLA tier exists for, and the ordinary appliance-patching cadence does not apply: remediation is measured from the 2025-12-17 KEV listing, and where the AsyncOS upgrade cannot be staged inside that window the affected listener and management interfaces must be pulled off untrusted networks until it can. The upgrade takes the appliance out of mail flow - no live-patch path is registered for this entry, so the fix lands via service restart or reboot - which means the mail-delivery outage has to be planned into the KEV clock rather than used as the reason to slip it.",
+        "evidence": "Packet vector: the affected Cisco appliances contain an improper input validation vulnerability that allows threat actors to execute arbitrary commands with root privileges on the underlying operating system of an affected appliance. attack_vector: improper input validation (CWE-20) reachable by an unauthenticated attacker. cisa_kev true, kev_date 2025-12-17, active_exploitation confirmed, rwep_score 77, cvss 8.8, poc_available true. patch_available true, live_patch_available false, live_patch_notes: no live-patch tool registered 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"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Because this flaw yields root on the appliance's own operating system and exploitation is confirmed in the wild, any Cisco Secure Email Gateway or Web Manager that was reachable and unpatched during the exposure window has to be treated as compromised, not merely vulnerable. Installing the AsyncOS fix closes the input-validation path but leaves anything an attacker already wrote as root on the appliance untouched - added accounts, altered message filters and listener configuration, and OS-level persistence all survive the upgrade, and the restart the fix requires does not clear them. The IR default for these appliances must therefore be: export and review the running configuration, rebuild from vendor media at the fixed release, and rotate every credential the appliance stored or presented (directory bind, mail-relay, and management/API credentials) - patch-in-place is the wrong response and a flaw-remediation attestation recording it as resolved is exactly the paper outcome to avoid.",
+        "evidence": "Packet vector and attack_vector: unauthenticated reachability plus arbitrary command execution with root privileges on the appliance's underlying operating system. active_exploitation confirmed, cisa_kev true with kev_date 2025-12-17, poc_available true, rwep_score 77, cvss 8.8. patch_available true but live_patch_available false, with live_patch_notes recording that the vendor patch typically requires service restart or system reboot per the KEV requiredAction - a restart that restores the code path without removing attacker-placed state.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-59718": {
     "name": "Fortinet Multiple Products Improper Verification of Cryptographic Signature Vulnerability",
@@ -17475,7 +17713,30 @@
     },
     "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, FortiSwitchMaster, FortiProxy and FortiWeb sit at the network edge and are themselves the authentication enforcement point, so a crafted SAML message that defeats the FortiCloud SSO signature check puts an unauthenticated attacker in front of the control rather than behind it -- this cannot ride the routine appliance-patch window. Two packet details make the remediation record easy to get wrong. First, the advisory covers CVE-2025-59719 for the same problem, so a change ticket that installs one fix and closes leaves the same defect reachable; the expedited clock must run against every patch in the advisory. Second, the packet records no live-patch path and notes the vendor fix typically needs a service restart or reboot, which means the restart has to be scheduled inside the KEV clock from the 2025-12-16 listing, not deferred. Until the fixed builds are in, enumerate every appliance whose login federates to FortiCloud SSO and restrict the management surface to known client networks.",
+        "evidence": "Packet vector: 'Fortinet FortiOS, FortiSwitchMaster, FortiProxy, and FortiWeb contain an improper verification of cryptographic signature vulnerability that may allow an unauthenticated attacker to bypass the FortiCloud SSO login authentication via a crafted SAML message. Please be aware that CVE-2025-59719 pertains to the same problem and is mentioned in the same vendor advisory. Ensure to apply all patches mentioned in the advisory.' CWE-347; cisa_kev true, kev_date 2025-12-16; 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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-046",
+        "name": "PEN-TEST-SCOPE-INCLUDES-SECURITY-PRODUCTS",
+        "description": "The defect is in the security appliance's own login path -- the signature check applied to a SAML message on FortiCloud SSO -- so a test programme that treats FortiOS, FortiProxy and FortiWeb as the controls protecting the estate never sends the one input that finds it. Scope language must name these appliances' management and SSO login surfaces as targets in their own right, and the test has to be the inversion of the usual one: present a SAML message with an invalid or absent signature to a staging appliance and confirm no session is issued. This is the check that separates paper from reality here, because an attestation that SSO is enforced on the appliance passes cleanly while the signature verification is broken -- the login is enforced, it just accepts a forged assertion.",
+        "evidence": "Packet: CWE-347 improper verification of cryptographic signature; vector states an unauthenticated attacker can bypass the FortiCloud SSO login authentication via a crafted SAML message on FortiOS, FortiSwitchMaster, FortiProxy and FortiWeb -- Fortinet security-defense products whose own login surface carries the flaw. active_exploitation 'confirmed', poc_available true, KEV-listed 2025-12-16, CVSS 8.8, RWEP 77.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-14611": {
     "name": "Gladinet CentreStack and Triofox Hard Coded Cryptographic Vulnerability",
@@ -17785,7 +18046,30 @@
     },
     "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": "WinRAR is a user-installed desktop archiver, not an operating-system component — which is exactly why the cited 'Patch operating systems' control does not reach this defect, and why an OS-patch-compliance dashboard can read 100% green whether or not a single WinRAR copy was updated. For this CVE the control means the KEV clock that opened 2025-12-09 is driven by a software-inventory sweep that locates every WinRAR installation across the estate — including copies users installed themselves, outside any managed-software channel — and drives each one to the vendor's fixed release. The packet records a vendor patch with no live-patch path registered, so the update itself is the remediation: there is no mitigating rule, signature or configuration toggle recorded here that can stand in for it while the sweep runs. The distinguishing test is whether the estate can answer, on demand, how many WinRAR installations currently sit below the fixed release; an organisation that can report OS patch percentages but cannot enumerate its archiver installations has no clock running on this KEV entry at all.",
+        "evidence": "Packet: CISA KEV-listed 2025-12-09, active_exploitation 'confirmed', poc_available true, CVSS 7.5, RWEP 77. Product per packet name: 'RARLAB WinRAR Path Traversal Vulnerability'. patch_available true; live_patch_available false, with live_patch_notes stating no live-patch tool is registered for this entry at bulk-import time. 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",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation requires a victim to receive a crafted archive and extract it, so until every WinRAR installation reaches the fixed release the delivery path is the only surface an operator can enforce against. This CVE is specifically the container case the control exists for: per the packet the crafted archive writes files outside the intended directory — for example into a Startup/autorun location — so the file that eventually executes is one the extractor created, never one the user selected or opened. The requirement for this product is that the untrusted-origin marking applied at the mail gateway and the file-share boundary survives extraction and attaches to what WinRAR writes, so a binary that lands in an autorun location out of an externally-sourced archive is still handled as externally-sourced when it runs at the user's privilege. The distinguishing test: deliver an externally-sourced archive through each ingress path, extract it, and confirm the extracted contents — not merely the archive that arrived — still carry the untrusted-origin marking. An estate that marks the received container and lets everything unpacked from it emerge unmarked has enforced provenance on the one file the traversal does not use.",
+        "evidence": "Packet: attack_vector records 'a path-traversal flaw (CWE-22) in WinRAR's archive extraction, letting a crafted archive write files outside the intended directory (e.g. into a Startup/autorun location) for code execution when the victim extracts it.' Vector: 'RARLAB WinRAR contains a path traversal vulnerability allowing an attacker to execute code in the context of the current user.' poc_available true, active_exploitation 'confirmed', CISA KEV-listed 2025-12-09; patch_available true with live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-62221": {
     "name": "Microsoft Windows Use After Free Vulnerability",
@@ -17840,7 +18124,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet's vector says an *authorized* attacker elevates privileges locally through a use-after-free in the Windows Cloud Files Mini Filter Driver — a kernel-mode component, so the defect executes below every account-level boundary the endpoint estate is audited on. For this CVE the control means the Windows update carrying the fix is driven across the whole affected endpoint fleet on the KEV clock that opened 2025-12-09, not folded into the next monthly rollup cycle, and that completion is measured by each host's installed build against the fixed build for its SKU rather than by 'update approved' 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 host that has taken the update but not restarted still carries the vulnerable driver in memory and must be counted as exposed, not as remediated. The control's second half is the load-bearing half on this path: because the attacker is already an authorized local user, tightening account privilege does not contain the escalation to SYSTEM — a least-privilege attestation passes cleanly while the flaw remains fully exploitable, which is exactly why the cited AC-6 gap is recorded against this entry.",
+        "evidence": "Packet: CISA KEV-listed 2025-12-09, active_exploitation 'confirmed', poc_available true, CVSS 8.8, RWEP 77. Vector: 'Microsoft Windows Cloud Files Mini Filter Driver contains a use after free vulnerability that can allow an authorized attacker to elevate privileges locally.' attack_vector: 'a use-after-free (CWE-416) in a Windows kernel-mode component, exploited by a local foothold to escalate privileges to SYSTEM.' patch_available true; live_patch_available false, with live_patch_notes stating no live-patch tool is registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction. Citing gaps 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": "No live-patch path is registered for this entry and the vendor fix only takes effect after a restart, so each endpoint runs the vulnerable kernel-mode filter driver until it reboots — and with a public PoC plus confirmed in-the-wild exploitation, that window is contested rather than theoretical. For this CVE the control means the endpoint estate must carry telemetry keyed to the *outcome* of the kernel-mode use-after-free rather than to the driver's version: a process running in an ordinary user context acquiring a SYSTEM token, SYSTEM-privileged children spawned out of an interactive user session, and abnormal activity against the kernel-mode filter-driver surface — with alerting measured in seconds, not surfaced at the next log review. The packet notes that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators, so this rule has to stand on its own: it is the detection that has to fire when the initial-access step was already missed, and the escalation to SYSTEM is the last observable step before the operator holds the host.",
+        "evidence": "Packet: poc_available true with active_exploitation 'confirmed'; attack_vector records 'a use-after-free (CWE-416) in a Windows kernel-mode component, exploited by a local foothold to escalate privileges to SYSTEM' and that 'LPEs of this class are routinely paired with an initial-access flaw by ransomware operators.' live_patch_available false, live_patch_notes stating no live-patch tool is registered and the vendor patch typically requires service restart or system reboot per the KEV requiredAction. CISA KEV-listed 2025-12-09.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-37055": {
     "name": "D-Link Routers Buffer Overflow Vulnerability",
@@ -17900,7 +18208,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": "An affected D-Link router is the trust boundary for everything behind it, and this overflow is reachable without credentials, so it cannot share a patch queue with interior workstations. Put the router class in its own SLA tier: firmware for each affected model deployed within hours of the KEV listing, or the reachable interface isolated from untrusted networks until firmware lands. The tier has to name an owner and a per-model firmware inventory, because router firmware is applied by hand per device on a schedule nobody audits — an SLA with no named owner and no model-level inventory expires silently on exactly this device class. Build the restart into the tier as well: the packet gives no hot-fix path, so the plan needs a window in which the device goes down, and a tier that assumes zero-downtime remediation will not be executed.",
+        "evidence": "Packet: buffer overflow (CWE-120) on affected D-Link routers 'reachable by an unauthenticated attacker', with 'a high impact on confidentiality, integrity, and availability'; CVSS 8.8, RWEP 77, poc_available true. CISA KEV-listed 2025-12-08 with active_exploitation confirmed. patch_available is true and live_patch_available is false, with the note that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "With in-the-wild exploitation confirmed and a public proof of concept, any affected router that was reachable before its firmware update has to be treated as possibly already compromised, not as fixed the moment the version string changes. The runbook for this model class should be: capture the running configuration for forensics, reset the unit to factory state and flash the fixed firmware rather than upgrading in place, then rotate everything the device held or brokered — administrative credentials, wireless keys, and any credentials stored on it for upstream or remote-access services — before returning it to service. Upgrading over a live implant leaves attacker-made configuration changes intact on a device that now reports patched firmware, which is precisely what the flaw-remediation and technical-vulnerability-management controls will score as closed.",
+        "evidence": "Packet: active_exploitation confirmed and poc_available true, CISA KEV-listed 2025-12-08; the flaw is reachable by an unauthenticated attacker and rated high impact on confidentiality, integrity and availability (CVSS 8.8, RWEP 77). patch_available is true with live_patch_available false, and the packet notes the vendor patch typically requires service restart or system reboot per the KEV requiredAction — so every affected unit has an exposure window that closes only at that restart, and the citing gaps NIST 800-53 SI-2 (Flaw Remediation) and ISO/IEC 27001 A.8.8 (Management of technical vulnerabilities) both score that restart as remediation complete.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-66644": {
     "name": "Array Networks ArrayOS AG OS Command Injection Vulnerability",
@@ -18080,7 +18411,29 @@
     },
     "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": "ScadaBR is an HMI web front end and has to be governed like one. The packet puts the upload-and-execute path at view_edit.shtm, so anything that can reach that page can reach JSP execution on the machine operators use to drive the process — the compromise lands on the supervisory host, not on a back-office web server. Put the ScadaBR interface on a segmented management plane rather than a flat plant network or a directly reachable address, and eliminate vendor-default or blank administrative accounts on every instance, because the packet's product description gates the upload behind a ScadaBR login and an unrotated default credential turns that gate into a formality. The distinguishing test: from a network segment with no operational need to reach the HMI, attempt to load view_edit.shtm — reachability alone is the finding, since past that point a single valid or default login yields code execution on the process-control host.",
+        "evidence": "The packet's vector states: 'OpenPLC ScadaBR contains an unrestricted upload of file with dangerous type vulnerability that allows remote authenticated users to upload and execute arbitrary JSP files via view_edit.shtm.' cwe_refs is CWE-434, cvss 8.8, rwep_score 77, cisa_kev true with kev_date 2025-12-03, active_exploitation 'confirmed', poc_available true. The packet's own citing gaps include NIS2-Art21-network-security ('Security of network and information systems') and UK-CAF-B4 ('System security').",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV clock for this entry runs against an HMI, where 'restart the service' is a process-availability decision rather than a maintenance chore — which is exactly why an unmodified KEV SLA gets waived on OT assets and the exposure persists. From the 2025-12-03 listing, the SLA must pre-authorize a ScadaBR restart window, because the packet records no live-patch tool and a vendor patch that typically requires a service restart or reboot; there is no in-place option that leaves the HMI running. Where the restart cannot be scheduled inside the window, the required output is a declared compensating control — blocking reachability to view_edit.shtm from anything but the operator segment — carried as an open, time-bound item, not an entry marked remediated on schedule.",
+        "evidence": "The packet records cisa_kev true with kev_date 2025-12-03, active_exploitation 'confirmed', poc_available true, cvss 8.8 and rwep_score 77 for CWE-434 on OpenPLC ScadaBR, with the upload path at view_edit.shtm. patch_available is true, live_patch_available is false, and live_patch_notes reads: '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": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-48633": {
     "name": "Android Framework Information Disclosure Vulnerability",
@@ -18138,7 +18491,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "The Android Framework out-of-bounds read is closed only by advancing the handset's security-patch level, and the packet records no live-patch path - the device has to take the update and reboot. The MDM/EMM must read each managed device's security-patch level and block or quarantine handsets below the level carrying this Framework fix from organizational data, not merely surface the stale level on a dashboard. The second half matters more than usual here: the leak is consumed by a locally running app to defeat ASLR for the follow-on exploit, so devices that cannot yet update must also be prevented from installing untrusted or side-loaded apps - denying the local app that harvests the leak is the only mitigation available while the OEM update is out of reach. It is also the control that survives triage: at CVSS 5.5 this reads as a low-priority information disclosure, while the packet scores it RWEP 77 on confirmed in-the-wild use. Distinguishing test: enroll a device pinned below the fixing patch level and confirm it is denied protected resources.",
         "evidence": "Packet vector: Android Framework contains an unspecified vulnerability that allows for information disclosure. attack_vector records an out-of-bounds read (CWE-125) in the Android Framework used by a local app as a primitive in a privilege-escalation chain, leaking memory to defeat ASLR for a follow-on exploit, and forming the local-escalation half of a mobile-spyware chain. CISA KEV-listed 2025-12-02, active_exploitation confirmed, PoC available, CVSS 5.5, RWEP 77. patch_available true; live_patch_available false, with live_patch_notes stating no live-patch tool is registered and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
@@ -18264,7 +18617,19 @@
     },
     "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": "ScadaBR's SCADA/HMI web interface carries a CVSS of 6.1 for this stored-script flaw, which puts it below the critical/high band most patch-triage programs actually act on, while its real-world priority is RWEP 77 because CISA listed it in KEV on 2025-11-28 with confirmed in-the-wild exploitation. The KEV listing, not the CVSS band, has to set the clock on an OpenPLC/ScadaBR deployment: the vendor fix (or, until it is staged, removing the HMI web interface from any operator-reachable path as a documented compensating control) must land inside the KEV-tied window rather than being deferred to the next control-system outage. Because no live-patch path exists for this entry, the fix arrives through a service restart or reboot of the HMI host, so that ICS change window must be booked the moment the KEV listing lands - a four-year-old medium-severity CVE will otherwise sit in the vulnerability backlog indefinitely while it is being exploited against operator sessions.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-11-28, active_exploitation confirmed, rwep_score 77 against cvss 6.1, poc_available true. Vector records a cross-site scripting vulnerability via system_settings.shtm; attack_vector describes script running in an operator's authenticated session on the ScadaBR SCADA/HMI web interface. patch_available true, live_patch_available false, live_patch_notes: no live-patch tool registered at bulk-import time, vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-61757": {
     "name": "Oracle Fusion Middleware Missing Authentication for Critical Function Vulnerability",
@@ -18324,7 +18689,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": "Identity Manager is the platform that issues and governs everyone else's access, and this flaw shows Fusion Middleware exposing a critical function that could be invoked with no credential at all — so the control has to bind at the function, not at the console login. Every management-plane and environment-management function on the Fusion Middleware stack must authenticate the caller before the function runs, and the management surface must be segmented so an untrusted network caller cannot reach it in the first place. Least privilege applied to Identity Manager accounts is beside the point on this path: the attacker never holds an account, and a successful call yields takeover of the identity platform itself rather than the privileges of some compromised user. Distinguishing test: from an untrusted network segment, send an unauthenticated request to each Fusion Middleware management / critical-function endpoint on a staging instance and confirm it is refused before any privileged action executes — an attestation that 'all Identity Manager users authenticate at login' passes cleanly while this path remains open.",
+        "evidence": "Packet description: 'Oracle Fusion Middleware contains a missing authentication for critical function vulnerability, allowing unauthenticated remote attackers to take over Identity Manager' (CWE-306). CISA KEV-listed 2025-11-21 with active_exploitation 'confirmed'; CVSS 9.1, RWEP 77; poc_available true. The citing gaps this addresses are the access-path ones the packet records: UK-CAF-B2 (identity and access control), NIST-800-53-AC-6 (least privilege) and NIS2-Art21-network-security (security of network and information systems).",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "An identity platform whose downtime blocks every dependent application tends to sit on the slowest change-control calendar in the estate; this entry inverts that ordering. With confirmed in-the-wild exploitation of an unauthenticated path to Identity Manager takeover, the fixed release has to land on a KEV-tied clock measured in hours, and — since the packet records no live-patch path and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — the middleware-tier restart must be scheduled as part of that SLA rather than treated as the reason to wait for the next maintenance window. Until the restart happens the unauthenticated path is open regardless of what the patch inventory says was downloaded. Distinguishing test: for every Fusion Middleware / Identity Manager instance, measure elapsed time from the KEV listing to the fixed build actually running post-restart; a programme that records the patch as applied at download or staging time is measuring intent, not remediation.",
+        "evidence": "Packet: CISA KEV-listed 2025-11-21 with active_exploitation 'confirmed'; CVSS 9.1, 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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-13223": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2025-13223)",
@@ -18838,7 +19227,30 @@
     },
     "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": "Samsung handsets in the estate must be denied access to organizational data until their security-patch level carries the fixed libimagecodec.quram.so, not merely flagged as stale on an MDM dashboard. Because the delivery path is a malicious image processed without any user interaction, there is no user-behavior control to fall back on and no defensible 'the user will update eventually' allowance -- a handset sitting below the fixed patch level is exploitable for exactly as long as it is reported rather than quarantined. No live-patch path exists for this entry, so remediation is the vendor firmware update and its reboot; the MDM/EMM must therefore quarantine handsets that defer that update instead of counting deferral as compliance.",
+        "evidence": "Packet: 'Samsung mobile devices contain an out-of-bounds write vulnerability in libimagecodec.quram.so. This vulnerability could allow remote attackers to execute arbitrary code.' cwe_refs CWE-787. CISA KEV-listed 2025-11-10 with active_exploitation 'confirmed'; CVSS 9.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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "High-risk Samsung users -- the population this exploit class actually targets -- must run in a reduced-attack-surface mode that stops untrusted inbound images being decoded automatically, because the vulnerable code is an image parser reached by a message the user never opens. A patch SLA, however tight, cannot cover the interval between a spyware operator's use of the bug and the firmware update reaching the handset; suppressing automatic processing of untrusted message attachments and previews removes the delivery path itself across that interval. This is an explicit per-role posture decision an enterprise mobility policy has to make for exposed users, not a fleet-wide default, and it is the half of the response that survives the device being unpatched.",
+        "evidence": "Packet attack_vector: 'an out-of-bounds write (CWE-787) in the Samsung image-parsing library, exploitable by a malicious image (zero-click, e.g. delivered through a messaging app) for code execution on the device -- used in the wild in mobile spyware. CISA KEV-listed 2025-11-10 with confirmed in-the-wild exploitation; this class forms the initial-access half of a mobile-spyware chain.' poc_available true; CVSS 9.8 / RWEP 77.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-48703": {
     "name": "CWP Control Web Panel OS Command Injection Vulnerability (CVE-2025-48703)",
@@ -18958,7 +19370,30 @@
     },
     "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": "Gladinet CentreStack and Triofox are the remote file-access tier, so the clock on this entry has to start at the KEV listing rather than at the next maintenance window: the packet's chain is disclosure of server files including the machine key feeding a follow-on deserialization remote code execution, which means an unpatched hour is a full-server-takeover window, not a file-disclosure window. A vendor patch exists and is the mitigation path; because the packet records no live-patch tool for this entry and notes the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, the restart itself must be pre-authorized inside the SLA instead of being deferred to a change board. Any instance that cannot take the restart inside the window needs documented compensating controls (removing untrusted reach to the disclosing path) recorded as the SLA outcome, not an open exception.",
+        "evidence": "CISA KEV-listed 2025-11-04 with active_exploitation confirmed; RWEP 77, CVSS 8.8, poc_available true; patch_available true, live_patch_available false with the packet's note that no live-patch tool is registered for this entry and 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"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For a CentreStack or Triofox instance that was reachable while unpatched, installing the vendor update closes the CWE-552 read path but does nothing about what the packet says the read path already handed over: server files including the machine key, which is precisely the material that makes the follow-on deserialization code execution work. The response for an exposed instance must therefore default to treating the disclosed configuration and machine key as attacker-held — rotate that cryptographic material and any credentials stored on the host, and rebuild rather than patch in place — because the same disclosure that leaks the key also gives an operator no way to prove no implant was planted during the exposure window. Patch-only remediation on this CVE produces a host that reports 'remediated' while the attacker still holds a valid key for the deserialization path.",
+        "evidence": "The packet's attack vector: a files-or-directories-accessible-to-external-parties flaw (CWE-552) disclosing server files including the machine key, enabling a follow-on deserialization remote code execution; active_exploitation confirmed and KEV-listed 2025-11-04, with poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-41244": {
     "name": "Broadcom VMware Aria Operations and VMware Tools Privilege Defined with Unsafe Actions Vulnerability",
@@ -19207,7 +19642,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": "Dassault Systemes DELMIA Apriso is an enterprise manufacturing-operations platform in the same class this control names, and the packet's flaw is the exact failure it exists to prevent: a privileged application function invocable without the caller ever proving who they are. Every Apriso management-plane and privileged operation must have its authorization decision enforced server-side on each request, never inferred from the caller having reached the endpoint, and the Apriso management surface must be segmented so untrusted networks cannot reach those functions at all. The distinguishing test for this CVE: from an unauthenticated client on a staging Apriso instance, invoke each privileged/management function and confirm it is refused before any privileged action executes — an attested access-control policy that only covers interactive user login still permits the takeover the packet describes, because the flaw needs no account to abuse.",
+        "evidence": "CWE-862 missing authorization; the packet states DELMIA Apriso 'contains a missing authorization vulnerability that could allow an attacker to gain privileged access to the application', with the attack vector recorded as an unauthenticated attacker reaching privileged functionality. CISA KEV-listed 2025-10-28, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 77.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Apriso sits in the manufacturing-operations path, where restarts are normally negotiated against production schedules — and this entry's patch, per the packet, is the only remediation on offer with no live-patch tool registered and a typical service restart or reboot required. That collision is the point of a KEV-tied clock here: the restart authorization for Apriso has to be pre-agreed with operations so it can happen inside the window rather than waiting for the next planned outage, and where it genuinely cannot, the compensating control (denying untrusted network reach to the privileged endpoints named in the missing-authorization flaw) must be deployed and documented as the SLA outcome for that instance.",
+        "evidence": "CISA KEV-listed 2025-10-28 with active_exploitation confirmed; RWEP 77, CVSS 8.8, poc_available true; patch_available true, live_patch_available false with the packet's note that no live-patch tool is registered for this entry and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-54236": {
     "name": "Adobe Commerce and Magento Improper Input Validation Vulnerability",
@@ -19267,7 +19726,30 @@
     },
     "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": "An Adobe Commerce or Magento Open Source storefront is on the public internet as a condition of doing its job, and the packet's path through the Commerce REST API requires no authentication, so there is no interior network step between a published exploit and the store — the exposure window is exactly the interval between the 2025-10-24 KEV listing and the fix being live. That makes this a KEV-clock item rather than a release-train item, which matters for this product class specifically: storefront deployments are commonly scheduled around retail change-freeze windows, and a freeze is precisely the period when the store is busiest, most reluctant to deploy, and most valuable to an attacker holding an unauthenticated session-takeover primitive. The packet records a vendor patch with no live-patch path and a service restart or reboot requirement, so remediation is applying the vendor fix and taking that restart inside the KEV window, with the freeze treated as something the KEV listing overrides rather than something that defers it. Distinguishing test: read the applied patch level from the running store and confirm the restart completed, rather than accepting the deployment ticket or the change-management record as evidence — a store whose pipeline shows the patch merged but not released is unremediated in the only place that counts.",
+        "evidence": "Packet: CWE-20 improper input validation in Adobe Commerce and Magento Open Source, in the Commerce REST API (the 'SessionReaper' flaw), allowing an unauthenticated attacker to take over customer/admin sessions and reach code execution; the vector text records account takeover through the Commerce REST API. cisa_kev true with kev_date 2025-10-24; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 77. patch_available true; live_patch_available false, with live_patch_notes recording no registered live-patch tool and that the 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",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The storefront occupies the position this control governs even though it is an application tier rather than an appliance: an unauthenticated, internet-reachable path — the Commerce REST API — that ends in code execution, under exploitation confirmed in the wild as of the 2025-10-24 KEV listing. Applied to a store, the requirement is that remediation is not 'apply the patch and close the ticket'. Any store that was reachable and unpatched during the exploitation window has to be handled as possibly holding attacker-written code and attacker-held sessions, because the packet's primitive is session takeover: the fix closes the path that produced those sessions and does nothing to sessions already issued through it. That makes forced invalidation of every session predating the fix, plus rotation of administrator credentials and integration/API keys, part of remediation rather than a follow-up, and it makes the integrity question a comparison of deployed storefront code against the release artifact rather than an inference from the absence of an alert. Distinguishing test: on a patched store, confirm a session token minted before the fix is now refused, and diff the deployed code tree against the build artifact — a store that reports the vendor patch applied while pre-fix sessions still authenticate has closed the entry path and left the access it produced in place.",
+        "evidence": "Packet: the flaw lets an unauthenticated attacker take over customer/admin sessions and reach code execution through the Commerce REST API; cisa_kev true with kev_date 2025-10-24 and active_exploitation confirmed, so the exploitation window predates any operator's remediation. poc_available true; cvss 9.8; rwep_score 77. The packet's citing framework gaps include UK-CAF-B2 (Identity and access control). patch_available true; live_patch_available false, with the vendor patch requiring service restart or reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-59287": {
     "name": "Microsoft Windows Server Update Service (WSUS) Deserialization of Untrusted Data Vulnerability",
@@ -19502,7 +19984,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Kentico Xperience instances are internet-facing content servers whose administrative surface this flaw exposes to an unauthenticated caller, so the remediation clock must start at the KEV listing (2025-10-20) rather than at the site's next CMS maintenance window — which for a CMS estate is typically owned by a marketing or agency release calendar, not by security. Every instance must be enumerated by the security team, not inferred from the CMS release schedule, and because the packet records no live-patch path the remediation is the vendor update plus the service restart it requires; sites carrying the updated package but awaiting a restart stay in the exposed bucket.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-10-20, active_exploitation 'confirmed', rwep_score 77, cvss 9.1, 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: 'an authentication bypass using an alternate path or channel (CWE-288), letting an unauthenticated attacker reach administrative functionality.' The cited ASD Essential Eight patching, ISO/IEC 27001:2022 A.8.8 and NIST-800-53-SI-2 controls are recorded as insufficient for this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Any Kentico Xperience instance that was network-reachable during the confirmed-exploitation window must be triaged as compromised, not merely as unpatched. The packet's flaw lets an unauthenticated caller reach administrative functionality and control administrative objects — so administrator accounts, roles and configuration objects the attacker created are attacker-owned state that the vendor update does not touch and that survives the restart the patch requires. The runbook default for this CMS must therefore be: export and diff the administrative object state against a known-good baseline, rotate every credential the instance holds or that authenticates to it, and rebuild from known-good before returning the site to service — patch-in-place plus a green scanner result reports the CVE closed while leaving the attacker's administrative objects intact.",
+        "evidence": "Packet: cwe_refs CWE-288; vector — the flaw 'could allow an attacker to control administrative objects'; attack_vector — 'letting an unauthenticated attacker reach administrative functionality'. cisa_kev true with kev_date 2025-10-20, active_exploitation 'confirmed' and poc_available true, so in-the-wild exposure precedes any operator's patch action. patch_available true, live_patch_available false, with the vendor patch requiring a service restart per live_patch_notes. The cited UK CAF v3.2 B2 Identity and access control is recorded as insufficient for this CVE.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-2747": {
     "name": "Kentico Xperience CMS Authentication Bypass Using an Alternate Path or Channel Vulnerability (variant: CVE-2025-2747)",
@@ -19562,7 +20066,30 @@
     },
     "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": "Kentico Xperience instances are public-facing content-delivery surfaces, and this defect hands an unauthenticated caller control of administrative objects — so the exposure window for a KEV-listed bypass is measured from the 2025-10-20 listing to the moment the last instance has actually restarted on the fixed build, not to the moment the update was staged. The packet's live-patch note makes that second half load-bearing: there is no live-patch path, and the vendor fix typically requires a service restart or system reboot per the KEV requiredAction, so an SLA that stops at package deployment leaves the bypass reachable on a running site. The estate side of this is the enumeration: every Kentico instance, including sites that are not on the primary application's patch cadence, has to be on the same clock, because a single unrestarted internet-reachable instance is a full administrative-object compromise and the CMS is where the organization's public content and its administrative credential material meet. The distinguishing test: after the due date, list instances by running build and restart timestamp — a patch-compliance dashboard reporting the fixed version as available or downloaded, rather than running, records the exposure instead of ending it.",
+        "evidence": "CISA KEV-listed 2025-10-20 with active_exploitation confirmed and poc_available true; CVSS 9.1, RWEP 77. The vector states the authentication bypass could allow an attacker to control administrative objects, and the attack_vector characterises it as CWE-288 authentication bypass using an alternate path or channel reaching administrative functionality without credentials. patch_available is true but live_patch_available is false, and live_patch_notes record that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction. The citing gaps AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIS2-Art21-patch-management and NIST-800-53-SI-2 are all patch-cadence controls; none of them defines a listing-triggered clock of its own.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet says this bypass lets an attacker control administrative objects, and that it has been exploited in the wild with a public PoC — which means on an instance that was internet-reachable before the fix landed, the update removes the alternate-path bypass but leaves behind whatever administrative objects were created or altered through it. Those objects are indistinguishable from legitimate ones after the fact, because they were created through the CMS's own administrative interfaces rather than by writing to disk. A Kentico instance exposed during the window therefore needs an administrative-object and account audit against a known-good baseline, rotation of administrative credentials and of any API or connection secrets the CMS holds, and invalidation of existing administrative sessions — treated as an incident with the update as one step in it, not as a patch-and-close. The distinguishing test: on an already-updated instance, diff the administrative object and account inventory against the pre-exposure baseline; 'the fixed build is running' is not evidence that the administrative state is the one the operator intended.",
+        "evidence": "The packet's vector states the flaw could allow an attacker to control administrative objects, and the attack_vector records an unauthenticated attacker reaching administrative functionality. active_exploitation is confirmed, CISA KEV-listed 2025-10-20, poc_available true, CVSS 9.1, RWEP 77. patch_available is true with live_patch_available false and live_patch_notes recording a service restart or system reboot requirement, so the remediation on offer is an in-place vendor update that carries the instance's existing administrative state forward. UK-CAF-B2 (identity and access control) is cited as a gap: an attestation that administrator accounts are governed and periodically reviewed does not surface principals or administrative objects introduced through an authentication bypass rather than through the account-provisioning path it governs.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-33073": {
     "name": "Microsoft Windows SMB Client Improper Access Control Vulnerability",
@@ -19690,7 +20217,30 @@
     },
     "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": "Oracle E-Business Suite is the class of system whose changes normally queue behind an ERP change window and a regression cycle, and this control's demand is that a KEV listing with confirmed exploitation preempts that queue for the affected component. For this deployment 'verified mitigation' has a specific end state the packet defines: the fix applied to the Configurator component and the service restarted, because live_patch_available is false and the packet's live-patch note records that the vendor patch typically requires a service restart or system reboot per the KEV required action -- an EBS instance that has taken the patch into its staging environment, or applied it without the restart, has not mitigated. Where the change window genuinely cannot be pulled forward, this control's third option is the one that must be exercised explicitly rather than assumed: a written, time-bound compensating control -- the Configurator Runtime endpoints removed from untrusted-network reachability until the restart happens -- recorded as an active compensating state with an owner and an expiry, not as an informal decision to wait for the next window. Distinguishing test: for each EBS instance, produce the timestamp at which the fixed Configurator component was actually running post-restart and compare it against the 2025-10-20 KEV listing date; an instance whose only evidence is a change ticket scheduled into a future quarterly window has not met the SLA no matter how cleanly it passes a patch-management audit.",
+        "evidence": "Packet facts only: CISA KEV-listed 2025-10-20 with active_exploitation 'confirmed' and poc_available true. CWE-918 server-side request forgery in the Runtime component of Oracle Configurator, which the vector records as remotely exploitable without authentication. RWEP 83 against CVSS 7.5 -- real-world exploit priority far above the base score, driven by the KEV listing and confirmed exploitation rather than by base severity. patch_available true, live_patch_available false, with the live-patch note stating that no live-patch tool is registered for this entry and that the vendor patch typically requires service restart or system reboot per the KEV required action. The citing gaps are AU Essential Eight patch operating systems, ISO/IEC 27001:2022 A.8.8, NIST SP 800-53 SI-2 and NIS2 Art. 21 vulnerability handling -- every one of them cadence-based, none tied to a KEV clock.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The precondition the packet records is that the Runtime component of Oracle Configurator can be reached and driven over the network with no credential at all, so the control has to bind at the function and at reachability rather than at the EBS sign-on page. For this deployment that means two things. The Configurator Runtime paths must require an authenticated, authorized caller before the component acts on the request -- an unauthenticated caller must be refused before the server-side fetch the SSRF depends on is ever issued. And the EBS surface must be segmented so that an untrusted network caller cannot reach those paths at all: an internet-facing EBS front end should publish only the modules it has a business reason to publish, with Configurator Runtime off that list unless external self-service configuration is a deliberate requirement. On this entry the segmentation half is also the only lever that exists between the KEV listing and the restart the vendor patch needs, since the packet records no live-patch path. Least-privilege posture on EBS accounts is beside the point on this path and should not be offered as a compensating control: the attacker never holds an account. Distinguishing test: from an untrusted network segment against a staging instance, request each Configurator Runtime path unauthenticated and confirm the request is refused before the component processes it -- an attestation that 'all E-Business Suite users authenticate' passes cleanly while this path remains open.",
+        "evidence": "Packet facts only: the vector states the SSRF exists 'in the Runtime component of Oracle Configurator' and that the vulnerability 'is remotely exploitable without authentication'; attack_vector describes an unauthenticated attacker coercing server-side requests to internal resources. CWE-918. CISA KEV-listed 2025-10-20, active_exploitation 'confirmed', poc_available true, RWEP 83, CVSS 7.5. patch_available true with live_patch_available false and a note recording that the vendor patch typically requires service restart or system reboot, so reachability control is the only interim lever. UK NCSC CAF B4 system security is cited as an insufficient control on this entry.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-54253": {
     "name": "Adobe Experience Manager Forms Code Execution Vulnerability",
@@ -19948,7 +20498,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": "Windows Remote Access Connection Manager is present on the whole Windows estate, so this improper-access-control flaw turns any commodity local foothold - a phished payload, a low-privilege service account - into SYSTEM on the same host, and the packet records it as confirmed in-the-wild exploitation of a class routinely paired with an initial-access flaw by ransomware operators. That makes the monthly patch ring the wrong unit of remediation: the clock starts at the 2025-10-14 KEV listing, and the Windows update carrying the fix has to reach the entire fleet inside the KEV-tied window, explicitly including the servers and change-frozen hosts that update rings normally grant deferral to. Since no live-patch path is registered for this entry and the fix lands through a service restart or reboot, the reboot those deferral policies postpone is the exact step that closes the escalation - a host counted as 'patched pending reboot' is still a one-step path to SYSTEM.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-10-14, active_exploitation confirmed, rwep_score 77, cvss 8.8, poc_available true. Vector: improper access control in Windows Remote Access Connection Manager which could allow an authorized attacker to elevate privileges locally; attack_vector describes a local foothold escalating to SYSTEM and notes that LPEs of this class are routinely paired with an initial-access flaw by ransomware operators. patch_available true, live_patch_available false, live_patch_notes: no live-patch tool registered 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-2016-7836": {
     "name": "SKYSEA Client View Improper Authentication Vulnerability",
@@ -20128,7 +20692,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For a ZCS estate the KEV clock has to be started by the KEV listing itself rather than by severity, because this entry is the case where severity actively argues against acting: CVSS 6.1 falls below the critical-only trigger most mail-platform patch policies fire on, while the packet's RWEP of 77 reflects what is actually true of it — confirmed in-the-wild exploitation and a public PoC. The surface on the clock is the Classic Web Client, not the mail transport that vulnerability programs usually track for a mail server, since the packet's execution path is a user opening a message whose ICS entry carries the ontoggle payload. The packet records a vendor patch with no live-patch path and notes that the vendor patch typically requires a service restart or reboot per the KEV required action, so remediation means taking that restart on the KEV clock instead of holding it for the next mail-system maintenance window. Distinguishing test: confirm the running Classic Web Client is serving the fixed build rather than reading a package-level 'patched' status off the mail host — and treat closing the SLA ticket as separate from closing the incident, because applying the fix stops new ICS payloads from executing and does nothing to a redirect filter the packet's payload already created.",
+        "evidence": "Packet: CWE-79 in the Synacor Zimbra Collaboration Suite (ZCS) Classic Web Client caused by insufficient sanitization of HTML content in ICS files; when a user views an e-mail message containing a malicious ICS entry, embedded JavaScript executes via an ontoggle event inside a tag, running arbitrary JavaScript within the victim's session and enabling unauthorized actions such as setting e-mail filters that redirect messages to an attacker-controlled address, leading to e-mail redirection and data exfiltration. cisa_kev true with kev_date 2025-10-07; active_exploitation confirmed; poc_available true; cvss 6.1; rwep_score 77. patch_available true; live_patch_available false, with live_patch_notes recording no registered live-patch tool and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Zimbra's Classic Web Client presents this control's exact telemetry problem, and the packet's own impact description is why: the script runs inside a session the victim already authenticated, so the attacker never authenticates and every authentication event a ZCS deployment forwards stays clean through the whole exploitation path. The only trace is the request stream the victim's own browser produces after the ICS entry renders, including the mailbox-configuration call that installs the filter redirecting mail to the attacker's address. Forward ZCS per-request web-client access logs and mailbox filter/forwarding-configuration changes to a SIEM held outside the mail server, retained far enough back to cover the period before the 2025-10-07 KEV listing, and alert on filter or forwarding-address changes not originating from an interactive settings session. This is the half of the response that still has value after the patch lands: the fix closes the ICS execution path but leaves any filter already created quietly forwarding mail, and nothing in an authentication or MTA delivery log will surface it. Distinguishing test: create a filter through the web client on a staging ZCS and confirm the SIEM records the change with actor and timestamp — a deployment whose mail-server logging consists of authentication events and MTA delivery records passes a security-monitoring attestation while the entire exploitation and persistence path is invisible to it.",
+        "evidence": "Packet: the ICS-borne JavaScript runs within the victim's session and allows unauthorized actions on the victim's account, specifically named as setting e-mail filters to redirect messages to an attacker-controlled address, producing e-mail redirection and data exfiltration. active_exploitation confirmed; cisa_kev true with kev_date 2025-10-07; poc_available true; rwep_score 77. The packet's citing framework gaps include UK-CAF-C1 (Security monitoring) and NIS2-Art21-incident-handling. patch_available true; live_patch_available false, with the vendor patch requiring service restart or reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2021-22555": {
     "name": "Linux Kernel Heap Out-of-Bounds Write Vulnerability",
@@ -20183,7 +20769,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-130",
+        "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "description": "The packet states the precondition rather than leaving it implicit: the flaw is reached through user namespaces, by a local user with user-namespace access, and the outcome is root. On a container host that is the escape case exactly — a confined workload able to create a user namespace drives a heap out-of-bounds write in the kernel's netfilter x_tables code and lands as host root, so the namespace boundary the deployment is designed around is not a boundary at all and the kernel is the only thing left. For this CVE the control means unprivileged user-namespace creation is disabled on every host whose workloads do not genuinely require it, and each container is confined with an AppArmor or SELinux profile plus a seccomp profile with CAP_SYS_ADMIN dropped — because those measures remove the exploit precondition on hosts that cannot yet absorb the reboot the vendor kernel update needs. The distinguishing test: from inside a representative unprivileged container on a staging host, attempt to create a user namespace and reach the x_tables path, and confirm it is refused before the write occurs. A fleet that passes image-scanning and RBAC audits while permitting unprivileged user-namespace creation is still handing every confined workload this primitive.",
+        "evidence": "Packet: vector states the flaw 'could allow an attacker to gain privileges or cause a DoS (via heap memory corruption) through user name space'; attack_vector records 'a heap out-of-bounds write (CWE-787) in the Linux kernel netfilter x_tables, exploited by a local user (with user-namespace access) to gain root.' CISA KEV-listed 2025-10-06, active_exploitation 'confirmed', poc_available true, CVSS 8.8, RWEP 77. patch_available true; live_patch_available false, with live_patch_notes stating no live-patch tool is registered and the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-002",
+        "name": "LIVE-PATCH-CAPABILITY",
+        "description": "The packet pairs an available vendor kernel fix with no registered live-patch path and a remediation that requires a service restart or system reboot — which, on a Linux fleet carrying production workloads, converts an actively-exploited local-root flaw into a scheduling negotiation measured in maintenance windows rather than in the hours the KEV listing implies. For this CVE the control means live kernel patching (kpatch, livepatch, kGraft or equivalent) must already be a deployed and quarterly-tested capability on every host that cannot absorb an unplanned reboot, provisioned ahead of the next kernel KEV listing rather than stood up in response to one: a capability that did not exist on 2025-10-06 could not shorten this exposure by a single day. To be explicit about what is actionable here — the remediation for this entry remains the vendor kernel update taken with the reboot, since the packet records no live-patch tool for it; the control's value is that the next kernel out-of-bounds write does not have to queue behind the same negotiation. The distinguishing test: pick a production host and confirm a live-patch agent is installed and has successfully applied a kernel patch within the last quarter. A fleet whose compliance report is green because kernel updates are staged-but-not-rebooted is still running the vulnerable kernel in memory.",
+        "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 2025-10-06 with active_exploitation 'confirmed' and poc_available true; CVSS 8.8, RWEP 77. Affected product per packet name: 'Linux Kernel Heap Out-of-Bounds Write Vulnerability'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "With a public PoC, confirmed in-the-wild exploitation, no registered live-patch path, and a fix that only takes effect on reboot, every host still waiting in the maintenance queue is running the vulnerable netfilter x_tables code with a working exploit in circulation. For this CVE the control means auditd or eBPF rules written against the exploitation sequence the packet describes rather than against the kernel package version: unprivileged user-namespace creation by a process that then issues netfilter/x_tables socket-option calls, and any transition to uid 0 by a process that did not start privileged — alerting within 60 seconds, because a local-root primitive is used and moved on from in far less time than a daily log review. The packet records that LPEs of this class are routinely paired with an initial-access primitive, so the rule has to stand alone rather than assume an earlier alert: this is the detection that has to fire when the initial-access step went unseen. It is also the control that distinguishes a fleet that knows its unrebooted hosts are exposed from one that reports them as patched because the package version is current.",
+        "evidence": "Packet: poc_available true with active_exploitation 'confirmed'; attack_vector records 'a heap out-of-bounds write (CWE-787) in the Linux kernel netfilter x_tables, exploited by a local user (with user-namespace access) to gain root' and that 'LPEs of this class are routinely paired with an initial-access primitive.' Vector notes the path is 'through user name space'. live_patch_available false, with live_patch_notes stating no live-patch tool is registered and the vendor patch typically requires service restart or system reboot per the KEV requiredAction. CISA KEV-listed 2025-10-06.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2010-3962": {
     "name": "Microsoft Internet Explorer Uninitialized Memory Corruption Vulnerability",
@@ -20813,7 +21431,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": "A Meteobridge is a small weather-station data-logger appliance that no endpoint-management console enrols and no software-inventory agent reports, so the KEV clock this control imposes lands on a device class that typically has no owner inside the patch program at all — the first work the SLA forces is enumerating where these units are before any of them can be counted as remediated. Meeting it means each unit is taken through the vendor update and the restart the packet's live_patch_notes describe, with no live-patch path available to avoid that interruption. The SLA is unusually load-bearing on this product because the flaw needs no credential and yields root: there is no partial state where an unpatched unit is merely degraded, and there is no account lockout, session expiry or credential rotation that buys time while the update is scheduled — an enumerated-but-unpatched Meteobridge past the clock is fully exposed to a publicly available exploit.",
+        "evidence": "Packet records cisa_kev true with kev_date 2025-10-02 and active_exploitation confirmed, RWEP 77 / CVSS 9.8, poc_available true. patch_available is true, live_patch_available is false, and live_patch_notes read: '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 NIST-800-53-SI-2 are recorded among the citing gaps.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The packet's CWE pair is the entire defect: CWE-306 means the Meteobridge's network-facing configuration surface performs a critical function without ever demanding a credential, and CWE-77 means what arrives at that surface reaches an OS command sink — which is why the packet's own wording is that a remote unauthenticated attacker gains arbitrary command execution with elevated privileges (root) on affected devices. Bound to this appliance, the control requires each of those configuration endpoints to authenticate its caller before processing, to neutralize what it passes to the command interpreter rather than filtering the request string, and to be unreachable from untrusted networks — the last clause is the practical one, because a weather station's data-publishing role is precisely what puts its interface on a reachable address, and reachability is the only remaining exploit precondition once a public exploit exists. The least-privilege gap cited for this CVE is not on this path: the attacker holds no account to constrain, and the injected command already executes as root, so account-privilege scoping is never consulted. Because exploitation is confirmed rather than theoretical, a unit whose configuration surface was reachable before the firmware update needs forensic triage rather than a patch-and-close, since the update closes the injection path but removes nothing an attacker already ran as root. Distinguishing test: from an untrusted segment, send each configuration endpoint on a staging Meteobridge a payload that attempts command execution and confirm it is refused before any interpreter runs.",
+        "evidence": "Packet vector: 'Smartbedded Meteobridge contains a command injection vulnerability that could allow remote unauthenticated attackers to gain arbitrary command execution with elevated privileges (root) on affected devices.' cwe_refs are CWE-306 and CWE-77; attack_vector describes an OS command-injection flaw on the Smartbedded Meteobridge weather-station device letting an unauthenticated attacker execute commands on the device, CISA KEV-listed 2025-10-02 with confirmed in-the-wild exploitation, poc_available true. NIST-800-53-AC-6 (Least Privilege), UK-CAF-B4 (System security) and NIS2-Art21-network-security are recorded among the citing gaps.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-32463": {
     "name": "Sudo Inclusion of Functionality from Untrusted Control Sphere Vulnerability",
@@ -20868,7 +21510,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": "Sudo is present on effectively every Linux/Unix host in an estate, so for this entry the KEV clock governs a fleet-wide package rollout rather than one service, and the at-risk population is every host on which any local code execution is possible — not just internet-facing ones, since the packet's path starts from a local attacker. The remediation the packet supports is the vendor sudo update: patch_available is true and no live-patch tool is registered for this entry, so there is no in-place kernel-style hot fix to fall back on, and the SLA has to be measured as percentage of hosts carrying the updated sudo package, not as 'patch approved for release'. Any host that cannot take the update inside the window needs its compensating control written down, because the flaw grants root to a local user regardless of that user's sudoers entitlements, so existing sudoers restrictions cannot be claimed as the compensating control.",
+        "evidence": "The packet: sudo's -R (--chroot) option lets a local attacker run arbitrary commands as root 'even if they are not listed in the sudoers file' (CWE-829, inclusion of functionality from an untrusted control sphere). CISA KEV-listed 2025-09-29 with active_exploitation confirmed; RWEP 77, CVSS 8.8, poc_available true; patch_available true, live_patch_available false with the packet's note that no live-patch tool is registered for this entry.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-59689": {
     "name": "Libraesva Email Security Gateway Command Injection Vulnerability",
@@ -21282,7 +21938,40 @@
     },
     "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 vulnerable component is the VPN web server on Cisco Secure Firewall ASA and FTD — the device that terminates remote access and is itself the trust boundary — and the packet gives a CWE-120 buffer overflow reachable without authentication for remote code execution at CVSS 9.8. A standard 14- or 30-day appliance patch SLA measures the wrong thing on this class: from the KEV listing there is a public PoC and confirmed in-the-wild exploitation against the box whose whole job is deciding who gets inside, so the exposure is not proportional to the number of days remaining in the window. The requirement for this deployment is a distinct tier — the vendor fix deployed within hours of the KEV listing, taking the service restart or reboot the packet's requiredAction calls for, or the VPN web server's listener removed from untrusted networks until that reboot completes. The distinguishing test: enumerate every ASA and FTD unit with the VPN web server enabled and confirm each is on the fixed build past the KEV due date; a fleet report showing those units scheduled into the next quarterly maintenance window has recorded the exposure rather than removed it, and the restart requirement is exactly why they get scheduled there.",
+        "evidence": "Packet: CWE-120 buffer overflow in the Cisco Secure Firewall ASA and Secure Firewall Threat Defense (FTD) VPN Web Server, allowing unauthenticated remote code execution; cvss 9.8, rwep_score 77, poc_available true. CISA KEV-listed 2025-09-25 with active_exploitation confirmed. 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",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Because this is pre-authentication code execution on the ASA/FTD appliance itself and the packet records confirmed in-the-wild exploitation alongside a public PoC, the vendor update remediates the defect but not the device: anything an attacker wrote to a unit during the exposure window survives the upgrade. Any appliance whose VPN web server was reachable before the fix landed has to be treated as compromised until shown otherwise — configuration and image captured for forensics first, the device rebuilt from a known-good image, and every credential it held or terminated rotated, including local administrative accounts, VPN user credentials and active session material, and the key material on the tunnels it fronted. The packet also states this flaw can be chained with CVE-2025-20362, so the triage question is not whether the overflow ran in isolation but what the chained access reached afterwards and which interior credentials passed through the box during the window. Distinguishing test: an IR runbook that answers a KEV-listed pre-auth RCE on a VPN concentrator with patch-and-monitor fails this control — the default has to be rebuild plus rotation, decided before the next disclosure rather than during it.",
+        "evidence": "Packet: unauthenticated remote code execution on the ASA/FTD VPN Web Server via a CWE-120 buffer overflow; the vector notes 'This vulnerability could be chained with CVE-2025-20362.' active_exploitation confirmed, CISA KEV-listed 2025-09-25, poc_available true, rwep_score 77. patch_available true with no live-patch path recorded.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "Code execution on the ASA/FTD unit puts the attacker inside the same system that produces the device's own record, so syslog, VPN authentication events and threat logs held on the compromised appliance are attacker-controlled evidence from the moment the overflow lands. This deployment therefore has to be forwarding those streams continuously to a collector in a separate trust zone — different management plane, different credentials, different authentication path from the firewall administrators' — so that the record of pre-exploitation probing of the VPN web server, and of what the chain with CVE-2025-20362 reached afterwards, exists somewhere the appliance cannot reach or erase. With exploitation already confirmed at KEV listing and a restart-requiring vendor update, the interval between exposure and completed reboot is precisely when the off-device copy is the only surviving source. Distinguishing test: on a staging unit, clear the local log store and confirm the separate-zone collector still holds that period's VPN authentication and connection events.",
+        "evidence": "Packet: the flaw yields remote code execution on the Cisco ASA/FTD appliance's VPN Web Server itself; active_exploitation confirmed, CISA KEV-listed 2025-09-25, poc_available true. Remediation requires the vendor patch with a service restart or system reboot per the KEV requiredAction (live_patch_available false), and the vector notes the flaw can be chained with CVE-2025-20362.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-5086": {
     "name": "Dassault Systèmes DELMIA Apriso Deserialization of Untrusted Data Vulnerability",
@@ -22592,7 +23281,30 @@
     },
     "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": "Run the KEV clock against the camera population itself, not against the servers that consume its streams. From the 2025-08-05 KEV listing, every reachable DCS-2530L/DCS-2670L must reach a verified mitigation inside the same window a managed server fleet would get: either the vendor firmware that closes cgi-bin/ddns_enc.cgi, or removal of the camera's management surface from any segment an untrusted caller can reach. These cameras carry no management agent, so 'deploy the update' is a per-device, hands-on firmware push with no fleet-wide rollout path — and the packet records no live-patch tool and a vendor fix that typically needs a restart or reboot, so the SLA has to budget a per-device outage rather than assume a background update lands on its own.",
+        "evidence": "The packet records cisa_kev true with kev_date 2025-08-05, active_exploitation 'confirmed', poc_available true, cvss 9.8 and rwep_score 77 for command injection (CWE-77) in cgi-bin/ddns_enc.cgi on the D-Link DCS-2530L and DCS-2670L. patch_available is true, live_patch_available is false, and live_patch_notes reads: '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"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Extend the rebuild-don't-patch default to network-edge embedded devices. A DCS-2530L/2670L that was reachable during the confirmed-exploitation window must be treated as having already been executed against by a public exploit, and flashing fixed firmware restores the binary without evicting whatever the attacker left behind or re-securing what it read. The runbook for these cameras must capture the running configuration first, then factory-reset and reflash rather than update in place, and rotate the camera's administrative credential plus any DDNS credentials configured through ddns_enc.cgi — the exact page the injection reaches, so those values are inside the attacker's read scope. 'Firmware updated' is an incomplete remediation record for this entry unless the reset and the credential rotation are logged next to it.",
+        "evidence": "The packet records active_exploitation 'confirmed' with a CISA KEV listing on 2025-08-05 and poc_available true, for a flaw its attack_vector describes as 'command injection (CWE-77) on the D-Link DCS-2530L/2670L cameras, giving an unauthenticated attacker command execution' (cvss 9.8, rwep_score 77). The vulnerable endpoint named in the packet's vector is cgi-bin/ddns_enc.cgi. The only remediation the packet carries is the vendor patch (patch_available true, live_patch_available false, restart-or-reboot note); nothing in the packet addresses the state of a device that was already exploited.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-40799": {
     "name": "D-Link DNR-322L Download of Code Without Integrity Check Vulnerability",
@@ -23050,7 +23762,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The catalog records this SysAid On-Prem entry as a variant and places the XXE at a second injection point — the same XML-parsing primitive reached through a different input on the Server URL processing path. A vulnerability-management program that scores each SysAid XXE CVE as a discrete finding will re-run the same triage and reach the same urgency each time, when the correct reading is that external-entity resolution was never disabled at the parser level; only the individual reachable inputs were closed. Until the vendor states that the parser itself rejects external entities and DTD processing globally, every SysAid On-Prem XXE finding should carry a sequence multiplier and the deployment should be treated as having further undiscovered injection points into the same primitive, rather than as remediated once this specific parameter is fixed.",
+        "evidence": "Packet name: \"SysAid On-Prem Improper Restriction of XML External Entity Reference Vulnerability (variant: CVE-2025-2776)\"; attack_vector: \"an XML external entity (XXE) flaw (CWE-611) at a second injection point, letting an unauthenticated attacker read server files and coerce server-side requests.\" CWE-611, CVSS 8.8, RWEP 77, PoC available, KEV-listed 2025-07-22 with confirmed in-the-wild exploitation.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "SysAid On-Prem is customer-operated and the packet's exploitation path is unauthenticated, so any deployment whose portal is reachable by untrusted callers is exposed from the KEV listing forward and the clock starts there, not at the next maintenance window. A vendor update exists, but there is no live-patch path and applying it requires a service restart per the KEV required action — which means the four-hour mitigation obligation has to be met by a compensating control while that restart is scheduled: block unauthenticated reachability of the Server URL processing endpoint at the reverse proxy or WAF, or take the portal off untrusted networks entirely. Because the impact is administrator account takeover plus a file-read primitive, an operator who logs \"update scheduled for the next change window\" is recording unmitigated exposure, not compliance, and should also plan credential rotation for the SysAid administrative accounts once the update lands.",
+        "evidence": "KEV-listed 2025-07-22 with confirmed in-the-wild exploitation; RWEP 77, CVSS 8.8, PoC available. patch_available is true but live_patch_available is false, and the packet's live-patch note states the vendor patch \"typically requires service restart or system reboot per the KEV requiredAction.\" The vector names \"the Server URL processing functionality\" and the impact as \"administrator account takeover and file read primitives.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-6558": {
     "name": "Google Chromium ANGLE and GPU Improper Input Validation Vulnerability",
@@ -23165,7 +23900,30 @@
     },
     "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": "CrushFTP is an internet-facing managed file-transfer server whose exposure, per the packet's own vector, exists whenever the DMZ proxy deployment mode is not in use — the AS2 validation path is then reachable over HTTPS and yields admin access without credentials. Because live_patch_available is false and the packet notes the vendor patch typically requires a service restart or reboot, meeting the 4-hour clock means running the CrushFTP service restart as an emergency change rather than queueing it for the next maintenance window. Where the restart cannot land inside that window, the compensating-control branch has to remove the unauthenticated route rather than merely monitor it: cut external reach to the HTTPS/AS2 listener and move the instance behind the DMZ proxy topology the packet names as the condition under which the flaw does not arise, and record that isolation as the attested mitigation. 'Update scheduled' is not an acceptable interim state for a server that holds transfer data for every partner it serves.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-07-22 and active_exploitation confirmed; RWEP 77, CVSS 8.8, poc_available true. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' Vector: 'When the DMZ proxy feature is not used, mishandles AS2 validation and consequently allows remote attackers to obtain admin access via HTTPS.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "CWE-420 on CrushFTP hands an unauthenticated caller admin access to the file-transfer server that sits on the trust boundary, and the packet records exploitation as confirmed in the wild with a PoC available. An instance that was internet-reachable before the update therefore has to be handled as one an attacker may already control, not as a host awaiting a patch. Applying the update and restarting the service does not undo anything reached through that admin session: additional admin users, stored partner credentials, and automation entries are configuration, not code, and they survive the upgrade intact. The runbook for an exposed CrushFTP instance must export the admin/user and job configuration and diff it against a known-good baseline, rebuild the host, rotate every admin, service and partner transfer credential the instance held, and treat files staged on it as potentially exfiltrated. Patch-in-place — the default reading of 'flaw remediated' — is exactly the failure mode this control exists to prevent on this class of internet-facing transfer server.",
+        "evidence": "Packet: active_exploitation confirmed, cisa_kev true (kev_date 2025-07-22), poc_available true, RWEP 77, CVSS 8.8. Attack vector: 'an unprotected-alternate-channel flaw (CWE-420) letting an unauthenticated attacker reach administrative functionality via the alternate (AS2) path and gain admin control of the file-transfer server.' patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-49704": {
     "name": "Microsoft SharePoint Code Injection Vulnerability",
@@ -23771,7 +24529,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The interval is what makes this a KEV-clock case: the packet carries a 2016 identifier year and a KEV listing dated 2025-07-07 with confirmed exploitation. Nine years of CVSS 9.8 sitting in the record did not get this fixed, which is the direct evidence that severity-ordered, recency-fed remediation does not reach it — a queue built from current-year advisories and this month's vendor bulletins never surfaces a 2016 library flaw at all, no matter how the severity threshold is set. The KEV listing is the event that has to override that ordering and put every PHP application sending mail through PHPMailer on the clock. The packet records a vendor patch with no live-patch path and a restart or reboot requirement, so remediation is shipping the fixed library into each affected application and taking that restart, rather than assuming that replacing files on disk is the end of it. Distinguishing test: ask the KEV-response process to produce the remediation date for a CVE whose identifier year is 2016 — a program reporting full KEV coverage while its intake is driven by current-year advisory feeds has not looked at this entry, and the gap is in what feeds the queue rather than in the SLA written above it.",
+        "evidence": "Packet: CWE-77/CWE-88 command injection in PHPMailer because it fails to sanitize user-supplied input, affecting the 'mail()' function of the 'class.phpmailer.php' script; an attacker can execute arbitrary code within the context of the application, and failed exploit attempts result in a denial-of-service condition. The packet places the flaw in PHPMailer's sender-address handling, enabling remote code execution in PHP applications that pass attacker-controlled input to the From address. cisa_kev true with kev_date 2025-07-07 against a CVE identifier year of 2016; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 77. patch_available true; live_patch_available false, with live_patch_notes recording no registered live-patch tool and that the vendor patch typically requires service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "PHPMailer is almost never something an organization decides to install. It arrives inside a CMS, a plugin, a theme, a vendored composer tree, or a third-party web application, which means estate exposure here is a property of dependencies-of-dependencies rather than of anything that appears on a software inventory or in an OS package database — and an operating-system patch cycle will never touch a copy of class.phpmailer.php sitting inside an application directory. The packet's path needs exactly one such copy: any PHP application that passes attacker-controlled input into the From address supplies the flaw its input, and code then executes in that application's context, so a single unenumerated copy behind a contact form is the whole exposure. Inventory therefore has to resolve to the library level and follow transitive and vendored copies — every place the file exists on disk and in every container image — because a copy nobody has enumerated cannot be assessed as vulnerable, cannot be put in a patch queue, and cannot be confirmed as fixed afterwards. Distinguishing test: search filesystems and built images for PHPMailer copies and reconcile the result against the software inventory; every copy the search returns that the inventory does not list was never in the patch queue, and a clean patch-compliance report covering only the products the organization believes it runs is measuring the wrong set.",
+        "evidence": "Packet: the flaw is in the 'mail()' function of the 'class.phpmailer.php' script and enables remote code execution in PHP applications that pass attacker-controlled input to the From address, with code executing within the context of the application. cisa_kev true with kev_date 2025-07-07; active_exploitation confirmed; poc_available true; cvss 9.8; rwep_score 77. The packet's citing framework gaps include AU-Essential-8-Patch (Patch operating systems) and NIS2-Art21-vulnerability-management (Vulnerability handling). patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2014-3931": {
     "name": "Multi-Router Looking Glass (MRLG) Buffer Overflow Vulnerability",
@@ -23826,7 +24606,38 @@
     },
     "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": "Anchor MRLG remediation to the KEV listing date (2025-07-07) rather than to the CVE's assignment year: a vulnerability-management program that risk-ranks or ages its queue by CVE year parks a 2014 identifier at the bottom of the backlog on the same day CISA declares it actively exploited. Scope is every looking-glass or route-server host still serving the MRLG Perl CGI — infrastructure that is usually inventoried as a network service rather than as an application and so falls outside the estate a patch SLA is measured against. The packet records no live-patch path, so remediation is the vendor update plus the service restart it requires, and the SLA closes only when the CGI is confirmed no longer serving the vulnerable code.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-07-07, active_exploitation 'confirmed', rwep_score 77, cvss 8.8, poc_available true — against a CVE identifier assigned in 2014. patch_available true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' The cited ASD Essential Eight patching, NIST-800-53-SI-2 Flaw Remediation and UK CAF B4 System security controls are recorded as insufficient for this CVE.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A public looking-glass host runs MRLG as an unauthenticated, internet-reachable CGI, and the packet's exploitation path is a remote arbitrary memory write leading to code execution on that host — so any host that was serving the CGI during the confirmed-exploitation window has to be handled as compromised. Updating the CGI leaves everything the attacker wrote to the host in place: added accounts, scheduled jobs, modified CGI or wrapper scripts, and any stored configuration the looking glass uses to reach the routers it queries. The default response for a route-server or looking-glass host must be evidence capture, rebuild from known-good, and rotation of every credential that host holds or that authenticates to it — not an in-place package update, which is what a patch-SLA attestation would otherwise record as sufficient.",
+        "evidence": "Packet: vector — MRLG 'contains a buffer overflow vulnerability that could allow remote attackers to cause an arbitrary memory write and memory corruption'; attack_vector — 'a buffer overflow (CWE-119) in Multi-Router Looking Glass (MRLG), the Perl CGI used on looking-glass route servers, letting a remote attacker write to arbitrary memory for code execution on the looking-glass host'. cisa_kev true, kev_date 2025-07-07, active_exploitation 'confirmed', poc_available true. patch_available true, live_patch_available false with a restart required per live_patch_notes. The cited NIS2 Art. 21 security-of-network-and-information-systems control is recorded as insufficient for this CVE.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-074",
+        "name": "CVE-REGRESSION-WATCHER",
+        "description": "This entry is the case the watcher exists for: the identifier is from 2014 and the flaw only became an operator emergency when CISA listed it on 2025-07-07, with working exploit material already available. An intake pipeline keyed to current-year advisories never resurfaced MRLG across that gap, even though the Perl CGI stayed deployed and internet-reachable on looking-glass hosts the whole time. The watcher must poll exploit and PoC publication for references to old CVE identifiers and route a hit on an identifier this old into the same triage queue as a fresh advisory — because for long-lived, rarely-touched infrastructure software the age of the identifier says nothing about whether the code is still running and reachable.",
+        "evidence": "Packet: the identifier is CVE-2014-3931 while cisa_kev_date is 2025-07-07 — the flaw sat between assignment and KEV listing — with active_exploitation 'confirmed', poc_available true, rwep_score 77 and cvss 8.8. attack_vector places the code in 'the Perl CGI used on looking-glass route servers'. The cited ISO/IEC 27001:2022 A.8.8 management-of-technical-vulnerabilities control is recorded as insufficient for this CVE.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-6554": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (variant: CVE-2025-6554)",
@@ -24097,7 +24908,29 @@
     },
     "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": "NetScaler ADC/Gateway carries this defect only when it is configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or an AAA virtual server — which is to say, only when it is acting as the organization's remote-access trust boundary, exactly the deployment class this SLA tier exists for. Two consequences for this product: units in those roles cannot be folded into a 14- or 30-day appliance-maintenance cadence, and the clock does not stop at the staged image, because the packet records no live-patch path and a restart-or-reboot requirement — so it runs from the 2025-06-30 KEV listing through the completed restart of every unit in a Gateway or AAA role. The control's alternative, isolating the vulnerable interface, has a specific meaning here: the vulnerable parser is what answers on the Gateway or AAA virtual server itself, so interim exposure is bounded by restricting reachability of those virtual servers, not by filtering somewhere upstream of an appliance that is itself the filter. Inventorying which units hold those roles is the first action, since it is also what lets the rest of the fleet be triaged down. The distinguishing test: enumerate every NetScaler by configured role and running build against the fixed build past the due date — a severity-driven patch queue that sorts by CVSS 7.5 leaves an actively-exploited boundary device sitting behind higher-scored internal findings.",
+        "evidence": "The packet's vector states that NetScaler must be configured as Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) OR AAA virtual server for the flaw to apply, placing the vulnerable role on the remote-access trust boundary. The attack_vector describes a CWE-119 buffer overflow exploitable for memory corruption yielding both DoS and code execution. CISA KEV-listed 2025-06-30, active_exploitation confirmed, poc_available true, CVSS 7.5 against RWEP 77. patch_available is true, live_patch_available is false, and live_patch_notes record that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction. The citing gaps AU-Essential-8-Patch, ISO-27001-2022-A.8.8 and NIST-800-53-SI-2 are general patch-and-flaw-remediation controls that apply one cadence to the estate and draw no distinction for a device that is itself the trust boundary.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A NetScaler in the Gateway or AAA role that was reachable while this was being exploited cannot be treated as clean once the update lands. The packet's primitive is a buffer overflow producing unintended control flow, and its attack_vector records code execution alongside denial of service — so a successful run means attacker-controlled execution on the appliance that terminates the organization's remote-access sessions and performs its authentication. The default response for an affected unit is therefore configuration extraction, rebuild from vendor media, and rotation of the credential and key material the appliance holds or could observe — administrative credentials, certificate private keys, and any credentials that traversed the Gateway or AAA virtual server — with existing sessions invalidated rather than carried across the upgrade. The reason this is the default rather than the escalation is mechanical: the packet offers no live-patch path, so remediation is an in-place vendor update plus restart, and an in-place update preserves the appliance's configuration and filesystem, which is precisely what an implant needs to survive the fix. The distinguishing test: on an already-upgraded unit, ask what evidence exists that no code ran before the upgrade — if the answer is the build number, the unit has been patched but not cleared.",
+        "evidence": "The packet describes a CWE-119 buffer overflow leading to unintended control flow, with the attack_vector recording exploitation for memory corruption yielding DoS and code execution, on a NetScaler configured as Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server. active_exploitation is confirmed, CISA KEV-listed 2025-06-30, poc_available true, CVSS 7.5, RWEP 77. patch_available is true with live_patch_available false and live_patch_notes recording a service restart or system reboot requirement — an in-place update that carries the appliance's existing configuration forward. UK-CAF-B4 (system security) is cited as a gap: a system-security attestation satisfied by the appliance running a supported, patched build says nothing about whether that build was applied over a unit that had already executed attacker code.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2019-6693": {
     "name": "Fortinet FortiOS Use of Hard-Coded Credentials Vulnerability",
@@ -24157,7 +24990,41 @@
     },
     "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": "Remediation of the affected FortiOS gateways has to be clocked from the KEV listing of 2025-06-25, not from the CVE's vintage or its base score. The identifier is from the 2019 series, so any queue ordered by disclosure year — or by an 8.8 CVSS competing against newer criticals — buries it, yet the packet records confirmed in-the-wild exploitation, a public PoC, and an RWEP of 83. A vendor patch is available, and the packet notes it typically requires a service restart or system reboot per the KEV requiredAction, so the SLA has to include the firewall's failover or maintenance window: on a perimeter device, remediation is only complete when the device is actually running the fixed build, not when the image is staged on it.",
+        "evidence": "Packet: cve CVE-2019-6693, name 'Fortinet FortiOS Use of Hard-Coded Credentials Vulnerability', cisa_kev true, kev_date 2025-06-25, active_exploitation confirmed, rwep_score 83, cvss 8.8, poc_available true, patch_available true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-124",
+        "name": "FRAMEWORK-DEFAULT-SECRET-DETECTION",
+        "description": "The secret at issue is one no operator ever chose or could rotate: per the packet, FortiOS ciphers sensitive data in the configuration backup file using a hard-coded key (CWE-798), so knowledge of that key is enough to read any backup produced by an affected build. Configuration and deployment gating must therefore treat 'appliance running a build whose backup encryption depends on a vendor-embedded constant' as a failing state for the device, and must treat every configuration archive taken from such a device — in backup repositories, ticketing attachments, vendor support bundles, config-management stores — as effectively cleartext until the appliance is on a fixed build. This is precisely the class the control names: a shipped constant cryptographic secret that converts a routine data artifact into a compromise. No credential review, key-inventory questionnaire or access recertification surfaces a key that was compiled into the firmware; only an explicit check for shipped default secrets does.",
+        "evidence": "Packet: cwe_refs CWE-798; vector 'Fortinet FortiOS contains a use of hard-coded credentials vulnerability that could allow an attacker to cipher sensitive data in FortiOS configuration backup file via knowledge of the hard-coded key.'; attack_vector describes 'use of hard-coded credentials (CWE-798) in FortiOS, allowing authentication with built-in credentials'; poc_available true.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive in this entry is key and credential disclosure rather than code execution, so it is the runbook's rotation limb, not its RCE trigger, that binds here: upgrading the FortiOS device does not make a configuration backup an attacker already holds any less readable, because the key that ciphered it is a fixed constant the operator never controlled. For every affected gateway, the response has to assume the archives are readable and rotate the credentials and keys the device configuration holds, then review where those archives were stored, mailed, or handed to third parties during the exposure window. The packet records confirmed in-the-wild exploitation and a public PoC on a perimeter device, which is exactly the condition under which treating patch-in-place as the terminal remediation step leaves the attacker's material valid after the ticket is closed.",
+        "evidence": "Packet: FortiOS entry with active_exploitation confirmed, cisa_kev true (kev_date 2025-06-25), poc_available true, rwep_score 83; vector states the hard-coded key is used to 'cipher sensitive data in FortiOS configuration backup file'; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-0769": {
     "name": " D-Link DIR-859 Router Path Traversal Vulnerability",
@@ -24277,7 +25144,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The MegaRAC SPx BMC is a fleet control plane in the sense this control means: one Redfish administrative tier governs power state, console, virtual media and firmware across every server carrying that BMC, and the packet states that control of the BMC is control of the host beneath its operating system. The CWE-290 spoofing bypass on the Redfish Host Interface removes the credential requirement altogether, which leaves network reachability as the only remaining boundary — so the privilege-tier requirement has to be expressed as a reachability requirement too. Classify BMC/Redfish administration as a tier above OS and hypervisor admin: reachable only from a PAM jumphost on a dedicated out-of-band management network that is not routable from user VLANs or the internet, FIDO2 step-up per session, an identity distinct from the server-admin account, and BMC administrators enumerated separately in access reviews rather than inherited from 'server admin'. Frameworks that collapse server administrator and BMC administrator into one tier leave the below-OS plane governed by ordinary application-admin controls while an unauthenticated bypass exists against it.",
+        "evidence": "Packet: 'an authentication-bypass-by-spoofing flaw (CWE-290) in the AMI MegaRAC SPx baseboard management controller (Redfish), letting an unauthenticated attacker gain administrative control of the BMC — and thus the host beneath the operating system.' cisa_kev true (kev_date 2025-06-25), active_exploitation confirmed, RWEP 77, CVSS 9.1, poc_available true.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIST-800-53-AC-6",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "KEV listing on 2025-06-25 with confirmed exploitation starts the clock, but BMC remediation does not behave like an OS patch. live_patch_available is false and the packet notes the fix typically requires a service restart or system reboot, which on a baseboard management controller means a firmware update plus a controller restart scheduled against production servers — a per-host window most fleets cannot complete in four hours. The SLA therefore has to be met through this control's compensating-control branch: immediately remove every path from an untrusted network to the Redfish/BMC interface, record that isolation as the deployed mitigation, and track the firmware update as the follow-on action per server. An SLA measured only by firmware-deployed dates leaves a confirmed-exploited, credential-free interface reachable for the entire staging period and still reports as within tolerance.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-06-25 and active_exploitation confirmed; RWEP 77, CVSS 9.1, 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.'",
+        "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": "Nothing done inside the operating system evicts a BMC compromise — the packet places the attacker's control beneath the OS, so OS reinstall and disk replacement leave it untouched. For any MegaRAC SPx instance whose Redfish interface was reachable while the spoofing bypass was unpatched, the playbook must cover re-flashing and verifying BMC firmware rather than accepting an in-place update as remediation, auditing BMC user accounts and configuration for changes since the exposure window opened, rotating every credential the BMC stored and every credential that transited its console or virtual-media sessions, and rotating host-side credentials on the servers it fronted. This control's fleet-wide elements map directly: configuration audit since the suspected compromise window, and rotation for any account that authenticated through the compromised control-plane device. Without it, 'firmware updated' is recorded as closure on a plane an unauthenticated attacker held administrative rights over.",
+        "evidence": "Packet: CWE-290 authentication bypass by spoofing in the AMI MegaRAC SPx Redfish Host Interface giving an unauthenticated attacker administrative control of the BMC 'and thus the host beneath the operating system'; active_exploitation confirmed, cisa_kev true (kev_date 2025-06-25), poc_available true, CVSS 9.1.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-0386": {
     "name": "Linux Kernel Improper Ownership Management Vulnerability",
@@ -24761,7 +25661,32 @@
     },
     "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 code is V8, and the packet's own vendor description says the flaw reaches every Chromium-derived browser, not just Chrome. So the no-deferral update ring has to be scoped to the whole Chromium-derived population in the estate — Chrome, Edge and Opera are named in the packet — rather than to the single browser the organization designates as corporate standard. An update ring that fast-tracks the primary browser while leaving a second Chromium build unmanaged or pinned keeps the same out-of-bounds read/write reachable from any attacker-controlled page. Compliance also has to be measured on the running build: the packet records no live-patch path and notes the vendor fix typically requires a service restart or system reboot, so a host that has staged or installed the update but not restarted the browser is still exposed and must not count as remediated.",
+        "evidence": "Packet: name 'Google Chromium V8 Out-of-Bounds Read and Write Vulnerability'; cwe_refs CWE-125 and CWE-787; vendor description states the vulnerability 'could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera'; attack_vector describes exploitation 'by an attacker-controlled web page for code execution in the renderer'; 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.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a CVSS-band trigger fails outright: the packet's CVSS is 5.5, below the high/critical cut most vulnerability-management programs use to authorize an out-of-band browser push, while the packet's RWEP is 77 because CISA listed the CVE as exploited on 2025-06-05, exploitation is confirmed in the wild, and a PoC is public. Left to a severity-ranked queue, a renderer code-execution bug in V8 sits in the routine monthly browser ring behind higher-scoring server CVEs. The clock for Chromium-derived browsers must start at the KEV listing or patch availability, whichever is later, and the packet confirms a vendor patch exists — so there is no waiting state here, only a deployment decision.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-06-05, active_exploitation confirmed, rwep_score 77, cvss 5.5, poc_available true, patch_available true; attack_vector notes 'browser zero-days of this class are typically used in targeted-spyware or watering-hole chains'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-21479": {
     "name": "Qualcomm Multiple Chipsets Incorrect Authorization Vulnerability",
@@ -24819,7 +25744,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "An operator cannot remediate this flaw in place — the incorrect-authorization defect is in the Qualcomm chipset's GPU driver, so it closes only when the handset is running a build that carries the vendor fix. The enforcing control is therefore a minimum device security-patch level as a condition of access to organizational data, not as a reported attribute: the MDM/EMM must read each enrolled device's patch level, block or quarantine devices below the level carrying the Qualcomm fix, and — because the unauthorized GPU command sequence has to be issued by code already running on the device — constrain side-loaded and untrusted app installation on devices that cannot yet update. The distinguishing test: enroll a device pinned below the fixing patch level and confirm policy denies it access to protected resources; if the only outcome is a stale-patch-level row on a dashboard, the estate is attesting patch management it is not enforcing.",
         "evidence": "Packet: incorrect authorization (CWE-863) in the Qualcomm Adreno GPU driver across multiple Qualcomm chipsets, allowing unauthorized GPU command execution in the GPU micronode while executing a specific sequence of commands, corrupting memory to escalate privilege; exploited in the wild in Android targeted chains. patch_available true, live_patch_available false, and live_patch_notes records that no live-patch tool is registered and the vendor patch typically requires service restart or system reboot per the KEV requiredAction — remediation lands only when the device itself updates and restarts. RWEP 77, CVSS 8.8, poc_available true.",
@@ -24905,7 +25830,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "A Qualcomm chipset fix reaches a handset only once the OEM folds it into a device security-patch level, so the enforcement point available to the operator is the MDM/EMM, not the software. Managed Android fleets must read the device security-patch level and deny or quarantine handsets below the level carrying this Adreno GPU-driver fix — as a condition of access to organizational data, not as a dashboard metric — and must block untrusted/side-loaded app installation on handsets that cannot yet update. The blocking half is load-bearing here specifically because the unauthorized GPU-micronode command sequence is issued by code already executing on the device: constraining what runs on an unpatched handset is the only thing standing between the KEV listing and the OEM rollout. A fleet whose mobile-patching attestation reports patch levels without gating on them leaves every stale handset exploitable in production.",
         "evidence": "Packet: incorrect-authorization flaw (CWE-863) in the Qualcomm Adreno GPU driver allowing unauthorized GPU command execution that corrupts memory to escalate privilege; the vector records memory corruption 'due to unauthorized command execution in GPU micronode while executing specific sequence of commands'. CISA KEV-listed 2025-06-03, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 77. patch_available is true, but live_patch_available is false and live_patch_notes records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction — there is no in-place fix, so handsets stay exploitable across the whole update-and-reboot window.",
@@ -26002,7 +26927,20 @@
     },
     "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 vulnerable component here is a Windows OS component driven by attacker-controlled web/script content delivered as a crafted URL, so exposure is estate-wide across every Windows endpoint that renders one — there is no single service to isolate and no interface to restrict as an interim measure, which removes the compensating-control branch this SLA normally allows. The packet records no registered live-patch tool and a vendor fix that requires a service restart or system reboot per the KEV requiredAction, and that makes the load-bearing detail the terminus of the clock rather than its length: the KEV-tied remediation window must end at reboot-completed on each endpoint, because until the restart happens the scripting engine resident in memory is still the vulnerable one. The distinguishing test: sample endpoints the patch console reports as compliant and confirm each has actually restarted since the update was staged — a fleet reporting full deployment while carrying pending-reboot endpoints past the KEV due date has recorded compliance, not removed the exposure.",
+        "evidence": "Packet records cisa_kev true with kev_date 2025-05-13, active_exploitation confirmed, poc_available true, CVSS 8.8 and RWEP 77. patch_available is true, live_patch_available is false, and live_patch_notes state that 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. The vector records a type confusion (CWE-843) in the Windows Scripting Engine allowing an unauthorized attacker to execute code over a network via a specially crafted URL, exploitable by attacker-controlled web/script content for code execution in the client.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-32706": {
     "name": "Microsoft Windows Common Log File System (CLFS) Driver Heap-Based Buffer Overflow Vulnerability",
@@ -27244,7 +28182,40 @@
     },
     "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": "This CVE is the case that proves the patch SLA tier must key off the device's position in the topology, not off the vendor's initial severity call. Ivanti shipped the fix in 22.7R2.6 on 2025-02-11 assessed as a low-risk denial of service; fleets that fed that rating into a standard risk-ranked patch queue deferred it and were then exploited from mid-March once the same stack overflow was weaponized into unauthenticated RCE. A Connect Secure / Policy Secure / ZTA gateway is the trust boundary, so any fix touching its pre-authentication web surface has to be deployed on the perimeter tier's clock — or that interface isolated until it is — regardless of the CVSS or the vendor's stated impact at disclosure. The operational rule this yields: on an edge gateway, a pre-auth memory-corruption fix is a perimeter-tier item on the day it ships, and a later re-rating never arrives in time to help.",
+        "evidence": "Packet attack_vector: \"Unauthenticated stack-based buffer overflow in Ivanti Connect Secure initially assessed as a low-risk DoS and patched in 22.7R2.6 (2025-02-11), then weaponized to RCE and exploited in the wild from mid-March 2025 ... Fleets that deprioritized the fix on the basis of its initial DoS rating were exploited after the patch shipped.\" CWE-121/CWE-787, CVSS 9.0, RWEP 83, KEV-listed 2025-04-04 with confirmed in-the-wild exploitation, PoC available.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For any Connect Secure / Policy Secure / ZTA gateway that was reachable during the exploitation window, the default response is not the firmware upgrade. The packet names TRAILBLAZE as an in-memory dropper and BRUSHFIRE as a passive backdoor — a passive implant waits for attacker-supplied traffic rather than beaconing out, so egress monitoring produces nothing to alert on, and an in-memory stage leaves the on-disk integrity check clean. The runbook therefore has to be: pull the configuration off-box, factory-reset and rebuild the appliance to a known-good image, then rotate every credential, session token and certificate that transited the device, treating a passing integrity check as non-exculpatory. The cost argument that normally favors patch-in-place does not hold here: the firmware upgrade already requires a reboot and there is no live-patch path, so the appliance is going down either way.",
+        "evidence": "Packet vector: \"Patch-in-place insufficient on compromised devices; factory reset required where indicators are present.\" live_patch_notes: \"Appliance firmware upgrade requires reboot; no live patch. Rebuild required on compromise indicators.\" attack_vector names \"the TRAILBLAZE in-memory dropper and BRUSHFIRE passive backdoor\" used in exploitation from mid-March 2025. live_patch_available is false.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet attributes in-the-wild exploitation of this CVE to the named cluster UNC5221 operating purpose-built appliance tooling. An IR queue that classifies a VPN-appliance alert as commodity malware will scope the incident to the appliance and close it once the firmware upgrade lands; what this CVE requires instead is an escalation path triggered by the attribution plus custom-implant tooling, which widens scope to everything reachable from the gateway's trust position — terminated VPN sessions, the directory credentials that authenticated through it, and the internal segments it fronts. The ICT risk-management framework has to name that trigger in advance rather than leaving the scoping decision to whichever analyst picks up the appliance alert, because the standard commodity-infection path under-scopes a dedicated actor with a passive backdoor already resident.",
+        "evidence": "Packet attack_vector: \"weaponized to RCE and exploited in the wild from mid-March 2025 by UNC5221 using the TRAILBLAZE in-memory dropper and BRUSHFIRE passive backdoor.\" active_exploitation is confirmed; RWEP 83; CVSS 9.0; KEV-listed 2025-04-04.",
+        "gap_closes": [
+          "DORA-Art-9"
+        ]
+      }
+    ]
   },
   "CVE-2025-31324": {
     "name": "SAP NetWeaver Visual Composer Metadata Uploader unauthenticated file-upload RCE",
@@ -27314,7 +28285,32 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The Visual Composer Metadata Uploader is a development/management function of the NetWeaver application server, and the packet shows it accepting an unauthenticated POST to /developmentserver/metadatauploader with no authorization check at all — so the control has to bind at the endpoint, not at the SAP logon. Every development-server and Visual Composer function on the NetWeaver stack must authorize the caller before the upload handler runs, and the /developmentserver/* surface must be segmented so an untrusted network caller cannot reach it in the first place. Role and authorization-object review over SAP user accounts is beside the point on this path: the attacker never holds an SAP account, and the uploaded JSP executes with the SAP service account's privileges rather than any user's, so the blast radius is the service identity and everything it can reach, not the rights of some compromised dialog user. The distinguishing test for this product: from an untrusted network segment, POST a file to /developmentserver/metadatauploader on a staging NetWeaver instance and confirm it is refused before anything is written into a directory the application server serves — an estate that passes SAP role-and-authorization audits while leaving that endpoint network-reachable is still exposed to the unauthenticated upload path.",
+        "evidence": "The packet's vector records an unauthenticated POST to /developmentserver/metadatauploader that uploads an executable binary / JSP webshell which the application server then serves and executes, yielding RCE as the SAP service account; the attack_vector states the endpoint lacks an authorization check. CVSS 10, RWEP 78, CISA KEV-listed 2025-04-29, active_exploitation confirmed, poc_available true. The citing gaps include DORA-Art-9 (ICT risk management framework), UK-CAF-B4 (system security) and NIS2-Art21-network-security (security of network and information systems) — protection-and-prevention controls that carry no requirement for an application server's development or upload endpoints to authenticate the caller before the function runs.",
+        "gap_closes": [
+          "DORA-Art-9",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For this SAP flaw the artifact left behind is a JSP webshell already written into a directory the NetWeaver application server serves and executes, so applying the Visual Composer fix closes the upload path and removes nothing that came through it. Any instance that was reachable at /developmentserver/metadatauploader during the mass-exploitation window has to be triaged as compromised rather than patched and closed: hunt the served and deployment directories for files that do not correspond to a sanctioned deployment, rotate the SAP service account and every credential recoverable from the host, and rebuild rather than clean where a webshell is found. The packet records hands-on-keyboard follow-on including ransomware staging behind this access and frequent chaining with the NetWeaver deserialization flaw CVE-2025-42999, which means an operator whose entire response is the vendor update may be closing the door behind an actor already inside, and may leave the second flaw's path open as well. The distinguishing test: on an instance already updated, enumerate the served directory tree against a known-good deployment manifest — a patch-compliance record showing the fix applied is not evidence that nothing was written before it landed.",
+        "evidence": "The packet's vector states the uploaded executable binary / JSP webshell is served and executed by the application server itself. Its attack_vector records mass exploitation from April 2025, webshell access leading to hands-on-keyboard follow-on including ransomware staging, and frequent chaining with CVE-2025-42999. patch_available is true and live_patch_available is false with no live-patch notes recorded, so the remediation on offer is a vendor update — an action that cannot remove a webshell already written to disk. CISA KEV-listed 2025-04-29, active_exploitation confirmed, poc_available true, CVSS 10, RWEP 78. The citing gaps ISO-27001-2022-A.8.8, NIST-800-53-SI-2, PCI-DSS-4.0-6.3.3 and AU-ISM-1546 are all patch-installation controls whose satisfied state is 'update applied'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "PCI-DSS-4.0-6.3.3",
+          "AU-ISM-1546"
+        ]
+      }
+    ]
   },
   "CVE-2025-31161": {
     "name": "CrushFTP HTTP authorization-header authentication bypass (crushadmin takeover)",
@@ -28080,7 +29076,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "Remediation here is not a package version. The packet states the fix is 8.18.0.2 plus setting the 'o' flag in srv_features, and live_patch_notes confirms remediation is a software update and, for the smuggling class, a server configuration change (service restart, not host reboot). That makes the configuration-side path a first-class deliverable rather than an optional hardening note: the srv_features setting has to be inventoried per Sendmail instance, deployed and tested independently of the package upgrade, and verified behaviourally — send the non-standard <LF>.<CR><LF> sequence to a staging listener and confirm it is not accepted as end-of-data. Without that inventory an operator who installs 8.18.0.2 and never sets the flag passes every version-based check while the smuggling path stays open, because the version string and the actual protective state are decoupled for this CVE.",
+        "evidence": "Packet vector: 'Sendmail accepts <LF>.<CR><LF> as end-of-data where other MTAs require <CR><LF>.<CR><LF>, letting an attacker smuggle a second message that inherits the outer envelope's sender-authentication pass and spoof the sender. Fix: 8.18.0.2 and set the \"o\" flag in srv_features.' 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.' cisa_kev false, active_exploitation suspected, RWEP 29, CVSS 5.3, poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "PCI-DSS-4.0-6.3.3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "The mechanism that fails here is sender authentication itself: the packet describes a smuggled second message inheriting the outer envelope's SPF/DKIM/DMARC pass, so the receiving side records an authenticated verdict for a message that was never authenticated. Because the defect is a divergence between MTA implementations of the end-of-data sequence rather than a single product bug, one vendor's fix does not retire the class — the perimeter MTA, any relay behind it, and the mail gateway each need a class-level regression battery covering the known end-of-data variants (including the <LF>.<CR><LF> form this CVE turns on), executed after every MTA update and configuration change rather than once at remediation time. The keeper test is behavioural, not version-based: submit a smuggling probe through the perimeter MTA and assert the inner message does not arrive carrying a pass verdict. Attesting 'DMARC enforced' proves the policy is published, not that the verdict binds to the message that was delivered.",
+        "evidence": "Packet name: 'Sendmail SMTP smuggling (non-standard end-of-data sequence enables sender spoofing past SPF/DKIM/DMARC)'; cwe_refs CWE-345 and CWE-93; attack_vector: 'SMTP smuggling: the MTA accepts a non-standard end-of-data sequence, letting an attacker smuggle a second message that inherits the outer connection's SPF/DKIM/DMARC pass and delivers a spoofed sender. Disclosed Dec 2023 (SEC Consult).' poc_available true, active_exploitation suspected.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2023-51766": {
     "name": "Exim SMTP smuggling (non-standard end-of-data sequence enables sender spoofing past SPF/DKIM/DMARC)",
@@ -28602,7 +29621,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "id": "NEW-CTRL-130",
         "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
         "description": "Container hosts must treat the kernel - not the namespace boundary - as the last line of defense against a confined workload. Patch host kernels to the fixed release for each maintained series (with reboot) or apply a vendor live-kernel-patch, and layer compensating controls that block cgroups/namespace escapes even on an unpatched kernel: confine every container with AppArmor or SELinux and a seccomp profile, drop CAP_SYS_ADMIN, and disable unprivileged user namespaces where workloads do not need them. The distinguishing test: from inside a representative container on a staging host, attempt the release_agent escape (create user+cgroup namespaces, mount cgroupfs, write a payload path to release_agent, trigger cgroup release) and confirm it is refused before any code runs as root - a fleet that passes image-scan and RBAC audits but permits this on an unpatched, unconfined host still allows container-to-host root.",
         "evidence": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af",
@@ -28652,7 +29671,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-EOL-DEVICE-RETIREMENT",
+        "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
         "description": "Every network-attached embedded device (IP cameras, video servers, NVRs, routers, print/scan appliances) must carry an end-of-support date in the asset inventory, and any device past that date that exposes a remotely reachable management or media surface must be removed from untrusted networks and scheduled for replacement — patching is not an option once the vendor retires the model. The distinguishing test: query the asset inventory for devices whose firmware lifecycle has ended and whose management interface is reachable from an untrusted segment; any non-empty result that lacks a replace-or-formally-risk-accept decision is a finding. Paper patch-management policies that assume a fix always exists leave actively-exploited EOL devices (GeoVision IP cameras, recruited by Mirai-style botnets) on the network indefinitely.",
         "evidence": "https://www.akamai.com/blog/security-research/active-exploitation-mirai-geovision-iot-botnet",
@@ -28702,7 +29721,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "id": "NEW-CTRL-128",
         "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
         "description": "Application servers that expose binary remoting protocols (Oracle WebLogic T3/IIOP, and equivalents) must restrict those protocols to trusted hosts and apply vendor critical patch updates on an accelerated schedule when a remoting flaw is KEV-listed. Place T3/IIOP behind a connection filter (weblogic.security.net.ConnectionFilterImpl) or network ACLs so only known hosts can reach them, never expose the ports to untrusted networks, and apply the Oracle CPU bundle (with server restart) rather than deferring to the next quarterly window. The distinguishing test: from an untrusted network segment, attempt an unauthenticated T3/IIOP connection to a staging WebLogic instance and confirm it is refused at the connection filter before any data is served - a perimeter-firewall + quarterly-patch policy that still leaves T3/IIOP reachable from an internal untrusted segment leaves the unauthenticated data-access path open.",
         "evidence": "https://www.oracle.com/security-alerts/cpujul2024.html",
@@ -28752,7 +29771,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-EOL-DEVICE-RETIREMENT",
+        "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
         "description": "Every network-attached embedded device (IP cameras, video servers, NVRs, LPR units, routers, print/scan appliances) must carry an end-of-support date in the asset inventory, and any device past that date that exposes a remotely reachable management or media surface must be removed from untrusted networks and scheduled for replacement — patching is not an option once the vendor retires the model. The distinguishing test: query the asset inventory for devices whose firmware lifecycle has ended and whose management interface is reachable from an untrusted segment; any non-empty result that lacks a replace-or-formally-risk-accept decision is a finding. Paper patch-management policies that assume a fix always exists leave actively-exploited EOL devices (a broad GeoVision fleet, recruited by Mirai-style botnets) on the network indefinitely.",
         "evidence": "https://www.akamai.com/blog/security-research/active-exploitation-mirai-geovision-iot-botnet",
@@ -28822,7 +29841,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-105",
+        "id": "NEW-CTRL-144",
         "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
         "description": "An organization must inventory every place a high-risk embedded media-parsing library (FreeType, image/codec/font/document parsers) is statically or dynamically bundled - including copies vendored inside individual applications - and apply the security update to all of them, not only the OS-level package. The distinguishing test: after applying the OS FreeType update, scan the application estate for binaries that bundle their own FreeType copy and confirm each reports the fixed version - a paper patch-management policy that closes the OS package while leaving an application's vendored copy at <= 2.13.0 still permits the crafted-font out-of-bounds write.",
         "evidence": "https://www.facebook.com/security/advisories/cve-2025-27363",
@@ -28892,7 +29911,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-106",
+        "id": "NEW-CTRL-145",
         "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
         "description": "When an OS vendor flags a local-privilege-escalation flaw as exploited in the wild (and it is KEV-listed), the monthly cumulative update that fixes it must be applied and rebooted across the entire affected endpoint fleet within the KEV remediation window, not on the normal patch cadence, and account-privilege policy must not be relied on to contain it. The distinguishing test: enumerate the fleet's installed build numbers against the fixed build for each SKU and confirm zero endpoints remain below it past the due date - a paper patch-management policy that ships monthly rollups on a 30-day cadence still leaves an actively-exploited LPE open during the window the vendor flagged it as exploited.",
         "evidence": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-30400",
@@ -28942,7 +29961,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-MESSAGING-E2E-CLAIM-VERIFICATION",
+        "id": "NEW-CTRL-138",
         "name": "VERIFY-MESSAGING-BACKEND-DATA-HANDLING-AGAINST-E2E-CLAIM",
         "description": "Do not accept a messaging or archiving product's end-to-end-encryption claim from documentation alone. Before trusting a vendor backend with sensitive communications, require evidence that the archive holds no recoverable cleartext - independent cryptographic review, a documented key-custody model that excludes the vendor, or contractual/technical proof that the backend cannot read message contents. The distinguishing test: ask the vendor (or test in a controlled deployment) whether the archiving backend can produce the plaintext of a stored message without the endpoint's keys; if it can, the 'end-to-end' claim does not hold and the backend is a cleartext-exposure surface regardless of marketing. A product that passes a paper controls audit on the strength of its E2E datasheet still exposes plaintext if its backend silently retains it.",
         "evidence": "https://nvd.nist.gov/vuln/detail/CVE-2025-47729",
@@ -28991,7 +30010,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "https://source.android.com/docs/security/bulletin/2026/2026-06-01",
@@ -29041,7 +30060,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-PERIMETER-VPN-AUTH-BYPASS-EXPEDITED-PATCH",
+        "id": "NEW-CTRL-131",
         "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
         "description": "A remote-access VPN gateway (GlobalProtect, IKEv1/IKEv2 concentrators, SSL-VPN portals) is itself the authentication enforcement point for the network perimeter; an authentication-bypass flaw on that device must be remediated on a KEV-tied expedited clock, not the routine appliance-patch window. Require: enumerate every internet-facing VPN/portal authentication surface, subscribe to the vendor's advisory feed, apply vendor interim mitigations within hours of a confirmed-exploited auth bypass, and restrict gateway exposure to known client networks where feasible. The distinguishing test: on a staging gateway running the vulnerable release, send an unauthenticated request to the portal/gateway and confirm no VPN session or interior reachability is granted before authentication completes — paper 'VPN authentication enforced' policies do not detect a pre-credential bypass that grants an interior foothold.",
         "evidence": "https://security.paloaltonetworks.com/CVE-2026-0257",
@@ -29089,7 +30108,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-MDM-GATEWAY-UNAUTH-CONFIG-ENDPOINT-NEUTRALIZE-AND-CONTAIN",
+        "id": "NEW-CTRL-134",
         "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
         "description": "A device-management / MDM gateway (Ivanti Sentry, MobileIron, and similar) is a privileged root-execution surface at the network perimeter; every config/message endpoint must authenticate the caller and must neutralize OS-command input before any shell or process invocation, and the appliance must never be left unmanaged with externally reachable endpoints. Require: inventory all gateway HTTP endpoints, ensure they are managed (mTLS with the management server or restricted HTTPS) so config interfaces are not externally reachable, neutralize OS-command metacharacters at every message handler, and remediate any confirmed-exploited unauthenticated root RCE on a KEV-tied expedited clock with mandatory forensic triage of exposed instances. The distinguishing test: send an unauthenticated request carrying an OS-command metacharacter payload to each gateway config endpoint on a staging instance and confirm it is refused before any command runs — paper 'appliance hardened' policies that leave an unmanaged instance's config endpoint wired to a root command sink still permit unauthenticated root RCE.",
         "evidence": "https://labs.watchtowr.com/more-evidence-that-words-dont-mean-what-we-thought-they-meant-ivanti-sentry-pre-auth-os-command-injection-cve-2026-10520/",
@@ -29238,7 +30257,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "MFT-REQUEST-ENCODING-RESOURCE-GUARD",
+        "id": "NEW-CTRL-136",
         "name": "FILE-TRANSFER-SERVICE-REQUEST-ENCODING-RESOURCE-GUARD",
         "description": "An internet-exposed managed file-transfer / FTP / HTTP file service (SolarWinds Serv-U and similar) must bound the resources consumed when decoding a request body and must reject malformed or abusive content encodings (oversized or malformed Content-Encoding: deflate / gzip payloads) before they reach the decode path, so that no single unauthenticated request can exhaust resources and crash the service. The distinguishing test: send an unauthenticated request with a malformed or pathological Content-Encoding: deflate body to a staging instance and confirm the request is rejected with bounded resource use and the service stays available - paper 'DoS protection' that relies only on network-layer rate limiting still permits an application-layer single-request crash.",
         "evidence": "https://www.solarwinds.com/trust-center/security-advisories/CVE-2026-28318",
@@ -29286,7 +30305,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "ERP-MGMT-PLANE-CRITICAL-FUNCTION-AUTH",
+        "id": "NEW-CTRL-129",
         "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
         "description": "An enterprise ERP platform (Oracle PeopleSoft, Oracle E-Business Suite, SAP, and similar) must authenticate every management-plane and environment-management function before it can be invoked, and must not expose any takeover-capable function to an unauthenticated network caller. Segment the ERP management surface from untrusted networks and place it behind authenticated access control. The distinguishing test: send an unauthenticated network request to each environment-management / configuration endpoint on a staging instance and confirm it is refused before any privileged action runs - paper 'ERP access control' policies that attest user-login authentication while leaving a critical management function reachable without credentials still permit unauthenticated takeover.",
         "evidence": "https://www.oracle.com/security-alerts/alert-cve-2026-35273.html",
@@ -29354,7 +30373,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-104",
+        "id": "NEW-CTRL-143",
         "name": "LLM-GATEWAY-MCP-EXECUTION-ENDPOINT-PRIVILEGE-PARITY",
         "description": "An LLM gateway/proxy (LiteLLM and similar) must enforce the same administrative privilege on every endpoint that can spawn a subprocess or reach a code-execution path from a supplied MCP server configuration - test-connection, list-tools, and save-config must share one privilege gate - and must not spawn a host subprocess from a request-supplied stdio transport config without sandboxing. The distinguishing test: call each MCP test endpoint on a staging instance with a low-privilege (non-admin) authenticated key and a server config whose command attempts a non-MCP host action, and confirm it is refused before any subprocess spawns - paper access-control policies that gate the save endpoint but leave the test endpoints open still permit an authenticated low-privilege key to run host commands.",
         "evidence": "https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g",
@@ -29404,7 +30423,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "ECOMMERCE-EXTENSION-DESERIALIZATION-GUARD",
+        "id": "NEW-CTRL-133",
         "name": "ECOMMERCE-PLATFORM-EXTENSION-UNTRUSTED-DESERIALIZATION-GUARD",
         "description": "An e-commerce platform (Magento / Adobe Commerce and similar) and every third-party extension it loads must never pass request-supplied data (cookies, headers, body, query parameters) to a native deserialization function (PHP unserialize(), and equivalents in other runtimes) on an unauthenticated storefront request path. Patch-management and secure-coding programs must enumerate every installed extension as part of the storefront's code-execution surface, not only the core platform. The distinguishing test: send an unauthenticated storefront request carrying a crafted serialized object in each cookie / header an extension reads, on a staging store, and confirm it is rejected before any deserialization runs - paper 'platform patched' attestations that ignore the installed extensions still permit unauthenticated RCE through an extension's object-injection sink.",
         "evidence": "https://sansec.io/research/mirasvit-cache-warmer-object-injection",
@@ -29452,7 +30471,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-CONTROLPANEL-PLUGIN-PRIVILEGE-SEPARATION",
+        "id": "NEW-CTRL-135",
         "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
         "description": "On a multi-tenant hosting control panel (cPanel/WHM and similar), no function reachable from the unprivileged user-end plugin surface may execute as root or run tenant-supplied scripts with host privileges. Privileged operations must live behind an administrative trust boundary with their own authorization, and the user-facing surface must only request them through a constrained, validated interface. The distinguishing test: from an ordinary tenant account on a staging panel, invoke each user-end plugin function (including enable/disable and configuration calls) with a payload that attempts a root-level action, and confirm the action is refused before any privileged code runs - a panel that passes an OS-hardening audit but wires a tenant-callable function to a root operation still grants user-to-root escalation.",
         "evidence": "https://blog.litespeedtech.com/2026/05/21/security-update-for-litespeed-cpanel-plugin/",
@@ -29500,7 +30519,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-DEPRECATED-VPN-PROTOCOL-DISABLE-AND-EXPEDITED-PATCH",
+        "id": "NEW-CTRL-137",
         "name": "DEPRECATED-VPN-KEY-EXCHANGE-DISABLE-AND-MACHINE-CERT-ENFORCEMENT",
         "description": "Deprecated VPN key-exchange protocols (IKEv1 and similar) left enabled on a perimeter gateway are a latent authentication-enforcement surface; a certificate-validation logic flaw there yields an unauthenticated remote-access foothold. Require: inventory every gateway's enabled key-exchange protocols, disable deprecated protocols (IKEv1) for remote access unless a documented legacy-client need exists, require a machine certificate for remote-access connections, and remediate any confirmed-exploited gateway auth bypass on a KEV-tied expedited clock with a reboot-required hotfix. The distinguishing test: on a staging gateway with IKEv1 remote access enabled, attempt a remote-access connection without a valid user password and confirm it is refused before any tunnel is established — paper 'VPN authentication enforced' policies do not detect a deprecated-protocol certificate-validation bypass that grants an interior foothold to a ransomware affiliate.",
         "evidence": "https://support.checkpoint.com/results/sk/sk185033",
@@ -29599,7 +30618,7 @@
     "ai_assist_factor": "none",
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-SUPPLYCHAIN-SIGNED-INSTALLER-INTEGRITY",
+        "id": "NEW-CTRL-132",
         "name": "INDEPENDENT-INTEGRITY-VERIFICATION-OF-SIGNED-VENDOR-INSTALLERS",
         "description": "Do not treat a valid code signature as proof of artifact integrity. For software installed from third-party vendors, verify distributed artifacts against an independent integrity source - published per-release hashes from a separate channel, reproducible-build attestation, or a behavioral baseline of the installed binaries - because a compromised vendor build/signing pipeline can ship validly signed malware (DAEMON Tools Lite, 2026). The distinguishing test: take a known-good and a suspect release of the same vendor binary, confirm both carry valid signatures, and verify that an independent integrity check (hash from a second channel, reproducible build, or behavioral diff) can still flag the substituted one - publisher-signature allowlisting alone passes both and so cannot detect a pipeline compromise.",
         "evidence": "https://blog.daemon-tools.cc/post/security-incident",
@@ -29940,7 +30959,41 @@
     },
     "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": "UniFi OS is the management gateway for the estate it fronts, and on this path the authentication decision itself is what fails: an nginx allowlist matches the raw, percent-encoded request URI while the backend routes on a separately decoded URI, so a caller with no credential reaches an authenticated backend route. Applied to this product the control has two halves. The vendor's half is that the route-authorization decision and the routing decision must be taken from the same normalized form of the URI, so a request the gateway believes matches the auth-exempt /api/auth/validate-sso/ entry cannot resolve to a different handler — that is why the packet's remediation is the vendor update. The operator's half is reachability and the sink: the package-update path the chain reaches passes an unsanitized package name to sh -c, so the UniFi OS management surface must answer only from an operator/management segment or an authenticated VPN, never from a general user VLAN and never published to the internet through a port forward or remote-access mapping. The distinguishing test: from a general user VLAN and from an external address, request the allowlisted /api/auth/validate-sso/ path in percent-encoded form and confirm the console does not answer at all — reachability is the entire precondition for an unauthenticated bypass, and 'the console is behind our firewall' is a claim about topology, not a demonstration that the surface is unreachable from untrusted segments. Because exploitation is confirmed, a console that was reachable before the update lands needs forensic review of what is installed on it rather than a patch-and-close.",
+        "evidence": "Packet vector: the UniFi OS nginx gateway compares a raw, percent-encoded request URI against its public-routes allowlist while the backend routing decision uses a separately decoded/normalized URI, so a request whose raw form matches the allowlisted, auth-exempt /api/auth/validate-sso/ entry normalizes to an authenticated backend route — an unauthenticated, network-reachable attacker defeats the access-control gate (CWE-284, CVSS 10, RWEP 79). The packet records the chain with CVE-2026-34909 (path traversal) and CVE-2026-34910 (an unsanitized package name passed to sh -c) yielding remote code execution; cisa_kev true with kev_date 2026-06-23, active_exploitation confirmed, poc_available true. live_patch_available is false and live_patch_notes state remediation is the vendor update plus the named compensating controls until it lands.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "What this flaw defeats is the console's own access-control gate — the allowlist that decides which routes answer without a credential — so the device is not an application sitting behind a trust boundary, it is the boundary. The packet gives a CVSS 10 unauthenticated path with a public PoC and confirmed exploitation, and records no live-patch path for this product class, which leaves an operator exactly the two branches this control names: take the UniFi OS update, accepting the service restart that the absence of a live-patch path implies, on a clock measured from the 2026-06-23 KEV listing; or isolate the management interface from every untrusted segment until the update lands. A 14- or 30-day operating-system patch SLA applied to a console whose bypass chains to full root through passwordless sudo to /usr/bin/dpkg is a cadence, not a remediation plan. The distinguishing test: enumerate every UniFi OS console in the estate against the fixed release and confirm none remains below it past the KEV due date, with any that do carrying an explicit interface-isolation record rather than a dashboard row.",
+        "evidence": "Packet records CVSS 10 with RWEP 79, cisa_kev true with kev_date 2026-06-23, active_exploitation confirmed, poc_available true, patch_available true, live_patch_available false, and live_patch_notes stating there is no live-patch path for this product class and that remediation is the vendor update plus the named compensating controls until it lands. The vector places the failure in the gateway's own access-control gate (raw percent-encoded URI matched against the public-routes allowlist versus a separately decoded/normalized backend URI) and records escalation to full root via the service's passwordless sudo to /usr/bin/dpkg.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The last step of this chain installs attacker-chosen content through the console's own package-update path: an unsanitized package name reaching sh -c, then passwordless sudo to /usr/bin/dpkg running a malicious package maintainer script as root. A package installed that way — and anything its maintainer script wrote — is simply part of the console's filesystem afterward, and the UniFi OS update that fixes the URI-normalization mismatch removes none of it. So for any console that was reachable by an unauthenticated caller during the exposure window, with exploitation confirmed in the wild, the default disposition has to be configuration export, rebuild from a vendor image, and rotation of every credential the console held or brokered — not update-in-place followed by a green patch report. The distinguishing test: on a console suspected of exposure, compare the installed package set and dpkg maintainer scripts against a known-good build before the update is applied; an estate holding no such baseline cannot distinguish a patched console from a patched-and-still-owned one.",
+        "evidence": "Packet vector: chained with CVE-2026-34909 and CVE-2026-34910 (an unsanitized package name passed to sh -c) the access-control bypass yields remote code execution, and the service's passwordless sudo to /usr/bin/dpkg escalates to full root via a malicious package maintainer script. active_exploitation is confirmed, cisa_kev true with kev_date 2026-06-23, poc_available true. patch_available is true but live_patch_available is false, with live_patch_notes stating there is no live-patch path for this product class.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2026-20253": {
     "name": "Splunk Enterprise Missing Authentication for Critical Function Vulnerability",
@@ -30325,7 +31378,45 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "On an Apache-bundling remote-access appliance such as the SonicWall SMA100, deploying the vendor update for the mod_rewrite escaping flaw does not undo what the traversal already yielded. The packet records UNC6148 reading on-disk SQLite databases holding admin credentials and OTP seeds, then replaying those secrets to regain privileged access and install the OVERSTEP rootkit. Both outcomes survive an in-place update: the rootkit persists on the same filesystem, and the stolen OTP seeds keep authenticating against a fully patched appliance. Any SMA100 or other Apache-fronted edge device that was internet-reachable during the exposure window must therefore be handled as compromised-until-disproven -- export the configuration, rebuild the device onto the vendor-updated build rather than patching the running instance, and rotate every credential and OTP seed the appliance held plus everything those secrets authenticated to. A program that closes this CVE on 'update deployed' records a remediation the attacker has already outlived.",
+        "evidence": "Packet attack vector: 'UNC6148 used the unauthenticated traversal to read SQLite databases holding admin credentials and OTP seeds, then replayed those secrets to regain privileged access and install the OVERSTEP rootkit for persistence and data theft' -- 'regain' is the evidence that credential replay defeats a patch-only response. CISA KEV-listed 2025-05-01, active_exploitation confirmed; RWEP 76, CVSS 9.1, poc_available true. patch_available true but live_patch_available false, with the packet note 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands' -- the appliance takes a service-affecting update, and the pre-update exposure window cannot be closed retroactively.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The vulnerable code is Apache HTTP Server 2.4.59 or earlier, but the deployment that was exploited is the SonicWall SMA100 remote-access appliance that bundles it -- the device that is itself the network trust boundary. Operators typically run two different clocks for these: a web-server patch SLA and a much slower appliance-firmware SLA. This CVE requires both to collapse into a perimeter tier: within hours of the KEV listing, either the vendor appliance update is deployed or the vulnerable HTTP interface is removed from untrusted networks. Because the packet records no live-patch path for this product class, taking the rewrite-serving interface off the internet is the only action available while the update is pending, and a standard 14- or 30-day window is not a defensible SLA for an unauthenticated traversal that reads the appliance's own credential store.",
+        "evidence": "Packet vector: 'mod_rewrite is reachable on any internet-facing Apache HTTP Server 2.4.59 or earlier whose configuration uses a server-context RewriteRule where the substitution's first segment is a backreference or variable', and 'In the SonicWall SMA100 deployment that bundles Apache, UNC6148 used the unauthenticated traversal' to reach on-disk secrets. CISA KEV-listed 2025-05-01 with confirmed in-the-wild exploitation; CVSS 9.1, RWEP 76, poc_available true. patch_available true, live_patch_available false; packet 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",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "The packet states reachability precisely: the flaw is exploitable where a server-context RewriteRule's substitution begins with a backreference or variable. That makes the rewrite ruleset itself a mitigation surface -- refactoring those substitutions so the first segment is a literal removes the attacker-steerable path without waiting for the Apache update, and it is deployable in minutes where the operator owns httpd.conf. This path must be inventoried and tested in advance, not improvised after a KEV listing, because the packet records no live-patch option for this product class. The inventory must also record where the path does NOT exist: on an appliance like the SMA100, the bundled Apache configuration belongs to the vendor, so those instances have no configuration-side mitigation and fall back entirely to the vendor update or interface isolation -- a distinction the operator needs written down before the incident, not discovered during it.",
+        "evidence": "Packet vector names the exact triggering configuration: 'a server-context RewriteRule where the substitution's first segment is a backreference or variable. Because the substituted output is improperly escaped, attacker-controlled request input can steer the post-rewrite target to a filesystem location the server is permitted to serve.' The packet also identifies the affected deployment as one 'that bundles Apache' (SonicWall SMA100). live_patch_available false with the packet note that remediation is the vendor update plus the named compensating controls until it lands; KEV-listed 2025-05-01, confirmed exploitation, poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-44221": {
     "name": "SonicWall SMA100 Appliances OS Command Injection Vulnerability",
@@ -30490,7 +31581,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": "Active! Mail's web front end is internet-facing and parses incoming HTTP requests prior to authentication, and the packet records the successful outcome as arbitrary code execution in the context of the web service on the mail server. It also records what attackers did with that foothold: reached hosted mailboxes and harvested stored credentials, including cloud-admin credentials at affected providers. Both facts point the same way — installing the vendor update on an instance that was reachable during the exploitation window closes the overflow and does nothing about credentials already taken or anything left running on the host. So for this product the default response to a confirmed-exploited instance is to preserve and export the configuration, rebuild the mail host rather than patch it in place, and rotate every credential the server stored or could reach: mailbox credentials first, then the provider and cloud-admin credentials the packet names, because those are the ones whose blast radius extends past the mail server into the hosting environment. Service crashes deserve the same treatment as a signal: the packet ties the denial-of-service outcome to a failed-control attempt at the same overflow, so a crash on an internet-facing Active! Mail instance is a reason to hunt, not a stability ticket to close.",
+        "evidence": "CWE-121 stack-based buffer overflow reachable pre-authentication on an internet-facing webmail front end; the packet describes an over-length field overflowing a fixed-size stack buffer and overwriting the saved return address, yielding arbitrary code execution in the context of the web service on the mail server, or a service crash for denial of service on failed control. The packet further states that 'in observed incidents the foothold was used to reach hosted mailboxes and harvest stored credentials (including cloud-admin credentials at affected providers)'. CISA KEV-listed 2025-04-28, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 68.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives a vendor update and no live-patch path for this product class, stating that remediation is the vendor update plus the named compensating controls until it lands — so on Active! Mail there is nothing to apply without taking the webmail service down, and the compensating controls are the whole of the coverage in between. That interval is also the whole of the exposure, because there is no access-control lever to pull meanwhile: the front end must stay internet-reachable to serve users, it parses the attacker's request before authentication, and no user interaction is involved in reaching the vulnerable parser. Run the clock from the 2025-04-28 KEV listing through the restart of every affected instance, and count instances rather than hosts — the packet's own incident detail is about hosted mailboxes at providers, so an operator running the product for multiple tenants owes one completed clock per instance. The service interruption the update requires belongs inside the SLA, not as the reason to defer it into the next maintenance window.",
+        "evidence": "CISA KEV-listed 2025-04-28 with active_exploitation confirmed and poc_available true. patch_available true; live_patch_available false, with the packet stating there is no live-patch path for this product class and that remediation is the vendor update plus the named compensating controls until it lands. The packet describes the front end as internet-facing and parsing incoming HTTP requests prior to authentication, exploitable by a remote unauthenticated attacker. CVSS 9.8, RWEP 68.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-3928": {
     "name": "Commvault Web Server Unspecified Vulnerability",
@@ -30678,7 +31793,33 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The chain's entry point is a crafted media file arriving over iMessage or SMS and parsed automatically by CoreAudio's AudioConverterService -- the packet is explicit that no user interaction is involved. Between delivery and the update landing, no patch-cadence control protects the handset, and CVE-2025-31201's own contribution (an arbitrary read/write primitive that defeats ARM Pointer Authentication) has no compensating control at all once code is running: it removes the platform's ROP/JOP mitigation from underneath everything above it. The only place an operator can intervene is the delivery path, before CoreAudio ever sees the media. Users the organization assesses as targets for this class of attack must therefore run in a reduced-attack-surface mode such as Lockdown Mode as a standing posture, not as a post-disclosure reaction, because it suppresses automatic processing of untrusted message attachments and previews that the exploit depends on for zero-click reachability.",
+        "evidence": "Packet attack vector: 'Reachability is network-based and zero-click: a maliciously crafted media file delivered over iMessage/SMS is processed by CoreAudio's AudioConverterService (CVE-2025-31200), yielding initial code execution without user interaction'; 'CVE-2025-31201 then supplies an arbitrary read/write primitive that defeats ARM Pointer Authentication (RPAC), neutralizing Apple's primary ROP/JOP control-flow mitigation'; 'The two CVEs are exploited together as one chain against specifically targeted individuals.' CISA KEV-listed 2025-04-17, active_exploitation confirmed; CVSS 9.8, RWEP 81, poc_available true. live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "A vendor update exists for this entry and there is no live-patch path, so the update is the remediation -- but on an Apple estate the update only matters when the handset actually installs it, and iOS/iPadOS updates are user-deferrable by default. Because CVE-2025-31201 is the mitigation-bypass half of a chain whose first half executes with no user action at all, every day a user postpones the release is a day that handset is fully exploitable over an inbound message. Managed iPhones, iPads and Macs must be pushed the KEV-fixing release through MDM declarative device management on a KEV-tied clock with user deferral disallowed, and any enrolled device that has not reported the fixed build must be raised as a tracked exception rather than left to its own update prompt. Reporting patch level without enforcing it is exactly the paper-compliance state this CVE punishes.",
+        "evidence": "Packet fields: 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.' CISA KEV-listed 2025-04-17 with confirmed in-the-wild exploitation; RWEP 81 against CVSS 9.8. Entry name 'Apple Multiple Products Arbitrary Read and Write Vulnerability' establishes multi-product estate scope; the packet's attack vector establishes the zero-click, no-user-interaction delivery that makes a deferred update an open door.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-31200": {
     "name": "Apple Multiple Products Memory Corruption Vulnerability",
@@ -30843,7 +31984,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The packet states the snd-usb-audio driver is bound by the kernel automatically when a USB audio device enumerates, which means the vulnerable descriptor-parsing code runs on any host with a physically reachable USB port whether or not that host has any audio-peripheral role. For this CVE the control means enumerating which systems actually need USB audio-class support and removing the driver from the reachable surface on the ones that do not — kiosks, servers, rack-mounted and unattended endpoints, and any device whose threat model includes an attacker with physical access to the port. The mechanism depends on how the kernel was built, and getting that wrong is how this control gets recorded as a mitigation while the parse path stays reachable: a modprobe blacklist only stops an autoload, so it applies where snd-usb-audio is a module, and does nothing on a kernel compiled with CONFIG_SND_USB_AUDIO=y, where the driver is built in and binds regardless. Determine which build a host is running before claiming the control — the driver is built in if it appears in /lib/modules/<release>/modules.builtin, and modular if modinfo resolves it. Where it is built in, the equivalent controls are USB device authorization (deny-by-default on the USB bus, allowlisting the peripherals a host is meant to accept) or a kernel built without the driver; a blacklist entry on such a host is not a compensating control and the host stays unremediated until it reboots onto the fixed kernel. The distinguishing test is to attach a USB audio-class device to a supposedly remediated host and confirm the driver does not bind, rather than confirming the module is absent from the currently loaded set — a host whose loaded-module list looks clean at audit time will still bind the driver the moment a device is plugged in, and a built-in driver will bind no matter what the blacklist says.",
+        "evidence": "Packet vector: the ALSA USB-audio driver (snd-usb-audio) traverses clock-source, clock-multiplier and clock-selector descriptors of an attached USB audio device without validating each descriptor's bLength field, and reachability requires physical USB access plus 'the (low) privilege of the kernel auto-binding the audio driver on enumeration'. CWE-125, CVSS 7.1, RWEP 59, AV:L. 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",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-017",
+        "name": "BUG-FAMILY-MITIGATION-PERSISTENCE",
+        "description": "The packet does not describe one unchecked descriptor read; it describes the same missing bLength validation across three separate descriptor traversals in the same driver, which makes this a parse-site class rather than a point defect. For this CVE the control means whichever USB-audio surface removal the host required — modprobe blacklist on a modular build, USB device authorization on a built-in one — and any USB-peripheral restriction deployed alongside it, stays in force after the fixed kernel is installed and rebooted, for a stated soak period, instead of being reverted the moment the vulnerability scanner reports the host on a fixed build. A fix that hardens the three named traversals says nothing about the remaining descriptor-parsing paths the same driver walks on enumeration, and the packet's own primitive — reading past the end of an allocated descriptor buffer using an attacker-declared length — is a pattern, not a location. The distinguishing test is whether the change record for this CVE has a scheduled review date on removing the compensating control, or whether the blacklist was rolled back in the same maintenance action that applied the kernel; the second is the failure mode this control exists to prevent.",
+        "evidence": "Packet vector names three distinct descriptor types traversed without bLength validation in the same driver: clock-source, clock-multiplier and clock-selector descriptors of an attached USB audio device, where 'a malicious or bogus USB device can present a descriptor whose declared length is shorter than the structure the driver dereferences'. CWE-125 out-of-bounds read. live_patch_available false; remediation per live_patch_notes 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": "This entry is KEV-listed with confirmed exploitation, but the packet records no live-patch path for the product class, so the mitigation the SLA clock demands cannot be a hot fix — it is either the vendor kernel update with a reboot, or the documented compensating control, and on a fleet that cannot reboot inside the window it is the compensating control by default. For this CVE the SLA therefore has to be written so that a verified USB-audio surface removal counts as the mitigation for hosts still awaiting a reboot — a modprobe blacklist where the driver is modular, or USB device authorization where it is built into the kernel and a blacklist would do nothing, with the reboot tracked as a separate open item rather than the clock being paused until a maintenance window appears. The distinguishing test is whether the KEV response record for this CVE names a mitigation state for every affected host at the deadline — updated-and-rebooted, or compensating-control-verified — or whether hosts pending reboot are simply absent from the record; an SLA that only counts completed kernel updates will report a clean deadline while the descriptor-parse path stays reachable on every host that has not yet restarted.",
+        "evidence": "cisa_kev true, kev_date 2025-04-09, active_exploitation 'confirmed'. RWEP 59, CVSS 7.1. 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.' poc_available is false, so the confirmed-exploitation signal here comes from the KEV listing rather than from published exploit code.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-53197": {
     "name": "Linux Kernel Out-of-Bounds Access Vulnerability",
@@ -31118,7 +32293,41 @@
     },
     "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": "Cisco Smart Licensing Utility ships an undocumented static administrative account whose credential is compiled into the binary, so the secret an attacker needs is a property of the product, identical on every install, and not something the operator provisioned or can rotate. That inverts the usual form of this control: there is no per-instance key to make unique, so the deployment gate has to be presence-of-the-shipped-credential rather than uniqueness-of-the-operator's. For CSLU that means treating any host carrying an affected 2.0.0-2.2.0 build as holding a published administrative credential until the vendor update is applied, and verifying after the update that presenting the shipped Basic-auth credential to the CSLU REST API on TCP/8182 is refused rather than accepted. Re-run that check after any workstation or server rebuild, image restore or CSLU reinstall, since those are the operations that silently put an affected build back on a host that was previously remediated, and the utility carries no operator-visible account listing that would make the regression obvious. The distinguishing test is to authenticate against a staging instance with the shipped credential and confirm refusal — an estate that passes a password-policy and privileged-account-review audit still hands full administrative control of the CSLU API to any unauthenticated caller who can reach the port, because the account was never in the directory the audit examined.",
+        "evidence": "Packet vector: 'Cisco Smart Licensing Utility ships an undocumented static administrative account (CWE-798 / CWE-912) whose credentials (cslu-windows-client:Library4C$LU) are hardcoded in the binary', its REST API 'listens on TCP/8182' when running, and 'an unauthenticated, remote attacker who reaches the host over the network can present the static Basic-auth credentials to authenticate as administrator with no prior access', yielding 'full administrative control over the CSLU application API'. Affected range given as 2.0.0-2.2.0. CVSS 9.8, RWEP 70, poc_available true.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet records that CSLU only listens while actively invoked, which makes this vulnerability structurally invisible to the two techniques most estates rely on for evidence: a network scan of TCP/8182 finds the port closed whenever the utility happens not to be running, and a service inventory finds nothing listening to attribute a version to. For this CVE the operational test has to be installed-software inventory across the Windows estate — does any host carry a Smart Licensing Utility build in the 2.0.0-2.2.0 range, regardless of whether the service answered at scan time — because that, not port reachability, is the condition the packet ties exposure to. The distinguishing test is to scan a staging host with an affected CSLU installed but not currently invoked, and confirm the tooling still reports it as affected; a scanner that returns clean because nothing answered on 8182 has measured the sampling moment rather than the exposure, and every subsequent invocation of the utility reopens an unauthenticated administrative API with a credential published in the advisory.",
+        "evidence": "Packet vector: 'Because CSLU only listens while actively invoked, exposure is intermittent, but any reachable, running 2.0.0-2.2.0 instance is trivially compromisable', with the REST API on TCP/8182 reachable by an unauthenticated remote attacker while the service runs. cisa_kev true, kev_date 2025-03-31, active_exploitation 'confirmed'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "KEV listing on 2025-03-31 with confirmed exploitation, a public PoC and unauthenticated administrative access at CVSS 9.8 puts this above any routine patch cadence, and the packet gives no live-patch path, so the mitigation that satisfies the clock is either upgrading past the affected 2.0.0-2.2.0 range or removing/stopping the utility on hosts that do not need it. For this CVE the SLA should treat 'CSLU not installed' as a first-class satisfying outcome rather than only counting upgrades, because Smart Licensing Utility is a support tool rather than a production dependency on most of the hosts that carry it, and uninstalling is faster than scheduling a software update across a Windows estate. The distinguishing test is whether the KEV record for this CVE resolves every affected host to upgraded, uninstalled, or explicitly risk-accepted at the deadline; an SLA measured only on upgrade completion will show hosts as pending indefinitely while an unauthenticated caller with the published credential can take administrative control of the API the next time the utility runs.",
+        "evidence": "cisa_kev true, kev_date 2025-03-31, active_exploitation 'confirmed'. CVSS 9.8, RWEP 70, poc_available true. 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.' Packet vector states the attacker gains 'full administrative control over the CSLU application API', which is chained with CVE-2024-20440 to harvest further credentials and tokens.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-2783": {
     "name": "Google Chromium Mojo Sandbox Escape Vulnerability",
@@ -31860,7 +33069,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": "CVSS 4.6 puts this NTFS driver information-disclosure flaw below the escalation threshold of nearly every severity-ranked patch program: physical/local reachability, no code execution, no privilege escalation. Yet CISA listed it as exploited in the wild on 2025-03-11 and the packet scores it RWEP 57, and what leaks is heap memory that may carry cached credentials, tokens or keys. The clock that must govern the Windows fleet here is the KEV listing, not the CVSS band -- the vendor update carrying the NTFS driver fix has to be scheduled off the KEV date, and until it lands the documented compensating control this entry needs is refusing to mount untrusted NTFS volumes (attacker-supplied USB media and VHD images) on unpatched hosts, since that mount is the entire delivery mechanism. Deferring it as 'medium, next cycle' leaves an actively-exploited heap-disclosure primitive available to anyone who can attach a volume, in the same servicing window as the NTFS heap-overflow RCE CVE-2025-24993 that it pairs with.",
+        "evidence": "Packet: CISA KEV-listed 2025-03-11 with active_exploitation 'confirmed', against CVSS 4.6 and RWEP 57; poc_available false, so the confirmed exploitation is not explained away by a public exploit lowering the barrier. Attack vector: 'Reachability requires physical/local access (CVSS AV:P) -- the attacker mounts a crafted NTFS volume, typically via a malicious USB device or VHD image'; the flaw 'inserts sensitive in-memory data (portions of heap, potentially containing cached credentials, tokens, or keys) into NTFS log/metadata structures'; and 'it was shipped/exploited in the same window as the NTFS heap-overflow RCE CVE-2025-24993, making it a useful information-leak primitive in a physical-access chain.' 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"
+        ]
+      }
+    ]
   },
   "CVE-2025-24983": {
     "name": "Microsoft Windows Win32k Use-After-Free Vulnerability",
@@ -32080,7 +33303,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_disclosure",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Microsoft Management Console is a built-in Windows component, so the affected population is the entire managed Windows endpoint estate rather than a single service that can be stopped or firewalled while a fix is scheduled. The packet records a vendor update with live_patch_available false and no live-patch path for this product class, which means remediation is the update landing on each host, and the interval before it lands is carried by the compensating controls the packet's live_patch_notes points to. This control binds that deployment clock to the 2025-03-11 KEV listing rather than to the next scheduled endpoint-patch ring, so the estate must reach the fixed state (or run documented, expiring compensating controls) inside the window the packet records as closing 2025-04-01. The distinguishing test is to enumerate the fleet against the fixed state on the due date: a patch programme that ships this update on a monthly ring passes a process audit while every unremediated host carries an actively-exploited security-feature bypass for the remainder of that month, and the packet's RWEP of 82 against a CVSS of 7.0 is exactly the case a CVSS-ranked queue defers.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-03-11, attack_vector records the KEV due date as 2025-04-01, active_exploitation confirmed, poc_available true, rwep_score 82 against cvss 7.0, patch_available true, live_patch_available false, 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": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "What fails in this CVE is not a code-execution sink but a Windows security feature refusing to hold: the packet's vector is improper neutralization in Microsoft Management Console that lets an unauthorized attacker bypass a security feature locally (CWE-707). That makes build-number verification structurally unable to answer the operator's real question, because a host reports the same patch state whether the protection enforces or has been bypassed. The requirement here is to carry the MMC bypass primitive in the standing protection-mechanism regression battery alongside the MOTW/SmartScreen/AMSI-class primitives the control already governs, and to re-run that battery after each Windows update deployment on a representative build rather than once at remediation of this CVE. The distinguishing test for this product: on a host the scanner reports as fixed, exercise the bypass against the MMC surface and confirm the security feature blocks it. With a PoC available and exploitation confirmed, an estate that verifies patch level but never verifies enforcement cannot distinguish a re-enforced protection from a re-broken one.",
+        "evidence": "Packet: cwe_refs CWE-707, vector 'Improper neutralization in Microsoft Management Console allows an unauthorized attacker to bypass a security feature locally.', poc_available true, active_exploitation confirmed, cisa_kev true (2025-03-11), patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-13161": {
     "name": "Ivanti Endpoint Manager (EPM) Absolute Path Traversal Vulnerability (GetHashForSingleFile)",
@@ -32135,7 +33381,39 @@
     },
     "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 for the estate, and this flaw reaches sensitive information on it with no credential at all: the GetHashForSingleFile handler consumes a caller-supplied absolute path and returns what it finds, so the read completes before any authentication decision is made. Two requirements follow for this deployment. Every EPM handler that takes a caller-supplied path must authenticate the caller before it acts, and must resolve the supplied path to a canonical absolute form and verify the result still sits under the directory that handler is entitled to read — rejecting absolute paths and traversal segments before a file handle is opened, rather than filtering the request string on the way in. And no EPM instance may present those handlers to an untrusted network, because a remote unauthenticated attacker is the packet's threat model and reachability is the entire exploit precondition. The distinguishing test for this product: from an unauthenticated client against a staging EPM, call the file-hash handler with an absolute path outside its intended directory and confirm the request is refused before any file is read — an estate that passes EPM role-and-permission audits still exposes this path, since the attacker never reaches the role model. Because exploitation is confirmed and a public PoC exists, an instance that presented these handlers to an untrusted network before the January-2025 security updates needs forensic triage rather than a patch-and-close.",
+        "evidence": "CWE-36 absolute path traversal, named in the packet against the GetHashForSingleFile handler; the packet states the flaw 'allows a remote unauthenticated attacker to leak sensitive information' in Ivanti EPM before the 2024 January-2025 Security Update and the 2022 SU6 January-2025 Security Update. CISA KEV-listed 2025-03-10 (due 2025-03-31), active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 73.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the compressed clock runs on the EPM server itself, not on the endpoints it manages, and that inverts the usual patch-cadence assumption: one server-side update closes the exposure for the whole estate, so there is no fleet-rollout tail to justify a monthly or quarterly maintenance window. The packet records a vendor fix — the 2024 January-2025 Security Update and the 2022 SU6 January-2025 Security Update — and no live-patch path for this product class, so remediation means taking the EPM server through the update rather than applying anything in place, and the named compensating controls hold only until it lands. The flaw was already exploited in the wild with a public PoC when CISA listed it on 2025-03-10, which makes the 2025-03-31 due date the outer bound rather than the target. Inside the interval the only available lever is reachability: restrict which networks can reach the EPM management surface, since the attack requires no credential and no user interaction.",
+        "evidence": "CISA KEV-listed 2025-03-10 with a stated due date of 2025-03-31 and active_exploitation confirmed; poc_available true; patch_available true, with the packet naming the 2024 January-2025 Security Update and 2022 SU6 January-2025 Security Update as the fixing releases; live_patch_available false, and the packet's live-patch note stating there is no live-patch path for this product class and that remediation is the vendor update plus the named compensating controls until it lands. CVSS 9.8, RWEP 73.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The primitive here is a read, and a read is not reversed by an update: whatever an unauthenticated attacker pulled off an exposed EPM server before the January-2025 security updates remains in their hands afterwards. Because EPM is a fleet-control-plane asset rather than an ordinary application server, the response has to be scoped to the estate it serves and not to the one host — establish the exposure window from the instance's first untrusted-network-reachable day through the day the update landed, rotate credentials for every account that authenticated through the EPM server inside that window, and treat material the server held during it as disclosed rather than still-confidential. This playbook has to be written before the disclosure, because reconstructing which accounts transited a management server months after the fact is the step that fails under time pressure. It is also the half of the response no patch-status dashboard surfaces: a flaw-remediation control closes at 'update installed', and for a confirmed-exploited disclosure primitive that is not closure.",
+        "evidence": "CWE-36 absolute path traversal allowing, per the packet, a remote unauthenticated attacker to leak sensitive information from Ivanti EPM; active_exploitation confirmed and CISA KEV-listed 2025-03-10 (due 2025-03-31); poc_available true; live_patch_available false, with remediation recorded as the vendor update plus named compensating controls until it lands.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-13160": {
     "name": "Ivanti Endpoint Manager (EPM) Absolute Path Traversal Vulnerability (GetHashForWildcard)",
@@ -32355,7 +33633,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-085",
+        "name": "DB-ABSTRACTION-LAYER-PARAMETERIZATION-VERIFICATION",
+        "description": "Verify parameterization inside VeraCore's own data-access path rather than inferring it from a WAF signature or an application-wide input-validation attestation. The sink the packet names is the PmSess1 parameter on a single page, timeoutWarning.asp, so the check has to target the query that one page builds — a per-page surface that a platform-level 'we use parameterized queries' claim does not cover, and that a perimeter filter only masks. The distinguishing test: send a SQL metacharacter in PmSess1 to a staging VeraCore instance and confirm the value is bound as a parameter rather than concatenated into the statement; any build in the affected range ('through 2025.1.0') that answers the metacharacter request differently from a control request is still exploitable regardless of what sits in front of it. The vendor update is what removes the sink — the verification is what proves it is gone.",
+        "evidence": "The packet's vector states: 'A SQL injection vulnerability in timeoutWarning.asp in Advantive VeraCore through 2025.1.0 allows remote attackers to execute arbitrary SQL commands via the PmSess1 parameter.' cwe_refs is CWE-89. cisa_kev is true (kev_date 2025-03-10), active_exploitation is 'confirmed', poc_available is true. patch_available is true; live_patch_available is 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": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "VeraCore is the entry where a CVSS-threshold SLA never fires. At 5.8 this SQL injection falls below the critical/high cut most patch programs use to trigger expedited work, while the packet's RWEP of 64 reflects a KEV listing with confirmed in-the-wild exploitation and a public exploit. Bind the remediation clock to the KEV listing of 2025-03-10 and its 2025-03-31 due date rather than to the score, and keep the interim state recorded honestly: the packet says there is no live-patch path for this product class, so until the vendor update lands the posture is compensating controls in front of timeoutWarning.asp — that is a compensating-control state with a time-bound action item, not a closed finding.",
+        "evidence": "The packet records cvss 5.8 against rwep_score 64, with cisa_kev true, kev_date 2025-03-10, active_exploitation 'confirmed' and poc_available true; the attack_vector line records the listing as 'CISA KEV-listed 2025-03-10 (due 2025-03-31) with confirmed in-the-wild exploitation.' patch_available is true and live_patch_available is 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": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-50302": {
     "name": "Linux Kernel Use of Uninitialized Resource Vulnerability",
@@ -32410,7 +33712,42 @@
     },
     "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": "This is the paper-compliance trap that a kernel CVE with no live-patch path sets. The fix is a source change in HID core — zero-initializing the report buffer at allocation — and the packet records live_patch_available false, so there is no way to apply it to a kernel that is already running: the zero-initialization is only in effect on a host that is running the updated kernel, not on a host that merely has the updated kernel package installed. Every scanner that keys 'patched' off the installed kernel package version will mark such a host green, and long-uptime hosts (the exact population that defers restarts) are where that gap is widest. The operational test this control demands here: for each Linux host, compare the running kernel build against the installed kernel package, and count any host where they differ as unremediated against the CISA due date of 2025-03-25 — not as patched. An asset inventory that cannot produce running-kernel-versus-installed-package per host cannot evidence remediation of this entry at all.",
+        "evidence": "Packet fields for CVE-2024-50302: vector 'In the Linux kernel, the following vulnerability has been resolved:\\n\\nHID: core: zero-initialize the report buffer\\n\\nSince the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.'; cwe_refs CWE-908; cisa_kev true, kev_date 2025-03-04 with attack_vector recording 'due 2025-03-25'; active_exploitation confirmed; patch_available true; 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": [
+          "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 packet states the vulnerable report buffer is consumed by all kinds of HID drivers and is reached by a specially-crafted report, so the exposure of a given host is a function of which HID transport and device drivers it will bind at all. On servers, VMs and appliance-class hosts that never need an arbitrary human-interface peripheral, the HID transport drivers (USB HID and any Bluetooth HID stack) are not required for business function and can be modprobe-blacklisted — which removes the path by which a crafted report reaches the uninitialized buffer, on the running kernel, without waiting for the vendor update. That matters specifically for this entry because the packet records no live-patch path: blacklisting is the one mitigation available on an already-running vulnerable kernel. Inventory the loaded HID modules per host class, blacklist the ones with no business need, and review the list quarterly so a re-enabled driver reopens the path visibly rather than silently.",
+        "evidence": "Packet fields for CVE-2024-50302: vector states the report buffer 'is used by all kinds of drivers in various ways' and that the fix zero-initializes it 'during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report'; cwe_refs CWE-908; active_exploitation confirmed; cisa_kev true, kev_date 2025-03-04; 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": "This entry is the case against severity-driven scheduling: CVSS 5.5 with no public PoC, which every risk-ranked patch queue reads as a medium-priority information-disclosure bug, against active_exploitation confirmed and RWEP 55 — CISA listed it precisely because someone is using it. Kernel memory leaked through a crafted HID report is chain material, not an end state, so the queue position it earns on CVSS is wrong. The control keys the clock to the KEV listing instead: remediation is the distribution kernel update, and because the packet records no live-patch path for this class, the SLA is only satisfied when hosts are running the updated kernel, with the named compensating controls carrying every host that is not there yet. CISA allowed until 2025-03-25; the control's requirement is 4 hours from listing or patch availability, whichever is later.",
+        "evidence": "Packet fields for CVE-2024-50302: cisa_kev true, kev_date 2025-03-04, attack_vector states 'CISA KEV-listed 2025-03-04 (due 2025-03-25) with confirmed in-the-wild exploitation'; active_exploitation confirmed; CVSS 5.5; RWEP 55; poc_available false; patch_available true; live_patch_available false; 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": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-4885": {
     "name": "Progress WhatsUp Gold Path Traversal Vulnerability",
@@ -33015,7 +34352,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_disclosure",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "PAN-OS is the trust boundary itself, and the exposed surface in this CVE is its management web interface — the plane that administers the boundary — which is why placing this appliance in the same patch population as a general server or workstation gives it the wrong clock. The control's alternative branch is precisely the action the packet's own vector names: isolate the vulnerable interface by restricting management-web-interface access to trusted internal IP addresses per the vendor's deployment guidance, which removes network reach for callers outside the operator network while the appliance update is scheduled. The packet also bounds the tier's scope — it states the issue does not affect Cloud NGFW or Prisma Access — so the accelerated tier applies to the PAN-OS appliance estate specifically rather than to every Palo Alto product in the inventory. The distinguishing test: from a general user segment, attempt to load the PAN-OS management web interface; anything that answers is inside the reachable population for an authenticated file read whose exploitation the packet records as confirmed, and 'the firewall is on the internal network' is a topology assertion, not a demonstration that the management plane is unreachable.",
+        "evidence": "Packet: name 'Palo Alto Networks PAN-OS File Read Vulnerability', vector states an authenticated attacker with network access to the management web interface can read files readable by the 'nobody' user and that risk is greatly reduced by restricting management web interface access to trusted internal IP addresses per the vendor's linked best-practices deployment guidelines; vector also states the issue does not affect Cloud NGFW or Prisma Access. cisa_kev true, kev_date 2025-02-20, active_exploitation confirmed, patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this CVE the packet supplies the compensating-control branch of the SLA directly: the vendor's stated risk-reduction step is restricting management-web-interface access to trusted internal IP addresses, a configuration change on the firewall itself rather than a code deployment. That leaves no defensible interval between the 2025-02-20 KEV listing and a mitigated state, even where the PAN-OS update must wait for a change window — the packet records patch_available true with live_patch_available false and no live-patch path, so the update has to be taken on the appliance and the access restriction is what covers the wait. The clock the control imposes runs to the due date the packet records as 2025-03-13, and it applies per appliance: the deliverable is every PAN-OS unit either updated or demonstrably answering its management interface only from the operator network, dated against the KEV listing rather than against the next firmware maintenance cycle.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-02-20, attack_vector records the KEV due date as 2025-03-13, active_exploitation confirmed, poc_available true, rwep_score 77 against cvss 6.5, patch_available true, live_patch_available false, 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.', and the vector names the management-web-interface IP restriction as the risk-reduction measure.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry is unusually prone to the conflation the control exists to prevent, because the vendor's own text offers the access restriction as risk reduction in the same breath as the flaw description. The two states are materially different on this appliance: restricting the management web interface to trusted internal IP addresses narrows who can reach the endpoint, but the file read still succeeds for any caller who reaches it with credentials — which on a firewall means every administrator account and anything that has taken one — so the primitive is contained, not removed. Compliance evidence must therefore carry 'management interface restricted to trusted internal IPs, PAN-OS update pending' as its own time-bound state rather than folding it into a patched-per-SLA line. The residual to record with it: with exploitation confirmed and a PoC available, any appliance whose management interface was reachable before the restriction was applied may already have disclosed every file the 'nobody' user can open, so closing the state also means treating that pre-restriction window as an exposure to triage rather than a patch-and-close.",
+        "evidence": "Packet: vector states an authenticated attacker with network access to the management web interface reads files readable by the 'nobody' user, and that restricting management web interface access to trusted internal IP addresses greatly reduces the risk; cwe_refs CWE-73 and CWE-610; active_exploitation confirmed; poc_available true; patch_available true; live_patch_available false with live_patch_notes recording no live-patch path for this product class.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2026-56291": {
     "name": "Balbooa Forms Unrestricted Upload of File with Dangerous Type Vulnerability",
@@ -33457,7 +34825,29 @@
         "adequate": false,
         "gap": "Access enforcement for a locked device assumed the USB Restricted Mode state machine was sound; the authorization flaw let a physical attacker force the device back into an accessible state without credentials."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Every enrolled iPhone and iPad must be driven to the fixed build for its own OS line by declarative device management on a KEV-tied clock, with user deferral removed. USB Restricted Mode is the only thing standing between a locked handset in someone else's hands and its data over a port that is supposed to be delivering charge only; because the attack needs physical possession rather than network reach, no perimeter rule, no VPN posture check and no conditional-access policy compensates while the device is still on a vulnerable build, and a user who postpones the update for a week is carrying an extractable device for that week. The campaign has to target four separate fixed builds (iOS/iPadOS 15.8.4, iOS/iPadOS 16.7.11, iPadOS 17.7.5, iOS/iPadOS 18.3.1) rather than a single 'update to latest', because the older lines exist precisely for hardware that cannot take the newest release.",
+        "evidence": "Packet: CISA KEV-listed 2025-02-12 with active_exploitation confirmed. patch_available is true and the vendor text names the fixed builds — 'This issue is fixed in iOS 15.8.4 and iPadOS 15.8.4, iOS 16.7.11 and iPadOS 16.7.11, iOS 18.3.1 and iPadOS 18.3.1, iPadOS 17.7.5.' The recorded exploitation path is an attacker with physical possession of a locked iOS/iPadOS device using specialized forensic-extraction hardware to disable USB Restricted Mode; Apple 'is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals.' poc_available is false and CVSS is 6.1 (RWEP 49), so a severity-threshold patch queue leaves this below the cut line even though exploitation is confirmed — which is exactly why the SLA has to key off the KEV listing, not the score.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Access to organizational mail, documents and internal services from an iOS/iPadOS device must be conditioned on the device actually running at or above the fixed build for its OS line — enforced as a gate, not recorded as a compliance datapoint. The packet enumerates fixes across four OS lines, which means the estate contains hardware that will never reach the newest release; for those devices the gate is 15.8.4 / 16.7.11 / 17.7.5, and a device that cannot reach its line's fixed build should lose access to organizational data rather than appear as a stale row on a dashboard. The gate matters more than usual for this flaw because the exploitation state is a locked, powered-on device in an attacker's hands — the exact condition of a lost, stolen or seized corporate handset, where the MDM has no further influence and only the installed build decides whether the USB data path opens.",
+        "evidence": "Packet: CWE-863 incorrect authorization; 'A physical attack may disable USB Restricted Mode on a locked device', restoring full USB data access to a device that should only permit charging when locked. patch_available is true with the fixed builds enumerated per OS line, and live_patch_available is false — there is no mitigation that can be applied to a device short of installing the fixed OS build, so the build level is the whole of the device's defensive state. KEV-listed 2025-02-12, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-41710": {
     "name": "Mitel SIP Phones Argument Injection Vulnerability",
@@ -33531,7 +34921,30 @@
         "adequate": false,
         "gap": "Monthly Patch Tuesday cadence is the fastest routine remediation path, but this flaw was exploited in the wild as a zero-day before the February 2025 patch existed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The afd.sys WinSock driver fix has to run on a KEV-tied clock across the whole Windows estate rather than ride the routine servicing cadence, because this entry has no alternative remediation path: the packet records patch_available true with live_patch_available false and no live-patch notes at all, so nothing closes the IOCTL path while the host keeps running. Escalation to SYSTEM is the second half of a chain whose first half is a phishing-delivered payload, which means every unpatched workstation that can run user-delivered code is a full-host compromise waiting on one foothold. Hosts that genuinely cannot take the update inside the window need a documented, time-bound decision about what untrusted code is allowed to execute on them, not an SLA extension.",
+        "evidence": "cisa_kev is true with kev_date 2025-02-11 and active_exploitation confirmed; rwep_score 61 against a cvss of 7.8. patch_available is true, live_patch_available is false, and live_patch_notes is null, so the vendor update is the only remediation the packet records. The attack_vector describes a local attacker who already has code execution (typically via a prior phishing-delivered payload) sending crafted IOCTL requests to the kernel-mode afd.sys driver, triggering a heap-based buffer overflow to escalate to SYSTEM. The gaps citing this CVE — AU-Essential-8-Patch, ISO-27001-2022-A.8.8, NIST-800-53-SI-2 and NIS2-Art21-vulnerability-management — are all routine-cadence flaw-remediation controls carrying no KEV-tied clock.",
+        "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": "Windows hosts need behavioural alerting on the post-exploitation signature of an afd.sys overflow — a user-mode process issuing anomalous IOCTLs to the AFD device, followed by a token swap or a SYSTEM-integrity child spawned from a non-SYSTEM parent — with the alert raised in seconds, not at the next log review. The defining constraint for this CVE is that defenders cannot validate their coverage by replaying a published exploit: exploitation is confirmed in the wild while no public PoC exists, so signature-and-replay verification is unavailable and detection has to key on the privilege-escalation behaviour itself. That telemetry is also the input the response and recovery plan depends on, since the escalation is what converts a phishing foothold into a host that must be rebuilt rather than cleaned, and it is the only visibility an operator has over the hosts still inside the patch window.",
+        "evidence": "poc_available is false while active_exploitation is confirmed and cisa_kev is true (kev_date 2025-02-11) — in-the-wild exploitation with no public proof-of-concept to test defences against. The attack_vector records a local attacker with prior code execution sending crafted IOCTL requests to the kernel-mode afd.sys driver, corrupting kernel memory to escalate to SYSTEM privileges. UK-CAF-D1 (Response and recovery planning) is one of the framework gaps citing this CVE as evidence.",
+        "gap_closes": [
+          "UK-CAF-D1"
+        ]
+      }
+    ]
   },
   "CVE-2025-21391": {
     "name": "Microsoft Windows Storage Link Following Vulnerability",
@@ -33568,7 +34981,19 @@
         "adequate": false,
         "gap": "Protection-of-audit-information control is directly undermined — the observed exploitation pattern deletes security logs via link-following, defeating log-integrity assumptions."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "Windows Storage is an OS component rather than an optional server role, so the exposed population is the whole Windows fleet and there is no subset an operator can enumerate and isolate instead of updating. The exploitation precondition the packet names is standard user access — the local attacker plants a symbolic link that redirects a privileged Windows Storage file-management operation to a target of their choosing — so account-privilege policy is not a containment story here: the flaw is the thing that converts a standard user into a privileged one, which is precisely why this control says privilege policy must not be relied on to hold the line. Applied to this entry, the Windows update carrying the fix has to be driven across every affected endpoint on the clock that started with the 2025-02-11 KEV listing rather than folded into the normal monthly ring, and the packet's live_patch_available: false with no live_patch_notes has to be treated as a hard planning fact — nothing can be applied to a running endpoint, so the rollout needs restart windows for the fleet and not just a deployment ring. One scheduling signal is actively misleading on this entry: poc_available is false while active_exploitation is confirmed, so a program that gates urgency on public proof-of-concept availability will hold this at routine severity indefinitely. The distinguishing test: enumerate installed build numbers across the fleet against the fixed build for each Windows SKU in the estate and confirm zero endpoints remain below it past the KEV due date — an attestation that 'standard users are not local administrators' passes cleanly while this path stays wide open.",
+        "evidence": "Packet: CISA KEV-listed 2025-02-11, active_exploitation confirmed, CVSS 7.1, RWEP 61, CWE-59. Attack path as recorded: 'A local attacker with standard user access creates a symbolic link that redirects a privileged Windows Storage file-management operation to an unintended target, allowing them to delete arbitrary files — including security event logs — and escalate privileges.' Remediation fields: patch_available true; live_patch_available false with live_patch_notes null. poc_available false, i.e. confirmed in-the-wild exploitation with no public PoC recorded.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-40891": {
     "name": "Zyxel DSL CPE OS Command Injection Vulnerability",
@@ -33716,7 +35141,39 @@
         "adequate": false,
         "gap": "Malicious-code protections that gate on Mark-of-the-Web (SmartScreen prompts, Protected View) are bypassed entirely by the double-archive technique, so endpoint controls relying solely on MotW propagation are insufficient."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-119",
+        "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
+        "description": "The archive tool itself must carry the Mark-of-the-Web from the downloaded outer archive onto every file it writes — including the files it writes while extracting an archive that was itself extracted — and must decide how to render or launch an entry from its verified content type rather than from the name shown in the extraction listing. Both halves are load-bearing for this specific chain: the target receives a double-encapsulated 7-Zip archive whose entries carry homoglyph-spoofed names, and 7-Zip drops the outer archive's mark when it extracts the inner one, so the script files land on disk indistinguishable from files the user authored locally. Until 24.09 or later has actually been pushed to the fleet, treat any nested archive that 7-Zip extracts as mark-stripped by default: open it in a detonation chamber, not on a user endpoint, and do not rely on the displayed filename to judge what an entry is.",
+        "evidence": "Packet: 'The specific flaw exists within the handling of archived files. When extracting files from a crafted archive that bears the Mark-of-the-Web, 7-Zip does not propagate the Mark-of-the-Web to the extracted files' (CWE-693). The recorded path is a spear-phished, homoglyph-spoofed double-encapsulated 7-Zip archive whose extracted .js/.wsf/.url files execute attacker code, observed delivering SmokeLoader. User interaction is required — the target must visit a malicious page or open a malicious file. KEV-listed 2025-02-06, active_exploitation confirmed, poc_available true, CVSS 7.0, RWEP 68.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Script hosts and shortcut handlers must be blocked from running .js, .wsf and .url content that arrived through a download path, and that block must not be conditional on a reputation verdict — in this chain SmartScreen and Office Protected View never render a verdict at all, because the extracted files carry no mark for them to evaluate. Enforce provenance at the execution boundary instead (WDAC/AppLocker rules covering wscript/cscript and the shortcut handler, or removing script-host associations for user-writable extraction directories), so a mark-stripped payload dropped by a 7-Zip extraction is refused when it tries to run rather than when it tries to earn a reputation. Malware protection alone is the control this entry shows failing: the loader ran because the operating system had no reason to treat the file as internet-sourced.",
+        "evidence": "Packet: the extracted .js/.wsf/.url script files 'run without triggering Windows SmartScreen or Office Protected View, executing attacker code (observed delivering SmokeLoader)'. The flaw class is CWE-693, a protection-mechanism failure — the bypassed mechanism is the provenance mark itself. KEV-listed 2025-02-06 with active_exploitation confirmed and poc_available true. The entry's own citing gaps already record NIST 800-53 SI-3 (Malicious Code Protection), ISO/IEC 27001 A.8.7 (Protection against malware) and NIST 800-53 CM-7 (Least Functionality) as insufficient here.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7",
+          "NIST-800-53-CM-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "7-Zip carries no auto-update channel, so the fixed build only exists on an endpoint once someone has packaged and pushed 24.09 or later — and that push is only meaningful if a Mark-of-the-Web bypass battery is re-run against the build that actually landed. Keep that battery as a standing asset and make sure it includes the nested case this entry demonstrates (outer archive bearing the mark, inner archive extracted from it, script file extracted from that), not just a single-level download test, because the single-level test passes on a build that still drops the mark one layer down. Run it on every 7-Zip redistribution across the fleet and treat a software-inventory report showing '24.09 deployed' with no accompanying bypass result as unverified. Extend the same battery to every other archive tool operators are permitted to install: the packaging tool, not Windows, decides whether the mark survives extraction.",
+        "evidence": "Packet live_patch_notes: '7-Zip has no built-in auto-update mechanism; enterprises must manually redistribute 24.09 or later, unlike browser-class software with silent auto-update.' live_patch_available is false, so there is no vendor-side path that reaches endpoints without the organization packaging and pushing the build. The defect is a protection-mechanism failure (CWE-693) against the Mark-of-the-Web / SmartScreen class, KEV-listed 2025-02-06 with active_exploitation confirmed and poc_available true — a working bypass primitive for the class is public, so the regression battery has real material to test with.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-21413": {
     "name": "Microsoft Outlook Improper Input Validation Vulnerability (MonikerLink)",
@@ -35293,7 +36750,20 @@
         "adequate": false,
         "gap": "Vulnerability management processes did not surface XXE-capable unauthenticated endpoints as high-priority exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Proself ships as three separately versioned editions and the packet gives each its own affected ceiling — Enterprise/Standard Ver5.62 and earlier, Gateway Edition Ver1.65 and earlier, Mail Sanitize Edition Ver1.08 and earlier — so 'verified mitigation' on this entry means confirming every deployed edition individually against its own fixed version. A single 'Proself is updated' attestation is the specific failure mode here, because the version numbers are not comparable across editions and an estate that moved its Enterprise/Standard servers while leaving a Gateway or Mail Sanitize instance in place is still answering the unauthenticated XXE path. The clock this control sets runs from the 2024-12-03 KEV listing, and because live_patch_available is false with no live-patch notes recorded, meeting it means taking each Proself instance through the vendor update — there is nothing to apply to a running service as an interim. Two properties of this entry make the compressed clock matter more than its 7.5 base score suggests. First, exploitation is confirmed in the wild while no public proof-of-concept is recorded, so a program that schedules on PoC availability will never receive the signal it is waiting for. Second, what the flaw returns is arbitrary files on the server 'containing account information', which means updating does not end the incident: every credential readable through the pre-update window has to be treated as disclosed and rotated, and the control's 'verified mitigation' bar is not met by the update alone on an instance that was internet-reachable before it landed.",
+        "evidence": "Packet: CWE-611, CVSS 7.5, RWEP 42, CISA KEV-listed 2024-12-03, active_exploitation confirmed, poc_available false. Attack path as recorded: 'An unauthenticated attacker submits a specially crafted XML request containing external entity declarations to a Proself endpoint, causing the server to disclose arbitrary local files including account information.' Packet vector text names the affected ceilings — 'Proself Enterprise/Standard Edition Ver5.62 and earlier, Proself Gateway Edition Ver1.65 and earlier, and Proself Mail Sanitize Edition Ver1.08 and earlier' — and states that 'arbitrary files on the server containing account information may be read by the attacker.' Remediation fields: patch_available true; live_patch_available false with live_patch_notes null.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-28461": {
     "name": "Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function Vulnerability",
@@ -35441,7 +36911,31 @@
         "adequate": false,
         "gap": "Access enforcement failed because the Process Extension SDK component did not correctly authorize requests, allowing unauthenticated access to data that should require a session."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Agile PLM is the system of record for product designs and supplier data, and this flaw shows the Agile PLM Framework's Process Extension SDK component answering a crafted HTTP request from a caller holding no credential at all — the authorization decision is taken incorrectly inside the function rather than at the console login. Applied to this deployment the control means every Process Extension / SDK entry point on the Framework authorizes the caller before it returns any PLM content, and the Framework's HTTP surface is segmented so an untrusted network caller cannot reach that component in the first place. Least-privilege review of Agile PLM user roles does not touch this path: the attacker never holds an account, and the packet scores impact as unauthorized access to critical data or complete access to all Agile PLM Framework accessible data (C:H) rather than the privileges of some compromised user. Distinguishing test: from an untrusted network segment, send an unauthenticated HTTP request to each Process Extension SDK endpoint on a staging 9.3.6 instance and confirm it is refused before any PLM data is returned — an attestation that 'all PLM users authenticate at login' passes cleanly while this path stays open.",
+        "evidence": "Packet: CWE-863 incorrect authorization in the Oracle Agile PLM Framework's Software Development Kit / Process Extension component; an unauthenticated attacker with network access via HTTP sends a crafted request and obtains unauthorized access to critical data or complete access to all Agile PLM Framework accessible data. CVSS 3.1 base 7.5, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N; affected supported version 9.3.6. CISA KEV-listed 2024-11-21, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Agile PLM sits in the supply-chain application tier that most estates patch on a quarterly application cadence, and the packet's own numbers are what make that cadence wrong here: a 7.5 base score with confidentiality-only impact and poc_available false will sort below every 9.x item in a score-ordered or exploit-availability-ordered queue, while the entry is KEV-listed with exploitation already confirmed. The control binds the clock to the KEV listing instead of to the score: the affected 9.3.6 Framework instance is taken through the vendor update inside the KEV-tier window. The packet records a vendor patch and no live-patch path, so there is no in-place mitigation to buy time with — where the update cannot land in that window the remaining lever is removing HTTP reachability of the Process Extension SDK surface from untrusted networks, recorded as a time-bound exception rather than as patched-per-SLA.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-11-21, active_exploitation confirmed, poc_available false, rwep_score 42, cvss 7.5. patch_available true, live_patch_available false, live_patch_notes null. Attack path is an unauthenticated crafted HTTP request to the Agile PLM Framework Process Extension SDK component (version 9.3.6).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-38813": {
     "name": "VMware vCenter Server Privilege Escalation Vulnerability",
@@ -35811,7 +37305,39 @@
         "adequate": false,
         "gap": "The roughly three-year gap between the 2021 patch and 2024 KEV listing shows unpatched internet-exposed instances persisted well past any reasonable flaw-remediation SLA."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Metabase instances must be moved to a fixed maintenance release on the KEV clock, not on whatever cadence the analytics platform normally gets as a business-intelligence tool rather than a perimeter service. The remediation is a straightforward version upgrade — the packet names the fix as 0.40.5 and 1.40.5 and any subsequent release — but the urgency is that the flaw needs no authentication and returns the Metabase process's own environment variables, so every hour on a vulnerable release is an hour an anonymous caller can read the cloud credentials that process holds. Remediation is therefore not finished when the upgrade lands: any credential readable from that process environment during the exposure window has to be treated as disclosed and rotated, because the upgrade closes the read path but does nothing about what was already read.",
+        "evidence": "cisa_kev is true with kev_date 2024-11-12 and active_exploitation confirmed; cvss is 10 and rwep_score 70, with poc_available true. patch_available is true and the packet's vector text states the issue 'is fixed in a new maintenance release (0.40.5 and 1.40.5), and any subsequent release after that'; live_patch_available is false. The attack_vector records an unauthenticated attacker submitting a file:// URL to Metabase's custom-map GeoJSON API, disclosing arbitrary local files and process environment variables including cloud credentials.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "This entry has a vendor-named configuration-side mitigation that exists independently of the upgrade: validation rules in the reverse proxy, load balancer, or WAF that filter the request before it reaches Metabase. That rule — rejecting non-http(s) schemes and traversal in the GeoJSON map URL parameter — must be written, tested against a staging instance, and held as a deployable artifact ahead of need, rather than improvised once the KEV clock is already running and the change-advisory board is the bottleneck. It matters here specifically because the vulnerable endpoint accepts a caller-supplied URL and performs no scheme or path validation of its own, so on any instance still awaiting its upgrade window the proxy filter is the only enforcement point standing between an anonymous HTTP request and a local file read.",
+        "evidence": "The packet's vector text states: 'If you're unable to upgrade immediately, you can mitigate this by including rules in your reverse proxy or load balancer or WAF to provide a validation filter before the application.' The attack_vector records the custom-map GeoJSON API loading a caller-supplied file:// URL 'without scheme or path validation'. NIST-800-53-AC-3 (Access Enforcement), ISO-27001-2022-A.8.9 (Configuration management) and UK-CAF-B4 (System security) are among the framework gaps citing this CVE as evidence.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "ISO-27001-2022-A.8.9",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "An audit of a Metabase estate must not record 'proxy validation filter deployed' as patched, because the two states differ materially for this flaw. On the fixed maintenance release the GeoJSON URL is validated inside the application; with only the reverse-proxy or WAF filter the unauthenticated file-read path is fully intact behind a rule that any URL-encoding or parser-differential defect reopens — and what it reopens is a CVSS 10 disclosure of local files and process environment variables holding cloud credentials. The mitigated-but-unpatched instances therefore have to appear in the compliance record as a distinct compensating-control state with a time-bound action item naming the 0.40.5 / 1.40.5 upgrade, not folded into the same 'remediated within SLA' bucket as the upgraded ones.",
+        "evidence": "The packet documents two distinct remediation paths: patch_available is true with the fix in '0.40.5 and 1.40.5, and any subsequent release after that', and separately an interim path of 'rules in your reverse proxy or load balancer or WAF to provide a validation filter before the application' for operators unable to upgrade immediately. cvss is 10, active_exploitation is confirmed, and cisa_kev listing is dated 2024-11-12. NIS2-Art21-patch-management is one of the framework gaps citing this CVE.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2021-26086": {
     "name": "Atlassian Jira Server and Data Center Path Traversal Vulnerability",
@@ -37398,7 +38924,39 @@
         "adequate": false,
         "gap": "Least-functionality is the real fix here: the IOS HTTP admin server should be disabled, but CM-7 baselining rarely reaches retired edge routers still exposing /level/15/exec, so the CSRF surface persists."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "A 2008-vintage flaw in the Cisco IOS 12.4 HTTP administration component on the 871 Integrated Services Router is reachable in 2026 only because the router is still racked and still answering. The control means the asset inventory has to carry an end-of-support date for every network-attached embedded device including routers, so a unit whose vendor has stopped issuing fixes but whose HTTP admin surface is still remotely reachable is discoverable before an advisory names it, not after. The distinguishing test for this device class: query the inventory for routers past end-of-support whose management interface answers from a segment with no operational need to reach it; any non-empty result without a replace-or-formally-risk-accept decision is the finding. A patch-management policy that assumes a fix always exists produces no record at all for this router, because there is no version to compare it against.",
+        "evidence": "Packet: affected product is the HTTP Administration component in Cisco IOS 12.4 on the 871 Integrated Services Router; patch_available is false and live_patch_available is false; live_patch_notes reads 'End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.' CISA KEV-listed 2026-07-13 with active_exploitation confirmed (RWEP 70, CVSS 4.3). Citing gaps include ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) and the NIS2 Art.21 network-security measures.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "There is no build of IOS an operator can move this router to, so for CVE-2008-4128 'remediation' means removal and nothing else. Applied to this device: any surviving unit must be segmented so that its HTTP admin server cannot be reached from any network an administrator browses the web from, and carried to decommission on a bounded, dated schedule rather than an open-ended risk acceptance. Segmentation is the compensating control, not the fix, because the exploit needs only an already-authenticated administrator's browser to be able to issue requests to /level/15/exec/- and /level/15/exec/-/configure/http on the device — the attacker never authenticates. The distinguishing test: from every segment an administrator's workstation can browse from, attempt to load the router's HTTP admin surface; anything that answers is within reach of the lure path, and a risk-acceptance memo with no removal date leaves a KEV-listed no-fix device in service indefinitely.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes 'End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.' Attack vector per packet: an attacker lures an already-authenticated IOS administrator to a crafted page that forces requests to /level/15/exec/- and /level/15/exec/-/configure/http, executing privilege-15 and configuration commands through the router HTTP admin server. CWE-352; CISA KEV-listed 2026-07-13, active_exploitation confirmed. Citing gaps name NIST SP 800-53 Rev 5 SC-7 (Boundary Protection) and UK CAF B4 (System security) as insufficient.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This router can never reach a 'patched' verdict — the packet records no vendor fix and no live-patch path — so vulnerability-management reporting has to represent it as its own state rather than as an overdue patch item that rolls forward every cycle. For CVE-2008-4128 the register entry must read: full exposure, contained by segmentation of the HTTP admin surface, with a dated decommission action attached; not 'patch pending'. The distinguishing test: pull the register entry for this CVE and confirm the recorded state names the compensating control and the removal date; an estate whose report shows only an aging patch-SLA breach has recorded the exposure without ever forcing the only decision that ends it.",
+        "evidence": "Packet: patch_available false and live_patch_available false, with live_patch_notes stating no vendor fix and no live-patch path exists; CISA KEV-listed 2026-07-13 with active_exploitation confirmed and poc_available false. The citing gap ISO/IEC 27001:2022 A.8.8 (Management of technical vulnerabilities) is patch-closure-shaped and has no verdict for a product with no fix.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2020-14644": {
     "name": "Oracle WebLogic Server Remote Code Execution Vulnerability",
@@ -37768,7 +39326,30 @@
         "adequate": false,
         "gap": "Malicious-code protection keyed on file extension/type is defeated precisely because the vulnerability misrepresents the extension to both the user and naive filters."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "The victim in this chain ran the file because of what it was called, not what it was: the packet records the downloaded HTA being presented with a filename that read as a PDF. That makes the untrusted-origin marking, applied at the ingress boundary and independent of anything the file carries, the control that still functions when the displayed name lies. For this CVE it means the .URL lure arriving by mail or web download is tagged as externally sourced at the gateway, and the tag survives the transformation the packet describes — a file that is renamed, or fetched onward through the handler the lure opens, must inherit the untrusted marking rather than lose it, so the artifact the user is invited to double-click still triggers an untrusted-content decision. The distinguishing test: deliver a file whose presented name and actual handler disagree through each ingress path onto a managed workstation and confirm it still reaches the user marked as untrusted; a user-application-hardening attestation that covers macro and ActiveX settings, and user training to 'check the extension', are exactly what a filename-spoofing flaw defeats.",
+        "evidence": "Packet attack_vector: 'Void Banshee lured victims with a .URL that used CVE-2024-38112 to open attacker content in MSHTML/IE, then used CVE-2024-43461 to spoof the downloaded HTA's filename as a PDF so the victim ran it, dropping Atlantida stealer.' CWE-451; CISA KEV-listed 2024-09-16 with active_exploitation confirmed; RWEP 79, CVSS 8.8, poc_available true. Citing gaps name ASD Essential Eight user application hardening, NIST SP 800-53 SI-3 (Malicious Code Protection) and ISO/IEC 27001:2022 A.8.7 (Protection against malware) as insufficient.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this MSHTML flaw the packet gives a vendor update and no live-patch path, and states the update requires a reboot to take effect — so the KEV clock has to run from the 2024-09-16 listing through completed reboot of every affected endpoint, not to the moment the update is staged or downloaded. Until that reboot lands, the endpoint still renders the attacker-chosen filename to the user, which is the whole exploitation step this CVE contributes to the chain. Where the reboot cannot be taken inside the window, the compensating position has to be documented explicitly for those hosts rather than assumed from the deployment report. The distinguishing test: measure elapsed time from the KEV listing to the last endpoint's post-update reboot; a fleet reported as compliant on update-deployment counts while endpoints await restart has not closed the window.",
+        "evidence": "Packet: CISA KEV-listed 2024-09-16, active_exploitation confirmed, RWEP 79, CVSS 8.8. patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' The packet places this CVE as the victim-deception step of a chain that also uses CVE-2024-38112 and ends in the Atlantida stealer. Citing gaps name NIST SP 800-53 SI-2 (Flaw Remediation) and NIS2 Art.21 vulnerability handling as insufficient.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-8190": {
     "name": "Ivanti Cloud Services Appliance OS Command Injection Vulnerability",
@@ -37842,7 +39423,40 @@
         "adequate": false,
         "gap": "Malicious-code protection that keys off MOTW/Protected View is directly undermined when the mark is stripped, so signature/behavioral gating never triggers on the downloaded payload."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "What fails here is a defense, not a parser: a crafted .lnk whose target path forces Windows to rewrite and canonicalize the shortcut drops the Zone.Identifier alternate data stream, so files opened afterwards skip Protected View and SmartScreen. An estate can hold every MOTW, SmartScreen and Protected View policy in the enforced state and still detonate the payload, which is why this product needs a standing class-level regression battery rather than a one-off check that this shortcut is now tagged — the known Zone.Identifier-stripping primitives replayed against detonation chambers, EDR rules and application-hardening policy on every patch deployment, since the packet's CWE-693 classification says the mechanism itself failed and mechanisms that fail once tend to fail again on the same primitive. The distinguishing test: deliver a shortcut-borne file through a managed workstation's normal path after the update lands and confirm the opened file still carries its zone marking and still opens in Protected View. Confirming that SmartScreen and Protected View are 'enabled' is a statement about policy state, not evidence that the marking survives an attacker-chosen delivery container.",
+        "evidence": "Packet: CWE-693 protection-mechanism failure, Windows Mark of the Web (MOTW). Attack path is a crafted .lnk file whose target path forces Windows to rewrite/canonicalize the shortcut, dropping the Zone.Identifier ADS and removing the Mark-of-the-Web so subsequently opened files skip Protected View and SmartScreen prompts. CISA KEV-listed 2024-09-10, active_exploitation confirmed, poc_available true, cvss 5.4, rwep_score 75.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-119",
+        "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
+        "description": "On this CVE the endpoint's own provenance marking is the thing that breaks — the Zone.Identifier ADS is dropped when Windows canonicalizes the attacker's shortcut — so the untrusted-origin decision cannot be left to metadata that rides along with the delivered file and that the attacker's .lnk controls. The operator-side expression is that the mail gateway and file-share boundary establish and hold the origin decision themselves: externally-sourced shortcut files and the archives carrying them are blocked, detonated or quarantined at ingress, so a file whose zone marking has been stripped on the workstation is never treated as locally-sourced content on the strength of the missing ADS. The distinguishing test: deliver a .lnk-bearing item through each ingress path and confirm the boundary acts on it, instead of confirming only that Protected View and SmartScreen are enabled on the endpoint — the packet's path is specifically the removal of the tag those two features key off, so an endpoint-only attestation says nothing about this delivery.",
+        "evidence": "Packet: the delivered artifact is a crafted .lnk file; Windows rewriting the shortcut's target path drops the Zone.Identifier ADS, removing the Mark-of-the-Web, so subsequently opened files skip Protected View and SmartScreen. poc_available true and active_exploitation confirmed (CISA KEV 2024-09-10), so the delivery path is in live use.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-3",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "At CVSS 5.4 this is the shape of finding a score-ordered queue puts below every critical in the same month's rollup, yet the packet has it KEV-listed with confirmed in-the-wild exploitation and a public PoC — its value to an attacker is that it silences the prompt the user would otherwise see, not that it scores high. The control replaces the score-ordered queue with a KEV-triggered clock: the Windows update that fixes the shortcut-rewrite path is deployed and the reboot taken across the affected fleet inside the KEV window, because the packet records no live-patching primitive for this product and names the reboot-requiring vendor update as the remediation. There is no configuration toggle that holds the line in the meantime — MOTW is itself the control being bypassed — so an estate that defers the reboot into its normal cadence is relying entirely on gateway-side delivery blocking, and should record that as its actual posture.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-09-10, active_exploitation confirmed, poc_available true, cvss 5.4, rwep_score 75. patch_available true, live_patch_available false; live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-38014": {
     "name": "Microsoft Windows Installer Improper Privilege Management Vulnerability",
@@ -38363,7 +39977,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "id": "NEW-CTRL-130",
         "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
         "description": "This flaw is the case the control is written for: the packet's own reachability precondition is that unprivileged user namespaces are enabled (otherwise namespaced CAP_SYS_ADMIN is required), and the escalation is stated to include breaking out of a container — so the namespace boundary provides no containment and the host kernel is the only thing between a tenant workload and root. The two compensating controls named here map one-to-one onto that precondition: disabling unprivileged user namespaces on hosts whose workloads do not need them, and dropping CAP_SYS_ADMIN from container specs, each removes reachability without touching the kernel, which matters for nodes waiting on a change window. Confining every workload with an AppArmor or SELinux profile plus seccomp additionally constrains which filesystem types a confined process can ask the kernel to mount, and mounting a filesystem that falls back to legacy handling is the step that reaches the overflowing parser. On this entry the live-kernel-patch branch of the control is real rather than aspirational, so host remediation and namespace hardening can land on the same day.",
         "evidence": "vector: heap-based buffer overflow in legacy_parse_param in the Filesystem Context functionality, reachable by 'An unprivileged (in case of unprivileged user namespaces enabled, otherwise needs namespaced CAP_SYS_ADMIN privilege) local user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to legacy handling)'. attack_vector: the local user escalates to root 'including breaking out of a container'. cisa_kev true with kev_date 2024-08-21, active_exploitation 'confirmed', poc_available true, RWEP 65, CVSS 8.4. live_patch_available true, live_patch_notes: 'Distros shipped livepatchable fixes for the legacy_parse_param overflow, allowing remediation without an immediate reboot on supported kernels.'",
@@ -39245,7 +40859,42 @@
         "adequate": false,
         "gap": "The 2024-08-05 KEV due date lagged the near-immediate mass exploitation of a preauth RCE affecting every default GeoServer install; SI-2 remediation windows are too slow for this exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "The GeoServer advisory in this packet ships a deployment-side mitigation that removes the vulnerable code without waiting for the upgrade: deleting the gt-complex-x.y.jar matching the running GeoTools version (the packet's own example is gt-complex-31.1.jar on GeoServer 2.25.1) strips the JXPath evaluation path that the OGC request handlers reach. For this product the control means knowing, per instance, whether the gt-complex module is load-bearing before the next disclosure — because the same advisory states that removing the jar may break GeoServer functionality or prevent GeoServer from deploying where that module is needed. An operator who discovers that during an incident has neither a mitigation nor a tested rollback. Hold a rehearsed jar-removal-and-restart procedure for the instances where gt-complex is not required, keep it deployable independently of the upgrade to 2.22.6 / 2.23.6 / 2.24.4 / 2.25.2, and record which instances cannot take it so their exposure is managed by reachability instead. The packet records no live-patching primitive for this product, so between the KEV listing and a completed upgrade this configuration path is the only lever that removes the unauthenticated code-execution sink rather than merely narrowing who can reach it.",
+        "evidence": "Packet vector: \"multiple OGC request parameters allow Remote Code Execution (RCE) by unauthenticated users through specially crafted input against a default GeoServer installation due to unsafely evaluating property names as XPath expressions\"; \"Versions 2.22.6, 2.23.6, 2.24.4, and 2.25.2 contain a patch for the issue. A workaround exists by removing the `gt-complex-x.y.jar` file from the GeoServer where `x.y` is the GeoTools version (e.g., `gt-complex-31.1.jar` if running GeoServer 2.25.1). This will remove the vulnerable code from GeoServer but may break some GeoServer functionality or prevent GeoServer from deploying if the gt-complex module is needed.\" patch_available: true; live_patch_available: false; live_patch_notes: \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" CISA KEV 2024-07-15, active_exploitation confirmed, CVSS 9.8, RWEP 70.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "A GeoServer instance with gt-complex removed and a GeoServer instance upgraded to 2.22.6 / 2.23.6 / 2.24.4 / 2.25.2 are not the same compliance state, and this CVE makes the difference operationally sharp rather than academic. The mitigated instance still runs an affected release and still reports an affected version, so nothing in its self-description distinguishes it from an unremediated one; and because the mitigation is the absence of a file rather than a change to the code, any operation that rebuilds the deployment from its original artifact — redeploying the WAR, rebuilding the container image, installing an extension that pulls the module back — silently restores unauthenticated remote code execution with no new CVE, no version change, and no failed control test. The audit verdict for such an instance must therefore be recorded as a compensating-control state carrying a time-bound action item to reach a fixed release, never as \"patched per SLA\". The distinguishing test for this deployment: redeploy a mitigated instance through its normal build-and-release pipeline, then confirm the gt-complex jar is still absent afterwards — an estate that verified the removal once, by hand, has verified nothing about the state its pipeline will produce tomorrow.",
+        "evidence": "Packet vector: workaround is \"removing the `gt-complex-x.y.jar` file from the GeoServer\", which \"will remove the vulnerable code from GeoServer but may break some GeoServer functionality or prevent GeoServer from deploying if the gt-complex module is needed\", while the fix is \"Versions 2.22.6, 2.23.6, 2.24.4, and 2.25.2\". patch_available: true; live_patch_available: false. CISA KEV 2024-07-15 with active_exploitation confirmed; attack_vector: \"An unauthenticated attacker sends an OGC request (WFS/WMS/WPS) whose property name is a JXPath expression; GeoServer evaluates it via the GeoTools/commons-jxpath path and executes arbitrary code.\"",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "This CVE carries two distinct false-clean traps, and the packet names both. The first is scoping: the XPath evaluation was intended only for complex feature types (Application Schema data stores) but is applied to simple feature types as well, which is why the advisory states the vulnerability applies to ALL GeoServer instances including a default installation — so an assessment that excluded the estate's simple-feature deployments as \"not the affected configuration\" excluded nothing real. The second is version reading: the vulnerable code is in the GeoTools library GeoServer calls, whose jar version numbering differs from the GeoServer release it ships with (gt-complex-31.1.jar on GeoServer 2.25.1), and a jar-removal-mitigated host still advertises an affected GeoServer version. Version-string scanning therefore misreports in both directions on this product. The operational test that separates paper compliance from a demonstrated result: submit a property name containing a benign JXPath expression through each of the six request types the advisory confirms as exploitable — WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic and WPS Execute — against a staging instance and confirm none of them evaluates it. A scan report keyed on the GeoServer banner alone has not tested any of those paths.",
+        "evidence": "Packet vector: \"This XPath evaluation is intended to be used only by complex feature types (i.e., Application Schema data stores) but is incorrectly being applied to simple feature types as well which makes this vulnerability apply to **ALL** GeoServer instances\"; \"this vulnerability has been confirmed to be exploitable through WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic and WPS Execute requests\"; \"The GeoTools library API that GeoServer calls evaluates property/attribute names for feature types in a way that unsafely passes them to the commons-jxpath library\"; workaround jar named as `gt-complex-31.1.jar` for GeoServer 2.25.1. CISA KEV 2024-07-15, active_exploitation confirmed, CVSS 9.8.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-23692": {
     "name": "Rejetto HTTP File Server Template Engine Injection Vulnerability",
@@ -39282,7 +40931,30 @@
         "adequate": false,
         "gap": "SI-2 flaw remediation has no vendor patch to apply for EoL HFS 2.3m; only decommission/migration mitigates."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "For Rejetto HFS there is no remediation to schedule. The packet records no vendor fix, no live-patch path, and the product unsupported at and below 2.3m as of the CVE assignment date, so exposure that persists is exposure no future maintenance window will ever close — the usual vulnerability-management response of assigning a patch due date produces a register entry that can never be satisfied. What this control means for this product: enumerate every HFS instance at 2.3m or earlier, including the ones nobody registered as a service, because HFS is characteristically stood up ad hoc to hand a file to somebody and then left running; take its HTTP listener off every untrusted network immediately, which for these hosts usually means withdrawing a router port-forward or firewall publish rather than reconfiguring the application; and set a dated commitment to replace it with a supported file-transfer product and remove the binary. Reachability is the whole exploit precondition here — the request that runs commands carries its payload in the search parameter with an empty Host header to defeat filtering and needs no credential at all, so any instance that answers an HTTP request from an untrusted network is exploitable by anyone who can reach it. Segmentation is the mandatory interim state, not a substitute for removal; leaving a confirmed-exploited unpatchable service behind a firewall indefinitely converts a temporary compensating control into a permanent accepted breach path.",
+        "evidence": "Packet: patch_available false; live_patch_available false; live_patch_notes \"End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.\" vector: \"Rejetto HTTP File Server, up to and including version 2.3m, is vulnerable to a template injection vulnerability. This vulnerability allows a remote, unauthenticated attacker to execute arbitrary commands on the affected system by sending a specially crafted HTTP request. As of the CVE assignment date, Rejetto HFS 2.3m is no longer supported.\" attack_vector: \"An unauthenticated attacker sends an HTTP request whose 'search' parameter contains HFS template macros with an empty Host header to bypass filtering; the server evaluates the injected {.exec.}/{.chr.} macros and runs arbitrary OS commands.\" CISA KEV 2024-07-09, active_exploitation confirmed, CVSS 9.8, RWEP 81, poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This CVE is the case the three-state verdict exists for, because the state every framework treats as the destination — binary patch deployed — is permanently unavailable. The packet gives no vendor fix and an unsupported product, so an HFS instance can only ever occupy the compensating-control state (network isolation holding the unauthenticated macro-injection path out of reach) or the full-exposure state, and the compliance record has to say which, with a decommission date attached. The failure this control prevents is procedural rather than technical: a register that records \"remediation blocked pending vendor patch\" for an unsupported product produces an entry that renews quietly at every review, reads as diligence, and never escalates, while the service stays reachable and confirmed-exploited. The distinguishing test: query the vulnerability register for every entry whose remediation is blocked on a vendor fix, and check each against the product's support status — any entry for an unsupported product that carries a patch due date instead of a decommission date is a finding, because the due date describes an event that will not occur.",
+        "evidence": "Packet: patch_available false; live_patch_available false; live_patch_notes \"End-of-life or unpatched product with no vendor fix and no live-patch path; isolate or decommission affected systems.\" vector: \"As of the CVE assignment date, Rejetto HFS 2.3m is no longer supported.\" CISA KEV 2024-07-09 with active_exploitation confirmed and poc_available true; RWEP 81, CVSS 9.8.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-38080": {
     "name": "Microsoft Windows Hyper-V Privilege Escalation Vulnerability",
@@ -39319,7 +40991,31 @@
         "adequate": false,
         "gap": "Least-privilege limits initial access but cannot stop a local user from escalating to SYSTEM once this Hyper-V integer overflow is reachable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-068",
+        "name": "HYPERVISOR-VM-ESCAPE-TENANCY-ASSUMPTION",
+        "description": "A Hyper-V host cannot inherit the ordinary Windows-server patch tier. Per the packet, a local attacker who already has code execution as a standard user triggers an integer overflow (CWE-190) in Hyper-V and elevates to SYSTEM, which the packet characterizes as full host compromise — and a compromised virtualization host takes every guest running on it with it. The 24-hour KEV clock this control defines must therefore apply to Hyper-V hosts regardless of the tenancy story an estate tells itself: 'all of these VMs are ours' does not shrink the exposure, because the attacker's requirement is an unprivileged foothold anywhere on the host, not a hostile tenant. The packet states there is no live-patching primitive for this product and that the vendor update requires a reboot and is the remediation, so committing to the 24-hour tier means committing to drain, patch and reboot the host inside that window — staging the update on a host that keeps running does not stop the escalation.",
+        "evidence": "Packet: name 'Microsoft Windows Hyper-V Privilege Escalation Vulnerability', cwe_refs CWE-190, cisa_kev true, kev_date 2024-07-09, active_exploitation confirmed, cvss 7.8, rwep_score 53; attack_vector 'A local attacker who already has code execution as a standard user triggers an integer overflow in Windows Hyper-V to elevate to SYSTEM, enabling full host compromise.'; patch_available true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "Exploitation of this flaw has a precondition the packet states plainly: the attacker must already be running code as a standard user on the Hyper-V host itself. A virtualization host belongs in the elevated tier this control defines for other fleet-control planes, because one host carries every guest scheduled onto it — which means no unprivileged interactive session, no general-purpose user workload, and no low-tier service principal should be able to execute code on it at all. Access to the host should come from PAM jumphosts and dedicated privileged workstations, with per-session step-up and just-in-time elevation, and host-admin identities kept separate from application-admin identities. Generic least-privilege wording does not forbid a standard user having a session on a hypervisor; naming virtualization hosts as their own tier does, and that removes the foothold this integer overflow needs. The packet records no public PoC, so exploit-signature coverage is unlikely to catch the escalation — denying the precondition is the control that survives that.",
+        "evidence": "Packet: attack_vector 'A local attacker who already has code execution as a standard user triggers an integer overflow in Windows Hyper-V to elevate to SYSTEM, enabling full host compromise.'; poc_available false; active_exploitation confirmed; cisa_kev true, kev_date 2024-07-09.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2024-38112": {
     "name": "Microsoft Windows MSHTML Platform Spoofing Vulnerability (CVE-2024-38112)",
@@ -39800,7 +41496,39 @@
         "adequate": false,
         "gap": "Boundary protection is undermined because the vulnerable component IS the boundary device; SC-7 assumes the gateway is trustworthy, but the traversal turns the VPN concentrator into an unauthenticated file-read oracle."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A Check Point Quantum Security Gateway is not a server behind the boundary, it is the boundary, and the packet places the vulnerable MyCRL endpoint on the internet-facing surface of gateways running the Remote Access VPN or Mobile Access blades. This control's tier therefore governs: vendor fix deployed within hours of the KEV listing, or isolation of the vulnerable interface -- meaning the remote-access and mobile-access portal taken out of service -- as the interim, rather than the standard multi-week appliance-patch window that would otherwise apply. Two packet facts shape how the tier runs on this product. First, the vendor update requires a reboot and there is no live-patching primitive for this product, so the tier's clock cannot stop at 'hotfix installed'; it stops at 'gateway restarted', because until then the vulnerable endpoint is still being served. Second, the exposure is conditioned on which blades are enabled, so the tier's opening action is enumerating which gateways are internet-connected with Remote Access VPN or Mobile Access enabled -- that list bounds the interim exposure and tells the operator which units must be isolated if the reboot cannot happen immediately. Distinguishing test: ask the operator to produce, within the tier's own window, the list of internet-facing gateways with those blades enabled and the restart timestamp for each; an appliance-patching programme that can only report a change-ticket queue has no tier for the device that terminates every remote-access session.",
+        "evidence": "Packet facts only: CISA KEV-listed 2024-05-30 with active_exploitation 'confirmed', poc_available true, CVSS 8.6 and RWEP 81. The vector records the exposure as affecting Check Point Security Gateways 'once connected to the internet and enabled with remote Access VPN or Mobile Access Software Blades', and states that a security fix mitigating the vulnerability is available. attack_vector: an unauthenticated attacker sends a path-traversal request to the gateway's MyCRL endpoint and reads arbitrary appliance files. patch_available is true; live_patch_available is false, with the live-patch note recording 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' The citing gaps include NIST SP 800-53 SC-7 boundary protection and NIS2 Art. 21 security of network and information systems -- controls that presume the boundary device itself is sound -- alongside AU Essential Eight patch operating systems.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This control normally fires on pre-auth RCE; here the primitive is a pre-auth arbitrary file read, and that difference makes the control more necessary rather than less, because the entire product of the exploit is secret material. Per the packet the attacker reads arbitrary appliance files and harvests credentials and configuration that enable follow-on VPN and lateral access -- so applying the vendor fix and rebooting closes the read path while leaving every secret already taken fully valid. For a gateway that sat internet-connected with Remote Access VPN or Mobile Access enabled before the fix landed, the runbook default must therefore be assume-exfiltrated: rotate the local account and administrative credential material the gateway holds, re-issue the certificate and key material it stores, treat the stored VPN configuration as known to the attacker, and reset any directory or authentication-service credentials the gateway was configured with -- ahead of, or alongside, the reboot rather than after a subsequent incident. Follow-on access on this path arrives as a successful remote-access authentication using real credentials, which is why closing the vulnerability does not close the incident. Distinguishing test: choose one gateway that was exposed before remediation and ask which specific secrets it held and when each was last rotated; if the answer is 'we installed the fix and rebooted', the disclosure has been stopped without being remediated, and the framework's flaw-remediation control has recorded a closure the attacker's stolen credentials do not honour.",
+        "evidence": "Packet facts only: attack_vector states the unauthenticated path-traversal request against the MyCRL endpoint lets the attacker read arbitrary appliance files, 'harvesting credentials and configuration that enable follow-on VPN/lateral access'. CWE-200 information disclosure -- not remote code execution. CISA KEV-listed 2024-05-30 with active_exploitation 'confirmed' and poc_available true, RWEP 81 against CVSS 8.6. patch_available true; live_patch_available false, with the note that the vendor update requires a reboot and is the remediation -- i.e. the packet records remediation of the flaw, not of the disclosure it already produced. Citing gaps NIST SP 800-53 SI-2 flaw remediation and ISO/IEC 27001:2022 A.8.8 technical-vulnerability management both treat the fix as the terminal state.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "On this CVE the only record that a given gateway's MyCRL endpoint was requested -- and which appliance files came back -- is generated by the gateway itself, the same device the unauthenticated attacker is reading arbitrary files from. Once the harvested credentials are replayed, the follow-on step the packet describes surfaces as an ordinary successful remote-access VPN authentication, which is invisible unless the authentication record is held and queried somewhere the gateway's own state cannot influence. Applied to this product, the control means the gateway's request-level logs and its remote-access authentication logs are forwarded continuously to a SIEM in a separate trust zone -- different management plane, different credentials, different authentication path -- so that after a KEV listing the operator can retrospectively answer two questions across the whole fleet: was this endpoint requested on any gateway before the reboot completed, and which accounts authenticated through remote access afterwards from new locations or at anomalous times. That retrospective window is the whole value here, because the KEV listing arrives after exploitation, and the packet's citing gap is precisely that security monitoring is not carrying this. Distinguishing test: take a gateway's local log store out of the picture entirely and confirm both questions can still be answered from the off-box collector, for the period preceding the reboot -- a monitoring attestation resting on the gateway's own log retention cannot scope an incident whose first act was reading that gateway's files.",
+        "evidence": "Packet facts only: the vulnerable surface is the gateway's MyCRL endpoint, reachable unauthenticated, and the recorded outcome is reading arbitrary appliance files to harvest credentials and configuration enabling follow-on VPN/lateral access. CISA KEV-listed 2024-05-30, active_exploitation 'confirmed', poc_available true -- exploitation preceded the listing, so the operator's question is retrospective. live_patch_available false with the note that the vendor update requires a reboot, so a detection window exists between the KEV listing and the completed restart of every affected gateway. UK NCSC CAF C1 security monitoring is cited as an insufficient control on this entry.",
+        "gap_closes": [
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2024-4978": {
     "name": "JAVS Viewer Installer Embedded Malicious Code Vulnerability",
@@ -41173,7 +42901,31 @@
         "adequate": false,
         "gap": "Application-hardening baselines do not disable or restrict the Microsoft Streaming Service driver, leaving the vulnerable IOCTL/KS path reachable by any local user."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet's path for this flaw starts from an ordinary local process and ends at SYSTEM: a user-mode caller drives the mskssrv.sys streaming driver into dereferencing an attacker-controlled pointer, which yields a kernel write primitive. That makes the account-privilege posture most estates are audited on — standard users, no local administrators, least privilege attested — a boundary this flaw does not have to cross, so it cannot be the containment story while the fix is outstanding. The second half matters more for scheduling: the packet states there is no vendor live-patch mechanism and that remediation requires applying the fixed release and rebooting, which means exposure does not end when the update is pushed, it ends when each host restarts. A fleet reporting successful deployment while machines sit unrestarted is still exploitable on every one of them. Run the clock from the KEV listing date to completed reboot per host rather than to deployment-tool success, enumerate the fleet's actual installed builds against the fixed build for each SKU, and treat any host that has taken the update but not the restart as unremediated in the compliance record rather than as compliant-pending-reboot.",
+        "evidence": "Packet: attack_vector \"A local process drives the mskssrv.sys streaming driver to dereference an attacker-controlled pointer, converting a user-mode foothold into a kernel write primitive and SYSTEM privileges.\"; vector \"Microsoft Streaming Service Elevation of Privilege Vulnerability\"; CWE-822. patch_available true; live_patch_available false; live_patch_notes \"No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.\" CISA KEV 2024-02-29, active_exploitation confirmed, CVSS 8.4, RWEP 77, poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-AC-6",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "Because the packet ties remediation to a reboot of every affected endpoint and records confirmed in-the-wild exploitation with a PoC available, this estate has a detection-only window whose length is set by its restart schedule rather than by how fast the update is pushed — and monitoring is the citing gap the packet names. On a Windows fleet the telemetry source is the EDR/ETW equivalent of the auditd or eBPF rules this control is usually expressed in: alert on a local, unprivileged process obtaining a handle to the Microsoft Streaming Service device, and on a subsequent token or integrity-level change to SYSTEM within the same process lineage. That pairing is what the packet's path actually produces — the user-mode foothold reaching the driver, then the kernel write cashing out as SYSTEM — and detecting only the second half means detecting the escalation after it has already succeeded, at whatever point the follow-on payload becomes noisy enough for signature-based tooling to notice. The rule has to be live for the whole reboot window and its coverage checked against the same host list used for the build enumeration, so unrestarted hosts are the ones being watched most closely rather than the ones nobody has instrumented.",
+        "evidence": "Packet: attack_vector \"A local process drives the mskssrv.sys streaming driver to dereference an attacker-controlled pointer, converting a user-mode foothold into a kernel write primitive and SYSTEM privileges.\"; live_patch_notes \"No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.\"; live_patch_available false. CISA KEV 2024-02-29 with active_exploitation confirmed and poc_available true; RWEP 77, CVSS 8.4. Citing gap in the packet: UK-CAF-C1 \"Security monitoring\" (UK NCSC Cyber Assessment Framework v3.2).",
+        "gap_closes": [
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2020-3259": {
     "name": "Cisco ASA and FTD Information Disclosure Vulnerability",
@@ -41596,7 +43348,41 @@
         "adequate": false,
         "gap": "System-security assurance credits hardware mitigations like PAC; this flaw defeats that mitigation, so control coverage over-relies on the bypassed protection."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Apple shipped this fix as an OS release across five product families at once — macOS Ventura 13.1, watchOS 9.2, iOS 16.2, iPadOS 16.2 and tvOS 16.2 — and the packet records no live-patch mechanism, so every affected device has to be carried through the update and rebooted before the defect is gone. Enforce the fixed build from the device-management channel with user deferral disallowed rather than by prompting the user, and make the enrolment scope cover the watchOS and tvOS members of the estate, which patch-compliance programs built around laptops and phones routinely leave out while the same defect sits on them. The clock runs from the KEV listing, not from the next device-refresh window, because the remediation the packet describes is a reboot the operator has to schedule rather than a silent background fix.",
+        "evidence": "Packet vector: \"This issue is fixed in macOS Ventura 13.1, watchOS 9.2, iOS 16.2 and iPadOS 16.2, tvOS 16.2.\" patch_available true; live_patch_available false with live_patch_notes \"No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.\" cisa_kev true, kev_date 2024-01-31, active_exploitation confirmed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Treat the fixed build as an access condition for organizational data rather than a reporting metric: a Mac, iPhone, iPad, Watch or Apple TV still below macOS Ventura 13.1 / watchOS 9.2 / iOS 16.2 / iPadOS 16.2 / tvOS 16.2 is denied or quarantined from mail, VPN and document access until it takes the update. The distinction matters more than usual for this defect because what it removes is Pointer Authentication — a mitigation whose entire job is to stop an attacker who already holds arbitrary kernel read/write from converting that into reliable control. A device left below the fixed build is therefore not simply unpatched; it has lost the mitigation that would otherwise blunt the rest of the chain, and no downstream detection replaces it. Distinguishing test: enrol a device pinned below the fixed build and confirm the policy actually refuses it protected resources, rather than listing the stale build on a dashboard while the device keeps its access.",
+        "evidence": "Packet vector: \"An attacker with arbitrary read and write capability may be able to bypass Pointer Authentication.\" attack_vector: \"Within an exploit chain, code that already holds arbitrary kernel read/write wins a time-of-check/time-of-use race to defeat Pointer Authentication, removing a key mitigation and enabling reliable kernel-level control on the device.\" CWE-367; RWEP 57 with CVSS 7.0; active_exploitation confirmed; fixed releases named in the packet vector.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet does not describe a standalone bug reachable on its own — it is a step inside a chain whose precondition is arbitrary kernel read/write already held, and the exploitation signal is Apple's own report against iOS releases predating iOS 15.7.1 with no public PoC, which is the targeted-implant profile rather than commodity malware. For the population plausibly inside that targeting set — executives, journalists, legal and security staff — place devices in the platform's reduced-attack-surface mode where the OS version supports it, so untrusted web content, message attachments, fonts and link previews are not processed automatically. That narrows the delivery path for the earlier chain stages that must land before this PAC bypass is reachable at all, which is the only lever available while devices wait on a reboot-gated update. It has to be a standing assignment made before the next disclosure, not a reaction to this CVE — the mode only helps if it was already on when the chain arrived.",
+        "evidence": "Packet vector: \"Apple is aware of a report that this issue may have been exploited against versions of iOS released before iOS 15.7.1.\" attack_vector places the flaw \"[w]ithin an exploit chain\". poc_available false while active_exploitation is confirmed. live_patch_available false; remediation per live_patch_notes requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-21893": {
     "name": "Ivanti Connect Secure, Policy Secure, and Neurons Server-Side Request Forgery (SSRF) Vulnerability",
@@ -43148,7 +44934,31 @@
         "adequate": false,
         "gap": "Mobile-device hardening controls rarely account for a GPU-driver LPE that undoes app-sandbox isolation once a malicious app is already present."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "This is a confirmed-exploited local privilege escalation reached from an ordinary unprivileged application through a GPU driver IOCTL, and the packet records no vendor live-patch mechanism — remediation is applying the fixed release and rebooting. For this CVE that means the fixed release is driven across the affected estate on the KEV clock rather than folded into the next routine device-update cycle, and the reboot is treated as part of remediation rather than as a follow-up, since an installed-but-not-restarted device is still running the vulnerable kgsl code. Because the packet scopes the defect to multiple Qualcomm chipsets rather than one product, the enforcement has to enumerate the fixed build per affected device model and confirm zero devices remain below it past the due date; a single fleet-wide 'up to date' figure hides the models whose fixed release has not been taken. The control's second clause is the one that matters most here: account-privilege policy is not containment, because the packet's attacker is already an unprivileged local application, so restricting administrative rights changes nothing about the escalation path. The distinguishing test is a per-model build enumeration against the fixed release with a hard deadline, not a patch-compliance percentage.",
+        "evidence": "Packet attack_vector: 'A local, already-present unprivileged application issues a crafted IOCTL to the Adreno GPU (kgsl) driver; an integer overflow during shared-virtual-memory assignment corrupts kernel memory and escalates privileges, typically as one stage of a mobile exploit chain.' Entry name 'Qualcomm Multiple Chipsets Integer Overflow Vulnerability'; CWE-190; CVSS 7.8; RWEP 53. cisa_kev true, kev_date 2023-12-05, active_exploitation 'confirmed'. patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's trigger is a locally installed unprivileged application issuing a crafted IOCTL, so on any device that has not yet taken the fixed release the operator's only remaining lever is constraining what code gets to run at all — restricting installation of untrusted or side-loaded applications, and denying the device access to organizational data rather than listing it on a patch-compliance report. For this CVE the fixed release for each affected chipset must be an access condition: a device below it is quarantined from mail, VPN and document access instead of being flagged for later. That is what the citing least-functionality gap actually demands on this vector, and it is the half of the control that does the work here, because the escalation path does not need network reachability or elevated rights — it needs an app on the device. The distinguishing test is to enrol a device pinned below the fixed release for its chipset and confirm the policy denies 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, and the packet describes this flaw as one stage of a chain, which means the device that keeps its access is the one that carries the rest of the chain inside the trust boundary.",
+        "evidence": "Packet attack_vector: 'A local, already-present unprivileged application issues a crafted IOCTL to the Adreno GPU (kgsl) driver ... corrupts kernel memory and escalates privileges, typically as one stage of a mobile exploit chain.' Packet vector: 'Memory corruption in Graphics Linux while assigning shared virtual memory region during IOCTL call.' Citing gap NIST-800-53-CM-7 (Least Functionality) is recorded as insufficient for this entry. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' poc_available false.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-33106": {
     "name": "Qualcomm Multiple Chipsets Use of Out-of-Range Pointer Offset Vulnerability",
@@ -44072,7 +45882,33 @@
         "adequate": false,
         "gap": "Patching within the ISM window helps, but the control does not mandate restricting the J-Web management interface that is the actual attack surface."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "The vulnerable surface here is J-Web, the optional web management front end on EX Series switches — the device forwards traffic without it — and the packet's only remediation is applying a fixed Junos release and rebooting, which on an access-layer switch is a service outage the operator has to schedule. That gap between disclosure and reboot window is precisely when an unauthenticated, network-reachable request path stays open. Inventory and pre-test the configuration-side path so it is deployable independently of the Junos upgrade schedule: the J-Web HTTP/HTTPS management service turned off on units that do not need it, and restricted to a management network on the units that do. Exposure then ends at a config commit instead of at the next maintenance window. Track which units are running on the configuration-side mitigation versus which are on the fixed release — those are two different states, and a fleet report that merges them hides how many devices still carry the reachable code path.",
+        "evidence": "Packet vector: \"A PHP External Variable Modification vulnerability in J-Web of Juniper Networks Junos OS on EX Series allows an unauthenticated, network-based attacker to control certain, important environment variables.\" patch_available true; live_patch_available false with live_patch_notes \"No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.\" The entry's own citing framework gaps name NIST 800-53 CM-7 Least Functionality and SC-7 Boundary Protection.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIST-800-53-SC-7",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This flaw is not the end state the operator is defending against — the packet describes it being chained with other J-Web flaws toward pre-auth remote code execution, carrying a public PoC and confirmed in-the-wild exploitation. Any EX Series unit whose J-Web interface was reachable during the exposure window has to be handled as potentially implanted, not merely unpatched: capture the running and candidate configuration for comparison against a known-good baseline, rebuild from a vendor image rather than upgrading in place, and rotate every credential the device held or authenticated — local administrative accounts, shared secrets, and any key material sitting in the configuration. Upgrading in place closes the request path and leaves untouched whatever was written through it beforehand, which is exactly the outcome a vulnerability-management attestation records as remediated. The gap is that the frameworks cited here are satisfied by the version bump alone.",
+        "evidence": "Packet attack_vector: \"An unauthenticated attacker sends crafted J-Web requests that modify PHP environment variables, causing partial integrity loss that is chained with other J-Web flaws toward pre-auth remote code execution.\" cisa_kev true, kev_date 2023-11-13, active_exploitation confirmed, poc_available true. RWEP 76 against CVSS 5.3 — the base score reflects the packet's \"partial loss of integrity\" wording while the real-world priority reflects the chain, so CVSS-driven triage under-ranks this entry.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-36845": {
     "name": "Juniper Junos OS EX/SRX J-Web PHPRC Modification RCE",
@@ -44372,7 +46208,29 @@
         "adequate": false,
         "gap": "Configuration management does not flag internet-reachable SLP as a non-compliant baseline, so exposed directory agents pass audit while remaining exploitable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The distinguishing feature of this SLP flaw is that the exposed host is the weapon, not the target -- an unauthenticated attacker registers arbitrary services with a reachable SLP directory agent and then sends small spoofed-source SrvReq packets so the oversized responses land on someone else. That means the usual reason to move slowly (my own service is fine, so the risk is mine to accept) does not hold, and the mitigation clock has to run from the 2023-11-08 KEV listing regardless of the owning team's own availability posture. The packet gives two acceptable ways to stop the clock: the vendor fixed release, or a documented compensating control that makes the SLP directory agent unreachable from untrusted networks -- there is no live-patch option, so a host that can still answer a spoofed SrvReq from the internet is unmitigated no matter what the patch ticket says.",
+        "evidence": "Packet vector: SLP (RFC 2608) 'allows an unauthenticated, remote attacker to register arbitrary services ... use spoofed UDP traffic to conduct a denial-of-service attack with a significant amplification factor'; attack_vector describes an exposed SLP directory agent reflecting oversized responses at a victim with 'a very high amplification factor'. cisa_kev true, kev_date 2023-11-08, active_exploitation 'confirmed', poc_available true, CVSS 7.5, RWEP 68. patch_available true; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "Because the packet says there is no live-patch mechanism and remediation requires the vendor fixed release, most estates spend a long interval in the middle state: the SLP directory agent has been disabled or made unreachable from untrusted networks, but the fixed release is still queued behind an appliance or host maintenance window. That interim state is a configuration, and configurations revert -- a firmware update, a rebuilt host, or a new instance cloned from an older image quietly restores a listener that will again answer spoofed SrvReq packets and reflect amplified traffic at a third party, with no ticket open because the audit already recorded the CVE as handled. The verdict for this CVE must therefore distinguish 'running the vendor fixed release' from 'reachability blocked, fix pending', and the latter must carry a time-bound action item plus drift detection on the blocking configuration, rather than rolling up as remediated-per-SLA.",
+        "evidence": "Packet: patch_available true and live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' Attack path per attack_vector is an exposed SLP directory agent that reflects oversized responses at a victim after an unauthenticated attacker registers arbitrary services. KEV-listed 2023-11-08 with active_exploitation 'confirmed' and poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.9"
+        ]
+      }
+    ]
   },
   "CVE-2023-22518": {
     "name": "Atlassian Confluence Data Center and Server Improper Authorization Vulnerability",
@@ -45569,7 +47427,32 @@
         "adequate": false,
         "gap": "System security expects a trustworthy code-integrity anchor, but this flaw defeats the code-signature trust anchor itself, so the control's assumption is invalid until patched."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Both halves of this control are load-bearing here, because the trigger the packet names is a malicious application defeating code-signature validation. First, make macOS Ventura 13.6 / iOS 16.7 / iPadOS 16.7 an access condition: a device below it is denied or quarantined from organizational mail, VPN and documents rather than listed on a patch-compliance report. Second, on any device that cannot yet take the fixed build, constrain what code is permitted to run at all — installation restricted to the managed application catalogue, no side-loading, and no enterprise or developer provisioning profiles beyond the ones the estate itself issues. Signature validation is the platform mechanism that normally makes \"only approved code runs\" true, and this defect is that mechanism failing, so while devices sit below the fixed build the enforcement has to come from the management layer instead. Distinguishing test: enrol a device pinned below the fixed build and confirm it is actually refused protected resources.",
+        "evidence": "Packet vector: \"A malicious app may be able to bypass signature validation. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.\" Fixed releases named in the packet: macOS Ventura 13.6, iOS 16.7 and iPadOS 16.7. CWE-295 improper certificate validation; attack_vector describes bypassing code-signature checks so unsigned code runs as part of a chained exploit. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The fix ships only as an OS release — macOS Ventura 13.6, iOS 16.7, iPadOS 16.7 — with no live-patch path, so remediation across the Apple estate is a reboot on every device and nothing lands silently in the background. Drive it from the device-management channel on the KEV clock with user deferral disallowed, because this is the update class users postpone longest: a certificate-validation fix produces no symptom the user can perceive, so the reboot is the only part of it they experience. Hold the macOS half of the estate to the same clock as the phones — a Ventura Mac below 13.6 carries the same signature-validation bypass as an iPhone below iOS 16.7, and it is typically the population left on a user-driven update cadence while the mobile fleet is centrally enforced.",
+        "evidence": "Packet vector: \"This issue is fixed in macOS Ventura 13.6, iOS 16.7 and iPadOS 16.7.\" cisa_kev true, kev_date 2023-09-25, active_exploitation confirmed. live_patch_available false with live_patch_notes \"No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.\" poc_available false — the exploitation signal is Apple's own report, not a published exploit.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-41992": {
     "name": "Apple Multiple Products Kernel Privilege Escalation Vulnerability",
@@ -53963,7 +55846,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "id": "NEW-CTRL-128",
         "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
         "description": "Application servers that expose binary remoting protocols (Oracle WebLogic T3/IIOP, and equivalents) must restrict those protocols to trusted hosts and apply vendor critical patch updates on an accelerated schedule when a remoting flaw is KEV-listed. Place T3/IIOP behind a connection filter (weblogic.security.net.ConnectionFilterImpl) or network ACLs so only known hosts can reach them, never expose the ports to untrusted networks, and apply the Oracle CPU bundle (with server restart) rather than deferring to the next quarterly window. The distinguishing test: from an untrusted network segment, attempt an unauthenticated T3/IIOP connection to a staging WebLogic instance and confirm it is refused at the connection filter before any data is served - a perimeter-firewall + quarterly-patch policy that still leaves T3/IIOP reachable from an internal untrusted segment leaves the unauthenticated data-access path open.",
         "evidence": "CVE-2026-34486 needs only network reach to the Tomcat Tribes cluster receiver (default TCP 4000), where a framed membership packet lands in ObjectInputStream.readObject() with no ObjectInputFilter and a Commons Collections chain runs as the Tomcat user. The remediation is exactly this control's shape: restrict TCP 4000 to cluster members or disable clustering now, then replace the JARs with 11.0.21 / 10.1.54 / 9.0.117 and restart the JVM on every node rather than waiting for a routine window.",
@@ -54849,7 +56732,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "ERP-MGMT-PLANE-CRITICAL-FUNCTION-AUTH",
+        "id": "NEW-CTRL-129",
         "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
         "description": "An enterprise ERP platform (Oracle PeopleSoft, Oracle E-Business Suite, SAP, and similar) must authenticate every management-plane and environment-management function before it can be invoked, and must not expose any takeover-capable function to an unauthenticated network caller. Segment the ERP management surface from untrusted networks and place it behind authenticated access control. The distinguishing test: send an unauthenticated network request to each environment-management / configuration endpoint on a staging instance and confirm it is refused before any privileged action runs - paper 'ERP access control' policies that attest user-login authentication while leaving a critical management function reachable without credentials still permit unauthenticated takeover.",
         "evidence": "CVE-2022-21587 lets an unauthenticated multipart POST to /OA_HTML/BneUploaderService and its three sibling Bne*Service servlets on Oracle E-Business Suite 12.2.3-12.2.11 write a file anywhere the application tier can reach, because all four inherit from BneAbstractXMLServlet and require no session, token or credential. AC-3 has no authenticated subject to evaluate here, so an EBS deployment with fully modelled roles and segregation of duties still hands an anonymous HTTP client an arbitrary file write on the ERP tier.",
@@ -54921,7 +56804,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "ECOMMERCE-EXTENSION-DESERIALIZATION-GUARD",
+        "id": "NEW-CTRL-133",
         "name": "ECOMMERCE-PLATFORM-EXTENSION-UNTRUSTED-DESERIALIZATION-GUARD",
         "description": "An e-commerce platform (Magento / Adobe Commerce and similar) and every third-party extension it loads must never pass request-supplied data (cookies, headers, body, query parameters) to a native deserialization function (PHP unserialize(), and equivalents in other runtimes) on an unauthenticated storefront request path. Patch-management and secure-coding programs must enumerate every installed extension as part of the storefront's code-execution surface, not only the core platform. The distinguishing test: send an unauthenticated storefront request carrying a crafted serialized object in each cookie / header an extension reads, on a staging store, and confirm it is rejected before any deserialization runs - paper 'platform patched' attestations that ignore the installed extensions still permit unauthenticated RCE through an extension's object-injection sink.",
         "evidence": "CVE-2023-22952 carries a PNG with appended PHP through SugarCRM's module=EmailTemplates&action=AttachFiles handler onto /cache/images/ and executes it as www-data on refetch — request-supplied content reaching an in-process code-execution sink in a purchased PHP business platform, on a path the loadUser() session-handling defect makes effectively unauthenticated. SI-10 is assessed at design level for systems the organisation builds, so only a programme that enumerates the bought platform's whole request-handling surface as code-execution surface — rather than attesting 'platform patched' — reaches this upload handler.",
@@ -55155,7 +57038,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-CONTROLPANEL-PLUGIN-PRIVILEGE-SEPARATION",
+        "id": "NEW-CTRL-135",
         "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
         "description": "On a multi-tenant hosting control panel (cPanel/WHM and similar), no function reachable from the unprivileged user-end plugin surface may execute as root or run tenant-supplied scripts with host privileges. Privileged operations must live behind an administrative trust boundary with their own authorization, and the user-facing surface must only request them through a constrained, validated interface. The distinguishing test: from an ordinary tenant account on a staging panel, invoke each user-end plugin function (including enable/disable and configuration calls) with a payload that attempts a root-level action, and confirm the action is refused before any privileged code runs - a panel that passes an OS-hardening audit but wires a tenant-callable function to a root operation still grants user-to-root escalation.",
         "evidence": "CVE-2022-44877 injects shell metacharacters through the login parameter of CWP's /login/index.php and the command runs as root, because the multi-tenant hosting panel's whole request-handling surface — including the pre-authentication login page — executes in a root context. UK CAF B4 offers no secure-configuration lever here since that login page must stay internet-reachable for the shared-hosting customers it serves; separating the panel's caller-reachable functions from root operations is the only structural answer.",
@@ -55164,7 +57047,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-MDM-GATEWAY-UNAUTH-CONFIG-ENDPOINT-NEUTRALIZE-AND-CONTAIN",
+        "id": "NEW-CTRL-134",
         "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
         "description": "A device-management / MDM gateway (Ivanti Sentry, MobileIron, and similar) is a privileged root-execution surface at the network perimeter; every config/message endpoint must authenticate the caller and must neutralize OS-command input before any shell or process invocation, and the appliance must never be left unmanaged with externally reachable endpoints. Require: inventory all gateway HTTP endpoints, ensure they are managed (mTLS with the management server or restricted HTTPS) so config interfaces are not externally reachable, neutralize OS-command metacharacters at every message handler, and remediate any confirmed-exploited unauthenticated root RCE on a KEV-tied expedited clock with mandatory forensic triage of exposed instances. The distinguishing test: send an unauthenticated request carrying an OS-command metacharacter payload to each gateway config endpoint on a staging instance and confirm it is refused before any command runs — paper 'appliance hardened' policies that leave an unmanaged instance's config endpoint wired to a root command sink still permit unauthenticated root RCE.",
         "evidence": "CVE-2022-44877 is the same primitive this control governs on a different management surface: an unauthenticated request to a network-exposed management panel's own endpoint, whose failed-login value is written into a shell context unescaped so bash performs command substitution as root. SI-10 names the missing neutralization exactly but binds the operator's own system, and a deploying organisation running third-party CWP has no input-validation hook to insert ahead of the 0.9.8.1147 vendor fix.",
@@ -56086,7 +57969,7 @@
         ]
       },
       {
-        "id": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "id": "NEW-CTRL-130",
         "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
         "description": "Container hosts must treat the kernel - not the namespace boundary - as the last line of defense against a confined workload. Patch host kernels to the fixed release for each maintained series (with reboot) or apply a vendor live-kernel-patch, and layer compensating controls that block cgroups/namespace escapes even on an unpatched kernel: confine every container with AppArmor or SELinux and a seccomp profile, drop CAP_SYS_ADMIN, and disable unprivileged user namespaces where workloads do not need them. The distinguishing test: from inside a representative container on a staging host, attempt the release_agent escape (create user+cgroup namespaces, mount cgroupfs, write a payload path to release_agent, trigger cgroup release) and confirm it is refused before any code runs as root - a fleet that passes image-scan and RBAC audits but permits this on an unpatched, unconfined host still allows container-to-host root.",
         "evidence": "CVE-2021-3493 exists only because Ubuntu's downstream FS_USERNS_MOUNT patch lets an unprivileged user mount an overlay inside a user namespace that upstream Linux refuses outright, and the missing capability validation then attaches CAP_SETUID to a binary that runs privileged in the init namespace. The documented interim mitigation is this control's namespace clause exactly — kernel.unprivileged_userns_clone=0 or user.max_user_namespaces=0 — which removes the clone(CLONE_NEWUSER) primitive that no role assignment, sudoers restriction or CIS-hardened baseline constrains.",
@@ -56782,7 +58665,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2021-25337 is driven entirely by a locally installed untrusted app calling Samsung's exported SemClipboardProvider in system_server with no permission attribute, and the caller check that fixes it exists only in SMR Mar-2021 Release 1 or later — a carrier-staggered, reboot-bearing OEM update that Google Play system updates do not cover. Blocking handsets below that SMR level from organizational data and constraining side-loaded installs on devices that cannot yet reach it is the only operator-side lever, since no MDM policy or platform hardening setting affects the provider declaration.",
@@ -56864,7 +58747,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2021-25369 is remediated only by SMR Mar-2021 Release 1, whose fix deletes the sec_log duplicate of the kernel ring buffer outright, and delivery is OEM- and carrier-gated per model and per region. The exposed Exynos handsets are consumer hardware frequently outside enrolment entirely, so making the minimum security-patch level a condition of access to organizational data — rather than a dashboard field — is what removes vulnerable phones from corporate mail and VPN.",
@@ -56954,7 +58837,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2021-25370 has no configuration workaround — the vulnerable path is the ordinary DECON window-config ioctl the Exynos display stack uses in normal operation — and the fix exists only in SMR Mar-2021 Release 1 (SVE-2021-19925), which moves fd_install() to the end of decon_set_win_config. The escalation runs from a locally installed app that first obtains system_app context, so enforcing the minimum SMR level as an access condition and constraining side-loaded installs are the only levers an operator holds on the device.",
@@ -57591,7 +59474,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-PERIMETER-VPN-AUTH-BYPASS-EXPEDITED-PATCH",
+        "id": "NEW-CTRL-131",
         "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
         "description": "A remote-access VPN gateway (GlobalProtect, IKEv1/IKEv2 concentrators, SSL-VPN portals) is itself the authentication enforcement point for the network perimeter; an authentication-bypass flaw on that device must be remediated on a KEV-tied expedited clock, not the routine appliance-patch window. Require: enumerate every internet-facing VPN/portal authentication surface, subscribe to the vendor's advisory feed, apply vendor interim mitigations within hours of a confirmed-exploited auth bypass, and restrict gateway exposure to known client networks where feasible. The distinguishing test: on a staging gateway running the vulnerable release, send an unauthenticated request to the portal/gateway and confirm no VPN session or interior reachability is granted before authentication completes — paper 'VPN authentication enforced' policies do not detect a pre-credential bypass that grants an interior foothold.",
         "evidence": "CVE-2022-27518 is processed by the Citrix ADC / Gateway SAML SP/IdP handler before any authentication decision, so APT5 executes as administrator on the appliance that adjudicates MFA and session policy for every application federated behind it — Maturity Level 3 phishing-resistant MFA is reached only after the exploited code. Citrix's interim mitigation is deleting the samlAction / samlIdPProfile lines from ns.conf, an hours-scale gateway action that only exists if the internet-facing portal authentication surface has been enumerated and is governed on a KEV-tied clock rather than the routine appliance-patch window.",
@@ -57932,7 +59815,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "ERP-MGMT-PLANE-CRITICAL-FUNCTION-AUTH",
+        "id": "NEW-CTRL-129",
         "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
         "description": "An enterprise ERP platform (Oracle PeopleSoft, Oracle E-Business Suite, SAP, and similar) must authenticate every management-plane and environment-management function before it can be invoked, and must not expose any takeover-capable function to an unauthenticated network caller. Segment the ERP management surface from untrusted networks and place it behind authenticated access control. The distinguishing test: send an unauthenticated network request to each environment-management / configuration endpoint on a staging instance and confirm it is refused before any privileged action runs - paper 'ERP access control' policies that attest user-login authentication while leaving a critical management function reachable without credentials still permit unauthenticated takeover.",
         "evidence": "CVE-2021-35587 lets one unauthenticated HTTP POST to /oam/server/opensso/sessionservice take over Oracle Access Manager — the broker enforcing session policy, step-up authentication and authorisation for every Fusion Middleware application behind it — and the finders documented that takeover also permits creating users with arbitrary privileges, minting identities that satisfy the MFA control by construction. NIS2 Art.21(2)(d), CAF B2 and E8 MFA all measure identity outcomes on that broker; none requires that no takeover-capable function on it be reachable without credentials.",
@@ -57943,7 +59826,7 @@
         ]
       },
       {
-        "id": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "id": "NEW-CTRL-128",
         "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
         "description": "Application servers that expose binary remoting protocols (Oracle WebLogic T3/IIOP, and equivalents) must restrict those protocols to trusted hosts and apply vendor critical patch updates on an accelerated schedule when a remoting flaw is KEV-listed. Place T3/IIOP behind a connection filter (weblogic.security.net.ConnectionFilterImpl) or network ACLs so only known hosts can reach them, never expose the ports to untrusted networks, and apply the Oracle CPU bundle (with server restart) rather than deferring to the next quarterly window. The distinguishing test: from an untrusted network segment, attempt an unauthenticated T3/IIOP connection to a staging WebLogic instance and confirm it is refused at the connection filter before any data is served - a perimeter-firewall + quarterly-patch policy that still leaves T3/IIOP reachable from an internal untrusted segment leaves the unauthenticated data-access path open.",
         "evidence": "CVE-2021-35587 base64-decodes the requester attribute, recognises the 'object:' prefix and hands the bytes to Java deserialization of a WebLogic gadget chain with no class allowlist, so no SI-10 length, type, format or encoding check can reject it — Oracle conceded the point by deleting the 12c endpoint outright. The controls that do work are exactly this requirement's: restrict the WebLogic-hosted unauthenticated data path (/oam/server/opensso/*, TCP 14100) to known hosts, and apply the January 2022 Critical Patch Update with OPatch and a managed-server restart instead of waiting for the next quarterly window.",
@@ -58198,7 +60081,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-EOL-DEVICE-RETIREMENT",
+        "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
         "description": "Every network-attached embedded device (IP cameras, video servers, NVRs, routers, print/scan appliances) must carry an end-of-support date in the asset inventory, and any device past that date that exposes a remotely reachable management or media surface must be removed from untrusted networks and scheduled for replacement — patching is not an option once the vendor retires the model. The distinguishing test: query the asset inventory for devices whose firmware lifecycle has ended and whose management interface is reachable from an untrusted segment; any non-empty result that lacks a replace-or-formally-risk-accept decision is a finding. Paper patch-management policies that assume a fix always exists leave actively-exploited EOL devices (GeoVision IP cameras, recruited by Mirai-style botnets) on the network indefinitely.",
         "evidence": "CVE-2017-5521 — NETGEAR published fixed firmware for 19 router models in KB 30632 but left eight routers and four DSL gateways (AC1450, WNR1000v3, WNDR4000, DGN2200v4 and others) with no build at all, and CISA's KEV required action adds that any affected unit past end-of-life should be disconnected rather than kept in service. Only an inventory that carries each router's end-of-support date and forces a replace-or-risk-accept decision produces an action for those twelve models, because there is no vendor release to patch to.",
@@ -58280,7 +60163,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "NEW-CTRL-EOL-DEVICE-RETIREMENT",
+        "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
         "description": "Every network-attached embedded device (IP cameras, video servers, NVRs, routers, print/scan appliances) must carry an end-of-support date in the asset inventory, and any device past that date that exposes a remotely reachable management or media surface must be removed from untrusted networks and scheduled for replacement — patching is not an option once the vendor retires the model. The distinguishing test: query the asset inventory for devices whose firmware lifecycle has ended and whose management interface is reachable from an untrusted segment; any non-empty result that lacks a replace-or-formally-risk-accept decision is a finding. Paper patch-management policies that assume a fix always exists leave actively-exploited EOL devices (GeoVision IP cameras, recruited by Mirai-style botnets) on the network indefinitely.",
         "evidence": "CVE-2011-4723 — the DIR-300 stores its admin password unhashed inside firmware the operator cannot alter, D-Link phased the model out on 2013-05-15 with last date of support 2015-05-15, and CISA's required action for this KEV entry is disconnection rather than patching. Rotating the credential on a device still in service is pointless because the replacement is stored the same way, so only an end-of-support date in the asset inventory that forces replacement removes the exposure.",
@@ -58362,7 +60245,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2011-1823 — the vold SO_PASSCRED fix landed in AOSP on 2011-04-18 and shipped in Android 2.3.4, but reached a handset only when its OEM and carrier pushed an OTA, and GingerBreak was delivered by locally-installed repackaged apps (GingerMaster, DroidKungFu) on unenrolled personal devices. Reading the device build level and denying access below the fixed release — plus constraining side-loaded installs on handsets that will never update — is the only lever available when the fix exists upstream and never arrives on the device.",
@@ -58529,7 +60412,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "id": "NEW-CTRL-128",
         "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
         "description": "Application servers that expose binary remoting protocols (Oracle WebLogic T3/IIOP, and equivalents) must restrict those protocols to trusted hosts and apply vendor critical patch updates on an accelerated schedule when a remoting flaw is KEV-listed. Place T3/IIOP behind a connection filter (weblogic.security.net.ConnectionFilterImpl) or network ACLs so only known hosts can reach them, never expose the ports to untrusted networks, and apply the Oracle CPU bundle (with server restart) rather than deferring to the next quarterly window. The distinguishing test: from an untrusted network segment, attempt an unauthenticated T3/IIOP connection to a staging WebLogic instance and confirm it is refused at the connection filter before any data is served - a perimeter-firewall + quarterly-patch policy that still leaves T3/IIOP reachable from an internal untrusted segment leaves the unauthenticated data-access path open.",
         "evidence": "CVE-2022-24706 — CouchDB's packaging opened epmd on 4369/tcp plus an Erlang distribution listener bound to all interfaces on a port assigned at process start, and exploitation is an ordinary distribution handshake followed by an rex os:cmd/1 call. Restricting that binary remoting protocol to known hosts by network ACL is exactly the vendor's own 'firewall in front of all CouchDB installations' guidance, and it is the control a port-list baseline and a 5984-only segmentation review both structurally missed because the port is not fixed in configuration.",
@@ -59392,7 +61275,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-EOL-DEVICE-RETIREMENT",
+        "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
         "description": "Every network-attached embedded device (IP cameras, video servers, NVRs, routers, print/scan appliances) must carry an end-of-support date in the asset inventory, and any device past that date that exposes a remotely reachable management or media surface must be removed from untrusted networks and scheduled for replacement — patching is not an option once the vendor retires the model. The distinguishing test: query the asset inventory for devices whose firmware lifecycle has ended and whose management interface is reachable from an untrusted segment; any non-empty result that lacks a replace-or-formally-risk-accept decision is a finding. Paper patch-management policies that assume a fix always exists leave actively-exploited EOL devices (GeoVision IP cameras, recruited by Mirai-style botnets) on the network indefinitely.",
         "evidence": "CVE-2022-26258 sits on consumer routers that front home-worker broadband lines and unmanaged branch connections and therefore never appear in any scoped asset register, so the exposure is invisible until the device is enumerated: an inventory that carries an end-of-support date for every network-attached embedded device is what surfaces an EOL DIR-820L whose HTTP admin surface is reachable and forces the replace-or-formally-risk-accept decision.",
@@ -59567,7 +61450,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-EOL-DEVICE-RETIREMENT",
+        "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
         "description": "Every network-attached embedded device (IP cameras, video servers, NVRs, routers, print/scan appliances) must carry an end-of-support date in the asset inventory, and any device past that date that exposes a remotely reachable management or media surface must be removed from untrusted networks and scheduled for replacement — patching is not an option once the vendor retires the model. The distinguishing test: query the asset inventory for devices whose firmware lifecycle has ended and whose management interface is reachable from an untrusted segment; any non-empty result that lacks a replace-or-formally-risk-accept decision is a finding. Paper patch-management policies that assume a fix always exists leave actively-exploited EOL devices (GeoVision IP cameras, recruited by Mirai-style botnets) on the network indefinitely.",
         "evidence": "CVE-2018-7445 persists on MikroTik boards years after MikroTik confirmed the fix to Core Security on 2018-03-12, because the affected units are cheap branch CPE, lab kit and spare edge routers that no asset register lists — an organisation is only ever assessed against the internet-facing devices it has enumerated, so an inventory obligation covering every network-attached embedded device is the precondition for this CVE being remediated at all.",
@@ -59668,7 +61551,7 @@
         ]
       },
       {
-        "id": "NEW-CTRL-EOL-DEVICE-RETIREMENT",
+        "id": "NEW-CTRL-127",
         "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
         "description": "Every network-attached embedded device (IP cameras, video servers, NVRs, routers, print/scan appliances) must carry an end-of-support date in the asset inventory, and any device past that date that exposes a remotely reachable management or media surface must be removed from untrusted networks and scheduled for replacement — patching is not an option once the vendor retires the model. The distinguishing test: query the asset inventory for devices whose firmware lifecycle has ended and whose management interface is reachable from an untrusted segment; any non-empty result that lacks a replace-or-formally-risk-accept decision is a finding. Paper patch-management policies that assume a fix always exists leave actively-exploited EOL devices (GeoVision IP cameras, recruited by Mirai-style botnets) on the network indefinitely.",
         "evidence": "CVE-2018-6530 affects consumer routers bought and installed outside procurement at homeworker premises and small branch sites, so they carry no end-of-support date in any register and no assessment ever reaches them even though a homeworker VPN may terminate on an end-of-support DIR-880L executing shell commands from an unauthenticated query parameter — enumeration of every network-attached embedded device is what makes the exposure visible.",
@@ -59741,7 +61624,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "id": "NEW-CTRL-128",
         "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
         "description": "Application servers that expose binary remoting protocols (Oracle WebLogic T3/IIOP, and equivalents) must restrict those protocols to trusted hosts and apply vendor critical patch updates on an accelerated schedule when a remoting flaw is KEV-listed. Place T3/IIOP behind a connection filter (weblogic.security.net.ConnectionFilterImpl) or network ACLs so only known hosts can reach them, never expose the ports to untrusted networks, and apply the Oracle CPU bundle (with server restart) rather than deferring to the next quarterly window. The distinguishing test: from an untrusted network segment, attempt an unauthenticated T3/IIOP connection to a staging WebLogic instance and confirm it is refused at the connection filter before any data is served - a perimeter-firewall + quarterly-patch policy that still leaves T3/IIOP reachable from an internal untrusted segment leaves the unauthenticated data-access path open.",
         "evidence": "CVE-2018-2628 is unauthenticated deserialization of T3 traffic on WebLogic port 7001, where T3 is multiplexed onto the same socket as HTTP so TLS, a WAF and application authentication leave the pre-authentication listener untouched; the one action that removes the attack surface independent of which Critical Patch Update is installed is a weblogic.security.net.ConnectionFilterImpl filter or a network ACL in front of 7001 so untrusted hosts never reach the protocol.",
@@ -60367,7 +62250,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2013-6282's fix shipped upstream in Linux 3.5.5 in September 2012, more than a year before the CVE, and reached handsets only through OEM and carrier builds that mostly never came — so OS-version attestation reports Android 4.3 as current while the ARMv6k/v7 kernel underneath still lacks the __user check. The exploit arrives as locally running code (it shipped already weaponised inside the vroot rooting application), so reading the device patch level, denying protected-resource access below it, and constraining untrusted app installation are the only levers an operator holds over a build pipeline it does not control.",
@@ -60451,7 +62334,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2013-2597 needs nothing more than membership of the audio group — which any application granted RECORD_AUDIO obtains — to open /dev/msm_acdb and smash acdb_ioctl's stack on a Qualcomm MSM handset that never took the 2013-06-21 Code Aurora fix. Since the escalation is driven entirely by locally installed code, blocking devices below the fixed build from organisational data and constraining untrusted app installation are the enforceable levers, and keying that enforcement to the KEV listing rather than to EPSS matters here because EPSS sits near 0.015 on a confirmed-exploited kernel takeover.",
@@ -60544,7 +62427,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "id": "NEW-CTRL-126",
         "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
         "description": "Managed mobile fleets must enforce a minimum OS security-patch level as a condition of access to organizational data, not merely report it. For Android, the MDM/EMM must read the device security-patch level and block or quarantine devices below the patch level that fixes a KEV-listed Framework flaw (here, 2026-06-01), and constrain installation of untrusted/side-loaded apps on devices that cannot yet update - since the privilege escalation is driven by locally running code. The distinguishing test: enroll a device pinned below 2026-06-01 and confirm the MDM policy denies it access to protected resources (rather than only recording the stale patch level on a dashboard) - paper 'mobile patching' policies that surface patch level without enforcing it leave exploitable devices in production.",
         "evidence": "CVE-2013-2596 is reached by Motochopper through the ADB shell on Motorola Android 4.1.2 builds that never received the 3.8.9 fb_mmap fix, and developer options stayed enabled across enterprise-issued Atrix HD, RAZR HD and RAZR M fleets whose configuration baselines enumerated software, ports and services but not device-side debug transports. An MDM that reads the patch level, quarantines devices below the fixed build and constrains locally installed or side-loaded code governs exactly the precondition the exploit needs.",
@@ -60636,7 +62519,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "id": "NEW-CTRL-130",
         "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
         "description": "Container hosts must treat the kernel - not the namespace boundary - as the last line of defense against a confined workload. Patch host kernels to the fixed release for each maintained series (with reboot) or apply a vendor live-kernel-patch, and layer compensating controls that block cgroups/namespace escapes even on an unpatched kernel: confine every container with AppArmor or SELinux and a seccomp profile, drop CAP_SYS_ADMIN, and disable unprivileged user namespaces where workloads do not need them. The distinguishing test: from inside a representative container on a staging host, attempt the release_agent escape (create user+cgroup namespaces, mount cgroupfs, write a payload path to release_agent, trigger cgroup release) and confirm it is refused before any code runs as root - a fleet that passes image-scan and RBAC audits but permits this on an unpatched, unconfined host still allows container-to-host root.",
         "evidence": "CVE-2013-2094 is reachable by any unprivileged local account through perf_event_open(), and its out-of-bounds decrement lands in shared kernel memory, so a confined workload reaches the host kernel and every co-resident tenant with it — restarting the offending container is not containment. Seccomp confinement of the syscall, or kernel.perf_event_paranoid set to 3 where the distro carried that hardening patch, was the one compensating control that held on an unpatched host; the upstream maximum of 2 is not sufficient because it still permits the unprivileged software-event creation the bug lives in.",
@@ -60995,7 +62878,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "ECOMMERCE-EXTENSION-DESERIALIZATION-GUARD",
+        "id": "NEW-CTRL-133",
         "name": "ECOMMERCE-PLATFORM-EXTENSION-UNTRUSTED-DESERIALIZATION-GUARD",
         "description": "An e-commerce platform (Magento / Adobe Commerce and similar) and every third-party extension it loads must never pass request-supplied data (cookies, headers, body, query parameters) to a native deserialization function (PHP unserialize(), and equivalents in other runtimes) on an unauthenticated storefront request path. Patch-management and secure-coding programs must enumerate every installed extension as part of the storefront's code-execution surface, not only the core platform. The distinguishing test: send an unauthenticated storefront request carrying a crafted serialized object in each cookie / header an extension reads, on a staging store, and confirm it is rejected before any deserialization runs - paper 'platform patched' attestations that ignore the installed extensions still permit unauthenticated RCE through an extension's object-injection sink.",
         "evidence": "CVE-2020-28949's pre-1.4.11 _maliciousFilename() was a denylist of exactly one string, 'phar://', so file://, php:// and the uppercase PHAR:// variant in an uploaded tar member name reached an absolute-path write as the web-server user and dropped an executable PHP file into the webroot. The failing sink is in a PHP library the CMS bundles rather than in the platform an operator audits, which is exactly the surface this control forces a programme to enumerate and test rather than attest.",
@@ -61161,7 +63044,7 @@
     },
     "new_control_requirements": [
       {
-        "id": "ERP-MGMT-PLANE-CRITICAL-FUNCTION-AUTH",
+        "id": "NEW-CTRL-129",
         "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
         "description": "An enterprise ERP platform (Oracle PeopleSoft, Oracle E-Business Suite, SAP, and similar) must authenticate every management-plane and environment-management function before it can be invoked, and must not expose any takeover-capable function to an unauthenticated network caller. Segment the ERP management surface from untrusted networks and place it behind authenticated access control. The distinguishing test: send an unauthenticated network request to each environment-management / configuration endpoint on a staging instance and confirm it is refused before any privileged action runs - paper 'ERP access control' policies that attest user-login authentication while leaving a critical management function reachable without credentials still permit unauthenticated takeover.",
         "evidence": "CVE-2022-22536's published exploit pairs the ICM desynchronisation with an injected 127.0.0.1 loopback Host header to defeat the ICM and Web Dispatcher ACL and reach internal-only paths such as /heapdump/ and /sap/public/bc/icf/info from an unauthenticated caller. The management surface of NetWeaver ABAP/Java, Content Server and Web Dispatcher was reachable without credentials, and adding proxy layers in front of it made the desync worse rather than gating the function.",