@blamejs/exceptd-skills 0.19.20 → 0.19.22

package/data/zeroday-lessons.json

@@ -33794,7 +33794,41 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "human_researcher",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The EDS5000 is a device server sitting between legacy serial equipment and the IP network, so on this estate it is the trust boundary itself, and the packet's defect is a pre-auth one: the network-reachable HTTP RPC module concatenates the attacker-supplied username directly into a shell command while logging a failed authentication attempt, so a crafted username executes as root without any valid credential ever being presented. That combination is what puts this device in a distinct SLA tier rather than an appliance patch window. The clock is the KEV clock that opened 2026-06-23 with a 2026-06-26 due date — days — not the 30-day flaw-remediation SLA or the monthly/fortnightly Essential-Eight cadence the cited gaps are scored against, and not the normal vulnerability-management cadence A.8.8 leaves undefined. Completion is measured per unit by the firmware actually running: the packet fixes this at 2.2.0.0R1 against 2.1.0.0R3 and earlier, patch_required_reboot is true and live_patch_available is false, so a unit that has downloaded firmware but has not restarted onto it is still executing the vulnerable RPC handler and must be counted as exposed rather than as patched. On a device bridging live serial equipment that restart is the step most likely to be deferred to an OT maintenance window, and a deferral recorded as patched is the specific way this remediation goes wrong. Where a unit genuinely cannot be restarted inside the KEV window, the tier's alternative applies — isolate the HTTP RPC interface from every network that does not need to reach it — but that is an interim state carrying a dated restart, not a closure: the packet records the vendor update as the remediation with the named compensating controls holding only until it lands. Scope to the EDS5000, which is the product the packet names at 2.1.0.0R3 and earlier; it gives no mapping into other Lantronix device servers.",
+        "evidence": "Packet: CISA KEV added 2026-06-23 with due date 2026-06-26, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 77. vector: \"The EDS5000 HTTP RPC module is reachable over the network. When logging a failed authentication attempt it concatenates the attacker-supplied username directly into a shell command without sanitization (CWE-94), so a crafted username executes arbitrary OS commands as root.\" affected_versions: \"Lantronix EDS5000 firmware 2.1.0.0R3 and earlier\", \"Fixed in firmware 2.2.0.0R1\". patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: \"No live-patch path for this product class; remediation is the vendor update plus the named compensating controls until it lands.\" NIST-800-53-SI-2 gap: the routine 30-day SLA is far longer than the exploitation window; the operationally-meaningful clock is days. ISO-27001-2022-A.8.8 gap: \"appropriate timescales\" undefined, must collapse to the CISA due date. AU-Essential-8-Patch gap: maturity scored on cadence, not KEV-anchored emergency response. UK-CAF-B4 gap: \"the managed cycle itself is the gap here.\"",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-118",
+        "name": "OT-DEFAULT-CREDENTIAL-ELIMINATION",
+        "description": "On this entry only the segmentation half of this control is a lever, and the packet says why outright: the injection fires while the EDS5000 is logging a FAILED authentication attempt, so the attacker never presents a working credential and there is no vendor-default or shared account for the operator to rotate away — credential elimination does not touch this path. Reachability is what bounds it. Applied to this device, the control means the EDS5000's HTTP RPC interface answers only from a segmented engineering and management plane — the hosts with an operational need to configure the device server — and not from the internet, a flat plant network, or a general business VLAN, which is where the packet records exploitation actually happening against internet-facing and network-accessible units. That restriction is also the only thing keeping the IT/OT conduit from becoming the pivot: root on this box lets an attacker intercept and manipulate the serial streams of the PLCs and RTUs behind it, so a management interface reachable from the IT side is exactly the zone bridge the segmentation model assumes does not exist. Distinguishing test: from a general business VLAN and from an external address, attempt to reach the EDS5000's HTTP RPC interface on a staging unit; anything that answers is within reach of the published exploit, because past that point the attacker supplies nothing but a crafted username. Precondition: this bounds the population that can send the request, it does not repair the concatenation. Any compromised engineering workstation, contractor laptop or jump host already inside the permitted segment satisfies the exploit's requirement in full, and the control gives nothing where the interface must stay reachable for normal operation. It is a holding measure for the window before firmware 2.2.0.0R1 and its restart land — the packet records the vendor update plus the named compensating controls as the remediation, with those controls holding only until the update arrives.",
+        "evidence": "Packet vector: the HTTP RPC module is reachable over the network and injects on the failed-authentication logging path, so exploitation requires no valid credential; CVSS 9.8. active_exploitation_notes: \"KEV-confirmed (added 2026-06-23, due 2026-06-26). Actively exploited against internet-facing/network-accessible EDS5000 device servers... the device bridges serial OT assets (PLCs/RTUs) to IP, so exploitation enables OT pivot.\" vector: \"root control lets the attacker intercept/manipulate serial streams and pivot into connected OT networks.\" NIS2-Art21-network-security gap: perimeter and segmentation controls assume the appliance is trustworthy; an unauthenticated root OS command injection in the network device itself defeats that assumption. IEC-62443-3-3 gap: zone-and-conduit segmentation is the compensating control, but an internet-reachable device server with a root-level command injection bridges the IT and OT zones it is supposed to keep apart. live_patch_notes: \"remediation is the vendor update plus the named compensating controls until it lands.\"",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "IEC-62443-3-3"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records confirmed in-the-wild exploitation of internet-facing and network-accessible EDS5000 units by an exploit that lands as root, so for any unit that was reachable during the exposure window the firmware update is not the end state. Upgrading to 2.2.0.0R1 closes the RPC concatenation; it establishes nothing about what root-level access already did to the unit — its stored configuration, its serial port and host mappings, its administrative and any stored network credentials — and it gives no answer at all on the serial side, where the packet places the real consequence: root on the gateway lets an attacker intercept and manipulate the streams of the PLCs and RTUs it bridges. The requirement for this device is therefore that a suspected-exposed EDS5000 is rebuilt from a known-good configuration rather than patched in place, with every credential it held or that transited it rotated, and with the connected serial equipment's own state compared against a known-good copy rather than assumed intact because the gateway now reports fixed firmware. This is the part of the response that survives the patch, and it is the part the OT-security guidance cited on this entry has no step for — that guide treats the serial-to-IP gateway as a trusted conduit, so once the conduit itself has executed attacker code there is no defined path back to trust, and a segmentation-only reading leaves the compromised gateway sitting inside the zone it was meant to divide. Precondition: this applies to units that were reachable from an untrusted network during the exposure window, and establishing which those were requires reachability records or logs held off the device — a device whose own root account was taken is not the authority on its own integrity, and its local logs are not evidence of a clean unit.",
+        "evidence": "Packet: active_exploitation confirmed; active_exploitation_notes \"Actively exploited against internet-facing/network-accessible EDS5000 device servers. No named actor; the device bridges serial OT assets (PLCs/RTUs) to IP, so exploitation enables OT pivot.\" vector: a crafted username \"executes arbitrary OS commands as root... root control lets the attacker intercept/manipulate serial streams and pivot into connected OT networks.\" poc_available true, CVSS 9.8, RWEP 77. patch_available true (fixed in firmware 2.2.0.0R1), patch_required_reboot true, live_patch_available false. NIST-800-82r3 gap: \"800-82r3 treats the serial-to-IP gateway as a trusted conduit; root compromise via this root OS command injection turns the gateway into an OT pivot, which a segmentation-only reading of the guide does not address.\" IEC-62443-3-3 gap: the internet-reachable device server bridges the IT and OT zones it is supposed to keep apart.",
+        "gap_closes": [
+          "NIST-800-82r3",
+          "IEC-62443-3-3"
+        ]
+      }
+    ]
   },
   "CVE-2026-34910": {
     "name": "Ubiquiti UniFi OS Improper Input Validation Vulnerability",
@@ -34777,7 +34811,31 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places exploitation behind a pre-authenticated local user who already holds a pre-defined admin role, or a user-defined role with admin-level privileges, on the Brocade Fabric OS switch — the account is legitimate, so no account model is being abused; a privilege boundary inside the switch is failing and the result is full root code execution. That is why tightening role assignment does not contain this: holding the admin role is the exploit's precondition, not its abuse. For this CVE the control means the firmware carrying the fix is driven across the affected switches on the clock that opened with the 2025-04-28 KEV listing against the 2025-05-19 CISA due date, rather than folded into the next SAN change window, with completion measured by the firmware level each switch is running. Take the population from affected_versions: Fabric OS 9.1.0 through 9.1.1d6 inclusive is the affected train and 9.1.1d7 is the remediated build. The 9.2.x and 10.x trains are not listed as affected by this advisory and are covered separately under advisory doc 25000 — do not sweep them as instances of this CVE, and equally do not mark them clear on this entry, because their status comes from that other advisory. Precondition, and the specific way this remediation is recorded wrong: live_patch_available is false and patch_required_reboot is true, so a switch with 9.1.1d7 downloaded or staged is still executing the vulnerable code until it is running that build, and on a fabric switch that final step is the one most likely to be deferred — a deferral entered as patched is the failure mode to guard against. Because exploitation is confirmed and the primitive lets the attacker run any Fabric OS command or modify the OS itself, including inserting custom subroutines, a switch whose admin surface was reachable by a non-root account during the exposure window needs its firmware and configuration compared against a known-good baseline and its credentials rotated, rather than being closed out on the upgrade record.",
+        "evidence": "Packet facts only: the vector states exploitation requires a pre-authenticated local user already holding a pre-defined admin role or a user-defined role with admin-level privileges, that an IP-address input-validation flaw lets that user smuggle arbitrary code into a command path executing as root, that the primitive yields full root code execution allowing any Fabric OS command or modification of the OS itself (e.g. inserting custom subroutines), and that the net effect is admin-to-root privilege escalation on the SAN fabric switch. cisa_kev true with kev_date 2025-04-28; active_exploitation confirmed, with active_exploitation_notes recording Broadcom's advisory statement that the vulnerability \"has been actively exploited in the field\"; poc_available true; rwep_score 75 against cvss 6.7. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes stating there is no live-patch path for this product class. affected_versions gives 9.1.0 through 9.1.1d6 (inclusive) affected, fixed in 9.1.1d7, and states 9.2.x and 10.x are not listed as affected by this advisory and are covered separately under advisory doc 25000. The 2025-05-19 CISA due date is taken from the NIST-800-53-SI-2 gap text.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "Fabric OS's restricted admin shell is the constrained user surface this control governs, and the packet describes the forbidden pattern exactly: a flaw in IP-address input validation lets an admin-role user smuggle arbitrary code into a command path that executes as root, breaking out of that shell — which, as the packet notes, defeats the root-access removal Broadcom introduced starting in Fabric OS 9.1.0. Applied to this switch the requirement is that the privileged operations behind the admin shell sit behind their own authorization boundary, reachable only through a constrained and validated interface, so that the shell's own handling of an operator-supplied field — here an IP address — is not the single thing standing between an admin-level account and root. This is also the answer to the boundary-protection and network-security gaps cited on this entry: the switch's trustworthiness cannot be inherited from the segment it sits in, because the escalation happens inside the appliance the segmentation treats as the boundary, so a fabric that passes a segmentation review is not thereby protected. Preconditions, both load-bearing. First, the vendor firmware is what repairs the internal boundary — this control states the property to verify, it does not implement it; until the switch is running 9.1.1d7 the boundary is broken regardless of what is verified. Second, the only operator-side lever before that is restricting which accounts hold an admin or admin-equivalent role and which management segment a Fabric OS session may be opened from, and that bounds the population able to attempt the escalation without closing it — any account that legitimately reaches the admin shell still reaches root. The packet's CVSS 4.0 rescoring to adjacent access is the reason to enforce that reachability limit at the management network rather than treating the flaw as local-only.",
+        "evidence": "Packet facts only: the vector states the flaw is in IP-address input validation, that it lets an admin-level user smuggle arbitrary code into a command path executing as root, that this breaks out of the restricted admin shell, and that it defeats the root-access removal Broadcom introduced starting in Fabric OS 9.1.0; it also records CVSS 3.1 AV:L / PR:H with a CVSS 4.0 rescoring to AV:A adjacent. affected_versions gives 9.1.1d7 as the fixed build; patch_available true, patch_required_reboot true, live_patch_available false. The NIST-800-53-SC-7 gap states boundary protection treats this appliance as the boundary so the control protects nothing in front of it once the device itself carries the flaw; the NIS2-Art21-network-security gap states perimeter and segmentation controls assume the appliance is trustworthy and that a code injection to root in the network device defeats that assumption. active_exploitation is confirmed per the packet.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2025-42599": {
     "name": "Qualitia Active! Mail Stack-Based Buffer Overflow Vulnerability",
@@ -38891,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.",
@@ -38913,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",
@@ -41365,7 +41445,31 @@
         "adequate": false,
         "gap": "Many affected cameras remain on end-of-life firmware years after the fix shipped; Essential 8's patch-application pillar requires an inventory and update mechanism that consumer IoT vendors typically don't provide."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "Two facts in this packet have to be resolved per camera before anything else. A vendor firmware fix exists — patch_available is true and the flaw-remediation gap records it shipping 2022-01-19 — and the Essential-Eight gap records that many affected cameras remain on end-of-life firmware years later because consumer IoT vendors provide no inventory or update mechanism. So the requirement is an inventory naming every Reolink RLC-410W in service with its hardware revision, its running firmware version, and an end-of-support status obtained from Reolink rather than assumed in either direction: the packet gives the vulnerable level as v3.0.0.136_20121102 and earlier but does not name the fixed build, so that level has to come from the vendor for that exact model and revision. Cameras whose revision has firmware carrying the fix are remediation items on the clock that opened with the 2024-12-18 KEV listing, and because patch_required_reboot is true and live_patch_available is false, a camera that has taken firmware but has not restarted onto it is still running the vulnerable SetDdns handler and counts as exposed. Cameras whose revision has no fixed firmware cannot be patched at all and are replacement items needing a dated removal schedule; a risk acceptance with no removal date leaves a device with a public exploit and confirmed exploitation watching a premises indefinitely. Scope this to the RLC-410W — the packet ties the DDNS-field injection to that model at that firmware level and gives no mapping into other Reolink models or other vendors' cameras, so sweeping every IP camera in the estate manufactures replacement work against hardware no evidence implicates. And because exploitation is confirmed and the flaw yields command execution on the camera itself, a unit that was exposed is not remediated by firmware alone: its configuration and its administrative credential have to be rebuilt from a known-good baseline rather than carried through the update.",
+        "evidence": "Packet: CISA KEV 2024-12-18, active_exploitation confirmed, poc_available true, CVSS 7.2, RWEP 66. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. NIST-800-53-SI-2 gap: \"A firmware patch exists (vendor-fixed 2022-01-19), but the KEV listing three years later shows widespread unpatched devices; flaw-remediation SLAs do not reach consumer/SMB IoT fleets with no centralized patch management.\" AU-Essential-8-Patch gap: \"Many affected cameras remain on end-of-life firmware years after the fix shipped; Essential 8's patch-application pillar requires an inventory and update mechanism that consumer IoT vendors typically don't provide.\" UK-CAF-B4 gap: \"Secure-configuration baselines don't segment or retire consumer IP cameras...\" affected_versions: \"Reolink RLC-410W firmware v3.0.0.136_20121102 and earlier\".",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The camera's device-network-settings API is the configuration endpoint this control governs, and the defect sits inside it: the SetDdns call takes the operator-supplied domain parameter into the ddns->domain variable without validating it and passes it into a system-level command, so shell metacharacters in that one field execute as OS commands on the camera, reached by nothing more than an HTTP request. Bound to this product, the control means the RLC-410W's network-settings API validates and neutralizes every field it forwards into a command — the DDNS domain among them — before that command runs, instead of treating the value as safe because the caller authenticated as the camera's administrator; and that no RLC-410W is left with its HTTP administration surface reachable from a general user LAN or from the internet. This is precisely why the least-privilege gap cited on this entry does not close the path: the attacker is exercising the administrator role as designed, so scoping privileges more tightly changes nothing about a configuration field that reaches a shell, and an access-control attestation showing one named administrator per camera passes cleanly while the injection stays live. Distinguishing test: on a spare RLC-410W, submit a SetDdns request whose domain parameter carries shell metacharacters and confirm the value is rejected or neutralized before any command runs — not merely that the API demanded a login first. Precondition on each half, because both are commonly over-claimed. The field validation is a property the vendor firmware establishes; this control states what to verify, it does not implement it, and until the fixed firmware and its reboot land the endpoint stays fully exploitable to anyone who reaches it holding the admin credential. Restricting which segments can reach the camera's administration interface bounds that population but does not close the path — the packet's own least-privilege gap names default, reused and phished admin credentials as the way in, so any host inside the permitted segment, including the workstation or phone that legitimately administers the camera, satisfies the exploit's precondition in full.",
+        "evidence": "Packet vector: \"the ddns->domain variable, that has the value of the domain parameter provided through the SetDdns API, is not validated properly. This would lead to an OS command injection. An attacker can send an HTTP request to trigger this vulnerability.\" attack_vector: an authenticated attacker embeds shell metacharacters in the DDNS domain field of the network-configuration API and the device passes them unsanitized into a system-level command. NIST-800-53-AC-6 gap: \"The DDNS configuration API trusts authenticated admin input without sanitizing it; least-privilege alone does not stop command injection once admin credentials are reused, defaulted, or phished.\" ISO-27001-2022-A.8.9 gap: \"Secure configuration management for the device's network-settings API did not include input validation; the config interface accepts unsanitized shell metacharacters by design.\" NIS2-Art21-network-security gap: \"Consumer/SMB IP cameras ... are rarely network-segmented; Art. 21 network security requires isolating IoT camera management interfaces from the general LAN.\" patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "ISO-27001-2022-A.8.9",
+          "NIS2-Art21-network-security"
+        ]
+      }
+    ]
   },
   "CVE-2019-11001": {
     "name": "Reolink Multiple IP Cameras OS Command Injection Vulnerability",
@@ -41402,7 +41506,42 @@
         "adequate": false,
         "gap": "No confirmed vendor firmware fix has been identified for all affected models, and CISA's own required action notes the product may be EoL/EoS; flaw remediation cannot be satisfied where no patch exists."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry is the pure form of the case the control exists for, because the interim half does not apply at all: patch_available is false, live_patch_available is false, and the packet records that CISA's own required action notes the product may be end-of-life / end-of-service. There is no fixed build to reach on these cameras, so removal or replacement is not the terminal state after an interim patch — it is the only state. Scope the inventory to exactly the five models the packet names — RLC-410W, C1 Pro, C2 Pro, RLC-422W and RLC-511W, at firmware through 1.0.227 — and give each unit in service a dated replacement schedule; a risk acceptance with no removal date leaves a KEV-listed root command injection with a public proof of concept and confirmed exploitation running indefinitely, which is what the Essential Eight gap means when it says decommissioning is the only durable control. Do not widen past those five: the packet ties the TestEmail/addr1 sink to those models and gives no mapping into other Reolink lines or other vendors' cameras, so treating every IP camera in the estate as an instance of this CVE manufactures replacement work and budget against hardware no evidence implicates — extend only where a verified source names another model carrying the same firmware. And because the injected command runs as root on the device, replacement alone does not close a unit that was exposed: its stored configuration and any credential it held or that transited it must be treated as compromised and rotated rather than carried onto the replacement.",
+        "evidence": "Packet facts only: patch_available false, live_patch_available false, live_patch_notes null; cisa_kev true with kev_date 2024-12-18 and active_exploitation confirmed; poc_available true; rwep_score 75 against cvss 7.2. The affected and affected_versions fields name Reolink RLC-410W, C1 Pro, C2 Pro, RLC-422W and RLC-511W at firmware through 1.0.227, with the injection reached through the TestEmail notification-configuration feature's addr1 field and executed as root. The NIST-800-53-SI-2 gap states no confirmed vendor firmware fix has been identified for all affected models and that CISA's required action notes the product may be EoL/EoS; the AU-Essential-8-Patch gap states decommissioning is the only durable control; the UK-CAF-B4 gap states network segmentation or device replacement is the only control the framework leaves available. No firmware version, advisory identifier or date beyond these is asserted.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The control admits three ways to satisfy its clock — patch, live patch, or documented compensating controls — and on this entry only the third exists, which is what makes it worth attaching rather than routine. patch_available is false and live_patch_available is false, so the deliverable inside the window that opened with the 2024-12-18 KEV listing is a written, per-unit compensating-control statement, and specifically not a \"pending vendor firmware\" note, because the packet records no firmware to wait for. The compensating control the packet's own NIS2 and CAF gaps name is isolation: each camera's administrative interface — the notification-configuration surface that carries TestEmail — answers only from the segment that operates it, and from no path reachable outside that segment. State the precondition plainly, because it is the whole reason this is a holding measure and not a fix: exploitation requires an authenticated admin session against that feature, so isolation bounds who can reach the sink but removes nothing for any host already inside the permitted segment or for anyone holding the admin credential. A camera that must stay reachable from a general client network has no segment that removes the path at all — only isolation of that network from anything that matters — and those units belong at the front of the replacement schedule rather than in the compensating-control column.",
+        "evidence": "Packet facts only: cisa_kev true with kev_date 2024-12-18 and active_exploitation confirmed; patch_available false, live_patch_available false, live_patch_notes null; poc_available true. The vector and attack_vector state that an authenticated admin submits shell metacharacters in the addr1 field of the TestEmail notification-test feature and the device executes them as an OS command running as root. The NIS2-Art21-vulnerability-management gap states EU operators with these models deployed have no confirmed patch path and that Art. 21 requires network isolation or device replacement as the compensating control; the UK-CAF-B4 gap likewise names network segmentation or device replacement as the only remaining control; the NIST-800-53-SI-2 gap states flaw remediation cannot be satisfied where no patch exists. No claim is made about internet exposure, port forwarding, or a default credential, none of which this packet establishes.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "The three verdict states this control requires are where the frameworks cited on this entry actually break. State (a) — binary patch deployed — is unreachable here, because patch_available is false and no vendor fix is recorded for all affected models, so every unit sits in either the compensating-control state or full exposure. A patch-compliance report that renders \"no patch available\" as not-applicable, suppressed, or an accepted exception therefore marks a root-exploitable KEV-listed camera as compliant, which is exactly what the SI-2 gap means by remediation being unsatisfiable and the Essential Eight gap means by the maturity level being unreachable for this device line. Bound to these cameras, the requirement is that each unit carries an explicit verdict of \"isolation active, no vendor fix exists\" with a dated replacement action attached, distinguishable in the report from units where nothing has been done. The softer verdicts are wrong here for a product-specific reason the packet supplies: the device's notification-configuration surface passes its input to a root OS command by design defect, so no configuration change and no account-privilege change converts a unit into a remediated one. Distinguishing test: pull the fleet's patch-compliance report and confirm the affected models appear as an open, dated compensating-control item — an estate whose report shows them as not-applicable, or as awaiting vendor firmware, has recorded the exposure rather than tracked it.",
+        "evidence": "Packet facts only: patch_available false and live_patch_available false, so no binary-patch state exists for this entry; cisa_kev true with kev_date 2024-12-18, active_exploitation confirmed, poc_available true. The NIST-800-53-SI-2 gap states flaw remediation cannot be satisfied where no patch exists; the AU-Essential-8-Patch gap states Essential 8's patch-application maturity level is unreachable for this device line with no confirmed fix and possible EoL/EoS status. The NIST-800-53-AC-6 gap states the TestEmail feature trusts authenticated admin input without sanitizing it so least-privilege on the admin account does not prevent the injection, and the ISO-27001-2022-A.8.9 gap states secure configuration management for notification-testing functionality never validated input — the basis for the statement that no configuration or account state remediates a unit. Those two gaps inform the reasoning but are not claimed as closed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2018-14933": {
     "name": "NUUO NVRmini Devices OS Command Injection Vulnerability",
@@ -41439,7 +41578,39 @@
         "adequate": false,
         "gap": "NUUO has declared the NVRmini line end-of-life with no fix; flaw-remediation SLAs cannot be met where no vendor patch exists, so the required action is decommissioning rather than patching."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "patch_available is false, and the packet states why: NUUO has declared the NVRmini line end-of-life with no fix, and the packet records CISA's required action as decommissioning rather than patching. There is no fixed firmware to reach and no live-patch path, so for this CVE the control has only its terminal half — every NUUO NVRmini network video recorder in service is a replacement item on a dated schedule, and the compliance record for this entry closes on removal, not on a firmware level. Two things follow. First, the inventory has to be built by the method that will actually find these units: the packet's own monitoring gap notes that security-monitoring outcomes seldom cover end-of-life NVR appliances, which is the same reason they are missing from asset registers, so sweep for the recorder's web management surface from the network as well as reading the register, and cover the branch, retail and facilities sites where a surveillance system was commissioned outside IT. Second, scope to what the packet names: it ties the CWE-78 sink to upgrade_handle.php on NUUO NVRmini devices and gives no mapping into other NUUO products or into other vendors' recorders, so treating every NVR in the estate as an instance of this CVE manufactures findings and replacement work against hardware no evidence implicates. Precondition on the interval before each unit is physically removed: unauthenticated network reachability is the entire exploit precondition, so isolating the device is the only holding measure — it is a holding measure and not the closure, and a risk acceptance with no removal date leaves a CVSS 9.8 unauthenticated command-execution path with a public PoC and confirmed exploitation in service indefinitely. And because exploitation is confirmed and the attacker runs commands on the recorder itself, a unit that was reachable during the exposure window is presumed compromised: it is removed rather than re-homed onto a quieter segment, and credentials it held or that transited it are rotated.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes null. NIST-800-53-SI-2 gap: 'NUUO has declared the NVRmini line end-of-life with no fix; flaw-remediation SLAs cannot be met where no vendor patch exists, so the required action is decommissioning rather than patching.' ISO-27001-2022-A.8.8 gap: 'Technical vulnerability management assumes a remediation path exists; for this EoL device it does not, so the control's compliance model must shift to asset retirement.' AU-Essential-8-Patch gap: 'Patch-application maturity is unreachable for an EoL device with no vendor fix; the compensating control is decommissioning per CISA's required action.' UK-CAF-C1 gap: 'Security-monitoring outcomes seldom cover EoL NVR appliances'. vector: 'upgrade_handle.php on NUUO NVRmini devices allows Remote Command Execution via shell metacharacters in the uploaddir parameter for a writeuploaddir command.' CWE-78; CVSS 9.8; RWEP 79; poc_available true; cisa_kev true with kev_date 2024-12-18; active_exploitation confirmed, with active_exploitation_notes citing 'continued exploitation of end-of-life devices still deployed in the field'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "A NUUO NVRmini is the recording and retention tier of a surveillance installation — the box that holds the footage — and the packet's exploit path reaches it with no credential and no user interaction: an unauthenticated request to upgrade_handle.php invoking the writeuploaddir command with shell metacharacters in the uploaddir parameter, ending in OS command execution on the recorder. With patch_available false and the product line end-of-life, reachability is not one lever among several; until the unit is removed it is the only one the operator holds, and it is the operator-side form of the least-functionality requirement this entry records as missing, since the vendor will not be authenticating or removing that endpoint. Applied to this device it means the NVRmini's web management surface answers only from a segmented surveillance or operations subnet, or from an authenticated VPN — not from a general user VLAN, and not from the internet through the router port-forward or UPnP mapping that a remote-viewing requirement typically creates on a small-site recorder, which is how this class of appliance acquires internet exposure in the first place. Constrain the outbound path as well: the packet's monitoring gap records botnet enlistment of the recorder following compromise, so a rooted NVRmini reaching arbitrary destinations is the documented outcome rather than a hypothetical one. The distinguishing test: from a general user VLAN and from an external address, request upgrade_handle.php on the unit — anything that answers is within reach of the published exploit, and 'the recorder is on the internal network' is an assertion about topology, not a demonstration that the surface is unreachable from untrusted segments. Two preconditions must be stated rather than assumed. Isolation bounds who can send the request; it does not repair the missing authentication on the endpoint, so any host inside the permitted segment — a compromised workstation, a jump host, the camera VLAN itself — still reaches an unauthenticated command-execution path. And it does nothing for a unit already compromised during the exposure window, which belongs on the incident path. This is a holding measure for the interval before removal, never a closure.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends a crafted request to upgrade_handle.php invoking the writeuploaddir command with shell metacharacters embedded in the uploaddir parameter, resulting in direct OS command execution on the NVR.' NIST-800-53-CM-7 gap: 'An unauthenticated remote-command-execution path in the firmware-upgrade handler should never have been network-reachable; least-functionality review would have caught missing authentication on this endpoint.' NIS2-Art21-vulnerability-management gap: 'EU operators with NVRmini devices still deployed have no patch path; Art. 21 requires network isolation or replacement as the compensating control for unremediable flaws.' UK-CAF-C1 gap names 'subsequent botnet enlistment of the camera recorder'. patch_available false, live_patch_available false; CWE-78; CVSS 9.8; poc_available true; active_exploitation confirmed; kev_date 2024-12-18.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "On this entry the control's premise applies in its strongest form: the NVRmini cannot be its own log source at all. The packet's flaw hands an unauthenticated remote caller OS command execution on the recorder, so anything the device reports about itself is attacker-controlled, there is no vendor fix coming that would change that, and an end-of-life appliance carries no endpoint agent — which is precisely why the entry's monitoring gap records that compromise and the botnet enlistment that follows proceed unobserved. The separate-trust-zone collector therefore has to be fed by the network boundary in front of the recorder rather than by the recorder itself, and held where the compromised device cannot reach or alter it. Key the detection on the two behaviours the packet documents, not on a proxy for them. The first is the exploit request as it crosses the boundary: unauthenticated HTTP requests to upgrade_handle.php carrying the writeuploaddir command with shell metacharacters in the uploaddir parameter — this is a device whose management surface should see a small, predictable set of callers, so requests to that path from anything but an operator host are the signal, and a single successful request is the whole exploit. The second is what the packet says happens after: outbound connections from the recorder to destinations outside the small set it normally speaks to, which is the botnet enlistment named in the monitoring gap. Ask what an exploit doing exactly what the packet describes would emit — one crafted HTTP request in, then new outbound sessions — and note what will not see it: the recorder's own logs, signature-based endpoint tooling that has nothing to run on, and any rule keyed on a process crash or on named exploit tooling, since the request is served by the device's normal web handler and nothing crashes. Precondition: this requires boundary telemetry already being collected and shipped off-device before the attempt, and on the branch and facilities segments where these recorders sit that is exactly where it is least often enabled; a rule written afterwards against telemetry nobody was collecting produces nothing. Detection also prevents nothing here — with no patch available it bounds the window to alert-and-response time on a device whose only closure is removal.",
+        "evidence": "Packet UK-CAF-C1 gap: 'Security-monitoring outcomes seldom cover EoL NVR appliances, so unauthenticated command-injection compromise and subsequent botnet enlistment of the camera recorder proceed unobserved with no vendor fix to close the endpoint.' vector: 'upgrade_handle.php on NUUO NVRmini devices allows Remote Command Execution via shell metacharacters in the uploaddir parameter for a writeuploaddir command.' attack_vector: 'An unauthenticated attacker sends a crafted request to upgrade_handle.php... resulting in direct OS command execution on the NVR.' patch_available false, live_patch_available false, live_patch_notes null; active_exploitation confirmed with active_exploitation_notes recording 'continued exploitation of end-of-life devices still deployed in the field'; poc_available true; kev_date 2024-12-18.",
+        "gap_closes": [
+          "UK-CAF-C1"
+        ]
+      }
+    ]
   },
   "CVE-2024-55956": {
     "name": "Cleo Multiple Products Unauthenticated File Upload Vulnerability",
@@ -41818,7 +41989,40 @@
         "adequate": false,
         "gap": "Vulnerability handling did not anticipate that authentication middleware scoped only to POST requests was trivially bypassable via GET."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "CyberPanel's secMiddleware is where the panel makes its authentication decision, and this CVE is that layer failing open along a dimension nobody tested: the middleware enforces only on POST, so a GET to /dns/getresetstatus or /ftp/getresetstatus reaches getresetstatus in dns/views.py and ftp/views.py with no authentication at all, and the statusfile property is then carried unsanitized into a shell command. Bound to this product the control means each management function in the panel authorizes its own caller before the view body runs, rather than inheriting a verdict from the middleware fronting it, and that the authorization decision is independent of HTTP verb — a middleware that dispatches on request method is a middleware with an unauthenticated path by construction. The second half is reachability: the packet records roughly 22,000 internet-facing instances compromised, so a panel administrative surface that answers from the open internet is the precondition the campaign relied on. The least-privilege framing the entry's access-enforcement gap is scored against never applies on this path, because the attacker holds no CyberPanel account at any privilege — per-account scoping is never consulted, so the account model an access-control attestation examines is bypassed rather than abused. Distinguishing test on a staging CyberPanel: issue unauthenticated requests to each reset-status endpoint using every HTTP verb the framework will route, not only the one the application documents, and confirm each is refused before the view function executes — an attestation that every panel administrator authenticates at login passes cleanly while the GET path stays wide open.",
+        "evidence": "The packet's vector and affected fields state that getresetstatus in dns/views.py and ftp/views.py allows remote attackers to bypass authentication and execute arbitrary commands via /dns/getresetstatus or /ftp/getresetstatus by bypassing secMiddleware (which is only for a POST request) and using shell metacharacters in the statusfile property. attack_vector confirms the sequence: GET instead of POST to bypass the middleware, then shell metacharacters in statusfile. active_exploitation_notes records mass exploitation within days of disclosure by the PSAUX ransomware campaign in October 2024, compromising roughly 22,000 internet-facing CyberPanel instances. cvss 10, rwep_score 70, poc_available true, cisa_kev true (2024-12-04). The cited NIST-800-53-AC-3 gap states access enforcement was implemented only for POST requests; the ISO-27001-2022-A.8.28 gap states secure coding should have caught middleware guarding only POST; the AU-Essential-8-Patch gap states the patch control alone does not address the underlying authentication-middleware design flaw; the UK-CAF-B4 gap states this class of flaw remained internet-exposed at scale.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "ISO-27001-2022-A.8.28",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "CyberPanel is the management plane for every site and service the host serves, reached over the internet, and the packet's exploitation record is not a handful of intrusions — roughly 22,000 internet-facing instances were compromised within days of disclosure by the PSAUX ransomware campaign in October 2024 through an unauthenticated OS-command-execution path. For any instance that was internet-reachable while running an affected build (through 2.3.6, or 2.3.7 before the fix), the requirement is that moving to the build carrying commit 1c0c6cb is treated as closing the entry path only: the panel host is rebuilt from a known-good baseline, and every credential it held or that transited it — panel administrator, hosted-site, DNS and FTP account material — is rotated. Arbitrary OS command execution through the reset-status endpoint leaves whatever the attacker wrote in place, and updating the code removes none of it, which is why the flaw-remediation control this entry cites can be satisfied on paper by an instance that is still under attacker control. Precondition, stated so this is not applied indiscriminately: the rebuild path is for instances that were reachable while unpatched during the exposure window; an install that was never exposed is a straight update, and an operator who cannot establish which it was should treat it as the former, because the packet's mass-scanning-scale campaign gives no basis for assuming a reachable panel went untouched.",
+        "evidence": "active_exploitation_notes: mass-exploited within days of disclosure by the PSAUX ransomware campaign in October 2024, compromising roughly 22,000 internet-facing CyberPanel instances by chaining the HTTP-verb auth bypass with shell metacharacter injection. active_exploitation is confirmed and poc_available is true. The vector states the flaw allows remote attackers to bypass authentication and execute arbitrary commands, and gives the affected population as versions through 2.3.6 and unpatched 2.3.7, fixed at commit 1c0c6cb. The cited NIST-800-53-SI-2 gap states patch-SLA cadence did not prevent the 22,000-instance mass-exploitation event; the UK-CAF-B4 gap states system-security lifecycle management allowed a hosting control panel with this class of flaw to remain internet-exposed at scale. The packet records no live-patch path (live_patch_available false, live_patch_notes null) and no vendor-named interim mitigation.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet's timeline is both the argument for this control and its honest limit on this entry. PSAUX mass exploitation ran in October 2024, within days of disclosure, while the KEV listing is dated 2024-12-04 — so a KEV-anchored clock had no force during the campaign itself, and the population compromised then belongs on the rebuild path rather than the patch path. What the clock governs is the long tail: instances still running an affected build (through 2.3.6, or 2.3.7 unpatched) after the listing, which for a hosting control panel installed per-server, often by a reseller or an end customer and rarely under any central software-management console, is the larger population and the one no enterprise patch cadence is even aware of. The requirement is therefore an enumeration before a clock: identify every CyberPanel install the organization operates or hosts, including those on customer-controlled servers, and move each to the build carrying commit 1c0c6cb on the KEV clock rather than a routine application-patch cycle, with completion measured by the build each install actually runs. The packet records no live-patch mechanism and names no vendor interim mitigation, so the only holding measure while that enumeration runs is restricting which networks can reach the panel's HTTP surface — and that lever is unavailable wherever the panel must answer from the internet to do its job, which describes most of the affected population.",
+        "evidence": "cisa_kev true with kev_date 2024-12-04; active_exploitation_notes place the PSAUX mass-exploitation campaign in October 2024, within days of disclosure, against roughly 22,000 internet-facing instances — before the KEV listing. affected_versions: through 2.3.6, 2.3.7 unpatched at disclosure, fixed at commit 1c0c6cb. patch_available true, live_patch_available false, live_patch_notes null — the packet names no vendor interim mitigation. cvss 10, rwep_score 70, poc_available true. The cited NIST-800-53-SI-2 gap states patch-SLA cadence did not prevent a mass-exploitation event that occurred within days of public disclosure.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-11680": {
     "name": "ProjectSend Improper Authentication Vulnerability",
@@ -42440,7 +42644,40 @@
         "adequate": false,
         "gap": "Boundary protection guidance directly addresses this threat: the vendor's own advisory states risk is greatest when the management interface is reachable from the internet or an untrusted network, which is a configuration control independent of patching."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "A PAN-OS firewall is the trust boundary, so a root-privilege command injection in its management web interface cannot sit in the same SLA tier as ordinary application patching — the tier requirement here is the vendor hotfix deployed on the clock that opened with the 2024-11-18 KEV listing, or isolation of the management interface until it is, and not the standard 14/30-day cycle. Scope the sweep from the packet's affected field rather than the word firewall: PA-Series, VM-Series and CN-Series firewalls, Panorama, and WildFire appliances all carry this interface, and Cloud NGFW and Prisma Access are explicitly excluded, so an estate that patches its PA-Series units while Panorama and the WildFire appliances stay behind is not remediated. Each branch has its own fixed build — 10.1.14-h6, 10.2.12-h2, 11.0.6-h1, 11.1.5-h1, 11.2.4-h1 — so the completion record is the running build per unit against the fixed build for that unit's branch, not a count of units with a hotfix downloaded. The packet records patch_required_reboot true with no live-patch path, so a unit that has loaded the image but has not rebooted onto it is still executing the vulnerable code and counts as exposed; on a production firewall that reboot is the step most likely to be deferred into a maintenance window, and a deferral recorded as patched is the specific way this remediation goes wrong.",
+        "evidence": "KEV-listed 2024-11-18 with active_exploitation confirmed, poc_available true, RWEP 82, CVSS 7.2. active_exploitation_notes record exploitation in the wild chained with CVE-2024-0012 (PAN-OS management-interface authentication bypass) for unauthenticated root-level command execution on internet-exposed firewalls, a CISA KEV known-ransomware-actor flag, and Palo Alto Networks/Unit 42 confirming mass exploitation against devices with an internet-facing management interface. affected names PA-Series, VM-Series, CN-Series firewalls, Panorama and WildFire appliances, with Cloud NGFW and Prisma Access not affected; affected_versions give PAN-OS 10.1 prior to 10.1.14-h6, 10.2 prior to 10.2.12-h2, 11.0 prior to 11.0.6-h1, 11.1 prior to 11.1.5-h1, 11.2 prior to 11.2.4-h1. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null. The NIST-800-53-SI-2 gap records that hotfixes shipped across all supported branches but mass exploitation began before many organizations completed emergency patching; the AU-Essential-8-Patch gap records attackers scanning and exploiting exposed management interfaces within days of disclosure against a 48-hour bar; the UK-CAF-B4 gap records patch timelines for critical perimeter infrastructure tested by the compressed window between advisory publication and confirmed mass exploitation.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "Panorama administers the firewall estate and each PAN-OS unit's management web interface administers the traffic policy, so this is a control plane whose administrative surface must be treated as its own tier rather than folded into general admin — reached only from a dedicated management network through a jumphost or privileged workstation, never answering from the internet or a general user segment, and enumerated as such for PA-Series, VM-Series and CN-Series firewalls, Panorama, and the WildFire appliances the packet names. The reachability half of the tier is the load-bearing half for this CVE, and the precondition has to be said plainly: the packet's own attack_vector has the injection chained with CVE-2024-0012, an authentication bypass on the same interface, so the attacker never presents a credential and the tier's credential-strength elements — step-up authentication, just-in-time elevation, separate admin identity — give nothing against the observed campaign. Only the restriction on who can reach the interface bounds it, and it bounds rather than closes: any host inside the permitted management segment still reaches the injection path, so a compromised jump host satisfies the precondition in full. Distinguishing test: from a general user VLAN and from an external address, attempt to load the PAN-OS management web interface on each unit and confirm nothing answers — an audit confirming every firewall administrator holds a unique, MFA-backed account passes cleanly while the interface stays reachable from an untrusted network.",
+        "evidence": "The packet's affected field states that a PAN-OS administrator — or an attacker who first bypasses authentication via CVE-2024-0012 — can perform OS command injection executed with root privileges on the management web interface, and the attack_vector states that in the observed mass-exploitation campaign an unauthenticated attacker with network access to an internet-exposed management interface could achieve root command execution directly. The NIST-800-53-SC-7 gap records the vendor's own advisory stating risk is greatest when the management interface is reachable from the internet or an untrusted network, which is a configuration control independent of patching; the ISO-27001-2022-A.8.22 gap records that segregation of networks is the controlling measure and that the ransomware campaigns targeted exactly the instances where the interface was internet-exposed rather than confined to an isolated management network; the NIS2-Art21-network-security gap records internet-exposed management interfaces on perimeter firewalls as precisely the covered scenario, with the KEV ransomware flag underscoring criticality for regulated sectors.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "ISO-27001-2022-A.8.22",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "For any PAN-OS unit whose management web interface was reachable from the internet or another untrusted network during the exposure window, reaching 10.1.14-h6 / 10.2.12-h2 / 11.0.6-h1 / 11.1.5-h1 / 11.2.4-h1 is not the remediation record — the packet describes mass exploitation of exactly that population and a chained path ending in root command execution on the device, and a hotfix plus reboot removes the injection path without removing anything root already did. The default for those units is therefore configuration export for forensic comparison, rebuild onto the fixed build from a known-good image, rotation of every administrative credential and key material the device held, and a review of the running security policy and configuration against a known-good copy, since the vector is explicit that actions are performed with root privileges and policy modification is within reach. This is what the flaw-remediation control does not carry: its verdict is satisfied by a version number, so a firewall that was rooted before the emergency patch landed is marked remediated while the attacker's residue survives the upgrade. Precondition on scope: this applies to units whose management interface was reachable from an untrusted network during the window, which is the population the packet's campaign describes; a unit whose management interface has only ever answered on an isolated management network is a patch-and-reboot item, and treating the whole estate as compromised manufactures rebuild work the evidence does not support.",
+        "evidence": "active_exploitation_notes record active exploitation in the wild chained with CVE-2024-0012 for unauthenticated root-level command execution on internet-exposed firewalls, a CISA KEV known-ransomware-actor flag, and Palo Alto Networks/Unit 42 confirming mass exploitation against devices with an internet-facing management interface; KEV listing 2024-11-18, poc_available true, RWEP 82. The vector states that the vulnerability allows a PAN-OS administrator with access to the management web interface to perform actions on the firewall with root privileges. The NIST-800-53-SI-2 gap records that hotfixes shipped across all supported PAN-OS branches but mass exploitation began before many organizations completed emergency patching of internet-facing firewalls — that is, devices were reached before the patch, which is the condition under which a version-based remediation verdict is wrong. patch_required_reboot is true, live_patch_available is false and live_patch_notes is null, so no interim vendor mitigation covered the interval.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-1212": {
     "name": "Progress Kemp LoadMaster OS Command Injection Vulnerability",
@@ -42477,7 +42714,39 @@
         "adequate": false,
         "gap": "Boundary protection didn't stop exploitation because the LoadMaster management interface was reachable from untrusted networks; restricting management-plane access was vendor guidance, not an enforced default."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "Progress Kemp LoadMaster is an application delivery controller and load balancer — the edge load-balancer class this tier names — and the packet's flaw is an unauthenticated command injection in the appliance's own management interface, so the device that terminates and steers traffic for everything behind it is what gets taken over. Applied here the tier means every LoadMaster reaches its branch's fixed build on the KEV clock that opened 2024-11-18 rather than on an appliance-maintenance cadence, and where that cannot be met, the management interface is isolated until it can. Completion has to be counted per unit against its own branch: the packet's affected range starts after 7.2.48.1 with fixes at 7.2.48.10, 7.2.54.8 and 7.2.59.2, so the target build depends on which branch the unit is on, and the range explicitly includes LoadMaster Multi-Tenant (MT) VFNs — an estate that updates its standalone appliances while the MT virtual functions stay on a pre-fix build has not finished and will report clean on a sweep scoped to appliances. The packet records patch_required_reboot true with no live-patch path, so a unit that has taken the firmware but has not rebooted onto it is still executing the vulnerable code and counts as exposed. Precondition that has to be stated plainly: the KEV clock opened 2024-11-18 but the packet dates in-the-wild exploitation to at least April 2024, so meeting the tier bounds future exposure and is not evidence the unit was never reached — a LoadMaster that was reachable across that window needs forensic triage and rotation of the default 'bal' administrative credential rather than closure on the patch record.",
+        "evidence": "The packet records cisa_kev true with kev_date 2024-11-18, active_exploitation confirmed and exploited in the wild since at least April 2024, poc_available true, CVSS 10 with rwep_score 77, patch_available true, patch_required_reboot true, live_patch_available false and live_patch_notes null. affected identifies the product as a Progress Kemp LoadMaster application delivery controller/load balancer with unauthenticated command injection via the management web interface, affecting all LoadMaster releases after 7.2.48.1 including Multi-Tenant (MT) VFNs; affected_versions lists releases after 7.2.48.1 and before 7.2.48.10, before 7.2.54.8, before 7.2.59.2, and LoadMaster Multi-Tenant (MT) VFNs. The active-exploitation note records post-exploitation escalation from the default 'bal' admin account to root by abusing sudo entries. The cited flaw-remediation gap states the standard SLA is far slower than the roughly seven-month gap between silent April 2024 exploitation and the November 2024 KEV due date.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The defect sits on LoadMaster's management web interface: the packet has an unauthenticated remote attacker reaching that interface and executing arbitrary system commands, so the endpoint's own authorization decision and its handling of caller-supplied content are the only things standing between an untrusted caller and command execution on the appliance. Bound to this product the control means the management interface authorizes its caller before request content reaches any command construction, and neutralizes that content rather than passing it into a shell; and that no LoadMaster instance — standalone appliance or MT VFN — is left with its management interface reachable from a segment with no operational need to reach it, in particular from the internet or a general user VLAN. This is also why the least-privilege reading of the appliance's account model does not help: the attacker holds no LoadMaster operator account at the point of injection, so per-account scoping is never consulted. Distinguishing test: from a segment with no load-balancer administration role, send an unauthenticated request carrying shell metacharacters to the management interface of a staging LoadMaster and confirm it is refused before any command runs. Preconditions: the endpoint-side authorization and input neutralization are properties the vendor firmware establishes — this control states what to verify, it does not implement it. Until that firmware and its reboot land, restricting which segments can reach the management interface bounds who can send the request but leaves the injection fully reachable from anything inside the permitted segment, and it gives nothing on a deployment where the interface must stay reachable for normal administration.",
+        "evidence": "The packet's vector states that unauthenticated remote attackers can access the system through the LoadMaster management interface, enabling arbitrary system command execution, with cwe_refs CWE-78. The attack_vector describes an unauthenticated crafted request to the management web interface injecting OS commands that execute in the context of the web service, followed by a sudo-abuse step escalating from the default admin account to root. The cited boundary-protection gap records that the management interface was reachable from untrusted networks and that restricting management-plane access was vendor guidance rather than an enforced default; the NIS2 network-security gap records EU operators lacking the management-plane segmentation CISA's mitigation calls for; the UK CAF gap records secure-configuration guidance as insufficient to prevent an unauthenticated command injection in a security-critical appliance's admin interface.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-031",
+        "name": "FIREWALL-EGRESS-TELEMETRY-SEPARATE-TRUST-ZONE",
+        "description": "The packet's post-exploitation step is what makes this control load-bearing on a LoadMaster: the attacker escalates from the default 'bal' administrative account to root by abusing sudo entries, and root on the appliance owns whatever record the appliance was keeping of how it was reached. The requirement here is that LoadMaster's syslog, administrative-access and authentication events leave the unit in real time to a collector in a separate trust zone — different management plane, different credentials, different authentication path — instead of being retained on the appliance the attacker roots. What that collector has to carry is the behaviour the packet documents rather than a generic appliance feed: requests to the management web interface that are followed by command execution in the web service's context, and sudo invocations by the 'bal' account, since those two are precisely the recorded exploitation path and the recorded escalation. Preconditions: this is a detection and post-incident control, not a mitigation — it does not stop the injection, and it produces nothing unless forwarding was already configured before the attempt. It also cannot recover what a rooted unit deleted locally in a period when nothing was being forwarded, which matters here because the packet dates exploitation to at least April 2024, months before the 2024-11-18 KEV listing that prompted most operators to look at these appliances at all.",
+        "evidence": "The packet's active-exploitation note records that post-exploitation attackers escalate from the default 'bal' admin account to root by abusing sudo entries, with exploitation in the wild since at least April 2024 and the KEV listing on 2024-11-18. The attack_vector records OS commands executing in the context of the web service followed by the sudo-abuse escalation to root. The cited monitoring gap states that A.8.16 monitoring of a load balancer rarely inspects management-interface command execution, so a CVSS 10 unauthenticated injection yielding full command execution on the LoadMaster runs without the logging or alerting the control nominally provides for a security-critical appliance.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.16"
+        ]
+      }
+    ]
   },
   "CVE-2024-0012": {
     "name": "Palo Alto Networks PAN-OS Management Interface Authentication Bypass Vulnerability",
@@ -42644,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",
@@ -43278,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",
@@ -43620,7 +43944,29 @@
         "adequate": false,
         "gap": "Component-inventory and least-functionality practices didn't flag an unreviewed bundled third-party utility as an independent attack surface within SL1."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The packet's own description of this flaw is the inventory gap stated as a fact: an unspecified vulnerability in an unspecified third-party component packaged with ScienceLogic SL1. The operator's asset record says 'ScienceLogic SL1, 11.2.x' and stops there, so the component that actually carried the remote code execution was never an item anyone tracked, scanned, threat-modelled or held a patch SLA against — which is exactly what the least-functionality and component-inventory control cited on this entry failed to catch. For this platform the requirement is that the inventory extends past the purchased product into what the product bundles: obtain from ScienceLogic a component manifest for each SL1 release in service, and where the vendor will not name what it packages, record the platform as a surface of unmeasured composition rather than as a satisfied inventory line, and carry that as an accepted risk with an owner instead of an invisible one. The distinguishing test is producing the artifact, not running a scan: for each SL1 release in the estate — the packet's affected lines run 10.1.x, 10.2.x, 11.1.x, 11.2.x, 11.3.x, 12.1.x, 12.2.x and 12.x — produce the list of third-party components it packages and the version of each. An estate that can produce a complete software inventory of every device SL1 monitors, which is what the platform exists to do, while unable to produce the composition of the monitoring platform itself, has inventoried everything except the asset that reads all the others. Precondition, and it is a real one: this control cannot name a component the vendor declines to name, and the advisory in this packet never does, so it produces no detection and no patch on its own. What it produces is an accurate record of an unmeasured surface and the procurement lever to change that at the next renewal; the remediation for this specific CVE remains the vendor platform update.",
+        "evidence": "The packet's vector states SL1 (formerly EM7) is affected by an unspecified vulnerability involving an unspecified third-party component packaged with SL1, and the affected field describes SL1 releases bundling a vulnerable, unnamed third-party utility that allows remote code execution. affected_versions enumerate 10.1.x, 10.2.x, 11.1.x, 11.2.x, 11.3.x, 12.1.x < 12.1.3, 12.2.x < 12.2.3 and 12.x < 12.3. The cited NIST-800-53-CM-7 gap states component-inventory and least-functionality practices didn't flag an unreviewed bundled third-party utility as an independent attack surface within SL1; the cited NIS2-Art21-vulnerability-management gap states supply-chain vulnerability management for bundled third-party components within a monitored MSP platform failed to catch the exposure before exploitation. active_exploitation is confirmed and cisa_kev is true (2024-10-21).",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the control's honest scope is the post-listing population, and saying so is part of applying it correctly. The packet records exploitation of ScienceLogic SL1 as a zero-day against Rackspace's MyRack portal, a hosted SL1 deployment, before any vendor fix existed — no response SLA has force in that window, which is precisely what this entry's flaw-remediation and patch-cadence gaps record. What the 2024-10-21 KEV listing establishes is that no SL1 deployment lacks a target build: the packet gives remediated releases at 12.1.3+, 12.2.3+ and 12.3+, with remediations made available back through the 10.1.x, 10.2.x, 11.1.x, 11.2.x and 11.3.x lines, so 'our appliances are on an older line' is not an available deferral. The requirement is that every SL1 appliance and collector moves to its own line's remediated release on the KEV clock rather than on the routine platform-upgrade cycle a monitoring system usually sits in, with completion measured by the release each appliance reports as running rather than by a change ticket marked approved — the packet records no live-patch path, so the platform update is the remediation and nothing bridges the interval before it lands. Two things shape priority beyond the base score. The platform is the one that watches everything else, so its own degradation reads as an operations event: in the observed case the compromise surfaced as a monitoring-graph outage rather than as a security detection. And the packet records the intrusion exposing customer account names, usernames, device details and encrypted internal credentials — so for a deployment that was exposed, the stored material it held is treated as disclosed and rotated as part of the response, because the update does not invalidate anything already read out.",
+        "evidence": "cisa_kev true with kev_date 2024-10-21; active_exploitation confirmed; active_exploitation_notes record exploitation as a zero-day against Rackspace's MyRack monitoring portal (a hosted ScienceLogic SL1 deployment), disrupting monitoring-graph availability and exposing customer account names, usernames, device details, and encrypted internal credentials, and note CISA does not flag it as ransomware-associated. The vector states the vulnerability is addressed in SL1 12.1.3+, 12.2.3+ and 12.3+, with remediations made available for all SL1 versions back to the 10.1.x, 10.2.x, 11.1.x, 11.2.x and 11.3.x lines. patch_available true, live_patch_available false, live_patch_notes null. cvss 9.8, rwep_score 46, poc_available false. The cited NIST-800-53-SI-2 gap states flaw-remediation SLAs can't apply pre-disclosure because the component's vulnerability was unknown to the vendor until active zero-day exploitation was discovered; the cited AU-Essential-8-Patch gap states patch-maturity cadence is meaningless against a zero-day exploited before any vendor fix existed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-40711": {
     "name": "Veeam Backup and Replication Deserialization Vulnerability",
@@ -44323,7 +44669,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",
@@ -44429,7 +44809,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",
@@ -44466,7 +44872,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",
@@ -44646,7 +45077,41 @@
         "adequate": false,
         "gap": "NIS2 vulnerability-handling expects prompt remediation, but Ivanti CSA 4.6 was already flagged End-of-Life when the flaw was disclosed, leaving organizations with no vendor-supported patch path other than full migration."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet supplies both facts this control turns on: a vendor fix exists — Ivanti CSA 4.6 Patch 519 — and the 4.6 branch itself is recorded as End-of-Life, with the NIS2, ISO, AU-ISM and UK-CAF gaps each stating in their own vocabulary that there is no supported remediation path beyond migration. So for this product a unit that reaches Patch 519 is fixed for this specific path traversal and holds no security-update path for anything found in that branch afterward: Patch 519 is the interim state and removal of the 4.6 appliance is the terminal one. In operational terms, inventory every Ivanti Cloud Services Appliance in service with its branch and patch level; put any unit below Patch 519 on the clock that opened with the 2024-09-19 KEV listing against CISA's 2024-10-10 due date; and put every 4.6 unit, including those that reach Patch 519, on a dated migration schedule off the branch — a risk acceptance with no removal date leaves an internet-facing appliance with a public PoC and confirmed exploitation in service indefinitely, and it is precisely what lets a patch-compliance report mark this estate clean. Scope the inventory to what the packet names: the CSA appliance, its broker web server and its PHP CGI path handling. The packet ties the URL-decoding-order defect to that appliance and gives no mapping into other Ivanti products, so sweeping the wider estate as instances of this CVE manufactures replacement work against software no evidence implicates. Precondition on the interim half: patch_required_reboot is true and no live-patch path is recorded, so a unit that has taken Patch 519 without the restart is still executing the vulnerable code and counts as exposed. And because exploitation is confirmed and the packet describes webshells and reverse-shell implants deployed through this appliance, a unit that was internet-reachable while unpatched is not made clean by either the patch or the migration on its own — its disposition is rebuild and credential rotation, not a configuration carried forward onto its replacement.",
+        "evidence": "affected_versions: 'Ivanti CSA 4.6.x before Patch 519 (branch now End-of-Life)'; patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes null; cisa_kev true, kev_date 2024-09-19, active_exploitation_notes 'CISA KEV added 2024-09-19 (due 2024-10-10)'; NIS2-Art21-vulnerability-handling gap: 'Ivanti CSA 4.6 was already flagged End-of-Life when the flaw was disclosed, leaving organizations with no vendor-supported patch path other than full migration'; AU-ISM-1546 gap: control 1546 'cannot be satisfied for a product the vendor states will receive no further security updates'; ISO-27001-2022-A.8.8 gap: 'an EOL appliance falls outside normal patch-remediation SLAs, requiring a decommission/migration control instead of a patch cycle'; UK-CAF-B4 gap: 'running an EOL CSA 4.6 branch in production is itself a CAF B4 gap independent of this specific CVE'; affected: the CSA 'broker' web server and PHP CGI path-handling; poc_available true; active_exploitation_notes record webshells and reverse-shell implants deployed on internet-facing CSA appliances by suspected nation-state actors chaining CVE-2024-8190.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling",
+          "ISO-27001-2022-A.8.8",
+          "AU-ISM-1546",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Every trigger condition this control names is present in the packet: an internet-facing appliance, a remote unauthenticated path into restricted administrative functionality, confirmed exploitation, and — the part that makes patch-in-place the wrong default — attacker persistence already established, with webshells and reverse-shell implants deployed after the traversal was chained with CVE-2024-8190 for command execution. Applied to the Ivanti CSA, that means any appliance internet-reachable while below Patch 519 defaults to configuration export for forensics, rebuild, and rotation of every credential and secret the appliance held or that transited it during the exposure window, rather than to installing Patch 519 and closing the ticket. Patch 519 repairs the inconsistent URL-decoding between the broker web server and PHP CGI; it evicts nothing an implant established through it, and neither does the restart the fix requires. Two things specific to this entry make the rebuild step sharper than usual. First, the disposition is not rebuild-onto-the-same-branch: restoring the 4.6 configuration onto a fresh 4.6 unit carries forward both the End-of-Life status and any attacker-modified configuration, so the rebuild is the moment the migration off the branch happens. Second, the packet attributes the activity to suspected nation-state actors, so implants should be assumed to be bespoke rather than expected to match a signature. Precondition: this control is a disposition rule, not a detection method — it does not tell an operator whether a given appliance was reached. Where the exposure window cannot be bounded from evidence held off the appliance, an appliance that was internet-reachable while unpatched has to be treated as compromised rather than cleared, because the artefacts that would show otherwise sit on the device the attacker controlled.",
+        "evidence": "active_exploitation_notes: 'Suspected nation-state actors chained this path traversal with CVE-2024-8190 (OS command injection) to bypass authentication and execute arbitrary commands on internet-facing CSA appliances, deploying webshells and reverse-shell implants'; attack_vector: an unauthenticated attacker sends a %3F-encoded path segment against the CSA broker web server, exploiting inconsistent URL-decoding order between the broker and PHP CGI, yielding authenticated command execution and webshell deployment when chained; vector: 'Path Traversal in the Ivanti CSA before 4.6 Patch 519 allows a remote unauthenticated attacker to access restricted functionality'; cisa_kev true (2024-09-19, due 2024-10-10), active_exploitation 'confirmed', poc_available true, rwep_score 76, cvss 9.4; patch_available true with patch_required_reboot true and live_patch_available false; affected_versions record the 4.6 branch as End-of-Life; NIS2-Art21-vulnerability-handling and ISO-27001-2022-A.8.8 gaps both record that a patch cycle is not the available remediation for this appliance.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-handling",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The CSA is itself the boundary this flaw defeats, which is what the boundary-protection gap on this entry says: the control assumes the appliance correctly parses and enforces path restrictions at its network edge, and the URL-decoding-order bug smuggled traversal past that parser entirely. A defect of that shape on a device that IS the trust boundary does not belong in a severity-keyed patch timeframe — which is the second gap here, since the Australian ISM control prescribes timeframes based on severity and cannot deliver them for this product at all past Patch 519. The requirement for this appliance is a distinct tier: an unauthenticated-reachable defect on the CSA is mitigated within hours of the KEV listing rather than within a 14- or 30-day window, measured against CISA's 2024-10-10 due date on a 2024-09-19 listing, and the tier must state its own exit condition — for an End-of-Life branch that condition is migration, not a patch level. Precondition, and this is where this control is most often over-claimed: the alternative the tier normally offers — isolate the vulnerable interface — is not generally available here. The packet's exploited population is internet-facing CSA appliances, so restricting who can send the %3F-encoded request works only where the set of legitimate client addresses is enumerable and can be enforced ahead of the appliance; where the appliance must stay reachable from untrusted networks there is no segment that removes the path, and recording a reachability restriction as the mitigation while the broker web server still answers the internet leaves the flaw fully exploitable. Under those conditions the tier's only honest exit is the migration the decommission requirement describes.",
+        "evidence": "NIST-800-53-SC-7 gap: 'SC-7 boundary protection assumes the appliance correctly parses and enforces path restrictions at its network edge; the URL-decoding-order bug let attackers smuggle traversal past the boundary parser entirely'; AU-ISM-1546 gap: 'ISM control 1546 (patching within timeframes based on severity) cannot be satisfied for a product the vendor states will receive no further security updates'; vector: remote unauthenticated attacker accesses restricted functionality in Ivanti CSA before 4.6 Patch 519; active_exploitation_notes: KEV added 2024-09-19 (due 2024-10-10), exploitation against internet-facing CSA appliances; affected: the CSA 'broker' web server and PHP CGI path-handling allowing unauthenticated access to restricted administrative functionality; affected_versions: CSA 4.6.x before Patch 519, branch now End-of-Life; cvss 9.4, rwep_score 76, poc_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "AU-ISM-1546"
+        ]
+      }
+    ]
   },
   "CVE-2026-58644": {
     "name": "Microsoft SharePoint Deserialization of Untrusted Data Vulnerability (CVE-2026-58644)",
@@ -44743,7 +45208,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)",
@@ -44780,7 +45280,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",
@@ -45126,7 +45662,39 @@
         "adequate": false,
         "gap": "The KEV due date is three days after listing; a standard flaw-remediation SLA measured in weeks leaves the internet-facing AMC exploitable well past the observed exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock this appliance runs on is not the organization's patch cadence. CISA listed CVE-2026-15410 on 2026-07-14 with a three-day due date against confirmed in-the-wild abuse of SMA1000 SSL-VPN appliances, while the flaw-remediation gap on this entry records a standard SLA measured in weeks. Applied to this product, the control means every SMA1000 series unit is driven to the SNWLID-2026-0008 fixed release on the KEV clock rather than folded into the next appliance-maintenance window, with completion measured per unit by the firmware the appliance is actually running rather than by 'approved' or 'downloaded' in a management record. The packet registers no live-patch primitive and a vendor update that requires a reboot, so a unit that has staged the firmware but has not restarted onto it is still executing the vulnerable code and must be counted as exposed — on a remote-access appliance that restart is the step most likely to be deferred, because taking it drops the sessions the appliance exists to carry, and a deferral recorded as patched is the specific way this remediation goes wrong. Scope the sweep to the SMA1000 series named in the packet's affected and affected_versions fields, and widen only where a verified source identifies another product carrying the same code. Precondition: this control is a scheduling and verification requirement, not a mitigation — the packet gives the vendor update as the remediation with no live-patch path, so nothing here reduces exposure during the window before that release and its reboot land.",
+        "evidence": "cisa_kev true with kev_date 2026-07-14 and active_exploitation confirmed; the packet's active_exploitation_notes record a three-day due date signalling observed in-the-wild abuse of SMA1000 SSL-VPN appliances. patch_available true, live_patch_available false, patch_required_reboot true, with live_patch_notes stating 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' affected_versions gives 'SMA1000 firmware prior to the SNWLID-2026-0008 fixed release'. The NIST-800-53-SI-2 gap states the KEV due date is three days after listing and a standard flaw-remediation SLA measured in weeks leaves the internet-facing AMC exploitable well past the observed exploitation window; the AU-Essential-8-Patch gap states Essential Eight patch timelines for internet-facing services can lag the emergency vendor mitigation this appliance needs before the CISA due date.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The SMA1000 Appliance Management Console is the device-management surface this control governs, and the packet puts the defect squarely on it: the AMC accepts an administrator-supplied management field and generates and executes arbitrary OS commands from it. Bound to this appliance the requirement has two halves. First, every AMC field that feeds a system-level operation validates and neutralizes its content before the command is constructed, so management input cannot select what the appliance executes at the OS level. Second, no SMA1000 is left with its AMC answering from a segment that has no operational need to administer it — that is the network-security half, and the packet's own gap records the console exposed to reachable networks while segmentation is what keeps a post-authentication code-injection path from becoming a network foothold. Distinguishing test for this product: on a staging SMA1000, submit shell metacharacters in each AMC management field that reaches a system operation and confirm the value is rejected before anything executes; and from a general user VLAN, attempt to load the AMC and confirm it does not answer. An appliance that passes an administrator-account review while its console answers from any internal segment is still one credential away from the published path. Precondition, and this is where the control is most often over-claimed: input neutralization inside the AMC is a property the SNWLID-2026-0008 release establishes — this control states what to verify, it does not implement it. Until that release and its reboot land, restricting which segments reach the AMC bounds who can attempt the injection but leaves it fully exploitable from inside the permitted segment, and it is unavailable where the console must stay reachable for routine remote administration.",
+        "evidence": "The packet's affected field: 'SonicWall SMA1000 series appliances, Appliance Management Console (AMC), where a remote authenticated administrator can inject and execute arbitrary OS commands under specific conditions.' attack_vector: an attacker holding administrator access to the SMA1000 AMC injects OS command syntax into an accepted management field, causing the appliance to execute attacker-chosen commands at the underlying OS level. cwe_refs lists CWE-94. The ISO-27001-2022-A.8.28 gap states the SMA1000 AMC generates and executes code from administrator-supplied input without command-execution guards, turning any privileged credential into arbitrary OS commands on the appliance host; the NIS2-Art21-network-security gap states exposing the SMA1000 management console to reachable networks violates the segmentation needed to keep a post-auth RCE from becoming a network foothold; the UK-CAF-B4 gap states the appliance trusts privileged input without command-execution guards. patch_available true with the fixed release named as SNWLID-2026-0008, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.28",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "Exploitation of this flaw requires an authenticated administrator session on the SMA1000 Appliance Management Console, so that credential is the entire access precondition — and what it opens is the control plane for remote access into the estate, an appliance whose administrator can rewrite how everyone else connects. That is exactly why the least-privilege control cited as insufficient on this entry passes its attestation while the flaw stays exploitable: the privilege being abused is one the account legitimately holds, so per-account scoping is never the thing that fails. Applied to this deployment, the control means SMA1000 AMC administrators are enumerated as a control-plane tier distinct from application administrators — reachable only through a privileged-access jump host, with per-session step-up on a phishing-resistant factor, just-in-time elevation under approval, and an identity used for nothing else — so that a credential phished, reused or coerced somewhere else does not carry into the console that can execute OS commands on the appliance host. Precondition, stated plainly: this bounds who can obtain an AMC session; it does not close the injection. Anyone who does reach an administrator session still gets arbitrary OS commands on the appliance, and it offers nothing against an administrator acting maliciously or against a session already established. It is a holding measure for the window before the SNWLID-2026-0008 release and its reboot, not a substitute for them.",
+        "evidence": "The packet's active_exploitation_notes state that exploitation requires an authenticated administrator session on the Appliance Management Console, and affected describes a remote authenticated administrator injecting and executing arbitrary OS commands. The NIST-800-53-AC-6 gap states least-privilege assumes admin accounts are trustworthy, but this flaw turns any compromised or coerced administrator credential into arbitrary OS command execution on the appliance host. active_exploitation is confirmed with cisa_kev true (kev_date 2026-07-14). patch_available true (fixed release SNWLID-2026-0008), patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2008-4128": {
     "name": "Cisco IOS Cross-Site Request Forgery Vulnerability",
@@ -45302,7 +45870,30 @@
         "adequate": false,
         "gap": "Oracle's quarterly CPU cadence plus enterprise change windows leaves ADF/WebLogic unpatched for months; the observed exploitation window is far shorter than the typical Fusion Middleware patch SLA."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Oracle ADF Faces is the case this control exists for, because the product's own release rhythm is the gap the entry records: the flaw-remediation gap on this entry names Oracle's quarterly critical-patch cadence plus enterprise change windows as leaving ADF and its WebLogic host unpatched for months, and the Essential Eight gap names patch timelines of up to a month, both against an unauthenticated network-reachable deserialization that the packet records as actively exploited. Bound to this product, the control means the KEV listing of 2024-09-18 opens the clock and the Fusion Middleware estate is driven to the fixed level on that clock rather than parked until the next quarterly window. The population is enumerable exactly — the packet names Oracle ADF 12.2.1.3.0 and 12.2.1.4.0 — but it is easy to under-count, because the vector notes ADF is downloaded via Oracle JDeveloper and most operators inventory the deployment as a WebLogic application rather than as ADF, so the enumeration has to be of every WebLogic domain serving an ADF or ADF Faces application, not of an ADF line item in a software register. Remediation and its precondition: the packet records patch_available true, live_patch_available false, and that the vendor update requires no reboot — no host reboot, which is not the same as the fix being live. The ADF Faces runtime is loaded into the running WebLogic managed server's JVM, so a domain whose libraries have been replaced but whose managed servers have not been restarted onto them is still serving the vulnerable deserialization path; completion is measured on what the running managed server is executing, and on an internet-facing production domain that restart is precisely the step a change window defers.",
+        "evidence": "CISA KEV added 2024-09-18; active_exploitation confirmed; active_exploitation_notes: 'Added to CISA KEV 2024-09-18 as an actively-exploited unauthenticated RCE in Oracle ADF Faces (Fusion Middleware / WebLogic-hosted)... internet-facing WebLogic estates are routinely swept for this by opportunistic and access-broker actors.' CVSS 9.8, RWEP 72, poc_available true. affected_versions: 12.2.1.3.0 and 12.2.1.4.0; the vector states 'Oracle Application Development Framework (ADF) is downloaded via Oracle JDeveloper Product' and that successful attack results in 'takeover of Oracle Application Development Framework (ADF)'. patch_available true, live_patch_available false, patch_required_reboot false, live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The NIST-800-53-SI-2 gap records the quarterly CPU cadence and change windows leaving ADF/WebLogic unpatched for months; the AU-Essential-8-Patch gap records maturity timelines of up to a month exceeding the active-exploitation window; the ISO-27001-2022-A.8.8 gap records that treating Fusion Middleware as a slow-moving app tier misses that this unauthenticated 9.8 deserialization RCE requires KEV-speed emergency patching.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry's NIS2 gap names the interim measure directly — deserialization-gadget filtering at the web tier while an internet-facing WebLogic estate waits on the patch — and the requirement here is that such filtering be recorded as its own verdict state, mitigation active with no binary patch, carrying a dated action item, and never rolled up as patched-per-SLA on the vulnerability register. That distinction is load-bearing for this specific flaw rather than a bookkeeping preference. The malicious request is an ordinary unauthenticated HTTP request to an ADF Faces resource-loader endpoint carrying a serialized Java object, which the packet identifies as a LambdaIdentity gadget, so the filter is matching a gadget shape inside traffic that is otherwise well-formed and expected — it is a signature on one known chain, not a repair of the deserialization sink. Preconditions, all of which the register entry has to carry alongside the mitigation: the filter only inspects request paths that traverse it, so a caller that reaches a managed server directly, an administrative or secondary listener, or any virtual host not fronted by the proxy is unfiltered and fully exploitable; a filter tuned to the named gadget does not cover a different chain into the same unauthenticated sink, which is why residual risk stays open until the fixed level is running; and because the packet records a public proof-of-concept and confirmed exploitation from the 2024-09-18 KEV listing, a filter deployed now bounds new attempts but removes nothing an earlier successful exploitation left behind, so a domain that was internet-facing and unpatched through the exposure window belongs on the incident path rather than being closed on the mitigation record.",
+        "evidence": "The NIS2-Art21-vulnerability-management gap on this entry: 'Baseline vuln-handling processes do not mandate the WAF deserialization-gadget filtering needed while patching a preauth Java deserialization flaw on internet-facing WebLogic.' attack_vector: 'An unauthenticated attacker sends a crafted HTTP request to an ADF Faces resource-loader endpoint carrying a serialized Java gadget (LambdaIdentity); the server deserializes it without validation, executing arbitrary commands and taking over the WebLogic-hosted application.' poc_available true; active_exploitation confirmed; CISA KEV 2024-09-18; CVSS 9.8. patch_available true with live_patch_available false, so no vendor live-patch stands between the mitigation state and the fixed build. The ISO-27001-2022-A.8.8 gap records that technical-vulnerability management treating Fusion Middleware as a slow-moving app tier misses the KEV-speed requirement.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2020-0618": {
     "name": "Microsoft SQL Server Reporting Services Remote Code Execution Vulnerability",
@@ -45339,7 +45930,40 @@
         "adequate": false,
         "gap": "SSRS is often a long-lived internal BI server outside the standard OS patch cadence; a 21-day KEV due date lags the observed exploitation of exposed instances."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The shape of this entry is unusual and it changes what the SLA clock is for: the vendor fix long predates the KEV listing, so an organization finding this in 2024 is not late on a patch cycle it was running — it is holding an SSRS instance the patch cycle never reached. The clock that matters therefore starts at the 2024-09-18 KEV listing, and the first action is enumeration, not deployment. Scope it from the affected versions the packet names: SQL Server 2012 SP4, 2014 SP2/SP3 and 2016 SP2 Reporting Services, every instance across all three families. An OS-patch report is not evidence about any of them — the entry's own flaw-remediation gap records that SSRS is often a long-lived internal BI server outside the standard OS patch cadence, which is precisely how an instance survives four years below the fixed build. Order the work by exposure rather than by CVSS band: the packet records exploitation against internet-exposed instances, and the sink needs only one low-privileged authenticated account, so an instance reachable from outside or from a broad user population is the first item and not an average one. Completion is measured on the Report Server build in service. patch_required_reboot is true and the packet records no live-patching primitive for this product, with the vendor update plus a reboot being the remediation, so an instance that has installed the update and not restarted is still running the vulnerable code and must be counted as exposed rather than as patched. And the SLA item does not close on the reboot alone where the instance was reachable during the exposure window — that instance is an incident item, since code execution here runs as the Report Server service account.",
+        "evidence": "Packet: Microsoft SQL Server Reporting Services mishandles page requests, deserializing attacker-controlled ViewState (CWE-502) from an authenticated user into remote code execution as the Report Server service account. affected_versions: SQL Server 2012 SP4 (SSRS), SQL Server 2014 SP2/SP3 (SSRS), SQL Server 2016 SP2 (SSRS). CISA KEV added 2024-09-18, active_exploitation confirmed, poc_available true; CVSS 8.8, RWEP 77. The packet records active exploitation against internet-exposed SSRS instances, with a low-privileged authenticated user posting a crafted __VIEWSTATE to a report page to run code as the Report Server service account. patch_available true, patch_required_reboot true, live_patch_available false, with live-patch notes recording no live-patching primitive for this product and the vendor update plus reboot as the remediation. The flaw-remediation gap records that SSRS is often a long-lived internal BI server outside the standard OS patch cadence and that the 21-day KEV due date lags observed exploitation of exposed instances; the Essential Eight gap records that application patch timelines lag near-immediate exploitation of exposed SSRS endpoints; the patch-management gap records that reporting-services patch SLAs treat BI middleware as low priority; the system-security gap records that patch governance rarely tracks SQL Server Reporting Services as an at-risk asset.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "__VIEWSTATE is the service-internal protocol field this control governs on SSRS: a serialized object graph the server hands the browser and accepts back, which the report-rendering path reconstructs through LosFormatter/ObjectStateFormatter and turns into code running as the Report Server service account. Unlike the unauthenticated-broker case the control was first written against, SSRS does authenticate its caller — the packet's path needs a low-privileged authenticated user — so authentication is not the boundary that fails, and an access-review attestation showing every SSRS user is a named account passes cleanly while the path stays fully open. Two requirements bite instead. First, the report endpoints answer only from segments with an operational need to render reports, rather than inheriting safety from the assumption that a BI server is internal — the packet's boundary-protection gap records exactly the opposite state, endpoints left reachable from internal or VPN networks where a single low-privileged account is enough to reach the sink. Second, what the endpoint is permitted to reconstruct from request-supplied serialized state is constrained rather than trusted. Preconditions, and the first one is where this control gets over-claimed: an SSRS instance exists to serve report consumers, so on an instance serving a general staff population there is no segment restriction that removes the path — restriction bounds who can present the payload, and every account inside the permitted segment still reaches the sink. It bounds exposure; it does not close it. The endpoint-side property is established by the vendor update, not by this control, which states what to verify. Distinguishing test for this product: from a segment with no reporting role on a staging instance, attempt to reach a report-rendering endpoint and confirm it is refused before any authentication exchange; then, holding a deliberately low-privileged account inside the permitted segment, post a crafted __VIEWSTATE and confirm it is rejected rather than deserialized.",
+        "evidence": "Packet: a low-privileged authenticated user POSTs a crafted __VIEWSTATE payload to an SSRS report-rendering page; SSRS deserializes it insecurely (LosFormatter/ObjectStateFormatter), executing attacker code as the Report Server service account. poc_available true, active_exploitation confirmed, CISA KEV added 2024-09-18; CVSS 8.8, RWEP 77. The boundary-protection gap on this entry records that boundary controls frequently leave SSRS report endpoints reachable from internal or VPN networks where a single low-privileged account is enough to reach the sink. patch_available true with patch_required_reboot true and live_patch_available false, the vendor update plus reboot being the remediation.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "SSRS is BI middleware rather than a perimeter appliance, but the packet puts it internet-exposed with confirmed exploitation and a public PoC, and the outcome is code execution as the Report Server service account — which is the condition this control exists for. For an instance whose report endpoints were reachable from untrusted networks while it ran below the fixed build, neither the update nor the reboot is remediation: the fix closes the deserialization path and removes nothing an attacker wrote through it, and it does not invalidate anything the attacker took. The default for that instance is rebuild plus rotation rather than update-in-place — reinstate the report server from a known-good baseline rather than from its live filesystem, and rotate the Report Server service account credential together with every credential that account could use, because the entire point of this sink is that the attacker's code ran holding it. Preconditions and limits: the trigger is the exposure window, not a matched indicator. poc_available is true, but the packet names no actor and no artifact set, so an estate waiting for an IoC before opening the case will not open it — reachability below the fixed build during the window is the criterion. A rebuild that restores the instance from a backup taken inside that window reinstates whatever was written through the path, so the restore point has to predate the exposure or be validated independently. And this control governs the response to an instance that was exposed; it neither detects the original intrusion nor substitutes for the update, which the packet records as the remediation and which still has to land with its reboot on the rebuilt instance.",
+        "evidence": "Packet: active_exploitation confirmed with poc_available true; the packet records exploitation against internet-exposed SQL Server Reporting Services instances, with a low-privileged authenticated user posting a crafted __VIEWSTATE to a report page to run code as the Report Server service account, and notes that ransomware use is unconfirmed by CISA but that the flaw is a common ransomware-adjacent foothold on exposed BI servers. CISA KEV added 2024-09-18; CVSS 8.8, RWEP 77. patch_available true, patch_required_reboot true, live_patch_available false, with live-patch notes recording no live-patching primitive for this product and the vendor update plus reboot as the remediation. The flaw-remediation gap records that the KEV due date lags the observed exploitation of exposed instances; the technical-vulnerability gap records that SSRS is rarely inventoried as internet-adjacent, so the deserialization sink goes untracked past the exploitation window.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-27348": {
     "name": "Apache HugeGraph-Server Improper Access Control Vulnerability",
@@ -45810,7 +46434,40 @@
         "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."
       }
-    }
+    },
+    "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"
+        ]
+      },
+      {
+        "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",
@@ -46226,7 +46883,28 @@
         "adequate": false,
         "gap": "WPS Office is user-installed productivity software often outside enterprise patch tooling, so the fix lags the one-click in-the-wild exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The obstacle to meeting a KEV clock on Kingsoft WPS Office is not the change window, it is the inventory: this entry's flaw-remediation gap records WPS Office as user-installed productivity software that often sits outside enterprise patch tooling, so the population that has to be driven to the fixed build is largely invisible to the software-distribution console that would normally produce the compliance evidence. Bound to this product, the control means the clock opens at the 2024-09-03 KEV listing and is met by enumerating Windows hosts carrying a WPS Office build inside the affected range from endpoint inventory of the installed binaries rather than from managed-package records, then driving each to 12.2.0.16412 or later — the packet's range runs from 12.2.0.13110 up to but excluding 12.2.0.16412. Where a per-user copy is not manageable, removing it is the remediation; recording it as present-and-pending leaves the one-click path live on that desktop. Priority follows the packet rather than the software's category: this is a productivity suite most vulnerability programmes queue behind server-side findings, yet the packet records a public proof-of-concept and weaponization as a single-click exploit by an espionage group delivering a backdoor, which makes it an initial-access item. Remediation shape and its precondition: patch_available is true, live_patch_available is false, and the packet states the vendor update requires no reboot — no host reboot, which does not mean the fix is live on the desktop. The vulnerable code is the promecefpluginhost.exe plugin host that WPS Office spawns, so an installation that has taken the update while a WPS session is still open continues to serve that path from the pre-fix install; completion is measured on the build the running installation reports after the application has been closed and relaunched.",
+        "evidence": "CISA KEV added 2024-09-03; active_exploitation confirmed; poc_available true; CVSS 9.3; RWEP 68. affected: 'Kingsoft WPS Office for Windows: promecefpluginhost.exe performs improper path validation, letting a crafted document load an arbitrary Windows library (DLL).' affected_versions: '12.2.0.13110 through 12.2.0.16412 (exclusive) on Windows'. active_exploitation_notes: 'Weaponized as a one-click exploit by the South-Korea-aligned APT-C-60 espionage group: a booby-trapped spreadsheet (uploaded to VirusTotal Feb 2024) triggers promecefpluginhost.exe to load an attacker-supplied DLL, deploying the SpyGlace backdoor.' patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The NIST-800-53-SI-2 gap records that 'WPS Office is user-installed productivity software often outside enterprise patch tooling, so the fix lags the one-click in-the-wild exploitation'; the NIS2-Art21-vulnerability-handling gap records that 'vulnerability handling for third-party office suites is under-scoped, delaying response to an actively weaponized single-click flaw'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Every recorded instance of this flaw starts with an attacker-supplied spreadsheet arriving at a user: the packet's attack path is a victim opening, or single-clicking a link inside, a malicious WPS spreadsheet, and the weaponized sample is described as a deceptive spreadsheet document. On any desktop still inside the affected build range the delivery path is therefore the only lever the operator holds, and this control's requirement bound to that path is that externally-sourced office documents are marked with their untrusted origin by the boundary that receives them — mail gateway, web download, untrusted file share — that the marking survives whatever container the document is delivered in, so extraction from an archive, mounting from an image, or a rename does not strip it, and that a document whose origin cannot be established as trusted is quarantined or blocked rather than delivered to the desktop. This is the complement of the malware-protection gap on this entry rather than a restatement of it: the loader is a legitimately signed WPS binary and the payload is an attacker-supplied DLL, so detection on the payload is what fails, and handling the delivery vehicle by verified provenance is what does not depend on recognising the payload. Precondition, and it is a real limitation here rather than a formality: the sandboxing half of this control depends on the document handler consulting the provenance marking, and the packet establishes nothing about whether WPS Office honours a Windows origin marking. Where it does not, the enforceable half is entirely what the gateway and file-share boundary do with the file before the user receives it — once the spreadsheet is open in an unpatched WPS Office, the marking does not stop promecefpluginhost.exe from resolving the attacker-supplied plugin path. It also gives nothing against a document delivered through a channel that applies no marking, or one already sitting on the endpoint from before the policy. This is a holding measure for the window before the fixed build lands, not a closure. The distinguishing test keys on the real delivery behaviour: send an externally-sourced spreadsheet through each ingress path, including one nested inside an archive, and confirm it arrives marked or quarantined rather than clean — an attestation covering macro and OLE settings passes while a booby-trapped spreadsheet reaches the user with its origin stripped.",
+        "evidence": "attack_vector: 'A victim opens (or single-clicks a link inside) a malicious WPS spreadsheet that invokes the custom ksoqing protocol; promecefpluginhost.exe fails to validate the supplied plugin path and loads an attacker-controlled DLL, executing the SpyGlace backdoor.' The vector records that 'the vulnerability was found weaponized as a single-click exploit in the form of a deceptive spreadsheet document', and active_exploitation_notes records a booby-trapped spreadsheet uploaded to VirusTotal in Feb 2024. The ISO-27001-2022-A.8.7 gap: 'Malware-protection controls miss document-borne library-load abuse because the loader is a signed WPS binary.' patch_available true with live_patch_available false, so the interim window runs until the fixed build (12.2.0.16412 or later per affected_versions) is running. active_exploitation confirmed; poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.7"
+        ]
+      }
+    ]
   },
   "CVE-2021-20124": {
     "name": "Draytek VigorConnect Path Traversal Vulnerability (CVE-2021-20124)",
@@ -46263,7 +46941,40 @@
         "adequate": false,
         "gap": "Boundary protection is the real mitigation here — the file-read is only exploitable when the WebServlet is internet-reachable, yet SC-7 controls frequently leave device-management portals exposed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet carries both halves of this control's premise for DrayTek VigorConnect. A vendor update is recorded as available, and at the same time the flaw-remediation gap calls VigorConnect end-of-support-era management software where remediation fails when no vendor patch is applied and operators must instead discontinue or firewall the product, while the Essential Eight gap states that for legacy VigorConnect the only compliant action is removal. So on an install that can still take an update, reaching an updated build is an interim state; the terminal state is removing or replacing the management platform, because a host left on an unsupported management product is exposed not only to this unauthenticated root-level file read but to everything found in that product since its last build. Scope the inventory to what the packet names — VigorConnect installs, with the affected version recorded as 1.6.0-B3 — and not to the network devices VigorConnect administers, which the packet does not tie to this defect; sweeping the managed devices manufactures replacement work against equipment no evidence implicates. Per install, record the running VigorConnect version, whether an update carrying the fix is obtainable for it, and a dated removal or replacement date where it is not: a risk acceptance with no removal date leaves a KEV-listed flaw with a public PoC and confirmed exploitation in service indefinitely. Precondition on the interim half: patch_required_reboot is false, which means no host reboot — not that the fix is live the moment the update is laid down. The VigorConnect service keeps executing the code it started with, so completion has to be measured on the version the running WebServlet reports rather than on the installer having run.",
+        "evidence": "Packet records patch_available true, patch_required_reboot false, live_patch_available false with live_patch_notes 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation'; affected_versions is 1.6.0-B3. The NIST-800-53-SI-2 gap states VigorConnect is end-of-support-era management software and that flaw remediation fails when no vendor patch is applied, with operators required to discontinue or firewall the product; the AU-Essential-8-Patch gap states Essential Eight patching assumes a supported product with available updates and that for legacy VigorConnect the only compliant action is removal, which the control does not force. The ISO-27001-2022-A.8.8 gap states technical vulnerability management often omits network-appliance companion software like VigorConnect from the asset register, so the traversal flaw goes untracked. cisa_kev true (2024-09-03), active_exploitation confirmed, poc_available true, rwep_score 63, cvss 7.5.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "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": "VigorConnect is the device-management platform this control governs, and the defect sits on its WebServlet file-download endpoint: the endpoint performs no path validation, so an unauthenticated caller reads arbitrary files from the underlying operating system with root privileges. Bound to this product the control means the download endpoint authorizes its caller before any file is opened, and resolves the requested path to canonical absolute form and verifies the result is still under the directory it is meant to serve before the handle is opened — containment must be enforced on the read direction here, because the privileged operation is a root-level read rather than a write, and filtering the request string is not the same as checking the resolved path. It also means no VigorConnect instance is left with the WebServlet reachable from a segment with no operational need for the management console. The packet's own attack vector has the caller unauthenticated, which is why the endpoint's own authorization decision rather than the surrounding account model is the only thing between an untrusted network and the root read: an identity-and-access attestation recording that every VigorConnect administrator authenticates at login passes cleanly while this path stays fully open. Distinguishing test: from a segment with no management role, send a directory-traversal request to the WebServlet download endpoint on a staging install and confirm it is refused before any file is read — 'the management server is internal' is a statement about topology, not a demonstration that the endpoint is unreachable from untrusted networks. Precondition: the endpoint-side authorization and path validation are properties the vendor update establishes; this control states what to verify, it does not implement it. Until the update is in service, restricting which segments can reach the WebServlet bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, and it is unavailable where the console must stay reachable for remote administration.",
+        "evidence": "Packet affected: the VigorConnect WebServlet file-download endpoint performs no path validation, letting an unauthenticated attacker read arbitrary OS files with root privileges; attack_vector: an unauthenticated attacker sends a directory-traversal request to the WebServlet download endpoint and retrieves arbitrary files from the host with root privileges. The NIST-800-53-SC-7 gap states the file-read is only exploitable when the WebServlet is internet-reachable, yet SC-7 controls frequently leave device-management portals exposed; the NIS2-Art21-network-security gap states network-security measures rarely segment out-of-band management consoles, leaving the unauthenticated root-level file read reachable from untrusted networks; the UK-CAF-B2 gap states identity-and-access outcomes assume the management console authenticates callers, but this endpoint reads arbitrary files as root without auth. active_exploitation_notes: GreyNoise and Tenable reported active exploitation of internet-exposed VigorConnect management servers, with dozens of source IPs observed reading arbitrary files as root (CISA KEV 2024-09-03).",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "VigorConnect is the management plane for the devices it administers, and this flaw hands an unauthenticated caller a root-level read of everything the host holds — which the packet's identity-and-access gap describes as handing the attacker the credentials and configuration that seed follow-on access. An update does not un-disclose them, which is why a remediation record that ends at the fixed build closes this entry while the attacker still holds working credentials. For this product the playbook means treating any install whose WebServlet was reachable from an untrusted network during the exploitation period the packet records as having had its files read: rotate the VigorConnect host's own administrative credentials, rotate every device credential and secret the platform stored, re-issue rather than reuse key material recovered from those files, and review the configuration of the devices the platform manages for changes made with those credentials since the exposure window opened. Precondition and limit, which matter more than usual here: this CVE's primitive is a read, so exploitation of it writes nothing to the host and leaves no attacker-installed artifact to serve as the trigger — whether an install was reached has to be determined from whether the WebServlet was reachable during the window, not from host-side indicators. And the playbook reduces nothing about the exploit surface itself; it bounds what an attacker can do with material already taken, and it presumes the credentials the platform stored can be enumerated and rotated at all.",
+        "evidence": "Packet UK-CAF-B2 gap: identity-and-access outcomes assume the management console authenticates callers, but this WebServlet endpoint reads arbitrary files as root without auth, 'handing an attacker the credentials and config that seed follow-on access'. active_exploitation confirmed, with active_exploitation_notes recording GreyNoise and Tenable reporting active exploitation of internet-exposed VigorConnect management servers and dozens of source IPs observed reading arbitrary files as root; CISA KEV 2024-09-03; poc_available true; ransomware use not confirmed. The vector is a file-download/local-file-inclusion primitive (download arbitrary files with root privileges), not code execution.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2021-20123": {
     "name": "DrayTek VigorConnect Path Traversal Vulnerability (CVE-2021-20123)",
@@ -46300,7 +47011,31 @@
         "adequate": false,
         "gap": "SC-7 boundary protection does not by itself force a device-management portal off the public Internet, which is the decisive exposure here."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "VigorConnect is the device-management platform the packet names and the defect sits directly on its API surface: the DownloadFileServlet endpoint performs a file download with root privileges, with no path sanitization, for a caller that never authenticates. Bound to this product, the control means that endpoint authorizes its caller before any file is opened, and resolves the requested path to a canonical absolute form and verifies the result is still under the intended download root — rejecting absolute paths, ../ sequences and symlinks that leave the root — with the check performed before the file handle is opened rather than by filtering the request string; and that no VigorConnect instance is left with its web interface reachable from the public internet or from any segment with no operational need to manage DrayTek devices. Note the direction, because it is where this differs from the upload-side case the control is usually written against: the primitive here is read, so containment has to be enforced on the download path, and because the servlet runs as root an unbounded read returns every file on the host — on a network-management server that is where its configuration and credential material lives, which is what the packet records the campaign taking. This is also why the flaw is reachable with no account at all: the attacker never holds a VigorConnect operator identity, so per-account privilege scoping is never consulted and an access-control attestation passes cleanly while the path stays open. Distinguishing test: from an external address and from a general user VLAN, send DownloadFileServlet an unauthenticated request whose path resolves outside the intended download root against a staging instance, and confirm it is refused before anything is read. Precondition: the endpoint-side authorization and path canonicalization are properties the vendor update establishes — this control states what to verify, it does not implement it. Until that update is running, restricting which networks can reach the VigorConnect web interface bounds who can send the request but leaves the endpoint fully exploitable to anything inside a permitted segment, and that lever is unavailable wherever the portal must stay reachable for remote device management.",
+        "evidence": "`affected` records DrayTek VigorConnect network management software with the DownloadFileServlet endpoint performing unauthenticated file download with root privileges and no path sanitization; affected_versions gives VigorConnect 1.6.0-B3 and earlier. attack_vector records an unauthenticated attacker sending a crafted request with directory-traversal sequences, causing VigorConnect to return arbitrary files from the OS with root privileges. active_exploitation_notes record a global campaign against DrayTek devices in which unauthenticated attackers abuse this path traversal to read arbitrary files such as credentials as root from internet-exposed VigorConnect management servers. The NIST-800-53-SC-7 gap states boundary protection is insufficient when the management interface is deliberately internet-exposed; the NIS2-Art21-network-security gap that network-security measures do not mandate isolating device-management portals from untrusted networks; the UK-CAF-B4 gap that the system-security principle does not require keeping the VigorConnect management portal off untrusted networks; the AU-ISM-1546 gap that internet-facing service hardening guidance is not enforced strongly enough to keep an unauthenticated file-read endpoint off the public edge. CISA KEV 2024-09-03, active_exploitation confirmed, poc_available true, CVSS 7.5, RWEP 64.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4",
+          "AU-ISM-1546"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For VigorConnect the fix was never the missing part: the packet's flaw-remediation gap records that a patch to v1.6.1 exists against affected builds of 1.6.0-B3 and earlier, and that the observed campaign exploited long-unpatched internet-facing appliances anyway. Under this control the clock therefore runs from the 2024-09-03 KEV listing — the later of the two events — and each VigorConnect install is driven to the fixed release on that clock rather than through the routine vulnerability-management cadence the packet's technical-vulnerability-management gap describes, which never prioritized a management-software file-read in the first place. patch_required_reboot is false, which removes the host-reboot argument for deferral, but that is not the same as the fix being live: the running VigorConnect service has to be executing the fixed build, so completion is measured on the version that service reports after the upgrade, not on the installer having run. There is no live-patch path, so nothing protects the endpoint during the interval — the only interim lever is restricting which networks can reach the portal at all. Precondition and limit, and this is the one operators miss on a read-primitive flaw: the update closes the traversal, it does not un-read anything. The packet records unauthenticated attackers reading arbitrary files as root, credentials included, from internet-exposed VigorConnect servers, so on any instance that was reachable during the exposure window every credential, key and configuration secret readable on that host must be treated as disclosed and rotated. An appliance upgraded to the fixed release with those credentials left in place reads as remediated on the patch record while the attacker still holds what the read returned.",
+        "evidence": "The packet's NIST-800-53-SI-2 gap states a patch to v1.6.1 exists but the observed campaign exploited long-unpatched internet-facing appliances, and that SI-2 SLAs far exceed the exploitation window for a trivially weaponizable traversal; the ISO-27001-2022-A.8.8 gap states technical vulnerability management did not prioritize a management-software LFI. patch_available is true, 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, requiring no reboot, is the remediation. affected_versions gives VigorConnect 1.6.0-B3 and earlier. CISA KEV added 2024-09-03; active_exploitation confirmed; active_exploitation_notes record unauthenticated attackers reading arbitrary files such as credentials as root from internet-exposed VigorConnect management servers, with ransomware use not confirmed; poc_available true; CVSS 7.5; RWEP 64.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-7965": {
     "name": "Google Chromium V8 Inappropriate Implementation Vulnerability",
@@ -46588,7 +47323,32 @@
         "adequate": false,
         "gap": "Perimeter controls do not block the attack because Exchange OWA/ECP must be internet-reachable for mail flow, so the vulnerable endpoints stay exposed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this Exchange flaw the two events this control chooses between are far apart: the vendor fix shipped in the July 2021 security updates (KB5004778 for Exchange Server 2013, KB5004779 for 2016, KB5004780 for 2019) and CISA listed it on 2024-08-21, so the clock is the KEV listing, the later of the two. Bound to this product that means every on-premises Exchange server carrying OWA/ECP is driven to a build at or above the July 2021 update on the KEV clock, not folded into the cumulative-update cadence and change-freeze windows the packet's flaw-remediation gap names as the reason servers stayed exposed. Completion has to be measured on the running build: live_patch_available is false and the packet records the vendor update requiring a reboot, so a server that has staged or installed the update but not rebooted still executes the vulnerable code and counts as exposed — and on a production mail server the reboot is precisely the step deferred out of the change window, so a deferral recorded as 'patched' is the specific way this remediation goes wrong. Preconditions and limits. There is no segmentation step that buys time: the packet's boundary-protection gap records that OWA/ECP must be internet-reachable for mail flow, so until the fixed build is running the vulnerable endpoint is reachable and the mitigation state is binary. And the SLA closes the flaw, not the incident — exploitation is confirmed and the packet records operators dropping ASPX web shells into Exchange virtual directories, which a cumulative update does not remove, so a server that was reachable and unpatched during the exposure window belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "The packet gives patch_available true, patch_required_reboot true, live_patch_available false, and 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 lists Exchange Server 2013 (pre-KB5004778), 2016 (pre-KB5004779) and 2019 (pre-KB5004780), with `affected` describing on-premises Exchange prior to the July 2021 security updates. CISA KEV added 2024-08-21, active_exploitation confirmed, RWEP 77, CVSS 7.2, poc_available true, CWE-502. active_exploitation_notes record operators running code on internet-facing Exchange and dropping web shells, with ransomware association unconfirmed. The NIST-800-53-SI-2 gap names Exchange cumulative-update cadence and change-freeze windows as keeping servers exposed past the observed exploitation window; the NIST-800-53-SC-7 gap records that OWA/ECP must be internet-reachable for mail flow.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "This Exchange flaw is post-authentication, and that is exactly the property that makes authentication-event logging blind to it: the attacker arrives holding valid Exchange credentials, so the logon preceding the exploit is a successful and unremarkable one, and the identity controls the estate is audited against have already been satisfied before the request that matters is sent. Ask what an exploit doing what this packet describes actually emits and it is a request pattern, not an authentication anomaly — a request from an already-authenticated session to an internet-facing OWA/ECP back-end endpoint, followed by requests to a .aspx path under an Exchange virtual directory that did not exist before it, since the packet records persistence via an ASPX web shell placed there. Only per-request access logs carry either half, so IIS/OWA per-request access logs — not just authentication events — must be forwarded off the Exchange server to an external SIEM, with retention long enough to cover the exposure window this entry implies: the fix shipped with the July 2021 updates and the KEV listing came on 2024-08-21, so a retention period that ages out that span turns 'was this server used' into an unanswerable question, and 90 days is a floor rather than a comfortable margin. The second reason the destination must be external is the same one that makes this control the complement of the unavoidable exposure: an attacker who reached code execution on the server can reach logs stored on it. Preconditions. This detects, it does not prevent — it does not stop the deserialization from executing and it does not remove a web shell already written; it bounds the window to alert-and-response time. And it only works if the forwarding was in place before the request arrived, which on an on-premises Exchange server whose logging was scoped to logon events is precisely the assumption that fails.",
+        "evidence": "The packet's NIST-800-53-IA-2 gap states the flaw is post-authentication, so identification and authentication controls are already satisfied by the attacker and MFA on OWA does not stop a valid-account or credential-replay path into the RCE. The NIST-800-53-SC-7 gap states perimeter controls do not block the attack because Exchange OWA/ECP must be internet-reachable for mail flow, so the vulnerable endpoints stay exposed. attack_vector records an attacker with valid Exchange authentication reaching an internet-facing OWA/ECP back-end endpoint, triggering server-side code execution, then persisting via an ASPX web shell in an Exchange virtual directory; active_exploitation_notes record web-shell drops on internet-facing Exchange. CISA KEV 2024-08-21 against a fix shipped in the July 2021 security updates; active_exploitation confirmed; poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "NIST-800-53-SC-7"
+        ]
+      }
+    ]
   },
   "CVE-2022-0185": {
     "name": "Linux Kernel Heap-Based Buffer Overflow Vulnerability",
@@ -46815,7 +47575,40 @@
         "adequate": false,
         "gap": "Public PoCs landed within hours of disclosure; any remediation SLA slower than same-day left internet-facing controllers readable long before patch windows closed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For the Jenkins controller this means a build above the affected range is driven onto every controller on the clock that opened with the 2024-08-19 KEV listing rather than into the next platform-maintenance window. Two release tracks move independently and both are in the affected range — Jenkins 2.441 and earlier on the weekly line, LTS 2.426.2 and earlier — so an estate that upgrades its weekly-line controllers while an LTS controller stays on 2.426.2 has not finished, and the count has to be taken per controller against its own track. The packet records no live-patch path and no host reboot, but a reboot is not the restart that matters here: the controller is a long-running service, so a new war staged on disk is not remediation until the controller is running it, and completion must be measured on the version the running instance reports. Priority follows the packet rather than the maintenance calendar — a public proof of concept, near-1.0 EPSS with mass scanning of internet-exposed controllers, and a Known ransomware association on the KEV entry.",
+        "evidence": "The packet records cisa_kev true with kev_date 2024-08-19, active_exploitation confirmed, poc_available true, rwep_score 74 against CVSS 9.8, patch_available true, live_patch_available false, and live_patch_notes stating there is no live-patching primitive for this product and that the vendor update (no reboot required) is the remediation. affected_versions gives Jenkins 2.441 and earlier and Jenkins LTS 2.426.2 and earlier. The active-exploitation note records a Known ransomware association and near-1.0 EPSS with mass scanning of internet-exposed Jenkins controllers; the flaw-remediation gap states public PoCs landed within hours of disclosure, so any SLA slower than same-day left controllers readable before patch windows closed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The vulnerable code here is the Jenkins controller's own CLI command parser — the args4j feature that expands an argument beginning with '@' into the contents of the named file, left enabled — and it answers before the caller authenticates, which is exactly the protocol-endpoint class this control governs. Applied to Jenkins it means the controller's CLI accepts connections only from the hosts that legitimately drive it (build agents, operator jump hosts, the CI automation that invokes it), enforced by network ACL or host firewall rather than inferred from the controller sitting on an internal network, and that a KEV-listed defect in that parser moves on an accelerated clock with the controller restarted onto the fixed build rather than folded into the next platform window. Distinguishing test for this product: from a general user or workstation segment against a staging controller, issue an unauthenticated CLI command whose argument is '@' followed by a path on the controller filesystem, and confirm the connection is refused before the parser sees it — 'the controller is internal' is an assertion about topology, not a demonstration that the CLI is unreachable from untrusted segments. Precondition: restricting reachability bounds who can send the command, it does not repair the parser. Every host inside the permitted segment still reaches it with no credential, and on a controller that exists to serve a broad engineering population there is no segment that removes the path — only one that narrows it until the upgrade lands.",
+        "evidence": "The packet's vector places the defect in the CLI command parser: Jenkins does not disable the feature that replaces an '@' character followed by a file path in an argument with that file's contents, allowing unauthenticated attackers to read arbitrary files on the Jenkins controller file system. The affected summary names the args4j expandAtFiles feature as the unfixed behaviour. The cited boundary-protection gap states that boundary protection still exposing the Jenkins CLI/HTTP endpoint to untrusted networks leaves the unauthenticated file read directly reachable, and the flaw-remediation gap records public PoCs landing within hours of disclosure.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This CVE's primitive is disclosure, so the upgrade closes the read and removes nothing that was already read. The packet has the attacker recovering secrets from the controller filesystem — it names the Jenkins master key — and chaining them into remote code execution, and it records that a caller without Overall/Read still obtains the first lines of any file, so an unauthenticated scanner reaching an exposed controller gets at least partial content of every credential-bearing file on it. For a Jenkins controller that was reachable by untrusted callers during the exposure window, the requirement is therefore to treat the instance as compromised rather than patched: capture the configuration and the job and plugin state for review, rebuild the controller from a known-good baseline instead of upgrading in place, and rotate everything the controller held — the master key and the credentials store it protects, agent and SSH keys, API tokens, and any signing or registry credential the pipelines used. Preconditions: rotation only helps for material the operator can enumerate and revoke, so a credential the controller held that is also in use elsewhere stays valid until it is rotated at every consumer, and a controller rebuilt onto the fixed build with the old key material restored is back where it started. Scope this to controllers that were actually reachable during the window — the packet's exploitation evidence is mass scanning of internet-exposed controllers, not a claim that every install was reached.",
+        "evidence": "The packet's affected summary states the flaw lets an attacker read arbitrary files — full contents with Overall/Read, first lines without — and chain leaked secrets into remote code execution. The attack_vector names the Jenkins master key as the disclosed secret then used to achieve remote code execution. active_exploitation is confirmed, with mass scanning of internet-exposed Jenkins controllers and a Known ransomware association at the 2024-08-19 KEV listing. The cited DORA gap states that ICT protection for a financial-sector build pipeline is undermined when signing keys and credentials can be exfiltrated through an unauthenticated CLI read, and the Essential Eight gap records the controllers and the build secrets they hold as readable well before any patch window closed.",
+        "gap_closes": [
+          "DORA-Art-9",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2024-28986": {
     "name": "SolarWinds Web Help Desk Deserialization of Untrusted Data Vulnerability (CVE-2024-28986)",
@@ -46852,7 +47645,30 @@
         "adequate": false,
         "gap": "Flaw remediation via WHD 12.8.3 Hotfix 1 is correct, but the 3-week KEV due window is slow against a CVSS 9.8 deserialization RCE already being exploited on internet-facing help-desk servers."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For Web Help Desk the packet sets the clock and the frameworks cited on this entry both miss it: CISA listed the CVE on 2024-08-15 on evidence of active exploitation against internet-facing instances, the flaw-remediation gap records a three-week KEV due window as slow against a CVSS 9.8 deserialization RCE already being exploited, and the Essential Eight gap records the 48-hour internet-facing target as trailing exploitation of an already-reachable server. Applied to this product, the requirement is that every Web Help Desk instance in the 12.4 through 12.8 range is driven to 12.8.3 Hotfix 1 on the KEV clock rather than on the ITSM's own change cadence, and that the internet-reachable instances are enumerated first, because reachability is what turned this from a patch item into an exploited one. Completion is measured by the version the running WHD service reports: the packet records no host reboot for this fix, but the defect is in the Java application, so a server where the hotfix has been applied while the old WHD/Tomcat service process is still serving requests is still executing the vulnerable code and is not remediated. Preconditions and limits: the packet registers no live-patch primitive, so there is no vendor mechanism that holds the gap while the hotfix is scheduled — until it lands and the service is running the fixed build, the only operator-side lever is reachability, covered by the boundary control on this entry. And a KEV-clock patch is not evidence of cleanliness: exploitation is confirmed in the wild, so an internet-reachable instance that was exposed before the hotfix needs forensic triage and rotation of the credentials that ITSM holds, which applying 12.8.3 Hotfix 1 does nothing to undo.",
+        "evidence": "cisa_kev true with kev_date 2024-08-15; active_exploitation confirmed, with active_exploitation_notes stating it is exploited in the wild against internet-facing Web Help Desk. cvss 9.8, poc_available true. affected_versions: 'Web Help Desk 12.4 through 12.8 (fixed in 12.8.3 Hotfix 1)'. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes stating 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' The NIST-800-53-SI-2 gap states flaw remediation via WHD 12.8.3 Hotfix 1 is correct but the 3-week KEV due window is slow against a CVSS 9.8 deserialization RCE already being exploited on internet-facing help-desk servers; the AU-Essential-8-Patch gap states the 48-hour internet-facing target trails exploitation of an already-reachable WHD deserialization RCE; the NIS2-Art21-vulnerability-handling gap states vulnerability-handling obligations do not compel rapid mitigation of a single-exploit-away RCE on an ITSM asset that holds broad credentials. The UK-CAF-B2 gap records that a Web Help Desk RCE hands an attacker the privileged service and integrated-AD credentials the ITSM stores.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "For Web Help Desk the control means treating the request path that accepts serialized Java objects as a trust boundary rather than an internal convenience. The packet's attack vector is a crafted serialized Java object whose gadget chain runs arbitrary OS commands as the WHD service account, so the governing question is what arriving content the application is permitted to reconstruct — not whether the caller looks legitimate. SolarWinds could only reproduce the flaw authenticated, which is precisely why an authentication check sitting in front of the sink is not the thing that stops the gadget chain: a caller who does authenticate reaches it anyway. Bound to this deployment the requirement is that deserialization is constrained to the object types WHD legitimately exchanges instead of accepting arbitrary object graphs, and that the WHD listener answers only from the segment its help-desk users actually come from rather than being internet-reachable, which the packet's boundary-protection gap records as the state of the exploited instances. That gap also notes a WAF without deserialization-aware rules will not stop the gadget chain, so 'there is a WAF in front of it' is an assertion about topology, not a demonstration that the sink is unreachable. This is the same point the technical-vulnerability-management gap makes about the class rather than the instance: closing the ticket at 12.8.3 Hotfix 1 removes this sink and the packet records that later WHD deserialization CVEs followed, so the requirement has to be a property of the next release too. Distinguishing test: from an unauthenticated host that can route to a staging WHD, and again from an authenticated low-privilege session, submit a serialized object carrying a type WHD never legitimately receives and confirm it is refused before deserialization runs — an instance that passes a patch-level audit while reconstructing arbitrary object graphs from request content still exposes the path the moment the next parsing defect lands. Precondition: type constraint inside the application is a property of the vendor's fixed release — this control states what to verify and what to require of subsequent releases, it does not implement it. The reachability half is what the operator holds in the interim, and it bounds who can send the object without repairing the sink, so any caller inside the permitted segment still reaches it; it is also unavailable where the help desk must stay reachable to remote or external users.",
+        "evidence": "affected: 'SolarWinds Web Help Desk (WHD) Java application; the deserialization sink allows OS command execution on the host running the WHD/Tomcat service.' attack_vector: 'An attacker sends a crafted serialized Java object to Web Help Desk; unsafe deserialization instantiates a gadget chain that runs arbitrary OS commands as the WHD service account.' vector: 'While it was reported as an unauthenticated vulnerability, SolarWinds has been unable to reproduce it without authentication after thorough testing.' cwe_refs lists CWE-502. The NIST-800-53-SC-7 gap states boundary protection assumes WHD is not directly exposed, yet exploited instances are internet-reachable, and a WAF without deserialization-aware rules will not stop the gadget chain; the ISO-27001-2022-A.8.8 gap states technical vulnerability management does not enforce removing untrusted Java deserialization sinks, so the class of bug recurs (later WHD deserialization CVEs followed). patch_available true with affected_versions 'Web Help Desk 12.4 through 12.8 (fixed in 12.8.3 Hotfix 1)', live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-38107": {
     "name": "Microsoft Windows Power Dependency Coordinator Privilege Escalation Vulnerability",
@@ -47262,7 +48078,31 @@
         "adequate": false,
         "gap": "Traversal in the controller lets requests reach endpoints the access model intended to protect, bypassing the authorization mapping the control relies on."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "Apache OFBiz is an ERP/e-commerce application whose request controller maps an incoming URI onto a screen or controller entry, and this CVE is that mapping being escaped: the packet has an unauthenticated attacker embedding path-traversal sequences in the controller URI to leave the intended request-to-view mapping and reach restricted endpoints, which is then chained to code execution. Bound to this product, the control means each restricted OFBiz endpoint authorizes its own caller rather than inheriting a verdict from the front controller's URI mapping, so a request that arrives by an unintended path is still refused at the endpoint; and the back-office and administrative side of the deployment is segmented from untrusted callers separately from the storefront, so such a request cannot be presented at all. The access-enforcement gap cited on this entry is exactly this shape and explains why an identity-side attestation misses it: the attacker never authenticates as any OFBiz user, so per-account authorization is never consulted and a review of OFBiz roles and permissions passes cleanly while the path stays open. Distinguishing test on a staging instance: from a network position with no back-office role, issue unauthenticated requests carrying traversal sequences at each restricted controller endpoint and confirm each is refused before the endpoint runs — verifying the deployed third-party build behaves this way, rather than inferring it from the upstream project's development practices, is the point, since the packet's secure-coding gap is precisely that such assurance rarely reaches a deployed third-party ERP. Precondition: the path canonicalisation that repairs the controller mapping is what the vendor fix at 18.12.13 establishes — this control states the property to verify, it does not implement it. Until the fixed build is the one running, endpoint-side authorization and segmentation bound who can present the request but do not close the traversal, and the segmentation half is unavailable on a public-facing storefront deployment that must answer untrusted callers by design.",
+        "evidence": "Packet: affected \"Apache OFBiz (open-source ERP/e-commerce) web application — a path-traversal flaw in the request controller lets an unauthenticated attacker reach restricted endpoints, enabling remote code execution.\" attack_vector: \"An unauthenticated attacker embeds path-traversal sequences in the OFBiz controller URI to escape the intended request-to-view mapping and reach restricted screen/controller endpoints, which is then chained to code execution.\" cwe_refs CWE-22, cvss 9.8, rwep_score 67, cisa_kev true, kev_date 2024-08-07, active_exploitation confirmed, poc_available true. affected_versions: \"Apache OFBiz before 18.12.13\", \"Fixed in 18.12.13\". NIST-800-53-AC-3 gap: \"Traversal in the controller lets requests reach endpoints the access model intended to protect, bypassing the authorization mapping the control relies on.\" UK-CAF-B4 gap: \"System-security controls do not inherently canonicalize/validate request paths in the application controller, which is where the fix lives.\" ISO-27001-2022-A.8.28 gap: \"Secure-development controls should catch path canonicalisation in the OFBiz controller where the traversal lives, but A.8.28 secure-coding assurance rarely extends to a deployed third-party ERP whose request-routing flaw becomes preauth RCE.\"",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.28"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the clock runs from the 2024-08-07 KEV listing, and the packet's own numbers say why a routine patch cadence is the wrong instrument against it: EPSS around 0.994 at the 99.9th percentile, a public proof-of-concept, confirmed exploitation, and weaponization inside the same window as the related OFBiz RCE chain, against an unauthenticated pre-auth path traversal that reaches code execution. Remediation for this product is the upgrade to Apache OFBiz 18.12.13. Read the reboot field carefully here, because it is about the host and not the service: patch_required_reboot is false, so no machine reboot has to be scheduled, but OFBiz runs as a long-lived application service and an instance with the 18.12.13 artifact deployed while the running service is still executing the pre-fix build is not remediated. Measure completion on the version the running OFBiz process reports, not on what the deployment record or the artifact on disk says, and never record this one as having no restart to coordinate. Precondition on the interim state, before the upgrade is running: the only lever is reachability — restricting which networks can reach the OFBiz web tier — and it holds only for internal ERP and back-office deployments. A public e-commerce storefront must answer untrusted callers to function, so for that deployment shape there is no interim compensating state at all and the upgrade is the whole of the remediation; recording network restriction as the mitigation on a storefront leaves the pre-auth traversal fully reachable.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-08-07, active_exploitation confirmed, poc_available true, cvss 9.8, rwep_score 67. active_exploitation_notes: \"Actively exploited (EPSS ~0.994, 99.9th percentile) and KEV-listed; the path-traversal flaw in the OFBiz controller is used to reach restricted endpoints and achieve remote code execution. Ransomware use not confirmed.\" affected_versions: \"Apache OFBiz before 18.12.13\", \"Fixed in 18.12.13\". patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes \"No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.\" NIST-800-53-SI-2 gap: \"The flaw was weaponized within the same window as the related OFBiz RCE chain; standard patch SLAs did not keep pace with the observed exploitation.\" AU-Essential-8-Patch gap: \"Even a 48-hour internet-facing patch target trails a flaw exploited alongside a public OFBiz RCE chain.\" NIS2-Art21-vulnerability-management gap: \"Essential entities running OFBiz commerce/ERP need emergency handling for a KEV-listed preauth traversal-to-RCE, exceeding routine vulnerability-management cadence.\"",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-36971": {
     "name": "Android Kernel Remote Code Execution Vulnerability",
@@ -47368,7 +48208,30 @@
         "adequate": false,
         "gap": "The flaw was patched in 2018 but reached KEV in 2024, meaning long-lived unpatched Windows hosts remained exploitable for years — flaw-remediation programs that leave legacy Windows 7/Server 2008/2012 systems unpatched miss this LPE-to-RCE primitive."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet gives both halves this control exists to resolve. patch_available is true — Microsoft shipped a fix for this COM deserialization flaw in 2018 — and two of this entry's own framework gaps record that legacy Windows versions cannot receive current updates and that nothing forces retirement of end-of-support Windows 7, Server 2008 and 2012 builds. So the requirement resolves per unit rather than per CVE. A host on a Windows build still receiving updates takes the fix and this CVE is closed on it. A host on an out-of-support build reaches the fixed state for CVE-2018-0824 and remains exposed to everything found in Windows since its last update, so on that unit the patched build is an interim state and the terminal state is removal or replacement on a dated schedule — a requirement that ends at \"every host reports the fixed build\" marks an abandoned Windows estate compliant while it stays exposed. Scope to the builds the packet names: Windows 7, 8.1, RT 8.1, 10, and Windows Server 2008, 2008 R2, 2012, 2012 R2 and 2016. In practice the Server 2008/2008 R2/2012/2012 R2 population is where this lands hardest, because a host is usually still running an out-of-support Windows build for a reason — a line-of-business application nobody has re-platformed — which is exactly why the retirement date has to be set and owned rather than deferred to the next patch cycle. Precondition on the interim half: live_patch_available is false and patch_required_reboot is true, so a host that installed the update but has not rebooted still runs the vulnerable COM code and is not remediated. A risk acceptance carrying no removal date leaves a KEV-listed flaw with a public proof-of-concept and confirmed exploitation in service indefinitely.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-08-05, active_exploitation confirmed, poc_available true, rwep_score 77, cvss 8.8. affected_versions lists Windows 7, Windows 8.1, Windows RT 8.1, Windows 10, Windows Server 2008, Server 2008 R2, Server 2012, Server 2012 R2, Server 2016. 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.\" AU-Essential-8-Patch gap: \"Essential Eight OS-patch maturity is undermined where legacy Windows versions cannot receive current updates, leaving the COM deserialization path open on unsupported builds.\" UK-CAF-B4 gap: \"CAF's secure-configuration objective does not force retirement or hardening of end-of-support Windows 7, Server 2008 and 2012 builds, where the UnmarshalPwn COM deserialization primitive stays exploitable years after the 2018 fix and reached KEV only in 2024.\" NIS2-Art21-patch-management gap: \"Patch-management obligations without a hard legacy-OS deadline let end-of-support Windows builds carry a decade-old exploitable deserialization flaw.\"",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this primitive in Microsoft COM for Windows: an attacker delivers a crafted serialized COM object via a file or script, the Windows COM runtime unsafely deserializes it (UnmarshalPwn), and the result is privilege escalation and code execution — used, per this entry's own technical-vulnerability-management gap, as a publicly-weaponized privilege-escalation building block after initial access. For this CVE the control means the Windows update carrying the 2018 fix is driven across every affected host on the clock that opened with the 2024-08-05 KEV listing, rather than left in the backlog where the age of the CVE has kept it, 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. Enumerate first the hosts where the flaw's precondition is the normal operating state: multi-user and service-account-heavy Windows servers from the packet's list, where an account for the attacker to escalate from already exists. The packet records patch_required_reboot true and live_patch_available false, with the vendor update requiring a reboot and being the remediation — so a host that installed the update and has not rebooted still carries vulnerable COM code and counts as exposed, and on a legacy line-of-business server the reboot is precisely the step that gets deferred while the console reads patched. That deferral is the specific way this remediation goes wrong. Priority follows the packet rather than the CVE's age: a public proof-of-concept, confirmed exploitation, KEV listing in 2024, and the packet's record of use by Chinese threat actors and around ransomware operators make this a containment step for a chain, not a standalone endpoint item. Note what the update is doing here that other controls cannot: the packet's malicious-code-protection gap records that signature-based defenses under-detect this primitive because it uses legitimate OS marshalling, so an endpoint-protection attestation passes cleanly while the flaw stays fully exploitable — reaching the fixed build is the containment, not the anti-malware posture.",
+        "evidence": "Packet vector and attack_vector: \"Microsoft COM for Windows ... fails to properly handle serialized objects\"; \"An attacker delivers a crafted serialized COM object via a file or script; the Windows COM runtime unsafely deserializes it (UnmarshalPwn), yielding privilege escalation and code execution on unpatched hosts.\" cisa_kev true, kev_date 2024-08-05, active_exploitation confirmed, poc_available true, rwep_score 77, cvss 8.8, cwe_refs CWE-502. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes \"No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.\" active_exploitation_notes: added to CISA KEV in August 2024 after in-the-wild use; leveraged for privilege escalation and code execution \"including by Chinese threat actors (e.g. Cinnamon Tempest / activity around the ChamelGang and ransomware operators)\"; KEV ransomware status Unknown. NIST-800-53-SI-2 gap: \"The flaw was patched in 2018 but reached KEV in 2024, meaning long-lived unpatched Windows hosts remained exploitable for years\". ISO-27001-2022-A.8.8 gap: management \"that defers old-CVE Windows patches as 'low priority' overlooks a reliable, publicly-weaponized privilege-escalation building block still used post-initial-access.\" NIST-800-53-SI-3 gap: \"Malicious-code protection often does not flag the UnmarshalPwn COM deserialization primitive because it uses legitimate OS marshalling\".",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-37085": {
     "name": "VMware ESXi Authentication Bypass Vulnerability",
@@ -47844,7 +48707,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",
@@ -48210,7 +49094,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",
@@ -48386,7 +49294,42 @@
         "adequate": false,
         "gap": "Technical-vulnerability management must track transitive dependencies (jt-jiffle inside GeoServer); a top-level GeoServer inventory alone misses the vulnerable component."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The vulnerable code is not GeoServer — it is jt-jiffle inside JAI-EXT, which GeoServer bundles, and the execution runs a level further down through Janino, which compiles the supplied Jiffle script into Java. An inventory that records the GeoServer version and stops there cannot answer whether a given deployment carries the vulnerable component, which is exactly how an estate keeps a maximum-severity unauthenticated RCE it does not know it has. Applied here the control means the inventory resolves to the JAR level for these deployments: record the jt-jiffle version each instance loads against the fixed 1.1.22 / 1.2.22 line as well as the GeoServer version against 2.18.6, 2.19.6 and 2.20.4, and search for the jt-jiffle artifact itself rather than only for the product name. The packet describes the flaw as affecting programs that allow a Jiffle script to be supplied via network request, with GeoServer named as the downstream project it particularly affects, so any other application in the estate that bundles jt-jiffle carries the same compile-and-execute sink and a product-name sweep will report it clean. This is also the step that reaches the unattended instance: a GeoServer standing up a public map service outside routine maintenance cannot be placed on any remediation clock until an inventory names both the instance and the component inside it.",
+        "evidence": "The packet's affected field identifies JAI-EXT jt-jiffle (used by GeoServer) as the vulnerable component, and its vector states that programs allowing Jiffle script to be provided via network request can lead to remote code execution because the script is compiled into Java code via Janino and executed, and that this in particular affects the downstream GeoServer project. affected_versions gives JAI-EXT (jt-jiffle) before 1.1.22 / 1.2.22 and GeoServer before 2.18.6 / 2.19.6 / 2.20.4. The cited A.8.8 gap states that technical-vulnerability management must track transitive dependencies — jt-jiffle inside GeoServer — because a top-level GeoServer inventory alone misses the vulnerable component; the UK CAF gap records GeoServer instances as frequently deployed as unattended GIS infrastructure outside routine maintenance, and the NIS2 gap records vulnerability-management obligations as not by themselves surfacing what is needed here.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "This CVE ships with exactly the configuration-side path this control requires operators to hold ready: the packet states that users unable to upgrade may negate the ability to compile Jiffle scripts from the final application by removing janino-x.y.z.jar from the classpath, which takes the compile-and-execute sink out of reach without waiting for the JAI-EXT or GeoServer release. The requirement is that this path is inventoried, tested on a staging instance, and deployable independently of the upgrade path — and it matters more than usual here because segmentation is not an alternative: the packet's boundary-protection gap records the Jiffle-backed WPS process as reachable on the same unauthenticated WMS/OWS endpoint the service exists to publish, so there is no network restriction that removes the path while leaving the service useful. Removing the sink is the lever that does. Two preconditions must be stated before this is recorded as an active mitigation. Removing janino negates Jiffle compilation altogether, so a deployment that legitimately renders Jiffle-backed processes loses that function and has to confirm it does not depend on it before applying this. And the classpath change is not in effect while the servlet container is still running with janino already loaded — the packet records no live-patch primitive and no host reboot, so the JVM has to be restarted and the state measured on what the running instance has loaded rather than on what is on disk.",
+        "evidence": "The packet's vector states that users unable to upgrade may negate the ability to compile Jiffle scripts from the final application by removing janino-x.y.z.jar from the classpath, and that version 1.2.22 contains a patch disabling the ability to inject malicious code into the resulting script. The attack_vector describes an unauthenticated WPS request to the GeoServer WMS/OWS endpoint invoking the ras:Jiffle process with injected Java that Janino compiles and executes. The cited boundary-protection gap states that boundary protection is ineffective because the Jiffle-backed WPS process is reachable on the same unauthenticated WMS/OWS endpoint the service exists to expose; the NIS2 gap states that vulnerability-management obligations do not by themselves surface the compensating control of removing janino from the classpath when immediate upgrade is not possible. patch_required_reboot is false and live_patch_available is false, with live_patch_notes recording no live-patching primitive for this product.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SC-7",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For GeoServer this control's requirement is that a verified mitigation lands on the clock the 2024-06-26 KEV listing opened, and that the record says which mitigation each instance got — because the two available paths are not equivalent. The fixed builds remove the injection (jt-jiffle 1.1.22 / 1.2.22; GeoServer 2.18.6, 2.19.6 or 2.20.4, so the target depends on which of the three branches the instance is on), while removing janino from the classpath removes the Jiffle feature instead; an instance carrying the second is mitigated, not fixed, and reverts the moment the jar returns through a redeploy or a container-image rebuild. Urgency here is not a CVSS argument: the packet puts EPSS at roughly 0.99 with confirmed in-the-wild exploitation, and records that on a default install the Jiffle-backed WPS endpoint is reachable unauthenticated, so the exposure needs no credential and no operator misconfiguration to be live. Precondition on measurement: patch_required_reboot is false, meaning no host reboot, but the replaced jt-jiffle jar is not in force while the servlet container is still running the old one — completion is the version the running GeoServer has loaded, not the artifact deployed beside it.",
+        "evidence": "The packet records cisa_kev true with kev_date 2024-06-26, active_exploitation confirmed, poc_available true, CVSS 10 with rwep_score 70, and an active-exploitation note stating it was added to KEV after in-the-wild exploitation against GeoServer, which bundles the vulnerable jt-jiffle, and that on a default install the Jiffle-backed WPS endpoint is reachable unauthenticated for unauthenticated RCE, with EPSS approximately 0.99. patch_available is true with affected_versions giving JAI-EXT (jt-jiffle) before 1.1.22 / 1.2.22 and GeoServer before 2.18.6 / 2.19.6 / 2.20.4; the vector records the alternative of removing janino-x.y.z.jar from the classpath for users unable to upgrade. live_patch_available is false and patch_required_reboot is false, with live_patch_notes recording the vendor update as the remediation. The cited Essential Eight gap states patch timelines exceed the exploitation window for a maximum-severity, publicly-reproduced unauthenticated RCE.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-4358": {
     "name": "Progress Telerik Report Server Authentication Bypass by Spoofing Vulnerability",
@@ -48645,7 +49588,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",
@@ -49412,7 +50388,32 @@
         "adequate": false,
         "gap": "Flaw remediation depends on the Chrome auto-update reaching every endpoint; unmanaged or air-gapped browsers lag the fix while an active zero-day is in circulation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "The packet scopes this past its headline product: affected_versions lists Google Chrome below 124.0.6367.201 and, separately, Chromium-based browsers embedding the pre-124.0.6367.201 Visuals component, and the affected field names Microsoft Edge and Opera among them. Each of those ships on its own vendor update channel, so the no-deferral requirement has to be set on every browser update ring in the estate rather than on the one the estate standardised on — an Edge or Opera population held on a slow ring keeps running the vulnerable Visuals code while the Chrome ring reports complete. The packet gives the fixed Chrome build (124.0.6367.201) and gives no build numbers for the other Chromium-based products, so each of those has to be pinned to its own vendor's build carrying this fix rather than to Chrome's number. Completion is measured on the version the running browser reports, not on what is staged on disk: patch_required_reboot is false, so no host reboot is being coordinated, but the packet records no live-patch path and states the vendor update is the remediation, and a browser process that has not been relaunched is still executing the pre-fix Visuals code — which is the whole exposure here, since the flaw is reached from a renderer already compromised inside that same running process tree. Precondition: an update ring only reaches browsers a management channel can see and set policy on. This entry's flaw-remediation gap records that remediation depends on the Chrome auto-update reaching every endpoint and that unmanaged or air-gapped browsers lag the fix; for those installs the ring policy delivers nothing and the browser has to be reached by whatever channel does manage it, or removed from the host. The distinguishing test is to query the running build from each browser product on a sample of endpoints and compare it against that product's fixed build — an estate that reports its Chrome ring at 100 percent while Edge and Opera version data is absent has proved currency for one product and nothing about the component the packet actually names.",
+        "evidence": "affected_versions: 'Google Chrome < 124.0.6367.201' and 'Chromium-based browsers embedding the pre-124.0.6367.201 Visuals component'; the affected field names 'Google Chrome (and Chromium-based browsers such as Microsoft Edge and Opera) prior to 124.0.6367.201'. patch_available true; patch_required_reboot false; live_patch_available false; live_patch_notes: 'No live-patching primitive for this product; the vendor update (no reboot required) is the remediation.' CISA KEV 2024-05-13, active_exploitation confirmed, CVSS 9.6, RWEP 54, poc_available false. The vector records a use-after-free in Visuals allowing 'a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page'. The AU-Essential-8-Patch gap records that the patch-applications control 'tracks app currency but rarely enforces same-day browser updates matching the zero-day timeline'; the UK-CAF-B4 gap records that system-security assurance 'rarely provides fleet-wide browser-version proof' during this exploitation window; the NIST-800-53-SI-2 gap records that 'unmanaged or air-gapped browsers lag the fix while an active zero-day is in circulation'; the ISO-27001-2022-A.8.8 gap records that patch coverage 'cannot be proven during the exploitation window'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This is the CVE shape that a severity-and-precondition triage queue demotes and the KEV clock does not. The vector states exploitation is performed by an attacker who has already compromised the renderer process, so a model that treats 'needs a prior foothold' as mitigating ranks a sandbox-escape link below unauthenticated RCEs — while the packet records confirmed in-the-wild exploitation as a Chrome zero-day with the vendor acknowledging an exploit exists, and poc_available false, meaning there is no public artifact to make the risk feel concrete to a reviewer. Under this control the KEV listing of 2024-05-13 sets the clock instead: the fixed build is driven across Chrome and every other Chromium-based browser the packet names on the KEV timeline, not on the browser-update cadence the estate normally runs, and the population that cannot take it inside the window gets a documented compensating control with a dated action item rather than a deferral. Precondition on what 'verified mitigation' can mean here: the packet records patch_available true with live_patch_available false and no vendor mitigation rule, so there is nothing to stand in for the fixed build — the only satisfying evidence is the fixed version running. Because the update needs no host reboot, the single step between staged and running is the browser relaunch, and that is the step users defer for days on a browser they keep open; a KEV clock closed on deployment records rather than on relaunched-version telemetry closes on the wrong event.",
+        "evidence": "CISA KEV listed 2024-05-13; active_exploitation confirmed; active_exploitation_notes: 'Exploited in the wild as a Chrome zero-day (Google acknowledged an exploit exists) before the 124.0.6367.201 fix; the Visuals use-after-free is used from a renderer-compromised context to attempt a sandbox escape.' poc_available false; RWEP 54 against CVSS 9.6; patch_available true; live_patch_available false with live_patch_notes stating the vendor update is the remediation and requires no reboot. The NIS2-Art21-vulnerability-management gap records that 'vulnerability-management obligations do not mandate blocking browsing until the browser is confirmed patched against an actively exploited client-side RCE'; the NIST-800-53-SI-2 gap records that remediation depends on the Chrome auto-update reaching every endpoint.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-7028": {
     "name": "GitLab Community and Enterprise Editions Improper Access Control Vulnerability",
@@ -50112,7 +51113,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",
@@ -50186,7 +51219,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)",
@@ -51988,7 +53046,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",
@@ -52666,7 +53747,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",
@@ -52723,7 +53827,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",
@@ -53123,7 +54260,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",
@@ -53432,7 +54592,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)",
@@ -53489,7 +54673,32 @@
         "adequate": false,
         "gap": "Technical vulnerability management presumes an available remediation path, but chipset-driver fixes are OEM-gated and frequently unavailable for legacy models."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The trigger the packet records is a local application: a use-after-free reached when process shell memory is freed through an IOCTL munmap call while process initialization is still in progress, ending in local privilege escalation. Nothing sits in front of that — the code is already on the device — and Qualcomm's fix reaches a unit only inside an OEM firmware/OS update the operator cannot push, which is what all five framework gaps on this entry record. So for this CVE the control's access-condition half is the load-bearing one: on the Snapdragon Mobile handsets an MDM/UEM enrols, the OEM build carrying the Qualcomm May 2022 bulletin fix must function as a condition of access — mail, VPN and document access denied to a handset below it — not as a row on a patch-compliance dashboard, because a dashboard that surfaces the stale build while the device keeps its access has recorded the exposure rather than removed it. The distinguishing test is to enrol a handset pinned below the fixed build and confirm the policy actually refuses it access to protected resources. Preconditions, both load-bearing here. First, this reaches only devices a management console enrols: `affected` also names Snapdragon Auto, Compute, Connectivity, Consumer IOT, Industrial IOT and Voice & Music platforms, and an in-vehicle head unit or an industrial gateway takes no device-compliance policy, so scoping this to handsets alone leaves those families untouched and they belong on the enumeration-and-replacement path instead. Second, live_patch_available is false and the packet states remediation requires the OEM update plus a device reboot, so a device that has taken the update but not rebooted is still executing the vulnerable driver and must be counted as exposed. Restricting which applications may be installed raises the bar for getting the attacker's application onto the device, but it does not evict one already installed, and a device suspected of already running it belongs on the incident path rather than the install-policy path.",
+        "evidence": "The packet records patch_available true with patch_required_reboot true, live_patch_available false, and live_patch_notes stating there is no live-patch mechanism for chipset drivers and that remediation requires the OEM firmware/OS update carrying Qualcomm's fix plus a device reboot. `affected` names Snapdragon Auto, Compute, Connectivity, Consumer IOT, Industrial IOT, Mobile and Voice & Music platforms with the use-after-free triggered when process shell memory is freed via an IOCTL munmap call during process initialization; affected_versions points to the Qualcomm May 2022 security bulletin. CISA KEV listing 2023-12-05 with active_exploitation confirmed. The UK-CAF-B4 gap states a chipset-driver use-after-free on unmanaged mobile is outside the org's patch reach; the NIS2-Art21-patch-management gap states patching duties cannot compel OEMs/carriers to deliver the chipset driver update and that enterprise tooling cannot patch the affected driver directly.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "patch_available:true here means Qualcomm shipped a fix, not that any given unit can receive it, and the packet states the difference outright: the Essential-Eight gap records that older device models may never receive the OEM firmware carrying the fix, and the ISO A.8.8 gap that chipset-driver fixes are OEM-gated and frequently unavailable for legacy models. That is a no-ongoing-patch-path condition determined per unit, so the control's requirement is to resolve it per unit rather than at the CVE level. Inventory every Snapdragon-based asset in service across the platforms the packet names — Mobile, Compute, Connectivity, Auto, Consumer IOT, Industrial IOT and Voice & Music — and record for each whether its OEM has actually shipped a build carrying the May 2022 bulletin fix for that exact model. Units that have one are interim items on the clock that opened with the 2023-12-05 KEV listing; because the packet registers no live-patch path and a required device reboot, a unit that took the update but has not rebooted is still running the vulnerable driver and is not remediated. Units whose OEM has shipped nothing cannot be patched by any operator action at all, so the terminal state for them is replacement on a dated schedule — a risk acceptance with no removal date leaves a confirmed-exploited local privilege escalation in service indefinitely, and that unit stays exposed not only to this use-after-free but to everything found in that driver since its last build. The Auto and Industrial IOT families are where this bites hardest, because those units have long service lives and no consumer refresh cycle to retire them incidentally. Scope it to the Snapdragon platforms the packet names: it gives no mapping into other vendors' chipsets, so treating every mobile or embedded device in the estate as an instance of this CVE manufactures replacement work against hardware no evidence implicates.",
+        "evidence": "The packet's AU-Essential-8-Patch gap states the exploited-flaw patch window is not achievable when older device models may never receive the OEM firmware carrying the fix; the ISO-27001-2022-A.8.8 gap states technical vulnerability management presumes an available remediation path but chipset-driver fixes are OEM-gated and frequently unavailable for legacy models; the NIST-800-53-SI-2 gap states devices remain exposed long after the bulletin. patch_available is true, patch_required_reboot true, live_patch_available false, with live_patch_notes recording no live-patch mechanism for chipset drivers. `affected` enumerates Snapdragon Auto, Compute, Connectivity, Consumer IOT, Industrial IOT, Mobile and Voice & Music; affected_versions cites the Qualcomm May 2022 security bulletin. CISA KEV 2023-12-05, active_exploitation confirmed, RWEP 55, CVSS 7.8, poc_available false.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-42917": {
     "name": "Apple Multiple Products WebKit Memory Corruption Vulnerability",
@@ -54158,7 +55367,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",
@@ -54695,7 +55929,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",
@@ -54752,7 +56011,41 @@
         "adequate": false,
         "gap": "Hardening/removing unused management functionality would drop the installAppPackage.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-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "J-Web is the management plane on these EX-series switches, and installAppPackage.php is a file-accepting endpoint on it that enforces no authentication at all — an unauthenticated, network-based request uploads arbitrary files into a restricted J-Web directory. Bound to this product the control means two things. Every file-accepting J-Web endpoint authorizes its caller before the upload is processed, so a caller with no credential cannot cause a write. And no EX-series switch is left with J-Web reachable from a segment with no operational need for it: disabled outright on switches administered through another path, and confined to a management network on those where the web interface must stay available. The account model is not the lever here — the attacker never presents an operator credential, so per-account access rules on the switch are never consulted and an identity attestation over the device passes while the upload path stays open. Distinguishing test: from a general user VLAN, POST a file to installAppPackage.php on a staging EX switch and confirm it is refused before anything is written; 'J-Web is on the internal network' is a statement about topology, not a demonstration that the endpoint is unreachable from untrusted segments. Precondition: the endpoint's own authentication is restored by the fixed Junos release, not by this control. Until that release is running, restricting reachability bounds who can send the request and leaves the endpoint fully exploitable to anything inside the permitted segment — and disabling J-Web is unavailable where it is the operational management path.",
+        "evidence": "affected: Juniper Networks Junos OS on EX Series, J-Web interface; unauthenticated arbitrary file upload via installAppPackage.php, under CWE-306. attack_vector: an unauthenticated attacker sends a request to installAppPackage.php that lacks an authentication check, uploading arbitrary files into a restricted J-Web directory. The NIST-800-53-AC-3 gap states access enforcement is exactly what is missing and that until patched no access policy compensates; the NIST-800-53-SC-7 gap names boundary protection that exposes J-Web as the precondition and segmenting/disabling the management interface as the durable mitigation; the NIS2-Art21-network-security gap states network-security duties do not mandate management-plane isolation; the AU-Essential-8-App-Hardening gap states that hardening or removing unused management functionality would drop the installAppPackage.php surface but is easily left enabled; the UK-CAF-B4 gap states system-security expectations do not require disabling or segmenting J-Web on EX-series switches. patch_available true, live_patch_available false, patch_required_reboot true.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a CVSS-keyed queue produces the wrong answer: a 5.3 base score against RWEP 76, EPSS 0.85 at the 99.7th percentile, a public PoC, and exploitation observed from Aug 25 2023 on a flaw the packet calls a documented link in a public pre-auth RCE chain. The requirement is that the remediation clock runs from the 2023-11-13 KEV listing and the chain evidence rather than the base-score band, across every EX-series switch, with the target taken per branch — 20.4R3-S8, 21.2R3-S6, 21.3R3-S5, 21.4R3-S4, 22.1R3-S3, 22.2R3-S1, 22.3R2-S2/22.3R3, 22.4R2-S1/22.4R3 — because an enumeration keyed to one release number marks every other branch clean. The packet records 21.1R1 and later as affected while naming no fixed release in that branch, so a 21.1 switch cannot be closed against this list and needs a branch that has one. Completion is the running Junos release: there is no live-patch path and the fix requires a reboot, so a switch with the image installed but not yet rebooted onto it is still serving the vulnerable J-Web and counts as exposed — on a switch carrying production traffic that reboot is the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong.",
+        "evidence": "CVSS 5.3, RWEP 76, poc_available true; active_exploitation_notes record EPSS 0.85 (99.7th pct), exploitation observed from Aug 25 2023 as part of the actively-exploited Juniper J-Web pre-auth RCE chain, and KEV listing 2023-11-13. The NIST-800-53-SI-2 gap states 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 states triage keyed to the 5.3 base score misses that it is a proven link in a public RCE chain warranting out-of-cycle remediation on any exposed EX-series switch. affected_versions give the per-branch fixed releases listed above, and the vector records 21.1 versions 21.1R1 and later as affected with no fixed 21.1 release named. live_patch_available false; live_patch_notes: remediation requires applying the fixed release and rebooting; patch_required_reboot true.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive on this CVE is a write, not a crash: an unauthenticated request to installAppPackage.php places arbitrary files into a restricted J-Web directory, and the packet chains that with the PHPRC flaw into pre-auth RCE. Exploitation of this J-Web chain was observed from Aug 25 2023, roughly three months ahead of the KEV listing, so for any EX-series switch whose J-Web was reachable during that window the fixed release closes the upload path and removes nothing already written through it. Remediation for those units is therefore config-capture and comparison against a known-good baseline, rebuild from a vendor image rather than an in-place upgrade that inherits the existing filesystem, and rotation of the credentials the switch held and the credentials that transited it. Precondition and scope, which decide which units this applies to: a switch whose J-Web was disabled or unreachable throughout the window is remediated by the fixed release plus its reboot, and the rebuild path is not warranted for it. Distinguishing that case requires knowing historical J-Web reachability rather than current configuration, which is why the estate enumeration has to record exposure alongside the running release — a switch whose J-Web was opened temporarily and later closed reads clean on a configuration snapshot taken today.",
+        "evidence": "attack_vector: an unauthenticated attacker sends a request to installAppPackage.php that lacks an authentication check, uploading arbitrary files into a restricted J-Web directory; combined with the PHPRC flaw this yields pre-auth RCE. active_exploitation_notes record it as part of the actively-exploited Juniper J-Web pre-auth RCE chain providing the file-write primitive that chains toward RCE, with exploitation observed from Aug 25 2023, ahead of the 2023-11-13 KEV listing; active_exploitation is confirmed and poc_available true. The UK-CAF-B4 gap describes the unauthenticated installAppPackage.php upload as the documented first link of watchTowr's public preauth RCE chain. live_patch_available false; live_patch_notes: remediation requires applying the fixed release and rebooting — which changes the running code and does not remove files already written.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-36851": {
     "name": "Juniper Junos OS SRX J-Web Missing Authentication File Upload/Download",
@@ -55060,7 +56353,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",
@@ -55604,7 +56930,30 @@
         "adequate": false,
         "gap": "Essential-8 patch-applications targets cover this class, but Acrobat/Reader is commonly under-patched on endpoints, leaving the UAF exploitable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet's affected_versions field is why this is an inventory problem and not a routine patch item: it names two distinct Adobe update tracks — Acrobat/Reader DC (Continuous) at 22.003.20282 and 22.003.20281 and earlier, and Acrobat/Reader 2020 (Classic) at 20.005.30418 and earlier — and on a real estate those ship as separate products on separate update schedules, with per-user copies landing outside managed software distribution entirely. The requirement here is to enumerate every Acrobat and every Reader install across both tracks and on both platforms the packet names (Windows and macOS), and confirm each one reports a build past its track's affected range, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. An estate that patches Reader on the Continuous track while a Classic 2020 Acrobat keeps its build still opens crafted PDFs into the same use-after-free, with an attestation that reads clean. Keep the scope to Acrobat and Reader: the packet ties the use-after-free to those products and provides no mapping from the vulnerable code into other PDF-handling software, so instructing operators to treat every PDF-capable binary in the estate as an instance of this CVE manufactures findings and remediation work against renderers no evidence implicates; widen the inventory only where a verified source identifies another product carrying the same component. Preconditions: this reaches only copies the inventory can see and the operator can update — an unmanaged per-user install is remediated by removing it, not by recording it as patched. And while the packet records no host reboot for this fix and no live-patch path, replacing the binary on disk does not change the code a copy of Acrobat or Reader already has open, so a workstation is remediated when the running application reports a fixed build, not when the installer exits.",
+        "evidence": "affected: 'Adobe Acrobat and Reader (Windows/macOS) — a use-after-free reachable by opening a crafted PDF results in arbitrary code execution in the context of the current user.' affected_versions names three entries across two tracks: 'Acrobat/Reader DC (Continuous) 22.003.20282 and earlier', '22.003.20281 and earlier', and 'Acrobat/Reader 2020 (Classic) 20.005.30418 and earlier'. cwe_refs lists CWE-416. cisa_kev true with kev_date 2023-10-10, active_exploitation confirmed, poc_available true. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes stating 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' The NIST-800-53-SI-2 gap states endpoint-software patch cadence for client apps like Acrobat is often slow relative to how quickly a KEV-listed, PoC-available UAF is weaponized in phishing; the ISO-27001-2022-A.8.8 gap states technical-vulnerability management typically tracks server estates more tightly than endpoint client apps, so this KEV-listed use-after-free lingers unpatched on user workstations; the AU-Essential-8-Patch gap states Acrobat/Reader is commonly under-patched on endpoints.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "Exploitation of this CVE requires the victim to open an attacker-supplied PDF — the packet states user interaction is required and describes phishing as the delivery path — so on any workstation that has not yet reached a fixed Acrobat or Reader build, the delivery path is the only lever the operator holds. Require the untrusted-origin marking on every PDF arriving by mail, web download, or an untrusted file share, and require marked PDFs to open in Acrobat/Reader's Protected View, the reduced-privilege render, instead of the full parsing path that carries the use-after-free at the user's own process privilege. The marking has to survive the container the document arrives in: a PDF extracted from an archive, mounted from an ISO, or renamed must still reach the reader as externally sourced rather than losing the tag on the way, and enabling all features on an externally sourced document must be a policy decision rather than a user click at the moment of the phish. This is also the answer to the malicious-code-protection gap on this entry, and the reason it is a containment control rather than a detection one: a crafted-PDF memory-corruption exploit gives signature-based mail and endpoint scanning nothing reliable to match, so the control has to constrain what the parser runs as, not try to recognize the document. The distinguishing test: mail a PDF nested inside a ZIP to a managed workstation, extract it, and confirm the extracted file still opens in Protected View — an attestation that Protected View is enabled in policy passes while a provenance-stripped document reaches the full parser with the user's privileges. Preconditions: Protected View reduces what the resulting code execution reaches, it does not remove the use-after-free — the vulnerable parser still runs on attacker-controlled content, and the packet records no live-patch path, so only the vendor fixed release removes the flaw. A PDF opened from a location policy treats as trusted, or delivered by an ingress path that does not apply the marking, reaches the full parser regardless. And none of this evicts an attacker who already executed code in a user's context during the exposure window; confirmed exploitation means a workstation that opened untrusted PDFs while unpatched belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "vector: 'Exploitation of this issue requires user interaction in that a victim must open a malicious file.' attack_vector: 'A victim opens a malicious PDF that triggers a use-after-free in Acrobat/Reader, corrupting memory to achieve arbitrary code execution in the current user's context; typically delivered via phishing.' The UK-CAF-B4 gap states system-security expectations don't reliably enforce Protected View / sandboxing and prompt client-app patching, so the exploit runs in the user's context; the NIST-800-53-SI-3 gap states malicious-code protection frequently fails to detect a novel crafted-PDF UAF exploit, so signature-based mail/endpoint AV lets the weaponized document through. cisa_kev true with kev_date 2023-10-10, active_exploitation confirmed, poc_available true. patch_available true, live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.'",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-3"
+        ]
+      }
+    ]
   },
   "CVE-2023-20109": {
     "name": "Cisco IOS and IOS XE Group Encrypted Transport VPN Out-of-Bounds Write Vulnerability",
@@ -55990,7 +57339,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",
@@ -56297,7 +57671,32 @@
         "adequate": false,
         "gap": "Patch-application controls depend on OEM update delivery for mobile firmware, which is slower and less complete than for managed workstations."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet's actor is a local, non-privileged app already on the device performing improper GPU memory-processing operations against the Arm Mali GPU kernel driver to reach already-freed memory and escalate. The fix is a driver-level correction that only arrives on a device as an OEM firmware/OTA level, so the enforceable object for an operator is the device's reported build, and it must function as an access condition — mail, VPN and document access denied to any device below it — not a row on a patch-compliance dashboard. Scope from the packet's affected and affected_versions rather than from the vector: it names multiple Mali driver families (Midgard, Bifrost, Valhall, Arm 5th Gen) across Android and Linux devices, with fixed releases at Midgard r44p0 and Bifrost/Valhall/Arm 5th Gen r44p0 and related fixes per Arm's advisory, so an inventory built only around one vendor's Android handsets reports clean across Linux-based and embedded hardware carrying the same driver families. The distinguishing test is to enrol a device pinned below its family's fixed driver release and confirm the policy actually denies it protected resources; an estate that lists the stale build on a report while the device keeps its access has recorded the exposure rather than removed it. Preconditions, both load-bearing here: patch_available is true but live_patch_available is false and the packet states remediation requires applying the fixed release and rebooting, so a device that has taken the OTA but not restarted is still executing the vulnerable driver and must be counted exposed; and devices whose SoC vendor or OEM has not shipped a build carrying the fix cannot reach the condition at all — those need a dated replacement schedule, because an open-ended exception leaves a KEV-listed flaw with confirmed exploitation in service indefinitely. Constraining which apps may install raises the bar for getting the attacker's app onto the device but does not evict one already installed; a device suspected of running it belongs on the incident path, not the install-policy path.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-10-03, active_exploitation confirmed, rwep_score 57, cvss 5.5. affected: \"Arm Mali GPU Kernel Driver (multiple driver families, e.g. Midgard/Bifrost/Valhall/Arm 5th Gen) on Android/Linux devices; a local non-privileged user can access already-freed memory.\" affected_versions: \"Arm Mali GPU Kernel Driver versions prior to the fixed releases listed in Arm's advisory (Midgard r44p0, Bifrost/Valhall/Arm 5th Gen r44p0 and related fixes)\". 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.\" active_exploitation_notes: Arm warned the flaw may be under limited, targeted exploitation and Google TAG attributed in-the-wild use to a commercial surveillance (spyware) vendor; the affected drivers are present across a very large Android device population. NIST-800-53-SI-2 gap: fixes \"must flow through SoC vendors and OEMs into device firmware/OTA updates; this multi-party patch chain leaves many Android devices exposed long after Arm's fix\". NIS2-Art21-patch-management gap: the correction \"must traverse Arm → SoC vendor → OEM → carrier OTA\".",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "This entry carries a monitoring gap alongside its patch-chain gaps, and the packet describes the behaviour precisely enough to key on it. The rule keys on the pairing the packet documents: an ordinary, non-privileged installed application driving GPU memory-processing operations at the Mali kernel driver interface, followed by a privilege transition in that same process — an unprivileged app acquiring kernel-level or root capability with no user interaction. Both halves are needed, because either alone is normal traffic on a device with a GPU: graphics workloads talk to the Mali driver constantly, and privileged processes exist legitimately; it is the transition arriving out of an unprivileged app's own driver activity that distinguishes this exploit. Note what will not see it. The packet records poc_available as false, so there is no published exploit artifact to signature and a tool-name or hash-based rule has nothing to match; and the primitive is access to already-freed memory rather than a fault, so an exploit doing exactly what the packet describes may complete without a crash — alerting on process crashes or on named exploit tooling would miss it entirely. Precondition, and it is the reason this gap exists rather than a lever the operator always holds: this requires kernel-level audit or eBPF telemetry collected on the device and shipped off-device before the attempt. The packet's own system-monitoring gap records that mobile-device monitoring has little visibility into GPU-driver-level kernel exploitation, so on a stock consumer Android handset the operator generally cannot enable it; the control is reachable on managed estates and on the Linux-based Mali devices the packet also names, and a rule authored after the fact against telemetry nobody was collecting produces nothing. Detection also does not prevent the escalation and does not remove what an implant left behind — it bounds exposure to alert-and-response time during the window before the fixed driver release and its reboot land, and given confirmed exploitation attributed to a commercial surveillance vendor, a device that produces the signal belongs on the incident path rather than the patch queue.",
+        "evidence": "Packet NIST-800-53-SI-4 gap: \"Mobile-device monitoring has little visibility into GPU-driver-level kernel exploitation, so this LPE proceeds without a practical detection signal.\" UK-CAF-B4 gap: \"System-security assurance relies on the app sandbox holding, yet a kernel use-after-free reached from a non-privileged app breaks that boundary, and mobile telemetry gives the control no practical signal for GPU-driver-level exploitation.\" attack_vector: \"A local, non-privileged app performs improper GPU memory-processing operations against the Mali kernel driver to access already-freed memory, achieving kernel privilege escalation as a stage in a targeted surveillance exploit chain.\" poc_available false; active_exploitation confirmed; Google TAG attributed in-the-wild use to a commercial surveillance (spyware) vendor; affected covers Android/Linux devices; live_patch_available false with remediation requiring the fixed release and a reboot.",
+        "gap_closes": [
+          "NIST-800-53-SI-4",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-5217": {
     "name": "Google Chromium libvpx Heap Buffer Overflow Vulnerability",
@@ -56445,7 +57844,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",
@@ -56755,7 +58178,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",
@@ -57110,7 +58564,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",
@@ -57247,7 +58727,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",
@@ -57540,7 +59045,31 @@
         "adequate": false,
         "gap": "System security expects timely patching but provides no compensating control for a publicly-weaponized kernel driver flaw in the interim."
       }
-    }
+    },
+    "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",
@@ -57777,7 +59306,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",
@@ -58424,7 +59985,41 @@
         "adequate": false,
         "gap": "A.5.15 access-control policy assumes administrative rights are assigned to authenticated principals, but this improper-authentication flaw lets a remote, unauthenticated attacker assume full administrator rights on the Management Server, so the access-control model is circumvented at the authentication boundary rather than enforced."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry uses the control's 'patch, live patch, or documented compensating controls' clause in full, because the packet supplies both halves: the fix is the 22 July 2026 Jumbo Hotfix (sk185169) installed on the Security Management / Multi-Domain Management server with a management-service restart, and the documented interim mitigation is restricting Trusted Clients to known SmartConsole hosts. CISA listed the flaw on 2026-07-22 with a 2026-07-25 due date — three days — so the clock this control names is the operative one and no routine management-server maintenance window satisfies it. Scope the sweep to both products the packet names: Security Management and Multi-Domain Management servers alike, because an estate standardised on Multi-Domain Management is untouched by an inventory that enumerates Security Management only. Completion is measured on the management service actually executing the hotfixed login path, not on the hotfix being installed: patch_required_reboot is true, the packet's own remediation note specifies a management-service restart, and live_patch_available is false, so a server carrying the hotfix that has not been restarted is still minting tokens from the pre-fix code and must be counted as exposed. Precondition on the interim mitigation, which is where this gets recorded wrong: the packet states remote exploitation requires internet access to the Management Server IP and a configuration that does not restrict Trusted Clients, so restricting Trusted Clients removes the remote precondition — it does not repair the server's trust in a peer-supplied SIC distinguished name. It gives nothing against a caller operating from a host already in the Trusted Clients set or otherwise able to reach the management network, and it is a holding measure for the window before the hotfix and its restart land, not a closure. And because Check Point confirmed exploitation, a server that was internet-reachable without Trusted Clients restrictions during that window needs its administrator objects and installed security policy compared against a known-good copy: the vector's stated outcome is modification of security policies and configurations, and the hotfix does not undo changes already made.",
+        "evidence": "live_patch_notes: 'No live-patch mechanism; remediation requires installing the 22 July 2026 Jumbo Hotfix (sk185169) on the Security Management / Multi-Domain Management server, with a management-service restart. Restricting Trusted Clients to known SmartConsole hosts is the interim mitigation'; patch_available true, patch_required_reboot true, live_patch_available false; cisa_kev true, kev_date 2026-07-22, active_exploitation_notes: 'CISA added it to KEV the same day with a three-day remediation due date (2026-07-25)' and Check Point confirmed active exploitation affecting a small number of customers at disclosure on 22 July 2026; vector: 'Remote exploitation requires internet access to the Management Server IP address and a configuration that does not restrict Trusted Clients', and successful exploitation 'allows the attacker to modify security policies and security configurations'; affected_versions: 'Check Point Security Management and Multi-Domain Management without the 22 July 2026 Jumbo Hotfix (sk185169)'; NIST-800-53-IA-2 gap: 'MFA layered on SmartConsole does not help because the token is minted before any user credential is checked'; AU-Essential-8-MFA gap: requiring MFA 'provides no protection against CVE-2026-16232 until the 22 July 2026 hotfix is applied'; cvss 9.1, rwep_score 75, poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "AU-Essential-8-MFA"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The SmartConsole login process is where this product makes its authentication decision, and this CVE is that decision failing open: the packet places the flaw in a login flow that trusts an attacker-supplied SIC distinguished name instead of the authenticated peer certificate DN, mints a valid application login token from it, and hands the caller full administrative privilege — after which every administrative operation on the Management Server honours a token that no credential was ever presented for. Bound to this product, the control means the Management Server derives the peer's identity from the authenticated channel rather than from a name the peer asserts, that the privileged operations behind the login — security policy modification, configuration change — authorise their caller rather than inheriting a verdict from the login step, and that the management surface is segmented so an untrusted network caller cannot present a login attempt to that server at all. This is exactly why every identity control cited on this entry passes its attestation while the path stays open: the attacker never authenticates as any Check Point administrator, so per-account access-control policy is never consulted and the account model an access-control review examines is bypassed rather than abused. Distinguishing test for this product: from a segment with no operational need to administer firewall policy, drive the SmartConsole login flow against a staging Security Management or Multi-Domain Management server supplying an arbitrary SIC DN, and confirm no login token is issued — a review confirming that every SmartConsole administrator holds a named account and authenticates at login passes cleanly while this path is open. Precondition: the identity-derivation property is what the 22 July 2026 Jumbo Hotfix establishes; this control states what to verify, it does not implement it. Until that hotfix and its management-service restart land, the segmentation half bounds who can present the request — and only where the Management Server IP is not internet-reachable and Trusted Clients is restricted, the two conditions the packet names for remote exploitation — while leaving the server fully exploitable by anything inside the permitted set.",
+        "evidence": "affected: 'Check Point SmartConsole / Security Management and Multi-Domain Management, where the login process trusts an attacker-supplied SIC distinguished name instead of the authenticated peer certificate DN'; attack_vector: an unauthenticated remote attacker with network access to the Management Server IP supplies a SIC distinguished name the server accepts as the remote application's identity, and the server issues a valid login token granting full administrative access to modify security policy and configuration; vector: 'an unauthenticated remote attacker to obtain an application login token and use it to authenticate with full administrative privileges'; UK-CAF-B2 gap: 'the SIC-DN trust flaw grants administrative privilege without any valid credential, so B2 access governance over the SmartConsole management plane is bypassed rather than merely weakened'; ISO-27001-2022-A.5.15 gap: 'the access-control model is circumvented at the authentication boundary rather than enforced'; NIST-800-53-IA-2 gap: 'identity verification is bypassed entirely rather than strengthened'; live_patch_notes name the 22 July 2026 Jumbo Hotfix (sk185169) with a management-service restart as the remediation and Trusted Clients restriction as the interim mitigation; active_exploitation confirmed, poc_available true.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "A Check Point Security Management or Multi-Domain Management server is a configuration-management control plane for a firewall estate — the packet's stated exploitation outcome is the attacker modifying security policies and configurations — and this CVE exposes what the frameworks cited here do not carry: they govern the administrator's credential, and no credential was used. State that plainly before anything else, because it is the half of this control that must not be claimed on this entry: FIDO2 step-up per session, just-in-time elevation with approval, and a separate identity for SmartConsole administrators leave this flaw fully exploitable, since the login token is minted from a spoofed peer identity before any user credential is checked. What is load-bearing here is the tier's other two halves. Reachability: the management plane is administered only from a dedicated privileged-access tier, so the Management Server's login surface answers a known jumphost set rather than a general network or the internet — the same restriction the packet names as the interim mitigation, expressed as standing architecture rather than as an emergency response, which is the difference between having it in place when the disclosure lands and configuring it under a three-day KEV clock. Classification: compliance frameworks must enumerate the firewall management plane as a distinct tier instead of collapsing it into 'admin', because that is what makes an estate ask whether a Security Management or Multi-Domain Management server is internet-reachable before a KEV listing forces the question, and both server products have to be enumerated rather than the Security Management ones alone. Precondition: reachability confinement bounds the population that can attempt the token mint and does not repair the server's trust in a peer-supplied SIC DN; it is unavailable where a Management Server must stay reachable from outside the tier; and it does not evict an attacker who already obtained an administrative token during the exposure window, whose access has to be handled as an incident against the policy and configuration the packet says such a token can rewrite.",
+        "evidence": "AU-Essential-8-MFA gap: 'the login token is issued pre-authentication from a spoofed peer identity, so requiring MFA for SmartConsole admins provides no protection against CVE-2026-16232 until the 22 July 2026 hotfix is applied'; NIS2-Art21-identity-management gap: 'policy-level identity controls did not prevent unauthenticated administrative access to the firewall management plane', with a 2026-07-25 KEV due date and confirmed exploitation; UK-CAF-B2 gap: 'CAF B2 (identity and access control) presumes privileged management access is gated by verified identity'; ISO-27001-2022-A.5.15 gap: 'A.5.15 access-control policy assumes administrative rights are assigned to authenticated principals'; vector: remote exploitation 'requires internet access to the Management Server IP address and a configuration that does not restrict Trusted Clients', and successful exploitation allows the attacker to modify security policies and security configurations; live_patch_notes: restricting Trusted Clients to known SmartConsole hosts is the interim mitigation, with the 22 July 2026 Jumbo Hotfix (sk185169) and a management-service restart as remediation; affected_versions name both Security Management and Multi-Domain Management; active_exploitation confirmed, kev_date 2026-07-22.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "NIS2-Art21-identity-management",
+          "ISO-27001-2022-A.5.15"
+        ]
+      }
+    ]
   },
   "CVE-2026-50522": {
     "name": "Microsoft SharePoint Deserialization of Untrusted Data Vulnerability",
@@ -58546,7 +60141,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",
@@ -58701,7 +60319,39 @@
         "adequate": false,
         "gap": "A.5.15 access control presumes credentials are protected behind an access-control decision; here the stored credentials are returned to any unauthenticated caller of the backup service, so an access-control policy that never gates the remoting endpoint provides no protection."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "Veeam Backup & Replication's exposure here is exactly the binary remoting-protocol class this control governs: the Veeam.Backup.Service answers a credential-retrieval method on a .NET remoting endpoint at TCP/9401, the endpoint answers before any authentication, and what it returns is the encrypted credentials held in the configuration database. Bound to this deployment the requirement is that TCP/9401 accepts connections only from the hosts the deployment's own component topology shows must speak to the Veeam.Backup.Service, enforced by host firewall or network ACL rather than inferred from 'the backup server is internal', and that the KEV-listed defect in that endpoint is remediated on an accelerated clock by upgrading to 11.0.1.1261 (11a) or 12.0.0.1420 per KB4424 with the Veeam services restarted. The packet records no live-patch path and names the services restart as part of remediation, so a server whose installer has run but whose Veeam services have not restarted is still executing the pre-fix code; completion is the version the running services report. Distinguishing test for this product: from a general user or application-server VLAN on a staging deployment, open a connection to TCP/9401 and confirm it is refused before the service answers — the identity controls cited on this entry govern console and operator login and never observe an unauthenticated remoting call, so they attest clean while this path stays open. Precondition, and it is the half most often over-claimed: restricting TCP/9401 bounds which hosts can reach the method, it does not repair the missing authentication — any host inside the permitted set still reaches it in full, and a compromised backup proxy or management host inside that set satisfies the exploit's only access requirement. It is the packet's stated interim mitigation for the window before the upgrade, not a closure. Credentials already returned to a caller also remain valid after the upgrade.",
+        "evidence": "The packet's affected field places the defect on the Veeam.Backup.Service .NET remoting endpoint at TCP/9401, exposed to unauthenticated callers and returning encrypted credentials from the configuration database; attack_vector has the caller reusing them to reach backup infrastructure hosts. cisa_kev true (2023-08-22), active_exploitation confirmed, poc_available true, with a working PoC public within eleven days of the 2023-03-07 advisory and mass internet scanning for exposed TCP/9401 following it; CISA ransomware use recorded as Known. live_patch_available is false and live_patch_notes gives remediation as upgrading to 11.0.1.1261 (11a) or 12.0.0.1420 per KB4424 with a Veeam services restart, and names restricting TCP/9401 to trusted hosts as the recommended interim mitigation. The cited NIST-800-53-IA-2 gap states an IA-2 set that only governs console/user login never sees the unauthenticated remoting call; the UK-CAF-B2 and NIS2 identity-management gaps state machine-to-machine backup-service interfaces are neither locked down nor segmented.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "NIS2-Art21-identity-management",
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.5.15"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The packet supplies the exact interval that defeats the cadence this entry cites as insufficient: a working PoC existed within eleven days of the 2023-03-07 Veeam advisory and mass scanning for exposed TCP/9401 followed, while the Essential Eight timeline allows up to a month. For this CVE the clock therefore runs from the 2023-08-22 KEV listing, the later of listing and fix availability, and what must land inside it is one of two verified states: the upgrade to Veeam Backup & Replication 11.0.1.1261 (11a) or 12.0.0.1420 per KB4424 with the Veeam services restarted, or — where that upgrade cannot be taken in the window — the packet's named interim mitigation of restricting TCP/9401 to trusted hosts, recorded as a compensating control carrying a dated action to finish the upgrade. Priority follows the packet rather than the 7.5 base score: CISA records ransomware use as Known and the packet places this vulnerability in intrusion chains that harvest backup credentials to disable or encrypt backups before detonation, which makes it a pre-detonation step against the recovery capability rather than a standalone server finding. The response also does not end at the version check. Because the endpoint returns stored credentials to whoever calls it, a server that was reachable on TCP/9401 while unpatched must have the credentials in its configuration database treated as disclosed and rotated; the upgrade closes the retrieval path and does nothing to material already read out.",
+        "evidence": "Packet facts: poc_available true, with the PoC public within eleven days of the 2023-03-07 advisory and mass internet scanning for exposed TCP/9401 afterwards; cisa_kev true with kev_date 2023-08-22; active_exploitation confirmed; CISA ransomware use Known; the entry folded into chains that harvest backup credentials to disable or encrypt backups before ransomware detonation. cvss 7.5, rwep_score 68. patch_available true with live_patch_available false; live_patch_notes gives the upgrade targets 11.0.1.1261 (11a) and 12.0.0.1420 per KB4424 with a Veeam services restart, plus restricting TCP/9401 to trusted hosts as the interim mitigation. The cited AU-Essential-8-Patch gap states that a compliant 30-day cadence still leaves the ransomware-linked credential dump exploitable for weeks. The disclosed-credential point follows from the packet's own affected and attack_vector text: the endpoint returns stored credentials from the configuration database and the attacker reuses them against backup infrastructure hosts.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry produces two intermediate states that a Veeam patch-compliance report collapses into a single green row. The first is the packet's own interim mitigation: a server with TCP/9401 restricted to trusted hosts but still running a build below 11.0.1.1261 (11a) or 12.0.0.1420 has not had the defect fixed — the unauthenticated credential-retrieval method still answers every host inside the permitted set — so it belongs in a distinct compensating-control state with a dated action to complete the upgrade, never in the 'patched per SLA' bucket. The second is narrower and easier to miss: the packet's remediation is the upgrade plus a restart of the Veeam services, so a server whose installer has run but whose services have not restarted is still executing pre-fix code while the installed-package record reads current. The audit requirement for this product is that the verdict is taken from the version the running Veeam services report and from the state of the TCP/9401 restriction as two separate facts, so that 'mitigation active, patch pending' and 'upgraded, services not restarted' are both visible as open exposure rather than resolved items.",
+        "evidence": "live_patch_available is false and live_patch_notes states there is no vendor live-patch mechanism, that remediation requires upgrading to Veeam Backup & Replication 11a (11.0.1.1261) or 12 (12.0.0.1420) per KB4424 and restarting the Veeam services, and that restricting TCP/9401 to trusted hosts is the recommended interim mitigation. patch_required_reboot is false, which the packet pairs with that services restart — the host needs no reboot, the service does need to restart onto the new code. The cited AU-Essential-8-Patch gap states that the compliant cadence leaves the ransomware-linked credential dump exploitable for weeks, which is the interval during which one of these intermediate states is what a Veeam server is actually in.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-26359": {
     "name": "Adobe ColdFusion Deserialization of Untrusted Data Vulnerability (CVE-2023-26359)",
@@ -58762,7 +60412,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",
@@ -59286,7 +60969,40 @@
         "adequate": false,
         "gap": "A.5.15 access-control policy is bypassed at the application layer: the flaw grants unauthenticated access to restricted device-management functions, so documented role/authentication rules provide no barrier to the API paths CVE-2023-35078 exposes."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "EPMM's device-management API is where this product makes its authentication decision, and this CVE is that decision missing on specific paths: a remote caller with no credential reaches device and user PII and the functions that change configuration, install software, and alter security profiles on managed devices. Bound to this product, the control means each EPMM device-management function authorizes its own caller rather than inheriting a verdict from whatever fronts the API, and no EPMM instance is left with that API surface reachable from a segment with no operational need to reach it — which for an internet-facing MDM server is the difference between a bounded population and the whole internet. This is why the identity-side gaps recorded on this entry cannot be closed by tightening accounts: the attacker never authenticates as any EPMM operator, so per-account privilege scoping is never consulted and the account model an access-control attestation examines is bypassed rather than abused. Distinguishing test: from an untrusted network, issue unauthenticated requests to each device-management API path on a staging EPMM instance and confirm each is refused before the function runs — an attestation that every EPMM administrator authenticates at login passes cleanly while this path stays open. Precondition: endpoint-side authentication is a property the vendor upgrade establishes; this control states what to verify, it does not implement it. Until 11.8.1.1 / 11.9.1.1 / 11.10.0.2 is running, restricting which segments can reach the API bounds who can send the request but leaves the path fully exploitable from inside the permitted segment, and it is unavailable where the API must stay reachable for enrolled devices to check in. Scope it to EPMM: the packet ties this flaw to EPMM's device-management API and gives no mapping into other products.",
+        "evidence": "The packet's affected field records Ivanti EPMM (formerly MobileIron Core) as failing to authenticate specific device-management API paths, allowing unauthenticated access to PII and configuration functions, under CWE-287. attack_vector: a remote unauthenticated attacker requests specific EPMM API paths that fail to enforce authentication, gaining device/user PII and the ability to change configuration, install software, and alter security profiles on managed devices. The UK-CAF-B2 gap names the bypassed paths as /mifs/aad/api and states B2's account-management controls never engage against an actor who bypasses auth entirely; the ISO-27001-2022-A.5.15 gap states the access-control policy is bypassed at the application layer; the NIS2-Art21-vulnerability-management gap states the preauth bypass reaches EPMM device-management APIs with no credentials. CVSS 9.8, RWEP 72, poc_available true, KEV-listed 2023-07-25.",
+        "gap_closes": [
+          "UK-CAF-B2",
+          "ISO-27001-2022-A.5.15",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the KEV clock is what replaces a monthly application-patch cadence on an internet-facing MDM server. The packet records mass exploitation after disclosure, so every EPMM instance has to be driven to 11.8.1.1, 11.9.1.1 or 11.10.0.2 (or later) against the 2023-07-25 listing rather than the organisation's normal cycle. Two product-specific points govern how completion is measured. There is no live-patch path, and the packet records the fix as a service update rather than a host reboot — so completion is the version the running EPMM service reports, not a host-reboot record and not an 'approved' or 'downloaded' state in a management console. And the consequence of missing the clock is understated by this CVE alone: the packet records CVE-2023-35081 chaining with this bypass for web-shell RCE, so an instance still below the fixed build after the listing is exposed to the full chain rather than to information disclosure only. Sequence the estate by internet reachability first, since that is the condition the observed mass exploitation required.",
+        "evidence": "patch_available true, live_patch_available false; live_patch_notes state remediation requires upgrading Ivanti EPMM to 11.8.1.1, 11.9.1.1, or 11.10.0.2 (or later), 'a service update rather than a host reboot', and patch_required_reboot is false. active_exploitation confirmed; KEV date 2023-07-25 with ransomware use recorded ('Known'); active_exploitation_notes record mass exploitation after disclosure and that it is commonly chained with CVE-2023-35081 for web-shell RCE. The AU-Essential-8-Patch gap describes EPMM as an internet-facing identity/MDM server; the NIST-800-53-SI-2 gap describes flaw-remediation timelines losing the race.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "EPMM is the fleet control plane, and the packet records this flaw being used as a zero-day to breach twelve Norwegian government ministries before a fix existed — which is precisely the case where reaching the fixed build closes the entry path and removes nothing behind it. The playbook's scope for this CVE is therefore the managed fleet and not just the server, because the packet puts the attacker's reach at configuration change, software installation, and security-profile alteration on managed devices: audit configuration profiles and pushed software back to the start of the suspected exposure window rather than to the disclosure date, invalidate device trust state, rotate credentials for accounts that authenticated through the platform during that window, and set quarantine criteria for downstream devices that received changes inside it. For any instance that was internet-reachable, assume the CVE-2023-35081 chain the packet names and hunt for a web shell, which the upgrade does not remove. Precondition: this depends on retaining EPMM configuration-change and API-access history far enough back to cover a pre-disclosure window — an organisation whose retention starts at the KEV listing cannot answer the question the playbook asks, and the playbook does not prevent the compromise; it bounds what an already-breached fleet inherits.",
+        "evidence": "active_exploitation_notes record the flaw as exploited as a zero-day to breach twelve Norwegian government ministries in mid-2023, with a CISA/NCSC-NO joint advisory, and as commonly chained with CVE-2023-35081 for web-shell RCE. The NIST-800-53-SI-2 gap states the 0-day was used before a patch existed, so flaw-remediation timelines gave no protection during the exploitation window that started before 2023-07-25; the AU-Essential-8-Patch gap states that even a fast patch left exposure for organisations already breached in the pre-disclosure period. attack_vector records the attacker's reach as device/user PII plus configuration change, software installation, and security-profile alteration on managed devices.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-29298": {
     "name": "Adobe ColdFusion Improper Access Control Vulnerability (CVE-2023-29298)",
@@ -60112,7 +61828,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)",
@@ -60524,7 +62273,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)",
@@ -60935,7 +62709,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management ranks by CVSS/EPSS, but a targeted spyware zero-day like this bypasses that triage entirely — the risk was active before the CVSS 8.8 score or KEV entry existed, so only rapid device-wide patch enforcement reduced exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Scope this from affected_versions, not from the vector's headline: the packet places the out-of-bounds write in WebKit itself and records four separate completion lines — iOS/iPadOS at 16.4, iOS/iPadOS at 15.7.7 on the older track, macOS at Ventura 13.3, and Safari at 16.4. Because the packet describes WebKit as reached through Safari and through any product that embeds WebKit for HTML processing, a Mac whose OS build is current while Safari sits below 16.4, or an iPad held on the 15.x track that never took 15.7.7, is still executing the vulnerable engine regardless of which application the user opened; an estate standardised on one of those lines and swept only on that line reports clean while the others stay exposed. The requirement is that the update is pushed and completed against the KEV clock that opened 2023-06-23 with user deferral disallowed, because the packet's attack vector is processing crafted web content and needs no action from the user beyond rendering it. Measurement is the load-bearing half: live_patch_available is false and the packet states the fix installs via a device update and reboot, so a device that has downloaded the update but not restarted is still running pre-fix WebKit — completion is the build the device reports after restart, never 'available', 'downloaded' or 'approved' in the management console. Distinguishing test: hold a device below the fixed build for its line and confirm the console both flags it and forces the update without allowing the user to defer — an estate that surfaces stale builds on a patch-compliance report while users defer indefinitely has recorded the exposure rather than removed it. Finally, because active_exploitation is confirmed and delivery is attacker-controlled web content, a device in scope that rendered untrusted content before it reached the fixed build belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-06-23; active_exploitation confirmed; RWEP 72 against CVSS 8.8; poc_available true. affected_versions enumerates four lines — Apple iOS/iPadOS < 16.4, Apple iOS/iPadOS < 15.7.7, macOS < Ventura 13.3, Apple Safari < 16.4 — and affected identifies the flaw as being in Apple WebKit, reached through Safari and any product embedding WebKit for HTML processing. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes recording no vendor live-patch mechanism and remediation as updating to iOS/iPadOS 16.4 (or 15.7.7), macOS Ventura 13.3 and Safari 16.4, installed via a device update and reboot. The AU-Essential-8-Patch gap states mobile fleets often lack MDM-enforced same-day OS updates, so the zero-click WebKit RCE remained live on devices that had not taken the iOS 16.4 / 15.7.7 update; the NIS2-Art21-patch-management gap states the obligation rarely enforces same-week mobile OS updates on user devices, leaving unpatched iPhones and Macs on slow update tracks exploitable for the whole delay.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "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 does not describe a standalone browser bug: it places this out-of-bounds write as the WebKit stage of the Operation Triangulation spyware chain, chained with a kernel bug for zero-click device takeover, and records Apple's note that exploitation may have run against iOS releases predating 15.7 — that is, before the fixed builds existed. For the population plausibly inside that targeting set, the reboot-gated update therefore cannot be the whole answer, because the exposure ran during a window no patch cadence could have shortened. The requirement is a standing reduced-attack-surface posture on the iPhones, iPads and Macs assigned to that cohort, in which crafted web content and link previews are not automatically fed through the full WebKit rendering path, narrowing the delivery route into the CWE-787 primitive during the interval before the device reaches iOS/iPadOS 16.4 or 15.7.7, macOS Ventura 13.3 and Safari 16.4 and restarts onto them. Precondition, and this is where the control is most often over-claimed: the posture reduces exposure only if it was already enabled when the content arrived, so assigning it in response to the 2023-06-23 KEV listing does nothing for the pre-listing exploitation the packet describes — it has to be a cohort assignment made before the next disclosure. It does not remove the WebKit sink, which only the fixed build and its restart do, and it does not evict an implant already resident on a device compromised earlier in the chain; a cohort device suspected of having rendered the chain is an incident, not a hardening item.",
+        "evidence": "Packet: active_exploitation_notes state the issue formed the WebKit stage of the Operation Triangulation spyware chain used for targeted, zero-click device compromise, and that Apple noted it may have been actively exploited against versions of iOS released before iOS 15.7; attack_vector records that processing maliciously crafted web content triggers the out-of-bounds write in WebKit, giving arbitrary code execution in the browser/WebContent process, chained with a kernel bug for zero-click device takeover. cwe_refs CWE-787; active_exploitation confirmed; kev_date 2023-06-23. patch_required_reboot true and live_patch_available false, with live_patch_notes recording no vendor live-patch mechanism. The UK-CAF-B4 gap states that CAF B4 assumes the browser sandbox contains malicious web content and that system-security baselines had no compensating control once the WebContent process itself was the code-execution surface; the ISO-27001-2022-A.8.8 gap states that CVSS/EPSS-ranked triage was bypassed entirely because the risk was active before the CVSS 8.8 score or KEV entry existed.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-32439": {
     "name": "Apple Multiple Products WebKit Type Confusion Vulnerability (CVE-2023-32439)",
@@ -61088,7 +62886,30 @@
         "adequate": false,
         "gap": "A.5.15 access control is scoped to the guest OS, but this flaw executes below it at the Tools/vgauth layer, so guest-level RBAC and logon controls cannot see or stop the host-to-guest operations until the fixed Tools release is installed."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "The packet makes ESXi host root the entire precondition for this VMware Tools flaw: the attacker must already hold root on the ESXi host, and from there the Tools vgauth module executes host-initiated operations inside guests with no guest credential presented. That makes the hypervisor a control plane over every workload running on it, and it is why the guest is the wrong place to defend this — the operation never presents a guest credential, so guest RBAC, guest logon policy and any MFA layered inside the guest are never consulted and never see it. Applied to a virtual estate, the control means ESXi and vCenter administration is classified as a privilege tier above the guest and application admin roles that guest-scoped access attestations examine: separate identities from any other admin role, access only through a PAM jumphost, hardware-bound step-up per session, and just-in-time elevation with approval, so the credential that yields host root is materially harder to obtain than a guest administrator's. Distinguishing test: enumerate the accounts that can obtain root on an ESXi host today and show that none is an ordinary guest or application administrator account and none can reach the host outside the privileged path — an estate that passes guest-OS access-control review while a shared administrator account can reach ESXi has left this CVE's precondition intact. Precondition, stated plainly: this bounds who can reach the position the packet describes the attacker operating from; it does nothing on a host where root is already held, where the flaw stays fully exploitable against every guest until each guest reaches the fixed VMware Tools build and takes the reboot. An estate that suspects ESXi root was held during the exposure window belongs on the incident path, not the hardening path.",
+        "evidence": "Packet affected: the VMware Tools vgauth module improperly authenticates host-initiated guest operations (CWE-287), letting a root-compromised ESXi host run commands and transfer files inside guests without guest credentials. active_exploitation_notes: used by the Chinese-nexus espionage group UNC3886 as a post-compromise technique against ESXi/vCenter estates, and 'it requires the attacker to already hold root on the ESXi host, so it is a lateral/persistence primitive (host into guest) rather than an initial-access vector'. The NIST-800-53-IA-2 gap states guest-side identity assurance is silently voided until VMware Tools 12.2.5 is deployed; the ISO-27001-2022-A.5.15 gap states the flaw executes below the guest OS at the Tools/vgauth layer so guest-level RBAC and logon controls cannot see or stop the host-to-guest operations; the UK-CAF-B2 gap states an attacker who owns ESXi root can operate inside every guest without triggering guest access controls; the NIS2-Art21-identity-management gap states MFA and identity policy inside the guest never sees the host-driven operation. cisa_kev true (2023-06-23), active_exploitation confirmed.",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B2",
+          "NIS2-Art21-identity-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The Essential Eight gap on this entry names the failure precisely: a 3.9 base score is deprioritised by a cadence-scored patch program while the packet records a KEV-listed, confirmed nation-state guest-execution primitive. For this CVE the KEV clock that opened 2023-06-23 runs against the guests rather than the hosts — every guest running VMware Tools 12.x below 12.2.5, and every guest on 11.x or 10.3.x, Windows and Linux both per the packet's affected versions, has to reach the fixed build for its branch. The packet names 12.2.5 for the 12.x Windows track and records only 'the fixed builds' for 11.x and 10.3.x, so those levels must be taken from the vendor advisory rather than assumed from the 12.x number. Completion is measured per guest on the Tools build the guest is actually running after the reboot the packet says the upgrade typically requires — not on the ESXi host's patch level, and not on a 'deployed' state in the virtualization console; a guest whose Tools package was pushed but which has not rebooted is still executing the vulnerable vgauth code and must be counted as exposed. Sequencing should follow the value of what each guest holds rather than the CVSS band, because the packet frames this as the lateral step taken after the hypervisor falls rather than as a standalone endpoint item. Precondition: live_patch_available is false and the packet records no vendor live-patch mechanism, so nothing here is available faster than the per-guest upgrade and its restart — an estate that cannot reboot a guest inside the window has an exposure to record, not a mitigation.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-06-23, active_exploitation confirmed, cvss 3.9, rwep_score 63, poc_available true. patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes 'No vendor live-patch mechanism; remediation is upgrading VMware Tools to 12.2.5 (or the backported fixed build) on each guest, which typically requires a guest OS reboot to complete'. affected_versions: 'VMware Tools 12.x prior to 12.2.5 (Windows)' and 'VMware Tools 11.x and 10.3.x (Windows/Linux) prior to the fixed builds'. The AU-Essential-8-Patch gap states that because exploitation needs prior ESXi root, orgs commonly deprioritise a 3.9 CVE, 'leaving a confirmed nation-state guest-execution primitive unpatched on virtual estates well past KEV listing'. active_exploitation_notes attribute post-compromise use to UNC3886 and describe the flaw as a lateral/persistence primitive (host into guest).",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-27992": {
     "name": "Zyxel Multiple NAS Devices Command Injection Vulnerability",
@@ -61303,7 +63124,29 @@
         "adequate": false,
         "gap": "A.8.28 secure coding should have caught the unescaped handling of link-reference content in rcube_string_replacer.php; the defect shipped in the renderer, so the control failed at the source level and left every unpatched tenant exposed to script-on-open."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For self-hosted Roundcube the fixed builds already existed when CISA listed this on 2023-06-22, so the \"whichever is later\" clock this control sets starts at the KEV listing and the remaining work is entirely deployment, not waiting on a vendor. Bound to this product it means every Roundcube instance in the estate — including any the software inventory does not already enumerate — is moved onto the fixed point release for the branch it runs: 1.4.10 for the 1.4.x train, 1.3.16 for 1.3.x, 1.2.13 for anything older, or later. The packet records the upgrade as a package update with no host reboot, which is not the same as the fix being live: completion has to be measured on the Roundcube version the webmail service is actually serving on each host, not on a package manifest or a closed change ticket. Precondition, and it is the limit of what this control buys: it governs deployment speed only and gives nothing to an instance during the window before the upgrade lands, since the payload arrives as an ordinary plain-text message and fires when a user opens it — there is no user-behaviour instruction that helps. And because exploitation is confirmed and the packet records APT28 (BlueDelta) using this to steal messages and credentials from government webmail servers, a server that ran an affected build during that period is an incident-triage question; mail and credentials already read out of a mailbox stay compromised after the upgrade and need rotation, not closure on the patch record.",
+        "evidence": "Packet facts only: cisa_kev true with kev_date 2023-06-22 and active_exploitation confirmed; poc_available true; patch_available true with patch_required_reboot false; live_patch_available false, with live_patch_notes stating remediation is \"upgrading Roundcube to 1.4.10 / 1.3.16 / 1.2.13 (or later), a package update with no host reboot\"; affected_versions listing Roundcube Webmail < 1.2.13, 1.3.x < 1.3.16, 1.4.x < 1.4.10. The AU-Essential-8-Patch gap states the fixed builds \"existed but were not applied, leaving the on-open XSS exploitable during the APT28 campaign\", and the NIS2-Art21-patch-management gap states many installs ran versions before 1.4.10/1.3.16/1.2.13 \"well past disclosure\" with APT28 exploiting that lag around the 2023-06-22 KEV listing. The delivery description (plain-text email whose script runs in the Roundcube origin when the victim opens the message, enabling mailbox theft) and the APT28/BlueDelta message- and credential-theft attribution are both taken from the packet's attack_vector and active_exploitation_notes.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "This CVE breaks single-number version checking, which is exactly the paper-compliance shape the control names. Roundcube's fix landed on three maintained branches at three different version numbers — 1.2.13, 1.3.16 and 1.4.10 — so a check that compares an installed version against one \"current\" figure is wrong in both directions: a host on 1.3.15 sorts newer than 1.2.13 and passes while still carrying the vulnerable linkref_addindex path, and a correctly-remediated 1.2.13 host sorts older than 1.4.10 and produces a false finding that consumes the remediation effort the first host needed. The operational test for this entry is branch-aware: resolve each install's release train first, compare it against that train's fixed point release, and take the version from what the running webmail service serves rather than from a package manifest — the packet records this remediation as a package update with no host reboot, so nothing forces the served version and the recorded version to agree. Precondition: this verifies only the installs the scan can see. A Roundcube copy that no inventory enumerates is not made compliant by a clean result across the ones that are, and the packet's own gap text — that self-managed Roundcube servers frequently run outdated point releases while the fixed builds sat available — describes precisely that unenumerated population.",
+        "evidence": "Packet facts only: affected_versions gives the three branch-specific boundaries (< 1.2.13, 1.3.x < 1.3.16, 1.4.x < 1.4.10) and live_patch_notes gives the three corresponding fixed targets (1.4.10 / 1.3.16 / 1.2.13 or later) as a package update with no host reboot; patch_required_reboot is false and live_patch_available is false. The AU-Essential-8-Patch gap records that self-managed Roundcube servers frequently run outdated point releases and that the fixed builds existed but were not applied; the NIS2-Art21-patch-management gap records installs running pre-fix versions well past disclosure. The vulnerable code path named in the vector is linkref_addindex in rcube_string_replacer.php. No version, date or build not present in the packet is used.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2020-12641": {
     "name": "Roundcube Webmail Remote Code Execution Vulnerability",
@@ -61517,7 +63360,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",
@@ -61578,7 +63443,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management requires identifying and patching the vulnerable Win32k component across a mixed Windows estate; the 2023 KEV listing of a 2016 flaw shows the control failing where asset inventory misses legacy or unsupported Windows versions still carrying the bug."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this defect in the Microsoft Windows Win32k kernel-mode driver and describes a crafted application running arbitrary code in kernel mode to escalate a local low-privileged or sandboxed process to SYSTEM (CWE-269) — the attacker is already executing on the host, so no account model is being abused; a kernel privilege boundary is failing. For this CVE the control means MS16-039 is driven across every host running one of the builds the packet names — Windows Vista SP2, Server 2008 SP2 and R2 SP1, 7 SP1, 8.1, Server 2012 Gold and R2, RT 8.1, and Windows 10 Gold and 1511 — on the clock that opened with the 2023-06-22 KEV listing rather than folded into a routine cycle, with completion measured by each host's installed build against the fixed one rather than by 'approved' or 'downloaded' in the update console. The packet records no live-patch path and states the update installs through Windows Update and requires a reboot to load the fixed kernel-mode driver, so a host that has taken MS16-039 but has not rebooted is still executing the vulnerable driver and must be counted as exposed; on a shared or multi-user server that reboot 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 the load-bearing one here: because the escalation runs from code the attacker is already executing, tightening user rights does not contain it, which is exactly why the least-privilege control cited on this entry can pass its attestation while the flaw stays fully exploitable. Priority follows the packet rather than the score bands — poc_available is false and the packet notes no clearly public per-CVE exploit exists for this identifier, yet exploitation is confirmed and KEV-listed, and the packet describes this class as the escalation step chained after initial code execution, making it a containment step for a chain rather than a standalone endpoint item.",
+        "evidence": "Packet: CWE-269 in the Microsoft Windows Win32k kernel-mode driver; attack_vector — 'A crafted application exploits a flaw in the Win32k kernel-mode driver to run arbitrary code in kernel mode, escalating a local low-privileged or sandboxed process to SYSTEM'. cisa_kev true, kev_date 2023-06-22, active_exploitation confirmed; poc_available false, with active_exploitation_notes stating 'No clearly public per-CVE exploit exists for this identifier' and that such Win32k EoP bugs are 'chained after initial code execution (e.g. a document or browser exploit)'. patch_available true, live_patch_available false, patch_required_reboot true, live_patch_notes: 'No live-patch mechanism; remediation requires installing Microsoft security update MS16-039 (April 2016) via Windows Update, which requires a reboot to load the fixed kernel-mode driver.' CVSS 7.8, RWEP 49. affected_versions: 'Windows Vista SP2, Server 2008 SP2 / R2 SP1, 7 SP1, 8.1, Server 2012 Gold & R2, RT 8.1, and 10 Gold & 1511 before MS16-039'. The NIST-800-53-AC-6 gap records that 'restricting user rights does not contain an attacker who has already achieved initial execution until MS16-039 is applied'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-AC-6"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "patch_available is true — MS16-039 exists for the Windows builds this packet names — but the packet's own gap statements put a large part of the affected population outside any supported patch stream: the Essential Eight gap records 'the risk of running end-of-support Windows' and that unsupported hosts fail the control, and the technical-vulnerability-management gap reads the 2023 KEV listing of a 2016 flaw as asset inventory missing 'legacy or unsupported Windows versions still carrying the bug'. Those two facts together define the requirement for this CVE. On a host whose Windows version still receives security updates, installing MS16-039 and taking the reboot is an interim state. On a host running a version that no longer receives them, MS16-039 closes this one Win32k defect while the machine remains exposed to every kernel flaw found since that build shipped, so the terminal state is rebuild onto a supported version or removal — and a requirement that ends at 'every host reports MS16-039 installed' marks such a machine compliant while it stays exposed. In operational terms: enumerate every host running one of the builds the packet names (Vista SP2, Server 2008 SP2 and R2 SP1, 7 SP1, 8.1, Server 2012 Gold and R2, RT 8.1, Windows 10 Gold and 1511), record for each its running build and a support status obtained from the vendor rather than assumed in either direction, put the still-supported ones on the KEV clock that opened 2023-06-22, and put the rest on a dated replacement schedule; a risk acceptance with no removal date leaves a confirmed-exploited local-to-SYSTEM escalation primitive in service indefinitely. Precondition: this is an inventory-and-schedule control and it reaches only hosts the inventory can see — the packet's own framing, a 2016 flaw KEV-listed in 2023 because inventories missed legacy Windows, is the evidence that this is where it fails. A host absent from the inventory is neither patched nor scheduled, and hardening it is not a substitute: the packet's system-security gap records that a Win32k kernel bug bypasses user-mode sandboxes, so application-layer hardening on a build that no longer receives kernel fixes does not stop the escalation.",
+        "evidence": "Packet framework_control_gaps, AU-Essential-8-Patch: 'the exploited window shows the risk of running end-of-support Windows: MS16-039 must be applied, and unpatched or unsupported hosts fail the control precisely where a browser/document exploit would chain into this EoP.' ISO-27001-2022-A.8.8: 'the 2023 KEV listing of a 2016 flaw shows the control failing where asset inventory misses legacy or unsupported Windows versions still carrying the bug.' NIS2-Art21-patch-management: 'legacy or unpatched Windows (Vista/7/8.1/Server 2008-2012) in essential-entity estates stayed vulnerable to SYSTEM takeover.' UK-CAF-B4: 'a Win32k kernel bug bypasses user-mode sandboxes; without the MS16-039 kernel patch, hardening the application layer does not stop escalation to kernel-mode SYSTEM.' patch_available true with live_patch_available false and patch_required_reboot true; cisa_kev true, kev_date 2023-06-22, active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-27997": {
     "name": "Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow Vulnerability",
@@ -62236,7 +64125,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)",
@@ -62382,7 +64304,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",
@@ -63275,7 +65229,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",
@@ -64340,7 +66317,42 @@
         "adequate": false,
         "gap": "A.8.8 vulnerability management often lacks a fast lane for mobile OS CVEs, but this actively-exploited kernel out-of-bounds write in a spyware chain demanded emergency device updates that a routine mobile-patch schedule would not deliver in time."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "The operationally load-bearing detail for this CVE is that there is no single fixed build to enforce: the packet names iOS/iPadOS 16.4.1 or 15.7.5, macOS Ventura 13.3.1, Monterey 12.6.5 and Big Sur 11.7.6, so a KEV-clock policy has to compare each device against the fixed build for the branch that device can actually run. An estate that measures compliance against 16.4.1 and 13.3.1 alone reports the older iPhones offered only 15.7.5 and the Macs on Monterey and Big Sur as out of scope while they stay exploitable to a kernel-privilege out-of-bounds write. Second: patch_required_reboot is true and there is no live-patch path, so a device that has downloaded the update but not restarted is still executing the vulnerable kernel code — user deferral of that restart is the specific mechanism by which the dashboard reads patched while the device is not, which is why deferral has to be disallowed rather than shortened. Measure completion on the build the device is running, per branch, against the 2023-04-10 listing. Scope to the products the packet names — iOS, iPadOS and macOS — rather than to every Apple platform in the estate.",
+        "evidence": "live_patch_notes name the fixed releases as iOS/iPadOS 16.4.1 or 15.7.5, macOS Ventura 13.3.1, Monterey 12.6.5 and Big Sur 11.7.6, and record that they reboot the device to apply; patch_required_reboot is true and live_patch_available false. affected_versions list the same five branches. affected: Apple IOSurfaceAccelerator on iOS, iPadOS and macOS, an out-of-bounds write (CWE-787) letting a malicious app execute code with kernel privileges. KEV date 2023-04-10, active_exploitation confirmed, CVSS 8.6, RWEP 70. The AU-Essential-8-Patch gap names a 48-hour target for actively-exploited critical flaws that is hard to meet on a BYOD Apple fleet; the NIS2-Art21-patch-management gap records that mobile patch management rarely enforces same-day OS updates.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "This entry's own gaps name a BYOD Apple fleet and mobile update policies that do not enforce same-day OS updates — populations where an update cannot be compelled, and where the fixed build therefore has to function as an access condition rather than as a row on a patch report. For this CVE that means mail, VPN and document access are denied to any device below the fixed build for its branch (16.4.1 or 15.7.5 on iOS/iPadOS; 13.3.1, 12.6.5 or 11.7.6 on macOS), on the reasoning that a device carrying a kernel-privilege out-of-bounds write cannot be trusted to hold organisational data. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it protected resources; an estate that surfaces the stale build on a report while the device keeps its access has recorded the exposure rather than removed it. Precondition, and this is where this control is normally over-claimed: its install-restriction half does not cover this CVE's observed delivery path. The packet reaches the IOSurfaceAccelerator operations from an app context obtained through an initial WebKit content-process compromise (CVE-2023-28205), not from a side-loaded application, so restricting untrusted installation neither prevents that path nor evicts code already running. This is a holding measure for the window before the fixed build and its reboot land, not a substitute for them.",
+        "evidence": "The AU-Essential-8-Patch gap names a BYOD Apple fleet where a 48-hour target for actively-exploited critical flaws is hard to meet; the NIS2-Art21-patch-management and ISO-27001-2022-A.8.8 gaps record that routine mobile schedules and NIS2 patch management do not deliver the emergency device updates this entry demanded. attack_vector: a malicious app performs crafted IOSurfaceAccelerator operations that trigger an out-of-bounds write in the kernel, and in the observed campaign it escalated privileges after an initial WebKit content-process compromise (CVE-2023-28205). Fixed builds per live_patch_notes: iOS/iPadOS 16.4.1 or 15.7.5, macOS Ventura 13.3.1, Monterey 12.6.5, Big Sur 11.7.6; patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet places this bug as the kernel-privilege-escalation link of a commercial-surveillance chain against iPhones and Macs, reached after an initial WebKit content-process compromise — which has two consequences for the estate. The app sandbox is the containment boundary the deployment leans on, and this out-of-bounds write is precisely what breaks it, so there is no sandbox-hardening or MDM-configuration setting that contains the flaw before the fixed build. And a reboot-gated OS update is not fast enough on its own for the population plausibly inside a targeted-surveillance targeting set. What remains is narrowing what content is processed automatically: place that cohort in the vendor's reduced-attack-surface mode so untrusted web content, message attachments and link previews are not rendered without action, cutting the delivery path into the kernel primitive during the window that ran before Apple's 2023-04-07 fix and continued on each device until it took 16.4.1, 15.7.5, 13.3.1, 12.6.5 or 11.7.6 and restarted. Preconditions, both load-bearing: the mode only helps if it was already the standing posture when the chain arrived, so it must be assigned to the high-risk cohort before the next disclosure rather than in response to this KEV listing; and it narrows delivery rather than removing the kernel defect, which only the fixed build and its restart do. A device in the targeted set that processed untrusted content during the window belongs on the incident path — kernel-privilege code execution is not undone by the later update.",
+        "evidence": "active_exploitation_notes describe the flaw as actively exploited as part of a commercial-surveillance exploit chain against iPhones and Macs, as the kernel-privilege-escalation link reached after an initial WebKit content-process compromise (CVE-2023-28205), giving the spyware full-device control; CISA added it to KEV 2023-04-10. The UK-CAF-B4 gap states the app sandbox is the containment boundary, that the IOSurfaceAccelerator out-of-bounds write breaks out of it to kernel code execution, and that MDM hardening alone cannot stop it pre-patch. The NIST-800-53-SI-2 gap records the spyware zero-day as live before Apple's 2023-04-07 fix. patch_required_reboot true; live_patch_available false; fixed builds per live_patch_notes.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-27876": {
     "name": "Veritas Backup Exec Agent File Access Vulnerability",
@@ -64485,7 +66497,29 @@
         "adequate": false,
         "gap": "A.5.15 access control presumes only authenticated principals reach the agent, but the retained SHA scheme granted privileged command execution to anyone who spoke the legacy protocol, so the access-control boundary never actually held for this service."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For the Veritas Backup Exec Agent the remediation the packet records is the upgrade to Backup Exec 21.2, which disables the deprecated SHA authentication scheme, and the clock to run it against is the 2023-04-07 KEV listing rather than the routine application-patch cycle a backup agent normally sits inside. The population to enumerate is every host running the Backup Exec Agent, not only the media server, because the agent is the component that accepts the handshake. Completion has to be measured on the Backup Exec version the agent process is actually executing: the packet records patch_required_reboot false, so there is no machine reboot to schedule, but that does not mean the fix is live on install — the packet's own live_patch_notes require restarting the agent service, and until that restart the running agent still answers the SHA scheme. A host where the 21.2 upgrade is staged or installed but the agent service has not been restarted is still exploitable and must not be counted as remediated. Because live_patch_available is false there is no mechanism to hold the exposure in the interim, so the reachability restriction is the only cover between the KEV listing and the completed restart.",
+        "evidence": "KEV-listed 2023-04-07 with active_exploitation confirmed, poc_available true, CVSS 9.8 and RWEP 72. The packet records disclosure by Veritas in March 2021 but broad exploitation from late 2022, with Mandiant attributing a campaign (UNC4466) that used a Metasploit module against internet-exposed Backup Exec agents to deploy ALPHV/BlackCat ransomware, and the KEV entry carrying a Known-ransomware flag. patch_available is true for versions before 21.2; live_patch_available is false; patch_required_reboot is false; live_patch_notes states remediation requires upgrading to 21.2 (which disables the deprecated SHA authentication scheme) and restarting the agent service. The AU-Essential-8-Patch gap records that patch-applications maturity did not compel rapid upgrade of a backup agent, and the NIS2-Art21-patch-management gap records that patch management deprioritized a backup-infrastructure agent so exposed agents remained a pre-auth foothold at the KEV listing.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "Applied to this product, the control means the Backup Exec Agent's listener answers only from the media servers with an operational need to drive it, on a backup segment — not from the internet, and not from a general user VLAN — because the packet places the observed campaign specifically against internet-exposed Backup Exec agents. This is the operator-side access boundary that remains while the agent still accepts the deprecated scheme, and it is the half an access-control attestation misses: the account model is never consulted, so a review confirming every backup operator holds a unique authenticated account passes cleanly while the agent grants privileged command execution to anyone who speaks the legacy protocol. Precondition, and it is the whole limit of this control: restricting reachability bounds the population that can complete the SHA handshake, it does not repair the authenticator. Any host already inside the permitted segment — a compromised media server, an administrative workstation with a route to the backup VLAN — still reaches the agent and still authenticates with no credential, so this is a holding measure for the window before the 21.2 upgrade and its agent-service restart, not a closure. Distinguishing test: from a general user VLAN and from an external address, attempt to open the agent's listener on a staging host; anything that answers is within reach of the published module, and \"the backup network is internal\" is an assertion about topology rather than a demonstration that the agent is unreachable from untrusted segments.",
+        "evidence": "The packet's affected field states the Backup Exec Agent continued to accept the deprecated SHA authentication scheme, letting a remote attacker authenticate without valid credentials and run privileged commands, and the attack_vector has an unauthenticated attacker completing that handshake to gain agent access and execute privileged commands on the host. active_exploitation_notes name internet-exposed Backup Exec agents as the targets of the UNC4466 campaign. The ISO-27001-2022-A.5.15 gap records that access control presumes only authenticated principals reach the agent, but the retained SHA scheme granted privileged command execution to anyone who spoke the legacy protocol, so the access-control boundary never actually held for this service; the UK-CAF-B2 gap records that identity-and-access control assumes agents enforce a robust auth scheme, yet the legacy scheme let attackers authenticate as trusted. live_patch_available is false, so no vendor mechanism covers the interval before the 21.2 upgrade and agent-service restart.",
+        "gap_closes": [
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2021-27878": {
     "name": "Veritas Backup Exec Agent Command Execution Vulnerability",
@@ -64874,7 +66908,31 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management must track legacy-browser exposure across the estate; the 2023 KEV listing of a 2013 IE flaw shows the control failing where inventory misses hosts still running unpatched Internet Explorer 8."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet states the remediation and its preferred terminal form in the same breath: install Microsoft cumulative update MS13-055 via Windows Update, which requires a reboot, or preferably retire legacy Internet Explorer in favour of a supported browser. That is exactly the interim/terminal split this control exists for. MS13-055 fixes the CAnchorElement use-after-free in mshtml, but a host still rendering untrusted web content in Internet Explorer is exposed to everything found in that engine since 2013 — which is what a 2013 flaw appearing on the KEV list in 2023 as a still-relevant exploited flaw for legacy IE deployments is telling operators. Scope the inventory to what the affected versions name: Internet Explorer 8 through 10 before MS13-055. The gap prose speaks of IE 8, but the affected range covers 9 and 10 as well, and a sweep written against IE 8 alone reports an estate clean while its IE 9 and IE 10 hosts stay exploitable by the same crafted page. Per host, record the Internet Explorer version in service, whether MS13-055 or a later cumulative update carrying it has been installed and the machine has restarted onto it, and a dated replacement date for the browser itself; a requirement that ends at 'every host reports the fixed build' marks a browser nobody maintains as compliant while it keeps rendering attacker-controlled content. Precondition: patch_required_reboot is true and live_patch_available is false, so a host that took the update but has not restarted is still executing the vulnerable mshtml code and cannot be counted as remediated. And because exploitation is confirmed through crafted web pages with a public Metasploit module, a host that browsed untrusted content while exposed belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet live_patch_notes: 'No live-patch mechanism; remediation requires installing Microsoft cumulative update MS13-055 via Windows Update (reboot required) or, preferably, retiring legacy Internet Explorer 8 in favor of a supported browser'; patch_available true, patch_required_reboot true, live_patch_available false, poc_available true. affected_versions: 'Internet Explorer 8 through 10 before MS13-055'; affected describes the mshtml rendering engine where a CAnchorElement is freed while a stale reference is retained. active_exploitation_notes: exploited in the wild via crafted web pages when MS13-055 shipped in July 2013, a classic drive-by/watering-hole browser RCE, a public Metasploit module made weaponization trivial, and 'CISA added it to KEV on 2023-03-30 as a still-relevant exploited flaw for legacy IE deployments'. The AU-Essential-8-App-Hardening gap states that failing to disable or replace legacy IE left the CAnchorElement use-after-free reachable; the ISO-27001-2022-A.8.8 gap states the control fails where inventory misses hosts still running unpatched Internet Explorer; the UK-CAF-B4 gap states that without MS13-055 or retiring IE, endpoint hardening does not stop the drive-by execution; the NIST-800-53-SI-2 gap records the exposure persisting in old estates.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "For Internet Explorer the browser's security channel is Windows Update — the packet's remediation is the MS13-055 cumulative update installed that way — so whatever deferral an enterprise applies to its operating-system update rings is applied to a browser remote-code-execution fix, and there is no separate browser channel that bypasses the ring. This CVE shows what that costs: the packet records the flaw as already under active attack when MS13-055 shipped in July 2013, with a public Metasploit module making weaponization trivial, so each interval of ring deferral was an interval of drive-by exposure on an engine that executes attacker code in the user's context from a single crafted page with no further interaction. Applied here, the requirement is that an update carrying an Internet Explorer engine fix is not held in a pilot or broad ring beyond this control's deferral limit, and that the restart completing it is driven rather than left to the user — the packet records a reboot as required and no live-patch path, so an approved-and-downloaded state on the management console is not remediation. Precondition, and it is why this control cannot stand alone on this entry: an update ring only reaches hosts that still receive cumulative updates for the Internet Explorer version they run. A host on a build outside that path is a replacement item, not a deferral-policy item, and recording it as 'awaiting the next ring' hides the only action available for it.",
+        "evidence": "Packet live_patch_notes: remediation requires installing Microsoft cumulative update MS13-055 via Windows Update (reboot required); patch_available true, patch_required_reboot true, live_patch_available false. active_exploitation_notes: 'Microsoft disclosed CVE-2013-3163 as being exploited in the wild via crafted web pages when MS13-055 shipped in July 2013; it is a classic drive-by/watering-hole browser RCE. A public Metasploit module made weaponization trivial.' vector: Internet Explorer 8 through 10 allows remote attackers to execute arbitrary code via a crafted web site. The NIS2-Art21-patch-management gap states patch management assumes browser updates are applied promptly, that this flaw was exploited before MS13-055 was available, and that the residual gap is legacy IE that never received the cumulative update; the NIST-800-53-SI-2 gap states the flaw was already under active attack when the patch shipped and that unpatched hosts remained a reliable drive-by RCE target.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2017-7494": {
     "name": "Samba Remote Code Execution Vulnerability",
@@ -65080,7 +67138,30 @@
         "adequate": false,
         "gap": "A.8.28 secure coding is exactly what was missing — the username field parsed from a beacon should be treated as untrusted and output-encoded; its absence let a stored XSS in the teamserver UI reach code execution, which only the corrected Cobalt Strike release resolves."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-055",
+        "name": "SECURITY-TOOL-INTEGRITY-VERIFICATION",
+        "description": "The vulnerable asset here is the security team's own tooling: a Fortra (HelpSystems) Cobalt Strike teamserver, where a malformed username in a Beacon payload's configuration is rendered as HTML by the Java Swing UI (CWE-79) and, per the packet, is chainable to code execution on the teamserver itself. Bound to this product the control means two things. First, the teamserver is carried in the vulnerability-management inventory with the same SLA as any other privileged software rather than sitting outside it as operator tooling — it is the host that holds an engagement's payload configuration and the console its operators sit in front of. Second, because the packet records that the initial 4.7.1 fix was incomplete, the input handling is verified by test rather than inferred from a version string: this is the control's trust-anchor-inversion test, made concrete for this CVE as feeding a teamserver on a staging instance a Beacon whose username field carries markup and confirming the UI renders it as inert text. That test is the distinguishing one — an estate that records 'Cobalt Strike upgraded past 4.7' passes a patch attestation while a teamserver still on the incomplete first fix renders the injected markup exactly as before, and it is the only operator-side substitute for trusting that the vendor's encoding was written correctly, which the packet shows it was not on the first attempt. Note where the malicious input arrives: the packet's vector has the attacker inspect a Cobalt Strike payload and modify the username field in it, so the markup comes in through normal Beacon processing rather than through the console's login, and no authentication or network control in front of the operator UI sits on that path — a teamserver has to accept Beacon traffic to do its job. Precondition: remediation is the fixed release, and the packet records no live-patch mechanism and requires the teamserver service to be restarted; patch_required_reboot is false, which means no host reboot, not that the fix is live on deployment — a teamserver upgraded but not restarted is still executing the vulnerable rendering code.",
+        "evidence": "Packet vector: 'An XSS (Cross Site Scripting) vulnerability was found in HelpSystems Cobalt Strike through 4.7 that allowed a remote attacker to execute HTML on the Cobalt Strike teamserver. To exploit the vulnerability, one must first inspect a Cobalt Strike payload, and then modify the username field in the payload... to be malformed.' affected: 'a cross-site scripting flaw (CWE-79) lets a malformed username in a Beacon configuration render as HTML in the Swing-based UI, chainable to remote code execution on the teamserver.' affected_versions: 'Fortra/HelpSystems Cobalt Strike <= 4.7 (fixed in 4.7.1 and later)'. live_patch_notes: 'No live-patch mechanism; remediation requires upgrading to the fixed Cobalt Strike release (the out-of-band 4.7.1 update and subsequent fixes) and restarting the teamserver service — no host reboot is needed, but note the initial 4.7.1 fix was incomplete, so a fully-patched version is required.' patch_available true, patch_required_reboot false, live_patch_available false, poc_available true, cisa_kev true with kev_date 2023-03-30, active_exploitation confirmed, CVSS 6.1, RWEP 62. NIST-800-53-SI-10 gap: 'the teamserver did not validate/encode the attacker-controllable username field from beacon metadata before rendering it in the Swing UI, so a malformed username became executable markup'. ISO-27001-2022-A.8.28 gap: 'the username field parsed from a beacon should be treated as untrusted and output-encoded'.",
+        "gap_closes": [
+          "NIST-800-53-SI-10",
+          "ISO-27001-2022-A.8.28",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "This entry is the incomplete-patch case stated twice in its own packet: the remediation note records that the initial 4.7.1 fix was incomplete so a fully-patched version is required, and the vulnerability-handling gap records that teamservers considered 'patched' could still be exploitable until later fixes. Applied to this product, the control means a Cobalt Strike teamserver's record for this CVE cannot be closed on 'upgraded off 4.7' or on 'upgraded to 4.7.1' — the closure criterion is the running teamserver being on a release later than the incomplete first fix, and the item stays open and is re-checked against each subsequent Cobalt Strike release rather than treated as terminal at the first vendor response. The multiplier's operational effect for this entry is the priority inversion it corrects: a CVSS 6.1 cross-site scripting finding in a desktop Swing UI reads as a low-ranked item on a score-ordered queue, while the packet describes the same flaw as chainable to remote code execution on the teamserver, KEV-listed 2023-03-30 with confirmed exploitation and a public PoC, scoring RWEP 62 against that CVSS 6.1 — so the score-keyed queue is the specific mechanism by which this stays unremediated. Preconditions and limits: this control changes the ranking and the closure criterion; it does not remediate, and it gives nothing to a teamserver that has not yet been upgraded and restarted. And because exploitation is confirmed, a teamserver that processed Beacon traffic while running 4.7 or the incomplete first fix belongs on the incident path — upgrading it does not remove anything an attacker who reached code execution left on that host, and the operator credentials and payload configuration it held are rotated rather than inherited across the upgrade.",
+        "evidence": "Packet live_patch_notes: 'the initial 4.7.1 fix was incomplete, so a fully-patched version is required.' NIS2-Art21-vulnerability-management gap: 'NIS2 vulnerability management assumes a fix fully remediates, but Cobalt Strike's initial 4.7.1 patch for this XSS was incomplete, so teamservers considered \"patched\" could still be exploitable until later fixes — a reminder that KEV-listed (2023-03-30) issues need verification that the fix actually closes the vector.' AU-Essential-8-Patch gap: 'because the first fix (4.7.1) was incomplete and this is niche operator software, the window between the 2023-03-30 KEV date and a fully-remediated teamserver left the injection-to-RCE path exploitable.' affected: 'chainable to remote code execution on the teamserver'. CVSS 6.1 against rwep_score 62; poc_available true; cisa_kev true; active_exploitation confirmed.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2021-30900": {
     "name": "Apple iOS, iPadOS, and macOS Out-of-Bounds Write Vulnerability",
@@ -65141,7 +67222,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management depends on tracking OS versions across the Apple estate; unmanaged or slow-updating devices kept the KEV-listed GPU-driver kernel write exploitable well after Apple's October 2021 fix."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "Scope this to what the packet's affected and affected_versions fields name — iOS, iPadOS and macOS — and treat all three as one population on one clock, because a sweep aimed only at iPhones reports clean across a Mac estate carrying the same GPU-driver defect. The enforced targets are iOS/iPadOS 14.8.1 for devices held on the 14.x line, iOS/iPadOS 15.1 for devices that can take it, and the corresponding October 2021 macOS release (Big Sur 11.6.1 / Monterey 12.0.1 per HT212872); a compliance report that recognises only the latest major version leaves the 14.8.1 population invisible rather than remediated. Push the update by management policy on the clock that opened with the 2023-03-30 KEV listing, with user deferral disallowed, and measure completion on the build each device is actually running after its restart — the packet records patch_required_reboot true and no live-patch mechanism for the affected GPU/kernel component, so a device that has downloaded the update but not restarted is still executing the vulnerable driver and is not remediated. There is no interim vendor mitigation to fall back on: the escalation is reached by an application already running on the device, so nothing short of the fixed build and its restart removes it.",
+        "evidence": "CISA added CVE-2021-30900 to KEV on 2023-03-30 based on evidence of exploitation; active_exploitation is confirmed, CVSS 7.8, RWEP 50, and poc_available is false (the packet notes no standalone public PoC is known). 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 affected GPU/kernel component and that remediation requires the Apple OS update (iOS/iPadOS 14.8.1 or 15.1 and the corresponding macOS release), which requires a device restart. affected_versions list iOS/iPadOS < 14.8.1, iOS/iPadOS < 15.1, and macOS releases prior to the October 2021 fix (Big Sur 11.6.1 / Monterey 12.0.1 per HT212872). The AU-Essential-8-Patch gap records that Essential Eight allows up to a month for high-severity OS patches while this kernel-privilege out-of-bounds write was exploited in the wild; the NIS2-Art21-patch-management gap records that any lag between the October 2021 fix and deployment left kernel-level compromise reachable from a malicious app; the NIST-800-53-SI-2 gap records that devices left on older iOS retained an app-to-kernel escalation the control never forced to be closed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "For this entry the fixed build has to function as an access condition rather than a row on a dashboard: an iPhone, iPad or Mac below iOS/iPadOS 14.8.1 (or 15.1) or below the corresponding October 2021 macOS release is denied mail, VPN and document access until it is at or above that build. That is the answer to both gaps here — an estate that cannot see or reach an unmanaged or slow-updating Apple device cannot patch it, and endpoint hardening has nothing to offer once the primitive is an out-of-bounds write in the GPU driver that crosses into the kernel, so what remains is refusing the device organizational data while it stays below the fix. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its mailbox has recorded the exposure rather than removed it. Precondition, and it is the load-bearing caveat on this entry: the packet's trigger is a malicious application already on the device, so restricting untrusted or side-loaded application installation raises the bar for getting that application onto a device but does not evict one already installed and does not cover one that arrived through the normal store channel. A device suspected of already running the malicious application belongs on the incident path, not the install-policy path. This is a holding measure for the window before the fixed build and its required restart land, not a substitute for them.",
+        "evidence": "The packet's affected field places the flaw in Apple GPU drivers in iOS, iPadOS and macOS, where an out-of-bounds write lets a malicious application execute code with kernel privileges, and the attack_vector describes a malicious application triggering that write to elevate from an app foothold to full kernel control. patch_required_reboot is true, live_patch_available is false, and live_patch_notes require the Apple OS update (iOS/iPadOS 14.8.1 or 15.1 and the corresponding macOS release) plus a device restart. The ISO-27001-2022-A.8.8 gap records that technical-vulnerability management depends on tracking OS versions across the Apple estate, and that unmanaged or slow-updating devices kept the KEV-listed GPU-driver kernel write exploitable well after Apple's October 2021 fix; the UK-CAF-B4 gap records that endpoint hardening does not prevent this out-of-bounds write and that app sandboxing and platform hardening are bypassed until the October 2021 update is applied. KEV listing 2023-03-30, active_exploitation confirmed.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2022-38181": {
     "name": "Arm Mali GPU Kernel Driver Use-After-Free Vulnerability (CVE-2022-38181)",
@@ -65720,7 +67824,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",