@blamejs/exceptd-skills 0.19.21 → 0.19.23

package/data/zeroday-lessons.json

@@ -38949,10 +38949,10 @@
     },
     "defense_chain": {
       "prevention": {
-        "what_would_have_worked": "Update to Craft 4.13.8 / 5.5.8+ AND rotate the security key regardless of patch status, since a previously leaked key remains dangerous even after patching unless rotated.",
+        "what_would_have_worked": "Update to Craft 4.13.8 / 5.5.8 or later, which is what closes this injection path — the vendor scopes the flaw to unpatched installs. For installs that could not update promptly, the vendor names rotating the security key as the interim measure.",
         "was_this_required": true,
         "framework_requiring_it": "CISA BOD 22-01 (KEV remediation, added 2025-02-20)",
-        "adequacy": "Patching alone is insufficient — Craft's own advisory explicitly calls out key rotation as a required companion step, which many operators skip if they only track CVE/patch status."
+        "adequacy": "The fixed release remediates this CVE; Craft's advisory offers key rotation to users who cannot update, not as a companion step required alongside the upgrade. What patch-status tracking does miss is separate: a security key that may already have been disclosed stays valuable to an attacker for everything else it protects, so it remains a credential-rotation and incident-response item after the upgrade — a finding with its own owner rather than a condition on closing this CVE."
       },
       "detection": {
         "what_would_have_worked": "Monitoring for anomalous database-backup/restore operations and unexpected outbound connections from the Craft application process.",
@@ -38971,14 +38971,36 @@
       "NIST-800-53-SI-2": {
         "covered": true,
         "adequate": false,
-        "gap": "Patch alone (4.13.8 / 5.5.8) doesn't remediate an already-compromised security key from before the update — rotation is a separate required action the patch cannot force."
+        "gap": "Flaw remediation closes on the fixed release (4.13.8 / 5.5.8), which is what remediates this CVE — but the exploit precondition is a security key compromised before the update, and SI-2 has no trigger for rotating a secret whose exposure the vulnerability reveals. The upgrade closes the injection path and leaves a key the attacker may hold still in service for everything else it protects."
       },
       "GDPR-Art32": {
         "covered": true,
         "adequate": false,
         "gap": "Security-of-processing is directly undermined when a leaked application security key enables remote code execution against a system that may process personal data."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "Craft's own guidance in the packet splits the response into two actions, and which one remediates depends on where the install is: the fix is Craft 4.13.8 and 5.5.8, and installs that cannot update should rotate their security keys. So the verdict classes for this CVE are: the running install reports 4.13.8 or 5.5.8 or later — remediated, because the vendor scopes the flaw to unpatched installs and the upgrade closes the injection path whatever the key's history; the install is still below the fixed release but its security key has been rotated — the vendor's own stated interim mitigation, which must be reported as a compensating state carrying a dated upgrade item rather than as a pass, because it depends on the new key staying secret and the injection path is still present; and neither — full exposure of a KEV-listed, confirmed-exploited code-injection path. The state a compliance record most often gets wrong here is the middle one: closing the CVE on \"keys rotated\" while the install remains below the fixed release records the interim mitigation as the remediation. Cover both release lines the packet names: 4.x installs need 4.13.8 and 5.x installs need 5.5.8, so an estate that upgraded its Craft 5 sites and left a Craft 4 site behind holds more than one of these states at once. Preconditions, and the second is the one this control must not overstate. It governs how the outcome is recorded and chased — it does not itself upgrade or rotate anything. And a key that may have been disclosed remains a credential-rotation and incident-response item after the upgrade, because the key opens whatever else it protects and the upgrade does not un-disclose it — but that is its own finding with its own owner, not a condition on closing this CVE, and an install with any indication of code having executed belongs on the incident path regardless of either verdict.",
+        "evidence": "Packet: cisa_kev true with kev_date 2025-02-20 and active_exploitation confirmed; cwe_refs CWE-94; patch_available true with affected_versions '4.x < 4.13.8' and '5.x < 5.5.8'; live_patch_available false. The vector states this is an RCE affecting 'Craft 4 and 5 installs where your security key has already been compromised', that 'Anyone running an unpatched version of Craft with a compromised security key is affected', that it 'has been patched in Craft 5.5.8 and 4.13.8', and that 'Users who cannot update to a patched version, should rotate their security keys and ensure their privacy to help migitgate the issue.' The NIS2-Art21-vulnerability-management gap records that vulnerability management has no state for that interim measure, so a site running it is neither exposed as reported nor remediated; the AU-Essential-8-Patch gap records that patch-application guidance reports such a site identically to one that did nothing.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.24"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance case for this CVE is not the version check — the vendor scopes the flaw to unpatched installs, so a site genuinely reporting 4.13.8 or 5.5.8 or later is remediated and a scanner reading the version is answering the right question. It is the other direction that goes wrong: an attestation that closes this CVE because the security keys were rotated, while the install is still below the fixed release. Rotation is the vendor's stated measure for sites that cannot update yet; it depends on the new key staying secret and leaves the injection path in the code, so recording it as remediation converts an interim state into a pass. The operational test is per-site and per-release-line: take the version the running install reports and compare it against the fixed release for ITS line — 4.x against 4.13.8, 5.x against 5.5.8 — and require any site closed on rotation alone to carry a dated upgrade item instead. The line-matching half is not incidental: an estate that upgraded its Craft 5 sites and reports \"Craft patched\" holds Craft 4 sites the 5.5.8 figure says nothing about. Precondition and limit: this control produces a truthful verdict and remediates nothing. Where a site cannot produce the version its running install reports — as opposed to the version its deployment record claims — the answer is \"unknown\", not \"pass\".",
+        "evidence": "Packet: affected states Craft CMS 4 and 5 code-injection RCE 'reachable when the installation's application security key has already been compromised through any other means'; affected_versions '4.x < 4.13.8' and '5.x < 5.5.8'; patch_available true; poc_available false; cisa_kev true (2025-02-20) with active_exploitation confirmed. The vector records the fix as Craft 5.5.8 and 4.13.8 and scopes the flaw to anyone 'running an unpatched version', with key rotation given as what users who cannot update should do. active_exploitation_notes state that 'Exploitation requires the installation's security key to already be compromised, so observed abuse is likely chained after a separate initial-access flaw' and reference the related CVE-2025-32432 asset-transform RCE as a plausible key-leaking precursor. The AU-Essential-8-Patch gap records that patch guidance has no expression for the vendor-provided interim mitigation, which is the state this test exists to keep distinguishable from remediation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-0108": {
     "name": "Palo Alto Networks PAN-OS Authentication Bypass Vulnerability",
@@ -42891,7 +42913,39 @@
         "adequate": false,
         "gap": "Least-privilege wasn't enforced on the Expedition process, which ran the vulnerable code path as root, maximizing the impact of the injection."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Expedition is a migration tool rather than production infrastructure, which is exactly why it sits outside the asset classes a flaw-remediation SLA normally tiers — and it is also the store holding, in the packet's own terms, the usernames, cleartext passwords, device configurations and device API keys of the PAN-OS firewalls it has handled. The requirement here is that every Expedition install is inventoried and clocked at the tier its contents justify rather than the tier its role suggests: the clock opens with the 2024-11-14 KEV listing, the fixed release the packet records is 1.2.96, and completion is measured by the version the install is actually running, not by an approved change record. The inventory has to reach installs that were stood up for a migration which has since finished, because an install nobody is using still answers the same unauthenticated request path. Scope it to what the packet names: the affected range is Expedition versions prior to 1.2.96, and the PAN-OS firewalls are what the disclosed credentials open, not additional instances of this flaw. Distinguishing test: produce, per install, the running Expedition version and show it is 1.2.96 or later — an estate whose vulnerability-management record carries Expedition as a low-tier internal utility passes its technical-vulnerability review cleanly while an unauthenticated root command-injection stays reachable. Precondition: the packet records no live-patch path, so an install that has not been taken to 1.2.96 is executing the vulnerable code whatever compensating rules sit around it, and reaching 1.2.96 does nothing about credentials disclosed before the upgrade.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-11-14; active_exploitation confirmed; poc_available true; patch_available true; live_patch_available false; affected_versions 'Expedition versions prior to 1.2.96'. affected names the Palo Alto Networks Expedition migration tool with unauthenticated OS command injection executing as root, disclosing PAN-OS firewall usernames, cleartext passwords, configurations and API keys. The NIST-800-53-SI-2 gap records a flaw-remediation SLA that 'lagged the compressed exploitation window for a tool that stores highly sensitive downstream firewall credentials'; the ISO-27001-2022-A.8.8 gap records that technical vulnerability management 'didn't treat Expedition as a high-value credential store requiring the same patch cadence as the firewalls it manages'; the NIS2-Art21-vulnerability-handling gap records EU operators likely excluding Expedition from critical-asset vulnerability-handling scope despite it holding firewall credentials.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "Expedition's web application is the user-facing surface this control governs, and the packet has it wired to the strongest possible root operation: an unauthenticated request reaches an OS command that executes as root. The least-privilege gap on this entry states the same thing from the other side — the vulnerable code path ran as root, maximising the impact of the injection. Bound to this product, the control means the Expedition web tier does not execute OS commands on behalf of request input at all, and any operation that genuinely needs elevation is reached through a constrained, validated interface instead of by handing request-derived strings to a shell under a root identity. That property is what the vendor update establishes: this control states what to verify on the deployment, it does not implement it. It is also why the least-privilege gap cannot be closed on the account side — the attacker never authenticates as any Expedition user, so per-account privilege scoping is never consulted and an access-control attestation covering Expedition's own logins passes while the path stays open; the privilege that matters here is the one the service process itself holds. Distinguishing test: on a staging install, show the identity the Expedition web tier executes under and confirm it is not root, and show that input reaching the migration interface is not passed to a shell — an application-hardening attestation covering browser and document-macro settings across the estate says nothing about a web application that carries request input into an OS-command sink. Precondition: until the install reaches 1.2.96, restricting which networks can reach the Expedition web interface bounds the population that can send the request but does not close the path, because the request carries no credentials — anything inside the permitted segment can send it — and the measure is unavailable wherever migration engineers must reach that interface for normal work.",
+        "evidence": "Packet: cwe_refs CWE-78; the vector states an OS command injection in Palo Alto Networks Expedition 'allows an unauthenticated attacker to run arbitrary OS commands as root in Expedition'; attack_vector describes an unauthenticated attacker sending a crafted request to the Expedition web application, injecting OS commands that execute as root. The NIST-800-53-AC-6 gap records that 'Least-privilege wasn't enforced on the Expedition process, which ran the vulnerable code path as root'; framework_coverage marks AC-6 covered but not adequate for that reason. The AU-Essential-8-App-Hardening gap records that application-hardening controls 'didn't prevent unsanitized input from reaching an OS-command-execution sink in the Expedition web application'. patch_available is true with affected_versions 'Expedition versions prior to 1.2.96'.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "An Expedition compromise is a credential-store breach before it is anything else: the packet describes unauthenticated command execution as root that discloses the usernames, cleartext passwords, device configurations and device API keys of the PAN-OS firewalls the tool has handled. Upgrading the install to 1.2.96 closes the injection and changes none of that — every password and device API key that passed through the install stays valid, and the configurations stay known. Written for this product, the runbook this control requires is: for any Expedition install that was reachable while below 1.2.96, rotate every PAN-OS administrative credential and device API key the install held and re-issue them on the firewalls themselves, treat the firewall configurations it stored as disclosed, and rebuild the Expedition host from a known-good baseline rather than upgrading in place, because execution as root means the update removes nothing the attacker was able to leave behind. Trigger it on exposure rather than on proof of a specific intrusion — the packet records confirmed exploitation in the wild and public exploit code for the Expedition chain. Distinguishing test, keyed to the identity-and-access gap on this entry: for each PAN-OS device Expedition handled, show that its administrative credential and its device API key carry a rotation date later than the Expedition upgrade; an identity attestation stating that every firewall administrator is uniquely named and multi-factor-backed passes cleanly while an API key dumped through Expedition is still accepted by the device, because presenting that key involves no interactive authentication. Precondition: rotation only addresses credentials that have not yet been used — it does nothing about actions an attacker already took with them, so a firewall whose configuration changed during the exposure window belongs on the incident path rather than being closed on the rotation record.",
+        "evidence": "Packet: active_exploitation confirmed, with active_exploitation_notes recording CISA-confirmed evidence of exploitation, the 2024-11-14 KEV listing alongside CVE-2024-9465, and public exploit code for the broader Expedition vulnerability chain; poc_available true. The vector states the injection results in 'disclosure of usernames, cleartext passwords, device configurations, and device API keys of PAN-OS firewalls', executing as root. The UK-CAF-B2 gap records that 'Identity-and-access assurance breaks downstream: the unauthenticated root command-injection dumps cleartext passwords and PAN-OS device API keys, handing an attacker the credentials to take over every firewall Expedition manages.' patch_available is true (fixed at 1.2.96) and live_patch_available is false.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2024-49039": {
     "name": "Microsoft Windows Task Scheduler Privilege Escalation Vulnerability",
@@ -43525,7 +43579,30 @@
         "adequate": false,
         "gap": "Essential Eight application-hardening guidance targets exactly this class of exposed CGI configuration endpoint on network video devices."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The camera's CGI configuration API is the device-management surface this control governs, and the defect sits squarely on it: the packet states the camera does not sufficiently validate the ntp_addr configuration value, which leads to arbitrary command execution when ntp_client is started. Bound to this product, the control means each CGI configuration parameter is validated against the value it actually holds — an NTP server address is a hostname or address, never a string carrying shell metacharacters — before it is stored and before any service consumes it at start-up, and the CGI API authorizes its caller at the endpoint itself rather than inheriting a verdict from the weak authentication that CVE-2024-8956 bypasses to make this reachable remotely and unauthenticated. Note the deferred-execution shape, which is what makes the storage-time check the important one: the value is written at configuration time and executes when the ntp_client service starts, so a camera can be poisoned and behave normally until that service next starts. Distinguishing test: on a staging camera, set ntp_addr to a value containing shell metacharacters, restart ntp_client, and confirm nothing executes. Precondition: endpoint-side authorization and parameter validation are properties the vendor firmware establishes — this control states what to verify, it does not implement it. Until firmware 6.3.40 and its reboot land, restricting which segments can reach the camera's CGI API bounds who can submit the parameter but leaves it fully exploitable to anything inside a permitted segment, and it is unavailable where the API must stay reachable for normal operation. And because exploitation gives root-level takeover of the device, a camera that was reachable during the exposure window is not remediated by firmware alone: its stored configuration, ntp_addr included, has to be rebuilt from a known-good baseline rather than inherited through the update.",
+        "evidence": "Packet fields: vector states 'PTZOptics PT30X-SDI/NDI-xx before firmware 6.3.40 is vulnerable to an OS command injection issue. The camera does not sufficiently validate the ntp_addr configuration value which may lead to arbitrary command execution when ntp_client is started. When chained with CVE-2024-8956, a remote and unauthenticated attacker can execute arbitrary OS commands on affected devices.' attack_vector describes reaching the camera's CGI API — directly if authenticated, or unauthenticated by first chaining CVE-2024-8956's weak-authentication bypass — and setting ntp_addr to a value containing shell metacharacters that execute when the ntp_client service starts. cwe_refs CWE-78; poc_available true; rwep_score 83; patch_available true with patch_required_reboot true and live_patch_available false. active_exploitation_notes records that successful exploitation gives full root-level device takeover in conferencing, telehealth and government deployments. The ISO-27001-2022-A.8.9 gap states configuration management should restrict which CGI parameters (like ntp_addr) can carry shell metacharacters before reaching a system() call, a build-time control the firmware lacked; the AU-Essential-8-App-Hardening gap states application-hardening guidance targets exactly this class of exposed CGI configuration endpoint on network video devices; the UK-CAF-B4 gap expects hardened default configs on network video devices.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.9",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry needs the clock, but it needs the population first. The packet's affected set is not one brand: alongside PTZOptics PT30X-SDI/NDI cameras it names rebadged Multicam Systems SAS and SMTAV Corporation devices sharing the same Hisilicon Hi3516A-based firmware, so a sweep scoped to the PTZOptics name reports clean across a site standardised on a rebadge while every unit still carries the ntp_addr injection. Applied here, the control means enumerating all three brands, driving each unit to its own vendor's fixed firmware on the clock that opened with the 2024-11-04 KEV listing, and measuring completion on the firmware version the camera reports after restart — the packet records patch_required_reboot true and no live-patch path, so a camera that took the firmware but has not restarted is not remediated. For PTZOptics the packet gives that fixed level as 6.3.40; for the rebadged Multicam Systems SAS and SMTAV units it gives no separate version, so the fixed firmware level for that exact model must be obtained from its vendor rather than assumed to be 6.3.40 unchanged. Where a unit cannot be taken through the update inside the window, the documented compensating control is removing reachability of its CGI API from untrusted networks and from the internet, because internet exposure is the condition being exploited — the packet records internet-wide exploitation attempts against exposed cameras, and a public exploit exists. Precondition on that compensating half: it bounds who can reach the CGI API, it does not repair the parameter handling, so any host inside a permitted segment still reaches the injection; it is a holding measure for the window before the firmware and its reboot, not a closure.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2024-11-04 and active_exploitation confirmed; poc_available true; rwep_score 83 against cvss 7.2. affected states 'PTZOptics PT30X-SDI/NDI cameras (and rebadged Multicam Systems SAS / SMTAV Corporation devices sharing the same Hisilicon Hi3516A-based firmware)'; affected_versions gives 'firmware before 6.3.40'. patch_available true, patch_required_reboot true, live_patch_available false. active_exploitation_notes records that GreyNoise observed active internet-wide exploitation attempts against exposed PTZOptics and rebadged Multicam Systems SAS / SMTAV Corporation cameras around the time of public disclosure in late October 2024, that CISA added it to KEV in November 2024, and that successful exploitation gives full root-level device takeover in conferencing, telehealth and government deployments. The NIS2-Art21-vulnerability-management gap states IoT/NDI camera fleets in EU conferencing and telehealth settings fall under Art.21 vulnerability-management obligations even though they are rarely inventoried as core IT assets.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-8956": {
     "name": "PTZOptics PT30X-SDI/NDI Cameras Authentication Bypass Vulnerability",
@@ -43830,7 +43907,40 @@
         "adequate": false,
         "gap": "Least-privilege wasn't enforced in the documented intrusion — an over-privileged (domain admin) service account reached the vulnerable Site-Owner-level endpoint."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For on-premises SharePoint Server the operative fact is that the documented exploitation planted a webshell, so applying the July 9 2024 security update removes the deserialization sink in the API endpoint and removes nothing the attacker already wrote to the farm — the planted .aspx, any account it added, and anything it staged all survive the update. The requirement: an on-prem farm that ran below the July 2024 build during the exploitation window and shows any indicator of exploitation is handled as a compromised host rather than a late patch ticket — content and configuration exported for analysis, the servers rebuilt from a known-good image onto the fixed build rather than updated in place, and every credential the farm held or that authenticated through it rotated. Scope the rotation by what the packet records about the documented intrusion: it ran through an over-privileged domain-admin service account that reached the Site-Owner-level endpoint, so rotation cannot stop at the SharePoint farm account. Precondition, and it is the one that decides scope: this is the post-exposure path only, and it does not apply to a farm that reached the fixed build before it was ever exposed. Establishing which farms are in that set depends on retained web telemetry, which is exactly what the monitoring and incident-handling gaps on this entry record as absent — the documented case ran two weeks between the webshell drop and detection — so a farm with no retained request telemetry across the window cannot demonstrate non-exposure and belongs on the rebuild path by default.",
+        "evidence": "Packet: CWE-502 deserialization of untrusted data in an on-premises SharePoint Server API endpoint; active_exploitation confirmed; poc_available true; active_exploitation_notes record exploitation in the wild using a publicly disclosed proof-of-concept to plant a webshell on a compromised SharePoint server, with CISA KEV flagging the entry ransomware-associated (Known); CISA KEV listing 2024-10-22; patch_available true, the fix being the July 9 2024 security update (build-specific KBs in the MSRC advisory); live_patch_available false. NIS2-Art21-incident-handling gap: the attacker went undetected for two weeks post-webshell-drop. NIST-800-53-SI-2 gap: the patch shipped in July 2024 but exploitation was still observed afterward. NIST-800-53-AC-6 gap: an over-privileged (domain admin) service account reached the vulnerable Site-Owner-level endpoint.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "This is the authenticated-session blind spot the control exists for, on SharePoint instead of Exchange. The packet's attack vector has the attacker holding Site Owner-level permissions — often obtained from a previously compromised privileged account — and submitting a crafted request to a SharePoint API endpoint, so every authentication event the farm emits is a legitimate operator signing in and nothing in an auth-only log separates the deserialization request from ordinary site administration. Bound to an on-prem farm, the control means per-request IIS and SharePoint access logs for the farm, not just sign-in events, are forwarded to a SIEM outside the farm's own trust zone and retained long enough to cover the detection latency this entry records, since telemetry that ages out inside two weeks cannot reconstruct an intrusion that ran two weeks before discovery. Alert on the behaviour the monitoring gap names for this CVE rather than on generic exploit signatures: w3wp.exe spawning child processes, and new .aspx files appearing under the farm's web directories. Distinguishing test: on a staging farm, submit a request to the vulnerable API endpoint as a Site Owner and confirm the request itself — path, parameters and the identity that sent it — reaches the external SIEM, and that writing a new .aspx under a web directory raises an alert. A farm whose logging shows only that the service account signed in passes a security-monitoring attestation cleanly while this entire request class stays invisible. Precondition: this is detection, not prevention — it shortens the window between the deserialization request and response, and it does nothing about a webshell already resident.",
+        "evidence": "Packet attack_vector: an attacker holding Site Owner-level SharePoint permissions (often obtained via a previously compromised privileged account) submits a crafted request that triggers unsafe .NET deserialization in a SharePoint API endpoint, achieving remote code execution and, in observed incidents, planting a webshell for persistence. UK-CAF-C1 gap: monitoring coverage did not catch anomalous w3wp.exe process spawning or new .aspx file writes in a timely fashion. NIS2-Art21-incident-handling gap: in the documented case the attacker went undetected for two weeks post-webshell-drop. active_exploitation confirmed; poc_available true; CISA KEV 2024-10-22.",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "NIS2-Art21-incident-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the control's 'whichever is later' clause resolves to the KEV listing rather than patch availability: the fix shipped in the July 9 2024 security update and CISA listed the CVE on 2024-10-22, so the later of the two triggers is the listing and the four-hour window opens on 2024-10-22 — a farm still below the July 2024 build on that date is inside its response window, not already in breach, and treating it as breached manufactures a violation and can start compromise handling before the window has run — which is the condition the flaw-remediation gap records, exploitation continuing after the patch existed. Scope the population to what the packet names: on-premises SharePoint Server releases prior to the July 9 2024 update, per the build-specific KBs in the vendor advisory, not SharePoint generally. Measure completion per farm on the build its servers actually report against those KBs, not on 'approved' or 'downloaded' in the update console — the packet records no live-patch path, so a farm counts as remediated only once the fixed assemblies are the code its servers are executing. The KEV-listed ransomware association and the public proof-of-concept change what a missed clock means here: a farm found past the deadline is a compromise-triage question rather than a late patch ticket, because the same window that left it unpatched is the window in which the documented webshell drop occurred.",
+        "evidence": "Packet: CISA KEV listing 2024-10-22 with ransomware association flagged Known; patch_available true, affected_versions given as on-premises SharePoint Server releases prior to the July 9, 2024 security update (build-specific KBs listed in the MSRC advisory); live_patch_available false; poc_available true; active_exploitation confirmed; RWEP 72, CVSS 7.2. NIST-800-53-SI-2 gap: the patch shipped in July 2024 but exploitation was still observed afterward, showing standard flaw-remediation SLAs did not outpace attacker patch-diffing and weaponization. AU-Essential-8-Patch gap: on-prem internet-facing SharePoint patch cadence trailed attacker patch-diffing. ISO-27001-2022-A.8.8 gap: technical vulnerability management did not flag internet-facing on-prem SharePoint for accelerated patch cadence.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-9537": {
     "name": "ScienceLogic SL1 Unspecified Vulnerability",
@@ -44592,7 +44702,41 @@
         "adequate": false,
         "gap": "Zimbra's official fix shipped 2024-09-04 but mass exploitation began 2024-09-28 — a roughly 3.5-week patch window closed by attackers well before most self-hosted deployments applied it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the clock has to start at the vendor fix, not at the KEV listing. The packet records Zimbra's fix shipping 2024-09-04, mass exploitation beginning 2024-09-28, and the KEV listing following on 2024-10-03 — so an operator whose SLA is keyed to KEV began responding five days after the exploitation wave was already running against the install base. Scope from the affected versions rather than from the product name: ZCS ships four release branches here and each has its own fixed level (8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9, 10.1.1), so an estate standardized on one branch that reports itself current still leaves the other branches on vulnerable code. patch_available is true and no live-patch path is recorded, so driving each install to its branch's fixed level is the remediation; measure completion on the version the running ZCS services report rather than on a package record, because postjournal keeps executing pre-fix code until the service it runs under restarts onto the new build. The packet describes the flaw as one postjournal 'sometimes' exposes without stating the condition that decides it, so no install can be written off as unaffected on configuration grounds — its patch level is the only fact that settles the question. Self-hosted mail is the population this bites hardest: the packet's vulnerability-handling gap records that these operators have no vendor-driven forced-upgrade mechanism, so nothing closes the window if the operator's own clock does not.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-10-03; active_exploitation confirmed; CVSS 10, RWEP 74; poc_available true; patch_available true, live_patch_available false, live_patch_notes null, patch_required_reboot false. The flaw-remediation gap records the fix shipping 2024-09-04 against mass exploitation beginning 2024-09-28, a roughly 3.5-week window. active_exploitation_notes: mass-exploited beginning 2024-09-28, days after ProjectDiscovery published technical details and PoC code. affected_versions: ZCS 8.8.15 before Patch 46, 9.0.0 before Patch 41, 10.0 before 10.0.9, 10.1 before 10.1.1. The vector states postjournal 'sometimes' allows unauthenticated users to execute commands. The NIS2 gap records that self-hosted mail operators had no vendor-driven forced-upgrade mechanism, unlike SaaS email.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records not just that Zimbra was exploited but what the attackers did with it: spoofed emails carrying base64-encoded shell commands in the CC field, dropping webshells on internet-facing Zimbra servers throughout the wave that began 2024-09-28. Applied to this product, the requirement is that any ZCS server sitting below its branch's fixed level during that wave is handled as an incident, not as a patch ticket. Upgrading to 8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9 or 10.1.1 closes the injection path and removes nothing already written through it — a webshell placed before the upgrade survives it, and the commands ran with whatever privilege the postjournal path holds on the mail server the packet names as the drop location. The default response is therefore preserve and export the configuration and logs first, rebuild the server from a known-good image already at the fixed level rather than upgrading the exposed one in place, and rotate the credentials that server held or that authenticated through it during the exposure window. The absence of an anti-malware alert is specifically not evidence of a clean server here: the packet's own malware-protection gap records that mail controls scan attachment and body content for signatures and pass shell metacharacters in the CC header as clean, so the delivery that dropped the webshell is exactly the event those controls did not see, and 'nothing was flagged' cannot be the basis for choosing patch-in-place.",
+        "evidence": "Packet: active_exploitation confirmed; active_exploitation_notes state attackers sent spoofed emails with base64-encoded shell commands in the CC field to drop webshells on internet-facing Zimbra servers, mass-exploited beginning 2024-09-28, used for broad opportunistic RCE and not flagged as ransomware by CISA. attack_vector: postjournal parses SMTP CC-header content and executes base64-decoded shell commands via sh without authentication, letting attackers send a crafted email to drop a webshell on the mail server. patch_available true with fixed levels 8.8.15 Patch 46 / 9.0.0 Patch 41 / 10.0.9 / 10.1.1; live_patch_available false. The ISO-27001-2022-A.8.7 gap states email malware protections scan attachment and body content for signatures, not shell metacharacters in the CC header, so the unauthenticated command execution rides in on mail those controls pass as clean. The Essential Eight gap records the mass-exploitation wave documented by Proofpoint across the Zimbra install base.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "postjournal is the internal service channel this control governs. The packet has it receiving SMTP CC-header content from the mail pipeline and executing base64-decoded shell commands through sh with no authentication — an internal component evaluating the content it is handed rather than merely parsing it, on the inherited assumption that anything arriving from the MTA is already trusted. Bound to ZCS, the requirement is that a component reached over an internal service channel constrain or authenticate what that channel delivers, so mail-header content cannot reach a shell-evaluation sink; that is a property to verify on the fixed builds (8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9, 10.1.1), not something an operator can add to an unpatched install. The precondition has to be stated plainly because this is where the control is most easily over-claimed: the documented delivery path is an ordinary inbound email, so restricting network reachability is not available as a compensating control here — an internet-facing mail server must accept mail from arbitrary senders, and that acceptance is the exploit path. This is exactly why the boundary-protection gap is recorded against this entry: perimeter filtering sits in front of the SMTP listener, not between the MTA and postjournal, and inspects neither CC-header content for command injection nor the internal hand-off. The distinguishing test is a per-node build check against the fixed level for that node's branch; an attestation that the mail perimeter filters inbound traffic passes cleanly while this path stays open.",
+        "evidence": "Packet: attack_vector states postjournal parses SMTP CC-header content and executes base64-decoded shell commands via sh without authentication. affected: the postjournal service, which sometimes allows unauthenticated users to execute OS commands via crafted SMTP header content. cwe_refs CWE-78. The NIST-800-53-SC-7 gap states postjournal listens for SMTP-adjacent input with no boundary filtering on CC-header content and that typical perimeter controls do not inspect mail-header command-injection patterns. The UK-CAF-B4 gap states secure configuration guidance for on-prem mail servers does not typically address internal service-to-service trust boundaries like postjournal's unauthenticated command execution. patch_available true with the branch-specific fixed levels in affected_versions; live_patch_available false, live_patch_notes null.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-29824": {
     "name": "Ivanti Endpoint Manager (EPM) SQL Injection Vulnerability",
@@ -44698,7 +44842,33 @@
         "adequate": false,
         "gap": "The product is end-of-life with no vendor patch — flaw remediation as a control is structurally unavailable, and CISA's required action is decommissioning rather than patching."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This packet offers no interim state: patch_available is false, no live-patch path is recorded, the vendor no longer supports the product, and CISA's listed required action is to discontinue use rather than remediate. So for the DIR-820 the control reduces to its retirement half, and there is no fixed firmware level that would ever close the ticket. Produce an inventory naming every D-Link DIR-820 in service with its hardware revision and running firmware — the packet names DIR820LA1_FW105B03 explicitly and describes later end-of-life firmware only as likely affected, so per-unit status has to be obtained from the vendor or the KEV entry rather than asserted in either direction — and put every unit on a dated replacement schedule running from the 2024-09-30 KEV listing. A risk acceptance with no removal date leaves a device carrying an unauthenticated root command-execution path, with a public PoC and confirmed exploitation, in service indefinitely. Keep the programme scoped to what the packet establishes: it ties the ping.ccp injection to the DIR-820 and gives no mapping into other D-Link models, so a replacement sweep aimed at every D-Link router in the estate manufactures removal work against devices no evidence implicates. Precondition on the interim reachability measure, which is where this is most often over-claimed: the injection sits in the ping.ccp CGI handler on the router's web administration surface, so where the firmware offers a remote-administration toggle, disabling it bounds who can reach that surface from the internet — but a router of this class exists to serve the client network attached to it, and every client on that network still reaches the administration surface. 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 until the replacement lands.",
+        "evidence": "Packet: patch_available false; live_patch_available false; live_patch_notes null. affected_versions: 'DIR820LA1_FW105B03 and likely later EoL firmware — vendor no longer supports the product.' active_exploitation_notes: 'Actively exploited against end-of-life D-Link DIR-820 routers; CISA added it to KEV noting the product is EoL/EoS with no vendor patch forthcoming, and the required action is to discontinue use rather than remediate.' kev_date 2024-09-30; poc_available true; cvss 9.8; rwep_score 80. attack_vector: 'A remote, unauthenticated attacker sends a crafted request to the router's ping.ccp CGI handler with shell metacharacters embedded in the ping_addr parameter, achieving root command execution.' NIST-800-53-SI-2 gap: 'flaw remediation as a control is structurally unavailable, and CISA's required action is decommissioning rather than patching.' ISO-27001-2022-A.8.9 gap: 'on this EoL DIR-820 the hardened baseline A.8.9 expects can't be applied, forcing replacement over configuration.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security",
+          "ISO-27001-2022-A.8.9",
+          "NIST-800-53-CM-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A DIR-820 is the network edge for whatever sits behind it, and the packet's path is unauthenticated root command execution on that edge, with a public PoC and confirmed exploitation. The patch-in-place branch this control warns against does not even exist here, which makes its response default the only one available: for a unit that was reachable while in service, treat the device as compromised rather than recoverable. A factory reset returns it to DIR820LA1_FW105B03 — the firmware the packet names as vulnerable — so resetting restores the exploit path instead of removing what an attacker left, and the administrative password and any wireless key held in the device's configuration are within reach of an attacker who reached root, so they are reissued on the replacement rather than carried across from a configuration backup. Precondition: this governs units that were reachable during the exposure window, and a consumer-class router of this kind generally produces no telemetry that would establish whether a given unit was reached, so for an internet-reachable DIR-820 the operating assumption has to be that it was. This control decides how a unit is retired, not whether — the packet's stated action is discontinuing use, and nothing here substitutes for that.",
+        "evidence": "Packet vector: 'OS Command injection vulnerability in D-Link DIR820LA1_FW105B03 allows attackers to escalate privileges to root via a crafted payload with the ping_addr parameter to ping.ccp.' active_exploitation confirmed; poc_available true; rwep_score 80; cvss 9.8. patch_available false and live_patch_notes null, so no fixed firmware exists to apply in place. affected_versions records that the vendor no longer supports the product, and active_exploitation_notes records CISA's required action as discontinuing use rather than remediating. AU-Essential-8-Patch gap: 'Patch-management maturity is unachievable for EoL hardware — the only compensating action is replacement.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2020-15415": {
     "name": "DrayTek Multiple Vigor Routers OS Command Injection Vulnerability",
@@ -44735,7 +44905,32 @@
         "adequate": false,
         "gap": "The vendor fix has existed since 2020, yet KEV addition in 2024 shows a four-year unpatched-device population still being actively targeted — patch-management enforcement, not availability, is the gap."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The Vigor3900, Vigor2960 and Vigor300B are WAN edge devices, and this is an unauthenticated remote command execution running as root on them — the trust boundary itself executing an attacker's commands, which is the case this SLA tier exists for and which a standard 14/30-day appliance window does not fit. The fact that makes this entry different from a normal KEV item is the age of the fix: firmware 1.5.1 has existed since 2020 and CISA listed the flaw on 2024-09-30, so the tier's clock must restart at the KEV listing rather than be treated as long expired. A vulnerability process that ingests advisories only at publication never re-opens a four-year-old fix, which is exactly how the packet's actively-targeted unpatched population stays in service. Operationally: enumerate every Vigor3900, Vigor2960 and Vigor300B in the estate and record each unit's running firmware against 1.5.1. Scope the sweep to those three models — the packet names them in both affected and affected_versions and ties the cvmcfgupload defect to that firmware line, so widening it to DrayTek's range generally manufactures work against models no evidence implicates. The tier's second branch is the one that matters when the window cannot be met: patch_required_reboot is true and live_patch_available is false, so there is no way to fix a unit without taking its reboot, and a unit whose reboot cannot be scheduled inside the window must have the vulnerable interface isolated — the WAN-facing management and CGI surface — rather than being carried as an accepted risk. Completion is measured on the firmware the device reports after that reboot; a unit with 1.5.1 staged but not yet restarted onto it is still running the vulnerable code and counts as exposed.",
+        "evidence": "Packet: affected is 'DrayTek Vigor3900, Vigor2960, and Vigor300B devices before firmware 1.5.1', with affected_versions listing 'Vigor3900 before 1.5.1', 'Vigor2960 before 1.5.1', 'Vigor300B before 1.5.1'. cisa_kev true, kev_date 2024-09-30, active_exploitation confirmed, with active_exploitation_notes recording exploitation of internet-facing management interfaces and KEV addition in September 2024 'despite the flaw and vendor fix dating to 2020, indicating a long tail of unpatched exposed devices continuing to be targeted'. The NIST-800-53-SI-2 gap states 'patch-management enforcement, not availability, is the gap'; the NIST-800-53-SC-7 gap states the configuration-upload CGI endpoint 'is commonly left reachable from the WAN interface with no boundary restriction to trusted management networks'. attack_vector has command execution as root. patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes null; poc_available true; cvss 9.8; rwep_score 73.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The sink here is a configuration-upload endpoint on the router's own management CGI — cgi-bin/mainfunction.cgi/cvmcfgupload — and the attacker input is the uploaded file's name rather than its contents: shell metacharacters in the filename, sent with a text/x-python-script content type, reach an OS command that runs as root, with no credential presented. Bound to this device, the control is both halves at once. The endpoint authorizes its caller before the upload is processed at all, so an unauthenticated request never reaches the handler; and the caller-supplied filename is neutralized before any command is constructed from it, which for a filename means it is never allowed to become part of a shell string. Treating the upload's content type or body as the untrusted part and the filename as metadata is the specific mistake this CVE punishes. The third requirement is reachability: no Vigor unit leaves that CGI answering on the WAN interface or from any segment with no operational need to administer it, which is what the cited configuration-management and system-security gaps record as absent — a WAN-reachable cvmcfgupload and edge-device baselines that do not disable remote administrative CGI endpoints by default. Distinguishing test: from an untrusted network against a staging Vigor, POST to cgi-bin/mainfunction.cgi/cvmcfgupload with shell metacharacters in the filename and the text/x-python-script content type, and confirm the request is refused before any command executes — a unit that passes an administrative-password audit while answering that request is still fully exploitable, because the attacker never authenticates. Precondition: the endpoint-side authorization and filename neutralization are properties the 1.5.1 firmware establishes; this control states what to verify, it does not implement it. Until 1.5.1 and its reboot land, disabling WAN-side administration bounds who can reach the CGI from the internet but leaves it exploitable from anything inside a permitted segment, and it is unavailable where the unit must be administered remotely.",
+        "evidence": "Packet vector: 'On DrayTek Vigor3900, Vigor2960, and Vigor300B devices before 1.5.1, cgi-bin/mainfunction.cgi/cvmcfgupload allows remote command execution via shell metacharacters in a filename when the text/x-python-script content type is used'. attack_vector: 'An unauthenticated remote attacker uploads a crafted configuration file with shell metacharacters in the filename to cgi-bin/mainfunction.cgi/cvmcfgupload using a text/x-python-script content type, achieving command execution as root.' The ISO-27001-2022-A.8.9 gap states secure-configuration management 'doesn't disable the WAN-reachable cvmcfgupload CGI on DrayTek Vigor edge devices, so the filename-metacharacter OS command injection stays exploitable years after the fix shipped'; the UK-CAF-B4 gap states baselines 'should disable remote administrative CGI endpoints by default; many deployments leave them exposed'; the NIST-800-53-SC-7 gap records the endpoint left reachable from the WAN with no boundary restriction. cwe_refs CWE-78; patch_available true with the fix at firmware 1.5.1; patch_required_reboot true; live_patch_available false; poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "ISO-27001-2022-A.8.9",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2019-0344": {
     "name": "SAP Commerce Cloud Deserialization of Untrusted Data Vulnerability",
@@ -45046,7 +45241,42 @@
         "adequate": false,
         "gap": "A security appliance whose management UI is internet-reachable defeats boundary protection; the FortiSandbox admin plane must not be exposed to untrusted networks."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "FortiSandbox is the detonation appliance an estate buys so that hostile content is inspected somewhere other than production, and this CVE is that appliance taking an unauthenticated OS command injection through its own web management UI: a value handled by the 'start VNC' feature is later executed as an OS command, a second-order injection reachable with crafted HTTP requests carrying malicious JSON. Bound to this product, the control means FortiSandbox is carried in the technical-vulnerability-management inventory under the same SLA as any other privileged system rather than being treated as part of the defence that inspects everything else, and that the inventory covers every form the affected list names — the FortiSandbox appliance (5.0.0 through 5.0.5, 4.4.0 through 4.4.8, and 4.2 in its entirety), FortiSandbox Cloud 5.0.4 through 5.0.5, and FortiSandbox PaaS 5.0.4 through 5.0.5. An estate that enumerates only its on-premises appliances reports clean while a hosted Cloud or PaaS instance stays on an affected build, so scope the sweep from the affected list rather than from the appliance rack. The 4.2 train needs a per-unit answer: the affected list names it in full and names no fixed build inside it, so the target build for a 4.2 unit has to be obtained from the vendor rather than assumed in either direction. Completion is measured on the build each instance is actually running after its restart — the packet records no live-patching primitive and a vendor update that requires a reboot, so a unit that has taken the image but not rebooted is still executing the vulnerable code and counts as exposed. Distinguishing test: from a host with no management role, send the crafted HTTP/JSON request that drives the 'start VNC' path at a staging FortiSandbox and confirm it is refused before any OS command runs. A vulnerability-management attestation assembled from the platforms FortiSandbox inspects passes cleanly while the inspector itself is unpatched and reachable.",
+        "evidence": "Packet: 'unauthenticated OS command injection reachable via the web management UI (start VNC feature) using crafted HTTP/JSON requests'; a second-order injection per attack_vector. affected_versions: FortiSandbox 5.0.0 through 5.0.5, FortiSandbox 4.4.0 through 4.4.8, FortiSandbox 4.2 (all versions), FortiSandbox Cloud 5.0.4 through 5.0.5, FortiSandbox PaaS 5.0.4 through 5.0.5. CVSS 9.8, RWEP 57, poc_available false, active_exploitation confirmed; CISA KEV 2026-07-16. 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.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability-management scoping routinely excludes the security appliances doing the scanning; a preauth command injection on FortiSandbox itself sits in the blind spot A.8.8 assessment cycles rarely cover, and exploitation preceded the KEV listing.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The FortiSandbox web management UI is the management plane this control governs, and the defect sits on a configuration-accepting path within it: a value the 'start VNC' feature handles is stored and later executed as an OS command, so the endpoint's own decisions — does it authorize this caller, and does it neutralize this value before it reaches a command sink — are the only things between an untrusted HTTP client and command execution on the appliance. Bound to this product the control means every configuration-accepting endpoint on the FortiSandbox management UI authorizes its caller before the submitted JSON is processed at all, and neutralizes the value before the deferred execution rather than at the point of display, since the injection is second-order and a validator that only inspects the immediate request will not see where the value is later used; and no FortiSandbox instance — appliance, Cloud or PaaS — is left with its management surface reachable from a segment with no operational need to reach it. The packet's own summary has this path reachable by an unauthenticated attacker, which is why the endpoint's authorization decision and not the surrounding account model is what matters here: no FortiSandbox operator account is ever presented, so administrator hygiene on the appliance is never consulted. Precondition, stated because this control is most often over-claimed here: the endpoint-side authorization and input neutralization are properties the vendor update establishes — this control says what to verify, it does not implement it, and the packet records no live-patch path and a reboot requirement, so the update is not in force until each unit restarts. Until then, restricting which segments can reach the management UI bounds the population that can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it removes nothing from an instance that was already reached — exploitation attempts were recorded against exposed management UIs from mid-June 2026, before the KEV listing, so an instance that was internet-reachable in that window belongs on the incident path rather than being closed on the patch record. Distinguishing test: from a general user segment and from an external address, attempt to load the FortiSandbox management UI; anything that answers is within reach of the unauthenticated path, and 'the sandbox is on the internal network' is a claim about topology, not a demonstration.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends crafted HTTP requests with malicious JSON to the FortiSandbox web management UI; input handled by the start VNC feature is later executed as an OS command (a second-order injection), yielding command execution on the appliance.' NIST-800-53-SC-7 gap: 'A security appliance whose management UI is internet-reachable defeats boundary protection; the FortiSandbox admin plane must not be exposed to untrusted networks.' UK-CAF-B4 gap: 'System-security expectations do not by themselves force removal of the management interface from public exposure, which is the primary compensating control here.' active_exploitation_notes: 'honeypot telemetry and threat-intel vendors recorded unauthenticated exploitation attempts against exposed FortiSandbox management UIs since mid-June 2026', with the KEV listing on 2026-07-16. patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "What this control has to supply for this entry is a clock short enough to matter, and the packet sets it twice over. CISA listed the flaw on 2026-07-16 with a three-day BOD 26-04 deadline, and exploitation attempts against exposed FortiSandbox management UIs were already being recorded from mid-June 2026 — so a programme that starts counting from the listing date has spent its whole window before the first meeting, and a routine flaw-remediation SLA measured in weeks is not a slower version of the right answer but a different one. poc_available is false, and that is not a deferral argument on this entry: active exploitation is confirmed, which is the stronger signal, and the absence of published exploit code says only that the working code is not public. For FortiSandbox the deployable mitigation is the vendor update, and the packet gives no live-patching primitive and requires a reboot, so 'mitigation deployed' means each appliance, Cloud and PaaS instance is running a fixed build after its restart — an image staged on a unit awaiting a maintenance window is not mitigation and must not be recorded as one. Where the reboot genuinely cannot be taken inside the window, the documented compensating control is removing the management surface from untrusted networks, recorded as a time-boxed compensating state with the reboot still owed; its precondition is that it bounds who can send the crafted request and repairs nothing about the injection itself, so it expires when the reboot lands rather than substituting for it.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-07-16. active_exploitation_notes: 'CISA added it to KEV on 2026-07-16 with a 3-day BOD 26-04 deadline; honeypot telemetry and threat-intel vendors recorded unauthenticated exploitation attempts against exposed FortiSandbox management UIs since mid-June 2026. Ransomware use not confirmed.' poc_available false; active_exploitation confirmed; CVSS 9.8; RWEP 57. 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: 'The BOD 26-04 remediation window was three days, far shorter than a typical enterprise flaw-remediation SLA, and exploitation preceded the KEV listing — patch cadence alone does not close the exposure.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2026-39808": {
     "name": "Fortinet FortiSandbox OS Command Injection Vulnerability (CVE-2026-39808)",
@@ -45083,7 +45313,43 @@
         "adequate": false,
         "gap": "The KEV due date (2026-07-19) is three days from listing; a standard 30-day flaw-remediation SLA leaves the appliance exploitable across the entire observed active-exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Fortinet FortiSandbox, with the tightest clock in this batch: CISA listed it on 2026-07-16 with a due date of 2026-07-19, three days out, and the packet reads that compressed window as itself the signal of observed exploitation. For this appliance the control means the clock runs from the KEV listing to each unit running a fixed build, with the population scoped from both product fields rather than the headline one — affected_versions records 4.4.0 through 4.4.8, and the vector additionally names FortiSandbox PaaS builds, so an estate that sweeps only its self-hosted appliances has not established its exposure and must obtain the PaaS instances' build status from Fortinet rather than assume the hosted service is out of scope. Completion is the build the appliance is executing after its reboot: patch_required_reboot is true and there is no live-patch path, so a unit that has downloaded or staged the update is still running the vulnerable code, and on a detonation appliance mid-queue that reboot is exactly the step a team defers — a deferral recorded as patched is the specific way this remediation goes wrong. Where the reboot cannot be taken inside three days, the compensating clause has to be a documented, time-bound restriction on who can reach the management interface, because that is the exploited surface. Its precondition is a real limit and must be recorded as one: restricting reachability bounds which callers can send the crafted request, it does not neutralise the injection, it gives nothing against a caller inside a permitted segment, and it is simply unavailable where the management interface has to stay reachable for operations. Nothing in the account model helps in the meantime — the packet's attacker is unauthenticated, so no privilege scoping, credential policy or administrator tiering is ever consulted on this path.",
+        "evidence": "Packet: cisa_kev true with kev_date 2026-07-16; active_exploitation confirmed; poc_available true; cvss 9.8 with rwep_score 79. active_exploitation_notes: 'CISA added it to KEV on 2026-07-16 with a 3-day due date, citing crafted-HTTP-request exploitation of internet-facing FortiSandbox appliances by an unauthenticated attacker. Ransomware use is unconfirmed but the compressed remediation window signals observed active exploitation.' vector: unauthenticated OS command injection reaching an OS command without sanitization, 'yielding remote code execution as root. Affects FortiSandbox 4.4.0 through 4.4.8 and FortiSandbox PaaS builds.' affected_versions: 'FortiSandbox 4.4.0 through 4.4.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.' The NIST-800-53-SI-2 gap names the 2026-07-19 due date against a standard 30-day SLA; the UK-CAF-B4 gap states system-security expectations 'do not force isolation of the management plane of a preauth-RCE-exposed sandbox appliance.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "Two of this entry's gaps name the same root cause in different vocabularies: boundary protection does not restrict inbound access to the appliance because it is treated as trusted infrastructure, and technical-vulnerability management never prioritises the appliance's own pre-auth RCE because it is filed as a security control rather than as a server. FortiSandbox is a malware-detonation appliance, and this control's premise is precisely that such a product is in scope of vulnerability management at the same SLA as any other privileged software, with its administrative interfaces treated as testable attack surface rather than as defences. Applied here that means the appliance appears in the asset register as an internet-adjacent server with an exposed management interface, is enrolled in the same patch programme and KEV clock as any other, and has that interface's inbound reachability restricted to networks with an operational need to administer it. Get the direction of the exploited path right or the requirement gets mis-scoped: the packet places the injection in the management interface, in the jid parameter of the /fortisandbox/job-detail/tracer-behavior endpoint reached by unauthenticated crafted HTTP requests — not in sample submission or detonation — so no sample-handling, detonation-policy or submission-source control touches this flaw. The distinguishing test follows the real path: from a network with no administrative role, request that endpoint with shell metacharacters in jid against a staging FortiSandbox, and confirm both that the request never reaches the appliance and that a fixed build refuses it. An estate whose register lists the FortiSandbox under security controls rather than under servers requiring patching passes an A.8.8 attestation cleanly while a root-level unauthenticated RCE stays open. One more reason this asset class is skipped is in the packet itself: the upstream NVD record shipped with no documented attack vector, and the entry had to be reconstructed from the Fortinet PSIRT advisory FG-IR-26-100 and public exploitation reporting — so a triage process keyed to NVD text alone had nothing to act on. Precondition: this control determines whether the appliance is ever scheduled and how reachable it is; the vendor update and its reboot are what remove the injection, and this delivers neither.",
+        "evidence": "Packet: affected 'Fortinet FortiSandbox management/web interface improperly neutralizes special elements in OS commands, allowing an unauthenticated remote attacker to execute arbitrary commands via crafted HTTP requests.' vector: 'An unauthenticated attacker injects shell metacharacters into the `jid` parameter of the /fortisandbox/job-detail/tracer-behavior endpoint; the value reaches an underlying OS command without sanitization, yielding remote code execution as root... Reconstructed from the Fortinet PSIRT advisory (FG-IR-26-100) and public exploitation reporting, as the upstream NVD record shipped without a documented attack vector.' The NIST-800-53-SC-7 gap states 'Boundary-protection controls that treat a security-inspection appliance as trusted infrastructure do not restrict inbound access to its management interface, which is the exploited surface.' The ISO-27001-2022-A.8.8 gap states that technical-vulnerability management 'that treats a FortiSandbox security appliance as trusted never prioritizes its own management-interface pre-auth RCE.' cwe_refs CWE-78; poc_available true; active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SC-7",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Both gaps this attaches to establish that the framework-prescribed clock is longer than the window in which this flaw was being exploited — a 30-day flaw-remediation SLA and an Essential-Eight internet-facing patch window against a KEV due date of three days. On an appliance the packet describes as internet-facing and exploited by an unauthenticated attacker for remote code execution as root, that arithmetic has a consequence the frameworks stop short of stating: an update-and-reboot recorded as remediation removes the injection but removes nothing installed as root before it. For FortiSandbox the control therefore means a unit that was reachable from untrusted networks while running 4.4.0 through 4.4.8 goes down the incident path rather than being closed on the version record — preserve its configuration and logs as evidence, rebuild from vendor firmware and a configuration reviewed against a known-good baseline instead of updating in place, and treat as disclosed every credential held on the appliance and every credential presented to it, rotating each, since root-level execution puts all of it within reach. Preconditions. The trigger is prior reachability during the exposure window, not a detection: the packet supplies no indicator set, so a clean scan is not evidence the rebuild is unnecessary, and nobody should wait for a hit before invoking this. A configuration restore from a backup taken inside the window reinstates whatever was placed there, so the baseline must predate it. And this control does not reduce the chance of exploitation at all — the vendor update and its reboot are the remediation, and this governs only what a compliant response looks like on a unit the clock left exposed while exploitation was under way.",
+        "evidence": "Packet: active_exploitation confirmed; poc_available true; active_exploitation_notes cite 'crafted-HTTP-request exploitation of internet-facing FortiSandbox appliances by an unauthenticated attacker' and note the compressed remediation window signals observed active exploitation. vector records remote code execution as root from an unauthenticated attacker; affected_versions 'FortiSandbox 4.4.0 through 4.4.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.' The NIST-800-53-SI-2 gap: 'The KEV due date (2026-07-19) is three days from listing; a standard 30-day flaw-remediation SLA leaves the appliance exploitable across the entire observed active-exploitation window.' The AU-Essential-8-Patch gap: 'Essential Eight patch-application maturity permits internet-facing patch windows longer than the observed exploitation window for this critical preauth flaw.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2026-46817": {
     "name": "Oracle E-Business Suite Improper Privilege Management Vulnerability",
@@ -46201,25 +46467,58 @@
         "adequate": false,
         "gap": "Flaw remediation SLAs are outpaced by exploitation that began days after disclosure on an end-of-life 4.6.x appliance line that receives no further security fixes."
       }
-    }
-  },
-  "CVE-2024-38217": {
-    "name": "Microsoft Windows Mark of the Web (MOTW) Protection Mechanism Failure Vulnerability",
-    "lesson_date": "2026-07-11",
-    "attack_vector": {
-      "description": "An attacker delivers a crafted .lnk file whose target path forces Windows to rewrite/canonicalize the shortcut, which drops the Zone.Identifier ADS and removes the Mark-of-the-Web so subsequently opened files skip Protected View and SmartScreen prompts.",
-      "privileges_required": "none (unauthenticated), but requires the victim to open the delivered file (UI:R)",
-      "complexity": "low — the LNK-stomping crafting is trivial once the technique is known.",
-      "ai_factor": "Not AI-discovered — reported by Elastic Security Labs. No AI involvement documented."
     },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Apply the September 2024 Windows update; enforce macro blocking and Attack Surface Reduction rules that do not depend solely on MOTW tagging.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation, added 2024-09-10)",
-        "adequacy": "Patch restores MOTW integrity, but any defense that keyed purely on MOTW needs a defense-in-depth layer since MOTW can be stripped by design flaws."
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry carries both halves the control exists to separate. A fix for this CVE exists inside the dead line — the packet's affected_versions record 4.6 Patch 518 and earlier as vulnerable, fixed in 4.6 Patch 519 — while the entry simultaneously records the 4.6.x line as end-of-life, receiving no further security fixes, with the vendor directing removal rather than patching. So the requirement is two-staged and must be written that way: inventory every CSA appliance in service with its running version; units at or below 4.6 Patch 518 are on the interim clock that opened with the 2024-09-13 KEV listing, and reaching Patch 519 closes this command-injection path only. It does not return the appliance to a supported line, so migration to 5.0.x — where the packet records the vulnerable functionality removed outright rather than patched — or decommission is the terminal state, and it needs a dated schedule rather than an open-ended risk acceptance. A requirement that ends at 'every CSA reports 4.6 Patch 519' marks an appliance line the vendor has stopped fixing as compliant while it stays exposed to everything found in it since that build. Precondition on the interim half: live_patch_available is false and the vendor update requires a reboot, so an appliance that has taken Patch 519 but has not rebooted is still executing the vulnerable code and must be counted as exposed, not as remediated.",
+        "evidence": "patch_available true with affected_versions 'Ivanti CSA 4.6 Patch 518 and earlier (fixed in 4.6 Patch 519; functionality removed in 5.0.x)'. The framework_control_gaps record the line as end-of-life in four places: NIST-800-53-SI-2 'an end-of-life 4.6.x appliance line that receives no further security fixes'; ISO-27001-2022-A.8.8 'CSA 4.6.x is EoL, so the only compliant action is decommission/migrate to 5.0.x'; NIS2-Art21-patch-management 'an EoL appliance where the vendor directs removal rather than patching'; AU-Essential-8-Patch 'Essential-8 patch windows are irrelevant for an EoL product; the mitigation is retirement'. 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 listed 2024-09-13, active_exploitation confirmed, poc_available true, RWEP 77, CVSS 7.2, CWE-78.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
       },
-      "detection": {
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For this appliance the update cannot be the whole of the response. The packet records exploitation in the wild within days of disclosure by a suspected nation-state actor, and the outcome of that exploitation is OS command execution on the underlying appliance OS — with the admin access the flaw requires supplied by chaining the CSA authentication bypass CVE-2024-8963, so the effective path needed no legitimate credential. On any CSA that was reachable during that window, the runbook must therefore default to capturing the configuration off the box, rebuilding the appliance from vendor media, and rotating every credential the appliance held or that transited it — not to applying 4.6 Patch 519 over a system that may already carry attacker-executed changes. Patch 519 closes the DateTimeTab.php injection path; it removes nothing an attacker already ran or wrote through it, and the packet gives no live-patch path, so the update also carries a reboot that an implant surviving on disk would simply persist across. Precondition, and it bounds what this control can decide: after root-level command execution the appliance's own logs are not a trustworthy source for scoping the exposure window, so that determination has to come from telemetry held off the appliance. Where none was collected, the appliance belongs in scope by default rather than being cleared.",
+        "evidence": "active_exploitation confirmed; active_exploitation_notes 'Exploited in the wild within days of disclosure by a suspected nation-state actor (FortiGuard, SecurityWeek), frequently chained with the CSA auth-bypass CVE-2024-8963 to reach the admin console.' affected: 'Ivanti Cloud Services Appliance (CSA) administrative console, DateTimeTab.php, allowing an authenticated admin to inject OS commands and gain RCE on the underlying appliance OS.' The NIST-800-53-SI-2 gap states 'Flaw remediation SLAs are outpaced by exploitation that began days after disclosure'. poc_available true; patch_available true with patch_required_reboot true and live_patch_available false; KEV 2024-09-13; RWEP 77.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The CSA administrative console is the management surface here, and the sink is a configuration value on it: the packet places the injection in DateTimeTab.php's TIMEZONE parameter, which reaches OS command execution on the appliance OS. Bound to this appliance, the control means each configuration endpoint on that console makes its own authorization decision rather than inheriting a verdict from the front-door authentication — which is exactly what the paired CVE-2024-8963 bypass defeats to supply the admin privilege this flaw requires — and neutralizes the configuration value before it reaches a shell, so a caller-supplied timezone string cannot carry a command. It also means no CSA is left with its administrative console reachable from a segment with no operational need to reach it. Preconditions, both load-bearing: the endpoint-side neutralization is a property the vendor fix establishes — 4.6 Patch 519 for this CVE, with the packet recording the functionality removed entirely in 5.0.x — so this control states what to verify, it does not implement it. And until that update and its reboot land, restricting which networks can reach the console bounds who can attempt the chain but leaves the endpoint fully exploitable to anything inside the permitted segment; it is unavailable wherever the console must stay remotely reachable for normal operation, which is the exposure the entry's boundary-protection gap records.",
+        "evidence": "attack_vector: 'An attacker with admin access to the CSA console injects OS commands through the DateTimeTab.php TIMEZONE parameter to run arbitrary code on the appliance; admin access is often obtained by chaining the CVE-2024-8963 authentication bypass.' vector: 'a remote authenticated attacker to obtain remote code execution. The attacker must have admin level privileges'. The NIST-800-53-SC-7 gap: 'Boundary protection does not help when the vulnerable admin console is exposed and the attack requires only authenticated admin access, which the paired CVE-2024-8963 bypass supplies.' cwe_refs CWE-78. affected_versions '4.6 Patch 518 and earlier (fixed in 4.6 Patch 519; functionality removed in 5.0.x)'; patch_required_reboot true; live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      }
+    ]
+  },
+  "CVE-2024-38217": {
+    "name": "Microsoft Windows Mark of the Web (MOTW) Protection Mechanism Failure Vulnerability",
+    "lesson_date": "2026-07-11",
+    "attack_vector": {
+      "description": "An attacker delivers a crafted .lnk file whose target path forces Windows to rewrite/canonicalize the shortcut, which drops the Zone.Identifier ADS and removes the Mark-of-the-Web so subsequently opened files skip Protected View and SmartScreen prompts.",
+      "privileges_required": "none (unauthenticated), but requires the victim to open the delivered file (UI:R)",
+      "complexity": "low — the LNK-stomping crafting is trivial once the technique is known.",
+      "ai_factor": "Not AI-discovered — reported by Elastic Security Labs. No AI involvement documented."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Apply the September 2024 Windows update; enforce macro blocking and Attack Surface Reduction rules that do not depend solely on MOTW tagging.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation, added 2024-09-10)",
+        "adequacy": "Patch restores MOTW integrity, but any defense that keyed purely on MOTW needs a defense-in-depth layer since MOTW can be stripped by design flaws."
+      },
+      "detection": {
         "what_would_have_worked": "Hunt for LNK files with non-canonical target paths and for internet-sourced files missing a Zone.Identifier ADS.",
         "was_this_required": false,
         "framework_requiring_it": null,
@@ -48441,7 +48740,28 @@
         "adequate": false,
         "gap": "Access-enforcement controls are bypassed because the traversal reads files entirely outside the application's authorization model, requiring no valid account."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "SolarWinds Serv-U is an internet-facing managed file-transfer server, and the packet's own timing is the argument for this control: the hotfix and mass exploitation were days apart, while the Essential Eight patch-application window the estate is audited against runs up to a month. Bound to this product, the requirement is that every Serv-U instance is enumerated and driven to 15.4.2 Hotfix 2 or later on a clock that starts at the 2024-07-17 KEV listing, not at the next appliance maintenance window and not at the next quarterly vulnerability scan — the packet records quarterly scanning as the specific cadence that misses this flaw entirely. Completion is measured on the version the running Serv-U service reports, because live_patch_available is false and the packet names the vendor update, recorded as requiring no reboot, as the remediation: a host where the hotfix has been staged but the Serv-U service is still executing 15.4.2 Hotfix 1 or earlier is still returning arbitrary host files to unauthenticated requests. Enumeration is the load-bearing half on this product, since a file-transfer server is frequently stood up for a partner integration outside the managed application inventory, and an instance nobody lists is an instance nobody patches while internet-wide scanning is under way. Precondition: reaching Hotfix 2 stops further reads and un-discloses nothing already read, so on any instance that was internet-reachable and unpatched during the exposure window this control is only the first half of the response.",
+        "evidence": "cisa_kev is true with kev_date 2024-07-17, active_exploitation is confirmed and poc_available is true. affected_versions gives Serv-U 15.4.2 Hotfix 1 and earlier, and anything below 15.4.2 Hotfix 2, as affected. patch_available is true; live_patch_available is false with live_patch_notes stating there is no live-patching primitive for this product and that the vendor update (no reboot required) is the remediation. active_exploitation_notes records mass Internet-wide scanning and exploitation with very high EPSS around 0.996, shortly after the Rapid7 write-up and public PoCs appeared. The AU-Essential-8-Patch gap records maturity windows of up to a month against the days between the Serv-U hotfix and observed mass exploitation, and the ISO-27001-2022-A.8.8 gap records that quarterly technical-vulnerability scanning misses an internet-facing MFT appliance flaw under active mass exploitation within days of disclosure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Scope this control honestly to what the packet establishes: the Serv-U primitive is an unauthenticated read, not a write and not code execution, so the implant half of the control — the reason it normally insists on rebuild over patch-in-place — is not what this CVE demonstrates. The half that applies in full is the config-exfil and credential-rotation half, and this CVE demonstrates it as clearly as any entry can. The packet has a crafted HTTP request to the Serv-U web client returning files outside the served directory, including config and credential files, from an attacker holding no account at all, against a server under confirmed mass internet-wide exploitation. So any Serv-U instance that was internet-reachable on 15.4.2 Hotfix 1 or earlier during the exposure window has to be treated as having had those files read: inventory what the host actually held, then rotate every credential recoverable from it — the Serv-U service and administrative accounts, the credentials stored in its configuration, and any transfer-partner or downstream account whose secret sat on that machine — and re-key anything the configuration referenced. Applying Hotfix 2 closes the read path and leaves every already-read secret valid and usable, and that is the precise way this remediation gets recorded as complete while the attacker keeps working credentials into an environment the file-transfer server was trusted to reach. Precondition: rotation is bounded by the inventory, so an instance whose stored credentials were never catalogued cannot be rotated with confidence and the inventory is the first step rather than the last. And rotation is not detection — it does not surface use of a credential already read, so accounts appearing in the Serv-U configuration also need their authentication activity reviewed across and after the exposure window.",
+        "evidence": "affected records that the Serv-U web client permits directory traversal via crafted path parameters, allowing unauthenticated reading of arbitrary files on the host, and attack_vector records the server reading and returning files outside the served directory, including config and credential files, in response to an unauthenticated HTTP request using mixed Windows/Unix separators and encodings. active_exploitation is confirmed and active_exploitation_notes records mass Internet-wide scanning and exploitation with very high EPSS around 0.996; poc_available is true; cisa_kev is true with kev_date 2024-07-17. patch_available is true with the fix at 15.4.2 Hotfix 2 per affected_versions. The UK-CAF-B2 gap records that identity-and-access-control expectations are moot when an unauthenticated traversal reads sensitive files, including credentials, without authenticating at all.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2024-34102": {
     "name": "Adobe Commerce and Magento Open Source Improper Restriction of XML External Entity Reference (XXE) Vulnerability",
@@ -48807,7 +49127,31 @@
         "adequate": false,
         "gap": "System monitoring is undermined because the exploit executes below the NX-OS command-accounting layer, so detection controls relying on CLI logs miss it."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The NX-OS configuration CLI is the constrained user surface this control governs, and the packet describes it failing in exactly the forbidden shape: insufficient validation of arguments passed to specific configuration CLI commands lets an authenticated Administrator's crafted argument execute as an arbitrary root command on the underlying operating system. Bound to this product, the control means the values NX-OS configuration commands hand to underlying OS operations are validated at that boundary, so a command argument cannot select what the underlying OS runs and the CLI's own argument handling is not the single thing standing between an NX-OS Administrator account and root. Scope from affected_versions rather than from one headline platform: MDS 9000 Series and the Nexus 3000, 5500 platform, 5600 platform, 6000, 7000 and 9000 Series, each at the fixed release named in cisco-sa-nxos-cmd-injection-xD9OhyOP. The packet's own vector carves part of that population out and it matters for prioritisation: on Nexus 3000, on Nexus 7000 running 8.1(1) and later, and on Nexus 9000 in standalone NX-OS mode, administrative users already reach the underlying operating system through the bash-shell feature, so the flaw grants no additional privileges there — the boundary this control asserts is load-bearing on the remaining platforms, where the restricted CLI is supposed to be the privilege boundary. Precondition: the vendor update is what repairs the validation; this control states the property to verify and does not implement it. patch_required_reboot is true with no live-patching primitive, so a switch with the fixed image staged but not reloaded still runs the vulnerable code and counts as exposed. Until that reload, the only operator-side lever is limiting which accounts can open an NX-OS Administrator session, which bounds who can attempt the escalation but does not close it, because any account that legitimately reaches the configuration CLI still reaches root. And because exploitation is confirmed, a switch whose Administrator credentials may have been held by an attacker needs forensic triage and credential rotation — the packet records custom malware run on Cisco Nexus switches for persistent, low-visibility access, and the upgrade does not remove what was left behind.",
+        "evidence": "Packet fields: cwe_refs CWE-78; vector 'A vulnerability in the CLI of Cisco NX-OS Software could allow an authenticated user in possession of Administrator credentials to execute arbitrary commands as root on the underlying operating system', 'due to insufficient validation of arguments that are passed to specific configuration CLI commands', and the note that Nexus 3000 Series, Nexus 7000 Series running releases 8.1(1) and later, and Nexus 9000 Series in standalone NX-OS mode 'already allow administrative users to access the underlying operating system through the bash-shell feature, so, for these devices, this vulnerability does not grant any additional privileges'; affected_versions 'Cisco NX-OS on MDS 9000 Series' and 'Nexus 3000, 5500 platform, 5600 platform, 6000, 7000, and 9000 Series (fixed releases per cisco-sa-nxos-cmd-injection-xD9OhyOP)'; 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 'confirmed' with active_exploitation_notes describing Velvet Ant using it as a zero-day 'to run custom malware on Cisco Nexus switches for persistent, low-visibility access'; NIST-800-53-AC-6 gap 'The flaw defeats the CLI/root privilege separation on NX-OS, so least-privilege between admin-CLI and the underlying OS is not actually enforced.'; ISO-27001-2022-A.8.8 gap 'Technical vulnerability management assumes patch closure suffices, but the zero-day was exploited pre-fix by a state actor with valid admin access.'",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The packet makes stolen Administrator credentials the entire precondition for this CVE — it functions as a stealthy escape from the CLI to root for an actor who already holds an admin credential — which is why patch timelines alone leave the chain intact. For this CVE the control means the accounts that administer the NX-OS fabric named in affected_versions (MDS 9000 and the Nexus 3000, 5500 platform, 5600 platform, 6000, 7000 and 9000 Series) are enumerated as a distinct control-plane admin tier rather than collapsed into a general 'network admin' role: the switch management interfaces reachable only from a PAM jumphost, the NX-OS Administrator identity separate from the operator's other accounts, elevation issued just-in-time against an approval record rather than standing, and a phishing-resistant step-up in the authentication path so a credential harvested elsewhere does not by itself open an Administrator session. Where a device's own admin authentication path cannot carry a phishing-resistant factor directly, the enforceable form is the jumphost and the step-up at that hop, with the residual recorded — the control's requirement is that the tier be enumerated and enforced somewhere in the path, not that a claim be made about what the switch's login supports. This is the half that bites during the window before the reload, because it attacks the precondition rather than the injection sink. Precondition and limit: it changes how a session is obtained and does nothing once one is legitimately open. An attacker who compromises the jumphost, satisfies the step-up, or is an authorised administrator still reaches root through the unfixed CLI, so this is a holding measure that runs alongside the fixed release from cisco-sa-nxos-cmd-injection-xD9OhyOP and its reload, never a substitute for it.",
+        "evidence": "Packet fields: vector 'To successfully exploit this vulnerability on a Cisco NX-OS device, an attacker must have Administrator credentials'; active_exploitation_notes 'requires stolen Administrator credentials, so it functions as a stealthy escape from the CLI to root', with exploitation attributed by Sygnia to the China-nexus espionage group Velvet Ant; UK-CAF-B2 gap 'The chain depends on already-stolen administrator credentials, so the CAF's identity objective — phishing-resistant MFA on network-device admin access — is the load-bearing control, yet B2 doesn't force out-of-band MFA on switch CLI logins that would break the credential precondition.'; NIS2-Art21-network-security gap 'Network-security obligations for critical infrastructure do not force out-of-band admin credential hardening (phishing-resistant MFA) that would blunt the credential-dependent chain.'; NIST-800-53-SI-2 gap 'Even prompt patching leaves exposure because exploitation requires already-stolen admin credentials; flaw remediation does not address the credential-theft precondition.'; AU-Essential-8-Patch gap 'no strategy mandates the MFA that blunts the credential-theft chain'; patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIS2-Art21-network-security",
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2020-13965": {
     "name": "Roundcube Webmail Cross-Site Scripting (XSS) Vulnerability",
@@ -49216,10 +49560,10 @@
     },
     "defense_chain": {
       "prevention": {
-        "what_would_have_worked": "Upgrade PHP to 8.1.29/8.2.20/8.3.8 and migrate off PHP-CGI to PHP-FPM; if unavoidable, add mod_rewrite rules blocking the encoded option pattern",
+        "what_would_have_worked": "Upgrade PHP to 8.1.29 / 8.2.20 / 8.3.8, which is what closes the flaw. Where the deployment permits it, also stop routing requests to the CGI binary — the argument path exists because the request becomes command-line arguments handed to php-cgi. If the CGI mapping has to stay, add rewrite rules blocking the encoded option pattern, validated by replaying the 0xAD byte rather than a literal dash.",
         "was_this_required": true,
         "framework_requiring_it": "CISA BOD 22-01 (KEV remediation, added 2024-06-12)",
-        "adequacy": "Patch closes it, but leaving the CGI SAPI in place keeps the fragile Best-Fit surface; FPM migration is the durable fix."
+        "adequacy": "The fixed build closes it. Leaving the CGI SAPI in place keeps the Best-Fit surface for whatever is found in it next, but note what is NOT available as the durable fix here: PHP-FPM is a Unix SAPI and is not shipped for Windows, and Windows Apache with PHP-CGI is the entire affected population — so there is no drop-in interpreter swap on this platform, and the durable options are dropping the CGI mapping where the site does not need it or moving the workload to a platform where a non-CGI SAPI exists."
       },
       "detection": {
         "what_would_have_worked": "Alert on %AD in query strings, PHP-CGI option strings in requests, and php-cgi.exe spawning shells",
@@ -49240,7 +49584,40 @@
         "adequate": false,
         "gap": "Boundary/WAF rules keyed on literal '-' options miss the Best-Fit 0xAD encoding, so perimeter filtering fails to block the argument injection."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The population this SLA governs is narrow and the packet defines it: Windows hosts running Apache with PHP-CGI on a build below PHP 8.1.29, 8.2.20 or 8.3.8. A Linux host, or a Windows host serving PHP through a different SAPI, is not an instance of this CVE and does not belong in the same emergency batch — the vector conditions the flaw on Apache plus PHP-CGI on Windows. For that population the four-hour clock runs from the 2024-06-12 KEV listing, and the reason a monthly or even weekly application-patch cadence is not merely late but useless here is that the packet records mass exploitation already under way at disclosure with an EPSS of roughly 0.9999: the entire standard SLA window is spent on a host that is being exploited. Completion has to be measured on the version the PHP binary Apache actually invokes reports for each site, not on a change ticket, a package record, or an inventory row — a Windows PHP install is commonly an unpacked per-site build that no software-distribution channel tracks, so several vulnerable copies can sit behind one 'PHP upgraded' entry. Precondition: the clock is only enforceable where the operator controls the host. For a site running on a hosted or managed provider the remediation is the provider's to apply, and the deliverable for those is written confirmation of the running PHP version, not a local upgrade; an SLA that silently excludes them reports compliance for the sites the operator can reach while the exposed ones are the ones outside the inventory.",
+        "evidence": "The packet records CISA KEV listing on 2024-06-12 with active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 76, and notes mass exploitation in the wild since disclosure in June 2024 by multiple actors and ransomware operators, with EPSS approximately 0.9999 and CISA KEV flagging ransomware use as Known. patch_available is true with fixed builds PHP 8.1.29, 8.2.20 and 8.3.8; live_patch_available is false and live_patch_notes states there is no live-patching primitive for this product and that the vendor update is the remediation. The cited NIST 800-53 SI-2 gap states the near-immediate mass exploitation outran typical patch SLAs on internet-facing Windows PHP-CGI hosts; the NIS2 Art.21 gap states patch-management timelines are far slower than the observed same-week weaponization; the Essential Eight gap states application-patch timelines trail the near-immediate, ransomware-linked mass exploitation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "The configuration-side path for this CVE is the interpreter mode, and the packet's own PCI gap names it: the patching requirement never prompts anything about the CGI SAPI, so the injectable mode stays deployed on an estate that patches diligently. Applied to a Windows Apache estate the control means holding an inventory of which virtual hosts route requests to the CGI binary, because that is the exposed surface — the primitive here exists because the request becomes command-line arguments handed to the PHP binary, which is a property of the CGI interface rather than of a particular PHP build. State the constraint that bounds this half honestly, because it is the one an operator will hit first: there is no drop-in alternative interpreter mode on the affected platform. PHP-FPM is a Unix SAPI and is not shipped for Windows, and Windows is where this CVE lives, so the available moves are dropping the CGI mapping on sites that do not need it, or moving the workload to a platform where a non-CGI SAPI exists — and for a site that must keep serving PHP through CGI on Windows, neither is available and the fixed build is the remediation. The second half is the request-filtering path, and it is where this is most often recorded as mitigated while staying open: the packet describes the injection arriving as a soft-hyphen (0xAD) that Windows Best-Fit remaps to '-', so any rule written to block option injection must be validated by replaying a request that carries the 0xAD byte, not the literal '-' the rule author had in mind. Distinguishing test: send the encoded form against a staging host and confirm the request is rejected before PHP is invoked; a rule proven against a literal '-' has demonstrated nothing about this CVE. Precondition: the Best-Fit remapping is conditioned on the code page — the packet states it occurs where the system is set up to use certain code pages — so a mitigation premised on the code page requires knowing each host's exact configuration and cannot be asserted fleet-wide, whereas removing the CGI mapping removes the argument path itself. Neither half evicts an attacker already resident on a host that was exposed during the mass-exploitation window.",
+        "evidence": "The packet's vector states the flaw arises when using Apache and PHP-CGI on Windows where the system is set up to use certain code pages, and that Windows may use Best-Fit behavior to replace characters in the command line given to Win32 API functions, which the PHP CGI module may misinterpret as PHP options. The attack_vector records the soft-hyphen (0xAD) being remapped to '-' so that PHP-CGI options (auto_prepend_file=php://input, allow_url_include=1) are injected into the PHP binary, yielding execution of attacker-supplied PHP or disclosure of script source. The cited ISO/IEC 27001:2022 A.8.9 gap states configuration management does not flag the insecure Windows Apache + PHP-CGI + Best-Fit code-page combination that is the precondition for this bug; the PCI DSS 4.0 6.3.3 gap states the requirement is satisfied by the fixed build and prompts nothing about the interpreter mode, and records that PHP-FPM is a Unix SAPI not shipped for Windows so there is no drop-in alternative on the affected platform; the NIST 800-53 SC-7 gap states boundary/WAF rules keyed on literal '-' options miss the Best-Fit 0xAD encoding, so perimeter filtering fails to block the argument injection.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.9",
+          "PCI-DSS-4.0-6.3.3",
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's CAF gap records the failure mode this control exists for: an internet-facing PHP-CGI RCE at an EPSS near 1.0 was mass-exploited faster than an incident-response cycle could spin up, so the runbook has to pre-exist the disclosure rather than be written during it. For this CVE the requirement is that any internet-facing Windows Apache/PHP-CGI host that ran a pre-8.1.29 / 8.2.20 / 8.3.8 build during the exploitation window is triaged as a compromise rather than closed on the upgrade: the primitive the packet describes runs attacker-supplied PHP as the web-server identity, and the upgrade removes the injection path while removing nothing written or read through it. The runbook content is therefore the content of the host, not the version of the binary — web-root and application directories compared against a known-good source, and the database and application credentials held in the site's configuration files rotated, because the same flaw discloses script source and those files were readable through it. Precondition: this is a response control. It does not block the injection, does not shorten the exposure window, and depends on knowing when each host reached the fixed build; a host with no reliable record of its PHP version history has to be treated as exposed for the whole period since the 2024-06-12 KEV listing rather than cleared by an upgrade applied later.",
+        "evidence": "The packet records active_exploitation confirmed with mass exploitation in the wild since disclosure in June 2024 against Windows Apache + PHP-CGI, used by multiple actors and ransomware operators for arbitrary code execution and source disclosure, and CISA KEV flagging ransomware use as Known. The affected field states that command-line options are injectable into the PHP binary, yielding source disclosure or RCE, and the attack_vector records auto_prepend_file=php://input with allow_url_include=1 causing attacker-supplied PHP to execute. The cited UK CAF D1 gap states response-and-recovery planning does not account for the same-week ransomware weaponization observed here, where an internet-facing PHP-CGI RCE is mass-exploited faster than an incident-response cycle can spin up.",
+        "gap_closes": [
+          "UK-CAF-D1"
+        ]
+      }
+    ]
   },
   "CVE-2024-4610": {
     "name": "Arm Mali GPU Kernel Driver Use-After-Free Vulnerability",
@@ -49277,7 +49654,40 @@
         "adequate": false,
         "gap": "Flaw remediation depends on Arm's fix propagating through SoC vendors and Android OEM update chains, so device patch latency vastly exceeds the exploitation window for this KEV-listed mobile LPE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records is a local, non-privileged app performing improper GPU memory-processing operations against the Mali kernel driver to reach already-freed memory and escalate privilege or escape the app sandbox — so the population is every device carrying a Bifrost or Valhall driver in the r34p0-through-r40p0 range, and the remediating state is a build carrying r41p0. The operator cannot make that build exist: the packet's flaw-remediation gap records that Arm's fix has to be integrated by SoC vendors and shipped through Android OEM and carrier update chains. What the operator does hold is the access decision, and this control's requirement is that the fixed driver becomes a condition of access rather than a row on a patch-compliance report — a device that cannot show a build carrying r41p0 is denied mail, VPN and document access until it can. Distinguishing test: enrol a device pinned to a pre-r41p0 build and confirm the policy actually denies it the protected resources; an estate that surfaces the stale driver on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition on the remediation half: patch_required_reboot is true and the packet states there is no live-patching primitive for this product and that the vendor update requires a reboot and is the remediation — so a device that has taken the OEM update but has not rebooted is still executing the pre-r41p0 driver and counts as exposed, not as patched. Precondition on the interim half: restricting installation to vetted application sources raises the bar for getting the attacker's app onto the device, but the packet's exploit runs from an ordinary installed app needing no additional execution privilege, so it does not evict an app already present and does not cover one delivered through the normal store channel; a device suspected of already running such an app belongs on the incident path. This is a holding measure for the window before a build carrying r41p0 lands and is rebooted onto, not a substitute for it.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-06-12; active_exploitation confirmed, with active_exploitation_notes recording that Arm confirmed indications of exploitation in the wild and that a local non-privileged app can leverage it for privilege escalation / sandbox escape across a very large population of Android devices; cwe_refs CWE-416. affected names the Arm Bifrost and Valhall Mali GPU Kernel Drivers (mali_kbase), 'Fixed in driver version r41p0'; affected_versions are 'Bifrost GPU Kernel Driver r34p0 through r40p0' and 'Valhall GPU Kernel Driver r34p0 through r40p0'. 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.' The NIST-800-53-SI-2 gap records that the upstream Arm fix (r41p0) 'must be integrated by SoC vendors and shipped through Android OEM/carrier update chains'; the AU-Essential-8-Patch gap records that OS-patch maturity models 'assume a controllable update path'; the UK-CAF-B4 gap records endpoint-hardening expectations undercut when the vulnerable component is a vendor GPU kernel driver outside the operator's patch control.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance case for this CVE is a device-management console or scanner that reads the device's OS security patch level, finds it current, and reports the fleet remediated. The packet rules that out: the vulnerable component is Arm's Bifrost/Valhall Mali kernel driver, and the packet's own flaw-remediation gap says the r41p0 fix must be integrated by the SoC vendor and shipped through the OEM chain — so an OS-level currency date is not evidence that the driver in service is r41p0 rather than something in the r34p0-through-r40p0 range. The operational test for this entry is the driver version actually running on the device, checked against that affected range and the r41p0 fix, per device model, rather than the OS patch date or the existence of an update policy. Precondition and limit, which is where this control is most often over-claimed: where the management channel cannot report the driver version, the model-and-build to driver-version mapping has to be obtained from the OEM or SoC vendor for that exact model, not assumed in either direction. The packet establishes that the fix may not reach older devices but does not say which models those are, so a model whose status the vendor has not answered is an open question — neither a pass nor a device that can be written off as unfixable.",
+        "evidence": "Packet: affected records the fix as driver version r41p0 and affected_versions give the vulnerable ranges as Bifrost r34p0 through r40p0 and Valhall r34p0 through r40p0. The NIST-800-53-SI-2 gap records that 'The upstream Arm fix (r41p0) must be integrated by SoC vendors and shipped through Android OEM/carrier update chains, so device patch latency far exceeds the exploitation window for a KEV-listed mobile LPE.' The ISO-27001-2022-A.8.8 gap records that technical-vulnerability management for mobile endpoints 'depends on OEM update availability; a control cannot remediate a device whose vendor never ships r41p0.' The AU-Essential-8-Patch gap records that OS-patch maturity models assume a controllable update path 'which does not hold for fragmented Android OEM firmware where the GPU driver fix may never reach older devices.' cisa_kev true (2024-06-12) with active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "Applied to a fleet carrying this driver, the three states the packet forces apart are: a device on a build carrying r41p0 that has been rebooted onto it — remediated; a device still below r41p0 with an access restriction or install policy holding the line — a compensating state that must be reported as such, with a dated action item and a named owner pursuing the OEM for that model; and a device below r41p0 with neither — full exposure to a KEV-listed use-after-free with confirmed exploitation, reachable by any app already installed on it. The gap this closes is the one the packet's patch-management text describes: obligations that cannot reach third-party SoC and OEM firmware pipelines resolve today to 'policy exists and is applied', which reports a fleet as compliant without ever counting how many devices sit in the third state or for how long. The verdict class makes that count exist and makes it age, and it stops the second state being recorded as patched-per-SLA. Precondition: the compensating state is not remediation and must not close the item — the packet records no live-patching primitive and names the reboot-requiring vendor update as the remediation, so an access restriction bounds what a compromised device can reach while the local escalation on the device itself stays fully available to any app already installed there.",
+        "evidence": "Packet: 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 with kev_date 2024-06-12 and active_exploitation confirmed. The NIS2-Art21-patch-management gap records that 'Patch-management obligations cannot force fixes through third-party SoC/OEM firmware pipelines that carry the Mali driver, leaving managed mobile fleets exposed.' The ISO-27001-2022-A.8.8 gap records that 'a control cannot remediate a device whose vendor never ships r41p0.' The attack vector is a local, non-privileged app using the use-after-free to corrupt kernel memory and escalate privileges or escape the app sandbox.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2017-3506": {
     "name": "Oracle WebLogic Server OS Command Injection Vulnerability",
@@ -49314,7 +49724,30 @@
         "adequate": false,
         "gap": "Least-functionality guidance rarely mandates disabling/removing the unused WLS-WSAT (SOAP) subcomponent, leaving the command-injection endpoint enabled by default."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "WebLogic's WLS-WSAT handler is exactly the service-protocol endpoint this control governs, expressed over HTTP: a transaction-coordination web service that answers a peer which never authenticates, and whose parsing of the work-context XML is itself the vulnerable code — the packet's path is an unauthenticated POST of a crafted SOAP/XML document that reaches a ProcessBuilder gadget and executes attacker-supplied OS commands. Bound to Oracle WebLogic Server 10.3.6.0, 12.1.3.0, 12.2.1.0, 12.2.1.1 and 12.2.1.2 inside Fusion Middleware, the requirement is that the subcomponent stops being enabled by inheritance. For each managed server, establish whether any deployed application actually uses WS-AtomicTransaction; where none does, disable or remove the wls-wsat subcomponent rather than leaving the endpoint enabled by default, which is the step the least-functionality, system-security and application-hardening gaps all record that no framework mandates. Where an application genuinely depends on it, restrict which sources may reach the /wls-wsat/ path so an internet peer cannot present the document at all, and constrain what the work-context XML is permitted to construct, instead of inheriting safety from the assumption that only legitimate transaction peers speak to that endpoint. Distinguishing test: from an external address, POST a crafted work-context SOAP document to /wls-wsat/ on a staging server and confirm it is refused before the XML is parsed — a server that passes a WebLogic patch-level and account audit while the WSAT path answers unauthenticated from the internet still carries the sink, and because the flaw is pre-authentication no account or privilege review ever consults the attacker. Preconditions: removal closes this path only where nothing deployed depends on WS-AtomicTransaction; where something does, path restriction bounds who can reach the endpoint but leaves it fully exploitable to anything inside the permitted set, and it is unavailable where the endpoint must answer external partners. Neither substitutes for the vendor update, which the packet records as the remediation with no live-patch primitive.",
+        "evidence": "Packet vector and attack_vector: an unauthenticated attacker with network access over HTTP POSTs a crafted SOAP/XML request to the Oracle WebLogic Server Web Services (WLS-WSAT) endpoint; the server deserializes the work-context XML and, via a ProcessBuilder gadget, executes attacker-supplied OS commands. affected_versions 10.3.6.0, 12.1.3.0, 12.2.1.0, 12.2.1.1, 12.2.1.2; CWE-78; CVSS 7.4 (AV:N/AC:H/PR:N/UI:N); active_exploitation confirmed; poc_available true; CISA KEV 2024-06-03; patch_available true; live_patch_available false with live_patch_notes recording no live-patching primitive and the vendor update as the remediation. NIST-800-53-CM-7 gap: least-functionality guidance rarely mandates disabling or removing the unused WLS-WSAT (SOAP) subcomponent, leaving the command-injection endpoint enabled by default. UK-CAF-B4 gap: hardening baselines do not require stripping the unused WebLogic SOAP handler. AU-Essential-8-App-Hardening gap: application-hardening maturity does not require removing the vulnerable WebLogic SOAP handler. NIS2-Art21-network-security gap: network-security baselines do not require blocking or restricting the wls-wsat URL path at the perimeter while patching.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV listing for this WebLogic flaw came on 2024-06-03, years after the vendor fix, so the control's 'whichever is later' clause resolves to the listing date and the accelerated clock applies to a CVE whose patch has long been available — which is the gap the vulnerability-management statement on this entry records, that technical-vulnerability management overlooks legacy middleware subcomponents so a KEV-listed 2017 RCE persists on internet-facing servers. The scoping consequence is specific to this product: the population is every Fusion Middleware install running 10.3.6.0, 12.1.3.0, 12.2.1.0, 12.2.1.1 or 12.2.1.2 — the versions the packet names — and the KEV trigger has to fire against a subcomponent-level finding naming wls-wsat, because a product-level scan that reports only 'an old WebLogic' gives an operator nothing to act on and is how a KEV-listed sink survives repeated review cycles. Remediation is the vendor update; the packet records no live-patching primitive, so completion is measured on the version the running managed servers report rather than on a patch-set download. Because the packet records a public proof-of-concept and years of abuse of this WLS-WSAT vector by cryptomining and access-broker actors against internet-facing WebLogic, a server found past the clock is triaged for prior compromise rather than simply brought current — the exposure predates the listing by years, so the SLA governs how fast it closes, not whether the server was already reached.",
+        "evidence": "Packet: CISA KEV 2024-06-03 for a 2017 CVE; active_exploitation confirmed; poc_available true; patch_available true; live_patch_available false with live_patch_notes recording no live-patching primitive for this product and the vendor update (no reboot required) as the remediation; affected_versions 10.3.6.0, 12.1.3.0, 12.2.1.0, 12.2.1.1, 12.2.1.2; RWEP 72, CVSS 7.4. active_exploitation_notes: the WLS-WSAT vector, shared with CVE-2017-10271, has been abused for years by cryptomining and access-broker actors against internet-facing WebLogic, with no specific ransomware attribution. ISO-27001-2022-A.8.8 gap: technical-vulnerability management overlooks legacy middleware subcomponents like wls-wsat, so a KEV-listed 2017 RCE persists on internet-facing servers.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-1086": {
     "name": "Linux Kernel Use-After-Free Vulnerability (CVE-2024-1086)",
@@ -49718,7 +50151,41 @@
         "adequate": false,
         "gap": "Article 32 'appropriate technical measures' for PHI were undermined by an unauthenticated RCE that grants full access to health-data flows passing through the integration engine."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "CVE-2023-43208 is the second CVE on the same Mirth Connect primitive, and the packet says so outright: the vulnerability is caused by the incomplete patch of CVE-2023-37679. That changes what vulnerability management owes this product. An operator who applied the CVE-2023-37679 fix, recorded Mirth Connect as remediated and moved on was still running an unauthenticated remote-code-execution path, which is why re-verification rather than a version check is the requirement here — the running instance must be confirmed at 4.4.1 or later, not merely 'at a release after the earlier fix'. Because this is the second defect on the same deserialization and command-injection primitive, the programme must also carry forward the assumption the packet's history supports: a third bypass on this primitive is likely rather than surprising, so each subsequent Mirth Connect security release is re-tested against the class instead of being accepted on the vendor's word that the earlier issue is closed. Distinguishing test: take a staging Mirth Connect on a build that carries the CVE-2023-37679 fix but is below 4.4.1, replay the unauthenticated code-execution path against it, and confirm it still succeeds — an ISMS whose register records the CVE-2023-37679 remediation as applied reports that same instance clean. Precondition: this control changes triage and verification, it does not close the sink; only the 4.4.1 build does that, and until it is the version the service reports, the instance is exposed to a path with a public proof-of-concept and confirmed, ransomware-associated exploitation.",
+        "evidence": "Packet fields for CVE-2023-43208: vector states NextGen Healthcare Mirth Connect before version 4.4.1 is vulnerable to unauthenticated remote code execution and that this vulnerability is caused by the incomplete patch of CVE-2023-37679; cwe_refs CWE-78 and CWE-502; affected_versions '< 4.4.1'; poc_available true; cisa_kev true, kev_date 2024-05-20, with active_exploitation_notes recording it as ransomware-associated (ransomware: Known), mass-exploited against healthcare integration servers for initial access and ransomware staging, EPSS 0.83; active_exploitation confirmed; cvss 9.8; rwep_score 69; patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "Mirth Connect is an HL7 integration engine: its listeners exist to accept interface traffic from other systems, and the packet places the defect precisely on that surface — an unauthenticated attacker sends a crafted serialized payload to a Mirth Connect endpoint and unsafe deserialization becomes OS command execution as the service account. Applied to this product, the control means treating every Mirth Connect listener as a trust boundary rather than an internal convenience: bind channel and administration listeners to the interface segment instead of all interfaces, restrict each listener to the specific sending systems with an operational need to connect to it rather than to any host that can route to the port, require peer authentication on every protocol the engine has enabled and not only the one the live interfaces happen to use, and constrain what arriving content is permitted to construct or evaluate instead of inheriting safety from the assumption that the integration server sits inside the hospital network. The packet's boundary gap records the failure this addresses directly — these servers are frequently internet-facing to receive HL7 and interface traffic, and boundary controls rarely restrict the listener to trusted senders. The health-data exposure follows from the same reachability: everything the engine routes passes through the process this payload executes in. Distinguishing test: from a host with no interface role that can route to the listener on a staging Mirth Connect, open a connection and send content the HL7 interface never legitimately conveys, and confirm the peer is rejected before the server acts on the content. Precondition: restricting reach bounds who can send the payload, it does not repair the deserialization — any permitted sender, or anything that compromises one, still reaches the sink — and it is unavailable for a listener that must accept connections from an external trading partner. It is a holding measure alongside the 4.4.1 upgrade, not a substitute for it.",
+        "evidence": "Packet fields for CVE-2023-43208: attack_vector states an unauthenticated attacker sends a crafted serialized payload to an internet-facing Mirth Connect endpoint, where unsafe deserialization leads to OS command execution as the service account; affected describes unauthenticated RCE via untrusted-data deserialization / OS command injection in Mirth Connect before 4.4.1; framework_control_gaps NIST-800-53-SC-7 records that Mirth Connect servers are frequently internet-facing to receive HL7/interface traffic and that boundary controls rarely restrict the listener to trusted senders, exposing the preauth deserialization endpoint; framework_control_gaps GDPR-Art32 records that the unauthenticated RCE grants full access to health-data flows passing through the integration engine; cvss 9.8; poc_available true; active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "GDPR-Art32"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Mirth Connect entered KEV on 2024-05-20 flagged ransomware-associated, with a public proof-of-concept and EPSS 0.83 against an unauthenticated remote-code-execution path — a combination that leaves no room for a monthly or fortnightly application-patch cadence on an internet-facing healthcare integration server. The requirement for this product is that the 4.4.1 build is deployed within hours of KEV listing or fix availability, whichever is later, and that completion is measured on the version the running Mirth Connect service reports rather than on the installer having been run. That distinction is the one this deployment gets wrong: patch_required_reboot is false, which means the host needs no reboot — it does not mean the fix is live. The Java service continues executing the pre-fix code until it restarts onto the new build, and because the packet records no live-patch primitive, there is no way to apply the fix to the running process. Any completion report that counts a host as remediated before that service restart is counting an exposed system. Where the engine cannot be stopped inside the window — the usual reason this slips, because stopping it stops clinical message flow — the packet records no vendor mitigation and no live-patch path, so the only interim lever is constraining who can reach the listener, and the deferral must be recorded as an exposed system with a dated action rather than as patched per SLA.",
+        "evidence": "Packet fields for CVE-2023-43208: cisa_kev true, kev_date 2024-05-20, active_exploitation confirmed, active_exploitation_notes recording ransomware association (ransomware: Known), mass exploitation of healthcare integration servers for initial access and ransomware staging, and EPSS 0.83; poc_available true; cvss 9.8; rwep_score 69; patch_available true with the fixed version given by vector and affected_versions as 4.4.1; patch_required_reboot false; live_patch_available false with live_patch_notes stating there is no live-patching primitive for this product and that the vendor update (no reboot required) is the remediation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-4761": {
     "name": "Google Chromium V8 Out-of-Bounds Memory Write Vulnerability",
@@ -50275,7 +50742,39 @@
         "adequate": false,
         "gap": "Least privilege assumes administrator accounts are trustworthy, but this flaw lets an admin-level actor escalate to persistent root code execution — a privilege boundary AC-6 does not enforce within the appliance."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Cisco ASA and FTD are the perimeter-trust-boundary devices this control governs, and this CVE is the property the control turns on stated outright by the vendor: the injected code executes on the next reload and persists across device reboots, which is why Cisco raised the advisory's Security Impact Rating from Medium to High. The trigger here is an administrator credential rather than an unauthenticated request, but that changes who reaches the primitive, not what patch-in-place leaves behind — and it sharpens the problem, because the vendor update itself requires a reboot, so the device comes back running fixed software with whatever was written to disk0: still present and still executing. Applied to this appliance the requirement is that a unit whose administrative interface was reachable during the exposure window is triaged as compromised rather than closed on the upgrade: running and startup configuration exported and diffed against a known-good baseline, the contents of disk0: inventoried against what the vendor expects to be there, and every credential the appliance held or terminated rotated — device administrator accounts, VPN pre-shared keys and certificates, and the authentication-server secrets stored on it — with reimaging from vendor-verified software where the unit cannot be shown clean. Precondition: this is a response control and it depends on knowing the exposure window. It does not prevent the write and it produces no evidence of its own; an upgrade already applied to a unit that carried the implant has neither removed it nor demonstrated that it was absent, so a unit with no record covering the period cannot be cleared by the version it now reports.",
+        "evidence": "The packet records CISA KEV listing on 2024-04-24 with active_exploitation confirmed, attributing exploitation to the ArcaneDoor espionage campaign (actor UAT4356 / Storm-1849) against Cisco ASA/FTD perimeter devices and naming the Line Runner implant; ransomware use is not confirmed. The vector states a successful exploit could allow the attacker to execute arbitrary code on the affected device after the next reload of the device, and that because the injected code could persist across device reboots Cisco raised the Security Impact Rating from Medium to High. patch_available is true (multiple ASA and FTD releases per cisco-sa-asaftd-persist-rce-FLsNXF4h), patch_required_reboot is true, live_patch_available is false, and live_patch_notes states the vendor update requires a reboot and is the remediation. The cited NIS2 vulnerability-handling gap states NIS2 measures assume patching removes the threat but a pre-existing implant survives the update; the ISO/IEC 27001:2022 A.8.8 gap states technical vulnerability management cannot see a root implant that persists across reloads unless image-integrity verification is part of A.8.8; the NIST 800-53 SI-2 gap states the compressed 2024-05-01 KEV due date reflected active espionage use and that firmware-patch cycles for perimeter devices are slow relative to a persistent implant that survives reboots.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The surface this control governs on an ASA or FTD unit is the legacy VPN client and plug-in preloading capability the packet names, and this CVE is that surface wired straight to a root operation: a file copied into the disk0: file system is read from flash without proper validation and executed with root-level privileges on the next reload. Bound to this appliance the control means the preload path validates the origin and integrity of what it loads from flash before executing it, so that an administrator's ability to place a file on disk0: — an ordinary operational capability on these devices — is not the same capability as running root code that survives reboots. This is exactly why the least-privilege and privileged-access gaps cited on this entry pass their attestations while the path stays open: the actor is a legitimate administrator, so no account model is being violated, and a privileged-access review confirming every ASA administrator is named, approved and multi-factor protected never touches the flash-to-root path. Distinguishing test: on a staging ASA or FTD unit, place an unvalidated file into the preload location on disk0: and reload, and confirm it is refused rather than executed. Precondition: the validation is a property the vendor update establishes — this control states what to verify, it does not implement it. Until the update and its required reboot land, the only operator-side lever is restricting which accounts and which source networks reach the appliance's administrative and file-transfer interfaces, which bounds the population that can perform the write but does not close the path, because any account that legitimately administers the device still reaches disk0:.",
+        "evidence": "The packet's vector places the flaw in a legacy capability that allowed for the preloading of VPN clients and plug-ins in Cisco ASA and FTD Software, states that administrator-level privileges are required to exploit it, and attributes it to improper validation of a file when it is read from system flash memory; the recorded weakness is CWE-94. The attack_vector records an attacker holding administrator credentials copying a crafted file to the disk0: file system, which on the next device reload executes as root and persists across reboots. The cited NIST 800-53 AC-6 gap states least privilege assumes administrator accounts are trustworthy but this flaw lets an admin-level actor escalate to persistent root code execution, a privilege boundary AC-6 does not enforce within the appliance; the AU ISM 1546 gap states privileged-access management controls do not prevent a compromised administrator from writing a malicious file to flash, so the ISM control leaves the escalation-to-root path open.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "An ASA or FTD unit is precisely the perimeter device this control names, and this CVE is the case that makes its on-box logs worthless as evidence: the outcome is arbitrary code execution with root-level privileges on the appliance itself, so an actor who reaches that state is inside the same system that holds the local log and audit record of how they got there. For this CVE the telemetry that matters is the sequence the exploit requires and the packet documents — an authenticated administrative session, a file copied into the disk0: file system, and a device reload shortly afterwards — forwarded as it happens to a collector in a separate trust zone with different credentials and a different authentication path, so the record of the write outlives the compromise it records. That correlation is what an exploit doing exactly what the packet describes emits; alerting on appliance health or on signatures for known tooling would not see it, because nothing crashes, the device reload is a routine administrative event in isolation, and the implant the packet names is bespoke to the campaign. Precondition: this only yields evidence that was already being shipped off-box before the attempt — a collector stood up after the advisory has nothing to show for the exposure window — and it detects rather than prevents. It neither blocks the write to flash nor removes code already persisting across reboots, so a unit with no off-box record covering the period belongs on the rebuild path rather than being cleared by the absence of alerts.",
+        "evidence": "The packet records the outcome as an authenticated, local attacker executing arbitrary code with root-level privileges, reached by copying a crafted file to the disk0: file system so that it executes after the next reload of the device, with the injected code persisting across device reboots. active_exploitation is confirmed and attributed to the ArcaneDoor espionage campaign (UAT4356 / Storm-1849) with the Line Runner implant, and the CVE was added to CISA KEV on 2024-04-24. The cited UK CAF C1 gap states security-monitoring and detection-evasion controls do not catch the persistent root implant this ASA/FTD flaw writes to flash during the admin-to-root escalation, so the implant survives reboots and evades the monitoring CAF-C1 assumes would surface it.",
+        "gap_closes": [
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2024-20353": {
     "name": "Cisco ASA and FTD Web Services Denial of Service Vulnerability",
@@ -50769,7 +51268,39 @@
         "adequate": false,
         "gap": "Ransomware operators weaponized this SharePoint RCE, and the observed exploitation cadence outpaced the flaw-remediation SLAs many operators apply to on-prem SharePoint."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet names Microsoft SharePoint Server 2019 and SharePoint Server Subscription Edition, records the KEV listing on 2024-03-26 with ransomware association Known, and notes the flaw was originally demonstrated at Pwn2Own Vancouver 2023 by STAR Labs — so the exploitation know-how predates the listing by a long margin and the response window was never the interval the KEV date suggests. For this CVE the control's load-bearing effect is refusing to discount the SLA on the 'requires an authenticated Site Owner' reading of the prerequisite: the packet records that privilege being routinely supplied by chaining CVE-2023-29357's authentication bypass, which is how the flaw is reached unauthenticated in the campaigns actually observed. Remediation is the vendor update — patch_available is true, live_patch_available is false, and the packet's live-patch note states the update requires a reboot and is the remediation — so the clock runs through the restart of every SharePoint server running an affected product, and a server that took the update but has not rebooted still carries the vulnerable code however the deployment console reports it. Both products in the affected list are in scope: an estate inventory built around one of them leaves the other unremediated while the flaw-remediation record reads complete.",
+        "evidence": "Packet: cisa_kev true with kev_date 2024-03-26; active_exploitation confirmed; active_exploitation_notes record exploitation in the wild, CISA KEV flagging association with ransomware campaigns (Ransomware association: Known), chaining with CVE-2023-29357 (auth bypass) to reach unauthenticated RCE, and the original demonstration at Pwn2Own Vancouver 2023 by STAR Labs. affected_versions: Microsoft SharePoint Server 2019 and Microsoft SharePoint Server Subscription Edition. poc_available true; CVSS 7.2, RWEP 75; 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.' The flaw-remediation gap records the observed exploitation cadence outpacing the SLAs many operators apply to on-prem SharePoint.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records this SharePoint code injection as exploited in the wild with ransomware association Known, and its incident-handling gap names the consequence an operator has to plan around: the pivot from a SharePoint RCE into domain-wide impact. Applied to this product, the requirement is that a SharePoint Server 2019 or Subscription Edition instance which was below the fixed build while exploitation was running is handled as an incident rather than closed as a patch ticket. The injected code was evaluated server-side with the privilege of the SharePoint worker process, and the vendor update repairs the injection path without removing anything that execution left behind — so the default is to preserve and export first, rebuild at the fixed build rather than updating the exposed instance in place, and rotate the credentials that server held along with those that authenticated through it during the exposure window, which is the step that actually bounds the domain-wide pivot the packet names. The chained precondition changes what the rotation review should expect to find: the packet records the Site Owner privilege being obtained through CVE-2023-29357's authentication bypass rather than granted, so an account review looking for unexpected Site Owner assignments finds nothing while the access was entirely real. Restarting the rebuilt server onto the fixed build is part of reaching remediation here, since the packet records no live-patch path and a vendor update that requires a reboot.",
+        "evidence": "Packet: active_exploitation confirmed; active_exploitation_notes record exploitation in the wild, CISA KEV flagging association with ransomware campaigns, and chaining with CVE-2023-29357 to reach unauthenticated RCE. attack_vector: an attacker holding Site Owner privileges, often obtained by first exploiting CVE-2023-29357's auth bypass, injects code through a crafted SharePoint API/BDC path that SharePoint evaluates server-side, achieving remote code execution used in ransomware operations. The NIS2-Art21-incident-handling gap states incident-handling readiness under-accounts for ransomware chains that pivot from a SharePoint RCE into domain-wide impact. The UK-CAF-B2 gap states the Site Owner privilege is not a legitimate grant but is obtained by chaining the auth bypass. 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.'",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance failure on this entry is a scan that reports a SharePoint farm remediated on the strength of a single update record, and the packet establishes two separate reasons that record can be wrong. First the chain: the packet states the real severity of this code injection is realized only together with CVE-2023-29357's authentication bypass, which is what supplies the Site Owner privilege the injection requires — so a server carrying the fix for this CVE while the auth-bypass fix is missing has closed one half of the path attackers actually traverse, and a per-CVE scan result reads clean either way. Second the running state: patch_required_reboot is true and the packet's live-patch note records that the vendor update requires a reboot and is the remediation, so a server whose update is installed but not restarted is still executing vulnerable code while its patch record says otherwise. The distinguishing test is therefore to produce, per SharePoint server across both Microsoft SharePoint Server 2019 and Subscription Edition, the build actually running after restart, and to show both fixes present on that build — not to read 'update applied' out of the deployment console. An estate that runs the console report into its technical-vulnerability-management evidence pack satisfies the attestation while the exploited chain stays intact end to end.",
+        "evidence": "Packet: the ISO-27001-2022-A.8.8 gap states technical vulnerability management that patches CVE-2023-24955 in isolation misses that its real severity is realized only in chain with the auth-bypass CVE-2023-29357. active_exploitation_notes record that it is commonly chained with CVE-2023-29357 to reach unauthenticated RCE on SharePoint Server. 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_versions: Microsoft SharePoint Server 2019 and Microsoft SharePoint Server Subscription Edition. The flaw-remediation gap records the observed exploitation cadence outpacing the SLAs applied to on-prem SharePoint. poc_available true; active_exploitation confirmed; kev_date 2024-03-26.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2019-7256": {
     "name": "Nice Linear eMerge E3-Series OS Command Injection Vulnerability",
@@ -50806,23 +51337,55 @@
         "adequate": false,
         "gap": "eMerge E3 access-control panels are frequently exposed directly to the internet; boundary controls that would block the CGI endpoints are commonly absent for physical-security appliances."
       }
-    }
-  },
-  "CVE-2021-44529": {
-    "name": "Ivanti Endpoint Manager Cloud Service Appliance (EPM CSA) Code Injection Vulnerability",
-    "lesson_date": "2026-07-11",
-    "attack_vector": {
-      "description": "An unauthenticated attacker sends a crafted request to the CSA web interface (/client/index.php), which passes attacker input to code-execution routines via csrf-magic.php, running arbitrary code as the low-privileged 'nobody' user as an initial foothold.",
-      "privileges_required": "none (unauthenticated)",
-      "complexity": "low — a Metasploit module and Exploit-DB entry automate the unauthenticated RCE.",
-      "ai_factor": "Not AI-discovered — reported by researcher Jakub Kramarz. No AI involvement documented."
     },
-    "defense_chain": {
-      "prevention": {
-        "what_would_have_worked": "Upgrade the CSA to 4.6.0-512 or later and remove the management interface from internet exposure.",
-        "was_this_required": true,
-        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation, added 2024-03-25)",
-        "adequacy": "Patching closes the injection, but appliances exposed for years may already be compromised, so the CSA should be assumed breached and rebuilt."
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The Nice/Linear eMerge E3-Series panel is the management surface for the door hardware it drives, and this defect sits on its web endpoints: the packet has an unauthenticated remote attacker sending a crafted HTTP request whose parameter is passed into a shell command without sanitization, executing OS commands on the panel. Bound to this product, the control means each web endpoint on the panel authorizes its caller before the request is processed at all, and neutralizes request parameters before any of them reach a shell invocation, so a caller-supplied string cannot select what the panel executes; and no panel is left with that web interface reachable from the internet or from a segment with no operational need to reach it. This is why the least-privilege style of control never engages here — the attacker holds no account on the panel, so no account model is consulted and no credential policy is exercised; the endpoint's own authorization decision is the only thing between an untrusted caller and a shell. Preconditions, both load-bearing. The endpoint-side authorization and input neutralization are properties the vendor firmware update establishes — this control states what to verify, it does not implement it — and the packet records affected firmware only as 1.00-06 and earlier per the vendor advisory, so the target build must be obtained from that advisory for the model in service rather than assumed. And the reachability half bounds who can send the request without closing the endpoint: anything inside the permitted segment still reaches it unauthenticated, so for a panel that the badge readers, door controllers and its administrators must reach, the achievable reduction is isolating that segment from everything else, not removing the path. Distinguishing test: from an ordinary user VLAN and from an external address, attempt to load the panel's web interface — anything that answers is within reach of the published exploit, because the attacker supplies no credential past that point.",
+        "evidence": "The packet's affected field records OS command injection in the eMerge E3-Series web interface reachable by an unauthenticated remote attacker, and its attack vector is a crafted HTTP request to a web endpoint that passes a parameter into a shell command without sanitization, enabling botnet enrollment or full takeover. poc_available true, active_exploitation confirmed, CVSS 9.8, RWEP 75, with EPSS ~0.97 reflecting long-running mass exploitation by IoT botnets including Mirai variants against internet-exposed panels. The SC-7 gap records the panels frequently exposed directly to the internet with the boundary controls that would block the CGI endpoints commonly absent for physical-security appliances; the NIS2 network-security gap records physical-access-control systems rarely segmented from IT networks, so a compromised panel pivots into the enterprise; the AU-ISM-1546 gap records appliance-hardening guidance not covering embedded PHP web stacks on access-control panels that pass input to shell commands; the UK-CAF-B4 gap records system-security governance seldom extending to these panels, leaving the unauthenticated command injection unhardened. Affected versions are recorded as firmware 1.00-06 and earlier per the vendor advisory.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "AU-ISM-1546",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "These panels sit outside the tooling an estate's patch SLA actually runs on — the packet's flaw-remediation gap states the device firmware is rarely patched and that standard remediation cadence does not reach unmanaged OT and physical-security gear — so the requirement for this CVE is that the eMerge E3 fleet be enumerated and assigned a named owner on the KEV clock that opened 2024-03-25, explicitly, rather than inheriting an IT patch cycle it is invisible to. The packet names affected firmware only as 1.00-06 and earlier per the vendor advisory and gives no fixed build, so the target level must be read from that advisory for the model in service, and completion is measured by the firmware the panel reports after it has restarted onto it: patch_required_reboot is true and live_patch_available is false, so a panel that has taken the firmware but not rebooted is still running the injectable code. That reboot is the step most likely to be deferred on this product class, because taking it interrupts the door access a building depends on, and a deferral recorded as patched is the specific way this remediation goes wrong here. Precondition on the interim window: the packet records no live-patch path and no vendor mitigation rule, so the only lever while the reboot is outstanding is removing the panel's reachability from the internet and from general networks — which bounds who can send the request but leaves the endpoint fully exploitable from anything still permitted to reach it, and does nothing for a panel already compromised during the years the packet says this has been exploitable.",
+        "evidence": "CISA KEV listing 2024-03-25 with active_exploitation confirmed, CVSS 9.8, RWEP 75 and poc_available true; patch_available true with patch_required_reboot true and live_patch_available false, the packet's live_patch_notes stating there is no live-patching primitive for this product and that the vendor update requires a reboot and is the remediation. affected_versions is recorded only as 'Linear eMerge E3-Series firmware 1.00-06 and earlier (per vendor advisory)'. The SI-2 gap states the device firmware is rarely patched, the flaw has been exploitable for years, and standard vulnerability-remediation cadence does not reach unmanaged OT/physical-security gear.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records years of mass exploitation of internet-exposed eMerge E3 panels by IoT botnets, with the outcome given as botnet enrollment or full takeover of the panel. On a panel that was internet-reachable while below the vendor's fixed firmware, the update is a code replacement rather than an eviction, so the default disposition for such a unit is a rebuild: bring its configuration up from a known-good baseline instead of carrying the running configuration through the firmware update, and rotate its administrative credential and anything else it holds, because command execution on the panel gave the attacker the same reach into that configuration the operator has. Precondition on scoping: this applies to panels whose exposure during the window can be established, and the packet's own boundary gap says these panels are frequently exposed directly to the internet — so an estate that cannot demonstrate a given panel was unreachable should treat it as in scope rather than closing it on the firmware version alone. Note what the rebuild does not settle: this is a physical-access-control device, and the packet's stated outcome of full takeover makes the door and credential activity recorded for the exposure window part of the same review, not only the host's software state. The rebuild also has to be sequenced behind the reachability restriction and the firmware update, since a panel restored to a known-good configuration while still reachable is re-exploitable by the same public request.",
+        "evidence": "active_exploitation confirmed with CISA KEV listing 2024-03-25 and poc_available true; the packet's exploitation notes record EPSS ~0.97 reflecting long-running mass exploitation by IoT botnets including Mirai variants against internet-exposed eMerge E3 access-control panels, preauth with no user interaction, and the attack vector ends in injected OS commands executing on the panel enabling botnet enrollment or full takeover. patch_available true with patch_required_reboot true and no live-patch path. The SI-2 gap states the flaw has been exploitable for years and that standard vulnerability-remediation cadence does not reach this class of device — the interval in which the confirmed exploitation occurred.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
+  },
+  "CVE-2021-44529": {
+    "name": "Ivanti Endpoint Manager Cloud Service Appliance (EPM CSA) Code Injection Vulnerability",
+    "lesson_date": "2026-07-11",
+    "attack_vector": {
+      "description": "An unauthenticated attacker sends a crafted request to the CSA web interface (/client/index.php), which passes attacker input to code-execution routines via csrf-magic.php, running arbitrary code as the low-privileged 'nobody' user as an initial foothold.",
+      "privileges_required": "none (unauthenticated)",
+      "complexity": "low — a Metasploit module and Exploit-DB entry automate the unauthenticated RCE.",
+      "ai_factor": "Not AI-discovered — reported by researcher Jakub Kramarz. No AI involvement documented."
+    },
+    "defense_chain": {
+      "prevention": {
+        "what_would_have_worked": "Upgrade the CSA to 4.6.0-512 or later and remove the management interface from internet exposure.",
+        "was_this_required": true,
+        "framework_requiring_it": "CISA BOD 22-01 (KEV remediation, added 2024-03-25)",
+        "adequacy": "Patching closes the injection, but appliances exposed for years may already be compromised, so the CSA should be assumed breached and rebuilt."
       },
       "detection": {
         "what_would_have_worked": "Monitor CSA web logs for unauthenticated POSTs to /client/index.php and for shell activity spawned under 'nobody'.",
@@ -50843,7 +51406,32 @@
         "adequate": false,
         "gap": "Boundary protection that exposes the CSA web interface to the internet leaves the unauthenticated injection endpoint directly reachable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The Ivanti EPM Cloud Services Appliance sits at the trust boundary and this CVE is the pre-auth case the tier exists for: the packet has an unauthenticated attacker sending a crafted request to the CSA web interface (/client/index.php) whose input reaches code-execution routines via csrf-magic.php, executing arbitrary code as the 'nobody' user as an initial foothold. Bound to this product the tier means every CSA in service is enumerated with its running version and driven to 4.6.0-512 or later on a clock that runs from the 2024-03-25 KEV listing, not on whatever cadence the estate applies to ordinary server applications — the packet's flaw-remediation gap is precisely that a 2021 flaw sat unpatched on appliances for years while exploitation surged around the KEV listing, and with public Metasploit and exploit-db modules and a near-1.0 EPSS the reachable-and-unpatched state is the operative risk rather than the CVSS band. The tier's alternative arm is isolation of the vulnerable interface: restrict which sources can reach the CSA web interface at all so the unauthenticated request cannot be delivered while the update is staged. Both arms carry preconditions that have to be stated with them. patch_required_reboot is true and the packet records no live-patching primitive for this product, so an appliance that has taken 4.6.0-512 but has not rebooted is still executing the vulnerable code and counts as exposed — the version in the asset inventory is not the version the appliance is running. And the isolation arm is bounded rather than absolute: it removes only the sources it excludes, so any host inside a permitted range still reaches the injection endpoint unauthenticated, and where the deployment requires the CSA web interface to answer from the internet the restriction is unavailable altogether and the vendor update with its reboot is the only closure. The distinguishing test: from a network with no operational need to manage endpoints through this appliance, issue an unauthenticated request to the CSA web interface on a staging instance and confirm it is refused before the request reaches the code-execution routines.",
+        "evidence": "Packet: affected is the \"Ivanti Endpoint Manager Cloud Services Appliance (EPM CSA) web interface, where improper handling of user-supplied input to code-execution routines lets an unauthenticated attacker run arbitrary code as the 'nobody' user\"; attack_vector: \"An unauthenticated attacker sends a crafted request to the CSA web interface (/client/index.php), which passes attacker input to code-execution routines via csrf-magic.php, running arbitrary code as the low-privileged 'nobody' user as an initial foothold.\" affected_versions: \"Ivanti EPM Cloud Services Appliance versions before 4.6.0-512\". CISA KEV 2024-03-25 with a Known ransomware association; active_exploitation confirmed; poc_available true with Metasploit/exploit-db modules and near-1.0 EPSS; CVSS 9.8; RWEP 79. 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.\" The NIST-800-53-SC-7 gap states \"Boundary protection that exposes the CSA web interface to the internet leaves the unauthenticated injection endpoint directly reachable\"; the NIST-800-53-SI-2 gap states the 2021 flaw saw exploitation surge around the 2024 KEV listing with \"appliances left unpatched for years.\"",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet describes the estate condition this control exists for: a 2021 unauthenticated code-injection flaw on internet-facing Ivanti EPM CSA appliances that were frequently unmanaged and left exploitable for years, with exploitation surging around the 2024-03-25 KEV listing, a Known ransomware association, and public exploit modules at near-1.0 EPSS. For an appliance in that state, installing 4.6.0-512 is not remediation — the update closes the injection path but removes nothing an attacker placed through it while the appliance was reachable, and the packet is explicit that the code execution is an initial foothold, the position from which the rest of the intrusion proceeds rather than its end state. The requirement here is that any CSA that was reachable and below 4.6.0-512 during the exposure window is dispositioned as a suspected compromise rather than as a patch ticket: capture the configuration and logs off the appliance first, rebuild it from vendor media at the fixed version instead of upgrading in place, and rotate every credential and secret the appliance held or that transited it. The precondition worth stating, because it is the specific way this decision goes wrong on this CVE: the injected code runs as the low-privileged 'nobody' user, which makes an attacker artifact easy to dismiss as ordinary application content but says nothing about where the intrusion went after the foothold — treating \"only nobody\" as justification for patching in place is exactly how the foothold survives the remediation and the appliance is recorded as closed. This control governs the appliance's disposition after exposure; it does not close the injection path, which is what the vendor update and its reboot do, and it is not a substitute for reaching 4.6.0-512 on every unit.",
+        "evidence": "Packet: the ISO-27001-2022-A.8.8 gap states \"legacy CSA appliances were frequently unmanaged and left exploitable\"; the AU-Essential-8-Patch gap states \"the Ivanti CSA edge appliance was frequently unmanaged and left exposed for years, and its ransomware-linked unauth injection surged well after the normal patch window closed\"; the NIS2-Art21-vulnerability-management gap states measures that do not prioritize internet-facing management appliances \"allow a critical preauth RCE to persist as an entry point.\" active_exploitation confirmed; CISA KEV 2024-03-25 with a Known ransomware association; poc_available true. attack_vector describes arbitrary code as the low-privileged 'nobody' user \"as an initial foothold\". patch_available true, patch_required_reboot true, live_patch_available false; affected_versions \"before 4.6.0-512\".",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-48788": {
     "name": "Fortinet FortiClient EMS SQL Injection Vulnerability (CVE-2023-48788)",
@@ -51299,7 +51887,30 @@
         "adequate": false,
         "gap": "Essential-Eight patching is scoped to mainstream OS/applications and does not compel firmware updates for niche network appliances, leaving a 3-year-old fix unapplied."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Sunhillo SureLine's fix already existed when CISA listed this flaw, so the KEV listing rather than patch availability is what starts the clock, and the SLA has to be attached to an asset class that ordinary flaw-remediation cadence never reaches. Bound to this product it means enumerating every SureLine unit in service with its running release, and driving each unit below 8.7.0.1.1 onto the fixed release inside the KEV window instead of into the next appliance maintenance cycle. Completion is measured on the release the unit is actually executing, not on the image that was staged onto it: the packet records no live-patch mechanism and a remediation that requires applying the fixed release and rebooting, so a unit that has taken the image but has not rebooted is still serving the vulnerable /cgi/networkDiag.cgi handler and counts as exposed. Precondition on this control's compensating-control branch, which is where it is most often over-claimed for an appliance like this: the only operator-side lever before the reboot lands is removing reachability of the SureLine web interface from untrusted networks, and that bounds who can send the request without repairing anything. The injection fires before authentication, so there is no credential, account policy or admin-hardening posture to fall back on, and any host inside a permitted segment still reaches the CGI with full effect. Restricted reachability is therefore a time-bounded holding measure recorded as such, not a state in which the SLA can be closed.",
+        "evidence": "The packet gives the vector as 'Sunhillo SureLine before 8.7.0.1.1 allows Unauthenticated OS Command Injection via shell metacharacters in ipAddr or dnsAddr /cgi/networkDiag.cgi', with the affected summary adding that it executes as root, and affected_versions as 'Sunhillo SureLine < 8.7.0.1.1'. cisa_kev is true with kev_date 2024-03-05, active_exploitation is 'confirmed', CVSS 9.8, RWEP 67, poc_available true, and the active-exploitation notes record 'Added to CISA KEV in March 2024 for in-the-wild exploitation; EPSS ~0.98.' patch_available is 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 cited SI-2 gap states the flaw 'was patched in 2021 yet remains actively exploited in 2024, showing that long-lived niche OT/network appliances routinely fall outside routine flaw-remediation cadences', and the A.8.8 gap that technical-vulnerability management 'routinely omits long-lived niche OT/telemetry appliances like SureLine'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For SureLine the packet names persistence as an outcome of exploitation, which is what makes the upgrade the wrong end point for the response. An unauthenticated request to /cgi/networkDiag.cgi runs attacker-supplied commands as root on the appliance, so anything written through that path — an added account or authorized key, a modified startup or CGI script, the botnet implant the packet names — was written with full privilege and survives the move to 8.7.0.1.1 and the reboot that carries it. The fix removes the injection path; it removes nothing that was already installed through it. Applied to this product, any SureLine unit that was reachable from an untrusted network while running below 8.7.0.1.1 during the confirmed-exploitation window is handled as config-exfil, rebuild and credential rotation: export the running configuration for review rather than reuse, reimage the unit from vendor media at the fixed release, and rotate every credential and key the appliance held or that transited it. Preconditions. The exported configuration is evidence, not a restore artifact — restoring it wholesale reinstates whatever the attacker changed, so it has to be diffed against a known-good baseline before any element of it is carried forward. And this control does not detect compromise; it decides the disposition of a unit whose exposure cannot be excluded, which means a unit with no reliable record of what could reach it during the window belongs on the rebuild path rather than the patch path. The window here is measured in years rather than days, because the packet places the fix in 2021 and confirmed exploitation through the 2024 listing.",
+        "evidence": "The packet's active-exploitation notes state that 'Unauthenticated attackers inject shell metacharacters to run commands as root, enabling DoS, botnet enrollment, or persistence on the network device', with active_exploitation 'confirmed', poc_available true, and KEV listing 2024-03-05. The affected summary places the injection in the ipAddr or dnsAddr parameter of /cgi/networkDiag.cgi 'executing as root'. patch_available is true with patch_required_reboot true and live_patch_available false. The cited SI-2 gap records that the flaw 'was patched in 2021 yet remains actively exploited in 2024', and the A.8.8 gap that vulnerability management omits appliances like SureLine so that 'an unauthenticated root OS-command-injection patched in 2021 remains unremediated and still actively exploited years later' — together describing a multi-year interval in which an exposed unit could have been rooted before any update reaches it. The internet reachability the response assumes is the packet's own SC-7 gap: boundary-protection guidance 'does not force these surveillance/telemetry appliances off the public internet, which is the only thing that stops unauthenticated reach to the vulnerable CGI'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-21338": {
     "name": "Microsoft Windows Kernel Exposed IOCTL with Insufficient Access Control Vulnerability",
@@ -52645,7 +53256,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management does not prioritise the emergency upgrade of a KEV-listed appliance whose management plane yields RCE from a low-privileged account."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "NetScaler ADC and NetScaler Gateway are the trust-boundary device class this tier exists for, and on this CVE the packet puts the trust boundary's own management plane in the exploit path: an attacker with access to NSIP, CLIP or SNIP and a low-privileged account performs code injection yielding remote code execution on the management interface. Applied to this product the tier means two things running together. First, the management addresses (NSIP, CLIP, SNIP) answer only from a dedicated management network, never from a user, server or internet-facing segment — the packet's own gap text names that exposure as 'the precondition the entire exploit depends on'. Second, the fixed release for each unit's own branch is deployed on the KEV clock rather than folded into an appliance maintenance window, and the branch matters because the fixed build differs per branch: 14.1-12.35 for 14.1, 13.1-51.15 for 13.1, 13.0-92.21 for 13.0, 13.1-37.176 for 13.1-FIPS and 12.65.7.24 for 12.1-FIPS/NDcPP. The clock has to run through the reboot: patch_available is true but patch_required_reboot is true with live_patch_available false, so a unit that has taken the fixed release and not rebooted is still executing the vulnerable code and is not a remediated item. This tier is also the answer to the least-privilege gap the packet records — because a merely low-privileged management account suffices for code execution, containment moves off privilege scoping and onto reachability, which is the isolation half of this control. Preconditions, and this is where the control is routinely over-claimed: management-network isolation bounds who can attempt the injection, it does not neutralize it — every administrator, monitoring integration and service account that legitimately reaches NSIP/CLIP/SNIP still holds exactly the low-privileged access the flaw needs, so isolation is containment for the pre-reboot window, not a substitute for the fixed build. And on the non-FIPS 12.1 branch isolation is permanent rather than interim, because the packet records that branch as end-of-life and unpatched: no fixed release exists to reach, so 12.1 is a migration item, not a patch item. Distinguishing test: from a general user or server VLAN on a staging deployment, attempt to open the NSIP/CLIP/SNIP management surface and confirm the connection is dropped before authentication is even offered — an estate that passes a NetScaler role-and-permission audit while the management addresses answer from any internal segment is still fully exposed to any low-privileged account that exists on it.",
+        "evidence": "Packet facts only. cisa_kev true with kev_date 2024-01-17 and active_exploitation 'confirmed'; active_exploitation_notes: 'Exploited in the wild as a zero-day disclosed 16 Jan 2024 alongside CVE-2023-6549; a low-privileged authenticated user with access to the NetScaler management interface (NSIP, CLIP, or SNIP) achieves remote code execution on the appliance. CISA KEV ransomware flag: unknown.' cvss 7.2 is not claimed here — the packet records cvss 8.8, rwep_score 59, poc_available false. The vector states the flaw 'allows an attacker with access to NSIP, CLIP or SNIP with management interface to perform Authenticated (low privileged) remote code execution on Management Interface.' Remediation state: 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.' Branch-specific fixed builds are taken from affected_versions (14.1-12.35, 13.1-51.15, 13.0-92.21, 13.1-37.176, 12.65.7.24) and the end-of-life status of 12.1 from the same list. The framework side is quoted from the packet's own gaps: NIS2-Art21-network-security ('do not explicitly require the NetScaler management interface (NSIP/CLIP/SNIP) to be off the public network'), UK-CAF-B2 ('do not force administrative interfaces onto an isolated management network'), AU-Essential-8-App-Hardening ('does not address restricting appliance management-interface exposure, so the code-injection sink stays reachable'), NIST-800-53-AC-6 ('A merely low-privileged management account is sufficient for code execution, so least-privilege on the management plane does not contain the flaw once any management access exists').",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B2",
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet's affected-version list carries two different terminal states for the same appliance family, and they have to be resolved per unit before this entry can be closed. 14.1, 13.1, 13.0, 13.1-FIPS and 12.1-FIPS/NDcPP each have a named fixed build; 'NetScaler ADC/Gateway 12.1' is listed as end-of-life and unpatched. So the requirement is an inventory naming every NetScaler ADC and NetScaler Gateway in service with its branch and its running build, and — because a FIPS/NDcPP unit whose version string starts '12.1' does have a fix (12.65.7.24) while a non-FIPS 12.1 unit does not — with its support status obtained per model and branch from the vendor rather than inferred from the version string. Units on a branch with a fixed build are remediation items on the clock that opened with the 2024-01-17 KEV listing; since the packet records no live-patch path and a reboot-required fix, a unit that has taken the release but not rebooted is still executing the vulnerable code and is not a closed item. Units on the end-of-life 12.1 branch cannot be patched at all — reaching a fixed build is not available to them — so they are replacement or migration items needing a dated schedule. A requirement that ends at 'every NetScaler reports a fixed build' marks the 12.1 estate compliant by omission, and a risk acceptance with no removal date leaves a KEV-listed appliance under confirmed active exploitation in service indefinitely, exposed not only to this code injection but to everything found in that branch since its last build. Scope the sweep to what the packet names — NetScaler ADC and NetScaler Gateway including the FIPS and NDcPP variants. The packet ties the CWE-94 sink to those products and gives no mapping into other vendors' load balancers or remote-access gateways, so treating every edge appliance in the estate as an instance of this CVE manufactures replacement work against products no evidence implicates. Distinguishing test: enumerate the estate's ADC and Gateway units and confirm each reports a build at or above its own branch's fixed level and has rebooted onto it, and that every non-FIPS 12.1 unit appears on a dated migration schedule with an owner — a technical-vulnerability register that records '12.1 assessed, no fix available' and stops there reads clean while the appliance stays permanently exploitable by any low-privileged management account.",
+        "evidence": "Packet facts only. affected_versions lists 'NetScaler ADC/Gateway 12.1 (end-of-life, unpatched)' alongside the fixed builds for the other branches: '14.1 before 14.1-12.35', '13.1 before 13.1-51.15', '13.0 before 13.0-92.21', '13.1-FIPS before 13.1-37.176', '12.1-FIPS/NDcPP before 12.65.7.24'. cisa_kev true, kev_date 2024-01-17, active_exploitation 'confirmed', rwep_score 59, cvss 8.8, 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.' The framework side is the packet's own ISO gap: 'Technical-vulnerability management does not prioritise the emergency upgrade of a KEV-listed appliance whose management plane yields RCE from a low-privileged account.' The CWE reference (CWE-94) and the products in scope (NetScaler ADC, NetScaler Gateway) are taken from cwe_refs and the affected/affected_versions fields; the packet names no other vendor's product.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2018-15133": {
     "name": "Laravel Deserialization of Untrusted Data Vulnerability",
@@ -53323,7 +53957,30 @@
         "adequate": false,
         "gap": "The 48-hour internet-facing patch target is frequently missed on legacy ColdFusion estates, leaving a preauth RCE exposed after public gadget chains dropped."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Bound to this product the control is a per-train obligation, not a single ticket. The packet names Adobe ColdFusion 2018, 2021 and 2023, each with its own affected level — 2018 Update 16 and earlier, 2021 Update 6 and earlier, 2023.0.0.330468 and earlier — so the population to enumerate is every ColdFusion instance in the estate across all three trains, including the ones behind an internal application rather than the flagship public site. An estate that updates its 2023 servers while a 2018 install stays on Update 16 still exposes an unauthenticated, network-reachable deserialization path, and the flaw-remediation attestation reads clean while it does. The clock runs from the 2024-01-08 KEV listing rather than from an internal severity review, because the packet already supplies everything a review would be waiting for: a public PoC, EPSS in the top percentile, exploitation in the wild since mid-2023, and CISA's ransomware flag. Completion is measured by the update level each running ColdFusion instance reports, not by the installer having been run or the change ticket being closed — the packet records no live-patch mechanism, so nothing mitigates the flaw until the fixed release is the code actually serving requests. Precondition: this reaches only instances the inventory can see, and ColdFusion is commonly installed alongside an application rather than through managed software distribution; an instance nobody has enumerated is not remediated by an SLA it was never counted against.",
+        "evidence": "The packet lists ColdFusion 2018 Update 16 and earlier, ColdFusion 2021 Update 6 and earlier, and ColdFusion 2023.0.0.330468 and earlier as affected, with CVSS 9.8, RWEP 72, poc_available true, active_exploitation confirmed, and the CISA KEV listing on 2024-01-08; exploitation has run against internet-facing Adobe ColdFusion servers since mid-2023 to drop web shells, EPSS is in the top percentile (~1.0), and KEV flags associated ransomware use. The NIST-800-53-SI-2 gap records a standard 30-day flaw-remediation SLA being far longer than the observed window between disclosure and mass web-shell deployment; the NIS2-Art21-patch-management gap records the KEV due date of 2024-01-29 being tighter than typical SLAs; the AU-Essential-8-Patch gap records the 48-hour internet-facing patch target being frequently missed on ColdFusion estates; the ISO-27001-2022-A.8.8 gap records technical-vulnerability management cataloguing the CVE without compelling the emergency patch cadence a top-EPSS, ransomware-linked preauth RCE demands. patch_available is true, live_patch_available is false, and the packet states remediation requires applying the vendor fixed release.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "A ColdFusion server in this entry is the estate's internet-facing edge: the packet describes deserialization of untrusted data in the CFML runtime reachable over the network without authentication, exploited in the wild against internet-facing servers since mid-2023 to drop web shells, with CISA flagging associated ransomware use. Applying the vendor fixed release closes the deserialization path and removes nothing that was written through it — a web shell dropped into the ColdFusion web root or a CFML directory before the update survives the update and keeps serving the attacker with no further need for the CVE. So any instance that was internet-reachable on 2018 Update 16, 2021 Update 6, or 2023.0.0.330468 or earlier during the exploitation window is an incident-response item rather than a patch item: capture and analyse its filesystem off-box with the web root and CFML directories first, rebuild from known-good rather than updating in place where compromise cannot be excluded, and rotate what the server held — datasource and database credentials, ColdFusion Administrator passwords, API keys, and any service account it authenticated as. This has to be the default posture rather than something a detection triggers, because the entry's own system-security gap records that the initial deserialization POST reaches a legitimate application endpoint and blends with normal ColdFusion traffic: the absence of an alert is not evidence the server was not reached. Precondition: this is scoped to instances that were network-reachable by an untrusted caller during the window; it is an incident path, not a substitute for the fixed release, which every instance still needs.",
+        "evidence": "The packet describes deserialization of untrusted data in the CFML runtime reachable over the network without authentication, yielding arbitrary code execution, and records exploitation in the wild against internet-facing Adobe ColdFusion servers since mid-2023 to drop web shells, with CISA KEV flagging associated ransomware use and the listing dated 2024-01-08. The attack vector states the payload drives deserialization into arbitrary code execution, typically dropping a web shell. The UK-CAF-B4 gap states that system-security/patch controls do not on their own detect the initial deserialization POST, which reaches a legitimate application endpoint and blends with normal ColdFusion traffic. patch_available is true, live_patch_available is false, and the packet states remediation requires applying the vendor fixed release.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-38203": {
     "name": "Adobe ColdFusion Deserialization of Untrusted Data Vulnerability",
@@ -53380,7 +54037,40 @@
         "adequate": false,
         "gap": "Network/patch controls do not detect a deserialization POST to a legitimate endpoint using a not-yet-blocked gadget class."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This is the second CVE on the same ColdFusion deserialization primitive: the packet describes it as a bypass of the fix for CVE-2023-29300, reached with a gadget class (JdbcRowSetImpl) Adobe's denylist did not block. For ColdFusion the control means the vulnerability-management programme does not score this as a fresh discrete item on the normal application queue but as evidence that the denylist protecting the CFML runtime's deserialization path is structurally incomplete — so a further gadget-class bypass on the same path is treated as likely rather than hypothetical, and the ColdFusion entry is not closed when one update lands. Scope the multiplier across all three trains the packet names — 2018 Update 17 and earlier, 2021 Update 7 and earlier, 2023 Update 1 and earlier — because each has its own fixed release and an estate that updates one train while another stays behind is still running the bypassable denylist. Precondition: this is a prioritisation and tracking control. It changes when the out-of-band update is scheduled and whether the finding stays open afterwards; it does not make the runtime reject the gadget and it blocks no request on its own.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker submits a serialized payload using a gadget class (JdbcRowSetImpl) that Adobe's deserialization denylist did not block, achieving RCE — a bypass of the fix for the related CVE-2023-29300.' NIS2-Art21-vulnerability-handling gap: 'Vulnerability-handling processes assume a single patch closes the issue; a denylist bypass requires re-remediation, which routine handling under-covers.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management does not compel the emergency re-patch that a fix-bypass zero-day demands within days.' cwe_refs CWE-502; cvss 9.8; rwep_score 72; active_exploitation confirmed; poc_available true. affected_versions: ColdFusion 2018 Update 17 and earlier, 2021 Update 7 and earlier, 2023 Update 1 and earlier.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-041",
+        "name": "PROTECTION-MECHANISM-FAILURE-CLASS-REGRESSION",
+        "description": "Adobe's deserialization denylist is the protection mechanism here, and this CVE is that mechanism failing: the packet places the arbitrary code execution in a gadget class the denylist did not cover, reachable unauthenticated over the network. Applied to ColdFusion, the control means each update is validated against the full historic gadget battery for the CFML deserialization path — every gadget class previously used against ColdFusion, not only the one named in the current advisory — on a staging install at the new update level before the estate is declared remediated; and, where the runtime permits constraining which classes may be reconstructed, that the policy is expressed as an allowlist rather than as one more blocked-class entry, which is what the packet's least-functionality gap says is actually required. The distinguishing test is that battery: replay each known gadget, JdbcRowSetImpl included, at the network-reachable endpoint on staging and confirm each is refused before any object is reconstructed. An estate that verified only the gadget its advisory named would have passed cleanly while this path stayed open. Precondition: the battery covers only gadget classes someone has already published, so it narrows the window for a repeat of this class rather than proving the next unpublished gadget is blocked, and it gives nothing at all to an install still below the fixed update level.",
+        "evidence": "Packet affected: 'Adobe ColdFusion (2018, 2021, 2023) — a deserialization gadget (JdbcRowSetImpl) not covered by the denylist, reachable unauthenticated over the network for arbitrary code execution.' NIST-800-53-CM-7 gap: 'Least-functionality/deny-by-default at the object layer is exactly what Adobe's denylist attempted and failed — an allowlist-based deserialization policy, not a blocklist, is required, which this control does not by itself mandate.' attack_vector records the flaw as a bypass of the fix for CVE-2023-29300; poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-CM-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records a KEV listing on 2024-01-08 with confirmed exploitation, a public PoC and a ransomware association, against an Adobe fix issued out of band after the flaw was disclosed inadvertently. For ColdFusion that means the fixed release is driven onto every install on the KEV clock rather than folded into the next application-patching window, with completion measured on the update level the running ColdFusion instance reports — separately for each of the three trains the packet names, since a current 2023 install says nothing about a 2018 or 2021 install elsewhere on the same estate. The packet records live_patch_available false and states that remediation requires applying the vendor fixed release, so there is no mitigation rule to deploy while the update is being scheduled; the only lever between listing and fixed release is reducing who can reach the endpoint. And because exploitation is confirmed, an install that ran a pre-fix update level while network-reachable belongs on the incident path rather than being closed on the patch record — the flaw reaches arbitrary code execution, so the update repairs the code path and says nothing about what executed before it.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-01-08, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 72. active_exploitation_notes: 'A denylist-bypass zero-day in ColdFusion's deserialization, disclosed inadvertently and fixed by Adobe out-of-band; exploited in the wild alongside the other 2023 ColdFusion flaws, with ransomware association per CISA KEV.' patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' NIST-800-53-SI-2 gap: 'The out-of-band Adobe fix for this denylist bypass landed days after disclosure; a routine flaw-remediation SLA cannot keep pace with a chained, actively-exploited preauth RCE.' AU-Essential-8-Patch gap records the same for internet-facing ColdFusion.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-7101": {
     "name": "Spreadsheet::ParseExcel Remote Code Execution Vulnerability",
@@ -53597,7 +54287,29 @@
         "adequate": false,
         "gap": "Patch targets assume managed IT assets; unmanaged FXC edge routers fall outside the patch program entirely."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Bound to the FXC AE1021 and AE1021PE wall routers, the clock that opened with the 2023-12-21 KEV listing runs against every unit in service, and completion is measured on the firmware version the device itself reports rather than on a distribution job — these routers sit outside the console that reports build state for managed endpoints, which is precisely why the flaw-remediation gap on this entry exists. The packet gives the affected level as firmware 2.0.9 and earlier and does not name the fixed release, so the fixed version has to be obtained from FXC for the exact model before any unit can be called remediated; 'newer than 2.0.9' asserted from the CVE text is not a fixed-build figure. Because the packet records no live-patch path and a reboot requirement, a unit that has taken firmware but has not rebooted onto it is still executing the vulnerable image and counts as exposed. Where a unit cannot be reached inside the window, this control's compensating-control branch is what has to be documented, and its precondition must be written down with it: restricting who can reach the router's management plane bounds the population that can present a login, but the flaw is reached by an authenticated request, so any holder of a valid credential still reaches the injection point — and a wall router exists to serve the client network attached to it, 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. Distinguishing test: produce, per unit, the running firmware version and the time of the reboot that put it there; an asset list that names the model without a running-version figure has recorded the fleet, not its exposure.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-12-21, active_exploitation confirmed — 'Exploited as a zero-day by the Mirai-variant InfectedSlurs botnet (reported by Akamai SIRT) to conscript FXC AE1021/AE1021PE wall routers into a DDoS swarm; authenticated command injection over the network.' patch_available true, live_patch_available false, patch_required_reboot true, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' affected_versions: 'FXC AE1021PE firmware 2.0.9 and earlier', 'FXC AE1021 firmware 2.0.9 and earlier' (no fixed release named). vector: 'An OS command injection vulnerability exists in AE1021PE firmware version 2.0.9 and earlier and AE1021 firmware version 2.0.9 and earlier... an arbitrary OS command may be executed by an attacker who can log in to the product.' Cited gaps: NIST-800-53-SI-2 'SOHO/edge routers like the AE1021 rarely receive centrally managed patches, so a firmware fix does not reach the exposed fleet within the KEV window'; AU-Essential-8-Patch 'Patch targets assume managed IT assets; unmanaged FXC edge routers fall outside the patch program entirely'; ISO-27001-2022-A.8.8 'Technical-vulnerability-management inventories rarely include SOHO edge CPE like the AE1021, so its authenticated command-injection firmware flaw is never assessed or scheduled.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The AE1021/AE1021PE is the edge device for the site it serves, and the packet records the exploitation outcome as attacker code placed on it: the InfectedSlurs botnet conscripted these routers into a DDoS swarm, and the attack path ends in arbitrary OS commands and, typically, a Mirai-variant bot installed on the device. So a unit believed to have been exploited belongs on the rebuild path rather than the update path — firmware applied and the configuration restored from a known-good baseline rather than inherited through the flash, the administrative credential rotated rather than carried across, and any credential that transited the router treated as exposed. Note honestly where this entry differs from the usual case for this control: exploitation is not pre-authentication here, the packet requires an attacker who can log in to the product, and that makes the credential half load-bearing rather than incidental — the update replaces the vulnerable image but says nothing about the login the attacker used, so a unit returned to service on fixed firmware with the same administrative password is reachable by the same route as soon as the next defect lands. Preconditions, both of which bound this control rather than being satisfied by it: it is a response measure that presumes the unit has been identified as exploited, and the packet's own CAF gap records that conscription of consumer-grade routers surfaces only once the device emits DDoS traffic, so for most estates the trigger will be outbound-traffic evidence rather than anything the router reports; and it does not prevent the initial command injection, which only the fixed firmware and its reboot remove.",
+        "evidence": "Packet: active_exploitation confirmed; active_exploitation_notes 'Exploited as a zero-day by the Mirai-variant InfectedSlurs botnet (reported by Akamai SIRT) to conscript FXC AE1021/AE1021PE wall routers into a DDoS swarm.' attack_vector: 'An attacker who can authenticate to the router (often via default/weak credentials) submits a crafted value to a management parameter that is passed to an OS shell without sanitization, executing arbitrary commands and typically installing a Mirai-variant bot.' affected: 'FXC AE1021 and AE1021PE wall routers — OS command injection reachable by an authenticated user over the network, allowing arbitrary command execution on the device.' patch_available true with patch_required_reboot true and live_patch_available false. Cited gaps: NIST-800-53-SI-2 'a firmware fix does not reach the exposed fleet within the KEV window'; UK-CAF-B4 'Proactive security-event discovery does not extend to consumer-grade routers, so botnet conscription goes unnoticed until the device emits DDoS traffic'; NIST-800-63B-rev4 'weak/default/reused router credentials directly enable the injection.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-47565": {
     "name": "QNAP VioStor NVR OS Command Injection Vulnerability",
@@ -53654,7 +54366,31 @@
         "adequate": false,
         "gap": "Security-event discovery does not extend to standalone NVRs, so botnet conscription surfaces only as outbound DDoS abuse."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This packet states both halves the control needs. A fix exists — QNAP records the flaw as fixed in QVR Firmware 5.0.0 and later — while the affected population is legacy VioStor NVR models running QVR Firmware 4.x, which the entry's own gaps describe as end-of-life appliances that no longer receive routine updates and whose remediation is a migration or replacement effort rather than a patch cycle. That combination defines the requirement: reaching QVR 5.0.0 is an interim state where the model can get there, and removal or replacement is the terminal state where it cannot. The question the packet does not answer, and which must be resolved per unit before anything else, is which VioStor models can actually run QVR 5.0.0; that status has to be obtained from QNAP for the exact model, not assumed in either direction — assume it can and you strand units on a firmware line receiving no fixes, assume it cannot and you fund replacements that were not needed. Units whose model has a 5.0.0-or-later path are remediation items on the clock that opened with the 2023-12-21 KEV listing, and because the packet records no live-patch mechanism and a reboot requirement, a unit that has taken firmware but not rebooted onto it is still executing the vulnerable image and counts as exposed. Units with no path to 5.0.0 cannot be patched at all and need a dated replacement schedule: a risk acceptance with no removal date leaves a KEV-listed, actively-exploited command-injection flaw in service indefinitely, and a unit stuck on 4.x is exposed not only to this CVE but to everything found in that firmware line since it stopped receiving updates. Scope this to what the packet names — QNAP VioStor NVR models on QVR 4.x — rather than to every camera or recorder in the estate; the packet ties the command-injection sink to VioStor on QVR 4.x and maps it into no other product.",
+        "evidence": "Packet: vector 'An OS command injection vulnerability has been found to affect legacy QNAP VioStor NVR models running QVR Firmware 4.x. If exploited, the vulnerability could allow authenticated users to execute commands via a network. We have already fixed the vulnerability in the following versions: QVR Firmware 5.0.0 and later.' affected_versions: 'QNAP VioStor NVR on QVR Firmware 4.x (all 4.x prior to 5.0.0).' 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.' cisa_kev true, kev_date 2023-12-21, active_exploitation confirmed ('Exploited as a zero-day by the InfectedSlurs Mirai-variant botnet (Akamai SIRT) against legacy QNAP VioStor NVR devices on QVR firmware 4.x'). Cited gaps: NIST-800-53-SI-2 'The fix requires migrating off end-of-life QVR 4.x to QVR 5.0.0+, which is a device-replacement/upgrade effort a flaw-remediation SLA cannot satisfy within the KEV window'; ISO-27001-2022-A.8.8 'Vulnerability management tends to overlook end-of-life video-surveillance appliances that no longer receive routine updates'; AU-Essential-8-Patch 'does not compel migrating end-of-life QVR 4.x NVRs to 5.0.0+, so the InfectedSlurs-conscripted command-injection stays open on unsupported surveillance appliances.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Applied to the VioStor NVR estate, the 2023-12-21 KEV listing starts a clock that this packet allows only two ways to stop, because the middle option is unavailable: live_patch_available is false, so per unit the record must be either a running QVR version at 5.0.0 or later with the reboot the fix requires already taken, or a written compensating-control entry for a unit that cannot get there. That per-unit record is what produces the inventory of reachable NVRs the network-security gap says nobody maintains — the appliance is not going to appear in an endpoint-patch console on its own. The compensating control available on this device is bounding who can reach its web management plane, and its precondition has to be documented alongside it rather than left implied: exploitation is by an authenticated user over the network, so restricting reachability shrinks the population that can present a login but does nothing about anyone already holding a valid NVR credential inside the permitted segment, and the measure is simply unavailable where the recorder is deliberately published for remote viewing — a configuration the entry's own gap describes as routine for internet-exposed NVRs. It is a holding measure for the window before QVR 5.0.0 and its reboot land, or before the unit is replaced, and it is not a closure. Distinguishing test: from a segment with no operational need to administer video, attempt to load the VioStor management interface; anything that answers is inside the network-reachable population this flaw is exploited through.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-12-21, active_exploitation confirmed, rwep_score 48, cvss 8.8, poc_available false. affected: 'QNAP VioStor NVR (legacy models) running QVR Firmware 4.x — OS command injection reachable by an authenticated user over the network; fixed by upgrading to QVR Firmware 5.0.0 and later.' attack_vector: 'An attacker authenticated to a VioStor NVR submits a crafted value to a web-interface field that reaches an OS shell unsanitized, executing arbitrary commands and typically installing a Mirai-variant bot for DDoS.' live_patch_available false; patch_required_reboot true. Cited gaps: NIS2-Art21-network-security 'Network-security baselines rarely inventory internet-exposed NVRs, leaving their reachable management plane open to command injection'; NIST-800-53-SI-2 (replacement/upgrade effort no SLA can satisfy within the KEV window); AU-Essential-8-Patch (scoped to mainstream OS/applications, does not compel the QVR 4.x migration).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2023-6448": {
     "name": "Unitronics Vision PLC and HMI Insecure Default Password Vulnerability",
@@ -53780,7 +54516,30 @@
         "adequate": false,
         "gap": "Security monitoring often lacks visibility into anonymous-session creation inside the BI application, so the initial-access step goes undetected."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a KEV-keyed clock and a severity-keyed clock give opposite answers, and the control exists to make the KEV clock the one that binds. On its own the flaw scores 6.5 and only produces an anonymous session plus requests to unauthorized backend endpoints; chained with CVE-2023-41265 it is unauthenticated RCE and was used as initial access by Cactus ransomware against internet-facing Qlik Sense Enterprise for Windows. Applied here the remediation clock runs from the 2023-12-07 KEV listing rather than from the medium band, and the fix is tracked per release train because Qlik shipped it separately on each: August 2023 IR, May 2023 Patch 4, February 2023 Patch 8, November 2022 Patch 11, and August 2022 Patch 13. An estate running more than one train has to reach the fixed patch for each — the flaw-remediation gap on this entry is exactly that a single SLA could not cover an estate on mixed patch levels before weaponization, so a programme that records 'Qlik Sense patched' against one train has not remediated the others. Completion is measured by the version the running Qlik Sense service reports, not by the patch bundle being downloaded or staged; the packet records no live-patch mechanism, so the fixed release actually serving requests is the only state that counts. Precondition: this governs prioritisation and completion measurement, not reachability — it gives nothing to an instance during the interval before its train's fixed patch is installed.",
+        "evidence": "The packet gives CVSS 6.5 with RWEP 68, poc_available true, active_exploitation confirmed, and the CISA KEV listing on 2023-12-07 with ransomware use flagged; the vector states the traversal allows an unauthenticated remote attacker to generate an anonymous session and transmit HTTP requests to unauthorized endpoints, and the exploitation notes record the chain with CVE-2023-41265 for unauthenticated RCE used as initial access by Cactus ransomware against internet-facing Qlik Sense Enterprise for Windows, observed by Arctic Wolf. The vector names the affected trains as May 2023 Patch 3 and earlier, February 2023 Patch 7 and earlier, November 2022 Patch 10 and earlier, and August 2022 Patch 12 and earlier, and the fixes as August 2023 IR, May 2023 Patch 4, February 2023 Patch 8, November 2022 Patch 11, and August 2022 Patch 13. The NIST-800-53-SI-2 gap records the fix shipping as scattered per-release patches across many Qlik Sense trains with a single flaw-remediation SLA struggling to cover an estate on mixed patch levels before ransomware weaponization; the ISO-27001-2022-A.8.8, NIS2-Art21-vulnerability-management and AU-Essential-8-Patch gaps each record severity-driven prioritisation deprioritising a CVSS-6.5 primitive that becomes critical only when chained. patch_available is true, live_patch_available is false, and the packet states remediation requires applying the vendor fixed release.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "The requirement this control carries — forward the application's per-request access logs to an external SIEM, because authentication-event logging alone misses an attack that never produces an authentication event — is the exact shape of this Qlik Sense flaw. The traversal makes the server issue an anonymous session to an unauthenticated caller, which then transmits HTTP requests to unauthorized backend endpoints; nobody logs in, so an authentication-log-only pipeline has nothing to show, which is what the security-monitoring gap on this entry records. Applied to Qlik Sense Enterprise for Windows it means the proxy and audit logs covering session creation and per-request backend access are shipped off the Qlik host to a SIEM the Qlik service account cannot write to, retained long enough to cover the exposure window, with the rule keyed on the behaviour the packet documents rather than on a stand-in: a session appearing with no preceding authentication event, and requests from that session reaching backend endpoints an unauthenticated caller has no route to. Preconditions: this detects and reconstructs, it does not prevent — the traversal stays reachable until the fixed patch for that instance's train is the version the service reports — and it produces nothing unless the logs were already being shipped during the window, which on a BI server is commonly not the case; a rule written afterwards against telemetry nobody collected returns an empty result that reads like a clean one. Because the packet places this CVE as the first stage of a chain used for ransomware initial access, a hit here is an incident to be worked, not a vulnerability finding to be queued.",
+        "evidence": "The vector states that the path traversal allows an unauthenticated remote attacker to generate an anonymous session, which allows them to transmit HTTP requests to unauthorized endpoints. The UK-CAF-C1 gap states that security monitoring often lacks visibility into anonymous-session creation inside the BI application, so the initial-access step goes undetected. The packet describes this as the first stage of the ZeroQlik chain, chained with CVE-2023-41265 for unauthenticated RCE and used as initial access by Cactus ransomware against internet-facing Qlik Sense Enterprise for Windows, with active_exploitation confirmed and the CISA KEV listing on 2023-12-07 flagging ransomware use. live_patch_available is false and the packet states remediation requires applying the vendor fixed release.",
+        "gap_closes": [
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2023-41265": {
     "name": "Qlik Sense HTTP Tunneling Vulnerability",
@@ -54089,7 +54848,31 @@
         "adequate": false,
         "gap": "Technical vulnerability management assumes a remediation path exists, yet it is OEM-gated for chipset drivers."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "For this Qualcomm flaw the packet is explicit that remediation arrives only one way: the OEM firmware or OS update carrying Qualcomm's fix, followed by a device reboot, with no live-patch mechanism for the DSP driver. That makes the device's OEM build the only enforceable value, and this control's requirement is that it be treated as an access condition rather than a compliance statistic — organizational mail, VPN and document access withheld from any handset whose build does not carry the fix from Qualcomm's December 2023 security bulletin. The bulletin identifies the affected chipsets; whether a given handset model has received an OEM build carrying that fix has to be obtained from the OEM per model, not inferred in either direction. This matters most on the BYOD population the packet's system-security gap names, where the operator holds no patch lever at all and access gating is the only lever left. Distinguishing test: enrol a device on a pre-fix build and confirm it is actually denied protected resources rather than merely flagged as non-compliant. Preconditions: the primitive is reached by an unprivileged local process issuing a remote call from HLOS to the DSP, so any code already executing on the device satisfies the access requirement in full — gating organizational data does not evict an implant already resident, and the packet ties this CVE to limited, targeted exploitation named by Google Threat Analysis Group and Project Zero in a targeted-spyware pattern, so a device suspected of having run the chain belongs on the incident path rather than the patch path. And because no live-patch path exists, a device that has taken the OEM update but not rebooted is still executing the vulnerable DSP driver and is not remediated.",
+        "evidence": "Packet fields: affected states 'Multiple Qualcomm chipsets: use-after-free (memory corruption) in DSP Services triggered during a remote call from HLOS to the DSP, enabling local privilege escalation'; affected_versions gives 'Multiple Qualcomm chipsets with the affected Compute DSP (cDSP) driver — see Qualcomm December 2023 security bulletin'; vector gives 'Memory corruption in DSP Services during a remote call from HLOS to DSP'; attack_vector describes an unprivileged local process issuing a remote call from HLOS to the DSP via FastRPC. cisa_kev true with kev_date 2023-12-05, active_exploitation confirmed; active_exploitation_notes records Google Threat Analysis Group and Google Project Zero naming it under limited, targeted exploitation alongside the Adreno GPU flaws, Qualcomm confirming and issuing OEM guidance, and a targeted-spyware pattern with no ransomware association. patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes 'No live-patch mechanism for the DSP driver; remediation requires the OEM firmware/OS update carrying Qualcomm's fix and a device reboot.' The UK-CAF-B4 gap states a DSP kernel-driver use-after-free on BYOD mobile sits outside the org's patch reach; the ISO-27001-2022-A.8.8 gap states technical vulnerability management assumes a remediation path exists, yet it is OEM-gated for chipset drivers.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV clock on this entry opened 2023-12-05, but the clock an operator can actually run starts later and separately per device model: the packet records remediation as arriving only through the OEM firmware or OS update carrying Qualcomm's fix plus a reboot, so 'patch availability' for this control is the date that build is published for a given model, not the date of Qualcomm's December 2023 bulletin. Applied here, the requirement is to track both dates per model — when an OEM build carrying the fix became available, and when the fleet's devices of that model reached it after reboot — and, where the first has not happened, to record the documented compensating control (withholding organizational data from the device, and incident triage for any device suspected of having run the chain) with a stated review date rather than leaving the item open as awaiting vendor. That open-ended state is the specific shape of paper compliance this flaw produces: the flaw-remediation control is annotated vendor-dependent, the KEV entry stays unclosed, and nothing else happens for a use-after-free under confirmed targeted exploitation. No management-console report should be accepted as evidence of remediation here, because the packet states enterprise MDM cannot remediate the DSP driver directly; the evidence is the device's own build carrying Qualcomm's fix after a reboot. Precondition: this control sets and documents the clock, it does not create a build that does not exist — where the OEM has published nothing for a model, the compensating control is all that is operating, and it bounds exposure of organizational data without repairing the driver on the device.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2023-12-05 and active_exploitation confirmed; poc_available false; rwep_score 57 against cvss 7.8; cwe_refs CWE-416. patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes 'No live-patch mechanism for the DSP driver; remediation requires the OEM firmware/OS update carrying Qualcomm's fix and a device reboot.' affected_versions points to the Qualcomm December 2023 security bulletin for the affected cDSP chipsets. The NIST-800-53-SI-2 gap states flaw remediation presumes a patch the org can deploy while the DSP-driver fix must arrive via OEM firmware, so real-world remediation trails the active-exploitation window by months; the NIS2-Art21-patch-management gap states patch-management duties cannot force OEMs/carriers to ship the chipset DSP fix and that enterprise MDM cannot remediate a DSP kernel driver directly; the AU-Essential-8-Patch gap states the exploited-flaw patch SLA is not meetable when the fix is bound to an OEM firmware image. active_exploitation_notes records Google Threat Analysis Group and Project Zero naming it under limited, targeted exploitation with Qualcomm issuing OEM guidance.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2022-22071": {
     "name": "Qualcomm Multiple Chipsets Use-After-Free Vulnerability (process shell memory)",
@@ -54840,7 +55623,32 @@
         "adequate": false,
         "gap": "The Essential Eight 'patch applications within 48 hours for exploited flaws' target is only met if the org tracks Oracle CPUs as security-critical; the control is silent on disabling/segmenting the IIOP subprotocol as a compensating measure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "WebLogic's IIOP listener is exactly the binary remoting-protocol class this control governs: the packet has an unauthenticated attacker with network access via IIOP sending a crafted request carrying a Java deserialization gadget chain to the WebLogic listen port and taking over the server, so the protocol parser answering before any authentication is itself the vulnerable code — a path the HTTP-tier hardening and web-application filtering that most WebLogic estates are audited against never inspects. For this product the requirement is that the IIOP subprotocol is disabled on every WLS Core Components listener with no application that requires it, and that where it must stay enabled the listen port answers only to the specific hosts that legitimately speak IIOP to that server, enforced by network ACL or host firewall rather than inferred from \"the domain is internal\" — which the packet's own boundary-protection gap names as the failure, since a T3/IIOP listener (7001) reachable from the internet or a flat internal network is the precondition for the credential-free takeover. The distinguishing test for this deployment: from a general user or application VLAN on a staging domain, open an IIOP connection to the WebLogic listen port and confirm it is refused before the request reaches the parser — a domain that passes a WebLogic role-and-policy audit while the IIOP port answers from any internal segment is still fully exposed, because the attacker never authenticates and no account model is consulted. Precondition: this bounds who can deliver the gadget chain, it does not repair the deserialization defect. Any host inside the permitted set — or any workload compromised on one — satisfies the packet's stated requirement of network access via IIOP in full, so this is a holding measure to be run alongside the vendor fixed release for 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0 and 12.2.1.4.0, never recorded in place of it.",
+        "evidence": "Packet vector: \"Easily exploitable vulnerability allows unauthenticated attacker with network access via IIOP to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in takeover of Oracle WebLogic Server.\" affected: \"Oracle WebLogic Server (WLS Core Components) with the IIOP protocol enabled on the listen port; unauthenticated network attacker via IIOP.\" attack_vector: \"An unauthenticated attacker sends a crafted IIOP request to the WebLogic listen port carrying a Java deserialization gadget chain, achieving remote code execution and full server takeover without credentials.\" affected_versions: 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0. The NIST-800-53-SC-7 gap states \"Boundary protection that permits the T3/IIOP listener (7001) to reach the internet or flat internal networks is the precondition for unauthenticated RCE; simply patching does not close the exposed management protocol\"; the UK-CAF-B4 gap states system-security expectations \"don't require disabling the IIOP subprotocol or segmenting the 7001 listener\"; the NIS2-Art21-vulnerability-management gap states the article \"does not force IIOP-protocol hardening or listener segmentation\"; the AU-Essential-8-Patch gap states the control \"is silent on disabling/segmenting the IIOP subprotocol as a compensating measure.\" poc_available true; EPSS 0.93 (99.8th pct); CISA KEV 2023-11-16.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the cadence mismatch the SLA exists to remove. The packet records the WLS Core Components flaw as mass-scanned and weaponized since the January 2020 Oracle CPU with a public exploit and EPSS 0.93 (99.8th percentile), CISA listed it on 2023-11-16, and the estate-side clock the packet's gaps describe is a quarterly Oracle CPU cycle — years of reachable exposure against an unauthenticated takeover. Applied to this product it means a WebLogic domain on 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0 or 12.2.1.4.0 is either on the vendor fixed release or carrying a documented compensating control with a stated review date, from the KEV listing onward, handled as an out-of-cycle emergency change rather than folded into the next quarterly patch window. The compensating-control arm the packet supports is the IIOP one: the subprotocol disabled where no application needs it, or its listener restricted to hosts that legitimately speak IIOP to that server. That arm has to be recorded with its precondition attached — it bounds who can deliver the gadget chain but leaves it fully deliverable from any permitted host — so it is logged as an active mitigation with a review date, never as the item closed. Completion on the patch arm is measured on the version the running WebLogic process reports rather than on what the patch inventory says was applied: patch_required_reboot is false, which means the host needs no reboot, but the packet records no live-patch mechanism and states that remediation requires applying the vendor fixed release, so a managed server still executing the pre-fix build is not remediated and each instance in the domain has to be shown on the fixed version itself.",
+        "evidence": "Packet: CISA KEV 2023-11-16, active_exploitation confirmed, CVSS 9.8, RWEP 72, poc_available true. active_exploitation_notes: \"the IIOP-facing WLS Core Components flaw has been mass-scanned and weaponized since the Jan-2020 Oracle CPU, remaining a durable initial-access vector against internet-exposed WebLogic. EPSS 0.93 (99.8th pct).\" 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 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0. The NIST-800-53-SI-2 gap states \"Flaw remediation on a quarterly Oracle CPU cadence leaves the IIOP listener exploitable for months\"; the ISO-27001-2022-A.8.8 gap states the flaw \"demands emergency out-of-band remediation, not the standard cycle\"; the AU-Essential-8-Patch gap states the 48-hour exploited-flaw target \"is only met if the org tracks Oracle CPUs as security-critical\" and that the control \"is silent on disabling/segmenting the IIOP subprotocol as a compensating measure.\"",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-36033": {
     "name": "Windows DWM Core Library Elevation of Privilege",
@@ -55130,19 +55938,43 @@
         "adequate": false,
         "gap": "Technical-vulnerability management treats this as a scheduled patch, missing that it is a preauth, ransomware-actor-exploited RCE demanding out-of-band emergency remediation and web-shell hunting."
       }
-    }
-  },
-  "CVE-2023-36844": {
-    "name": "Juniper Junos OS EX Series J-Web PHP External Variable Modification",
-    "lesson_date": "2026-07-21",
-    "attack_vector": {
-      "description": "An unauthenticated attacker sends crafted J-Web requests that modify PHP environment variables, causing partial integrity loss that is chained with other J-Web flaws toward pre-auth remote code execution.",
-      "privileges_required": "none (unauthenticated network access to J-Web)",
-      "complexity": "low — public watchTowr PoC / EDB-51776 automates the chain",
-      "ai_factor": "Not AI-discovered — disclosed by Juniper SIRT and weaponized by watchTowr Labs. No AI involvement documented."
     },
-    "defense_chain": {
-      "prevention": {
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "SysAid On-Premise is the case this control is written for: an unauthenticated path traversal writes a file into the Tomcat webroot for code execution, and the packet records the observed exploitation writing a WAR-packaged web shell there and running a PowerShell loader for GraceWire and Cl0p tooling. Upgrading to 23.3.36 removes the traversal write primitive and removes nothing already written through it — the WAR in the webroot and anything the loader staged survive the upgrade intact, which is why a self-hosted instance that was reachable and below 23.3.36 during the exploitation window is a compromise, not a patch item. The requirement: preserve and export the server configuration and the full contents of the Tomcat webroot for analysis, rebuild the host from a known-good baseline onto 23.3.36 rather than upgrading the running instance in place, and rotate the credentials stored on that server and those that authenticated through it during the window. Precondition, and it decides which instances are in scope: this is the post-exposure path and does not apply to an instance that reached 23.3.36 before ever being exposed. But the detection gap on this entry records that default configurations do not alarm on new files appearing in the Tomcat webroot or on java spawning PowerShell — the exact deploy behaviour seen here — so most operators have no telemetry that can demonstrate non-exposure. Absent that evidence, an internet-reachable instance that ran below 23.3.36 across the November 2023 window belongs on the rebuild path; a clean scan of a running instance is not the same as proof that nothing was written to it.",
+        "evidence": "Packet: SysAid On-Premise before 23.3.36, unauthenticated path traversal leading to code execution after writing a file to the Tomcat webroot, as exploited in the wild in November 2023. attack_vector: an unauthenticated attacker uses a path-traversal request to write a WAR-packaged web shell into the SysAid Tomcat webroot, then executes it to run a PowerShell loader for GraceWire and Cl0p ransomware tooling. active_exploitation_notes: exploited by Lace Tempest, a Cl0p ransomware affiliate; CISA KEV flags ransomware use as known; EPSS 0.99 (99.9th pct). CISA KEV 2023-11-13; poc_available true; patch_available true; live_patch_available false with live_patch_notes recording no vendor live-patch mechanism and remediation requiring the vendor fixed release. NIST-800-53-SI-4 gap: default configs do not alarm on new files appearing in the Tomcat webroot or on java spawning PowerShell. ISO-27001-2022-A.8.8 gap: treated as a scheduled patch, missing that it is a preauth, ransomware-actor-exploited RCE demanding out-of-band emergency remediation and web-shell hunting. NIS2-Art21-incident-handling gap: the article does not require the webroot-integrity monitoring or egress control that would catch the web shell before ransomware deployment.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet records this flaw as exploited in the wild in November 2023 by a Cl0p affiliate before 23.3.36 existed, and the pre-fix window is not something any patch SLA can close — which is precisely what the flaw-remediation and Essential-Eight gaps on this entry record. Note which trigger the control's 'whichever is later' clause actually selects here, because the two dates fall in the order operators tend to assume is reversed: the vendor notification carrying 23.3.36 is recorded with a published date of 2023-11-08 and the KEV listing is 2023-11-13, so the fix predates the listing and the later trigger is the KEV date. Exploitation preceding the fix says nothing about that ordering — it orders the attack against the patch, not the patch against the listing. What the control does bind is the window after the fixed release landed: an internet-reachable SysAid On-Premise instance is a four-hour item from that point, not a scheduled-maintenance item, and the vulnerability-management gap names the failure mode exactly — treating it as a scheduled patch. Remediation is the vendor fixed release 23.3.36 itself; the packet records no live-patch mechanism, so there is no interim binary path, and completion is measured on the version the running instance reports rather than on a change ticket. The control's compensating-control branch is the only thing available to an instance that cannot take 23.3.36 inside the window: remove the SysAid web interface's reachability from the internet, since the packet's boundary-protection gap names that exposure as the precondition for the pre-auth file write. State its limits plainly — isolation bounds who can send the traversal request, it does not repair the traversal, it is unavailable where the service must stay reachable for remote users, and it evicts nothing from an instance that was already exploited, which is why an instance exposed during the November 2023 window goes down the compromise path regardless of when it reaches 23.3.36.",
+        "evidence": "Packet: CISA KEV 2023-11-13; active_exploitation confirmed with exploitation in the wild in November 2023; poc_available true; patch_available true with the fixed release 23.3.36; patch_required_reboot false; live_patch_available false and live_patch_notes stating no vendor live-patch mechanism and that remediation requires applying the vendor fixed release; CVSS 9.8, RWEP 69. NIST-800-53-SI-2 gap: emergency patching to 23.3.36 is required, but the flaw was already exploited as a zero-day by a ransomware affiliate, so SI-2 cadence does not cover the active-exploitation window before the fix landed. AU-Essential-8-Patch gap: the 48-hour internet-facing patch target could not act on a flaw exploited as a zero-day before 23.3.36 existed. ISO-27001-2022-A.8.8 gap: technical-vulnerability management treats this as a scheduled patch. NIST-800-53-SC-7 gap: boundary protection exposing the SysAid web interface to the internet is the precondition for the preauth file write, and patching does not remove the exposed attack surface.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
+  },
+  "CVE-2023-36844": {
+    "name": "Juniper Junos OS EX Series J-Web PHP External Variable Modification",
+    "lesson_date": "2026-07-21",
+    "attack_vector": {
+      "description": "An unauthenticated attacker sends crafted J-Web requests that modify PHP environment variables, causing partial integrity loss that is chained with other J-Web flaws toward pre-auth remote code execution.",
+      "privileges_required": "none (unauthenticated network access to J-Web)",
+      "complexity": "low — public watchTowr PoC / EDB-51776 automates the chain",
+      "ai_factor": "Not AI-discovered — disclosed by Juniper SIRT and weaponized by watchTowr Labs. No AI involvement documented."
+    },
+    "defense_chain": {
+      "prevention": {
         "what_would_have_worked": "Apply the Junos fixed releases and disable or restrict J-Web to trusted management networks.",
         "was_this_required": true,
         "framework_requiring_it": "CISA BOD 22-01 (KEV remediation, added 2023-11-13)",
@@ -55377,7 +56209,32 @@
         "adequate": false,
         "gap": "Hardening/removing unused management functionality would drop the user.php surface, but the Essential Eight control is not tied to this appliance interface and is easily left enabled."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The SRX Series is the trust boundary, and this entry's own base score is what makes it the case this control exists for. The packet scores it 5.3 while recording an RWEP of 77, a public PoC, EPSS 0.94 at the 99.8th percentile, exploitation observed from 2023-08-25, and the role the flaw actually plays: an unauthenticated request to user.php uploads arbitrary files via J-Web, supplying the file-write primitive that combines with CVE-2023-36845 into a pre-auth RCE chain. A CVSS-keyed SLA files that as a medium and schedules it into a routine window, which is the failure the packet records twice — once as flaw remediation deprioritizing it wrongly, once as technical-vulnerability triage under-weighting it against watchTowr's public PoC chaining through PHPRC/auto_prepend_file. Bound to this estate, the tier is set by the device class and the pre-auth reachability, not the score: every SRX running J-Web goes on the expedited clock that opened with the 2023-11-13 KEV listing and is driven to the fixed release for its train — 20.4R3-S8, 21.2R3-S6, 21.3R3-S5, 21.4R3-S5, 22.1R3-S3, 22.2R3-S2, 22.3R2-S2 or 22.3R3, 22.4R2-S1 or 22.4R3 — or has J-Web isolated until it gets there. Units running a 21.1 release are a per-unit question rather than an assumption: the packet's vector records 21.1R1 and later as affected but names no fixed release for that train, so that level has to be obtained from the vendor advisory for the specific unit rather than inferred in either direction. The restart is not a detail here. patch_required_reboot is true and the packet states remediation requires applying the fixed release and rebooting, with no vendor live-patch mechanism, so a firewall carrying the fixed release that has not been rebooted onto it is still executing the vulnerable code and counts as exposed — and on a perimeter firewall that reboot is exactly the step deferred to a maintenance window, which is how this remediation gets recorded as complete while the upload stays reachable. Precondition on the isolation alternative: restricting reachability of J-Web bounds who can send the request, it does not repair user.php, and any host inside the permitted management segment still reaches the unauthenticated upload — so isolation is the holding measure for the window before the reboot, never a substitute for it.",
+        "evidence": "cvss is 5.3 against rwep_score 77. cisa_kev is true with kev_date 2023-11-13, active_exploitation is confirmed and poc_available is true. active_exploitation_notes records this as part of the actively-exploited Juniper J-Web pre-auth RCE chain, with the unauthenticated request to user.php providing the file-write primitive combined with CVE-2023-36845 for RCE, exploitation observed from Aug 25 2023, and EPSS 0.94 at the 99.8th percentile. patch_available is true, patch_required_reboot is true, live_patch_available is false, and live_patch_notes states there is no vendor live-patch mechanism and that remediation requires applying the fixed release and rebooting. The fixed levels quoted are the affected_versions entries (all versions prior to 20.4R3-S8; 21.2 prior to 21.2R3-S6; 21.3 prior to 21.3R3-S5; 21.4 prior to 21.4R3-S5; 22.1 prior to 22.1R3-S3; 22.2 prior to 22.2R3-S2; 22.3 prior to 22.3R2-S2 / 22.3R3; 22.4 prior to 22.4R2-S1 / 22.4R3), and the vector separately lists 21.1 versions 21.1R1 and later as affected without a fixed release. The NIST-800-53-SI-2 gap records that the medium base score understates a preauth file-upload primitive that is a documented link in a public RCE chain and that CVSS-keyed patch SLAs deprioritize it wrongly; the ISO-27001-2022-A.8.8 gap records the same triage failure, naming watchTowr's public PoC chaining into RCE via PHPRC/auto_prepend_file.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "J-Web is the SRX's device-management interface, and this defect is one of its endpoints deciding nothing at all. The packet's vector states that a specific request to user.php that does not require authentication lets an attacker upload arbitrary files via J-Web, costing integrity of part of the file system and allowing chaining to other vulnerabilities. Bound to this appliance, the control has two halves and both are load-bearing here. First, the file-accepting endpoints on J-Web must authorize the caller before the upload is processed at all, and must constrain where the uploaded file lands, so an unauthenticated request cannot place content into a directory the appliance later reads from — which is precisely the step CVE-2023-36845 needs to convert the write into pre-auth code execution. Second, no SRX should be left with J-Web reachable from a segment with no operational need to reach it, and on units administered through the CLI or a management system J-Web is unused management functionality whose removal deletes the user.php surface rather than merely bounding who can send to it — the packet records exactly that as the hardening action the Essential Eight control is not tied to and that is easily left enabled. The identity-and-access controls this entry cites do not close this path: the attacker never holds a Junos account, so per-account authentication and privilege policy on the appliance is never consulted and an IAM attestation on the SRX passes cleanly while the unauthenticated upload stays reachable. Distinguishing test: from a segment with no management role, send an unauthenticated request to user.php on a staging SRX and confirm it is refused before anything is written — confirming that J-Web administrators authenticate at login exercises a different path entirely and will pass regardless. Preconditions, and they matter more than usual here. The endpoint-side authentication check is what the fixed release restores; this control states the property to verify, it does not implement it, and until the fixed release and its reboot land, segmenting J-Web bounds the population that can send the request while leaving the endpoint fully exploitable to anything inside the permitted segment — a compromised management workstation or jump host satisfies the flaw's only requirement in full. Segmentation is also unavailable where J-Web must stay reachable for operations. And because exploitation has been observed since 2023-08-25, an SRX whose J-Web was reachable during that window may already hold uploaded files; applying the fixed release and rebooting does not remove what was written before it, so an exposed unit belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "vector states that a missing authentication for critical function vulnerability in Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause limited impact to file system integrity, and that with a specific request to user.php that doesn't require authentication an attacker is able to upload arbitrary files via J-Web, which may allow chaining to other vulnerabilities; affected records the same as unauthenticated arbitrary file upload via user.php on the J-Web interface. attack_vector records the upload landing in a restricted J-Web directory and yielding pre-auth RCE when combined with the PHPRC flaw. The NIST-800-53-AC-3 gap records that access enforcement is exactly what is missing, that the fix restores the check, and that until patched no access-control policy compensates; the NIST-800-53-SC-7 gap records that boundary protection exposing J-Web is the precondition and that segmenting or disabling the management interface is the durable mitigation patch-only remediation ignores; the NIS2-Art21-network-security gap records that network-security duties do not mandate management-plane isolation; the AU-Essential-8-App-Hardening gap records that hardening or removing unused management functionality would drop the user.php surface but is easily left enabled; the UK-CAF-B2 gap records that a compliant IAM posture on the appliance still leaves the preauth upload primitive reachable until patched. active_exploitation is confirmed with exploitation observed from Aug 25 2023; patch_available is true, patch_required_reboot is true and live_patch_available is false.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B2",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2023-36847": {
     "name": "Juniper Junos OS EX J-Web Missing Authentication File Upload",
@@ -55776,7 +56633,40 @@
         "adequate": false,
         "gap": "Technical-vulnerability-management inventories often miss embedded/bundled ActiveMQ, so the affected component is never assessed against this CVE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The Java OpenWire marshaller is the listener this control governs on ActiveMQ: the packet has a remote attacker with network access manipulating serialized class types so the broker instantiates any class on the classpath, and the observed exploitation ran against internet-exposed OpenWire brokers on TCP/61616. Bound to this deployment the requirement is that the OpenWire transport binds to the messaging segment rather than all interfaces and answers only the application hosts that legitimately produce and consume messages; that every wire transport the broker has enabled is restricted the same way, not only the one the applications happen to use; and that the transport is disabled outright on brokers whose applications do not speak OpenWire. It reaches the client side too — the packet's vector states a remote attacker with network access to a Java-based OpenWire broker *or client* can drive the instantiation, so an application host that opens an outbound OpenWire connection to a broker it does not control is in scope, and a control that only firewalls inbound 61616 leaves that direction untouched. Precondition, and it is the half most often dropped: segmenting the listener bounds who can send an OpenWire frame, it does not neutralize the marshaller. Any host inside the permitted segment still reaches the class-instantiation path, so this is containment for the window before the broker and its clients are running 5.15.16, 5.16.7, 5.17.6 or 5.18.3 — not a substitute for those builds. And the control is unavailable where a broker must accept OpenWire connections from a network the operator does not control; there the fixed release is the only remedy and the exposure is live until it is the code actually executing. Distinguishing test: from a host outside the messaging segment on a staging instance, open a connection to the OpenWire port carrying a frame whose serialized class type names a class the application protocol never legitimately conveys, and confirm the peer is rejected before the broker instantiates anything — a broker that passes a patch-level audit while listening on all interfaces is still reachable by exactly the tooling the packet records against this port.",
+        "evidence": "Packet facts only. vector: 'The Java OpenWire protocol marshaller is vulnerable to Remote Code Execution. This vulnerability may allow a remote attacker with network access to either a Java-based OpenWire broker or client to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause either the client or the broker (respectively) to instantiate any class on the classpath.' attack_vector adds that the crafted OpenWire packet drives instantiation of an arbitrary class. active_exploitation_notes: 'Heavily exploited in the wild against internet-exposed OpenWire brokers (TCP/61616) to deploy ransomware (HelloKitty, TellYouThePass) as well as Kinsing, SparkRAT and cryptominers. CISA-KEV flags known ransomware use.' cisa_kev true, kev_date 2023-11-02, active_exploitation 'confirmed', cvss 9.8, rwep_score 71, poc_available true. Fixed releases 5.15.16 / 5.16.7 / 5.17.6 / 5.18.3 are from the vector and affected_versions. Remediation state: patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' The framework side is the packet's own gaps: NIST-800-53-SC-7 ('Boundary protection frequently overlooks message-broker ports; leaving OpenWire 61616 internet-reachable turns a preauth deserialization bug into RCE regardless of app-layer controls'), UK-CAF-B4 (\"System-security expectations don't specifically require restricting broker protocols to trusted segments, so the exposed OpenWire endpoint stays reachable\"), AU-Essential-8-App-Hardening (\"Application-hardening guidance doesn't cover restricting or disabling the OpenWire transport\").",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "ActiveMQ is frequently not an inventoried product on the estate that runs it, and the packet says so in two frameworks at once: technical-vulnerability inventories miss embedded and bundled ActiveMQ, and patch-management obligations rarely track middleware or message-broker inventory at all. That is a dependency-inventory requirement rather than a patch requirement, because the vulnerable OpenWire marshaller reaches an estate by routes a standalone-product register does not see — a broker bundled inside a vendor application and updated only on that vendor's schedule, and an OpenWire client library pulled in transitively by a Java service that no one thinks of as a messaging component but which the packet places in scope for the same defect. Bound to this CVE the control means the inventory resolves, for every Java application in the estate, whether an ActiveMQ broker or an OpenWire client sits anywhere in its dependency tree including below its direct dependencies, and records the version so it can be compared against 5.15.16, 5.16.7, 5.17.6 and 5.18.3 for the branch it is on. Scope it to what the packet names — ActiveMQ brokers and their OpenWire clients. The packet ties the deserialization sink to the Java OpenWire protocol marshaller and gives no mapping into other message brokers or queueing products, so instructing operators to treat every broker in the estate as an instance of this CVE manufactures findings against software no evidence implicates. Precondition: this reaches only what the inventory can resolve and the operator can update — a broker embedded in a vendor application is remediated by that vendor's fixed build, not by the operator swapping a library under it, so an embedded instance whose vendor has not shipped a fix is an exposure to track and compensate for at the network layer, not an item to close. Distinguishing test: take an application whose software register lists no message broker, resolve its full dependency tree, and confirm the register would have surfaced an embedded broker or a pre-fix OpenWire client — an estate that patched every standalone broker it knew about while a vendor application ships its own on a 5.16.x build closes the flaw-remediation ticket with the OpenWire path still live.",
+        "evidence": "Packet facts only. The ISO-27001-2022-A.8.8 gap states: 'Technical-vulnerability-management inventories often miss embedded/bundled ActiveMQ, so the affected component is never assessed against this CVE.' The NIS2-Art21-patch-management gap states: 'Patch-management obligations rarely track middleware/message-broker inventory, so ActiveMQ instances slip out of the essential-service patch scope that would have forced timely upgrade.' The client side is in scope per the vector, which names 'either a Java-based OpenWire broker or client' and recommends upgrading 'both brokers and clients to version 5.15.16, 5.16.7, 5.17.6, or 5.18.3'; affected likewise reads 'Apache ActiveMQ (and clients) using the Java OpenWire protocol marshaller'. Branch versions (5.16.x, 5.17.x, 5.18.x) are from affected_versions. cisa_kev true, kev_date 2023-11-02, active_exploitation 'confirmed', cvss 9.8, rwep_score 71, poc_available true, patch_available true. The packet names no message broker other than ActiveMQ.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This is the SLA case the packet's flaw-remediation gap describes: exposed OpenWire brokers were exploited within days of PoC release, so a scheduled-patching timeline never closed the window. For ActiveMQ the clock runs from the 2023-11-02 KEV listing, and the verified mitigation that satisfies it is one of the four fixed releases — 5.15.16, 5.16.7, 5.17.6 or 5.18.3 — actually executing on the broker; where that cannot land inside the window, the satisfying state is a documented compensating control, meaning removal of OpenWire reachability from anything outside the messaging segment, recorded as a time-bound action item rather than logged as patched. Completion is measured on the version the running process reports, not on the package on disk. patch_required_reboot is false here, which records that no host reboot is required; it does not mean the fix is live on deployment, because a broker keeps executing the marshaller loaded into the JVM it started with until that service is restarted onto the new build — and the same applies to every application holding an OpenWire client, which the packet puts in scope for the same defect and which is typically restarted on a different schedule from the broker, if at all. Precondition on the compensating half: restricting reachability of the OpenWire port bounds who can send a frame and does nothing about hosts inside the permitted segment, so it is a holding measure with an expiry, not a closure. Distinguishing test: after the change window, query each broker and each OpenWire client application for the version it is currently running and confirm none reports a pre-fix build — an attestation that the ActiveMQ package was updated inside the SLA reads clean while a broker that was never restarted keeps serving the vulnerable marshaller on a port the packet records under active ransomware exploitation.",
+        "evidence": "Packet facts only. cisa_kev true, kev_date 2023-11-02, active_exploitation 'confirmed'; active_exploitation_notes: 'Heavily exploited in the wild against internet-exposed OpenWire brokers (TCP/61616) to deploy ransomware (HelloKitty, TellYouThePass) as well as Kinsing, SparkRAT and cryptominers. CISA-KEV flags known ransomware use.' cvss 9.8, rwep_score 71, poc_available true. Remediation state: 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.' Fixed releases and the client-side scope are from the vector: 'Users are recommended to upgrade both brokers and clients to version 5.15.16, 5.16.7, 5.17.6, or 5.18.3 which fixes this issue.' The framework side is the packet's own gaps: NIST-800-53-SI-2 ('Flaw-remediation timelines assume scheduled patching, but exposed brokers were exploited within days of PoC release — the SLA is slower than the observed weaponization window') and NIS2-Art21-patch-management ('Patch-management obligations rarely track middleware/message-broker inventory, so ActiveMQ instances slip out of the essential-service patch scope that would have forced timely upgrade').",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-46748": {
     "name": "F5 BIG-IP Configuration Utility SQL Injection Vulnerability",
@@ -56091,7 +56981,40 @@
         "adequate": false,
         "gap": "Configuration-management baselines don't flag an internet-facing IOS XE web UI as non-compliant, so the exposed injectable interface passes audit."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "Cisco IOS XE runs the routers and switches that carry an organization's edge, and this entry offers exactly the two levers this tier admits. The fix is a per-train image — the packet names 17.9.4a, 17.6.6a, 17.3.8a and 16.12.10a — with no live-patch path and a reboot required, so a device that has the image staged but has not reloaded onto it is still executing the vulnerable code and must be counted exposed rather than closed on the download. The alternative the tier permits is isolation of the vulnerable interface, which here is the HTTP/HTTPS Server (web UI) feature the packet ties the injection to: an IOS XE device with no operational need for the web UI should not have that feature enabled at all, and where it is needed it should answer only from a management segment rather than from untrusted networks. Scope the sweep to what the packet's affected_versions names — IOS XE 16.x and 17.x trains with the HTTP/HTTPS Server feature enabled — and run the clock from the 2023-10-23 KEV listing rather than the next network-maintenance window, because this is a device class whose standard 14/30-day change cadence was outrun by a mass campaign. Precondition, and it is the half operators skip: disabling or segmenting the web UI bounds who can send the crafted input, but it removes nothing already written to a device that was exposed, and it gives nothing against an attacker who already reaches the permitted management segment.",
+        "evidence": "Packet: KEV listed 2023-10-23, active_exploitation confirmed, poc_available true, RWEP 79. patch_available true with patch_required_reboot true and live_patch_available false; live_patch_notes states remediation requires applying the fixed release and rebooting. affected_versions names IOS XE with the HTTP/HTTPS Server (web UI) feature enabled across 16.x/17.x trains, fixed in per-train releases such as 17.9.4a, 17.6.6a, 17.3.8a, 16.12.10a. The CM-7 gap records that least-functionality would have disabled the HTTP/HTTPS Server the injection abuses; the SC-7 gap records that internet-exposed management web UIs are what enabled the mass campaign; the NIS2 network-security gap records that disabling/segmenting the device management plane is rarely mandated.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "The IOS XE web UI is the user-facing management surface this control governs, and the packet's vector is the forbidden pattern stated plainly: crafted input to the web UI is insufficiently validated and injects commands that execute on the underlying operating system with root privileges. Applied to this device it means the privileged OS operations the web UI drives sit behind their own authorization and validation boundary, reachable only through a constrained interface, so the web UI's own handling of request input is not the single thing standing between a web-UI account and root on the router. Note where the account comes from, because it changes what account-side hardening buys: the packet records CVE-2023-20198 creating the local account this flaw then elevates from, so tightening who legitimately holds web-UI credentials bounds the population that can attempt it but does not close the path — the attacker in this campaign supplies their own account. Preconditions: the vendor fixed release is what repairs the boundary; this control states the property to verify, it does not implement it. And because active exploitation is confirmed and the packet records this injection being used to write a persistent implant, a device whose web UI was reachable during the campaign window needs forensic triage and credential rotation rather than being closed on the upgrade record.",
+        "evidence": "Packet vector: a vulnerability in the web UI feature of Cisco IOS XE Software allows an authenticated, remote attacker to inject commands with the privileges of root, due to insufficient input validation. affected: used to elevate and implant after CVE-2023-20198 provides the account. attack_vector: using the local account created via CVE-2023-20198, the attacker sends crafted input to the IOS XE web UI, injecting OS commands that run as root and are used to write a persistent implant. active_exploitation confirmed; CWE-78. The AU-Essential-8-App-Hardening gap records that hardening baselines for network devices seldom require turning off the web UI, leaving the root-command-injection path exploitable; the UK-CAF-B4 gap records that system-security assurance assumes the management web UI is trustworthy.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records the outcome of this flaw as persistence, not just execution: it was the second stage of the mass Cisco IOS XE campaign, used after CVE-2023-20198 had created a local account, to elevate to root and write a persistent implant. Loading 17.9.4a, 17.6.6a, 17.3.8a or 16.12.10a closes the injection path and removes neither the account the companion flaw created nor the implant written through this one, so the default response for an IOS XE device that was running an exposed web UI during the campaign window is configuration capture, rebuild from a known-good image and configuration, and rotation of every credential the device held or that transited it — not upgrade-in-place. The reload the fixed image requires is not the eviction step, and treating it as one is the specific way this remediation goes wrong: a device that reloads onto a fixed train with the attacker's local account and implant still resident is reported patched and stays compromised, which is exactly the state a system-security attestation reads as healthy.",
+        "evidence": "Packet active_exploitation_notes: exploited in the wild as the second stage of the mass Cisco IOS XE campaign — after CVE-2023-20198 created a local account, this web-UI command-injection flaw was used to elevate to root and write the persistent implant. affected: used to elevate and implant after CVE-2023-20198 provides the account. patch_available true, live_patch_available false, patch_required_reboot true, with fixed per-train releases named in affected_versions. The UK-CAF-B4 gap states that an authenticated root command-injection chained to the CVE-2023-20198 account-creation flaw drops an implant.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-4966": {
     "name": "Citrix NetScaler ADC and NetScaler Gateway Buffer Overflow Vulnerability",
@@ -56729,7 +57652,32 @@
         "adequate": false,
         "gap": "Even a 48-hour patch target for internet-facing services was outpaced by public PoC availability and ransomware tooling for this flaw."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Progress WS_FTP Server is a managed-file-transfer server that exists to be reachable by external parties, and the packet's numbers are why a routine flaw-remediation cycle is the wrong instrument for it: KEV listing on 2023-10-05, confirmed active exploitation, public proof-of-concept, and a KEV entry carrying a known ransomware association. For this CVE the control means the clock starts at the KEV listing and runs until each install reports 8.7.4, or 8.8.2 on the 8.8 branch, or later. Enumerate the population by where the Ad Hoc Transfer module is enabled, because that is the module the packet places the pre-authenticated .NET deserialization sink in, and an install without it is not the same exposure as one with it. Measure completion on the version the running WS_FTP Server service reports, not on the installer having been run: patch_required_reboot is false, so there is no host reboot to schedule, but that is a statement about the machine and not about the service, and a host that took the vendor release while the service process still executes pre-fix code has not been remediated. There is no live-patch path in the packet, so the vendor fixed release is the only remediation and there is no intermediate state to record as partial credit. Where the fixed release cannot be reached inside the window, the control's compensating-control clause has to be a documented, time-bound removal of reachability to the Ad Hoc Transfer module rather than an open-ended risk acceptance. State its limit plainly: restricting reachability bounds who can send the request, it does not repair the deserialization sink, and it gives nothing against a caller already inside a permitted network — the flaw needs no credential at all, so an attacker who can reach the module has satisfied the entire precondition.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-10-05; active_exploitation confirmed; poc_available true; rwep_score 70 against cvss 8.8. active_exploitation_notes: 'KEV-listed with a known ransomware association; EPSS ~0.90. Public exploitation followed rapidly after Assetnote's disclosure, targeting internet-facing WS_FTP Server Ad Hoc Transfer modules.' affected: 'Progress WS_FTP Server prior to 8.7.4 and 8.8.2 with the Ad Hoc Transfer module enabled; pre-authenticated .NET deserialization leads to OS command execution.' affected_versions: 'WS_FTP Server < 8.7.4', 'WS_FTP Server 8.8.x < 8.8.2'. 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-Patch gap records that even a 48-hour patch target for internet-facing services was outpaced by public PoC availability and ransomware tooling; the UK-CAF-B4 gap records that the control does not force the Ad-Hoc-Transfer hardening or accelerated patching this flaw demands.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The two gaps this attaches to both establish the same fact about Progress WS_FTP Server: the framework-prescribed patch window was longer than the interval between disclosure and exploitation, so on an internet-facing install the honest planning assumption is that the vulnerable window was open while the flaw was being exploited. What that means for this product is set by the primitive — the packet has a pre-authenticated attacker running arbitrary OS commands as the service account through the Ad Hoc Transfer module. Upgrading to 8.7.4 or 8.8.2 removes the deserialization sink; it removes nothing that already ran as that account. So an install that was internet-reachable with Ad Hoc Transfer enabled during the exposure window is an incident item, not a patch item: preserve the server's configuration and logs as evidence, rebuild the host from a known-good baseline and the fixed release rather than upgrading in place, and treat as disclosed every credential the service account held or that transited the transfer server — the service account itself, local transfer accounts, and any stored partner or downstream credential — rotating each. The KEV ransomware association is what makes the rebuild rather than the clean-up the default: an actor whose objective is deployment, not persistence-for-its-own-sake, leaves artifacts an upgrade preserves. Preconditions, because this control is easy to over-claim. It is triggered by the possibility of prior exposure, not by a detection: the packet records no indicator set, so nobody should wait for a hit before invoking it, and equally nobody should read a clean scan as evidence the rebuild is unnecessary. Restoring configuration or data from a backup taken inside the exposure window reinstates whatever was placed there, so the baseline must predate it. And this control does nothing to reduce the chance of exploitation — it governs only what a compliant response looks like after a window the patch clock left open.",
+        "evidence": "Packet: attack_vector 'A pre-authenticated attacker sends a crafted serialized .NET object to the WS_FTP Server Ad Hoc Transfer module; unsafe deserialization executes an attacker gadget chain, running arbitrary OS commands as the service account.' active_exploitation confirmed; poc_available true; active_exploitation_notes record a known ransomware association and that public exploitation followed rapidly after disclosure against internet-facing Ad Hoc Transfer modules. The NIST-800-53-SI-2 gap states 'Managed-file-transfer appliances are patched on change-controlled cycles; the observed exploitation window after disclosure was far shorter than typical MFT patch SLAs', and the AU-Essential-8-Patch gap states that even a 48-hour internet-facing patch target was outpaced. patch_available true with live_patch_available false and live_patch_notes recording the vendor fixed release as the only remediation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-42824": {
     "name": "Apple iOS and iPadOS Kernel Privilege Escalation Vulnerability",
@@ -57209,7 +58157,31 @@
         "adequate": false,
         "gap": "Patch-application maturity targets the OS/app vendor; an unmaintained embedded framework has no upstream patch, so the control cannot be satisfied by patching alone."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "RichFaces 3.x is not something an operator installs and can therefore be asked about — it arrives inside a WAR or EAR that someone else built, which is why an inventory keyed to the application product and version reports nothing while org.ajax4jsf.resource.UserResource$UriData sits in that archive answering unauthenticated requests and evaluating attacker-supplied Expression Language. Bound to this CVE the control means the component inventory is produced from the deployed artifact rather than from the vendor's product name: enumerate the JARs actually inside every deployed Java web application, explicitly including third-party and vendor-supplied applications the organization did not build and cannot see the source of, and match on the richfaces / ajax4jsf coordinates at 3.X through 3.3.4. That discovery has to be repeated after any redeployment, vendor upgrade or restore from an application archive, because those are the operations that quietly reintroduce the old JAR into an installation that had been remediated. Scope it to what the packet establishes: the EL-injection sink is named in RichFaces 3.X through 3.3.4, and the packet maps it into no other JSF component library, so sweeping every JSF application in the estate as an instance of this CVE manufactures findings and remediation work against code no evidence implicates — widen only where a verified source identifies another component carrying the same sink. Distinguishing test: take a deployed application whose vendor documentation never mentions RichFaces, unpack its WEB-INF/lib, and confirm the inventory the vulnerability-management programme actually consumes lists what is in there. An asset register naming the application and its version passes a technical-vulnerability-management review cleanly while a 3.3.4 JAR inside it serves an unauthenticated code-execution path.",
+        "evidence": "Packet affected: 'Red Hat JBoss RichFaces Framework 3.X through 3.3.4 — the UserResource resource (org.ajax4jsf.resource.UserResource$UriData) evaluates attacker-controlled Expression Language, enabling a Java-deserialization gadget chain to reach RCE without authentication.' attack_vector: 'A remote, unauthenticated attacker sends a crafted UserResource$UriData request whose serialized-object chain is evaluated as an EL expression, executing arbitrary Java in the servlet container.' CWE-94; CVSS 9.8; RWEP 68; poc_available true; active_exploitation confirmed, 'exploited against internet-facing JBoss/JSF applications for unauthenticated RCE (EPSS ~0.74)'; CISA KEV 2023-09-28. ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management that inventories only first-party components will not surface an embedded RichFaces 3.x dependency inside a deployed WAR, leaving the EL-injection sink unremediated.' NIS2-Art21-vulnerability-management gap: 'Requires timely handling but does not mandate the SBOM-level component discovery needed to find a legacy JSF library shipped inside third-party Java apps.' NIST-800-53-SI-2 gap: 'affected apps embed the vulnerable JAR transitively, so a patch cycle keyed to the product misses the bundled framework.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry carries two facts that have to be resolved together before any remediation sentence is written. The packet records patch_available true with the remediation given as applying the vendor fixed release; the entry's own framework gaps record RichFaces 3.x as end-of-life, the vulnerable JAR as embedded transitively in affected applications, and an unmaintained embedded framework as having no upstream patch, so the control cannot be satisfied by patching alone. The requirement that follows is per-application. Where the application's own vendor ships a build that no longer carries RichFaces 3.x, moving to it is the interim state — and the verification is that the richfaces/ajax4jsf JAR is gone from the deployed archive, not that a product version number changed, because the version number is the thing that was already passing while the JAR sat underneath it. Where no such build exists, the terminal state is removing the RichFaces 3.x dependency from the application or retiring the application, on a dated schedule: an application on that footing is exposed not only to this EL-injection path but to everything else found in an unmaintained framework since 3.3.4, and a risk acceptance with no removal date leaves an unauthenticated RCE with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half, and it is the one most often skipped here: patch_required_reboot false is a statement about the host, not about the application — the vulnerable classes stay live in the servlet container until the application is redeployed or the container restarted, so completion is measured on what the running container is serving rather than on what is on disk, and the packet records no live-patch mechanism that would make the swap take effect any earlier. And because exploitation against internet-facing JBoss/JSF applications is confirmed and the sink yields arbitrary Java execution in the container, an application that was reachable during the exposure window is not closed by the dependency change: what the container may already be serving needs triage, and credentials the application holds need rotation.",
+        "evidence": "Packet: 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.' Against that, the entry's framework_control_gaps state: NIST-800-53-SI-2 — 'RichFaces 3.x is end-of-life; flaw remediation assumes a vendor patch, but affected apps embed the vulnerable JAR transitively, so a patch cycle keyed to the product misses the bundled framework'; AU-Essential-8-Patch — 'Patch-application maturity targets the OS/app vendor; an unmaintained embedded framework has no upstream patch, so the control cannot be satisfied by patching alone'; UK-CAF-B4 — 'the framework is end-of-life with no upstream patch'. Exploitation: CISA KEV 2023-09-28, active_exploitation confirmed against internet-facing JBoss/JSF applications for unauthenticated RCE, EPSS ~0.74, poc_available true, CVSS 9.8, RWEP 68. affected_versions: RichFaces 3.X through 3.3.4.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-41991": {
     "name": "Apple Multiple Products Improper Certificate Validation Vulnerability",
@@ -57519,7 +58491,38 @@
         "adequate": false,
         "gap": "Restricting privileged access reduces who can reach the console but does not remove the code-injection sink in the uninstaller module for those who legitimately have access."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "The vulnerable product here is the endpoint-protection platform itself, and the sink is a module it ships: the 3rd-party AV uninstaller in Trend Micro Apex One (on-prem and SaaS), Worry-Free Business Security and Worry-Free Business Security Services, manipulated into executing arbitrary OS commands on the management install. Bound to this product the control means the Trend Micro management estate is carried in the vulnerability-management inventory with the same SLA as any other privileged software, and remediation is measured per install against the four fixed levels the packet names — Apex One 2019 on-prem at SP1 Patch 1 (B12380), Apex One as a Service at agent 14.0.12637, Worry-Free Business Security 10.0 SP1 at Patch 2495, and Worry-Free Business Security Services at the July 31, 2023 maintenance release — rather than by the console reporting itself healthy. All four SKUs must be enumerated, not just the on-prem Apex One most estates inventory: two of them are vendor-hosted, so the operator's evidence there is the agent or service level actually in service. live_patch_available is false and the packet records applying the vendor fixed release as the remediation, so no install is remediated until it is running the fixed level. Precondition: this was exploited as a zero-day before the fix existed, so patch level is not an answer to the exposure window — a management install that was reachable by an administrative console session during that period needs triage of what executed on the host, not closure on its build number.",
+        "evidence": "Packet: name 'Trend Micro Apex One and Worry-Free Business Security Remote Code Execution Vulnerability'. affected records the 3rd-party AV uninstaller module in Apex One (on-prem and SaaS), Worry-Free Business Security and Worry-Free Business Security Services being manipulated to execute arbitrary OS commands. affected_versions names Apex One 2019 (on-prem) before SP1 Patch 1 (B12380), Apex One as a Service before agent 14.0.12637, Worry-Free Business Security 10.0 SP1 before Patch 2495, and Worry-Free Business Security Services before the July 31, 2023 maintenance release. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release'. active_exploitation_notes records exploitation as a zero-day before the fix, with cisa_kev true and kev_date 2023-09-21.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The packet states the exploit's precondition outright and it is the whole of it: the attacker must first obtain administrative console access on the Trend Micro install. That makes the console an endpoint-security control plane whose administrator population is the entire attack prerequisite, and those accounts belong in a tier above application admins — reachable only through a PAM jumphost rather than from any workstation on the corporate segment, phishing-resistant step-up per session, just-in-time elevation with approval, and an identity used for nothing else. This is the concrete form of the boundary-protection requirement the entry records as insufficient: 'restrict the console to trusted networks' as usually implemented still means a broad internal segment, and jumphost-only reachability is the version of that restriction which actually narrows who can present a session. It is also the rejection of the assumption the system-security gap names — the endpoint-security console is treated as trusted infrastructure precisely because it is a security product, which is why it sits outside the privileged-access tiering applied to identity providers and orchestrators. Precondition, and it is the load-bearing one: this bounds who can reach the console; it does not remove the command-injection sink in the uninstaller module, which stays reachable by every account that legitimately reaches the console, and only the vendor fixed release removes it. Tiering applied after an administrator credential was already compromised gives nothing back.",
+        "evidence": "Packet: vector states 'an attacker must first obtain administrative console access on the target system in order to exploit this vulnerability'. attack_vector records an attacker who has already obtained administrative-console access manipulating the 3rd-party AV uninstaller module to inject and execute arbitrary OS commands on the management host. The NIST-800-53-SC-7 gap records boundary protection as the practical mitigation while the console stays exposed to a broad internal segment a compromised admin can reach; the UK-CAF-B4 gap records that system-security assurance treats the endpoint-security console as trusted infrastructure.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-044",
+        "name": "EDR-AS-VULNERABILITY-SECONDARY-OVERLAY",
+        "description": "The behaviour to detect is the one the packet describes and no other: the AV product's own 3rd-party uninstaller module spawning arbitrary OS commands on the management host, under a legitimate administrative console session. The product that would normally raise that alert is the product being exploited, and its own module is the process doing the spawning, so its telemetry is the least likely place the activity registers as anomalous — which is exactly why an overlay that does not share trust roots with the Trend Micro deployment is the requirement. Bound to this estate that means independent process-lineage monitoring on the Apex One and Worry-Free management hosts for OS command execution descending from the platform's service and uninstaller components, correlated with console sessions. Distinguishing test: on a staging management install, drive a benign command through the uninstaller module path with an authorized console session and confirm the overlay reports the child process; an estate that reports 'endpoint protection healthy everywhere' has said nothing about whether the protection product's own module executed a command. Note what will not see it — nothing crashes, no unsigned binary is introduced, and the console session is legitimate, so authentication logging and the platform's own health reporting have no artifact to match. Precondition: an overlay sharing trust roots or a management plane with the same vendor is not independent, and detection does not prevent the execution; it bounds the interval between execution and response, and only if the overlay was already deployed when the attempt came.",
+        "evidence": "Packet: affected and attack_vector record the 3rd-party AV uninstaller module being manipulated to inject and execute arbitrary OS commands on the management host by an attacker holding administrative-console access. active_exploitation is 'confirmed' and active_exploitation_notes records exploitation as a zero-day before the fix. The UK-CAF-B4 gap records that no compensating monitoring covers the third-party-uninstaller command-execution sink that this zero-day turned a legitimate admin session into RCE through.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-28434": {
     "name": "MinIO Security Feature Bypass Vulnerability",
@@ -57817,7 +58820,33 @@
         "adequate": false,
         "gap": "Patch maturity is unmet on EOL consumer hardware; there is no ongoing vendor patch stream."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet states the terminal condition outright — the Zyxel EMG2926 (EMG2926-Q10A) is end-of-life, and the flaw-remediation gap records that there is no supported firmware to apply so device replacement is the only fix. The requirement is therefore an inventory naming every EMG2926 in service with its running firmware version, checked against the affected build the packet names, V1.00(AAQT.4)b8, and with support status and any fixed build for that exact model obtained from Zyxel rather than assumed in either direction. Any unit for which the vendor does confirm a fixed build is an interim item, and because the packet records no live-patch path with a reboot required, a unit that has taken firmware but has not restarted onto it is still executing the vulnerable code; every unit with no supported firmware is a replacement item needing a dated schedule, since 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 on the router's diagnostic page — the ping_ip parameter of the expert/maintenance/diagnostic/nslookup URI — which is part of its web administration surface, so denying WAN-side access to administration removes the internet-side path, 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 diagnostic page. 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 exploitation is confirmed and the outcome is 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, and credentials that transited it rotated.",
+        "evidence": "Packet affected: Zyxel EMG2926 (EMG2926-Q10A) home router, firmware V1.00(AAQT.4)b8 — the nslookup diagnostic function's ping_ip parameter (expert/maintenance/diagnostic/nslookup) is command-injectable; the device is end-of-life. NIST-800-53-SI-2 gap: the EMG2926 is end-of-life, flaw remediation has no supported firmware to apply, device replacement is the only fix. AU-Essential-8-Patch gap: patch maturity is unmet on EOL consumer hardware, there is no ongoing vendor patch stream. NIST-800-53-SC-7 gap: boundary protection must deny WAN-side access to the admin/diagnostic interface. NIS2 gap: network-security measures do not remove the injection sink for anyone who reaches the authenticated diagnostic page. ISO-27001-2022-A.8.8 gap: vulnerability management on unmanaged SOHO/edge CPE rarely tracks router firmware. UK-CAF-B4 gap: the injectable nslookup page on an unpatchable EMG2926 stays in service, typically discovered only once the conscripted device emits botnet/DDoS traffic. KEV listed 2023-09-18, active_exploitation confirmed, poc_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry forecloses the state a patch-compliance verdict assumes it can reach. The packet records the EMG2926 as end-of-life with no supported firmware to apply and no ongoing vendor patch stream, so no unit can honestly be reported as remediated by a binary fix, and the state an operator can actually hold is the middle one: compensating controls active — WAN-side administration denied, the router's client network isolated from anything that matters — with no vendor fix behind them. The requirement is that this state appears on the vulnerability report as its own class with a dated replacement action item attached, never rolled up as patched-per-SLA and never closed as an accepted risk with no removal date. The distinguishing test is to ask what evidence turned an EMG2926 green: a report that marks it compliant because a scan could not reach expert/maintenance/diagnostic/nslookup has recorded where the scanner was standing, not the removal of a command-injection sink that remains reachable from the network the router serves. Precondition: this control changes what the verdict says, not what the device runs — it is the accounting that keeps a KEV-listed, publicly-exploitable injection visible until the unit is gone, and it removes nothing on its own.",
+        "evidence": "Packet: patch_available true but the NIST-800-53-SI-2 gap records the EMG2926 as end-of-life with no supported firmware to apply — flaw remediation cannot be satisfied and device replacement is the only fix — and the AU-Essential-8-Patch gap records patch maturity unmet on EOL consumer hardware with no ongoing vendor patch stream. live_patch_available false. KEV listed 2023-09-18 with active_exploitation confirmed and poc_available true; active_exploitation_notes records the nslookup diagnostic command injection being exploited by botnets against exposed routers and KEV ransomware status as known. The injection point is the ping_ip parameter of the expert/maintenance/diagnostic/nslookup URI per the packet vector.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-3129": {
     "name": "Laravel Ignition File Upload Vulnerability",
@@ -57874,7 +58903,33 @@
         "adequate": false,
         "gap": "Secure configuration standards must prohibit debug/verbose error pages in production; where 2.2.3 is not enforced for the app framework, the Ignition endpoint stays exposed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "This CVE has a configuration-side mitigation path that the packet states as the exploit's precondition rather than as a hardening nicety: the flaw is reachable only where the application runs in debug mode, and the packet's own affected_versions qualify Laravel before 8.4.2 with APP_DEBUG=true. The requirement is therefore that the debug-off path be inventoried, tested and deployable independently of the Composer upgrade to Ignition 2.5.2 — an operator who cannot immediately move the dependency can still take the unauthenticated /_ignition/execute-solution endpoint out of reach, and must not treat that as waiting on the package. In practice: enumerate every deployed Laravel application and record its running debug state, not the value in the repository, and enforce the setting where deployments are produced — the image build, the release pipeline, the configuration management that writes the environment file — so a restored template, a promoted staging config or a container built with the flag on cannot reintroduce it. Preconditions, and they are why this does not close the surface outright: disabling debug removes the precondition for this path but leaves the vulnerable Ignition package installed, so any later deployment or ad-hoc debugging session that re-enables the flag reopens the endpoint unless the package is also moved to 2.5.2 or later. And it is not retroactive — a host that served traffic in debug mode before the flag was flipped keeps whatever the file_put_contents primitive wrote to it, and given the packet's mass exploitation and ransomware association that host needs to be examined rather than closed on the configuration change.",
+        "evidence": "vector: 'Ignition before 2.5.2, as used in Laravel and other products, allows unauthenticated remote attackers to execute arbitrary code because of insecure usage of file_get_contents() and file_put_contents(). This is exploitable on sites using debug mode with Laravel before 8.4.2.' affected_versions: 'Ignition before 2.5.2', 'Laravel before 8.4.2 (with APP_DEBUG=true)'. attack_vector names the unauthenticated POST to /_ignition/execute-solution. The NIST-800-53-CM-7 gap: 'Least functionality is the real defense — Ignition's debug mode must not run in production'. The PCI-DSS-4.0-2.2.3 gap: 'Secure configuration standards must prohibit debug/verbose error pages in production'. The NIS2-Art21-patch-management gap: 'the control is insufficient without secure-configuration enforcement.' The AU-Essential-8-App-Hardening and UK-CAF-B4 gaps both record that baselines do not require disabling framework debug pages or verify APP_DEBUG is off in production. The NIST-800-53-SI-2 gap: 'the far more common exposure is a misconfigured debug flag that a package patch alone does not address.' KEV 2023-09-18, ransomware known per active_exploitation_notes, EPSS ~0.999, poc_available true, CVSS 9.8, RWEP 70.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "PCI-DSS-4.0-2.2.3",
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE a scan that reports the Ignition version alone is paper compliance, because the packet makes exploitability conditional on a runtime state the dependency manifest does not carry. The operational test has two parts and both must be in the scan: does it determine the debug state the application is actually running in, and does it establish whether /_ignition/execute-solution answers on the deployed host — not merely whether the lockfile pins Ignition at 2.5.2 or later. An estate whose vulnerability management is keyed to Composer metadata will report clean across every application while a single host serves the endpoint, because the fact that distinguishes an exploitable deployment from a safe one is a deployment-time setting rather than a package version. The same asymmetry runs the other way and is worth surfacing in the scan output: a host on a fixed Ignition is not exploitable through this path regardless of its debug setting, so a scan that flags on the configuration alone will generate findings it cannot close. Precondition: this control is a detection-quality requirement and changes nothing about the host's exposure by itself — it exists so that the configuration-side mitigation and the package upgrade can be verified as actually present on the running system. Because the packet records no reboot requirement and no live-patch path, completion is measured on the Ignition version the running application loads, which is the same reason the version claim needs to be taken from the deployment rather than from the manifest.",
+        "evidence": "The ISO-27001-2022-A.8.8 gap: 'Vulnerability management keyed to Composer dependencies may miss that the exploit precondition is a deployment misconfiguration (debug mode), not only an outdated package.' The NIST-800-53-SI-2 gap: 'Flaw remediation requires upgrading Ignition to >= 2.5.2, but the far more common exposure is a misconfigured debug flag that a package patch alone does not address.' affected: 'Ignition before 2.5.2 (as used by Laravel before 8.4.2 and other products) when the application runs in debug mode — insecure use of file_get_contents()/file_put_contents() at /_ignition/execute-solution allows unauthenticated remote code execution.' 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 confirmed; KEV 2023-09-18; CWE-94.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-26369": {
     "name": "Adobe Acrobat and Reader Out-of-Bounds Write Vulnerability",
@@ -58011,7 +59066,32 @@
         "adequate": false,
         "gap": "Technical-vulnerability management periodicity does not match a mobile local-privilege-escalation flaw needing MDM-enforced minimum-patch-level gating."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "For this CVE the fixed state is a single checkable value — an Android security patch level of 2023-09-01 or later — across the Android 11, 12, 12L and 13 devices the packet names. The trigger the packet records is a malicious app already installed on the device launching a background activity through the WindowState onCreate logic error, with no user interaction and no additional execution privilege, so on any device that cannot yet reach that patch level the load-bearing half of this control is the access-condition half: the 2023-09-01 patch level must function as a condition of access — mail, VPN and document access denied to a device below it — not as a row on a patch-compliance report that the device keeps its access despite. Whether a given handset model has an OEM build carrying that patch level is a question to put to the OEM per model, not to infer from the device's age in either direction. Distinguishing test: enrol a device pinned below the 2023-09-01 patch level and confirm the policy actually denies it protected resources; an estate that surfaces the stale patch level on a report while the device keeps its access has recorded the exposure rather than removed it. Preconditions: restricting untrusted or side-loaded application installation raises the bar for getting the attacker's app onto the device, but it does not evict an app already installed and does not cover one that arrived through the normal store channel — a device suspected of already running it belongs on the incident path, not the install-policy path. And the packet records no vendor live-patch mechanism and a fix that requires applying the fixed release and rebooting, so a device that has downloaded the OEM update but not restarted is still executing the vulnerable framework code and counts as exposed.",
+        "evidence": "Packet fields: affected_versions lists Android 11, Android 12, Android 12L and Android 13 (security patch level before 2023-09-01); vector places the flaw in onCreate of WindowState.java as a logic error allowing a background activity to be launched, leading to local escalation of privilege with no additional execution privileges and no user interaction needed; attack_vector states a malicious app already on the device is what exploits it. cisa_kev true with kev_date 2023-09-13 and active_exploitation confirmed; active_exploitation_notes records the Android Security Bulletin flagging limited, targeted exploitation before the September 2023 fix. 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 ISO-27001-2022-A.8.8 gap states technical-vulnerability management periodicity does not match a mobile local-privilege-escalation flaw needing MDM-enforced minimum-patch-level gating; the NIST-800-53-SI-2 gap states the KEV due date (2023-10-04) is unreachable for the long tail of devices that never receive the 2023-09-01 patch level; the UK-CAF-B4 gap states system security expects current software but provides no lever over OEM/carrier delivery.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "On the managed Android devices where an OEM build carrying the 2023-09-01 or later patch level does exist, this remediation fails for a mundane reason rather than a technical one: the update is published and the user defers it. Bound to this CVE, the control means the managed fleet is driven to the 2023-09-01 patch level on the clock that opened with the 2023-09-13 KEV listing — the packet's own flaw-remediation gap names 2023-10-04 as the KEV due date — with user deferral disallowed and the restart enforced rather than left to the user's convenience, because the packet records no live-patch mechanism and a fix that requires applying the fixed release and rebooting. Completion is measured on the security patch level the device reports after that restart, never on 'approved' or 'downloaded' in the management console: a device holding a staged update it has not rebooted onto is still running the vulnerable WindowState path. Enumerate the Android 11, 12, 12L and 13 population first, since that is the affected set the packet names. Precondition, and it is where this control is most often over-claimed: the management platform can only install what the OEM has published, so where a model has no build at or above 2023-09-01 there is nothing for the SLA to deploy, and that device belongs on the access-condition path instead. Carrying it as 'pending vendor' with its access intact is precisely how a device stays exploitable past the KEV date while the fleet reports compliant.",
+        "evidence": "Packet fields: cisa_kev true, kev_date 2023-09-13, active_exploitation confirmed; 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.' affected_versions names Android 11, 12, 12L and 13 (security patch level before 2023-09-01). The NIST-800-53-SI-2 gap gives the KEV due date as 2023-10-04 and attributes the shortfall to OEM/carrier patch propagation; the AU-Essential-8-Patch gap states patch-application maturity assumes an update is deliverable and that fragmented Android OEM update chains leave fleet devices vulnerable past the KEV window; the NIS2-Art21-patch-management gap states patch-management policy cannot force OEM firmware timelines on managed mobile endpoints the policy nominally covers.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-20269": {
     "name": "Cisco Adaptive Security Appliance and Firepower Threat Defense Unauthorized Access Vulnerability",
@@ -58304,16 +59384,40 @@
         "adequate": false,
         "gap": "System security expects timely patching but provides no compensating control for a publicly-weaponized kernel driver flaw in the interim."
       }
-    }
-  },
-  "CVE-2023-41064": {
-    "name": "Apple iOS, iPadOS, and macOS ImageIO Buffer Overflow Vulnerability",
-    "lesson_date": "2026-07-21",
-    "attack_vector": {
-      "description": "A maliciously crafted image sent as a PassKit attachment over iMessage is processed by ImageIO with no user interaction, overflowing a buffer and executing code; combined with CVE-2023-41061 (BLASTPASS) to install Pegasus.",
-      "privileges_required": "none (zero-click; victim need not open anything)",
-      "complexity": "low for the operator (weaponized by a commercial spyware vendor); the underlying chain is sophisticated",
-      "ai_factor": "Not AI-discovered — found by The Citizen Lab. No AI involvement documented."
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the MSKSSRV.SYS Microsoft Streaming Service Proxy kernel driver and describes a local low-privileged process reaching NT AUTHORITY\\SYSTEM through a use-after-free / type confusion. The attacker's account is already legitimate — a privilege boundary inside a kernel driver is failing, not an account model being abused. For this CVE the control means the September 2023 cumulative update is driven across every affected host on the KEV clock that opened 2023-09-12 rather than absorbed into the ordinary monthly rollup cadence, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. Scope from the affected versions rather than from the headline: the packet names affected Windows Server editions alongside Windows 10 and Windows 11, so a program that files this as a workstation item leaves servers running the vulnerable driver. The packet records patch_required_reboot true, no live-patch mechanism, and a live-patch note stating remediation requires applying the fixed release and rebooting — so a host that installed the cumulative update but has not restarted is still executing the vulnerable driver and must be counted as exposed. On always-on and shared machines that restart is 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: exploited in the wild as a zero-day with a public PoC and RWEP 79 against a 7.8 base, this is the escalation half of a chain — the step that turns any foothold into SYSTEM — which is precisely why the least-privilege control cited on this entry can pass its attestation while the flaw stays fully exploitable.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-09-12; active_exploitation confirmed; active_exploitation_notes record exploitation in the wild as a zero-day, analyzed by Google Project Zero's in-the-wild program and patched by Microsoft in September 2023, with a use-after-free / type confusion in the mskssrv kernel driver letting a local low-privileged process elevate to NT AUTHORITY\\SYSTEM. affected: Microsoft Streaming Service Proxy (MSKSSRV.SYS kernel driver) on Windows 10 and Windows 11. affected_versions: Windows 10 (builds before Sept 2023 cumulative update), Windows 11 (builds before Sept 2023 cumulative update), Windows Server (affected editions before Sept 2023 update). poc_available true; CVSS 7.8, RWEP 79; 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.' The NIST-800-53-AC-6 gap states least privilege is bypassed at the kernel boundary regardless of user-level restrictions.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "The packet describes this exploit precisely enough to key a rule on it rather than on an assumed signal: a local process opens the mskssrv device, issues IOCTL_FRAMESERVER_INIT_CONTEXT to initialize FsContext2 to an attacker-chosen object type, then triggers FSStreamReg::PublishRx, which consumes that field as an FsStreamReg object and yields a kernel write ending in SYSTEM. The rule keys on that shape — a non-privileged user-session process opening the Microsoft Streaming Service Proxy device object and issuing the frameserver context-init IOCTL — paired with the privilege transition the packet names as the outcome: that process, or a child it spawns, running as NT AUTHORITY\\SYSTEM. Both halves are needed. Device opens by media applications are legitimate on their own and a SYSTEM process alone arrives with no context; it is the pairing inside a short window that separates this exploit from either. Note what will not see it: nothing is compiled, no driver is loaded or replaced, no file is written, and an inbox Windows driver is being driven through its normal interface — so file-integrity monitoring, driver-load alerting and signature-based endpoint tooling have no artifact to match, and a rule keyed on process crashes or on named exploit tooling would miss an attempt behaving exactly as the packet describes. Precondition: this depends on device-object and IOCTL-level endpoint telemetry already being collected and shipped off-host before the attempt; a rule authored afterwards against telemetry nobody was collecting produces nothing. And detection neither prevents the escalation nor undoes what SYSTEM-level access was used for — it bounds exposure to alert-and-response time during the interim window before the cumulative update and its required reboot land, which is the window the system-security gap on this entry records as having no compensating control at all.",
+        "evidence": "Packet: attack_vector states a local process opens the mskssrv device and issues IOCTL_FRAMESERVER_INIT_CONTEXT to initialize FsContext2 to an attacker-chosen object type, then triggers FSStreamReg::PublishRx which uses that field as an FsStreamReg object, yielding a kernel write and elevation to SYSTEM. cwe_refs CWE-416; affected names the MSKSSRV.SYS kernel driver and a local use-after-free / type confusion escalating a low-privileged process to SYSTEM. poc_available true; active_exploitation confirmed. The UK-CAF-B4 gap states system security expects timely patching but provides no compensating control for a publicly-weaponized kernel driver flaw in the interim. The NIST-800-53-AC-6 gap states a driver type confusion elevates any low-privileged foothold to SYSTEM regardless of user-level restrictions, so AC-6 alone does not contain post-compromise escalation. patch_required_reboot true and live_patch_available false define the length of that interim window.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
+  },
+  "CVE-2023-41064": {
+    "name": "Apple iOS, iPadOS, and macOS ImageIO Buffer Overflow Vulnerability",
+    "lesson_date": "2026-07-21",
+    "attack_vector": {
+      "description": "A maliciously crafted image sent as a PassKit attachment over iMessage is processed by ImageIO with no user interaction, overflowing a buffer and executing code; combined with CVE-2023-41061 (BLASTPASS) to install Pegasus.",
+      "privileges_required": "none (zero-click; victim need not open anything)",
+      "complexity": "low for the operator (weaponized by a commercial spyware vendor); the underlying chain is sophisticated",
+      "ai_factor": "Not AI-discovered — found by The Citizen Lab. No AI involvement documented."
     },
     "defense_chain": {
       "prevention": {
@@ -58541,7 +59645,39 @@
         "adequate": false,
         "gap": "Technical-vulnerability management cadence trails an internet-facing preauth RCE with a public Metasploit module and active botnet use."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "RocketMQ's NameServer, Broker and Controller speak a binary remoting protocol, and this CVE is that protocol answering an unauthenticated caller: the packet records those components leaked on the extranet and lacking permission verification, with the same command execution reachable by forging RocketMQ protocol content instead of using the product's own client. Bound to this deployment, the control means each of those three component listeners accepts connections only from hosts that legitimately speak the protocol - the application producers and consumers, and the operations hosts that administer the cluster - enforced by network ACL or host firewall rather than inherited from an assumption that a message broker is internal by nature. Reachability is the entire exploit precondition here, because the attacker presents no credential: once a component answers, calling updateBrokerConfig to set rocketmqHome/filterServerNums to a shell payload runs commands as the RocketMQ service user. Distinguishing test for this product: from a segment with no producer, consumer or administration role, open a connection to each RocketMQ component on a staging cluster and confirm it is refused before the remoting handler parses the request - a cluster that passes a patch-level audit while its NameServer and Broker answer from any routable network is still exposed to the forged-protocol path. Precondition, and it is the half most often over-claimed: restricting reachability bounds who can send the request, it does not restore the missing permission check, so any host inside the permitted segment - a compromised application server that legitimately talks to the broker included - still reaches the config path in full. This is a holding measure for the window before 5.1.1 / 4.9.6 is the version each component is actually running, not a closure.",
+        "evidence": "Packet vector: 'Several components of RocketMQ, including NameServer, Broker, and Controller, are leaked on the extranet and lack permission verification' and 'an attacker can achieve the same effect by forging the RocketMQ protocol content' (RocketMQ 5.1.0 and below). attack_vector: attacker reaches an internet-exposed component lacking permission verification and calls updateBrokerConfig (or forges the remoting protocol) to set rocketmqHome/filterServerNums to a shell payload, so the broker executes commands as its service user. framework_control_gaps NIST-800-53-SC-7: components 'were never meant to face the extranet'; NIS2-Art21-network-security: measures 'do not inherently mandate isolating message-broker management ports from untrusted networks'; UK-CAF-B4: assurance 'doesn't specifically require isolating RocketMQ's NameServer/Broker/Controller from the extranet'. cisa_kev true (2023-09-06), active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 70. Fixed releases per affected_versions: 5.1.1 for 5.x, 4.9.6 for 4.x.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The update-configuration function is a broker administration operation, and on RocketMQ 5.1.0 and below it runs for a caller the component never verified - the packet places the missing permission check on the components themselves, not on an account model that was misconfigured. Bound to this product, the control means the configuration-mutating remoting commands, updateBrokerConfig among them, make their own authorization decision before the configuration value is applied, rather than inheriting trust from the caller's network position or from the fact that the connection reached a listener at all; and that the administration surface is not left enabled by default on components that also carry production messaging traffic, where nothing distinguishes an operator's config write from a producer's connection. This is the least-functionality gap on this entry rather than the privilege gap, and the distinction matters operationally: the attacker never holds any RocketMQ operator account, so per-account privilege scoping is never consulted and an access-review attestation over the cluster's administrators passes cleanly while this path stays open. Distinguishing test: on a staging cluster, issue a configuration-mutating remoting command from a host holding no RocketMQ credential and confirm it is refused before the value is applied - not merely that the request was logged. Precondition: the vendor releases the packet names, 5.1.1 or above for 5.x and 4.9.6 or above for 4.x, are the remediation it records; this control states the property to verify and the surface to reduce, it does not implement either, and it gives nothing on its own to a cluster still running an affected build.",
+        "evidence": "Packet vector: components 'lack permission verification, an attacker can exploit this vulnerability by using the update configuration function to execute commands as the system users that RocketMQ is running as'; recommended upgrade '5.1.1 or above for using RocketMQ 5.x or 4.9.6 or above for using RocketMQ 4.x'. framework_control_gaps NIST-800-53-CM-7: 'Least functionality is violated when the update-configuration remoting function is reachable unauthenticated; CM-7 does not by default disable/lock down the broker management interface.' framework_control_gaps AU-ISM-1546: 'Access-control guidance for services does not force authentication on the RocketMQ remoting interface, so the missing permission check remains the exploited gap.' cwe_refs CWE-94; active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the control means the RocketMQ upgrade runs on the clock that opened with the 2023-09-06 KEV listing rather than on the cluster's normal release cadence, with the population enumerated from the packet's own version ranges: every 5.x instance at or below 5.1.0 to 5.1.1 or later, and every 4.x instance at or below 4.9.5 to 4.9.6 or later. The priority argument is in the packet rather than in the CVSS band: public exploit code exists, exploitation is confirmed, EPSS is around 0.966, and the DreamBus botnet weaponized this against internet-exposed brokers, which makes an exposed cluster a swept target rather than a targeted one. Two things decide whether the remediation is real. First, the packet registers no live-patch path and states that remediation requires applying the vendor fixed release, so replacing the package is not the completion event - patch_required_reboot being false means no machine reboot is needed, not that a NameServer, Broker or Controller process already running the old build stops executing it; measure completion on the version each running component reports. Second, because exploitation is confirmed and the outcome is command execution as the RocketMQ service user, a component that was reachable from an untrusted network during the exposure window belongs on the incident path: the upgrade removes the injection path but nothing that was already placed on the host through it, and the service account's own credentials and any secrets in the broker's configuration are in scope for rotation.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-09-06; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 70. active_exploitation_notes: 'Actively exploited preauth RCE; the DreamBus botnet weaponized it against internet-exposed RocketMQ brokers... EPSS ~0.966.' affected_versions: 'RocketMQ 5.x <= 5.1.0 (fixed in 5.1.1)', 'RocketMQ 4.x <= 4.9.5 (fixed in 4.9.6)'. 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.' framework_control_gaps ISO-27001-2022-A.8.8: 'Technical-vulnerability management cadence trails an internet-facing preauth RCE with a public Metasploit module and active botnet use.' Command execution occurs 'as the system users that RocketMQ is running as' (vector).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-38831": {
     "name": "RARLAB WinRAR Code Execution Vulnerability",
@@ -59127,7 +60263,40 @@
         "adequate": false,
         "gap": "A.8.22 segregation of networks would have confined the internal-only VCO functions to a trusted management segment; leaving them remotely reachable exposed the unauthenticated command-injection path, which network segregation is specifically meant to prevent."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "VeloCloud Orchestrator is the SD-WAN management plane this control governs, and the defect sits on its network-facing interface: the packet states the exploited functionality was intended for internal use only and not intended to be remotely accessible, yet an unauthenticated attacker with only network reach to the VCO web interface reaches that privileged internal functionality and drives attacker-controlled input into an OS command on the orchestrator host. Bound to this product it means every privileged internal function on VCO makes its own authorization decision before the request is processed at all, and neutralizes the supplied input before it reaches an OS command, so internal-only is a property the endpoint enforces rather than an assumption inherited from where the orchestrator is deployed; and no on-prem VCO is left with that interface reachable from a segment with no operational need to reach it. Because the caller never authenticates as any VCO operator, per-account privilege scoping is never consulted, which is why an access-review attestation over orchestrator accounts passes cleanly while this path stays fully open. Distinguishing test: from a segment with no operational need to reach the orchestrator, send unauthenticated requests at each internal-only function on a staging VCO and confirm each is refused before anything executes. Precondition: the endpoint-side authorization and input handling are what Arista's fixed on-prem builds establish — 5.2.3.14, 6.1.3.4, 6.4.2.4 and 7.0.0.1 per the packet — this control states what to verify, it does not implement it. Until an instance is running one of those builds, restricting which segments can reach the web interface bounds who can send the request and leaves the endpoint fully exploitable to anything inside a permitted segment, and it is unavailable where the interface must stay reachable for edges and operators to work.",
+        "evidence": "Packet vector: VeloCloud Orchestrator (VCO) on-prem has an issue that may allow a remote attacker to access privileged internal functionality and impact the VCO host; this functionality was intended to be for internal use only and is not intended to be remotely accessible; discovered externally and known to be actively exploited. affected: an internal-only privileged function is reachable over the network and passes attacker-controlled input into an OS command (CWE-78). active_exploitation_notes: an unauthenticated attacker with only network reach to the VCO web interface accesses privileged internal functionality and runs OS commands on the orchestrator host. live_patch_notes names the fixed on-prem builds 5.2.3.14, 6.1.3.4, 6.4.2.4 and 7.0.0.1. The NIS2 gap records the internal-only functionality as network-reachable with the management/API plane unsegmented; the ISO-27001-2022-A.8.22 gap records that segregation of networks would have confined the internal-only VCO functions to a trusted management segment; the UK-CAF-B4 gap records the internal-only endpoints as not restricted at the network layer.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "ISO-27001-2022-A.8.22",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the SLA's start condition matters more than its length. The packet records the flaw exploited in the wild as a zero-day before Arista's advisory, so no clock keyed to disclosure was running while it was being exploited, and CISA then listed it 2026-07-27 with a due date of 2026-07-30 — three days. The requirement is that every on-prem VCO is driven to the fixed build for its own branch — 5.2.0 to 5.2.3.14, 6.1.0 to 6.1.3.4, 6.4.0 to 6.4.2.4, 7.0.0 to 7.0.0.1 — on a clock that starts at patch availability rather than at the next change window, with completion measured by the version the running orchestrator reports rather than by an approved change record: the packet registers no live-patch path, so an instance carries the vulnerable code until it is actually running the fixed build. Scope the action to on-prem, which is what the packet's affected field and affected_versions cover; it states Hosted and Dedicated VCO were patched in advance of the notice, so those are not operator action items and sweeping them manufactures work. Until the fixed build lands, removing network reach to the VCO web interface is the compensating control and must be recorded as one rather than as remediation: it bounds who can send the request, does nothing against a caller inside a permitted segment, and cannot evict an attacker who already executed commands on the host during the pre-advisory window.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-07-27, active_exploitation confirmed. active_exploitation_notes: exploited in the wild as a zero-day before Arista's advisory; CISA added it to KEV 2026-07-27 with an unusually short 3-day due date (2026-07-30); Hosted and Dedicated VCO were patched pre-disclosure and on-prem deployments bore the exposure. affected_versions: on-prem 5.2.0 < 5.2.3.14, 6.1.0 < 6.1.3.4, 6.4.0 < 6.4.2.4, 7.0.0 < 7.0.0.1. patch_available true, live_patch_available false; live_patch_notes: no vendor live-patch mechanism, remediation requires upgrading to Arista's fixed on-prem builds. The NIST-800-53-SI-2 gap records that SI-2 assumes a fixed release exists before exploitation and that a monthly remediation window is far wider than the 3-day KEV due date; the AU-Essential-8-Patch gap records the 48-hour internet-facing target being outrun by a zero-day exploited before a patch existed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "VCO is the control plane for a fleet of SD-WAN edges, and the packet states what its compromise costs: OS command execution on the orchestrator host, exposing all managed SD-WAN edge configuration and secrets. Because the flaw was exploited in the wild before Arista's advisory existed, any on-prem orchestrator that was network-reachable during that window has to enter this playbook rather than be closed on the upgrade. For this product the playbook means rotating every credential and key the orchestrator held or issued to managed edges, auditing every configuration pushed to the edge fleet since the start of the exposure window against a known-good baseline, defining in advance the criteria under which a downstream edge is quarantined rather than trusted, and rebuilding the orchestrator host rather than inheriting its state through the upgrade. Reaching 5.2.3.14, 6.1.3.4, 6.4.2.4 or 7.0.0.1 closes the injection path and returns nothing that was already read out of the host: edge configuration and secrets that left the orchestrator stay valid until they are rotated, so an estate that upgrades and stops has a clean flaw-remediation record over a fleet whose secrets the attacker still holds. Precondition: this is response, not prevention — it neither closes the command-injection path nor tells an operator whether a given orchestrator was reached, so the trigger has to be exposure during the pre-advisory window, not confirmation of intrusion.",
+        "evidence": "Packet active_exploitation_notes: exploited in the wild as a zero-day before Arista's advisory; an unauthenticated attacker with only network reach to the VCO web interface accesses privileged internal functionality and runs OS commands on the orchestrator host, exposing all managed SD-WAN edge configuration and secrets. vector: successful exploitation may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator. live_patch_notes names the fixed on-prem builds 5.2.3.14, 6.1.3.4, 6.4.2.4 and 7.0.0.1 with no live-patch mechanism. The UK-CAF-B4 gap records that an unauthenticated OS command injection on the SD-WAN control plane yields full host compromise regardless of endpoint hardening; the NIST-800-53-SI-2 gap records that on-prem VCO hosts were compromised before any patch could be scheduled.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2026-16232": {
     "name": "Check Point SmartConsole Improper Authentication Vulnerability",
@@ -59283,7 +60452,29 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management flags the CVE but its remediation ticket does not capture the machine-key-rotation step this bug requires, so an ISMS marking the patch 'applied' still leaves the forged-token persistence path open."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "CVE-2026-50522 gives a three-day KEV clock against exploitation that began immediately once a working PoC was public, which is the exact mismatch this control is written for. Applied to this farm it means Microsoft's July 2026 security update is driven across every SharePoint Server Subscription Edition, 2019 and 2016 server in the farm on the clock that opened with the 2026-07-22 listing, rather than on the monthly cadence the SI-2 gap describes or the two-week internet-facing application SLA the Essential-Eight gap describes. Completion is measured on the code the servers are actually running after the IIS reset or server reboot the packet records — the fix ships in a farm where the vulnerable SessionSecurityTokenHandler is already mapped into running worker processes, so a server that has installed the update and not restarted is still executing the pre-fix path and must be counted as exposed. The packet records no live-patch mechanism, so there is no vendor-side substitute for that restart. Precondition on the interim leg: restricting who can reach /_trust/default.aspx bounds who can post the forged token, but it is available only where federated sign-in through that endpoint is not in use — where it is, there is no compensating control and the update-plus-restart is the only action. And on this entry the four-hour verdict is not satisfied by the update alone: the packet makes machine-key rotation part of remediation, so a farm recorded as patched but not rotated is not mitigated.",
+        "evidence": "Packet: cisa_kev true, kev_date 2026-07-22, active_exploitation 'confirmed', poc_available true, CVSS 9.8, RWEP 81. active_exploitation_notes: 'Mass exploitation began immediately after a working PoC became public (watchTowr telemetry)... KEV due date was 2026-07-25, three days after listing.' live_patch_notes: 'No live-patch mechanism exists for SharePoint; remediation requires Microsoft's July 2026 security update (an IIS reset / server reboot) AND rotation of the ASP.NET machine keys because exploitation exfiltrates them for persistence.' patch_required_reboot true, live_patch_available false. affected_versions list Subscription Edition, 2019 and 2016 below the July 2026 security update. The NIST-800-53-SI-2 gap states the three-day KEV window and hours-after-PoC exploitation fall 'far inside any monthly-patch cadence for an internet-facing SharePoint farm'; the AU-Essential-8-Patch gap states the two-week internet-facing SLA left the window 'fully exploitable'. attack_vector names the unauthenticated POST to /_trust/default.aspx.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This entry is the case where 'patched' and 'remediated' come apart, and the packet says so directly: exploitation exfiltrates the ASP.NET machine keys and attackers retain forged-token access after the update. Bound to this product the control means an on-premises SharePoint Server Subscription Edition, 2019 or 2016 farm that was network-reachable during the exposure window is handled as a compromised host, with the July 2026 update as the opening step of a response rather than its conclusion: rotate the ASP.NET machine keys across every server in the farm — the credential-rotation leg, which this packet makes mandatory rather than advisory — and treat the farm's configuration and content as attacker-writable, because the deserialization executed as the SharePoint service account. Sequence matters: keys rotated before the update and restart land can be stolen again through the same unpatched pre-authentication path, so the order is update, restart, then rotate. Distinguishing test: after remediation, confirm the machine keys in use differ from those in effect during the exposure window and that a __VIEWSTATE signed with the superseded key is rejected — an ISMS record showing the patch applied proves nothing about the forged-token path. Precondition: rotation evicts that forged-token path and nothing else; it does not remove anything the attacker placed while running as the service account, so a farm with evidence of execution belongs on the incident path rather than being closed on a patch-and-rotate record.",
+        "evidence": "live_patch_notes: 'No live-patch mechanism exists for SharePoint; remediation requires Microsoft's July 2026 security update (an IIS reset / server reboot) AND rotation of the ASP.NET machine keys because exploitation exfiltrates them for persistence.' active_exploitation_notes: 'attackers steal ASP.NET machine keys to retain forged-token access after the patch, so patching alone does not evict them.' attack_vector: unauthenticated POST of a forged WS-Federation SecurityContextToken carrying a BinaryFormatter payload to /_trust/default.aspx, 'yielding remote code execution as the SharePoint service account, followed by machine-key theft for durable persistence.' The NIS2-Art21-patch-management gap states an operator 'who patches but does not rotate the stolen keys remains compromised via forged __VIEWSTATE tokens'; the ISO-27001-2022-A.8.8 gap states the remediation ticket 'does not capture the machine-key-rotation step this bug requires, so an ISMS marking the patch \"applied\" still leaves the forged-token persistence path open.' affected names SharePoint Server on-premises; active_exploitation 'confirmed'.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-32315": {
     "name": "Ignite Realtime Openfire Path Traversal Vulnerability",
@@ -59344,7 +60535,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management depends on the CVE being matched to an inventoried asset; because the vulnerable setup environment shipped in all post-2015 releases and Openfire is frequently uncatalogued, the traversal-to-plugin-RCE path went unassessed until active exploitation forced attention."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Openfire's remediation is a version upgrade — 4.7.5 on the 4.7 branch, 4.6.8 on the 4.6 branch — and the packet's own timeline is why an ordinary Java-application patch cadence never reaches it: mass exploitation began within weeks of the May 2023 disclosure, and CISA's 2023-08-24 KEV listing carried a 2023-09-14 due date while the Kinsing botnet was already using the console to plant plugins. For this product the control means the clock starts at the KEV listing and is measured against a specific fixed version rather than against recency, because the flaw is present in every build from 3.10.0 (April 2015) through 4.7.4 — an operator who confirms only that Openfire is 'reasonably current' can be eight years inside the vulnerable range and still record a pass, and an install on the 4.6 branch is remediated by 4.6.8, not by any 4.7.x check. Where the upgrade cannot be taken inside that window, the packet records an interim mitigation offered by the advisory — restricting the Admin Console — and that is precisely what the control's documented-compensating-control state exists to hold: it must be recorded as an interim state with the upgrade still owed, never as remediation. Precondition on that interim half: restricting who can reach the Admin Console bounds the population able to send the traversal request, it does not repair the traversal, and it does nothing about an instance that was already exploited during the confirmed 2023 wave. Completion is measured on the running service, not the filesystem: live_patch_available is false and the packet's stated remediation is upgrading and restarting the service, so an installation carrying the new files with the service not yet restarted is still executing the vulnerable code.",
+        "evidence": "Packet records cisa_kev true with kev_date 2023-08-24, and active_exploitation_notes stating CISA added it with a 2023-09-14 due date after confirmed mass exploitation of thousands of internet-exposed Openfire consoles within weeks of the May 2023 disclosure, with the Kinsing crypto-mining botnet using the auth bypass to plant plugins. affected_versions is 'Openfire 3.10.0 through 4.7.4 (fixed in 4.7.5 and 4.6.8)'. patch_available true; live_patch_available false; live_patch_notes: 'No vendor live-patch mechanism; remediation is upgrading to Openfire 4.7.5 or 4.6.8 and restarting the service. The advisory also offers an interim mitigation (restricting the Admin Console) for operators who cannot upgrade immediately.' poc_available true; rwep_score 70; cvss 7.5.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Openfire's setup environment is unauthenticated by design, and this CVE is the pages behind that exemption inheriting its verdict: the packet describes an unauthenticated user reaching restricted Admin Console pages reserved for administrative users, on a server that was already configured, by traversing out of the setup URI. Bound to this product, the control means each Admin Console function makes its own authorization decision — an already-configured Openfire refusing every setup-scoped and administrative page to an unauthenticated caller regardless of how the request path was spelled — rather than trusting a URI-prefix exemption to have sorted callers correctly, and it means the console is segmented so an untrusted network caller cannot present that request in the first place. The second half is what the cited system-security gap records as missing: the console's 9090/9091 surface was reachable straight from the internet during the confirmed 2023 wave rather than being confined to a management VLAN. Distinguishing test: from a host with no administrative role against a staging Openfire, request setup-scoped and administrative console pages using URL-encoded traversal in the setup/setup-s URI and confirm each is refused before the page runs, then confirm from a general user VLAN and from an external address that the console does not answer at all. Precondition, and this is where the network half is routinely over-claimed: restricting reachability bounds who can attempt the traversal, it does not close it — anything inside the permitted segment still reaches the flaw, and it is unavailable where the console must stay broadly reachable for administration. The endpoint-side authorization is a property the 4.7.5/4.6.8 upgrade establishes; this control states what to verify, it does not implement it. Because exploitation is confirmed and the attack path ends in an attacker-created admin account and an uploaded plugin JAR, an instance that was exposed during the wave is not closed by the upgrade alone — the account list and installed plugins have to be compared against a known-good baseline, since neither is removed by upgrading.",
+        "evidence": "Packet vector: 'Openfire's administrative console, a web-based application, was found to be vulnerable to a path traversal attack via the setup environment. This permitted an unauthenticated user to use the unauthenticated Openfire Setup Environment in an already configured Openfire environment to access restricted pages in the Openfire Admin Console reserved for administrative users.' attack_vector: 'URL-encoded path traversal in the setup/setup-s URI lets an unauthenticated attacker reach setup-only Admin Console pages on an already-configured Openfire, create an admin account, and upload a malicious plugin JAR for OS command execution.' The UK-CAF-B4 gap states hardening 'rarely restricts the Openfire Admin Console (9090/9091) to a management VLAN, so the unauthenticated setup-page traversal was reachable straight from the internet during the confirmed 2023 exploitation wave'. active_exploitation confirmed; poc_available true; fixed in 4.7.5 and 4.6.8.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-38035": {
     "name": "Ivanti Sentry Authentication Bypass Vulnerability",
@@ -59592,7 +60806,40 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management typically drives a risk-rated patch schedule; the CVSS 9.8, EPSS ~0.18 preauth deserialization vector plus a shipped Metasploit module means anything short of emergency out-of-band patching left the ColdFusion server exploitable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the clock opens at the 2023-08-21 KEV listing and the only qualifying mitigation the packet records is the upgrade to ColdFusion 2018 Update 16 or 2021 Update 6 (or later) followed by a restart of the ColdFusion service. patch_required_reboot is false, which means no machine reboot — it does not mean the fix is live on install: the running ColdFusion process keeps executing the pre-fix WDDX handler until it restarts, so completion is measured per instance on the version the running service reports, never on 'update applied' in a change record. Scope from affected_versions rather than from a single headline install: every ColdFusion 2018 at or below Update 15 and every ColdFusion 2021 at or below Update 5, both trains, including instances behind load balancers and any non-production instance that is internet-reachable — the packet's exploitation population is internet-facing ColdFusion servers, not a curated production list. live_patch_available is false and the packet records no vendor mitigation rule or configuration workaround, so there is no interim state to log as a compensating control: an instance that cannot take the update and restart inside the window is a dated, accepted exposure carrying an unauthenticated code-execution path, and must be recorded that way. Priority follows the packet rather than a queue position: CVSS 9.8, poc_available true, confirmed exploitation, and a Metasploit module that lowered the bar to mass exploitation.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2023-08-21; active_exploitation 'confirmed'; cvss 9.8; rwep_score 72; poc_available true; patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires upgrading to ColdFusion 2018 Update 16 or 2021 Update 6 (or later) and restarting the ColdFusion service.'; affected_versions 'Adobe ColdFusion 2018 <= Update 15' and 'Adobe ColdFusion 2021 <= Update 5'; active_exploitation_notes 'a Metasploit module lowered the bar to mass exploitation of internet-facing ColdFusion servers'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The packet places the defect in ColdFusion's WDDX packet handler, which deserializes untrusted data without validating the incoming class contents, reached by an unauthenticated request that needs no user interaction and ending in code execution as the ColdFusion service account. Bound to this product, the control means the WDDX intake is treated as a trust boundary rather than as an internal convenience inherited from the web tier in front of it: what an arriving packet is permitted to construct or evaluate is constrained to an explicit set of expected types, instead of the handler instantiating whatever class the packet names and letting a gadget chain assemble itself. Distinguishing test for this product: from an unauthenticated client, send a WDDX packet naming a gadget class to a staging ColdFusion instance and confirm it is refused before the object graph is constructed — an instance that passes a patch-level attestation is exposed again the moment the next deserialization defect in the same handler lands, because nothing in the estate constrains what the handler will build. Precondition, and this is where the control is most easily over-claimed: restricting which networks can reach the ColdFusion endpoints bounds who can send the packet, but it does not repair the handler, and for the internet-facing servers the packet describes as mass-exploited there is no segment that removes the path at all — the site exists to answer untrusted requests. The packet records no vendor switch that disables WDDX intake, so this is the property to require and verify of the deployed build, not something an operator can toggle today; the upgrade to Update 16 / Update 6 with the service restart is what removes the current instance of the sink.",
+        "evidence": "Packet fields: cwe_refs CWE-502; affected 'Adobe ColdFusion application server, whose WDDX packet handler deserializes untrusted data without validating the incoming class contents, enabling arbitrary code execution as the current ColdFusion user'; attack_vector 'An unauthenticated attacker sends a crafted WDDX packet to a ColdFusion endpoint; ColdFusion deserializes it without validating the incoming class contents, allowing a gadget chain to execute arbitrary code as the ColdFusion service account'; vector 'Exploitation of this issue does not require user interaction'; UK-CAF-B4 gap 'ColdFusion accepts and deserializes attacker-supplied WDDX packets by design on a network-facing port; hardening guides rarely remove that endpoint, leaving the deserialization sink live until the Update 16 / Update 6 patch is applied'; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This entry is the internet-facing application-server form of the case the control exists for, and both trigger conditions the control names are packet facts: the code execution is reachable pre-auth, and exploitation is confirmed, with attackers using it to drop web shells on internet-facing ColdFusion servers. The requirement that follows is that a ColdFusion instance which was reachable and unpatched during the exposure window is handled as a compromise rather than as a patch item — the upgrade to Update 16 / Update 6 closes the WDDX path but removes nothing an attacker already wrote through it, and a web shell placed in the web root or an application directory survives the update and the service restart intact. For this product that means comparing the deployed application and ColdFusion directories against a known-good build rather than trusting the upgrade to normalise them, treating any credential the ColdFusion service account holds — datasource credentials, keys and tokens readable by that account — as exposed and rotating them, and preserving the instance's evidence before rebuilding. Precondition and limit: this applies to instances the operator can establish were reachable while below Update 16 / Update 6, and 'no alert fired' is not that establishment — the packet gives a Metasploit-driven mass-exploitation population and no detection claim, so absence of a finding is not absence of exploitation. It is also not a substitute for the upgrade: a rebuilt instance restored to a pre-fix version is exploitable again on first exposure, so the rebuild and the upgrade are both required, in that order.",
+        "evidence": "Packet fields: active_exploitation 'confirmed'; active_exploitation_notes 'Attackers use it for unauthenticated RCE to drop web shells; a Metasploit module lowered the bar to mass exploitation of internet-facing ColdFusion servers'; attack_vector describes an unauthenticated attacker achieving arbitrary code execution 'as the ColdFusion service account'; poc_available true; cisa_kev true, kev_date 2023-08-21; patch_available true with live_patch_available false and live_patch_notes requiring the Update 16 / Update 6 upgrade plus a ColdFusion service restart.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-24489": {
     "name": "Citrix Content Collaboration ShareFile Improper Access Control Vulnerability",
@@ -59815,7 +61062,31 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management cannot enumerate or remediate CPE outside the organization's asset inventory, so the 9.8-rated CWE-78 sink on these subscriber routers is invisible to the vulnerability-management process."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet carries both halves this control resolves per unit: patch_available is true with patch_required_reboot true and no live-patch path, while live_patch_notes states that for end-of-life units no delivery channel exists. So the first requirement is an inventory naming every ZyXEL P660HN-T1A v1 in service, recording for each its running firmware and whether a fixed or hotfix image is actually deliverable to it, with that status obtained from the vendor or from TrueOnline as the distributing ISP rather than assumed in either direction. Scope it to what the packet names — the P660HN-T1A v1 on TCLinux Fw $7.3.15.0 v001 / 3.40(ULM.0)b31, TrueOnline distribution — not to ZyXEL DSL gear generally, which would manufacture replacement work against hardware no evidence implicates. Units that can take the fixed image are remediation items on the clock that opened with the 2023-08-07 KEV listing and its 2023-08-28 due date, and because the fix is a firmware flash with no live-patch path, a unit that has been given an image but not restarted onto it is still executing the ViewLog.asp code and counts as exposed. Units with no delivery channel cannot be patched at all and are replacement items needing a dated schedule; a risk acceptance with no removal date leaves an unauthenticated 9.8 command-injection sink with a public PoC in service indefinitely. Precondition on the reachability half, which is where this control is most often over-claimed: blocking the router's HTTP administration surface from the WAN bounds who can reach /ViewLog.asp from the internet, but on ISP-provisioned CPE that lever usually belongs to TrueOnline rather than to the subscribing organisation, and every client on the network the gateway serves still reaches that page — 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 in-the-wild botnet exploitation is confirmed and the injection runs commands on the router itself, a unit that was exposed is not remediated by the flash alone: its configuration and administrative credential must be rebuilt from a known-good baseline rather than inherited across the update, and credentials that transited it rotated.",
+        "evidence": "Packet: unauthenticated CWE-78 injection in the ViewLog.asp Remote System Log forwarding function's remote_host parameter on the ZyXEL P660HN-T1A v1 (TCLinux Fw $7.3.15.0 v001 / 3.40(ULM.0)b31), TrueOnline distribution; CVSS 9.8, RWEP 75, poc_available true; CISA KEV added 2023-08-07 with a 2023-08-28 remediation due date; active_exploitation confirmed, the notes recording in-the-wild recruitment of these ISP-distributed home gateways by Mirai/Gafgyt-family IoT botnets and EPSS ~0.945. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes stating that remediation requires flashing fixed/hotfix firmware (a device reboot) and that for end-of-life units no delivery channel exists. The ISO-27001-2022-A.8.8 gap records that the CPE sits outside the organisation's asset inventory; the NIS2-Art21-patch-management gap records that the obligation does not reach ISP-owned customer-premises equipment the reporting entity does not administer.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this fleet the three verdict states are not a bookkeeping distinction — the packet puts different P660HN-T1A units in different ones simultaneously. A unit flashed and restarted onto fixed firmware is state (a). A unit with no deliverable image, where the only thing between the internet and the ViewLog.asp remote_host sink is a WAN-side block on the router's HTTP administration surface, is state (b) and has to be recorded as an active compensating control carrying a dated action — replacement of the unit — rather than folded into a 'patched per SLA' line. A unit with neither is state (c): full exposure to an unauthenticated command injection with a public PoC and confirmed botnet exploitation. This matters here rather than being an audit formality because the packet's own gaps describe precisely that failure — a flaw-remediation process that assumes a managed patch pipeline and a patch window that is unenforceable when the device has no update channel, with the sink staying exploitable for years past the 2023-08-07 KEV listing. A fleet-level 'firmware current' percentage that averages states (a) and (c) together is how that record stays clean. Precondition on the state-(b) mitigation, and it is a real one: the WAN-side block bounds internet-origin requests only. It does not repair the unsanitised remote_host parameter, it leaves every host on the LAN the gateway serves able to reach /ViewLog.asp, on TrueOnline-provisioned CPE it is administered by the ISP rather than by the subscriber, and it does nothing about a gateway already conscripted before the block went on.",
+        "evidence": "Packet: patch_available true, but live_patch_notes gives remediation as flashing fixed/hotfix firmware with a device reboot, live_patch_available false, and states that for end-of-life units no delivery channel exists. The NIST-800-53-SI-2 gap states that flaw remediation assumes a managed patch pipeline the ISP-provisioned units do not have, so the unauthenticated CWE-78 remote_host sink stayed exploitable for years past the 2023-08-07 KEV listing and kept feeding botnet recruitment; the AU-Essential-8-Patch gap states the 48-hour internet-facing patch window is unenforceable when the device has no update channel. CVSS 9.8, RWEP 75, poc_available true, active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-35081": {
     "name": "Ivanti Endpoint Manager Mobile (EPMM) Path Traversal Vulnerability",
@@ -59876,7 +61147,40 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would have flagged EPMM for patching only after the 2023-07-28 advisory, whereas the arbitrary file write was already being chained in the wild; the control's disclosure-driven cadence trails the actual exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Ivanti EPMM (formerly MobileIron Core) is the device-management appliance this control governs, and the defect sits on its file-handling endpoint: the packet's vector has an authenticated administrator writing arbitrary files onto the appliance through an unsanitized path traversal, and the attack path ends with a JSP web shell planted on the appliance filesystem. Bound to this product, the control means the EPMM administrative file-write endpoint authorizes its caller before the upload is processed at all, and normalizes and validates the destination path before the write executes, so a caller-supplied name cannot select which file gets written or where it lands. The authorization half is the load-bearing one here, and it is the reason the appliance's own account model gives no protection: the packet records this chained behind CVE-2023-35078, an authentication bypass, so the attacker never holds an EPMM administrator account, the per-account privilege model is never consulted, and an attestation that every EPMM administrator authenticates at login passes cleanly while the file-write path stays open. Distinguishing test: on a staging EPMM, send the administrative file-write endpoint a request whose destination path resolves outside the intended directory — once unauthenticated and once as a low-privilege operator — and confirm both are refused before anything is written to disk. Precondition, and this is where the control is most often over-claimed: path sanitization is a property the vendor builds establish, not something this control implements. Until 11.10.0.3 / 11.9.1.2 / 11.8.1.2 is running, restricting which segments can reach the administrative interface bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable wherever that interface must stay reachable for normal administration. The packet records no live-patch path and an upgrade that restarts the appliance services, so an appliance that has taken the build but not restarted onto it is still executing the vulnerable handler and counts as exposed.",
+        "evidence": "Packet fields for CVE-2023-35081: CWE-22; vector states a path traversal in Ivanti EPMM 11.10.x < 11.10.0.3, 11.9.x < 11.9.1.2, 11.8.x < 11.8.1.2 allows an authenticated administrator to write arbitrary files onto the appliance; affected describes the authenticated-admin file-write handler failing to sanitize path traversal; attack_vector records the file write chained behind the CVE-2023-35078 auth bypass to let an unauthenticated attacker plant a JSP web shell and execute code on the MDM appliance; poc_available true; patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes recording that the upgrade to 11.10.0.3 / 11.9.1.2 / 11.8.1.2 restarts the appliance services; cisa_kev true, kev_date 2023-07-31; active_exploitation confirmed; rwep_score 73, cvss 7.2.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For EPMM this control decides what the word 'remediated' is allowed to mean. The packet records confirmed zero-day exploitation of the CVE-2023-35078 + CVE-2023-35081 chain against internet-facing EPMM appliances, including a compromise of a Norwegian government platform, and a CISA/NCSC-NO advisory (AA23-213A, 2023-08-01) documenting web-shell deployment; the attack path plants a JSP web shell on the appliance. Upgrading to 11.10.0.3 / 11.9.1.2 / 11.8.1.2 closes the traversal but removes nothing already written through it — a JSP file dropped into the appliance before the upgrade survives the upgrade, and anything the appliance held while an attacker had code execution on it (administrative credentials, API keys, certificates, enrolment secrets) must be treated as read. So an EPMM that was reachable and below the fixed build during the exposure window is an incident item before it is a patch item: capture configuration and logs off the box first, rebuild the appliance from vendor media at the fixed build rather than upgrading in place, and rotate every credential the appliance held or that authenticated through it. The exposure window has to be dated from before the vendor advisory, not from it — the packet records this as exploited as a zero-day, with Ivanti shipping the fix on 2023-07-28 and KEV listing following on 2023-07-31, so an appliance that was internet-reachable in the weeks prior is in scope even though no advisory existed to act on. Precondition: rebuild-not-patch only produces a clean appliance if the restored configuration is itself reviewed rather than exported wholesale from the compromised instance, since an attacker with code execution could have modified it; and it does nothing for what already left the appliance, which is why the credential rotation half is not optional.",
+        "evidence": "Packet fields for CVE-2023-35081: active_exploitation confirmed with active_exploitation_notes stating it was exploited as a zero-day, chained with CVE-2023-35078 to gain unauthenticated RCE on Ivanti EPMM (MobileIron Core) appliances, including a compromise of a Norwegian government platform, with CISA/NCSC-NO advisory AA23-213A issued 2023-08-01 documenting web-shell deployment and Ivanti shipping the fix 2023-07-28; attack_vector records a JSP web shell planted on the MDM appliance; cisa_kev true, kev_date 2023-07-31; poc_available true; rwep_score 73; patch_available true with fixed builds 11.10.0.3 / 11.9.1.2 / 11.8.1.2, live_patch_available false.",
+        "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": "EPMM is the control plane for an organization's mobile estate, so code execution on it is not a single-appliance incident — it is authority over every enrolled device. The packet's exploitation record makes that concrete: a chained zero-day yielding RCE on the MDM appliance, a web shell deployed per AA23-213A, and a government platform compromised. The playbook this CVE demands is therefore fleet-wide and has to be written before it is needed: revoke and re-issue any certificate the compromised EPMM issued or pushed, invalidate device trust state so an enrolled handset must re-establish it, audit every configuration profile and policy pushed since the start of the exposure window against a known-good baseline, define the criteria under which an enrolled device is quarantined rather than trusted, and rotate credentials for any account that authenticated through the appliance during that window. Sequencing matters on this CVE specifically: the appliance must be rebuilt to the fixed build first, because pushing revocations and fresh profiles from an appliance an attacker still controls hands the attacker the new material. Precondition: this is damage-bounding, not closure — it does not remove the traversal, which needs the 11.10.0.3 / 11.9.1.2 / 11.8.1.2 build and the appliance-service restart the packet records. It is also only executable against records held off the appliance: an attacker with code execution on EPMM can edit what the appliance's own profile-push and enrolment history say, so the audit needs an external copy of that history or it audits the attacker's version of events.",
+        "evidence": "Packet fields for CVE-2023-35081: affected identifies Ivanti Endpoint Manager Mobile (EPMM, formerly MobileIron Core) — a mobile device management appliance; attack_vector records an unauthenticated attacker planting a JSP web shell and executing code on the MDM appliance when the file write is chained behind CVE-2023-35078; active_exploitation_notes record confirmed zero-day exploitation, a compromise of a Norwegian government platform, and CISA/NCSC-NO advisory AA23-213A (2023-08-01) documenting web-shell deployment; patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes recording the upgrade to 11.10.0.3 / 11.9.1.2 / 11.8.1.2 restarting the appliance services; cisa_kev true, kev_date 2023-07-31.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-37580": {
     "name": "Synacor Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Vulnerability (CVE-2023-37580)",
@@ -60480,7 +61784,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management assumes vendor patches map cleanly to versions, but SolarView's non-linear fix history (6.00 vulnerable, 6.20/7.00 still vulnerable, 8.00 fixed) means a naive 'is it updated?' check passed for devices that remained exploitable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "SolarView Compact is this control's case stated in the packet's own words. The fix lands only in firmware 8.00, and the packet states explicitly that the intermediate 6.20 and 7.00 releases do not fix conf_mail.php — so any check asking 'is this appliance newer than the vulnerable 6.00?' returns a pass for a device whose mail-test handler still passes web-form input straight to a shell, unauthenticated. The operational test for this product is therefore two-part: does the inventory record each SolarView Compact's exact firmware string and compare it against 8.00-or-later specifically rather than against later-than-6.00; and does it confirm the appliance has actually been restarted onto that firmware, since the packet records a firmware upgrade that reboots the device and no live-patch path, so a unit that has taken the image but not restarted is still running the injectable handler. Scope this to the SolarView Compact appliances the packet names — it ties the CWE-78 sink to that product's conf_mail.php and gives no mapping into other Contec products or other photovoltaic-monitoring equipment, so sweeping every PV or OT appliance in the estate as an instance of this CVE manufactures findings against devices no evidence implicates. The failure this exposes is concrete: an estate that ran a fleet-wide firmware refresh to 6.20 or 7.00 and closed the ticket presents a clean vulnerability-management record while every one of those units remains exploitable pre-authentication by the same scanner traffic that has been reaching them since March 2023.",
+        "evidence": "Packet: CWE-78 command injection via conf_mail.php on the Contec SolarView Compact photovoltaic-monitoring appliance, unauthenticated; CVSS 9.8, RWEP 73, poc_available true; CISA KEV added 2023-07-13, due 2023-08-03. affected_versions records 'SolarView Compact ver.6.00 and earlier (fixed in firmware 8.00; 6.20 and 7.00 remain vulnerable)', and live_patch_notes states remediation is a firmware upgrade to 8.00 or later which reboots the device, live_patch_available false, and that intermediate 6.20/7.00 firmware does not fix the command injection. The NIST-800-53-SI-2 gap states an operator who 'updated' still ran the injectable endpoint; the ISO-27001-2022-A.8.8 gap states a naive 'is it updated?' check passed for devices that remained exploitable. active_exploitation confirmed, with Unit 42 observing a Mirai-variant botnet weaponising conf_mail.php from around 2023-03-15.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's gaps say the standard patch programs do not reach this appliance at all — Essential Eight targets enterprise operating systems and applications rather than embedded ICS firmware, and NIS2 patch management rarely covers solar-monitoring gear — so the requirement this control places on a KEV listing is the one that carries here: mitigation is a verified patch OR a documented compensating control, and the clock runs from the listing rather than from whenever the site's next maintenance visit is scheduled. For SolarView Compact the patch branch is the firmware upgrade to 8.00 or later with the device restart it requires; the compensating branch available from the day of the 2023-07-13 listing is removing the appliance's web server from direct internet reachability, since the exploited request is an unauthenticated HTTP request to conf_mail.php and reachability is the entire precondition for the Mirai-variant scanning the packet records. State the precondition rather than claiming the surface is removed: restricting reachability bounds who can send the request, it does not repair the handler. Any host that legitimately reaches the appliance — the installer's or O&M provider's remote-monitoring path, a site jump host, anything on the same plant network — still triggers the injection with no credential, and where the monitoring appliance must stay reachable by a third party for its operational purpose the compensating branch is simply unavailable and only the firmware jump closes it. Neither branch cleans a unit already carrying a bot payload dropped before the mitigation went on.",
+        "evidence": "Packet: CISA added this to KEV on 2023-07-13 with a 2023-08-03 due date; active_exploitation confirmed, with Palo Alto Unit 42 observing a Mirai-variant botnet weaponising conf_mail.php from around 2023-03-15 and VulnCheck reporting that the majority of internet-facing SolarView systems remained unpatched. Unauthenticated CWE-78, CVSS 9.8, RWEP 73, poc_available true. patch_available true with patch_required_reboot true and live_patch_available false; live_patch_notes gives remediation as a firmware upgrade to SolarView Compact 8.00 or later, which reboots the device. The AU-Essential-8-Patch gap states the fix fell outside any standard patch program so the pre-auth RCE was not remediated within the KEV window; the NIS2-Art21-patch-management gap states the flaw stayed live on internet-facing units well past the 2023-08-03 due date; the UK-CAF-B4 gap states hardening for OT/monitoring gear seldom removes the SolarView web server's direct internet exposure.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-37450": {
     "name": "Apple Multiple Products WebKit Code Execution Vulnerability (CVE-2023-37450)",
@@ -60975,7 +62302,40 @@
         "adequate": false,
         "gap": "A.8.22 network segregation should isolate the 9004/TCP Remoting service to a management enclave, but flat internal networks leave it reachable from workstation subnets, giving Truebot operators an unauthenticated path to SYSTEM on the audit server."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "The Netwrix Auditor User Activity Video Recording component is the case this control governs exactly: a non-HTTP protocol endpoint - .NET Remoting on TCP/9004 - that answers before authentication and whose deserialization of the incoming object stream is itself the vulnerable code, so the perimeter controls and the web-tier hardening an audit platform is normally assessed against never touch it. Bound to this product, the requirement is that the Remoting listener answers only from a management enclave, enforced by host firewall or network ACL rather than assumed from the fact that the Auditor server sits inside the corporate network, and that the content arriving on that port is not permitted to construct arbitrary object graphs. Scope the enclave rule to where the component actually runs: the packet places these flaws in both the Netwrix Auditor server and the agents installed on monitored systems, so a rule written only around the server leaves the monitored-endpoint population carrying the same sink. Distinguishing test for this product: from a general workstation VLAN on a staging deployment, connect to 9004/TCP on the Auditor server and confirm the peer is rejected before any object is deserialized - a deployment that passes its Auditor role-and-permission review while 9004/TCP answers from any internal subnet is still exposed to the unauthenticated object path. Preconditions, both real: segmentation bounds who can reach the sink but does not repair the deserialization, so any host inside the permitted enclave still reaches it in full, and the packet's own attribution has Truebot using this for initial access - an operator working from an already-compromised workstation inside the enclave satisfies the access requirement completely. The safe-content half is a property of the vendor release rather than of the network, and the packet records that release as Auditor 10.5 or later with the affected services restarted.",
+        "evidence": "Packet affected: 'Netwrix Auditor User Activity Video Recording component, whose underlying .NET Remoting protocol on TCP/9004 insecurely deserializes untrusted objects.' vector: 'Remote code execution vulnerabilities exist in the Netwrix Auditor User Activity Video Recording component affecting both the Netwrix Auditor server and agents installed on monitored systems... potentially allow an unauthenticated remote attacker to execute arbitrary code as the NT AUTHORITY\\SYSTEM user.' attack_vector: 'An unauthenticated attacker who can reach TCP/9004 sends a malicious serialized object to the Netwrix Auditor .NET Remoting service; deserialization triggers a gadget chain that runs arbitrary code as NT AUTHORITY\\SYSTEM.' framework_control_gaps ISO-27001-2022-A.8.22: 'A.8.22 network segregation should isolate the 9004/TCP Remoting service to a management enclave, but flat internal networks leave it reachable from workstation subnets, giving Truebot operators an unauthenticated path to SYSTEM on the audit server.' framework_control_gaps UK-CAF-B4: hardening 'seldom flags the Auditor's 9004/TCP Remoting listener as an exposed service... the baseline treats a critical preauth RCE sink as benign infrastructure.' cwe_refs CWE-502; active_exploitation confirmed; live_patch_notes: 'remediation requires upgrading to Netwrix Auditor 10.5 (or later) and restarting the affected services.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.22",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the control's value is which event starts the clock. The packet records the fix - Netwrix Auditor 10.5 - as having shipped in 2022 while the unauthenticated 9004/TCP path was still being exploited by Truebot into 2023, so the availability of a patch was never the constraint; the prioritization was. The requirement is that the 2023-07-11 KEV listing, with its 2023-08-01 due date, sets the remediation deadline for every Auditor instance below 10.5, irrespective of the internal-versus-internet-facing placement that the entry's patch-cadence gaps say drives the estate's urgency scoring. Completion is measured against the packet's remediation statement rather than against the reboot flag: there is no live-patch mechanism, remediation is an upgrade to 10.5 or later with the affected services restarted, and patch_required_reboot being false means only that no machine reboot is required - an Auditor service still running the pre-10.5 build after the installer completes is still exploitable. Enumerate the population the packet defines, which includes the agents installed on monitored systems and not only the Auditor server. And treat this as a foothold rather than an endpoint finding: the packet has confirmed in-the-wild exploitation attributed to Truebot for initial access, ransomware use listed as Known, and SYSTEM on a server that monitors Active Directory - an instance that was reachable during the exposure window needs forensic triage and rotation of the credentials that server held, because the upgrade closes the path and removes nothing an operator established through it.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-07-11; active_exploitation 'confirmed'; poc_available true; CVSS 9.8; RWEP 70. active_exploitation_notes: 'CISA/FBI/CCCS joint advisory AA23-187A (2023-07-06) attributes exploitation to the Truebot malware campaign for initial access, and CISA lists ransomware use as Known. Added to KEV 2023-07-11 with a 2023-08-01 due date... yields SYSTEM on a server that already monitors Active Directory, so a hit cascades to domain compromise.' affected_versions: 'Netwrix Auditor < 10.5'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires upgrading to Netwrix Auditor 10.5 (or later) and restarting the affected services.' framework_control_gaps NIST-800-53-SI-2: 'the fix (Auditor 10.5) shipped in 2022 but the unauthenticated 9004/TCP deserialization was still being exploited by Truebot into 2023'; NIS2-Art21-patch-management: 'timelines rarely prioritize an internal audit appliance'; AU-Essential-8-Patch: 'patch prioritization keys off internet-facing exposure, but Netwrix Auditor is typically an internal management server'. vector: flaws affect 'both the Netwrix Auditor server and agents installed on monitored systems'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "Netwrix Auditor is software the estate deploys to watch itself, and this entry is that product being the attack surface rather than the observer: a component of it deserializes an unauthenticated peer's object stream into NT AUTHORITY\\SYSTEM. What the control requires here is enrollment rather than hygiene, because the packet's own gaps show the product excluded before any SLA is applied - patch urgency keys off internet-facing exposure and this is an internal management server, so a preauth SYSTEM sink is scored below the threshold, and the hardening baseline reads its listener as benign infrastructure. Concretely: the Auditor server and the agents it installs on monitored systems belong in the vulnerability-management inventory at the same tier as other privileged software, each with a per-host installed-version record, and its listening surface is in scope for assessment rather than treated as part of the monitoring fabric. Distinguishing test: produce the installed Auditor version for the server and for every monitored endpoint carrying an agent, and show each is at or above 10.5 - an estate whose patch reporting covers the servers in its internet-facing inventory reads clean while agents on monitored systems keep the vulnerable component, which is precisely the population the packet's vector names and a server-scoped report cannot see. Precondition: this is inventory and enrollment only. It prescribes no code change, does not narrow reachability of the Remoting port, and gives nothing on its own to a deployment that has not yet reached 10.5 with the affected services restarted; its function is to stop the product being exempted from the program that would have driven that upgrade.",
+        "evidence": "Packet vector: the flaws affect 'both the Netwrix Auditor server and agents installed on monitored systems' and allow code execution 'as the NT AUTHORITY\\SYSTEM user on affected systems, including on systems Netwrix Auditor monitors.' framework_control_gaps AU-Essential-8-Patch: 'Essential 8 patch prioritization keys off internet-facing exposure, but Netwrix Auditor is typically an internal management server, so the SYSTEM-level deserialization sink falls below the patch-urgency threshold despite active Truebot exploitation.' framework_control_gaps UK-CAF-B4: 'CAF B4 system-security hardening seldom flags the Auditor's 9004/TCP Remoting listener as an exposed service, but it deserializes untrusted input with no auth, so the baseline treats a critical preauth RCE sink as benign infrastructure.' affected_versions 'Netwrix Auditor < 10.5'; live_patch_notes: 'remediation requires upgrading to Netwrix Auditor 10.5 (or later) and restarting the affected services.' active_exploitation confirmed; cisa_kev true (2023-07-11).",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-29256": {
     "name": "Arm Mali GPU Kernel Driver Use-After-Free Vulnerability (CVE-2021-29256)",
@@ -61036,14 +62396,37 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management cannot remediate a GPU kernel-driver UAF on managed handsets when the fixed driver revision is unavailable for the device model, so the control records a known-exploited flaw it has no path to close."
       }
-    }
-  },
-  "CVE-2019-17621": {
-    "name": "D-Link DIR-859 Router Command Execution Vulnerability",
-    "lesson_date": "2026-07-29",
-    "ai_discovered_zeroday": false,
-    "ai_discovery_source": "human_researcher",
-    "ai_discovery_date": "2023-06-29",
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "For the Arm Mali GPU kernel driver the fixed level is a driver revision delivered as an OEM/carrier OS or firmware update, and it is NOT one number across the fleet — reading it as one is how this control readmits a vulnerable handset. The packet gives the affected ranges per architecture: Bifrost r16p0 through r29p0 and Valhall r19p0 through r29p0 are recorded as before r30p0, so r30p0 or later passes on those; Midgard is recorded as r28p0 through r30p0, so r30p0 is still affected there and a Midgard device at that revision must not be admitted. The packet names no fixed revision for Midgard, so that threshold has to be obtained from Arm or the OEM for the model in question rather than inferred from the other two architectures — and until it is, a Midgard handset has no verified pass condition. The access condition therefore keys on the pair (architecture, driver revision), never on the revision alone, and the reason this control's access-condition half is the load-bearing one is that every other lever the operator holds sits above the boundary that fails. The packet has an unprivileged local process reaching freed kernel memory and escalating to root, so the app sandbox is not a boundary and on-device privilege scoping is not being violated — it is being bypassed; and as the CAF gap states, MDM policy cannot patch a kernel driver. What MDM can do is withhold the data: a handset whose Mali driver is below the fixed revision for its architecture is denied mail, VPN and document access until it is at or above it, so the revision functions as an access condition rather than as a row on a compliance dashboard. Because the packet records that the r30p0 driver lags by months or never arrives for many Android device models, the status is a per-model question and must be obtained from the OEM rather than assumed in either direction — models for which an OEM build carrying the fix does exist are remediation items on the clock that opened with the 2023-07-07 KEV listing, and models for which the operator cannot obtain one have no patch path at all and need a decision about whether they hold organizational data. Distinguishing test: enrol a handset on a driver revision below the fix and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale revision on a report while the device keeps its mail and VPN has recorded the exposure rather than removed it. Precondition: patch_required_reboot is true and there is no live-patch mechanism, so a handset that has taken an OS/firmware update but not rebooted is still executing the vulnerable driver and must count as exposed. And an access condition does not evict spyware already resident — this is a local escalation reached from an app already on the device, so a handset suspected of having run the chain belongs on the incident path, not the policy path.",
+        "evidence": "The packet records the Arm Mali GPU kernel driver allowing an unprivileged user access to freed memory, leading to information disclosure or root privilege escalation, with CISA KEV listing on 2023-07-07, active_exploitation confirmed, CVSS 8.8, RWEP 51, and poc_available false with no public PoC for this specific CVE confirmed; active_exploitation_notes records this class of Mali use-after-free being weaponized by commercial/mercenary spyware to escalate from a sandboxed app to root on Android devices. patch_available is true, patch_required_reboot is true, live_patch_available is false, and live_patch_notes states there is no live-patch mechanism for the Mali GPU kernel driver and that the fix ships in driver revision r30p0 requiring an OS/firmware update and device reboot. The cited NIST 800-53 AC-6 gap states least privilege assumes an unprivileged app cannot cross into kernel context while this flaw defeats the app-sandbox privilege boundary; the UK CAF B4 gap states MDM policy cannot patch a kernel driver; the NIS2 Art.21 gap states the fix depends on the OEM/carrier shipping the r30p0 driver, which for many Android devices lags the 2023-07-07 KEV date by months or never arrives. affected_versions records the ranges per architecture — 'Arm Mali Bifrost driver r16p0 through r29p0 (before r30p0)', 'Arm Mali Valhall driver r19p0 through r29p0 (before r30p0)' and 'Arm Mali Midgard driver r28p0 through r30p0' — so r30p0 is the fixed level on Bifrost and Valhall and is itself an affected revision on Midgard, for which no fixed revision is given.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The version identity that decides this CVE is a GPU driver revision, and it does not appear anywhere in the Android version or security-patch-level string a fleet-compliance report reads. The packet expresses the affected range per Mali architecture — Bifrost r16p0 through r29p0, Valhall r19p0 through r29p0, Midgard r28p0 through r30p0 — so a handset marked compliant because its security patch level is current has not been evaluated against this CVE at all; the report answers a different question and returns a pass. Applied here the control means the check resolves, per device, which Mali architecture the SoC carries and what driver revision the running kernel reports, compares that against the fixed revision for that architecture, and records a device that cannot report its driver revision as unverified rather than as passing — for a KEV-listed local root escalation those are not the same verdict. The per-architecture read matters and is the specific trap in this packet: the ranges given for Bifrost and Valhall stop before r30p0 while the range given for Midgard runs through r30p0, so a blanket 'at or above r30p0' rule applied across all three is not supported by the packet, and the fixed revision for Midgard has to be confirmed against the vendor advisory rather than generalized from the other two. Distinguishing test: take a handset the fleet report already marks compliant, read the Mali driver revision the kernel actually reports, and confirm it is at or above the fixed revision for its architecture. Precondition: this is a verification control — it changes what the estate knows, not what the device runs. It gives nothing on a model for which no OEM build carrying the fix exists, and it cannot close the gap on its own, since patch_required_reboot is true and a handset that has not rebooted onto the updated driver is still executing the vulnerable code however the inventory reads.",
+        "evidence": "The packet's affected_versions record Arm Mali Bifrost driver r16p0 through r29p0 (before r30p0), Valhall r19p0 through r29p0 (before r30p0), and Midgard r28p0 through r30p0, while live_patch_notes states the fix ships in driver revision r30p0 and requires an OS/firmware update and device reboot; patch_required_reboot is true and live_patch_available is false. The cited ISO/IEC 27001:2022 A.8.8 gap states technical-vulnerability management cannot remediate this on managed handsets when the fixed driver revision is unavailable for the device model, so the control records a known-exploited flaw it has no path to close. The Essential Eight gap states Arm Mali fixes flow through a fragmented Android OEM supply chain, so the r30p0 driver often cannot be applied within the mitigation's window even after the 2023-07-07 KEV listing.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
+  },
+  "CVE-2019-17621": {
+    "name": "D-Link DIR-859 Router Command Execution Vulnerability",
+    "lesson_date": "2026-07-29",
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_discovery_date": "2023-06-29",
     "ai_assist_factor": "none",
     "attack_vector": {
       "description": "An unauthenticated HTTP SUBSCRIBE request to the UPnP /gena.cgi endpoint injects shell commands via a crafted Callback header, executing them as root on the router.",
@@ -61097,7 +62480,21 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management records a known-exploited root RCE it has no remediation for, since the DIR-859 is unsupported; the control degrades to asset-retirement rather than patching, which many operators never action."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "This is the terminal case for the control rather than the mixed one. The packet records patch_available false and live_patch_notes stating there is no fix: the DIR-859 is end-of-life and D-Link's advisory SAP10146 directs owners to retire and replace the device rather than patch. So there is no 'reach the fixed build' state to inventory toward — every DIR-859 in service on firmware 1.05 or 1.06B01 Beta01 is a replacement item, and the enumeration exists to produce a dated replacement schedule per unit rather than a patch-compliance figure. Scope it to the DIR-859 at those firmware levels: the packet ties the /gena.cgi UPnP command injection to that model and gives no mapping into other D-Link routers, so treating the wider D-Link estate as instances of this CVE manufactures replacement work against hardware no evidence implicates. For the window before each unit is physically removed the packet gives the interim mitigation as disabling UPnP or blocking the service at the network edge, and the precondition on that is exactly what makes replacement non-negotiable rather than optional: it does not remove the /gena.cgi code path, it depends on the UPnP service staying disabled across a configuration restore or factory reset on a device no central console manages, and edge blocking does nothing about the attack position the vector itself names — a crafted HTTP SUBSCRIBE request sent when connecting to the local network — so any client, guest device or already-conscripted host on the LAN still reaches root command execution. And because active exploitation is confirmed and the packet states that exploited DIR-859 devices generally stay compromised, a unit that was exposed is not returned to service by reconfiguration: it is removed, and any credential that transited it rotated.",
+        "evidence": "Packet: an unauthenticated HTTP SUBSCRIBE request to the UPnP endpoint /gena.cgi executes system commands as root on the D-Link DIR-859 Wi-Fi router, affected_versions firmware 1.05 and 1.06B01 Beta01; CVSS 9.8, RWEP 86, poc_available true; CISA KEV added 2023-06-29. active_exploitation confirmed, with the notes recording that Mirai-variant botnets fold the /gena.cgi command injection into their scanner/loader chains to conscript exposed DIR-859 routers for DDoS, and that because the DIR-859 is end-of-life, exploited devices generally stay compromised. patch_available false and live_patch_available false, with live_patch_notes stating no fix is available, that D-Link's advisory SAP10146 directs owners to retire and replace the device rather than patch, and that interim mitigation is disabling UPnP / blocking the service at the network edge. The NIS2-Art21-patch-management gap states the only compliant action is decommissioning, which a patch-centric process does not mandate; the ISO-27001-2022-A.8.8 gap states the control degrades to asset retirement, which many operators never action.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2019-20500": {
     "name": "D-Link DWL-2600AP Access Point Command Injection Vulnerability",
@@ -61158,7 +62555,31 @@
         "adequate": false,
         "gap": "Technical vulnerability management that excludes network-appliance firmware from scanning misses this CWE-78 sink entirely; the admin.cgi injection is invisible to app-focused vuln scans."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The D-Link DWL-2600AP wireless access point is the network device this control governs, and the packet supplies both halves it needs: a fix exists — flashing the D-Link firmware named in advisory SAP10113, with a device reboot and no live-patch path — and the flaw-remediation gap records the DWL-2600AP as an end-of-life embedded AP most operators never patch, with the live-patch note giving 'retiring the EOL unit' as the alternative to flashing. So the first requirement is an inventory naming every DWL-2600AP in service with its hardware revision and its running firmware version, and an end-of-support status for that exact model and revision obtained from D-Link rather than assumed in either direction; the packet gives the vulnerable level as firmware 4.2.0.15 Rev A and earlier but names no fixed build, so the fixed firmware level has to come from advisory SAP10113 itself for that model and revision. Scope the sweep to the DWL-2600AP: the packet ties the admin.cgi?action=config_save sink to that model alone and maps it into no other D-Link access point, so treating every AP in the estate as an instance of this CVE manufactures findings and replacement work against hardware no evidence implicates. Units whose revision has firmware carrying the fix are remediation items on the clock that opened with the 2023-06-29 KEV listing, and because there is no live-patch path and the flash requires a reboot, an AP that has taken the image but has not restarted onto it is still executing the vulnerable admin.cgi and counts as exposed — measure completion on the firmware version the AP reports after the restart, not on the number of images pushed. Units whose revision has no fixed image cannot be patched at all and need a dated replacement schedule; and because the product is end-of-life, reaching the SAP10113 build is an interim state on every unit — the terminal state is removal or replacement, since an AP that will take no further D-Link firmware stays exposed to everything found in that firmware since that build, and 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 behind the AP's web administration login, so keeping that administration surface off the WAN and off general user segments bounds who can attempt it — but the packet records that the authenticated precondition is trivially met with default or reused admin credentials, so that bounding is worth nothing on a unit whose administrative credential was never rotated, and an AP exists to serve the client network attached to it, so clients on that network still reach the login. And because active exploitation is confirmed and a successful config_save injection executes commands as root on the AP itself, a unit that was reachable during the exposure window is not remediated by firmware alone: its configuration and administrative credential must be rebuilt from a known-good baseline rather than inherited through the flash, and credentials that transited it rotated.",
+        "evidence": "Packet facts only: patch_available true with remediation given as flashing the fixed D-Link firmware per advisory SAP10113 and rebooting the device 'or retiring the EOL unit'; patch_required_reboot true; live_patch_available false. The NIST-800-53-SI-2 gap states 'the DWL-2600AP is an end-of-life embedded AP most operators never patch; SI-2 flaw-remediation assumes a maintained vendor pipeline that EOL hardware lacks, so the KEV due date (2023-07-20) went unmet across fleets'; the AU-Essential-8-Patch gap records Essential Eight patching as not covering 'firmware on EOL access points'. Vector: DWL-2600AP 4.2.0.15 Rev A, authenticated OS command injection via the Save Configuration functionality using shell metacharacters in the admin.cgi?action=config_save configBackup or downloadServerip parameter; affected_versions 'D-Link DWL-2600AP firmware 4.2.0.15 Rev A and earlier'; attack_vector ends in 'executing arbitrary commands as root on the AP'. CISA KEV listing 2023-06-29, active_exploitation confirmed, poc_available true, EPSS ~0.97. UK-CAF-B4 gap: 'B4 network-device hardening seldom enforces credential rotation or admin-UI exposure limits on embedded APs, so the authenticated precondition is trivially met with default or reused admin credentials.' ISO-27001-2022-A.8.8 gap: vulnerability management excluding network-appliance firmware from scanning 'misses this CWE-78 sink entirely'. NIS2 gap: these devices 'sit outside the asset inventory NIS2 assumes patch cadences reach'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For the DWL-2600AP the KEV clock opened 2023-06-29 with a 2023-07-20 due date the packet records as unmet across fleets, so the requirement here is that the listing produce a verified per-unit action rather than a ticket filed against a device class no patch program owns. On a unit whose revision has a fixed image in advisory SAP10113, the action that satisfies the clock is the flash plus the reboot, verified by reading back the firmware version the AP is running — the packet records no live-patch mechanism for this embedded AP firmware, so nothing shorter counts, and an image staged but not restarted onto leaves admin.cgi's config_save handler executing pre-fix code. On a unit whose revision has no fixed image, no patch action exists and the clock can only be met as a documented compensating control carrying a removal date: taking the AP's web administration surface off untrusted segments and rotating the administrative credential the packet describes as default or reused. State that mitigation's limit rather than recording it as closure — it bounds who can reach the configBackup / downloadServerip parameters, it does not remove the unsanitized shell path for anyone still permitted to authenticate, and it does nothing on a unit already enrolled into the Mirai IoT-botnet campaigns the packet records. Carrying an unpatchable end-of-life AP as 'risk accepted' with no removal date is the outcome this control exists to prevent: with a public PoC and EPSS ~0.97 the unit remains a mass-scan target for as long as it is in service.",
+        "evidence": "Packet facts only: cisa_kev true with kev_date 2023-06-29; the NIST-800-53-SI-2 gap names the KEV due date as 2023-07-20 and states it 'went unmet across fleets while Mirai mass-exploited it'. patch_available true, remediation recorded as 'flashing the fixed D-Link firmware per advisory SAP10113 and rebooting the device (or retiring the EOL unit)'; live_patch_available false with 'No live-patch mechanism for embedded AP firmware'; patch_required_reboot true. active_exploitation confirmed; active_exploitation_notes record incorporation 'into Mirai IoT-botnet campaigns that chain multiple embedded-device exploits to build DDoS bots' and 'EPSS ~0.97 reflects near-ubiquitous mass-scan/exploit attempts'; poc_available true. AU-Essential-8-Patch gap: 'the vulnerable 4.2.0.15 firmware stays deployed long after the SAP10113 fix, and Mirai mass-exploits the gap.' UK-CAF-B4 gap supplies the default-or-reused admin credential condition.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2021-25487": {
     "name": "Samsung Mobile Devices Out-of-Bounds Read Vulnerability",
@@ -61387,7 +62808,32 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management struggles with mobile-kernel CVEs because visibility into per-device SMR level is limited; an organization may not even know which handsets still carry the vulnerable MFC charger driver ahead of the SMR MAY-2021 patch."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "For these handsets the fix has exactly one form — Samsung's SMR MAY-2021 Release 1, delivered over the air and rebooting the device — and the packet's gaps say plainly that the operator controls neither its delivery nor, often, its visibility: rollout is staggered by model and carrier, and an organization may not know which handsets still carry the vulnerable MFC charger driver. That is why the fixed SMR level has to function as an access condition rather than a dashboard row: a Samsung device reporting an SMR level below MAY-2021 Release 1 is denied mail, VPN and document access until it reports at or above it, which is the one lever that works whether or not the carrier has shipped. Enumerate from what the packet names — Samsung mobile devices on Android 8.1, 9.0, 10.0 and 11.0, across both the Exynos and Qualcomm model families it lists — and note that scoping the sweep to a single chipset family misses the other, and that widening it to the Android fleet generally covers devices the packet does not implicate, since the vulnerable driver is a Samsung component. Distinguishing test: enrol a handset pinned below SMR MAY-2021 Release 1 and confirm the policy actually refuses it access to protected resources; an estate that surfaces the stale SMR level on a compliance report while the device keeps its mailbox has recorded the exposure rather than removed it. Precondition, stated rather than implied: this is a holding measure and not remediation. The race and the arbitrary kernel write remain fully available to anything already running on the handset, so this bounds what the device can reach, not what an attacker on it can do. It reaches only enrolled devices whose SMR level is actually readable — a personally-owned handset outside enrolment is not covered. And because the update is an over-the-air firmware install that reboots the device, a handset that has taken the SMR but not rebooted onto it is still running the vulnerable driver. Where a specific model and carrier combination appears never to have received SMR MAY-2021 Release 1, that status has to be obtained from the vendor or carrier for that exact model rather than assumed in either direction, because the answer determines whether the device is a remediation item or a longer-term one.",
+        "evidence": "Packet: affected is 'Samsung mobile devices (selected Exynos and Qualcomm models), where a race condition in the MFC charger driver causes a use-after-free that permits an arbitrary kernel write from a compromised radio-privilege context'; affected_versions is 'Samsung mobile devices (Android O/8.1, P/9.0, Q/10.0, R/11.0) before SMR MAY-2021 Release 1'. live_patch_notes: 'No live-patch mechanism for the mobile kernel; remediation requires installing the Samsung Security Maintenance Release for May 2021 (SMR MAY-2021 Release 1) via an over-the-air firmware update, which reboots the device.' patch_available true; patch_required_reboot true; live_patch_available false. The ISO-27001-2022-A.8.8 gap states 'visibility into per-device SMR level is limited; an organization may not even know which handsets still carry the vulnerable MFC charger driver'; the NIS2-Art21-patch-management gap states 'Samsung SMR rollout is staggered by model and carrier'; the AU-Essential-8-Patch gap states mobile SMR delivery 'is outside the organization's direct control'; the UK-CAF-B4 gap states 'device hardening and MDM policy do not stop the escalation' without the vendor SMR fix. cisa_kev true, kev_date 2023-06-29, active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "This control governs the half of the Samsung population the delivery gaps do not excuse: handsets whose model and carrier did ship SMR MAY-2021 Release 1. CISA listed this flaw on 2023-06-29, more than two years after that release, so a device in that population that is still vulnerable is one where an available update was simply never installed — deferred by the user, or never enforced by the management platform. The requirement is that the management platform push the SMR on a KEV-tied clock with user deferral disallowed, and that per-device SMR level be reported back so the estate can distinguish 'update not available for this model' from 'update available and not taken' — a distinction the packet's own gaps show is currently invisible, and one that decides which of the two remaining actions applies to each handset. Because the packet records the fix as an over-the-air firmware update that reboots the device, the deferral that actually matters is the reboot: measure completion on the SMR level the handset reports after restart, never on 'downloaded' or 'approved'. Precondition: enforcement can only reach enrolled devices and can only push an update the carrier or OEM has actually released for that exact model, so where the release never arrived this control has nothing to push and the exposure falls back to withholding access, not to a compliance exception. It also does nothing for a handset already compromised — the packet describes exploitation as part of targeted device-compromise chains that first obtain radio privilege on the device and end in full device control, so a handset suspected of having been through that chain is an incident-response and credential-rotation question, and installing the SMR afterwards does not make it a closed patch record.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-06-29, against a fix identified in live_patch_notes as 'the Samsung Security Maintenance Release for May 2021 (SMR MAY-2021 Release 1) via an over-the-air firmware update, which reboots the device'; patch_available true, patch_required_reboot true, live_patch_available false. active_exploitation confirmed, with active_exploitation_notes recording that 'the low EPSS (~0.004) reflects that exploitation is not mass-scanning but part of targeted device-compromise chains that first obtain radio/privileged context on Samsung handsets, then use the MFC charger-driver race to gain an arbitrary kernel write for privilege escalation' and that no public proof-of-concept specific to this CVE is available (poc_available false). attack_vector ends in 'escalating to full device control'. The AU-Essential-8-Patch gap notes the standard critical-patch window 'is only met when the carrier/OEM ships SMR MAY-2021'; the ISO-27001-2022-A.8.8 gap notes limited visibility into per-device SMR level.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2021-25395": {
     "name": "Samsung Mobile Devices Race Condition Vulnerability (CVE-2021-25395)",
@@ -62059,7 +63505,28 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management cannot act on NAS appliances absent from the asset inventory, so the crafted-HTTP-request command injection remains an untracked critical exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "The Zyxel NAS326, NAS540 and NAS542 are the storage appliances this control governs, and the packet's path reaches them with no credential at all: an unauthenticated crafted HTTP request to the NAS web management interface reaches an OS command on the box that holds the data. Applied to these units the control means that management interface answers only from an operator subnet or an authenticated VPN — not from the general user VLAN, and not from the WAN through a router port-forward or UPnP mapping, which is how small-business and branch NAS hardware normally acquires the exposure the packet records as routine on these models. Constrain the appliance's outbound path as well, so a NAS running attacker-supplied commands cannot reach arbitrary destinations with the data it stores; the packet records internet-facing Zyxel NAS devices as a recurring botnet target. The distinguishing test, run per model because all three are in scope: from a general user VLAN and from an external address, attempt to load the web management interface of each NAS326, NAS540 and NAS542 in service — anything that answers is within reach of the public PoC, and 'the NAS is on the internal network' is an assertion about topology, not a demonstration that the management interface is unreachable from untrusted segments. Two preconditions, both routinely skipped when this is recorded as the mitigation. Reachability is the exploit's only access requirement, so bounding it bounds who can send the request — it does not repair the unsanitized input path, and any host already inside a permitted segment, including a compromised workstation, still reaches a sink that requires no authentication; and where the web UI must stay reachable for remote use, this lever is unavailable outright and the fixed V5.21 firmware is the only remedy. Nor does isolation applied after the fact evict anyone: with exploitation confirmed and the outcome OS command execution on the appliance, a unit that was WAN-reachable before the update belongs on the incident path rather than being closed on the firmware record.",
+        "evidence": "Packet facts only: vector states 'The pre-authentication command injection vulnerability in the Zyxel NAS326 firmware versions prior to V5.21(AAZF.14)C0, NAS540 firmware versions prior to V5.21(AATB.11)C0, and NAS542 firmware versions prior to V5.21(ABAG.11)C0 could allow an unauthenticated attacker to execute some operating system (OS) commands remotely by sending a crafted HTTP request'; affected names the web management interface failing to sanitize input before executing OS commands pre-authentication. cvss 9.8, rwep_score 75, poc_available true, active_exploitation confirmed, cisa_kev true (2023-06-23). active_exploitation_notes: 'Internet-facing Zyxel NAS devices are a recurring botnet target, and the preauth CWE-78 sink is trivially mass-scannable (EPSS ~0.84)'. UK-CAF-B4 gap: 'CAF B4 hardening expects management interfaces off the public internet, yet these NAS devices commonly expose the vulnerable web UI to the WAN, so the routine hardening posture never removes the reachable preauth injection point.' live_patch_available false; live_patch_notes: 'No live-patch mechanism for the NAS firmware; remediation requires installing the fixed V5.21 firmware build, which reboots the device.'",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The KEV listing for these NAS appliances is 2023-06-23 with a 2023-07-14 due date, and the packet records why it slips: consumer and small-business NAS boxes are rarely enrolled in a managed patch program, so a 9.8-rated pre-authentication command injection stays live on internet-facing units well past the date. Bound to this product the SLA is a per-model obligation, not a per-CVE one — the packet gives three distinct fixed builds, NAS326 to V5.21(AAZF.14)C0, NAS540 to V5.21(AATB.11)C0 and NAS542 to V5.21(ABAG.11)C0 — so an estate that updates one model and closes the finding still runs the unsanitized handler on the other two. The packet records no live-patch mechanism for this firmware and an install that reboots the device, so the action that satisfies the clock is the reboot onto the fixed build, verified by reading the build each unit reports; an image downloaded but not installed leaves the appliance executing the vulnerable web handler and must not be counted. Where a unit cannot be taken through the update inside the window, the only thing that counts as a documented compensating control is removing the web management interface's reachability from untrusted networks — and it has to carry a date for the firmware rather than standing in for it, because the pre-authentication sink stays reachable from every segment still permitted and from any host compromised inside one.",
+        "evidence": "Packet facts only: cisa_kev true, kev_date 2023-06-23; active_exploitation_notes state 'added to CISA KEV 2023-06-23 (due 2023-07-14)'. Fixed builds per model from vector and affected_versions: NAS326 < V5.21(AAZF.14)C0, NAS540 < V5.21(AATB.11)C0, NAS542 < V5.21(ABAG.11)C0. patch_available true; patch_required_reboot true; live_patch_available false with live_patch_notes 'No live-patch mechanism for the NAS firmware; remediation requires installing the fixed V5.21 firmware build, which reboots the device.' cvss 9.8; poc_available true; EPSS ~0.84 per active_exploitation_notes. NIST-800-53-SI-2 gap: 'SI-2 flaw remediation depends on operators applying the fixed V5.21 firmware, but consumer/SMB NAS appliances are rarely enrolled in a managed patch program, so the unauthenticated CWE-78 sink stayed live on internet-facing units well past the 2023-06-23 KEV listing.' AU-Essential-8-Patch gap: 'Essential 8's internet-facing patch SLA is undercut because the NAS web UI is exposed by default and owners seldom monitor Zyxel advisories, leaving the 9.8-rated injection exploitable beyond the intended window.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-20887": {
     "name": "Vmware Aria Operations for Networks Command Injection Vulnerability",
@@ -62296,7 +63763,38 @@
         "adequate": false,
         "gap": "Technical vulnerability management that scans only the OS misses application-level CWE-78 in Roundcube; the fixed version is well known but the webmail asset is frequently unscanned."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "Roundcube Webmail's vulnerable sink is itself a configuration value: rcube_image.php builds the ImageMagick command line out of the im_convert_path / im_identify_path settings and never neutralizes shell metacharacters in them, so the tainted command runs as the web-server user the moment Roundcube processes an image such as a message attachment. That makes the configuration-side path a mitigation an operator can deploy today, independent of the vendor-patch path, and the packet's own application-hardening gap names it — hardening that covers browsers and Office macros but not 'disabling or pinning ImageMagick invocation in webmail' leaves the shell-metacharacter path live. Applied to this product the requirement is to inventory every self-hosted Roundcube instance's configuration for those two settings, pin each to a fixed absolute path to the ImageMagick binary with no shell metacharacters (or leave the image-conversion setting unconfigured on deployments that do not need conversion), and hold that as a tested, deployable change rather than as advice waiting on a maintenance window. Running the inventory is also a detection step, keyed on the behaviour the packet documents rather than on an assumed signature: an instance whose im_convert_path or im_identify_path already contains shell metacharacters is not a hardening finding, it is evidence the sink was set, and that host belongs on the incident path. State the precondition rather than recording this as closure, because it is the whole reason it cannot substitute for the upgrade: the pinned value holds only while it stays pinned, so anyone able to write the Roundcube configuration — including a hosting control panel that regenerates it — can reintroduce the metacharacters, and the unsanitized construction inside rcube_image.php remains present until the instance reaches 1.4.4, 1.3.11 or 1.2.10 or later. It is a holding measure for the window before the upgrade, not a removal of the surface.",
+        "evidence": "Packet facts only: vector states 'rcube_image.php in Roundcube Webmail before 1.4.4 allows attackers to execute arbitrary code via shell metacharacters in a configuration setting for im_convert_path or im_identify_path'; affected states rcube_image.php 'constructs an ImageMagick shell command from the im_convert_path / im_identify_path configuration values without sanitizing shell metacharacters (CWE-78)'; attack_vector states that when Roundcube processes an image (e.g. an attachment) rcube_image.php 'runs the tainted command as the web-server user, achieving code execution'. AU-Essential-8-App-Hardening gap: 'Essential Eight application hardening focuses on browsers and Office macros, not on disabling or pinning ImageMagick invocation in webmail, so the shell-metacharacter path stays live.' UK-CAF-B4 gap: 'B4 system-security baselines rarely harden the webmail application layer against config-value injection; the im_convert_path sink is a trusted-config path that operators do not treat as attacker-influenced.' Fixed releases from affected_versions and live_patch_notes: 1.4.4 / 1.3.11 / 1.2.10 or later; live_patch_available false. cvss 9.8, poc_available true, active_exploitation confirmed.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This Roundcube entry is the case of the clock never starting: the packet records a fixed release from 2020-04-29 and a KEV listing only on 2023-06-22, and states that organizations treating webmail as low priority left an internet-facing RCE exposed for years. Bound to this product the SLA means the 2023-06-22 listing forces a verified action on every self-hosted Roundcube instance across all three maintenance branches the packet names — 1.2.x to 1.2.10, 1.3.x to 1.3.11, and otherwise 1.4.4 or later — because a mail estate that upgrades its 1.4 host and closes the ticket still runs rcube_image.php's unsanitized ImageMagick invocation on a 1.2 or 1.3 host. patch_required_reboot is false, and that means no machine reboot, not that the fix is live on deployment: the packet's remediation is the upgrade plus a restart of the web application, so a PHP process still serving pre-upgrade code is not remediated, and completion must be measured on the version the running application reports rather than on the files on disk. There is no vendor live-patch, so nothing short of that upgrade-and-restart satisfies the clock. Precondition: this reaches only the instances the operator knows are running — the forgotten self-hosted mail host the packet describes is remediated by finding and either enrolling or decommissioning it, and an SLA attested against a partial list of webmail assets passes cleanly while that host stays exposed.",
+        "evidence": "Packet facts only: cisa_kev true, kev_date 2023-06-22, active_exploitation confirmed with 'Added to CISA KEV on 2023-06-22 as confirmed exploited'; cvss 9.8, rwep_score 67, poc_available true, EPSS ~0.84 per active_exploitation_notes. NIST-800-53-SI-2 gap: 'A fixed release existed from 2020-04-29, yet the CVE only entered KEV in 2023; SI-2's remediation clock never started for organizations that treat webmail as low priority, leaving a multi-year exposure on an internet-facing RCE.' NIS2-Art21-patch-management gap: 'Self-hosted Roundcube often falls outside centralized patch management; the config-driven command injection persists on forgotten mail hosts that patch cadences do not reach.' affected_versions: 'Roundcube Webmail < 1.4.4', 'Roundcube Webmail 1.3.x < 1.3.11', 'Roundcube Webmail 1.2.x < 1.2.10'. patch_available true; patch_required_reboot false; live_patch_available false with live_patch_notes 'No vendor live-patch; remediation requires upgrading to Roundcube 1.4.4 / 1.3.11 / 1.2.10 or later and restarting the web application.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "A scan that pronounces a Roundcube host patched from its operating-system package inventory alone is paper compliance for this CVE, and the packet's technical-vulnerability-management gap describes exactly that failure: scanning only the OS misses the application-level CWE-78 in Roundcube, and the fixed version is well known while the webmail asset itself goes unscanned. The operational test for this product has two halves and both must pass. Does the scan read the version the deployed Roundcube actually reports and compare it against the branch-specific fixed builds — 1.2.10, 1.3.11, 1.4.4 or later — rather than against the distribution's package list, so a webmail instance unpacked into a webroot that no package manager owns is still assessed? And does it read the im_convert_path / im_identify_path settings the injection travels through, so an instance whose configuration already carries shell metacharacters is surfaced as a compromise indicator instead of being scored on version alone? A scanner returning clean on a host running a pre-1.4.4 (or pre-1.3.11, or pre-1.2.10) Roundcube is producing a compliance record, not a finding. Precondition: this governs the quality of the verdict on assets the scan already covers — it does not discover a self-hosted webmail instance nobody registered, and a scan scoped to a host list that omits the mail server will pass this test and still miss the exposure.",
+        "evidence": "Packet facts only: ISO-27001-2022-A.8.8 gap states 'Technical vulnerability management that scans only the OS misses application-level CWE-78 in Roundcube; the fixed version is well known but the webmail asset is frequently unscanned.' cwe_refs CWE-78. affected_versions give the three branch-specific fixed builds: '< 1.4.4', '1.3.x < 1.3.11', '1.2.x < 1.2.10'. vector and affected identify the injection as travelling through the im_convert_path / im_identify_path configuration settings consumed by rcube_image.php. active_exploitation confirmed; poc_available true; cisa_kev true (2023-06-22).",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2021-44026": {
     "name": "Roundcube Webmail SQL Injection Vulnerability",
@@ -62449,7 +63947,29 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management could not act before the fix existed — the use-after-free was exploited as a zero-day drive-by, and remediation required the Firefox 50.0.2 / ESR 45.5.1 update reaching each client."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet records Mozilla shipping an emergency fix within roughly a day of the exploit surfacing, which puts the whole operator-side exposure in the interval between that build existing and each client actually running it — this is the deferral case, not the patch-availability case. Applied here the control means the update ring is scoped to every product the packet names, each held to its own fixed build rather than to a single channel: Firefox below 50.0.2, Firefox ESR below 45.5.1, Thunderbird below 45.5.1, and Tor Browser below 6.0.7 for the Tor population the packet's remediation note names. The extended-support channel is the specific trap on this entry, because deferral is what it is for: an estate whose policy forbids deferring the mainline Firefox channel while its ESR fleet moves on the ordinary quarterly rhythm has left the ESR-45-based builds on the exploited code, and the mail client is a third track that a browser-shaped update ring frequently never enumerates at all even though the same SVG-animation path is reachable from a crafted mail page. Measure completion on the version the running process reports, not on the installed package: patch_required_reboot false means no machine reboot, not that the fix is live, and a browser or mail client that was open when the update landed keeps executing the pre-fix code until that process restarts — on the long-lived browser sessions typical of the targeted population, that restart is the step most likely to be deferred and a deferral recorded as 'updated' is exactly how this remediation goes wrong. Precondition: this reaches only clients an update ring can govern. The packet places the exploitation against Firefox and Tor Browser users on Windows, and an unmanaged or anonymity-focused client is remediated when its user takes the update, so for that population the lever is notification and, where the estate controls the host, blocking the below-build client from organizational resources — not a management console that never enrolled it.",
+        "evidence": "Packet: use-after-free in SVG animation (CWE-416), 'exploited in the wild in November 2016 against Firefox and Tor Browser users on Windows to deanonymize visitors of hidden services; Mozilla shipped an emergency fix within roughly a day of the exploit surfacing.' affected_versions: Firefox < 50.0.2, Firefox ESR < 45.5.1, Thunderbird < 45.5.1; affected notes the flaw is 'reachable from a crafted web or mail page'. live_patch_notes: 'No live-patch mechanism; remediation requires updating to Firefox 50.0.2, Firefox ESR 45.5.1, or Thunderbird 45.5.1 (Tor Browser 6.0.7 for Tor users).' patch_available true, patch_required_reboot false, live_patch_available false; poc_available true; CVSS 7.5, RWEP 65; CISA KEV 2023-06-22. NIS2-Art21-patch-management gap: 'Browser patch-management must reach every endpoint; Tor Browser users on the older ESR 45 base stayed exposed to the deanonymization exploit until they updated, and NIS2 patch cadence does not cover unmanaged, anonymity-focused clients.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this entry 'patched' cannot be read off one version comparison, and a scanner that tries produces wrong answers in both directions. The packet gives four remediation targets across three products, two of them numerically lower than the third: Firefox 50.0.2, Firefox ESR 45.5.1, Thunderbird 45.5.1, and Tor Browser 6.0.7 for Tor users. A rule written as 'Firefox at or above 50.0.2' marks a correctly-remediated ESR 45.5.1 install as vulnerable, which trains operators to dismiss it; a rule scoped to the mainline browser never evaluates the Thunderbird install at all, even though the same SVG-animation use-after-free is reachable from a crafted mail page; and Tor Browser is a fourth track that the scan has to be told about explicitly, since the packet names it as the remediation for Tor users and it is not one of the three builds the affected-version list carries. So the operational test has two halves. Does the scan resolve each install to its own product track and compare against that track's fixed build, and does it read the version the process is actually executing rather than the version sitting on disk — because patch_required_reboot is false and no live-patch mechanism exists, a browser or mail client left running across the update keeps the vulnerable SVG-animation code mapped until it restarts, and an inventory query answered from the installed package cannot distinguish that host from a remediated one. An estate whose dashboard shows every Firefox at 50.0.2 while a running session, an ESR build, a Thunderbird install or a Tor Browser copy still renders the crafted page has recorded the exposure rather than removed it, and a technical-vulnerability-management review reads clean throughout.",
+        "evidence": "Packet live_patch_notes names four distinct remediation targets: 'updating to Firefox 50.0.2, Firefox ESR 45.5.1, or Thunderbird 45.5.1 (Tor Browser 6.0.7 for Tor users)'; affected_versions carries three of them (Firefox < 50.0.2, Firefox ESR < 45.5.1, Thunderbird < 45.5.1). affected: 'a use-after-free in SVG animation (CWE-416) reachable from a crafted web or mail page yields content-process code execution on Windows.' patch_required_reboot false; live_patch_available false; poc_available true; active_exploitation confirmed; CISA KEV 2023-06-22. ISO-27001-2022-A.8.8 gap: 'A.8.8 technical vulnerability management could not act before the fix existed — the use-after-free was exploited as a zero-day drive-by, and remediation required the Firefox 50.0.2 / ESR 45.5.1 update reaching each client.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2016-0165": {
     "name": "Microsoft Win32k Privilege Escalation Vulnerability",
@@ -63048,7 +64568,41 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management flags the KEV entry, but because UDP/500 must remain reachable for VPN, mitigation short of the fixed firmware leaves the command injection open, and the exploitation-vs-disclosure gap defeated slower patch programs."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The Zyxel ATP, USG FLEX, VPN and ZyWALL/USG firewall IS the trust boundary, and the packet's attack vector is a single crafted IKEv2 packet to UDP/500 that executes OS commands as root with no session or credentials — so this CVE must sit in the distinct perimeter SLA tier, not in the two-week internet-facing application window the Essential Eight, NIS2 and ISO A.8.8 gaps say it was triaged under. The clock runs from the 2023-05-31 KEV listing, and the sweep must cover all four families named in affected_versions at their own fixed builds — ZyWALL/USG 4.60 through 4.73 and VPN, USG FLEX and ATP 4.60 through 5.35 — reaching, per live_patch_notes, ZLD 5.36 for the ZLD-branch families and the relevant ZyWALL build for ZyWALL/USG; scoping the sweep to one family reports clean on an estate standardised on another. Precondition on the alternative this control permits in place of vendor mitigation: isolating the vulnerable interface does NOT hold generally here, because the packet's SI-2 gap states IKE/UDP-500 is required for VPN operation and cannot simply be firewalled off. A source-address ACL on UDP/500 is available only where that gateway terminates site-to-site tunnels from a fixed, enumerated peer set; where it terminates roaming client VPN from arbitrary addresses there is no isolation option and the flashed firmware is the only path. And because patch_required_reboot is true and live_patch_available is false, a unit counts as remediated only when it reports the fixed build as its running firmware after the reboot the flash forces — an image uploaded but not booted is still executing the vulnerable IKE daemon.",
+        "evidence": "Packet records cisa_kev true with kev_date 2023-05-31, active_exploitation confirmed, poc_available true, RWEP 80 against CVSS 9.8. active_exploitation_notes: Zyxel patched in April 2023, by late May 2023 a Mirai-based botnet was mass-exploiting exposed ATP/USG FLEX/VPN/ZyWALL firewalls, EPSS ~0.99, and the unauthenticated single-packet root RCE is described as effectively wormable. attack_vector: crafted IKEv2 packet to UDP/500, improper error-message handling injects attacker input into an OS command executing as root with no session or credentials. patch_available true, patch_required_reboot true, live_patch_available false; live_patch_notes: 'No live-patch mechanism; remediation requires flashing the Zyxel fixed firmware (ZLD 5.36 / relevant ZyWALL build), which reboots the device.' affected_versions lists the four families and their ranges. The AU-Essential-8-Patch gap records the two-week internet-facing SLA being outpaced, and the NIST-800-53-SI-2 gap records that UDP/500 cannot simply be firewalled off.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This is the exact shape this control exists for: a perimeter device with a pre-auth RCE under confirmed active exploitation, where the packet's own attack vector ends in botnet implant deployment. Flashing the fixed Zyxel firmware removes the injectable IKE error-handling path, but it does not remove what a Mirai implant left on a unit that was already rooted, and it does not rotate the material the appliance held — VPN pre-shared keys, admin credentials, and any certificates and configuration exportable by a process running as root. So for any ATP, USG FLEX, VPN or ZyWALL/USG unit that was internet-reachable on UDP/500 while running an affected build during the window the packet describes — Zyxel's April 2023 fix, mass Mirai exploitation by late May 2023, KEV listing 2023-05-31 — the default disposition is config export for forensics, rebuild from a known-good baseline, and rotation of every credential and key that transited the device, rather than patch-in-place. This is what makes the UK-CAF-B4 gap concrete: treating the firewall as a hardened trust anchor is wrong not only until the firmware is flashed, but afterwards on any unit whose exposure window was real, because the flash restores the code and not the trust. Precondition: this applies to units whose exposure can be established; a unit whose UDP/500 listener was never reachable from an untrusted network for the duration is a patch item, and that reachability must be established from configuration and edge records rather than assumed in either direction.",
+        "evidence": "Packet attack_vector: 'executing commands as root on the firewall with no session or credentials, enabling botnet implant deployment.' active_exploitation_notes: 'by late May 2023 a Mirai-based botnet was mass-exploiting exposed ATP/USG FLEX/VPN/ZyWALL firewalls', added to KEV 2023-05-31, used for DDoS botnet growth; active_exploitation is 'confirmed' and poc_available is true. The UK-CAF-B4 gap states CAF B4 'treats the perimeter firewall as a hardened trust anchor, but here the firewall's mandatory internet-facing IKE listener is the target; a single unauthenticated UDP/500 packet roots the appliance'. The NIS2-Art21-patch-management gap states a monthly firmware cadence 'exposed its perimeter firewall to unauthenticated takeover'. Remediation facts: patch_available true with patch_required_reboot true and live_patch_available false, fixed firmware per live_patch_notes.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this CVE the 'vendor-mitigation active, binary patch pending' state that audits normally bank is largely unavailable, and the record has to say so rather than carry an interim measure as a satisfied control. The packet's SI-2 gap states IKE/UDP-500 is required for VPN operation and cannot simply be firewalled off, and the ISO A.8.8 gap states that because UDP/500 must remain reachable for VPN, mitigation short of the fixed firmware leaves the command injection open — so a source-address ACL on UDP/500 qualifies as a genuine compensating state only for a gateway whose peers are a fixed, enumerated site-to-site set, and is simply not an option for one terminating roaming client VPN. On those units the only honest verdict classes are 'fixed build running' or 'fully exposed'; there is no middle column to sit in. Two further placements this CVE forces: live_patch_available is false, so no live-patch state exists to claim; and because the flash reboots the device, a unit with the image staged but not yet booted onto the fixed build belongs in the pending column, since it is still executing the vulnerable IKE daemon. Each unit still in the pending column carries a dated action item, not a recurring 'mitigated' verdict.",
+        "evidence": "Packet NIST-800-53-SI-2 gap: 'IKE/UDP-500 is required for VPN operation and cannot simply be firewalled off; unpatched Zyxel firmware stayed exploitable to a single-packet root RCE until the vendor build was flashed'. Packet ISO-27001-2022-A.8.8 gap: 'because UDP/500 must remain reachable for VPN, mitigation short of the fixed firmware leaves the command injection open'. live_patch_available false and live_patch_notes 'No live-patch mechanism; remediation requires flashing the Zyxel fixed firmware (ZLD 5.36 / relevant ZyWALL build), which reboots the device'; patch_required_reboot true. Exposure facts backing the dated action item: KEV 2023-05-31, active_exploitation confirmed, poc_available true, EPSS ~0.99 per active_exploitation_notes.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-2868": {
     "name": "Barracuda Networks ESG Appliance Improper Input Validation Vulnerability",
@@ -63192,7 +64746,40 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management operating on periodic scans lags a mercenary-spyware zero-day; the sandbox escape was weaponized before the fix, so scan-and-patch timing left endpoints exposed during the active-exploitation window flagged by the 2023-05-22 KEV listing."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Remediation for this WebKit sandbox escape is not one build but six product lines: live_patch_notes names watchOS 9.5, tvOS 16.5, macOS Ventura 13.4, iOS 15.7.8 and iPadOS 15.7.8, Safari 16.5, and iOS 16.5 and iPadOS 16.5 as the releases carrying the fix, and affected_versions lists iOS, iPadOS, macOS Ventura, tvOS, watchOS and Safari separately. The enforced-update population must therefore be every one of those lines at its own fixed build — an estate that drives iPhones and Macs to the fixed release on a managed ring while Apple TVs, Watches and the Safari build on macOS are left to user-initiated updates still has an unpatched WebKit engine rendering untrusted web content. The clock runs from the 2023-05-22 KEV listing rather than the next scheduled ring, because Apple shipped these as fixes for a flaw already in use. Completion is measured on the build the device is executing: patch_required_reboot is true and live_patch_available is false, so a device that downloaded the update and has not restarted is still running the vulnerable engine and counts as exposed, not as compliant. Precondition: this control reaches only devices the management channel enrolls and can compel; an unenrolled personal device, or a product line no console in the estate manages, is outside the SLA and needs the access-condition route instead. And because exploitation is confirmed and delivery is attacker-controlled web content, a device that rendered untrusted content while below the fixed build belongs on the incident path rather than being closed on the update record.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-05-22; active_exploitation 'confirmed', with active_exploitation_notes recording that Apple acknowledged in-the-wild exploitation. patch_available true, patch_required_reboot true, live_patch_available false; live_patch_notes states remediation requires installing the fixed Apple OS/Safari releases (watchOS 9.5, tvOS 16.5, macOS Ventura 13.4, iOS/iPadOS 15.7.8 and 16.5, Safari 16.5), which reboot the device. affected_versions names iOS, iPadOS, macOS Ventura, tvOS, watchOS and Safari as separate product lines.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this flaw inside a mercenary-spyware WebKit chain used in targeted operations rather than mass exploitation, with no reusable public PoC released — so for the cohort plausibly inside that targeting set the update ring alone is not fast enough, and the only operator lever during the window is the delivery path. Put that cohort's iPhones, iPads and Macs in the vendor's reduced-attack-surface mode so untrusted web content is not handed to WebKit automatically, narrowing the path into the out-of-bounds condition between the 2023-05-22 KEV listing and completed restart on the fixed builds. This has to be a standing posture assigned to the cohort before the next disclosure, because the mode only helps if it was already on when the chain arrived; enabling it in response to this CVE protects nobody who was targeted with it. Precondition, and it is the one that is usually over-claimed: the mode narrows how attacker-controlled web content reaches the engine, it does not remove the defect in WebKit — the fixed builds do, and the packet records those as requiring a restart. It also does nothing for a device already compromised during the targeted-operation window, which is an incident, not a hardening item. This is why the browser-settings form of application hardening the frameworks carry is not equivalent: the memory-safety bug is inside the engine, so no setting inside the browser prevents the escape once the content is parsed.",
+        "evidence": "Packet: active_exploitation_notes records the flaw as part of a mercenary-spyware WebKit exploit chain in which the Web Content process escapes its sandbox by hopping to the GPU process, used in targeted operations rather than mass exploitation, with no reusable public PoC released (poc_available false). attack_vector records malicious web content processed by WebKit as the trigger. kev_date 2023-05-22; patch_required_reboot true; live_patch_available false. The AU-Essential-8-App-Hardening gap states that hardening browser settings does not neutralize a memory-safety bug inside WebKit itself.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "For this entry the threshold is not a single version number: the packet splits iOS and iPadOS across two supported lines, 15.7.8 on the 15.x line and 16.5 on the 16.x line, alongside macOS Ventura 13.4, tvOS 16.5, watchOS 9.5 and Safari 16.5. The minimum-build policy therefore has to be expressed per line, or a device deliberately held on 15.x either reads as permanently non-compliant or gets waved through by a rule written against 16.5 alone. The fixed build must function as an access condition — organizational mail, VPN and document access denied to a device below its line's fixed build — rather than as a row on a patch-compliance report, because the citing framework gaps here record endpoint hardening and periodic scanning as the controls that already exist and already fail against a browser-engine sandbox escape. Distinguishing test: enrol a device pinned below its line's fixed build and confirm the policy actually denies it protected resources; an estate that surfaces the stale build on a dashboard while the device keeps its access has recorded the exposure rather than removed it. Precondition: this withholds organizational data from an exposed device, it does not protect the device — the user still browses on the vulnerable engine, and the fixed build plus its restart is the only thing that removes the flaw. patch_required_reboot is true, so the access condition must evaluate the build actually running, not the one downloaded.",
+        "evidence": "Packet: affected_versions records Apple iOS < 16.5 (and < 15.7.8 on the 15.x line), iPadOS < 16.5 (and < 15.7.8 on the 15.x line), macOS Ventura < 13.4, tvOS < 16.5, watchOS < 9.5 and Safari < 16.5. patch_required_reboot true, live_patch_available false. The UK-CAF-B4 gap records that routine endpoint hardening does not blunt a zero-day breaking the Web Content sandbox; the NIS2-Art21-patch-management gap records that server-focused patch management under-serves mobile/endpoint fleets and that without rapid mobile OS update enforcement the sandbox escape remained reachable on unpatched iPhones and Macs.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-28204": {
     "name": "Apple Multiple Products WebKit Out-of-Bounds Read Vulnerability (CVE-2023-28204)",
@@ -63338,7 +64925,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management can enumerate the affected Apple versions but cannot compress the exploited-before-patch gap for a zero-day WebKit UAF; the control's assessment cadence trails an exploit already used in the wild by the 2023-05-22 KEV listing."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The fix for this CVE is not one build but a set, and the managed-update requirement has to be written per product line against its own fixed build: iOS/iPadOS 16.5, iOS/iPadOS 15.7.6, macOS Ventura 13.4, Safari 16.5, tvOS 16.5 and watchOS 9.5, driven on the KEV clock that opened 2023-05-22 with user deferral disallowed rather than folded into a routine update ring. The iOS/iPadOS 15 line is the specific trap: its fix is 15.7.6, not 16.5, so an estate that measures compliance against 16.5 alone misreads devices that are actually remediated and, worse, may treat the 15 line as having no available fix at all. Completion is measured on the build the device is running after restart, not on 'update pushed' or 'downloaded' — patch_required_reboot is true and the packet records no live-patch mechanism for WebKit, so a device holding the update but deferring the restart is still executing the vulnerable engine. Scope the sweep to what the packet names, which is all six of those product lines and not iOS alone; the entry additionally records non-Apple products embedding WebKit, and since it gives no fixed version for them, that level must be obtained from the embedding vendor rather than assumed to be one of Apple's builds. Precondition: this reaches only enrolled devices. Personally-owned and unenrolled devices sit outside it entirely and are covered by the minimum-build access condition, not by this control.",
+        "evidence": "live_patch_notes: 'No live-patch mechanism for WebKit; the fix ships in OS/Safari updates (iOS 16.5, iPadOS 16.5, macOS Ventura 13.4, tvOS 16.5, watchOS 9.5, Safari 16.5, iOS/iPadOS 15.7.6) and requires a device restart.' affected_versions: 'Apple iOS/iPadOS 16 < 16.5', 'Apple iOS/iPadOS 15 < 15.7.6', 'macOS Ventura < 13.4', 'Safari < 16.5', 'tvOS < 16.5', 'watchOS < 9.5'. affected names WebKit 'as used across iOS, iPadOS, macOS, tvOS, watchOS and Safari (and non-Apple products embedding WebKit)'. The NIST-800-53-SI-2 gap: 'the WebKit UAF was weaponized before many devices updated, and MDM update-deferral policies extend that window'. The AU-Essential-8-Patch gap: 'Apple's fix spans many OS/Safari builds and users defer reboots'. CISA KEV 2023-05-22; active_exploitation confirmed; patch_available true; patch_required_reboot true; live_patch_available false; CVSS 8.8; RWEP 52.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "On an Apple device the organization cannot force to update — the personally-owned and BYOD endpoints the entry's NIS2 gap names — the remaining lever is to make the fixed build an access condition rather than a dashboard row. For this CVE that means organizational mail, VPN and document access denied to any device reporting below the fixed build for its own line: iOS/iPadOS 16.5, or 15.7.6 on the 15 line, macOS Ventura 13.4, Safari 16.5, tvOS 16.5, watchOS 9.5. This is what converts the affected-version enumeration the technical-vulnerability control already produces into something that actually changes the device's reach; enumerating the stale build while the device keeps its mail session records the exposure instead of removing it. The distinguishing test is to present a device pinned below its line's fixed build and confirm the policy denies it protected resources. Preconditions: because the fix requires a device restart and the packet records no live-patch mechanism for WebKit, the condition has to evaluate the build the device is running, not the update it has downloaded — otherwise a deferred restart passes the gate while the vulnerable engine is still loaded. And this is a holding measure only. It bounds what a compromised device can reach; it does not prevent the arbitrary code execution on the device itself, since delivery is attacker-controlled web content that needs no organizational resource. A device that rendered untrusted content while below its fixed build belongs on the incident path rather than being closed out when it later reports current.",
+        "evidence": "The NIS2-Art21-patch-management gap: 'NIS2 Art.21 patch management struggles with BYOD/personally-owned Apple devices where the org cannot force the OS update carrying the WebKit fix, so the code-execution-on-web-content flaw stays live on unmanaged endpoints past the KEV date.' The ISO-27001-2022-A.8.8 gap: 'A.8.8 technical-vulnerability management can enumerate the affected Apple versions but cannot compress the exploited-before-patch gap for a zero-day WebKit UAF'. attack_vector: 'A use-after-free in WebKit's processing of maliciously crafted web content lets a hostile page corrupt memory and execute arbitrary code'. Fixed builds per live_patch_notes and affected_versions (iOS/iPadOS 16.5, iOS/iPadOS 15.7.6, macOS Ventura 13.4, Safari 16.5, tvOS 16.5, watchOS 9.5); patch_required_reboot true; live_patch_available false; KEV 2023-05-22; CWE-416.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The entry records this class of WebKit use-after-free as characteristically the browser-engine stage of mercenary-spyware initial-access chains against iOS and macOS, and the trigger is processing maliciously crafted web content. For the population plausibly inside that targeting set, the reboot-gated multi-OS update is not fast enough on its own, because the flaw is the entry point of a chain rather than a bug that needs a second condition to matter. Place those users on the platform's reduced-attack-surface mode so untrusted web content, message attachments, fonts and link previews are not processed automatically, narrowing the delivery path into the use-after-free during the window between the 2023-05-22 KEV listing and completed installation and restart of the fixed build. Preconditions, and they are the whole substance of this control: it only helps if it was already the standing posture for that cohort when the chain arrived — enabling it in response to this CVE does nothing about a device already compromised, since the mode restricts what content is processed and does not evict resident code. It narrows the path rather than removing it: a user in that mode still renders web content through the same engine, so it is a holding measure and not a substitute for reaching iOS/iPadOS 16.5 or 15.7.6, macOS Ventura 13.4, Safari 16.5, tvOS 16.5 or watchOS 9.5 and restarting. Note also that no public PoC exists for this specific CVE, so there is no exploit signature to detect against — the lever is the content path, not recognition of the attack.",
+        "evidence": "active_exploitation_notes: 'Apple reported it may have been actively exploited; CISA added it to KEV 2023-05-22. WebKit use-after-free bugs of this class are characteristically the browser-engine stage of mercenary-spyware initial-access chains against iOS/macOS. No public PoC or exploit has surfaced for this specific CVE.' poc_available false; active_exploitation confirmed. vector: 'Processing maliciously crafted web content may lead to arbitrary code execution.' The UK-CAF-B4 gap: 'CAF B4 system-security assurance trusts the browser sandbox to contain malicious web content, but a WebKit use-after-free yields arbitrary code execution from a crafted page — the initial-access primitive B4 assumes the platform prevents.' The AU-Essential-8-Patch gap: 'the actively-exploited UAF remained reachable via web content until the update was installed and the device restarted.' patch_required_reboot true; live_patch_available false; CVSS 8.8.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2004-1464": {
     "name": "Cisco IOS Denial-of-Service Vulnerability",
@@ -63658,7 +65277,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management often overlooks network-appliance firmware inventory; organizations may not track which Ruckus APs run the vulnerable 10.4-or-earlier admin software, leaving unmanaged devices exploitable via the public /forms/doLogin PoC."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "CVE-2023-25717 is the case this control exists for: KEV listing on 2023-05-12, a public one-line exploit, and botnet exploitation of internet-reachable Ruckus web services already under way. Applied to this product it means the KEV clock — not the site's ordinary firmware-maintenance calendar — governs every ZoneDirector, SmartZone and Solo AP unit running Ruckus Wireless Admin 10.4 or earlier, and that where the firmware upgrade above 10.4 and its device reboot cannot be taken inside that window, the interim mitigation the packet names is deployed and recorded as the documented compensating control rather than the CVE being carried open to the next change window. Completion is measured on the build the AP is running after its reboot, because the packet records no live-patch path and a fix that reboots the device: an AP with new firmware staged and not restarted is still serving the vulnerable handler. Precondition, and it is where this is most often over-claimed: disabling the web services component removes the vulnerable login handler only at sites where that component is not required to operate the wireless estate, and isolating the management interface bounds who can send the unauthenticated GET without removing the injection path — anything inside the permitted segment, including a compromised client or jump host, still reaches it. Neither substitutes for the firmware fix, and neither remediates a unit that was already exploited.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-05-12, active_exploitation 'confirmed', poc_available true, CVSS 9.8, RWEP 77. live_patch_notes: 'No live-patch mechanism; remediation requires upgrading the Ruckus AP firmware per security bulletin 315 (fixed builds above 10.4), which reboots the device. Disabling the web services component or isolating the management interface is the interim mitigation.' patch_required_reboot true, live_patch_available false. active_exploitation_notes record mass exploitation from early May 2023 by the AndoryuBot DDoS botnet with EPSS ~0.98. The AU-Essential-8-Patch gap states access points 'often fall outside standard patch tooling; the 48-hour critical window is hard to meet on embedded Ruckus firmware, and the botnet exploited that lag right after the PoC went public'; the NIST-800-53-SI-2 gap states any AP left on 10.4 or earlier 'was compromised faster than typical firmware patch cycles'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "Ruckus Wireless Admin is the device-management surface this control governs, and the defect sits on one of its endpoints: the web services login handler passes attacker-controlled credential parameters straight to a shell, so an unauthenticated HTTP GET to /forms/doLogin executes commands on the ZoneDirector, SmartZone or Solo AP. Bound to this product the control means that handler decides its caller's authorization before it processes the request at all, and neutralizes the parameter content before anything reaches a shell, so a command-substitution string in a credential field cannot select what the device executes; and that no unit is left with its management interface reachable from a segment with no operational need to reach it. This is precisely why the credential and admin-policy hardening CAF B4 examines cannot close the path — the payload runs before authentication, so no account model is ever consulted and a hardening attestation passes cleanly while the device is being taken over. Distinguishing test: from a client VLAN and from an external address, send the unauthenticated GET with a command-substitution payload in the credential parameters to a staging unit and confirm it is refused before any shell is invoked. Precondition: the endpoint-side authorization and input neutralization are properties the vendor firmware above 10.4 establishes — this control states what to verify, it does not implement it. Until that firmware and its reboot land, disabling the web services component is available only where the component is not operationally required, and isolating the management interface bounds who can send the request while leaving it fully exploitable to anything inside the permitted segment, which on a controller must still include its administrators and the APs it manages.",
+        "evidence": "Packet vector: 'Ruckus Wireless Admin through 10.4 allows Remote Code Execution via an unauthenticated HTTP GET Request, as demonstrated by a /forms/doLogin?login_username=admin&password=password$(curl substring.' affected: 'Ruckus Wireless access-point software (ZoneDirector, SmartZone, Solo APs), where the web services login handler passes attacker-controlled input to a shell, allowing unauthenticated command injection.' The UK-CAF-B4 gap states hardening 'credentials or admin policy does nothing because the payload executes before authentication, so only the vendor firmware fix or disabling web services closes it'; the NIS2-Art21-network-security gap states the component 'is reachable pre-authentication; exposing the AP management interface (rather than segregating it) lets an unauthenticated GET request inject shell commands, so network-security posture must include removing that exposure ahead of the firmware fix.' live_patch_notes names disabling the web services component or isolating the management interface as the interim mitigation, with fixed builds above 10.4 requiring a device reboot.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For CVE-2023-25717 this control is what separates 'firmware above 10.4 installed' from 'the access point is clean'. The packet records confirmed in-the-wild exploitation from early May 2023 by the AndoryuBot DDoS botnet, which enrols compromised Ruckus APs, and an attack path whose outcome is command execution and full control of the device — so any ZoneDirector, SmartZone or Solo AP that was reachable while running Ruckus Wireless Admin 10.4 or earlier has to be handled as a compromised host rather than as a patch item. Applied here that means capturing the running configuration for comparison rather than trusting it, restoring the unit to a known-good baseline instead of carrying its existing configuration forward through the firmware upgrade, and rotating the device's administrative credentials and any other secrets held in that configuration; the upgrade replaces the vulnerable login handler but removes nothing that the injected commands did before it landed, and the packet does not — and cannot — record what each compromised unit was left with. Distinguishing test: after remediation, compare the unit's running configuration and administrative accounts against the known-good baseline rather than confirming only that the firmware version is above 10.4. Precondition: this is a response control and it prevents nothing — it applies only to units identified as having been reachable during the exposure window, and identifying them depends on knowing which APs ran the affected admin software, which is the inventory the packet's own technical-vulnerability-management gap says is commonly missing.",
+        "evidence": "Packet active_exploitation 'confirmed' with active_exploitation_notes: 'Mass-exploited from early May 2023 by the AndoryuBot DDoS botnet (sold on Telegram; SOCKS5 C2, multi-protocol DDoS modules), which enrols compromised Ruckus APs... CISA added it to KEV on 2023-05-12.' attack_vector: 'the device executes the injected command, giving remote code execution and full control of the access point.' The NIST-800-53-SI-2 gap states 'any AP left on Ruckus Wireless Admin 10.4 or earlier was compromised faster than typical firmware patch cycles'; the AU-Essential-8-Patch gap states 'the botnet exploited that lag right after the PoC went public'. live_patch_notes give the remediation as firmware above 10.4 per security bulletin 315, requiring a device reboot, with no live-patch mechanism. The ISO-27001-2022-A.8.8 gap records that organizations 'may not track which Ruckus APs run the vulnerable 10.4-or-earlier admin software'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2021-3560": {
     "name": "Red Hat Polkit Incorrect Authorization Vulnerability",
@@ -64170,7 +65821,30 @@
         "adequate": false,
         "gap": "A.8.9 configuration management should baseline Tomcat without remote JMX or with tightly scoped access, but drift toward enabling JmxRemoteLifecycleListener for observability reopened the deserialization RCE on servers assumed to be patched."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "Tomcat's JmxRemoteLifecycleListener is exactly the binary remoting-protocol surface this control governs: JMX over RMI rather than HTTP, answering on ports that the servlet container's web-tier hardening and its HTTP-oriented perimeter rules never touch, with the deserialization of the incoming object being the vulnerable code itself. Bound to this product, the control means every Tomcat carrying that listener accepts JMX/RMI connections only from the monitoring and management hosts that legitimately poll it, enforced by host firewall or network ACL on the RMI registry and JMX server ports rather than inferred from 'the app server is internal', and that a KEV-listed defect in that listener is taken on an accelerated clock with the container restart rather than folded into the next application release. The packet gives two remediation forms with different residues: upgrading to 6.0.48 / 7.0.73 / 8.0.39 / 8.5.7 / 9.0.0.M12 keeps remote JMX and repairs the listener, while removing JmxRemoteLifecycleListener deletes the surface along with the remote monitoring built on it — choose per host and record which was applied. Two preconditions, both load-bearing. The packet records no host reboot but requires restarting the servlet container, so a Tomcat whose files were replaced or whose configuration was edited while the JVM keeps running is still serving the vulnerable listener and is not remediated. And the ACL bounds who can deliver the serialized gadget chain without repairing the deserialization: every monitoring host inside the permitted set, and anything that compromises one, still reaches it. Distinguishing test: from a general application or user VLAN on a staging server, connect to the RMI registry and JMX ports and confirm the connection is refused before the listener processes anything.",
+        "evidence": "The packet places the flaw in the optional JmxRemoteLifecycleListener, exploitable when the listener is used and an attacker can reach JMX ports, because that listener was not updated for consistency with the CVE-2016-3427 credential-type fix; the attack vector is a serialized Java gadget-chain object delivered over JMX causing unsafe deserialization and code execution in the Tomcat JVM. patch_available true with fixed releases 6.0.48 / 7.0.73 / 8.0.39 / 8.5.7 / 9.0.0.M12, live_patch_available false, patch_required_reboot false, and live_patch_notes recording remediation as the fixed release or removing JmxRemoteLifecycleListener, then restarting the servlet container. CISA KEV listing 2023-05-12 with confirmed exploitation and poc_available true, seven years after the 2016 disclosure — the packet attributes that to continued in-the-wild abuse of exposed JMX-enabled Tomcat servers. The CM-7 gap records the optional listener and its JMX/RMI ports being left reachable, the NIS2 network-security gap records JMX/RMI ports exposed beyond the management VLAN, and the CAF B4 gap records the opt-in listener being left enabled with reachable RMI ports.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "For this CVE a scan verdict keyed on the Tomcat version answers a narrower question than the estate needs. The packet states that exploitation requires the non-default JmxRemoteLifecycleListener plus reachable JMX ports — which narrows the population but yields full RCE where present — so which servers are in that population is a configuration and reachability fact, and the packet's configuration-management gap records baselines drifting into enabling the listener for observability. The operational test is therefore two-part per server: does the audit read the listener configuration of the running Tomcat and probe the RMI registry and JMX ports from outside the management segment, and does it record which of the two remediations the packet names was actually applied — the fixed release, or removal of JmxRemoteLifecycleListener — rather than reporting 'Tomcat patched' from a package version. That matters twice here. It names the servers that were in the exploitable set during the in-the-wild abuse the 2023-05-12 KEV listing reflects, and so warrant investigation rather than only upgrade; and it is the only way to confirm the listener-removal path was genuinely taken on hosts whose Tomcat version could not be moved, since that path leaves the version string unchanged and a version-keyed scan will report those hosts as vulnerable or as fixed entirely by coincidence. Precondition: the check has to interrogate the running container, because the packet's remediation requires a servlet-container restart — an edited configuration on a JVM that has not restarted still has the listener live, and a config-file-only audit scores it compliant while the port stays open.",
+        "evidence": "The packet's vector states remote code execution is possible if JmxRemoteLifecycleListener is used and an attacker can reach JMX ports, and its affected_versions list qualifies the 9.x entry as 'with JmxRemoteLifecycleListener enabled'; the exploitation notes state that exploitation requires the non-default listener plus reachable JMX ports, which narrows the population but yields full RCE where present. live_patch_available is false and remediation is recorded as the fixed release or removing the listener, then restarting the servlet container. The ISO-27001-2022-A.8.9 gap records configuration baselines drifting toward enabling JmxRemoteLifecycleListener for observability on servers assumed to be patched; the Essential-Eight application-hardening gap records environments that enabled remote JMX for monitoring without restricting the RMI ports remaining exploitable.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.9",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2023-29336": {
     "name": "Microsoft Win32K Privilege Escalation Vulnerability",
@@ -64231,7 +65905,30 @@
         "adequate": false,
         "gap": "A.8.8 vulnerability management may rank a 7.8 local LPE below network-facing CVEs, yet as a confirmed in-the-wild kernel escalation it warranted out-of-band patching that a CVSS-only prioritisation would defer."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows Win32k kernel-mode driver and describes a local attacker in an ordinary user context reclaiming freed window and menu objects to corrupt kernel memory, manipulate a process token and run as SYSTEM — the account is already legitimate, so no account model is being abused; a privilege boundary inside the kernel is failing. For this CVE the control means the May 2023 cumulative update is driven across the estate on the KEV clock that opened 2023-05-09 against the 2023-05-30 due date, rather than folded into the next monthly ring, with completion measured per host on the build actually running rather than on 'approved', 'downloaded' or 'installed' in the management console. The population to enumerate is not a server subset: the packet's own system-security gap records that every interactive Windows process can reach win32k, so every host in affected_versions — Windows 10 and Windows 11 clients, and Windows Server 2016, 2019 and 2022 — where an unprivileged user can execute code is in scope. patch_required_reboot is true and the packet records no vendor live-patch mechanism, so a host that installed the update through the servicing stack but has not restarted still executes the vulnerable Win32k and must be counted as exposed; on shared and always-on hosts that restart is the step most likely to be deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. The control's second half is load-bearing here: because the attacker is already executing as an authorized local user, tightening account privilege or hardening configuration does not contain the escalation — which is why system-security expectations can pass their attestation while the flaw stays fully exploitable. Priority follows the packet rather than the 7.8 band: a public PoC, confirmed in-the-wild exploitation as a zero-day, and the packet's note that this class is a post-access SYSTEM-escalation primitive paired with commodity loaders and info-stealers make it the containment step in a chain, not a standalone endpoint item.",
+        "evidence": "Packet fields: cwe_refs CWE-416; affected 'Windows Win32k kernel-mode driver, which contains a use-after-free (CWE-416) that a local attacker exploits to run code at SYSTEM'; attack_vector 'A local attacker with any user context exploits a use-after-free (CWE-416) in the Win32k kernel driver, reclaiming freed window/menu objects to corrupt kernel memory and manipulate a process token'; affected_versions 'Windows 10 and Windows 11 prior to the May 2023 cumulative update' and 'Windows Server (2016/2019/2022) prior to the May 2023 cumulative update'; cisa_kev true, kev_date 2023-05-09, active_exploitation_notes 'CISA added it to KEV on 2023-05-09 with a 2023-05-30 due date' and 'a classic post-access SYSTEM-escalation primitive used after initial code execution, frequently paired with commodity loaders and info-stealers'; poc_available true; patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires the May 2023 Windows cumulative update installed via the standard servicing stack, which requires a reboot.'; UK-CAF-B4 gap 'CAF B4 system-security hardening cannot mitigate a kernel use-after-free in a core graphics subsystem (win32k) that every interactive Windows process can reach; only the vendor patch removes the freed-object reuse.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "What this control changes for this CVE is the trigger, which is where the vulnerability-management gap on this entry actually sits: at CVSS 7.8 and classed as a local escalation, this Win32k flaw sorts below network-facing criticals in a severity-ranked queue and gets deferred, while the packet records it as a confirmed in-the-wild zero-day added to KEV on 2023-05-09 with a 2023-05-30 due date. The requirement is that the KEV listing, not the base score, starts the clock for the May 2023 cumulative update across Windows 10, Windows 11 and Windows Server 2016/2019/2022. The control admits patch, live patch or documented compensating controls as qualifying mitigations, and this entry is worth stating explicitly because two of the three are unavailable: live_patch_available is false and the packet records no vendor live-patch mechanism, and the packet's system-security gap records that hardening cannot mitigate the freed-object reuse and only the vendor patch removes it — so there is no configuration change or vendor mitigation rule to log as a compensating control. The consequence for the compliance record is the point: a host that cannot take the update and its required reboot inside the window is a dated, accepted exposure still carrying a working local-to-SYSTEM primitive, and recording it as 'mitigated' or 'compensating control in place' would be a false entry, because the packet supports no such control. Precondition on the clock itself: it is satisfied by the running build after restart, since the servicing-stack install alone leaves the vulnerable driver in memory.",
+        "evidence": "Packet fields: cvss 7.8; rwep_score 68; cisa_kev true with kev_date 2023-05-09; active_exploitation 'confirmed', notes 'Exploited in the wild as a local privilege-escalation zero-day and fixed in Microsoft's May 2023 Patch Tuesday; CISA added it to KEV on 2023-05-09 with a 2023-05-30 due date'; poc_available true; patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes 'No vendor live-patch mechanism; remediation requires the May 2023 Windows cumulative update installed via the standard servicing stack, which requires a reboot.'; ISO-27001-2022-A.8.8 gap 'A.8.8 vulnerability management may rank a 7.8 local LPE below network-facing CVEs, yet as a confirmed in-the-wild kernel escalation it warranted out-of-band patching that a CVSS-only prioritisation would defer.'; UK-CAF-B4 gap 'only the vendor patch removes the freed-object reuse'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-1389": {
     "name": "TP-Link Archer AX-21 Command Injection Vulnerability",
@@ -64468,7 +66165,31 @@
         "adequate": false,
         "gap": "A.8.22 network segregation would have isolated the WebLogic T3/IIOP ports from untrusted networks, but many deployments expose them flat; without segregation the unauthenticated JNDI class-load reaches the server, which A.8.8 patching alone would not prevent for unpatched hosts."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "Oracle WebLogic Server's T3 and IIOP naming service is the binary remoting listener this control governs: a non-HTTP endpoint that answers before authentication and whose own handling is the vulnerable code, so a perimeter that inspects HTTP and a WAF fronting the web tier never see the request that binds the JNDI reference. For WebLogic 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0 the requirement is that the T3 and IIOP ports accept connections only from hosts that legitimately speak them — the admin/managed-server mesh and the specific clients that use T3 or IIOP — enforced by network ACL or host firewall rather than assumed from 'WebLogic sits behind the load balancer', and that the Oracle January 2023 Critical Patch Update be applied on an accelerated clock with the WebLogic domain-services restart taken. live_patch_available is false and live_patch_notes records that the update restarts the domain services (no host reboot), so a domain that staged the CPU without that restart is still running the vulnerable code, and patch_required_reboot being false must not be read as 'nothing to restart'. The distinguishing test for this product: from a DMZ or general user segment against a staging domain, open a T3 and an IIOP connection and confirm both are dropped before the naming service answers — an estate that passes WebLogic role, credential and HTTP-hardening audits while leaving T3/IIOP reachable is fully exposed to the unauthenticated remote class-load. Precondition: the ACL bounds who can present the request, it does not repair the JNDI handling, so any compromised host inside the permitted segment still reaches it, and where T3 or IIOP must remain reachable for a legitimate client the only closure is the CPU plus the restart.",
+        "evidence": "Packet vector: an unauthenticated attacker with network access via T3, IIOP compromises Oracle WebLogic Server; CVSS 3.1 base score 7.5, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. affected_versions: WebLogic 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0. attack_vector: over T3/IIOP the attacker binds a JNDI reference so a subsequent lookup makes WebLogic fetch and execute a remote class from an attacker LDAP/RMI server. CISA KEV 2023-05-01 with active_exploitation confirmed, mass exploitation and a near-maximal EPSS noted, and poc_available true. The NIST-800-53-SC-7 gap records that WebLogic frequently exposes the T3/IIOP naming ports by default and a perimeter guarding only HTTP misses them; the ISO-27001-2022-A.8.22 gap records deployments exposing them flat without segregation; the NIS2-Art21-network-security gap records that network-security measures rarely restrict the proprietary T3/IIOP channels even where HTTP is fronted by a WAF; the UK-CAF-B4 gap records that baselines hardening HTTP endpoints do not close the IIOP naming service. live_patch_available false; live_patch_notes: the January 2023 Critical Patch Update restarts the WebLogic domain services, no host reboot required.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "ISO-27001-2022-A.8.22",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records mass exploitation of internet-exposed WebLogic after the January 2023 Critical Patch Update and the public proof-of-concept, with opportunistic actors deploying crypto-miners and web shells. Applying the CPU closes the T3/IIOP class-load path; it removes nothing already written while the server was executing attacker-supplied classes — a web shell under the domain's application or staging directories, an installed miner, a scheduled job, an added account or key, or a credential read out of the domain's configuration. So for any WebLogic 12.2.1.3.0, 12.2.1.4.0 or 14.1.1.0.0 domain that was reachable on T3 or IIOP from an untrusted network during the window that was already open at the KEV listing of 2023-05-01, the default disposition is to preserve the configuration for analysis, rebuild the server from a known-good deployment, and rotate the credentials the domain held — datasource and JMS credentials, the domain administrative account, and keystore material — rather than apply the CPU in place and close the finding on the patch record. Precondition: this is a disposition rule for hosts already exposed, not a mitigation, and it gives nothing to a domain that was never reachable; it also depends on being able to tell the two apart, so a domain with no record of which segments could reach its T3/IIOP ports must be treated as exposed rather than assumed clean.",
+        "evidence": "Packet: active_exploitation confirmed; active_exploitation_notes state the CVE was mass-exploited, that CISA added it to KEV on 2023-05-01, that it carries a near-maximal EPSS, and that after the January 2023 CPU and public PoC release opportunistic actors weaponized the T3/IIOP JNDI vector against internet-exposed WebLogic servers to deploy crypto-miners and web shells. poc_available true; RWEP 72; CVSS 7.5. attack_vector: the JNDI reference causes WebLogic to fetch and execute a remote class from an attacker LDAP/RMI server. affected_versions 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0. live_patch_available false; live_patch_notes: remediation is the Oracle January 2023 Critical Patch Update, which restarts the WebLogic domain services. The AU-Essential-8-Patch gap records that estates missing the 48-hour window for exploited internet-facing services were mass-exploited around the 2023-05-01 KEV date.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-28432": {
     "name": "MinIO Information Disclosure Vulnerability",
@@ -64871,7 +66592,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management may treat a local-only macOS escalation as low priority, but as a KEV-listed in-the-wild bug it warranted expedited handling, exposing a gap between CVSS-driven triage and real exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For CVE-2019-8526 the enforcement target is the managed macOS estate, and the only remediation the packet records is moving each Mac to macOS Mojave 10.14.4 or later — there is no live-patch path and the upgrade reboots the machine. Applied to this CVE the control means that upgrade is driven on the clock that opened with the 2023-04-17 KEV listing rather than folded into the next compatibility-tested image refresh, with user deferral disallowed, and with completion measured per Mac against the build it is actually booted into: a machine that has staged the 10.14.4 upgrade but has not restarted is still executing the vulnerable code and counts as exposed, not as patched. Priority has to follow the packet rather than the CVSS band — poc_available is false and the packet notes EPSS is modest because this is a local privilege-escalation stage rather than a remote entry point, yet active_exploitation is confirmed and the entry is KEV-listed, which is exactly the triage split the ISO A.8.8 gap describes. Precondition: this reaches only Macs the management platform can actually enforce against, and it gives nothing for a Mac deliberately held below 10.14.4 because an application will not run on the fixed build — that population is the access-condition case, not the SLA case.",
+        "evidence": "Packet records cisa_kev true with kev_date 2023-04-17 and active_exploitation 'confirmed'; patch_available true, live_patch_available false, patch_required_reboot true, and live_patch_notes: 'No live-patch mechanism for macOS; remediation requires upgrading to macOS Mojave 10.14.4 (or later), which reboots the system.' affected_versions is 'Apple macOS before Mojave 10.14.4'. poc_available false, CVSS 7.8, RWEP 48, and active_exploitation_notes state EPSS is modest (~0.7%) because this is a local privilege-escalation stage. The AU-Essential-8-Patch gap records macOS point-release upgrades commonly deferred for compatibility testing so the fixed 10.14.4 build routinely lands after the one-month SLA; the NIS2-Art21-patch-management gap records endpoints held back on older macOS staying exploitable well past the 2023-04-17 KEV listing; the ISO-27001-2022-A.8.8 gap records CVSS-driven triage treating a local-only escalation as low priority.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records for CVE-2019-8526 is a local application: an application running on the Mac reaches a use-after-free and comes away with rights above its assigned user context. For the Macs an estate cannot move to macOS Mojave 10.14.4 — held back for application compatibility, which both the Essential-Eight and NIS2 gaps name as the reason the fix lands late — the two levers left are constraining what code is permitted to run on the machine at all, and making the fixed build an access condition rather than a dashboard row: a Mac below 10.14.4 is denied mail, VPN and document access until it is at or above the fix. This is the half AC-6 cannot supply, because the escalation happens inside macOS and no privilege scoping applied to the user's account contains it once the application executes, and the half CAF B4 cannot supply, because MDM hardening leaves the vulnerable code path in place. Distinguishing test: enrol a Mac pinned below 10.14.4 and confirm policy actually denies it access to protected resources — an estate that surfaces the stale build on a report while the Mac keeps its access has recorded the exposure rather than removed it. Precondition: restricting which applications may be installed and run raises the bar for getting the triggering application onto the Mac, but it does not evict one already installed and does nothing against one arriving through a channel the policy already trusts; a Mac suspected of having run such an application belongs on the incident path, since the packet records confirmed in-the-wild exploitation. This is a holding measure for the window before the 10.14.4 upgrade and its reboot land, not a substitute for them.",
+        "evidence": "Packet vector: 'A use after free issue was addressed with improved memory management. This issue is fixed in macOS Mojave 10.14.4. An application may be able to gain elevated privileges.' attack_vector: 'A local application triggers a use-after-free in macOS; reusing the freed object corrupts memory in a way that grants the app elevated privileges beyond its user context.' The NIST-800-53-AC-6 gap states least privilege 'cannot contain a use-after-free that yields elevated privileges within macOS itself... defeating the privilege boundary AC-6 relies on'; the UK-CAF-B4 gap states endpoint system security 'cannot remediate an OS memory-management flaw through configuration; MDM hardening does not remove the vulnerable code path fixed only in macOS 10.14.4'; the AU-Essential-8-Patch gap records point-release upgrades deferred for compatibility testing. active_exploitation is 'confirmed' (KEV 2023-04-17); patch_required_reboot true with no live-patch mechanism.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-2033": {
     "name": "Google Chromium V8 Type Confusion Vulnerability (CVE-2023-2033)",
@@ -65090,7 +66835,29 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management depends on inventorying the Novi Survey deployment; where such a niche app is untracked, the KEV-listed preauth deserialization RCE persists unpatched despite the April 2023 fix."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Novi Survey is the deployment shape this SLA exists to override. The packet's own gaps record it being handled as a low-criticality survey web application on a routine cycle, while the defect is an unauthenticated deserialization that gives arbitrary code execution as the service account to anyone who can reach the site. For this CVE the control means the clock runs from the 2023-04-13 KEV listing rather than from the next application-maintenance window, and completion is measured by the running Novi Survey service reporting 8.9.43676 or later — not by the upgrade being staged or approved. The packet records no host reboot but does record that remediation is upgrading to 8.9.43676 or later and restarting the application service, so an instance whose files were replaced while the service kept running is still executing the vulnerable deserialization path and counts as exposed; that restart is the completion criterion. Precondition on the interim window: live_patch_available is false and the packet names no vendor mitigation rule, so between the KEV listing and that restart the only operator-side lever is removing the site's reachability from untrusted networks. That bounds who can deliver the serialized object without repairing the deserialization, and it is unavailable where the survey site exists precisely to take responses from an untrusted population — for those instances there is no interim state, only the upgrade.",
+        "evidence": "CISA KEV listing 2023-04-13 with active_exploitation confirmed and CVSS 9.8; patch_available true with the fix recorded as Novi Survey 8.9.43676 or later per the vendor advisory; live_patch_available false and patch_required_reboot false, with the packet's live_patch_notes stating remediation requires upgrading and restarting the application service. The attack vector is an unauthenticated crafted serialized object deserialized without validation, executing arbitrary code as the service account. The cited SI-2 gap records that flaw remediation only applies after 8.9.43676 is deployed and that any patch lag leaves an unauthenticated code-execution path open; the NIS2 patch-management gap records the app being treated as low-criticality despite a KEV-listed CVSS 9.8 preauth RCE; the Essential-Eight gap records the 48-hour internet-facing target being missed because a self-hosted survey platform is easily overlooked.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet has this exploited in the wild by the KEV date, and the exploit outcome is attacker code running as the Novi Survey service account on the host. The upgrade to 8.9.43676 replaces the vulnerable deserialization path and removes nothing that ran through it, so for any Novi Survey instance that was reachable from untrusted networks while below 8.9.43676 after 2023-04-13, the default disposition is rebuild from a known-good image with the service account's credential rotated — not upgrade-in-place followed by closing the flaw-remediation ticket. Scope the rebuild to what the packet establishes and no further: the vendor states that code execution does not itself grant access to stored survey or response data, so this is a host and service-account compromise question, and asserting that the response corpus was read goes beyond the packet. Precondition: the rebuild default applies to instances whose exposure window can be established from the site's reachability and its upgrade date. Where those cannot place an instance outside the window, confirmed in-the-wild exploitation of a preauth path makes 'assume clean' the weaker default; and note that no standalone public PoC is recorded for this CVE, so absence of a matching public exploit artifact in logs is not evidence the instance was not reached.",
+        "evidence": "active_exploitation confirmed, CISA KEV listing 2023-04-13, CVSS 9.8, RWEP 48, poc_available false with the packet noting no standalone public PoC is known. The packet's exploitation notes state that an unauthenticated attacker sends a crafted serialized object the server insecurely deserializes, executing code in the context of the service account, and that per the vendor this does not itself grant access to stored survey/response data but provides a foothold on the host. patch_available true (8.9.43676) with live_patch_available false. The SI-2 gap records that the flaw-remediation control only engages once 8.9.43676 is deployed — which is exactly the interval in which the preauth code-execution path was already in use.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-28252": {
     "name": "Microsoft Windows Common Log File System (CLFS) Driver Privilege Escalation Vulnerability (CVE-2023-28252)",
@@ -65235,7 +67002,41 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management prioritizes CVE-2023-28205 once KEV-listed, but because the exploit predates the advisory only prompt emergency-update deployment (and Lockdown Mode for at-risk users) actually closes the WebKit RCE."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "This is an Apple-estate CVE with an emergency vendor release, so the control applies directly — but its scope has to come from the packet's affected list, not from the word 'Safari', or the sweep reports clean on the devices most likely to be behind. Four fixed builds are in scope: iOS and iPadOS 16.4.1 for devices on the 16 branch, iOS and iPadOS 15.7.5 for those held on the 15 branch, macOS Ventura 13.3.1, and Safari 16.4.1, which ships as its own update rather than inside an OS build. Drive all four through device management on the clock that opened with the 2023-04-10 KEV listing, against a fix Apple released on 2023-04-07, with user deferral disallowed rather than merely discouraged — the packet describes exploitation as a stage in a commercial-spyware chain, and the population being targeted is exactly the population that defers updates because the device is in constant use. Completion must be measured on the build the device is actually executing: patch_required_reboot is true and the packet records the fix applying only through an OS or Safari update requiring a device restart, with no live-patch mechanism, so a device that has downloaded the update and not restarted is still rendering web content through the vulnerable WebKit and must be counted as exposed rather than as compliant. Precondition: this reaches supervised and enrolled devices only. A personally-owned handset, a contractor's laptop, or any device outside enrolment renders the same crafted web content and is untouched by a management push — those need the access-condition treatment instead, and counting them as out of scope rather than as unremediated is how this control gets reported green over an exposed estate.",
+        "evidence": "Packet fields for CVE-2023-28205: affected identifies Apple WebKit as used by Safari and WebKit-based HTML parsers across iOS, iPadOS and macOS; affected_versions lists Apple iOS/iPadOS < 16.4.1 (and < 15.7.5), macOS Ventura < 13.3.1, and Safari < 16.4.1; vector states the issue is fixed in Safari 16.4.1, iOS 15.7.5 and iPadOS 15.7.5, iOS 16.4.1 and iPadOS 16.4.1, macOS Ventura 13.3.1, that processing maliciously crafted web content may lead to arbitrary code execution, and that Apple is aware of a report that this issue may have been actively exploited; active_exploitation_notes record Apple's April 7, 2023 emergency updates and CISA KEV addition on 2023-04-10; patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes stating Apple ships the fix in an OS/Safari update requiring a device restart to apply; cvss 8.8; rwep_score 52.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet's attribution is what makes this control the one that matters on this CVE: Google TAG and Amnesty tie the flaw to a commercial-spyware exploit chain used against targeted individuals, Apple acknowledged a report of active exploitation, and no public proof-of-concept was released. That profile means the exposed population is not the whole estate — it is the people a mercenary-spyware customer pays to target — and the delivery path is attacker-controlled web content rendered by WebKit, which every affected device does by design. For that cohort the reboot-gated emergency update is not fast enough on its own, because the packet records exploitation preceding both the 2023-04-07 fix and the 2023-04-10 KEV listing. Identify the cohort in advance — executives, journalists, legal and security staff, anyone handling sensitive negotiations or at-risk sources — and place them in Apple's reduced-attack-surface mode, which the packet's own technical-vulnerability gap names as Lockdown Mode for at-risk users, so untrusted web content, message attachments and link previews are not processed on the normal path. It only works as a standing posture assigned before the next disclosure: the mode has to have been on when the chain arrived, and assigning it in response to this CVE protects nobody against this CVE. Precondition, stated plainly because this control is easy to over-claim: the mode narrows what reaches WebKit, it does not remove the use-after-free and does not make the device patched. It does nothing for a targeted user who is not in the cohort you defined, it does not cover a WebKit-based parser reached outside the paths the mode restricts, and it does not evict an implant already delivered — a device in the targeted set that rendered untrusted content while below the fixed build belongs on the incident path, not on the mitigation record.",
+        "evidence": "Packet fields for CVE-2023-28205: active_exploitation_notes state that the Google TAG / Amnesty attribution ties it to a commercial-spyware exploit chain used against targeted individuals, that Apple acknowledged a report of active exploitation, that the fix shipped in Apple's April 7, 2023 emergency updates and KEV listing followed on 2023-04-10, and that no public PoC was released (poc_available false); attack_vector describes the use-after-free being triggered when Safari or a WebKit-based parser processes maliciously crafted web content, yielding a code-execution primitive in the renderer as a stage in a commercial-spyware browser exploit chain; framework_control_gaps ISO-27001-2022-A.8.8 records that because the exploit predates the advisory, only prompt emergency-update deployment and Lockdown Mode for at-risk users actually close the WebKit RCE; framework_control_gaps UK-CAF-B4 records that endpoint hardening does not neutralize the flaw and the renderer sandbox only raises exploit cost; patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "On this CVE the access-condition half of this control is the load-bearing half, and the install-policy half does not apply — the packet's trigger is maliciously crafted web content processed by WebKit, not a malicious application, so restricting untrusted or side-loaded application installation gives nothing here; the browser and every WebKit-based parser on the device render attacker-supplied content by design. What the control means for this estate is that the fixed build functions as a condition of access rather than as a row on a patch-compliance report: a device below iOS or iPadOS 16.4.1 (or 15.7.5 on the 15 branch), below macOS Ventura 13.3.1, or running Safari below 16.4.1 is denied mail, VPN and document access until it is at or above that build. That is the only lever that reaches the population a management push cannot force — unenrolled and personally-owned devices, and devices deliberately held on the iOS 15 branch for application compatibility, which the packet shows Apple treated as in scope by shipping 15.7.5 alongside 16.4.1. The condition must key on the build the device is running after the restart, since the packet records the fix applying only through an update requiring a device restart and no live-patch path; a device reporting a downloaded-but-not-applied update satisfies a dashboard, not this control. Distinguishing test: enrol a device pinned below the fixed build and confirm the policy actually denies it access to protected resources — an estate that surfaces the stale build on a report while the device keeps its mail and VPN has recorded the exposure rather than removed it. Precondition: this is a holding measure for the window before the fixed build and its restart land, not a substitute for them, and it protects organizational data on the device rather than the device itself — a targeted user's personal browsing on that same handset still reaches the vulnerable WebKit.",
+        "evidence": "Packet fields for CVE-2023-28205: affected_versions list Apple iOS/iPadOS < 16.4.1 (and < 15.7.5), macOS Ventura < 13.3.1, and Safari < 16.4.1; vector states the issue is fixed in Safari 16.4.1, iOS 15.7.5 and iPadOS 15.7.5, iOS 16.4.1 and iPadOS 16.4.1, macOS Ventura 13.3.1, and that processing maliciously crafted web content may lead to arbitrary code execution; affected identifies WebKit as used by Safari and WebKit-based HTML parsers across iOS, iPadOS and macOS; patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes stating Apple ships the fix in an OS/Safari update requiring a device restart to apply; framework_control_gaps NIS2-Art21-patch-management records that mobile fleets deferring iOS 16.4.1 stayed exposed to a WebKit RCE reachable from any crafted page; cisa_kev true, kev_date 2023-04-10.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-28206": {
     "name": "Apple iOS, iPadOS, and macOS IOSurfaceAccelerator Out-of-Bounds Write Vulnerability",
@@ -65972,7 +67773,42 @@
         "adequate": false,
         "gap": "A.8.9 configuration management is the miss here: leaving writable shares and named-pipe execution enabled by default is an insecure baseline, so an ISMS that never hardened the Samba config left the SambaCry path open even where the software was otherwise current."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "Samba is the case this control's middle state exists for, because the packet names a configuration-side mitigation alongside the vendor fix. live_patch_notes gives three dispositions: upgrade to Samba 4.4.14 / 4.5.10 / 4.6.4 or later and restart smbd; apply the 'nt pipe support = no' workaround; or, on embedded NAS/IoT devices, depend on a vendor firmware update. A host running with 'nt pipe support = no' is in the mitigation-active state, not the patched state — the named-pipe-to-dlopen path is closed by a configuration setting that a firmware factory reset, a package upgrade restoring a default smb.conf, or a vendor configuration restore silently reverts, with nothing re-checking it — so it must carry a time-bound action to reach the fixed Samba build rather than being reported as patched per SLA. A NAS or embedded appliance whose vendor has shipped no firmware carrying the fix is in the third state, full exposure, and must be reported as such. Note the restart trap the packet records: patch_required_reboot is false, meaning no machine reboot, but live_patch_notes requires smbd to be restarted, so a host that installed the fixed package while the old smbd process is still serving belongs in neither the patched nor the mitigated column. The distinguishing test is per host: report the running smbd version, whether 'nt pipe support' is disabled, and whether write access to shares was removed — an ISMS carrying one 'SambaCry remediated' line over a mixed estate is recording three different exposures as one.",
+        "evidence": "Packet: live_patch_notes states there is no live-patch mechanism and that remediation is upgrading to Samba 4.4.14 / 4.5.10 / 4.6.4 (or later) and restarting smbd, or applying the 'nt pipe support = no' workaround, with embedded NAS/IoT devices often depending on a vendor firmware update instead. patch_available true, live_patch_available false, patch_required_reboot false. The NIST-800-53-CM-7 gap names Samba's own workaround as 'nt pipe support = no' plus removing writable-share access, and records that default configurations left the named-pipe-to-filesystem path enabled; the ISO-27001-2022-A.8.9 gap records that leaving writable shares and named-pipe execution enabled by default is an insecure baseline that an ISMS never hardened; the NIS2-Art21-patch-management gap records embedded NAS/IoT firmware with no vendor patch, so the fixed Samba releases never reach those hosts. CISA KEV 2023-03-30, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 76.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.9",
+          "NIST-800-53-CM-7",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "The packet names embedded NAS and IoT devices as the bulk of the exposed Samba population, and those devices are exactly what this control governs: an appliance whose function is holding the data on the very share the attacker must write to, reachable from untrusted networks. Applied here it means the SMB service on those appliances answers only from the client segment that legitimately mounts the shares — never from the internet through a router port-forward or UPnP mapping, and never from a general user VLAN with no need for the data — and the appliance's outbound path is constrained so a compromised device cannot reach arbitrary destinations with the data it holds. Reachability plus write access to a share is the entire exploit precondition per the packet's attack vector, and on a NAS whose vendor has shipped no firmware carrying the Samba fix, restricting reachability is the only lever the operator holds. Precondition, and it is the part most often over-claimed: an SMB file server exists to serve its clients, so isolation removes internet and untrusted-segment exposure but removes nothing for a client inside the permitted segment — any host there that holds write access to a share still satisfies the precondition in full. Inside that segment the remaining lever is the one the packet's own gap names, removing writable-share and anonymous/guest write access, and neither measure evicts an attacker who already exploited the device. The distinguishing test: from an external address and from a general user VLAN, attempt to reach TCP/445 on each NAS; anything that answers is within reach of the published single-request exploit, and 'the NAS is on the internal network' is a claim about topology, not a demonstration.",
+        "evidence": "Packet: active_exploitation_notes record confirmed exploitation since 2017 by cryptomining botnets such as EternalMiner and other campaigns targeting internet-exposed Samba on NAS/IoT, with a single-request Metasploit module making mass exploitation of writable-share Samba hosts trivial. attack_vector: a client with write access to an SMB share uploads a .so payload and opens a named pipe whose path resolves to that file, so smbd calls dlopen on it. live_patch_notes record that embedded NAS/IoT devices often depend on a vendor firmware update instead of the Samba upgrade. The AU-Essential-8-Patch gap records internet-facing Samba on unmanaged NAS/embedded devices sitting outside the fleet update process; the NIS2-Art21-patch-management gap records that much of the exposed population is embedded NAS/IoT firmware with no vendor patch; the UK-CAF-B4 gap records that system security should have restricted anonymous/guest write to shares. poc_available true, CVSS 9.8, KEV 2023-03-30.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The uploaded shared library is loaded inside smbd, so per the packet's attack vector the injected code runs as the Samba service user, commonly root, on hosts the packet records as exploited in the wild since 2017 and flagged by KEV for known ransomware use. Upgrading to Samba 4.4.14 / 4.5.10 / 4.6.4 and restarting smbd closes the load path and removes nothing already placed through it: the uploaded .so, any miner or service it started, any account or key added, and any credential the host held remain exactly where the attacker left them. So for any Samba host or NAS that ran an affected build — 3.5.0 through before 4.4.14, 4.5.10 and 4.6.4 — while reachable from an untrusted network with a writable share, the default disposition is to capture the configuration for analysis, rebuild from a known-good image, and rotate every credential the host held or that transited it, rather than patch in place and close the finding on the version number. Precondition: this is a disposition rule for hosts already exposed, not a mitigation — it lowers no exploitation probability, and it depends on being able to distinguish exposed from not, so a host with no record of who could reach TCP/445 and no record of share write permissions has to be treated as exposed. Second precondition specific to the embedded population: where the packet records devices depending on a vendor firmware update, a rebuild restores the same vulnerable Samba code, so rebuild only completes the remediation when paired with firmware carrying the fix or with isolation — and whether such firmware exists for a given model is a question for that device's vendor, not one this entry answers.",
+        "evidence": "Packet: active_exploitation confirmed, with active_exploitation_notes recording exploitation in the wild since 2017 by cryptomining botnets such as EternalMiner and campaigns targeting internet-exposed Samba on NAS/IoT, and KEV flagging ransomware use as Known; CISA KEV 2023-03-30; poc_available true with a single-request Metasploit module noted; RWEP 76, CVSS 9.8. attack_vector: smbd calls dlopen on the uploaded library and executes the code as the Samba service user, commonly root. affected_versions: Samba 3.5.0 through versions before 4.4.14, 4.5.10 and 4.6.4. live_patch_notes: no live-patch mechanism; remediation is the upgrade plus an smbd restart, with embedded NAS/IoT devices often depending on a vendor firmware update instead. The AU-Essential-8-Patch gap records a wormable pre-auth RCE left unpatched for years after the KEV listing.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2022-42948": {
     "name": "Fortra Cobalt Strike User Interface Remote Code Execution Vulnerability",
@@ -66285,7 +68121,34 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management struggles because the vulnerable component is a hardware GPU driver whose fix ships on OEM schedules; risk-rated patching cannot close a CVSS 8.8 kernel UAF when the fixed r40p0 driver is not yet available for the device model."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The vulnerable component is the Arm Mali GPU kernel driver on handsets — Bifrost r0p0 through r38p1 and r39p0, Valhall r19p0 through r38p1 and r39p0, and Midgard r4p0 through r32p0 — and the fixed r40p0 driver reaches a device only when its OEM ships a firmware/OS update, which the packet records as installing with a reboot. Because the operator cannot deliver that fix, the enforceable form of this control is the access-condition half: a handset whose running Mali driver revision is below r40p0 is denied organizational mail, VPN and document access until the OEM build carrying the fix is installed AND the device has restarted onto it. patch_required_reboot is true and live_patch_available is false, so a device that has downloaded the OEM update but not restarted is still executing the vulnerable driver and must not be counted as remediated. The distinguishing test is to enrol a device on an OEM build below the fix and confirm policy actually denies it protected resources — an estate that shows the stale driver revision on a compliance report while the device keeps its access has recorded the exposure rather than removed it. Precondition on the second half: restricting which applications may install raises the bar on getting the unprivileged app onto the device, but it does not evict an application already installed, and it does not cover code arriving through the browser/renderer foothold the packet describes this use-after-free being chained behind. A device suspected of already having run such code belongs on the incident path, not the install-policy path.",
+        "evidence": "Packet: CISA KEV 2023-03-30, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 71. patch_available true with patch_required_reboot true and live_patch_available false; live_patch_notes states remediation is the fixed Arm Mali GPU kernel driver (r40p0 or later) delivered through the device OEM's firmware/OS update, which installs with a reboot. affected_versions list Bifrost r0p0 through r38p1 and r39p0, Valhall r19p0 through r38p1 and r39p0, Midgard r4p0 through r32p0. The NIS2-Art21-patch-management gap records that organizations could not directly remediate and depended on carrier/OEM update timelines; the ISO-27001-2022-A.8.8 gap records that the fixed r40p0 driver is not yet available for some device models; the UK-CAF-B4 gap records that the use-after-free lets an unprivileged app reach root, breaking the sandbox boundary mobile baselines rely on. active_exploitation_notes place it as the local privilege-escalation step in a mobile spyware chain, chained after an initial browser/renderer foothold.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "For this CVE the handset population splits by device model, and the compliance verdict has to state which state each device is in rather than carrying one open remediation ticket for the fleet. The packet records no live-patch path and names no configuration-side workaround: the trigger is mishandled GPU memory operations reached through ordinary unprivileged GPU use, so there is no feature to disable and no vendor mitigation rule to run. That means a handset whose OEM has not shipped a build carrying r40p0 sits in the third state — no mitigation and no patch, full exposure — and must be reported that way, with a dated action, instead of as 'patch scheduled' or an untimed risk acceptance against a KEV-listed, actively exploited root escalation. Only a device that has received the OEM build and restarted onto it is in the patched state; patch_required_reboot is true, so a downloaded-but-not-restarted device belongs in the exposed column. The distinguishing test: produce the per-device running Mali driver revision and its state rather than a fleet-level patch percentage — a dashboard reporting 'patching in progress' for models whose OEM never shipped the fixed driver is asserting an SLA that cannot be met, which is the specific way this remediation is recorded as complete while every affected handset stays exploitable.",
+        "evidence": "Packet: patch_available true but, per live_patch_notes, delivered only through the device OEM's firmware/OS update, with live_patch_available false and patch_required_reboot true. The ISO-27001-2022-A.8.8 gap states risk-rated patching cannot close a CVSS 8.8 kernel use-after-free when the fixed r40p0 driver is not yet available for the device model; the NIS2-Art21-patch-management gap states the patch is gated on OEM firmware releases and operators depended on carrier/OEM timelines; the AU-Essential-8-Patch gap states driver revisions r38p1/r39p0 stayed deployed past the fix during the in-the-wild campaign. CISA KEV 2023-03-30 with active_exploitation confirmed and poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-0266": {
     "name": "Linux Kernel Use-After-Free Vulnerability",
@@ -66346,7 +68209,39 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management flags the KEV entry, yet the practical exposure is the reboot-deferred kernel-update window during which a local use-after-free continues to grant ring0 escalation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-002",
+        "name": "LIVE-PATCH-CAPABILITY",
+        "description": "The residual exposure of this Linux kernel flaw on a production estate is the reboot-deferred window, and the packet is unusually explicit about what could shorten it: no live patch shipped with the fix, but kpatch, Canonical Livepatch and Ksplice can in principle carry the sound/core/control.c rwsem-lock change without a reboot on supported distributions. For this CVE the control means that capability is already deployed and exercised on hosts that cannot absorb an unplanned reboot before the next kernel local-privilege-escalation lands — multi-user and shared hosts first, because there the precondition this flaw needs is the normal operating state rather than an anomaly: an ordinary local user who can open an ALSA control device and call SNDRV_CTL_IOCTL_ELEM_READ/WRITE32 wins ring0 through the missing lock. A capability stood up in response to a listing arrives after the window it was meant to cover. Precondition, and it is the whole of this control's honesty on this entry: 'in principle' is not 'shipped'. The lever exists only where the distribution's live-patch vendor actually published a patch carrying this specific control.c change, and the packet records that none shipped with the fix, so on any host where that is the case the canonical remediation stands unchanged — a kernel past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e plus a reboot. Completion is measured on the kernel the host is executing: a host with the fixed package installed and the old kernel still running is exposed, not patched, and this control does nothing to change that.",
+        "evidence": "live_patch_available is false and live_patch_notes state: 'No vendor live-patch was shipped with the fix; kernel live-patching frameworks (kpatch, Canonical Livepatch, Ksplice) can in principle apply the control.c rwsem-lock fix without reboot on supported distributions, but the canonical remediation is the fixed kernel (past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e) plus a reboot.' patch_available is true with patch_required_reboot true. The affected summary places the defect in the Linux kernel ALSA PCM subsystem where 'SNDRV_CTL_IOCTL_ELEM_READ/WRITE32 in sound/core/control.c miss the read-write semaphore, creating a use-after-free race that escalates a local user to ring0', with active_exploitation 'confirmed' and KEV listing 2023-03-30. The three gaps this attaches to name the same window: the NIS2 gap that kernel patch management 'is reboot-gated and slow' leaving hosts 'awaiting a maintenance window', the Essential Eight gap that 'kernel patching requires a reboot and is often deferred', and the A.8.8 gap that 'the practical exposure is the reboot-deferred kernel-update window during which a local use-after-free continues to grant ring0 escalation'.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-009",
+        "name": "KERNEL-MODULE-INVENTORY-AND-DISABLE",
+        "description": "The reachable surface for this CVE is the ALSA control device. The packet's attack path is a local user invoking SNDRV_CTL_IOCTL_ELEM_READ/WRITE32 against it, and the missing read-write semaphore in sound/core/control.c turns that call into a use-after-free race that is groomed into a kernel read/write primitive. So the inventory question this control asks, bound to this CVE, is which hosts have the ALSA sound modules present at all: on a server with no audio function, snd and snd-pcm and the control device they create are attack surface carrying no business purpose, and a host where they are neither loaded nor loadable does not offer the vulnerable ioctl to a local user in the first place. This is the complement of the least-privilege control cited as insufficient on this entry — the attacker uses an ordinary unprivileged account exactly as intended, so no account scoping is ever consulted, and the only operator-side lever short of the kernel fix is whether the call can be made. Two preconditions decide whether this is worth anything on a given host, and both must be checked per host rather than assumed for the fleet. A modprobe blacklist only prevents a future autoload: where the modules are already loaded, or are built into the running kernel image, the blacklist changes nothing, and the remaining levers are unloading them or booting a kernel that does not include them. And on any host that legitimately plays audio — every workstation, and any machine running the browser session the entry's own CAF-B4 gap names as a plausible foothold — the modules cannot be removed and this control is unavailable, leaving those hosts with the fixed kernel and its reboot as the only path. Narrowing who can reach the ioctl is not repairing the lock.",
+        "evidence": "The packet's attack_vector reads: 'A local user invokes SNDRV_CTL_IOCTL_ELEM_READ/WRITE32 on an ALSA control device; missing rwsem locking in snd_ctl_elem_read creates a use-after-free race that is groomed into a kernel read/write primitive, escalating from system user to ring0.' The affected summary names the Linux kernel ALSA PCM subsystem and sound/core/control.c. The cited AC-6 gap states that least privilege 'assumes the OS enforces the user/kernel boundary, but this ALSA PCM use-after-free lets any local system user race to ring0, so least-privilege account design gives no protection once the vulnerable ioctl is reachable — only the fixed kernel restores the boundary'. The CAF-B4 gap records that hardening 'can narrow reach to the ioctl but does not fix the missing rwsem lock; a local attacker or a browser-renderer foothold that can call the ALSA control ioctl still wins ring0 until the kernel is patched'. patch_available is true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "Two properties of this specific kernel CVE make a package-version verdict wrong. The fix is identified by a commit rather than a release: the packet's remediation is a kernel past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e while affected versions are recorded as 'Linux kernel through 6.1.6', so a scanner comparing an upstream version number against a distribution kernel that carries the change as a backport reads the wrong answer in both directions — a backported vendor kernel numbered below 6.1.6 is reported vulnerable when it is fixed, and a kernel numbered above it without the backport is reported fixed when it is not. And the remediation is reboot-gated with no live patch shipped, so a host whose package database shows the fixed kernel while it is still executing the old one will be reported patched while a local user can still race to ring0. The operational test for this entry, then: does the scan report the kernel the host is currently executing rather than the newest kernel package installed, does it resolve the distribution's backport of the control.c rwsem fix rather than performing an upstream version comparison, and does it record whether an ALSA control device is present on that host at all — the module-surface question that decides whether the vulnerable ioctl is reachable there. A scan that answers only 'kernel package version' returns a clean estate report across hosts that are one unprivileged local user away from ring0, which is precisely the reboot-deferred window the cited framework gaps describe and the reason a patch-compliance dashboard cannot be the evidence for this CVE.",
+        "evidence": "affected_versions reads 'Linux kernel through 6.1.6 (ALSA PCM); fixed past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e', and the vector's own remediation advice is 'We recommend upgrading past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e'. patch_required_reboot is true, live_patch_available false, and live_patch_notes confirm 'No vendor live-patch was shipped with the fix'. The A.8.8 gap states that technical-vulnerability management 'flags the KEV entry, yet the practical exposure is the reboot-deferred kernel-update window during which a local use-after-free continues to grant ring0 escalation', and the Essential Eight gap that patch-operating-systems 'targets prompt kernel updates, but kernel patching requires a reboot and is often deferred; that latency leaves the use-after-free LPE available to chain after any initial code execution'. The module-surface half of the test follows the packet's attack_vector, which requires the local user to invoke the ioctl 'on an ALSA control device'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2022-3038": {
     "name": "Google Chromium Network Service Use-After-Free Vulnerability",
@@ -66407,7 +68302,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management must track fast-moving Chromium releases across every derived browser; a program that inventories only 'Chrome' can miss Edge/Opera instances still exposed to this crafted-HTML use-after-free."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "For this CVE the no-deferral ring has to be defined over every Chromium-derived browser in the estate, not over Chrome: the packet fixes it at Google Chrome 105.0.5195.52 and records the affected population as Chromium-based browsers including Edge and Opera prior to their corresponding patched builds, each shipping on its own update channel. An estate standardised on Edge, or carrying a second Chromium browser for one legacy application, stays exposed to the same crafted-page path while its Chrome ring reports compliant — which is exactly the inventory failure the ISO gap on this entry names. Deployment completion has to be measured on the browser that is running, not the bits on disk: patch_required_reboot is false, meaning no machine reboot, but the packet's recorded remediation includes restarting the browser, so a Chrome or Edge process that has been up since before the update still executes the pre-fix Network Service code and is not remediated. Take the reported version from the running process (chrome://version and the equivalent page on each derived browser) after that restart. Preconditions: this reaches only browsers whose update channel the estate actually controls — a per-user install, an unmanaged host, or a policy that suppresses auto-update is remediated by removing the suppression or the install, not by shortening the ring; and because the defect is in the browser's own network process and triggered by rendering a page, no configuration or policy setting substitutes for reaching the patched build.",
+        "evidence": "Packet: vector 'Use after free in Network Service in Google Chrome prior to 105.0.5195.52 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.' affected_versions: 'Google Chrome < 105.0.5195.52' and 'Chromium-based browsers (Edge, Opera, and others) prior to the corresponding patched build.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation is updating to Google Chrome 105.0.5195.52 or later (and the equivalent patched build of each Chromium-based browser) and restarting the browser.' Cited gaps: NIS2-Art21-patch-management 'Chromium-based products (Chrome, Edge, Opera) update on separate channels; a crafted HTML page could exploit any host whose browser lagged 105.0.5195.52'; ISO-27001-2022-A.8.8 'a program that inventories only Chrome can miss Edge/Opera instances still exposed to this crafted-HTML use-after-free'; UK-CAF-B4 'secure configuration cannot mitigate a use-after-free in the browser's own Network Service process reached by simply rendering a page; only shipping the patched Chromium build removes the heap-corruption path'; AU-Essential-8-Patch 'targets 48 hours for actively-exploited browser flaws.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The two dates in this packet are what make the control bite differently here: the fixed build, Chrome 105.0.5195.52, shipped on the stable channel 30 August 2022, and the CISA KEV listing came on 2023-03-30. Under this control's 'within 4 hours of KEV listing or patch availability, whichever is later' wording, the clock therefore starts at the listing, on a build that had already been available for roughly seven months — so the action the listing demands is not a deployment but a verification sweep: on the day of listing, enumerate every Chrome, Edge, Opera and other Chromium-derived install and produce the version each one is running, because by then the exposed population is exactly the set whose auto-update was suppressed, deferred, or never applied. There is no interim state to record for this CVE: live_patch_available is false, so a browser below its product's patched build is simply exposed, and the only remediation is the patched build plus the browser restart the packet requires. Precondition and limit, which this entry demonstrates rather than hides: the KEV listing is the trigger, and here it arrived months after in-the-wild use began, so this control bounds the tail of the exposure rather than its opening — the standing update posture is what covers the window between the vendor fix and the listing.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-03-30, active_exploitation confirmed. active_exploitation_notes: 'Fixed in Google Chrome 105.0.5195.52 (stable channel, 30 August 2022) and later added to CISA KEV on 2023-03-30, indicating in-the-wild exploitation... affects the broad Chromium base — Chrome, Edge, Opera and other Chromium-derived browsers — so a single malicious page can target a large browser population.' patch_available true, live_patch_available false, poc_available false, cvss 8.8, rwep_score 45. Cited gap NIST-800-53-SI-2: 'this Network Service use-after-free was fixed on 2022-08-30 but only KEV-listed on 2023-03-30, so environments that suppressed or delayed Chromium auto-update ran an exploitable browser for months.' Cited gap AU-Essential-8-Patch records the '~7-month gap between the 2022-08-30 fix and the 2023-03-30 KEV listing.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2022-22706": {
     "name": "Arm Mali GPU Kernel Driver Unspecified Vulnerability",
@@ -66803,7 +68722,42 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management would schedule the FortiOS patch, but because exploitation writes persistent implants into the device image, A.8.8's patch focus misses the firmware-integrity check needed to catch UNC3886's THINCRUST/CASTLETAP footholds."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This is the case four of this entry's five gaps are separately describing. On Fortinet FortiOS the packet's exploitation is not opportunistic: UNC3886 used the path traversal to write files to FortiGate devices and maintain persistence with super-admin privileges, planting the THINCRUST and CASTLETAP implants. Upgrading to FortiOS 7.2.4, 7.0.10 or 6.4.12 closes the CLI path-handling flaw that allowed the write; it removes nothing already written through it, and the packet says so directly in its own remediation note, which advises firmware-integrity verification for previously-exposed devices. For this appliance the control therefore means a unit that ran an affected build — 7.2.0 through 7.2.3, 7.0.0 through 7.0.9, or below 6.4.11 — during the exposure window goes down the incident path rather than the change-control path: verify the running firmware image against the vendor's expected image rather than trusting the device's own version string, rebuild the unit from vendor firmware and a configuration reviewed against a known-good baseline instead of upgrading in place and inheriting whatever the existing image carries, and treat as disclosed every credential the device held or that authenticated through it — super-admin and administrator accounts, local and VPN user credentials, RADIUS and LDAP service accounts, and device certificates — rotating each. Preconditions, stated because they change who this applies to. The trigger here is narrower than the pre-auth-RCE case this control is usually invoked for: CVE-2022-41328 requires privileged CLI access, and the packet's actor already held super-admin, so the population is units with an affected build that had privileged CLI exposure — including any unit whose administrative credentials could have been obtained through a separate path — not every affected unit in the estate. Restoring the configuration from a backup taken inside the exposure window reinstates what the attacker placed there, so the baseline must predate it. And this control does not prevent the write; the vendor upgrade is what removes the traversal, and this is what has to happen alongside it.",
+        "evidence": "Packet: active_exploitation_notes 'Confirmed exploited in highly targeted attacks by the China-nexus actor UNC3886, which used the path traversal to write files to FortiGate devices and maintain persistence (THINCRUST/CASTLETAP implants) with super-admin privileges. KEV-listed 2023-03-14; exploitation was espionage, not ransomware.' attack_vector describes crafted CLI commands traversing outside the intended directory to read and write files on the underlying Linux system, used to plant persistent implants in the FortiGate firmware. live_patch_notes: 'No live-patch mechanism for FortiOS; remediation is upgrading to FortiOS 7.2.4, 7.0.10, or 6.4.12 (or later), a firmware upgrade that reboots the appliance, and firmware-integrity verification is advised for previously-exposed devices.' affected_versions: 7.2.0-7.2.3 (fixed 7.2.4), 7.0.0-7.0.9 (fixed 7.0.10), < 6.4.11 (fixed 6.4.12). The NIST-800-53-SI-2 gap states applying the fix 'closes the write primitive yet does not by itself detect or remove implants already planted in firmware'; the NIS2-Art21-supply-chain gap states the framework 'offers no control forcing firmware-integrity verification on FortiGate appliances'; the AU-Essential-8-Patch gap states that even after patching there is no requirement to re-verify FortiGate firmware integrity for prior tampering; the ISO-27001-2022-A.8.8 gap states its patch focus 'misses the firmware-integrity check needed to catch UNC3886's THINCRUST/CASTLETAP footholds'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-supply-chain"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A FortiGate running FortiOS is the device class this tier exists for, and the packet's Essential-Eight gap states the deficiency the tier answers: patch cadence rarely tracks firewall firmware at all. Bound to this CVE, the tier has to be written against what the remediation actually costs, which the packet gives precisely — FortiOS 7.2.4, 7.0.10 or 6.4.12 or later, delivered as a firmware upgrade that reboots the appliance, with no live-patch mechanism. So the clock runs from the 2023-03-14 KEV listing to each unit running a fixed build, and the completion measure is the build the appliance is executing after that reboot: a unit with firmware staged but not booted is still running the vulnerable CLI path handler and must be counted as exposed, which matters here because taking a firewall through a reboot is the step most likely to be deferred to a maintenance window and then recorded as done. Be honest about the fit: this is not the pre-authentication remote code execution the tier is usually invoked for — the packet requires privileged CLI access — and the reason it still belongs in the tier is the device class rather than the authentication level, because a firewall is the trust boundary and its firmware sits outside the general patch cadence the estate runs. The isolation half of the tier is the only lever available before the reboot window: restrict which networks and which accounts can open an administrative CLI session on the appliance, and remove administrative reachability from anything that has no operational need for it. Its precondition is the important part and it is a real limit, not a caveat — that restriction bounds the population who can attempt the traversal, it does not close it, because any account that legitimately reaches the privileged CLI still reaches the file read and write. The packet's own case is exactly that: an actor operating with super-admin, for whom no amount of reachability restriction is a barrier. It is a holding measure for the window before the firmware upgrade and reboot land, not a substitute for them.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-03-14; active_exploitation confirmed; cvss 7.1 with rwep_score 47; poc_available false. patch_available true, patch_required_reboot true, live_patch_available false. live_patch_notes: 'No live-patch mechanism for FortiOS; remediation is upgrading to FortiOS 7.2.4, 7.0.10, or 6.4.12 (or later), a firmware upgrade that reboots the appliance...' affected: 'Fortinet FortiOS, whose CLI command handling allows path traversal, letting a local privileged attacker read and write files on the underlying Linux system.' attack_vector: 'An attacker with privileged FortiOS CLI access issues crafted commands that traverse outside the intended directory...' The AU-Essential-8-Patch gap states 'Essential 8 patch cadence rarely tracks firewall firmware and cannot help against a 0-day used in targeted intrusions before the 2023-03 fix.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The UK-CAF-B4 gap on this entry says the appliance's own configuration controls cannot constrain what a super-admin does through the flawed CLI path handling, and the SI-2 gap says the fix does not detect what was already planted. Both leave the same question open on a FortiGate: where does the record of that activity live, given the actor holds super-admin on the device that produces it. For this CVE the control means FortiOS admin and event logs, configuration-change records and traffic logs are forwarded to a collector in a separate trust zone — different management plane, different credentials, different authentication path — so that the evidence of the exposure window survives an actor with full administrative control of its source. The behaviour to key on is what the packet documents rather than a generic exploit signature: privileged CLI sessions issuing commands whose path arguments resolve outside the intended directory, and the file writes and configuration changes that follow them onto the underlying Linux filesystem. That is the observable shape of this flaw — no crash, no unsigned binary loading through a supported interface, nothing that a firmware version check would surface — which is why an alert keyed to appliance crashes or to named exploit tooling would miss an intrusion behaving exactly as the packet describes. Preconditions, and they are the reason this control is worth stating rather than assumed. The forwarding must already have been in place before the compromise: configured afterwards it produces nothing about the window that matters, and on the units most exposed to a targeted actor it is precisely the configuration most often left at defaults. The forwarding configuration itself lives on the device, so an actor with super-admin can disable it — which makes the log stream going quiet an event the off-box collector must alarm on rather than absorb. And this neither prevents the traversal nor removes an implant already planted; it bounds the intrusion to detection-and-response time and preserves the record that the firmware-integrity work and credential rotation are then scoped from.",
+        "evidence": "Packet: affected 'Fortinet FortiOS, whose CLI command handling allows path traversal, letting a local privileged attacker read and write files on the underlying Linux system.' attack_vector describes an attacker with privileged FortiOS CLI access issuing crafted commands that traverse outside the intended directory to read and write files on the underlying Linux system. active_exploitation_notes: UNC3886 'used the path traversal to write files to FortiGate devices and maintain persistence (THINCRUST/CASTLETAP implants) with super-admin privileges'; exploitation was espionage, not ransomware. The UK-CAF-B4 gap states 'CAF B4 system-security hardening of a firewall cannot prevent a super-admin from writing arbitrary files via the flawed CLI path handling; the traversal turns legitimate privileged CLI access into filesystem write, which B4's configuration controls do not constrain.' The NIST-800-53-SI-2 gap states the fix 'does not by itself detect or remove implants already planted in firmware.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2021-39144": {
     "name": "XStream Remote Code Execution Vulnerability",
@@ -66864,7 +68818,38 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management must cover embedded libraries; this deserialization flaw was remediable only by upgrading XStream to 1.4.18 or applying the embedding vendor's patch, and inventories that tracked only top-level products missed the vulnerable component."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "For most operators exposed to this XStream flaw, XStream is not something they chose. It arrives below the layer their inventory records — inside a commercial product that bundles it, and inside their own Java services as a dependency of a dependency — which is why an estate could be running the vulnerable code with every top-level product accounted for. Bound to this CVE the requirement is to resolve XStream by component and version rather than by product name across both arrivals the packet names: every Java service whose resolved dependency tree pulls XStream below 1.4.18, and every shipped product that bundles it, with VMware Cloud Foundation (NSX) named explicitly and each such product's own fixed release being the remediation target rather than the library's. Scope it to that. The packet ties this CWE-502 sink to XStream and to products bundling XStream, and gives no mapping into other XML or serialization libraries, so treating every Java deserialization path in the estate as an instance of this CVE manufactures findings and remediation work against code no evidence implicates; widen the inventory only where a verified source identifies another product carrying XStream below 1.4.18. Preconditions. The inventory reaches only what its sources can see: a closed-source product that publishes no component list cannot be resolved from the outside, and there the embedding vendor's advisory is the only evidence of exposure — the packet records that VMware issued a critical-rated advisory for Cloud Foundation. And locating the component is not removing it; this control tells an operator where the exposure is, after which each instance still has to reach 1.4.18+ or its vendor's fixed release.",
+        "evidence": "The packet gives affected as 'XStream (Java XML serialization library) and products embedding it — the pre-1.4.18 default converts an attacker-controlled XML stream into arbitrary objects (CWE-502), enabling OS command execution', with affected_versions 'XStream < 1.4.18' and 'VMware Cloud Foundation (NSX) and other products bundling XStream < 1.4.18'. The active-exploitation notes record it 'Exploited against products that bundle XStream with a default (blacklist) configuration, notably VMware Cloud Foundation (NSX), for which VMware issued a critical-rated advisory', with KEV listing 2023-03-10 and active_exploitation 'confirmed'. The NIS2 supply-chain gap states organizations 'often did not know XStream < 1.4.18 was embedded in their VMware or other stack until exploitation'; the A.8.8 gap that 'inventories that tracked only top-level products missed the vulnerable component'; and the SI-2 gap that remediation 'required each product (e.g. VMware Cloud Foundation) to ship an updated XStream, so downstream remediation lagged the 2021 library fix'.",
+        "gap_closes": [
+          "NIS2-Art21-supply-chain",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The XStream fix predates the KEV listing by well over a year, so on this entry the listing is what starts the clock, and the SLA has to be written against two distinct remediation targets rather than one. Services whose XStream dependency the operator controls move to 1.4.18 or later. Instances bundled inside a shipped product move to that product's fixed release — VMware Cloud Foundation (NSX) is the one the packet names, and there the operator cannot compile a library fix in at all, so the vendor's release is the only path and the SLA is met by deploying it, not by noting that the library upstream is fixed. Completion is measured on the version the running process is executing. patch_required_reboot is false, meaning no host reboot, but the packet records no live-patch mechanism, so a replaced XStream artifact on disk is not in effect until the JVM that has it loaded restarts — a service still running the pre-1.4.18 classes is exposed however current the filesystem looks, and that restart is the step to plan and evidence rather than the one to assume away. Precondition on the compensating-control branch this SLA allows: the packet's own remediation note offers configuring an explicit type whitelist as an alternative to upgrading, and that is available only where the operator controls the XStream instantiation. Inside a bundled product it cannot be configured from outside, so for those instances there is no compensating state to fall back to during the window — only the vendor's fixed release, or removing the service's exposure to untrusted XML until it lands.",
+        "evidence": "cisa_kev is true with kev_date 2023-03-10, active_exploitation 'confirmed', poc_available true, CVSS 8.5 and RWEP 67. patch_available is true, patch_required_reboot false, live_patch_available false, and live_patch_notes read 'No live-patch mechanism; remediation requires upgrading XStream to 1.4.18+ (or configuring an explicit type whitelist) and applying the fixed release of any embedding product such as VMware Cloud Foundation.' affected_versions name both 'XStream < 1.4.18' and 'VMware Cloud Foundation (NSX) and other products bundling XStream < 1.4.18'. The cited SI-2 gap states that flaw remediation 'is complicated because XStream is an embedded dependency; patching required each product (e.g. VMware Cloud Foundation) to ship an updated XStream, so downstream remediation lagged the 2021 library fix and the flaw was still KEV-listed as exploited on 2023-03-10.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This CVE produces a genuine mitigation-active state that a patch-oriented verdict cannot express, and the packet describes it directly: no user is affected who followed the recommendation to set up XStream's security framework with a whitelist limited to the minimal required types. So a service can be protected while still running a library version the scanner flags, and — more dangerously for an audit — can be recorded as hardened while the protection covers only part of it. For this CVE the requirement is that a service carrying an explicit XStream type allowlist while still below 1.4.18 is recorded as mitigation-active-patch-pending with a dated action to reach 1.4.18 or the embedding vendor's fixed release, never as remediated. The residual risk that classification carries is specific here: the allowlist is per-instantiation configuration, so it holds only for the XStream instances it was applied to, and a second instance constructed elsewhere in the same service, or inside a bundled product whose configuration the operator does not control, reverts to the vulnerable default. Precondition, and it decides which state a deployment is actually in: the pre-1.4.18 default is a blacklist, and the packet records that 1.4.18 stopped using one because it cannot be secured for general purpose. A deployment relying on that default is not in the mitigation-active state at all — it belongs in the no-mitigation state, and recording it as configured-and-therefore-hardened is the specific way this entry's application-hardening posture becomes paper.",
+        "evidence": "The packet's vector states: 'No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. XStream 1.4.18 uses no longer a blacklist by default, since it cannot be secured for general purpose.' live_patch_notes give the two remediation routes as 'upgrading XStream to 1.4.18+ (or configuring an explicit type whitelist) and applying the fixed release of any embedding product such as VMware Cloud Foundation'. The active-exploitation notes record exploitation 'against products that bundle XStream with a default (blacklist) configuration'. The cited Essential Eight application-hardening gap states that 'the safe posture (an XStream type whitelist) was off by default before 1.4.18, so hardening depended on developers configuring it, which most embedding products had not.'",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2022-47986": {
     "name": "IBM Aspera Faspex Code Execution Vulnerability",