@blamejs/exceptd-skills 0.19.17 → 0.19.19

package/data/zeroday-lessons.json

@@ -19620,7 +19620,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": "FortiWeb is a web application firewall — the device is deployed as the protective control on the perimeter trust boundary, and this CVE puts OS command execution (CWE-78) on that device's own operating system. For this product the SLA tier means the vendor build is driven onto every Fortinet FortiWeb unit on the clock that opened with the 2025-11-18 KEV listing, not folded into the appliance-firmware maintenance window, and completion is measured by the build each unit is actually running after its restart rather than by 'update staged' or 'approved' in the management console: the packet records patch_required_reboot as true, live_patch_available as false, and states that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a unit carrying the new image but not yet restarted is still executing the vulnerable code and must be counted as exposed. Scope the sweep from the packet's affected fields, which name Fortinet FortiWeb and give no build numbers — 'versions per vendor advisory' — so the inventory is every FortiWeb unit in service and the fixed build for each has to be read off the vendor advisory rather than assumed from a version that merely looks newer. Precondition on the isolation half of this control, which is where it is normally over-claimed: restricting reachability of the administrative and CLI surfaces bounds one of the two delivery paths the packet's vector names, but the other is crafted HTTP requests, and serving HTTP traffic is the entire reason a FortiWeb is deployed — that surface cannot be withdrawn without removing the device's function. Isolation is therefore a holding measure that narrows who can reach the CLI path during the window before the restart lands; it is not a closure, and a unit whose HTTP surface stays in service stays reachable by the path the vector describes.",
+        "evidence": "Packet: 'Fortinet FortiWeb contains an OS command Injection vulnerability that may allow an authenticated attacker to execute unauthorized code on the underlying system via crafted HTTP requests or CLI commands'; CWE-78; cisa_kev true with kev_date 2025-11-18; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 77; patch_available true; patch_required_reboot 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.'; affected/affected_versions give 'Fortinet FortiWeb — versions per vendor advisory'. The entry's own AU-Essential-8-Patch gap records that the Essential-Eight cadence for internet-facing appliances trails the KEV due date here, and the UK-CAF-B4 gap records that CAF expectations do not isolate the management surface of a WAF appliance.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Applied to FortiWeb, this is the control that decides what happens to a unit that was in service before its restart on the fixed build. Reaching that build stops re-exploitation; it says nothing about what already ran, because the packet's primitive is execution of unauthorized code on the appliance's underlying system — not a crash, not a config change the appliance would log as such. The default response for any FortiWeb unit reachable during the window that opened with the 2025-11-18 KEV listing is therefore configuration capture for analysis, rebuild from vendor media, and rotation of every credential the unit held, rather than patch-in-place. This is also why the least-privilege gap recorded on this entry does not contain the outcome: the packet's vector describes an authenticated attacker, and the entry's UK-CAF-B4 gap notes the flaw is readily chained with a preceding auth bypass, so per-account privilege scoping on the appliance is not the boundary that held — any credential valid on the unit during the exposure window has to be treated as attacker-known regardless of how narrowly it was scoped. Precondition, and it is the one that usually voids this control in practice: a rebuild seeded from the compromised unit's own configuration backup reinstates whatever the attacker changed on it. The saved configuration is evidence to be diffed against a known-good baseline, not the source to restore from. And the decision has to be pre-made in the runbook — with confirmed exploitation and a public PoC on this entry, the question 'was this unit exploited before we patched it' arrives after the patch window has closed, at which point the fastest available answer is the on-box state the exploit already had authority over.",
+        "evidence": "Packet vector: an attacker may 'execute unauthorized code on the underlying system'; active_exploitation 'confirmed'; cisa_kev true, kev_date 2025-11-18; poc_available true; RWEP 77; CVSS 9.8. The entry's NIS2-Art21-network-security gap states that an OS command injection reachable post-authentication 'turns the web-application firewall into an execution host on the network it guards'; its UK-CAF-B4 gap states the flaw is 'readily chained with a preceding auth bypass'; its NIST-800-53-AC-6 gap states that least-privilege presumes a working authentication/authorization boundary and that the exploit demonstrates the boundary is breakable from a baseline context.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "For FortiWeb the requirement is that the appliance's traffic, administrative and authentication, and system logs are forwarded to a collector in a different trust zone — different management plane, different credentials, different authentication path — with retention covering the period from before the 2025-11-18 KEV listing through each unit's restart on the fixed build. The reason is specific to this CVE's primitive rather than generic log hygiene: the packet's vector puts command execution on the appliance's own underlying system, so whatever the FortiWeb recorded about the crafted HTTP request or CLI command that triggered it is held at the same level of authority the exploit grants. On-box telemetry about this exploitation path cannot be treated as an independent record of it. Off-box telemetry is also the input the rebuild-or-patch decision above depends on — without it an operator has no basis for answering whether a unit was hit, and the default becomes patch-in-place by absence of evidence rather than by finding. Precondition: this control only produces value if the forwarding was already in place before the exposure window. A collector configured in response to the KEV listing returns nothing about the period that matters, and it prevents no exploitation at all — what it does is make the claim that the WAF is still a trusted protective control falsifiable rather than assumed.",
+        "evidence": "Packet: OS command injection (CWE-78) allowing an attacker to 'execute unauthorized code on the underlying system via crafted HTTP requests or CLI commands'; active_exploitation 'confirmed'; cisa_kev true, kev_date 2025-11-18; poc_available true. The entry's NIS2-Art21-network-security gap records that network-security duties 'assume the FortiWeb WAF is a trusted protective control' while the flaw turns it into an execution host on the network it guards.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-64446": {
     "name": "Fortinet FortiWeb Path Traversal Vulnerability",
@@ -22071,7 +22104,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This Microsoft Windows entry is the case this control exists for, and the packet states both halves explicitly. patch_available is true, and the vector itself states that the impacted product could be end-of-life and/or end-of-service and that users should discontinue product utilization; the entry's NIS2-Art21-patch-management gap goes further and states that the InformationCardSigninHelper ActiveX control is end-of-life, so patch management cannot remediate it and only removal or decommissioning of the affected component satisfies the obligation, while the UK-CAF-B4 gap states that compliance requires retiring the still-registered control rather than patching it. The operational requirement follows directly: enumerate every Windows system where the InformationCardSigninHelper Class ActiveX control (icardie.dll) is still registered and reachable from a browser rendering attacker-supplied web content. On a system that can still take a Windows update carrying the fix, reaching that build is the interim state; the terminal state is removing or unregistering the control and retiring the Internet Explorer-era rendering path that instantiates it, because a machine held only at the fixed build is still running an unsupported component and remains exposed to anything found in it since. Scope to what the packet names — the Windows component icardie.dll, reached by a specially crafted webpage. The packet ties the out-of-bounds write to that control and gives no mapping into other vendors' browsers or into other ActiveX components, so treating every ActiveX control in the estate as an instance of this CVE manufactures removal work against components no evidence implicates. Precondition on the interim half: live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot, so a system that took the update but has not restarted still runs the vulnerable code and is not remediated. And a risk acceptance carrying no dated removal schedule leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely.",
+        "evidence": "Packet vector: 'Microsoft Windows contains an out-of-bounds write vulnerability in the InformationCardSigninHelper Class ActiveX control, icardie.dll. An attacker could exploit the vulnerability by constructing a specially crafted webpage... The impacted product could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' cisa_kev true, kev_date 2025-10-06; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 77; CWE-94; patch_available true; patch_required_reboot true; live_patch_available false with live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. NIS2-Art21-patch-management gap: 'No patch exists — the InformationCardSigninHelper ActiveX control is end-of-life... only removal or decommissioning of the affected component satisfies the obligation.' UK-CAF-B4 gap: 'an unsupported, still-registered ActiveX control remains exploitable via a crafted webpage, and B4 compliance requires retiring it rather than patching.' AU-Essential-8-App-Hardening gap: 'disabling ActiveX/OLE in browsers neutralises the crafted-webpage vector, whereas patch controls are moot for an end-of-life control.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this Windows entry is not the original disclosure — the packet records the KEV listing as 2025-10-06, so a flaw-remediation programme keyed to first-disclosure date carries no open item for it at all and its SLA never starts. For this CVE the control means the response clock runs from that KEV date, and the mitigation the control accepts has to be chosen per system rather than assumed: on a Windows build that can still take the update carrying the fix, the mitigation is that update plus the restart the packet says the vendor fix typically requires, since live_patch_available is false and there is no in-memory path; where the component sits on an unsupported build, the mitigation is the documented compensating control — unregistering or removing the InformationCardSigninHelper ActiveX control and blocking the browser path that instantiates it — and the record must show it as a compensating control with a removal date attached, not as 'patched per SLA'. The distinguishing test is per-endpoint state rather than a scanner verdict: enumerate the systems on which the control is still instantiable from a rendered page. An estate that reports this CVE closed because its inventory resolved it years ago has recorded the exposure as fixed while it stays live — which is precisely what the entry's own flaw-remediation and technical-vulnerability-management gaps say the legacy KEV re-listing documents.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-10-06 on a CVE identifier from 2013; active_exploitation 'confirmed'; poc_available true; patch_available true; live_patch_available false; patch_required_reboot true; live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction. NIST-800-53-SI-2 framework_coverage gap: the 30-day SLA 'is far longer than the observed exploitation window for a KEV-listed, actively-exploited client-side document/browser RCE; legacy KEV re-listings document organizations still running unpatched builds.' ISO-27001-2022-A.8.8 gap: \"'Appropriate timescales' is undefined... the legacy KEV re-listing exists because organizations still run vulnerable Office/IE/Windows builds.\"",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-074",
+        "name": "CVE-REGRESSION-WATCHER",
+        "description": "What is hard about this Windows entry is not the remediation, it is noticing that a remediation is owed. The packet records a CVE identifier from 2013 entering CISA KEV on 2025-10-06 with confirmed exploitation and a public PoC — years after any asset inventory recorded the item as resolved. This control is the intake rule that produces the signal the KEV response clock above needs a start for: surface current exploitation and PoC material that references CVE identifiers from prior years as candidate re-triage cases, and require an explicit re-check of whether the affected component is still present, instead of deferring to the historical 'remediated' state held in the register. Bound to this entry the re-check is one concrete question with an answer independent of the original remediation record — is the InformationCardSigninHelper ActiveX control still registered on any Windows build in service, and can a rendered page still instantiate it. Limits, stated plainly: this control detects nothing on an endpoint and remediates nothing. It converts a historical CVE reappearing in current exploitation material into a work item, and it produces that item only if the threat-intake pipeline ingests something broader than current-year advisory feeds — if it does not, nothing downstream of it fires and the estate's exposure stays invisible rather than accepted.",
+        "evidence": "Packet: a CVE identifier from 2013 with cisa_kev true and kev_date 2025-10-06; active_exploitation 'confirmed'; poc_available true; RWEP 77; the vector names a specific still-registered component (InformationCardSigninHelper Class ActiveX control, icardie.dll). NIST-800-53-SI-2 gap: 'legacy KEV re-listings document organizations still running unpatched builds.' ISO-27001-2022-A.8.8 gap: 'the legacy KEV re-listing exists because organizations still run vulnerable Office/IE/Windows builds.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2011-3402": {
     "name": "Microsoft Windows Remote Code Execution Vulnerability (CVE-2011-3402)",
@@ -22126,7 +22192,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": "For this entry the KEV listing is the only clock that moved. patch_available is already true, so the control's 'KEV listing or patch availability, whichever is later' branch resolves to 2025-10-06, and the work is not obtaining a fix but locating the Windows hosts that never took the one that has long existed. Scope the sweep from the affected fields, not from the vector: the vector names a Word document as one delivery route, but affected and affected_versions name Microsoft Windows with ranges left to the vendor advisory, so the population is every Windows install — an estate that inventories Office installs reports clean while hosts reachable through the web-page route stay exposed. The hosts that a patch-approval report never covers are the ones this CVE lives on: machines rebuilt from images that predate the fix, restored backups, long-dormant VMs, and anything re-provisioned from old media. Measure completion on the win32k.sys code each host is actually executing: live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a host that installed the update but has not restarted still runs the vulnerable font parser and is not remediated. Note also what gives no help here — the packet has the flaw in the kernel-mode drivers with code execution at kernel privilege, so the least-privilege scoping recorded as insufficient on this entry is not a lever: running the user as a non-administrator does not change where the crafted font is parsed.",
+        "evidence": "Packet fields for CVE-2011-3402: vector places an unspecified vulnerability in the TrueType font parsing engine in win32k.sys in the Windows kernel-mode drivers, reachable by remote attackers via crafted font data in a Word document or web page; affected and affected_versions read 'Microsoft Windows — versions per vendor advisory'; cisa_kev true with kev_date 2025-10-06 and active_exploitation confirmed; poc_available true; cvss 9.8 and rwep_score 77; patch_available true with patch_required_reboot true; live_patch_available false, live_patch_notes stating the vendor patch typically requires service restart or system reboot per the KEV requiredAction; attack_vector records code execution at kernel privilege and states the legacy re-listing exists because long-tail unpatched estates remain exposed; framework_coverage for NIST-800-53-SI-2 and ISO-27001-2022-A.8.8 both record that organizations still run unpatched builds.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The reason a fourteen-year-old Windows kernel flaw needed a 2025 KEV listing is as much a measurement failure as a remediation one, and this is where paper compliance hides on this entry: a vulnerability console reports the estate clean for CVE-2011-3402 because no check fires for a 2011 Windows CVE that every inventory treats as permanently closed — an outcome byte-identical to an estate where every host is above the fixed build. Prove the check works before trusting its verdict. Point the scanner at a host whose Windows build predates the fix — a restored backup, an archived image, or a VM known never to have taken it — and confirm the CVE is actually reported on it; a clean result from a scan that never tested is not evidence of remediation. The check must read the build the host is running rather than the update-approval or download state in the management console, because live_patch_available is false and the packet records a restart-or-reboot requirement, so a downloaded-but-not-restarted host is still executing the vulnerable win32k.sys font parser while every console field says patched. Precondition and limit: this control produces a truthful inventory and removes nothing — it tells the operator which hosts the KEV clock actually applies to, and the fixed build plus its restart is still what closes them.",
+        "evidence": "Packet fields for CVE-2011-3402: cisa_kev true with kev_date 2025-10-06 against a CVE identifier from 2011, active_exploitation confirmed, poc_available true; attack_vector states the legacy re-listing exists because long-tail unpatched estates remain exposed; framework_coverage for NIST-800-53-SI-2 records that legacy KEV re-listings document organizations still running unpatched builds, and the AU-ISM-1546 coverage entry records that long-tail unpatched estates persist; patch_available true with patch_required_reboot true and live_patch_available false, live_patch_notes recording the service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2010-3765": {
     "name": "Mozilla Multiple Products Remote Code Execution Vulnerability",
@@ -22181,7 +22271,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry states both halves the control needs. A fixed Mozilla build exists — patch_available is true — while the packet's patch-management gap records that this memory-corruption RCE persists on end-of-life Mozilla builds where no vendor patch exists, and the system-security gap records that those legacy JavaScript-enabled clients can only be decommissioned or hardened out. So the requirement is an inventory that resolves that question per install rather than assuming either answer: enumerate every Mozilla Firefox, SeaMonkey and Thunderbird install that renders untrusted web content or HTML mail, and record for each whether it sits on a line that still receives Mozilla security updates. Installs on a maintained line are interim items on the clock that opened with the 2025-10-06 KEV listing, remediated by reaching the fixed version named in the vendor advisory. Installs on a line with no vendor patch cannot be remediated at all and are replacement items with a dated schedule — a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely, and such a build is exposed not only to this CWE-94 path through the frame constructor but to everything found in that engine since it was last updated. Scope the inventory to the three products the entry names; widen it only where a verified source identifies other software carrying the same component, since treating every renderer in the estate as an instance of this CVE manufactures replacement work against software no evidence here implicates. Precondition on the interim half: the packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so an install that has taken the update while its process keeps running is still executing pre-fix code and is not yet remediated. And because exploitation is confirmed and delivery is attacker-controlled content, a client that rendered untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet NIS2-Art21-patch-management gap: 'Patch-management assumes supported software, but this KEV-listed Firefox/Thunderbird memory-corruption RCE persists on end-of-life Mozilla builds where no vendor patch exists, so the control has no remediation to schedule.' UK-CAF-B4 gap: 'System-security lifecycle expectations are violated by continued exposure of legacy JavaScript-enabled Mozilla clients whose known RCE cannot be patched, only decommissioned or hardened out.' vector: 'Mozilla Firefox, SeaMonkey, and Thunderbird contain an unspecified vulnerability when JavaScript is enabled... via vectors related to nsCSSFrameConstructor::ContentAppended, the appendChild method, incorrect index tracking, and the creation of multiple frames, which triggers memory corruption.' attack_vector notes 'the legacy re-listing exists because long-tail unpatched/end-of-life estates remain exposed.' cisa_kev true, kev_date 2025-10-06, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 77. patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' affected_versions: 'Mozilla Multiple Products — versions per vendor advisory.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "For the Mozilla installs that are still on a line receiving updates, this is the control that decides whether the fixed build actually arrives before an attacker-controlled page does. The requirement here is that the managed update ring covers all three products the entry names — Firefox, SeaMonkey and Thunderbird — rather than the browser alone: the packet places the flaw in code reached when JavaScript is enabled, and names the suite and the mail client alongside the browser, so a ring scoped to Firefox leaves the same frame-constructor path live wherever SeaMonkey or Thunderbird renders content. Deferral windows and per-user deferral are the specific failure: the packet records a public PoC and confirmed in-the-wild exploitation, so an update ring that holds these clients back for a validation cycle is holding them on a build with a known-exploited code-execution path. Completion is measured on the version the running process reports, not on what was downloaded or staged — the packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, and a browser or mail client left open for days is the ordinary case, so an install that took the update without the process restarting is still executing pre-fix code. Precondition: this reaches only the installs the management channel can see and that are on a line with a fixed build available. An unmanaged per-user copy is remediated by removing it, and an install on a line with no vendor patch is not an update item at all — that population belongs to the decommissioning path, and counting it in an update-compliance figure is how a KEV-listed flaw stays in service behind a green metric.",
+        "evidence": "Packet NIST-800-53-SI-2 gap: '30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE. CISA due date is the operationally-meaningful clock — typically 14-21 days for new KEV listings', with framework_coverage adding that the SLA 'is far longer than the observed exploitation window for a KEV-listed, actively-exploited client-side browser/reader RCE'. ISO-27001-2022-A.8.8 gap: 'Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs. KEV listing collapses patch-cycle response to incident-speed response', with coverage noting 'appropriate timescales' is undefined. vector names Mozilla Firefox, SeaMonkey and Thunderbird, exploitable 'when JavaScript is enabled'. poc_available true; active_exploitation confirmed; kev_date 2025-10-06. patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2025-61882": {
     "name": "Oracle E-Business Suite Unspecified Vulnerability (CVE-2025-61882)",
@@ -22241,7 +22353,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet puts an unauthenticated attacker with network access over HTTP through the BI Publisher Integration component and into takeover of Oracle Concurrent Processing, with a public PoC and mass exploitation in a data-theft extortion campaign — so the interval that matters for Oracle E-Business Suite is the one between the 2025-10-06 KEV listing and the moment each application tier is actually running the fixed code, not the quarterly change window an ERP is normally patched in. Applied to this product: enumerate every EBS instance rather than only the ones the organisation thinks of as internet-facing, because the packet's stated access requirement is HTTP network access — an instance reachable only from the corporate network is exposed to every host on that network, and scoping the emergency to the external ones leaves the rest serving the same unauthenticated path. Take the fixed level from the Oracle advisory the packet points to rather than assuming a version, since the entry records affected versions only by reference to it, and apply it out of band. The completion measure is the load-bearing part here: the packet records that the vendor patch typically requires a service restart or system reboot and registers no live-patch tool, so an instance where the patch files landed but the EBS services were not bounced is still serving pre-fix code. On an ERP that restart is the single step most likely to be deferred, because taking it interrupts Concurrent Processing jobs and the user population, and a deferral recorded as 'patched' is the specific way this remediation fails. Priority follows the packet rather than the CVSS band — an 8.8 that is KEV-listed, has a public PoC and is being mass-exploited for extortion outranks higher-scored items with neither.",
+        "evidence": "Packet for CVE-2025-61882, Oracle E-Business Suite Unspecified Vulnerability: CWE-94; cisa_kev true with kev_date 2025-10-06; active_exploitation confirmed; rwep_score 83, cvss 8.8; poc_available true; patch_available true; patch_required_reboot 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 'Oracle E-Business Suite contains an unspecified vulnerability in the BI Publisher Integration component. The vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Concurrent Processing. Successful attacks can result in takeover of Oracle Concurrent Processing.'; affected_versions 'Oracle E-Business Suite — versions per vendor advisory'; attack_vector 'mass-exploited in a data-theft extortion campaign'; AU-Essential-8-Patch gap 'Essential-Eight internet-facing patch windows trail the mass exploitation of exposed Oracle E-Business Suite by a ransomware crew, where unauthenticated HTTP RCE demands emergency out-of-band patching.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Oracle E-Business Suite is the enterprise ERP this control governs, and this CVE is its function-level authorization failing: the packet has an unauthenticated attacker reaching the BI Publisher Integration component over HTTP and taking over Oracle Concurrent Processing — the batch-execution engine that runs an ERP's privileged jobs and holds the connections and credentials those jobs use. Bound to this deployment, the control means each function the BI Publisher integration exposes, and each path it opens into Concurrent Processing, authorizes its own caller before doing work, rather than inheriting a verdict from the tier that fronts it; and that no EBS instance is left with that HTTP surface reachable from a network segment with no operational need for it. The distinction matters for the audit, not just the engineering: the cited least-privilege gap does not touch this path, because the attacker never authenticates as any EBS user, so responsibility and role scoping — the account model an identity or least-privilege attestation examines — is never consulted at all. That attestation passes cleanly while the unauthenticated path stays fully open. Distinguishing test on a staging EBS instance: from a segment with no operational need for EBS, issue unauthenticated HTTP requests to the BI Publisher Integration endpoints and confirm each is refused before the function executes — an environment that can produce a clean report of every EBS responsibility assignment tells you nothing about this path. Precondition: the vendor update is what establishes the endpoint-side authorization property; this control is the verification and the reachability discipline around it. Restricting which segments can reach the EBS HTTP surface bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable where the instance must serve a broad user population.",
+        "evidence": "Packet for CVE-2025-61882, Oracle E-Business Suite Unspecified Vulnerability: vector 'unspecified vulnerability in the BI Publisher Integration component ... allows unauthenticated attacker with network access via HTTP to compromise Oracle Concurrent Processing. Successful attacks can result in takeover of Oracle Concurrent Processing.'; cwe_refs CWE-94; NIST-800-53-AC-6 gap 'Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.'; active_exploitation confirmed, cisa_kev true (kev_date 2025-10-06); poc_available true; patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For an Oracle E-Business Suite instance that was reachable while exposed, the Oracle patch closes the entry point and removes nothing that came through it. The packet records confirmed in-the-wild exploitation, a public PoC, and mass exploitation in a data-theft extortion campaign against a path needing no credentials, so the response default has to be incident handling rather than a patch ticket. Applied to this product: capture forensic state of the application tier before remediation where the outage budget allows, hunt the web-accessible directories and the EBS file system for artifacts written during the exposure window, rebuild the tier from a known-good deployment wherever an artifact is found or the instance cannot be cleared, and rotate the credentials that tier holds — database accounts, integration and service accounts, and any secret in the EBS configuration — because on a Concurrent Processing takeover those are what leaves the host along with the data. The packet's NIS2 gap is the reporting half of the same requirement: it records that known campaign use lifts this above routine vulnerability handling into a Significant Incident class where disclosure clocks engage, which means the finding of exposure during the window — not the later finding of an implant — is what starts the notification assessment, and a runbook that waits for confirmed compromise before escalating misses the clock. Boundary of the requirement: the rebuild default applies to instances that were reachable by an untrusted caller during the exposure window; an instance that provably was not is a patch item, and conflating the two spends the rebuild effort in the wrong place.",
+        "evidence": "Packet for CVE-2025-61882, Oracle E-Business Suite Unspecified Vulnerability: active_exploitation confirmed; cisa_kev true (kev_date 2025-10-06); poc_available true; attack_vector 'an unauthenticated code-injection / remote code execution flaw (CWE-94), mass-exploited in a data-theft extortion campaign'; vector 'takeover of Oracle Concurrent Processing'; UK-CAF-D1 gap 'CAF response-and-recovery planning must treat this Oracle EBS RCE as an active ransomware-campaign vector rather than a routine patch item, since unauthenticated Concurrent-Processing takeover has been used for large-scale data theft.'; NIS2-Art21-vulnerability-handling gap 'Known ransomware-campaign use elevates this from routine vulnerability handling to a Significant Incident class under NIS2 Art.23(4) — disclosure clocks engage.'; framework_coverage NIS2-Art21-network-security 'does not require the web-shell-hunt / credential-rotation / downstream-review cleanup these RCEs need given their managed-estate reach'; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-D1",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2014-6278": {
     "name": "GNU Bash OS Command Injection Vulnerability",
@@ -22386,7 +22530,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Jenkins CLI's remoting channel is exactly the binary remoting-protocol class this control governs: the packet describes a serialized Java SignedObject transferred to the remoting-based Jenkins CLI and deserialized with a new ObjectInputStream, so the endpoint reconstructs attacker-supplied objects before any authentication decision and the parser is itself the vulnerable code — which is why a perimeter firewall and the web-tier hardening most Jenkins deployments are audited against never touch it. Bound to this deployment, the control means the controller's remoting endpoint accepts connections only from hosts that legitimately speak it (build agents, and the administrator jump hosts where the CLI is genuinely used), enforced by network ACL or host firewall rather than inherited from 'Jenkins is internal', with any internet-reachable controller taken first. The UK CAF gap on this entry is the assumption being corrected — an internal build server scored as low-exposure while an unauthenticated RCE on it hands over the pipeline's signing and deploy keys — and the NIS2 gap is the same point at directive level: the compromise is a software-supply-chain event across every downstream build, so the controller's segmentation has to be justified by blast radius, not by where the box sits. Distinguishing test: from a general developer VLAN and from an external address, open a connection to the remoting port of a staging controller and send a serialized object; anything that reaches the deserialization path is exposed to the published exploit, while a clean Jenkins role-and-permission audit says nothing about whether that port answers. Precondition: reachability restriction bounds who can send the object, it does not repair the deserialization path, it is unavailable wherever agents must reach the controller, and it gives nothing on a controller already exploited — the packet records a vendor fix with no live-patch path and a service restart or system reboot required, so until that restart the controller is still executing the vulnerable code.",
+        "evidence": "Packet fields: cwe_refs CWE-94; vector states attackers transfer a serialized Java SignedObject to the remoting-based Jenkins CLI, deserialized using a new ObjectInputStream, bypassing the existing blocklist-based protection mechanism; attack_vector records unauthenticated remote code execution on the CI server; cisa_kev true, kev_date 2025-10-02; active_exploitation confirmed; poc_available true; cvss 9.8, rwep_score 77; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes recording a service restart or system reboot per the KEV requiredAction. The UK-CAF-B4 gap states that system-security controls treat an internal build server as low-exposure while this deserialization RCE hands attackers the signing and deploy keys of the whole pipeline; the NIS2-Art21-network-security gap states Jenkins is a CI/CD control point whose compromise poisons every downstream build and that the measures focus on perimeter and segmentation rather than on an internal unauthenticated-RCE build server.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "This CVE is the exact failure this control exists to prevent: the packet records that the serialized SignedObject was deserialized with a new ObjectInputStream and that this bypassed the existing blocklist-based protection mechanism — so an enumeration of classes known to be dangerous was the only thing between an unauthenticated peer and code execution, and wrapping the payload in a permitted type defeated it. For Jenkins the requirement is that the remoting endpoint authenticate its peer before any object is reconstructed, and that what arrives on that channel be constrained by what the protocol legitimately conveys rather than by a denylist, which is only ever as current as its last update. This is also the control that answers the least-privilege gap recorded on this entry: the attacker holds no Jenkins account, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the endpoint deserializes for anyone who can reach it — the decision point has to move to the endpoint's own peer authentication rather than to the account model behind it. Distinguishing test: from an unauthenticated host that can route to the remoting port of a staging controller, send a serialized object wrapped in a type the blocklist permits, and confirm the peer is rejected before the object is reconstructed. Precondition: this endpoint-side property is what the vendor fix establishes — the control states what to verify, not what the operator implements — so until the fixed release named in the vendor advisory is deployed and the service restarted, the only operator-side lever is who can reach the port, and that bounds the attacker population rather than closing the path.",
+        "evidence": "Packet fields: vector states the serialized Java SignedObject sent to the remoting-based Jenkins CLI is deserialized using a new ObjectInputStream, bypassing the existing blocklist-based protection mechanism; cwe_refs CWE-94; attack_vector records unauthenticated remote code execution on the CI server; poc_available true; active_exploitation confirmed; patch_available true with patch_required_reboot true and live_patch_available false; affected_versions recorded only as 'Jenkins Jenkins — versions per vendor advisory'. The NIST-800-53-AC-6 gap states that least privilege presumes a working authentication/authorization boundary and that the KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is a 2017-era flaw that CISA listed on 2025-10-02, so the population it addresses is not controllers that missed one patch window but controllers that have not been upgraded in years — which is why the routine 30-day flaw-remediation clock the SI-2 gap describes never reaches them, and why the undefined 'appropriate timescales' reading in ISO A.8.8 and the Essential-Eight cadence the AU gap names can all be satisfied while the instance stays unauthenticated-RCE-exploitable. For this CVE the control means the KEV listing date, not the CVE's disclosure age, starts the clock on every Jenkins controller in the estate, and completion is measured by the version the running controller process reports after its restart rather than by a package or archive having been replaced: the packet records patch_available true with no live-patch path and a vendor patch that typically requires a service restart or system reboot per the KEV requiredAction, so a staged upgrade that has not been restarted into is not remediation. Take the fixed version from the vendor advisory — the packet records affected versions only as 'Jenkins Jenkins — versions per vendor advisory', so a sweep keyed on a guessed build string will mark instances clean that are not. Distinguishing test: enumerate every Jenkins controller including the ones stood up by teams outside the platform group, and produce for each the version its running process reports; the instances this flaw survives on are the ones no patch programme knows about, and an inventory-scoped attestation reads clean while they run.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2025-10-02 for a CVE identified as CVE-2017-1000353; active_exploitation confirmed with active_exploitation_notes stating the KEV listing is CISA's confirmed-exploitation attestation and in-wild observation may predate the dateAdded; poc_available true; cvss 9.8, rwep_score 77; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes recording a service restart or system reboot per the KEV requiredAction; affected_versions 'Jenkins Jenkins — versions per vendor advisory'. The NIST-800-53-SI-2 gap records the 30-day SLA as inadequate for a KEV-listed actively-exploited CVE and names the CISA due date as the operationally-meaningful clock; the ISO-27001-2022-A.8.8 gap records that the standard does not differentiate routinely-disclosed CVEs from KEV-listed ones; the AU-Essential-8-Patch gap records that the patch cadence lags the long-public exploit for this Jenkins CLI deserialization bug.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2015-7755": {
     "name": "Juniper ScreenOS Improper Authentication Vulnerability",
@@ -23639,7 +23815,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries two facts that must be resolved per unit before anything else: a vendor patch is recorded as available with a restart or reboot required and no live-patch path, and the entry's own vector states the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization, with the NIS2, UK-CAF and Essential-Eight gaps recording the affected Archer routers as end-of-life with no fix. So the first requirement is an inventory naming every TP-Link Archer C7(EU) and TL-WR841N/ND(MS) in service with its hardware revision, its running firmware version, and an end-of-support status obtained from the vendor rather than assumed in either direction — the packet gives affected versions only as 'per vendor advisory', so the fixed firmware level has to come from that advisory for that exact model and revision. Units whose revision has firmware carrying the fix are remediation items on the clock that opened with the 2025-09-03 KEV listing, and because the packet registers no live-patch path and a fix that typically requires a service restart or system reboot, a unit that has taken firmware but has not restarted onto it is still executing the vulnerable code and counts as exposed. Units whose revision has no fixed firmware cannot be patched at all and are replacement items needing a dated schedule; a risk acceptance with no removal date leaves a device with a public PoC and confirmed exploitation in service indefinitely. Precondition on the reachability half, which is where this control is most often over-claimed: the injection sits in the Parental Control page, part of the router's web administration surface, so blocking administration from the WAN side bounds who can reach it from the internet — but a home or small-branch router exists to serve the client network attached to it, and every client on that network still reaches the administration surface, so for a unit serving a general user network there is no segment that removes the path, only isolation of that network from anything that matters. And because active exploitation is confirmed and the flaw yields command execution on the router itself, a unit that was exposed is not remediated by firmware alone: its configuration and administrative credential must be rebuilt from a known-good baseline rather than inherited through the update, and credentials that transited it rotated.",
+        "evidence": "Vector: 'TP-Link Archer C7(EU) and TL-WR841N/ND(MS) contain an OS command injection vulnerability that exists in the Parental Control page. The impacted products could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.' affected / affected_versions: 'TP-Link Multiple Routers — see vendor advisory linked in verification_sources for affected version ranges' / 'versions per vendor advisory'. patch_available true, patch_required_reboot 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.' cisa_kev true, kev_date 2025-09-03, active_exploitation 'confirmed', poc_available true. NIS2-Art21-patch-management gap: 'The affected TP-Link Archer routers are end-of-life with no fix, so patch-management obligations are unmeetable and NIS2 compliance for this KEV-listed command-injection requires device replacement, not patching.' UK-CAF-B4 gap: 'only removing the EoL device from the estate resolves the exposure.' AU-Essential-8-Patch gap: 'Essential-Eight patch maturity presumes a patch exists; for these EoL TP-Link edge devices there is none.'",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "KEV-listed 2025-09-03 with confirmed exploitation, a public PoC and unauthenticated command execution on the router — and the packet's own framework note that SOHO routers and edge appliances are mass-exploited into botnets and operational-relay networks within days is the reason the ordinary 30-day flaw-remediation window is exposure acceptance here rather than a schedule. What this control requires for these devices is a verified mitigation inside a compressed window measured from the KEV listing, and the end-of-life population forces the point that the mitigation is not always a patch. For an Archer C7(EU) or TL-WR841N/ND(MS) whose hardware revision has firmware carrying the fix, the mitigation is that firmware plus the restart or reboot the packet records as required, verified against the version the unit reports after it has restarted rather than against the version pushed to it. For a revision with no fixed firmware — which the packet's NIS2, UK-CAF and Essential-Eight gaps say is the case for the affected Archer routers — 'no patch available' must not close the item: the documented compensating control is removal of the device from service, or, where it cannot be removed immediately, eliminating any internet-side reachability of its administration surface and isolating the network it serves from anything of value, with a replacement date attached to the record. Precondition: those measures bound who can send the request; they do not repair the Parental Control page's command handling, and any client on the network the router serves still reaches that page, so they are a holding measure until the unit is replaced and never a closure.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-09-03, active_exploitation 'confirmed', poc_available true, cvss 9.8, rwep_score 77; attack_vector 'an OS command-injection flaw (CWE-78) enabling unauthenticated remote command execution on the router'. patch_available true, patch_required_reboot true, live_patch_available false ('Vendor patch typically requires service restart or system reboot per the KEV requiredAction'). NIST-800-53-SI-2 gap: '30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE', and framework_coverage for SI-2: 'SOHO routers and edge appliances are mass-exploited into botnets and operational-relay (ORB) networks within days, and many run end-of-life firmware with no available fix.' ISO-27001-2022-A.8.8 gap: 'KEV listing collapses \"patch-cycle response\" to \"incident-speed response\".'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance failure on this entry is a register that marks a TP-Link Archer C7(EU) or TL-WR841N/ND(MS) compliant because it is running the newest firmware available for its model. The packet's structured record says a patch exists, while its vector says the impacted products could be end-of-life or end-of-service and that users should discontinue use, and its NIS2, UK-CAF and Essential-Eight gaps say the affected Archer routers have no fix — which means 'newest available firmware' and 'firmware containing the fix for the Parental Control command injection' are different statements for at least part of this population, and a currency check cannot tell them apart. The operational test for this entry: can the programme produce, per unit, the model, the hardware revision, the running firmware version and the fixed version named in the vendor advisory for that exact revision — and does a revision for which the advisory names no fixed firmware appear as unremediable-pending-replacement rather than as up to date? A second failure mode is specific to this device class: consumer routers usually sit outside authenticated scanning scope, so a scan that never reached the unit reports nothing rather than a finding, and the inventory has to be built from what is physically in service at each site instead of from what the scanner enumerated. Precondition: this test surfaces the exposure and does not reduce it. Units it flags still need firmware carrying the fix and the restart the packet records as required, or replacement — and a unit already exploited needs its configuration and administrative credential rebuilt, since the packet records confirmed exploitation yielding command execution on the router.",
+        "evidence": "Vector states the impacted products 'could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization,' while patch_available is true with patch_required_reboot true and live_patch_available false. affected_versions is recorded only as 'TP-Link Multiple Routers — versions per vendor advisory'. framework_coverage for ISO-27001-2022-A.8.8: \"'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited internet-facing device, and unmanaged/EOL devices fall outside most patch programs entirely.\" AU-Essential-8-Patch gap: 'Essential-Eight patch maturity presumes a patch exists; for these EoL TP-Link edge devices there is none, and the model offers no control for retiring unsupported internet-facing consumer hardware.' active_exploitation 'confirmed'; poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2020-24363": {
     "name": "TP-link TL-WA855RE Missing Authentication for Critical Function Vulnerability",
@@ -24283,7 +24492,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "Apex One is the product the estate relies on for malware defense, and this CVE is that product's own management console accepting attacker input before any authentication decision is made — the packet has a pre-authenticated remote attacker uploading malicious code and executing commands on the on-premise console. Bound to this product, the control means the Apex One console is enrolled in vulnerability management as privileged software in its own right, with the same expedited SLA the estate would apply to any other privileged server, and that security-product audits include the trust-anchor-inversion test rather than only confirming the tool is deployed and reporting. The distinguishing test for this console: on a staging Apex One installation, send an unauthenticated request to the console's upload path carrying OS command metacharacters and confirm it is refused before any command runs on the host. That test is the one that separates paper compliance from the real state here, because an attestation that every Apex One administrator authenticates and holds least privilege passes cleanly while this path is open — the attacker never holds a console account, so the account model the attestation examines is bypassed rather than abused. Preconditions: the input handling is a property the vendor update establishes; this control states what to verify and what SLA tier the product sits in, it does not implement the fix. Until the fixed build named in the vendor advisory and its restart land, restricting which segments can reach the console bounds who can send the request but leaves the endpoint fully exploitable to anything inside a permitted segment, and it is unavailable where the console must stay reachable for agents and administrators to work.",
+        "evidence": "Packet vector: 'Trend Micro Apex One Management Console (on-premise) contains an OS command injection vulnerability that could allow a pre-authenticated remote attacker to upload malicious code and execute commands on affected installations.' cwe_refs CWE-78; cvss 9.8; rwep_score 77; poc_available true; cisa_kev true with kev_date 2025-08-18 and active_exploitation confirmed. NIS2-Art21-network-security gap: 'NIS2 network-security relies on the Apex One console as a protective EDR control; a pre-auth command-injection that runs code on the management server subverts the defense itself, a security-tooling compromise Article-21 does not treat as its own priority class.' NIST-800-53-AC-6 gap: 'Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.' patch_available true; live_patch_available false; live_patch_notes: 'Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' affected_versions: 'Trend Micro Apex One — versions per vendor advisory.'",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-045",
+        "name": "EDR-PLATFORM-UPDATE-DISTINCT-SLA",
+        "description": "The Apex One management console updates on Trend Micro's own product release channel, which is not the operating-system update channel the estate's patch metrics are usually built on — and that is exactly why the three timing gaps recorded here can all read green while this console stays exploitable. An Essential-Eight control scored on patching operating systems does not look at the Apex One console build at all, and a 30-day flaw-remediation clock is longer than the window the packet describes for a KEV-listed pre-auth RCE. Applied to this product, the control means the on-premise Apex One console is tracked as its own patch surface with its own SLA, driven from the 2025-08-18 KEV listing rather than folded into the next server-patching window, and completion is measured per console on the build the console actually reports against the fixed build named in the vendor advisory — the packet carries no version strings, so the advisory is the reference and 'update approved' or 'update downloaded' in a management view is not the measurement. The packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a console that has taken the update but has not restarted is still executing pre-fix code and must be counted as exposed; on a console that the whole agent fleet reports to, that restart is precisely the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Priority follows the packet rather than the CVSS band alone: a public PoC, confirmed in-the-wild exploitation, and the packet's own note that the in-wild observation may predate the KEV listing by weeks put this ahead of routine server patching.",
+        "evidence": "Packet AU-Essential-8-Patch gap: 'Essential Eight patch targets for internet-facing management consoles trail the KEV window for a pre-auth RCE on the very tool tasked with malware defense.' NIST-800-53-SI-2 gap: '30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE. CISA due date is the operationally-meaningful clock.' ISO-27001-2022-A.8.8 gap: 'Vulnerability management standard does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs.' kev_date 2025-08-18; poc_available true; active_exploitation confirmed; active_exploitation_notes: 'the actual in-wild observation may predate it by weeks.' patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' affected_versions: 'Trend Micro Apex One — versions per vendor advisory.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet's own framing of the B4 gap is what makes this an IR item rather than a patch item: an unauthenticated OS command injection on the Apex One console inverts the trust the estate places in that console into fleet-wide reach. With active exploitation confirmed and a public PoC recorded, an on-premise console that was reachable during the exposure window is a suspected fleet-control-plane compromise, and applying the vendor update does not resolve it — the update closes the injection path and removes nothing an attacker executed through it. The playbook for this product means: reviewing the console's configuration and the actions it directed at managed endpoints across the suspected window rather than only from the day the update landed, defining quarantine criteria for endpoints that received console-directed actions in that window, and rotating credentials for every account that authenticated to the console during it. Preconditions, both load-bearing here: the console's own logs sit on the host where the packet says commands executed, so the timeline has to be corroborated from an off-host copy or it is evidence the attacker could edit; and the exposure window is not the KEV date — the packet states the in-wild observation may predate the 2025-08-18 listing by weeks, so scoping the review to the listing date understates it. This control governs the response, not the exposure: it does not evict an attacker still resident, and it is not a substitute for the fixed build and the restart the packet requires.",
+        "evidence": "Packet UK-CAF-B4 gap: 'CAF B4 hardening trusts the endpoint-protection console, but a KEV-listed unauth OS-command-injection on Apex One inverts that trust into fleet-wide reach, warranting emergency patching beyond B4's routine expectation.' vector: pre-authenticated remote attacker can 'upload malicious code and execute commands on affected installations' of the on-premise Apex One Management Console. active_exploitation confirmed; poc_available true; rwep_score 77. active_exploitation_notes: 'The dateAdded is the formal KEV listing date; the actual in-wild observation may predate it by weeks.' patch_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-8876": {
     "name": "N-able N-Central Command Injection Vulnerability",
@@ -24343,7 +24583,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "N-able N-Central is the MSP's management server, and the packet's own coverage text calls it an internet-facing management platform whose compromise is fleet-wide, so the clock on this command-injection flaw runs from the KEV listing of 2025-08-13 rather than from the next maintenance window that suits a platform every technician depends on. Bound to this product the control means: the N-Central server reaches the fixed build named in the vendor advisory — the packet gives affected versions only as 'per vendor advisory', so the target build must be taken from that advisory for the deployed release rather than assumed — and completion is measured on the version the running N-Central service reports after the restart, not on the update being downloaded or marked approved. The packet records no live-patch path and states the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a server that has taken the update but has not restarted is still executing the vulnerable code and counts as exposed; on an RMM that restart is the step most likely to slip, because taking it interrupts every managed endpoint's check-in, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Limit of this control: it governs the operator's own N-Central server and says nothing about downstream client systems already reached through it while the flaw was live.",
+        "evidence": "Packet: CISA KEV-listed 2025-08-13, active_exploitation confirmed, CVSS 9.8, RWEP 77, poc_available true. Vector: command injection via improper sanitization of user input (CWE-94); attack_vector records unauthenticated remote command execution on the RMM server. patch_available true, live_patch_available false, patch_required_reboot true, live_patch_notes: no live-patch tool registered and the vendor patch typically requires a service restart or system reboot per the KEV requiredAction. affected and affected_versions give the fixed level only as 'per vendor advisory'. AU-Essential-8-Patch gap records the 48h patch target trailing same-day exploitation of a KEV-listed RMM command injection; SI-2 and A.8.8 gaps record the 30-day/undefined-timescale readings as unsafe for an actively-exploited internet-facing management platform.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet records that command injection on N-Central reaches every downstream client the MSP manages, well beyond the operator's own boundary, and turns one server into managed-fleet-wide code execution across every client estate. A compromised N-Central is therefore not a single-server incident, and the playbook has to treat every endpoint the platform administers as having been under attacker control for the exposure window: rotate every credential the platform can use or that technicians used through it to reach managed devices, invalidate technician sessions and API tokens, audit the scripts, scheduled jobs and automation policies pushed since the start of the window, and set quarantine criteria for downstream client devices that executed anything in that period. The audit half is where this differs from ordinary server IR — remote script execution is the product's normal function, so attacker actions appear in the managed agent's logs as legitimate platform use, and there is no anomalous binary or unsigned process to pivot from. Patch-only closure is the specific failure this control prevents: the packet's coverage text records that compressed-SLA controls do not require the web-shell-hunt, credential-rotation and downstream-review cleanup these RCEs need given their managed-estate reach, and the vendor update removes the injection path but nothing already installed through it. Precondition: this depends on the platform's job history and agent telemetry being retained off the N-Central server itself — an attacker holding command execution on that server can alter what its console reports, so a playbook keyed only on N-Central's own records has no independent account of the window to reconstruct.",
+        "evidence": "Packet: NIS2-Art21-patch-management gap records that patch-management obligations do not capture the supply-chain blast of an RMM platform, and that command injection on N-Central reaches every downstream client the MSP manages, well beyond the operator's own boundary. UK-CAF-B4 gap records that CAF scoping treats N-Central as an internal admin tool while command injection on an RMM turns one server into managed-fleet-wide code execution across every client estate. AU-Essential-8-Patch gap names the multi-tenant blast radius from an owned N-Central server. framework_coverage records that the framework does not require the web-shell-hunt / credential-rotation / downstream-review cleanup these RCEs need given their managed-estate reach. active_exploitation confirmed with poc_available true.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "N-Central is the device-management gateway this control governs and the packet places the defect on its request-handling surface: improper sanitization of user input reaching a command-execution path, exploitable without authentication. Bound to this product the requirement is that every N-Central endpoint carrying operator- or agent-supplied values into a command path authorizes its caller before the value is processed at all, and passes that value as an argument to the invoked program rather than composing it into a shell string, so a caller-supplied metacharacter cannot select what runs. Precondition, and it is the half that gets over-claimed: the vendor update is what establishes that property — this control states what to verify, not how to implement it — and until it lands the only operator-side lever is restricting which networks can reach the N-Central administration surface. On an RMM that lever is weak by construction, because agents at every client site check in to this server and technicians reach it remotely; the packet's own coverage text describes it as internet-facing, so for a deployment that must answer from the internet the restriction bounds nothing meaningful, and for one reachable only over a VPN it bounds the population to VPN-authenticated hosts and no further. It never closes the path. Note also why the least-privilege control cited as insufficient on this entry cannot substitute: the attack_vector places execution before authentication, so the attacker never holds an N-Central operator account, per-account privilege scoping is never consulted, and an AC-6 attestation passes cleanly while the injection path stays open.",
+        "evidence": "Packet vector: 'N-able N-Central contains a command injection vulnerability via improper sanitization of user input.' attack_vector: a command-injection flaw (CWE-94) enabling unauthenticated remote command execution on the RMM server. framework_coverage describes an actively-exploited, internet-facing management platform whose compromise is fleet-wide. NIST-800-53-AC-6 gap records that least privilege presumes a working authentication/authorization boundary and that the KEV-listed exploit demonstrates the boundary is breakable. UK-CAF-B4 gap records CAF system-security scoping treating N-Central as an internal admin tool. patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-8875": {
     "name": "N-able N-Central Insecure Deserialization Vulnerability",
@@ -24403,7 +24675,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "N-Central is the console a managed-service provider runs its customers' estates from, so this is not an application-patching item on the server's normal cycle. The packet records the defect as insecure deserialization (CWE-94) reaching command execution, with the entry's attack vector describing it as unauthenticated remote code execution on the RMM server, a public proof of concept available, CVSS 9.8, and confirmed exploitation with a KEV listing on 2025-08-13 — and the entry's own note that the KEV dateAdded is the formal listing date while in-wild observation may predate it by weeks, so the exposure window opened before the clock did. The requirement here is that the N-Central server is remediated against that listing rather than folded into the next maintenance window, and that completion is measured on the version the running N-Central service is executing rather than on 'update downloaded' or 'change approved' in the change record. The packet gives no live-patch path and states the vendor patch typically requires a service restart or system reboot, so an instance that has staged the update but not restarted is still serving the vulnerable deserialization path and must be counted as exposed — on a console that is doing continuous work for customers, that restart is the step most likely to be deferred and is the specific way this remediation gets recorded as done while the server stays exploitable. Precondition on verification: this entry names no build. affected_versions reads only 'N-able N-Central — versions per vendor advisory', so the target version has to be taken from that advisory for the deployed release line; an operator working from this entry alone cannot demonstrate remediation. Note what buys no time: the least-privilege gap cited on this entry is not a mitigation for this path, because the attack vector places the attacker at the server without authenticating, so no operator account is presented and per-account privilege scoping is never consulted.",
+        "evidence": "Packet name: 'N-able N-Central Insecure Deserialization Vulnerability'; CWE-94; cisa_kev true, kev_date 2025-08-13, active_exploitation 'confirmed'; cvss 9.8; rwep_score 77; poc_available true. vector: 'N-able N-Central contains an insecure deserialization vulnerability that could lead to command execution.' attack_vector: 'an insecure-deserialization flaw (CWE-94) enabling unauthenticated remote code execution on the RMM server.' affected_versions: 'N-able N-Central — versions per vendor advisory'. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' active_exploitation_notes: 'The dateAdded is the formal KEV listing date; the actual in-wild observation may predate it by weeks.' The NIST-800-53-AC-6 gap records that least privilege 'presumes a working authentication / authorization boundary'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "What separates this from an ordinary server RCE is what the server does for a living. The packet's own gap analysis states that N-Central is MSP RMM tooling and that a deserialization RCE on the platform cascades to every managed downstream estate, projecting command execution into every client network it manages. Code execution on the N-Central server is therefore control of the channel that ships scripts, agent updates and remote-execution jobs to managed endpoints — the exposed asset is not the console's own data but everything the console distributes and runs on other networks. Applied to this product, the control means the N-Central installation and every directory from which it stages or serves content to agents are file-integrity-monitored, with alerts on writes that do not correspond to a sanctioned administrator action or a vendor update; the server is held to management-plane patch priority rather than to general server cadence; and the record of what the platform distributed and executed downstream — job, script and automation history — is retained off the N-Central server, so the question 'what did this console push during the exposure window' is answerable from something an attacker on that console could not edit. This is the control that retains value after the vendor update lands, which is why it sits alongside the remediation clock rather than being replaced by it: the fix closes the deserialization sink but removes nothing already written through it, and a script or agent payload staged before remediation survives the upgrade and keeps reaching managed endpoints down the platform's legitimate distribution path — where anti-malware on those endpoints sees a change delivered by their own management agent and the console's authentication log shows no anomalous login, because the attacker never needed one.",
+        "evidence": "Packet attack_vector: 'an insecure-deserialization flaw (CWE-94) enabling unauthenticated remote code execution on the RMM server.' The NIS2-Art21-vulnerability-management gap states: 'N-Central is MSP RMM tooling, so a deserialization RCE on the platform cascades to every managed downstream estate — a supply-chain blast radius NIS2 vulnerability-management treats as a single-entity flaw rather than a multi-customer incident.' The UK-CAF-B4 gap states: 'an RMM server compromise via insecure deserialization projects command execution into every client network it manages, well beyond the assessed system.' cisa_kev true, kev_date 2025-08-13, active_exploitation 'confirmed', poc_available true, cvss 9.8. patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The blast radius the packet describes for this CVE — every managed downstream estate, command execution projected into every client network the console manages — is a multi-customer incident, and almost all of the response consists of actions taken on networks the entity running the N-Central server does not own. That has to be rehearsed before it is needed, because it cannot be negotiated during the incident. For this platform the playbook is: revoke and reissue the agent-to-server trust material so managed endpoints stop honouring the compromised console, invalidate and rotate every credential the console holds for managed environments (domain and local administrator accounts, remote-access credentials, integration API keys, and credentials for the backup and monitoring tooling N-Central drives), audit every automation policy, scheduled task and script run through the console back to the start of the exposure window, define the criteria under which a managed endpoint that executed console-delivered content in that window is quarantined, and pre-agree the customer notification path since the parties who need to act are not the ones holding the server. Precondition on scoping, and it is the reason this cannot be improvised: the start of the exposure window is not derivable from this entry — the packet states the KEV dateAdded of 2025-08-13 is the formal listing date and the actual in-wild observation may predate it by weeks — so the downstream review has to run to a conservatively earlier boundary rather than to the listing date, and a playbook written during the incident will default to the listing date because it is the only number to hand. This control governs the response. It neither prevents the deserialization RCE nor substitutes for taking the vendor update and its restart.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-08-13, active_exploitation 'confirmed'; active_exploitation_notes: 'KEV listing is CISA's confirmed-exploitation attestation. The dateAdded is the formal KEV listing date; the actual in-wild observation may predate it by weeks.' attack_vector: unauthenticated remote code execution on the RMM server via an insecure-deserialization flaw (CWE-94). The NIS2-Art21-vulnerability-management gap records the cascade to 'every managed downstream estate' as 'a multi-customer incident'; the UK-CAF-B4 gap records that CAF system-security scoping 'stops at the entity boundary'; the AU-Essential-8-Patch gap records that the maturity model 'has no concept of the downstream managed fleet a single RMM RCE simultaneously exposes'. The NIST-800-53-SI-2 framework_coverage gap notes that 'RMM/ITSM/endpoint-management compromise reaches the entire managed estate'.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-8088": {
     "name": "RARLAB WinRAR Path Traversal Vulnerability (variant: CVE-2025-8088)",
@@ -24539,7 +24844,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation here requires a user to open the attacker's spreadsheet: the packet's vector has the specially crafted Excel file delivered as an email attachment or hosted on a malicious website, with code execution following when it is opened. On any Microsoft Office install that has not reached the fixed build, the delivery path is therefore the enforceable control. Require the untrusted-origin marking (Mark-of-the-Web) on every Office file arriving by mail, web download, or untrusted file share, and require marked documents to open in Protected View — an isolated, reduced-privilege render — instead of the full parsing path that carries the CWE-94 sink. That render is also the only least-privilege boundary available on this path: the least-privilege gap cited on this entry concerns account scoping, but the code here executes as whichever user opened the attachment, so privilege containment has to happen at the render rather than in the account model, and an account-privilege attestation passes cleanly while the parser runs with the target's full rights. Provenance must survive the container the attachment arrives in — a file extracted from a ZIP, mounted from an ISO or VHD, or renamed must inherit the marking rather than lose it — and 'Enable Editing' on externally sourced spreadsheets must be blocked by policy rather than left to the person the mail was aimed at. Distinguishing test: mail a marked spreadsheet nested inside an archive to a managed workstation, extract it, and confirm the extracted file still opens in Protected View; an Office-hardening attestation covering macro and add-in settings reads clean while a provenance-stripped spreadsheet reaches the vulnerable parser. Precondition: this constrains the render, it does not remove the sink. A user permitted to click through to editing, or a file that arrives by a path which never applies the marking — removable media, a share configured as a trusted location — is back on the full parsing path, so this is the control for the window before the fixed build and its restart land, not a substitute for them.",
+        "evidence": "Packet fields for CVE-2007-0671 (Microsoft Office Excel Remote Code Execution Vulnerability): cwe_refs CWE-94; cisa_kev true, kev_date 2025-08-12, active_exploitation confirmed; rwep_score 77, cvss 9.8; poc_available true. The vector states the vulnerability can be exploited when a specially crafted Excel file is opened, that the malicious file could be delivered as an email attachment or hosted on a malicious website, and that opening it allows an attacker to execute remote code on the affected system. Cited gaps: AU-Essential-8-App-Hardening ('Essential Eight Office hardening that blocks untrusted content is the control that neutralizes this email-delivered malicious-Excel RCE, and it is not guaranteed enabled'), UK-CAF-B4 ('System-security hardening should block file-borne execution, yet a crafted Excel document delivered by email or web link still reaches code execution on under-hardened clients'), NIST-800-53-AC-6 ('Least-privilege presumes a working authentication / authorization boundary').",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock this control anchors is unusual on this entry, and that is the point: the packet records a 2025-08-12 KEV listing on a 2007 CVE with confirmed in-the-wild exploitation, and states that the legacy re-listing exists because long-tail unpatched estates remain exposed. So the population is not the hosts a recent patch cycle touched — it is the Microsoft Office installs a routine cycle never reaches: unmanaged and per-user copies outside managed software distribution, machines rebuilt from old images or restored from backup, long-offline and air-gapped workstations, and the estates the packet's own gaps describe as still running vulnerable builds. Enumerate those against the vendor advisory the packet defers to, since affected_versions gives the range only as 'per vendor advisory' and the fixed build has to come from that advisory per install rather than from an assumed version. Completion is measured on the build the running Office process is executing, not on an 'approved' or 'downloaded' status in the management console: the packet records a vendor patch requiring a reboot with no live-patch path, so a workstation where the update installed while the restart is still pending — and an Excel process that stayed open across the update — is still running the pre-fix parser and is not remediated. Priority follows the packet rather than the age of the CVE: a public PoC, confirmed exploitation and a current KEV listing make this an active item on the KEV clock, and treating a 2007 identifier as historical is precisely the triage error that produced the long-tail estate the re-listing documents.",
+        "evidence": "Packet fields for CVE-2007-0671: patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.'; affected 'Microsoft Office — see vendor advisory linked in verification_sources for affected version ranges'; affected_versions 'Microsoft Office — versions per vendor advisory'; cisa_kev true with kev_date 2025-08-12; active_exploitation confirmed; poc_available true; rwep_score 77. attack_vector states the CISA KEV listing is 2025-08-12 with confirmed in-the-wild exploitation and that 'the legacy re-listing exists because long-tail unpatched estates remain exposed'. Cited gaps: NIST-800-53-SI-2 (30-day flaw-remediation SLA inadequate for a KEV-listed actively-exploited client RCE; 'legacy KEV re-listings document organizations still running unpatched builds') and ISO-27001-2022-A.8.8 (''Appropriate timescales' is undefined ... the legacy KEV re-listing exists because organizations still run vulnerable Office/IE/Windows builds').",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This applies to one slice of the exposed population and has to be scoped to it. The packet's patch-management gap records that this Excel RCE persists wherever unpatched or end-of-life Office builds still open attachments, and patch_available true means a fix exists for this CVE — not that every install carrying the flaw can still receive one. The determination is therefore per install rather than per product: for each Microsoft Office install the packet's affected field names, establish from the vendor advisory whether that version can still be driven to the build carrying this fix. Installs that can are remediation items on the KEV clock that opened 2025-08-12, and because the packet records a reboot requirement with no live-patch path, they are not complete until that restart is taken. Installs on an Office version past end-of-support cannot reach a fixed build at all; for those the terminal state is removal or replacement on a dated schedule, because such a copy is exposed not only to this parser flaw but to everything found in Office since its last servicing, and it will keep opening mailed spreadsheets in the meantime. The failure this prevents is a compliance record that reads clean while the exposure stands: an estate whose supported installs all report the fixed build closes the flaw-remediation ticket, while the out-of-support copies — precisely where the packet says this legacy CVE lives — are carried as an accepted risk with no removal date. Scope this to the Microsoft Office installs the packet names; a crafted spreadsheet opened in some other vendor's application is not this CVE, and treating every out-of-support office suite in the estate as an instance of it manufactures replacement work no evidence in this packet supports. Precondition: this reaches only the installs an inventory can see, and an unmanaged per-user copy is remediated by removing it, not by recording it as accepted.",
+        "evidence": "Packet fields for CVE-2007-0671: patch_available true; patch_required_reboot true; live_patch_available false, with live_patch_notes recording that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction; affected 'Microsoft Office — see vendor advisory linked in verification_sources for affected version ranges'; affected_versions 'Microsoft Office — versions per vendor advisory'; kev_date 2025-08-12; active_exploitation confirmed; poc_available true. The NIS2-Art21-patch-management gap states: 'Patch-management duties assume the Office fleet is current, but this legacy Excel RCE persists wherever unpatched or end-of-life Office builds still open attachments.' The vector records delivery as an email attachment or a malicious website, with code execution when the crafted Excel file is opened.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2013-3893": {
     "name": "Microsoft Internet Explorer Resource Management Errors Vulnerability",
@@ -28154,7 +28491,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "An RT-AX55 is the trust boundary for whatever sits behind it — a home-office or a small branch network — and this entry is the case where the ordinary remediation programme structurally cannot reach the device: the packet's own gaps record that router firmware sits outside standard Essential Eight patch tooling and that CAF's system-security objective assumes centrally-managed network devices rather than SOHO routers whose firmware updates are user-driven. So the requirement here is a remediation tier for the RT-AX55 that does not depend on the estate's software-distribution channel. Enumerate every RT-AX55 in service, including the remote-worker homes and branch closets where these units actually live and where no management console sees them; take the fixed firmware level from the ASUS advisory the packet points to rather than assuming a build, since the entry records affected versions only by reference to that advisory; and drive each unit onto it against the clock that opened with the 2025-06-02 KEV listing rather than a device-refresh cycle. Completion is measured on the firmware the unit is running after its restart, not on a download: the packet records that the vendor patch typically requires a service restart or system reboot and registers no live-patch tool, so a router that fetched firmware and was never restarted is still executing the vulnerable code and must be counted exposed. Where a unit cannot be reached on that clock, the tier's alternative is isolation of the vulnerable interface — the administration surface must not answer from the WAN side, and the segment behind the router is treated as untrusted until the firmware lands. Precondition on that alternative, which is where this control is usually over-claimed: restricting the administration interface bounds who can present the request, but the packet's stated access requirement is a remote authenticated attacker, so every credential holder still satisfies it — including anyone reusing a default or shared password, which the packet's NIS2 gap names as the common condition on this class of edge hardware. Isolation buys the window; it does not close the path.",
+        "evidence": "Packet for CVE-2023-39780, ASUS RT-AX55 Routers OS Command Injection Vulnerability: CWE-78; cisa_kev true with kev_date 2025-06-02; active_exploitation confirmed; rwep_score 77, cvss 9.8; poc_available true; patch_available true; patch_required_reboot 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 'ASUS RT-AX55 devices contain an OS command injection vulnerability that could allow a remote, authenticated attacker to execute arbitrary commands'; affected_versions 'ASUS RT-AX55 Routers — versions per vendor advisory'; AU-Essential-8-Patch gap 'Router firmware sits outside standard Essential Eight patch tooling, so the 48-hour patch-application window is unreachable on consumer ASUS routers'; UK-CAF-B4 gap 'CAF's system-security objective assumes centrally-managed network devices, not SOHO routers whose firmware updates are user-driven'; NIS2-Art21-network-security gap 'consumer RT-AX55 routers sit at the network edge where default and reused credentials are common'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For an RT-AX55 that was reachable by an untrusted caller during the exposure window, the firmware update is not the end of the work. The packet records confirmed in-the-wild exploitation and a public PoC, and its NIS2 gap names botnet recruitment as what this command injection is used for — so the assumption the runbook must default to is that the box ran attacker code, and reflashing replaces the vulnerable binary while removing nothing the attacker left in the device's configuration. On this product that means specifically: attacker-set DNS servers, port-forwards and firewall rules, a changed or added administrative credential, and any persistence in the router's own settings all survive a firmware update applied in place, and every one of them keeps working after the vulnerability is closed. Credential rotation carries extra weight here because the packet's vector requires an authenticated attacker: the credential that reached the injection is either still valid or has been replaced by one the attacker chose. The runbook for an exposed unit is therefore capture the running configuration as evidence, factory reset, flash the fixed firmware from the vendor advisory, rebuild the configuration from a known-good baseline rather than restoring the saved config file (which is exactly where attacker-set entries would be carried forward), rotate the administrative password and the WLAN pre-shared key, and treat credentials used by clients behind that router during the window as exposed. Boundary of the requirement: this is the default for a unit with plausible exposure during the window, not for every RT-AX55 in the estate — a unit no untrusted caller could reach is a straightforward patch item, and treating them alike wastes the rebuild capacity on the units that need it.",
+        "evidence": "Packet for CVE-2023-39780, ASUS RT-AX55 Routers OS Command Injection Vulnerability: active_exploitation confirmed with cisa_kev true (kev_date 2025-06-02); poc_available true; vector 'a remote, authenticated attacker to execute arbitrary commands'; attack_vector 'an OS command-injection flaw (CWE-78) enabling ... remote command execution on the router'; NIS2-Art21-network-security gap 'making this authenticated command injection a botnet-recruitment vector that network-security obligations do not cover for unmanaged edge hardware'; framework_coverage NIS2-Art21-network-security 'does not address end-of-life devices that can only be replaced, or appliance compromise that requires rebuild rather than patch-in-place'; UK-CAF-B4 gap 'the OS command-injection path on the RT-AX55 falls outside its secure-configuration coverage'; patch_available true with patch_required_reboot true.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The RT-AX55's administration surface is the constrained user surface this control governs, and the packet describes it failing in the exact pattern the control forbids: a remote, authenticated attacker executes arbitrary commands on the device, meaning a management function that should only write a setting is instead passing caller-supplied input into an OS command on the router. Applied to this product, the requirement is that the router's management functions reach system operations only through a constrained, validated interface, so that the administration surface's own parameter handling is not the single thing standing between a logged-in user and command execution at the device's privileged level. This is why the least-privilege gap recorded on this entry cannot close the path: a consumer router's account model is one or two administrative logins, and the flaw needs no privilege beyond what the legitimate user already holds — an attestation stating that only administrators can sign in to the router passes cleanly while any credentialed caller reaches the shell. Precondition: the ASUS firmware update is what repairs that boundary; this control states the property to verify and does not implement it. Until the fixed firmware and its restart land, the only operator-side lever is reducing who can present a request to the administration interface — disabling WAN-side administration, and restricting it to a management segment where the deployment allows one — which bounds the population that can attempt it but does not close it, because every remaining credential holder still reaches the same path, and the lever is simply unavailable on a unit whose administration interface has to stay reachable from the client network it serves.",
+        "evidence": "Packet for CVE-2023-39780, ASUS RT-AX55 Routers OS Command Injection Vulnerability: cwe_refs CWE-78; vector 'ASUS RT-AX55 devices contain an OS command injection vulnerability that could allow a remote, authenticated attacker to execute arbitrary commands. As represented by CVE-2023-41346.'; NIST-800-53-AC-6 gap 'Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.'; NIS2-Art21-network-security gap noting default and reused credentials are common on these edge routers; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2025-4632": {
     "name": "Samsung MagicINFO 9 Server Path Traversal Vulnerability (variant: CVE-2025-4632)",
@@ -28883,7 +29252,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A DrayTek Vigor router is the trust boundary for the site it fronts, and this defect sits on that boundary device's own web management interface: the packet places the OS command injection in /cgi-bin/mainfunction.cgi/apmcfgupload and records unauthenticated remote command execution on the router itself. For this CVE the control means affected Vigor units run on a perimeter-tier clock that opened with the 2025-05-15 KEV listing rather than on the ordinary appliance patch window, and that the web management interface is taken off every untrusted-reachable path for the duration of that clock. Scope the sweep from the affected fields, not the vector's headline models: the vector names Vigor2960, Vigor300B and Vigor3900, but affected and affected_versions record the scope only as DrayTek Vigor Routers with versions per vendor advisory, so the model and firmware list must be read from that advisory — a sweep restricted to the three models the vector happens to name reports clean across an estate standardised on another Vigor model. Completion is measured on the firmware the unit is executing: the packet records a vendor patch with no live-patch path and a fix that typically requires a service restart or system reboot per the KEV requiredAction, so a unit that has taken firmware but has not restarted onto it still runs the vulnerable code. Distinguishing test: from an external address and from a client segment with no administrative role, request the router's web management interface including the /cgi-bin/mainfunction.cgi path — anything that answers is within reach of the published exploit, and 'management is LAN-side only' is a statement of intent, not a demonstration. Precondition on the isolation half: blocking WAN-side administration removes the internet path, but a Vigor unit exists to serve the client network attached to it and every client on that network still reaches the management interface, so on a unit fronting a general user network isolation bounds the attacker population rather than closing the path, and it removes nothing from a unit that was already exploited.",
+        "evidence": "Packet fields: cwe_refs CWE-78; vector places the OS command injection in /cgi-bin/mainfunction.cgi/apmcfgupload of the web management interface on DrayTek Vigor2960, Vigor300B and Vigor3900; attack_vector records unauthenticated remote command execution on the router; cisa_kev true with kev_date 2025-05-15; active_exploitation confirmed; poc_available true; cvss 9.8, rwep_score 77; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes stating the vendor patch typically requires a service restart or system reboot per the KEV requiredAction; affected and affected_versions give the scope only as 'DrayTek Vigor Routers — versions per vendor advisory'. The UK-CAF-B4 gap names removing the DrayTek web-management interface from WAN exposure as the single reliable compensating control; the NIST-800-53-SI-2 gap records the 30-day flaw-remediation SLA as far longer than the observed exploitation window for this KEV-listed unauthenticated flaw on an internet-facing network device.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The Essential-Eight gap on this entry states where this starts: SOHO-grade Vigor routers are seldom in the patch inventory at all, so the first requirement is an inventory naming every DrayTek Vigor unit in service with its model, hardware revision and running firmware version. The packet gives affected versions only as 'DrayTek Vigor Routers — versions per vendor advisory', so both the affected-model list and the fixed firmware level have to be read from that advisory per model rather than inferred from the three models the vector names, and each unit's end-of-support status must be obtained from the vendor rather than assumed in either direction — patch_available true says a fix exists for this CVE, not that every Vigor model in service can still receive one. Units whose model and revision have fixed firmware are remediation items on the clock that opened with the 2025-05-15 KEV listing; because the packet registers no live-patch path and a fix that typically requires a service restart or system reboot, a unit that has taken firmware but not restarted onto it still executes the vulnerable code and counts as exposed. Units whose model has no fixed firmware per the advisory cannot be patched at all and are replacement items needing a dated schedule — closing this entry at 'every unit reports the fixed build' leaves an unsupported Vigor with a public PoC and confirmed exploitation in service indefinitely, which is precisely what this entry's ISO A.8.8 coverage records when it notes that unmanaged and end-of-life devices fall outside most patch programs entirely and that such devices can only be replaced, not patched. Precondition: an inventory reaches only units the operator knows about, and home-office and small-branch Vigor units bought outside procurement are the population this class is mass-exploited through — they are remediated by being found and then updated or removed, not by being absent from the report.",
+        "evidence": "Packet fields: affected 'DrayTek Vigor Routers — see vendor advisory linked in verification_sources for affected version ranges' and affected_versions 'DrayTek Vigor Routers — versions per vendor advisory'; patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes recording a service restart or system reboot per the KEV requiredAction; cisa_kev true, kev_date 2025-05-15; active_exploitation confirmed; poc_available true. The AU-Essential-8-Patch gap states SOHO-grade Vigor routers are seldom in the patch inventory, leaving this KEV-listed edge-device RCE exposed on the internet. This entry's framework_coverage records for ISO-27001-2022-A.8.8 that unmanaged/EOL devices fall outside most patch programs entirely, for NIST-800-53-SI-2 that many such devices run end-of-life firmware with no available fix, and for NIS2 that end-of-life devices can only be replaced, not patched.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet gives confirmed active exploitation, a public PoC and unauthenticated command execution on the router, so for any Vigor unit whose web management interface was reachable from an untrusted network during the exposure window, firmware alone is not remediation: the update replaces the vulnerable code and removes nothing the attacker executed through it. Applied to this device the runbook means exporting the unit's configuration for off-box review, rebuilding it from a known-good baseline rather than carrying the running configuration across the update, and comparing that configuration for attacker-added administrative accounts, port forwards, remote-access and tunnel settings before the unit returns to service — then rotating the administrative credential and every credential the configuration held or that transited the router. This is the only part of the response that speaks to the least-privilege gap recorded on this entry: the attacker never authenticates as any Vigor operator, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the path stays open; what least privilege can still do is bound what the credentials recovered from a compromised router unlock elsewhere, which is a rotation-and-scoping exercise off the device. It is also the answer to the network-security gap on this entry, which records that the duties assume the router is the boundary rather than the target — this control treats it as the target. Precondition: the rebuild is only meaningful against a baseline held off the device, because a configuration exported from a unit that was already exploited carries whatever was added to it, and 'the configuration looks normal' is not a compromise assessment for a device that executed attacker-supplied commands.",
+        "evidence": "Packet fields: active_exploitation confirmed with active_exploitation_notes stating the KEV listing is CISA's confirmed-exploitation attestation and that in-wild observation may predate the dateAdded by weeks; poc_available true; attack_vector records unauthenticated remote command execution on the router via the CWE-78 flaw; patch_available true with patch_required_reboot true and live_patch_available false. The NIS2-Art21-network-security gap states that network-security duties assume the router is the boundary, not the target, and that a command injection on the internet-facing Vigor management CGI turns the perimeter device itself into the attacker's entry point. The NIST-800-53-AC-6 gap states that least privilege presumes a working authentication/authorization boundary and that the KEV-listed exploit demonstrates the boundary is breakable from a baseline context.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2025-32756": {
     "name": "Fortinet Multiple Products Stack-Based Buffer Overflow Vulnerability",
@@ -33880,7 +34281,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The sequence the packet records is what makes the standard cycle indefensible for this CVE: Commvault released patches on 2025-04-10, the advisory and a public watchTowr PoC appeared 2025-04-23/24, a Metasploit module followed, and CISA listed the CVE on 2025-05-02 with a 2025-05-23 due date. A fully weaponized, unauthenticated CVSS 10.0 chain was therefore public roughly two weeks after the fix shipped and three weeks before the KEV due date, and the packet records exploitation as opportunistic and mass-scanning-driven — meaning exposure was a function of being reachable, not of being interesting to an attacker. Applied to this product, the control means the Command Center is driven to a fixed build on the KEV clock rather than in the next backup-infrastructure change window, and completion is recorded per instance against the maintenance pack for that instance's own release line: 11.38.20 via SP38-CU20-433 or SP38-CU20-436, or 11.38.25 via SP38-CU25-434 or SP38-CU25-438. Those are not interchangeable — an estate standardised on the 11.38.25 long-term line is not remediated by a CU20 pack, and the reverse holds too, so a single 'Commvault patched this cycle' line covers instances it never touched. Enumerate both platforms the packet names, Linux and Windows; a sweep of one leaves the other unmeasured. patch_required_reboot is false, which records that no host reboot is required; it does not mean the fix is live on deployment, and live_patch_available is false, so nothing remediates a running Command Center short of taking the maintenance pack — measure on the pack level the running instance reports. Distinguishing test: produce every Command Center instance with its operating system and its running maintenance-pack level and show each is at or above the pack for its line. An instance still on the 11.38.19 build keeps serving deployWebpackage.do to unauthenticated callers no matter how current the surrounding fleet is.",
+        "evidence": "Packet fields for CVE-2025-34028: name 'Commvault Command Center Path Traversal Vulnerability'; affected_versions list 'Commvault Command Center Innovation Release 11.38.0 through 11.38.19 (Linux and Windows)', 'NVD-stated affected range: 11.38.0 to 11.38.20', 'Fixed in 11.38.20 via maintenance packs SP38-CU20-433 and SP38-CU20-436', 'Fixed in 11.38.25 via maintenance packs SP38-CU25-434 and SP38-CU25-438', 'patches released 2025-04-10'; cisa_kev true, kev_date 2025-05-02, framework_control_gaps naming the CISA due date 2025-05-23; active_exploitation 'confirmed'; active_exploitation_notes 'advisory + PoC published 2025-04-23/24 ... exploitation was opportunistic/mass-scanning-driven, accelerated by the public watchTowr PoC and a subsequent Metasploit module'; cvss 10; rwep_score 72; poc_available true; patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The packet puts two distinct defects on one Command Center endpoint, and this control is the statement of what the fixed build has to establish on both. deployWebpackage.do answers without authentication (CWE-306), so any network actor can present a request; and the servicePack parameter selects where content from the fetched ZIP lands (CWE-22), so the caller — not the server — decides the destination path. Bound to this product, the requirement is that the endpoint authorizes its caller before any package is fetched or unpacked at all, and that the destination path is canonicalized and verified to resolve inside the temporary directory before the write executes, so a caller-supplied servicePack value cannot relocate a JSP into a web-accessible path. Precondition: the vendor maintenance pack is what establishes those properties — this control states what to verify, it does not implement it, and it gives nothing to an instance that has not yet taken 11.38.20 or 11.38.25. The half of this control that still has value after the fix lands is the one operators most often skip: the maintenance pack closes the write path and removes nothing already written through it. Exploitation is confirmed, it was mass-scanning-driven, and a public PoC plus a Metasploit module existed before the KEV listing, so an instance that was reachable during that window has to be examined for a planted JSP under its web-accessible paths and for actions taken by the Commvault service account the planted code would run as — an artifact dropped before remediation survives the upgrade and stays executable by anyone who requests it, and no patch-level report will show it. Distinguishing test: on a staging Command Center, send an unauthenticated request to deployWebpackage.do carrying a servicePack value that resolves outside the temporary directory, and confirm it is refused before anything is fetched or written. A system-security attestation recorded as met by 'patches applied in a managed cycle' passes while an unauthenticated endpoint is selecting file destinations from request input.",
+        "evidence": "Packet fields for CVE-2025-34028: cwe_refs CWE-22 and CWE-306; vector 'The Command Center exposes the deployWebpackage.do endpoint without authentication (CWE-306) ... a path-traversal in the servicePack parameter (CWE-22) then relocates a malicious JSP from that temp directory into a web-accessible path. Requesting the planted JSP executes attacker code, yielding unauthenticated remote code execution in the context of the Commvault service account. The chain requires no credentials and no user interaction (CVSS 3.1 = 10.0, AV:N/AC:L/PR:N/UI:N/S:C)'; active_exploitation 'confirmed'; poc_available true with active_exploitation_notes recording the watchTowr PoC (2025-04-23/24) and a subsequent Metasploit module ahead of the 2025-05-02 KEV listing; affected_versions fixed builds 11.38.20 and 11.38.25; framework_control_gaps UK-CAF-B4 'recorded as met by \"patches applied in a managed cycle\"'.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "Commvault Command Center is the console of the backup tier, and the packet's chain ends with code execution in the context of the Commvault service account — the identity the backup platform holds against everything it protects and the data it holds. Reachability is the exploit precondition here in both directions, and both are levers the operator holds during the window before the maintenance pack lands. Inbound: the Command Center web surface should answer only from an operator subnet or an authenticated VPN, not from the internet and not from a general user VLAN. The packet records exploitation as opportunistic and mass-scanning-driven, which means internet reachability rather than targeting is what selected victims — an instance nobody could route to was not in the population regardless of its build. Outbound: the chain's middle link requires the Command Center server itself to fetch an attacker-hosted ZIP, because the endpoint performs no host validation on the fetch, so constraining what the server may reach outbound breaks that link. Preconditions on both halves, because neither removes the surface. Inbound restriction bounds who can present the request and leaves the endpoint fully exploitable to anything inside the permitted segment — a compromised administrator workstation or jump host satisfies it in full — and the console has to stay reachable by the operators who run backups. Outbound restriction narrows where the ZIP can be served from but does not close the path: an attacker-controlled host inside the permitted egress or on an internal range still satisfies it, and a Commvault server that legitimately needs outbound access for vendor or cloud-storage destinations cannot be closed down entirely. Neither substitutes for reaching 11.38.20 or 11.38.25, and neither evicts an attacker who already ran the chain. Distinguishing test: from a general user VLAN and from an external address, attempt to load the Command Center web surface and reach deployWebpackage.do — anything that answers is within reach of the published PoC, and 'the backup console is on the internal network' is a claim about topology, not a demonstration that it is unreachable from untrusted segments.",
+        "evidence": "Packet fields for CVE-2025-34028: affected 'Commvault Command Center'; vector describes the unauthenticated deployWebpackage.do endpoint, a server-side request forgery with 'no host validation' that forces the server to 'download an attacker-hosted ZIP \"install package\"', and remote code execution 'in the context of the Commvault service account' requiring 'no credentials and no user interaction'; active_exploitation_notes 'exploitation was opportunistic/mass-scanning-driven, accelerated by the public watchTowr PoC and a subsequent Metasploit module'; cvss 10 (AV:N/AC:L/PR:N/UI:N/S:C); patch_available true with fixed builds 11.38.20 / 11.38.25; live_patch_available false; framework_control_gaps AU-Essential-8-Patch 'a compliant maturity-level-2 org on its normal cycle remains exposed to this unauthenticated path-traversal to RCE until its next window'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-58136": {
     "name": "Yiiframework Yii Improper Protection of Alternate Path Vulnerability",
@@ -34106,7 +34541,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The SMA100 is an SSL-VPN remote-access appliance — the trust boundary itself — and this entry is the case where a CVSS-driven SLA sends it down the wrong lane: CVSS 7.2 sits below most frameworks' emergency band while the packet records RWEP 77, a public PoC, KEV listing on 2025-05-01 with a CISA due date of 2025-05-22, and SonicWall confirming in-the-wild exploitation around 2025-04-29. The tier requirement for this device: the firmware upgrade runs on the KEV clock rather than in the appliance-maintenance window, across every model the packet names — SMA 200, 210, 400, 410 and 500v running 10.2.1.9-57sv or earlier — to a minimum of 10.2.1.10-62sv and to SonicWall's recommended 10.2.1.14-75sv or later. Completion is measured on the firmware the running appliance reports: patch_required_reboot is true and live_patch_available is false, so a unit that has staged firmware but not rebooted onto it is still executing the vulnerable code and counts as exposed, and on a remote-access appliance that reboot is the step most likely to be deferred because taking it drops every connected user session — a deferral recorded as patched is the specific way this remediation goes wrong. Precondition on the alternative the tier permits: isolating the vulnerable interface. The packet states only that the SSL-VPN management interface is network-reachable, so where the deployment can restrict that interface to an operator network, doing so bounds who can submit the crafted request; where it cannot be separated from the internet-facing service the appliance exists to provide, that half of the tier is unavailable and the reboot onto fixed firmware is the only remediation. Neither form neutralizes the metacharacter handling.",
+        "evidence": "cvss 7.2 against rwep_score 77; cisa_kev true with kev_date 2025-05-01; the NIST-800-53-SI-2 gap records the CISA due date as 2025-05-22 and states the operationally-meaningful clock is days, not the standard patch cycle; active_exploitation confirmed, with active_exploitation_notes recording SonicWall publicly confirming active in-the-wild exploitation around 2025-04-29 and no vendor or CISA threat-actor attribution; poc_available true; affected_versions: 'SonicWall SMA 100 series (SMA 200, 210, 400, 410, 500v) running firmware 10.2.1.9-57sv and earlier — affected', 'Fixed in firmware 10.2.1.10-62sv (released 2023-12-04) and later', 'SonicWall recommends upgrading to 10.2.1.14-75sv or later'; patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes stating remediation is the vendor update plus the named compensating controls until it lands; the NIST-800-53-SC-7 gap states that when the boundary device itself carries the injection, boundary protection protects nothing in front of it; the AU-Essential-8-Patch gap states Essential Eight maturity is scored on cadence, not KEV-anchored emergency response.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "The packet is explicit that this flaw's stated precondition is administrative privilege, and equally explicit that in observed activity the precondition is not a barrier: attackers chain CVE-2024-38475, an Apache mod_rewrite path-mapping flaw in the same SMA100, to leak a logged-in administrator's session token, eliminating the need for valid credentials, and then use this CVE for command execution. Two requirements follow for this appliance. First, remediation is scoped to the chain rather than to this CVE alone: reaching 10.2.1.10-62sv establishes that the metacharacter-handling fix is present, but it is not by itself evidence that the path-mapping flaw supplying the session token is also fixed on that unit, so the firmware level chosen must be verified against the vendor advisory for CVE-2024-38475 as well, with the packet's recommended 10.2.1.14-75sv or later as the floor. Second, exposure during the window is bounded by enumerating which SMA100 units have their administrative surface reachable from untrusted networks and restricting it until the reboot onto fixed firmware completes. Precondition, and the reason this control is here rather than an identity control: because the observed path is session-token theft from a flaw on the same appliance, administrator credential strength, password rotation and MFA on the administrator account do not bound this — no authentication event occurs for them to gate, which is why an identity attestation on the appliance passes cleanly while the path stays open. Restricting administrative-surface reachability bounds the population that can submit the crafted request; it does not repair the neutralization, and any host inside the permitted segment still reaches the sink.",
+        "evidence": "vector and attack_vector: the SMA100 SSL-VPN management interface is network-reachable and an attacker holding administrative privilege submits a crafted request whose shell metacharacters are not neutralized (CWE-78), executing OS commands as the low-privileged 'nobody' user; both fields record that in observed in-the-wild activity the post-authentication precondition is met by chaining CVE-2024-38475 — an Apache mod_rewrite path-mapping flaw in the SMA100 — to leak a logged-in administrator's session token, 'eliminating the need for valid credentials'; active_exploitation_notes repeats the chain and notes watchTowr Labs' 'SonicBoom' is a researcher codename, not an adversary; affected_versions gives 10.2.1.10-62sv (released 2023-12-04) as fixed and 10.2.1.14-75sv or later as the vendor recommendation; the NIS2-Art21-network-security gap states perimeter and segmentation obligations assume the appliance is trustworthy and that a command injection in the network device itself defeats that assumption; patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet does not stop at command execution: it records that the injected commands are used to stage tooling and obtain interactive remote shells on the appliance, after which further on-box privilege escalation can target root, with exploitation confirmed in the wild. Firmware upgrade plus reboot restores the code; it evicts nothing that was staged, and the appliance's configuration and local administrative accounts carry across the upgrade untouched. For any SMA 200, 210, 400, 410 or 500v that was reachable while running 10.2.1.9-57sv or earlier during the exposure window, the requirement is therefore to treat the unit as compromised rather than as behind: export the configuration for review instead of restoring it wholesale onto the new build, rebuild at the vendor-recommended firmware, invalidate administrator sessions and rotate administrator credentials, and rotate credentials for users who authenticated through the appliance during the window. This is the complement of a managed patch cycle, which is exactly what the packet's CAF B4 gap describes being recorded as compliance — a cycle whose closure condition is 'firmware current' marks an appliance clean on which an attacker held an interactive shell. Preconditions and limits: the rebuild decision depends on establishing per unit whether it was reachable and at which firmware during the window, and where that cannot be evidenced the unit is treated as exposed rather than clean; the rebuild removes appliance-resident persistence only, so anything reached from the appliance into the internal network during the shell access the packet describes is incident-response scope that rebuilding the appliance does not recover; and rebuilding a remote-access concentrator drops every user session it serves, so it needs a scheduled path rather than being assumed free.",
+        "evidence": "vector and attack_vector: 'The injected commands are then used to stage tooling and obtain interactive remote shells on the appliance, after which further on-box privilege escalation can target root'; command injection executes as the low-privileged 'nobody' user per the same fields; active_exploitation confirmed, cisa_kev true with kev_date 2025-05-01 and SonicWall confirming active in-the-wild exploitation around 2025-04-29 per active_exploitation_notes; poc_available true, rwep_score 77; affected_versions names SMA 200, 210, 400, 410 and 500v on 10.2.1.9-57sv and earlier as affected, with 10.2.1.14-75sv or later recommended; the UK-CAF-B4 gap states CAF B4 is recorded as met by 'patches applied in a managed cycle' and that the managed cycle itself is the gap; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-1976": {
     "name": "Broadcom Brocade Fabric OS Code Injection Vulnerability",
@@ -34610,7 +35077,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet's exploitation record is why this control leads on this entry rather than a patch-cadence one: UNC6148 chained stolen admin credentials and OTP seeds with this injection on SMA 100 appliances the packet describes as fully patched but end-of-life. Reaching the fixed build is therefore an interim state on this product, not the finish line — a unit that is current but out of support is exposed to everything found in SMA 100 firmware since its last build, and this entry shows that is not a hypothetical. The requirement is an inventory naming every SMA 100 in service by the models the packet names — 200, 210, 400, 410 and 500v — with its running firmware, resolving two things per unit. First, whether it is above the vulnerable ranges the packet records (9.0.0.10-28sv and earlier, 10.2.0.7-34sv and earlier, 10.2.1.0-17sv and earlier); anything at or below is a remediation item on the clock that opened with the 2025-04-16 KEV listing, against the 2025-05-07 CISA due date the entry's flaw-remediation and technical-vulnerability gaps both cite. Second, whether that unit still has a support path at all, obtained from the vendor for that exact model rather than assumed in either direction; units without one cannot be carried by any patch programme and are replacement items needing a dated schedule, because a risk acceptance with no removal date leaves a KEV-listed appliance with confirmed exploitation terminating the estate's remote access indefinitely. Scope the sweep to the SMA 100 series the packet names — the entry ties this CWE-78 sink to the SMA 100 web management interface and gives no mapping into other SonicWall remote-access lines, so folding them in manufactures replacement work against products no evidence here implicates. Precondition on the interim half: live_patch_available is false and the packet states remediation is the vendor update plus the named compensating controls until it lands, with a reboot required — so a unit that has taken firmware but has not restarted onto it is still executing the vulnerable code and counts as exposed, and completion must be measured on the build the appliance is running rather than on the firmware file having been uploaded.",
+        "evidence": "Packet name: 'SonicWall SMA100 Appliances OS Command Injection Vulnerability'; CWE-78; cisa_kev true with kev_date 2025-04-16 and active_exploitation 'confirmed'. active_exploitation_notes: UNC6148 'chains stolen admin credentials/OTP seeds with CVE-2021-20035 on fully-patched but end-of-life SMA 100 appliances to deploy the OVERSTEP persistent backdoor/user-mode rootkit (GTIG/Mandiant, July 2025)', an actor active since at least October 2024 with tradecraft overlapping historical Abyss-branded ransomware deployments. affected_versions: 'SMA 100 series (models 200, 210, 400, 410, 500v): 9.0.0.10-28sv and earlier', '10.2.0.7-34sv and earlier', '10.2.1.0-17sv and earlier'. The NIST-800-53-SI-2 and ISO-27001-2022-A.8.8 gap statements both record a CISA due date of 2025-05-07. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.' rwep_score 57, cvss 6.5, poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For an SMA 100 that was actually exploited, the vendor firmware is not the fix. The packet describes the actor using this injection as the on-box code-execution primitive to repack the INITRD boot image and install the OVERSTEP rootkit via /etc/ld.so.preload, producing persistent, reboot-surviving, log-tampering control of the appliance and a credential-exfiltration foothold for lateral movement. Each of those properties defeats patch-in-place specifically: the implant sits in the boot image and the preload path rather than in the vulnerable web-management component, and it survives the reboot the update itself requires, so an appliance can come back from the upgrade on a fixed build and still be under the actor's control. The requirement is that any SMA 100 which was reachable and running an affected build during the exposure window is handled as compromised until shown otherwise — configuration exported and reviewed off the appliance, the unit rebuilt from vendor media rather than upgraded in place (or replaced outright where the retirement control applies), and every credential that lived on or transited it rotated, including the administrator accounts and the OTP seeds, since the packet places both in the actor's hands already and describes the appliance as a credential-exfiltration foothold. Precondition, and it is the one operators get wrong here: the appliance's own logs cannot support a 'we were not affected' conclusion, because the packet records the implant as giving log-tampering control of the box — absence of evidence on-box is not evidence of absence, and that judgement has to rest on records held elsewhere. This is a response requirement only. It does nothing about the injection itself, which needs the vendor update the packet records, and it does not reduce the window before that update lands.",
+        "evidence": "Packet vector: the actor 'uses this injection as the on-box code-execution primitive to repack the INITRD boot image and install the OVERSTEP rootkit via /etc/ld.so.preload — converting a limited \"nobody\" command run into persistent, reboot-surviving, log-tampering control of the appliance and a credential-exfiltration foothold for lateral movement', after first obtaining 'valid admin credentials/OTP seeds (likely harvested in earlier intrusions)'. Injected commands execute as the low-privilege 'nobody' account. active_exploitation 'confirmed'; kev_date 2025-04-16; active_exploitation_notes attribute the campaign to UNC6148 with tradecraft overlapping historical Abyss-branded ransomware deployments (GTIG/Mandiant, July 2025). patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The only signal this campaign generates on the appliance is an authentication event, and it is exactly the record the implant can edit. The packet has UNC6148 arriving with valid admin credentials and OTP seeds harvested in earlier intrusions, so on the SMA 100 the exploitation looks like a legitimate administrator authenticating to the management plane and the appliance then doing something — and it has OVERSTEP giving log-tampering control of that same box. Applied to this appliance, the control means every SMA 100 forwards its management-plane authentication, administrative-action and system logs to a collector in a separate trust zone: different credentials, different management plane, and no administrative path from the appliance to the collector, so an admin login from an unfamiliar source or outside an operator's working hours is recorded somewhere the appliance cannot reach. Include the appliance's outbound connection records, because the packet describes the foothold as a credential-exfiltration platform for lateral movement, and egress from a remote-access appliance to an unfamiliar destination is observable from the network even when the on-box record is not. This is also what stops the estate's assurance about its boundary from depending on the boundary device's own integrity — the premise the cited boundary-protection and network-security gaps both rest on. Precondition, stated plainly because it is easy to overclaim: forwarding preserves what reached the collector before the implant landed and gives an independent view afterward, but the packet describes an actor with log-tampering control of the appliance, so what the appliance chooses to emit after compromise is not trustworthy either. Treat the post-compromise stream as suspect and lean on the pre-compromise record and network-side observation. It is detection only: it neither prevents the injection nor evicts OVERSTEP, and on an appliance already carrying the implant it bounds discovery time rather than exposure.",
+        "evidence": "Packet vector: the actor 'first obtains valid admin credentials/OTP seeds (likely harvested in earlier intrusions)' and the resulting control of the appliance is 'persistent, reboot-surviving, log-tampering ... and a credential-exfiltration foothold for lateral movement'. The NIST-800-53-SC-7 gap records that boundary protection treats this appliance as the boundary and protects nothing in front of it once the boundary device itself carries the flaw; the NIS2-Art21-network-security gap records that network-security obligations are met by perimeter and segmentation controls that assume the appliance is trustworthy. active_exploitation 'confirmed', kev_date 2025-04-16, attributed to UNC6148 (GTIG/Mandiant, July 2025). poc_available false.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-53150": {
     "name": "Linux Kernel Out-of-Bounds Read Vulnerability",
@@ -35424,7 +35925,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "SAP NetWeaver AS Java is the population this clock runs against, and for this entry the clock starts late relative to the flaw: the packet records original in-the-wild exploitation in August 2017 and a CISA listing only on 2025-03-19 with a 2025-04-09 due date, so an estate treating the KEV listing as first notice is starting years behind an exploited path. Bound to this product, the control means every AS Java 7.5 instance carrying ENGINEAPI 7.50 SP02 through SP05, and every SAP Central Process Scheduling (CPS) by Redwood 8.0 install, is driven to the level set by SAP Note 3476549 on the KEV clock rather than folded into the next SAP maintenance window, with completion measured on the component patch level the running instance reports rather than on a change ticket. The scope has to include the CPS/Redwood installs: the packet names them at all versions under that note, so an inventory built only from 'NetWeaver AS Java' asset names reports clean while the scheduler product carrying the same handler stays exposed. Precondition on remediation: live_patch_available is false and the packet states there is no live-patch path for this product class, so the vendor note is the only thing that removes the flaw, and the named compensating controls are all an operator holds until it lands. And because exploitation is confirmed and the packet's escalation is exfiltrating the SAP Secure Store and decrypting the credentials inside it with publicly available tooling, an instance that was reachable during the exposure window is not closed by applying the note — the attacker's subsequent logins to SAP applications use legitimate credentials, leave no exploit artifact, and survive the patch, so credentials held in that Secure Store must be treated as attacker-held and rotated.",
+        "evidence": "Packet: KEV-listed 2025-03-19, due 2025-04-09; active_exploitation confirmed; poc_available true; RWEP 70; CVSS 7.5; 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.' affected_versions: SAP NetWeaver Application Server (AS) Java 7.5; component ENGINEAPI 7.50 SP02 through SP05; SAP Central Process Scheduling (CPS) by Redwood 8.0 (and all versions per SAP Note 3476549). active_exploitation_notes: per NVD, originally exploited in the wild in August 2017 (SAP Security Note 2486657); Onapsis Research Labs reported renewed active exploitation in 2025, with attackers exfiltrating SAP system files including the SAP Secure Store binary to decrypt stored credentials and pivot into full SAP-application compromise; no public named threat-actor/ransomware attribution.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this entry a version-alone verdict is demonstrably wrong, and the packet says why: systems can remain exposed even above the original SAP Note 2486657 patch level, because the flaw was re-addressed by SAP Note 3476549. A scan result or patch register that marks a NetWeaver AS Java instance remediated because its ENGINEAPI component is newer than the 2017 fix is paper compliance; the operational test is whether the running instance sits at the 3476549 level specifically, and whether the SAP Central Process Scheduling by Redwood installs were enumerated at all, since the packet places them in scope at every version under that note. The second half of the test is reachability rather than version, and it is the half a credentialed SAP scan never performs: the vulnerable handler is scheduler/ui/js/ffffffffbca41eb4/UIUtilJavaScriptJS, answering pre-authentication over HTTP, so issue that request with dot-dot traversal in the query string against a staging instance and confirm the path is normalized and the read refused. An authenticated scan of the SAP stack never presents that unauthenticated request and returns nothing about the primitive. Precondition: this control verifies remediation, it does not deliver it — an instance this test finds still exposed needs the vendor note, and nothing in the test reduces its exposure in the meantime.",
+        "evidence": "Packet affected_versions: 'Older/earlier NetWeaver AS Java releases may also be affected; systems can remain exposed even above the original 2486657 patch level (re-addressed by SAP Note 3476549)' and 'SAP Central Process Scheduling (CPS) by Redwood 8.0 (and all versions per SAP Note 3476549)'. Vector: the scheduler/ui/js/ffffffffbca41eb4/UIUtilJavaScriptJS handler in SAP NetWeaver AS Java 7.5 is reachable pre-authentication over HTTP and fails to normalize `..` sequences in its query string, giving an unauthenticated remote attacker arbitrary file read (CWE-22). poc_available true. ISO-27001-2022-A.8.8 gap as recorded: 'appropriate timescales' is undefined for this actively-exploited directory-traversal arbitrary file disclosure.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "SAP NetWeaver AS Java is the enterprise ERP platform this control governs, and the failing surface is one of its management functions: the job-scheduler UI handler answers over HTTP before any authentication decision is taken and returns files selected by the caller's query string. Bound to this deployment, the control means the AS Java scheduler and Central Process Scheduling UI paths make their own authorization decision before serving anything, and that the AS Java HTTP surface carrying them is reachable only from segments with an operational need to reach the scheduler — not from a general user VLAN and not from an untrusted network. What makes this more than a patch-timing issue is where the pre-auth position leads: the packet's escalation is reading the SAP Secure Store and decrypting the credentials in it, after which the attacker's next action is an ordinary authenticated SAP login that no ERP account-model or privilege-scoping attestation distinguishes from a legitimate one. Precondition, and this is where the control is usually over-claimed: the endpoint-side path normalization and the authorization decision are properties the SAP notes establish — this control states what to verify and where to restrict, it does not implement them. Restricting reachability bounds who can send the traversal request but leaves the handler fully exploitable to anything inside the permitted segment, including a compromised workstation or contractor host, and it is unavailable where the scheduler UI must stay reachable by its normal user population.",
+        "evidence": "Packet vector: the handler is reachable pre-authentication over HTTP and fails to normalize `..` sequences; escalation comes from targeting SAP-specific files — chiefly the SAP Secure Store — and decrypting the recovered credentials with publicly available tooling, after which the attacker logs in to SAP applications and pivots to full compromise of the SAP environment despite the flaw itself yielding only confidentiality impact. UK-CAF-B4 gap as recorded: CAF B4 (system security) is treated as met by 'patches applied in a managed cycle', and the managed cycle is itself the gap because SAP NetWeaver was exploited before a normal cycle would have reached it. active_exploitation confirmed; KEV-listed 2025-03-19.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-48248": {
     "name": "NAKIVO Backup and Replication Absolute Path Traversal Vulnerability",
@@ -35557,7 +36091,40 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet leaves no interim state to reach. patch_available is false, and affected_versions records every firmware version of the Edimax IC-7100 as affected with no fixed version existing, because the product is end-of-life / end-of-service and will not receive a security patch; the vector states the same conclusion directly — the only durable remediation is network isolation or hardware replacement. So unlike a device where reaching the fixed build is an interim step, here there is no build any unit can be driven to, and the requirement is an inventory naming every IC-7100 in service with its location and its network reachability, with each unit placed on a dated replacement schedule. A risk acceptance carrying no removal date leaves a KEV-listed camera with a PoC public since June 2023 and confirmed enrollment into DDoS botnets in service indefinitely, which is the outcome this control exists to prevent. Scope the sweep to the model the packet names — the IC-7100 — and widen it only where a verified source identifies another product carrying the same /camera-cgi/admin/param.cgi handling. Precondition on the isolation that bridges the gap until replacement: the injection sits in the camera's own web management interface, so removing internet reachability — typically a router port-forward or a UPnP mapping, which is how these cameras acquire exposure — bounds who can send the request from outside, but the camera exists to be viewed from the network attached to it, and every host on that segment still reaches the CGI. Isolation therefore means placing the camera in a segment that can reach nothing else, not removing the path. And because exploitation is confirmed and the injected command stages and runs an architecture-matched Mirai ELF binary on the device, a unit that was internet-reachable is not returned to service by a configuration change: it is a removal item, and the segment and credentials it sat on belong on the incident path.",
+        "evidence": "Packet fields for CVE-2025-1316 (Edimax IC-7100 IP Camera OS Command Injection Vulnerability): cwe_refs CWE-78; cisa_kev true, kev_date 2025-03-19, active_exploitation confirmed; rwep_score 85, cvss 9.8; poc_available true; patch_available false; live_patch_available false. affected_versions records 'Edimax IC-7100 IP camera — all firmware versions (no fixed version exists; product is end-of-life / end-of-service and will not receive a security patch)'. The vector names the /camera-cgi/admin/param.cgi endpoint of the web management interface, the failure to neutralize OS shell metacharacters in the NTP_serverName field of the ipcamSource option, cameras commonly internet-exposed, an injected command that downloads a curl.sh/wget.sh stager pulling architecture-matched Mirai ELF payloads into a world-writable directory and running them to enroll the camera into a DDoS botnet, and states that because the device is end-of-life with no patch the only durable remediation is network isolation or hardware replacement. active_exploitation_notes record a public PoC available since June 2023 and Akamai SIRT honeypot activity from May 2024.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-118",
+        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
+        "description": "This entry's own citing gaps place the camera inside a zone-and-conduit model — IEC 62443-3-3 segmentation as the compensating control, and NIST SP 800-82r3 treating the device as a trusted endpoint inside a segmented cell — so both halves of this control have purchase here, but they carry different weight. The credential half is a lever the operator genuinely holds, unlike cases where the key is discoverable from the vendor's own software: the packet names unchanged default credentials admin:1234 as the route by which attackers commonly reach /camera-cgi/admin/param.cgi, so every IC-7100 in service should have that vendor default rotated. It must not be recorded as closing the path, because this entry's framework gaps describe the flaw as an unauthenticated OS command injection — rotating the password removes the commonly-observed access route without demonstrating that the endpoint requires a credential at all. The segmentation half is therefore load-bearing. Applied to this camera it means the IC-7100's web management interface answers only from the operator segment that legitimately views and administers it, not from the internet through a port-forward or UPnP mapping and not from a general user VLAN, and that the camera's outbound path is constrained as well — the packet's exploitation path is outbound by design, since the injected command fetches a curl.sh/wget.sh stager, pulls architecture-matched Mirai ELF payloads, and then beacons to C2 (angela.spklove.com:3093 for the strain Akamai labels 'Unstable Mirai'; merisprivate.net / ziparchive.xyz for the second, anti-debugging variant). An egress policy permitting the camera only the destinations its operation requires — including the NTP server named by the very field that carries the injection — breaks the stager fetch and the beacon. Distinguishing test: from a general user VLAN and from an external address, request /camera-cgi/admin/param.cgi on an IC-7100; anything that answers is within reach of a PoC public since June 2023, and 'the cameras are on the internal network' is a statement about topology rather than a demonstration that the CGI is unreachable. Preconditions: segmentation bounds who can send the request and egress control bounds what an injected command can retrieve; neither repairs the missing metacharacter neutralization, and any compromised host inside the permitted segment reaches the CGI in full. Because patch_available is false these are permanent compensating measures rather than a holding action before a fix, which is why the dated replacement schedule has to run alongside them.",
+        "evidence": "Packet fields for CVE-2025-1316: the vector states that an attacker who reaches /camera-cgi/admin/param.cgi — commonly via unchanged default credentials admin:1234, often on internet-exposed cameras — injects a shell command string executed as the CGI's privileged context, and that in observed campaigns the injected command downloads a curl.sh/wget.sh stager pulling architecture-matched Mirai ELF payloads into a world-writable directory. The endpoint's vulnerable field is NTP_serverName of the ipcamSource option. active_exploitation_notes name the Akamai-labelled 'Unstable Mirai' strain beaconing to angela.spklove.com:3093 and a second anti-debugging variant using merisprivate.net / ziparchive.xyz C2, with a public PoC since June 2023. Cited gaps: IEC-62443-3-3 ('zone-and-conduit segmentation is the compensating control, but an internet-reachable device ... bridges the IT and OT zones it is supposed to keep apart'), NIST-800-82r3 ('treats the device as a trusted endpoint inside a segmented cell; compromise ... turns it into an OT pivot'), NIS2-Art21-network-security ('perimeter and segmentation controls that assume the appliance is trustworthy'). patch_available is false and affected_versions records no fixed version because the product is end-of-life.",
+        "gap_closes": [
+          "IEC-62443-3-3",
+          "NIST-800-82r3",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This control's three-state distinction is what an IC-7100 estate needs, because the first state — binary patch deployed, vulnerability eliminated — is unreachable for this CVE and always will be: patch_available is false, every firmware version is affected, and affected_versions records that no fixed version exists because the product is end-of-life and will not receive a security patch. A camera whose management CGI has been isolated therefore sits permanently in the compensating-control state, and the audit record must show it as that, with the dated replacement action attached, rather than as remediated or as a closed flaw-remediation ticket. The failure this prevents is specific to a device with no patch path: a vulnerability-management report keyed on patched-versus-unpatched has no true state to move an IC-7100 into, so the finding either stays open forever and is eventually suppressed as stale noise, or it is closed on the isolation change — at which point the camera leaves the estate's exposure view while still running a CGI with a PoC public since June 2023 and confirmed exploitation into Mirai botnets. The same record must also distinguish the isolated units from the third state the control names, full exposure, since the packet's exploitation set is internet-reachable cameras and an unisolated unit is in that state today. Precondition: this is a reporting requirement, not a mitigation. It changes nothing on the device, and it is only meaningful if the compensating-control entry carries the removal date — an isolation record with no expiry is the same permanent open exposure written in different words, which is exactly the outcome a KEV due date of 2025-04-09 was meant to force.",
+        "evidence": "Packet fields for CVE-2025-1316: patch_available false; live_patch_available false; affected_versions 'all firmware versions (no fixed version exists; product is end-of-life / end-of-service and will not receive a security patch)'; cisa_kev true with kev_date 2025-03-19; active_exploitation confirmed; poc_available true, with active_exploitation_notes recording a public PoC since June 2023 and exploitation by at least two Mirai-variant botnets. The NIST-800-53-SI-2 gap records that the routine 30-day flaw-remediation SLA is far longer than the in-the-wild exploitation window for this KEV-listed unauthenticated OS command injection and that CISA set a 2025-04-09 due date. The vector records the device as end-of-life with no patch, leaving network isolation or hardware replacement as the only durable remediation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-24472": {
     "name": "Fortinet FortiOS and FortiProxy Authentication Bypass Vulnerability",
@@ -36912,7 +37479,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For Progress WhatsUp Gold the packet shows why the trigger for this SLA cannot be the KEV listing alone. Exploitation began 2024-08-30, within hours of the public PoC release, against internet-exposed instances; CISA listed it 2025-03-03 with a 2025-03-24 due date; and the fixed build, 2023.1.3, predates both. An organization whose emergency clock starts at KEV listing was therefore roughly six months late by construction, while one that started at patch availability had the fix on the shelf the whole time. Bound to this product, the requirement is that the four-hour clock start at the first observable of {fixed build published, working PoC public, KEV listing} for any internet-reachable WhatsUp Gold instance, and that the 2025-03-24 CISA due date be treated as the outer bound rather than the target. Remediation is the vendor update to 2023.1.3 or later; live_patch_available is false, so there is no in-place hot fix and no configuration change stands in for the update indefinitely. Note precisely what patch_required_reboot: false buys — it removes a host reboot from the change window, but the vulnerable code is the WhatsUp Gold web application served under the iisapppool\\nmconsole identity the packet names, so completion is measured on the build the running application reports after the update, not on the installer's exit status. Distinguishing test: confirm each instance's running application reports 2023.1.3 or later, and separately establish whether it was reachable from an untrusted network at any point after 2024-08-30 — that second question is an incident question, and a clean version check does not answer it.",
+        "evidence": "Packet: 'In WhatsUp Gold versions released before 2023.1.3, an unauthenticated Remote Code Execution vulnerability in Progress WhatsUpGold. The WhatsUp.ExportUtilities.Export.GetFileWithoutZip allows execution of commands with iisapppool\\nmconsole privileges' (CWE-22, CVSS 9.8, RWEP 68, poc_available true). active_exploitation_notes: 'Actively exploited beginning Aug 30, 2024 — within hours of the public PoC release... Added to CISA KEV March 3, 2025.' The NIST-800-53-SI-2 gap records the CISA due date as 2025-03-24. affected_versions: 'Affected: WhatsUp Gold before 2023.1.3', 'Fixed: 2023.1.3'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No live-patch path for this product class; remediation is the vendor update... plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "WhatsUp Gold is not a firewall, but the packet puts it in exactly the position this runbook governs — an internet-exposed service taking unauthenticated remote code execution while under active exploitation — and it names the post-exploitation behaviour that makes patch-in-place insufficient. Trend Micro's MXDR team observed attacks abusing the legitimate WhatsUp Gold process, in the iisapppool\\nmconsole context, to download and stage multiple remote-management tools (Atera, Radmin) as an initial-access foothold. Those are ordinary remote-administration agents installed on the host: updating WhatsUp Gold to 2023.1.3 removes the traversal path and leaves them running and reachable by whoever installed them, and they survive the update, an application restart and a host reboot alike. So for any instance that was internet-reachable between 2024-08-30 and the date it was actually serving 2023.1.3, the disposition is host-level — enumerate installed remote-management agents, services and scheduled tasks against a known-good baseline, rebuild where one is found rather than uninstalling in place, and rotate the credentials the host and its service identity used. Precondition: this is scoped by exposure window and reachability, not applied to every install; an instance that was never reachable from an untrusted network during that window is a patch item. The signal to hunt is the one the packet documents — the WhatsUp Gold application process initiating downloads or installer activity, and RMM agents present on a monitoring server that has no operational reason to run them. Absence of that signal is weak evidence wherever process-level telemetry was not retained on the host, which on a monitoring server is common.",
+        "evidence": "Packet active_exploitation_notes: 'Trend Micro's MXDR team observed attacks abusing the legitimate WhatsUp Gold process (the iisapppool\\nmconsole context) to download and stage multiple remote-management tools (Atera, Radmin) as an initial-access foothold on internet-exposed instances. Unauthenticated, so mass opportunistic scanning followed.' Exploitation began 2024-08-30 within hours of the public PoC release; CISA KEV 2025-03-03. Fixed build 2023.1.3; patch_required_reboot false; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The version boundary in this entry is one point release wide — affected is everything before 2023.1.3, fixed is 2023.1.3 — so any attestation that records the product at marketing-version granularity cannot answer whether the host is exposed, and a scanner or CMDB comparison that treats an install on the 2023.1 line as satisfying '2023.1' reports a vulnerable monitoring server as compliant. Bound to this product the operational test has two parts. Does the inventory carry the full point release for every WhatsUp Gold install? And is that value read from the running application rather than from an installer log or a change ticket — because patch_required_reboot is false, which removes the host reboot that would otherwise force the question, and live_patch_available is false, so nothing about the running instance changes until the updated application is actually serving. The second part is what makes the difference here: an organization can hold a true statement that the update was applied while the instance an attacker reaches is still the pre-fix build. Precondition: this is a verification control, not a remediation. It catches the false-clean report; it does not shorten the exposure, and on a host that was internet-reachable while exposed a clean version check says nothing about whether the host was already reached — that question is answered by hunting the staged remote-management agents, not by a build number.",
+        "evidence": "Packet affected_versions: 'Affected: WhatsUp Gold before 2023.1.3' and 'Fixed: 2023.1.3'. patch_required_reboot false; live_patch_available false. The AU-Essential-8-Patch gap records that Essential Eight patch maturity 'is scored on cadence, not on KEV-anchored emergency response'; the ISO-27001-2022-A.8.8 gap records that 'appropriate timescales' is left undefined while the operative clock is the CISA due date of 2025-03-24.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2018-8639": {
     "name": "Microsoft Windows Win32k Improper Resource Shutdown or Release Vulnerability",
@@ -37367,7 +37968,29 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_disclosure",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-058",
+        "name": "CLOUD-CONTROL-PLANE-CROSS-TENANT-CLAIM-VALIDATION",
+        "description": "Partner Center is not software an operator runs, so the usual expression of this control — patch the thing, then verify — has no target here. What the operator holds is the relationship the packet names: Partner Center brokers access into downstream customer tenants, so an unauthenticated privilege escalation inside partner.microsoft.com lands on the delegated grant rather than on any one organisation's server. Bound to this service the control means the cross-tenant calls a partner identity makes into a customer tenant carry a validated originating-tenant claim and are logged into a channel the customer controls rather than only into the partner's own console, and that the customer side actively watches that channel for partner-attributed actions no engagement explains — privileged-role assignments, application consents, and administrative operations arriving through the delegated path outside a scheduled piece of work. For a downstream customer this monitoring is the only lever that would have surfaced abuse of this flaw at all, because nothing in that customer's vulnerability register ever contained partner.microsoft.com and no scan of their estate would have shown anything. The distinguishing test is attribution rather than inventory: pull the customer tenant's privileged-operation log across the exposure window and show, for each partner-originated action, which engagement authorised it — an organisation that can name its partners but cannot attribute their individual actions has no way to separate this exploitation from routine delegated administration. Two preconditions, both load-bearing: originating-tenant claim validation is a property of the identity provider and not something a customer implements, so the customer's half is the monitoring and the scoping of the grant itself; and monitoring detects rather than prevents — it depends on audit data having been retained and reachable from before the 2025-02-25 KEV listing, and it does nothing about privilege already exercised during the window.",
+        "evidence": "affected_versions records 'Microsoft Partner Center (partner.microsoft.com online service) prior to the November 2024 server-side fix; remediated automatically in the cloud service', and patch_required_reboot is false — there is no operator-side installation step. The vector is 'An improper access control vulnerability in Partner.Microsoft.com allows an a unauthenticated attacker to elevate privileges over a network' (CWE-269, CVSS 8.7). active_exploitation is confirmed: the packet records that Microsoft detected exploitation in the wild but has not published attribution, delivery, or victim specifics, and that CISA added it to KEV on 2025-02-25 with a 2025-03-18 deadline. The downstream scope is the packet's own: Partner Center 'sits on a Power Apps backend used by MSPs and enterprises to manage cloud services and customer tenants', and 'Because Partner Center brokers access to downstream customer tenants, successful privilege escalation carries lateral-movement/supply-chain risk.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "This entry needs an incident playbook rather than a remediation task because its remediation already happened without the operator: the packet records the fix as server-side and applied automatically in the cloud service, so every patch-shaped obligation on this CVE completes itself while confirmed in-the-wild exploitation ran against Partner Center before the November 2024 fix landed. Partner Center is the fleet control plane in this case — the packet places it on a backend used by MSPs and enterprises to manage cloud services and customer tenants — so the unit of compromise is the delegated relationship, not a device. The playbook for this CVE covers both sides of that relationship: enumerate every delegated administrative grant the partner organisation holds into customer tenants and every grant a customer tenant has issued to a partner; review privileged-role assignments, application consents and administrative actions in each downstream tenant across the window that closed with the November 2024 fix; rotate credentials and re-consent applications for any identity that acted through the delegated path during it; and write the criteria that put a downstream tenant in scope rather than assuming it clean. Preconditions: this detects and recovers, it does not close the escalation path — only Microsoft's server-side change closes that — and it reaches only as far back as each tenant's retained audit data, so where retention is shorter than the exposure window the honest output is an unknown rather than a clean finding. That distinction matters more than usual here because poc_available is false and the packet records no published attribution, delivery or victim specifics, leaving an operator with no indicator list to match against and nothing to reason from except the delegated grants themselves.",
+        "evidence": "patch_available is true but affected_versions states the service was 'remediated automatically in the cloud service' after the November 2024 server-side fix, and patch_required_reboot is false; live_patch_available is false, with live_patch_notes recording that remediation for this product class is the vendor update plus compensating controls until it lands. active_exploitation is confirmed — 'Microsoft confirmed it detected exploitation in the wild but has not published attribution, delivery, or victim specifics' — and poc_available is false. CISA KEV listing 2025-02-25, due 2025-03-18. The control plane's reach is from the packet: Partner Center 'sits on a Power Apps backend used by MSPs and enterprises to manage cloud services and customer tenants' and 'brokers access to downstream customer tenants'.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-20953": {
     "name": "Oracle Agile Product Lifecycle Management (PLM) Deserialization Vulnerability",
@@ -37422,7 +38045,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The load-bearing fact on this entry is the interval. Oracle shipped the fix for the Agile PLM Export component in the January 2024 Critical Patch Update, and CISA did not list the CVE until 2025-02-24 with a 2025-03-17 due date — roughly a year later, on confirmed in-the-wild exploitation. So for this CVE the control is not 'respond faster than disclosure'; it is that a KEV listing must re-open an item the organization already triaged and closed. An 8.8 that requires a low-privileged account, on an internal supply-chain application, is exactly the shape of finding that a January 2024 patch review defers behind internet-facing work — and nothing in a normal vulnerability-management cycle revisits that decision when the same CVE is listed thirteen months later. Bind the SLA to the KEV listing date, not to the CVE's publication date, and run it against the population the packet names: every Oracle Agile PLM 9.3.6 deployment with the Export component, remediated by the January 2024 CPU. patch_required_reboot is false on this entry, which records that no host reboot is required; it does not mean the fix is live on deployment, and live_patch_available is false, so there is no path that remediates a running instance without taking the update — completion must be measured on the CPU level the running PLM instance reports, not on a change ticket that says the CPU was applied. Distinguishing test: produce, per instance, the patch level the application is actually executing and show it is at or above the January 2024 CPU. A vulnerability-management attestation recording the CPU as approved, downloaded, or scheduled passes cleanly while a 9.3.6 instance keeps serving the vulnerable ExportServlet. Precondition on how this is prioritised against other KEV work: the packet records poc_available false and exploitation requiring a low-privileged authenticated account, and describes the CVE as most plausibly a post-initial-access step rather than an internet-wide mass-exploitation event. That lowers the likelihood of an untargeted hit; it does not lower the consequence, which the vector states as takeover of Oracle Agile PLM.",
+        "evidence": "Packet fields for CVE-2024-20953: name 'Oracle Agile Product Lifecycle Management (PLM) Deserialization Vulnerability'; affected_versions 'Oracle Agile PLM 9.3.6 (Export component); fixed by the January 2024 CPU'; cisa_kev true with kev_date 2025-02-24 and framework_control_gaps naming the CISA due date 2025-03-17; active_exploitation 'confirmed'; active_exploitation_notes state the flaw was 'patched in Oracle's January 2024 Critical Patch Update and reported via Trend Micro ZDI' and that CISA added it to KEV 'roughly a year after the patch'; poc_available false; rwep_score 44; cvss 8.8 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes 'No live-patch path for this product class; remediation is the vendor update ... plus the named compensating controls until it lands.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "Agile PLM's Export component is the endpoint this control governs. The packet places a CWE-502 Java deserialization sink in the ExportServlet, reachable over HTTP, and the CVSS vector records PR:L — the attacker holds a legitimate low-privileged PLM account, so no authentication boundary is bypassed and the endpoint's willingness to reconstruct arbitrary objects out of request content is the entire defect. Bound to this product, the control means the Export endpoint must not let arriving content decide what gets instantiated, and the PLM application must not inherit its safety from the assumption that an internal supply-chain system is only reached by trusted staff — that assumption is precisely what makes a PR:L flaw get scored as low-risk and deferred. Be clear about which half of this control is not a lever here: peer authentication on the listener is already present and the attacker passes it, so requiring authentication changes nothing on this path. The load-bearing half is constraining what the endpoint deserializes, and that property is established by the January 2024 CPU — this control states what to verify, it does not implement it. Precondition on the network half: restricting which segments can reach the PLM HTTP surface bounds the population that can present a request, but the packet's stated access requirement is network access via HTTP plus a low-privileged account, so any compromised or misused PLM user credential inside a permitted segment satisfies that requirement in full. Segmentation bounds who can reach the sink; it does not close it, and it is unavailable to the extent PLM must stay reachable by its normal user population — which, for a product-lifecycle system, is most of engineering and supply-chain operations. Distinguishing test: from a low-privileged account on a staging PLM instance, submit a serialized object to the Export component and confirm it is refused before deserialization runs. A system-security attestation recorded as met by 'patches applied in a managed cycle' — the wording the packet itself records for this control — says nothing about whether the endpoint deserializes untrusted content, and passes cleanly while it does.",
+        "evidence": "Packet fields for CVE-2024-20953: cwe_refs CWE-502; vector 'Vulnerability in the Oracle Agile PLM product of Oracle Supply Chain (component: Export). The supported version that is affected is 9.3.6. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Agile PLM. Successful attacks ... can result in takeover of Oracle Agile PLM' with CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; active_exploitation_notes 'A Java deserialization RCE in the Oracle Agile PLM ExportServlet ... Because exploitation requires low-privileged authentication, it is most plausibly used as a post-initial-access step for code execution/takeover of the PLM host'; framework_control_gaps UK-CAF-B4 'CAF B4 (system security) is recorded as met by \"patches applied in a managed cycle\"'; patch_available true (January 2024 CPU per affected_versions); live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2017-3066": {
     "name": "Adobe ColdFusion Deserialization Vulnerability",
@@ -37477,7 +38124,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The fix here predates the KEV listing by years — the packet records Adobe patching in April 2017 via APSB17-14 against a KEV listing of 2025-02-24 with a 2025-03-17 due date — so the control's 'whichever is later' branch resolves to the listing, and the deliverable is per-instance version proof rather than patch acquisition. Do it per branch, because the packet gives three of them and they do not share a fixed level: ColdFusion 2016 must reach Update 4, ColdFusion 11 must reach Update 12, and ColdFusion 10 must reach Update 23. An estate that upgrades its ColdFusion 2016 instances and closes the ticket while a ColdFusion 10 or 11 instance sits below its own fixed update is still fully exposed, and this is the common shape because the older branches are the ones that fall outside managed software distribution. On completion measurement: patch_required_reboot is false, which records that no machine reboot is required — it does not mean the fix is live the moment the installer finishes. The packet puts the defect in the Apache BlazeDS library used by ColdFusion, library code the ColdFusion server process has loaded, so the instance keeps executing pre-fix code until it is running the updated build; measure completion on the update level the running ColdFusion instance reports, not on the installer having run. One further thing patch_available: true does not establish — that the branch an instance runs is still receiving fixes. The packet records a fix for this CVE at each of the three named update levels and no end-of-support status for any branch, so where an instance's branch support status is unknown, resolve it with the vendor before recording that instance as remediated; an instance sitting at a 2017-era update level on a branch that no longer receives fixes is closed against this CVE and open to everything found in it since.",
+        "evidence": "Packet fields for CVE-2017-3066: vector names Adobe ColdFusion 2016 Update 3 and earlier, ColdFusion 11 update 11 and earlier, and ColdFusion 10 Update 22 and earlier with a Java deserialization vulnerability in the Apache BlazeDS library leading to arbitrary code execution; affected_versions give the fixed levels as ColdFusion 2016 Update 4, ColdFusion 11 Update 12, and ColdFusion 10 Update 23; active_exploitation_notes record an unauthenticated Java deserialization RCE in the BlazeDS AMF handling used by Adobe ColdFusion, patched by Adobe in April 2017 (APSB17-14), with CISA adding it to KEV on 2025-02-24 (due 2025-03-17); cisa_kev true, active_exploitation confirmed, poc_available true; cvss 9.8, rwep_score 68; patch_available true, patch_required_reboot false, live_patch_available false with live_patch_notes recording no live-patch path for this product class.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The packet records this as an unauthenticated deserialization RCE in the BlazeDS AMF handling, which means the ColdFusion message endpoint deserializes attacker-supplied objects before any authentication decision is reached — the AMF path, not the ColdFusion login page or the administrator console, is the trust boundary. Applied to this deployment: enumerate which ColdFusion instances genuinely serve Flex/AMF remoting to clients and which merely have the handler present because it ships with the server. For the second group, restrict reachability of the AMF remoting path to nothing at all from untrusted networks, and do it at the network or web-tier layer rather than inheriting safety from 'ColdFusion sits behind the web server' — the packet's stated exploitation population is internet-exposed ColdFusion servers, which is the topology that assumption produces. Precondition, and this is where a reachability control is usually over-claimed: restricting who can send the AMF message bounds the population that can attempt it and repairs nothing in the deserialization. Any host inside the permitted segment retains the full pre-auth path, and on an instance whose application genuinely serves AMF remoting to client software there is no segment that removes it — for those instances only the branch's fixed update level closes anything. Treat this as a holding measure for the window before the update, not a closure, and record it that way rather than as a mitigated finding.",
+        "evidence": "Packet fields for CVE-2017-3066: vector records a Java deserialization vulnerability in the Apache BlazeDS library in Adobe ColdFusion 2016 Update 3 and earlier, ColdFusion 11 update 11 and earlier, and ColdFusion 10 Update 22 and earlier, with successful exploitation leading to arbitrary code execution; cwe_refs CWE-502; active_exploitation_notes describe it as an unauthenticated Java deserialization RCE in the Apache BlazeDS AMF handling used by Adobe ColdFusion, long a favorite of opportunistic and targeted actors against internet-exposed ColdFusion servers because it is pre-auth and has mature public tooling; poc_available true, active_exploitation confirmed, cvss 9.8; the UK-CAF-B4 gap on this entry records CAF B4 system security being treated as met by 'patches applied in a managed cycle'.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "ColdFusion is an application server rather than a firewall or VPN appliance, but this entry satisfies every condition the control keys on: a pre-authentication RCE, confirmed active exploitation, and public tooling the packet describes as mature and long-favoured against internet-exposed instances, with the observed outcome being webshell drops and server takeover. That combination is precisely the case where patch-in-place yields a compliant record and a still-owned server. Applying ColdFusion 2016 Update 4, 11 Update 12, or 10 Update 23 closes the BlazeDS deserialization path and removes nothing an attacker already wrote through it — a webshell placed in the application's web-accessible content is ordinary content to the updater and survives it untouched, and no version check will surface it. So for any instance that was reachable from untrusted networks while below its branch's fixed update level, the default is not patch-and-close: extract configuration and application content for comparison against a known-good copy, rebuild the instance at the fixed update level, and rotate every credential the ColdFusion service held or could read. The 2025-03-17 CISA due date is the clock for the update; the compromise assessment is not bounded by it and should not be closed with it. Precondition: this is the default for an instance whose exposure during the vulnerable period cannot be ruled out. Where an instance is demonstrably unreachable from untrusted networks throughout — established from network evidence, not from an assertion about where the server sits — the update alone is proportionate, and that determination should be written down rather than assumed.",
+        "evidence": "Packet fields for CVE-2017-3066: active_exploitation_notes record an unauthenticated (pre-auth) Java deserialization RCE with mature public tooling, long a favorite of opportunistic and targeted actors against internet-exposed ColdFusion servers, typically leveraged for webshell drops and server takeover of legacy ColdFusion deployments, with CISA adding it to KEV on 2025-02-24 (due 2025-03-17) reaffirming ongoing exploitation; active_exploitation confirmed and poc_available true; affected_versions name the fixed levels ColdFusion 2016 Update 4, ColdFusion 11 Update 12, and ColdFusion 10 Update 23; patch_available true with live_patch_available false and live_patch_notes recording that remediation is the vendor update plus the named compensating controls until it lands; the NIS2-Art21-vulnerability-management gap on this entry records that a documented vulnerability-handling procedure satisfies the obligation on paper.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2025-24989": {
     "name": "Microsoft Power Pages Improper Access Control Vulnerability",
@@ -37803,7 +38481,38 @@
         "adequate": false,
         "gap": "Patch cadence alone doesn't help sites still on end-of-support Joomla 3/4 branches, which needed separate back-ported fixes (3.1.1 / 3.4.10)."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry is unusually short and the packet states it: CISA added the Page Builder CK flaw to KEV on 2026-07-07 with a due date of 2026-07-10 — three days against an unauthenticated arbitrary file upload that leads to full RCE, with a public PoC and confirmed exploitation. For this product the verified mitigation is the extension update: every Joomla site running Page Builder CK 3.5.10 or earlier moves to a fixed release, and sites on end-of-support Joomla 3/4 branches take the separately back-ported fixes (3.1.1 / 3.4.10) rather than being recorded as unremediable. Completion is measured per site, on the Page Builder CK version the site is actually serving — an agency or hosting operator will have this extension installed at different versions across many Joomla sites, an inventory built from a single reference install proves nothing about the rest, and one un-updated site is unauthenticated RCE. Precondition on this control's compensating-control branch: the only interim lever available on a public website is a request-filtering rule at a reverse proxy or WAF in front of the front-end upload endpoint, and it holds only where every request reaches the site through that proxy — a site published directly, or reachable on a second hostname or on its origin IP, bypasses the rule entirely. And because exploitation is confirmed and the packet records webshells being planted on connected sites, a site that served a vulnerable version needs its web root compared against a known-good copy and its credentials rotated: updating the extension closes the upload path but does not remove a PHP file already written through it.",
+        "evidence": "Packet: cisa_kev true, 'CISA added this to KEV on 2026-07-07 (due date 2026-07-10) citing active exploitation; multiple reports describe webshells being planted on connected Joomla sites through the flaw'; active_exploitation 'confirmed'; poc_available true; cvss 9.8; affected_versions '<= 3.5.10'; vector 'The Joomla extension Page Builder CK is vulnerable to an unauthenticated arbitrary file upload that allows uploading executable files and leads to full RCE'; patch_available true, patch_required_reboot false, live_patch_available false. AU-Essential-8-Patch gap names the back-ported fixes '(3.1.1 / 3.4.10)' for end-of-support Joomla 3/4 branches; the NIS2-Art21-network-security gap records WAF/reverse-proxy rules as 'the practical compensating control while the flaw was unpatched'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "Page Builder CK is a Joomla extension whose front-end surface is wired directly to a privileged operation: the packet describes an upload endpoint that accepts a caller-chosen destination folder and file type, gated only by a publicly-readable CSRF token, so an unauthenticated attacker scrapes the token from a public page and writes an executable PHP file into a web-accessible path. That is the pattern this control forbids — a user-facing surface reaching a filesystem write the web server will subsequently execute. Read the privilege precisely for this product: what the attacker obtains is code execution in the context the web server runs Joomla as, which the packet calls full RCE; it is not a root operation, and the requirement here is the authorization boundary, not a claim about the account reached. A CSRF token is a replay defence and carries no identity, which is why the identity-and-access gap recorded on this entry cannot close the path: the attacker never holds a Joomla account, so no account model or privilege assignment is ever consulted and an access-control attestation passes cleanly while the endpoint stays open. Bound to this extension, the property to verify is that the front-end upload path makes its own authorization decision before any write occurs, and that the destination directory and the permitted file types are fixed server-side rather than taken from the request, so no caller input selects where the file lands or whether it is executable. Distinguishing test: on a staging Joomla site, take a CSRF token from a public page and post a PHP file with a chosen destination folder to the Page Builder CK front-end upload endpoint, and confirm the request is refused before anything is written. Preconditions: the vendor update establishes that boundary — this control states the property to verify, it does not implement it — and a Joomla site's front end must remain publicly reachable, so unlike a management interface there is no segment to withdraw it into. The only pre-update lever is the proxy rule blocking that endpoint, which covers only traffic traversing the proxy and does nothing about a webshell already planted.",
+        "evidence": "Packet affected field: 'Page Builder CK extension for Joomla (Joomlack) — front-end upload endpoint accepts a caller-chosen destination folder and file type, gated only by a publicly-readable CSRF token'. attack_vector: 'An unauthenticated attacker scrapes a CSRF token from a public page, then uses it to call Page Builder CK's front-end upload endpoint with an arbitrary destination folder and a PHP payload, achieving RCE without any real authentication check.' cwe_refs CWE-434. NIST-800-53-CM-7 gap: 'Least-functionality controls should prevent an unauthenticated caller from choosing an arbitrary upload destination, but the extension exposed that as normal front-end behavior.' UK-CAF-B2 gap: 'Identity and access management guidance doesn't address an endpoint whose only \"authentication\" is a publicly-readable anti-CSRF token.' NIS2-Art21-network-security gap: WAF/reverse-proxy rules 'were the practical compensating control while the flaw was unpatched, but aren't mandated for third-party CMS plugins by default.' active_exploitation 'confirmed', with webshells planted.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B2",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet names a second population that the extension update alone does not resolve: Joomla sites still on end-of-support Joomla 3 and 4 branches, which needed the separately back-ported Page Builder CK fixes (3.1.1 / 3.4.10). On those sites taking the back-port closes this CVE, but it leaves the site on a Joomla core branch that receives no further security maintenance — so it is an interim state and the terminal state is migration to a supported Joomla branch or retirement of the site. The requirement is an inventory that records, per site, the Joomla core branch alongside the Page Builder CK version: sites on supported branches run against the KEV clock (listed 2026-07-07, due 2026-07-10), and sites on end-of-support branches carry a dated migration schedule. A risk acceptance with no migration date is what this control exists to prevent — the next extension or core defect on an end-of-support branch may have no back-port at all, and this entry already demonstrates a KEV-listed unauthenticated file upload reaching full RCE on exactly that population. Scope this to what the packet establishes: the vulnerable component is the Page Builder CK extension at 3.5.10 and earlier on Joomla, so the inventory covers Joomla sites running that extension. The packet gives no mapping from this defect into other CMS platforms or other page-builder extensions, so treating every third-party plugin in the estate as an instance of this CVE manufactures migration work against software no evidence implicates. Precondition: migrating to a supported branch does not clean a site that was already exploited — the packet records confirmed exploitation with webshells planted on connected sites, so a site that served a vulnerable version must be rebuilt from a known-good copy rather than carried across, and its credentials rotated.",
+        "evidence": "AU-Essential-8-Patch gap: 'Patch cadence alone doesn't help sites still on end-of-support Joomla 3/4 branches, which needed separate back-ported fixes (3.1.1 / 3.4.10).' Packet: affected_versions '<= 3.5.10'; cisa_kev true, kev_date 2026-07-07, 'due date 2026-07-10'; active_exploitation 'confirmed' with 'multiple reports describe webshells being planted on connected Joomla sites through the flaw'; patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2026-55255": {
     "name": "Langflow Authorization Bypass Through User-Controlled Key Vulnerability",
@@ -37987,7 +38696,40 @@
         "adequate": false,
         "gap": "Adobe's patch existed before the exploitation wave, but the ~24-hour gap between WatchTowr's public technical analysis and CISA's KEV addition shows flaw-remediation timelines can't outrun a public write-up that doubles as an exploitation guide."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For ColdFusion this CVE sets the clock at disclosure, not at the next application-patch window: the packet records honeypots seeing the first in-the-wild attempt within roughly two hours of the public technical write-up on 2026-07-06, CISA listing on 2026-07-07, and a due date of 2026-07-10. The population is both release trains the packet names — every ColdFusion 2025 install at or below Update 9 and every 2023 install at or below Update 20 — driven above those update levels on that clock. Completion is measured on the update level the running ColdFusion instance reports, not on an update downloaded or approved in a management console: patch_required_reboot is false, so no host reboot is recorded, but the packet registers no live-patch path, so nothing about this fix lands on an instance that is not actually executing the newer build. For an instance that genuinely cannot take the update inside the window, the SLA's compensating-control branch is removing external reach to the RDS FILEIO endpoint — and that branch must be recorded as a time-bound holding measure, with the precondition that the instance's users do not need to reach /CFIDE/main/ide.cfm, and with no claim that it remediates an instance already exploited during the window.",
+        "evidence": "Packet: CISA KEV 2026-07-07, due 2026-07-10; active_exploitation confirmed; active_exploitation_notes record the first in-the-wild exploitation attempt within roughly two hours of the public technical write-up on 2026-07-06, using C:\\Windows\\win.ini as a canary, with Canadian and Belgian national CERT alerts. CVSS 10, RWEP 74, poc_available true. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions: 2025 <= Update 9, 2023 <= Update 20. The AU-Essential-8-Patch gap states the internet-facing patch target was outpaced by the ~24-hour gap between the public write-up and the KEV listing; the SI-2 gap states flaw-remediation timelines cannot outrun a public write-up that doubles as an exploitation guide.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "ColdFusion's Remote Development Services is exactly the application-server remoting surface this control governs: the packet places the defect in the RDS FILEIO handler at /CFIDE/main/ide.cfm, which insufficiently validates the FILE path parameter and answers an unauthenticated caller with arbitrary file read and write anywhere on the filesystem, including the webroot. For this product the requirement is that a production ColdFusion instance does not expose RDS at all — disabled in the server configuration on any deployment that does not do remote development — and that where it must stay enabled, the endpoint answers only from a development or management segment enforced by network ACL or host firewall, rather than inherited from the assumption that the app server sits behind a load balancer. Distinguishing test for this product: from an untrusted user segment and from an external address, request /CFIDE/main/ide.cfm with ACTION=FILEIO against a staging instance; anything that answers is within reach of the published path, and an instance that passes a boundary-protection review because its HTTPS listener is fronted by a proxy is still exposed if that proxy forwards this path. Precondition: this bounds who can send the request, it does not repair the FILE parameter validation — the vendor update does that — and it is unavailable where the deployment legitimately requires remote development access, which is why it is an interim measure against the KEV clock rather than a substitute for the update.",
+        "evidence": "Packet: affected states the RDS FILEIO handler at /CFIDE/main/ide.cfm insufficiently validates the FILE path parameter, allowing unauthenticated arbitrary file read/write anywhere on the filesystem including the webroot; attack_vector describes an unauthenticated crafted request to /CFIDE/main/ide.cfm?ACTION=FILEIO with a path-traversal payload in the FILE parameter. The NIST-800-53-SC-7 gap states RDS endpoints like /CFIDE/main/ide.cfm are development tooling that should be blocked at the network boundary in production, not internet-reachable; the UK-CAF-B4 gap states secure-by-default guidance should disable RDS in production ColdFusion instances, which many long-lived installs leave enabled from initial setup.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive here is an arbitrary write into the ColdFusion webroot and the packet's own attack path is dropping a .cfm webshell there for code execution, so the update closes the write path and removes nothing already written through it — a webshell placed before remediation keeps serving from an instance that now reports an update level above 2025 Update 9 / 2023 Update 20. Because exploitation began roughly two hours after the public write-up and CISA's due date was three days after listing, any instance that was internet-reachable across that window has to be assessed rather than closed on the patch record: compare the webroot and the ColdFusion installation against a known-good deployment artifact, treat any .cfm present that no sanctioned deployment produced as an implant, and treat every secret stored on that filesystem as read, since the same handler gave unauthenticated arbitrary file read anywhere on disk. Distinguishing test keyed to the behaviour the packet documents rather than to tool signatures or crashes — this exploit produces neither: search web logs for requests to /CFIDE/main/ide.cfm carrying ACTION=FILEIO with traversal sequences in the FILE parameter, and for reads of C:\\Windows\\win.ini, the canary the packet records honeypots observing, then correlate against files appearing under the webroot outside a deployment window. A flaw-remediation attestation showing every instance above the fixed update level reads clean while a pre-patch webshell is still reachable.",
+        "evidence": "Packet: attack_vector describes writing an arbitrary file (e.g. a .cfm webshell) into the webroot for RCE, or reading sensitive files as reconnaissance; affected records unauthenticated arbitrary file read/write anywhere on the filesystem including the webroot. active_exploitation confirmed, with the first attempt recorded within roughly two hours of the 2026-07-06 write-up, reading C:\\Windows\\win.ini as a canary; KEV 2026-07-07 due 2026-07-10. The NIST-800-53-SI-2 gap states Adobe's patch existed before the exploitation wave and that flaw-remediation timelines cannot outrun a public write-up that doubles as an exploitation guide — i.e. exploitation preceded remediation on exposed instances, which is the condition under which patch-in-place is not an end state.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-23209": {
     "name": "Craft CMS Code Injection Vulnerability",
@@ -38135,7 +38877,30 @@
         "adequate": false,
         "gap": "Identification/authentication control assumes session-validation logic is sound; here the SSLVPN mechanism itself failed to validate sessions correctly, bypassing IA-2's intent regardless of any MFA configuration."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "SonicOS SSLVPN is the authentication enforcement point for remote access, and this CVE is that enforcement point failing open: a crafted session cookie makes the gateway resolve an unauthenticated request onto an already-authenticated user's live VPN session, putting the attacker inside on someone else's session. The clock cannot start at the KEV listing, because the packet's own sequence puts exploitation ahead of it — Bishop Fox published a PoC on 2025-02-10, exploitation followed within days, and CISA listed the CVE on 2025-02-18, so the listing is confirmation rather than warning, and the packet records roughly 4,500 internet-facing instances still unpatched a week after the PoC. Scope from the affected fields, not from the headline: the population is Gen7 firewalls, Gen7 NSv and TZ80 units with SSL VPN enabled and internet-facing, across three separate build lines — SonicOS 7.1.x (7.1.1-7058 and earlier), 7.1.2-7019, and 8.0.0-8035 — so a sweep run only against the 7.1 branch reports clean across an estate standardised on 8.0.0-8035, and each unit must be shown at or above the vendor's fixed build for its own line. patch_required_reboot is true and live_patch_available is false, so a unit that has taken the firmware but has not rebooted is still executing the vulnerable session-validation code and must be counted as exposed. On a remote-access gateway that reboot is the step most likely to be deferred, because taking it drops every active VPN session — a deferral recorded as patched is the specific way this remediation goes wrong, so completion is measured on the firmware the unit is running, not on the upload. Interim exposure is bounded by the packet's own scoping condition, that the flaw affects these units when SSL VPN is enabled and internet-facing: enumerate which units have that listener enabled and reachable, and restrict or suspend it until the reboot completes. Precondition on that interim measure — it is available only where the remote-access population is address-bounded or where remote access can be taken out of service; a general remote-workforce portal cannot be source-restricted without denying the workforce, and neither restriction helps a unit whose sessions were hijacked before the restriction went on. Because the packet records confirmed ransomware use and initial access to internal network resources, a gateway that was internet-facing with SSL VPN enabled during that window belongs on the incident path: the intrusion this exploit enables lives behind the firewall, not on it, so a rebooted, patched gateway is not evidence that the network behind it is clean.",
+        "evidence": "Packet fields for CVE-2024-53704: name 'SonicWall SonicOS SSLVPN Improper Authentication Vulnerability'; affected 'SonicOS SSLVPN authentication/session-management mechanism on Gen7 firewalls, Gen7 NSv, and TZ80, when SSL VPN is enabled and internet-facing'; affected_versions 'SonicOS 7.1.x (7.1.1-7058 and earlier)', 'SonicOS 7.1.2-7019', 'SonicOS 8.0.0-8035'; attack_vector 'A remote, unauthenticated attacker sends a crafted session cookie to the SonicOS SSLVPN authentication endpoint, exploiting improper session validation to hijack an already-authenticated user's active VPN session and reach internal network resources'; active_exploitation_notes 'Actively exploited in the wild within days of Bishop Fox publishing a public PoC (Feb 10, 2025); CISA KEV flags confirmed ransomware use — responders observed exploitation tied to intrusions that hijacked active SSL VPN sessions for initial access'; kev_date 2025-02-18; framework_control_gaps AU-Essential-8-Patch 'roughly 4,500 internet-facing instances remained unpatched a week after the public PoC'; cvss 9.8; rwep_score 80; poc_available true; patch_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "The SonicWall gateway is itself the security product, and this CVE is the case the control's trust-anchor-inversion test exists for. The packet places the failure inside the SSLVPN authentication mechanism: improper session validation resolves an attacker-supplied session cookie onto an active session, which is exactly why the identification-and-authentication gap on this entry says the control's intent is bypassed regardless of any MFA configuration. No factor is ever challenged because no authentication event occurs at all — the attacker inherits a session that was authenticated by someone else. That makes the estate's identity evidence, however strong, evidence about a path this exploit does not take, and it means the missing obligation is a test aimed at the product rather than at the account model: deliver a crafted session cookie to a staging gateway's SSLVPN endpoint and confirm it is rejected rather than resolved onto an existing session. The same reclassification governs how the appliance is managed day to day — its firmware belongs in vulnerability management under the same SLA as any other privileged software, and its advisories belong in threat intake, because a device bought as a defense is routinely excluded from both and is inventoried as infrastructure rather than as attack surface. Note also what an exploit doing exactly what the packet describes will not emit: no credential is guessed and no factor is presented, so authentication logs and MFA telemetry carry no record of the event; the observable is an active SSL VPN session being used from a source address that never authenticated it, which is only visible where per-session activity, not just authentication events, is collected off the appliance. Precondition: this control produces a testing obligation and evidence about the product's behaviour — it does not repair the session-validation logic, which only the vendor firmware and its reboot do, and a clean result on a staging unit says nothing about whether a production gateway's sessions were hijacked during the exposure window.",
+        "evidence": "Packet fields for CVE-2024-53704: cwe_refs CWE-287; vector 'An Improper Authentication vulnerability in the SSLVPN authentication mechanism allows a remote attacker to bypass authentication'; attack_vector 'sends a crafted session cookie to the SonicOS SSLVPN authentication endpoint, exploiting improper session validation to hijack an already-authenticated user's active VPN session'; framework_control_gaps / framework_coverage NIST-800-53-IA-2 'Identification/authentication control assumes session-validation logic is sound; here the SSLVPN mechanism itself failed to validate sessions correctly, bypassing IA-2's intent regardless of any MFA configuration'; active_exploitation 'confirmed' with KEV-flagged ransomware use; poc_available true (Bishop Fox, Feb 10 2025); patch_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-IA-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-57727": {
     "name": "SimpleHelp Path Traversal Vulnerability",
@@ -38172,7 +38937,38 @@
         "adequate": false,
         "gap": "Access enforcement assumed authentication was required before file retrieval; the traversal bug let the toolbox handler serve files outside any access-control check."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the control means every SimpleHelp server is moved past 5.5.7 on the clock that opened with the 2025-02-13 KEV listing, and it has two SimpleHelp-specific requirements that a generic patch SLA does not produce. First, the clock cannot be driven by advisory-feed ingestion: the packet records that the vendor's fix was published as release notes rather than a CVE-tagged bulletin, so a vulnerability-management pipeline that waits for a CVE-tagged vendor advisory to raise a ticket never starts counting on this one — the trigger has to be the KEV listing itself plus the vendor's release notes watched as a patch source in their own right. Second, the inventory has to extend past self-operated servers. The packet's own gaps record third-party remote-support and RMM tooling as routinely outside an operator's vulnerability program while being a direct pivot into customer networks, so an estate that enumerates only the SimpleHelp servers it runs itself reports clean while a managed-service provider's unpatched server holds the path into the same network. Scope stays where the packet puts it: the SimpleHelp server component at 5.5.7 and earlier — the packet gives no mapping into other remote-support products, so this is not licence to sweep every RMM tool in the estate as an instance of this CVE. patch_required_reboot is false, which records no machine reboot, and live_patch_available is false; completion is therefore measured on the version the running SimpleHelp server reports, not on a build being staged on the host. The urgency is set by the packet rather than the 7.5 CVSS: a public proof-of-concept, confirmed exploitation from January 2025, and a KEV entry flagged for confirmed ransomware use.",
+        "evidence": "affected_versions: 'SimpleHelp <= 5.5.7'; patch_available true; patch_required_reboot false; live_patch_available false. CISA KEV listing 2025-02-13; active_exploitation 'confirmed'; poc_available true; CVSS 7.5; RWEP 70. The packet's NIS2-Art21-vulnerability-management gap: 'Third-party RMM software supply-chain risk (MSP and utility exposure) isn't covered by an operator's own patch cadence when the vendor's fix was published as release notes rather than a CVE-tagged bulletin.' The AU-Essential-8-Patch gap: 'Extreme-risk patch timeframe (48h) was not met broadly — thousands of internet-facing SimpleHelp instances remained unpatched into the DragonForce ransomware campaign.' The ISO-27001-2022-A.8.8 gap records third-party RMM/remote-support tooling as 'frequently out of scope for an operator's own vulnerability program, even though it's a direct pivot point into customer networks.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "A SimpleHelp server is the remote-management plane for every machine its technicians reach, and the packet puts the defect on one of its resource handlers by name: respondToolboxResource serves files selected by a crafted HTTP request, and the traversal walks the selection out of the intended root. Bound to this product the control means that handler authorizes its caller before it resolves anything at all, and resolves the requested path to a canonical absolute form and verifies the result still sits under the intended resource root before the file is opened — a check on the resolved path rather than a filter applied to the request string, and applied to the read direction, since the unauthorized operation here is a download rather than an upload. The access-enforcement control cited as insufficient on this entry cannot reach this path for a structural reason worth stating: the attacker never authenticates, so no access-control decision is ever consulted, and an attestation that every SimpleHelp technician account is authenticated and scoped passes cleanly while the handler hands configuration files to anonymous callers. Distinguishing test: from an unauthenticated client, request paths carrying traversal sequences against each resource handler on a staging SimpleHelp server and confirm each is refused before any file handle is opened. Precondition: the containment check is a property the vendor build above 5.5.7 establishes — this control states what to verify, it does not implement it. Restricting which networks can reach the server bounds who can send the request, but SimpleHelp exists to be reachable by remote technicians and remote client machines, so on any instance serving that purpose there is no segment that removes the path; network restriction is a real lever only for instances whose reachable population can genuinely be narrowed, and it is not available as the answer for an internet-facing support server.",
+        "evidence": "affected: 'SimpleHelp remote support/RMM software server component, toolbox resource handler (respondToolboxResource), versions 5.5.7 and earlier.' vector: 'SimpleHelp remote support software v5.5.7 and before is vulnerable to multiple path traversal vulnerabilities that enable unauthenticated remote attackers to download arbitrary files from the SimpleHelp host via crafted HTTP requests.' The packet's NIST-800-53-AC-3 gap: 'Access enforcement assumed authentication was required before file retrieval; the traversal bug let the toolbox handler serve files outside any access-control check.' patch_available is true.",
+        "gap_closes": [
+          "NIST-800-53-AC-3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "What this traversal returned is why the upgrade alone does not end the incident: the packet states the downloadable files include server configuration files containing various secrets and hashed user passwords, and that DragonForce affiliates used the flaw as an initial-access vector against unpatched servers from January 2025. Moving a server past 5.5.7 closes the read path and invalidates nothing already read. Bound to this product the requirement is that any SimpleHelp server which was reachable by untrusted callers while running 5.5.7 or earlier is handled as a configuration-exfiltration event rather than a patching item: rotate every secret the server's configuration held and every credential it stored, and treat the technician accounts and the downstream machines that server could reach as in scope, because that reach into customer networks is exactly what the ransomware affiliates were acquiring. Scope note, stated rather than glossed: this control is written around pre-authentication remote code execution on a boundary system, and the primitive the packet records here is an unauthenticated read, not execution — so the rebuild half applies to hosts where follow-on access or execution is evidenced, while the configuration-exfiltration-and-rotation half is what the packet documents directly and applies to every exposed instance. Precondition: rotation is only complete if it covers material that is not obviously credential-shaped, because the packet says 'various secrets' rather than naming them, so anything the server used to authenticate outward is in scope; and hashed passwords remain usable for offline cracking and for replay wherever those accounts reused them, so rotation has to follow those accounts onto their other systems rather than stopping at SimpleHelp's own login.",
+        "evidence": "vector: 'These files include server configuration files containing various secrets and hashed user passwords.' active_exploitation_notes: 'Actively exploited since January 2025 by ransomware affiliates (DragonForce) as an initial-access vector against unpatched SimpleHelp servers, most notably a utility billing software provider per CISA advisory AA25-163A; CISA KEV flags confirmed ransomware use.' The packet's UK-CAF-B2 gap: 'Identity and access management control assumes credentials in config files stay secret; path traversal defeats that assumption entirely regardless of IAM posture.' patch_available true with affected_versions 'SimpleHelp <= 5.5.7'.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2025-24200": {
     "name": "Apple iOS and iPadOS Incorrect Authorization Vulnerability",
@@ -38509,7 +39305,30 @@
         "adequate": false,
         "gap": "The emergency patches (15.8.9 / 23.10, released Jan 28-29 2025) landed only after in-the-wild zero-day exploitation was already underway, showing standard patch-SLA timelines don't cover a pre-disclosure exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "Cityworks reaches its deserialization sink over an ordinary authenticated application request to the IIS site, so only one half of this control is a lever here and the other half must not be claimed. The bind-the-listener-and-authenticate-the-peer half gives nothing: the packet's exploitation precondition is a low-privileged authenticated Cityworks session, which every legitimate field and office user already holds, and the deployments the packet describes as exploited are internet-facing by design for local-government and utility users — there is no network position to remove that does not also remove the product's function. The load-bearing half is constraining what arriving content the service is permitted to construct or evaluate: the Cityworks request path must not inherit safety from the fact that the caller authenticated, and the deserializer must be bound to an explicit set of expected types rather than reconstructing whatever object graph the submitted payload names. That is exactly why the least-privilege control cited against this entry passes its attestation while the flaw stays fully exploitable — the attacker is a legitimate low-privileged account behaving like one, so per-account privilege scoping is never the thing that fails and no access decision is ever wrong. Precondition: this states the property the vendor build must hold, it does not implement it. Cityworks 15.8.9 and Cityworks with Office Companion 23.10 are what establish it, and until a deployment is on those builds nothing on the operator side constrains the sink, because the request that reaches it is indistinguishable from a legitimate authenticated one. Measure completion per component on the version the running IIS deployment actually serves: the packet gives Office Companion its own fixed build, so a site that took the Cityworks update alone is not remediated.",
+        "evidence": "Packet vector: 'Trimble Cityworks versions prior to 15.8.9 and Cityworks with office companion versions prior to 23.10 are vulnerable to a deserialization vulnerability. This could allow an authenticated user to perform a remote code execution attack against a customer's Microsoft Internet Information Services (IIS) web server.' cwe_refs CWE-502. affected: 'Trimble Cityworks GIS-centric asset-management software deployed on Microsoft IIS, including the Cityworks with Office Companion add-on, vulnerable to a .NET deserialization flaw reachable by an authenticated user.' affected_versions: 'Cityworks < 15.8.9', 'Cityworks with Office Companion < 23.10'. The NIST-800-53-AC-6 gap states exploitation only requires a low-privileged authenticated session (PR:L), so the deserialization surface itself needs to be constrained regardless of the caller's privilege level; the ISO-27001-2022-A.8.28 gap states the root cause is unsafe deserialization and that account-level trust in a low-privileged authenticated user cannot compensate. active_exploitation confirmed against internet-facing Cityworks/IIS deployments at local-government and utility operators; patch_available true, live_patch_available false, live_patch_notes null, patch_required_reboot false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.28",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet dates exploitation of Cityworks to around January 2025, the emergency builds 15.8.9 and Office Companion 23.10 to 28-29 January 2025, and the KEV listing to 2025-02-07. For this CVE the control's 'whichever is later' clause does real work: patch availability was the trigger that had already passed, and the interval between the vendor's emergency release and a site's next scheduled application-update window is the whole of the operator-controllable exposure. Concretely for a Cityworks estate that means the emergency build is driven out on an incident clock rather than folded into the normal application-update cycle, with each site's remediation recorded as the version its running IIS deployment serves and both components tracked separately, since Office Companion carries its own build number. The sector profile the packet records — water and wastewater, energy, transportation — is why the clock has to be the incident one rather than the cadence one, since these are the operators for whom a documented vulnerability-handling procedure is what currently satisfies the obligation. Precondition, stated because this is where a KEV SLA is routinely over-claimed: the control bounds the post-release window only. The packet records this as a zero-day exploited before the vendor build existed, so no SLA reaches the period in which the documented victims were actually compromised. And because the packet records custom Rust-based loaders staging VShell and Cobalt Strike in memory on the IIS host, an installation upgraded to 15.8.9 without triage carries whatever was staged on it into the fixed build — reaching the fixed version closes the sink, not the intrusion.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-02-07, active_exploitation confirmed, cvss 8.8, rwep_score 50, poc_available false, patch_available true, live_patch_available false, live_patch_notes null. The NIST-800-53-SI-2 gap states: 'The emergency patches (15.8.9 / 23.10, released Jan 28-29 2025) landed only after in-the-wild zero-day exploitation was already underway, showing standard patch-SLA timelines don't cover a pre-disclosure exploitation window.' active_exploitation_notes: 'Actively exploited as a zero-day beginning around January 2025 against internet-facing Cityworks/IIS deployments at local-government and utility operators; Trimble-shared IOCs indicate attackers deployed custom Rust-based loaders to stage the VShell and Cobalt Strike post-exploitation frameworks in memory... the affected sectors span water/wastewater, energy, and transportation.' The AU-Essential-8-Patch gap states the 48-hour guidance could not be met because the vendor's own emergency patch trailed the observed zero-day exploitation start date; the NIS2-Art21-vulnerability-handling gap states critical-infrastructure operators running Cityworks had no coordinated emergency-patch SLA matching that timeline.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2025-0411": {
     "name": "7-Zip Mark of the Web Bypass Vulnerability",
@@ -39246,7 +40065,40 @@
         "adequate": false,
         "gap": "Patch was released only after MSTIC flagged in-the-wild zero-day exploitation; a standard flaw-remediation SLA does not cover a pre-auth appliance flaw already being exploited before the fix shipped."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The SMA1000 is a remote-access appliance and its AMC/CMC management console is the surface this tier exists for: the packet's boundary-protection gap records that the console is intentionally internet-reachable for remote administration, so a request carrying a serialized object reaches a pre-authentication code path by design. Bound to this product, the tier means an SMA1000 defect of this class runs on a clock measured from the 2025-01-24 KEV listing rather than on the appliance-maintenance window — and the clock does not stop at 'hotfix downloaded'. The packet records live_patch_available as false and patch_required_reboot as true, so a unit that has taken the January 22, 2025 hotfix but has not been restarted is still executing the vulnerable code and is not remediated. Scope by the affected ceiling the packet gives — 12.4.3-02804 (platform-hotfix) and earlier — across every SMA1000 series unit, AMC and CMC alike, and take the exact fixed build from the vendor's advisory for that hotfix rather than assuming a later-looking version carries it. Precondition, and this is where the tier is most often over-claimed: its alternative of isolating the vulnerable interface is not available on a unit whose AMC/CMC must stay reachable for remote administration. For those units, restricting source networks bounds who can send the object but leaves the path fully exploitable from every permitted source; only the restart-completed hotfix closes it. Distinguishing test: for each SMA1000, compare the build the console reports after its last restart against the fixed build, not the build recorded in the change ticket.",
+        "evidence": "Packet: pre-authentication deserialization of untrusted data (CWE-502) in the SMA1000 AMC and CMC enabling a remote unauthenticated attacker to execute arbitrary OS commands; CVSS 9.8, RWEP 81, poc_available true, active_exploitation confirmed, CISA KEV 2025-01-24. Microsoft Threat Intelligence Center notified SonicWall of possible active exploitation as a zero-day before the January 22, 2025 hotfix; CISA added it to KEV two days later flagging known ransomware use. patch_available true, patch_required_reboot true, live_patch_available false. affected_versions: '12.4.3-02804 (platform-hotfix) and earlier'. The NIST-800-53-SC-7 gap states the AMC/CMC is intentionally internet-reachable for remote administration.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This entry is the case the runbook exists for. The packet records the flaw as exploited in the wild before a fix existed — Microsoft Threat Intelligence Center notified SonicWall of possible active exploitation ahead of the January 22, 2025 hotfix — so every SMA1000 whose AMC/CMC was reachable during that window has to be dispositioned as possibly-already-executed, not merely as unpatched. Applying the hotfix and restarting closes the deserialization path; it does not undo OS commands that already ran, and the packet records that threat actors later chained this with CVE-2025-40602 to obtain full root-level RCE, so on a unit that was reached the attacker's privilege is not bounded by what the management console normally holds. Default the disposition to capturing the configuration for analysis, rebuilding from vendor media onto the fixed build, and rotating the administrator credentials and every secret the appliance held or brokered — rather than restoring the pre-incident configuration wholesale, which carries any attacker-added account or setting straight onto the rebuilt unit. Precondition: this is scoped to units whose AMC/CMC was reachable from an untrusted network during the exposure window, and it does not identify which units were actually reached — the packet documents no indicator for that. Treat it as the default disposition to be argued down with evidence, not a finding raised only after evidence appears; CISA's KEV entry flags known ransomware use, which is precisely the outcome a patch-only disposition would leave in place.",
+        "evidence": "Packet active_exploitation_notes: 'Microsoft Threat Intelligence Center notified SonicWall of possible active exploitation of this pre-auth deserialization flaw as a zero-day before the January 22, 2025 hotfix; CISA added it to KEV two days later flagging known ransomware use. Threat actors later chained it with CVE-2025-40602 to obtain full root-level RCE on SMA1000 appliances.' The NIST-800-53-SI-2 gap records that the patch was released only after MSTIC flagged in-the-wild zero-day exploitation. active_exploitation confirmed; poc_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The AMC and the CMC are the device-management consoles this control governs, and the packet places the defect exactly where the control binds: the console accepts an untrusted serialized object and acts on it before any authentication decision is made, so an unauthenticated caller's input reaches a deserialization sink that ends in arbitrary OS command execution. Bound to this product the requirement is twofold — every AMC and CMC request path authorizes its caller before the request body is parsed at all, and the console does not reconstruct arbitrary object types from request-supplied data, so a crafted object cannot select what gets executed. This is also why the identity and least-privilege controls an audit examines never engage: the attacker holds no SMA1000 operator account, so per-account scoping is never consulted and an access-control attestation passes cleanly while the path stays open. Distinguishing test: on a staging SMA1000, send the AMC and the CMC an unauthenticated request carrying a serialized object of a type the console never legitimately receives, and confirm it is rejected before any deserialization runs. Precondition, stated plainly: the endpoint-side authorization and the deserialization restriction are properties of the vendor's fixed build — this control states what to verify, it does not implement it. Until the hotfix and its reboot land, restricting which networks may reach the AMC/CMC bounds who can send the object but leaves the sink fully reachable from every permitted source, and that bound is unavailable where the console must stay internet-reachable for remote administration, which the packet records as the deployed posture.",
+        "evidence": "Packet vector: 'Pre-authentication deserialization of untrusted data vulnerability has been identified in the SMA1000 Appliance Management Console (AMC) and Central Management Console (CMC), which in specific conditions could potentially enable a remote unauthenticated attacker to execute arbitrary OS commands' (CWE-502, CVSS 9.8). The ISO-27001-2022-A.8.28 gap records this as 'an unsafe-deserialization sink on a pre-auth remote-access console' whose deserialization-hygiene expectations 'were never met in the shipped product'. The NIST-800-53-SC-7 gap records that the AMC/CMC is intentionally internet-reachable for remote administration, so boundary protection alone cannot stop the request reaching the vulnerable endpoint. patch_available true; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.28",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2020-11023": {
     "name": "JQuery Cross-Site Scripting (XSS) Vulnerability",
@@ -39380,7 +40232,32 @@
         "adequate": false,
         "gap": "Microsoft confirmed active exploitation at time of disclosure, meaning routine patch-cycle SLAs did not cover the exposure window for this Hyper-V component."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Hyper-V NT Kernel Integration Virtual Service Provider — the host-side component that manages VM-to-host communication — and describes a local low-privilege attacker, on the host or by way of a guest VM, triggering a use-after-free (CWE-416) that causes the kernel to operate on freed memory and lands as SYSTEM. For this CVE the control means the January 2025 cumulative update carrying the fix is driven across every Windows Server and Windows client system with the Hyper-V role enabled on the clock that opened with the 2025-01-14 KEV listing, rather than folded into the next virtualization maintenance window, with completion measured by each host's running build against the fixed build for its SKU. The packet does not carry per-SKU build numbers — it points at the MSRC advisory for them — so the target build has to be read off that advisory per SKU rather than inferred from any build that merely looks newer. patch_required_reboot is true and live_patch_available is false, so a host that installed the update and has not rebooted is still executing the vulnerable kernel; on a virtualization host that reboot means draining or restarting the guests the host is running, which is exactly the step a change process defers, and a deferral recorded as patched is the specific way this remediation goes wrong. The second half of the control is the load-bearing one here: the attacker the packet describes is already a legitimate low-privilege local principal, so tightening account privilege does not contain the escalation — which is why the least-privilege gap recorded on this entry can pass its attestation while the flaw stays fully exploitable. Priority follows the packet rather than the 7.8 CVSS band: Microsoft confirmed exploitation in the wild at the time of disclosure, and the packet records the flaw being used as the local privilege-escalation step to reach SYSTEM after initial host or guest access, which makes it the containment step in a chain rather than a standalone endpoint item. Note also that poc_available is false — there is no public exploit to test an estate against, so the population to enumerate is every Hyper-V-enabled host, not the subset someone can demonstrate against.",
+        "evidence": "Packet: name 'Microsoft Windows Hyper-V NT Kernel Integration VSP Use-After-Free Vulnerability (CVE-2025-21335)'; CWE-416; attack_vector 'A local low-privilege attacker (on the host or via a guest VM) triggers a use-after-free in the Hyper-V NT Kernel Integration VSP component, causing the kernel to operate on freed memory and allowing escalation to SYSTEM'; affected 'Windows Server and Windows client systems running the Hyper-V role, specifically the NT Kernel Integration Virtual Service Provider (VSP) component that manages VM-to-host communication'; affected_versions 'Windows Server and Windows client builds with the Hyper-V role enabled, prior to the January 2025 cumulative update (see MSRC advisory for exact per-SKU build numbers)'; cisa_kev true with kev_date 2025-01-14; active_exploitation 'confirmed'; active_exploitation_notes 'Microsoft confirmed exploitation in the wild at time of disclosure. Used as a local privilege-escalation step to reach SYSTEM after initial host or guest access. Not flagged for ransomware.'; CVSS 7.8; RWEP 54; poc_available false; patch_available true; patch_required_reboot true; live_patch_available false. NIST-800-53-AC-6 gap: 'Least-privilege controls on host/guest processes do not stop a use-after-free that grants a low-privilege local process a path directly to SYSTEM.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-068",
+        "name": "HYPERVISOR-VM-ESCAPE-TENANCY-ASSUMPTION",
+        "description": "The packet states that the trigger can come from inside a guest — a local low-privilege attacker on the host or via a guest VM — against the very component that manages VM-to-host communication, so for this flaw the guest boundary is not a boundary. Applied to this CVE, the control means every Windows Server and Windows client host with the Hyper-V role enabled is treated as adversary-facing from its own guests regardless of who owns those guests: not only multi-tenant hosts, but internal workload hosts and developer test hosts, because the packet's precondition is low-privilege local access rather than a hostile tenant. Two things follow. The host's remediation priority is set by the flaw's KEV status and confirmed exploitation rather than by how trusted the workloads on it are, and a guest administrator is not accepted as a principal below the host — a machine whose guests are 'internal' satisfies the packet's stated precondition just as fully as one whose guests are customers. The packet also records this as one of three Hyper-V NT Kernel Integration VSP memory-corruption elevation-of-privilege flaws fixed in the same January 2025 Patch Tuesday, alongside CVE-2025-21333 and CVE-2025-21334, so the assumption being corrected is about the component's trust position rather than about one bug. Precondition, stated because this control governs prioritization and trust assumptions and not the code path: it does not remove the surface. The VSP exists to service VM-to-host communication, so a host running the Hyper-V role cannot withdraw the interface, and restricting who holds an interactive low-privilege session on the host or inside its guests bounds the population that can attempt the escalation without closing it for anyone who legitimately has one. Closure is the January 2025 cumulative update and the reboot it requires — live_patch_available is false and patch_required_reboot is true — so a host that cannot absorb that reboot immediately is on an interim clock, not remediated, and must be recorded that way.",
+        "evidence": "Packet: attack_vector 'A local low-privilege attacker (on the host or via a guest VM) triggers a use-after-free in the Hyper-V NT Kernel Integration VSP component'; affected names the 'NT Kernel Integration Virtual Service Provider (VSP) component that manages VM-to-host communication'; cisa_kev true, kev_date 2025-01-14; active_exploitation 'confirmed'; active_exploitation_notes 'One of three Windows Hyper-V NT Kernel Integration VSP memory-corruption elevation-of-privilege flaws (alongside CVE-2025-21333 and CVE-2025-21334) patched in Microsoft's January 2025 Patch Tuesday'; patch_available true; patch_required_reboot true; live_patch_available false. UK-CAF-B4 gap: 'Secure configuration baselines for virtualization hosts do not mitigate a kernel use-after-free in the VSP component itself.' AU-Essential-8-Patch gap: 'Patch Applications/OS guidance is tested by a confirmed-exploited kernel flaw requiring emergency out-of-cycle patching of virtualization hosts.'",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-21334": {
     "name": "Microsoft Windows Hyper-V NT Kernel Integration VSP Use-After-Free Vulnerability (CVE-2025-21334)",
@@ -39417,7 +40294,32 @@
         "adequate": false,
         "gap": "Microsoft confirmed active exploitation at time of disclosure, meaning routine patch-cycle SLAs did not cover the exposure window for this Hyper-V component."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "Scope from the affected fields, which name both halves of the estate: Windows Server and Windows client systems running the Hyper-V role, at builds prior to the January 2025 cumulative update. The client half is where this sweep normally comes back falsely clean — a Hyper-V VSP defect reads as a datacentre problem, so an estate that enumerates only its Windows Server hosts leaves every Hyper-V-enabled workstation on pre-fix code. Drive the January 2025 cumulative update across that population on the clock that opened with the 2025-01-14 KEV listing rather than folding it into the next quarterly virtualization window, since Microsoft confirmed exploitation in the wild at the time of disclosure. Measure completion per host against its own SKU's fixed build from the MSRC advisory, not by 'approved' or 'downloaded' in the management console: patch_required_reboot is true and live_patch_available is false, so a host that installed the update and has not rebooted still runs the vulnerable NT Kernel Integration VSP. On a virtualization host that reboot is the single most-deferred step in the whole remediation, because taking it means draining, migrating, or stopping every guest the host carries — a host recorded as patched while its reboot waits for a maintenance window is the specific way this one goes wrong, so the evidence of completion has to be the running build. The second half of this control is the load-bearing half here: the packet's attacker is a low-privilege local principal on the host or inside a guest, already legitimately authenticated, so tightening account privilege does not contain the escalation — which is exactly why the least-privilege gap recorded on this entry can pass its attestation while the flaw stays fully exploitable.",
+        "evidence": "Packet fields for CVE-2025-21334: name and vector record the Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability, CWE-416; affected names Windows Server and Windows client systems running the Hyper-V role, specifically the NT Kernel Integration Virtual Service Provider component that manages VM-to-host communication; affected_versions names Windows Server and Windows client builds with the Hyper-V role enabled prior to the January 2025 cumulative update, with exact per-SKU build numbers in the MSRC advisory; attack_vector describes a local low-privilege attacker on the host or via a guest VM triggering the use-after-free and escalating to SYSTEM; cisa_kev true with kev_date 2025-01-14, active_exploitation confirmed, and active_exploitation_notes recording that Microsoft confirmed exploitation in the wild at time of disclosure; cvss 7.8, rwep_score 54, poc_available false; patch_available true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-068",
+        "name": "HYPERVISOR-VM-ESCAPE-TENANCY-ASSUMPTION",
+        "description": "The packet places the defect in the component that manages VM-to-host communication and places the attacker on either side of it — on the host or via a guest VM — so the boundary the deployment is designed around is the thing that fails. For the exposure window that means the population who can attempt this is not the host administrator list: it is the union of every local principal who can execute code inside any guest on that host. Single-tenant estates need this stated most, because 'every VM here is ours' is where the assumption goes unexamined; the packet describes this flaw being used as a local privilege-escalation step after initial host or guest access, so any initial-access event inside any guest during the window puts that guest's attacker one step from host SYSTEM. Concrete action while hosts wait for their reboot: shrink that population rather than assume it. Move guests running untrusted or lower-assurance workloads — internet-facing services, developer and lab VMs, anything with interactive non-administrative users — onto hosts that have already completed the update and reboot, and hold new workloads of that kind off unremediated hosts. Treat the KEV-listed hypervisor defect on a 24-hour class clock regardless of tenancy. Precondition, and it is the whole caveat: this is a threat-model and prioritization control and it repairs nothing in the VSP. The packet records a vendor patch with no live-patch path, so each host still has to reach the fixed build and reboot; relocating guests bounds who can attempt the escalation and does nothing for any principal still running on an unremediated host. Where a host's guests cannot be relocated, the exposure stands until the reboot and should be recorded as such, not as mitigated.",
+        "evidence": "Packet fields for CVE-2025-21334: affected identifies the NT Kernel Integration Virtual Service Provider component that manages VM-to-host communication on Windows Server and Windows client systems running the Hyper-V role; attack_vector states a local low-privilege attacker on the host or via a guest VM triggers the use-after-free, causing the kernel to operate on freed memory and allowing escalation to SYSTEM; active_exploitation_notes record Microsoft-confirmed exploitation in the wild at disclosure, use as a local privilege-escalation step to reach SYSTEM after initial host or guest access, and that it is not flagged for ransomware; cisa_kev true, kev_date 2025-01-14; the NIST-800-53-AC-6 gap on this entry records that least-privilege controls on host/guest processes do not stop a use-after-free granting a low-privilege local process a path directly to SYSTEM, and the UK-CAF-B4 gap records that secure configuration baselines for virtualization hosts do not mitigate a kernel use-after-free in the VSP component itself; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-21333": {
     "name": "Microsoft Windows Hyper-V NT Kernel Integration VSP Heap-based Buffer Overflow Vulnerability",
@@ -39706,7 +40608,30 @@
         "adequate": false,
         "gap": "EU operators of MiCollab UC platforms need to treat chained low/critical CVE pairs as a single high-severity remediation item, not two independent low-priority tickets."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Every prioritization mechanism the citing gaps name would put this Mitel MiCollab fix near the bottom of the queue: cvss is 2.7, the packet's own vector caps the impact at reading non-sensitive system information with no modification and no privilege escalation, and the appliance is a telephony box rather than a tracked application server. The packet also records rwep_score 60, a CISA KEV listing on 2025-01-07 with a ransomware association, and live exploitation chained with CVE-2024-41713 against internet-facing MiCollab servers around the December 2024 disclosure window. Applied here, the control means the KEV listing sets the clock and the CVSS band does not enter the decision — the MiCollab update is driven across every instance from the 2025-01-07 listing, and the queue position is not recomputed downward when someone notices the score. The population to enumerate is every MiCollab server, with the internet-reachable ones first, because that is the population the packet says was actually exploited. The remediation target has to be resolved per install rather than by range arithmetic: the packet gives affected as 'through 9.8 SP2' and full mitigation as '9.8.2.12 / 9.8 SP2 and later', so the build the appliance reports must be checked against the vendor advisory for that exact release. patch_required_reboot is false, so the packet records no host reboot — but live_patch_available is false, so nothing fixes a running MiCollab instance short of taking it through the update, and completion is measured on the build the appliance reports afterwards rather than on the maintenance record. Treat this as one remediation item with its chain partner rather than as an isolated low-severity ticket; the packet describes the two being used together, and closing only the higher-scoring half leaves the chain's other step in place.",
+        "evidence": "Packet: name 'Mitel MiCollab Path Traversal Vulnerability (CVE-2024-55550)'; cisa_kev true, kev_date 2025-01-07, active_exploitation 'confirmed'; cvss 2.7 against rwep_score 60; poc_available true; active_exploitation_notes 'Chained with CVE-2024-41713 in live exploitation against internet-facing MiCollab servers around the December 2024 disclosure window. CISA KEV flags a ransomware association for this entry.'; affected_versions 'Mitel MiCollab through 9.8 SP2 (fully mitigated only in 9.8.2.12 / 9.8 SP2 and later)'; patch_available true, patch_required_reboot false, live_patch_available false; AU-Essential-8-Patch gap 'Patch prioritization by CVSS score alone would deprioritize this fix relative to its actual exploitation risk when chained'; NIS2-Art21-vulnerability-management gap 'EU operators of MiCollab UC platforms need to treat chained low/critical CVE pairs as a single high-severity remediation item, not two independent low-priority tickets.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this entry the paper-compliance failure happens twice, and the packet supplies both. First, coverage: the technical-vulnerability inventory classifies the MiCollab UC appliance as a low-risk telephony box, so it is not in the scanned estate at all — and a vulnerability report containing no MiCollab row reads identically to one showing MiCollab clean. The operational test is to confirm the appliance appears as a scanned asset with a reported build, before any conclusion is drawn from the absence of a finding; on a telephony platform this usually means the scan has to reach the admin console rather than only the SIP and media services that a network sweep discovers. Second, version resolution: the packet's own strings place the same release on both sides — affected 'through 9.8 SP2', fully mitigated in '9.8.2.12 / 9.8 SP2 and later' — so a check that compares a reported version against 'SP2' can return affected and fixed for one install, and either answer looks authoritative in a report. The check must resolve the exact build the appliance reports against the vendor advisory for this CVE rather than performing a range comparison on a service-pack label. Third, and this is what makes it a compliance-theater test rather than a scan-hygiene one: confirm the recorded severity for this asset reflects the KEV listing rather than the 2.7 score, because an inventory that carries the appliance, resolves the build correctly, and then files the finding as low-priority has produced a clean-looking programme while leaving the exploited path open. Precondition: this verifies that the estate can see and correctly classify the flaw; it removes nothing on its own — the vendor update does that.",
+        "evidence": "Packet: ISO-27001-2022-A.8.8 gap 'Technical-vulnerability inventories classify the MiCollab UC appliance as a low-risk telephony box, so its admin-readable traversal — the file-read half of a chain completed by the unauthenticated CVE-2024-41713 — goes untracked and unpatched'; UK-CAF-B4 gap 'Vulnerability management processes scoring this CVE alone as low severity (CVSS 2.7) understate its real-world impact when chained with CVE-2024-41713'; affected_versions 'Mitel MiCollab through 9.8 SP2 (fully mitigated only in 9.8.2.12 / 9.8 SP2 and later)'; affected 'Mitel MiCollab admin console — an authenticated administrative attacker can read local files outside the intended admin-access scope due to insufficient input sanitization on a file-read parameter'; cisa_kev true with kev_date 2025-01-07; cvss 2.7.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-41713": {
     "name": "Mitel MiCollab Path Traversal Vulnerability (CVE-2024-41713)",
@@ -39790,7 +40715,31 @@
         "adequate": false,
         "gap": "EU operators running WebLogic as middleware need network-layer segmentation of T3/IIOP as a standing control, independent of patch status."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "Oracle WebLogic Server's T3 and IIOP listeners are precisely the binary remoting-protocol class this control governs: non-HTTP endpoints that answer an unauthenticated peer and whose object-handling path is itself the vulnerable code, so the HTTP-tier hardening and web application firewalling most WebLogic estates are audited against never touch them. For this deployment the requirement is that T3 and IIOP accept connections only from hosts that legitimately speak them — the application tier, cluster peers and management hosts — enforced at the network layer or by the server's own connection filtering rather than inferred from 'WebLogic is internal', and that whichever of the two protocols nothing legitimately uses is not listening at all; the packet names both as attack paths, and an estate that firewalls T3 while leaving IIOP answering has moved the exploit, not removed it. Distinguishing test for this product: from a general user or workstation VLAN, and from an external address, attempt to open a T3 connection and an IIOP connection to a staging WebLogic instance — anything that answers is within reach of an exploit that needs no credential, and 'the middleware is on the internal network' is a claim about topology rather than a demonstration that the listener is unreachable. Precondition, which is the whole reason the boundary-protection gap is recorded on this entry: restricting reachability bounds who can send the serialized object and does not repair the deserialization, so any host inside the permitted segment — a compromised application server, a jump host, a workstation with a legitimate T3 need — still reaches the Coherence sink in full; and where a cluster or a legacy client genuinely requires T3 across a wider segment, the lever is unavailable and only the vendor patch remains. Because the packet records continuous cryptomining and webshell campaigns against exposed T3/IIOP interfaces, an instance that answered from an untrusted network needs examining for an already-planted webshell or miner rather than being closed on the patch record.",
+        "evidence": "Packet: affected records that an unauthenticated attacker with network access to the T3 or IIOP protocol can send a malicious serialized object deserialized by the Oracle Coherence library, resulting in full server takeover; CVSS 9.8 with vector AV:N/AC:L/PR:N/UI:N. NIST-800-53-SC-7 gap: the most effective compensating control — disabling or firewalling T3/IIOP from untrusted networks — is a boundary-protection measure, not a patch, and many affected servers left T3/IIOP internet-reachable long after patching. NIS2-Art21-network-security gap: EU operators running WebLogic as middleware need network-layer segmentation of T3/IIOP as a standing control, independent of patch status. active_exploitation_notes: exploited in the wild almost immediately after the April 2020 patch and the May 2020 public PoC release, and still targeted by opportunistic scanners and cryptomining/webshell campaigns against exposed WebLogic T3/IIOP interfaces, prompting the CISA KEV addition in January 2025. poc_available true; active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet states the divergence this control exists to test: technical vulnerability management marks the control satisfied once the April 2020 patch is recorded as applied, yet CISA added this to KEV in January 2025 — 'patched in inventory' and 'not exploitable' are different statements wherever a shadow WebLogic instance was missed. A scan that reports this closed by reading a patch level from the hosts already in the asset register is paper compliance for exactly this CVE, because the instances driving a five-year exploitation tail are the ones the register does not contain: WebLogic embedded inside a vendor product or appliance, a dev or DR clone of production, an instance stood up for a migration and never retired. The operational test that separates the two is to discover by protocol response rather than by asset record — sweep the internal estate, the cloud ranges and the external perimeter for anything answering T3 or IIOP, and for every responder establish which release it is running against the four the packet names as affected (10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0) and whether the Oracle Coherence deserialization path it is executing carries the fix. A programme that reports zero vulnerable WebLogic hosts while a T3 listener answers somewhere has measured its inventory, not its estate. Preconditions: this finds instances, it does not remediate them — each responder still needs the vendor patch, and while the packet records no host reboot as required and no live-patch path, completion has to be read from the release the running server process reports, since the process holding the listener is the one executing the vulnerable deserialization path and a patch applied on disk under a still-running server is not yet in force. And because a public PoC has existed since May 2020 and campaigns have been continuous, a newly discovered exposed instance should be triaged as potentially already compromised rather than merely unpatched.",
+        "evidence": "Packet ISO-27001-2022-A.8.8 gap: technical vulnerability management marks A.8.8 satisfied once the April-2020 patch is recorded as applied, yet KEV addition in 2025 proves 'patched in inventory' and 'not exploitable' diverge for this T3/IIOP deserialization flaw wherever a shadow WebLogic instance was missed. UK-CAF-B2 gap: asset inventories that fail to track exposed middleware protocol ports (T3/IIOP) leave legacy WebLogic deployments exploitable years after a patch exists. AU-Essential-8-Patch gap: patch-application timelines alone do not explain multi-year persistence of exploitation against a patched vulnerability — unpatched shadow/legacy instances are the likely driver. NIST-800-53-SI-2 gap: patched in April 2020 yet CISA found active in-the-wild exploitation warranting KEV addition in January 2025. affected_versions: 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. poc_available true, with the public PoC recorded as released May 2020.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B2",
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-3393": {
     "name": "Palo Alto Networks PAN-OS Malicious DNS Packet Vulnerability",
@@ -40410,7 +41359,40 @@
         "adequate": false,
         "gap": "Financial-sector file-transfer exposure via MFT appliances was not adequately tested for resilience against this exploitation chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This entry is the incomplete-patch sequence the control exists for, and the packet states it outright: the fix shipped in 5.8.0.21 was itself incomplete and was bypassed, tracked separately as CVE-2024-55956, with the products recorded fully patched only in 5.8.0.24. Applied to Cleo, the requirement has three parts. The remediation target is 5.8.0.24 or later, not the first fix — an estate that closed this CVE at 5.8.0.21 recorded remediation while the arbitrary-write path into the autorun directory stayed open through the December 2024 ransomware campaign. The scope is all three products the packet names: Harmony, VLTrader and LexiCom are each recorded affected before 5.8.0.21, so an inventory built around the Harmony servers leaves the VLTrader and LexiCom installs on the identical write path, and each must be enumerated and shown at the fixed build in its own right. And the verdict on a first fix in a sequence is 'unproven', not 'closed': the second CVE on the same primitive raises rather than lowers the expectation of a third, so a vendor's assertion that a build closes the flaw is evidence to be tested, not accepted, which is precisely what the packet's ICT-supply-chain gap says no framework requires. Completion is measured on the version the running Cleo service reports rather than on the installer having been executed. Distinguishing test: against a staging install left at 5.8.0.21, replay the unauthenticated crafted POST carrying a traversal filename at the Synchronization endpoint and confirm nothing is written into the autorun directory — a patch metric that went green at 5.8.0.21 passes every cadence attestation while the write path remains exploitable.",
+        "evidence": "affected_versions: 'Harmony before 5.8.0.21 (initial fix incomplete)', 'VLTrader before 5.8.0.21', 'LexiCom before 5.8.0.21', 'fully patched in 5.8.0.24'; the NIST-800-53-SI-2 gap states the initial fix in 5.8.0.21 was itself incomplete and was bypassed (tracked separately as CVE-2024-55956), so patch-SLA compliance alone did not close the exposure window; the AU-Essential-8-Patch gap states patch-compliance was met by applying 5.8.0.21 yet that fix was bypassable and the appliances were mass-exploited by ransomware anyway; the ISO-27001-2022-A.5.21 gap states the ICT-supply-chain control does not require validating that a vendor's fix actually closes the flaw; the UK-CAF-B4 gap states system-security lifecycle management did not catch that the patched version remained exploitable; attack_vector describes an unauthenticated crafted POST with a path-traversal filename to the Cleo Synchronization endpoint writing into the autorun directory; CVSS 9.8, RWEP 74, poc_available true, cisa_kev true (2024-12-13); patch_available true, live_patch_available false, patch_required_reboot false, live_patch_notes null.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling",
+          "ISO-27001-2022-A.5.21",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive the packet describes is an arbitrary file write that lands in the Cleo autorun directory — a directory whose contents the product executes automatically — so on Harmony, VLTrader and LexiCom the directories the server holds and acts on are a privileged execution channel, not application data, and must be monitored as one. The requirement: file-integrity monitoring on the Cleo installation and on the autorun directory in particular, alerting on any file appearing there that does not correspond to a sanctioned operator action or a vendor update, together with alerting on child processes spawned by the Cleo service. The detection has to key on that shape and no other, because the shape is all the exploit produces. An attacker doing exactly what the packet describes sends a well-formed POST, causes a file to be written, and then lets the product run it through its ordinary autorun behaviour: nothing crashes, no exploit tooling signature is present on the host, and the execution is performed by the legitimate service. A rule keyed on service crashes, on known-bad hashes, or on anomalous inbound request volume would miss it; a rule keyed on unexpected writes into autorun plus the service's subsequent child process would not. This is also the control that retains value after 5.8.0.24 lands, since the upgrade closes the write path but removes nothing already written through it. Precondition: it requires the file-integrity and process telemetry to have been collected and forwarded off the server before the drop — against an actor holding code execution on that host, an alert stream retained only on the host is not evidence, and a rule authored afterwards against telemetry nobody was collecting produces nothing.",
+        "evidence": "attack_vector: 'An unauthenticated attacker sends a crafted POST request with a path-traversal filename to the Cleo Synchronization endpoint, writing an arbitrary file into the autorun directory that Cleo executes automatically, yielding remote code execution'; affected names Cleo Harmony, VLTrader and LexiCom and records unauthenticated upload/download leading to RCE through the autorun feature; active_exploitation_notes records at least ten businesses' Cleo servers confirmed compromised via arbitrary file write leading to RCE, with activity dating to 2024-12-03 and spiking 2024-12-08; DORA-Art10 is cited on this entry as 'Detection of anomalous activities and ICT-related incidents'; patch_available true with the fully-patched level recorded as 5.8.0.24.",
+        "gap_closes": [
+          "DORA-Art10"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records confirmed compromise, not merely exposure: at least ten businesses' Cleo servers compromised via arbitrary file write leading to RCE, mass exploitation from 3 December 2024 spiking on 8 December by a Termite-affiliated ransomware actor, and a KEV entry flagged ransomware Known. Upgrading Harmony, VLTrader and LexiCom to 5.8.0.24 closes the write path and leaves intact whatever was written into the autorun directory and executed before the upgrade. So for any Cleo server that was internet-reachable while running a build at or below 5.8.0.21 during that window, the default response is exporting the configuration for review, rebuilding at 5.8.0.24, and rotating every credential configured on the server — not upgrading in place and closing the ticket on the version number. Preconditions this control must not be recorded without. The rebuild decision depends on establishing whether the server was reachable and at which build during the window; where that cannot be evidenced, it is treated as exposed rather than clean. Taking an MFT server out of service for rebuild interrupts the partner transfers it exists to perform, so the action needs a scheduled path with the transfer partners rather than being assumed free — an unscheduled rebuild requirement is the one most likely to be quietly downgraded to an in-place upgrade. And the rebuild removes server-resident persistence only: files the actor moved through the server, and any encryptor deployment that already reached hosts beyond it, are incident-response scope that rebuilding the Cleo server does not recover.",
+        "evidence": "active_exploitation confirmed; active_exploitation_notes: 'Mass-exploited from early December 2024 (activity dating to Dec 3, spiking Dec 8) by a Termite-affiliated ransomware actor; at least ten businesses' Cleo servers were confirmed compromised via arbitrary file write leading to RCE. CISA KEV flags ransomware use as Known.'; attack_vector records the arbitrary file write into the autorun directory that Cleo executes automatically; affected_versions records the products affected before 5.8.0.21 and fully patched in 5.8.0.24; the NIST-800-53-SC-7 gap records the MFT appliances as directly internet-reachable with no additional network segmentation; the NIST-800-53-SI-2 gap records that patch-SLA compliance alone did not close the exposure window; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-49138": {
     "name": "Microsoft Windows Common Log File System (CLFS) Driver Heap-Based Buffer Overflow Vulnerability",
@@ -40561,7 +41543,38 @@
         "adequate": false,
         "gap": "Vulnerability management did not catch mass in-the-wild scanning that predated the CISA KEV addition."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "ProjectSend's configuration surface is options.php, and this CVE is that surface making no authentication decision at all: the packet has remote, unauthenticated attackers sending crafted HTTP requests to options.php and modifying the application's configuration. Bound to this product, the control means every configuration-writing action in ProjectSend authorizes its caller itself before the setting is persisted - not merely that the administrative UI requires a login - because at the moment of the write the attacker holds no ProjectSend account at all; the account it uses afterwards is one the write creates by enabling self-registration. That is also why the cited access-enforcement and identification-and-authentication controls do not close this path: the account model those attestations examine is bypassed rather than abused, so a review confirming that every ProjectSend user authenticates passes cleanly while an unauthenticated caller rewrites the site's security-relevant settings. Distinguishing test: from an unauthenticated client against a staging instance, POST configuration changes to options.php - the packet names self-registration and permissive upload types as the settings this attack toggles - and confirm each is refused before anything is written. Precondition: the endpoint-side authorization is a property the r1720 release establishes; this control states what to verify, it does not implement it. Until r1720 is deployed, restricting which networks can reach the instance bounds the caller population but leaves the endpoint fully exploitable to anything inside the permitted network, and the packet records mass scanning of internet-facing instances, so an instance published to the internet has no such bound at all.",
+        "evidence": "The packet's vector states that ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability, that remote unauthenticated attackers can exploit it by sending crafted HTTP requests to options.php enabling unauthorized modification of the application's configuration, and that successful exploitation allows attackers to create accounts, upload webshells and embed malicious JavaScript; the attack_vector record adds that the configuration change enables self-registration and permissive upload types, after which the attacker registers an account and uploads a webshell for remote code execution. CWE-306; affected_versions: prior to r1720. CISA KEV-listed 2024-12-03 with active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 64; patch_available true, patch_required_reboot false, live_patch_available false. The framework record states that the configuration endpoint (options.php) lacked authentication enforcement allowing unauthenticated modification of security-relevant settings (NIST SP 800-53 AC-3), that identification and authentication were not enforced on a configuration endpoint capable of enabling attacker-controlled account creation (NIST SP 800-53 IA-2), and that UK CAF B4 system-security lifecycle management allowed a self-hosted file-sharing app with unauthenticated config-write to remain internet-exposed.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "NIST-800-53-IA-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This exploitation chain ends in attacker-created artifacts rather than a transient condition, and the packet lists them: modified site configuration, created accounts, uploaded webshells and embedded malicious JavaScript, with mass scanning and exploitation of internet-facing instances observed since mid-2024. Upgrading to r1720 closes the unauthenticated configuration write and leaves every one of those artifacts exactly where it is - the webshell is application content sitting in the upload path, not product code the release replaces, and the attacker-created account and the flipped settings survive the upgrade untouched. So for any ProjectSend instance that was internet-reachable on a pre-r1720 build during that window, the remediation verdict cannot be 'now on r1720'. Audit the site configuration back to intended values, starting with self-registration and the permitted upload types the packet names; enumerate every account against a known-good roster and remove those with no owner; inspect the upload directory for files served as executable content; and check served pages for injected JavaScript. If any of those turn up, rebuild the deployment from known-good source and restore only reviewed data. Detection keys on the documented behaviour rather than a tool signature: unauthenticated requests to options.php, configuration changes with no corresponding administrator action, accounts appearing without an approval record, and new files in the upload path being requested directly. patch_required_reboot is false, so there is no host reboot to coordinate, but that is not the completion criterion either - measure completion on the release the deployed instance actually reports, and the packet registers no live-patch path, so nothing mitigates the code in place before that release lands.",
+        "evidence": "The packet's vector states that successful exploitation allows attackers to create accounts, upload webshells and embed malicious JavaScript, and affected names unauthenticated requests to options.php allowing modification of site configuration enabling attacker account creation, webshell upload and stored XSS. active_exploitation_notes record exploitation in the wild since mid-2024, with VulnCheck and honeypot telemetry observing mass scanning and exploitation of internet-facing ProjectSend instances to plant webshells and stored XSS payloads ahead of CISA's KEV addition. CISA KEV-listed 2024-12-03; active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 64. patch_available true with the fixed version recorded as r1720 (affected_versions: prior to r1720); patch_required_reboot false; live_patch_available false with live_patch_notes null. The framework record states that the ASD Essential Eight patch-applications control is reactive and that exploitation was already occurring in the wild before widespread patching - the gap this control answers, because on an instance exposed during that window the patch is not the completion criterion.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-072",
+        "name": "PRIMARY-SOURCE-INTAKE-VENDOR-BLOG-COVERAGE",
+        "description": "On this entry the exploitation signal existed months before the compliance-visible one, and the packet names both. Exploitation in the wild ran from mid-2024, seen by VulnCheck and honeypot telemetry as mass scanning and exploitation of internet-facing ProjectSend instances; the KEV listing that most vulnerability programmes trigger on is dated 2024-12-03. A pipeline that ingests advisory feeds and the KEV catalogue alone learns about this at the far end of that interval, which is the whole of the exposure for an internet-published instance. The requirement here is that threat intake also covers exploitation-telemetry reporting of that class - vendor and research publications of mass-scanning and honeypot observations - and that such a report naming a product the organisation actually runs opens a ticket on its own authority, without waiting for a KEV entry or a CVSS score to justify it. Distinguishing test: take a currently-reported mass-exploitation campaign against a self-hosted web application present in the estate and check whether the intake pipeline already holds a record of it; if the only record is the eventual KEV entry, the pipeline is the gap. Precondition: this is early warning, not mitigation - it advances the moment the operator knows, and on this entry the actual fix remains the r1720 release plus the compromise check for anything the earlier exposure already left behind.",
+        "evidence": "active_exploitation_notes state that ProjectSend was actively exploited in the wild since mid-2024, and that VulnCheck and honeypot telemetry observed mass scanning and exploitation of internet-facing ProjectSend instances to plant webshells and stored XSS payloads ahead of CISA's KEV addition; the KEV listing date recorded on this entry is 2024-12-03, with active_exploitation confirmed. poc_available true; CVSS 9.8, RWEP 64; patch_available true with the fixed version recorded as r1720. The framework record states that EU NIS2 Article 21 vulnerability management did not catch mass in-the-wild scanning that predated the CISA KEV addition - the gap this control is attached to, since the shortfall named there is source coverage rather than remediation speed.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-11667": {
     "name": "Zyxel Multiple Firewalls Path Traversal Vulnerability",
@@ -40695,7 +41708,40 @@
         "adequate": false,
         "gap": "Flaw remediation existed as a vendor patch (9.4.0.484) since March 2023, but SSL VPN gateways are commonly deprioritized for patching since they sit outside standard endpoint patch cycles, leaving a 20+ month exploitation window before CISA KEV listing."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "An Array AG Series or vxAG unit is a VPN concentrator, so this is the tier's own case rather than an appliance-patch-window item: an unauthenticated HTTP request carrying a crafted flags attribute in the header browses the gateway filesystem and chains through a vulnerable URL into remote code execution, with no credential presented at any point. Bound to this product, the tier means the fixed ArrayOS AG build (9.4.0.484 per the packet) is driven onto every unit on a KEV-anchored clock rather than the next planned firmware maintenance window, and where a unit cannot take it immediately the SSL VPN interface is removed from untrusted reachability instead of left serving. Two scoping decisions determine whether the sweep is real. Cover vxAG alongside the AG Series hardware — the packet names both, and virtual instances routinely sit outside the hardware appliance register a firmware-currency review walks. And measure completion on the ArrayOS version each unit is actually running: the packet records patch_required_reboot true with no live-patch path, so a unit holding the new image but not yet rebooted is still executing 9.4.0.481-or-earlier code and is not remediated, which is exactly the state a maintenance-window process leaves behind when the reboot slips to the next window. The clock this replaces is the one the packet indicts — a vendor fix in existence since March 2023 against a KEV listing more than twenty months later.",
+        "evidence": "Packet: KEV-listed 2024-11-25; active_exploitation confirmed; poc_available true; RWEP 77; CVSS 9.8; patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes null. Vector: Array Networks Array AG Series and vxAG (9.4.0.481 and earlier) allow remote code execution — an attacker can browse the filesystem on the SSL VPN gateway using a flags attribute in an HTTP header without authentication, and the product can then be exploited through a vulnerable URL; the 2023-03-09 vendor advisory stated 'a new Array AG release with the fix will be available soon.' NIST-800-53-SI-2 gap as recorded: the vendor patch 9.4.0.484 existed since March 2023, but SSL VPN gateways are commonly deprioritized because they sit outside standard endpoint patch cycles, leaving a 20+ month exploitation window before the KEV listing. AU-Essential-8-Patch gap as recorded: the 48-hour internet-facing target is outrun in practice because gateway firmware updates require planned maintenance windows.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This entry is the case the control's default exists for: a pre-authentication path to remote code execution on an SSL VPN gateway, used in the wild by Earth Kasha for initial access into target networks, with the KEV entry also carrying a known history of ransomware-actor use, against a fixed build that had existed for more than twenty months before the listing. For an Array AG or vxAG unit that was reachable from untrusted networks during that window, moving to the fixed ArrayOS build closes the header-flags file-browse path and removes nothing an attacker already took or placed — the packet's primitive reaches the appliance filesystem and then code execution on the gateway. The IR default is therefore to capture and preserve the configuration, rebuild the unit from vendor media, and rotate what the gateway held or brokered: its administrative credentials, its certificates and keys, and the VPN user credentials and session material that passed through it — rather than record the version bump as closure. Why this cannot be settled by looking for evidence first is also in the packet: the missing-authentication flaw has no built-in detection, so the absence of an alert on a gateway is not evidence it went unused, and the appliance is itself where any local record an attacker with code execution could alter lives. Precondition: rebuild-and-rotate applies to units that were reachable while unpatched. A unit that can be shown unreachable from untrusted networks for the whole exposure window is a patch item — but that demonstration has to come from network-side records, not from the gateway's own logs.",
+        "evidence": "Packet active_exploitation_notes: actively exploited in the wild by the China-linked espionage group Earth Kasha for initial access into target networks; CISA KEV flags this entry with a known history of ransomware-actor use. attack_vector: an unauthenticated HTTP request with a crafted flags attribute in the header grants filesystem browsing on the Array AG/vxAG SSL VPN portal and, through a vulnerable URL, remote code execution on the gateway. UK-CAF-B4 gap as recorded: a missing-authentication flaw with no built-in detection left gateways exposed long after a fix existed. NIST-800-53-SI-2 gap as recorded: a 20+ month exploitation window before the CISA KEV listing, with the vendor patch (9.4.0.484) available since March 2023. active_exploitation confirmed; poc_available true.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The packet states why a scanner verdict cannot carry this entry: the primitive is an unauthenticated file-browse on the SSL VPN gateway, invisible to standard vulnerability scanners that only probe authenticated surfaces, so a clean scan against an Array AG or vxAG unit says nothing about whether the flaw is present. The operational test is a version-and-state check taken on the device rather than a network verdict: produce, per unit and including the vxAG virtual instances, the ArrayOS AG version currently running against the 9.4.0.484 fixed build, and confirm the unit has actually rebooted onto it — the packet records the fix as reboot-required with no live-patch path, so an appliance showing the new image staged while still executing 9.4.0.481-or-earlier code is exposed with every dashboard reading remediated. The distinguishing exercise on a staging unit is to send the unauthenticated header-flags request and confirm the filesystem browse is refused before anything is returned; a firmware-currency review that walks only the hardware appliance register, and a scan report with no findings, both pass while an unregistered vxAG instance keeps serving the path. Precondition: this is a verification control — it tells the operator which units are still exposed, it does not reduce the exposure of any of them.",
+        "evidence": "ISO-27001-2022-A.8.8 gap as recorded: technical vulnerability management requires timely identification and remediation, but an unauthenticated file-browse primitive on a VPN gateway is invisible to standard vulnerability scanners that only probe authenticated surfaces. Packet affected/affected_versions: Array Networks AG Series and vxAG SSL VPN gateway appliances, ArrayOS AG 9.4.0.481 and earlier; the fixed vendor patch is recorded as 9.4.0.484, available since March 2023. patch_required_reboot true; live_patch_available false. Vector: unauthenticated filesystem browsing via a flags attribute in an HTTP header, chained through a vulnerable URL into remote code execution.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-44309": {
     "name": "Apple Multiple Products Cross-Site Scripting (XSS) Vulnerability",
@@ -41119,7 +42165,40 @@
         "adequate": false,
         "gap": "Access enforcement on the management plane failed because the interface itself lacked authentication for privileged actions, not because an access policy was misconfigured."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The device that has to be remediated here is the firewall itself: an unauthenticated caller who can reach the PAN-OS management web interface obtains PAN-OS administrator privileges, so the appliance enforcing the perimeter is the appliance failing open, and no standard 14- or 30-day appliance patch window applies to it. Scope the sweep from the packet's affected list rather than from 'our Palo Alto estate': PAN-OS 10.2, 11.0, 11.1 and 11.2 are the applicable trains, and the vector states Cloud NGFW and Prisma Access are not impacted, so an inventory must enumerate the on-prem units on those four trains at each train's own fixed release and must not raise findings against the cloud-delivered products. The clock runs from the 2024-11-18 KEV listing rather than from the next maintenance window, because the packet records a public PoC, confirmed exploitation, KEV ransomware use flagged as Known, and a chain with CVE-2024-9474 that converts administrator access into full firewall takeover. patch_available is true and live_patch_available is false, and the packet records the fix as requiring a reboot — so a unit that has installed the fixed PAN-OS release but has not restarted is still running the vulnerable code, and completion must be measured on the PAN-OS version the running unit reports rather than on an 'installed' or 'downloaded' state in the management console. Precondition on the interim measure, which is where this is usually over-claimed: the vector's guidance is that risk is greatly reduced by restricting management-web-interface access to trusted internal IP addresses — greatly reduced is not removed. The restriction bounds who can send the request; it does not restore the authentication the interface is not performing, so any address inside the permitted range — an administrator workstation, a jump host, a management VLAN routable from the general internal network — still reaches an interface that authenticates no one, and the measure is unavailable at all where the management interface must stay reachable for operations.",
+        "evidence": "Packet vector: 'An authentication bypass in Palo Alto Networks PAN-OS software enables an unauthenticated attacker with network access to the management web interface to gain PAN-OS administrator privileges to perform administrative actions, tamper with the configuration, or exploit other authenticated privilege escalation vulnerabilities like CVE-2024-9474', with 'The risk of this issue is greatly reduced if you secure access to the management web interface by restricting access to only trusted internal IP addresses', 'This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, PAN-OS 11.1, and PAN-OS 11.2 software' and 'Cloud NGFW and Prisma Access are not impacted by this vulnerability.' affected_versions: PAN-OS 10.2 / 11.0 / 11.1 / 11.2 prior to fixed releases. cisa_kev true, kev_date 2024-11-18, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 83. active_exploitation_notes: 'Actively exploited in the wild beginning November 2024 in a campaign researchers dubbed Operation Lunar Peek; chained with CVE-2024-9474 privilege-escalation to achieve full PAN-OS firewall takeover. CISA KEV flags ransomware use as Known.' patch_available true, patch_required_reboot true, live_patch_available false. AU-Essential-8-Patch gap: 'The Essential-Eight 48-hour internet-facing patch window is still slower than the ransomware-linked exploitation of a pre-auth admin bypass on a PAN-OS management interface.' NIS2-Art21-vulnerability-management gap: 'NIS2 vulnerability-handling obligations ... didn't prevent weeks of active exploitation before KEV listing forced remediation.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The PAN-OS management web interface is the device-management surface this control governs, and for this CVE the authorization half is the load-bearing one — the packet places the defect in the interface's own authentication decision, with administrative actions and configuration tampering reachable by a caller who never authenticates (CWE-306), not in a misconfigured access policy. Bound to this product the control means two things. First, that the privileged functions behind the management interface authorize their caller themselves rather than inheriting a verdict from a front-end that can be bypassed; that property is what the fixed PAN-OS release for each of 10.2, 11.0, 11.1 and 11.2 establishes — this control states what to verify, it does not implement it. Second, that no PAN-OS unit is left with its management web interface reachable from a segment with no operational need to reach it: the vector's own deployment guidance points at restricting access to trusted internal IP addresses, and reachability is the entire exploit precondition. This is also why the cited access-enforcement and identity-side attestations pass cleanly while the path stays open — the attacker never presents a PAN-OS account, so per-account privilege scoping is never consulted and the account model an audit examines is bypassed rather than abused. Distinguishing test: from a general user VLAN and from an external address, attempt to load the PAN-OS management web interface on a staging unit and confirm nothing answers; anything that responds is within reach of the published bypass, and 'the firewall's management plane is internal' is an assertion about topology rather than a demonstration that it is unreachable from untrusted segments. Precondition: restricting reachability bounds the population that can send the request and does not repair the authentication decision, and it gives nothing against a caller already inside the permitted management segment — a compromised administrator workstation or jump host satisfies the exploit's only stated access requirement in full.",
+        "evidence": "Packet vector places the flaw in the PAN-OS 'management web interface' with an unauthenticated attacker gaining 'PAN-OS administrator privileges to perform administrative actions, tamper with the configuration', and states 'The risk of this issue is greatly reduced if you secure access to the management web interface by restricting access to only trusted internal IP addresses'. cwe_refs: CWE-306. NIST-800-53-AC-3 gap: 'Access enforcement on the management plane failed because the interface itself lacked authentication for privileged actions, not because an access policy was misconfigured.' NIST-800-53-SC-7 gap: 'Restricting the management interface to trusted internal IPs is a mitigating control, not a fix — PAN-OS instances with any internet exposure of the management plane remained vulnerable regardless of standard perimeter controls.' ISO-27001-2022-A.8.9 gap: 'a hardening baseline forbidding exposure of the PAN-OS management plane to untrusted networks would blunt this pre-auth bypass, whereas access-control policy cannot help once the interface authenticates no one.' DORA-Art-9 gap: 'ICT protection and prevention measures for financial-sector firewalls didn't account for a pre-auth bypass on the management plane of core network security appliances.' affected_versions: PAN-OS 10.2 / 11.0 / 11.1 / 11.2. patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-AC-3",
+          "ISO-27001-2022-A.8.9",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's exploitation record is what makes this a rebuild question rather than a patch ticket: confirmed in-the-wild exploitation from November 2024 in the campaign researchers dubbed Operation Lunar Peek, chained with CVE-2024-9474 to reach full PAN-OS firewall takeover, with KEV ransomware use flagged as Known. On a unit whose management web interface was reachable from an untrusted segment during that window, the fixed PAN-OS release restores the authentication check but removes nothing an attacker did with administrator privileges beforehand — the vector names configuration tampering explicitly, and a firewall's configuration is where administrative accounts, API keys, certificates and the rules the rest of the estate depends on live. So for an exposed unit the sequence is: export and preserve the running and candidate configuration for comparison against a known-good baseline before touching the device, rebuild from that baseline rather than upgrading in place, and rotate every credential the unit held or authenticated — local administrator accounts, API keys, certificates and any shared secret configured on it. The identity assumption the cited identity-and-access control rests on cannot be restored by the update alone, because the material that assumption depends on was readable and writable by an unauthenticated caller. Precondition: this is scoped to units whose management interface was actually reachable from an untrusted segment during the exposure window, and that determination has to come from network evidence rather than from an assumption in either direction. Where the evidence does not exist, the unit belongs in the rebuilt population by default — an authentication bypass leaves no failed-login record to hunt for, because the request never presents a credential for the device to reject.",
+        "evidence": "active_exploitation_notes: 'Actively exploited in the wild beginning November 2024 in a campaign researchers dubbed Operation Lunar Peek; chained with CVE-2024-9474 privilege-escalation to achieve full PAN-OS firewall takeover. CISA KEV flags ransomware use as Known.' Packet vector: unauthenticated attacker gains 'PAN-OS administrator privileges to perform administrative actions, tamper with the configuration, or exploit other authenticated privilege escalation vulnerabilities like CVE-2024-9474'. attack_vector: 'An unauthenticated attacker with network access to the PAN-OS management web interface gains administrator privileges, then chains CVE-2024-9474 for full root-equivalent compromise of the firewall.' active_exploitation confirmed; poc_available true; kev_date 2024-11-18. UK-CAF-B2 gap: 'Identity and access management guidance assumes authentication exists on privileged interfaces; this flaw bypassed authentication entirely.' patch_available true, live_patch_available false, patch_required_reboot true.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2024-9465": {
     "name": "Palo Alto Networks Expedition SQL Injection Vulnerability",
@@ -41253,7 +42332,29 @@
         "adequate": false,
         "gap": "Endpoint anomaly detection wasn't tuned to catch AppContainer-to-service RPC escalation, which requires sandbox-escape-specific telemetry most EDR baselines lack."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "Windows Task Scheduler is the component the packet names, and the escalation begins from a process that is already running: a low-privileged local application or AppContainer process invokes privileged Task Scheduler RPC functions, escapes the sandbox and reaches Medium integrity. For this CVE the control means the November 2024 Windows update carrying the fix is driven across the population the packet's affected_versions actually names — multiple supported Windows client AND server builds — rather than across the browser-facing workstations the RomCom delivery path implies; a sweep scoped to laptops because the entry point was a browser renderer reports clean across a server estate that is equally affected. Completion is measured per host against the fixed build for that SKU from the November 2024 advisory, not against 'approved' or 'downloaded' in the management console: patch_required_reboot is true and no live-patch path is registered, so a host that has taken the update but not restarted is still executing the vulnerable code and must be counted as exposed. The control's second half is the load-bearing one here — the attacker's starting position is a sandboxed process rather than an over-privileged account, so tightening user privilege contains nothing, which is precisely why an application-hardening attestation (browser sandboxing enabled) and an environment-segregation attestation can both pass cleanly while the privileged RPC path stays open; the AppContainer boundary is the thing being defeated, not a boundary that can be re-asserted by configuration. Precondition: the packet records no live-patch path and names no interim vendor mitigation, so nothing in it supports treating hardening as a substitute for the update — and because exploitation is confirmed and the chain needed no user interaction beyond the initial browser compromise, a host that rendered untrusted web content during the exposure window belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet: patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. affected is 'Microsoft Windows Task Scheduler; elevation-of-privilege vulnerability allowing a low-privileged local application/AppContainer process to escape sandbox restrictions and access privileged RPC functions'; affected_versions is 'Multiple supported Windows client and server versions per the November 2024 Patch Tuesday advisory'. cisa_kev true with kev_date 2024-11-12, active_exploitation 'confirmed', poc_available true, RWEP 77, CVSS 8.8. attack_vector: 'After gaining code execution inside a sandboxed AppContainer (e.g. via a browser renderer exploit), an attacker invokes privileged Task Scheduler RPC functions to escape the sandbox and escalate to Medium integrity, with no user interaction required beyond the initial browser compromise.' Cited gaps: NIST-800-53-SI-2 'Monthly Patch Tuesday cadence trailed live zero-day exploitation by RomCom; the flaw was weaponized before a patch existed'; AU-Essential-8-App-Hardening 'Application hardening (browser sandboxing) was itself the control defeated by this chained zero-day, showing hardening alone is insufficient against a companion OS-level flaw'; ISO-27001-2022-A.8.22 'The AppContainer sandbox is a segregation boundary this flaw crosses to reach privileged RPC'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.22"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet attributes exploitation of this Task Scheduler flaw to the Russia-aligned RomCom threat actor, used as a zero-day and chained with a Mozilla Firefox zero-day against European and North American targets between October and November 2024. For this CVE the control means the runbook's escalation trigger is the chain shape rather than a malware verdict: a browser-renderer compromise followed on the same host by a Task Scheduler privilege transition to Medium integrity is the pattern the packet describes, and handling it as commodity browser-exploit cleanup under-scopes the response. Escalation here has to assume targeting rather than opportunism — preserve the host rather than reimaging it first, scope what the Medium-integrity foothold could reach, and treat other hosts in the same targeted population as in scope, because the packet describes campaign activity across two regions over a two-month window rather than an isolated infection. Precondition, and it is the binding one: this is a response control that fires only if something reported the escalation. The packet's own system-monitoring gap states that endpoint anomaly detection was not tuned to catch AppContainer-to-service RPC escalation and that most EDR baselines lack that sandbox-escape telemetry, so an estate that never collected it has no event for the runbook to escalate — the runbook does not create the signal. It also prevents nothing: it does not stop the escalation, and it does not evict an actor already holding Medium integrity on the host.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited in the wild as a zero-day by the Russia-aligned RomCom threat actor, chained with a Mozilla Firefox zero-day (CVE-2024-9680) to escape the browser sandbox and escalate to Medium integrity with no user interaction, in campaigns against European and North American targets between October and November 2024.' active_exploitation is 'confirmed'. Cited gaps: NIS2-Art21-incident-handling 'EU entities lacked telemetry to detect this AppContainer-escape technique as part of standard incident-handling baselines'; NIST-800-53-SI-4 'Endpoint anomaly detection wasn't tuned to catch AppContainer-to-service RPC escalation, which requires sandbox-escape-specific telemetry most EDR baselines lack.'",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-43451": {
     "name": "Microsoft Windows NTLMv2 Hash Disclosure Spoofing Vulnerability",
@@ -41455,7 +42556,38 @@
         "adequate": false,
         "gap": "Renewed exploitation of a decade-old, MEDIUM-severity XSS wasn't detected by most operators until Cisco publicly revised its bulletin; CAF C1 security monitoring needs signature coverage extended to old CVEs."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-074",
+        "name": "CVE-REGRESSION-WATCHER",
+        "description": "Nothing about this vulnerability changed - only its status did, and that is what the intake pipeline has to be able to see. The packet records poc_available false and CVSS 6.1, so no new exploit publication forced anyone's hand; what happened is that Cisco PSIRT revised its advisory for this decade-old ASA WebVPN login-page XSS to note renewed exploitation attempts (the packet records a 2024-03-18 publication and a further bulletin revision on 2024-12-02 confirming additional attempted exploitation), and CISA added CVE-2014-2120 to KEV on 2024-11-12. The requirement is an intake rule that re-opens historical CVE identifiers on exactly those two events - a vendor advisory revision and a KEV addition - instead of only on first disclosure, and that the resulting re-triage runs against the estate as it stands rather than inheriting the risk decision filed in 2014. Bound to this product, the watcher's hit list is CVE-2014-2120 / Cisco Bug ID CSCun19025 against every Cisco ASA in service, and the re-triage has to be allowed to override the severity filter that closed the item originally: a MEDIUM-scored XSS is precisely what a CVSS-keyed cadence deprioritises, while this entry carries confirmed active exploitation and an RWEP of 53 against that 6.1 base score. Distinguishing test: query the intake pipeline for CVE identifiers older than two years that acquired a KEV date or an advisory revision in the last quarter, and confirm each produced a ticket - a pipeline that only surfaces newly published CVEs returns an empty set and reports clean while this one is being exploited.",
+        "evidence": "active_exploitation_notes state that CISA added this to KEV in November 2024 after Cisco PSIRT revised its decade-old advisory (originally published 2024-03-18) to note renewed exploitation attempts, with a further bulletin revision on 2024-12-02 confirming additional attempted exploitation, and that CloudSEK reports AndroxGh0st botnet operators chaining this WebVPN login-page XSS with other Cisco ASA/IOS flaws in attempts to upload and backdoor PHP files for persistence; it is not flagged as ransomware. kev_date 2024-11-12, active_exploitation confirmed, poc_available false, CVSS 6.1, RWEP 53. The vector identifies the flaw as a cross-site scripting vulnerability in the WebVPN login page in Cisco ASA Software, injectable via an unspecified parameter, Bug ID CSCun19025. The framework record states that a 2014 flaw resurfacing a decade later shows patch-verification programmes rarely re-check advisories on EOL-adjacent devices and that SI-2 needs a KEV-relisting trigger rather than first-disclosure tracking; that A.8.8 vulnerability-management scope should include re-triage when a vendor revises a decade-old bulletin, since most asset inventories treat 2014 CVEs as permanently resolved; and that NIS2 Article 21 network-security obligations for entities running Cisco ASA as their VPN boundary require re-verification of decade-old advisories once CISA confirms renewed exploitation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The operative fact on this entry is in affected_versions: Cisco ASA Software releases predating the CSCun19025 fix, including EOL and unpatched branches still in production in 2024. patch_available is true, so a fixed release exists - but not necessarily for the branch a given appliance runs, and that has to be established per unit rather than assumed in either direction. The inventory therefore names every Cisco ASA in service with the software branch it runs and that branch's support status obtained from Cisco. Units on a branch that still receives fixes are remediation items: move them to a release carrying the CSCun19025 fix, and because patch_required_reboot is true with no live-patch path registered on this entry, completion is the image the appliance is running after the reload, not the image staged on it. Units on an end-of-life branch cannot reach the fix at all; those are replacement items - onto a supported branch the hardware can run, or onto new hardware - and they need a dated schedule, because a risk acceptance with no end date leaves a KEV-listed, actively-exploited VPN boundary appliance in service against everything found in that branch since it stopped receiving fixes, not merely against this XSS. Precondition on reachability, which is where this control is usually over-claimed: the defect lives in the WebVPN login page, so a unit that does not have WebVPN in operational use does not present that page - confirm that per unit rather than assume it - and on a unit that does, the page must stay reachable to the remote-access population it exists to serve, so there is no network restriction that removes the path while the service is in use.",
+        "evidence": "affected_versions state: Cisco ASA Software releases predating the CSCun19025 fix, including EOL/unpatched branches still in production in 2024. affected names the Cisco Adaptive Security Appliance (ASA) Software WebVPN login page, with reflected cross-site scripting via an unspecified parameter, Bug ID CSCun19025. CWE-79; CISA KEV-listed 2024-11-12 with active_exploitation confirmed; poc_available false; CVSS 6.1, RWEP 53. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. The framework record states that Essential Eight patch cadence typically deprioritizes MEDIUM-severity, decade-old bugs and that this CVE shows old low/medium CVEs can return to active exploitation and need periodic re-triage against KEV - the gap this control answers for the subset of units whose branch has no fix to apply, where a cadence-based patch control cannot complete at all.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The Cisco ASA is the perimeter-trust-boundary device this control names, and the monitoring failure on this entry is concrete: renewed exploitation attempts went unnoticed by operators until Cisco revised its bulletin. The packet also describes where the chain is heading - AndroxGh0st operators chaining this WebVPN login-page XSS with other Cisco ASA/IOS flaws in attempts to upload and backdoor PHP files for persistence - which is the case that makes the separate trust zone load-bearing, because telemetry that only lives on a device an attacker is trying to backdoor is not evidence you can rely on afterwards. So ASA syslog, WebVPN request logs and authentication logs must be forwarded to a collector in a different trust zone with its own credentials and management path, and the detection content on that collector has to key on what this attack actually emits: requests to the WebVPN login page carrying script or HTML markup in a URL parameter - the flaw is reflected, so the payload is present in the request as delivered - and the same source progressing to the upload and file-write attempts the packet describes as the chained follow-on. A rule keyed on appliance crashes, reboots or exploit-tool signatures will not fire here: a successful reflection produces an ordinary login-page render, and with poc_available false there is no public tool fingerprint to match. Precondition: this is detection, not prevention. Forwarding telemetry shortens the interval between the crafted request and the operator knowing; it does not stop the injection, which only a release carrying the CSCun19025 fix does, applied and reloaded.",
+        "evidence": "The vector states the flaw is a cross-site scripting vulnerability in the WebVPN login page in Cisco ASA Software allowing remote attackers to inject arbitrary web script or HTML via an unspecified parameter (Bug ID CSCun19025), and affected records it as reflected. attack_vector states an attacker crafts a URL targeting the ASA WebVPN login page with a script-injection payload in an unspecified parameter and that, a decade after disclosure, actors including AndroxGh0st began chaining it with other Cisco flaws to attempt file upload and backdooring; active_exploitation_notes attribute that chaining report to CloudSEK, naming AndroxGh0st botnet operators chaining this XSS with other Cisco ASA/IOS flaws in attempts to upload and backdoor PHP files for persistence. poc_available false; CISA KEV-listed 2024-11-12 with active_exploitation confirmed; CVSS 6.1, RWEP 53; patch_available true, patch_required_reboot true, live_patch_available false. The framework record states that renewed exploitation of a decade-old, MEDIUM-severity XSS was not detected by most operators until Cisco publicly revised its bulletin, and that UK CAF C1 security monitoring needs signature coverage extended to old CVEs, not only recent ones - the gap this control is attached to.",
+        "gap_closes": [
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2024-5910": {
     "name": "Palo Alto Networks Expedition Missing Authentication Vulnerability",
@@ -41497,7 +42629,38 @@
         "adequate": false,
         "gap": "Expedition is itself security infrastructure whose compromise cascades to every firewall it manages, raising the bar beyond routine vulnerability-handling timelines."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Expedition is the device-management tool the packet names — a Palo Alto Networks utility for firewall configuration migration, tuning and enrichment — and the defect sits on its administrative surface: the admin password-reset function performs no authentication, so an attacker with network access resets the admin password and takes the account over. Of this control's two halves, the authentication half is the load-bearing one and the input-neutralization half does not apply: nothing is being smuggled past a filter, the function simply never makes an authentication decision, which is why the packet's CWE is missing authentication for a critical function. Bound to this product it means each administrative function on Expedition — the password-reset path first — authorizes its caller before it executes, and no Expedition instance is left reachable from a segment with no operational need to reach it. The distinguishing test: from a segment with no configuration-migration role, send an unauthenticated request to the admin password-reset function on a staging Expedition instance and confirm it is refused before the password changes. An attestation that every Expedition operator authenticates at login passes cleanly while this path stays wide open, because the attacker never holds any Expedition account and the identity control's account model is never consulted. Precondition: the caller-side authorization is a property the vendor update to 1.2.92 establishes — this control states what to verify, it does not implement it. Until 1.2.92 is running, restricting which segments can reach Expedition bounds who can send the reset (the packet's only stated access requirement is network access to Expedition), but it leaves the function fully exploitable to anything inside the permitted segment, including a compromised engineering workstation or jump host, and it is unavailable where migration engineers must reach the tool. Measure the fix on the version the running Expedition service reports: patch_required_reboot is false, which records no host reboot, not that a service still executing pre-fix code has picked the fix up.",
+        "evidence": "Packet vector: 'Missing authentication for a critical function in Palo Alto Networks Expedition can lead to an Expedition admin account takeover for attackers with network access to Expedition. Note: Expedition is a tool aiding in configuration migration, tuning, and enrichment. Configuration secrets, credentials, and other data imported into Expedition is at risk due to this issue.' cwe_refs CWE-306; attack_vector describes a request to the admin password-reset function 'which performs no authentication check'. affected_versions: 'Expedition versions prior to 1.2.92'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null; poc_available true; CVSS 9.8, RWEP 72. Cited gaps: NIST-800-53-IA-2 'Expedition's admin password-reset function lacked identification/authentication entirely; IA-2 controls assumed at the app layer were absent by design in the vulnerable versions'; ISO-27001-2022-A.8.9 'configuration management should have caught an admin function shipped with no authentication gate by design before release'; UK-CAF-B4 'secure configuration expectations were violated by shipping an admin function with no authentication check by default.'",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "ISO-27001-2022-A.8.9",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "Expedition is a control-plane asset for a firewall fleet: the packet states that configuration secrets, credentials and other data imported into it are at risk from this flaw, and that harvested credentials give attackers a path to compromise downstream production firewalls. That makes the upgrade to 1.2.92 the smaller half of the response — the update closes the unauthenticated reset path but does not un-disclose a single secret already read out of the instance, and those secrets stay valid until they are rotated. For this product the playbook means: enumerate which PAN-OS configurations were imported into each Expedition instance and when, rotate every credential and secret contained in those imported configurations plus the Expedition admin account itself, audit the downstream firewalls whose configurations were exposed for changes made during the window, and set quarantine criteria for any of them showing unexplained configuration or account changes. Ordering matters here in a way it does not for an ordinary application: rotating on the firewalls while an unpatched Expedition instance still holds the new material simply re-exposes it, so the instance is patched or taken offline first. Precondition: the rotation scope is bounded by knowing what was imported, so the import inventory is part of the playbook rather than an input to it — an Expedition instance stood up ad hoc for a migration, with no record of which device configurations were loaded, cannot scope its own rotation and has to be treated as having exposed everything it ever imported. This control does not prevent the takeover and it does not detect it; it bounds what a takeover that already happened costs, and the packet records confirmed in-the-wild exploitation with a public proof of concept, so an instance that was network-reachable during the exposure window belongs on this path rather than being closed on the upgrade.",
+        "evidence": "Packet vector note: 'Configuration secrets, credentials, and other data imported into Expedition is at risk due to this issue.' affected: 'missing authentication for a critical admin function allows account takeover and access to imported PAN-OS configuration secrets and credentials.' active_exploitation_notes: 'Horizon3.ai researcher Zach Hanley published a working PoC (\"From N-Day to Full Compromise\") showing an unauthenticated attacker could reset the Expedition admin password and reach imported PAN-OS configuration secrets and credentials. Not flagged as ransomware, but harvested credentials give attackers a path to compromise downstream production firewalls.' active_exploitation 'confirmed'; poc_available true; patch_available true with affected_versions 'Expedition versions prior to 1.2.92'. Cited gap NIS2-Art21-vulnerability-handling: 'Expedition is itself security infrastructure whose compromise cascades to every firewall it manages.'",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock this control sets runs for this CVE from the 2024-11-07 KEV listing, with the fixed release (1.2.92) already available and a working proof of concept public — so there is no window in which a normal application-patch cadence is defensible, and the packet's own Essential Eight gap says the KEV remediation window is already tight given the trust Expedition holds over a firewall fleet. What makes the SLA hard to meet here is enumeration rather than the upgrade itself: Expedition is a migration utility, typically stood up by an engineer for a specific project and left running afterwards, so the instances most likely to be missed are the ones no software inventory records and no owner claims. The SLA therefore has to be driven from a deliberate hunt for Expedition instances — including any that were built for a finished migration — and each one taken to 1.2.92 or shut down, with completion measured on the version the running instance reports. Precondition on the interim mitigation, and it is the usual over-claim: the exploit precondition the packet states is network access to Expedition, so restricting reachability to a migration-engineering segment bounds who can send the unauthenticated reset but does not close the function for anything inside that segment, and it is unavailable while engineers are actively using the tool. It also gives nothing retroactively — reachability restriction applied after the fact does not invalidate secrets already read out of the instance, which is the separate rotation obligation.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-11-07, active_exploitation 'confirmed', poc_available true, patch_available true, affected_versions 'Expedition versions prior to 1.2.92', patch_required_reboot false, live_patch_available false, live_patch_notes null, CVSS 9.8, RWEP 72. Vector states the attacker requirement is 'network access to Expedition'. Cited gap AU-Essential-8-Patch: 'Essential Eight patch-applications guidance for network/security tooling; a 21-day KEV remediation window is tight given Expedition typically holds elevated trust to an entire firewall fleet.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-51567": {
     "name": "CyberPanel Incorrect Default Permissions Vulnerability",
@@ -41539,7 +42702,38 @@
         "adequate": false,
         "gap": "CAF D1 response-and-recovery planning is what actually determined outcomes for the 22,000 compromised instances — patching alone doesn't undo an existing PSAUX ransomware infection."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "CyberPanel is the hosting control panel this control governs, and the packet places the defect exactly where the control forbids it: a request-reachable view, upgrademysqlstatus in databases/views.py, whose statusfile property flows into OS command execution as root, with the only thing in front of it — secMiddleware — validating the request method rather than who is making it. That is CWE-306 at the precise function performing privileged database operations. Bound to this product the control means each CyberPanel view that performs a privileged operation authorizes its own caller instead of inheriting a verdict from a middleware layer that fronts it, and the statusfile value reaches the underlying operation as data rather than as text composed into a command line. Note which cited gap this does and does not touch: the access-enforcement gap is the one it closes, and per-account privilege scoping is never consulted on this path at all, because the attacker holds no CyberPanel account — the account model an access review examines is bypassed rather than abused, so an attestation that every panel administrator authenticates at login passes cleanly while this path stays open. Distinguishing test: against a staging CyberPanel, send unauthenticated requests to /dataBases/upgrademysqlstatus carrying shell metacharacters in statusfile, including with HTTP methods other than POST, and confirm each is refused before any command runs. Precondition: the caller-side authorization is a property the fix at commit 5b08cd6 establishes — this control states what to verify, it does not implement it, and it gives nothing to an instance still running 2.3.6 or unpatched 2.3.7.",
+        "evidence": "Packet: cvss 10, rwep_score 74, poc_available true, cisa_kev true with kev_date 2024-11-07, active_exploitation confirmed, cwe_refs CWE-306. vector: 'upgrademysqlstatus in databases/views.py in CyberPanel (aka Cyber Panel) before 5b08cd6 allows remote attackers to bypass authentication and execute arbitrary commands via /dataBases/upgrademysqlstatus by bypassing secMiddleware (which is only for a POST request) and using shell metacharacters in the statusfile property, as exploited in the wild in October 2024 by PSAUX. Versions through 2.3.6 and (unpatched) 2.3.7 are affected.' The NIST-800-53-AC-3 gap records that 'secMiddleware only validated the HTTP method (POST), not caller identity — an AC-3 access-enforcement gap at the exact function performing privileged database operations.'",
+        "gap_closes": [
+          "NIST-800-53-AC-3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This entry is the case the control's premise describes — an internet-facing pre-auth path to code execution under confirmed exploitation — and it is the case where patch-in-place is demonstrably not remediation. The packet records the PSAUX ransomware operation using an automated script (ak47.py) against over 22,000 internet-facing CyberPanel instances, deploying a custom encryptor (actually.sh) and dropping ransom notes system-wide, with the KEV entry flagged ransomware: Known. Updating past 2.3.6 / unpatched 2.3.7 closes the endpoint; it removes nothing an attacker already executed as root through it. So for any instance that was reachable from an untrusted network during the exposure window the requirement is the compromise path, not the patch path: capture configuration and evidence before touching the host, rebuild from a known-good baseline rather than repairing in place, and rotate every credential the host held or that root on it could read — the panel's own administrative credentials and the database credentials it manages, since the injection sits in the database-management view and runs as root. The response-and-recovery gap on this entry states the same conclusion in framework terms: recovery planning, not patching, determined outcomes for the compromised population. Precondition and scope: this applies to instances with exposure during the window, and absence of a ransom note is not a clean bill — the packet's campaign encrypted loudly, but the same unauthenticated root primitive is equally usable quietly on a panel that administers other people's hosting. An instance that can be shown never to have been reachable from an untrusted network during the window is a patch item, not a rebuild item.",
+        "evidence": "Packet: active_exploitation confirmed; active_exploitation_notes 'Actively exploited in the wild since October 2024 by the PSAUX ransomware operation, which used an automated script (ak47.py) to compromise over 22,000 internet-facing CyberPanel instances, deploy a custom encryptor (actually.sh), and drop ransom notes system-wide. CISA flags this KEV entry as ransomware-associated (ransomware: Known).' affected: unauthenticated root remote code execution via the upgrademysqlstatus function. framework_coverage for UK-CAF-D1: 'CAF D1 response-and-recovery planning is what actually determined outcomes for the 22,000 compromised instances — patching alone doesn't undo an existing PSAUX ransomware infection.'",
+        "gap_closes": [
+          "UK-CAF-D1",
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For CyberPanel the hard part of this SLA is not applying the fix, it is finding the instances. The packet's technical-vulnerability-management gap states that CyberPanel deployments are frequently unmanaged, forgotten hosting infrastructure that missed the emergency patch before the PSAUX campaign, and the campaign reached over 22,000 internet-facing instances — so the control's requirement here begins with an enumeration step ahead of the clock: identify every CyberPanel install the organisation or its hosting tenants run, including instances stood up outside change management and instances nobody currently owns, and drive each from 2.3.6 or unpatched 2.3.7 to the fixed code on the KEV clock rather than the routine application-patch cadence. Completion is measured on the version the running CyberPanel process is serving. patch_required_reboot is false, which means no host reboot is needed — not that a process already running has picked up a replaced databases/views.py — so verify the running instance rather than the files on disk. Preconditions, both of which bound what this control can claim. An emergency SLA is only as good as the inventory it runs against; attested against a known-instance list it marks the estate compliant while the untracked hosts, which are the exposed population for this product, stay on vulnerable code. And the KEV listing of 2024-11-07 postdates the start of exploitation in October 2024, so on this entry the SLA governs the population not yet hit — for an instance already compromised the applicable path is rebuild and credential rotation, not the patch record.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-11-07, active_exploitation confirmed, poc_available true, cvss 10. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions: through 2.3.6 and 2.3.7 (unpatched). The ISO-27001-2022-A.8.8 gap records that 'CyberPanel deployments are frequently unmanaged, forgotten hosting infrastructure that missed the emergency patch before PSAUX's mass campaign'; the AU-Essential-8-Patch gap records that the Essential Eight patch-applications target for internet-facing services is far tighter than the roughly one month between disclosure and the ransomware wave that hit 22,000 instances. active_exploitation_notes places exploitation in the wild since October 2024.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-43093": {
     "name": "Android Framework Privilege Escalation Vulnerability",
@@ -41725,7 +42919,40 @@
         "adequate": false,
         "gap": "The device relies on the presence of an HTTP Authorization header rather than server-side session validation; simply omitting the header bypasses identification and authentication entirely."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Bound to the PTZOptics PT30X-SDI/NDI camera, this means /cgi-bin/param.cgi — and every other endpoint on the camera's lighttpd-based CGI management interface that reads or writes configuration — makes its own server-side authorization decision on every request, instead of treating the presence of an HTTP Authorization header as the decision. The packet's defect is the absence of that decision in both directions: a request sent with no Authorization header is answered, returning usernames, password hashes and configuration details, and is also accepted for writes that change individual configuration values or overwrite the whole configuration file. The second half of the control is reachability: no camera's management interface should answer from a segment with no operational need to configure it, which in a broadcast or remote-production deployment means reaching the cameras through an authenticated path onto the production VLAN rather than port-forwarding the CGI interface to the internet. Scope the sweep from the packet's affected field, not from the headline brand: PT30X-SDI/NDI-xx units below firmware 6.3.40 AND the OEM-rebadged Multicam Systems SAS and SMTAV Corporation devices that share the same Hisilicon Hi3516A V600 SoC firmware — an inventory keyed on the PTZOptics name alone reports clean across a fleet bought under a rebadge while every unit still answers the same unauthenticated request. The packet records the fixed level as firmware 6.3.40 for PT30X-SDI/NDI-xx only, so the fixed level for a rebadged unit has to come from that vendor rather than be assumed to be the same string. Distinguishing test: from an untrusted segment, issue a request to /cgi-bin/param.cgi on a staging camera with no Authorization header and confirm it is refused before any value is returned or written — an attestation that every camera has an administrator password with a rotation policy passes cleanly while this path stays open, because the attacker never presents a credential for that policy to govern. Precondition: the endpoint-side authorization is a property firmware 6.3.40 establishes; this control states what to verify, it does not implement it. Until a unit is on 6.3.40 and has been restarted onto it, restricting reachability only bounds who can send the request — it leaves the endpoint fully exploitable to anything inside the permitted segment, and it is not available at all where the camera must stay internet-reachable for remote production, which the packet records as the normal deployment. And because exploitation is confirmed and the read returns usernames and password hashes, a camera that was reachable during the window is not remediated by firmware alone: its configuration has to be rebuilt from a known-good baseline rather than inherited through the update, and every credential it held rotated.",
+        "evidence": "The packet's vector states the camera does not properly enforce authentication to /cgi-bin/param.cgi when requests are sent without an HTTP Authorization header, that a remote unauthenticated attacker can leak sensitive data such as usernames, password hashes and configuration details, and that the attacker can update individual configuration values or overwrite the whole file. `affected` names PTZOptics PT30X-SDI/NDI-xx PTZ cameras and OEM-rebadged Multicam Systems SAS / SMTAV Corporation devices sharing the Hisilicon Hi3516A V600 SoC firmware, running the lighttpd-based CGI management interface prior to firmware 6.3.40; affected_versions records PT30X-SDI/NDI-xx firmware < 6.3.40. CWE-306 and CWE-287, CVSS 9.1, RWEP 86, poc_available true, active_exploitation confirmed, CISA KEV dated 2024-11-04, with GreyNoise observing active scanning and exploitation attempts against the vulnerable /cgi-bin/param.cgi endpoint shortly after disclosure. The cited boundary-protection gap records that PTZ cameras are frequently exposed directly to the internet for remote production/broadcast use, so boundary protection is the only backstop once the CGI endpoint's own auth check fails; the identity gap records that the device relies on the presence of an HTTP Authorization header rather than server-side session validation; the configuration-management gap records that /cgi-bin/param.cgi ships accepting requests with no Authorization header and that this chains to root RCE via CVE-2024-8957. patch_available is true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.8.9",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry opens with the 2024-11-04 KEV listing and the deliverable is firmware 6.3.40 running on every affected camera — not approved, not staged, running. Embedded camera fleets are the population where a KEV clock usually fails to start at all: the packet's own Essential-Eight gap records that embedded/IoT device patching is rarely covered by standard patch-management tooling, so these units are absent from the inventory the SLA is measured against and the deadline passes over an estate nobody is counting. The first action the SLA requires here is therefore enumeration — every PT30X-SDI/NDI-xx unit and every OEM-rebadged Multicam Systems SAS or SMTAV unit sharing the Hisilicon Hi3516A V600 SoC firmware, each with its running firmware version and, for a rebadged unit, a fixed-firmware level obtained from that vendor rather than assumed in either direction, since the packet publishes 6.3.40 only for the PTZOptics part number. Completion is measured per camera on the firmware the device reports after it has restarted onto it: the packet records a vendor patch requiring reboot and no live-patch path, so a camera that has taken 6.3.40 but has not been restarted is still executing the vulnerable CGI and counts as exposed. Where a rebadged unit's vendor publishes no firmware carrying the fix, there is nothing for the SLA to land against and the response is entirely the compensating half — removing that unit's management interface from any untrusted-reachable path, or removing the unit — recorded with a dated review rather than an open-ended acceptance. Priority follows the packet rather than the CVSS band alone: a public PoC, confirmed exploitation, and observed scanning against this exact endpoint within days of disclosure put this ahead of the routine firmware cycle an AV estate normally runs.",
+        "evidence": "cisa_kev true with kev_date 2024-11-04; active_exploitation confirmed; poc_available true; CVSS 9.1 and RWEP 86. active_exploitation_notes records GreyNoise observing active scanning and exploitation attempts against the vulnerable /cgi-bin/param.cgi endpoint on live-streaming PTZ cameras shortly after disclosure, and that CISA did not flag it ransomware-associated. patch_available true, patch_required_reboot true, live_patch_available false, with the fixed level recorded in the vector and affected fields as firmware 6.3.40 for PT30X-SDI/NDI-xx; `affected` additionally names OEM-rebadged Multicam Systems SAS / SMTAV Corporation devices sharing the Hisilicon Hi3516A V600 SoC firmware. The cited Essential-Eight gap states embedded/IoT device patching is rarely covered by standard patch-management tooling, delaying rollout of firmware 6.3.40 across affected fleets; the cited NIS2 vulnerability-management gap states firmware-update SLAs for embedded camera fleets routinely exceed the observed exploitation window, with active scanning beginning within days of public disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-024",
+        "name": "AI-DISCOVERY-RESPONSE-SLA",
+        "description": "This is one of the entries where the packet's ai_discovered flag is set, and the control's premise is that the flag is a scheduling input rather than trivia: a defect found by automated analysis is one an adversary's automated analysis can reach too, so the interval between disclosure and weaponisation compresses relative to a hand-found bug carrying the same CVSS. The record here is what that compression looks like — a public PoC, and scanning and exploitation attempts against /cgi-bin/param.cgi observed shortly after disclosure, well inside the firmware cycle an embedded camera fleet normally runs, which is the packet's stated NIS2 gap. Operationally the control is an intake rule: an advisory carrying an AI-discovery attribution for any device class in the estate enters the compressed-response queue at disclosure rather than waiting for a KEV listing to promote it. For this CVE the KEV listing arrived 2024-11-04 and would have been the only trigger most programmes had, while the exploitation the packet records was already under way. Preconditions and limits: this changes when the firmware work starts and nothing about what it consists of — the remediation is still 6.3.40 and the restart onto it on every PT30X-SDI/NDI-xx unit and every rebadged Multicam Systems SAS / SMTAV unit sharing the same SoC firmware — and starting earlier does not create a fixed build where a rebadging vendor has published none. It also depends on the discovery modality being present in the intake feed at all: an advisory that does not say how the bug was found cannot be triaged this way, which is the reason to capture the modality as a recorded field rather than leave it in the prose of a writeup.",
+        "evidence": "The packet sets ai_discovered true for this entry. It also records poc_available true, active_exploitation confirmed, cisa_kev true with kev_date 2024-11-04, CVSS 9.1 and RWEP 86, and active_exploitation_notes describing GreyNoise-observed active scanning and exploitation attempts against the vulnerable /cgi-bin/param.cgi endpoint shortly after disclosure. The cited NIS2 vulnerability-management gap states that firmware-update SLAs for embedded camera fleets routinely exceed the observed exploitation window because active scanning began within days of public disclosure. patch_available true, patch_required_reboot true, live_patch_available false; fixed level recorded as firmware 6.3.40 for PT30X-SDI/NDI-xx, with `affected` also naming OEM-rebadged Multicam Systems SAS / SMTAV Corporation devices on the same Hisilicon Hi3516A V600 SoC firmware.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-37383": {
     "name": "RoundCube Webmail Cross-Site Scripting (XSS) Vulnerability",
@@ -41762,7 +42989,39 @@
         "adequate": false,
         "gap": "Malicious-code/content filtering at the email gateway rarely sanitized SVG animate attributes, so the payload reached the webmail client unfiltered."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "Roundcube's HTML/SVG sanitizer is the protection mechanism here, and this CVE is a bypass of it rather than a defect elsewhere in the client: the packet locates the failure in the handling of <animate> element attributes when rendering message previews, reached by a crafted, whitespace-padded attribute the sanitizer does not strip. Applied to this product the control means that sanitizer is treated as a tested protection-mechanism class rather than an assumed property of the platform — a bypass battery re-run against every Roundcube instance on every upgrade and configuration change, carrying the historic primitives for this class including the SVG animate-attribute form this CVE used and attribute-whitespace padding, instead of a one-off confirmation that 1.5.7 / 1.6.7 rejects this one input. That is exactly what the cited gaps describe: configuration management for the input-sanitization library did not surface the animate-attribute hole until active phishing exploitation did, and the secure-configuration assurance recorded for the webmail platform assumed the sanitization was complete. Distinguishing test: deliver the SVG animate payload class to a staging Roundcube instance by email and open the message in the reading pane, confirming it renders as inert markup — an application-hardening attestation scoped to office macros and browser plugins never reaches the webmail client's sanitizer and passes cleanly while this path is open. Precondition: a regression battery finds only the primitives it contains. It does not make the sanitizer correct and will not anticipate the next attribute the parser mishandles; it bounds recurrence of a known class and gives a signal when an upgrade or a configuration change reopens one.",
+        "evidence": "Packet: vector 'Roundcube Webmail before 1.5.7 and 1.6.x before 1.6.7 allows XSS via SVG animate attributes'; affected identifies 'Roundcube Webmail's HTML/SVG sanitizer, specifically its handling of <animate> element attributes when rendering email message previews'; attack_vector describes a crafted, whitespace-padded <animate> attribute that Roundcube's HTML sanitizer fails to strip. The ISO-27001-2022-A.8.9 gap records that 'Configuration management for the input-sanitization library didn't catch the animate-attribute gap until active phishing exploitation surfaced it'; the UK-CAF-B4 gap records that secure configuration of the webmail platform assumed complete HTML/SVG sanitization; the AU-Essential-8-App-Hardening gap records that application hardening targets office macros and browser plugins, not the webmail client's HTML/SVG sanitisation.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.9",
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Rebound to Roundcube, this control's stated rationale is this CVE exactly: the malicious activity flows over a session that is already authenticated, so authentication-event logging records nothing. Roundcube per-request access logs — not just login events — must be forwarded to a collector outside the webmail host and retained long enough to reconstruct a campaign. The detection keys on what the packet documents: the payload arrives as an SVG in a message, executes when the victim opens or previews it, and injects a fake login form to harvest credentials. So the observable shape is requests issued from a user's authenticated webmail session while a specific message is being previewed that the reading pane does not otherwise generate, and above all a credential submission going somewhere other than the instance's own login endpoint, with no new authentication event anywhere in the timeline. Correlate the same message reaching multiple mailboxes, since the packet describes a campaign against an organisation rather than a single victim. Note what will not see it: nothing is installed or written to the endpoint — the payload is script inside a rendered page — so signature-based endpoint tooling has no artifact to match, and by the packet's own account the gateway content filter already failed to strip the animate attribute on the way in. The credential theft itself surfaces later as a valid login that looks like the user. Preconditions: per-request logging has to be collected and shipped off-host before the message arrives, and a rule written afterwards against telemetry nobody retained produces nothing. And detection does not prevent the harvest — it bounds it to alert-and-response time and identifies whose credentials and sessions must be invalidated.",
+        "evidence": "Packet: attack_vector states that when the victim opens or previews the message, injected JavaScript executes in their authenticated session and can inject a fake login form to harvest credentials. active_exploitation_notes: 'Exploited in June 2024 phishing campaigns (reported by Positive Technologies) targeting government organizations in the CIS region, using SVG-embedded payloads in email attachments to inject fake login forms and steal credentials.' The NIST-800-53-SI-3 gap records that 'Malicious-code/content filtering at the email gateway rarely sanitized SVG animate attributes, so the payload reached the webmail client unfiltered'; the GDPR-Art32 gap records that technical measures protecting session/credential data were undermined by the XSS-driven fake-login-form credential theft. cisa_kev true, kev_date 2024-10-24, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "GDPR-Art32"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For Roundcube the SLA has to be expressed per instance and per release line, because the packet gives two distinct fixed builds: 1.5.7 on the 1.5 line and 1.6.7 on the 1.6.x line. An estate that upgraded its 1.6 instances while a 1.5.x instance sits below 1.5.7 is still serving the vulnerable sanitizer, and a single 'Roundcube patched' entry on a vulnerability register hides that. Completion is measured on the version the running Roundcube instance is actually serving: patch_required_reboot is false, which means no host reboot is required — not that a running instance is executing the replaced sanitizer code — so verify the served version per instance rather than the package state on disk. The vulnerability-handling gap on this entry names the underlying cause of the delay: webmail platforms are deprioritised in patch cadence, which is why this needs to be on the KEV clock rather than the normal application cycle. Preconditions: the KEV listing is 2024-10-24 while the packet places exploitation in June 2024 phishing campaigns, so this SLA governs the residual population and cannot be presented as having covered the campaign window; and because the exploitation outcome recorded here is credential theft rather than server compromise, upgrading an instance that was exposed does not invalidate credentials already harvested from it — those accounts need password reset and session invalidation independently of the version record.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-10-24, active_exploitation confirmed, poc_available true, cvss 6.1, rwep_score 68. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions: '< 1.5.7' and '1.6.x < 1.6.7'. active_exploitation_notes places exploitation in June 2024 phishing campaigns targeting government organizations in the CIS region, stealing credentials via fake login forms. The NIS2-Art21-vulnerability-handling gap records that 'Webmail platforms are often deprioritized in patch cadence; the June 2024 exploitation window against government targets preceded widescale patching.'",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-20481": {
     "name": "Cisco ASA and FTD Denial-of-Service Vulnerability",
@@ -41858,7 +43117,40 @@
         "adequate": false,
         "gap": "fgfmd accepted device-registration requests presenting a self-signed certificate/serial number without verifying prior trust establishment, defeating device-level authentication entirely."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "FortiManager is the device-management gateway this control governs and fgfmd is its registration endpoint: the packet describes the daemon accepting FortiGate Manager Protocol device-registration requests without verifying the requesting device's authenticity, so an unauthenticated remote attacker presents a crafted certificate and serial number, registers a rogue device, and then drives management-protocol requests into arbitrary code or command execution on the FortiManager server. Bound to this product, the control means fgfmd decides for itself whether the registering device matches previously established trust before it processes any management-protocol request from it, rather than treating presentation of a self-signed certificate and a serial number as the trust establishment; and no FortiManager or FortiManager Cloud instance is left with its FGFM interface answering from a segment that holds none of the FortiGates it administers. This is also why the least-privilege-style attestations on this entry pass while the path stays open: the attacker never holds a FortiManager operator account, so per-account access enforcement and organizational-user authentication are never consulted. Distinguishing test: from a segment containing no managed FortiGate, present a crafted certificate and serial number to fgfmd on a staging FortiManager and confirm the registration is refused before any management request is acted on. Preconditions, and they are where this gets over-claimed. The endpoint-side verification is a property the vendor update establishes — this control states what to verify, it does not implement it, and patch_required_reboot is true with live_patch_available false, so a unit that has taken the image but has not rebooted is still running the vulnerable fgfmd and counts as exposed. Until that reboot the operator holds two partial levers. The first is the interim setting the packet records, `set fgfm-deny-unknown enable`, published for FortiManager 7.0.12+, 7.2.5+ and 7.4.3+ — a unit on 6.2.x, 6.4.x, 7.0.0 through 7.0.11, 7.2.0 through 7.2.4, or 7.6.0 is outside the builds the packet names for that setting and has no recorded interim configuration at all; and even where it applies it blocks unknown-device registration, so it neither removes a device the attacker already registered nor helps a unit compromised during the pre-disclosure zero-day window. The second is restricting which segments reach FGFM, which bounds who can attempt registration but leaves the endpoint fully exploitable to anything inside the permitted segment, and is unavailable where FGFM must stay reachable for the managed fleet to check in. The packet lists FortiManager Cloud releases among the affected versions, so Cloud tenancies belong in the same inventory as on-premises appliances; the packet records the interim setting for FortiManager builds and states no Cloud equivalent.",
+        "evidence": "Packet affected: 'Fortinet FortiManager and FortiManager Cloud fgfmd daemon, which handles FortiGate Manager Protocol (FGFM) device-registration requests without verifying the requesting device's authenticity.' attack_vector: 'An unauthenticated remote attacker registers a rogue device against the fgfmd daemon using a crafted certificate/serial number, bypassing FGFM protocol authentication, then sends crafted management-protocol requests to execute arbitrary code or commands on the FortiManager server.' NIST-800-53-IA-2 gap: 'fgfmd accepted device-registration requests presenting a self-signed certificate/serial number without verifying prior trust establishment, defeating device-level authentication entirely.' NIST-800-53-AC-3 gap: 'Access enforcement for the FGFM management protocol didn't validate device identity before granting management-plane command execution.' UK-CAF-B4 gap: 'Secure configuration guidance assumed FGFM device registration required prior trust establishment; the missing-authentication flaw broke that assumption.' ISO-27001-2022-A.8.22 gap names segregation of networks as the compensating control the flaw demands. live_patch_notes: 'Fortinet published an interim mitigation (set fgfm-deny-unknown enable) for FortiManager 7.0.12+/7.2.5+/7.4.3+ to block unknown-device registration ahead of the full patch.' affected_versions include FortiManager 7.6.0, 7.4.0-7.4.4, 7.2.0-7.2.7, 7.0.0-7.0.12, 6.4.0-6.4.14, 6.2.0-6.2.12 and FortiManager Cloud 7.4.1-7.4.4, 7.2.1-7.2.7, 7.0.1-7.0.12, 6.4.1-6.4.7. patch_available true, patch_required_reboot true, live_patch_available false. CWE-306, CVSS 9.8, RWEP 83, poc_available true, CISA KEV 2024-10-23, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.22"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "FortiManager is the fleet control plane for a FortiGate estate, and the packet states the consequence plainly: because it centrally manages fleets of FortiGate firewalls, compromise of the management plane can cascade to every managed device. That makes this the exact scenario the playbook exists for, and the exploit's first act — registering a rogue device against fgfmd — is literally a device-trust-state problem, so the playbook's trust-invalidation step is not a generic gesture here but the specific remediation. Bound to this product, the playbook must enumerate every device registered to each FortiManager and FortiManager Cloud tenancy and revoke and re-establish trust for any registration that does not correspond to a known unit; audit the configuration and policy pushed to managed FortiGates across the whole exposure window rather than since the patch; define quarantine criteria for downstream FortiGates that received a push during that window, since a rogue registration on the manager is a supply route into devices that were never themselves vulnerable; and rotate the credentials and API material held on or distributed through the manager. Precondition on the window, which is where this playbook is usually mis-scoped: the packet records exploitation in the wild both prior to and following Fortinet's disclosure, so the window opens before the 2024-10-23 KEV listing and before the operator's own patch, not at either of them — a review that starts at the patch date examines the period after the attacker had already finished. This is response work; it does not repair the missing authentication, which the vendor update and its reboot do, and a manager whose fgfmd was reachable during the window needs both.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited as a zero-day in the wild prior to and following Fortinet's disclosure; because FortiManager centrally manages fleets of FortiGate firewalls, compromise of the management plane can cascade to every managed device.' NIS2-Art21-vulnerability-handling gap: 'FortiManager centrally manages fleets of FortiGate firewalls; a missed patch window converts a single flaw into fleet-wide compromise, exceeding standard vulnerability-handling SLAs.' DORA-Art-9 gap: 'ICT third-party risk management for centralized network-management platforms didn't anticipate a preauth RCE in the management plane itself.' attack_vector describes the attacker registering a rogue device against fgfmd, then executing arbitrary code or commands on the FortiManager server. affected covers both FortiManager and FortiManager Cloud. CISA KEV 2024-10-23; active_exploitation confirmed; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling",
+          "DORA-Art-9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records this as a zero-day exploited in the wild before Fortinet's disclosure, and the packet's own Essential Eight gap draws the conclusion the control encodes: patching alone could not prevent initial compromise, because exploitation preceded patch availability. For a FortiManager or FortiManager Cloud instance whose FGFM interface was reachable during that window, the vendor update is therefore not the finish line. The attacker's path ends in arbitrary code and command execution on the FortiManager server, and the update replaces the vulnerable fgfmd without removing anything already placed through it — including the rogue device registration itself, which survives the upgrade as configuration rather than as a file an update would overwrite. The requirement for this appliance is the default the control names: export and preserve the configuration for analysis, rebuild the unit from vendor media, restore only reviewed configuration rather than the running config wholesale, and rotate every credential and API key the appliance held or distributed, before it resumes managing the FortiGate fleet. Precondition on which units this applies to: rebuild is the default for a unit with evidence of exploitation and equally for a unit where the evidence would not exist either way, because the exposure window opened before disclosure and most operators have no telemetry covering it; a unit that can be demonstrated unreachable on FGFM for the entire window is a patch-and-reboot item rather than a rebuild item, and that demonstration is a positive finding about reachability, not an assumption from topology. patch_required_reboot is true and live_patch_available is false, so the reboot is part of the remediation on every unit either way — an image staged but not rebooted onto is still the vulnerable build.",
+        "evidence": "Packet AU-Essential-8-Patch gap: 'Zero-day exploitation preceded patch availability, so patching alone couldn't prevent initial compromise; the fgfm-deny-unknown workaround required separate, deliberate deployment.' active_exploitation_notes: 'Exploited as a zero-day in the wild prior to and following Fortinet's disclosure.' attack_vector ends in 'execute arbitrary code or commands on the FortiManager server' after the attacker 'registers a rogue device against the fgfmd daemon'. patch_available true, patch_required_reboot true, live_patch_available false; live_patch_notes records the interim `set fgfm-deny-unknown enable` mitigation for FortiManager 7.0.12+/7.2.5+/7.4.3+ ahead of the full patch. CISA KEV 2024-10-23, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 83.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-38094": {
     "name": "Microsoft SharePoint Deserialization Vulnerability",
@@ -41969,7 +43261,40 @@
         "adequate": false,
         "gap": "Backup servers are frequently granted broad domain-trust/administrative reach; least-privilege segmentation wasn't enforced, letting a single RCE cascade into domain and backup-destruction access."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "The sink on this product is specific and the packet locates it: Veeam.Backup.MountService, reachable on the Veeam Backup & Replication server's backend service on TCP/8000, deserializing untrusted .NET objects with no credential presented. Applied to this deployment, the control means that port answers only from the backup-administration segment and the hosts Veeam has an operational need to speak to — not from the general user VLAN, and not from the internet. It also means constraining the server's outbound path, because the packet records rclone-based exfiltration from this same access, and a backup server that can reach arbitrary destinations is a server that can carry the entire protected data set out. The precondition is where this control is most often over-claimed on this CVE, and the packet states it outright: the affiliates typically chained the RCE with compromised VPN credentials to gain initial network access first. So an isolation policy that admits the general remote-access client pool into the backup segment does not bound this at all — the attacker satisfies the reachability precondition in full before sending the request, using credentials that belong to a legitimate user. Isolation has to exclude the ordinary VPN pool, with administrative reach to Veeam coming through a separately controlled path; where that separation is not in place, this control is not a mitigation for this CVE and should not be recorded as one. Distinguishing test for this product: from the general user VLAN and from a standard remote-access VPN session, attempt to open TCP/8000 on a staging Veeam Backup & Replication server — anything that answers is within reach of the published technique, and poc_available is true. This bounds who can present the payload; it does not repair the deserialization sink, which only the vendor upgrade does.",
+        "evidence": "Packet: affected 'Veeam Backup & Replication server component (Veeam.Backup.MountService) deserialization of untrusted data reachable via the backend service on TCP/8000'; attack_vector 'An attacker who has gained network access (commonly via compromised VPN credentials) sends a crafted request to the Veeam.Backup.MountService on TCP/8000 ... ransomware affiliates chained this with local-account creation and rclone-based exfiltration before deploying ransomware'; UK-CAF-B4 gap 'Secure configuration baselines for backup servers didn't isolate the Veeam management service (TCP/8000, the deserialization-reachable endpoint) from general network reachability'; NIST-800-53-AC-6 gap 'Backup servers are frequently granted broad domain-trust/administrative reach; least-privilege segmentation wasn't enforced'; poc_available true; cvss 9.8; cwe_refs CWE-502.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "What failed on this CVE was not the availability of a fix but the priority the backup tier was given: the packet records the patch as 12.2 in September 2024, roughly six weeks ahead of the observed Akira and Fog exploitation, with many organizations still not having patched backup infrastructure by that campaign window. Applied to this product, the control means any Veeam Backup & Replication server at 12.1.2.172 or earlier is driven on the clock that opened with the 2024-10-17 KEV listing, on the tier an internet-facing service would get, rather than riding the change window that backup and recovery infrastructure normally sits in — which is the window that produced the six-week gap. The population to enumerate is every Veeam Backup & Replication server including the ones outside the primary datacentre inventory, since a backup server that no one lists is a backup server no one patches. On the restart question the packet is specific and easy to misread: patch_required_reboot is false, so no host reboot is recorded — but the vulnerable code runs inside the Veeam.Backup.MountService process, and live_patch_available is false, so nothing fixes that service while it keeps running. Completion is therefore measured on the build the running Veeam backup services report after the upgrade, not on the upgrade package having been staged or the installer having been launched. Priority also should not be taken from severity banding alone: the packet's exploitation window opened within days of the public technical write-up, which is shorter than any routine cycle.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-10-17, active_exploitation 'confirmed'; affected_versions '12.1.2.172 and earlier'; NIST-800-53-SI-2 gap 'The patch (12.2, September 2024) predated in-the-wild ransomware exploitation by roughly six weeks, but many organizations had not yet patched backup infrastructure by the observed Akira/Fog campaign window'; active_exploitation_notes 'Exploited at scale by Akira and Fog ransomware affiliates within days of watchTowr Labs' public technical write-up'; patch_available true, patch_required_reboot false, live_patch_available false; AU-Essential-8-Patch gap 'Rapid patching of VPN/network-reachable backup software wasn't achieved within the Essential Eight target timeframe given the compressed time-to-exploitation after PoC release.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Scope this honestly: the Veeam Backup & Replication server is not a perimeter device — the packet places the attacker inside the network first, commonly with compromised VPN credentials — but the trigger condition this control exists for is met exactly, an unauthenticated remote code execution under confirmed in-the-wild exploitation. What the packet then names is precisely what an upgrade does not undo: affiliates created local accounts on the compromised server and staged rclone-based exfiltration before deploying ransomware. Upgrading such a server from 12.1.2.172 to the fixed build closes the deserialization sink and leaves every account, credential and artifact placed through it in service. So for any Veeam server whose TCP/8000 service was reachable from a segment an attacker could occupy during the exposure window, the default response is to capture the configuration, rebuild the server from a known-good baseline rather than inherit its state through the upgrade, enumerate and remove local accounts not accounted for by change records, and rotate every credential the server held or that transited it — which on a backup server means the service accounts carrying its domain and hypervisor reach, not only the console logins. This is also the control that answers what the backup tier is actually for: a recovery mechanism run from a host the attacker owned is not a recovery mechanism, so the runbook has to be rehearsed against the case where the backup infrastructure is the compromised asset rather than the tool used to recover from compromise. Precondition: this is an incident-response requirement, not a preventive one — it applies only to servers assessed as having been reachable during the window, and it does nothing to protect a server that has not yet been upgraded.",
+        "evidence": "Packet: attack_vector 'ransomware affiliates chained this with local-account creation and rclone-based exfiltration before deploying ransomware'; active_exploitation 'confirmed'; active_exploitation_notes 'Exploited at scale by Akira and Fog ransomware affiliates ... typically chained with compromised VPN credentials to gain initial network access before exploiting the Veeam RCE for domain/backup-infrastructure compromise'; vector 'A deserialization of untrusted data vulnerability with a malicious payload can allow an unauthenticated remote code execution (RCE)'; ISO-27001-2022-A.8.13 gap 'this unauthenticated deserialization RCE makes the backup infrastructure itself the entry point that Akira/Fog crews used to destroy recovery capability'; DORA-Art10 gap 'ICT resilience testing didn't validate that backup infrastructure itself could become the ransomware entry point rather than the recovery mechanism.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.13",
+          "DORA-Art10"
+        ]
+      }
+    ]
   },
   "CVE-2024-9680": {
     "name": "Mozilla Firefox Use-After-Free Vulnerability",
@@ -42011,7 +43336,29 @@
         "adequate": false,
         "gap": "Security monitoring tuned to known-bad indicators misses a first-seen exploit chain with no prior signature."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet's affected list is not one product on one channel: the fix lands as Firefox 131.0.2, Firefox ESR 128.3.1 and Firefox ESR 115.16.1, and as Thunderbird 131.0.1, 128.3.1 and 115.16.0. A no-deferral rule scoped to the browser's release channel therefore reports an estate clean while two ESR populations and every Thunderbird install stay on pre-fix code — and ESR is precisely the channel an organisation that defers updates has standardised on, so the population most likely to be governed by an update ring is the population a release-channel-only ring misses. For this CVE the requirement is per-channel: each of the six builds is its own target, and an install counts as remediated only against the fixed build for the channel it is actually on. Thunderbird has to be enumerated as its own deployment with its own owner, because in most estates it is neither distributed nor measured by browser update policy, even though the packet places the same content-process animation-timeline defect in it. Completion is measured on the version the running process is executing rather than the version present on disk: patch_required_reboot is false, but that is a statement about the machine, not about the application — a Firefox or Thunderbird process already running when the update was staged keeps executing the pre-fix animation-timeline code until that process itself restarts, and a mail client left open for weeks is the normal case rather than the exception. Precondition: this control compresses only the window after the fixed builds existed. The packet records ESET finding the flaw already weaponised in the wild on 2024-10-08 and CISA listing it on 2024-10-15, so no update cadence covers the period before the fix shipped, and a host that rendered untrusted web content while below its channel's fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet affected: 'Mozilla Firefox and Thunderbird content-process animation-timeline handling: use-after-free reachable via crafted web content, enabling code execution in the content process.' affected_versions: Firefox < 131.0.2, Firefox ESR < 128.3.1, Firefox ESR < 115.16.1, Thunderbird < 131.0.1, Thunderbird < 128.3.1, Thunderbird < 115.16.0. cwe_refs CWE-416; cvss 9.8; rwep_score 50; poc_available false; ai_discovered false. patch_available true, live_patch_available false, live_patch_notes null, patch_required_reboot false. cisa_kev true with kev_date 2024-10-15 and active_exploitation confirmed; active_exploitation_notes record ESET discovering it in the wild on 2024-10-08. The NIST-800-53-SI-2 gap states that standard flaw-remediation SLAs assume disclosed vulnerabilities rather than a zero-day weaponised in a drive-by chain before a patch exists; the NIS2-Art21-vulnerability-handling gap states that vulnerability-handling processes built around vendor advisories lag a same-day-disclosed zero-day.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet does not describe an opportunistic browser bug. It names RomCom (Storm-0978 / Tropical Scorpius / UNC2596) running this Firefox content-process use-after-free chained to a second Windows privilege-escalation zero-day, CVE-2024-49039, so that visiting a page produced sandbox-escaped code execution and a silently installed backdoor with no user interaction — an attributed actor operating a confirmed exploit chain, which is the escalation trigger this control defines. For this CVE the operational consequence is that the trigger cannot be an alert: poc_available is false, the chain was first-seen when ESET found it, and delivery is zero-click, so there is no user report, no prompt, no download and no prior signature to fire on. The trigger has to be exposure itself — a host on a pre-fix Firefox or Thunderbird build that rendered untrusted content during the window. Hosts identified that way go onto the actor-attributed initial-access path, which includes reviewing the Windows host and not only the browser process, because the packet places the sandbox escape in a separate Windows flaw; they do not go into commodity-malware handling that closes when anti-malware reports clean, which is the specific way this response goes wrong. Precondition: this control changes the response class, it does not prevent exploitation and it evicts nothing. Reaching the fixed Firefox and Thunderbird builds removes the entry point but removes nothing the backdoor already installed on a host that was exploited, so an in-scope host is triaged on its own evidence rather than closed on its browser version.",
+        "evidence": "Packet active_exploitation_notes: 'Discovered in the wild by ESET on 2024-10-08 as the trigger for a RomCom (Storm-0978/Tropical Scorpius/UNC2596) zero-click drive-by campaign that chained this Firefox content-process UAF with Windows privilege-escalation flaw CVE-2024-49039 to escape the sandbox and drop the RomCom backdoor with no user interaction. CISA KEV flags this entry as tied to known ransomware-affiliated activity.' attack_vector: 'A crafted web page triggers a use-after-free in Firefox's Animation timeline handling inside the content process... so a mere page visit resulted in sandbox-escaped code execution and silent backdoor install.' active_exploitation confirmed; poc_available false; cisa_kev true, kev_date 2024-10-15. The ISO-27001-2022-A.8.7 gap states that malware-protection controls assume signature or heuristic coverage while this first-seen zero-click chain delivers a payload no anti-malware baseline recognizes; the UK-CAF-B4 gap states that monitoring tuned to known-bad indicators misses a first-seen exploit chain with no prior signature.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-30088": {
     "name": "Microsoft Windows Kernel TOCTOU Race Condition Vulnerability",
@@ -42400,7 +43747,29 @@
         "adequate": false,
         "gap": "Application hardening that doesn't disable/restrict the legacy MSHTML engine leaves this repeatedly-abused spoofing surface exposed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet names the sequence this CVE belongs to rather than leaving it to inference: it records that CVE-2024-43573 follows the same MSHTML-spoofing pattern as CVE-2024-38112 and CVE-2024-43461, the pair Void Banshee abused to trick victims into rendering malicious content through the deprecated MSHTML/Internet Explorer engine and deliver the Atlantida infostealer. Applied to this CVE, the control means the remediation ticket for the Windows MSHTML platform inherits that family's exploitation history instead of opening at this entry's own numbers — a 6.5 CVSS and an impact word of 'spoofing', both of which sort below the remote-code-execution items competing for the same maintenance window, while the packet simultaneously records confirmed active exploitation and a KEV listing on 2024-10-08. The second half of the requirement is the forward-looking one: an estate that treats this fix as closing the class has assumed the sequence ended at its third member, when the packet gives three members inside one year, all reached the same way and all used for the same purpose. Plan for a further member of the family rather than for a closed issue. Scope the sweep from the packet's affected_versions, which names Windows and Windows Server builds prior to the October 2024 cumulative security update — not client Windows alone. On remediation: that cumulative update is the fix, and because the packet records live_patch_available false with patch_required_reboot true, a host that has installed the update but has not yet restarted is still executing the pre-fix MSHTML platform and must be counted as exposed rather than as patched. Distinguishing test: ask the vulnerability-management program to produce the priority it assigned this CVE and the priority it assigned CVE-2024-38112 and CVE-2024-43461 — a program that scored each independently from its own severity band, and closed each on its own ticket, is the failure this control names.",
+        "evidence": "All from the packet for CVE-2024-43573: active_exploitation_notes states the flaw was patched and flagged as actively exploited in Microsoft's October 2024 Patch Tuesday, added to CISA KEV on 2024-10-08, and that it 'follows the same MSHTML-spoofing pattern as CVE-2024-38112 and CVE-2024-43461, which the Void Banshee APT abused to trick victims into rendering malicious content via the deprecated MSHTML/Internet Explorer engine to deliver the Atlantida infostealer'. cisa_kev true, kev_date 2024-10-08, active_exploitation confirmed, cvss 6.5, rwep_score 57, poc_available false. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. affected_versions: 'Windows and Windows Server builds prior to the October 2024 cumulative security update'. The NIST-800-53-SI-2 gap states patch-SLA windows for a moderate-severity spoofing bug (CVSS 6.5) do not reflect that it was actively used as a malware-delivery primitive before patching; the NIS2-Art21-vulnerability-management gap states severity-based prioritization that deprioritizes 'spoofing' classifications over 'RCE' misses that this class is repeatedly weaponized for initial-access malware delivery.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-119",
+        "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
+        "description": "The packet's affected field describes the defect precisely: an unauthenticated remote attacker who convinces a victim to open a crafted file can spoof the rendering context, tricking the user into executing attacker-controlled content. The file's own content is therefore what decides how it is presented, and the thing being deceived is the user's judgement about what the file is. Bound to this CVE, the control means the handling decision for an externally-sourced file is taken from provenance established at the ingress boundary — the mail gateway, the web download path, the untrusted file share — and applied by that boundary itself, rather than derived by the endpoint from what the file presents itself as. The untrusted-origin marking must survive the container the file is delivered in, so that a file extracted from an archive or renamed on the way still reaches the endpoint marked as externally sourced. The distinguishing test is delivery-side, not policy-side: send an externally-sourced file through each ingress path into the estate and confirm it arrives at the endpoint carrying the untrusted-origin marking, rather than confirming only that a handling policy exists for marked files. This is also the reason the control acts where signature-based malicious-code protection cannot: origin is known at the boundary, whereas the packet records that the payload here is only revealed after the deprecated MSHTML engine renders the file deceptively, which is after any signature decision has already been made. Preconditions, both load-bearing. This bounds only files that cross a boundary which applies the marking — a file arriving on removable media, or through a channel that applies none, reaches the MSHTML platform with no provenance at all, and for that path the control offers nothing. And the marking does not repair the spoofing: the platform still misrepresents the rendering context until the October 2024 cumulative security update is installed and the host restarted, which the packet records as required, with no live-patch path available. This is a holding measure for the window before that update and restart, not a substitute for them.",
+        "evidence": "All from the packet for CVE-2024-43573: affected states 'Windows MSHTML Platform: an unauthenticated remote attacker who convinces a victim to open a crafted file can spoof the rendering context, tricking the user into executing attacker-controlled content (used as a malware-delivery primitive)'. attack_vector states the attacker convinces a victim to open a crafted file that abuses the Windows MSHTML platform to spoof its true content/rendering context, following the technique family used to disguise malware droppers as benign documents. cwe_refs CWE-79. The UK-CAF-B4 gap states user-facing security awareness and file-type verification controls are defeated when the OS itself misrepresents the rendering engine/file type to the user; the NIST-800-53-SI-3 gap states malicious-code protection tuned to known file signatures misses a spoofing technique whose payload is only revealed after the deprecated MSHTML engine renders it deceptively. patch_available true, patch_required_reboot true, live_patch_available false; affected_versions names Windows and Windows Server builds prior to the October 2024 cumulative security update.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-3"
+        ]
+      }
+    ]
   },
   "CVE-2024-43572": {
     "name": "Microsoft Windows Management Console Remote Code Execution Vulnerability",
@@ -42497,7 +43866,31 @@
         "adequate": false,
         "gap": "OEM/carrier patch propagation for Android chipset firmware routinely lags the Qualcomm bulletin by months, leaving a long exploitation window for exactly this class of targeted attack."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The gaps on this entry reduce to one operational fact: the fix is in Qualcomm chipset firmware and reaches a handset only when its OEM and carrier ship it, which the SI-2 gap records as routinely lagging the Qualcomm bulletin by months and the Essential-Eight gap records as making a 48-hour patch target unenforceable. No management console can install a build the OEM has not released, so the enforceable half of this control is the access-condition half: enumerate the issued Android fleet by SoC and by the security-patch level each device actually reports, and make the October 2024 bulletin level a condition of access to mail, VPN and document stores rather than a column on a compliance dashboard. A handset below the line keeps working as a phone and loses the organisation's data — that is the only lever the operator holds while the OEM queue runs. Scope the enumeration from the affected fields rather than from one handset vendor: the packet records the scope as multiple Qualcomm chipsets' DSP Services component and gives affected versions only as the chipsets covered by the October 2024 security bulletin, with the full SoC and DSP-driver list in the vendor advisory, so a sweep keyed on a single OEM's handsets reports clean across a fleet built by another OEM on the same SoC. Distinguishing test: enrol a device whose reported patch level is below the bulletin and confirm policy actually denies it access to protected resources — an estate that surfaces the stale patch level on a report while the device keeps its mailbox has recorded the exposure rather than removed it. Preconditions: patch_required_reboot is true with no live-patch path, so a handset that downloaded the OEM update but has not restarted onto it is still executing the vulnerable DSP code and must be counted below the line; and this control does not touch the exploitation path the packet describes — a handset physically seized and unlocked with forensic tooling is outside the operator's control at the moment of attack, so the access condition limits what a returned device can reach, it does not prevent the escalation.",
+        "evidence": "Packet fields: cwe_refs CWE-416; affected records multiple Qualcomm chipsets' DSP Services component mismanaging memory maps of HLOS memory, causing a use-after-free exploitable for local privilege escalation; affected_versions 'Qualcomm chipsets covered by the October 2024 security bulletin — see vendor advisory for the full SoC/DSP-driver list'; cisa_kev true, kev_date 2024-10-08; active_exploitation confirmed; poc_available false; cvss 7.8, rwep_score 55; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. The NIST-800-53-SI-2 gap states OEM/carrier patch propagation for Android chipset firmware routinely lags the Qualcomm bulletin by months; the AU-Essential-8-Patch gap states the 48-hour guidance is unenforceable for OEM-gated chipset firmware shipping on a multi-month cadence; the ISO-27001-2022-A.8.8 gap states this DSP-Services use-after-free escalates below the MDM and OS layer inside the Qualcomm chipset.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet's exploitation notes give this entry a trigger most mobile incident plans do not carry: the escalation was chained after physical access — Cellebrite forensic-extraction tooling used to unlock seized Android devices, then this Qualcomm DSP use-after-free used to escalate privilege and install NoviSpy spyware on journalists' and activists' handsets, per the Amnesty International Security Lab reporting the packet cites. The NIS2 gap names the missing control outright: entities issuing Qualcomm-based devices to at-risk personnel had no compensating control once a device left custody. This playbook is what fills it — loss of custody (seizure, border inspection, repair, or any interval the holder cannot account for) is declared a compromise event for that handset, with its device-trust state invalidated, its certificates and enrolment revoked, every credential it held or that authenticated through it rotated, and the handset quarantined from the fleet rather than silently re-enrolled. The handset itself goes to off-device forensic examination and is replaced rather than returned on the strength of looking normal, which is also the honest answer to the malicious-code-protection gap recorded here: on-device protection does not observe DSP-level memory-map corruption, so no scan clears the handset and the trust decision has to be made off it. It is likewise the answer to the device-hardening gap, whose configuration baselines assume the attacker never holds the hardware. Preconditions: this is a pre-arranged playbook or it is nothing — the cohort it protects must be identified and briefed on what to report before a seizure, not after; and it is a response control, bounding what a compromised handset reaches once custody is lost rather than preventing an escalation that happens on hardware the operator no longer holds.",
+        "evidence": "Packet fields: active_exploitation confirmed, with active_exploitation_notes recording exploitation as part of a targeted spyware chain in which Serbian authorities used Cellebrite forensic-extraction tooling to unlock seized Android devices, then chained this Qualcomm DSP use-after-free for privilege escalation to install the 'NoviSpy' spyware against journalists and activists (Amnesty International Security Lab, Dec 2024), not flagged as ransomware; poc_available false; cisa_kev true, kev_date 2024-10-08. The NIS2-Art21-vulnerability-management gap states entities issuing Qualcomm-based devices to at-risk personnel had no compensating control once a device left custody (e.g. lawful seizure) pending OEM patch rollout; the UK-CAF-B4 gap states device configuration/hardening baselines do not address firmware-level chipset flaws exploited during physical forensic-extraction access; the NIST-800-53-SI-3 gap states mobile endpoint protection rarely inspects DSP/kernel-level memory-map handling, so this class of use-after-free is invisible to conventional malware detection.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4",
+          "NIST-800-53-SI-3"
+        ]
+      }
+    ]
   },
   "CVE-2024-45519": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Command Execution Vulnerability",
@@ -42751,7 +44144,39 @@
         "adequate": false,
         "gap": "IA-2 assumes the identification/authentication mechanism itself is sound; CVE-2024-7593 is a flaw IN the authentication algorithm, so identity verification is bypassed regardless of IA-2 policy configuration."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-131",
+        "name": "PERIMETER-VPN-GATEWAY-AUTH-BYPASS-EXPEDITED-REMEDIATION",
+        "description": "Ivanti vTM is a traffic manager rather than a VPN concentrator, but the reason this control applies is unchanged: its admin panel is the authentication enforcement point for an internet-facing appliance, and the packet describes that enforcement failing open — an incorrect implementation of the authentication algorithm that lets a remote unauthenticated attacker past the admin-panel login entirely. That is not an appliance-patch-window item. Scope from the packet's version list rather than its headline: the fix is per release branch — before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2 — so every branch in service has its own fixed build, and an estate standardised on the 22.5 or 22.6 line is not covered by knowing that 22.2R1 and 22.7R2 exist. The expedited clock runs from the 2024-09-24 KEV listing, against the 2024-10-15 CISA due date, through the reboot of each unit: live_patch_available is false and patch_required_reboot is true, so a unit that has taken its branch fix but has not restarted is still running the broken authentication path and is not remediated. Precondition on the interim half: the packet records that Ivanti's mitigation guidance shipped ahead of a full patch, so during the mitigation-only period exposure is bounded, not removed — restricting which networks can reach the admin panel limits who can send the bypass but leaves it fully exploitable from every permitted source, and that bound is unavailable wherever the admin panel is reached over the internet, which is the deployment the packet says was mass-scanned.",
+        "evidence": "Packet vector: 'Incorrect implementation of an authentication algorithm in Ivanti vTM other than versions 22.2R1 or 22.7R2 allows a remote unauthenticated attacker to bypass authentication of the admin panel' (CWE-287, CWE-303, CVSS 9.8, RWEP 79, poc_available true). affected_versions lists five branch boundaries: before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2. active_exploitation_notes: 'CISA KEV added 2024-09-24 (due 2024-10-15) after mass scanning and exploitation of internet-exposed vTM admin panels.' patch_available true, patch_required_reboot true, live_patch_available false. The NIS2-Art21-vulnerability-management gap records that 'Ivanti's mitigation guidance shipped ahead of a full patch', and the AU-Essential-8-Patch gap that 'Ivanti initially published mitigations only, leaving a window where patch promptly had no patch to apply'.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet names the post-exploitation artifact precisely, and it is one no patch can reach: attackers bypassed the admin-panel login, POSTed a crafted user-creation request, and planted a rogue administrator account they then used to log in with full admin privileges. Upgrading a vTM unit to its branch fix repairs the authentication algorithm and leaves that account in place — afterwards it authenticates legitimately, which is exactly why an identity attestation and a least-privilege review both pass cleanly on an appliance the attacker still administers, and why the account survives the reboot the fix requires. So for every vTM that was reachable from an untrusted network between public disclosure and the moment its branch fix was running, the disposition is: enumerate the appliance's administrator accounts against a known-good roster and the change record, treat any account not accounted for as confirmation rather than as an oddity, and rebuild from vendor media with the configuration reviewed rather than restored wholesale — a wholesale restore carries the planted account back onto the rebuilt unit. Rotate the administrator credentials and the secrets the unit held, since the packet has the attacker operating the panel with full admin privileges. Precondition: this is scoped to units exposed during that window, and account enumeration is confirmation, not exclusion — an attacker holding admin can delete the account they added, so a clean roster on an exposed unit is weak evidence and does not on its own downgrade the disposition. Detection must key on what the packet describes: an administrator account appearing on the appliance outside a change window and an admin-panel session for it — not on failed-login volume, which this bypass never generates because authentication is never evaluated.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker exploits a flaw in vTM's authentication algorithm to bypass the admin-panel login entirely and POST a crafted user-creation request, planting a rogue administrator account they then use to log in with full admin privileges.' active_exploitation_notes: KEV added 2024-09-24 'after mass scanning and exploitation of internet-exposed vTM admin panels to plant rogue administrator accounts within days of public disclosure. Ransomware use is unknown/unconfirmed.' patch_required_reboot true; live_patch_available false. The UK-CAF-B2 gap records that CAF B2 'assumes access decisions are enforceable once presented'.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The version data in this entry is the trap this control exists to catch. The vector states the flaw affects vTM 'other than versions 22.2R1 or 22.7R2', and affected_versions expands that into five separate branch boundaries — before 22.2R1, before 22.3R3, before 22.5R2, before 22.6R2, before 22.7R2. A scanner or attestation that compares an installed version against a single fixed version marks a unit on the 22.3, 22.5 or 22.6 branch clean because it is numerically newer than 22.2R1, while that unit has not reached its own branch's fixed build. The operational test is therefore branch-aware: for each vTM instance, resolve its release branch first, then compare against that branch's fixed build, and require the value to be read from the running appliance after its last restart — patch_required_reboot is true and live_patch_available is false, so a unit that has staged the fix without rebooting reports an installed version its running authentication code does not reflect. Precondition: this is a verification control. It finds the false-clean report; it does not shorten the exposure, and it says nothing about whether a unit that was exposed already carries an attacker-created administrator — that question is answered by enumerating the appliance's admin accounts and rebuilding, never by a version comparison.",
+        "evidence": "Packet affected_versions: 'versions before 22.2R1', 'versions before 22.3R3', 'versions before 22.5R2', 'versions before 22.6R2', 'versions before 22.7R2'. The vector states the flaw is present in vTM 'other than versions 22.2R1 or 22.7R2', and affected records it as present on 'all release branches except the already-fixed 22.2R1 and 22.7R2 lines'. patch_required_reboot true; live_patch_available false; CISA KEV 2024-09-24 with a 2024-10-15 due date. The ISO-27001-2022-A.8.8 gap records that this unauthenticated CVSS 9.8 flaw 'was mass-exploited within the CISA-mandated remediation window'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-8963": {
     "name": "Ivanti Cloud Services Appliance (CSA) Path Traversal Vulnerability",
@@ -44586,7 +46011,40 @@
         "adequate": false,
         "gap": "Versa's own guidance was to firewall management ports 4566/4570, but many operators left them internet-reachable; the boundary control was available yet not enforced, enabling the initial upload."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Versa Director is an SD-WAN orchestrator and this defect sits on a file-accepting function of its management GUI: the packet's vector places it in the 'Change Favicon' option, where a malicious file ending in .png is accepted as an image and executed, enabling web-shell deployment (CWE-434). Bound to this product the control means the Change Favicon path — and every other upload endpoint on the Director GUI — decides what a file actually is before storing it anywhere the server will execute from, rather than treating the extension as a content claim; and that no Director instance is left with its management interface reachable from a network with no operational need to reach it. The packet is specific on that second half: Versa's own guidance was to firewall management ports 4566 and 4570, many operators left them internet-reachable, and observed intrusions reached those exposed management ports before the upload. Note which half of this control is load-bearing here, because it differs from the unauthenticated cases in this class: the packet's stated precondition is a successfully authenticated Provider-Data-Center-Admin or Provider-Data-Center-System-Admin session, and tenant-level users do not hold the privilege — so the endpoint's authorization decision is present and functioning, and it is the content validation that fails. Distinguishing test: on a staging Director, upload a file whose contents are a JSP payload and whose name ends in .png through Change Favicon and confirm it is rejected on content rather than accepted on extension; then, from a general corporate segment and from an external address, attempt to reach ports 4566 and 4570 and confirm nothing answers. Precondition: the content-validation repair is what the vendor update delivers — the packet records that update as the remediation, with a reboot required and no live-patching primitive for this product — so until each Director has been taken through it and restarted, firewalling the management ports bounds who can present the upload but leaves the path fully usable to anything inside a permitted segment and to any account that legitimately administers the Director. Scope the sweep from the packet's affected list rather than from the current release train: it names builds below 22.1.4 together with 21.2.3, 22.1.2 and 22.1.3, so a 21.2.x Director is in scope alongside the 22.1.x fleet and an estate that inventories only its 22.1 line will report clean while an older orchestrator stays exposed.",
+        "evidence": "Packet facts only: CWE-434; vector describing the Change Favicon option available only to Provider-Data-Center-Admin or Provider-Data-Center-System-Admin, tenant-level users excluded, with a malicious file 'ending with .png extension to masquerade as image file' and exploitation 'possible only after a user with Provider-Data-Center-Admin or Provider-Data-Center-System-Admin has successfully authenticated and logged in'; affected naming the Change Favicon upload where a malicious .png can be 'uploaded and executed, enabling web-shell deployment'; affected_versions '< 22.1.4', '21.2.3', '22.1.2', '22.1.3'; the SC-7 gap \"Versa's own guidance was to firewall management ports 4566/4570, but many operators left them internet-reachable; the boundary control was available yet not enforced, enabling the initial upload\"; the ISO A.8.9 gap 'Configuration management did not restrict management-plane exposure of the Director appliance'; the AU-ISM-1546 gap 'The ISM control for restricting web-application file uploads was not applied to the appliance's admin UI'; the SI-2 gap 'Zero-day exploitation preceded any patch by months ... so compensating network controls were the only defense'; attack_vector 'in observed intrusions attackers reached the exposed management ports'; patch_available true, patch_required_reboot true, 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-SC-7",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-network-security",
+          "ISO-27001-2022-A.8.9",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The packet gives this Versa Director exploit exactly one precondition and it is an identity: Change Favicon is available only to Provider-Data-Center-Admin and Provider-Data-Center-System-Admin, tenant-level users do not have the privilege, and the vector states that exploitation is possible only after such a user has successfully authenticated and logged in. That makes the provider-level Director administrator the subject of this control rather than a generic application admin — the Director orchestrates the SD-WAN fabric and the packet records the victims as ISPs and MSPs, so the account that can change a favicon on this appliance is an account with reach into downstream customer networks. Applied here the control means those two roles are enumerated as a distinct privilege tier: identities separate from their holders' other admin or day-to-day accounts, phishing-resistant step-up authentication per session, access only through a privileged-access path rather than from general workstations, and just-in-time elevation so neither role is standing. That raises the cost of the only precondition the packet records, which is what mattered on this CVE specifically — the packet places exploitation as a zero-day from at least June 2024, months in which no vendor fix existed and holding a provider-level account was the entire attack path. Precondition: this bounds who can reach the upload function, it does not repair the function, and it gives nothing against an attacker already holding a valid provider-admin credential or session — the packet records the deployed web shell as stealing credentials, so on a Director that was exposed, rotating the credentials for these roles comes before any tier hardening means anything. Distinguishing test: enumerate every account holding Provider-Data-Center-Admin or Provider-Data-Center-System-Admin and confirm each is separate from its holder's ordinary identity and cannot authenticate to the Director from a general user segment — an access review recording that administrators are named and approved passes cleanly while one standing provider-admin credential remains the whole exploit precondition.",
+        "evidence": "Packet facts only: vector 'This option is only available for a user logged with Provider-Data-Center-Admin or Provider-Data-Center-System-Admin. (Tenant level users do not have this privilege) ... This is possible only after a user with Provider-Data-Center-Admin or Provider-Data-Center-System-Admin has successfully authenticated and logged in.'; attack_vector 'An attacker who has (or obtains) high-privilege Provider-Data-Center admin access uploads a Java/JSP payload disguised as a .png via the Change Favicon function ... then loaded the memory-resident VersaMem web shell to steal credentials'; active_exploitation_notes 'Exploited as a zero-day since at least June 2024 ... against ISPs and MSPs'; the UK-CAF-B4 gap 'System-security hardening for an SD-WAN orchestrator failed to lock down the privileged Change-Favicon upload path'; cisa_kev true (2024-08-23), active_exploitation confirmed, poc_available true, RWEP 75 / CVSS 7.2.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet supplies this control's trigger directly for Versa Director: exploitation as a zero-day since at least June 2024, attributed with moderate confidence to Chinese state-sponsored actors (Volt Typhoon / Bronze Silhouette), deploying a memory-resident VersaMem web shell against ISPs and MSPs to steal credentials. For a Director that was running an affected build, that combination means the response cannot be 'apply the update and close the ticket': the packet's own system-security gap states that a memory-resident web shell evades the file-integrity monitoring the hardening principle relies on, so the absence of an on-disk artifact is not evidence the appliance was clean, and the vendor update — which the packet records as requiring a reboot — restarts the appliance without ever producing a compromise assessment. For this product the escalation path should require, before the Director is declared recovered: a review of Change Favicon uploads and of provider-level admin authentications back through the packet's June 2024 exposure window; a determination of whether management ports 4566 and 4570 were reachable from untrusted networks during it; rotation of the credentials the Director holds or brokers, since credential theft is the packet's recorded objective rather than a hypothetical outcome; and, because the named victims are ISPs and MSPs, a review extending into the customer networks the Director orchestrates rather than treating the appliance as the boundary of the incident. Detection has to key on the behaviour the packet describes rather than on tooling signatures: a favicon upload and a provider-admin login are both legitimate operations that generate no error and crash nothing, so the signal is a Change Favicon upload or a provider-level admin session arriving from an unexpected source or outside a change window, followed by use of credentials the Director holds — an alert built around malware artifacts or service crashes would miss an intrusion doing exactly what this packet records. Precondition: this is a response control and it prevents nothing; it also depends on GUI upload records and management-plane authentication logs having been retained back to June 2024 and shipped off the appliance, which on a Director whose management ports were internet-reachable is precisely the telemetry least likely to be intact.",
+        "evidence": "Packet facts only: active_exploitation_notes 'Exploited as a zero-day since at least June 2024, attributed with moderate confidence to Chinese state-sponsored actors (Volt Typhoon / Bronze Silhouette) who deployed a memory-resident VersaMem web shell against ISPs and MSPs. CISA KEV ransomware status: Unknown.'; attack_vector 'in observed intrusions attackers reached the exposed management ports and then loaded the memory-resident VersaMem web shell to steal credentials'; the UK-CAF-B4 gap 'a memory-resident web shell evades file-integrity monitoring the principle relies on'; the SC-7 gap naming management ports 4566/4570 left internet-reachable; patch_available true with patch_required_reboot true and live_patch_notes 'the vendor update requires a reboot and is the remediation'; cisa_kev true with kev_date 2024-08-23 and active_exploitation confirmed.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-31196": {
     "name": "Microsoft Exchange Server Remote Code Execution Vulnerability",
@@ -44731,7 +46189,28 @@
         "adequate": false,
         "gap": "Boundary protection is routinely absent for cameras placed directly on the internet or in flat networks; the auth bypass reaches the device's login service with no perimeter mediation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet carries both halves that this control exists to separate. A vendor fix exists and the entry records that there is no live-patching primitive for this product, that the vendor update requires a reboot, and that it is the remediation — while the A.8.8 and SI-2 gaps state that a large part of the affected fleet is end-of-support with no remediation path at all. So the first requirement is a per-unit inventory naming every Dahua IP camera, NVR and related product in service, and every OEM-rebranded Dahua-based device the packet's affected_versions call out, each recorded with its model, its running firmware baseline, and a supported-or-end-of-support answer obtained from the Dahua PSIRT advisory for that exact model rather than assumed in either direction — the packet gives affected versions only as firmware baselines prior to the vendor's 2021 fix, with per-model builds left to that advisory. Units whose model has fixed firmware are remediation items on the clock that opened with the 2024-08-21 KEV listing, and because the update requires a reboot with no live-patch path, a unit that has taken firmware but has not rebooted onto it is still running the bypassable login path and counts as exposed. Units whose model has no fixed firmware — the end-of-support population the A.8.8 gap names, which on an OEM rebrand may mean no vendor is shipping firmware at all — cannot be patched and belong on a dated replacement schedule; a risk acceptance with no removal date leaves a device with a public PoC, confirmed exploitation and 99.9th-percentile EPSS in service indefinitely, exposed not only to this bypass but to everything found in that firmware line since. And because exploitation is confirmed and the packet records recruitment into IoT botnets, a unit that was internet-exposed before remediation is not closed by firmware alone: its configuration and administrative credential must be rebuilt from a known-good baseline rather than inherited through the update, and credentials that transited it rotated.",
+        "evidence": "Packet: affected names Dahua IP cameras, NVRs and related products; affected_versions name multiple Dahua IPC/SD/NVR firmware baselines prior to the vendor's 2021 fix (per-model builds per the Dahua PSIRT advisory) and numerous OEM-rebranded Dahua-based devices. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' CISA KEV 2024-08-21, active_exploitation confirmed, poc_available true, RWEP 73, CVSS 9.8; active_exploitation_notes record broad exploitation of internet-exposed Dahua cameras and NVRs including recruitment into IoT botnets, with EPSS at the 99.9th percentile. The ISO-27001-2022-A.8.8 gap states there is no remediation path for end-of-support Dahua/OEM camera firmware and that the control cannot compel operators to patch or retire; the NIST-800-53-SI-2 gap states many affected Dahua/OEM cameras are end-of-support so the patch SLA effectively never closes on a large installed base.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For the Dahua units that do have fixed firmware, this is the clock the SI-2 gap says never closes on this fleet: firmware flashed and the device rebooted onto it, measured from the 2024-08-21 KEV listing rather than from a camera-refresh or building-maintenance cycle, with completion recorded per unit against the running firmware baseline. Two limits have to be stated rather than assumed for this product. The packet registers no live-patching primitive, so there is no mitigation that lands ahead of the reboot — a unit scheduled for firmware is exposed until it restarts. And for units with no fixed firmware, the SLA's compensating-control branch is the only branch available, which here means removing the device from any internet-reachable path — a holding measure with a hard precondition: the bypass sits inside the login process itself, triggered by a packet that names the loopback device as the client, so any caller that can open a session to the device still reaches it. Taking a camera off a port-forward or UPnP mapping does nothing about a caller already on the network segment that reaches it, so those units belong on the replacement schedule with a date, not on an indefinite compensating-control record.",
+        "evidence": "Packet: CISA KEV 2024-08-21, active_exploitation confirmed, EPSS at the 99.9th percentile, poc_available true, RWEP 73, CVSS 9.8. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes state the vendor update requires a reboot and is the remediation. vector and affected describe the login process being bypassed by constructing a packet that specifies the loopback device as the client, skipping identity authentication. The NIST-800-53-SI-2 gap states firmware flaw-remediation is chronically slow for IoT fleets and that many affected devices are end-of-support, so the patch SLA effectively never closes.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-33044": {
     "name": "Dahua IP Camera Authentication Bypass Vulnerability (CVE-2021-33044)",
@@ -44768,7 +46247,31 @@
         "adequate": false,
         "gap": "The authentication mechanism itself is bypassable via the NetKeyboard packet type, so an identification/authentication control that assumes credentials are checked provides no protection."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The remediation for this entry is the Dahua firmware fix, and the packet is explicit that it cannot be applied live: live_patch_available is false and live_patch_notes record that the vendor update requires a reboot and is the remediation. A camera or NVR that has received firmware but has not restarted onto it is still running the bypassable login path and is counted as exposed, not as patched — on camera fleets that restart is the step most often skipped, because taking it drops recording and live view, and a deferral recorded as patched is the specific way this remediation goes wrong. Scope comes from the affected field rather than the CVE's headline product: Dahua IP cameras, NVRs and OEM-rebranded devices are all in scope, so an inventory keyed on the vendor name reports clean across an estate standardised on a rebrand, and the recorders are as much in scope as the cameras they hold. The fixed level is per-model — the packet gives affected versions as the builds prior to the fixes listed in Dahua advisory 957 — so each model, and each rebranded equivalent, is checked against the fixed build for that model rather than against one estate-wide firmware number, and for a rebranded unit the fixed build has to be obtained from whoever ships that unit's firmware rather than assumed from the Dahua model it derives from. The clock is the 2024-08-21 KEV listing, and the packet's exposure note is why this cannot ride the normal cadence: EPSS near 0.999 with mass scanning and botnet exploitation of internet-exposed units, against a flaw whose fix has been available since well before the listing. The patch requirement is also the only closure for the authentication side: an alternate login path built into the firmware is not something gateway or authentication hardening guidance can compensate for, so reaching the fixed build is the control, not a supplement to it.",
+        "evidence": "live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' patch_required_reboot true; live_patch_available false; patch_available true. affected: 'Dahua IP cameras, NVRs and OEM-rebranded devices — authentication bypass during login when the client specifies the NetKeyboard type argument.' affected_versions: 'Multiple Dahua camera/NVR firmware builds prior to the fixes listed in Dahua advisory 957.' CISA KEV listing 2024-08-21; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 77. active_exploitation_notes: 'EPSS ~0.999 reflects mass scanning and botnet exploitation of internet-exposed Dahua cameras and OEM-rebranded devices.' The packet's ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management often excludes long-lived IP-camera firmware from the patch scope, so the flaw persists for years.' The AU-ISM-1546 gap: 'Gateway/authentication hardening guidance does not account for firmware that ships an alternate auth path bypassing the primary check.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The login handler is where a Dahua camera or NVR makes its authentication decision, and this CVE is that decision failing open: the packet has an attacker constructing a login packet that specifies the NetKeyboard type argument, which bypasses the credential check and returns an authenticated session to the device. Bound to this product the control means the device's functions do not inherit their authorization from that single login verdict, and — the half an operator holds today — that the camera and NVR login and management surfaces answer only from the segment that operates them, because a caller who cannot present the crafted packet cannot use the bypass. This is the specific reason the identity controls cited against this entry give nothing: no credential is ever presented, so no password policy, rotation schedule or account model is consulted, and an attestation that every camera carries a unique administrator password passes cleanly while the whole fleet is open. It also means the cameras, the recorders and the rebranded units belong in an identity-endpoint inventory rather than being carried as fixtures, since the packet's framing is that a bypassed camera becomes a foothold onto whatever network it shares. Distinguishing test: from a general corporate VLAN and from an external address, attempt to open a session to a staging camera and to a staging NVR; anything that answers is within reach of the published bypass, and 'the cameras are on the internal network' is a statement about topology rather than a demonstration that the login surface is unreachable from untrusted segments. Precondition: segmentation bounds who can send the packet, it does not repair the login path. Any host already inside the permitted segment — the video-management server that legitimately talks to the fleet, an operator workstation, a maintenance contractor's laptop — still reaches it, and the lever is unavailable entirely for a unit deliberately published for remote viewing. Those units stay exposed until the firmware fix and its reboot land, and because exploitation is confirmed and mass-scale, a unit that was internet-reachable while unpatched needs its configuration and credentials rebuilt from a known-good baseline rather than inherited through the firmware update.",
+        "evidence": "vector: 'The identity authentication bypass vulnerability found in some Dahua products during the login process. Attackers can bypass device identity authentication by constructing malicious data packets.' affected: 'authentication bypass during login when the client specifies the NetKeyboard type argument', covering 'Dahua IP cameras, NVRs and OEM-rebranded devices'. attack_vector: 'An unauthenticated remote attacker sends a crafted login packet specifying the NetKeyboard authentication type, which bypasses the credential check and grants an authenticated session to the camera or NVR.' The packet's NIST-800-53-IA-2 gap: 'The authentication mechanism itself is bypassable via the NetKeyboard packet type, so an identification/authentication control that assumes credentials are checked provides no protection.' The NIST-800-53-SC-7 gap: 'IoT cameras are routinely exposed directly to the internet; boundary controls are frequently absent for these devices, leaving the preauth bypass reachable at scale.' The NIS2-Art21-network-security gap: 'Network-security duties rarely segment CCTV/IoT VLANs from the corporate network, so a bypassed camera becomes a foothold.' The UK-CAF-B2 gap: the bypass 'defeats it across an entire fleet of internet-exposed Dahua cameras that B2 controls seldom inventory as identity endpoints.' active_exploitation confirmed; patch_available true with a reboot required per live_patch_notes.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2024-23897": {
     "name": "Jenkins Command Line Interface (CLI) Path Traversal Vulnerability",
@@ -44879,7 +46382,31 @@
         "adequate": false,
         "gap": "Staged monthly Windows patching leaves endpoints exposed for weeks after the KEV add, during which the SYSTEM-grade LPE is already being used post-foothold."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Power Dependency Coordinator (pdc.sys) kernel component and describes a local authenticated attacker driving a use-after-free from standard user to SYSTEM — the account is already legitimate, so no account model is being abused; a kernel privilege boundary is failing. For this CVE the control means the August 2024 Windows security update is driven across every affected host on the KEV clock that opened 2024-08-13 rather than riding the staged monthly ring rollout the packet records as leaving endpoints exposed for weeks, with completion measured by each host's installed build against the fixed build for its SKU. Enumerate the whole population the packet names — Windows 10 and Windows 11 clients alongside Windows Server 2016, 2019 and 2022 — and do not let the server fleet go first: this is a post-foothold escalation step, so the machines where an attacker lands initially are ordinary user workstations, and an estate that patches servers first leaves the primitive available exactly where initial access happens. The packet records patch_required_reboot true, no live-patch path, and that the vendor update requires a reboot and is the remediation, so a host that has installed the update but not rebooted is still executing the vulnerable driver and must be counted as exposed; measure on the running build rather than on 'installed' in the management console. What is not available here matters as much: the packet records this as an in-box driver that system-security hardening cannot remove or disable, so unlike an optional service or a third-party signed driver there is no disable, unload or blocklist interim measure — the update is the removal, which is why compressing its rollout is the whole control.",
+        "evidence": "Packet: CISA KEV-listed 2024-08-13, active_exploitation confirmed, CVSS 7.8, RWEP 61, poc_available false, CWE-416. affected: Windows Power Dependency Coordinator (pdc.sys) kernel component, local authenticated attacker exploits a use-after-free to elevate from standard user to SYSTEM, fixed in the August 2024 security updates across supported Windows client and server builds. affected_versions: Windows 10 (all supported builds pre-Aug 2024 update), Windows 11 (pre-Aug 2024 update), Windows Server 2016/2019/2022 (pre-Aug 2024 update). patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: no live-patching primitive for this product, the vendor update requires a reboot and is the remediation. NIST-800-53-SI-2 gap: monthly cadence plus staged enterprise ring rollout means the August 2024 fix reaches many endpoints weeks after the KEV add while the LPE is already weaponized. UK-CAF-B4 gap: an in-box driver B4 hardening cannot remove or disable. active_exploitation_notes: used as a post-exploitation escalation step; ransomware use unconfirmed but SYSTEM-grade LPEs are common in ransomware and hands-on-keyboard intrusions.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "pdc.sys is a Windows kernel driver, so for this CVE the control is Windows privilege-transition telemetry rather than the auditd/eBPF form it takes on Linux hosts — and the packet describes the behaviour precisely enough to key on it. The exploit is a local authenticated user's process corrupting kernel memory through the Power Dependency Coordinator and emerging as SYSTEM, run after an initial foothold. The rule therefore keys on that transition in that direction: a process running under a standard user account, inside an interactive user session, that acquires a SYSTEM-integrity token or spawns a SYSTEM-context child without having passed through a legitimate elevation path — no service-control-manager start, no scheduled task registered to run as SYSTEM, no consent prompt, no management-agent installer. Pair it with the driver-interaction half the packet names, a non-elevated user process opening a handle to the Power Dependency Coordinator driver, which ordinary user code has no reason to do; either signal alone is noisy, and it is the pairing inside a short window that separates this exploit from a benign elevation. Note what will not see it, because this is exactly where the anomaly-detection gap bites: the packet records no public PoC, so there is no tool signature to match; nothing is written to disk for a file-integrity monitor to catch; and the component being exercised is a signed in-box Microsoft driver, so driver-load and code-signing telemetry stay clean by construction — a rule keyed on process crashes, unsigned drivers or named exploit tooling would miss an attempt behaving exactly as the packet describes. Preconditions: this needs privilege-transition telemetry already collected and shipped off-host before the attempt, and a rule authored afterwards against telemetry nobody was collecting produces nothing. And detection prevents nothing — it bounds dwell time during the weeks the staged rollout takes; a host on which SYSTEM was reached is a rebuild-and-credential-rotation case, not one closed by the August 2024 update landing later.",
+        "evidence": "Packet SOC2-CC7-anomaly-detection gap: anomaly-detection controls rarely flag a same-host token-elevation from a legitimate driver interaction, so the escalation is easily missed without EDR tuned to privilege-transition events. attack_vector: a local, authenticated attacker triggers a use-after-free in the Windows Power Dependency Coordinator driver to corrupt kernel memory and elevate to SYSTEM, chaining it after an initial foothold to gain full host control. ISO-27001-2022-A.8.8 gap describes local exploitation of a signed in-box driver between assessment cycles. poc_available false. NIST-800-53-SI-2 gap records the weeks-long staged-rollout exposure window. active_exploitation confirmed, KEV 2024-08-13.",
+        "gap_closes": [
+          "SOC2-CC7-anomaly-detection"
+        ]
+      }
+    ]
   },
   "CVE-2024-38106": {
     "name": "Microsoft Windows Kernel Privilege Escalation Vulnerability",
@@ -44976,7 +46503,39 @@
         "adequate": false,
         "gap": "Signature-based malicious-code protection is precisely what FudModule disables post-escalation, so it cannot be relied on to catch this chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet's affected list is what scopes this sweep and it is broad — Windows 10, Windows 11 and Windows Server 2016, 2019 and 2022, each in its pre-August-2024-patch state — and the vector names no optional role or feature that would narrow it, so there is no 'does this host run the component' question to filter on. Treating a local privilege escalation as a workstation concern therefore leaves the entire server population the packet names unremediated, on machines where reaching SYSTEM is worth more to the attacker than it is on a laptop. The requirement is that the August 2024 Windows update carrying the afd.sys fix is driven across every host in that list on the clock that opened with the 2024-08-13 KEV listing rather than folded into the next monthly rollup, with completion measured per host against the build the machine is actually running for its SKU rather than against 'approved', 'downloaded' or 'deployed' in the management console. The packet records no live-patching primitive and states the vendor update requires a reboot and is the remediation, so a host that has installed the update and not rebooted is still executing the vulnerable driver and must be counted as exposed; on servers that pending reboot is the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Priority has to follow the packet rather than the CVSS band: the entry carries a 7.8 CVSS but an RWEP of 81, a public proof of concept, and exploitation as a zero-day by Lazarus Group to reach SYSTEM and install the FudModule rootkit — the 7.8 is exactly what drops this below an internet-facing fast lane and onto the routine cadence, which is the gap the cited patch and technical-vulnerability controls describe. The control's second half is load-bearing here too: the attacker is already a local low-privileged process, so tightening account privilege does not contain the escalation.",
+        "evidence": "Packet name: 'Microsoft Windows Ancillary Function Driver for WinSock Privilege Escalation Vulnerability'; CWE-416; affected: 'Microsoft Windows Ancillary Function Driver for WinSock (afd.sys) contains a use-after-free that a local attacker exploits to elevate privileges to SYSTEM.' affected_versions: 'Windows 10 (pre-August 2024 patch)', 'Windows 11 (pre-August 2024 patch)', 'Windows Server 2016/2019/2022 (pre-August 2024 patch)'. cisa_kev true, kev_date 2024-08-13, active_exploitation 'confirmed'; cvss 7.8; rwep_score 81; poc_available true. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' active_exploitation_notes: 'Exploited as a zero-day by North Korea's Lazarus Group to escalate to SYSTEM and install the FudModule rootkit'. The NIST-800-53-SI-2 gap records that 'kernel-driver patching requires a reboot cycle that lags an in-the-wild zero-day already chained to a rootkit installer'; the AU-Essential-8-Patch gap records that 'OS-patch timelines for driver updates lag the observed zero-day exploitation by a nation-state actor'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-079",
+        "name": "AV-EDR-AVAILABILITY-MONITORING",
+        "description": "The packet says what the attacker does in the seconds after the escalation: installs the FudModule rootkit to disable security monitoring — and the entry's own gap analysis adds that signature-based malicious-code protection is precisely what FudModule disables, and that the security-monitoring control assumes an intact telemetry pipeline the post-escalation rootkit tears down. A detection built on what that pipeline reports is therefore built on the thing being switched off, so the rule has to key on the pipeline going dark. Applied to this chain: an endpoint that stops reporting EDR or anti-malware telemetry, or whose protection service stops, restarts abnormally, or has its protections turned off, is itself a security event — raised by the off-host management console or SIEM that notices the absence, never by a rule running on the endpoint, since an on-host rule sits inside exactly what the packet says the rootkit disables. Pair that silence with the escalation the packet describes on the same host in the preceding interval: a local low-privileged process obtaining SYSTEM. The pairing is what makes it a finding — silence alone has ordinary causes (a shut-down machine, a laptop off the network, an agent upgrade), and an isolated SYSTEM transition arrives without context. Note what this deliberately does not key on, because those are the rules that would be written by reflex and would miss this: the packet records no process crash, no ransomware association and no named tooling artifact for the escalation itself, so detections anchored on crash telemetry, ransomware indicators or exploit-tool signatures will not fire on an intrusion that behaves exactly as the packet describes. Precondition: this needs the off-host control plane to be already tracking agent check-in state, with a staleness threshold short enough to matter, before the attempt. And it is detection only — by the time the telemetry stops, SYSTEM has already been obtained and the rootkit is loaded; the rule bounds dwell time, it does not prevent the escalation or remove what is resident.",
+        "evidence": "Packet attack_vector: 'A local, low-privileged process abuses a use-after-free in afd.sys (the WinSock Ancillary Function Driver) to corrupt kernel memory and elevate to SYSTEM, after which Lazarus installs the FudModule rootkit to disable security monitoring.' The NIST-800-53-SI-3 gap: 'Signature-based malicious-code protection is precisely what FudModule disables post-escalation, so it cannot be relied on to catch this chain.' The UK-CAF-C1 gap: 'CAF security monitoring is the exact control FudModule neutralises after this AFD.sys use-after-free grants SYSTEM; C1 detection assumes an intact telemetry pipeline that the post-escalation rootkit tears down.' The NIS2-Art21-incident-handling gap records that incident-handling controls 'trigger only after the rootkit blinds monitoring, leaving a detection gap during the escalation window.' active_exploitation_notes record 'no ransomware association reported'; the packet describes no crash and names no exploit tooling for the escalation.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "UK-CAF-C1"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "This entry is the case the control exists for — the packet attributes the zero-day exploitation to North Korea's Lazarus Group and records the payload as the FudModule rootkit — and the escalation path matters precisely because standard endpoint IR treats a rootkit as a commodity infection to be cleaned and closed. For this chain the requirement is that a confirmed SYSTEM escalation on a host in the populations the packet names — personnel working on cryptocurrency and aerospace — routes to the nation-state path rather than to routine endpoint remediation: the host is preserved for forensic acquisition instead of being reimaged first, every credential and key reachable from a SYSTEM context on it is treated as taken rather than as potentially exposed, and the review extends to what that identity could reach rather than terminating at the machine. The trigger cannot be the attribution: the packet records this as a zero-day discovered in the wild by Gen Digital, so the Lazarus and FudModule naming became available only after the exploitation, and a runbook waiting for a named actor never fires during the window it exists to cover. Trigger on the observable instead — a local low-privileged process obtaining SYSTEM, followed by security monitoring going down on that same host — and de-escalate afterwards if triage clears it. Note also that the packet records no ransomware association for this activity, so an escalation ladder anchored on ransomware indicators has nothing to trip and the intrusion is handled at commodity severity throughout. Precondition and limit: this governs the response only. It does not prevent the escalation, which needs the vendor update and the reboot the packet records, and preserving a host for forensics is compatible with isolating it but not with leaving it in service.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited as a zero-day by North Korea's Lazarus Group to escalate to SYSTEM and install the FudModule rootkit, targeting cryptocurrency and aerospace personnel. Discovered in-the-wild by Gen Digital; no ransomware association reported.' attack_vector: a local low-privileged process elevates to SYSTEM via the afd.sys use-after-free, 'after which Lazarus installs the FudModule rootkit to disable security monitoring.' The NIS2-Art21-incident-handling gap: 'Incident-handling controls trigger only after the rootkit blinds monitoring, leaving a detection gap during the escalation window.' cisa_kev true, kev_date 2024-08-13, active_exploitation 'confirmed'; rwep_score 81; poc_available true; patch_available true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2024-38213": {
     "name": "Microsoft Windows SmartScreen Security Feature Bypass Vulnerability",
@@ -45233,7 +46792,39 @@
         "adequate": false,
         "gap": "Kernel flaw remediation on mobile/embedded fleets depends on OEM backport cadence; the observed targeted exploitation preceded broad OTA availability, outrunning any patch SLA."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is two remediation populations, and the packet names both: `affected` puts the use-after-free in Linux kernel networking — __dst_negative_advice() clearing sk->dst_cache out of RCU order — and states it impacts Linux and Android (Pixel and other) kernels, while `affected_versions` gives the stable backports 5.10.218, 5.15.160, 6.1.94, 6.6.34 and 6.9.5 alongside 'Android kernels prior to the September 2024 Android Security Bulletin patch level'. Scoping the sweep to the entry's headline product name would leave every Linux server, container host and workstation in the estate reporting clean while running a kernel carrying the same defect, so the control binds to both: each Linux host taken to the backport for its own stable series, each Android device to the September 2024 bulletin patch level or later, both on the clock that opened with the 2024-08-07 KEV listing rather than on the next kernel maintenance window. Completion is measured on the kernel the machine is actually executing. patch_required_reboot is true and live_patch_available is false, with live_patch_notes recording that the vendor update requires a reboot and is the remediation — so a host whose package manager has installed the fixed kernel but has not rebooted onto it is still executing the vulnerable code and counts as exposed, and the running-kernel version, not the installed-package version, is the evidence. That distinction is where this remediation usually goes wrong: on the production hosts least willing to take an unplanned reboot, the update lands and the reboot is deferred, and the deferral is recorded as patched. Because there is no live-patch path, there is no interim state that removes the flaw from a host that cannot yet reboot — only the compensating controls on this entry.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-08-07, active_exploitation 'confirmed'; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.'; affected 'Linux kernel networking (__dst_negative_advice) clears sk->dst_cache in the wrong RCU order, producing a use-after-free reachable via UDP sockets; impacts Linux and Android (Pixel and other) kernels prior to the fix'; affected_versions lists 'stable backports: 5.10.218, 5.15.160, 6.1.94, 6.6.34, 6.9.5' and 'Android kernels prior to the September 2024 Android Security Bulletin patch level'; NIST-800-53-SI-2 gap records that observed targeted exploitation preceded broad OTA availability.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The Android half of this entry is the half the operator does not control: the packet's flaw-remediation gap records that kernel remediation on mobile fleets depends on OEM backport cadence and that the observed targeted exploitation preceded broad OTA availability, so for any device whose OEM has not yet shipped the September 2024 Android Security Bulletin patch level there is no patch action available at all. On that population the fixed patch level has to function as an access condition rather than a compliance row — organizational mail, VPN and document access denied to any enrolled Android device reporting a security patch level below September 2024, enforced by the access policy itself. The distinguishing test is to enrol a device pinned below that level and confirm it is actually refused the protected resources; an estate that surfaces the stale patch level on a dashboard while the device keeps its access has recorded the exposure rather than bounded it. Two preconditions, both load-bearing here. First, this bounds what organizational data an exposed handset can reach; it does not remove the use-after-free from the device, and the device's own contents stay exposed to a local escalation. Second, the packet records limited, targeted exploitation on Android confirmed by Google's Threat Analysis Group — a device that sat below the patch level during that window and belongs to the population such campaigns target is an incident item, not a patch item, because an access condition does not evict an attacker who already reached kernel context. The patch level counts only once the update has been applied and the device restarted onto it, since patch_required_reboot is true.",
+        "evidence": "Packet: affected_versions 'Android kernels prior to the September 2024 Android Security Bulletin patch level'; affected states impact on 'Linux and Android (Pixel and other) kernels prior to the fix'; active_exploitation_notes 'Reported by Clement Lecigne of Google Threat Analysis Group and flagged by Google as under limited, targeted exploitation on Android'; NIST-800-53-SI-2 gap 'Kernel flaw remediation on mobile/embedded fleets depends on OEM backport cadence; the observed targeted exploitation preceded broad OTA availability'; AU-Essential-8-Patch gap 'Essential Eight OS-patching maturity is defined for managed desktops/servers and under-covers fragmented Android OEM patch delivery'; UK-CAF-B4 gap 'System-hardening baselines are written for managed desktops and servers and don't reach fragmented Android OEM kernels'; patch_required_reboot true.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "The packet describes the exploitation precisely enough to key on it, and precisely enough to rule out the signals that would otherwise be reached for. A local attacker manipulates UDP-socket destination-cache state so that __dst_negative_advice() releases a dst entry out of RCU order, then grooms the resulting use-after-free into kernel memory corruption and privilege escalation. On Linux hosts the rule therefore keys on that shape: an unprivileged local process driving repeated UDP socket create/connect/send and teardown against destinations that provoke route-cache negative advice — the repetition is inherent, because the operation being exploited is a race that has to be re-attempted until the timing lands — paired with the outcome the packet names, a privilege transition to kernel or root context in a process lineage that never executed a setuid binary. Both halves are required: UDP socket churn alone is ordinary on a networked host, and a credential change alone arrives with no context; it is the pairing inside a short window that separates this from either. What will not see it: poc_available is false, so there is no public exploit binary or tool name for a signature to match; nothing is compiled, no module is loaded and no on-disk file changes, so file-integrity monitoring has no artifact; and a rule that alerts on kernel panics assumes a failed attempt rather than the successful grooming the packet describes. Preconditions: this needs host audit or eBPF telemetry that was already being collected and shipped off-host before the attempt, which on shared multi-user Linux hosts is exactly where it is least often enabled, and it is generally unavailable to the operator on the Android devices in scope — which is why that population depends on the access-condition control on this entry instead. Detection does not restore the privilege boundary this flaw defeats and does not undo an escalation; it bounds the exposure to alert-and-response time in the interval before the fixed kernel and its reboot land.",
+        "evidence": "Packet: attack_vector 'A local attacker manipulates UDP-socket destination-cache state so that __dst_negative_advice() releases a dst entry out of RCU order, causing a use-after-free that is groomed into kernel memory corruption and privilege escalation'; vector text 'RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst)' and 'This old bug became visible after the blamed commit, using UDP sockets'; cwe_refs CWE-416; poc_available false; active_exploitation 'confirmed'; NIST-800-53-AC-6 gap 'Least-privilege controls do not prevent a local UAF that escalates to kernel context, since the flaw itself defeats the privilege boundary.'",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2018-0824": {
     "name": "Microsoft COM for Windows Deserialization of Untrusted Data Vulnerability",
@@ -46104,7 +47695,39 @@
         "adequate": false,
         "gap": "Security monitoring focused on network indicators misses client-side script execution within the webmail DOM, delaying detection of mailbox exfiltration."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The distinguishing fact on this entry is the interval. The packet records the fix in Roundcube Webmail 1.3.12 and 1.4.5 and a KEV listing dated 2024-06-26, so the KEV clock opens on a fix that has been available for years — which makes the work here discovery rather than scheduling. The packet's own flaw-remediation gap names it: self-hosted Roundcube instances go long-unpatched, and the flaw reached KEV four years after the fix shipped. So the SLA's first deliverable is an enumeration of every Roundcube deployment the organisation's users can reach, including the instances that arrived with a hosting package, run on a departmental or project server, or survived a mail migration as a fallback interface — an SLA measured against a list that contains only the sanctioned webmail host will report complete while the exposed instance is one nobody owns. Record the running version of each against 1.3.12 or 1.4.5 and later, and measure completion on the version the instance actually serves to a browser rather than the version in a package manifest or a change ticket; the packet registers no live-patch path, so an instance whose files were replaced while the old code is still being served has not been remediated. Because the packet records confirmed exploitation with a public PoC, and describes the outcome as mail, contacts and session tokens taken from the authenticated session, an instance found below the fixed version is an incident question as well as a patch item: updating the code closes the preview path but tells you nothing about what was read from the mailboxes while it was open, so the sessions and credentials that instance carried need invalidating and rotating rather than being closed on the version number.",
+        "evidence": "The packet's vector records an issue in Roundcube Webmail before 1.3.12 and 1.4.x before 1.4.5, with XSS via a malicious XML attachment because text/xml is among the allowed types for a preview; affected_versions lists < 1.3.12 and 1.4.0 through 1.4.4. cisa_kev true with kev_date 2024-06-26, active_exploitation confirmed, poc_available true, CVSS 6.1, RWEP 64. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes stating there is no live-patching primitive for this product and the vendor update is the remediation. The cited flaw-remediation gap states the fix shipped in 2020 but the flaw reached KEV in 2024, showing self-hosted Roundcube instances go long-unpatched; the cited technical-vulnerability-management gap states a 'medium' XSS is often deprioritized but in webmail yields full mailbox compromise for high-value diplomatic targets. attack_vector states attacker JavaScript runs in the authenticated webmail session and can steal mail, contacts and session tokens; active_exploitation_notes records Roundcube XSS flaws being chained by espionage actors against government and diplomatic targets, with KEV ransomware status Unknown.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Applied to Roundcube, this control requires the webmail tier's per-request access logs — the web-server request log for the webmail vhost plus the application's own action log, not the login events — to be forwarded to a SIEM off the webmail host, with retention long enough to cover an instance discovered years after the fix shipped. The reason is the exact shape of this exploit: the packet has attacker JavaScript executing when the victim previews a text/xml attachment, running inside the victim's own already-authenticated session. So the requests that steal the mailbox are indistinguishable at the authentication layer from the victim working — one successful login is recorded, and everything after it belongs to a valid session. What an exploit doing exactly what the packet describes emits is a request stream: a fetch of an attachment part whose declared type is text/xml as the message is previewed, followed within that same session by a run of message-fetch, contact and attachment requests at a pace and breadth that does not match a person reading mail, which is the packet's own stated outcome of mail, contacts and session tokens taken from the session. That pairing — the preview of an XML part, then bulk reads in the same session — is the rule; either half alone is ordinary webmail traffic. Note what will not see it: no file lands on the host and no process is spawned, so signature-based endpoint tooling has no artifact to match; the traffic is TLS to the organisation's own webmail from the user's normal client, so network-indicator monitoring sees nothing anomalous, which is precisely the security-monitoring gap the packet records; and alerting on failed logins or on new authentications would miss an attempt that behaves exactly as described. Precondition: per-request logging has to be enabled and shipped off-host before the attempt. A deployment that logs only authentication, or that keeps its request log locally on the very webmail server the attacker's script is operating inside, produces nothing for an after-the-fact rule to run against. And detection does not prevent the theft — the script runs the moment the message is previewed — so this bounds the exposure to alert-and-response time (session invalidation, credential rotation, mailbox review) during the period before the 1.3.12 / 1.4.5 update removes the preview path.",
+        "evidence": "The packet's attack_vector states an attacker emails a crafted text/xml attachment and that when the victim previews it in a vulnerable Roundcube version attacker JavaScript runs in the authenticated webmail session and can steal mail, contacts and session tokens; the vector records that text/xml is among the allowed types for a preview. The cited security-monitoring gap states that monitoring focused on network indicators misses client-side script execution within the webmail DOM, delaying detection of mailbox exfiltration; the cited network-security gap states that network-security measures do not inspect authenticated in-app script execution, so an XSS running inside the trusted webmail session evades perimeter controls. active_exploitation is confirmed with poc_available true, kev_date 2024-06-26, and active_exploitation_notes recording Roundcube XSS being chained by espionage actors to steal mail and session data from government and diplomatic targets. patch_available true with the fixed releases recorded as 1.3.12 and 1.4.5, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-119",
+        "name": "ARCHIVE-CONTENT-TYPE-PROVENANCE",
+        "description": "The decision this flaw turns on is a rendering decision taken from attacker-supplied metadata: the packet states plainly that text/xml is among the allowed types for a preview, so the attachment's declared content type is what selects the inline-preview path that carries the payload, and the sender controls that value. Applied to this product, the control requires that whether an email attachment is treated as inert or as active content be established outside the message — by the mail boundary inspecting what the attachment actually is — rather than inherited from the type the sender declared, and that the resulting classification survive the container the attachment arrives in, so an XML document nested in an archive or renamed is still handled as active content. The mail boundary is where this is enforceable, because it is the only point that sees the message before it is stored in a mailbox where the victim can preview it. The two gaps this closes are exactly that omission: the packet records that malicious-code and attachment inspection typically does not treat a benign-looking XML attachment as active content, and that Essential-Eight user-application hardening does not treat a text/xml email attachment as active content — so both attest clean while the script-bearing preview reaches the reading pane. Distinguishing test: send an XML attachment carrying a script payload through each mail ingress path to a test mailbox, once plain and once inside an archive, and confirm it arrives classified as active content — quarantined, stripped, or marked so the client will not inline it — rather than confirming only that an attachment policy exists in the console. Precondition, and it is the load-bearing one: this bounds delivery, it does not repair the sanitizer. A gateway rule applied today does nothing about messages already sitting in mailboxes, and this flaw fires when a stored message is previewed, so with confirmed exploitation and a public PoC on the record, mailboxes served by a vulnerable instance need reviewing rather than being closed on the new rule. It also does not cover mail arriving by a path the gateway does not front. Only the update to 1.3.12 or 1.4.5 removes the preview path itself.",
+        "evidence": "The packet's vector states the XSS occurs via a malicious XML attachment because text/xml is among the allowed types for a preview, in Roundcube Webmail before 1.3.12 and 1.4.x before 1.4.5. The cited malicious-code-protection gap states that malicious-code / attachment inspection typically does not treat a benign-looking XML attachment as active content, so the script-bearing preview slips past content filtering; the cited user-application-hardening gap states Essential-Eight hardening does not treat a text/xml email attachment as active content, so the script-bearing XML previews in Roundcube despite hardening. attack_vector records that the payload executes when the victim previews the attachment, running in the authenticated webmail session. active_exploitation confirmed, poc_available true, kev_date 2024-06-26, CVSS 6.1, RWEP 64. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes recording the vendor update as the remediation.",
+        "gap_closes": [
+          "NIST-800-53-SI-3",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2022-2586": {
     "name": "Linux Kernel Use-After-Free Vulnerability (CVE-2022-2586)",
@@ -46277,7 +47900,32 @@
         "adequate": false,
         "gap": "Anomaly-detection controls that do not baseline WER registry manipulation and WerFault SYSTEM children miss the exact behavior ransomware operators used."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Error Reporting Service (werkernel.sys) and describes a local authenticated user reaching SYSTEM through improper privilege management — the account is already legitimate, so no account model is being abused and no boundary between users is being crossed by an unauthorized identity; a privilege boundary inside a Windows service is failing. For this CVE the control means the March 2024 Windows cumulative update carrying the fix is driven across the affected population on the KEV clock that opened 2024-06-13, with completion measured against each host's installed build for its SKU rather than by an approved or downloaded state in the update console. The population is the one the packet names — Windows 10, Windows 11 and Windows Server editions prior to that cumulative update — and it is an every-endpoint population rather than a server one, because the exploit's precondition, an interactive session held by a low-privileged local user, is the ordinary operating state of a workstation rather than an anomaly. The packet records no live-patch path and states plainly that the vendor update requires a reboot and is the remediation, so a host that installed the update but has not restarted still carries the vulnerable code and must be counted as exposed; the restart is the step most often deferred and a deferral recorded as patched is the specific way this remediation goes wrong. The least-privilege control cited as insufficient on this entry is why the update is the load-bearing step: the escalation runs from an ordinary user account to SYSTEM through a service path, so tightening per-account privilege does not contain it and that attestation passes cleanly while the flaw stays fully exploitable. Note the half this control cannot cover — the packet records an exploit tool attributed to the Cardinal / Storm-1811 group behind Black Basta with build timestamps predating the patch, so for part of the exposure there was no remediation window in existence to enforce. This governs the lag after March 2024; detection has to cover the rest.",
+        "evidence": "Packet affected: 'Microsoft Windows — Windows Error Reporting Service (werkernel.sys) improper privilege management, exploitable by a local authenticated user to gain SYSTEM.' affected_versions: 'Windows 10 / 11 and Windows Server editions prior to the March 2024 cumulative update'. cwe_refs: CWE-269. cisa_kev true, kev_date 2024-06-13, active_exploitation confirmed, poc_available true, rwep_score 75, cvss 7.8. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' active_exploitation_notes: 'Ransomware-linked: Symantec attributed an exploit tool for this flaw to the Cardinal/Storm-1811 group behind Black Basta, with build timestamps predating the patch (likely zero-day). Added to CISA KEV 2024-06-13.' NIST-800-53-SI-2 gap: 'Black Basta held a working exploit weeks-to-months before the March 2024 patch; any standard remediation cadence was irrelevant during the zero-day period, and lag after patch still enables ransomware escalation.' NIST-800-53-AC-6 gap: 'Least-privilege cannot contain this flaw — it escalates a standard user to SYSTEM via a system-service registry path, defeating the privilege model.' AU-Essential-8-Patch gap: 'The Essential Eight OS-patch timeframe far exceeds the zero-day window in which Black Basta was already exploiting this flaw.' UK-CAF-B4 gap: 'CAF system-security hardening does not cover the WER service registry path Black Basta abused to jump user-to-SYSTEM.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "What this control means for this CVE is a host rule keyed on the two-step behaviour the packet describes, expressed in the telemetry a Windows host produces rather than in the Linux audit primitives the control was first written against. The packet's exploit path is specific: a local low-privileged user manipulates Windows Error Reporting registry values, and WerFaultSecure — which the packet records as running with a null security descriptor — then launches an attacker-controlled process with SYSTEM privileges. The rule therefore keys on that pairing: writes to the WER registry values by a process running under a non-administrative user, followed within a short window by a WER service process creating a child whose token is SYSTEM. Both halves are needed. Windows Error Reporting writes its own registry state in normal operation, and Windows services create SYSTEM children constantly; it is the non-administrative write followed closely by the privilege transition that distinguishes this exploit from either, and the alerting posture has to be fast because the packet places this step inside a ransomware operator's chain rather than at its end. Note what will not see it: nothing crashes, no driver is installed, no new service is registered, and the work is done by an ordinary user session using the registry API together with a Windows service doing what it is built to do — so file-integrity monitoring, signature-based anti-malware, and any rule keyed on process crashes or on named exploit tooling have no artifact to match. That is precisely why the anti-malware control is recorded as insufficient on this entry: it targets the payload, and this is the escalation primitive chained ahead of it. Precondition: this requires registry-write auditing scoped to the WER keys and process-creation logging that records each child's user context, both already enabled and already shipping off-host before the attempt. A rule authored afterwards against telemetry nobody was collecting produces nothing, and on the shared and multi-user hosts where a low-privileged local session is routine that telemetry is often exactly what is not enabled. And this detects rather than prevents: a host that alerts has already had a SYSTEM process spawned by an unprivileged user and belongs on the incident path with credential rotation and forensic triage, not on the patch queue.",
+        "evidence": "attack_vector: 'A local low-privileged user manipulates Windows Error Reporting registry values so that the WerFaultSecure service, which runs with a null security descriptor, launches an attacker-controlled process with SYSTEM privileges.' SOC2-CC7-anomaly-detection gap (also recorded in framework_coverage as covered/not adequate): 'Anomaly-detection controls that do not baseline WER registry manipulation and WerFault SYSTEM children miss the exact behavior ransomware operators used.' ISO-27001-2022-A.8.7 gap: 'Antimalware controls target payload delivery and execution, not the privilege-escalation primitive a ransomware operator chains beforehand; A.8.7 would not flag WerFault spawning a SYSTEM child during the zero-day window Black Basta exploited.' NIS2-Art21-incident-handling gap: 'Incident-handling obligations do not require hunting for post-access EoP tooling, so the escalation step of a ransomware chain goes unnoticed until encryption.' active_exploitation_notes: exploit tool attributed by Symantec to the Cardinal/Storm-1811 group behind Black Basta, build timestamps predating the patch. active_exploitation confirmed; poc_available true; kev_date 2024-06-13.",
+        "gap_closes": [
+          "SOC2-CC7-anomaly-detection",
+          "NIS2-Art21-incident-handling",
+          "ISO-27001-2022-A.8.7"
+        ]
+      }
+    ]
   },
   "CVE-2024-32896": {
     "name": "Android Pixel Privilege Escalation Vulnerability (CVE-2024-32896)",
@@ -47460,7 +49108,32 @@
         "adequate": false,
         "gap": "Print Spooler should be disabled on servers that do not print; leaving the service enabled by default preserves the escalation surface this control is meant to remove."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The remediation for this CVE is the Windows cumulative update, and the population to sweep comes from affected_versions rather than from the gap prose: Windows 10, Windows 11 and Windows Server with the Print Spooler service enabled on a build predating the October 2022 cumulative update. A sweep scoped to servers alone, which is how the least-functionality gap phrases the problem, reports clean across an estate whose exposure is mostly Windows 10 and Windows 11 endpoints. Completion is measured per host on the build the machine is actually executing after its restart, never on approved or downloaded in the management console: the packet registers no live-patching primitive for this product and states the vendor update requires a reboot and is the remediation, so a host that installed the update and has not rebooted still runs the vulnerable Spooler and must be counted as exposed. The clock is the 2024-04-23 KEV listing, roughly eighteen months after the fix shipped, and the reason for the lag is recorded in the packet itself: a 7.8 local elevation fell below the internet-facing fast lane and rode the routine cadence, which is the window the packet says was exploited. The control's second half is the load-bearing one here. GooseEgg is a post-compromise tool, so the attacker already holds a foothold when the escalation runs; tightening account privilege does not contain it, which is precisely why the least-privilege gap cited on this entry can pass its attestation while the flaw stays fully exploitable to SYSTEM. Priority follows the packet rather than the CVSS band: confirmed exploitation by a named state actor over more than a year makes this a containment step for an intrusion chain, not a routine endpoint item.",
+        "evidence": "Packet: CWE-269 improper privilege management in the Windows Print Spooler service, where an attacker modifies a JavaScript constraints file and the service executes it with SYSTEM-level permissions. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' cisa_kev true, kev_date 2024-04-23, active_exploitation confirmed, cvss 7.8, rwep_score 55, poc_available false. affected_versions: 'Windows 10, Windows 11, and Windows Server with the Print Spooler service enabled (pre-October 2022 cumulative update)'. NIST-800-53-SI-2 gap: 'The flaw was patched in October 2022 yet was exploited into 2024; environments that deferred the Print Spooler update remained vulnerable long past the fix'. AU-Essential-8-Patch gap: this 7.8 local EoP 'fell below the internet-facing fast lane and rode the routine cadence'. NIST-800-53-AC-6 gap: 'Least-privilege cannot stop GooseEgg escalating a foothold to SYSTEM once the vulnerable Print Spooler is reachable'. active_exploitation_notes: exploited by Forest Blizzard (APT28/STRONTIUM) using a custom post-compromise tool named GooseEgg, per Microsoft Threat Intelligence in April 2024.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scan that marks a Windows host compliant because the October 2022 or later cumulative update is present is paper compliance for this CVE in two distinct ways the packet names. First, the packet records no live-patching primitive and a vendor update that requires a reboot, so a host carrying the update but not yet restarted still executes the vulnerable Spooler; the test must read the running build after restart, not the approved-update list. Second, the packet's own least-functionality and system-security gaps state that Print Spooler should be disabled on servers that do not print and that assurance must include disabling unnecessary services, not only patch tracking. So the operational test has to report, per host, whether the Spooler service is running on a machine with no print role alongside its running build. The distinguishing test: take a Windows Server with no print role that the scan reports compliant, then query the Spooler service state and the executing build on that same host; a least-functionality attestation recorded as met and a patch report showing the update approved both read clean while an enabled Spooler sits on a pre-restart build. Precondition, and it is the half most often over-claimed: disabling the service removes the escalation path only on hosts that genuinely do not print. On print servers and on the Windows 10 and Windows 11 endpoints that print, the service must stay enabled, and there the update plus its reboot is the only remediation, not the service-state check. And because the packet describes GooseEgg as a post-compromise tool run after an initial foothold, stopping the Spooler does not evict an attacker who already reached SYSTEM on that host: a host that was exposed while the service ran belongs on the incident path rather than being closed on a service-state report.",
+        "evidence": "Packet NIST-800-53-CM-7 gap: 'Print Spooler should be disabled on servers that do not print; leaving the service enabled by default preserves the escalation surface this control is meant to remove.' UK-CAF-B4 gap: 'System-security assurance must include disabling unnecessary services like Print Spooler, not only patch tracking, to remove APT28's post-compromise escalation path.' live_patch_notes: 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' patch_required_reboot true, live_patch_available false. affected_versions: 'Windows 10, Windows 11, and Windows Server with the Print Spooler service enabled (pre-October 2022 cumulative update)'. attack_vector: 'After gaining an initial foothold, APT28's GooseEgg tool modifies a Print Spooler JavaScript constraints file and causes the Spooler service to execute it with SYSTEM permissions, spawning attacker-chosen applications, backdoors, and credential-theft tooling.' active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-3400": {
     "name": "Palo Alto Networks PAN-OS Command Injection Vulnerability",
@@ -48836,7 +50509,39 @@
         "adequate": false,
         "gap": "System-security expectations assume webmail rendering is trustworthy; they do not mandate a content-security-policy / output-encoding control that would neutralize the stored-XSS payload."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The CVSS 6.1 on this entry is precisely what makes it go wrong in practice. Read as a medium-severity webmail XSS it sorts into a routine queue, while the packet records it as a zero-day used by the Winter Vivern (TA473) espionage group against European governmental webmail from at least October 2023 to steal mail and credentials, with a public proof of concept available. For Roundcube the requirement is that the KEV listing rather than the severity band sets the clock, and that the clock runs against the Roundcube install itself — a self-hosted third-party webmail server that typically sits outside the operating-system patch pipeline that Essential Eight maturity and most flaw-remediation programmes actually measure, which is why an organisation can be fully compliant on OS patching while the vulnerable rcube_string_replacer.php parser keeps rendering crafted links. The fixed levels are the ones the packet's own vector gives: 1.4.14, 1.5.4 on the 1.5.x line, and 1.6.3 on the 1.6.x line; anything below those on any line is in scope regardless of how current the host operating system is. Precondition on remediation and measurement: live_patch_available is false and the packet records no vendor live-patch mechanism, so the vendor fixed release is the only remediation available — there is no configuration setting or filter in the packet to reach for in the interim. patch_required_reboot is false, which means no host reboot to schedule and not that the fix is live on deployment; count an instance remediated on the version the running Roundcube reports, not on the package version staged on disk. And because exploitation against this exact parser path is confirmed, an instance that was serving mail below the fixed version during the exposure window is an incident item as well as a patch item — the upgrade removes the sink but returns nothing about what was already read out of the mailboxes.",
+        "evidence": "Packet vector: 'Roundcube before 1.4.14, 1.5.x before 1.5.4, and 1.6.x before 1.6.3 allows XSS via text/plain e-mail messages with crafted links because of program/lib/Roundcube/rcube_string_replacer.php behavior.' active_exploitation_notes: 'Exploited as a zero-day by the Winter Vivern (TA473) espionage group against European governmental webmail from at least October 2023; a crafted plain-text email link executed script in the victim's Roundcube session to steal mail and credentials.' NIST-800-53-SI-2 gap: 'The fix shipped in September 2023 but the flaw was already an operational zero-day against targeted governments; a routine SI-2 timeline is slower than the observed espionage exploitation.' AU-Essential-8-Patch gap: 'Essential-Eight patch maturity is oriented to OS and Office endpoints, not to timely upgrade of a third-party webmail server whose rcube_string_replacer.php parser is the stored-XSS sink.' PCI-DSS-4.0-6.2.4 gap: 'Injection-flaw handling in 6.2.4 targets first-party code review; it does not force timely upgrade of a third-party webmail component whose parser is the injection sink.' CISA KEV 2024-02-12; active_exploitation confirmed; poc_available true; CVSS 6.1; RWEP 67; patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "PCI-DSS-4.0-6.2.4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet attributes exploitation of this Roundcube flaw to the Winter Vivern (TA473) espionage group operating against European governmental webmail, which is exactly the attribution trigger this control exists to act on and exactly the case where commodity handling gets it wrong: a CVSS 6.1 cross-site scripting finding routed through standard malware-infection response is treated as a browser-session nuisance, when the packet describes it as a nation-state credential-theft primitive. For this CVE the trigger condition is concrete — a Roundcube instance below 1.4.14, 1.5.4 or 1.6.3 together with any evidence of the crafted plain-text link arriving or being rendered — and the escalated response has to be scoped to what the packet says the actor actually took: mail and credentials out of the victim's authenticated webmail session. That makes mailbox-content exposure assessment and credential rotation for every account whose session rendered a message during the window the substance of the response, rather than the endpoint reimaging a commodity playbook would reach for; the payload runs in the webmail session, so the user's workstation is not where the compromise lives. Preconditions: attribution of this kind arrives after the fact, so the escalation only changes an outcome if the mail-server and webmail telemetry it needs was already being retained across a window the packet dates to at least October 2023, months before the 2024-02-12 KEV listing. And escalation is a response posture — it does not remove the parser defect, which only the vendor fixed release does, and it does not invalidate credentials that were taken; those stay usable until they are rotated.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited as a zero-day by the Winter Vivern (TA473) espionage group against European governmental webmail from at least October 2023; a crafted plain-text email link executed script in the victim's Roundcube session to steal mail and credentials. KEV ransomware use unconfirmed.' NIS2-Art21-vulnerability-management gap: 'Vulnerability-management obligations do not by themselves prioritize a CVSS-medium XSS that is, in practice, a nation-state credential-theft primitive.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management is present but under-weights an internet-facing webmail XSS as a targeted-intrusion vector rather than a low-severity nuisance.' Fixed levels per vector: 1.4.14, 1.5.x before 1.5.4, 1.6.x before 1.6.3. CVSS 6.1; RWEP 67; CISA KEV 2024-02-12; active_exploitation confirmed; patch_available true, live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "Applied to Roundcube, this control addresses why the Winter Vivern activity the packet describes leaves no authentication-layer trace. The script executes inside the victim's already-authenticated webmail session at the moment the crafted plain-text message is viewed, so there is no failed login, no new session establishment and no client-side artifact to match — an authentication-event log is complete and silent while the mailbox is being read. Detection therefore has to key on the behaviour the packet actually documents: a message view followed, within the same authenticated session, by message-fetch and search activity whose volume and ordering no human reading pattern produces, and by outbound requests carrying session or credential material to a destination outside the deployment. The requirement is that Roundcube per-request access logs — message view, search, message fetch, and requests the application issues on the session's behalf — are forwarded to a SIEM off the webmail host and retained long enough to answer a question that arrives late, which for this CVE means spanning from at least October 2023, when the packet dates exploitation, to the 2024-02-12 KEV listing and beyond. Preconditions, and the second one is the limit that must not be glossed. This is detection, not neutralization: it does not stop the payload, and it supplies only the monitoring half of the system-security expectation — the CAF B4 gap on this entry names a content-security-policy or output-encoding control as what would neutralize the stored payload, and this control does not provide that; the vendor upgrade to 1.4.14, 1.5.4 or 1.6.3 is what removes the sink in rcube_string_replacer.php. And a rule written after the attribution lands, against per-request logs nobody was shipping off the host, returns nothing at all.",
+        "evidence": "Packet attack_vector: 'The attacker emails a plain-text message containing a crafted link; Roundcube's link-replacer converts it into HTML with attacker-controlled attributes/script, so JavaScript runs in the victim's authenticated webmail session when the message is viewed.' active_exploitation_notes: exploited by Winter Vivern (TA473) against European governmental webmail 'from at least October 2023; a crafted plain-text email link executed script in the victim's Roundcube session to steal mail and credentials.' UK-CAF-B4 gap: 'System-security expectations assume webmail rendering is trustworthy; they do not mandate a content-security-policy / output-encoding control that would neutralize the stored-XSS payload.' Fixed levels per vector: 1.4.14, 1.5.4, 1.6.3. CISA KEV 2024-02-12; active_exploitation confirmed; patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-4762": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2023-4762)",
@@ -49305,7 +51010,39 @@
         "adequate": false,
         "gap": "Security-monitoring expectations rarely include vmdird crash telemetry, so the earliest reliable signal of this exploit went uncollected."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The vulnerable code on this entry is vCenter Server's DCERPC implementation: the packet places the out-of-bounds write in the vmdird service's handling of crafted DCERPC packets, a binary listener that answers a network peer before any authentication, so the vCenter role-and-permission review and web-tier hardening most deployments are audited against never touch this path. Bound to this deployment, the control means the DCERPC listener on every vCenter Server accepts connections only from the management and jump networks and the hosts vCenter administers, enforced by network ACL or host firewall rather than inferred from 'vCenter is internal'. Scope that enforcement to everything the packet's affected_versions names - vCenter Server 8.0 and 7.0 appliances and the vCenter component inside VMware Cloud Foundation 5.x and 4.x - because an inventory built only from standalone vCenter appliances reports clean across a Cloud Foundation estate that carries the same listener. Distinguishing test: from a general user or workstation VLAN on a staging deployment, send DCERPC traffic at vCenter and confirm it is dropped before the listener processes it. Precondition, and this is where the control gets over-claimed: an ACL bounds who can send the packet, it does not repair the parser - any host inside the permitted segment still reaches the same out-of-bounds write, and the packet records the defect as network-facing, unauthenticated and RCE-class. Repair is the fixed release (vCenter Server 8.0 U1d/U2, 7.0 U3o, or the corresponding Cloud Foundation update); live_patch_available is false and the entry states remediation requires applying the fixed release and rebooting, so an appliance carrying the fixed release that has not rebooted is still executing the vulnerable vmdird and completion is measured on the version the running appliance reports.",
+        "evidence": "The packet's vector states vCenter Server contains an out-of-bounds write vulnerability in the implementation of the DCERPC protocol, and that a malicious actor with network access to vCenter Server may trigger it, potentially leading to remote code execution; the attack_vector record places the write in the vmdird service, triggered by crafted DCERPC packets, with code execution reached through control of the byte-swapped base address. CWE-787. affected lists VMware vCenter Server and vCenter within Cloud Foundation; affected_versions lists vCenter Server 8.0 before 8.0 U1d / U2, vCenter Server 7.0 before 7.0 U3o, and VMware Cloud Foundation 5.x / 4.x (vCenter component). CISA KEV-listed 2024-01-22 with active_exploitation confirmed; poc_available true; CVSS 9.8, RWEP 80; EPSS approximately 0.99. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes stating there is no vendor live-patch mechanism and that remediation requires applying the fixed release and rebooting. NIST SP 800-53 SC-7 (Boundary Protection) and EU NIS2 Article 21 network security are recorded among the framework controls insufficient for this entry, the first because vCenter is an internal management plane many networks leave broadly reachable so the DCERPC surface is exposed to any host that can reach the appliance, the second because network-security controls that assume the virtualization management plane is trusted neither segment nor monitor DCERPC to vCenter.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "On this entry the fixed build is not the remediation verdict, and the packet says why: the flaw was exploited as a zero-day by the China-nexus espionage group UNC3886 from approximately 2021, years before the October 2023 disclosure, and the vCenter foothold was used to reach ESXi hosts and deploy VIRTUALPITA and VIRTUALPIE implants. Those implants sit on the managed hosts, entirely outside anything a vCenter update rewrites, so an appliance moved to 8.0 U1d/U2 or 7.0 U3o can be fully patched and still sit in a live intrusion. For any vCenter Server - or Cloud Foundation vCenter component - that was network-reachable on a pre-fix build during that window, the default response is compromise assessment rather than patch-and-close: capture the appliance configuration and logs before touching it, rebuild the appliance from known-good media at the fixed release, extend the assessment to the ESXi hosts that appliance administers rather than stopping at the appliance boundary, and rotate the administrative credentials used for vCenter and for those hosts. Detection keys on what the packet documents rather than on a generic exploit signature: the same out-of-bounds write that can execute code can also crash the service, so vmdird crash and restart events on vCenter are the recorded observable, together with DCERPC connections to the appliance from segments that have no administrative relationship with it. Deleting a single located implant and then patching is not equivalent - dwell measured in years is long enough for access paths that no longer depend on the DCERPC defect.",
+        "evidence": "active_exploitation is confirmed and active_exploitation_notes state the flaw was exploited as a zero-day by the China-nexus espionage group UNC3886 since approximately 2021, years before the October 2023 disclosure, to reach ESXi hosts and deploy VIRTUALPITA/VIRTUALPIE implants, and that KEV ransomware use is unconfirmed. The attack_vector record states the crafted DCERPC packets corrupt memory to crash the vmdird service or, with control of the byte-swapped base address, execute code - a foothold UNC3886 used to reach ESXi hosts. patch_available true with fixed builds listed in affected_versions as vCenter Server 8.0 U1d / U2 and 7.0 U3o; patch_required_reboot true; live_patch_available false, live_patch_notes stating remediation requires applying the fixed release and rebooting. CISA KEV-listed 2024-01-22; CVSS 9.8, RWEP 80; poc_available true. The framework record states that NIST SP 800-53 SI-2 addresses known flaws and not a silent nation-state zero-day exploited for roughly two years before disclosure, and that ISO/IEC 27001:2022 A.8.8 technical-vulnerability management is disclosure-driven so its coverage begins only at VMware's advisory, not during the exploited window - which is precisely why the completion criterion on an exposed appliance has to be an assessment outcome rather than a build number.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "This entry carries named attribution, and a commodity-incident path under-escalates it. The packet attributes exploitation to UNC3886, a China-nexus espionage group, operating from approximately 2021 with implants named VIRTUALPITA and VIRTUALPIE on the ESXi hosts reached through vCenter. The finding an operator is holding is therefore not 'an appliance had a CVE' but a long-dwell espionage intrusion in the virtualization management plane, and the runbook needs an explicit trigger that routes it there: attribution or implant indicators of this class on a vCenter or ESXi finding escalate to the nation-state path, which sets the assessment scope to the managed virtualization estate rather than the appliance, extends telemetry retention past the normal window because the exposure predates the advisory by roughly two years, and treats regulatory notification and threat-intelligence reporting as part of closure rather than closing on a patch ticket. The trigger also has to be fed, which is the monitoring half: vmdird crash and restart events and DCERPC connection records from vCenter have to be collected into the SIEM, because the packet's own attack-vector description makes a crashing vmdird the observable byproduct of the same write that executes code. An estate that ingests vCenter administrative audit logs alone has no signal at all for a pre-authentication parser defect, which is exactly how the earliest reliable indicator of this exploit went uncollected. Precondition: this is detection and response scope, not prevention - it shortens dwell and sizes the investigation, and only the fixed release plus the reboot the packet requires removes the defect.",
+        "evidence": "active_exploitation_notes name the actor and the implants: exploited as a zero-day by the China-nexus espionage group UNC3886 since approximately 2021, years before the October 2023 disclosure, to reach ESXi hosts and deploy VIRTUALPITA/VIRTUALPIE implants; network-facing, unauthenticated, RCE-class. The attack_vector record states the out-of-bounds write in vmdird can crash the service or execute code, and that the foothold was used to reach ESXi hosts. CISA KEV-listed 2024-01-22, active_exploitation confirmed, CVSS 9.8, RWEP 80, EPSS approximately 0.99. The framework record states that EU DORA Article 9 ICT protection requirements do not mandate the compromise assessment of the hypervisor management layer needed after a stealthy, long-dwell vCenter intrusion, and that UK CAF C1 security-monitoring expectations rarely include vmdird crash telemetry, so the earliest reliable signal of this exploit went uncollected - the two gaps this control is attached to.",
+        "gap_closes": [
+          "DORA-Art-9",
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2023-35082": {
     "name": "Ivanti Endpoint Manager Mobile (EPMM) and MobileIron Core Authentication Bypass Vulnerability",
@@ -49419,7 +51156,30 @@
         "adequate": false,
         "gap": "System-security assurance assumes the renderer sandbox holds; a V8 out-of-bounds primitive undermines that assumption without additional exploit-mitigation controls."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The exploited surface is the browser on ordinary user endpoints — a victim visits an attacker-controlled page and JavaScript drives an out-of-bounds memory access in V8, corrupting the heap for code execution in the renderer — so for this CVE the control means the browser security channel is not held in any deferral ring on a managed fleet. The target build is per product, not per vendor: Chrome at 120.0.6099.224 or later, and the Edge, Opera and Brave builds that carry the fixed V8, because the packet places all of them in the affected set. An estate standardised on Edge that measures only its Chrome population reports full coverage while every endpoint keeps executing the vulnerable engine — the defect is in V8, and the vector's headline product is not the scope. Completion is measured on the version the running browser process reports, not the version installed: patch_required_reboot is false, which means no machine reboot, not that the fix is live — a Chromium browser that has downloaded the update keeps running the old V8 in its existing processes until the browser is relaunched, and the packet records that force-relaunch is often not enforced, which is precisely how a fleet reaches full installed coverage while a large share of it stays exploitable. Enforce the relaunch through policy with a bounded deadline rather than leaving it to the user closing their tabs. Precondition: there is no live-patch path here — the packet states remediation requires applying the vendor fixed release, so a deferral ring left in place has no compensating control behind it, only exposure to routine browsing.",
+        "evidence": "Packet: KEV-listed 2024-01-17; active_exploitation confirmed and exploited in the wild as a zero-day in January 2024; poc_available false; RWEP 55; CVSS 8.8; patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' affected_versions: Google Chrome before 120.0.6099.224; Chromium-based browsers (Edge, Opera, Brave) shipping V8 before the 120.0.6099.224 fix. AU-Essential-8-Patch gap as recorded: Essential-8 patch timelines can trail a browser zero-day already exploited before the CVE is public, and force-relaunch is often not enforced. NIS2-Art21-patch-management gap as recorded: endpoint-browser patch management is rarely enforced as tightly as server patching, yet browsing is the exact exploited vector. attack_vector: a victim visits an attacker-controlled page; JavaScript drives an out-of-bounds memory access in V8, corrupting the heap to gain code execution in the renderer.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "An installed-version verdict is paper compliance for this CVE for two specific reasons, both of which the packet supplies. First, the installed build and the executing build diverge: patch_required_reboot is false, so nothing forces a machine restart, and a Chromium browser continues running the pre-fix V8 in its existing processes until it is relaunched — the packet notes force-relaunch is often not enforced, so an inventory that reads the on-disk version marks an endpoint remediated while its open browser is still exploitable by the crafted page. Second, the scope is keyed to the wrong product: Edge, Opera and Brave are inventoried under their own names and their own version numbers, so a rule written as 'Chrome at or above 120.0.6099.224' silently returns nothing for them and an estate standardised on one of those reports clean. The operational test is therefore per endpoint and per browser: collect the version the running browser process reports for every Chromium-based browser installed, and check each against its own product's build that carries the fixed V8 rather than against Chrome's number. Precondition: this is verification only — it identifies which endpoints are still executing the vulnerable engine, and the remediation remains the vendor fixed release plus the relaunch, since the packet records no live-patch mechanism.",
+        "evidence": "Packet affected_versions: Google Chrome before 120.0.6099.224; Chromium-based browsers (Edge, Opera, Brave) shipping V8 before the 120.0.6099.224 fix. patch_required_reboot false; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' AU-Essential-8-Patch gap as recorded: force-relaunch is often not enforced. ISO-27001-2022-A.8.8 gap as recorded: technical-vulnerability management under-prioritizes client browsers, leaving the actual exploited surface under-governed. Vector: out of bounds memory access in V8 in Google Chrome prior to 120.0.6099.224 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page; poc_available false; active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-6549": {
     "name": "Citrix NetScaler ADC and NetScaler Gateway Buffer Overflow Vulnerability",
@@ -49828,7 +51588,38 @@
         "adequate": false,
         "gap": "Technical-vulnerability management offers no route for a KEV appliance command-injection zero-day where only a temporary mitigation existed before a patch."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For Ivanti Connect Secure 9.x/22.x and Policy Secure 9.x/22.x, the packet records the outcome of exploitation and not only the flaw: crafted requests to the ICS/IPS web components executed arbitrary OS commands, and webshells (GIFTEDVISITOR, WIREFIRE) were dropped across the fleet while this was still a zero-day. Applying the fixed release and rebooting — which the packet records as the only remediation path, with no vendor live-patch mechanism — restores the code but removes nothing an attacker wrote to the appliance during the exposure window. So for any ICS/IPS unit that was reachable between the 2024-01-10 KEV listing and the fixed release, the default runbook must be: export the configuration for review, rebuild the appliance from the vendor image onto the fixed release, and rotate every credential and certificate the appliance held or brokered — VPN user credentials, appliance administrator credentials, and any service account reachable through it — rather than patching in place and closing the item. The packet also removes the usual reassurance that would otherwise justify patch-in-place: the appliance's own Integrity Checker Tool was subverted by the attackers, so a clean on-box integrity result is not evidence the unit is clean, and 'ICT reports no changes' cannot be the basis for skipping the rebuild. Preconditions: the rebuild holds only if the unit returns on the fixed release — a rebuilt appliance restored to a pre-fix build is immediately re-exploitable through the same web-component path — and rebuilding does not retract credential material already exfiltrated, which is why rotation runs as part of the same action rather than as a later phase.",
+        "evidence": "Packet records a mass-exploited zero-day, CISA-flagged ransomware-associated, KEV-listed 2024-01-10 with active_exploitation 'confirmed' and poc_available true; webshells named as GIFTEDVISITOR and WIREFIRE dropped 'across the fleet', and the path becomes fully unauthenticated RCE when chained with the CVE-2023-46805 auth bypass. patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting'. The AU-Essential-8-Patch gap states 'interim mitigation plus factory reset were required beyond the normal patch SLA', and the NIST-800-53-SI-4 gap states the appliance's 'own Integrity Checker Tool was subverted by attackers'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "Both monitoring gaps recorded on this entry are on-box-trust failures: the packet states operators lacked telemetry from the Ivanti appliance and that its built-in integrity check was tampered with, so the two records an operator would consult after the fact were under the control of an attacker who held command execution on the box. For ICS/IPS the requirement is that the appliance continuously forward web-component request logs, administrative-action logs and authentication logs to a collector in a separate trust zone — different management plane, different credentials, different authentication path — so the record of exploitation survives the appliance that was exploited. The detection built on that feed has to key on what the packet describes this exploit doing: crafted requests to ICS/IPS web-component endpoints that result in OS command execution; an administrator-context request against those endpoints with no corresponding successful administrator authentication, which is the shape the packet records when the flaw is chained with CVE-2023-46805 and becomes unauthenticated; and subsequent requests to web-accessible paths that are not part of the vendor image, which is how a planted webshell is reached. Rules written around appliance crashes, malware signatures, or named exploit tooling would miss every stage of that — the packet describes well-formed requests to legitimate endpoints and a webshell as the artifact, not a crash. Precondition: this only produces evidence if the off-box collection was already running before the intrusion, which for a closed appliance is exactly where it is least often configured; and once a unit is compromised its own on-box logs cannot be used to fill the gap retrospectively, because the attacker had command execution on the system that wrote them.",
+        "evidence": "NIST-800-53-SI-4 gap: 'System monitoring does not natively cover a closed appliance whose own Integrity Checker Tool was subverted by attackers, so command-injection and webshell activity evaded the expected detection surface.' UK-CAF-C1 gap: 'Security-monitoring expectations were defeated because operators lacked telemetry from the appliance and the built-in integrity check was tampered with, hiding the command-execution stage.' Vector: a command injection in web components of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) where an authenticated administrator sends specially crafted requests to execute arbitrary commands; the packet records the same path as unauthenticated when chained with CVE-2023-46805, used to drop webshells. active_exploitation 'confirmed'.",
+        "gap_closes": [
+          "NIST-800-53-SI-4",
+          "UK-CAF-C1"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The packet records this as exploited before any fix existed, with only a temporary mitigation available in the interim — the state that compliance reporting on ICS/IPS could not express, because it has no verdict between 'vulnerable' and 'patched per SLA'. For this CVE the requirement is that an Ivanti Connect Secure or Policy Secure appliance carrying the interim mitigation with no fixed release installed be recorded as its own state — mitigation active, no fixed build — with a dated action item attached, and that the state age against the 2024-01-10 KEV listing rather than resetting the clock on the day the mitigation was applied. Two consequences are specific to this entry. Any defect in the interim mitigation reopens a command-injection path that the packet already shows was being exploited at scale across the fleet, so the residual risk in state (b) here is not theoretical. And the mitigation says nothing about units already compromised: the packet records that a factory reset was required alongside it, so an appliance in this state that was reachable during the exposure window sits on the rebuild path at the same time and must not be closed on the mitigation record. This control is a reporting requirement, not a defence — it makes the residual exposure countable; what removes it is the fixed release and the reboot the packet records as required, with no live-patch alternative.",
+        "evidence": "ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management offers no route for a KEV appliance command-injection zero-day where only a temporary mitigation existed before a patch.' AU-Essential-8-Patch gap: 'The patch objective could not apply during a zero-day with no fix; interim mitigation plus factory reset were required beyond the normal patch SLA.' Packet fields: cisa_kev true with kev_date 2024-01-10, active_exploitation 'confirmed', patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-23752": {
     "name": "Joomla! Improper Access Control Vulnerability",
@@ -50367,7 +52158,29 @@
         "adequate": false,
         "gap": "The application-patch target for browsers is frequently unmet on managed fleets, and 'patched' Chrome is not protected until every process is restarted."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "This is a heap buffer overflow in the WebRTC component of Chrome/Chromium reachable from a crafted HTML page, so the delivery path is ordinary browsing and every endpoint that renders web content is in the exploit population — the update ring is the whole of the remediation, and any ring that stages security-channel browser updates behind a validation window is holding a fleet on exploitable code while the pages that exploit it are already being served. Scope the ring from the packet's affected field rather than from the vector's headline product: it records Google Chrome / Chromium and downstream Chromium browsers, and the exploitation notes state the flaw affects the broad Chromium browser base, so every Chromium-based browser deployed in the estate has to be covered at that product's own fixed build. An estate standardised on a downstream Chromium browser will report clean if the check keys only on Chrome reaching 120.0.6099.129. Measure completion on the build the running browser process is executing, not on the installed package: patch_required_reboot is false, which means no machine reboot is required, not that the fix is live on deployment — a browser process that has been running since before the update keeps executing the pre-fix WebRTC code until it is relaunched, which is what the packet's own gap statements mean by needing a fleet-wide forced restart. Precondition: the ring reaches only browsers under management policy. A per-user or otherwise unmanaged Chromium install on a managed host is outside the ring, and the ring's compliance percentage will not show it; that copy is remediated by bringing it under management or removing it, not by the ring.",
+        "evidence": "Packet vector: 'Heap buffer overflow in WebRTC in Google Chrome prior to 120.0.6099.129 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.' affected: 'Google Chrome / Chromium (and downstream Chromium browsers) — heap buffer overflow in the WebRTC component reachable from a crafted HTML page'; affected_versions: 'Google Chrome prior to 120.0.6099.129'. active_exploitation_notes: exploited in the wild as a Chrome zero-day found by Google's Threat Analysis Group, 'fixed in Chrome 120.0.6099.129/130; affects the broad Chromium browser base'. cisa_kev true, kev_date 2024-01-02, active_exploitation 'confirmed', patch_available true, patch_required_reboot false, live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' Cited gaps: NIST-800-53-SI-2 'auto-update must be enforced, which flaw-remediation policy often does not treat as urgent for endpoints'; ISO-27001-2022-A.8.8 'a browser heap-overflow zero-day needs endpoint-fleet-wide forced restart to take effect'; NIS2-Art21-patch-management 'Baseline patch cadence does not force the near-immediate browser relaunch across a fleet that a drive-by client zero-day requires.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE the paper-compliance trap is specific and the packet states it outright: a scan that reads the installed Chrome/Chromium version off disk and reports the endpoint patched at 120.0.6099.129 is measuring the wrong thing, because the browser process that has been running since before the update is still executing the vulnerable WebRTC code. The operational test that distinguishes real remediation: on a sample of endpoints, compare the build the running browser process itself reports against the fixed build, and treat any host whose on-disk build is at or above the fix while the running process reports lower as exposed rather than remediated. Run the same comparison for every Chromium-based browser the estate deploys, since the packet places the defect in Chromium's WebRTC component and not solely in Chrome. This matters more here than for a server patch because of how endpoints are used — a laptop that is suspended and resumed for weeks without the browser ever being closed is the normal case, not the exception, so the population of 'installed but not yet running the fix' endpoints does not drain on its own. Precondition: this test measures state, it does not change it. It tells the operator which endpoints still owe a browser relaunch and gives nothing on a host where the relaunch is never forced; enforcing the relaunch is the update-ring control's job, not this one. It is also not an exploitation check — the packet's system-security gap notes the attack arrives as ordinary web content to a legitimately running browser, so a clean version comparison says nothing about whether a page already exploited the endpoint during the exposure window.",
+        "evidence": "Packet gap AU-Essential-8-Patch: 'The application-patch target for browsers is frequently unmet on managed fleets, and \"patched\" Chrome is not protected until every process is restarted.' Corroborating packet fields: patch_required_reboot false; live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release'; affected 'Google Chrome / Chromium (and downstream Chromium browsers)'; fixed build per vector 'prior to 120.0.6099.129'. Gap UK-CAF-B4: 'Endpoint/patch controls do not detect exploitation delivered as ordinary web content to a legitimately running browser.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-49897": {
     "name": "FXC AE1021, AE1021PE OS Command Injection Vulnerability",
@@ -51030,7 +52843,40 @@
         "adequate": false,
         "gap": "Technical vulnerability management reacts to known advisories, but this was weaponized as an unknown zero-day, defeating advisory-driven prioritization."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Bound to this CVE the control governs the residual Apple fleet after the fix shipped: every enrolled device driven to iOS/iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2, or the 16.7.2 backport on the 16.x line, on the clock that opened with the 2023-12-04 KEV listing, with user deferral disallowed rather than left to the device holder. Two scoping points decide whether the sweep is real. Safari carries its own version in affected_versions, so a Mac held on an older macOS line whose Safari is below 17.1.2 stays exposed while the Sonoma track shows nothing to do — enumerate the Safari build per Mac, not only the OS build. And the packet records patch_required_reboot true, live_patch_available false, and an update that requires a device restart, so a device that has downloaded the update and not restarted is still executing the vulnerable WebKit code: measure completion on the build the device is actually running, never on 'approved' or 'downloaded' in the management console. Scope the inventory to the products the packet names — iOS, iPadOS, macOS and Safari — and widen only where a verified source identifies another product carrying the same WebKit build. Precondition, and it is the reason this control cannot stand alone here: it reaches only devices the management platform enrols and can compel. The packet's UK-CAF-B4 gap names jailbroken, MDM-deferred and end-of-support devices as the population that remains exposed, and tightening a deferral policy does not touch a device that is not enrolled or cannot receive the build at all. It also does nothing for the window before the fix existed, which is the window this CVE was exploited in.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-12-04, active_exploitation confirmed, rwep_score 60, cvss 8.8. patch_available true, patch_required_reboot true, live_patch_available false, and live_patch_notes 'No live patch; requires the iOS/iPadOS/macOS/Safari update (17.1.2 / 14.1.2, backported to 16.7.2) and a device restart.' affected names Apple WebKit across iOS, iPadOS, macOS and Safari; affected_versions lists iOS/iPadOS < 17.1.2, macOS Sonoma < 14.1.2, Safari < 17.1.2, and iOS 16.x before the 16.7.2 backport. The UK-CAF-B4 gap records that secure-maintenance controls presume auto-update coverage and that jailbroken, MDM-deferred or end-of-support Apple devices remain exposed to malicious web content; the NIS2-Art21-patch-management gap records that timely patching addresses only the residual fleet after Apple shipped 17.1.2/16.7.2.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "This is the control for the window the patch clock never covered. The packet records that Apple is aware of a report the issue may have been exploited against iOS versions earlier than 16.7.1 — exploitation preceding the advisory — and characterises it as a targeted-spyware pattern with delivery through attacker-served web content that needs nothing from the victim but viewing the page. For the population plausibly inside that targeting set, the requirement is a standing reduced-attack-surface posture on their iPhones, iPads and Macs in which untrusted web content is not fetched and processed automatically, narrowing the path into the WebKit out-of-bounds write for devices that have not yet reached 17.1.2 / 14.1.2 / Safari 17.1.2 or the 16.7.2 backport and taken the restart the fix requires. Preconditions, all three load-bearing here. The posture only helps if it was already assigned before the disclosure — a mode switched on after a KEV listing was not on when a pre-disclosure exploit arrived, and this entry is the case where that timing is the whole point. It narrows the delivery path, it does not repair the WebKit defect and does not evict code already executing on a device compromised during the exposure window; a device in the targeted cohort that rendered untrusted content while exposed belongs on the incident path, not the configuration path. And it is a holding measure for the interval before the fixed build and its restart land, not a substitute for them.",
+        "evidence": "Packet: vector states 'Processing web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been exploited against versions of iOS before iOS 16.7.1.' active_exploitation confirmed; active_exploitation_notes describes a targeted-spyware exploitation pattern with no ransomware association. attack_vector: an attacker serves crafted web content triggering an out-of-bounds write in WebKit's WebContent process, yielding arbitrary code execution when the victim merely views the page. The ISO-27001-2022-A.8.8 gap records that technical vulnerability management reacts to known advisories but this was weaponized as an unknown zero-day, defeating advisory-driven prioritization; the AU-Essential-8-Patch gap records that the patch target starts the clock at disclosure while targeted exploitation preceded it.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet carries both halves this control exists to separate. patch_available is true — fixed builds exist at iOS/iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2, with a 16.7.2 backport for the 16.x line — and the packet's own UK-CAF-B4 gap records that end-of-support Apple devices remain exposed to malicious web content. So the first requirement is a per-unit determination rather than a fleet-wide patch percentage: for every iPhone, iPad, Mac and Safari install in service, establish from Apple whether that hardware can still receive a build carrying this fix. Units that can are interim items on the clock that opened with the 2023-12-04 KEV listing, and because live_patch_available is false and the fix requires a device restart, a unit that took the update without restarting is still running the vulnerable code and is not remediated. Units that cannot receive any of those builds have no patch path at all, and for them reaching a fixed build is not an available state: the terminal state is removal or replacement on a dated schedule, because such a device is exposed not only to this out-of-bounds write but to everything found in WebKit since its last build. A risk acceptance with no removal date records a device as compliant while it keeps rendering untrusted web content with a confirmed-exploited flaw. Scope the inventory to the products the packet names — iOS, iPadOS, macOS and Safari — and widen only where a verified source identifies another product carrying the same WebKit build; treating every renderer in the estate as an instance of this CVE manufactures replacement work against software no evidence here implicates.",
+        "evidence": "Packet: patch_available true with affected_versions iOS/iPadOS < 17.1.2, macOS Sonoma < 14.1.2, Safari < 17.1.2, and iOS 16.x before the 16.7.2 backport; live_patch_available false and live_patch_notes 'No live patch; requires the iOS/iPadOS/macOS/Safari update (17.1.2 / 14.1.2, backported to 16.7.2) and a device restart.' framework_coverage for UK-CAF-B4 states 'Secure-maintenance controls presume auto-update coverage; jailbroken, MDM-deferred, or end-of-support Apple devices remain exposed to malicious web content.' cisa_kev true, kev_date 2023-12-04, active_exploitation confirmed.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-42916": {
     "name": "Apple Multiple Products WebKit Out-of-Bounds Read Vulnerability",
@@ -51520,7 +53366,39 @@
         "adequate": false,
         "gap": "Secure-maintenance objectives assume a maintainable product; an unsupported internet-facing appliance with a pre-auth RCE cannot be brought into compliance by patching."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet carries both halves this control exists to separate, and states them explicitly. A fix exists — the appliance update to 4.3.10.4 or later, auto-applied to supported devices — and the product is end-of-life, so the packet records migration off Sophos Web Appliance as the durable remediation. That defines the requirement: reaching 4.3.10.4+ is an interim state, and the terminal state is removal and replacement of the appliance, because a unit kept in service past end-of-life is exposed not only to this pre-authentication command injection but to everything found in the product since that build, with no update path left to take it anywhere. Operationally: inventory every Sophos Web Appliance in service with the version it currently runs; confirm each has actually reached 4.3.10.4 or later rather than assuming the automatic update applied, since the packet ties auto-application to supported devices while the exposed population at issue is precisely the instances not receiving it; and put every unit on a dated replacement schedule with a named successor web gateway. A remediation record that ends at 'every appliance reports 4.3.10.4' marks an end-of-life, internet-facing appliance compliant while it stays exposed, and a risk acceptance carrying no removal date does the same thing more slowly — which is why the vulnerability-management and system-security gaps on this entry cannot be closed by any patch SLA. Scope to what the packet names: Sophos Web Appliance below 4.3.10.4. It gives no mapping of this warn-proceed handler into other Sophos products, so widening the retirement programme to the vendor's other appliances manufactures replacement work against software no evidence implicates. Precondition on the interim half: patch_required_reboot is true and no live patch exists, so an appliance that has taken the update but has not come back up on 4.3.10.4 is still running the vulnerable code and is not remediated.",
+        "evidence": "live_patch_notes: 'No live patch; requires the appliance update to 4.3.10.4+ (auto-applied to supported devices). The product is end-of-life, so migration off Sophos Web Appliance is the durable remediation.' active_exploitation_notes: added to CISA KEV as actively exploited, EPSS ~1.0 reflecting widespread exploitation attempts, pre-authentication command injection giving full remote code execution on internet-facing appliances, and the product is end-of-life, raising the risk of unpatched exposed instances. affected: Sophos Web Appliance versions older than 4.3.10.4 — a pre-authentication command injection in the warn-proceed handler allowing arbitrary OS commands. affected_versions: 'Sophos Web Appliance < 4.3.10.4'. patch_available true; patch_required_reboot true; live_patch_available false. The packet's NIST-800-53-SI-2 gap states flaw remediation is undercut because the product is end-of-life and many exposed instances will never receive the 4.3.10.4 fix; its NIS2-Art21-vulnerability-management gap states the required action is decommissioning/replacement, not patching; its ISO-27001-2022-A.8.8 gap states the required action for this preauth command-injection RCE with a public PoC is decommissioning/replacement, which A.8.8's patch-oriented remediation does not compel; its AU-Essential-8-Patch gap states the exploited-flaw patch SLA is unmeetable for an end-of-life appliance with no forthcoming update path.",
+        "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 Sophos Web Appliance is a web security gateway — the device is itself the trust boundary, which is why the boundary-protection control cited on this entry has nothing to act on: the packet places the pre-authentication injection on the very interface the appliance presents to the network it guards, so there is no upstream boundary that contains it and no perimeter posture that a compliant deployment could have adopted to keep the request away. The tier requirement bound to this device: a pre-authentication command injection yielding remote code execution on a security gateway is not an appliance-maintenance item on a 14- or 30-day cadence — it runs on the clock that opened with the 2023-11-16 KEV listing, with the appliance taken to 4.3.10.4 or later and brought back up, or the vulnerable interface isolated until that completes. Precondition, and this is where the isolation half is normally over-claimed: the packet places the flaw in the warn-proceed handler, part of the surface the appliance presents to the network it filters, and describes full remote code execution on internet-facing appliances. Removing internet reachability bounds who can send the crafted request, but every client the appliance exists to filter still reaches that handler, so isolation shrinks the attacker population rather than closing the path — and it is simply unavailable where the appliance must keep serving that surface to do its job. It is a holding measure for the window before 4.3.10.4 and the reboot the packet records as required, not a substitute for them; on a unit that will never receive 4.3.10.4 it is a holding measure for the window before removal, and must be recorded as such rather than as a mitigation.",
+        "evidence": "affected: 'Sophos Web Appliance versions older than 4.3.10.4: a pre-authentication command injection in the warn-proceed handler allows execution of arbitrary OS commands, yielding remote code execution.' vector: 'A pre-auth command injection vulnerability in the warn-proceed handler of Sophos Web Appliance older than version 4.3.10.4 allows execution of arbitrary code.' CWE-77; CVSS 9.8; RWEP 73; poc_available true; cisa_kev true with kev_date 2023-11-16; active_exploitation 'confirmed'. patch_available true; patch_required_reboot true; live_patch_available false, with live_patch_notes requiring the appliance update to 4.3.10.4+. active_exploitation_notes: EPSS ~1.0 (top percentile) reflecting widespread exploitation attempts; pre-authentication command injection gives full remote code execution on internet-facing appliances. The packet's NIST-800-53-SC-7 gap states boundary protection is ineffective when the appliance is itself the internet-facing security gateway and that the pre-auth injection is reachable on the very interface the device presents to the network.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Active exploitation is confirmed here and the packet puts EPSS at roughly 1.0, reflecting widespread exploitation attempts against a path that needs no credential — so for any Sophos Web Appliance that was internet-facing below 4.3.10.4, the operating assumption is exposure, not exposure-if-something-was-detected. The update is the specific trap on this entry because the packet records it as auto-applied to supported devices: an appliance can arrive at 4.3.10.4 with no operator action and read as remediated on a maintenance report, while whatever an attacker placed through the warn-proceed handler beforehand — added accounts, altered appliance configuration, persistence — survives the upgrade untouched. That is why recording secure maintenance as met by the update is the wrong verdict for an exposed unit. The response for a unit exposed during the window is configuration capture, rebuild from vendor media or outright replacement, and rotation of every credential the appliance held or could observe: its administrative credentials, any directory or authentication integration it used, and any credential that transited the gateway, since a compromised web proxy sits in the path of the traffic it filters. Detection must key on the behaviour the packet documents rather than on a crash or a tool signature: the attacker sends a crafted request to the warn-proceed handler with shell metacharacters in a parameter the appliance passes to an OS command, so the observables are command execution spawned by the appliance's web-handling process and outbound connections from the appliance to destinations it has no operational reason to reach — a successful injection does not require the service to fail, so alerting on process crashes would miss an attempt behaving exactly as described. Precondition: this depends on appliance telemetry being forwarded off the device before the compromise, because a rooted appliance's local logs are attacker-writable; and on an end-of-life product there is no future update that would later remove attacker persistence, so an exposed unit that is not rebuilt or replaced stays owned.",
+        "evidence": "vector and attack_vector: an unauthenticated attacker sends a crafted request to the warn-proceed handler, injecting shell metacharacters into a parameter the appliance passes to an OS command, achieving remote code execution. CWE-77; CVSS 9.8; RWEP 73; poc_available true; active_exploitation 'confirmed'; cisa_kev true, kev_date 2023-11-16. active_exploitation_notes: EPSS ~1.0 (top percentile) reflecting widespread exploitation attempts; pre-authentication command injection gives full remote code execution on internet-facing appliances; the product is end-of-life, raising the risk of unpatched exposed instances; no specific ransomware attribution. live_patch_notes: 'No live patch; requires the appliance update to 4.3.10.4+ (auto-applied to supported devices). The product is end-of-life, so migration off Sophos Web Appliance is the durable remediation.' patch_required_reboot true; live_patch_available false. The packet's UK-CAF-B4 gap states secure-maintenance objectives assume a maintainable product and that an unsupported internet-facing appliance with a pre-auth RCE cannot be brought into compliance by patching.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2020-2551": {
     "name": "Oracle Fusion Middleware WebLogic IIOP Deserialization RCE",
@@ -53023,7 +54901,39 @@
         "adequate": false,
         "gap": "Patch-application timeframes for network appliances are routinely exceeded because of change-freeze and maintenance-window constraints on core routing gear."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The population here is not the router estate: it is every Cisco IOS device and every Cisco IOS XE device with the GET VPN feature enabled, in both roles, since the packet's path reaches the out-of-bounds write from a compromised key server or from a group member reconfigured to register against an attacker-controlled one. Producing that list is part of the requirement rather than a precursor to it, because the A.8.8 gap records that host and web-application scanning rarely enumerates IOS/IOS XE feature-level CVEs, so a GET VPN router will not surface as vulnerable unless the GET VPN configuration itself is what gets inventoried. For each device the 2023-10-10 KEV listing sets the clock rather than the change-freeze calendar the SI-2 and AU-ISM-1546 gaps describe. Fixed releases are per-train and the packet points at the Cisco advisory for them rather than naming one, so the per-device check is that the running image is at or above the advisory's fixed release for that train. The packet records no live-patch mechanism and states that remediation requires applying the fixed release and rebooting, so completion is measured on the image the device is executing after the reload — a fixed image copied to flash and set as the boot image is not remediation, and on core routing gear that pending reload is precisely the step that gets deferred into the next window and then recorded as patched.",
+        "evidence": "Packet: CISA KEV 2023-10-10, active_exploitation confirmed; active_exploitation_notes state Cisco PSIRT observed attempted exploitation of the GET VPN feature in the wild and discovered this out-of-bounds write during the ensuing code review. CVSS 6.6, RWEP 55, poc_available false. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' affected_versions: Cisco IOS with GET VPN enabled and Cisco IOS XE with GET VPN enabled, fixed releases per the Cisco advisory. The SI-2 gap states GET VPN routers are change-controlled infrastructure operators reboot infrequently so the patch window far exceeds the exploitation window; AU-ISM-1546 states patch timeframes are routinely exceeded because of change-freeze and maintenance-window constraints; A.8.8 states vulnerability management rarely enumerates IOS/IOS XE feature-level CVEs on GET VPN routers.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The precondition the packet states outright is administrative control of either a group member or a key server — the attacker is already authorized, which is why the AC-6 gap records that least-privilege on the control plane does not help and a compromised-but-authorized key server or group member still weaponizes the out-of-bounds write. A GET VPN key server is a control plane for every router in its group: it distributes the group policy and keys the members act on, and the packet's second path is simply reconfiguring a group member so it registers against a key server the attacker controls. Applied to this deployment, the control means key-server administration and group-member configuration authority are classified as a tier above general network-operations access — reached only through a privileged-access path with step-up authentication and time-bound elevation, on identities used for nothing else — and that any change to a group member's key-server registration is an audited, reviewed change rather than a routine configuration push. The distinguishing test sits on the change path rather than on the device: on a staging group, attempt to repoint a group member at a different key server using an ordinary network-operations account, and confirm the change is refused or held for review before it takes effect. An estate that passes an AC-6 attestation because each router account carries scoped command privileges still hands this flaw to anyone who legitimately administers a key server. Precondition: this raises the bar on obtaining the administrative position the exploit needs and creates a record when it changes hands; it does nothing once that position is held, and it does not repair the attribute validation, which only the fixed IOS/IOS XE release does.",
+        "evidence": "Packet: vector states the vulnerability could allow an authenticated, remote attacker who has administrative control of either a group member or a key server to execute arbitrary code or crash the device, and that an attacker could exploit it by either compromising an installed key server or modifying the configuration of a group member to point to a key server controlled by the attacker. attack_vector repeats both paths. The NIST-800-53-AC-6 gap states least-privilege on the control plane does not help because the attack presupposes an attacker who already holds legitimate administrative control of a key server or group member, so a compromised-but-authorized KS/GM still weaponizes the out-of-bounds write.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The GDOI and G-IKEv2 exchange between a key server and its group members is the service-internal protocol this control governs, and the packet places the defect there: insufficient validation of attributes in those protocols, so a group member accepts group-policy attributes from its key server and parses them into an out-of-bounds write ending in code execution or a device reload. Both cited gaps make the same point from different frameworks — the GET VPN group is treated as an internal trust domain, and nothing validates the integrity of the group-policy attributes crossing it. Bound to this deployment, the requirement is that a group member registers only with key servers named in an operator-controlled configuration whose integrity is monitored for change, that the GDOI/G-IKEv2 registration interface on both roles answers only from the addresses of that group's own members and key servers rather than from any routable peer, and that 'the group sits inside our network' stops being accepted as the validation step for what the parser receives. Distinguishing test: from a host outside the group's member and key-server set on a staging deployment, attempt a GDOI/G-IKEv2 registration against a group member and against a key server, and confirm it is refused before any group-policy attribute is parsed. Precondition, and it is the load-bearing one: the attribute validation itself is a property of the fixed IOS/IOS XE release — this control bounds which peers can present attributes, it does not make the parser safe, and it gives nothing against a genuinely compromised key server that is already inside the permitted set, which is the packet's primary path. Until the fixed release and its reload land, that residual path stays fully open.",
+        "evidence": "Packet: vector states the vulnerability is due to insufficient validation of attributes in the Group Domain of Interpretation (GDOI) and G-IKEv2 protocols of the GET VPN feature, and that exploitation is either by compromising an installed key server or by modifying a group member's configuration to point to an attacker-controlled key server; attack_vector describes malformed GDOI/G-IKEv2 group-policy attributes triggering an out-of-bounds write, yielding code execution or a device reload. The NIS2-Art21-network-security gap states baseline controls treat the GET VPN trust domain as internal and do not validate the integrity of GDOI/G-IKEv2 group-policy attributes exchanged between KS and GM; the UK-CAF-B4 gap states the flaw is reached from a compromised-yet-authorized key server or group member, so integrity of the GDOI/G-IKEv2 group attributes — not perimeter defense — is what the control must assure.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-41763": {
     "name": "Microsoft Skype for Business Privilege Escalation Vulnerability",
@@ -53151,7 +55061,30 @@
         "adequate": false,
         "gap": "Application-hardening guidance rarely disables or removes WordPad, leaving a legacy document handler that can be coerced into outbound authentication."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "The packet's path into Microsoft WordPad begins with delivery rather than with a memory defect: a victim opens an attacker-crafted document in WordPad, and the file coerces the client into an outbound authentication attempt that leaks NTLM hash material to a host the attacker controls. Nothing else about the endpoint has to be true for that to work, so on any Windows host that has not yet reached the fixed build and taken the reboot the packet requires, keeping the attacker's file away from the WordPad handler is the enforceable control. Applied here that means the untrusted-origin marking is applied at the ingress boundaries themselves — mail gateway, web download, untrusted file share — rather than derived by the application from the file it was handed, and that the marking survives whatever container the document arrives in: a document extracted from an archive, mounted from an ISO or VHD, or renamed must still present as externally sourced, because the container is exactly where provenance is normally lost. Where policy can refuse to open externally-marked documents in the legacy handler at all, that is stronger than any per-file decision. The distinguishing test keys on the delivery the packet documents: send an externally-sourced document through each ingress path nested inside an archive, extract it on a managed host, and confirm it still carries the untrusted-origin marking when it reaches the handler — a user-application-hardening attestation that records macro and ActiveX settings says nothing about a provenance-stripped document opening in WordPad under the user's own token. Precondition: this bounds delivery, it does not repair the flaw, and it is unavailable for any path the marking does not cover. It also retracts nothing: the packet describes the disclosed NTLM material as relayable or crackable, so an endpoint that opened an untrusted document during the exposure window is a credential-rotation item, not a delivery-policy one.",
+        "evidence": "attack_vector: 'A victim opens an attacker-crafted document in WordPad; the file coerces the client into an outbound authentication attempt that leaks NTLM hash material to an attacker-controlled host, which can then be relayed or cracked.' affected states WordPad ships with supported Windows versions and that 'opening a crafted document can disclose NTLM credential material'. The packet's AU-Essential-8-App-Hardening gap: 'Application-hardening guidance rarely disables or removes WordPad, leaving a legacy document handler that can be coerced into outbound authentication.' Its UK-CAF-B2 gap: 'B2 assumes credentials aren't exfiltrable through a document handler, yet the leak enables downstream relay and lateral movement.' patch_required_reboot is true and live_patch_available is false, with live_patch_notes stating remediation requires applying the fixed release and rebooting.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The population this SLA has to run against is wider than the word WordPad suggests, and affected_versions is the authority rather than the vector: Windows 10 on all supported builds carrying WordPad, Windows 11 on supported builds carrying it, and Windows Server 2008 through 2022 with WordPad. An estate that scopes a document handler to desktops leaves the server population reporting clean — and on a server the interactive account that opens a document is disproportionately an administrator, whose hash is the one worth leaking. For this CVE the control means the Windows update carrying the fix is driven across all three of those populations on the clock that opened with the 2023-10-10 KEV listing rather than folded into the next monthly rollup, with completion measured per host on the build actually running. That last part is where this specific remediation goes wrong: live_patch_available is false and the packet states remediation requires applying the fixed release and rebooting, so a host that has the update installed but has not restarted still carries the vulnerable component and must be counted exposed. Priority has to follow the packet rather than the severity band — CVSS 5.5 with poc_available false sorts below routine items on a score-ranked register, while active_exploitation is confirmed and the outcome is credential material leaving the endpoint into relay and lateral movement. Distinguishing test: produce the running build for every Windows 10, Windows 11 and Windows Server host in the estate that carries WordPad and show each at or above the fixed build — a patch-compliance report that counts updates approved or downloaded, or that enumerates only the workstation fleet, passes cleanly while the exposed population is untouched. Precondition: patching stops future leaks and retracts nothing already taken, so hashes that left an endpoint before the update remain usable until the underlying credentials are rotated.",
+        "evidence": "affected_versions names three populations: 'Windows 10 (all supported builds with WordPad)', 'Windows 11 (supported builds with WordPad)', 'Windows Server 2008 through 2022 (with WordPad)'. cisa_kev is true with kev_date 2023-10-10; active_exploitation is confirmed and active_exploitation_notes records that 'the flaw discloses NTLM credential material and can be chained into relay/authentication attacks'. cvss is 5.5 and poc_available is false. patch_available is true, live_patch_available is false, patch_required_reboot is true, and live_patch_notes states 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' The packet's NIST-800-53-SI-2 gap: 'The fix ships in a Windows monthly update; endpoints that defer OS patching remain exposed, and WordPad is a default-installed component that operators rarely track as attack surface.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-22515": {
     "name": "Atlassian Confluence Data Center and Server Broken Access Control Vulnerability",
@@ -53208,7 +55141,39 @@
         "adequate": false,
         "gap": "Patch-application timelines are irrelevant to a zero-day; the control offers no protection until Atlassian's fix is released, underscoring the need for network restriction of admin/setup endpoints."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "For Confluence Data Center and Confluence Server the administrative surface that must authorize its own caller is the setup/onboarding path. The packet's attack vector is an unauthenticated, internet-based caller reaching those endpoints, moving the instance into a configurable state, and creating a new Confluence administrator account it then logs in with — so the product granted 'this request may configure the instance' without ever consulting an identity. Bound to this product the control means each setup/onboarding endpoint refuses a caller not authorized for it regardless of what state the instance believes it is in, and no self-hosted Confluence presents those endpoints to untrusted networks: a reverse proxy or network ACL denies setup/onboarding from any segment with no operational need to run first-time setup, while ordinary user-facing Confluence paths stay open. This is also why the identity-and-access gap is recorded against this entry rather than an account-hygiene finding — the attacker never authenticates as any existing Confluence user, so per-account privilege scoping and SSO/MFA posture are never consulted; the account model is bypassed, not abused. Scope: the packet names Confluence Data Center and Confluence Server 8.0.0 through 8.5.1 and states Atlassian Cloud sites accessed via an atlassian.net domain are not affected, so inventorying Cloud tenants for this flaw manufactures findings against a deployment the vendor states is not vulnerable. Distinguishing test: from an untrusted network, request each setup/onboarding endpoint on a staging Confluence Data Center instance and confirm it is refused before any state change — an estate whose Confluence administrators all authenticate through SSO with MFA passes an access-governance attestation cleanly while this path stays fully open. Precondition: the endpoint-side authorization is a property the vendor fixed release establishes; this control states what to verify and does not implement it. Reachability restriction is the operator-side lever before that release lands, and it bounds who can send the request rather than repairing the check — any caller inside a permitted segment still reaches the endpoint.",
+        "evidence": "Packet vector: external attackers exploited a previously unknown vulnerability in publicly accessible Confluence Data Center and Server instances to create unauthorized Confluence administrator accounts and access the instances; attack_vector adds that the attacker reaches setup/onboarding endpoints, moves the instance into a configurable state, creates an administrator account and logs in with full administrative control. affected: publicly accessible, self-hosted Confluence Data Center and Confluence Server exposing setup/onboarding endpoints; Atlassian Cloud (atlassian.net) is not affected. affected_versions: 8.0.0 through 8.5.1. CWE-20, CVSS 9.8, RWEP 73, poc_available true, CISA KEV 2023-10-05 with confirmed active exploitation. The packet's NIST-800-53-SC-7 gap states boundary protection often left the product directly internet-facing and that without restricting access to the setup/onboarding endpoints the perimeter did not contain the pre-auth admin-creation path; its UK-CAF-B2 gap states the flaw mints a fully-privileged Confluence admin outside any identity process, so access governance offers nothing until the internet-facing setup endpoints are restricted.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Upgrading to a fixed Confluence release closes the pre-auth path; it does not delete an administrator account the exploit already created, and the packet's own incident-handling gap says post-hoc handling must include hunting for attacker-created admins. So for any internet-facing Confluence Data Center or Server instance that ran 8.0.0 through 8.5.1 during the exposure window, the default response is not patch-in-place: enumerate every Confluence administrator against the organisation's own provisioning record, revoke any account with no matching record, rotate administrator credentials, personal-access/API tokens and every integration secret the instance held, and review what those accounts did — app installations, space and global permission changes, bulk exports — because an attacker holding full administrative control of a Confluence instance holds its content. Where an unaccounted administrator is found, restoration from a pre-exposure known-good state is the terminal action and the upgrade alone is not remediation. Detection has to key on what the packet documents, not on a synthetic stand-in: the account is minted through the product's own provisioning path, so it is well-formed and its first login succeeds on the first attempt with a password the attacker set — rules keyed on failed logins, brute-force volume, or malformed requests would miss an attempt behaving exactly as the packet describes. The observable pairing is unauthenticated requests to the setup/onboarding endpoints followed, in the same window, by a new Confluence administrator appearing and authenticating with no change record behind it. Precondition: this depends on holding a provisioning record to compare against and web/application logs covering the window; where neither exists the instance cannot be cleared by inspection, and rebuild from a pre-exposure state is the only honest verdict rather than an assumption of cleanliness.",
+        "evidence": "Packet vector and attack_vector: unauthorized Confluence administrator accounts were created on publicly accessible instances and used to access them. active_exploitation 'confirmed'; active_exploitation_notes record exploitation as a zero-day against internet-facing Confluence Data Center/Server instances to create unauthorized administrator accounts, a CISA KEV known ransomware association, EPSS ~0.99, and public exploitation that was rapid and widespread after disclosure. The packet's NIS2-Art21-incident-handling gap states that incident-handling obligations assume detection precedes admin-account creation, that the exploit mints a legitimate-looking admin account, and that post-hoc handling must therefore include hunting for attacker-created admins — which baseline procedures do not mandate. patch_available true with live_patch_available false and live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Self-hosted Confluence Data Center and Confluence Server instances on 8.0.0 through 8.5.1 must be driven to 8.3.3, 8.4.3, 8.5.2 or later on the clock that opened with the 2023-10-05 KEV listing, not on a quarterly application-upgrade window — the packet records a public PoC, a KEV ransomware association, EPSS ~0.99 and exploitation that was rapid and widespread after disclosure. Two limits bound what this control delivers, and stating them is the point. First, the packet records this as a zero-day exploited before a patch existed, so an SLA keyed to patch availability gave nothing during the pre-disclosure window; the only operator lever then was restricting reachability of the setup/onboarding endpoints, which is why the patch-cadence gaps on this entry cannot be closed by speed alone. Second, patch_required_reboot is false — there is no host reboot to schedule — but that does not make the fix live when the installer exits: live_patch_available is false and remediation is applying the vendor fixed release, so completion is measured per instance on the version the running Confluence reports, not on an upgrade ticket marked done. Scope the sweep to self-hosted Data Center and Server, because the packet states Atlassian Cloud sites on atlassian.net are not affected. And because active exploitation is confirmed, reaching a fixed release does not close an instance that was internet-facing during the window — that instance moves to the incident path with its administrator accounts enumerated, rather than being closed on the patch record.",
+        "evidence": "cisa_kev true with kev_date 2023-10-05; active_exploitation 'confirmed'; CVSS 9.8; RWEP 73; poc_available true; ai_discovered false. affected_versions: 'Confluence Data Center and Server 8.0.0 through 8.5.1 (fixed in 8.3.3, 8.4.3, 8.5.2 and later)'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' active_exploitation_notes: exploited as a zero-day against internet-facing instances, KEV ransomware association, EPSS ~0.99, public exploitation rapid and widespread after disclosure. The packet's NIST-800-53-SI-2 gap states this was a zero-day exploited before a patch existed and that compensating perimeter controls were the only defense during the exposure window; its ISO-27001-2022-A.8.8 gap states technical-vulnerability management could not enumerate an unknown flaw; its AU-Essential-8-Patch gap states patch-application timelines are irrelevant to a zero-day until Atlassian's fix is released. affected states Atlassian Cloud (atlassian.net) is not affected.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-40044": {
     "name": "Progress WS_FTP Server Deserialization of Untrusted Data Vulnerability",
@@ -53322,7 +55287,38 @@
         "adequate": false,
         "gap": "Patch-application controls provide no protection during the zero-day window and depend on mobile-fleet update enforcement that is weaker than for managed workstations."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this entry the deliverable is iOS 16.7.1 / iPadOS 16.7.1 installed and the device restarted onto it, driven from the 2023-10-05 KEV listing rather than left to the user's own update prompt. The packet's flaw-remediation gap names the mechanism that fails: mobile-OS remediation depends on user-driven or MDM-pushed updates, and fleet update compliance is slower than the timelines targeted exploitation runs on. So the substance of the control here is removing user deferral from the path — the update goes out through declarative device management with an enforced deadline instead of a notification the holder can dismiss indefinitely. Measure completion on the build each enrolled device reports after the restart, not on the state of the deployment in the management console: the packet records a fix that requires applying the release and rebooting, with no vendor live-patch mechanism, so a device that downloaded 16.7.1 and postponed the restart is still running the vulnerable kernel and must be counted as exposed. On a phone that restart is the step most reliably postponed, and a postponement recorded as patched is the specific way this remediation goes wrong. Scope the population from the packet's own fields — iOS and iPadOS below 16.7.1 — and note the boundary of this control: devices that cannot enrol, and enrolled devices sitting past the deadline, are not reached by a push at all and are the population the access-condition control has to catch instead.",
+        "evidence": "The packet's vector states the issue was addressed with improved checks and is fixed in iOS 16.7.1 and iPadOS 16.7.1, that a local attacker may be able to elevate their privileges, and that Apple is aware of a report that it may have been actively exploited against versions of iOS before iOS 16.6. affected_versions records iOS < 16.7.1 and iPadOS < 16.7.1. cisa_kev true with kev_date 2023-10-05, active_exploitation confirmed, CVSS 7.8, RWEP 61, poc_available false. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes stating there is no vendor live-patch mechanism and remediation requires applying the fixed release and rebooting. The cited flaw-remediation gap states mobile-OS flaw remediation depends on user-driven or MDM-pushed updates, that devices on iOS < 16.6 remain exploitable until the 16.7.1 update is installed, and that fleet update compliance is typically slower than targeted-exploitation timelines; the cited Essential-Eight gap states patch-application controls depend on mobile-fleet update enforcement that is weaker than for managed workstations.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's least-privilege gap makes the case for turning the build into an access condition: once a local process reaches kernel on iOS or iPadOS, the app-sandbox boundary that every on-device control is built on no longer holds, so nothing installed on the device can be relied on to constrain what the attacker does with organisational data. The lever that survives is on the other side of the connection — what the device is allowed to reach. For this CVE that means iOS/iPadOS 16.7.1 functions as a condition of access: a device below it is denied mail, VPN and document access until it reports the fixed build, rather than appearing as a red row on an update-compliance report while keeping every session it already holds. This is also the control that catches the population an MDM push cannot: the packet's system-security gap names slow-updating and unmanaged devices as where a local process could already reach kernel during the pre-16.7.1 window, and an unmanaged device is by definition not going to take a pushed update. Because the fix requires applying the release and rebooting with no live-patch path, the condition must be evaluated on the build the device is running after restart, not on the build it has downloaded. Distinguishing test: present a device pinned below 16.7.1 to each protected resource and confirm access is refused — an estate that surfaces the stale build on a dashboard while the device keeps its mail session has recorded the exposure rather than removed it. Precondition: this withholds data from an exposed device; it does not repair the device. A device that already ran the escalation is an incident, and denying it new access does not remove what was taken or evict an implant already installed — which, for a flaw the packet describes as exploited before iOS 16.6 in a manner consistent with targeted mobile surveillance, is the likelier state for anyone actually in the targeting set. Scope to what the packet names: iOS and iPadOS below 16.7.1.",
+        "evidence": "The cited least-privilege gap states that least-privilege at the app layer is bypassed by a kernel privilege escalation and that once kernel is reached the app-sandbox boundary the control relies on no longer holds. The cited system-security gap states that system-security assurance for mobile fleets presumes timely vendor patching yet offers no compensating control during the pre-16.7.1 zero-day window, when a local process could already reach kernel on slow-updating or unmanaged devices. The vector records the fix in iOS 16.7.1 and iPadOS 16.7.1 and exploitation reported against versions of iOS before iOS 16.6; affected_versions records iOS < 16.7.1 and iPadOS < 16.7.1. attack_vector describes a local attacker — typically a sandboxed app or an earlier stage of an exploit chain — elevating to kernel privileges, enabling implant installation on targeted devices; active_exploitation_notes records this as consistent with targeted mobile-surveillance use with no ransomware association. patch_available true, patch_required_reboot true, live_patch_available false, remediation requiring the fixed release plus a reboot. kev_date 2023-10-05, CVSS 7.8, RWEP 61.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this flaw inside a chain rather than at its start: the attack path is a local attacker — typically a sandboxed app or an earlier stage of an exploit chain — reaching kernel, with exploitation acknowledged against versions of iOS before 16.6, which is to say before the fix existed. That is the window the cited technical-vulnerability-management gap describes as impossible to enumerate: a control that reacts to advisories has nothing to act on until Apple discloses. The answer that exists before disclosure is a standing posture on the cohort plausibly inside the targeting set for a mobile-surveillance chain — the people whose devices hold the estate's most sensitive material and whose exposure would be worth a chain of this cost — placed in Apple's reduced-attack-surface mode as a default assignment, so that the automatic processing of untrusted web content, message attachments, fonts and link previews that an earlier chain stage relies on is already narrowed when the next undisclosed flaw arrives. Preconditions, and they bound this control tightly. The mode narrows delivery paths into a chain; it does nothing to this kernel flaw itself, and a stage that has already executed locally still reaches the kernel. It gives nothing against a malicious application already installed on the device, which the packet names as one of the two ways this local attacker arrives. And it only helps if it was enabled before the chain arrived — assigning it in reaction to this CVE protects nobody who was already targeted, so a device suspected of having been targeted belongs on a forensic path rather than a configuration path. It is a holding measure for the window before iOS/iPadOS 16.7.1 and the reboot it requires land, not a substitute for either.",
+        "evidence": "The packet's attack_vector states that a local attacker, typically a sandboxed app or an earlier stage of an exploit chain, leverages a kernel flaw fixed by improved checks to elevate to kernel privileges on iOS/iPadOS before 16.6, enabling implant installation on targeted devices. The vector records that Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.6, and that it is fixed in iOS 16.7.1 and iPadOS 16.7.1; active_exploitation_notes records this as consistent with targeted mobile-surveillance use. The cited technical-vulnerability-management gap states that vulnerability management cannot enumerate an unknown kernel zero-day and that coverage begins only after Apple's disclosure. cisa_kev true with kev_date 2023-10-05, active_exploitation confirmed, poc_available false, CVSS 7.8, RWEP 61. patch_available true, patch_required_reboot true, live_patch_available false, with remediation recorded as applying the fixed release and rebooting.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-42793": {
     "name": "JetBrains TeamCity Authentication Bypass Vulnerability",
@@ -53598,7 +55594,41 @@
         "adequate": false,
         "gap": "Browser/application hardening does not prevent exploitation of a zero-day codec bug; only patching the underlying libvpx closes it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The vector names Google Chrome, but the scope of this CVE lives in `affected` and `affected_versions`: the defect is in libvpx's VP8 encoding path prior to 1.13.1, bundled in Chrome prior to 117.0.5938.132 and in other browsers and applications that embed the codec, with Firefox named as one of them. A sweep scoped to the vector's headline product reports an estate standardised on Firefox — or on any other libvpx-embedding application — as clean while every one of those installs still carries the vulnerable encoder, and it is wrong to say no mapping into other products exists here because the packet states the mapping outright. For this CVE the control means one inventory line per product that carries the component, each closed at that product's own fixed level rather than at Chrome's: Chrome at 117.0.5938.132 or later, Firefox at the build its own vendor states carries libvpx 1.13.1 or later, a directly installed libvpx at 1.13.1 or later, and any other embedding application held open until its vendor ships a rebuild against the fixed codec, because those products move on their own update tracks and a browser-update report says nothing about them. Keep the sweep to what the packet establishes: it ties the overflow to libvpx and to software embedding libvpx, so an application enters the inventory when composition data actually shows the component inside it, not because it happens to play video — instructing operators to treat every media-handling binary as an instance of this CVE manufactures findings against software no evidence implicates. Precondition on how completion is measured: patch_required_reboot is false, which means no machine reboot, and it does not mean the fix is live. libvpx is mapped into the host application's own process, so a browser or application that has downloaded and staged the fixed build keeps executing the vulnerable encode path until that process is relaunched; count an install remediated on the version the running process reports, not on the version sitting on disk. live_patch_available is false and the packet records no vendor live-patch mechanism, so applying the vendor fixed release is the whole of the remediation and a long-running session has no in-place alternative. Distinguishing test: after the browser fleet reports updated, query each managed host for every artifact whose composition data lists libvpx and confirm none resolves below 1.13.1 — a flaw-remediation attestation that closes on 'Chrome is current' reads clean while a second embedding application keeps serving the same actively exploited heap overflow to crafted web content.",
+        "evidence": "Packet vector: 'Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.' Packet affected: 'libvpx VP8 encoding as bundled in Google Chrome prior to 117.0.5938.132 and libvpx prior to 1.13.1; also affects other browsers/applications (e.g. Firefox) and software embedding vulnerable libvpx.' affected_versions lists 'Google Chrome < 117.0.5938.132', 'libvpx < 1.13.1' and 'Applications bundling libvpx < 1.13.1 (e.g. Firefox and others)'. NIST-800-53-SI-2 gap: 'flaw remediation must reach not just Chrome/Firefox but every embedding app, so SI-2 tracking of a single browser CVE under-scopes the true exposure.' UK-CAF-B4 gap: 'System-security inventories track named browsers, but libvpx is a bundled codec inside many applications, so patching only Chrome/Firefox leaves the same actively-exploited zero-day live in every other embedding app.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' CISA KEV 2023-10-02, active_exploitation confirmed, CWE-787, CVSS 8.8, RWEP 54.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "This CVE is only findable through composition data. libvpx is not a product an operator installs or an inventory names — it arrives inside Chrome, inside Firefox, and inside whatever else bundles it, which is why the packet's own vulnerability-management gaps record that inventories rarely enumerate a transitive library like this one and that named-product tracking misses the software-composition dimension entirely. The requirement for this CVE is that the estate's SBOM or composition data resolve to the bundled and statically linked level, so that the query 'which artifacts here contain libvpx below 1.13.1' returns a list at all rather than returning nothing because no inventory row is called libvpx. That list, not the browser inventory, is the population for the patch-parity work; without it the operator cannot even tell whether an application is in scope, and the KEV clock that opened 2023-10-02 runs against an unknown denominator. Precondition, and it is the one that gets skipped: this reaches only components the composition data actually records. An application shipped as an opaque vendor binary with no SBOM answers nothing and does not become safe by being absent from the query — for those the question goes to the vendor as a direct request for the libvpx level in that build, and the artifact stays open until the vendor answers. This control produces the scope; it remediates nothing on its own, and each artifact it surfaces still needs its vendor's fixed release, since the packet records no live-patch mechanism.",
+        "evidence": "Packet NIS2-Art21-vulnerability-management gap: 'Vulnerability-management inventories rarely enumerate transitive/bundled libraries like libvpx, so many affected applications are not flagged as needing the fix.' Packet ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management focused on named products misses the software-composition dimension (SBOM) needed to find every libvpx-embedding artifact.' affected_versions includes 'Applications bundling libvpx < 1.13.1 (e.g. Firefox and others)'. active_exploitation_notes: 'the vulnerable libvpx codec is embedded far beyond Chrome, including Firefox and many applications that bundle it.' CISA KEV 2023-10-02; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "Delivery for this CVE is a crafted HTML page, so the victim's only required action is visiting one, and the packet records the flaw being used as a zero-day to deliver commercial spyware attributed by Google TAG to a surveillance vendor. Against that delivery path the enterprise update ring is the thing that actually sets the exposure window on the two browsers the packet names: a security-channel release held back for a staged rollout leaves managed Chrome and Firefox rendering attacker-supplied media through the vulnerable VP8 encode path for the length of the deferral. The requirement here is that the Chrome and Firefox security-channel updates carrying libvpx 1.13.1 or later are not deferred behind a ring, and that relaunch is enforced rather than left to the user — patch_required_reboot is false, so there is no machine reboot to schedule, but the codec is loaded into the browser's own process and a browser left running for days after the update stages is still executing the pre-fix code. Measure the ring's completion on the version the running browser reports. Two preconditions bound this control. It covers only the browsers the update ring manages, and the packet places the same vulnerable codec inside other applications that update on separate vendor tracks — those are outside this control entirely and need the inventory-and-parity work instead. And it does nothing during the window before the fixed build reaches a host: live_patch_available is false, the packet records no live-patch mechanism, and the AU Essential Eight application-hardening gap on this entry states the position directly — hardening does not prevent exploitation of the codec bug, only reaching the fixed libvpx does.",
+        "evidence": "Packet vector: exploitation of heap corruption 'via a crafted HTML page'. active_exploitation_notes: 'Exploited as a zero-day to deliver commercial spyware (attributed by Google TAG to a surveillance vendor)'. AU-Essential-8-App-Hardening gap: 'Browser/application hardening does not prevent exploitation of a zero-day codec bug; only patching the underlying libvpx closes it.' affected_versions: 'Google Chrome < 117.0.5938.132', 'libvpx < 1.13.1', 'Applications bundling libvpx < 1.13.1 (e.g. Firefox and others)'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' poc_available false, active_exploitation confirmed, CISA KEV 2023-10-02.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2018-14667": {
     "name": "Red Hat JBoss RichFaces Framework Expression Language Injection Vulnerability",
@@ -54022,7 +56052,29 @@
         "adequate": false,
         "gap": "Patch-application maturity is the real fix; the control is unmet on the many self-hosted MinIO deployments that lag releases."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For MinIO the clock runs backwards from the usual shape, and the packet gives both ends of it: the fixed release is RELEASE.2023-03-20T20-16-18Z and the KEV listing is 2023-09-19, so the fix was reachable roughly six months before CISA attested exploitation. On this entry the control is therefore not 'compress the patch window' — there was no window to compress — it is that the KEV listing must force an upgrade that every self-hosted MinIO deployment could already have taken. The half that decides whether this lands is measurement: completion is the RELEASE string the running MinIO server process reports, not the package, chart or container image on disk. The packet records patch_required_reboot false and live_patch_available false, with remediation stated as applying the vendor fixed release — so no host reboot is owed, but a server whose new image is staged while the process still executes a pre-RELEASE.2023-03-20T20-16-18Z build is still serving the vulnerable PostPolicyBucket path, and a deployment that was updated but never restarted onto the new binary reads current on an inventory while remaining fully exploitable. Scope from what affected and affected_versions name: MinIO before RELEASE.2023-03-20T20-16-18Z, which on a real estate means the standalone clusters, the operator-deployed StatefulSets and the copies bundled inside other stacks that an application inventory records under the surrounding product's name rather than MinIO's. Widen the sweep to any further product only where a verified source identifies it as carrying the same MinIO code; do not silently assume the vulnerable path is confined to instances someone has already labelled MinIO.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-09-19, active_exploitation 'confirmed', poc_available true, cvss 8.8, rwep_score 67. patch_available true; the vector names the fix as 'This issue has been patched in RELEASE.2023-03-20T20-16-18Z', which precedes the KEV date the same packet records. affected_versions: 'MinIO before RELEASE.2023-03-20T20-16-18Z'. patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' active_exploitation_notes: 'exploited in the wild and frequently chained with CVE-2023-28432 to escalate from limited credentials to arbitrary object writes on internet-exposed MinIO consoles. KEV ransomware status: unknown.' AU-Essential-8-Patch gap: 'Patch-application maturity is the real fix; the control is unmet on the many self-hosted MinIO deployments that lag releases.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management assumes prompt upgrade to RELEASE.2023-03-20T20-16-18Z; unpatched, internet-exposed MinIO instances remain exploitable.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This CVE has two stated exploit preconditions rather than one — the packet requires credentials carrying arn:aws:s3:::* and Console API access enabled — and the vector also records a MINIO_BROWSER workaround, so a MinIO instance can sit in a state that is neither exploitable-as-shipped nor upgraded. That state has to be recorded as its own verdict with a dated action to reach RELEASE.2023-03-20T20-16-18Z, not folded into 'patched per SLA'. Two cautions bind the mitigation half here. First, the workaround sentence as recorded in the packet reads 'As a workaround, enable browser API access and turn off `MINIO_BROWSER=off`', which is self-contradictory as written, so the exact setting must be taken from the vendor advisory and not from that line; what the packet does state unambiguously is that the attack requires Console API access enabled, so removing Console API reachability removes one named precondition. Second, that removal holds only while it stays in force and only where operators do not need the console: it does not repair the metadata bucket-name check, and it evicts nothing already written. The exploitation primitive the packet describes is writing objects into arbitrary buckets, so objects placed before the mitigation went on remain in those buckets — an instance that was internet-exposed with the console enabled needs its bucket contents compared against a known-good baseline rather than being closed on a configuration change. The second precondition, the wildcard arn:aws:s3:::* grant, is not something this control touches at all; the least-privilege and access-enforcement gaps cited on this entry stay open, and a network-security attestation continues to pass cleanly while a deliberately exposed console is reached with valid over-privileged credentials, which is precisely why the exposed-with-mitigation state must be visible as residual risk instead of as a green row.",
+        "evidence": "Packet vector: 'an attacker can use crafted requests to bypass metadata bucket name checking and put an object into any bucket while processing `PostPolicyBucket`. To carry out this attack, the attacker requires credentials with `arn:aws:s3:::*` permission, as well as enabled Console API access.' and 'As a workaround, enable browser API access and turn off `MINIO_BROWSER=off`.' live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' NIS2-Art21-network-security gap: 'Network-security measures do not help when the Console API is deliberately exposed and reached with valid (over-privileged) credentials.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management assumes prompt upgrade to RELEASE.2023-03-20T20-16-18Z; unpatched, internet-exposed MinIO instances remain exploitable.' NIST-800-53-AC-6 gap records the wildcard grant as 'a common default'. cisa_kev true (2023-09-19), active_exploitation 'confirmed', poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2022-22265": {
     "name": "Samsung Mobile Devices Use-After-Free Vulnerability",
@@ -54160,7 +56212,31 @@
         "adequate": false,
         "gap": "Patch maturity is unattainable for unmaintained embedded firmware; device replacement is the only remediation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet carries the two facts this control exists to resolve per unit, and they point in opposite directions: a patch is recorded as available, while the affected field states that numerous affected devices are end-of-life without fixed firmware. The flaw is in the Realtek SDK's miniigd UPnP SOAP service as shipped inside OEM router and IoT firmware, so whether a fix exists is a per-model question that has to be answered from each OEM rather than assumed either way across the estate. Scope the inventory to what the packet names — every router or IoT device whose firmware embeds the Realtek SDK miniigd service, across OEMs, with the packet naming D-Link among others — rather than to one vendor's model line, because an inventory built by brand misses the same embedded component under a different badge. Units whose OEM shipped fixed firmware are patch items, and the packet records no live-patch mechanism and a reboot as part of applying the fixed release, so such a unit is not remediated until it has come back up running the new firmware. Units whose model has no fixed firmware cannot be patched at all: for those the terminal state is replacement on a dated schedule, because a risk acceptance with no removal date leaves a device carrying a public exploit, an EPSS the packet puts at roughly 0.9998 and exploitation confirmed in the wild through 2023 in service indefinitely — and that device is exposed not only to this command-injection flaw but to everything found in its unmaintained firmware since. Precondition, which is where this control is normally over-claimed: an inventory is what makes action possible, it is not itself a mitigation, and the packet's exploit needs nothing more than the ability to send a crafted NewInternalClient SOAP request to the miniigd service. On ISP-provided CPE the operator may hold neither the firmware decision nor the configuration, in which case the replacement item is a conversation with the provider rather than a maintenance task, and recording it as an internal patch backlog item misstates who can act. Because exploitation is confirmed and the packet records this flaw as a staple of Mirai- and Gafgyt-class botnet recruitment, a unit that was reachable during the exposure window should be rebuilt from a known-good firmware image and re-provisioned rather than closed out on a firmware version number.",
+        "evidence": "Packet facts only: CWE-77; vector 'The miniigd SOAP service in Realtek SDK allows remote attackers to execute arbitrary code via a crafted NewInternalClient request, as exploited in the wild through 2023'; affected 'Devices embedding the Realtek SDK miniigd UPnP SOAP service ... Reachable across many OEM routers/IoT (e.g., D-Link and others); numerous affected devices are end-of-life without fixed firmware'; affected_versions 'Realtek SDK (miniigd UPnP service) as shipped in affected OEM router/IoT firmware'; cisa_kev true, kev_date 2023-09-18, active_exploitation confirmed, poc_available true, RWEP 79 / CVSS 9.8; active_exploitation_notes 'EPSS ~0.9998 ... a staple of Mirai/Gafgyt-class IoT botnets'; patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting'; the SI-2 gap 'Many affected consumer/embedded devices are end-of-life with no vendor firmware; flaw remediation has no patch to apply'; the ISO A.8.8 gap 'cannot inventory or patch the Realtek SDK buried in third-party OEM firmware across heterogeneous SOHO hardware'; the Essential Eight gap 'device replacement is the only remediation'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this Realtek SDK flaw the estate splits into exactly the three states this control requires be told apart, and the packet supplies the split. A device whose OEM shipped fixed firmware and has been rebooted onto it is the patched state. A device with no fixed firmware whose WAN-side access to the miniigd UPnP/SOAP port has been blocked is the mitigation-active state — the packet's own framing is that network-security controls are the only realistic defense — and the requirement here is that such a device is recorded as an active compensating control carrying a dated replacement action, never as patched per SLA, because nothing about the vulnerable code has changed and the crafted NewInternalClient request still executes if it arrives. A device with neither is full exposure and has to be scored that way rather than absorbed into a patch-compliance percentage, which is the specific way this CVE disappears from a compliance report while remaining exploitable. Precondition on the mitigation-active state, which is where it gets over-recorded: blocking WAN-side reachability removes the internet-facing route the packet attributes to Mirai- and Gafgyt-class botnet recruitment, but it removes nothing for a caller already on the device's own network, which is where the UPnP service is intended to answer — so a compromised host inside the LAN reaches the unauthenticated path unimpeded, and a device already enrolled in a botnet is not recovered by closing the WAN side. The packet also records that default configurations and ISP-provided CPE frequently leave the service WAN-reachable, so on a unit whose configuration the operator does not control, the mitigation-active state is not available at all and the honest verdict is full exposure. The distinguishing test is per device and from outside: probe the unit's WAN address for the UPnP/SOAP service and confirm nothing answers — a fleet record asserting that UPnP is disabled is a statement about intended configuration, not a demonstration that the port is closed.",
+        "evidence": "Packet facts only: patch_available true, patch_required_reboot true, live_patch_available false ('remediation requires applying the fixed release and rebooting'); affected 'numerous affected devices are end-of-life without fixed firmware'; the SC-7 gap 'Boundary protection must block WAN-side access to the UPnP/SOAP port; default configs and ISP-provided CPE frequently leave it reachable'; the NIS2 network-security gap 'Network-security controls are the only realistic defense (block WAN-side UPnP/SOAP), yet many devices expose the service to the WAN by default'; the UK-CAF-B4 gap 'the durable defense is blocking WAN-side UPnP/SOAP access to the miniigd service; the control does not compel that egress/ingress hardening, and default CPE configs leave the command-injection port reachable'; attack_vector 'A remote, unauthenticated attacker sends a crafted UPnP SOAP NewInternalClient request to the Realtek miniigd service ... typically enrolling the device in a botnet'; active_exploitation confirmed with poc_available true and KEV listing 2023-09-18.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2017-6884": {
     "name": "Zyxel EMG2926 Routers Command Injection Vulnerability",
@@ -54580,7 +56656,27 @@
         "adequate": false,
         "gap": "Technical-vulnerability management periodicity does not cover the NTLM-relay hardening (SMB signing, Extended Protection for Authentication) that turns a leaked hash from a breach into a non-event."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation of this CVE requires the victim to receive an attacker-crafted Word/Office document containing an external reference, so on an estate that has not yet reached the fixed release the delivery path is the enforceable control. Bound to this product: documents arriving by mail, web download or untrusted file share carry an untrusted-origin marking applied at the boundary, that marking survives the container the document is delivered in so a file extracted from an archive or renamed on the way still arrives marked, and an externally-sourced document opens into the isolated reduced-privilege render rather than the full parsing path that follows the external reference outbound. Scope this to what the packet's affected_versions names, which is four products on four update tracks — Microsoft 365 Apps for Enterprise, Office 2019, Office LTSC 2021 and Word 2013 Service Pack 1 — and note why that matters here: those tracks reach their fixed builds at different times, and the ingress marking is the single measure that applies identically to all four while they do, because it acts before the document reaches any of them. The distinguishing test is delivery-side: send an externally-sourced document through each ingress path — mail, web, file share, and nested inside an archive — and confirm it arrives marked as externally sourced, rather than confirming only that a policy for marked documents exists. Preconditions, and the first is the one that decides whether this control is worth anything on this CVE. The packet records that the forced authentication fires on open OR on a Preview-pane render, so a measure that acts on the user's open action does not by itself cover the preview path; the estate must be able to demonstrate that the preview render is governed by the same untrusted-origin decision, and where it cannot, preview rendering of externally-sourced documents has to be turned off — the packet's own application-hardening gap names disabling the Preview Pane as a mitigating measure for exactly this reason. Second, provenance marking bounds which documents reach the vulnerable parsing path; it does not stop a document that reaches it from forcing the outbound authentication, and it does nothing for a document arriving through a channel that applies no marking. This is a holding measure. The remediation the packet records is the vendor fixed release, with live_patch_available false and live_patch_notes stating there is no vendor live-patch mechanism. patch_required_reboot is false, which means no machine restart — it does not mean the fix is live on an Office process that is already running, which keeps executing the build it started with, so measure completion per track on the version the running Word or Office process reports.",
+        "evidence": "All from the packet for CVE-2023-36761: affected states 'Microsoft Word / Office document parsing; a crafted document (openable or Preview-pane-rendered) forces an outbound authentication that discloses the victim's NTLM hash.' attack_vector states a crafted Word/Office document contains an external reference that forces the client to authenticate outbound (SMB/WebDAV) to an attacker-controlled server on open or Preview-pane render, disclosing the victim's NetNTLM hash for relay or offline cracking. active_exploitation_notes states it was exploited in the wild as a zero-day patched by Microsoft in September 2023, that opening — or merely previewing in the Preview Pane — a crafted document forces the outbound authentication, and that CISA added it to KEV on 2023-09-12. affected_versions lists Microsoft 365 Apps for Enterprise, Microsoft Office 2019, Microsoft Office LTSC 2021, and Microsoft Word 2013 Service Pack 1. cwe_refs CWE-20, cvss 6.5, rwep_score 50, poc_available false. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' The AU-Essential-8-App-Hardening gap states application hardening (disabling the Preview Pane, blocking outbound SMB, enforcing SMB signing) is the mitigating control the KEV entry does not require, and that patching alone left the Preview-pane vector live until applied.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry is unusual in that the packet itself enumerates the compensating measures and states what they achieve: the application-hardening gap names disabling the Preview Pane, blocking outbound SMB and enforcing SMB signing, and the technical-vulnerability-management gap describes NTLM-relay hardening — SMB signing and Extended Protection for Authentication — as what turns a leaked hash from a breach into a non-event. Read precisely, that is a statement about what an attacker can do with the NetNTLM hash, not about whether the hash leaves the host: the crafted document still forces the outbound authentication when it is opened or previewed, and the disclosure still occurs. A hardened estate is therefore in a compensating state, not a remediated one, and this control exists to keep those two apart in the record. Applied to this CVE, it means the compliance verdict is carried per Office update track and distinguishes three states: the vendor fixed release applied and the running Office process reporting a fixed build; relay and preview hardening active while that release is still pending on this track; and neither. The middle state is recorded as a compensating-control state with a dated action item, never as patched per SLA. Per-track is the load-bearing part, because the packet's affected_versions names Microsoft 365 Apps for Enterprise, Office 2019, Office LTSC 2021 and Word 2013 Service Pack 1 — four products on separate update tracks — and a single estate-wide 'hardening in place' verdict is exactly how a track that never reached the fixed release gets closed out while it keeps leaking the hash on the first crafted document a user previews. The distinguishing test is to ask the vulnerability-management record to produce, per track, which of the three states that track is in and the date its middle-state action item comes due; a record that reports one verdict for 'Office' cannot answer it. Precondition: this control governs how the state is recorded and tracked — it does not itself apply the hardening, and it does not remediate. The packet records no live-patch mechanism and states remediation requires applying the vendor fixed release, so that release is the only thing that moves a track out of the middle state; and because active exploitation is confirmed and the disclosure is silent, a hash disclosed while a track sat in the middle state stays valid to an attacker until the affected credential is changed.",
+        "evidence": "All from the packet for CVE-2023-36761: the ISO-27001-2022-A.8.8 gap states 'Technical-vulnerability management periodicity does not cover the NTLM-relay hardening (SMB signing, Extended Protection for Authentication) that turns a leaked hash from a breach into a non-event.' The AU-Essential-8-App-Hardening gap names disabling the Preview Pane, blocking outbound SMB and enforcing SMB signing as the mitigating control the KEV entry does not require. affected_versions lists Microsoft 365 Apps for Enterprise, Microsoft Office 2019, Microsoft Office LTSC 2021 and Microsoft Word 2013 Service Pack 1. attack_vector states the crafted document forces the client to authenticate outbound (SMB/WebDAV) to an attacker-controlled server on open or Preview-pane render, disclosing the NetNTLM hash for relay or offline cracking. cisa_kev true, kev_date 2023-09-12, active_exploitation confirmed. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-36802": {
     "name": "Microsoft Streaming Service Proxy Privilege Escalation Vulnerability",
@@ -54785,7 +56881,39 @@
         "adequate": false,
         "gap": "Response and recovery planning is not scoped for targeted commercial-spyware zero-click intrusions that demand vendor-assisted forensics."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The delivery path the packet records for this Wallet flaw is a maliciously crafted attachment processed for arbitrary code execution with no user interaction, as the second half of the BLASTPASS chain with CVE-2023-41064 that installed Pegasus. Nothing about that path involves a user decision, so on this entry the reduced-attack-surface half of the control is the only lever that operates before the fixed build lands. For the population the organisation assesses as plausibly inside the targeting set for a mercenary-spyware chain, place devices in Apple's reduced-attack-surface mode so message attachments and link previews are not processed automatically, narrowing the route into the Wallet validation flaw during the window that opened before disclosure and closed only when the fixed release and its reboot completed across those devices. Scope by the packet's affected list rather than by handset: iOS and iPadOS below 16.6.1 and watchOS below 9.6.2. This has to be a standing posture assigned before the next disclosure, not a reaction to the 2023-09-11 KEV listing, because the mode only helps if it was already on when the chain arrived, and this chain was in use before Apple shipped the fix. Precondition, stated plainly: the mode narrows delivery, it does not repair the validation flaw and it does not evict an implant on a device that was already exploited. The packet records execution with no user interaction and Citizen Lab discovering the chain in the wild, so a device assessed as having received the attachment belongs on the forensic path, and the fixed release plus the reboot the packet requires remains the remediation for every device regardless of the mode.",
+        "evidence": "Packet vector: 'A validation issue was addressed with improved logic. This issue is fixed in watchOS 9.6.2, iOS 16.6.1 and iPadOS 16.6.1. A maliciously crafted attachment may result in arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.' active_exploitation_notes: 'Zero-click zero-day discovered by The Citizen Lab as the second half of the BLASTPASS chain (with CVE-2023-41064) delivering NSO Group's Pegasus.' AU-Essential-8-Patch gap: 'Patch maturity cannot cover a flaw exploited before a fix exists; Apple's Lockdown Mode was the effective pre-patch mitigation and is not framework-mandated.' ISO-27001-2022-A.8.8 gap: the periodic control 'offers no protection during in-the-wild use and does not mandate the Lockdown-Mode mitigation that actually blunts it.' NIST-800-53-SI-2 gap: 'the Wallet validation fix shipped only after in-the-wild use, so SI-2 SLAs offer no protection during exploitation.' affected_versions: 'iOS/iPadOS < 16.6.1', 'watchOS < 9.6.2'. cisa_kev true, kev_date 2023-09-11, cvss 7.8, rwep_score 60, poc_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The enforced target for this CVE is the packet's own fixed builds, iOS and iPadOS 16.6.1 and watchOS 9.6.2, driven from the 2023-09-11 KEV listing with user deferral disallowed. Two scoping details decide whether the enforcement is real. First, the packet names watchOS as an affected platform alongside iOS and iPadOS and gives watchOS 9.6.2 as its own fixed build, so an estate that measures only iPhone and iPad builds reports itself clean while the watch population is unmeasured; each platform must be counted against its own fixed build. Second, the packet records no vendor live-patch mechanism and remediation that requires applying the fixed release and rebooting, so completion is the build a device reports after that restart. A device that downloaded 16.6.1 and has not restarted is still executing the vulnerable Wallet code, and on personal-feeling devices the restart is exactly the step users defer, so a deferral recorded as patched is the specific way this remediation goes wrong. Precondition: this control addresses only the residual population after Apple shipped the fix. It cannot close the pre-disclosure window that the flaw-remediation gap on this entry actually names, because the chain was in use before the release existed, and it reaches only enrolled devices. It is also a remediation control and not a containment one: pushing 16.6.1 to a device that was already exploited closes the entry path without addressing what was installed through it, which is why that device needs the forensic route instead of being closed on its build number.",
+        "evidence": "Packet affected_versions: 'iOS/iPadOS < 16.6.1', 'watchOS < 9.6.2'. live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' patch_available true, patch_required_reboot true, live_patch_available false. cisa_kev true, kev_date 2023-09-11, active_exploitation confirmed. NIST-800-53-SI-2 gap: 'Flaw remediation cannot pre-empt a zero-click zero-day used to deliver Pegasus; the Wallet validation fix shipped only after in-the-wild use, so SI-2 SLAs offer no protection during exploitation.' affected: 'Apple Wallet on iOS, iPadOS and watchOS; a maliciously crafted attachment exploits a validation flaw to execute code. Chained with CVE-2023-41064 (BLASTPASS).'",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet records this as a zero-click zero-day found by The Citizen Lab as the second half of the BLASTPASS chain delivering NSO Group's Pegasus, and it records why ordinary handling fails on it: incident handling assumes detectable telemetry, a zero-click spyware chain leaves minimal evidence and requires specialised forensic acquisition to trigger the process at all, and response and recovery planning is not scoped for targeted commercial-spyware intrusions that demand vendor-assisted forensics. So what this CVE demonstrates is the need for an explicit escalation trigger on the mobile estate that routes a suspected commercial-spyware chain to specialised acquisition and vendor engagement rather than to a reimage or a wipe-and-reissue ticket, which destroys the only evidence such a chain leaves. The trigger cannot be a device-side alert, and the packet is the reason: the monitoring gap on this entry states that mobile endpoint monitoring yields little signal from a zero-click Wallet exploit. It has to be an external one, such as attribution of a chain by a research organisation, of the kind that surfaced this CVE, against a device in the packet's affected range, or an organisational assessment that a specific user is plausibly inside a mercenary-spyware targeting set. Precondition: this is a response control. It does nothing to prevent the execution and nothing to shorten the pre-fix window, and it is only actionable if the path exists before the trigger fires, which means naming in advance who performs the acquisition, with what tooling, and under what authority when the device may be personally owned rather than organisational. Escalation with no pre-arranged acquisition capability produces a wipe, and a wipe on this chain ends the investigation.",
+        "evidence": "Packet active_exploitation_notes: 'Zero-click zero-day discovered by The Citizen Lab as the second half of the BLASTPASS chain (with CVE-2023-41064) delivering NSO Group's Pegasus.' NIS2-Art21-incident-handling gap: 'Incident handling assumes detectable telemetry; a zero-click spyware chain leaves minimal evidence, requiring specialized forensic acquisition to trigger the process.' UK-CAF-D1 gap: 'Response and recovery planning is not scoped for targeted commercial-spyware zero-click intrusions that demand vendor-assisted forensics.' NIST-800-53-SI-4 gap: 'System monitoring on mobile endpoints yields little signal from a zero-click Wallet exploit, so SI-4 detection cannot reliably surface the intrusion.' attack_vector: 'A maliciously crafted attachment processed by Wallet exploits a validation flaw for code execution with no user interaction.' affected_versions: 'iOS/iPadOS < 16.6.1', 'watchOS < 9.6.2'. active_exploitation confirmed, kev_date 2023-09-11.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-D1"
+        ]
+      }
+    ]
   },
   "CVE-2023-33246": {
     "name": "Apache RocketMQ Command Execution Vulnerability",
@@ -56233,7 +58361,41 @@
         "adequate": false,
         "gap": "An organization's technical-vulnerability register scored this 5.5 and would not flag it as chain-critical; A.8.8 as normally run does not correlate a low-CVSS kernel item with an active APT zero-click chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "This Apple kernel flaw is not a standalone bug an operator can triage as an endpoint item — the packet places it as the kernel-primitive stage of the Operation Triangulation zero-click iMessage chain against iOS devices released before iOS 15.7.1, with Kaspersky documenting the abuse of undocumented hardware MMIO registers to defeat the memory-protection controller. Zero-click is the whole difficulty: there is no attachment for a user to decline and no link to leave untapped, so awareness training contributes nothing and the only pre-fix lever is refusing to process the content on arrival. For the cohort plausibly inside the targeting set this chain served, the requirement is a standing reduced-attack-surface posture on their iPhones, iPads and Macs in which message attachments, link previews, fonts and untrusted web content are not parsed automatically — assigned before the next disclosure rather than configured in response to this one, because the posture only helps if it was already on when the chain arrived. That timing is the point of the control on this entry: the packet's own flaw-remediation gap notes the exploited primitive was an undocumented hardware feature, so no remediation cadence could act until Apple shipped the fixed builds on 2023-07-24, which means the entire in-the-wild window was covered by whatever posture each device already carried. Preconditions: this narrows the delivery path into the kernel primitive, it does not remove it, and it is not available as a retroactive fix — a device compromised during the confirmed exploitation window is not remediated by enabling the posture afterwards and belongs on the incident path with its build and message history examined. It is a holding measure for the window before the fixed build and its required restart land, not a substitute for them.",
+        "evidence": "active_exploitation_notes: 'Exploited in the wild as a kernel-primitive stage of the Operation Triangulation zero-click iMessage chain against iOS devices released before iOS 15.7.1. Apple confirmed awareness of active exploitation; Kaspersky documented the abuse of undocumented hardware MMIO registers to defeat memory protection.' affected records that 'a malicious app can modify sensitive kernel state by abusing undocumented memory-mapped I/O (MMIO) registers to bypass the hardware page-protection controller'. The packet's NIST-800-53-SI-2 gap: 'The exploited primitive was an undocumented hardware feature, so no SI-2 flaw-remediation cadence could act until Apple shipped iOS 15.7.8/16.6 on 2023-07-24; devices patched only by the KEV due date (2023-08-16) stayed exposed across the entire zero-click in-the-wild window.' Its UK-CAF-B4 gap adds that 'B4 system-security assurance cannot be verified against an undocumented silicon MMIO register the vendor itself never documented.' active_exploitation is confirmed; kev_date 2023-07-26.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The scope trap on this entry sits in affected_versions, not in the vector's wording. Five Apple OS families are named — iOS/iPadOS below 15.7.8, iOS/iPadOS 16.x below 16.6, macOS Ventura below 13.5, macOS Monterey below 12.6.8, macOS Big Sur below 11.7.9, tvOS below 16.6 and watchOS below 9.6 — so an estate that enforces update policy on iPhones, iPads and Macs while never enumerating its Apple TV and Watch devices reports full compliance with two affected platforms untouched. For this CVE the control means the fixed build for each of those lines is pushed on the clock that opened with the 2023-07-26 KEV listing, with user deferral disallowed, rather than left to the device holder or to the next image refresh — the packet's Essential Eight gap records exactly this failing, that MDM update lag left devices exposed after the 2023-07-24 fix while the chain was actively deployed. Completion is measured on the build the device is running after its restart: live_patch_available is false and the packet states Apple ships no live-kernel-patch mechanism and that remediation requires installing the fixed OS build and rebooting the device, so an update downloaded and staged is not remediation and must not close the item. The trigger has to be the KEV listing rather than the score, because at CVSS 5.5 with poc_available false this ranks below routine work on a severity-sorted queue while being a live stage of a zero-click chain. Distinguishing test: report the running OS build for every enrolled iPhone, iPad, Mac, Apple TV and Watch and show each against the fixed build for its own line — a console that reports 'update policy applied', or that covers only the families the management platform was set up for, is the paper form of this control.",
+        "evidence": "affected_versions lists 'iOS/iPadOS < 15.7.8', 'iOS/iPadOS 16.x < 16.6', 'macOS Ventura < 13.5', 'macOS Monterey < 12.6.8', 'macOS Big Sur < 11.7.9', 'tvOS < 16.6', 'watchOS < 9.6'. live_patch_available is false and live_patch_notes states 'Apple ships no live-kernel-patch mechanism; remediation requires installing the fixed OS build (iOS/iPadOS 15.7.8 or 16.6, macOS Ventura 13.5, macOS Monterey 12.6.8, macOS Big Sur 11.7.9, tvOS 16.6, watchOS 9.6) and rebooting the device'; patch_required_reboot is true. cisa_kev is true with kev_date 2023-07-26 and active_exploitation confirmed; cvss is 5.5 and poc_available is false. The packet's AU-Essential-8-Patch gap: 'MDM update lag left devices exposed after the 2023-07-24 fix while the chain was actively deployed.' Its NIS2-Art21-patch-management gap: 'severity-driven patching misses low-CVSS kernel primitives that are chain-critical in real attacks.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "Half of this control applies to this Apple flaw and half does not, and the half that does not is worth stating so it is never recorded as a mitigation. The packet's trigger is an app modifying sensitive kernel state, which would ordinarily make application-install restriction the operator's lever — but the delivery it documents is a zero-click iMessage chain, so the malicious code arrives without any installation an install policy could refuse, and restricting untrusted or side-loaded applications does nothing against this path. What remains is making the fixed build a condition of access rather than a row on a report: an enrolled iPhone, iPad or Mac running below its own line's fixed build — 15.7.8 or 16.6 for iOS/iPadOS, 13.5 for Ventura, 12.6.8 for Monterey, 11.7.9 for Big Sur — is denied mail, VPN and document access until it is at or above it, instead of keeping every entitlement it had while showing as non-compliant. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually withholds access to protected resources; an estate that surfaces the stale build and leaves the access in place has recorded the exposure rather than removed it. Where a device family holds no organisational resource for the gate to withhold, the access condition has no grip and those devices — the tvOS and watchOS units affected_versions names at fixed builds 16.6 and 9.6 — must be held to the fixed build by enumeration instead, not dropped from scope because the gate cannot reach them. Precondition: because the packet requires the fixed build to be installed and the device rebooted, the condition must evaluate the build the device is running rather than the update it has downloaded, or it re-admits a device still executing the vulnerable kernel. This is a holding measure for the window before the build lands, and it does nothing for a device already compromised during the confirmed exploitation window.",
+        "evidence": "vector: 'An app may be able to modify sensitive kernel state. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.7.1', with the fix list 'macOS Monterey 12.6.8, iOS 15.7.8 and iPadOS 15.7.8, iOS 16.6 and iPadOS 16.6, tvOS 16.6, macOS Big Sur 11.7.9, macOS Ventura 13.5, watchOS 9.6'. active_exploitation_notes place delivery in 'the Operation Triangulation zero-click iMessage chain', not in a user-initiated installation. patch_required_reboot is true and live_patch_notes states remediation 'requires installing the fixed OS build ... and rebooting the device'. The packet's ISO-27001-2022-A.8.8 gap: 'An organization's technical-vulnerability register scored this 5.5 and would not flag it as chain-critical', and its AU-Essential-8-Patch gap records MDM update lag leaving devices exposed after the 2023-07-24 fix.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-35078": {
     "name": "Ivanti Endpoint Manager Mobile Authentication Bypass Vulnerability",
@@ -56355,7 +58517,38 @@
         "adequate": false,
         "gap": "A.5.15 access control is enforced by ColdFusion's own administrator authentication; CVE-2023-29298 bypasses that check via an unexpected path segment, so the documented access-control policy did not actually restrict the administrator endpoints."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "ColdFusion decides which requests may reach its administrator CFM and CFC endpoints, and this CVE is that decision failing open: the packet's attack vector is a crafted request path carrying an unexpected extra segment that defeats the access-control check, exposing administrator endpoints to unauthenticated callers with no user interaction required. Bound to this product the control means each administrator CFM/CFC endpoint authorizes its own caller rather than inheriting a verdict from the path-matching layer in front of it, and the ColdFusion administrator surface is segmented so an untrusted network caller cannot present a request to that layer at all — an internet-facing ColdFusion server should not answer administrator endpoints from the public internet whatever application content it serves. Apply this across all three product tracks the packet names, not just the one an inventory happens to list: ColdFusion 2018, 2021 and 2023 installations each carry the same administrator surface. This is also why an access-control-policy attestation passes while the flaw is live — the documented policy is enforced by ColdFusion's own administrator authentication, and the attacker never authenticates as any ColdFusion administrator, so no account model is ever consulted. Priority follows the chain rather than the 7.5 CVSS band: the packet records attackers chaining this with CVE-2023-29300 (WDDX deserialization) to reach unauthenticated RCE on internet-facing ColdFusion, so this is a code-execution precondition, not an information-exposure item. Distinguishing test: from a segment with no operational need to administer ColdFusion, request each administrator CFM/CFC endpoint on a staging instance — including with extra path segments appended — and confirm each is refused before the endpoint runs. Precondition: the endpoint-side check is what Adobe's update repairs; segmentation is the operator-side lever until that update and its follow-up land, and it bounds who can send the crafted request without repairing the check, so any caller inside a permitted segment still reaches it.",
+        "evidence": "Packet vector: ColdFusion 2018u16 and earlier, 2021u6 and earlier and 2023.0.0.330468 and earlier are affected by an Improper Access Control vulnerability resulting in a security feature bypass; an attacker could leverage it to access the administration CFM and CFC endpoints, and exploitation does not require user interaction. attack_vector: a crafted request path with an unexpected extra segment defeats ColdFusion's access-control check, exposing administrator CFM/CFC endpoints to unauthenticated callers, after which attackers chain the WDDX deserialization flaw CVE-2023-29300 for remote code execution. CWE-284; CVSS 7.5; RWEP 68; poc_available true; CISA KEV 2023-07-20 with confirmed active exploitation. affected_versions: ColdFusion 2018 <= Update 16, 2021 <= Update 6, 2023 <= 2023.0.0.330468. The packet's UK-CAF-B4 gap states CAF B4 assumes the admin console is authentication-gated and that this flaw let unauthenticated requests reach administrator endpoints; its ISO-27001-2022-A.5.15 gap states access control is enforced by ColdFusion's own administrator authentication, which the CVE bypasses via an unexpected path segment, so the documented policy did not actually restrict the administrator endpoints.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.5.15"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This entry is the case the control names. The packet records that Adobe's initial fix was incomplete and required a follow-up update, and that first-pass remediation left the access-control bypass exploitable until that follow-up landed. For ColdFusion that means the vulnerability-management record cannot treat 'the July update was applied' as closure: the closing evidence is the build each running ColdFusion instance reports, measured against both the initial update the packet names for its track — 2018 Update 17, 2021 Update 7, 2023.0.0.1 — and the follow-up fix that completed it, with every server re-verified after the follow-up rather than only after the first pass. It also sets what the operator should expect next on this surface. A bypass reachable by appending an unexpected segment to the request path, whose first vendor fix did not fully close it, points at the path-handling layer itself rather than one endpoint, so further bypasses against the same primitive are a live expectation: the administrator-endpoint segmentation should be retained past the update rather than removed once the patch record reads clean. Distinguishing test: after applying the update, re-issue the crafted extra-path-segment request against an administrator CFM/CFC endpoint on a staging ColdFusion instance instead of reading the installed update level — an estate that verified only the first patch carried a clean flaw-remediation record while the bypass still worked, which is exactly the failure this control exists to catch.",
+        "evidence": "live_patch_notes: 'No live-patch mechanism; remediation requires Adobe's ColdFusion update (2018 Update 17, 2021 Update 7, 2023.0.0.1) plus the follow-up fix that completed the incomplete initial patch.' active_exploitation_notes: Adobe's initial fix was incomplete and required a follow-up update, and attackers chained the flaw with CVE-2023-29300 to achieve unauthenticated RCE on internet-facing ColdFusion within days of Adobe's July 2023 patch. The packet's NIST-800-53-SI-2 gap states that Adobe's APSB23-40 fix was initially incomplete, so flaw remediation applied on the first patch still left the access-control bypass exploitable until the follow-up update, and that mass exploitation began within days of the 2023-07-20 KEV listing — faster than a single-pass remediation could verify. attack_vector identifies the primitive as a crafted request path with an unexpected extra segment defeating the access-control check. patch_available true; poc_available true; active_exploitation 'confirmed'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "ColdFusion 2018 up to Update 16, 2021 up to Update 6 and 2023 up to 2023.0.0.330468 must be driven to their fixed updates on the clock that opened with the 2023-07-20 KEV listing, not on a monthly or fortnightly application cadence — the packet records mass exploitation beginning within days of that listing, a public PoC, and a chain to unauthenticated remote code execution via CVE-2023-29300. Enumerate all three tracks: an estate that updates its inventoried ColdFusion 2021 servers while a 2018 or 2023 install sits on an affected build still answers the crafted request. The clock does not stop at the first update — live_patch_available is false and the packet states remediation is Adobe's ColdFusion update (2018 Update 17, 2021 Update 7, 2023.0.0.1) plus the follow-up fix that completed the incomplete initial patch, so the SLA has to carry through the follow-up on every server rather than closing when the first pass is recorded. patch_required_reboot is false, which means there is no host reboot to schedule; it does not mean the fixed code is executing when the installer exits, so completion is measured on the build each running ColdFusion instance reports. And because active exploitation is confirmed and the chained outcome is code execution in the ColdFusion context, an internet-facing server that ran an affected build during the window belongs on the incident path — reviewing what was placed or executed through the administrator endpoints — rather than being closed on the update record.",
+        "evidence": "cisa_kev true with kev_date 2023-07-20; active_exploitation 'confirmed'; CVSS 7.5; RWEP 68; poc_available true; ai_discovered false; patch_available true; patch_required_reboot false; live_patch_available false. live_patch_notes: 'No live-patch mechanism; remediation requires Adobe's ColdFusion update (2018 Update 17, 2021 Update 7, 2023.0.0.1) plus the follow-up fix that completed the incomplete initial patch.' affected_versions: Adobe ColdFusion 2018 <= Update 16, Adobe ColdFusion 2021 <= Update 6, Adobe ColdFusion 2023 <= 2023.0.0.330468. active_exploitation_notes: added to KEV 2023-07-20 amid active exploitation; attackers chained it with CVE-2023-29300 to achieve unauthenticated RCE on internet-facing ColdFusion within days of Adobe's July 2023 patch. The packet's AU-Essential-8-Patch gap states the two-week patch SLA for internet-facing applications was too slow because the preauth bypass was chained to RCE and exploited within days of the 2023-07-20 KEV date; its NIS2-Art21-patch-management gap states a monthly cadence leaves internet-facing ColdFusion exposed during the days-long window between the July 2023 disclosure and the emergency patching active exploitation demanded.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-38205": {
     "name": "Adobe ColdFusion Improper Access Control Vulnerability (CVE-2023-38205)",
@@ -56416,7 +58609,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management presumes tracking and applying vendor fixes closes exposure, but the superseded fix left the admin endpoints reachable; the control needed to recognize the patch-bypass relationship to CVE-2023-29298 and re-remediate before near-immediate exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This Adobe ColdFusion flaw is the second CVE on one primitive and the packet states the relation outright: CVE-2023-38205 is recorded as a bypass of the CVE-2023-29298 fix, reinstating unauthenticated reach to the ColdFusion administrator's CFM and CFC endpoints. For this product the control means a ColdFusion server that already took the earlier update is not carried forward as remediated — the earlier ticket's evidence proves nothing about this CVE — and that a second bypass of the same access-control check is ranked on the expectation that a third is likely, rather than as a discrete 7.5-rated item. Scope the sweep from the packet's affected list, not from the headline product name: three separate release trains are named (ColdFusion 2018 Update 18 and earlier, 2021 Update 8 and earlier, 2023 Update 2 and earlier), each with its own fixed update recorded in the packet as 2018u19, 2021u9 and 2023u3 or later in APSB23-47, so an estate that updates only its ColdFusion 2023 servers leaves the 2018 and 2021 installs fully exposed behind a remediation report that reads clean. Measure completion on the build the running service is executing: the packet records no live-patch mechanism and requires a restart of the ColdFusion service after the upgrade, so a server whose files were replaced but whose service was never restarted is still running the pre-fix code — patch_required_reboot being false means no host reboot is needed, not that the fix is live. The clock is the KEV listing of 2023-07-20 against a 2023-08-10 due date, and the packet records exploitation within days of disclosure against internet-facing servers, so the re-remediation runs ahead of that due date rather than to it. Finally, keep the second half of the chain in scope: the packet's exploitation path reaches code execution by combining admin-endpoint reach with deserialization primitives, and the packet records Adobe recommending the associated lockdown and serial-filter guidance alongside the update — the update closes the access-control bypass, that guidance constrains what the bypass was being chained into.",
+        "evidence": "Packet facts only: CWE-284; cisa_kev true with kev_date 2023-07-20 and a 2023-08-10 due date; active_exploitation confirmed; poc_available true; RWEP 68 / CVSS 7.5; active_exploitation_notes 'Actively exploited within days of disclosure in July 2023 as the access-control bypass that reinstated attacker reach to admin endpoints after the incomplete CVE-2023-29298 fix; EPSS sits at ~0.998'; affected_versions 'ColdFusion 2018 Update 18 and earlier', 'ColdFusion 2021 Update 8 and earlier', 'ColdFusion 2023 Update 2 and earlier'; patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation requires upgrading to the fixed ColdFusion builds in APSB23-47 (2018u19, 2021u9, 2023u3 or later) and restarting the ColdFusion service. Adobe also recommends applying the associated lockdown/serial-filter guidance.'; attack_vector 'combined with deserialization primitives this yields remote code execution on internet-facing servers'; the SI-2, ISO A.8.8, NIS2 patch-management and Essential Eight gap statements, each of which names the incomplete-fix relationship to CVE-2023-29298.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The ColdFusion administrator access-control check is where the product decides whether a caller may reach administrative functionality, and this CVE is that check failing open: the packet places the defect in the ColdFusion administrator interface as an improper access control (CWE-284) and has an unauthenticated caller reaching administrative CFM and CFC endpoints through a crafted request, with the vector stating that exploitation does not require user interaction. Bound to this product the control means each administrative CFM and CFC endpoint makes its own authorization decision rather than inheriting a verdict from the check that fronts it, and the ColdFusion Administrator surface is segmented so a caller on an untrusted network cannot present a request to that check at all — the packet records exploitation against internet-facing ColdFusion servers, which is precisely the deployment where the front check is the only thing in the path. Distinguishing test: from an external address and from an internal segment with no operational need for the ColdFusion Administrator, issue unauthenticated requests to administrative CFM and CFC endpoints on a staging server and confirm each is refused before the endpoint runs; a system-security attestation recording that 'administrator access is restricted' passes cleanly while this path stays open, because the restriction being attested to is the check the CVE bypasses. Precondition, stated rather than assumed: the endpoint-side authorization is a property the APSB23-47 update establishes — this control says what to verify, it does not implement it. Until that update and the ColdFusion service restart the packet requires have both landed, restricting which networks can reach the Administrator bounds who can send the crafted request but leaves the bypass fully usable from inside any permitted segment, and it is not available at all where the Administrator has to stay reachable for operations. And because exploitation is confirmed and a public PoC exists, a server that was internet-reachable during the window is a triage item rather than a patch item: the packet's path continues from admin-endpoint reach into code execution via deserialization primitives, so the update removes the reach without removing anything an attacker already placed.",
+        "evidence": "Packet facts only: CWE-284; affected 'Adobe ColdFusion administrator interface, where an improper access-control check allows unauthenticated reach to administrative CFM and CFC endpoints (a bypass of the CVE-2023-29298 fix)'; vector 'An attacker could leverage this vulnerability to access the administration CFM and CFC endpoints. Exploitation of this issue does not require user interaction.'; attack_vector 'A crafted request bypasses the ColdFusion administrator access-control check, letting an unauthenticated attacker reach admin CFM/CFC endpoints; combined with deserialization primitives this yields remote code execution on internet-facing servers.'; active_exploitation confirmed, poc_available true, cisa_kev true (2023-07-20); the UK-CAF-B4 gap statement 'hardening of the ColdFusion administrator surface is undermined because the access-control filter itself is bypassable; restricting admin functionality does not stop unauthenticated reach to CFM/CFC endpoints until APSB23-47 is applied'; live_patch_notes recording the APSB23-47 builds and the required ColdFusion service restart.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-36884": {
     "name": "Microsoft Windows Search Remote Code Execution Vulnerability",
@@ -57339,7 +59555,30 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management for a mobile estate cannot force the modem-driver fix onto devices lacking SMR Oct-2021; the input-validation flaw remains a local DoS until the OEM update lands on each handset."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "On Samsung handsets the fix for this flaw is not a component update but a whole OEM security-maintenance release: the packet's remediation is Samsung SMR Oct-2021 Release 1 or later installed via the device OTA, which reboots the handset, with no live-patch mechanism for the modem interface driver. Enterprise levers stop at that OTA boundary, so the fixed maintenance level has to function as an access condition — a handset reporting a security-maintenance level below SMR Oct-2021 Release 1 is denied mail, VPN and document access — rather than surfacing as a stale row on a patch-compliance report while the device keeps its access. The distinguishing test is to enrol a Samsung device pinned below SMR Oct-2021 Release 1 and confirm the policy actually refuses it protected resources; an estate that reports the level without enforcing it has recorded the exposure rather than removed it. Precondition: the packet states the exploit needs a local process holding the radio permission, so restricting which applications may be installed and which hold that permission narrows who can reach the modem interface driver — but it does not remove an application already installed and already holding it, and a handset suspected of running one belongs on the incident path, not the install-policy path. Second precondition: this access condition does not repair the driver. patch_required_reboot is true and the packet's own remediation path reboots the handset, so a device that has downloaded the OTA but not restarted onto it is still executing the unvalidated format-string path and must be counted as exposed.",
+        "evidence": "Packet fields for this entry: vector — 'Assuming radio permission is gained, missing input validation in modem interface driver prior to SMR Oct-2021 Release 1 results in format string bug leading to kernel panic'; affected_versions 'Samsung mobile devices prior to SMR Oct-2021 Release 1'; patch_available true with patch_required_reboot true and live_patch_available false; live_patch_notes 'No live-patch mechanism for the modem interface driver; remediation requires installing Samsung SMR Oct-2021 Release 1 or later via the device OTA update, which reboots the handset'; active_exploitation confirmed, CISA KEV 2023-06-29; active_exploitation_notes 'Requires a local process holding the radio permission; exploitation produces a kernel panic (device crash/DoS) rather than code execution'. The ISO-27001-2022-A.8.8 gap records that vulnerability management 'cannot force the modem-driver fix onto devices lacking SMR Oct-2021', and the UK-CAF-B4 gap records that the hardening baseline 'assumes drivers validate their input'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The two dates on this entry make the enforcement case unusually plain: the fixed release is SMR Oct-2021 Release 1 and the KEV listing is 2023-06-29, so across most of a fleet the OEM update had been publishable for a long stretch before the KEV clock opened, and what stayed exposed were handsets on which the OTA was simply never taken. Bound to this CVE the control means the device-management policy drives the security-maintenance level itself on the KEV clock — the available OTA installed and the handset restarted inside the enforced window, user deferral disallowed — with completion measured by the maintenance level each device reports after restart rather than by an 'update pushed' status, because patch_required_reboot is true and the packet's remediation path reboots the handset. Precondition, and it is the whole reason this entry's flaw-remediation gap exists: enforcement can only install what the OEM and carrier have actually published for that model. The packet records the fix as sitting outside the enterprise's direct patch control and the flaw as staying exploitable on any device that never received SMR Oct-2021, so where no OTA carrying that release exists for a handset there is nothing for the policy to install, and the minimum-maintenance-level access condition is the only lever left on that device. An enforced-SLA dashboard that shows such a handset as 'pending' is describing a device the policy will never remediate.",
+        "evidence": "Packet fields for this entry: kev_date 2023-06-29 with active_exploitation 'confirmed'; affected_versions 'Samsung mobile devices prior to SMR Oct-2021 Release 1'; patch_required_reboot true, live_patch_available false, live_patch_notes naming the SMR Oct-2021 Release 1 OTA that reboots the handset. The NIST-800-53-SI-2 gap records 'the multi-month gap between the October 2021 fix and the 2023-06-29 KEV listing shows how long unpatched Samsung devices remained exposed', and the NIS2-Art21-patch-management gap records that the flaw 'stayed exploitable on any device that never received SMR Oct-2021, outside the enterprise's direct patch control'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2021-25394": {
     "name": "Samsung Mobile Devices Race Condition Vulnerability (CVE-2021-25394)",
@@ -58063,7 +60302,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management often omits infrastructure-monitoring appliances from the primary asset inventory, so CVE-2023-20887 could remain unpatched on a 9.8 preauth-RCE path well after the KEV due date."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet gives two dates and the clock must run from the earlier: VMSA-2023-0012 shipped 2023-06-07 and CISA listed the CVE on 2023-06-22, with public PoCs and a Metasploit module in between. For VMware Aria Operations for Networks that means the appliance is remediated on patch availability rather than entering a queue at the KEV listing, because for this entry the exploitation was already underway when the listing arrived. Two details decide whether the requirement is actually met. First, scope: the packet's affected range is 6.x prior to the VMSA-2023-0012 patches under both product names, so an inventory keyed only to 'Aria Operations for Networks' misses installs still recorded as vRealize Network Insight, and per the packet's A.8.8 gap infrastructure-monitoring appliances are routinely absent from the primary asset inventory altogether — the appliance has to be an inventoried asset before any SLA can be applied to it. Second, completion: live_patch_available is false and the packet records that remediation requires applying the patch to the appliance, which restarts appliance services, so an appliance where the patch was staged but the services never restarted is still executing the vulnerable code and must be counted exposed. Distinguishing test: produce, per appliance, the build the running appliance reports and show it is at or above the VMSA-2023-0012 level — an estate reporting 'patch approved' or 'downloaded' passes a flaw-remediation attestation while the Thrift path stays live.",
+        "evidence": "cisa_kev true with kev_date 2023-06-22; active_exploitation confirmed; active_exploitation_notes records the KEV listing two weeks after VMSA-2023-0012 (2023-06-07) with public PoCs and a Metasploit module driving rapid opportunistic exploitation of exposed vRNI/Aria appliances; CVSS 9.8, RWEP 77, poc_available true; patch_available true, live_patch_available false, and live_patch_notes states remediation requires applying the VMSA-2023-0012 patch to the appliance, which restarts appliance services; affected_versions names 'VMware Aria Operations for Networks (vRealize Network Insight) 6.x prior to the VMSA-2023-0012 patches'; the ISO-27001-2022-A.8.8 gap records that monitoring appliances are often omitted from the primary asset inventory.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Apache Thrift servlet on Aria Operations for Networks is exactly the binary remoting endpoint this control governs: per the packet it answers without authentication, and the vulnerable code is a support-bundle path that concatenates the request's input into a shell command executed as the vRNI service account. Bound to this appliance, the requirement is that the Thrift listener accepts connections only from hosts with an operational need to speak it — the platform and collector nodes and the management network the appliance is administered from — enforced by network ACL or host firewall rather than inferred from 'the appliance is internal', and that a KEV-listed defect in that servlet is driven on an emergency clock with the appliance-service restart taken, instead of riding the routine cadence a network-monitoring appliance normally gets. The web UI is the surface operators check for exposure; the Thrift port is the one the exploit uses, and they are not the same reachability question. Distinguishing test: from a general user or server VLAN with no vRNI administration role, send Thrift requests at a staging appliance and confirm they are dropped before the servlet answers — an estate that passes vRNI role-and-permission review and keeps the appliance off the internet is still exposed if any internal segment can open that port, which is the assumption the packet's CAF B4 gap identifies as broken. Precondition: restricting reachability bounds who can send the request; it does not repair the concatenation, and every host inside the permitted segment still reaches an unauthenticated command-execution sink. It is a holding measure for the window before the VMSA-2023-0012 patch and its service restart land, not a closure.",
+        "evidence": "attack_vector: 'An unauthenticated Apache Thrift request reaches a support-bundle code path that concatenates user input into a shell command executed as the vRNI service account, giving remote code execution on the appliance'; affected records the Thrift servlet passing attacker-controlled input into an OS command reachable without authentication; the UK-CAF-B4 gap states CAF B4 assumes internal management appliances sit behind a trust boundary yet the servlet was reachable and the injection required no authentication; the NIS2-Art21-patch-management gap states network-monitoring appliances are treated as low-urgency infrastructure while this gave full RCE on a collector with broad network visibility; patch_available true, live_patch_available false, patch restarts appliance services per live_patch_notes.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Aria Operations for Networks is not a perimeter device, but the condition this control keys on is present in full: a pre-auth RCE under confirmed exploitation, with the packet recording public PoCs and a Metasploit module driving opportunistic exploitation of exposed vRNI/Aria appliances. The injection runs shell commands as the vRNI service account on the appliance itself, so the VMSA-2023-0012 patch restores the code path but removes nothing an attacker wrote to that appliance beforehand. The requirement here: for any Aria Operations for Networks / vRealize Network Insight appliance whose Thrift listener was reachable from an untrusted or semi-trusted segment during the window between the 2023-06-07 advisory and the completed patch plus appliance-service restart, the default response is exporting the configuration for review, rebuilding the appliance at the patched build, and rotating every credential configured on it — not patching in place. Where reachability during that window cannot be evidenced, the appliance is treated as exposed rather than as clean, because the absence of a record is not a record of absence. Preconditions and limits: an appliance that was genuinely unreachable from any untrusted segment throughout the window is a patch item, not a rebuild item, so this control depends on the reachability determination being made from evidence rather than assumption. And the rebuild removes appliance-resident persistence only — the packet describes this collector as already holding broad visibility into the network, so whatever an attacker learned or reached from it during the window is not undone by rebuilding it and belongs on the incident path.",
+        "evidence": "active_exploitation confirmed; active_exploitation_notes: 'Public PoCs and a Metasploit module drove rapid opportunistic scanning and exploitation of exposed vRNI/Aria appliances', with KEV listing 2023-06-22, two weeks after VMSA-2023-0012 (2023-06-07); attack_vector places command execution as the vRNI service account on the appliance; the NIS2-Art21-patch-management gap describes full RCE on 'the collector that already has broad visibility into the network'; patch_available true, live_patch_available false, and the patch restarts appliance services per live_patch_notes; the NIST-800-53-SI-2 gap records that mass exploitation was underway by the KEV listing, far inside a typical 30-day patch SLA.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2020-35730": {
     "name": "Roundcube Webmail Cross-Site Scripting (XSS) Vulnerability (CVE-2020-35730)",
@@ -58974,7 +61245,29 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management presumes a known CVE to remediate, but this was an unknown zero-day with no signature; and once known, remediation exceeded patching (appliance replacement), which a standard vuln-management workflow does not prescribe."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The Barracuda Email Security Gateway is the case this control exists for, and the packet states both halves outright: patch_available is true and Barracuda auto-applied the BNSF-36456 patch to all customer appliances, yet because implants persisted the vendor's guidance was full replacement of compromised ESG units rather than patch-in-place, with no mechanism that restores integrity of an already-backdoored appliance. So the operator's decision on an ESG is not 'is the fix applied' — the vendor applied it without them — it is 'was this unit compromised during the exposure window, and if it was, or if that cannot be shown either way, when is it being replaced'. Terminal state for an affected unit is a replaced appliance; a patched unit that carried an implant is not remediated, and recording it as patched marks a backdoored device inside the mail path compliant. Operationally: enumerate every ESG appliance that ran firmware in the 5.1.3.001 through 9.2.0.006 range (appliance form factor only, per the vector), preserve each unit's configuration and logs for forensic review before it is touched, treat credentials the appliance held or that transited it as disclosed and rotate them, and put the unit on a dated replacement schedule — a risk acceptance with no removal date leaves a device with confirmed nation-state implants brokering inbound mail indefinitely. The precondition that is most often over-claimed here: the auto-applied patch closes the .tar member-filename injection sink, but it removes nothing already installed through that sink, and the packet supplies no signature or artifact list, so 'nothing alerted' is not evidence of cleanliness. An appliance whose own telemetry the attacker controlled cannot attest to its own integrity, which is what makes replacement rather than inspection the default.",
+        "evidence": "live_patch_notes verbatim: 'Barracuda auto-applied the BNSF-36456 patch to all appliances, but because implants persisted the vendor's guidance was full replacement of compromised ESG units rather than patch-in-place; there is no live-patch mechanism that restores integrity of an already-backdoored appliance.' active_exploitation_notes: 'Exploited as a zero-day by the Chinese-nexus espionage actor UNC4841 from as early as October 2022 — roughly seven months before disclosure ... Compromise was so deep and persistent that Barracuda advised customers to fully replace affected appliances rather than rely on the patch, since implants survived remediation.' cisa_kev true, kev_date 2023-05-26, active_exploitation 'confirmed', cvss 9.8, rwep_score 74, poc_available true, live_patch_available false. affected_versions: 'Barracuda Email Security Gateway (ESG) appliance firmware 5.1.3.001 through 9.2.0.006'; the vector states 'appliance form factor only'. NIS2-Art21-patch-management gap: 'NIS2 patch-management assumes patching restores integrity ... so a patch-only SLA left compromised gateways trusted.' ISO-27001-2022-A.8.8 gap: 'once known, remediation exceeded patching (appliance replacement), which a standard vuln-management workflow does not prescribe.' AU-Essential-8-Patch gap: 'even flawless patch velocity from 2023-05-26 could not recover appliances already backdoored by UNC4841.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "UNC4841 held ESG appliances from as early as October 2022 until disclosure in May 2023 with command execution at the product's privileges, which means every log the appliance kept about that period was written on a box the attacker controlled. For an ESG the requirement is that its syslog, mail-processing records and administrative-authentication events are forwarded continuously to a collector in a separate trust zone — different management plane, different credentials — so the record of what the appliance did during an exposure window outlives the appliance. This is the control that produces the evidence the replacement decision needs: without off-appliance telemetry, 'was this unit compromised' has no answer other than replacing it. What the rule keys on has to match what the packet actually describes an exploit emitting: inbound email carrying .tar attachments whose member filenames embed shell metacharacters, and command execution through Perl's qx operator at the product's privileges, followed by persistent backdoors. So retain and alert on the gateway's own record of processed archive attachments and on outbound connections from the appliance that do not match its mail-delivery and vendor-update baseline. Do not key on the appliance crashing or on named tooling: the packet describes implants that survived remediation over roughly seven months, so a crash-oriented or signature-oriented rule would have stayed silent through the entire intrusion, and its silence would have been read as health. The precondition, stated plainly because it decides whether this control is worth anything: forwarding must have been configured before the intrusion. Telemetry cannot be retro-collected — an ESG that was never shipping logs off-box has no record of the October-2022-to-May-2023 window no matter what is enabled today, which is exactly the situation that leaves replacement as the only defensible verdict.",
+        "evidence": "attack_vector: 'An unauthenticated remote attacker emails a malformed .tar attachment whose member filenames embed shell metacharacters; the ESG fails to sanitize them (CWE-20) and passes them to Perl's qx() operator, executing arbitrary OS commands (CWE-77) with the product's privileges and installing persistent backdoors.' active_exploitation_notes place UNC4841 on the appliances 'from as early as October 2022 — roughly seven months before disclosure' through the 2023-05-26 KEV listing, with compromise 'so deep and persistent that Barracuda advised customers to fully replace affected appliances'. UK-CAF-B4 gap: 'CAF B4 secure maintenance of a network appliance did not help because the flaw is preauth (PR:N) on an internet-facing email gateway and was exploited for months before a fix existed; secure configuration cannot close a zero-day command-injection sink.' ISO-27001-2022-A.8.8 gap records it as 'an unknown zero-day with no signature'. live_patch_notes records that implants persisted through the vendor-applied patch.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-32409": {
     "name": "Apple Multiple Products WebKit Sandbox Escape Vulnerability",
@@ -59921,7 +62214,38 @@
         "adequate": false,
         "gap": "A.8.9 configuration management is undercut when default JMX/RMI remote monitoring is left on and internet-reachable; without a hardened baseline that disables or firewalls JMX, this deserialization flaw remained an unauthenticated RCE path on affected Java runtimes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "JMX over RMI is precisely the binary remoting listener this control governs: the packet places the defect in the Oracle Java SE and JRockit JMX RMI server component, which deserializes untrusted classes while handling authentication credentials, so the listener parses attacker-supplied content before any credential is validated and neither the perimeter firewall nor web-tier hardening touches it. The requirement for this entry is that the JMX/RMI port on every affected runtime is bound to loopback or reachable only from the management hosts that legitimately poll it, enforced by host firewall or network ACL rather than inferred from the application server being internal. Scope comes from affected_versions and not from the headline product name: Oracle Java SE 6u113, 7u99 and 8u77, Java SE Embedded 8u77 and Oracle JRockit R28.3.9, wherever they are installed, which the packet says includes inside the many Java middleware products that embed JMX. Distinguishing test: from a general application or user segment, open a connection to the JMX/RMI port on a staging instance of each Java product in the estate and confirm it is refused before the endpoint parses anything. A configuration baseline recorded as met while remote JMX answers from any internal segment still exposes the pre-auth deserialization path. Precondition: restricting reachability bounds who can send the serialized object, it does not repair the deserialization, so any host inside the permitted management segment, including a compromised monitoring server or jump host, still reaches the sink, and where remote JMX must stay enabled for production monitoring this control is unavailable and the runtime upgrade is the only closure. The packet records the remediation as Oracle's April 2016 Critical Patch Update applied by upgrading the Java runtime and restarting the affected JVM or application, with no live-patch mechanism; patch_required_reboot is false, but that restart is not optional, and a long-running application server keeps executing the affected runtime until it is taken through it.",
+        "evidence": "Packet affected: 'Oracle Java SE / JRockit JMX (RMI server) component, which deserializes untrusted classes when handling authentication credentials, allowing a remote attacker to affect confidentiality, integrity, and availability.' NIST-800-53-CM-7 gap: 'JMX remote monitoring over RMI is frequently left enabled and network-reachable when it need not be, and CVE-2016-3427 turns that exposed management surface into an unauthenticated deserialization RCE - disabling or localhost-binding JMX would have removed the vector entirely.' ISO-27001-2022-A.8.9 gap: 'A.8.9 configuration management is undercut when default JMX/RMI remote monitoring is left on and internet-reachable.' affected_versions: Oracle Java SE 6u113, 7u99, 8u77; Java SE Embedded 8u77; JRockit R28.3.9. active_exploitation_notes: 'because JMX is embedded in many Java middleware products, the same primitive was reused across numerous downstream products' RCE chains.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation is Oracle's April 2016 Critical Patch Update (and the JEP 290 serialization filtering in later JDK builds), applied by upgrading the Java runtime and restarting the affected JVM/application.' cvss 9.8, rwep_score 70, poc_available true, kev_date 2023-05-12.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The packet's attack path is content-level rather than reachability-level: a remote unauthenticated attacker who can connect to an exposed JMX port sends a malicious serialized object, the packet names ysoserial gadget chains as the delivery form, and the RMI server deserializes untrusted classes while handling authentication credentials. That makes the JMX port a trust boundary rather than an internal monitoring convenience, and the requirement is that the endpoint constrain what arriving content is permitted to construct instead of inheriting safety from the assumption that the management network is trusted. For this runtime the concrete expression is the serialization class filtering the packet names as part of the remediation, applied to the JMX/RMI endpoint so classes outside the expected set are refused before construction, with authentication required on the endpoint itself rather than treated as satisfied by the credential handling that is the vulnerable code here. Distinguishing test: from an unauthenticated host that can route to the JMX port on a staging instance, send a serialized object of a class the management protocol never legitimately conveys and confirm the peer is rejected before the object is constructed. A system-security attestation that records management interfaces as hardened passes cleanly while the endpoint still deserializes whatever it is handed. Precondition, and it is decisive on this entry: that filtering ships with the newer runtime the packet points at. On Java SE 6u113, 7u99, 8u77, Java SE Embedded 8u77 and JRockit R28.3.9 there is nothing to switch on, so until the runtime is upgraded and the JVM or application restarted this control states what to verify after the upgrade rather than offering a mitigation available on the affected build; the reachability restriction is the only operator-side lever in that window.",
+        "evidence": "Packet attack_vector: 'The JMX/RMI server deserializes untrusted classes when handling authentication credentials, so a remote unauthenticated attacker connecting to an exposed JMX port can send a malicious serialized object (e.g. via ysoserial gadget chains) to affect confidentiality, integrity, and availability.' UK-CAF-B4 gap: 'an exposed JMX/RMI endpoint deserializing authentication credentials without class filtering is a preauth code-execution surface that generic system-security baselines rarely close unless JMX exposure is explicitly restricted.' live_patch_notes: 'No vendor live-patch mechanism; remediation is Oracle's April 2016 Critical Patch Update (and the JEP 290 serialization filtering in later JDK builds), applied by upgrading the Java runtime and restarting the affected JVM/application.' affected_versions: Oracle Java SE 6u113, 7u99, 8u77; Java SE Embedded 8u77; JRockit R28.3.9. cwe_refs CWE-284, poc_available true, active_exploitation confirmed.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "Both patch-tracking gaps on this entry describe the same operational failure, and it is an inventory failure rather than an SLA failure: the vulnerable JMX/RMI stack is embedded inside many third-party Java products, operators cannot patch Java independently of each bundling vendor, and per-application patch tracking left hosts running 6u113, 7u99 and 8u77 long past the April 2016 Critical Patch Update, with CISA still listing the flaw as exploited when it added it to KEV on 2023-05-12. So the inventory has to record, for every Java application in the estate, the runtime it actually executes on: the private or bundled JRE shipped inside the product as well as the system-wide installation, plus Java SE Embedded and JRockit R28.3.9 deployments, which are routinely absent from an application-level software list altogether. A product-level inventory cannot answer whether an affected build is present, and that is the specific reason a patch programme scored as compliant kept running affected runtimes for years. Each recorded runtime then carries its own remediation state and its own owner: where the runtime is the operator's, upgrading it and restarting the JVM or application closes it; where the runtime is bundled by a vendor, the operator upgrading the system JRE does not remediate that product, and the entry stays open against the vendor's build. Precondition: this control makes the exposure countable, it does not reduce it. For every runtime the inventory finds that has no vendor build carrying the fix, the reachability restriction on the JMX/RMI port is what bounds the window, and the packet gives a public proof-of-concept and confirmed exploitation, so an entry left open with no dated vendor commitment is an accepted exposure rather than a pending patch.",
+        "evidence": "Packet NIS2-Art21-patch-management gap: 'the vulnerable JMX/RMI stack is embedded inside many third-party Java products; operators cannot patch Java independently of each bundling vendor, so the April 2016 fix reached fielded systems slowly and CISA still listed it as exploited in 2023.' AU-Essential-8-Patch gap: 'because the vulnerable JMX component ships inside diverse Java applications, patch tracking per application meant many hosts ran the affected 6u113/7u99/8u77 builds long past the April 2016 CPU.' active_exploitation_notes: 'because JMX is embedded in many Java middleware products, the same primitive was reused across numerous downstream products' RCE chains'; CISA added it to KEV on 2023-05-12. affected_versions: Oracle Java SE 6u113, 7u99, 8u77; Java SE Embedded 8u77; JRockit R28.3.9. patch_available true, live_patch_available false, poc_available true, active_exploitation confirmed, cvss 9.8, rwep_score 70.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2016-8735": {
     "name": "Apache Tomcat Remote Code Execution Vulnerability",
@@ -60403,7 +62727,36 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would rank this critical, but print-management servers are frequently absent from the asset register and internet-exposed on 9191/9192, so the control never scheduled the urgent patch that mass ransomware exploitation demanded."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The SetupCompleted class is where PaperCut MF/NG makes its access-control decision on this CVE, and the packet is that decision failing open: a remote unauthenticated attacker reaches the setup-wizard page through it and comes out holding an authenticated administrative session. Bound to this product, the control means each administrative function on the PaperCut application server authorizes its own caller rather than inheriting a verdict from a setup-state check that fronts it, and the administrative surface — the packet records these servers internet-exposed on 9191/9192 — answers only from a segment with an operational need to administer printing. The identity-and-access control cited as insufficient on this entry is never consulted: the attacker authenticates as no PaperCut operator, so per-account privilege scoping is bypassed rather than abused, and an attestation that every PaperCut administrator authenticates at login passes cleanly while this path stays open. Distinguishing test: from a segment with no print-administration role, issue unauthenticated requests to each administrative endpoint on a staging PaperCut instance and confirm each is refused before the function runs. Precondition: the endpoint-side authorization is a property the vendor upgrade to 20.1.7, 21.2.11 or 22.0.9 (or later) establishes — this control states what to verify, it does not implement it. Restricting admin-interface network access is the packet's documented interim mitigation and it bounds who can present the request, but it leaves the bypass fully exploitable to anything inside the permitted segment and is unavailable where the console must stay broadly reachable. patch_required_reboot is false, which means no host reboot is needed, not that the fix takes effect on an already-running service: the packet describes a service upgrade, so measure completion by the version the running PaperCut service reports, not by the installer having been run.",
+        "evidence": "Packet fields for this entry: vector — 'The specific flaw exists within the SetupCompleted class. The issue results from improper access control. An attacker can leverage this vulnerability to bypass authentication and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-18987'; attack_vector describing the unauthenticated attacker reaching the SetupCompleted setup-wizard page and obtaining an authenticated admin session; affected_versions '< 20.1.7', '21.x < 21.2.11', '22.x < 22.0.9'; patch_required_reboot false; live_patch_notes 'remediation is upgrading PaperCut MF/NG to 20.1.7, 21.2.11, or 22.0.9 (or later), a service upgrade rather than a host reboot; restricting admin-interface network access is a documented interim mitigation'. The UK-CAF-B2 gap records that the control 'presumes the admin console enforces authentication... so B2's privileged-account controls never engage before code execution'; the ISO-27001-2022-A.8.8 gap records these servers 'internet-exposed on 9191/9192'.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "PaperCut's built-in print/device scripting is the constrained user surface this control governs, and on this CVE it is the second half of the chain: the packet does not stop at the authentication bypass — having obtained an administrative session, the attacker uses the product's own scripting capability to execute arbitrary OS commands as SYSTEM. That is an administrative console feature wired directly to a SYSTEM-level operation, which is the pattern the control forbids. Applied to this product it means the command-executing operations sit behind their own authorization boundary that the console can only reach through a constrained, validated interface, so that obtaining an admin session is not the same as obtaining SYSTEM; and operationally, that the scripting capability is enabled only on servers whose printing workflow genuinely requires it. The application-hardening control cited on this entry cannot reach this: the primitive is a legitimate shipped product feature rather than malware, a macro or a browser plugin, so allow-listing and hardening leave it enabled by design. Precondition, and it is a severe one here: by the time the scripting feature is invoked the attacker already holds an administrative session, so a configuration toggle is within their reach to reverse — disabling the feature raises the cost of the SYSTEM step but does not close it, and it gives nothing at all on a server already compromised, which for this CVE is a live possibility rather than a hypothetical given the packet's record of mass exploitation within weeks by Cl0p and LockBit ransomware affiliates and the Bl00dy gang. The closure is the vendor upgrade plus restricting which networks can reach the console; this control names the architectural property the product was missing and the interim reduction, not a substitute for either.",
+        "evidence": "Packet fields for this entry: attack_vector — the attacker 'obtain[s] an authenticated admin session, then uses PaperCut's built-in print/device scripting to execute arbitrary OS commands as SYSTEM'; vector recording code execution 'in the context of SYSTEM'; active_exploitation_notes 'Mass-exploited within weeks of disclosure; used by Cl0p and LockBit ransomware affiliates and the Bl00dy gang, plus nation-state activity'. The AU-Essential-8-App-Hardening gap records that hardening 'does not contemplate disabling PaperCut's legitimate print/device-scripting feature, which is the exact primitive the exploit abuses to run commands as SYSTEM after the auth bypass — a built-in capability, not malware, so allow-listing/hardening leaves it enabled'.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This is the internet-facing pre-auth-RCE-under-active-exploitation case the control exists for, arriving on a print server rather than a firewall: the packet has PaperCut MF/NG servers exposed on 9191/9192 taking unauthenticated code execution as SYSTEM, mass-exploited within weeks of disclosure by Cl0p and LockBit ransomware affiliates, the Bl00dy gang and nation-state activity, KEV-listed 2023-04-21 with ransomware use recorded as Known. The requirement for this product is that the default incident response for any PaperCut server that was reachable during that window is configuration capture, rebuild and credential rotation — the print-system service account, the administrative credentials the bypass hands over, and any credential the server held or that transited it — rather than upgrading in place to 20.1.7/21.2.11/22.0.9 and closing the remediation ticket. This is precisely the shape of the flaw-remediation gap recorded on this entry: the packet states that organisations patching on a normal monthly cadence were breached before they applied the fix, so for those servers 'patched' and 'not compromised' are two different findings, and because the primitive is code execution as SYSTEM, nothing the upgrade performs removes what was installed beforehand. Precondition: the upgrade here is a service upgrade rather than a host reboot, which makes patch-in-place cheap and fast — that low cost is exactly what makes it the reflexive default that skips the compromise assessment, so the rebuild decision has to be taken deliberately and written into the runbook in advance rather than weighed per incident.",
+        "evidence": "Packet fields for this entry: cisa_kev true with kev_date 2023-04-21; active_exploitation 'confirmed'; active_exploitation_notes 'Mass-exploited within weeks of disclosure; used by Cl0p and LockBit ransomware affiliates and the Bl00dy gang, plus nation-state activity. KEV-listed 2023-04-21 with ransomware use recorded (Known). Preauth RCE as SYSTEM on internet-exposed print servers'; poc_available true; patch_required_reboot false with live_patch_notes describing 'a service upgrade rather than a host reboot'. The NIST-800-53-SI-2 gap records 'PaperCut servers were compromised within days of the 2023-03 fix, so organisations that patched on a normal monthly SI-2 cadence were breached before they applied 20.1.7/21.2.11/22.0.9'; the ISO-27001-2022-A.8.8 gap records these servers internet-exposed on 9191/9192.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-2136": {
     "name": "Google Chrome Skia Integer Overflow Vulnerability",
@@ -61118,7 +63471,30 @@
         "adequate": false,
         "gap": "A.5.15 access control is nullified because the SHA authentication scheme can be satisfied without valid credentials; identity gating on the Agent provides no barrier to the arbitrary-file read with System privileges."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "The packet puts thousands of Veritas Backup Exec Agents on the internet and describes an attacker completing the Agent's SHA authentication without valid credentials and then reading arbitrary files with System privileges through crafted data-management-protocol parameters — so on this product reachability is effectively the whole precondition, because the credential check is not a barrier. Applied to Backup Exec, the control means the Agent's DMP listener answers only from the media servers that legitimately back that host up, enforced by host firewall or network ACL rather than inferred from 'the agent is on the internal network', and never from the internet directly or through a port forward or published NAT rule. The distinguishing test is to attempt an Agent connection from an external address and from a general user VLAN against a staging host and confirm both are refused before the DMP handshake completes; an estate that passes an identity-and-access attestation because 'the Agent authenticates its callers' is still fully exposed, since that assumption is exactly what the cited access-control gaps record as broken. Preconditions, which is where this control gets over-claimed: isolation bounds who can reach the Agent, it does not repair the SHA authentication scheme. Any host inside the permitted segment — a compromised media server, a jump host, a backup admin's workstation — still completes the bypass and reads files as System, and the Agent exists to be reachable by its backup server, so no segmentation removes the path outright. It is a holding measure for the window before Backup Exec 21.2 or later and the Agent service restart land, not a substitute for them. And because the packet records confirmed ransomware exploitation from 2022-10-22 against internet-exposed agents, a host that was reachable during that period is an incident to triage, not an item to close on a firewall rule.",
+        "evidence": "vector: 'due to a vulnerability in the SHA Authentication scheme, an attacker is able to gain unauthorized access and complete the authentication process. Subsequently, the client can execute data management protocol commands on the authenticated connection. By using crafted input parameters in one of these commands, an attacker can access an arbitrary file on the system using System privileges.' active_exploitation_notes: 'Mandiant attributes exploitation of the Veritas Backup Exec flaws (including CVE-2021-27876) to ALPHV/BlackCat affiliate UNC4466, first observed 2022-10-22, using them for initial access before ransomware deployment. CISA lists ransomware use as Known and added it to KEV 2023-04-07 (due 2023-04-28). Thousands of Backup Exec agents were internet-exposed.' poc_available true, cvss 8.1, rwep_score 66. UK-CAF-B2 gap: 'the flawed SHA scheme lets an attacker complete authentication without credentials, defeating the access-control assumption entirely.' ISO-27001-2022-A.5.15 gap: 'A.5.15 access control is nullified because the SHA authentication scheme can be satisfied without valid credentials; identity gating on the Agent provides no barrier to the arbitrary-file read with System privileges.' live_patch_available false; live_patch_notes gives the fix as 'upgrading Veritas Backup Exec to 21.2 or later and restarting the affected Agent service.'",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.5.15"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The timeline on this entry is the argument for the control, and the packet supplies all of it: the fix shipped in Backup Exec 21.2 in 2021, UNC4466 began exploiting it 2022-10-22, and CISA listed it 2023-04-07 with a 2023-04-28 due date — more than a year of live exploitation against a fix that already existed. For Backup Exec the control means the KEV listing, not the backup platform's own upgrade window, drives the move to 21.2 or later across every agent-bearing host. The measurement half decides whether that actually happens: completion is the version the running Agent service reports on each protected host, not the media-server console showing an upgrade pushed. The packet records patch_required_reboot false alongside live_patch_available false and remediation stated as upgrading to 21.2 or later and restarting the affected Agent service — so no machine reboot is owed, but a host whose Agent service was never restarted is still executing pre-21.2 code and must be counted as exposed. On a backup estate that restart is also the step most likely to be deferred, because it lands on production servers during business hours, and a deferral recorded as upgraded is the specific way this remediation goes wrong. The population to enumerate is every server carrying an Agent rather than the backup servers themselves, including hosts whose backup coverage predates the current asset inventory — an Agent nobody tracks is an Agent nobody upgrades, and the packet's thousands of internet-exposed agents are drawn from exactly that set. Priority follows the packet rather than the 8.1 CVSS: CISA records ransomware use as Known, Mandiant ties exploitation to an ALPHV/BlackCat affiliate using it for initial access, and a public PoC exists, which makes this a ransomware entry point rather than a file-disclosure item to schedule.",
+        "evidence": "live_patch_notes: 'No vendor live-patch mechanism; remediation requires upgrading Veritas Backup Exec to 21.2 or later and restarting the affected Agent service.' patch_available true, patch_required_reboot false, live_patch_available false, affected_versions 'Veritas Backup Exec < 21.2'. cisa_kev true, kev_date 2023-04-07, and active_exploitation_notes record the CISA due date 2023-04-28, ransomware use 'Known', and first observed exploitation 2022-10-22 by UNC4466. poc_available true, cvss 8.1, rwep_score 66. NIST-800-53-SI-2 gap: 'SI-2 flaw remediation was available (Backup Exec 21.2, 2021) more than a year before UNC4466 began exploiting it in October 2022, so organizations on a slow SI-2 cadence still exposed the SHA-auth-bypass file-read path when it drove the 2023-04-07 KEV listing.' NIS2-Art21-patch-management gap: 'NIS2 patch-management often deprioritizes backup infrastructure, yet the Backup Exec Agent's auth-bypass grants System-level file access that ALPHV used for initial access; a routine patch window left the ransomware entry point open for months.' AU-Essential-8-Patch gap: 'Essential 8 patch prioritization keyed to obvious internet-facing apps under-weighted the Backup Exec Agent.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-27877": {
     "name": "Veritas Backup Exec Agent Improper Authentication Vulnerability",
@@ -61240,7 +63616,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management should have prioritized the Backup Exec 21.2 upgrade, but the flaw persisted on unpatched agents into 2023; because backup infrastructure is often excluded from aggressive patch windows, the known auth-bypass stayed exploitable well past disclosure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The Veritas Backup Exec Agent is exactly the binary remoting-protocol class this control governs. The packet describes a client-to-Agent channel that carries Data Management Protocol commands and is gated by the Agent's own SHA authentication scheme over TLS — and that scheme is itself the vulnerable code, since the attacker completes authentication without valid credentials and then issues a DMP command that executes an arbitrary command with system privileges. Bound to this product, the control means each Agent's listener accepts connections only from the Backup Exec servers that legitimately drive it, enforced by host firewall or network ACL on every protected host, rather than inferred from 'the agent is on the internal network' — the packet places an ALPHV/BlackCat affiliate against internet-exposed agents, so reachability of that listener is the entire access precondition. It also means a KEV-listed defect in that authentication path runs on an accelerated clock instead of the backup product's usual maintenance window. Distinguishing test for this product: from a segment with no backup role — a general user VLAN, and an external address — open a connection to the Backup Exec Agent port on a staging host and confirm it is refused before the SHA handshake is offered; an estate that passes a Backup Exec role-and-permission audit still fails this, because the attacker never presents a Backup Exec credential and no account model is ever consulted. Preconditions: this bounds who can reach the handshake, it does not repair it. The backup servers must keep reaching every agent, so a compromised backup server or any host inside the permitted segment satisfies the exploit's access requirement in full, and the restriction is unavailable where an agent must remain reachable from a wide segment for normal operation. It also gives nothing to an agent that was already reachable during the exposure window — with a public Metasploit module and confirmed ransomware staging, such a host needs forensic triage and rotation of credentials that transited it, not closure on the upgrade record.",
+        "evidence": "Packet fields for CVE-2021-27878 (Veritas Backup Exec Agent Command Execution Vulnerability): cwe_refs CWE-77; cisa_kev true, kev_date 2023-04-07, active_exploitation confirmed; rwep_score 71, cvss 8.8; poc_available true. The vector states that communication between a client and an Agent requires successful authentication typically completed over secure TLS, that a vulnerability in the SHA Authentication scheme lets an attacker gain unauthorized access and complete the authentication process, and that the client can then execute data management protocol commands on the authenticated connection, one of which executes an arbitrary command on the system using system privileges. active_exploitation_notes record CISA KEV as known ransomware-associated and an ALPHV/BlackCat affiliate leveraging the Backup Exec auth-bypass flaws against internet-exposed agents to gain a foothold and stage ransomware, following public release of a Metasploit module in 2023. Cited gaps: NIST-800-53-IA-2 ('the attacker is authenticated by the flawed scheme itself'), UK-CAF-B2 ('B2 access policy cannot help once the authentication mechanism it depends on can be satisfied without credentials'), AU-Essential-8-Backup ('this flaw turns the Backup Exec Agent itself into the entry point for system-privilege command execution').",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "UK-CAF-B2",
+          "AU-Essential-8-Backup"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock for this entry is the 2023-04-07 KEV listing, not the disclosure. The packet records that the fix shipped in Backup Exec 21.2 in 2021 and that many agents still ran older builds when the flaw was weaponized — a two-year lag that the ordinary vulnerability-management cadence produced and would produce again on the next backup-infrastructure CVE, because backup systems are routinely excluded from aggressive patch windows. Remediation is the upgrade of every Veritas Backup Exec install to 21.2 or later, and the population to enumerate is the Agent installs on protected hosts rather than the console version on the backup server: the agent is pushed onto each protected machine and stays behind on hosts that dropped out of the backup selection, were rebuilt from an older image, or were restored from backup. Completion is measured on the version the Backup Exec Agent service is actually executing. The packet records no host reboot requirement, but it also records that the upgrade restarts the Agent service — so an agent whose installer ran while the service has not restarted onto 21.2 or later is still executing the vulnerable authentication path and must be counted as exposed, not as patched. Priority follows the packet rather than the 8.8 CVSS band: a public PoC with a Metasploit module, confirmed exploitation, and a ransomware-associated KEV flag make this the entry point to a ransomware event, so it belongs on the emergency clock alongside internet-facing services rather than in the backup product's own maintenance cycle.",
+        "evidence": "Packet fields for CVE-2021-27878: patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires upgrading Veritas Backup Exec to 21.2 or later, which restarts the Backup Exec Agent service (no host reboot required)'; affected_versions 'Veritas Backup Exec < 21.2'; cisa_kev true with kev_date 2023-04-07; poc_available true with a Metasploit module publicly released in 2023 per active_exploitation_notes, which also flag the KEV entry as known ransomware-associated. The NIS2-Art21-patch-management gap records that the fix shipped in Backup Exec 21.2 (2021) but many agents ran older builds when ALPHV weaponized it, and that the 2023-04-07 KEV listing marks a two-year lag; the ISO-27001-2022-A.8.8 gap records that backup infrastructure is often excluded from aggressive patch windows, so the known auth-bypass stayed exploitable well past disclosure.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2019-1388": {
     "name": "Microsoft Windows Certificate Dialog Privilege Escalation Vulnerability",