@blamejs/exceptd-skills 0.19.19 → 0.19.21

package/data/zeroday-lessons.json

@@ -24960,7 +24960,7 @@
     "name": "D-Link DCS-2530L and DCS-2670L Devices Unspecified Vulnerability",
     "lesson_date": "2026-05-29",
     "attack_vector": {
-      "description": "an unauthenticated code-execution flaw (CWE-94) on the D-Link DCS-2530L/2670L network cameras. CISA KEV-listed 2025-08-05 with confirmed in-the-wild exploitation.",
+      "description": "an unauthenticated information-disclosure flaw on the D-Link DCS-2530L/2670L network cameras: the /config/getuser endpoint answers without authentication and returns the administrator password. CISA KEV-listed 2025-08-05 with confirmed in-the-wild exploitation.",
       "privileges_required": "none (unauthenticated network reach to the device/service)",
       "complexity": "low — KEV-listed, actively exploited; treat as weaponized",
       "ai_factor": "No AI involvement documented in discovery or weaponization."
@@ -24973,7 +24973,7 @@
         "adequacy": "Patch/replace is definitive; the gap is that the affected class is internet-exposed by function and (for consumer/EoL devices) often unpatchable, so network isolation is the load-bearing control."
       },
       "detection": {
-        "what_would_have_worked": "Monitoring for the IP camera web interface: exploit-shaped requests, device crashes/reboots, malicious firmware, and outbound botnet/C2 traffic from the device.",
+        "what_would_have_worked": "Monitoring the IP camera web interface for unauthenticated requests to /config/getuser from anything other than a known administration host, and for use of the camera administrator password on other systems — the flaw returns that credential without authentication, so its reuse elsewhere is the observable consequence.",
         "was_this_required": false,
         "framework_requiring_it": null,
         "adequacy": "Necessary to catch exploitation of devices not yet patched/replaced; edge devices are frequently recruited into botnets."
@@ -25014,7 +25014,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Both framework gaps recorded against this D-Link camera entry are timing gaps — a 30-day flaw-remediation SLA, and an \"appropriate timescales\" phrase the packet calls undefined — applied to an internet-facing device whose flaw discloses the remote administrator password and which CISA KEV-listed on 2025-08-05 with confirmed exploitation and a public proof of concept. This control binds the response to the KEV clock instead of the patch cycle: from the listing date, every DCS-2530L and DCS-2670L must carry a verified mitigation, meaning the vendor firmware for that model and hardware revision where one exists, or documented isolation of the camera from untrusted networks where it does not. The packet gives affected_versions only as \"versions per vendor advisory\", so the fixed level has to be read from the vendor advisory this entry references for that exact model rather than inferred from a version comparison — there is no version string in the packet to compare against. Completion is measured on the running unit, not on the management console: live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so a camera that has received firmware but has not restarted onto it is still executing the vulnerable code and counts as exposed. Distinguishing test: for each camera produce the firmware version the unit itself reports after its restart, alongside the fixed level named in the vendor advisory — a fleet report showing the update as pushed or scheduled satisfies a 30-day SLA attestation while cameras that never restarted keep the administrator-password disclosure path open.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2025-08-05, active_exploitation confirmed, poc_available true, cvss 7.5, rwep_score 67, CWE-200; patch_available true, patch_required_reboot true, live_patch_available false; live_patch_notes — \"No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" affected/affected_versions: \"D-Link DCS-2530L and DCS-2670L Devices — versions per vendor advisory\". vector: the devices contain a vulnerability that could allow for remote administrator password disclosure. framework_control_gaps: NIST-800-53-SI-2 — \"30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE. CISA due date is the operationally-meaningful clock — typically 14-21 days for new KEV listings\"; ISO-27001-2022-A.8.8 — the standard \"does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs\", and framework_coverage records \"'Appropriate timescales' is undefined; the standard 30-day reading is unsafe for an unauthenticated, actively-exploited flaw on an internet-facing device\".",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "The packet states both halves this control turns on. patch_available is true, so a fixed firmware exists for this flaw; and the entry's own vector states the impacted products could be end-of-life and/or end-of-service and that users should discontinue product utilization, with the Essential Eight, UK CAF and NIS2 gaps all recording these D-Link cameras as end-of-life hardware for which retirement or isolation, not patching, is the complete action. Together those define the requirement: on a DCS-2530L or DCS-2670L whose hardware revision still has firmware carrying this fix, reaching that build is an interim state; on a unit with no fixed firmware, and on every unit once the model leaves vendor service, the terminal state is removal or replacement, because the camera then stands exposed not only to this administrator-password disclosure but to everything found in that firmware since its last build. Scope to what the packet names — DCS-2530L and DCS-2670L — and inventory those two models; the packet ties this credential-disclosure flaw to them and gives no mapping into other D-Link camera lines or other vendors' cameras, so treating every IP camera in the estate as an instance of this CVE manufactures replacement work against hardware no evidence implicates. Operationally: enumerate both models, record per unit whether the vendor advisory lists a fixed firmware for that hardware revision, put those units on the interim clock that opened with the 2025-08-05 KEV listing, and put the rest on a dated replacement schedule — a risk acceptance with no removal date leaves a device with a public proof of concept and confirmed exploitation in service indefinitely. Precondition on the interim half: no live-patch path is registered and the vendor fix typically requires a service restart or system reboot, so a unit updated but not restarted is not remediated. Precondition on the isolation half, which is the compensating measure the network-security gap describes: reachability has to be verified from an untrusted network and from outside, because a consumer camera commonly acquires its exposure through a port forward or UPnP mapping the topology diagram does not show, and \"the cameras are on the internal network\" is an assertion rather than a demonstration.",
+        "evidence": "Packet fields: vector — \"D-Link DCS-2530L and DCS-2670L devices contains an unspecified vulnerability that could allow for remote administrator password disclosure. The impacted products could be end-of-life (EoL) and/or end-of-service (EoS). Users should discontinue product utilization.\" patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes records the vendor patch typically requires service restart or system reboot per the KEV requiredAction; affected_versions only \"versions per vendor advisory\"; CWE-200; poc_available true; cisa_kev true with kev_date 2025-08-05 and active_exploitation confirmed. framework_control_gaps: AU-Essential-8-Patch — \"The patch pillar is moot for EoL/EoS D-Link cameras with no available firmware; only device replacement remediates, which Essential-Eight patching does not mandate\"; UK-CAF-B4 — \"Hardening cannot patch an end-of-life camera; the only compliant action is retirement\"; NIS2-Art21-network-security — \"Network-security measures must compensate for an end-of-life IP camera with no vendor fix, yet Article 21 doesn't compel decommissioning or isolating the internet-exposed DCS-2530L/2670L whose admin password is remotely disclosable.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "Scope what this control is for on this entry, because the primitive bounds it: the verified flaw is administrator-password disclosure from an unauthenticated endpoint on the DCS-2530L/2670L cameras, not code execution on them, so reachability during the exposure window is evidence that the credential could have been taken — not evidence that anything ran on the device. The framework gaps record the devices as internet-facing and internet-exposed, exploitation is confirmed and a proof of concept is public. What makes the control load-bearing rather than redundant here is the outcome the vector names — remote administrator password disclosure. Firmware that closes the disclosure path does not invalidate a credential already taken, so patch-in-place is the wrong default for any camera that was reachable from an untrusted network during the exposure window that opened before the 2025-08-05 KEV listing. Such a unit is handled as compromised rather than updated: reset it to a factory state and rebuild the configuration from a known-good record instead of carrying the existing configuration across the update, set a new administrative credential rather than restoring the previous one, and where the same administrative password was configured on other units, treat the disclosure from one as a credential for the rest and rotate accordingly. This is also why the least-privilege control cited against this entry passes its attestation while the exposure stands: the attacker never authenticates as any camera operator, so per-account privilege scoping is never consulted and the account model an access-control attestation examines is bypassed rather than abused; what failed is the authentication boundary itself, and the operator-side repair for that is credential replacement, not privilege reduction. Preconditions: rebuild presupposes a fixed firmware for that hardware revision to rebuild onto — where the packet's end-of-life statement means none exists for the model, the unit is a removal item and the credential rotation still has to happen; and a factory reset removes the device's own state, not an attacker's continued access to whatever the disclosed credential opens elsewhere, which has to be scoped and revoked separately. What follows from the disclosed credential rather than from execution: rotate the administrator password on every reachable unit and everywhere that password was reused, and treat the camera as replaceable rather than recoverable where its firmware cannot be brought to a build carrying the fix. A full rebuild is warranted where separately verified indicators of compromise exist on the unit — this CVE alone does not supply them, and recording it as though it did would spend replacement budget on evidence the entry does not carry.",
+        "evidence": "Packet fields: attack_vector — \"an unauthenticated information-disclosure flaw on the D-Link DCS-2530L/2670L network cameras: the /config/getuser endpoint answers without authentication and returns the administrator password. CISA KEV-listed 2025-08-05 with confirmed in-the-wild exploitation.\" vector — the devices contain a vulnerability that could allow for remote administrator password disclosure, and the impacted products could be end-of-life and/or end-of-service with users advised to discontinue product utilization. poc_available true; active_exploitation confirmed; patch_available true with patch_required_reboot true and live_patch_available false. framework_control_gaps: NIST-800-53-AC-6 — \"Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context\"; NIS2-Art21-network-security and ISO-27001-2022-A.8.8 both describe the affected units as internet-exposed / internet-facing devices.",
+        "gap_closes": [
+          "NIST-800-53-AC-6"
+        ]
+      }
+    ]
   },
   "CVE-2020-25079": {
     "name": "D-Link DCS-2530L and DCS-2670L Command Injection Vulnerability",
@@ -25823,7 +25855,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-042",
+        "name": "INCOMPLETE-PATCH-SEQUENCE-SEVERITY-MULTIPLIER",
+        "description": "The packet states the sequence outright: CVE-2025-53770 is a patch bypass for this CVE, and the updates for CVE-2025-53770 include more robust protection than the ones shipped for CVE-2025-49704. That makes this the first fix in an incomplete-patch sequence on the same SharePoint code-injection sink, and it explains the outcome the packet's Essential Eight gap records — an estate that met its patch cadence was still exposed, because the cadence was measured against a fix that had been defeated. Bound to this product, the requirement is that the vulnerability-management record for a SharePoint farm is not closed on the 49704 update: the target state is the build carrying the hardened 53770 protection, the risk score carried against the farm reflects that a bypass of the first fix already exists rather than the discrete rating of one entry, and any further defect announced against the same injection sink is triaged on the assumption that the sink rather than the individual entry point is the defect. The chain feeds the same judgement — the packet records this CVE as chainable with CVE-2025-49706, and its own attack-vector summary describes the chained result as unauthenticated remote code execution, so the 'authorized attacker' framing in the vendor text understates what the farm is actually exposed to and should not be used to down-rank it. Precondition: this control governs how the flaw is scored and tracked and deploys nothing. It reduces no exposure on a farm that has taken neither update, and it says nothing about what happened during the window — a farm that was reachable while exploitation was confirmed belongs on the incident path regardless of which update it now holds.",
+        "evidence": "Packet vector: 'Microsoft SharePoint contains a code injection vulnerability that could allow an authorized attacker to execute code over a network. This vulnerability could be chained with CVE-2025-49706. CVE-2025-53770 is a patch bypass for CVE-2025-49704, and the updates for CVE-2025-53770 include more robust protection than those for CVE-2025-49704.' attack_vector: code injection (CWE-94) on SharePoint Server as part of the ToolShell chain, yielding unauthenticated remote code execution, KEV-listed 2025-07-22 with confirmed in-the-wild exploitation. CVSS 9.8, RWEP 83, poc_available true. The AU-Essential-8-Patch gap states patch cadence was actively defeated here because the initial fix was bypassed by CVE-2025-53770, so meeting the SLA still left KEV-listed, ransomware-linked exploitation live until the hardened update landed.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The clock on this entry opened with the KEV listing on 2025-07-22 against confirmed in-the-wild exploitation, and the packet's own coverage records the standard 30-day reading of 'appropriate timescales' as exploitation acceptance for an actively-exploited flaw on an internet-facing enterprise server. Applied to SharePoint, the first operational consequence is a sourcing rule: the fixed build for each on-premises farm server must be taken from the vendor advisory this entry links, because the packet gives affected versions only as 'per vendor advisory' — the version range is not something to infer, and not something to carry over from another SharePoint entry. The second is where completion is measured. live_patch_available is false and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV required action, so a farm server that has installed the update but has not been restarted is still serving requests from pre-fix code; on a farm that restart is also 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. Precondition, and it is what makes this control insufficient on its own here: satisfying the clock with the 49704 update alone does not end exposure, because the packet records CVE-2025-53770 as a bypass of exactly that fix with more robust protection in its updates — so the state this control drives toward is the hardened update, and the interim hardening the packet names for on-premises SharePoint (AMSI enforcement) bounds exploitation rather than removing the injection path.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-07-22, active_exploitation confirmed ('KEV listing is CISA's confirmed-exploitation attestation'), CVSS 9.8, RWEP 83, poc_available true. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' affected and affected_versions: 'Microsoft SharePoint — see vendor advisory linked in verification_sources for affected version ranges' / 'versions per vendor advisory'. The NIST-800-53-SI-2 gap states the 30-day flaw-remediation SLA is far longer than the observed exploitation window and that the ToolShell SharePoint chain was mass-exploited within days of disclosure; the ISO-27001-2022-A.8.8 gap states 'appropriate timescales' is undefined and the standard 30-day reading is unsafe for an actively-exploited flaw on an internet-facing enterprise server; the UK-CAF-B4 gap names AMSI enforcement as compensating hardening the baseline does not mandate.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This control was written for perimeter appliances, and an on-premises SharePoint farm is not one — but the packet places this flaw on an internet-facing enterprise server under confirmed exploitation with a public PoC, which puts the farm in the same position the control exists to address: the update closes the code-injection sink and removes nothing an attacker installed through it. The packet's gaps name the residue directly — machine-key rotation and a web-shell hunt are recorded as the cleanup this class needs and as hardening the CAF baseline does not mandate — and the machine keys are why patch-in-place specifically fails here: an attacker who took them during the exposure window can keep presenting forged authenticated payloads to a fully patched farm, so reaching the fixed build closes the entry point while leaving the access intact. For this product the requirement is therefore that a farm reachable while exploitation was live is triaged as a compromise — forensic capture, web-shell hunt across the front ends, machine-key rotation, rebuild of anything that cannot be cleared, and rotation of credentials the farm held or that authenticated through it — rather than being closed on the patch record. It also settles which process owns the finding: the packet records ransomware-linked exploitation of this chain, so an exposed farm is an incident to classify and report on the jurisdictional clocks, not a patch ticket. Preconditions: this is the response half and prevents nothing — it depends on the update to stop re-entry through the same sink, and it applies only to farms reachable during the window. Rotating machine keys does not evict an attacker who already holds a web shell or other persistence on the host, which is why the rebuild half is stated rather than rotation alone; and a farm whose request and process logs for the window were not retained cannot demonstrate it was untouched, so a clean hunt against absent telemetry is not evidence of absence.",
+        "evidence": "Packet: active_exploitation confirmed, kev_date 2025-07-22, poc_available true, CWE-94, RWEP 83. attack_vector places the flaw on SharePoint Server as part of the ToolShell chain yielding unauthenticated remote code execution. The UK-CAF-B4 gap states CAF system-security baselines don't mandate the compensating hardening (AMSI enforcement, machine-key rotation) on-prem SharePoint needed once this code-injection was chained and its first patch bypassed, and that patch-alone left the ToolShell path open. The entry's NIS2-Art21-network-security coverage states the framework 'does not require the key-rotation/web-shell-hunt cleanup' this class needs. The NIS2-Art21-vulnerability-handling gap states that known ransomware-campaign use elevates this from routine vulnerability handling to a Significant Incident class under NIS2 Art.23(4), engaging disclosure clocks. The entry's ISO-27001-2022-A.8.8 and PCI-DSS-4.0-6.3.3 coverage both describe the exposure as an internet-facing server.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2025-49706": {
     "name": "Microsoft SharePoint Improper Authentication Vulnerability",
@@ -27447,7 +27510,38 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-121",
+        "name": "MOBILE-ZERO-CLICK-HARDENING",
+        "description": "The packet's vector puts this in Apple iOS, iPadOS, macOS, watchOS and visionOS processing a maliciously crafted photo or video shared via an iCloud Link, and its NIS2 gap records the flaw as zero-click, compromising the device with no victim action, used for Paragon mercenary spyware. There is therefore no user decision anywhere on the delivery path to train, warn or gate — which is precisely why the cited system-security configuration control is recorded as unable to block it. Applied to this entry, the control means the cohort plausibly inside a mercenary-spyware targeting set runs in a reduced-attack-surface mode in which shared media, link previews and attachments are not rendered automatically, so a crafted photo or video arriving over an iCloud share does not reach the media-processing path without an explicit user action. Scope it to the five Apple families the entry names and to the high-risk cohort rather than the whole estate, since the mode costs normal functionality. Preconditions, and they are what make this a holding measure rather than a fix: the mode only helps if it was already on when the share arrived, so it must be a standing posture assigned before the next disclosure — turning it on after the 2025-06-16 KEV listing does nothing for a device already implanted during the window; it narrows the delivery path and removes nothing from the underlying flaw, which closes only when a device is running the vendor's fixed build and has restarted onto it (patch_required_reboot is true and live_patch_available is false); and it does not evict an implant already resident, so a device suspected of exposure is an incident, not a configuration item.",
+        "evidence": "Packet vector: \"Apple iOS, iPadOS, macOS, watchOS, and visionOS, contain an unspecified vulnerability when processing a maliciously crafted photo or video shared via an iCloud Link.\" NIS2-Art21-incident-handling gap: \"this zero-click flaw delivered via a crafted photo or video in an iCloud Link — used for Paragon mercenary spyware — compromises the device with no victim action\". UK-CAF-B4 gap: \"System-security configuration of a managed Apple fleet cannot block a zero-click media-processing exploit arriving over an iCloud share; the exposure closes only when Apple's patch reaches every device.\" cisa_kev true, kev_date 2025-06-16, active_exploitation confirmed, poc_available true, patch_available true, patch_required_reboot true, live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this entry the control means the update carrying the fix is driven across every Apple device in the estate on the clock that opened with the 2025-06-16 KEV listing, with user deferral disallowed, rather than folded into a normal update ring — the packet's own flaw-remediation gap states the 30-day SLA is far longer than the observed exploitation window for a client flaw delivered by attacker-controlled content. Two details decide whether this actually lands. First, the population is the five Apple families the entry names — iOS, iPadOS, macOS, watchOS and visionOS — and the fixed build for each has to be read from the vendor advisory the packet points to, because the entry records affected versions only as \"Apple Multiple Products — versions per vendor advisory\"; an estate that enforces this on phones and laptops while the watch and headset families sit outside the managed-update path has not covered what the vector names. Second, completion is measured on the build each device is actually running, not on \"update pushed\" or \"downloaded\" in the management console: patch_required_reboot is true and the packet records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, with no live-patch path, so a device that took the update and has not restarted is still executing vulnerable code and must be counted as exposed. Precondition: this control reaches only devices the management channel enrolls and can update. A personally-owned or unenrolled device carrying organizational data has the same completion measure and no enforcement lever, and belongs on the access-condition or removal path instead of on this one.",
+        "evidence": "NIST-800-53-SI-2 framework_coverage gap: \"The 30-day flaw-remediation SLA is far longer than the observed exploitation window for a KEV-listed, actively-exploited client memory-corruption flaw delivered by attacker-controlled content.\" ISO-27001-2022-A.8.8 gap: \"'Appropriate timescales' is undefined; the standard reading is unsafe for an actively-exploited mobile/desktop OS flaw, often part of a targeted-spyware chain against high-risk users.\" AU-Essential-8-Patch gap: \"Essential-Eight patch targets exceed the exploitation window for a KEV-listed zero-click Apple flaw already weaponised for targeted spyware before public disclosure.\" patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: \"Vendor patch typically requires service restart or system reboot per the KEV requiredAction.\" affected_versions: \"Apple Multiple Products — versions per vendor advisory\". Vector names iOS, iPadOS, macOS, watchOS and visionOS.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet records this flaw as used for Paragon mercenary spyware and delivered zero-click through a crafted photo or video in an iCloud Link, so the intrusion it produces is a targeted implant, not a commodity malware infection — which is the distinction this control exists to force, and the reason the entry's incident-handling gap says response begins only after covert implantation. The hard part for this CVE is the trigger: the packet states there is no victim action, so there is no user report, no click to reconstruct and no user-visible artifact to escalate on. The runbook must therefore key on the exposure fact the packet does supply rather than on a detection signal it does not: any device in the targeted cohort that was running a build below the vendor fix at any point after the 2025-06-16 KEV listing is handled as a suspected targeted-implant case — forensic acquisition and evidence preservation, review of what the device's credentials and sessions could reach, and rotation of those credentials — instead of being closed the moment the update installs. Preconditions. Escalation prevents nothing; it bounds dwell time and scope after the fact. It pulls directly against the update clock, because the packet records that remediation requires a restart, and restarting or wiping a suspected device destroys volatile state — so the runbook has to decide acquisition-before-update per device, which is a decision that has to exist in writing before a disclosure, not be composed while the fleet is mid-update. And where the organization has no defensible list of who is inside the targeting set, this control has no population to run against and the cohort definition is the prerequisite work.",
+        "evidence": "NIS2-Art21-incident-handling gap: \"Incident-handling obligations assume a detectable trigger, but this zero-click flaw delivered via a crafted photo or video in an iCloud Link — used for Paragon mercenary spyware — compromises the device with no victim action, so response begins only after covert implantation.\" active_exploitation_notes records CISA KEV listing as the confirmed-exploitation attestation with in-wild observation possibly predating the 2025-06-16 dateAdded. attack_vector: \"a code-execution flaw (CWE-94, variant) reachable via attacker-controlled content (a zero-click delivery path in the documented in-the-wild use)\". patch_required_reboot true; live_patch_available false; active_exploitation confirmed.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2025-33053": {
     "name": " Microsoft Windows External Control of File Name or Path Vulnerability",
@@ -28431,7 +28525,30 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "Craft CMS is the product, and this entry is unusual in that the packet names the configuration setting exploitation depends on: an install is vulnerable to remote code execution when the php.ini configuration serving it has register_argc_argv enabled. That makes a configuration-side mitigation path available which is independent of the Craft upgrade — and the upgrade is the slow path here, since the packet records patch_required_reboot true with the vendor fix typically requiring a service restart or system reboot per the KEV requiredAction. The control's requirement for this deployment: inventory every Craft CMS install with the effective register_argc_argv value of the PHP runtime that serves it, disable it on the web-serving runtime, and treat that as a deployable, tested mitigation held ready rather than something discovered during an incident. Distinguishing test: read the effective value back from the PHP process actually serving Craft on every host in the pool — not from a php.ini file on disk, and not from a configuration-management template — and confirm it is off; a secure-configuration attestation covering the operating system and web-server baseline passes cleanly while this flag stays on, which is precisely what the UK-CAF and Essential-Eight hardening gaps record. Preconditions, both load-bearing. The mitigation holds only where nothing in the deployment depends on the setting: command-line PHP tooling reads $argv, so the change must be scoped to the runtime handling web requests and verified there rather than cleared globally, or scheduled jobs break and the change gets reverted under pressure. And clearing the flag does not evict an attacker already resident — active exploitation is confirmed and the flaw is unauthenticated code execution on the web server, so an install that ran with the flag enabled while reachable needs a compromise assessment and rotation of the secrets that install holds, not a flag flip recorded as remediation. This is the holding measure for the window before the vendor release and its restart land; the least-privilege control cited on this entry gives nothing here, because the attacker never holds a Craft account and no privilege decision is ever consulted.",
+        "evidence": "Packet vector: 'Craft CMS contains a code injection vulnerability. Users with affected versions are vulnerable to remote code execution if their php.ini configuration has register_argc_argv enabled.' patch_required_reboot true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' active_exploitation confirmed; poc_available true; CVSS 9.8; RWEP 77. Cited gaps: NIS2-Art21-vulnerability-management ('exploitability here hinges on the register_argc_argv PHP runtime setting — a config-hardening step the process doesn't enumerate, so a patched-elsewhere host stays an unauthenticated RCE target'), UK-CAF-B4 ('secure-configuration baselines for the PHP runtime rarely flag register_argc_argv'), AU-Essential-8-App-Hardening ('application-hardening doesn't reach web-runtime php.ini flags'). NIST-800-53-AC-6 gap records that the exploit demonstrates the boundary is breakable from a baseline context.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For Craft CMS the packet gives an unauthenticated code-execution flaw on an internet-facing web application with a public proof of concept, KEV-listed 2025-06-02 with confirmed in-the-wild exploitation — the profile the cited 30-day flaw-remediation reading is least safe for. The control means the Craft upgrade runs on the KEV clock rather than the site's normal release train, and it means one specific piece of care with the fixed level: the packet records affected versions only as 'per vendor advisory', so the target build has to be taken from the vendor advisory linked in this entry's verification sources rather than assumed from a version the operator has to hand. Completion is measured on what the running site is executing, not on what was deployed. patch_required_reboot is true and the packet records the vendor fix as typically requiring a service restart or system reboot, so a host whose Craft files were updated while the PHP and web service kept running is still executing pre-fix code and must be counted as exposed — on a busy site that restart is the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Distinguishing test: enumerate every Craft CMS install the organisation runs — production, staging and the marketing or campaign sites that tend to sit outside the main asset register — and produce the version each is serving; an attestation covering the primary site passes cleanly while a forgotten install keeps an unauthenticated RCE reachable from the internet. Precondition: this control governs the speed and completeness of reaching the fixed release. It does nothing for an install already exploited, and it does not reach the runtime setting the same exploit depends on, which is a separate control on this entry.",
+        "evidence": "Packet: CISA KEV 2025-06-02, active_exploitation confirmed, CVSS 9.8, RWEP 77, poc_available true. attack_vector: 'a code-injection flaw (CWE-94, the related earlier variant) enabling unauthenticated remote code execution on the web server.' patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes records the vendor patch typically requiring service restart or system reboot per the KEV requiredAction. affected / affected_versions given only as 'Craft CMS — see vendor advisory linked in verification_sources for affected version ranges'. Cited gaps: NIST-800-53-SI-2 ('30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE'), ISO-27001-2022-A.8.8 (standard does not differentiate routinely-disclosed CVEs from actively-exploited KEV-listed ones).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-39780": {
     "name": "ASUS RT-AX55 Routers OS Command Injection Vulnerability",
@@ -29006,7 +29123,39 @@
     },
     "ai_discovered_zeroday": false,
     "ai_discovery_source": "vendor_research",
-    "ai_assist_factor": "none"
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "Ivanti Endpoint Manager Mobile is the trust boundary for the mobile fleet in the sense this tier exists for: the packet's own gaps record its API as internet-facing and the manager as controlling every enrolled device, and its attack_vector records the exploited form as unauthenticated remote code execution on the EPMM management surface once this code injection is chained with the authentication bypass. That makes EPMM not a system sitting behind a perimeter but the thing the fleet authenticates to, which is why the standard cadence fails: the packet's own gaps name a 30-day flaw-remediation SLA and a 48-hour internet-facing target, both longer than the interval in which a public proof of concept against a 9.8 pre-auth remote code execution gets used. The requirement for this CVE is that EPMM sits in its own SLA tier whose clock started with the 2025-05-19 KEV listing and is counted in hours. One scoping caution the packet forces: it carries the affected range only as 'versions per vendor advisory', so the fixed level must be read from that advisory for the EPMM release actually in service rather than assumed, and the sweep covers every EPMM instance the estate runs — widen beyond EPMM only where a verified source identifies another product carrying the same Hibernate Validator implementation. The packet records no live-patch path and states that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction, so an EPMM that has taken the update but has not restarted onto it is still executing the vulnerable code and is not remediated; completion is the version the running service reports. Precondition on the tier's isolation alternative, which is where this control is over-claimed on a device manager: isolating the vulnerable interface is only partly available here, because the packet's gap records the EPMM API as internet-facing and the device-facing paths that make it so are the ones the enrolled fleet depends on. Restricting the administrative surfaces and the source ranges permitted to reach the device API bounds who can attempt the chain; it does not remove the device-facing path, so it is a holding measure for the window before the update and its restart land, not a substitute for either.",
+        "evidence": "Packet: CWE-94; CVSS 9.8; RWEP 77; poc_available true; active_exploitation confirmed; cisa_kev true with kev_date 2025-05-19. attack_vector: 'code injection (CWE-94) yielding unauthenticated remote code execution on the EPMM management surface (chained with the authentication bypass). CISA KEV-listed 2025-05-19 with confirmed in-the-wild exploitation.' patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: 'No live-patch tool registered for this entry at bulk-import time. Vendor patch typically requires service restart or system reboot per the KEV requiredAction.' affected and affected_versions both give the product as 'Ivanti Endpoint Manager Mobile (EPMM)' with versions 'per vendor advisory'. NIST-800-53-SI-2 gap: '30-day flaw-remediation SLA inadequate for CISA-KEV-listed actively-exploited CVE.' AU-Essential-8-Patch gap: 'The 48h internet-facing patch target trails active chaining of this EPMM RCE, whose compromise pivots to every mobile device the manager controls.' ISO-27001-2022-A.8.8 gap: the standard 'does not differentiate between routinely-disclosed CVEs and actively-exploited KEV-listed CVEs'. NIS2-Art21-network-security gap names the 'internet-facing EPMM API'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "EPMM is the device-management gateway this control governs, and the defect sits on its API interface: the packet places a code-injection sink in the API component reachable through crafted API requests, arising from an insecure implementation of the Hibernate Validator open-source library as represented by CVE-2025-35036 — a request-supplied value reaching an expression-evaluation path. Bound to this product the control asks for two properties on that API. Each endpoint decides its caller's authorization itself, before the request body is processed at all, rather than inheriting a verdict from a front-end filter — which is exactly the arrangement that collapses when this injection is chained with the authentication bypass and the request arrives with no valid session; and request-supplied values never reach an evaluation path as expression text, so a parameter cannot select what the server evaluates. It also means no EPMM instance is left with its administrative API paths reachable from segments that have no operational need to reach them. This is why the least-privilege gap cited on this entry does not close the path: the packet's vector describes an authenticated attacker, but the exploited form it records is unauthenticated once chained, so per-account privilege scoping is never consulted and an AC-6 attestation passes cleanly while the endpoint stays reachable and evaluating. Distinguishing test on a staging EPMM: send each API endpoint an unauthenticated request whose parameter values carry expression syntax and confirm it is refused before the value is evaluated — not that EPMM administrators are correctly scoped, which this attacker never needed to be. Precondition: the endpoint-side authorization decision and the input handling are properties the vendor update establishes; this control states what to verify and does not implement it. Until that update and its restart land, restricting reachability bounds the population that can send the request while leaving the endpoint exploitable to anything within reach, and for the device-facing API that population includes any client that can present itself to it.",
+        "evidence": "Packet vector: 'Ivanti Endpoint Manager Mobile (EPMM) contains a code injection vulnerability in the API component that allows an authenticated attacker to remotely execute arbitrary code via crafted API requests. This vulnerability results from an insecure implementation of the Hibernate Validator open-source library, as represented by CVE-2025-35036.' attack_vector records the exploited form as unauthenticated remote code execution on the EPMM management surface when chained with the authentication bypass. NIST-800-53-AC-6 gap: 'Least-privilege presumes a working authentication / authorization boundary. The KEV-listed exploit demonstrates the boundary is breakable from a baseline context.' NIS2-Art21-network-security gap: 'Network-security controls do not compel restricting the internet-facing EPMM API whose expression-language injection RCE, chained with an auth bypass, hands over the MDM controlling an entire mobile fleet.' patch_available true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet states the consequence plainly in its UK-CAF gap: a compromised EPMM becomes a fleet-wide command channel to every enrolled device. Code execution on the management surface means the attacker inherits the manager's own authority over that fleet — configuration profiles, certificates, application deployment and device-trust state — so the response has to be written for the enrolled devices and not only for the appliance. For this product the pre-rehearsed playbook is: revoke and reissue the certificates EPMM issued; invalidate device-trust state and re-enroll; diff every configuration profile and application-deployment policy against a known-good baseline across the window in which the instance was exposed, which opens no later than the 2025-05-19 KEV listing and earlier if the instance was reachable before it; set quarantine criteria for enrolled devices that took a profile or package during that window; and rotate credentials for every account that authenticated through EPMM. Applying the vendor update answers none of these questions. The fix removes the injection sink and leaves in place whatever was pushed to handsets through it, and a profile or certificate delivered by a compromised manager stays trusted by the fleet until it is explicitly revoked — which is the specific way this remediation is recorded as complete while the fleet is still carrying attacker-supplied configuration. Precondition: this is a response measure and not a preventive one, and it depends on the exposure window being establishable from records the compromised appliance itself may hold. Where EPMM's logging was local to the instance, the window cannot be bounded from the appliance alone and has to be reconstructed from an independent source, which is the argument for treating the enrolled fleet as in scope by default rather than scoping the response to the manager.",
+        "evidence": "Packet UK-CAF-B4 gap: 'Hardening the EPMM appliance does not remove an expression-language injection in its API, and the compromised MDM becomes a fleet-wide command channel to every enrolled device.' NIS2-Art21-network-security gap describes the chained RCE as handing over 'the MDM controlling an entire mobile fleet'; AU-Essential-8-Patch gap notes the compromise 'pivots to every mobile device the manager controls'. active_exploitation confirmed with poc_available true and cisa_kev true, kev_date 2025-05-19. patch_available true; live_patch_available false; live_patch_notes records that the vendor patch typically requires a service restart or system reboot per the KEV requiredAction.",
+        "gap_closes": [
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2025-4427": {
     "name": "Ivanti Endpoint Manager Mobile (EPMM) Authentication Bypass Vulnerability",
@@ -33645,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",
@@ -34628,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",
@@ -39231,7 +39438,31 @@
         "adequate": false,
         "gap": "Flaw remediation is structurally impossible: Zyxel has declared these DSL CPE devices end-of-life/end-of-service with no patch planned, so the standard remediate-within-SLA control has no path to closure short of hardware replacement."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet forecloses the interim half of this control before it begins: patch_available is false, the vector opens with the UNSUPPORTED WHEN ASSIGNED marker, and live_patch_notes records that no live-patch path exists for this EOL firmware and that the vendor's only guidance is to discontinue use of the device if it cannot be isolated from untrusted networks. So for these legacy Zyxel DSL CPE units there is no fixed build to reach and no patched state to record — every unit in service is a replacement item, and the requirement is an inventory naming each VMG4325-B10A and each related legacy Zyxel DSL CPE running firmware 1.00(AAFR.4)C0_20170615, with a dated removal date per unit rather than a remediation ticket that waits on firmware. Scope it to what the packet's affected and affected_versions name — VMG4325-B10A and the related legacy Zyxel DSL CPE builds sharing the same management-command codebase — because the packet maps this command-injection sink to that codebase and to no other Zyxel line, and sweeping every Zyxel device in the estate as an instance of this CVE manufactures replacement work against hardware no evidence implicates. Until a unit is gone, the only lever the packet leaves is the isolation the vendor names, and its precondition has to be stated rather than assumed: the injection is reached through the Telnet-exposed management command interface, so blocking Telnet at the WAN interface removes the path Censys observed on 1,500+ of these devices and the path GreyNoise saw scanned from January 2025 — but a DSL CPE exists to serve the LAN attached to it, and every client on that LAN still reaches the management interface with the default or service-account credentials the packet describes the attack using. For a unit serving a general user network there is no filter that removes the path, only isolation of that network from anything that matters. And because active exploitation is confirmed and Mirai variants recruited these routers into botnet infrastructure, a unit that was WAN-reachable during the exposure window is not made safe by filtering it now: the flaw yields OS command execution on the device itself, so it is a removal item rather than a reconfiguration item, and any credential that transited it should be rotated.",
+        "evidence": "Packet fields: patch_available false, live_patch_available false, patch_required_reboot true with no patch to apply; live_patch_notes — \"No live-patch path exists for this EOL firmware; the vendor's only guidance is to discontinue use of the device if it cannot be isolated from untrusted networks.\" The vector carries the UNSUPPORTED WHEN ASSIGNED marker and describes a post-authentication command injection in the management commands of the legacy DSL CPE Zyxel VMG4325-B10A firmware version 1.00(AAFR.4)C0_20170615, executed via Telnet; affected/affected_versions scope to VMG4325-B10A and related legacy Zyxel DSL CPE firmware builds sharing the same management-command codebase; CWE-78; cvss 8.8, rwep_score 70; poc_available false; cisa_kev true with kev_date 2025-02-11 and active_exploitation confirmed. active_exploitation_notes: GreyNoise observed mass scanning and exploitation attempts beginning January 2025 and Mirai botnet variants incorporated exploitation of this Telnet-based command injection, using it alongside CVE-2024-40890 to recruit EOL routers. framework_control_gaps: NIST-800-53-SI-2 records Zyxel declaring these devices end-of-life/end-of-service with no patch planned and no closure short of hardware replacement; NIST-800-53-CM-7 records Censys observing 1,500+ of these EOL devices with the Telnet management interface reachable directly from the WAN; UK-CAF-B4 records the Telnet management plane exposed to the untrusted WAN interface; ISO-27001-2022-A.8.8 records these units sitting outside the ISMS asset register.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry only the control's third branch is reachable. Its requirement is a verified mitigation — patch, live patch, or documented compensating controls — on the KEV clock, and the packet records patch_available false and live_patch_available false with no live-patch path for this EOL firmware, so the clock that opened with the 2025-02-11 KEV listing can only be answered by the compensating action the vendor names: isolate the device from untrusted networks, or discontinue use. That is precisely what the two frameworks cited here cannot express — Essential Eight's patch-within-48-hours-of-active-exploitation expectation is unmeetable because no patch exists, and NIS2 vulnerability handling assumes an eventual vendor fix that will never ship for this hardware — so the compensating action has to be recorded as the terminal deliverable against the KEV date, not as a temporary state pending firmware. Operationally, every affected unit needs a dated, evidenced record of either its removal or its Telnet management interface being unreachable from the WAN, produced against the listing date rather than left as an open remediation ticket. Distinguishing test, keyed on the exploitation path the packet documents: from outside the device's WAN interface, attempt a Telnet connection to each unit and issue a management command; anything that answers is within reach of the scanning and exploitation GreyNoise observed from January 2025, and a vulnerability-management report carrying this CVE as \"no patch available, risk accepted\" while the interface answers has recorded the exposure rather than mitigated it. Precondition: the isolation is a mitigation only while it holds, and it depends on a WAN-side filter surviving firmware resets, ISP re-provisioning and user reconfiguration on hardware the operator generally does not manage — which is why the vendor's own guidance ends at discontinuing use rather than at isolation.",
+        "evidence": "Packet fields: cisa_kev true with kev_date 2025-02-11 and active_exploitation confirmed; patch_available false; live_patch_available false; live_patch_notes — \"No live-patch path exists for this EOL firmware; the vendor's only guidance is to discontinue use of the device if it cannot be isolated from untrusted networks.\" attack_vector: an attacker with a Telnet session to a legacy Zyxel DSL CPE device, using default or otherwise-obtained service-account credentials, sends management commands containing embedded shell metacharacters that are passed unsanitized to the underlying OS shell. active_exploitation_notes: GreyNoise observed mass scanning and exploitation attempts against exposed Zyxel legacy DSL CPE devices beginning January 2025. framework_control_gaps: AU-Essential-8-Patch — \"Essential 8's patch-within-48-hours-of-active-exploitation guidance is unmeetable since no patch exists; the only compensating action is decommissioning or isolating the device from the internet\"; NIS2-Art21-vulnerability-management — \"NIS2 operators relying on this hardware have no vendor remediation SLA at all post-EOL; typical vulnerability-management timelines assume an eventual vendor fix that will never ship.\"",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2024-40890": {
     "name": "Zyxel DSL CPE OS Command Injection Vulnerability (CGI)",
@@ -39268,7 +39499,31 @@
         "adequate": false,
         "gap": "Boundary protection is absent by design: the CGI management program is reachable via HTTP POST from the untrusted WAN interface with no network-layer restriction."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-127",
+        "name": "UNSUPPORTED-NETWORK-DEVICE-ENUMERATION-AND-RETIREMENT",
+        "description": "The packet settles the patch question before the control begins: patch_available is false, the CVE text is marked UNSUPPORTED WHEN ASSIGNED, and the vendor's only recorded guidance is to discontinue use of the device if it cannot be isolated from untrusted networks. There is no fixed firmware to reach and therefore no interim state — for these units the terminal state is removal or replacement, and the enumeration half is what makes that actionable: inventory every Zyxel legacy DSL CPE in service with its model and running firmware, covering the related legacy models sharing the same CGI codebase that the packet's affected_versions name rather than only the VMG4325-B10A the vector headlines, since an estate that standardised on a sibling model would otherwise report clean. Each unit becomes a dated replacement item; a risk acceptance with no removal date leaves a KEV-listed device under confirmed mass exploitation in service indefinitely, and it stays exposed to everything else found in that abandoned firmware, not only this command injection. Precondition on the isolation half, which the vendor guidance itself makes conditional: the flaw is reached by an HTTP POST to the CGI management program, so removing WAN-side reachability of that interface takes the unit out of the internet-facing path the trackers observed from January 2025 — but a DSL CPE exists to serve the client network behind it, and every client on that network still reaches the CGI management surface, so for a unit serving a general user network isolation bounds who can reach the path rather than removing it. The post-authentication framing is not a barrier either: the packet places the session on a default or service account, so the precondition is credentials that ship with the device rather than anything an attacker must first steal. And because active exploitation is confirmed and the outcome is OS command execution on the device itself, a unit that was reachable during the window is not made safe by reconfiguration — it is replaced, and credentials that transited it are rotated.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes 'No live-patch path exists for this EOL firmware; the vendor's only guidance is to discontinue use of the device if it cannot be isolated from untrusted networks.' vector begins '**UNSUPPORTED WHEN ASSIGNED**' and describes post-authentication command injection in the CGI program of the legacy DSL CPE Zyxel VMG4325-B10A firmware 1.00(AAFR.4)C0_20170615 via a crafted HTTP POST request; affected_versions extends to 'related legacy Zyxel DSL CPE firmware builds sharing the same CGI codebase'; affected records the session as an 'authenticated (default/service-account) session'. cisa_kev true, kev_date 2025-02-11, active_exploitation confirmed, CVSS 8.8, RWEP 70, CWE-78. active_exploitation_notes: GreyNoise and Mirai botnet trackers observed mass scanning/exploitation of exposed devices via crafted HTTP POST requests against the CGI management program beginning January 2025. The NIST-800-53-SI-2 gap states remediation is structurally impossible with no path to closure short of hardware replacement; the NIST-800-53-SC-7 gap states the CGI management program is reachable via HTTP POST from the untrusted WAN interface with no network-layer restriction; the ISO-27001-2022-A.5.21 gap states the devices are vendor-abandoned with no patch path.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.5.21"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This control's three states resolve unusually on this entry, and that is the point of attaching it: state (a), binary patch deployed, is permanently unreachable. patch_available is false and live_patch_available is false with no live-patch path recorded for the abandoned firmware, so a Zyxel legacy DSL CPE that has been isolated from untrusted networks sits permanently in state (b) — compensating control active, no binary patch — and one that has not sits in state (c), full exposure, while its CGI management program answers HTTP POSTs from the WAN. The requirement here is that the compliance record says exactly that: an isolated VMG4325-B10A or sibling legacy unit must appear as a compensating-control state carrying a dated replacement action, never as remediated and never as an open-ended accepted risk, because unlike a patch-pending entry there is no future vendor event that converts the state — the only thing that closes it is the device leaving the estate. Precondition on what may be recorded as the compensating control: it has to be isolation actually in force and verified from outside, since 'the router sits behind the ISP connection' is an assertion about topology rather than evidence that the CGI interface is unreachable. The residual-risk statement attached to state (b) must also carry the two facts that bound it — LAN-side clients still reach the management surface, and the authenticating credential is a device default or service account — otherwise the record reads as containment while the exploited path remains available to anything on the client network.",
+        "evidence": "Packet: patch_available false, live_patch_available false, live_patch_notes recording no live-patch path for this EOL firmware and vendor guidance to discontinue use of the device if it cannot be isolated from untrusted networks; poc_available false but active_exploitation confirmed with kev_date 2025-02-11 (KEV ransomware use flagged Unknown). The NIS2-Art21-vulnerability-management gap states that operators relying on this hardware have no vendor remediation SLA at all post-EOL and that typical vulnerability-management timelines assume an eventual vendor fix that will never ship; the AU-Essential-8-Patch gap states the patch-within-48-hours-of-active-exploitation guidance is unmeetable since no patch exists and the only compensating action is decommissioning or isolating the device from the internet.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2025-0994": {
     "name": "Trimble Cityworks Deserialization Vulnerability",
@@ -39895,7 +40150,38 @@
         "adequate": false,
         "gap": "Exploitation depends on obtaining admin credentials, frequently via the paired CVE-2018-19410 flaw; stronger identity-and-access controls (MFA, credential rotation) would blunt the chain."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-135",
+        "name": "CONTROL-PANEL-PLUGIN-USER-SURFACE-MUST-NOT-REACH-ROOT-OPERATIONS",
+        "description": "PRTG's sensor and notification management is the configuration surface this control governs, and the packet places the defect exactly there: parameters submitted through sensor or notification management — the packet names EXE/Script sensor parameters and notification 'Execute Program' actions — are passed unsanitized into an OS command, yielding execution on the PRTG core server and on any device the server manages. The missing boundary is not between an anonymous caller and the console; it is between holding PRTG System Administrator inside the application and running arbitrary OS commands as the account the PRTG core service runs under, across the monitored estate. Applied to this product, the control means the configuration fields that feed command execution accept a selection from an operator-curated set of programs and argument shapes rather than a free-form string composed at the console, and the process that executes them holds only the privileges monitoring genuinely requires rather than inheriting the reach of the monitoring platform. Distinguishing test: on a staging PRTG instance below 18.2.39, submit shell metacharacters in an EXE/Script sensor parameter and in a notification Execute Program action while authenticated as System Administrator, and observe whether an OS command runs — an attestation that every PRTG administrator is named, approved and periodically reviewed passes cleanly while this path is wide open, because the caller here is a legitimate administrator and no account model is being abused. That is the same reason the least-privilege gap recorded on this entry cannot be closed by tightening who holds the role. Precondition: the parameter handling itself is repaired by the vendor release — the packet records versions before 18.2.39 as affected — so this control states the property to verify and does not implement it. Until an instance is at or above that version, restricting who holds System Administrator bounds the population that can submit the parameters but does not close the path, because the packet's own exploitation account has attackers arriving with those credentials already in hand, frequently obtained through the companion pre-auth flaw CVE-2018-19410.",
+        "evidence": "Packet vector: 'An attacker who has access to the PRTG System Administrator web console with administrative privileges can exploit an OS command injection vulnerability (both on the server and on devices) by sending malformed parameters in sensor or notification management scenarios.' attack_vector names 'EXE/Script sensor parameters, notification \"Execute Program\" actions' passed unsanitized to an OS command 'yielding command execution on the PRTG core server or a monitored device'. affected_versions: '< 18.2.39'; patch_available true. The NIST-800-53-AC-6 gap: the console 'over-trusts authenticated administrators, allowing free-form OS-level parameter strings in sensor/notification configuration without least-privilege sandboxing of the executed command.' The AU-Essential-8-App-Hardening gap: those features 'are inherently high-risk command-execution surfaces that application-hardening guidance would restrict or disable where not required.' The ISO-27001-2022-A.8.9 gap: configuration management 'should validate/sanitize sensor and notification parameter fields rather than passing them unsanitized to OS command execution.' active_exploitation_notes place credential acquisition, 'often via the companion pre-auth flaw CVE-2018-19410', ahead of the injection.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.9"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The interval this control exists to compress is unusually visible on this entry: the flaw was disclosed against PRTG Network Monitor versions before 18.2.39 in 2018, and CISA added it to KEV on 2025-02-04, which the packet attributes to continued abuse of legacy, unpatched PRTG deployments. A KEV listing on a seven-year-old flaw is a statement that the population still running the vulnerable build is large enough to be worth an attacker's time, so the action here is an enumeration before it is a patch cycle: find every PRTG core server in service and record the version each runs, taking instances reachable from the internet first, since the packet's own vulnerability-management gap places the multi-year unpatched population in internet-exposed deployments. Every instance below 18.2.39 is on the clock that opened 2025-02-04. Measure completion on the version the running PRTG core service reports rather than on an installer having been executed; the packet records no live-patch path for this product, so the running service is the only thing whose version answers the question. Distinguishing test: query each PRTG core server for the version it is actually serving and confirm it is at or above 18.2.39 — a vulnerability-management report showing no PRTG findings because no PRTG server appears in it is the state this entry describes, not a clean result. Precondition: a public PoC exists and exploitation is confirmed, and the packet places command execution on the core server and on any device it manages, so an instance that ran a vulnerable build while its console was reachable by anyone holding or able to obtain System Administrator credentials is not remediated by the upgrade alone. Its configured sensors and notification actions are the objects the attacker writes to and should be compared against a known-good baseline rather than carried forward through the upgrade, and the devices the server manages belong in the blast radius rather than being assumed clean.",
+        "evidence": "Packet: cisa_kev true, kev_date 2025-02-04, active_exploitation confirmed, poc_available true, rwep_score 63 against cvss 7.2. affected_versions '< 18.2.39'; the vector records the issue as 'discovered in PRTG Network Monitor before 18.2.39'. active_exploitation_notes: attackers 'inject OS commands through sensor or notification configuration parameters for full RCE on the PRTG core server and any device it manages. Added to CISA KEV Feb 2025, reflecting continued abuse of legacy, unpatched PRTG deployments.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. The NIS2-Art21-vulnerability-management gap: 'A 2018-disclosed flaw remained unpatched and exploitable in internet-exposed PRTG deployments as of the 2025 KEV addition — patch-management processes failed over a multi-year window.'",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "PRTG Network Monitor is a monitoring control plane whose administrative account, on the packet's own account of this exploit, converts into command execution on the core server and on every device the server manages. That places PRTG System Administrator in the tier this control exists to name rather than in the application-admin tier where a monitoring tool is usually filed, and the difference is the whole point: an identity-and-access attestation that treats it as one more application admin is measuring the wrong thing. For this deployment the requirement is that the PRTG console is reached through a privileged-access path rather than from an operator's daily workstation, that holding System Administrator is a separate identity from the same person's ordinary account and other administrative roles, and that the session is step-up authenticated rather than opened with a reusable password — because the packet's exploitation account is a credential-theft chain, in which attackers first obtain PRTG System Administrator credentials, frequently via the companion pre-auth flaw CVE-2018-19410, and only then reach the injection sink. Distinguishing test: from a general workstation segment, attempt to reach the PRTG console with a password alone and confirm it is refused; an estate where the monitoring platform's admin credential is a reusable password reachable from any desk already satisfies the precondition this exploit needs. Precondition, stated plainly because this is where the control is over-claimed: raising the bar at the console login bounds credential reuse, it does not repair the unsanitized parameter handling, and it is never consulted by a chain step that yields a live session or an API token rather than a password. It also does nothing against an administrator who is legitimately authenticated, since the packet's caller holds the role by design. It bounds the population that can attempt the escalation; it is not a substitute for reaching 18.2.39.",
+        "evidence": "Packet active_exploitation_notes: 'Actively exploited by attackers who first obtain PRTG System Administrator credentials (often via the companion pre-auth flaw CVE-2018-19410) and then inject OS commands through sensor or notification configuration parameters for full RCE on the PRTG core server and any device it manages.' vector requires 'access to the PRTG System Administrator web console with administrative privileges'. The UK-CAF-B2 gap: 'Exploitation depends on obtaining admin credentials, frequently via the paired CVE-2018-19410 flaw; stronger identity-and-access controls (MFA, credential rotation) would blunt the chain.' patch_available true with affected_versions '< 18.2.39'.",
+        "gap_closes": [
+          "UK-CAF-B2"
+        ]
+      }
+    ]
   },
   "CVE-2018-19410": {
     "name": "Paessler PRTG Network Monitor Local File Inclusion Vulnerability",
@@ -40195,7 +40481,40 @@
         "adequate": false,
         "gap": "Aviatrix Controller instances left reachable from the internet had no boundary protection to stop unauthenticated command injection against a cloud-network control plane."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Aviatrix Controller is a multi-cloud network control plane, and the packet's timeline is what makes a KEV-tied clock the requirement rather than a cloud-infrastructure change window: exploitation ran January 7-10 2025 and surged after a public Nuclei detection template was released, with CISA listing the flaw on 2025-01-16. For this product the control means the upgrade to the fixed build — 7.1.4191 for the 7.1 line, 7.2.4996 for 7.2.x — is driven from the KEV listing, with completion measured per instance on the version the running controller reports. patch_required_reboot is false, which means no host reboot; it does not mean the fix is live the moment an upgrade is pushed, and a controller still answering /v1/api on a pre-fix version is exposed regardless of what the deployment record says. live_patch_available is false and live_patch_notes is empty, so there is no interim in-place fix to fall back on: reaching the fixed version is the only remediation the packet records. Distinguishing test: enumerate every Aviatrix Controller instance in the organisation — including any stood up by an application team outside the central cloud-platform inventory — and produce its running version; a patch attestation covering only the controllers the platform team already tracks passes cleanly while an unlisted instance keeps an unauthenticated command-injection endpoint reachable. Precondition: this control governs the speed and completeness of the upgrade only. It says nothing about an instance that was already exploited during the window the packet records, which is a separate response path.",
+        "evidence": "Packet: CISA KEV 2025-01-16, active_exploitation confirmed, CVSS 10, RWEP 75, poc_available true. Exploited in the wild from January 7-10 2025 with a sharp surge after a public Nuclei detection template was released. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions: before 7.1.4191; 7.2.x before 7.2.4996. Cited gaps: SI-2 (exploitation surged faster than routine remediation SLAs), ISO A.8.8 (periodic vuln-review cycles far slower than the days-long window), AU-Essential-8-Patch (mass exploitation within days, driven by public tooling).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The defect sits on Aviatrix Controller's own management API: /v1/api accepts list_flightpath_destination_instances and flightpath_connection_test, and the cloud_type and src_cloud_type parameters reach an OS command with shell metacharacters unneutralized, for a caller that never authenticates. Bound to this product the control means two things. First, each /v1/api operation authorizes its caller and neutralizes parameter content before the value reaches the command, so a caller-supplied string cannot select what the controller executes — this is the property the fixed build establishes, and the control states what to verify rather than implementing it. Second, no controller is left with that API reachable from a segment with no operational need to reach it; the packet's boundary gap records instances left reachable from the internet with nothing in front of them, and the NIS2 gap records segmentation isolating the controller's management API as frequently absent in this incident. Distinguishing test: from a general workstation VLAN and from an external address, attempt to reach /v1/api on a staging controller and confirm the connection is refused before the endpoint parses anything — 'the controller is in our cloud account' is a statement about topology, not a demonstration that the management API is unreachable from untrusted callers. Precondition, and this is where the reachability half is routinely over-claimed: restricting which segments can reach /v1/api bounds who can send the request, it does not close the injection. Any host inside a permitted segment still drives the endpoint to full unauthenticated command execution, and the lever is simply unavailable where the controller API must stay reachable for normal operation. It is a holding measure for the window before the fixed build lands, not a substitute for it.",
+        "evidence": "Packet vector/affected: shell metacharacters sent to /v1/api in cloud_type for list_flightpath_destination_instances, or src_cloud_type for flightpath_connection_test, fail neutralization and yield unauthenticated OS command execution (CWE-78). Cited gaps: NIST-800-53-SC-7 ('instances left reachable from the internet had no boundary protection to stop unauthenticated command injection against a cloud-network control plane'), UK-CAF-B4 ('secure configuration guidance for cloud-network control planes did not prevent an unauthenticated OS command injection sink from being internet-reachable'), NIS2-Art21-network-security (EU operators 'needed network segmentation isolating the controller's management API, which this incident showed was frequently absent').",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-network-security"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "This is the case the control exists for, and the packet supplies both halves: an unauthenticated pre-auth command-execution flaw on a network control-plane device, and confirmed exploitation in which threat actors deployed XMRig cryptominers and Sliver C2 backdoors for persistence. Upgrading an Aviatrix Controller to 7.1.4191 or 7.2.4996 closes the injection sink; it removes nothing an attacker installed through it, so an instance that was reachable during the January 7-10 2025 window is not remediated by the upgrade and must not be closed on the patch record. For this product the response is to export and review the controller configuration, rebuild the instance from a known-good image, and rotate the cloud credentials and role trust the controller holds — the packet records Wiz Research finding that 65% of organisations running Aviatrix Controller have a lateral-movement path from it to administrative cloud control-plane permissions, which is the blast radius a resident Sliver implant inherits. Distinguishing test: for each controller, establish whether its /v1/api was reachable from an untrusted network at any point before the upgrade; where it was, treat it as an incident rather than a patch item. Precondition: rebuild-not-patch presupposes a known-good image and a configuration export the operator trusts, and it applies to instances with exposure during the window — it is not a blanket instruction to rebuild every controller. Where a rebuild genuinely cannot be scheduled, the honest state is a compromised-until-proven-otherwise instance under monitoring with its cloud credentials rotated, not a remediated one.",
+        "evidence": "Packet active_exploitation_notes: exploited in the wild from January 7-10 2025; 'threat actors used unauthenticated command injection to deploy XMRig cryptominers and Sliver C2 backdoors for persistence'; 'Wiz Research notes 65% of organizations running Aviatrix Controller have a lateral-movement path to administrative cloud control-plane permissions'. active_exploitation confirmed; poc_available true; patch_available true (before 7.1.4191 / 7.2.x before 7.2.4996). Cited gap NIST-800-53-SI-2 treats remediation as flaw removal on a clock, which does not reach attacker-installed persistence.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2025-21335": {
     "name": "Microsoft Windows Hyper-V NT Kernel Integration VSP Use-After-Free Vulnerability (CVE-2025-21335)",
@@ -40493,7 +40812,39 @@
         "adequate": false,
         "gap": "EU operators relying on BeyondTrust PRA/RS as a privileged-access gateway need vendor-supply-chain risk monitoring, not just internal patch cadence, since the compromise originated at the vendor."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "BeyondTrust Privileged Remote Access and Remote Support are themselves the privileged-access control plane — the product exists so technicians reach other people's systems — and the packet's exploit precondition is an attacker who already holds administrative privileges on a PRA/RS site and uploads a crafted file the backend processes without OS-command sanitization, so commands run as the site user. Bound to this product the control means PRA/RS site administration is classified as its own privilege tier above application admin rather than collapsed into 'admin': a separate identity from any other administrative role, access only through a PAM jump host, per-session step-up, and just-in-time elevation with an approval workflow, so that holding an administrative session on the remote-support platform is a deliberately granted, time-bounded and individually attributable state instead of a standing role. What this incident adds to the tier is that it cannot enumerate human administrators only: the packet records the access arriving through a stolen BeyondTrust cloud API key used to reach 17 Remote Support SaaS tenants, so every API key carrying site-administrative capability — including keys the vendor holds against the customer's own tenant — needs a named owner, a scope, an expiry and a revocation path inside the same tier. Precondition, and it is the half this control is most often over-claimed on: jump-host routing, per-session step-up and just-in-time elevation constrain interactive administrator logons and do nothing to a machine-to-machine key presenting valid credentials to the API, because no session is ever opened for a step-up to interrupt. For that identity class the control reduces to enumeration, scoping and rotation, and a tenant that has recorded the vendor's key as simply 'vendor-managed' holds no lever at all until that key is listed as an administrative identity in its own right. Distinguishing test: produce the list of identities that can administer the PRA/RS site and confirm every non-human key on it has an owner and a revocation path — an attestation that every named BeyondTrust administrator authenticates with MFA passes cleanly while the documented access path stays open.",
+        "evidence": "Packet vector: 'A vulnerability has been discovered in Privileged Remote Access (PRA) and Remote Support (RS) which can allow an attacker with existing administrative privileges to inject commands and run as a site user.' affected: PRA and RS on-premises and SaaS deployments, where an attacker with existing administrative privileges uploads a malicious file processed without OS-command sanitization, executing commands as the site user. active_exploitation_notes: 'Exploited as a zero-day by the Chinese state-sponsored group Silk Typhoon in December 2024, chained with CVE-2024-12356 to steal a BeyondTrust API key and pivot into 17 Remote Support SaaS tenants, including the U.S. Treasury Department.' NIST-800-53-AC-6 gap: 'Least-privilege scoping alone does not stop an attacker who already holds legitimate admin credentials (via a stolen vendor API key) from injecting OS commands through the file-upload handler.' UK-CAF-B4 gap: 'Supply-chain and third-party PAM tooling assurance is insufficient when the vendor's own cloud API key can be silently compromised and used to reach customer tenants.'",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-078",
+        "name": "ENDPOINT-MGMT-DEPLOYMENT-CHANNEL-INTEGRITY",
+        "description": "The primitive on this entry is OS command execution as the site user on a remote-support server, reached by uploading a file the backend processes without neutralizing embedded command sequences — so the exposed asset is the whole PRA/RS installation and everything it stores and hands out: session artifacts, technician-facing client downloads, and the site's own service configuration. Treat that content as a privileged distribution channel rather than as application data: file-integrity-monitor the PRA/RS installation and every directory from which it serves artifacts, alert on writes that do not reconcile to a recorded, approved administrator change or a vendor update, and hold the support server to KEV-priority patching as a management-plane asset in its own right. That patching half is concrete here rather than generic: the packet records the December 2024 fix in BT24-11 with all cloud instances patched by 2024-12-16 while self-hosted instances required manual patching, so a self-hosted site is remediated only by an operator action someone has to schedule, and an estate that read the vendor's cloud-side completion as its own is unpatched. This is also the control that still carries value after that fix lands, because the fix closes the injection path and removes nothing that was written or executed through it during the zero-day window. Precondition, and it decides whether the monitoring is worth anything on this product: the upload arrives inside an authenticated administrative session, so the presence of an administrator login is not evidence the write was sanctioned — the alert only distinguishes attacker activity when it is reconciled against change records, and a site with no change record to reconcile against produces an alert it cannot adjudicate. On remediation status, the packet registers no live-patch path, and its host-reboot flag says nothing about the service being restarted onto the fix, so completion is measured on the version the running PRA/RS site reports rather than on the update having been applied.",
+        "evidence": "Packet: CWE-78; CVSS 6.6; RWEP 50; poc_available false; active_exploitation confirmed; cisa_kev true with kev_date 2025-01-13. attack_vector: the attacker 'uploads a specially crafted file through the admin console; the backend fails to neutralize embedded OS command sequences, so the commands execute with the privileges of the site user.' affected_versions: 'RS/PRA 22.1.x and later prior to the December 2024 fix in BT24-11 (all cloud instances patched by 2024-12-16; self-hosted instances required manual patching)'. patch_available true; live_patch_available false; live_patch_notes null; patch_required_reboot false. NIST-800-53-SI-2 gap: 'This flaw was exploited as a zero-day by a nation-state actor before a patch existed, so patch-SLA-based remediation could not have prevented the initial Treasury compromise.' ISO-27001-2022-A.8.16 gap: 'Monitoring keyed to failed-auth and anomalous logins does not flag command injection issued through a legitimately-authenticated session riding a stolen vendor API key, so A.8.16 telemetry read the Treasury intrusion as normal privileged use.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.16",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "A Remote Support / Privileged Remote Access site is a fleet control plane in the exact sense this control means — it holds standing access into every system its technicians support — and the packet documents the compromise propagating along that shape: a stolen BeyondTrust cloud API key reaching 17 Remote Support SaaS tenants, including the U.S. Treasury Department. Written in this product's terms and before it is needed, the playbook is: revoke and reissue every API key and site credential on notification of a vendor-side or tenant-side compromise; enumerate the support sessions, jump items and file transfers the site recorded across the suspected exposure window; rotate credentials for every account a technician used through the platform in that window, because those credentials transited a system on which an attacker was running commands as the site user; and fix quarantine criteria for the downstream endpoints that had a session in the window rather than negotiating them under time pressure. The trigger matters as much as the content here. The packet's compromise originated at the vendor and arrived at customers through a legitimately issued key, so the playbook has to be startable from a vendor advisory or a tenant notification and not only from the customer's own alerting — the customer-side telemetry, as the monitoring gap on this entry records, read the activity as normal privileged use. Precondition: this control bounds the damage of an intrusion that has already happened. It neither detects the command injection nor prevents it, and the rotation step is only complete if it covers the vendor-held key alongside the customer's own credentials — a rotation that reissues site passwords while leaving the vendor's cloud key in place leaves the documented access path intact.",
+        "evidence": "Packet active_exploitation_notes: 'Exploited as a zero-day by the Chinese state-sponsored group Silk Typhoon in December 2024, chained with CVE-2024-12356 to steal a BeyondTrust API key and pivot into 17 Remote Support SaaS tenants, including the U.S. Treasury Department. Ransomware status is unflagged in KEV for this entry.' affected: PRA and RS on-premises and SaaS deployments; commands execute as the site user. AU-Essential-8-Patch gap: 'Application patching alone does not address a vendor-side API key compromise; requires companion API-key rotation and access-anomaly monitoring.' NIS2-Art21-vulnerability-management gap: 'EU operators relying on BeyondTrust PRA/RS as a privileged-access gateway need vendor-supply-chain risk monitoring, not just internal patch cadence, since the compromise originated at the vendor.' ISO-27001-2022-A.8.16 gap records that the customer-side telemetry 'read the Treasury intrusion as normal privileged use'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-management"
+        ]
+      }
+    ]
   },
   "CVE-2023-48365": {
     "name": "Qlik Sense HTTP Tunneling Vulnerability",
@@ -40673,7 +41024,31 @@
         "adequate": false,
         "gap": "EU operators of MiCollab as unified-communications infrastructure need emergency out-of-cycle patch processes for unauthenticated critical flaws, not standard change-management timelines."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "The interval this control has to compress on MiCollab is the one the packet measures: watchTowr's disclosure in December 2024, active exploitation of internet-facing NuPoint Unified Messaging endpoints within days of it, and the KEV listing on 2025-01-07 — days, against the change-management cycle a unified-communications platform is normally patched on, which is what this entry's flaw-remediation, internet-facing-patching and vulnerability-handling gaps each record. Applied here the requirement is an out-of-cycle emergency window rather than the next UC maintenance slot, and the population is every instance publishing the NuPoint Unified Messaging component, not only the one the asset register lists as the UC platform. The packet gives the vulnerable range as the NPM component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) and does not name a fixed build, so the target level has to be taken from the vendor advisory for the deployed release rather than assumed. patch_required_reboot is false, meaning no host reboot — not that the fixed code is live: live_patch_available is false and no live-patch path is recorded, so an instance counts as remediated only once the running NuPoint service is executing the fixed build. Priority follows the packet rather than the CVSS band alone — a public proof-of-concept, confirmed exploitation, a KEV ransomware association, and the packet's note that this traversal is frequently chained with CVE-2024-55550 make it a chain-entry item rather than a standalone UC patch ticket. And the update is not the whole of remediation: an instance that was internet-facing while the exploit was public has already had provisioning and configuration data read by an unauthenticated caller, and applying the fix closes the path without recalling what was taken, so material held there needs rotation rather than being closed on the patch record.",
+        "evidence": "Packet: patch_available true; affected_versions 'NuPoint Unified Messaging (NPM) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201)' with no fixed build named; cisa_kev true with kev_date 2025-01-07; active_exploitation confirmed, notes record exploitation against internet-facing MiCollab NuPoint Unified Messaging endpoints shortly after watchTowr's December 2024 disclosure, frequent chaining with CVE-2024-55550, and a CISA KEV ransomware association; poc_available true; cvss 9.1, rwep_score 72. patch_required_reboot false, live_patch_available false, live_patch_notes null. The NIST-800-53-SI-2 gap records the disclosure-to-KEV window as days, far shorter than typical enterprise patch-SLA cycles for UC platforms; AU-ISM-1546 records exploitation within days of disclosure. The vector states the exploit allows an attacker to view, corrupt, or delete users' data and system configurations.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-ISM-1546",
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The path-sanitization boundary in front of MiCollab's NuPoint Unified Messaging component is where the product makes its access decision for everything behind it, and this CVE is that boundary failing: the packet has an unauthenticated caller sending a novel '..;/' sequence the sanitizer does not recognise, escaping the intended directory scope to reach internal AXIS2 SOAP services and read provisioning and configuration data or trigger limited administrative actions. Bound to this product, the control means those internal services — the AXIS2 SOAP endpoints and each administrative function reachable through them — authorize their own caller before acting rather than inheriting a verdict from the front-end path scoping, so that defeating the sanitizer yields a reachable endpoint instead of an executed administrative action; and that the NuPoint Unified Messaging component is not published to unauthenticated internet traffic, which this entry's own system-security gap names as the root cause. Distinguishing test: from an unauthenticated position outside the deployment, send the traversal sequence against a staging MiCollab and confirm the internal SOAP service refuses the caller rather than answering — an instance that passes a MiCollab user-account and role review still answers this request, because the attacker never authenticates as any MiCollab user and no account model is ever consulted. Preconditions, and they are load-bearing here. The caller-side authorization is a property the vendor update establishes; this control states what to verify, it does not implement it. Restricting reachability bounds who can send the sequence but closes nothing for anything inside the permitted segment, and that lever is unavailable where NuPoint Unified Messaging must stay published for remote users — which is precisely the deployment the packet describes as the exploited population — so it is a holding measure for the days between disclosure and the fix, not a closure. And because exploitation is confirmed and this read primitive is frequently chained with CVE-2024-55550, an instance reachable while the exploit was public has already disclosed provisioning data; restricting access afterwards does not recall it, so credentials and configuration held there need rotation.",
+        "evidence": "Packet vector: 'A vulnerability in the NuPoint Unified Messaging (NPM) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) could allow an unauthenticated attacker to conduct a path traversal attack, due to insufficient input validation.' attack_vector: an unauthenticated attacker sends a request containing a novel '..;/' traversal bypass to the NuPoint Unified Messaging endpoint, escaping the intended directory scope to reach internal AXIS2 SOAP services and read provisioning/configuration data or trigger limited administrative actions. The NIST-800-53-SC-7 gap states the vulnerability is itself a boundary-bypass primitive whose traversal sequence was unrecognized by the application's path-sanitization boundary, so standard boundary-protection assumptions failed to hold; the UK-CAF-B4 gap states internet exposure of the NuPoint Unified Messaging component to unauthenticated traffic is itself the root cause and that segmentation should have limited exposure regardless of patch status. poc_available true; active_exploitation confirmed and frequently chained with CVE-2024-55550.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2020-2883": {
     "name": "Oracle WebLogic Server Unspecified Vulnerability (CVE-2020-2883)",
@@ -41048,7 +41423,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",
@@ -41085,7 +41484,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",
@@ -41122,7 +41556,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",
@@ -41501,7 +41967,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",
@@ -41616,7 +42115,39 @@
         "adequate": false,
         "gap": "Network security controls did not restrict firewall management-plane access to trusted administrative networks only."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "These units are perimeter firewalls and VPN concentrators — the device is the trust boundary, which is why a standard firmware-patch window is the wrong instrument for a traversal in their web management interface that a ransomware group was already using for initial access. For this CVE the tier requirement is that within the clock opened by the 2024-12-03 KEV listing, every affected unit either runs ZLD V5.39 or has its web management interface isolated from untrusted networks until it does. Scope is all four series the packet names, at each one's own affected range — ATP V5.00 through V5.38, USG FLEX V5.00 through V5.38, USG FLEX 50(W) V5.10 through V5.38 and USG20(W)-VPN V5.10 through V5.38 — because an estate standardised on the USG20(W)-VPN or the USG FLEX 50(W) reports clean against a sweep scoped to the ATP series the summary leads with. Completion is measured on the firmware version the unit is executing: the packet records patch_required_reboot true and live_patch_available false, so a unit that has had V5.39 uploaded but has not restarted onto it is still running the traversal-vulnerable code and counts as exposed, and a management console showing the firmware as staged is not evidence of remediation. The isolation branch is the one that needs its condition stated: pulling the web management interface off the internet removes the internet-reachable path the packet identifies as the exploitation precondition, but it does not fix the traversal — any caller inside whatever segment retains access still reaches it — and it is unavailable where administrators must reach the interface remotely, in which case the permitted set is a named administrative or jump network rather than 'reduced exposure'.",
+        "evidence": "Packet affected: 'Zyxel ATP, USG FLEX, USG FLEX 50(W), and USG20(W)-VPN series firewalls running ZLD firmware; the web management interface allows directory traversal to download or upload files via a crafted URL.' affected_versions: 'ATP series V5.00-V5.38', 'USG FLEX series V5.00-V5.38', 'USG FLEX 50(W) series V5.10-V5.38', 'USG20(W)-VPN series V5.10-V5.38', 'fixed in ZLD V5.39'. cisa_kev true with kev_date 2024-12-03; active_exploitation confirmed; poc_available true; rwep_score 77; cvss 7.5; patch_available true; patch_required_reboot true; live_patch_available false. The NIST-800-53-SI-2 gap records that 'Firmware patch-SLA cadence did not close the window before Helldown began using this flaw for initial access'; the AU-Essential-8-Patch gap records that 'Patch-applications control alone does not compensate for internet-exposed firewall management planes.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet says the crafted URL both downloads and uploads files, and that Helldown affiliates used this traversal as initial access into victim networks from around November-December 2024 — before and during the period operators were still scheduling firmware. That combination is what this control exists for: upgrading an ATP, USG FLEX, USG FLEX 50(W) or USG20(W)-VPN unit to ZLD V5.39 closes the traversal, but it does not delete a file that was already written to the device and does not invalidate a credential or configuration item that was already read off it. For these firewalls the control means any unit whose web management interface was reachable from an untrusted network while it ran an affected V5.00-V5.38 build is handled as a compromise rather than as a patch item: its configuration exported for offline review before anything is changed, the unit rebuilt from a known-good image and a known-good configuration instead of upgraded in place, and every credential the device held or brokered rotated at its source — local administrator accounts, VPN and remote-access users, directory bind accounts, pre-shared keys and device certificates. Distinguishing test: instead of asking whether the unit now reports V5.39, ask its filesystem and configuration whether anything was added or altered during the window it ran an affected build, and whether each credential it held carries a rotation date later than the end of that window. Precondition, and the reason this is a branch of the incident path rather than a replacement for it: rebuilding the device removes on-device persistence only. It does not evict an attacker who already used what the traversal yielded to move into the network — the packet records ransomware deployment into victim networks as the objective — so the internal investigation proceeds regardless of what state the firewall is in.",
+        "evidence": "Packet vector: the traversal in the web management interface 'could allow an attacker to download or upload files via a crafted URL'. attack_vector: 'An attacker sends a crafted URL to the ZLD web management interface that traverses outside the intended directory scope, allowing arbitrary file download or upload — used by Helldown ransomware affiliates as initial access into victim networks.' active_exploitation_notes: 'Used as an initial-access vector by the Helldown ransomware group from around November-December 2024 to compromise internet-exposed Zyxel firewall/VPN management interfaces before deploying ransomware into victim networks. CISA KEV flags ransomware use as Known.' active_exploitation confirmed; kev_date 2024-12-03; patch_available true with fixed build ZLD V5.39; patch_required_reboot true; live_patch_available false. The ISO-27001-2022-A.8.8 gap records that 'Technical vulnerability management on firewall firmware assumes scheduled updates, but Helldown ransomware operators used this directory-traversal for initial access within the patch window, so the standard's cadence-based timescale left the internet-exposed management interface exploitable.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "The management plane the packet names is the ZLD web management interface on these Zyxel firewalls, and the defect sits on it: a crafted URL escapes the intended directory scope and drives a file download or upload. Bound to this product, the control means every file-serving and file-accepting path on that interface authorizes its caller before the file operation is performed at all, and normalizes and validates the resolved path before any read or write executes, so a caller-supplied URL cannot select which file is served or overwritten; and that no ATP, USG FLEX, USG FLEX 50(W) or USG20(W)-VPN unit is left with that interface reachable from a network that has no operational need to reach it. The reachability half is the one the packet ties directly to exploitation — internet-exposed management interfaces are what Helldown affiliates compromised — so the administrative surface belongs on an administrative or jump network, with the WAN side of the management interface closed, rather than on the internet with a strong administrator password standing in for a boundary. Distinguishing test: on a staging unit, request each file path the management interface serves and submit each upload it accepts, from an unauthenticated caller on a segment with no administrative role, using a URL whose path resolves outside the intended directory, and confirm it is refused before anything is read or written. Precondition, and it is the one most often skipped: the caller authorization and path normalization are properties the vendor establishes in ZLD V5.39 — this control states what to verify, it does not implement it. Until a unit has restarted onto V5.39, restricting which segments can reach the management interface bounds who can send the crafted URL but leaves the endpoint fully exploitable to anything inside the permitted segment, and that restriction is unavailable wherever the interface must remain reachable for remote administration.",
+        "evidence": "Packet vector: 'A directory traversal vulnerability in the web management interface of Zyxel ATP series firmware versions V5.00 through V5.38, USG FLEX series firmware versions V5.00 through V5.38, USG FLEX 50(W) series firmware versions V5.10 through V5.38, and USG20(W)-VPN series firmware versions V5.10 through V5.38 could allow an attacker to download or upload files via a crafted URL.' cwe_refs CWE-22; affected_versions record the fix as 'fixed in ZLD V5.39'; patch_available true, patch_required_reboot true, live_patch_available false. The NIST-800-53-SC-7 gap records that 'Boundary protection was insufficient — the ZLD web management interface was reachable from the internet, the precondition for this exploitation chain'; the NIS2-Art21-network-security gap that 'Network security controls did not restrict firewall management-plane access to trusted administrative networks only'; the UK-CAF-B4 gap that 'System security lifecycle management allowed perimeter firewall management interfaces to remain internet-exposed.' active_exploitation_notes records Helldown compromising 'internet-exposed Zyxel firewall/VPN management interfaces'.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-45727": {
     "name": "North Grid Proself Improper Restriction of XML External Entity (XXE) Reference Vulnerability",
@@ -42091,7 +42622,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",
@@ -42128,7 +42692,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",
@@ -42514,7 +43110,31 @@
         "adequate": false,
         "gap": "Essential Eight patch-applications guidance targets prompt remediation for exploited internet-facing services; a years-old MEDIUM CVE quietly returning to active-exploitation status falls outside routine patch-cadence triage."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this Jira entry the control means the remediation clock starts at the 2024-11-12 KEV listing, not at the CVSS 5.3 band that kept the CVE off high-severity-only remediation queues for the years the fixes had already existed. The mechanics are branch-specific and this is where the SLA is usually missed on Jira: the packet gives three separate fixed builds — before 8.5.14, 8.6.0-8.13.5 fixed in 8.13.6, and 8.14.0-8.16.0 fixed in 8.16.1 — so an estate pinned to the 8.5.x line closes this by reaching 8.5.14, and 'upgrade to the newest release' is a different change with a different approval path that instances on a long-term branch will not take inside the window. Completion is measured on the build the running instance reports, per Server instance and per Data Center node, not on the installer having run: live_patch_available is false, so there is no way to close the traversal on a process that is still executing pre-fix code, and patch_required_reboot false records only that no host reboot is needed — it does not mean the fix is live before the Jira process comes up on the new build. Speed matters beyond the patch record because of what the flaw yields: the packet has the unauthenticated read used to harvest servlet-mapping and configuration detail from web.xml ahead of follow-on attacks, and that material stays useful to the attacker after the upgrade lands, so an instance that was internet-facing during the exposure window needs the disclosed configuration reviewed rather than being closed on the version alone.",
+        "evidence": "Packet fields for CVE-2021-26086: cisa_kev true with kev_date 2024-11-12, active_exploitation confirmed, poc_available true, cvss 5.3 against rwep_score 67, patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. affected_versions gives the three fixed branches: before 8.5.14; 8.6.0 - 8.13.5 (fixed in 8.13.6); 8.14.0 - 8.16.0 (fixed in 8.16.1). The NIST-800-53-SI-2 gap states fixes existed years before the November 2024 KEV listing and that SI-2 SLAs commonly track vendor severity rather than active-exploitation status. active_exploitation_notes records active exploitation of unauthenticated file-read against internet-facing Jira Server/Data Center instances, used to harvest servlet-mapping and configuration detail from web.xml ahead of follow-on attacks, and that the entry is not flagged as ransomware-associated.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-074",
+        "name": "CVE-REGRESSION-WATCHER",
+        "description": "This entry is the case the watcher's trigger condition is written for, and it fires cleanly here: a CVE identifier assigned in 2021 appearing in current exploitation reporting and carrying a public proof-of-concept, three years after the fixed Jira branches shipped. What the triage must then resolve is specific to this product rather than the regression case the control was first written against — the finding is not a re-introduced defect but a Jira estate still running a pre-8.5.14, pre-8.13.6 or pre-8.16.1 branch, so the intake hit must be closed by resolving each instance's running branch against those three fixed builds rather than by checking whether the vendor shipped a fix. The distinguishing test is on the intake pipeline, not the host: replay a threat feed containing the 2024 exploitation reporting for this 2021 identifier and confirm it lands on the remediation queue. A pipeline that ingests only advisories for identifiers assigned in the current cycle, or that filters intake by CVSS band, never surfaces it at all — which is exactly how a fix that had been available for years went unapplied on internet-facing instances until CISA listed the CVE.",
+        "evidence": "Packet fields for CVE-2021-26086: the identifier is a 2021 assignment, kev_date is 2024-11-12, poc_available is true and active_exploitation is confirmed. The AU-Essential-8-Patch gap states that a years-old MEDIUM CVE quietly returning to active-exploitation status falls outside routine patch-cadence triage. The ISO-27001-2022-A.8.8 gap states that Jira's low CVSS kept it off many high-severity-only remediation queues despite the later KEV listing. affected_versions supplies the fixed branches the triage resolves against: 8.5.14, 8.13.6 and 8.16.1.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2014-2120": {
     "name": "Cisco Adaptive Security Appliance (ASA) Cross-Site Scripting (XSS) Vulnerability",
@@ -42840,7 +43460,30 @@
         "adequate": false,
         "gap": "CAF B4 secure configuration explicitly expects removal of unsupported internet-facing software; the real fix here is decommissioning, not patching."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "This entry is the case the control exists for and the packet states both halves. patch_available is true, so a build past the affected 'through 1.9.6' range exists and reaching it is available — but the packet's gaps describe an EOL, unmaintained web server that least-functionality controls should have listed as prohibited software, and the UK-CAF-B4 gap says the real fix is decommissioning rather than patching. Those facts define the requirement: on a host that must keep serving until it can be replaced, moving past 1.9.6 is an interim state; the terminal state is removal, because an unmaintained daemon is exposed not only to this traversal but to whatever is found in it next, and the packet records five years between disclosure and the 2024-11-07 KEV listing that finally forced attention. Scope to what the packet names — Nostromo nhttpd instances at or below 1.9.6 — and do not extend the removal work to other small HTTP daemons; the packet ties the traversal to the http_verify() authentication path in nhttpd on a non-chrooted instance and gives no mapping into any other server, so treating every lightweight web daemon in the estate as an instance of this CVE manufactures findings and replacement work against software no evidence implicates. Operationally: enumerate every nhttpd instance reachable from an untrusted network with its version, put each on a dated replacement schedule onto a maintained HTTP server, and for any instance that must stay in service in the meantime take the fixed build from the project rather than assuming a version number, and remove its reachability from untrusted networks. Precondition on the interim half: the packet registers no live-patch path, so replacing the binary on disk does not change what the listening process serves — the running daemon keeps executing the old image until it is restarted, and completion is the version the listener reports, not the version on the filesystem. And because active exploitation is confirmed and the outcome is remote code execution on a non-chrooted server, a host that was exposed is not remediated by the upgrade alone: what the web-server account could reach needs triage rather than being closed on the version record.",
+        "evidence": "Packet name: 'Nostromo nhttpd Directory Traversal Vulnerability'. affected: 'Nostromo nhttpd web server; directory traversal in the http_verify() authentication function of a non-chrooted server instance allows unauthenticated remote code execution.' affected_versions: 'through 1.9.6'. cwe_refs: CWE-22. cvss 9.8, rwep_score 63, poc_available true, active_exploitation confirmed, cisa_kev true with kev_date 2024-11-07. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. The NIST-800-53-CM-7 gap: 'Least-functionality controls should have flagged an EOL, non-chrooted web server as prohibited software years before the 2024 KEV listing.' The UK-CAF-B4 gap: 'CAF B4 secure configuration explicitly expects removal of unsupported internet-facing software; the real fix here is decommissioning, not patching.' The NIS2-Art21-vulnerability-handling gap: 'requires an inventory that catches unsupported software still exposed to the internet; EOL nhttpd instances are exactly the blind spot this control targets.' The AU-Essential-8-App-Hardening gap: 'Application-hardening guidance would flag an unmaintained, non-chrooted HTTP daemon as prohibited attack surface.'",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-vulnerability-handling",
+          "AU-Essential-8-App-Hardening"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The A.8.8 gap on this entry records the paper-compliance outcome precisely: an EOL, unmaintained nhttpd instance evaded routine vulnerability-scanning cadences for five years before the KEV listing forced attention. The scans ran the whole time and reported clean — that clean report is what the ISMS recorded as conformance, and it is the artefact this control tests. For this CVE the operational test is whether the estate's scanning can name a running nhttpd at all: stand up an nhttpd instance at or below 1.9.6 on a staging host, run the exact scan profile the estate is attested with, and require the report to identify the daemon, its version, and this CVE. A scan cycle built around managed-package inventory and expected service ports produces nothing against a host serving nhttpd outside that inventory, and the absence of a finding is indistinguishable in the report from the absence of the software — which is the whole failure. Make the pass condition the positive identification, not the absence of an alert. Precondition and limit: this is a detection test, not a remediation. Finding the daemon does not remove it, and a finding that lands in a scanner queue rather than on the dated replacement schedule reproduces the five-year outcome in a different system of record. It also only covers hosts the scan can reach and is authorised to inspect; an nhttpd instance on a segment or a host outside the scan's scope is invisible to the test as well as to the scan, so scope coverage has to be demonstrated separately rather than assumed from a clean estate-wide result.",
+        "evidence": "The ISO-27001-2022-A.8.8 gap on this entry: 'A.8.8 technical vulnerability management requires ongoing visibility into internet-facing software; an EOL, unmaintained nhttpd instance evaded routine vulnerability-scanning cadences for five years before KEV listing forced attention.' Packet affected_versions: 'through 1.9.6'. affected: 'Nostromo nhttpd web server; directory traversal in the http_verify() authentication function of a non-chrooted server instance allows unauthenticated remote code execution.' cisa_kev true, kev_date 2024-11-07, active_exploitation confirmed with active_exploitation_notes citing 'ongoing internet-wide scanning and exploitation of exposed Nostromo nhttpd servers for remote code execution'.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-8957": {
     "name": "PTZOptics PT30X-SDI/NDI Cameras OS Command Injection Vulnerability",
@@ -43224,7 +43867,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",
@@ -44107,7 +44772,39 @@
         "adequate": false,
         "gap": "SAP shipped a fix in 2019, but KEV addition in 2024 shows five years of unpatched exposure among internet-facing instances — patch-SLA enforcement failed long-term, not just at disclosure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-133",
+        "name": "ECOMMERCE-PLATFORM-EXTENSION-UNTRUSTED-DESERIALIZATION-GUARD",
+        "description": "SAP Commerce Cloud (formerly Hybris) is the e-commerce platform this control governs, and the packet places the sink where the control says to look: not in core storefront code but in the platform's extensions — the packet's affected field names both the mediaconversion and virtualjdbc extensions, while the vector text mentions only virtualjdbc, so a review scoped to the vector's headline extension leaves the other one live. For this deployment the requirement is that neither extension passes request-supplied data to Java deserialization on any path an untrusted caller can reach, and that the patch and asset programmes enumerate the enabled extension set of each Commerce Cloud node as part of its code-execution surface rather than recording only the platform release. That enumeration is the load-bearing half here: exploitation yields arbitrary code execution with the 'Hybris' OS user's rights, so the blast radius is the application account that owns the storefront's data and integrations, and an inventory that lists 'SAP Commerce Cloud 1811' without listing which extensions that node loads cannot tell an assessor whether the vulnerable code is deployed. Distinguishing test: on a staging node of each affected release in the estate (6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905), send a crafted serialized gadget-chain object to each interface the virtualjdbc and mediaconversion extensions expose, from a caller with no credentials, and confirm it is rejected before any deserialization runs — a paper attestation that the platform is patched, taken from a release banner while the extension set is never enumerated, passes cleanly while the object-injection sink stays reachable. Remediation is the SAP fix for the affected release, which the packet records as available; completion is measured on the extension code the running platform process is serving, since patch_required_reboot false records only that the host needs no reboot, not that a rebuilt artifact on disk is what the live process has loaded.",
+        "evidence": "Packet affected: 'SAP Commerce Cloud (formerly Hybris), mediaconversion and virtualjdbc extensions, vulnerable to unsafe Java deserialization enabling arbitrary code execution with \"Hybris\" OS user rights.' affected_versions: 6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905. cwe_refs CWE-502; cvss 9.8; rwep_score 70; poc_available true; cisa_kev true with kev_date 2024-09-30; active_exploitation confirmed. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes null. The ISO-27001-2022-A.8.8 gap records that 'Technical vulnerability management (asset + patch tracking) failed to catch a five-year-old vendor-patched flaw still present in production Commerce Cloud deployments'; the AU-Essential-8-Patch gap records that 'Essential Eight patch-application maturity presumes an asset inventory tracking the virtualjdbc extension that long-tail Commerce Cloud deployments plainly lacked.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "The packet's attack vector puts this CVE squarely in the binary remoting-protocol class this control governs: the virtualjdbc extension exposes Java serialization over HTTP, RMI and JMXMP, the listener answers a caller that never authenticates, and the deserializer behind it is the vulnerable code — so a storefront WAF, TLS termination and web-tier hardening, which is what a Commerce Cloud deployment is usually audited against, never sit in front of the path that gets exploited. For this deployment the requirement is that the virtualjdbc and mediaconversion listeners accept connections only from the hosts that legitimately speak those protocols — the application-tier nodes and the administrative or integration hosts that actually use them — enforced by network ACL or host firewall rather than inferred from 'the Hybris cluster is internal', and that where an extension is not required by the deployment it is removed from the enabled extension set rather than left listening. Distinguishing test for this product: from a general user VLAN or an internet-facing segment against a staging node, open a connection to each RMI/JMXMP/HTTP serialization endpoint the two extensions expose and confirm the peer is dropped before the node reads any serialized content — an estate that passes storefront penetration tests and Commerce Cloud role audits while leaving the serialization listener reachable from any internal segment is still exposed to the unauthenticated gadget-chain path. Precondition, which is where this control is most often over-claimed: restricting reachability bounds who can send the payload, it does not remove the deserialization sink. Any host inside the permitted set still reaches it, so this is interim to applying the SAP fix on the affected release — and it is unavailable where an integration genuinely requires the listener to answer, in which case the permitted set is the named integration hosts and nothing else.",
+        "evidence": "Packet attack_vector: 'SAP Commerce Cloud's virtualjdbc extension exposes Java serialization over HTTP/RMI/JMXMP; an attacker sends a crafted gadget-chain serialized payload directly to the exposed listener to achieve remote code execution as the \"Hybris\" OS user.' The vector text records the flaw as 'unsafe deserialization used in SAP Commerce Cloud (virtualjdbc extension), versions 6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905', and affected additionally names the mediaconversion extension. The NIST-800-53-SC-7 gap records that 'The virtualjdbc/JMXMP listener should never be reachable from untrusted networks, yet exploitation presumes direct network access to it — boundary protection was not enforced'; the UK-CAF-B4 gap records that 'Secure configuration guidance should have disabled or firewalled the legacy virtualjdbc extension where unused; long-tail exposure suggests this was not audited.' cvss 9.8, poc_available true, active_exploitation confirmed, patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "What the packet documents is not a patch decision that went wrong but five years in which nobody's tooling reported the exposure: SAP shipped the fix in 2019 and the entry reached KEV in September 2024 against internet-facing Commerce Cloud instances that were never patched. For this CVE the control means a scan result of 'patched' derived from the Commerce Cloud platform release banner is paper compliance, because the vulnerable code lives in the virtualjdbc and mediaconversion extensions and exposure is decided by two facts a banner cannot carry — whether those extensions are in the node's enabled extension set, and whether their Java serialization listener answers from a segment the node should not be answering. The operational test has both parts: an authenticated inventory of the enabled extension set on every Commerce Cloud node, compared against the affected releases the packet names (6.4, 6.5, 6.6, 6.7, 1808, 1811, 1905) and against the version of the extension code the running platform process is actually serving rather than the artifact sitting on disk; and an unauthenticated reachability probe of the HTTP/RMI/JMXMP serialization listener from outside the application tier. A node that passes on its release string while the extension is loaded and the listener answers counts as unverified, not as compliant. This is also the test that distinguishes an asset register from an inventory: the packet's own gap describes long-lived deployments that no patch-verification process ever saw, and a scanner that cannot reach or authenticate to the Hybris node will report the same clean result for a node that does not exist, a node that is patched, and a node that has been exploitable since 2019.",
+        "evidence": "Packet active_exploitation_notes: 'An aged (2019) flaw added to CISA KEV in September 2024, indicating renewed/ongoing active exploitation against internet-facing SAP Commerce Cloud (Hybris) instances that were never patched — likely opportunistic scanning against long-lived unpatched deployments rather than a fresh campaign. Not flagged as ransomware.' kev_date 2024-09-30; cisa_kev true; active_exploitation confirmed; poc_available true; patch_available true; patch_required_reboot false; live_patch_notes null. The NIST-800-53-SI-2 gap records that 'SAP shipped a fix in 2019, but KEV addition in 2024 shows five years of unpatched exposure among internet-facing instances — patch-SLA enforcement failed long-term, not just at disclosure'; the NIS2-Art21-vulnerability-management gap records that 'A five-year-old known-fixed flaw remaining exploitable at scale indicates an absent asset-inventory/patch-verification process for SAP e-commerce infrastructure.' Extension scope from affected (mediaconversion and virtualjdbc) and affected_versions.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2024-7593": {
     "name": "Ivanti Virtual Traffic Manager Authentication Bypass Vulnerability",
@@ -44218,7 +44915,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)",
@@ -44255,7 +44986,30 @@
         "adequate": false,
         "gap": "The KEV due date is 3 days; a standard 30-day flaw-remediation SLA leaves internet-facing SharePoint exploitable for weeks after weaponization."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this SharePoint Server deserialization flaw the packet gives a 3-day KEV clock opening 2026-07-16 against the 30-day flaw-remediation SLA the entry records as inadequate, an available vendor update, and no live-patch path — so the requirement is that the update is driven as an out-of-band emergency change on the KEV clock rather than scheduled into the next maintenance window. Two things decide whether the deployment is real. The fixed build has to be taken per version from the MSRC guide the packet points to, because the entry carries affected versions only as \"Microsoft SharePoint Server (see MSRC guide for supported-version build numbers)\" — there is no single build number to compare against across an estate running more than one SharePoint version. And completion is measured on the build the running SharePoint service reports, not on the installer's exit code or an \"approved\" state in the management console: patch_required_reboot is false, which means no host reboot is demanded, not that the fix is live the moment the package installs — the entry's own Essential Eight gap records a deploy-and-reboot interval through which the pre-auth deserialization path on ports 80/443 stays open, so a server whose update is installed but whose SharePoint services have not been restarted onto the new build is still executing vulnerable code and must be counted as exposed until it has. Order the estate by internet reachability first, since that is where the packet records exploitation, but do not stop there: the flaw needs no authentication, and the packet records this class being chained into hands-on-keyboard intrusion, which puts internal instances within reach of an attacker who is already inside. Precondition: this control only compresses the clock. It does nothing for a server exploited before the update landed, which confirmed exploitation and a 3-day due date make a live possibility rather than a hypothetical — that case belongs to the rebuild control below.",
+        "evidence": "NIST-800-53-SI-2 gap: \"The KEV due date is 3 days (2026-07-16 to 2026-07-19); a standard 30-day flaw-remediation SLA leaves internet-facing SharePoint exploitable for weeks after weaponization.\" NIS2-Art21-patch-management gap: \"Routine patch cadence is insufficient against a 3-day KEV clock; emergency out-of-band patching is required.\" ISO-27001-2022-A.8.8 gap: \"Periodic technical-vulnerability review cannot match the same-day exploitation window observed for critical SharePoint RCE.\" AU-Essential-8-Patch gap: \"...patch maturity alone leaves the pre-auth deserialization path on ports 80/443 open through the deploy-and-reboot interval.\" affected_versions: \"Microsoft SharePoint Server (see MSRC guide for supported-version build numbers)\". 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.\" active_exploitation_notes: KEV 2026-07-16 with a 3-day due date, confirmed active exploitation of internet-facing SharePoint servers, historically chained into web-shell drops and hands-on-keyboard intrusion.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet's attack path for this CVE ends in code execution as the SharePoint service account, typically followed by a web-shell drop, with exploitation confirmed and a 3-day KEV due date — so for any SharePoint Server that was internet-reachable and below the fixed build during the exposure window, compromise is the default working assumption and the update is not the end of the response. The update closes the deserialization path; it removes nothing an attacker already wrote through it and it does not invalidate credentials or session material taken from the box. Applied here that means: preserve configuration and content for evidence, rebuild the server from a known-good baseline rather than patching in place, and rotate the SharePoint service account credential along with anything else that account could reach. The hunt keys on what the packet actually documents rather than on assumed signals — a web shell placed in the content the server serves, and code running under the SharePoint service identity — so look for files newly written into the server's web-serving directories during the window and for child processes spawned by the SharePoint service identity, not for exploit-tool signatures or process crashes. The exploit is a single crafted serialized request that the server processes through its normal request path: it produces no crash to alert on, and because the attacker never authenticates, it produces no authentication event either, so an estate whose logging is sign-in-centric has no record that it happened. Preconditions, and they are the ones this control is most often over-claimed past: rebuild-not-patch presumes a known-good baseline and a content restore point predating the exposure window — where the earliest backup falls inside that window, restoring reinstates whatever was planted and the artifact hunt is the only remaining check; and it presumes the estate can say which servers were reachable, and on which build, during the window. Where that record does not exist, the scope is every internet-facing instance, not the ones someone remembers.",
+        "evidence": "Packet attack_vector: \"An unauthenticated attacker sends a crafted serialized .NET payload to an internet-facing SharePoint endpoint; unsafe deserialization triggers a gadget chain that executes attacker code as the SharePoint service account, typically followed by a web-shell drop.\" active_exploitation_notes: \"Added to CISA KEV 2026-07-16 with a 3-day due date, indicating confirmed active exploitation of internet-facing SharePoint servers. Ransomware use is not yet confirmed but deserialization RCE on SharePoint has historically been chained into web-shell drops and hands-on-keyboard intrusion.\" UK-CAF-B4 gap: \"System-security assurance based on scheduled hardening reviews will not detect exploitation of an unauthenticated code-execution path in real time.\" AU-Essential-8-Patch gap: \"...patch maturity alone leaves the pre-auth deserialization path on ports 80/443 open through the deploy-and-reboot interval.\" active_exploitation confirmed; cvss 9.8; patch_available true; live_patch_available false.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2026-25089": {
     "name": "Fortinet FortiSandbox OS Command Injection Vulnerability (CVE-2026-25089)",
@@ -44556,7 +45310,30 @@
         "adequate": false,
         "gap": "The 3-day KEV due date reflects that this was exploited as a zero-day before any patch existed; a standard 30-day flaw-remediation SLA is far longer than the observed exploitation window."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "The packet places this defect at exactly the layer this control governs: a missing authentication check (CWE-306) on a critical User Profiles administrative function in on-premises Microsoft SharePoint Server, reachable unauthenticated over the network via /_vti_bin/client.svc. The attack_vector shows the request-validation layer being stepped around rather than defeated — a crafted SOAP payload that omits the X-RequestDigest header and adds routing headers to reach an unvalidated code path — which is the pattern this control forbids: an administrative operation inheriting its authorization verdict from a validation layer that fronts it instead of deciding for itself. Bound to this product, the requirement is that each User Profiles administrative operation authorizes its caller inside its own code path, so a request that presents neither a digest nor a session cannot reach the operation at all, and that the farm's administrative surface is separated from the general-purpose client endpoint rather than sharing one entry point with it. This is also why the access-control gap cited on this entry cannot be closed operationally: the attacker never authenticates as any SharePoint principal, so per-account permission scoping is never consulted, and an access-control attestation showing every SharePoint administrator correctly assigned passes cleanly while this path stays open. Distinguishing test: on a staging farm at each of the three affected versions, issue unauthenticated SOAP requests to the User Profiles administrative endpoints through /_vti_bin/client.svc with the X-RequestDigest header omitted and the routing headers the packet describes added, and confirm each is refused before the operation runs. Preconditions: the endpoint-side authorization is a property the vendor update establishes — this control states what to verify, it does not implement it, and the packet records that update, which requires a reboot, as the remediation with no live-patching primitive available. Restricting which networks can reach the endpoint bounds the caller population only where the deployment permits it, and the packet's own boundary-protection gap records /_vti_bin/client.svc as an intended internet-facing service, so on a farm published to the internet that lever is unavailable and nothing stands between an untrusted caller and the missing check until the update and its reboot land.",
+        "evidence": "Packet fields: name = 'Microsoft SharePoint Server Missing Authentication for Critical Function Vulnerability'; cwe_refs = CWE-306; affected = 'On-premises Microsoft SharePoint Server: a missing authentication check on a critical User Profiles administrative function reachable unauthenticated via /_vti_bin/client.svc'; affected_versions = SharePoint Enterprise Server 2016, SharePoint Server 2019, SharePoint Server Subscription Edition; attack_vector = 'An unauthenticated attacker sends a crafted SOAP payload to /_vti_bin/client.svc targeting User Profiles administrative endpoints, omitting the X-RequestDigest header and adding routing headers to reach an unvalidated code path, elevating privileges over the network'; vector = 'Missing authentication for critical function in Microsoft Office SharePoint allows an unauthorized attacker to elevate privileges over a network'. Gap text used: ISO-27001-2022-A.5.15 = 'access control presumes authorisation is enforced at the function, but this flaw is a missing authentication check on a critical SharePoint operation reachable pre-auth over the network... a code defect A.5.15 cannot compensate for operationally'; UK-CAF-B4 = 'System security hardening cannot compensate for a code-level missing-authentication check on a critical administrative function reachable pre-auth'; NIST-800-53-SC-7 = 'Boundary protection does not help when the vulnerable /_vti_bin/client.svc endpoint is an intended internet-facing service'. Remediation state: 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": [
+          "ISO-27001-2022-A.5.15",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "On this entry the KEV listing and the patch arrived together: the packet records confirmed in-the-wild exploitation as a zero-day before the July 14 2026 patch, and CISA adding it to KEV the same day with a three-day due date. The control's 'whichever is later' trigger therefore fires at patch availability, and its four-hour requirement is the only reading that matches an unauthenticated network privilege-elevation reachable pre-auth on an internet-facing service at CVSS 9.8. Applied to this product: every on-premises SharePoint Enterprise Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition install is driven to its fixed build on the clock that opened 2026-07-14, counted per server rather than per farm, since a farm's patch record is not evidence about each server running the affected software. The packet records a vendor update that requires a reboot with no live-patching primitive, so a server that has installed the update but not completed its reboot is still executing the vulnerable code and must be counted as exposed rather than remediated; on servers carrying user-facing workloads the reboot is the step most likely to be deferred, and a deferral recorded as patched is the specific way this remediation goes wrong. Completion is measured on the build each server is actually running. Two things this control does not do, and both matter here. It gives nothing for the window before the fix: the flaw was exploited before any patch existed, so the 30-day flaw-remediation SLA the packet's gap describes was not merely slow, it had nothing to apply, and the coordinated-handling assumption of a disclosure-then-patch window that the EU gap names simply did not hold. And it does not evict an attacker already resident — the packet credits discovery to Mandiant incident responders and Google's FLARE team, stating the flaw was found inside active intrusions rather than routine research, so a farm that was network-reachable before the patch is a compromise-assessment and credential-rotation question, not something closed on the patch record.",
+        "evidence": "Packet fields: cisa_kev true, kev_date 2026-07-14; cvss 9.8; rwep_score 61; active_exploitation confirmed with active_exploitation_notes 'Confirmed exploited in the wild as a zero-day before the July 14 2026 patch; discovery credited to Mandiant incident responders and Google's FLARE team, indicating the flaw was found inside active intrusions rather than routine research. CISA added it to KEV the same day with a 3-day due date.'; affected_versions = SharePoint Enterprise Server 2016, SharePoint Server 2019, SharePoint Server Subscription Edition; 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 text used: NIST-800-53-SI-2 = 'The 3-day KEV due date reflects that this was exploited as a zero-day before any patch existed; a standard 30-day flaw-remediation SLA is far longer than the observed exploitation window'; AU-Essential-8-Patch = 'Essential 8 patch timelines (48 hours for internet-facing critical) still trail same-day active exploitation of an unpatched zero-day'; NIS2-Art21-vulnerability-handling = 'Coordinated vulnerability handling assumes a disclosure-then-patch window; an actively-exploited pre-patch zero-day gives operators no lead time to close exposure'. poc_available is false on this entry, so no public exploit code is claimed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-vulnerability-handling"
+        ]
+      }
+    ]
   },
   "CVE-2026-15409": {
     "name": "SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability",
@@ -44652,7 +45429,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",
@@ -44758,7 +45567,40 @@
         "adequate": false,
         "gap": "Boundary protection does not help when T3/IIOP management ports are exposed to the app tier or internet, which is common for WebLogic; the deserialization sink stays reachable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-128",
+        "name": "APPSERVER-REMOTING-PROTOCOL-RESTRICTION",
+        "description": "WebLogic's T3 and IIOP listeners are exactly the binary remoting-protocol class this control governs: non-HTTP endpoints that answer and begin reconstructing an object before any authentication happens, on the same server whose HTTP tier is the only part most WebLogic deployments are audited against. The packet places the flaw in the Fusion Middleware Core component and has an unauthenticated network attacker reaching it over T3 or IIOP for full server takeover, so the operative question is not whether the deployed application enforces its roles but which hosts can open a T3 or IIOP connection at all. Bound to this product it means enumerating every WebLogic Server instance at 12.2.1.3.0, 12.2.1.4.0 or 14.1.1.0.0 — the three versions the packet names, including any the estate does not carry under the WebLogic name because it was installed as part of a larger Oracle deployment — and for each restricting the T3/IIOP listen ports to the admin server, cluster peers and application hosts that legitimately speak those protocols, enforced by network ACL or host firewall rather than inferred from 'WebLogic is internal', with the protocol disabled outright on instances that use neither. The distinguishing test for this product: from a general application or user VLAN on a staging deployment, open a T3 connection to the managed server's listen port and confirm it is dropped before the server reads the serialized payload — an estate that passes WebLogic account, role and password audits still exposes this path in full, because no credential is presented anywhere in the attack the packet describes. Precondition, and it is where this control is most often over-claimed: restricting reachability bounds who can send the object, it does not repair the deserializer. Any host inside the permitted set reaches the sink unchanged, and the measure is unavailable on instances where T3 or IIOP must remain reachable for clustering or remote clients — for those the only lever is the Oracle update.",
+        "evidence": "Packet affected: 'Oracle WebLogic Server (Fusion Middleware, Core component) reachable over the T3 or IIOP protocols by an unauthenticated network attacker; exploitation yields full server takeover.' affected_versions: 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0. cwe_refs: CWE-502. The NIST-800-53-SC-7 gap records that boundary protection 'does not stop the flaw if the T3/IIOP admin ports are reachable from the app tier or internet; WebLogic management protocols are frequently left exposed, so segmentation alone leaves the deserialization sink live'. The ISO-27001-2022-A.8.8 gap records that technical-vulnerability management 'does not enforce protocol-level allowlisting of T3/IIOP', and the NIS2-Art21-vulnerability-management gap that the requirement 'does not mandate disabling or filtering the T3/IIOP protocols that carry the exploit, which is the only reliable compensating control when patching lags'. The UK-CAF-B4 gap names 'the exposed T3 port as the live entry point'. CISA KEV listed 2024-09-18, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 75.",
+        "gap_closes": [
+          "NIST-800-53-SC-7",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-125",
+        "name": "SERVICE-INTERNAL-PROTOCOL-DESERIALIZATION-HARDENING",
+        "description": "This is the half of the problem that survives after network placement has been fixed as far as it can be. The packet's attack path is a crafted serialized Java object arriving over T3 or IIOP which WebLogic deserializes through a vulnerable gadget chain, executing attacker code as the server process — so the listener is a trust boundary, and treating it as an internal convenience is what makes a routable path into a takeover. Applied to this deployment the control means the T3/IIOP handler does not inherit its safety from where the server sits: constrain which types the protocol path is permitted to reconstruct so that content arriving on the port cannot select the gadget chain, and require peer authentication on every remoting protocol the instance has enabled rather than only the one the applications happen to use — a deployment that authenticates its T3 clients but leaves IIOP enabled and open has not closed the packet's stated path, which names both. The distinguishing test: from an unauthenticated host that can route to the T3 port of a staging instance, send a serialized object of a type the application protocol never legitimately conveys and confirm the connection is refused before the object is reconstructed — a WebLogic instance that passes a patch-level and role audit while reconstructing arbitrary types from unauthenticated peers still exposes this sink and the next one found in the same class libraries. Precondition, stated plainly because the corpus keeps getting this wrong: an operator-side type constraint bounds the chains already known. The packet says exploitation runs through 'a vulnerable gadget chain', and a constraint expressed as known-bad chains is defeated by the next chain in the same libraries — so this reduces what can be sent at the sink, it does not make the port safe to expose, and it is not a substitute for the Oracle update, which is what removes this chain.",
+        "evidence": "Packet attack_vector: 'An unauthenticated attacker sends a crafted serialized Java object over the WebLogic T3 or IIOP protocol; WebLogic deserializes it through a vulnerable gadget chain and executes attacker code as the server process, resulting in full takeover.' cwe_refs: CWE-502. Vector text: 'Easily exploitable vulnerability allows unauthenticated attacker with network access via IIOP, T3 to compromise Oracle WebLogic Server.' The NIST-800-53-SC-7 gap records that segmentation alone 'leaves the deserialization sink live'. poc_available true, active_exploitation confirmed, CISA KEV 2024-09-18, CVSS 9.8.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock runs from the 2024-09-18 KEV listing, because the population that matters is the WebLogic instances still sitting at 12.2.1.3.0, 12.2.1.4.0 or 14.1.1.0.0 long after the Oracle fix shipped — the packet's own SI-2 gap describes monthly and quarterly enterprise-middleware remediation cycles against a class mass-scanned within days of an Oracle CPU, and its Essential-Eight gap the same mismatch at a two-week to one-month cadence. The packet records a vendor fix available, no host reboot required, and no live-patch primitive, which is the exact combination that makes this remediation look finished before it is: with no in-process patching path, a managed server that is running has already loaded the pre-fix classes and keeps executing them until that server process is restarted onto the updated libraries. Completion is therefore measured on the version each running WebLogic process reports, never on a patch-inventory row and never on the 'no reboot required' note — the absence of a machine reboot is not the fix being live in the JVM. Where a managed server cannot be restarted inside the SLA, the interim state is restricting reachability of its T3 and IIOP listeners, recorded as an open item with a dated restart rather than as remediation. And because active exploitation is confirmed, a public PoC exists and the outcome the packet states is full server takeover, an instance whose T3 or IIOP listeners were reachable during the exposure window belongs on the incident path — the update does not remove what was already placed on the server.",
+        "evidence": "Packet: cisa_kev true, kev_date 2024-09-18, active_exploitation confirmed, poc_available true, rwep_score 75, cvss 9.8. 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: 'Flaw-remediation SLAs run monthly/quarterly for enterprise middleware, but this class is mass-scanned within days of a Oracle CPU; the patch window vastly exceeds the observed exploitation window.' The AU-Essential-8-Patch gap: 'Application-patch maturity targets a 2-week/1-month cadence for internet-facing servers, still slower than the same-week weaponization seen for WebLogic deserialization chains.' affected states exploitation 'yields full server takeover'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2022-21445": {
     "name": "Oracle ADF Faces Deserialization of Untrusted Data Vulnerability",
@@ -44795,7 +45637,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",
@@ -44832,7 +45697,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",
@@ -45719,7 +46617,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)",
@@ -45756,7 +46675,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)",
@@ -45793,7 +46745,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",
@@ -46081,7 +47057,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",
@@ -46308,7 +47309,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)",
@@ -46345,7 +47379,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",
@@ -46755,7 +47812,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",
@@ -46861,7 +47942,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",
@@ -46898,7 +48002,37 @@
         "adequate": false,
         "gap": "Account-management controls do not detect that ESXi re-authorizes an AD group purely by name; deleting and re-creating 'ESXi Admins' re-grants full admin outside normal account provisioning review."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-036",
+        "name": "FLEET-CONTROL-PLANE-ADMIN-PRIVILEGE-TIER",
+        "description": "On an AD-integrated ESXi host the packet's grant path makes an ordinary directory operation equivalent to hypervisor root: the host gives full administrative access to members of a configured Active Directory group ('ESXi Admins' by default) matched by name, so whoever holds the AD permission to create a group with that name holds ESXi administration — which is what the packet describes the named actors doing, deleting and re-creating the group once they hold sufficient AD permissions. The control means that permission is classified and administered as a hypervisor-control-plane privilege in its own tier — just-in-time and approval-gated, held by an identity separate from routine directory administration, and enumerated explicitly rather than collapsed into 'admin' — instead of sitting inside general group-management delegation, where account-provisioning review never connects the operation to hypervisor access. That disconnect is the account-management gap this entry records. Scope the population from affected_versions, not from the headline product: ESXi 8.0 hosts reach the fix at ESXi 8.0 U3, ESXi 7.0 is recorded as having no patch with mitigation required, and VMware Cloud Foundation 4.x and 5.x AD-integrated ESXi is in scope on the same terms, so an estate that rolls 8.0 U3 and reports itself remediated leaves every 7.0 and Cloud Foundation host on the pre-fix grant path. Two preconditions decide whether this holds. patch_required_reboot is true and the packet records no live-patch path, with the vendor update requiring a reboot and being the remediation, so an 8.0 host that has taken the update but not rebooted is still running the name-matching code and must be counted as exposed. And on 7.0, where the packet states mitigation is required, repointing the host's configured admin group to a different name does not close the path — the host still matches by name, so an actor holding the AD permissions this attack already requires can create the new name just as easily. Only removing the host-administration grant from AD group membership removes the precondition, and a host that must retain AD user management stays exposed until it reaches a fixed build and reboots.",
+        "evidence": "Packet vector: a malicious actor with sufficient Active Directory permissions can gain full access to an ESXi host previously configured to use AD for user management by re-creating the configured AD group ('ESXi Admins' by default) after it was deleted from AD. affected: VMware ESXi (and vCenter-managed hosts) configured to use AD for user management, where the host grants full admin to members of a configured AD group matched by name. affected_versions: 'VMware ESXi 8.0 (fixed in ESXi 8.0 U3)', 'VMware ESXi 7.0 (no patch; mitigation required)', 'VMware Cloud Foundation 4.x / 5.x (AD-integrated ESXi)'. 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-AC-2 gap states account-management controls do not detect that ESXi re-authorizes an AD group purely by name, so deleting and re-creating 'ESXi Admins' re-grants full admin outside normal account provisioning review. active_exploitation confirmed; Microsoft observed Storm-0506, Storm-1175, Octo Tempest and Manatee Tempest.",
+        "gap_closes": [
+          "NIST-800-53-AC-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "The packet gives this entry an outcome, not just a flaw: Microsoft observed Storm-0506, Storm-1175, Octo Tempest and Manatee Tempest abusing it post-compromise to seize domain-joined ESXi hypervisors, ending in Akira and Black Basta deployment and mass-VM encryption, with CISA KEV flagging it 'Known' for ransomware. That is a hypervisor-control-plane compromise and the playbook has to exist before it happens, which is what the incident-handling and response-and-recovery gaps on this entry record as absent. Key the detection half on the behaviour the packet documents rather than on ransomware artefacts, which arrive after the encryption: deletion of the Active Directory group the host is configured to trust ('ESXi Admins' by default) followed by its re-creation, correlated with members of that group obtaining full administrative access on AD-integrated ESXi hosts. The pairing inside a short window is the distinguishing signal, because neither half is conclusive alone and nothing else is emitted — no exploit binary runs, no service crashes and no memory-corruption artefact appears; the host performs its configured group lookup and grants access exactly as designed, so file-integrity and signature-based endpoint tooling have nothing to match and a rule keyed on crashes or tool signatures would miss an attack behaving precisely as the packet describes. Size the response half to the blast radius the packet names — every VM on a seized host rather than one endpoint: invalidate the granted access and the host's AD integration, rotate credentials for every account that authenticated through an affected host during the exposure window, and rehearse recovery at fleet scale. Preconditions: this depends on directory security-event and ESXi host telemetry being collected and shipped off-host before the event, which is where a playbook written after the fact fails; and detection prevents nothing — it bounds the interval between the regrant and the encryption, and against the actors the packet names that interval is short.",
+        "evidence": "Packet active_exploitation_notes: flagged 'Known' for ransomware use in CISA KEV (added 2024-07-30); Microsoft observed Storm-0506, Storm-1175, Octo Tempest and Manatee Tempest abusing it post-compromise to seize domain-joined ESXi hypervisors, leading to Akira and Black Basta ransomware deployments and mass-VM encryption. attack_vector: after gaining a foothold with sufficient AD permissions, operators delete and re-create the 'ESXi Admins' group in Active Directory and the AD-joined host re-grants full administrative access by group name, giving hypervisor control to encrypt all hosted VMs. The NIS2-Art21-incident-handling gap states incident-handling controls do not flag AD-group re-creation as a hypervisor-takeover precursor, so the escalation goes unnoticed until ransomware fires; the UK-CAF-D1 gap states response-and-recovery planning does not anticipate hypervisor-layer admin regrant cascading into fleet-wide VM encryption, so no recovery path is pre-staged. rwep_score 79.",
+        "gap_closes": [
+          "NIS2-Art21-incident-handling",
+          "UK-CAF-D1"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-054",
+        "name": "BACKUP-TIER-NETWORK-ISOLATION",
+        "description": "This entry's backup gap states the failure directly: backups stored on the same hypervisor datastore are encrypted alongside the VMs when this ransomware-linked bypass fires, and the outcome the packet records is Akira and Black Basta mass-VM encryption once the actor holds full administrative access on an AD-integrated ESXi host. Applied here, the control means backup copies for VMs running on AD-integrated ESXi do not live on datastores those hosts present, and the backup tier's management and storage paths are not reachable using ESXi host administration — a separate credential path and a network position the hypervisor administrator does not inherit — so that seizing the hypervisor by re-creating the trusted AD group does not also hand over the recovery. Distinguishing test: from an account holding full administrative access on a staging AD-integrated host, attempt to enumerate, mount, alter or delete the backup repository for the VMs that host runs; anything reachable from that position is inside this CVE's blast radius, and a backup attestation showing only that jobs complete on schedule passes cleanly while every copy sits where the takeover reaches. Preconditions: this preserves a recovery path, it does not prevent the takeover and it does not repair the name-based grant that causes it. It also does nothing for a VM whose only protection is a snapshot on the datastore it runs from — that copy is inside the encrypted set by definition — and its value is bounded by whether restore has been exercised at the scale this flaw implies, an entire hypervisor's VM population rather than a single file.",
+        "evidence": "Packet AU-Essential-8-Backup gap: 'Essential-Eight backup guidance does not require offline/immutable copies resilient to an ESXi admin-takeover, so backups stored on the same hypervisor datastore are encrypted alongside the VMs when this ransomware-linked bypass fires.' active_exploitation_notes record Akira and Black Basta ransomware deployments and mass-VM encryption after actors seized domain-joined ESXi hypervisors; attack_vector ends in the attacker holding hypervisor control to encrypt all hosted VMs. cisa_kev true with kev_date 2024-07-30 and ransomware use flagged 'Known'; rwep_score 79. affected covers VMware ESXi (and vCenter-managed hosts) configured to use Active Directory for user management.",
+        "gap_closes": [
+          "AU-Essential-8-Backup"
+        ]
+      }
+    ]
   },
   "CVE-2023-45249": {
     "name": "Acronis Cyber Infrastructure (ACI) Insecure Default Password Vulnerability",
@@ -47186,7 +48320,22 @@
         "adequate": false,
         "gap": "Flaw remediation shipped as MS13-008, but the impacted IE is end-of-life; SI-2 does not force retirement of the unsupported browser that still renders attacker HTML."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-122",
+        "name": "EOL-ASSET-DECOMMISSION",
+        "description": "Both halves this control turns on are stated in the packet. patch_available is true — the flaw-remediation gap names MS13-008 as the fix that shipped — and the exploitation notes state that the impacted Internet Explorer is end-of-life and should be disconnected. So on a host still running Internet Explorer 6, 7 or 8, taking the update carrying this fix is an interim state; the terminal state is removing that browser from the host, because it remains exposed not only to this CDwnBindInfo use-after-free but to everything found in that rendering engine since its last servicing. Scope to what affected and affected_versions name: Internet Explorer 6, 7 and 8. The packet ties the use-after-free to the IE 6-8 rendering engine and gives no mapping into any other product, so treating every browser or HTML-rendering component in the estate as an instance of this CVE manufactures removal work against software no evidence implicates. Operationally: enumerate every host with IE 6, 7 or 8 installed, put each on a dated removal schedule measured against the 2024-07-23 KEV listing, and — because delivery here is a crafted page served from a site the victim trusts, which is how the December 2012 watering-hole compromise reached its targets — ensure that until removal completes IE 6-8 is not the browser handling untrusted web content, with browsing moved to a maintained one. That interim restriction is the disable-or-limit-legacy-browsers action the application-hardening gap names as missing, and its precondition must be stated: changing which browser is the default does not remove IE 6-8 from the host, so any application or workflow that launches it directly still reaches the same engine, and the restriction holds only where policy enforces it rather than user habit. Completion on the interim patch half is measured on the running host, not the update record: live_patch_available is false and the packet records that the vendor update requires a reboot and is the remediation, so a host that installed it without rebooting is still executing the vulnerable code. And because exploitation is confirmed with a public proof of concept and delivery is attacker-controlled web content, a host that browsed with IE 6-8 during the exposure window belongs on the incident path rather than being closed on the patch record — an update applied after the fact does not remove what a successful drive-by left behind.",
+        "evidence": "Packet fields: vector — \"Use-after-free vulnerability in Microsoft Internet Explorer 6 through 8 allows remote attackers to execute arbitrary code via a crafted web site that triggers access to an object that (1) was not properly allocated or (2) is deleted, as demonstrated by a CDwnBindInfo object, and exploited in the wild in December 2012.\" affected_versions: Internet Explorer 6, Internet Explorer 7, Internet Explorer 8; CWE-416; cvss 8.8, rwep_score 77; poc_available true; cisa_kev true with kev_date 2024-07-23 and active_exploitation confirmed. active_exploitation_notes — \"Exploited in the wild in December 2012 via watering-hole drive-by pages (notably the Council on Foreign Relations compromise) using a CDwnBindInfo use-after-free; re-added to CISA KEV 2024-07-23. The impacted Internet Explorer is end-of-life and should be disconnected.\" 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.\" framework_control_gaps: NIST-800-53-SI-2 — \"Flaw remediation shipped as MS13-008, but the impacted IE is end-of-life; SI-2 does not force retirement of the unsupported browser that still renders attacker HTML\"; ISO-27001-2022-A.8.8 — \"does not compel removal of legacy IE 6-8 clients, leaving a client-side RCE surface active\"; NIS2-Art21-vulnerability-management — duties \"do not specifically mandate decommissioning end-of-life browsers that remain drive-by exploitable\"; UK-CAF-B4 — the principle \"lacks a control forcing retirement of end-of-life clients, so IE 6-8 keeps rendering attacker HTML from watering-hole sites long after MS13-008\"; AU-Essential-8-App-Hardening — \"Application-hardening (disable/limit legacy browsers, block untrusted script) is exactly the missing control that would have blunted the drive-by.\"",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-vulnerability-management",
+          "UK-CAF-B4",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2022-22948": {
     "name": "VMware vCenter Server Incorrect Default File Permissions Vulnerability",
@@ -47764,7 +48913,40 @@
         "adequate": false,
         "gap": "Least-functionality controls rarely disable unprivileged user namespaces (kernel.unprivileged_userns_clone), which is what grants the CAP_NET_ADMIN needed to reach the nf_tables path."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-130",
+        "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "description": "The packet states this flaw's precondition rather than leaving it implicit: the local attacker needs CAP_NET_ADMIN before the netfilter nf_tables configuration path is reachable at all, and the packet's attack vector says that capability is often obtained through an unprivileged user namespace. For this CVE the control means unprivileged user-namespace creation (kernel.unprivileged_userns_clone) is disabled on every Linux host whose workloads do not genuinely require it, and each container is confined with an LSM profile plus a seccomp profile that does not hand it CAP_NET_ADMIN — because on a host still running a kernel without the nf_tables fix, that combination removes the entry condition while the reboot onto the fixed kernel is pending. On a container host the boundary claim itself is what is at stake: a confined workload able to create a user namespace holds CAP_NET_ADMIN inside it, creates an nft object referencing a set in a different table, deletes that table to free the set, and reclaims the dangling object as host root, so the confinement is not a boundary and the kernel is the only thing left. Distinguishing test: from a representative unprivileged container or an ordinary user session on a staging host running an affected kernel, create a user namespace and attempt the cross-table nft object/set configuration the packet describes, and confirm it is refused before the set can be freed. Two preconditions, both routinely skipped when this control is claimed. It closes only the user-namespace route — a process that already holds CAP_NET_ADMIN in the host's initial namespace (a container deliberately granted NET_ADMIN, a firewall or network-management daemon, a service account carrying the capability) reaches the identical path with unprivileged userns disabled, so that population must have the capability withdrawn or be counted as exposed until it reboots onto the fixed kernel. And it is unavailable on hosts that need unprivileged user namespaces to function — rootless container runtimes, build and CI hosts, sandboxes built on the same primitive — where the interim measure is detection plus the reboot, not this. Note also what is not available here: nf_tables is the host's own packet-filtering path, so unloading or blacklisting the subsystem is not the least-functionality answer the way an unused driver would be.",
+        "evidence": "Packet attack_vector: 'A local user obtains CAP_NET_ADMIN (often via an unprivileged user namespace), creates an nft object referencing a set in another table, deletes that table to free the set, and reclaims the dangling object to corrupt kernel memory and escalate to root.' The NIST-800-53-CM-7 gap records that 'Least-functionality controls rarely disable unprivileged user namespaces (kernel.unprivileged_userns_clone), which is what grants the CAP_NET_ADMIN needed to reach the nf_tables path'; the UK-CAF-B4 gap records that 'System-security assurance for Linux hosts seldom disables unprivileged user namespaces, the very setting that grants the CAP_NET_ADMIN this nf_tables use-after-free needs; CAF sets no requirement for that compensating control while the KEV-listed kernel LPE awaits a reboot'; the NIS2-Art21-patch-management gap records that patch-management obligations 'do not mandate the compensating control (disabling unprivileged userns) while kernel updates are pending.' An interim measure is needed because patch_available is true but patch_required_reboot is true and live_patch_available is false, with live_patch_notes stating 'No live-patching primitive for this product; the vendor update requires a reboot and is the remediation.' cisa_kev true (kev_date 2024-06-26), active_exploitation confirmed, poc_available true, rwep_score 73, cvss 7.8.",
+        "gap_closes": [
+          "NIST-800-53-CM-7",
+          "UK-CAF-B4",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "This is a local privilege escalation in the Linux kernel's netfilter nf_tables subsystem, so for this CVE the control means the distro kernel update carrying the backported nf_tables fix is driven across every affected host on the clock that opened with the 2024-06-26 KEV listing, rather than folded into the next quarterly maintenance window — with completion measured against the kernel the host is actually executing, not against the kernel package a configuration-management console reports as installed. The packet makes that distinction load-bearing: patch_required_reboot is true and live_patch_available is false, with the entry recording that the vendor update requires a reboot and is the remediation, so a host that has taken the new kernel package but has not rebooted onto it still runs the vulnerable code and must be counted as exposed. On the multi-user and long-uptime hosts most exposed to a local escalation the reboot is precisely the step that gets deferred, and a deferral recorded as 'patched' is the specific way this remediation goes wrong. Scoping cannot be done by kernel version number alone: the packet records the defect as present since v3.16-rc1 and lists distro kernels prior to the backported nf_tables patch (RHEL/Ubuntu/SUSE) as a separate affected population, so a vendor kernel with a lower upstream base may already carry the backport while a higher-numbered one does not — each host has to be compared against the fixed build its own distro published for that kernel line. Enumerate first the hosts where the flaw's precondition is the normal operating state rather than an anomaly: shared and multi-user systems, CI and build runners, and container hosts, anywhere unprivileged local code runs by design. Priority follows the packet rather than the CVSS band — a 7.8 with a local vector reads as a deferrable endpoint item, while the packet records confirmed active exploitation, a public PoC and a KEV listing for a primitive that converts any code execution as a local user into root, which is what makes it a containment step for a chain rather than a standalone item.",
+        "evidence": "Packet fields: 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-26; active_exploitation confirmed; active_exploitation_notes 'Added to CISA KEV 2024-06-26 as actively exploited. A use-after-free in the Linux kernel nf_tables (nft_object cross-table set reference) lets a local attacker with CAP_NET_ADMIN escalate to root. Ransomware association is unconfirmed.' poc_available true; cvss 7.8; rwep_score 73. Scope from affected ('Present since v3.16-rc1') and affected_versions ('Linux kernel >= 3.16-rc1 prior to the netfilter fix', 'distro kernels prior to the backported nf_tables patch (RHEL/Ubuntu/SUSE)'). The NIST-800-53-SI-2 gap records that 'Kernel patch-deployment cadence and reboot windows leave hosts exposed long after a working public LPE exists'; the AU-Essential-8-Patch gap that 'Patch-application timeframes for OS/kernel are measured in weeks, exceeding the exploitation window for a KEV-listed kernel LPE'; the ISO-27001-2022-A.8.8 gap that vulnerability management 'typically prioritizes remote flaws, deprioritizing a local kernel UAF that is in fact a ready root primitive for post-exploitation.'",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-003",
+        "name": "KERNEL-EXPLOITATION-DETECTION",
+        "description": "On hosts that cannot yet take the reboot, and on the hosts where unprivileged user namespaces must stay enabled for rootless containers or build sandboxes, detection is the only interim measure left — and the packet describes the exploitation behaviour precisely enough to key on it instead of on a guess. The rule keys on the sequence the packet's attack vector states: an unprivileged uid creating a user namespace, followed within the same session lineage by nf_tables netlink configuration traffic that creates an nft object referencing a set belonging to a different table and then deletes that table, paired with the outcome the packet names — a privilege transition to uid 0 in a process descended from that non-root session. Both halves are needed. Netlink nf_tables configuration on its own is what ordinary firewall tooling does all day on a firewall or container host, and a uid-0 transition on its own arrives with no context; it is the pairing inside a short window, from a session that began unprivileged, that separates this exploit from routine administration. Note what will not see it: nothing is compiled, no kernel module is loaded, no setuid binary changes, and the attacker uses the kernel's normal configuration interface, so file-integrity monitoring and signature-matching endpoint tooling have no artifact to match, and a rule written against process crashes or named exploit tooling would miss an attempt that behaves exactly as the packet describes — with poc_available true, the exact sequence is public and need not resemble any particular tool. Preconditions: this requires host audit or eBPF telemetry already being collected and shipped off-host before the attempt, which on shared multi-user hosts is exactly where it is least often enabled, and a rule authored after the fact against telemetry nobody collected produces nothing. Detection also does not prevent the escalation and does not undo root already obtained — it bounds the window to alert-and-response time during the period before the host reboots onto the fixed kernel.",
+        "evidence": "Packet attack_vector: 'A local user obtains CAP_NET_ADMIN (often via an unprivileged user namespace), creates an nft object referencing a set in another table, deletes that table to free the set, and reclaims the dangling object to corrupt kernel memory and escalate to root.' active_exploitation confirmed and poc_available true. The interim window exists because patch_required_reboot is true and live_patch_available is false ('No live-patching primitive for this product; the vendor update requires a reboot and is the remediation'). The NIS2-Art21-patch-management gap records that 'Patch-management obligations do not mandate the compensating control (disabling unprivileged userns) while kernel updates are pending' — this control covers that pending window on the hosts where disabling unprivileged user namespaces is not available.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      }
+    ]
   },
   "CVE-2022-24816": {
     "name": "OSGeo GeoServer JAI-EXT Code Injection Vulnerability",
@@ -47801,7 +48983,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",
@@ -48134,7 +49351,39 @@
         "adequate": false,
         "gap": "Least-functionality controls rarely disable unprivileged user namespaces (user.max_user_namespaces), leaving the nf_tables attack surface reachable to any local user."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-002",
+        "name": "LIVE-PATCH-CAPABILITY",
+        "description": "Four of the framework gaps cited on this entry say the same thing in four vocabularies: the nf_tables fix requires a reboot and Linux fleets do not take reboots on a KEV clock, so a ransomware-associated privilege escalation with a reliable public exploit stays live between assessment cycles. This packet is one of the few where that gap has a direct answer, because live_patch_available is true — the notes record that distributions shipping kernel livepatch (Ubuntu Livepatch, Oracle Ksplice, kpatch) can apply the nf_tables fix without reboot. For this CVE the control means the livepatch capability is deployed and exercised on production Linux hosts before the next kernel KEV listing, not procured in response to one: a capability first attempted during an incident is not a capability. Completion must be measured on the kernel that is running, since the whole point of the control is decoupling remediation from the reboot — a host whose fixed kernel package is installed but which is still executing the pre-fix image is exposed, and a host carrying the livepatch is remediated even though its package version has not moved. Preconditions, and both matter operationally. The livepatch path exists only where the distribution ships a livepatch stream carrying this specific nf_tables fix; a custom-built kernel, an unsupported release, or a host without the livepatch service has no such path and must take the reboot the packet records, so the fleet has to be split into those two populations rather than assumed uniform. And a livepatch covers the kernel running now — the on-disk kernel still has to reach a build carrying the fix (upstream commit f342de4e2f33e0e39165d8639387aa6c19dff660), so the reboot is deferred by this control, not cancelled by it.",
+        "evidence": "Packet: live_patch_available true; live_patch_notes: 'Distributions shipping kernel livepatch (Ubuntu Livepatch, Oracle Ksplice, kpatch) can apply the nf_tables fix without reboot; disabling unprivileged user namespaces is an immediate mitigation.' patch_available true, patch_required_reboot true. CISA KEV 2024-05-30; active_exploitation confirmed with CISA flagging known ransomware use; poc_available true with a widely-shared public exploit described as a reliable post-compromise privilege-escalation primitive across many distributions. affected_versions: Linux kernel 3.15 through 6.8-rc1 (prior to commit f342de4e2f33e0e39165d8639387aa6c19dff660). Cited gaps: SI-2 (kernel patching lags a public exploit within the KEV window), AU-Essential-8-Patch (OS-patch timelines do not match rapid weaponization), NIS2-Art21-patch-management (SLAs lag observed ransomware-linked exploitation), UK-CAF-B4 (patch expectations assume a maintenance-reboot window fleets rarely hit promptly).",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-130",
+        "name": "CONTAINER-HOST-NAMESPACE-ESCAPE-HARDENING",
+        "description": "The packet states the reach path rather than leaving it implicit: an unprivileged local user, often via an unprivileged user namespace, crafts nf_tables rules that make nf_hook_slow() double-free on an NF_DROP verdict carrying a drop error resembling NF_ACCEPT, and lands as root. On a container host that is the escape case — a confined workload able to create a user namespace reaches the kernel's netfilter code and becomes host root, so the isolation the deployment is designed around is not a boundary and the kernel is the only thing left. For this CVE the control means unprivileged user-namespace creation is disabled on every host whose workloads do not genuinely require it (the least-functionality gap on this entry names user.max_user_namespaces as the setting nobody sets), and each container is confined by three separate mechanisms that are not substitutes for one another: a mandatory-access-control profile (AppArmor or SELinux), a seccomp profile restricting the syscalls the workload may issue, and the runtime capability policy that drops the capabilities it does not need. The third is the one that bears on this path and the one most often assumed to be covered by the second — seccomp filters syscalls and cannot drop a capability, so a workload can satisfy a MAC-plus-seccomp requirement and still hold the network-admin capability that the precondition below records as retaining the primitive. Drop it explicitly in the capability policy for every workload that does not administer networking. Distinguishing test: from inside a representative unprivileged container on a staging host, attempt to create a user namespace and then program an nf_tables rule set, and confirm the attempt is refused before any verdict reaches the vulnerable path — a fleet that passes image-scanning and RBAC audits while permitting unprivileged user-namespace creation is still handing every confined workload this primitive. Preconditions, stated plainly because this control is easy to over-claim. The packet says 'often via an unprivileged user namespace', not always: disabling the namespace removes the usual reach path, it does not repair nft_verdict_init(), so any local context that still reaches nf_tables rule creation — a workload that legitimately requires user namespaces, or one holding network-admin capability by design — retains the primitive. It also does nothing about an attacker already resident, and nothing about one who has already escalated. Treat it as the immediate mitigation the packet names for the window before the livepatch or the fixed kernel and its reboot land, not as closure.",
+        "evidence": "Packet attack_vector: 'An unprivileged local user (often via an unprivileged user namespace) crafts nf_tables rules that make nf_hook_slow() double-free on an NF_DROP verdict carrying a drop error resembling NF_ACCEPT, corrupting kernel memory to escalate to root.' live_patch_notes: 'disabling unprivileged user namespaces is an immediate mitigation'. Cited gap NIST-800-53-CM-7: 'Least-functionality controls rarely disable unprivileged user namespaces (user.max_user_namespaces), leaving the nf_tables attack surface reachable to any local user.' active_exploitation confirmed with known ransomware use; poc_available true; patch_required_reboot true; live_patch_available true.",
+        "gap_closes": [
+          "NIST-800-53-CM-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "On this CVE the usual vulnerability-management evidence — a scan reporting the installed kernel package version — is wrong in both directions at once, which is why the technical-vulnerability-management gap here is about under-tracking rather than about speed. patch_required_reboot is true, so a host that installed the fixed kernel package and has not rebooted reads as patched while it is still executing the vulnerable nf_tables code and is fully exploitable by any local user. live_patch_available is true, so a host carrying the Ubuntu Livepatch, Ksplice or kpatch fix reads as unpatched while its running kernel is actually fixed. An A.8.8 attestation built on either reading describes something other than the fleet's exposure. For this CVE the control means the scan is taken against the running kernel and its livepatch state, and the version judgement is made against the distribution's build carrying the backport of commit f342de4e2f33e0e39165d8639387aa6c19dff660 — not against upstream 6.8-rc1, because distribution kernels carry the fix on their own version numbers and an 'older than 6.8-rc1' rule misjudges every one of them. It must also treat a host that has only the mitigation the packet names, unprivileged user namespaces disabled, as mitigated rather than remediated, so the two states stay distinguishable on the report. Distinguishing test: stage one host with the fixed package installed but not rebooted and one host livepatched without the package upgrade, run the scan against both, and confirm the first is reported exposed and the second remediated; a scanner that gets either backwards is generating the compliance record while real exposure is unknown. Precondition: this is a measurement control. It remediates nothing on its own — its whole value is that the livepatch and reboot work driven by the other controls on this entry can be verified rather than assumed.",
+        "evidence": "Packet: patch_available true, patch_required_reboot true, live_patch_available true, live_patch_notes naming Ubuntu Livepatch, Oracle Ksplice and kpatch as able to apply the nf_tables fix without reboot and disabling unprivileged user namespaces as an immediate mitigation. affected_versions: Linux kernel 3.15 through 6.8-rc1 (prior to commit f342de4e2f33e0e39165d8639387aa6c19dff660). Cited gap ISO-27001-2022-A.8.8: 'Technical-vulnerability management on Linux fleets under-tracks kernel LPE flaws that require reboots to remediate.' CISA KEV 2024-05-30; active_exploitation confirmed with known ransomware use; poc_available true.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-24919": {
     "name": "Check Point Quantum Security Gateways Information Disclosure Vulnerability",
@@ -48795,7 +50044,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",
@@ -50314,7 +51588,31 @@
         "adequate": false,
         "gap": "Identity-management control does not, by itself, mandate channel binding / EPA for legacy NTLM, leaving relayed authentication to Exchange viable."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-025",
+        "name": "CONFIGURATION-SIDE-LIVE-PATCH-INVENTORY",
+        "description": "For Microsoft Exchange Server the configuration-side path this control names is Extended Protection, and the packet makes it the load-bearing half rather than an optional extra: the affected condition is stated as Exchange Server where Extended Protection is not enforced, and the flaw-remediation gap records that applying the Exchange update is not enough on its own because Extended Protection must be actively enabled. Bound to this deployment that means every Exchange Server 2016 and 2019 host is inventoried by whether Extended Protection is enforced on the web endpoints that terminate authentication — Exchange Web Services first, because EWS is the endpoint the packet names as the relay target — and that this state is tracked, tested and driven as its own item rather than riding along with the CU14 upgrade project, since the packet describes CU14 as enabling Extended Protection by default rather than as the only route to it. Extended Protection is also exactly what the identity controls cited on this entry are missing: the packet's federated identity-management gap says the control does not by itself mandate channel binding for legacy NTLM, and channel binding at the EWS endpoint is what makes a relayed NetNTLM authentication fail instead of succeeding as the victim. Read the control's name carefully against this packet: live_patch_available is false, so enabling Extended Protection is a configuration change, not a vendor live-patch primitive, and it does not substitute for the remediation the packet records — applying the fixed release and rebooting. That is the precondition on treating this as closure: patch_required_reboot is true, so a server that took the February 2024 update but has not restarted is still running the vulnerable code. A second precondition is that Extended Protection bounds the relay into Exchange and does nothing about the step the attack begins with; the packet's network-security gap names disabling or segmenting NTLM and blocking authentication-coercion RPC as separate measures this control does not supply. And because active exploitation against internet-facing Exchange is confirmed, a server that was reachable while Extended Protection was off belongs on the incident path rather than being closed on the configuration change.",
+        "evidence": "Packet affected: 'Microsoft Exchange Server; when Extended Protection is not enforced, an attacker can relay a coerced NTLM authentication to Exchange Web Services and act as the victim (privilege escalation). Fixed by CU14 enabling Extended Protection by default.' affected_versions: 'Exchange Server 2016 and 2019 without Extended Protection (prior to Feb 2024 update / CU14)'. NIST-800-53-SI-2 gap: 'Applying the Exchange update is not enough on its own — Extended Protection must be actively enabled — so a standard patch-and-reboot SLA leaves the relay path open even on \"patched\" servers.' ISO-27001-2022-A.5.16-Federated gap: 'Identity-management control does not, by itself, mandate channel binding / EPA for legacy NTLM, leaving relayed authentication to Exchange viable.' NIS2-Art21-network-security gap names disabling/segmenting NTLM and blocking authentication-coercion RPC as what stops the relay chain. attack_vector: an attacker coerces a privileged account to authenticate (e.g. PetitPotam) then relays the NTLM credential to the Exchange EWS endpoint. 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.' CWE-287, CISA KEV listed 2024-02-15, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 80.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-IA-2",
+          "ISO-27001-2022-A.5.16-Federated",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-018",
+        "name": "SCANNER-PAPER-COMPLIANCE-TEST",
+        "description": "The paper-compliance shape this control exists to catch is precisely the failure the packet records for this CVE. A scanner that reads the Exchange build, sees the February 2024 update present and reports the server remediated has measured the one thing that does not settle the question: the condition the packet ties exploitation to is Extended Protection not being enforced, and that is a configuration state the build number does not carry. The operational test for this product is therefore per-server and per-endpoint — for every Exchange Server 2016 and 2019 host, produce the enforced/not-enforced state of Extended Protection on the web endpoints that accept authenticated traffic, Exchange Web Services first because the packet names EWS as the relay target, and treat a host that cannot produce that state as unverified rather than as compliant. The distinguishing test keys on the behaviour the packet documents rather than on a version string or a tool signature: on a staging Exchange server, coerce an account to authenticate and relay that NetNTLM authentication to the EWS endpoint — the exact sequence in the packet's attack vector, using the publicly available coercion and relay tooling its application-hardening gap names — and confirm the relayed authentication is refused rather than accepted as the victim. An estate whose patch report is green and whose user-application-hardening attestation covers Exchange passes both checks while that relay still succeeds, which is what makes the version-only scan and the hardening attestation paper compliance here. The same inventory must carry restart state alongside configuration state: the packet gives patch_required_reboot true with no live-patch path and states remediation requires applying the fixed release and rebooting, so a host that has installed the update and not restarted onto it is not remediated no matter what either check reports.",
+        "evidence": "Packet NIST-800-53-SI-2 gap: 'Applying the Exchange update is not enough on its own — Extended Protection must be actively enabled — so a standard patch-and-reboot SLA leaves the relay path open even on \"patched\" servers.' AU-Essential-8-App-Hardening gap: 'Application-hardening maturity does not enumerate Exchange Extended Protection or NTLM channel-binding, so a \"hardened\" server still relays a coerced NetNTLM authentication to EWS via public impacket/PetitPotam tooling; patching without enabling EPA leaves the relay path open.' affected_versions: 'Exchange Server 2016 and 2019 without Extended Protection (prior to Feb 2024 update / CU14)'. attack_vector: coerce a privileged account to authenticate (e.g. PetitPotam), relay the NTLM credential to the Exchange EWS endpoint; without Extended Protection the relay succeeds. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' CISA KEV 2024-02-15, active_exploitation confirmed, poc_available true, CVSS 9.8, RWEP 80.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-App-Hardening"
+        ]
+      }
+    ]
   },
   "CVE-2024-21412": {
     "name": "Microsoft Windows Internet Shortcut Files Security Feature Bypass Vulnerability",
@@ -51099,7 +52397,38 @@
         "adequate": false,
         "gap": "Identity-and-access-control assurance is undermined when authentication can be skipped entirely; B2 assumes the auth gate is reached for protected functions."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "Bound to this Ivanti EPMM and MobileIron Core entry, the control's clock opens at the 2024-01-18 KEV listing and closes only when each affected server has come up on the fixed release. Two things make that harder than the usual appliance ticket. First, the population is two separately-branded product lines: the packet gives Ivanti EPMM 11.10 and older on one side and MobileIron Core 11.7 and below on the other, so an inventory that queries for 'Ivanti EPMM' misses MobileIron Core-branded servers still in service, and those are the instances most likely to sit outside the current vendor-support relationship that drives patch notifications. Second, the packet records that remediation requires applying the fixed release and rebooting, with no live-patch mechanism available, so a server holding the fixed release staged but not yet restarted is still serving the bypass and must be counted as exposed rather than as patched — on an MDM server that reboot is the step most likely to be deferred, because taking it interrupts device check-in and enrollment. Priority follows the packet rather than a queue position: a public proof-of-concept, EPSS near 1.0, a KEV ransomware flag, and exploitation that began shortly after the public technical details make this a containment step whose delay is measured against attackers already operating, not a scheduled maintenance item.",
+        "evidence": "Packet fields for CVE-2023-35082: cisa_kev true with kev_date 2024-01-18, active_exploitation confirmed, cvss 9.8, rwep_score 82, poc_available true, patch_available true, patch_required_reboot true, live_patch_available false, and live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' affected_versions names both product lines: 'Ivanti EPMM 11.10 and older (11.9, 11.8, ...)' and 'MobileIron Core 11.7 and below'. active_exploitation_notes records CISA-confirmed exploitation in January 2024 against internet-facing EPMM / MobileIron Core MDM servers, a KEV ransomware flag, and EPSS ~1.0. The NIST-800-53-SI-2 gap states the flaw was exploited shortly after Rapid7's public details, faster than a routine flaw-remediation SLA closes an internet-facing MDM server.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-129",
+        "name": "ENTERPRISE-ERP-MANAGEMENT-FUNCTION-AUTHENTICATION",
+        "description": "EPMM's authentication filter is where the product makes its authentication decision, and this CVE is that layer failing open: the packet has an unauthenticated attacker sending a request whose URI prefix bypasses the filter, so the restricted management-API functions behind it run without any access-control decision ever being taken for that request. Bound to this product, the control means each management-API function on EPMM and MobileIron Core authorizes its own caller rather than inheriting a verdict from the filter that fronts it, and the administrative portion of the surface is separated from the enrollment portion so an untrusted caller cannot present a request to that filter for administrative functions at all. This is also why the least-privilege and identity-side attestations an estate carries do not reduce this flaw: the attacker never authenticates as any EPMM operator, so per-account privilege scoping is never consulted and the account model an identity-and-access attestation examines is bypassed rather than abused. Distinguishing test: from a segment with no administrative need for the MDM console, send unauthenticated requests carrying the URI-prefix form to each management-API endpoint on a staging EPMM 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, and it is a hard one on this product: the endpoint-side authorization is a property the vendor fixed release establishes, not something an operator can add, and the packet records that the platform must by design remain internet-reachable for mobile enrollment. So restricting reachability bounds only the administrative portion of the surface; it cannot cover the enrollment path, and it gives nothing against a caller that can reach whatever must stay exposed. Until the fixed release and its reboot land, this control states what to verify rather than what to deploy.",
+        "evidence": "Packet fields for CVE-2023-35082: cwe_refs CWE-287, and attack_vector states that an unauthenticated attacker sends a crafted request whose URI prefix bypasses the authentication filter, reaching MDM management-API endpoints to read user PII and alter server configuration. The NIST-800-53-AC-3 gap states that access enforcement is defeated at the source — a crafted URI prefix bypasses the authentication filter, so the access-control decision point never runs for the sensitive API. The UK-CAF-B2 gap states that identity-and-access-control assurance is undermined when authentication can be skipped entirely, because B2 assumes the auth gate is reached for protected functions. The NIS2-Art21-network-security gap records that the device must be internet-reachable by design for mobile enrollment. patch_available is true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-037",
+        "name": "FLEET-COMPROMISE-IR-PLAYBOOK",
+        "description": "EPMM and MobileIron Core are the control plane for every mobile device they manage, and the packet places the attacker inside that control plane rather than merely at its door: unauthenticated access to restricted management-API endpoints, reading user PII and altering server configuration, chainable toward remote code execution, on a KEV entry flagged for known ransomware use. That is why the fixed release and its reboot do not by themselves resolve an instance that was internet-reachable during the exposure window — configuration the attacker changed through the bypass is carried forward by the upgrade, and PII already read is gone regardless of what version the server later reports. Bound to this platform, the playbook items are: audit EPMM server configuration and every configuration profile pushed to the fleet since the start of the exposure window against a known-good baseline; invalidate device-trust state and revoke certificates issued or pushed through the platform during that window; rotate credentials for any account that authenticated through the platform; and define, in advance, the criteria under which downstream managed devices are quarantined. This is the half of the response that still has value after the patch record reads clean, and it is what turns a technical-vulnerability finding on one server into the fleet-wide isolation decision the compromise actually requires.",
+        "evidence": "Packet fields for CVE-2023-35082: active_exploitation confirmed, kev_date 2024-01-18, and active_exploitation_notes stating that unauthenticated attackers reach restricted API endpoints to read user PII and make server changes, that it can be chained toward RCE, and that KEV flags known ransomware use. attack_vector describes the result as a foothold on the control plane for the entire managed mobile fleet. The ISO-27001-2022-A.8.8 gap states that technical-vulnerability management does not by itself force emergency isolation of an MDM control plane whose compromise exposes the entire managed fleet. 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.'",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2024-0519": {
     "name": "Google Chromium V8 Out-of-Bounds Memory Access Vulnerability",
@@ -51531,7 +52860,38 @@
         "adequate": false,
         "gap": "Technical-vulnerability management provides no play for a KEV appliance zero-day with only a temporary mitigation, so exposed devices stayed reachable during active exploitation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "Ivanti Connect Secure and Policy Secure are the VPN-concentrator class this tier names, and the defect is in the web component that faces unauthenticated internet clients by design — the device is the trust boundary, which is why a standard 14- or 30-day application SLA is the wrong instrument regardless of the 8.2 base score. For this CVE the tier means the clock opened at the 2024-01-10 KEV listing and closes only at the reboot of every affected unit, covering Connect Secure 9.x and 22.x and Policy Secure 9.x and 22.x — the packet names all four, and an estate standardised on Policy Secure while treating this as a Connect Secure advisory will sweep clean and stay exposed. The packet records a vendor fix with no live-patch mechanism and a reboot requirement, so a unit that has taken the fixed release but has not been rebooted onto it is still running the vulnerable web component and must be counted as exposed; on a remote-access gateway that reboot is also the step most likely to be deferred, because taking it drops every live session, and a deferral recorded as patched is the specific way this remediation goes wrong. The tier's alternative limb — isolation of the vulnerable interface — needs its precondition stated for this product rather than inherited from the firewall case: the vulnerable web component IS the remote-access service, so there is no segment to move it behind. The only forms isolation takes here are withdrawing remote access for the duration, or restricting the source addresses permitted to reach the gateway, and on a device whose purpose is terminating arbitrary remote workers the second is usually unavailable. Where neither is possible the honest record is an accepted exposure with the reboot dated, not a compensating control marked in place.",
+        "evidence": "Packet name: 'Ivanti Connect Secure and Policy Secure Authentication Bypass Vulnerability'. affected: 'Web component of Ivanti Connect Secure (ICS, formerly Pulse Connect Secure) 9.x and 22.x and Ivanti Policy Secure; directory traversal lets a remote attacker bypass control checks and access restricted resources without authentication.' affected_versions lists Connect Secure 9.x, Connect Secure 22.x, Policy Secure 9.x and Policy Secure 22.x. cisa_kev true, kev_date 2024-01-10, active_exploitation confirmed, poc_available true, rwep_score 82, cvss 8.2. 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-SC-7 gap: 'Boundary protection does not prevent the appliance itself, which is the boundary, from being bypassed via path traversal; the flaw lives in the very device meant to enforce the perimeter.' active_exploitation_notes records a mass-exploited zero-day chaining with CVE-2024-21887 for unauthenticated RCE.",
+        "gap_closes": [
+          "NIST-800-53-SC-7"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-038",
+        "name": "MITIGATION-ACTIVE-PATCH-PENDING-VERDICT-CLASS",
+        "description": "This entry is the case the three-state verdict exists for, and the packet supplies the evidence in its own gap text: the Essential-Eight objective was overtaken by zero-day mass exploitation before a patch existed, and the initial vendor guidance was a mitigation release file rather than a fix, while ISO A.8.8 had no play at all for a KEV-listed appliance zero-day carrying only a temporary mitigation. An estate in that condition is in state (b) — vendor mitigation loaded, no fixed build installed — and it must be reported as its own compensating-control state with a dated action item, never folded into a green 'patched per SLA' row. The residual risk in state (b) is specific rather than theoretical here: the mitigation is a rule applied to the same request path the flaw lives in, so a defect in it or an incomplete application on any unit reopens the pre-auth traversal, and it does nothing whatever about an appliance already exploited before the file was loaded — which, for a flaw the packet describes as mass-exploited as a zero-day, is a live possibility on any unit that was internet-reachable. State (a) for this CVE is reached only when the unit is on the fixed release and has been rebooted onto it, because the packet records no live-patch mechanism and a reboot requirement; a unit showing the fixed release with the reboot outstanding is still state (b) at best. Distinguishing test: pull the current verdict for every Connect Secure and Policy Secure unit and require each to name which of the three states it is in and the evidence for that state — an appliance register showing green flaw-remediation rows for units carrying only the mitigation file is recording compliance for an exposure under active mass exploitation.",
+        "evidence": "The AU-Essential-8-Patch gap on this entry: 'The patch objective was overtaken by zero-day mass exploitation before a patch existed — initial guidance was a mitigation.release XML, not a fix, leaving a control gap the SLA cannot cover.' The ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management provides no play for a KEV appliance zero-day with only a temporary mitigation, so exposed devices stayed reachable during active exploitation.' Packet: 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 confirmed; active_exploitation_notes: 'Mass-exploited zero-day (CISA-flagged ransomware-associated)'. cisa_kev true, kev_date 2024-01-10, rwep_score 82.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet describes exactly the conditions under which patch-in-place is the wrong default: a mass-exploited zero-day on an internet-facing gateway, CISA-flagged ransomware-associated, with the traversal chaining to CVE-2024-21887 command injection for unauthenticated RCE across the Connect Secure and Policy Secure fleet. The runbook for these appliances must therefore assume that any Connect Secure 9.x or 22.x or Policy Secure 9.x or 22.x unit reachable from the internet during the exposure window was compromised until evidence says otherwise, and default to capturing the running configuration for analysis, rebuilding the appliance onto the fixed release, and rotating every credential and certificate the device held or brokered — VPN user credentials and session material, the appliance's own administrative accounts, any directory or authentication-service account it bound with, and its device certificates. This is precisely what the two network-security gaps on the entry miss: NIS2's obligations and CAF's resilient-network expectations both treat the remote-access gateway as a trusted enforcement point, so once it reports the fixed version the framework's questions are answered — while an implant installed through the RCE chain survives the upgrade untouched and keeps the position the gateway grants. Preconditions, all three load-bearing: the rebuild only helps if the unit comes up on the fixed release and is rebooted onto it, since the packet records no live-patch path and a reboot requirement; a configuration restored wholesale from a backup taken after the exposure began can carry the attacker's changes back in, so it is reviewed rather than replayed; and rebuilding the appliance does nothing about access the attacker already converted into a foothold behind it, so the internal follow-on investigation and the credential rotation are part of this runbook rather than a later phase.",
+        "evidence": "Packet active_exploitation_notes: 'Mass-exploited zero-day (CISA-flagged ransomware-associated); a remote unauthenticated attacker uses directory traversal in the web component to bypass control checks and reach restricted endpoints, and chains with CVE-2024-21887 command injection for unauthenticated RCE across the Ivanti Connect Secure / Policy Secure fleet.' attack_vector: the traversal 'slips past the authentication/control checks, exposing restricted endpoints and priming the paired CVE-2024-21887 command injection for full RCE'. affected_versions: Connect Secure 9.x and 22.x, Policy Secure 9.x and 22.x. The NIS2-Art21-network-security gap: 'Network-security obligations treat the VPN concentrator as a trusted control, but this pre-auth bypass turns the enforcement point into the entry point, which the control does not anticipate.' The UK-CAF-B4 gap: 'Resilient-network expectations assume the remote-access gateway is trustworthy; they do not require compensating segmentation for a gateway that is itself the vulnerable, internet-facing asset.' patch_required_reboot true, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying the fixed release and rebooting.' rwep_score 82, poc_available true, cisa_kev true, kev_date 2024-01-10.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2024-21887": {
     "name": "Ivanti Connect Secure and Policy Secure Command Injection Vulnerability",
@@ -52786,7 +54146,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",
@@ -54049,7 +55434,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",
@@ -54106,7 +55525,41 @@
         "adequate": false,
         "gap": "System-security outcomes assume management interfaces enforce authentication; an unauthenticated file upload/download endpoint defeats that assumption without dedicated management-plane isolation."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The SRX Series is a perimeter firewall — the trust boundary itself — and the packet describes an unauthenticated request to webauth_operation.php uploading and downloading arbitrary files through J-Web, with the write primitive chaining into pre-auth remote code execution via the PHPRC flaw the packet names as its chaining partner. That is the case this tier exists for, and this entry is also a clean demonstration of why a CVSS-keyed SLA misfiles it: the base score is 5.3, which routes the item to a routine queue, while the packet's own flaw-remediation gap records that the medium score understates a pre-auth upload/download primitive documented as part of a public RCE chain, and the entry's RWEP is 77. For this device the requirement is that remediation runs on the tier clock opened by the 2023-11-13 KEV listing — the fixed Junos release for whichever train is in service (21.2R3-S8, 21.4R3-S6, 22.1R3-S5, 22.2R3-S3, 22.3R3-S2, 22.4R2-S2 or 22.4R3, 23.2R1-S2 or 23.2R2) — or, where the maintenance window cannot be taken inside it, J-Web is made unreachable from untrusted networks until it can. Cover every train the packet names: an estate standardised on 22.4 or 23.2 is exposed at a different fixed build than one on 21.2, and a sweep scoped to a single train reports clean across the rest. Completion is measured on the release each chassis is actually running: the packet records no live-patch mechanism and remediation requiring the fixed release plus a reboot, so a device staged with the image but not rebooted onto it is still serving the unauthenticated endpoint. Precondition on the isolation alternative: restricting or disabling J-Web bounds who can reach webauth_operation.php, it does not repair the missing authentication check — anything inside a permitted management segment still reaches it unauthenticated — and it is unavailable where J-Web is the operational management path for the device. It is a holding measure for the window before the fixed release and its reboot land, not a closure.",
+        "evidence": "The packet records CISA KEV 2023-11-13, active_exploitation confirmed, poc_available true, CVSS 5.3 against RWEP 77. The NIST-800-53-SI-2 gap states the medium base score understates a preauth upload/download primitive documented as part of a public RCE chain and that CVSS-keyed patch SLAs deprioritize it wrongly; the AU-ISM-1546 gap states patching within the ISM window does not mandate restricting the exposed webauth_operation.php endpoint; the ISO-27001-2022-A.8.8 gap states technical-vulnerability management under CVSS-medium scoring deprioritizes this endpoint, delaying remediation of an actively-exploited preauth flaw. patch_available true, patch_required_reboot true, live_patch_available false with live_patch_notes recording that remediation requires applying the fixed release and rebooting. affected_versions lists 21.2 prior to 21.2R3-S8, 21.4 prior to 21.4R3-S6, 22.1 prior to 22.1R3-S5, 22.2 prior to 22.2R3-S3, 22.3 prior to 22.3R3-S2, 22.4 prior to 22.4R2-S2 / 22.4R3, and 23.2 prior to 23.2R1-S2 / 23.2R2.",
+        "gap_closes": [
+          "AU-ISM-1546",
+          "ISO-27001-2022-A.8.8",
+          "NIST-800-53-SI-2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-134",
+        "name": "DEVICE-MANAGEMENT-GATEWAY-CONFIG-ENDPOINT-AUTH-INPUT-NEUTRALIZATION",
+        "description": "J-Web is the device-management gateway on the SRX Series, and webauth_operation.php is the file-accepting endpoint on it that makes no authorization decision at all — the packet's access-enforcement gap states outright that access enforcement is exactly what is missing, and that it is missing for both the upload and the download direction. Bound to this product, the control means that endpoint authorizes its caller before the request is processed at all, in both directions, so an unauthenticated caller can neither write a file onto the firewall nor read one off it; and that no SRX is left with J-Web reachable from a segment with no operational need to manage the device, least of all from the internet. The read direction deserves separate attention on a firewall and is the half most often dropped: the same unauthenticated endpoint returns arbitrary files from the device that holds the configuration, and the packet records the read primitive as exposing sensitive files, so treating this purely as an upload bug leaves the disclosure path uncounted and closes the finding while the configuration is still readable. Distinguishing test: from a segment with no management role, issue an unauthenticated upload and an unauthenticated download request against webauth_operation.php on a staging SRX and confirm each is refused before any file is written or returned — an estate that attests every J-Web administrator authenticates at login passes cleanly while this path stays wide open, because the attacker never presents a J-Web account and no access decision is ever consulted. Precondition: the endpoint-side authorization is a property the fixed Junos release establishes — this control states what to verify, it does not implement it. Until that release and its reboot land, restricting which segments reach J-Web bounds who can send the request but leaves the endpoint fully exploitable to anything inside the permitted segment, so a compromised jump host or workstation already in the management network satisfies the exploit's only precondition in full.",
+        "evidence": "The packet's affected field records the J-Web interface on Juniper Junos OS SRX Series with unauthenticated arbitrary file upload and download via webauth_operation.php, and the attack_vector states the request lacks an authentication check, that the write primitive chains with the PHPRC flaw for pre-auth RCE, and that the read primitive exposes sensitive files. The NIST-800-53-AC-3 gap states access enforcement is exactly what is missing — webauth_operation.php requires no authentication for both upload and download of files — and that until patching, no access policy compensates. The NIST-800-53-SC-7 gap states boundary protection that exposes 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 states network-security duties do not mandate management-plane isolation, so an exposed J-Web keeps the unauthenticated upload/download reachable, and the UK-CAF-B4 gap states an unauthenticated file upload/download endpoint defeats the assumption that management interfaces enforce authentication. patch_available true with patch_required_reboot true and live_patch_available false.",
+        "gap_closes": [
+          "NIS2-Art21-network-security",
+          "NIST-800-53-AC-3",
+          "NIST-800-53-SC-7",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The primitive here is an unauthenticated arbitrary file write onto a perimeter firewall, and the fixed Junos release removes the write path without removing anything already written through it. So for any SRX whose J-Web was reachable from an untrusted network during the exposure window, the default disposition is configuration extraction, rebuild from a known-good image, and rotation of the credentials and keys the device's configuration held or that transited it — not upgrade-in-place followed by closing the flaw-remediation ticket. Both primitives argue for it: the write half means a file placed on the device survives the upgrade intact, and the read half means the configuration was retrievable unauthenticated, so the material inside it must be treated as disclosed rather than as protected by reaching the fixed release. The packet records confirmed active exploitation, a public proof-of-concept, and this CVE as part of the J-Web pre-auth chain, which is what makes the upgrade-only disposition insufficient rather than merely conservative. Scoping precondition, which is where this control is most often over-applied: this disposition attaches to units whose J-Web was actually reachable during the window, not to every SRX in the estate — the packet's own note that this entry's EPSS is far below its sibling CVEs, reflecting narrower standalone weaponization, is a reason to establish reachability per unit rather than to rebuild a whole fleet. It is also worth stating what cannot be leaned on when establishing that: because the flaw itself grants an unauthenticated write to the device's filesystem, records held only on the device are not a trustworthy basis for concluding a unit was untouched, so absence of local evidence on a reachable unit is inconclusive rather than exculpatory. Rebuild does not prevent the exploitation and does nothing for a unit still on a vulnerable release; it is what makes the fixed release a genuine end-state on a unit that was exposed.",
+        "evidence": "The packet's attack_vector records an unauthenticated attacker uploading and downloading arbitrary files via J-Web, giving both a file-write primitive for RCE chaining and arbitrary-file read, and the vector records the resulting loss of integrity or confidentiality with possible chaining to other vulnerabilities. active_exploitation is confirmed with poc_available true, the entry is described as part of the Juniper J-Web pre-auth chain, and it was CISA KEV-listed 2023-11-13. patch_available true, patch_required_reboot true, live_patch_available false, with live_patch_notes recording that remediation requires applying the fixed release and rebooting. The packet also records EPSS 0.011 (61.7th percentile), far lower than the sibling CVEs, reflecting narrower standalone weaponization, and the NIST-800-53-SI-2 gap frames remediation of this entry purely in patch-SLA terms.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-29552": {
     "name": "Service Location Protocol (SLP) Denial-of-Service Vulnerability",
@@ -54558,7 +56011,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability-management deprioritizes a 'medium' XSS, so the KEV-listed, actively-exploited flaw lingers unpatched on internet-facing webmail."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This entry is the case where a severity-keyed patch queue and a KEV-keyed one give opposite answers, and the packet says so three times. It scores the flaw at CVSS 5.4, and its technical-vulnerability-management, flaw-remediation and Essential Eight patch gaps all record the same failure: a 'medium' stored XSS is deprioritized on score while the same packet carries a CISA KEV listing dated 2023-10-26 and exploitation by the Winter Vivern (TA473) espionage group against government webmail. The requirement here is that the KEV listing, not the CVSS band, sets the clock for every Roundcube Webmail installation the organization runs, and that the upgrade is to the fixed release on each installation's own branch — 1.4.15 for installs below 1.4.15, 1.5.5 for 1.5.x, 1.6.4 for 1.6.x — rather than letting a medium score route the ticket into a routine maintenance queue. The branch split is operationally load-bearing because an estate hosting several Roundcube instances will have them at different branch levels, and an instance left on a pre-1.5.5 1.5.x build is still serving the vulnerable rcube_washtml.php sanitizer no matter what the 1.6.x instance was upgraded to. The packet records no live-patch mechanism and states that remediation requires applying the vendor fixed release, so completion is measured on the release the running webmail actually serves rather than on a package or repository state: where long-lived PHP worker processes or a bytecode cache continue serving previously deployed code, the fixed sanitizer is not yet in effect for the sessions being served, and that instance is not remediated. Distinguishing test: query every Roundcube instance in the estate for the release it is serving and confirm each is at or above its own branch's fixed release; an attestation satisfied by upgrading one instance leaves the rest exposed to a flaw with confirmed in-the-wild use and, on this entry, public exploit code. Precondition: this bounds future exposure only. The packet has the attacker's JavaScript running inside the victim's authenticated Roundcube session to read and exfiltrate mail, so upgrading recalls nothing already taken, and a mailbox whose owner rendered a crafted message during the exposure window is an incident-response question rather than a patch-record one.",
+        "evidence": "Packet fields: name = 'Roundcube Webmail Persistent Cross-Site Scripting (XSS) Vulnerability'; cvss 5.4 against rwep_score 64; cisa_kev true, kev_date 2023-10-26; active_exploitation confirmed with active_exploitation_notes 'Exploited in the wild by the Winter Vivern (TA473) espionage group against government webmail targets: a crafted SVG in an HTML email ran JavaScript in the victim's Roundcube session to exfiltrate mail'; vector = 'Roundcube before 1.4.15, 1.5.x before 1.5.5, and 1.6.x before 1.6.4 allows stored XSS via an HTML e-mail message with a crafted SVG document because of program/lib/Roundcube/rcube_washtml.php behavior'; affected_versions = '< 1.4.15', '1.5.x < 1.5.5', '1.6.x < 1.6.4'; poc_available true; patch_available true, patch_required_reboot false (no host reboot recorded), live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release'. Gap text used: ISO-27001-2022-A.8.8 = 'Technical-vulnerability-management deprioritizes a medium XSS, so the KEV-listed, actively-exploited flaw lingers unpatched on internet-facing webmail'; NIST-800-53-SI-2 = 'Flaw-remediation timelines for webmail are often relaxed given the medium CVSS, yet a targeted APT exploited it promptly — the severity-driven patch prioritization under-weights active exploitation'; AU-Essential-8-Patch = 'Essential-Eight patch prioritization keyed to CVSS under-weights a medium stored-XSS, yet Winter Vivern weaponized this SVG-sanitizer bypass promptly against internet-facing Roundcube'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "The premise this control rests on holds in its strongest form on this entry: the packet's attack path generates no authentication event at all. The victim logs into Roundcube Webmail normally, views an HTML message whose crafted SVG bypasses the rcube_washtml.php sanitizer, and the attacker's JavaScript then reads and exfiltrates mail across that same already-authenticated session — so an authentication-event log shows one ordinary login and nothing else, which is precisely why the monitoring and incident-handling gaps on this entry describe the exfiltration as unobserved and late-detected. For this product the requirement is that Roundcube's per-request access logs — which mail-retrieval actions ran, against which message identifiers, in what order, at what rate, and on which session — are forwarded to a SIEM outside the webmail host and retained long enough to cover a campaign rather than a shift. The rule has to key on what an exploit doing exactly what the packet describes emits: a burst of message-fetch requests inside a single authenticated session beginning when a message is rendered, sequenced by mailbox contents rather than by anything a person clicked, with no new login and no credential event anywhere in the sequence. That is the observable; a rule keyed to failed logins, server process anomalies, or host-level file changes would see nothing here, because the server is not compromised — the session is, which is exactly the incident-handling gap the packet records. Preconditions. This is detection, not prevention: it does not repair the sanitizer, does not stop the script executing in the session, and does not recall mail already exfiltrated; what it bounds is the interval between the message being viewed and someone knowing. It works only on telemetry already being collected and shipped off-host before the message arrives, and per-request access logging on an internet-facing webmail host is the collection most often left rotating locally, so a query written after the fact returns nothing. Retention has to be sized against the threat the packet names — a targeted espionage group working government webmail is a campaign that outlasts a short local rotation window — and the control is a complement to reaching the fixed release on each branch, not a substitute for it.",
+        "evidence": "Packet fields: attack_vector = 'An attacker sends an HTML email whose crafted SVG document bypasses Roundcube's HTML sanitizer; when the victim views the message, attacker-controlled JavaScript executes in the webmail session and can read/exfiltrate mail'; affected = 'Roundcube Webmail — stored XSS via a crafted SVG in an HTML email due to rcube_washtml.php sanitizer behavior, allowing attacker JavaScript to run in the victim's session'; active_exploitation_notes = 'Exploited in the wild by the Winter Vivern (TA473) espionage group against government webmail targets: a crafted SVG in an HTML email ran JavaScript in the victim's Roundcube session to exfiltrate mail'. Gap text used: UK-CAF-C1 = 'Security-monitoring expectations focus on host/network telemetry, not on anomalous webmail DOM/script behavior, leaving this XSS-driven exfiltration unobserved'; NIS2-Art21-incident-handling = 'Incident-handling processes centered on server compromise miss session-level mail exfiltration triggered purely by viewing an email, so the breach is detected late or not at all'. That the weaponized message reaches the mailbox in the first place is the packet's NIST-800-53-SI-3 gap: 'Malicious-code protection (mail AV/anti-spam) does not inspect for sanitizer-bypassing SVG/HTML that yields client-side script execution, so the weaponized email passes content filtering.'",
+        "gap_closes": [
+          "UK-CAF-C1",
+          "NIS2-Art21-incident-handling"
+        ]
+      }
+    ]
   },
   "CVE-2023-20273": {
     "name": "Cisco IOS XE Web UI Command Injection Vulnerability",
@@ -54844,7 +56320,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",
@@ -55537,7 +57036,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",
@@ -56407,7 +57931,30 @@
         "adequate": false,
         "gap": "Technical-vulnerability management is periodic; a client-side zero-day exploited on open needs continuous endpoint monitoring beyond A.8.8's assessment cadence."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet names the affected product as Adobe Acrobat and Adobe Acrobat Reader on Windows and macOS, and its affected_versions splits that into three separate update tracks: Acrobat/Reader DC at or below 23.003.20284, Acrobat/Reader 2020 at or below 20.005.30516, and Acrobat/Reader 2020 (Classic) at or below 20.005.30514. On a real estate those are separate products on separate update mechanisms, and per-user copies land outside managed software distribution, so this control means enumerating every Acrobat and every Reader install across all three tracks and both operating systems and confirming each reports a build above its own track's affected ceiling, rather than closing the flaw-remediation ticket when the single inventoried Reader package updates. Scope stops there. The packet ties the CWE-787 out-of-bounds write to Acrobat and Reader and gives no mapping into other PDF-handling software, so treating every PDF-capable binary on the estate as an instance of this CVE manufactures findings and removal work against renderers no evidence implicates; widen the inventory only where a verified source identifies another product carrying the same code. Drive the sweep on the clock that opened with the 2023-09-14 KEV listing rather than on the 2023-10-05 due date the packet's flaw-remediation gap records, because the packet states the flaw was exploited in the wild before Adobe's September 2023 fix existed, so the due date trails the exploitation it is supposed to bound. Distinguishing test: after the managed update lands, enumerate the Acrobat and Reader installs and produce each one's build, confirming none still sits at or below its own track's affected version. An estate that updates the inventoried Reader DC copy while a 2020 Classic install stays at 20.005.30514 still opens crafted PDFs into the out-of-bounds write, with a flaw-remediation attestation that reads clean. Preconditions: this reaches only copies the inventory can see and the operator can update, so an unmanaged per-user install is remediated by removing it, not by recording it as patched. The packet records no live-patch mechanism and states that remediation requires applying the vendor fixed release, so completion has to be measured on the build each install is actually executing rather than on a deployment task marked successful; a copy where the update is staged but the Acrobat or Reader process has not come up on the new build is still running the vulnerable parser. And because active exploitation is confirmed and delivery is an attacker-supplied file, a user who opened an untrusted PDF while their install was at or below the affected version belongs on the incident path rather than being closed on the patch record.",
+        "evidence": "Packet fields: affected = 'Adobe Acrobat and Adobe Acrobat Reader (Windows and macOS) processing a maliciously crafted PDF; out-of-bounds write reachable when the victim opens the file'; affected_versions = 'Acrobat/Reader DC <= 23.003.20284', 'Acrobat/Reader 2020 <= 20.005.30516', 'Acrobat/Reader 2020 (Classic) <= 20.005.30514'; cwe_refs = CWE-787; cisa_kev = true with kev_date 2023-09-14; active_exploitation = confirmed, with active_exploitation_notes 'Exploited in the wild as a zero-day before Adobe's September 2023 fix'; patch_available = true, live_patch_available = false, live_patch_notes = 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release'; patch_required_reboot = false (no host reboot recorded). The 2023-10-05 KEV due date is the figure recorded in the packet's NIST-800-53-SI-2 gap ('the KEV due date (2023-10-05) trailed active exploitation, so SI-2 SLAs alone do not close the exposure'), which is also the ISO-27001-2022-A.8.8 gap's point that periodic technical-vulnerability management does not match a client-side zero-day exploited on open. poc_available is false on this entry, so no public exploit code is claimed.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "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's vector states that exploitation requires user interaction in that a victim must open a malicious file, and its attack_vector has the attacker delivering a crafted PDF whose opening triggers the out-of-bounds write and code execution in the current user's context. On any Acrobat or Reader install not yet above its track's fixed build, the delivery path is therefore the only lever the operator holds. Require an untrusted-origin marking on every PDF arriving by mail, web download, or untrusted file share, and require marked PDFs to open in Acrobat's reduced-privilege isolated render rather than the full parsing path that carries the CWE-787 write at the user's own privilege; the packet's application-hardening gap names exactly this pairing, disabling Acrobat's embedded JavaScript and opening untrusted PDFs in Protected View, as the compensating control the KEV entry does not mandate, and its EU vulnerability-handling gap names the attachment sandboxing and mail filtering that keeps the file from reaching the parser at all. The marking must survive the container: a PDF extracted from an archive, mounted from an image, or renamed has to still reach Acrobat marked untrusted, and the user-facing escape from the isolated render has to be blocked by policy rather than left as a click, since the whole exploit precondition is one user action. Distinguishing test: mail a PDF nested inside an archive to a managed workstation, extract it, open it, and confirm it lands in the isolated render rather than the full parser; an attestation that records the hardening policy as configured still lets a provenance-stripped PDF reach the vulnerable parser with full user privileges. Preconditions, and they are the load-bearing half here. This contains the render, it does not repair the write: the out-of-bounds write is still present in the binary, so this is a holding measure for the window before the fixed build lands, which on this entry is precisely the window that mattered because the packet records exploitation in the wild before Adobe's September 2023 fix existed. It holds only where the ingress path actually applies the marking, so a PDF arriving on removable media, pulled from an internal share the policy treats as trusted, or re-saved by the user loses the tag and opens into the full parser, and those paths need to be enumerated rather than assumed covered. And it does nothing for a workstation on which a crafted PDF has already been opened: active exploitation is confirmed and the outcome is code execution in the user's context, so that machine is an incident, not a configuration item.",
+        "evidence": "Packet fields: vector = 'Exploitation of this issue requires user interaction in that a victim must open a malicious file'; attack_vector = 'An attacker delivers a crafted PDF; opening it in a vulnerable Acrobat/Reader build triggers an out-of-bounds write and arbitrary code execution in the current user's context'; cwe_refs = CWE-787; active_exploitation = confirmed with active_exploitation_notes 'Exploited in the wild as a zero-day before Adobe's September 2023 fix'. The named compensating measures are taken from the packet's own gap text: AU-Essential-8-App-Hardening = 'Hardening endpoint applications (disabling Acrobat's embedded JavaScript / opening untrusted PDFs in Protected View) is the compensating control the KEV entry does not mandate; patch cadence alone left users exposed at open-time'; NIS2-Art21-vulnerability-handling = 'Requires timely handling but not the user-interaction-blocking controls (attachment sandboxing, mail filtering) needed to stop a document-delivered client RCE between disclosure and patch'; UK-CAF-B4 = 'System security expects patched software but does not force the endpoint isolation/EDR detection required for a memory-corruption RCE that fires on document open'. patch_available is true with live_patch_available false, so this control is stated as interim to the fixed release rather than as an alternative to it.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "NIS2-Art21-vulnerability-handling",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-35674": {
     "name": "Android Framework Privilege Escalation Vulnerability",
@@ -56599,7 +58146,31 @@
         "adequate": false,
         "gap": "System security expects patched software but gives no mechanism to inventory and update a codec vendored into dozens of applications."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-144",
+        "name": "EMBEDDED-MEDIA-PARSER-LIBRARY-INVENTORY-AND-PATCH-PARITY",
+        "description": "The packet refuses to scope this to a browser and the inventory must not either. It records the flaw in libwebp below 1.3.2, states that everything embedding it is reachable through a crafted WebP image, and names Google Chrome below 116.0.5845.187 alongside Chromium-based browsers and Electron and native applications that bundle their own copy. That is the population this control requires enumerated, each install held to its own fixed build rather than to the browser's: Chrome at 116.0.5845.187 or later, each Chromium-based browser at the build its own vendor ships carrying the fix, and each Electron or native application at a build carrying libwebp 1.3.2 or later. Scoping the sweep to Chrome is the specific failure the packet's gaps describe — flaw remediation keyed to the browser misses the sprawl of applications shipping their own libwebp, and a vulnerability-management process scoped to OS and browser inventories never enumerates the embedded copies at all — so an estate standardised on a Chromium-based browser other than Chrome, or one whose desktop applications are Electron, produces a clean patch report while the decoder stays reachable from any rendered image. Do not widen past what the packet establishes: it ties the overflow to libwebp's VP8L Huffman-table decoding, so treating every image-handling or media-parsing binary in the estate as an instance of this CVE manufactures findings and update work against software no evidence implicates; widen only where a verified source names another product carrying this component. Precondition on completion, and it is the one most often mis-read here: patch_required_reboot is false, which means no machine reboot — it does not mean the fix is live. libwebp is mapped into a running process, so a browser or application that has received the new build keeps decoding through the copy already loaded until that process restarts, and the packet records no live-patch path. Measure each install on the version the running process is executing, not on what the software-distribution console reports as delivered. And because exploitation is confirmed and delivery is attacker-controlled content — a crafted HTML page, or any WebP image a vulnerable decoder renders — a host that rendered untrusted content while below the fixed build belongs on the incident path rather than being closed on the inventory.",
+        "evidence": "Packet affected: 'libwebp < 1.3.2 (and everything embedding it), reached via a crafted WebP image; Google Chrome prior to 116.0.5845.187 and numerous Chromium/Electron and native applications that decode WebP.' affected_versions: 'libwebp < 1.3.2', 'Google Chrome < 116.0.5845.187', 'Chromium-based browsers and Electron/native apps bundling libwebp < 1.3.2'. attack_vector: a crafted WebP image with malformed lossless (VP8L) Huffman coding tables overflows libwebp's BuildHuffmanTable, reachable via a crafted HTML page or any app that renders WebP. NIST-800-53-SI-2 gap: 'Flaw remediation must reach every application that statically or dynamically links libwebp, not just the browser; SI-2 patch tracking keyed to Chrome misses the sprawl of Electron/native apps that ship their own libwebp.' UK-CAF-B4 gap: 'System security expects patched software but gives no mechanism to inventory and update a codec vendored into dozens of applications.' AU-Essential-8-Patch gap: 'Patch maturity assumes a single vendor update path.' ISO-27001-2022-A.8.8 gap: technical-vulnerability management scoped to OS/browser inventories does not enumerate embedded libwebp. 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.' CWE-787, CISA KEV 2023-09-13, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 79, EPSS ~0.997.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-021",
+        "name": "TIER-3-DEPENDENCY-INVENTORY",
+        "description": "The reason the install inventory above cannot be built from an application list alone is the problem this control addresses. libwebp is not something an operator installs; it is a component vendored beneath products, and the packet's vulnerability-handling gap states outright that vulnerability management does not by itself require the SBOM or component inventory needed to find every product bundling the vulnerable codec. For this CVE that means component inventory has to reach the depth at which libwebp actually sits — statically linked into a native application, bundled inside an Electron runtime, or pulled in transitively by a framework the application depends on — and has to resolve to a version, because the only question that matters per artifact is whether the copy it ships is below 1.3.2. An SBOM that stops at the dependencies an application declares directly will not name libwebp at all for most of the affected population, which is how an estate can hold a complete and current application inventory and still not know where the vulnerable decoder is. Precondition, and it bounds what this control can be credited with: it produces knowledge, not remediation. It tells the operator which artifacts carry a copy below 1.3.2; each of those still has to reach a build carrying libwebp 1.3.2 or later from a vendor who may ship on a slower track than the browser, and the packet records no live-patch path, so each of those updated processes still has to be restarted before the fix is executing. Where a bundling application ships no updated build at all, the component inventory is what converts an invisible exposure into a decision the operator can actually take about that application rather than one they never knew they were carrying.",
+        "evidence": "Packet NIS2-Art21-vulnerability-management gap: 'Vulnerability management does not by itself require an SBOM/component inventory to find every product bundling the vulnerable codec, leaving unmanaged copies exposed to a crafted image.' ISO-27001-2022-A.8.8 gap: 'Technical-vulnerability management scoped to OS/browser inventories does not enumerate embedded libwebp in third-party software, so a supply-chain-wide image-decoder flaw stays unpatched in bundled copies.' affected: 'libwebp < 1.3.2 (and everything embedding it)'; affected_versions includes 'Chromium-based browsers and Electron/native apps bundling libwebp < 1.3.2'. patch_available true, live_patch_available false, live_patch_notes 'No vendor live-patch mechanism; remediation requires applying the vendor fixed release.' CISA KEV 2023-09-13, active_exploitation confirmed, poc_available true, CVSS 8.8, RWEP 79.",
+        "gap_closes": [
+          "NIS2-Art21-vulnerability-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-36761": {
     "name": "Microsoft Word Information Disclosure Vulnerability",
@@ -57617,7 +59188,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",
@@ -57894,7 +59499,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)",
@@ -58300,7 +59937,30 @@
         "adequate": false,
         "gap": "A.8.28 secure-coding controls should have caught the unescaped reflection of user-controlled URL parameters into the Classic Web Client; because the sink shipped to production and was exploited before the patch, the control failed at the code level rather than the deployment level."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this entry the clock has two starts and the estate has to be driven against the earlier one. Zimbra Collaboration 8 installs below 8.8.15 Patch 41 carry the Classic Web Client sink the packet describes — an unescaped URL parameter reflected into rendered HTML inside the authenticated webmail origin — and the packet places exploitation at 2023-06-29, roughly four weeks before the 2023-07-27 KEV listing and ahead of the vendor advisory. A KEV-tied SLA measured from 2023-07-27 alone therefore produces a remediation record for the tail of the campaign, not for the campaign. Applied to this product: enumerate every Zimbra Collaboration 8 mail server in service, drive each to 8.8.15 Patch 41, and measure completion on the version the running Zimbra services report after they restart. The packet records no live-patch path and states that applying Patch 41 restarts the Zimbra services though not the host, so an instance where the package landed but the webmail service was never restarted is still serving the vulnerable Classic Web Client and counts as exposed — patch_required_reboot being false says only that the machine stays up. Distinguishing test: request the Classic Web Client from each server and confirm the build it actually serves is at or above 8.8.15 Patch 41; an inventory row reading 'Patch 41 applied' beside a running service still answering on the prior build is precisely how this remediation gets recorded complete while the sink is live. Precondition, and the one most often missed here: the packet states the exploit steals mailbox data, cookies and auth tokens from the victim's session, and Patch 41 does nothing to a token already taken — a server reachable during the exposure window needs its webmail sessions invalidated and the credentials of users who could have clicked a crafted link rotated, rather than being closed on the patch record. Steering users toward a different client is not a substitute either: the Classic Web Client endpoint stays served by the same instance until the build carries the fix.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-07-27, active_exploitation confirmed, poc_available true, rwep_score 62 against cvss 6.1. active_exploitation_notes: 'Google TAG observed four distinct groups — including the Russia-aligned Winter Vivern — exploiting the flaw against government targets in Moldova and Tunisia starting 2023-06-29, at least two weeks before Zimbra's advisory.' affected: the ZCS Classic Web Client 'which reflects an unescaped URL parameter into rendered HTML, enabling cross-site scripting in the authenticated webmail origin'; affected_versions: 'Zimbra Collaboration 8 before 8.8.15 Patch 41'. patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes: 'No vendor live-patch mechanism; remediation requires applying Zimbra 8.8.15 Patch 41, which restarts Zimbra services but not the host.' attack_vector: attacker JavaScript runs in the webmail origin when an authenticated victim clicks a crafted link, 'allowing theft of mailbox data, cookies, and auth tokens'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-072",
+        "name": "PRIMARY-SOURCE-INTAKE-VENDOR-BLOG-COVERAGE",
+        "description": "This entry extends the control's premise past vendor blogs to the vendor's own public source repository. The packet records that Zimbra's fix landed in public source on 2023-07-05 and that a later wave of attackers harvested it from there and exploited the flaw before 8.8.15 Patch 41 shipped — so for the interval between that push and the released patch, the authoritative signal that Zimbra 8 webmail was exploitable existed in a primary source while every advisory-driven feed the estate subscribes to was still silent. For an operator running Zimbra Collaboration 8 the requirement is concrete: treat the vendor's public commit stream for that product as a monitored intake source alongside the advisory page; make a security-relevant commit touching the webmail rendering path, with no accompanying advisory, open a case rather than wait for the bulletin; and start the internal remediation clock at the earlier of the two signals rather than at the advisory. Distinguishing test: take a fix the vendor published in source ahead of its own advisory and check whether the intake pipeline raised anything on the commit date — a pipeline whose Zimbra coverage is the advisory page alone produces nothing, which is exactly the result it produced in July 2023 while a second wave was already exploiting the harvested fix. Precondition, stated because this control is easy to over-credit: it shortens the interval between a public fix and the operator knowing, and it gives nothing at all for the first window the packet describes — 2023-06-29 through the 2023-07-05 push — during which the flaw was a zero-day with no fix in any source. That window is bounded by response and by session/credential invalidation after the fact, not by intake coverage.",
+        "evidence": "Packet active_exploitation_notes: 'A later wave harvested the fix from Zimbra's public GitHub (pushed 2023-07-05) and exploited it before the official 8.8.15 Patch 41 shipped', with initial exploitation from 2023-06-29 'at least two weeks before Zimbra's advisory'. The NIST-800-53-SI-10 gap in framework_control_gaps states that 'because the fix landed in public source on 2023-07-05 before the advisory, an SI-10 review keyed to vendor bulletins had no signal until attackers were already stealing tokens'. The NIS2-Art21-patch-management gap states 'a bulletin-driven patch process left webmail exploitable through the KEV 2023-07-27 window and until 8.8.15 Patch 41'. The AU-Essential-8-Patch gap states the two-week clock 'starts at fix availability' and that the flaw was exploited 'via the leaked commit before 8.8.15 Patch 41, so an on-time patcher was still exposed during the active campaign'.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-38606": {
     "name": "Apple Multiple Products Kernel Unspecified Vulnerability",
@@ -58456,7 +60116,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)",
@@ -58848,7 +60541,39 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management presumes a triage-and-schedule flow, but an exploited WebKit zero-day demands emergency out-of-cycle patching; standard prioritization SLAs would leave a code-execution-on-page-load bug open far too long."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "For this WebKit entry the control means the KEV-class update is driven onto managed Apple endpoints from the 2023-07-13 listing with user deferral disallowed, because user-side deferral is precisely the failure the packet records: devices with automatic Rapid Security Response or updates disabled stayed exploitable through ordinary browsing until the fix was installed by hand. Completion has to be measured on the build the device is actually running after its restart, not on the update being approved, downloaded, or reported as applied — the packet registers no live-patch mechanism for WebKit and states the fixed release or the corresponding Rapid Security Response requires a device restart, so a device holding the update but not yet restarted is still executing vulnerable WebKit and still renders attacker-controlled web content through it. Scope the enforcement to every product the packet names rather than to the device classes this control's estate definition covers: iOS and iPadOS at 16.6, macOS Ventura at 13.5 and Safari at 16.5.2 fall inside a normal Apple device-management ring, but tvOS 16.6 and watchOS 9.6 are separate fixed builds in the same affected list and need enumerating on their own rather than being assumed covered by the ring that reports on phones and Macs. The packet's affected field further extends the same WebKit defect to non-Apple products embedding WebKit for HTML processing; it names no specific one, so widen the inventory to a given third-party product only where a verified source identifies it as carrying the component, and reach that product's own fixed build rather than treating the Apple builds as covering it.",
+        "evidence": "Packet fields for CVE-2023-37450: cisa_kev true with kev_date 2023-07-13, active_exploitation confirmed, cvss 8.8, cwe_refs CWE-787, patch_available true, patch_required_reboot true, live_patch_available false. live_patch_notes: 'No live-patch mechanism for WebKit; remediation is installing the Apple fixed release (iOS/iPadOS 16.6, Safari 16.5.2, macOS Ventura 13.5, tvOS 16.6, watchOS 9.6) or the corresponding Rapid Security Response, which requires a device restart.' affected_versions lists iOS/iPadOS < 16.6, Safari < 16.5.2, macOS Ventura < 13.5, tvOS < 16.6, watchOS < 9.6; the affected field covers iOS, iPadOS, macOS, Safari, tvOS and watchOS and non-Apple products embedding WebKit for HTML processing. The NIST-800-53-SI-2 gap states that devices with automatic RSR/updates disabled remained exploitable through simple web browsing until the fix was manually installed after the 2023-07-13 KEV listing. The AU-Essential-8-Patch gap states that fleets of iPhones, iPads and Macs are hard to force-update within the 48-hour target.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management",
+          "AU-Essential-8-Patch"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-057",
+        "name": "BROWSER-MANAGED-UPDATE-NO-DEFERRAL",
+        "description": "This CVE is a defect in the web engine itself, and the packet treats Safari as its own fixed build — Safari 16.5.2 is listed separately from macOS Ventura 13.5 — so on a managed Mac estate the browser has an update path that an OS-scoped deferral does not carry. The requirement here is that the channel delivering the Safari update and Apple's out-of-band Rapid Security Response is exempt from ring staging: the packet records that the fix shipped out of band rather than on the scheduled release cadence, and that organizations relying on managed update rings could not push it fast enough to close a bug reachable by any browsed page. A ring configured to hold releases for change-control review, with no security-channel exemption, keeps the estate on vulnerable WebKit for the duration of that hold while the rendering path stays fully exposed. Two preconditions on this control, both of which are how it gets over-recorded as the mitigation: it is an administrator-side lever only, so it does nothing on a device where the user has switched automatic updates off — the packet names that as a separate failure, and it belongs to the device-management enforcement path rather than to this one. And releasing the update into the ring is not the completion state: the packet records a required device restart with no live-patch mechanism, so a Mac that has taken Safari 16.5.2 or the Rapid Security Response but has not restarted is still running the pre-fix engine.",
+        "evidence": "Packet fields for CVE-2023-37450: affected_versions lists 'Safari < 16.5.2' and 'macOS Ventura < 13.5' as separate entries; live_patch_notes names both the fixed releases and 'the corresponding Rapid Security Response, which requires a device restart', with live_patch_available false and patch_required_reboot true. active_exploitation_notes records that Apple shipped the fix as an out-of-band Rapid Security Response and that CISA added the CVE to KEV on 2023-07-13. The NIS2-Art21-patch-management gap states that patch-management processes geared to scheduled vendor releases were outpaced by this actively-exploited WebKit zero-day, and that organizations relying on managed update rings could not push the emergency RSR fast enough to close a bug reachable by any browsed page. The NIST-800-53-SI-2 gap separately records devices with automatic RSR/updates disabled as remaining exploitable.",
+        "gap_closes": [
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "For the Apple devices in an estate that cannot yet reach iOS/iPadOS 16.6, Safari 16.5.2 or macOS Ventura 13.5, the fixed build has to function as an access condition — mail, VPN and document access denied to a device below it — rather than as a row on a patch-compliance dashboard, because until that device restarts onto the fixed build any page it renders reaches the WebKit defect. The distinguishing test is to enrol a device pinned below the fixed build and confirm the policy actually denies it access to protected resources; an estate that surfaces the stale build on a report while the device keeps its mail and document access has recorded the exposure rather than removed it. The precondition that matters on this CVE is which half of the control is load-bearing, and it is not the usual one: the packet's delivery path is a target lured to attacker-controlled web content, not a malicious application, so restricting untrusted or side-loaded application installation — the half this control normally leans on for the pre-fix window — does nothing here, and ordinary browsing on a fully compliant device reaches the flaw. The access condition therefore bounds what a compromised device can reach; it does not prevent the code execution, and it is a holding measure for the window before the fixed build and its required restart land. Because active exploitation is confirmed and the content is attacker-controlled, a device that browsed while below the fixed build belongs on the incident path rather than being closed when it later reports the fixed build.",
+        "evidence": "Packet fields for CVE-2023-37450: active_exploitation confirmed with kev_date 2023-07-13, patch_available true, patch_required_reboot true, live_patch_available false, and live_patch_notes naming iOS/iPadOS 16.6, Safari 16.5.2, macOS Ventura 13.5, tvOS 16.6 and watchOS 9.6 or the corresponding Rapid Security Response, which requires a device restart. attack_vector states that a target is lured to attacker-controlled web content and that processing it in WebKit triggers memory corruption leading to arbitrary code execution; active_exploitation_notes adds that exploitation requires luring a target to attacker-controlled web content (UI:R), consistent with targeted mobile-device attacks rather than mass exploitation, and that no detailed public PoC or technical writeup was released (poc_available false). The AU-Essential-8-Patch gap states that fleets of iPhones, iPads and Macs are hard to force-update within the 48-hour window. The ISO-27001-2022-A.8.8 gap states that standard prioritization SLAs would leave a code-execution-on-page-load bug open far too long.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8",
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-32046": {
     "name": "Microsoft Windows MSHTML Platform Privilege Escalation Vulnerability",
@@ -58909,7 +60634,30 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management presumes a known fix to prioritize; for a zero-day EoP shipped and exploited on 2023-07-11, the control has nothing to act on until the update exists, so the exposure predates any compliant vulnerability-handling cycle."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-120",
+        "name": "DOWNLOAD-PROVENANCE-ENFORCEMENT",
+        "description": "The packet gives one delivery path for this flaw and nothing else: a user opens a crafted file delivered by email or the web, and the Windows MSHTML platform elevates the attacker to that user's privileges as one link in a wider chain. On an estate that has not yet taken the July 2023 cumulative update and its reboot, controlling how externally sourced files arrive and are handled is the only lever the operator holds, because the defective component is a Windows platform component sitting behind whatever handler opens the file. Apply the untrusted-origin marking at ingress — mail gateway, web download, untrusted file share — rather than relying on the handling application to infer origin, and require the marking to survive the container the file arrives in: extraction from an archive, mounting from an ISO or VHD, and renaming must all preserve it. Two scoping points matter here and both come from the packet rather than from habit. It does not name a file type, only 'a crafted file', so the marking has to cover externally sourced files generally instead of one application's document format. And affected_versions names Windows and Windows Server editions below the July 2023 update, so the population is both — a server where an administrator opens an attachment is in scope exactly as a workstation is. Distinguishing test: send an externally sourced file through each ingress path, nested inside an archive, and confirm it still reaches the endpoint marked untrusted; a policy attestation that the marking is enabled says nothing about whether it survived the archive, and a provenance-stripped file reaches the handler with the user's full privileges. Precondition, and it is why this is a holding measure rather than a fix: the marking bounds how an externally sourced file is treated, it does not repair the MSHTML platform defect, and it is never consulted where a user is permitted to clear the marking, where an ingress path applies none, or where the file arrives by a route the estate does not mediate. The vulnerable component stays in-path on every affected host until the update and its reboot land.",
+        "evidence": "Packet active_exploitation_notes: 'Exploitation is via a crafted file (e.g. delivered by email or web) that the user opens; opening it triggers the MSHTML platform flaw and elevates the attacker to the privileges of the current user, chaining into fuller compromise.' attack_vector repeats the crafted-file open as the trigger. affected: 'Microsoft Windows MSHTML platform — a flaw in the MSHTML component allows an attacker to elevate to the privileges of the current user when a crafted file is opened'; affected_versions: 'Windows and Windows Server editions prior to the July 2023 (2023-07-11) cumulative security update'. patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patch mechanism for the MSHTML platform component; remediation requires installing the July 2023 Windows cumulative security update, which requires a reboot to complete.' The UK-CAF-B4 gap: hardening 'does not neutralize an MSHTML platform elevation reached by opening an attacker-supplied file; standard Windows hardening leaves the vulnerable component in-path until the July 2023 update lands.' The ISO-27001-2022-A.8.8 gap: 'for a zero-day EoP shipped and exploited on 2023-07-11, the control has nothing to act on until the update exists'.",
+        "gap_closes": [
+          "UK-CAF-B4",
+          "ISO-27001-2022-A.8.8"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This is the case where the KEV clock and the patch clock open on the same day: the packet records Microsoft flagging CVE-2023-32046 as exploited in the wild when it shipped the fix on 2023-07-11 Patch Tuesday, and CISA adding it to KEV on 2023-07-11. No operator could have acted before the vendor, so the entire value of this control lies after that date — driving the July 2023 Windows cumulative security update across every affected Windows and Windows Server edition on the KEV clock rather than folding it into the next monthly rollup, which is the cadence the Essential Eight and the standard flaw-remediation SLA both permit. Completion is measured per host by the installed build against the fixed build for that SKU and by the restart having been taken: the packet records no live-patch mechanism for the MSHTML platform component and states the update requires a reboot to complete, so a host that installed the update and has not restarted is still executing the vulnerable MSHTML platform and must be counted as exposed. On servers that restart is the step most likely to be deferred into a maintenance window and then recorded as patched, which is the specific failure mode for this entry. Note also that poc_available is false here and it should not lower the priority — exploitation is confirmed, so the absence of a public exploit means only that the operator cannot reproduce what an attacker is already doing. Distinguishing test: for a sample of hosts reporting the July 2023 update as installed, compare uptime against the install time and confirm each has restarted since; a management-console row reading 'installed' against a host that has not rebooted is a compliance record written over a still-exploitable component. Precondition: this control compresses only the post-disclosure half of the exposure. The packet describes a flaw already being exploited on the day the fix shipped, so no remediation SLA — this one included — reaches the period before 2023-07-11; the delivery-path control is what bounds that half.",
+        "evidence": "Packet: cisa_kev true, kev_date 2023-07-11, active_exploitation confirmed, poc_available false, rwep_score 47 against cvss 7.8. active_exploitation_notes: 'Microsoft flagged CVE-2023-32046 as exploited in the wild when it shipped the fix on 2023-07-11 Patch Tuesday... No public PoC has been released. Added to KEV 2023-07-11.' patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes: 'No live-patch mechanism for the MSHTML platform component; remediation requires installing the July 2023 Windows cumulative security update, which requires a reboot to complete.' The AU-Essential-8-Patch gap: 'Essential Eight patch-OS timelines allow up to a month for such updates, but this was an exploited-in-the-wild zero-day on release day.' The NIST-800-53-SI-2 gap: 'because CVE-2023-32046 was a zero-day already exploited on the 2023-07-11 patch-release date, any SI-2 remediation window at all left an exposure the vendor could not have pre-empted.' The NIS2-Art21-patch-management gap: patch measures 'cannot compress the interval between weaponization and the July 2023 fix'.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2023-32049": {
     "name": "Microsoft Windows Defender SmartScreen Security Feature Bypass Vulnerability",
@@ -59873,7 +61621,30 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management presumes a fix can be scheduled and applied, but for this DSP-driver OOB write on Samsung devices the fix availability depends on OEM SMR rollout, so vulnerability-management SLAs cannot guarantee remediation of the kernel escalation path."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-126",
+        "name": "MOBILE-OS-MINIMUM-PATCH-LEVEL-ENFORCEMENT",
+        "description": "The packet puts this flaw in Samsung's DSP kernel driver and puts remediation in the Samsung Mobile security maintenance release SMR Mar-2021 Release 1 or later — a build whose delivery the operator does not control, since it reaches a handset only through the OEM/carrier update channel. That is why every cited gap here is a patch-SLA gap: an estate can be fully compliant with its own patch policy and still be holding Samsung handsets running the vulnerable driver. Bound to this product, the control means the Samsung security-patch level functions as an access condition — mail, VPN and document access denied to any enrolled Samsung handset reporting a patch level below SMR Mar-2021 Release 1 — rather than as a row on a compliance report that stays red while the handset keeps its access. Completion is measured on the level the device is actually running: the packet records no live-patch mechanism for the DSP driver and an update that reboots the device, so a handset that has taken the SMR package but has not restarted onto it is still executing the vulnerable driver and counts as exposed. Scope to what the packet names — Samsung mobile devices prior to SMR Mar-2021 Release 1 — and widen to another vendor's handsets only where a verified source identifies a device carrying the same driver; the packet supplies no such mapping. Distinguishing test: enrol a Samsung handset pinned below SMR Mar-2021 Release 1 and confirm the policy actually denies it the protected resources, rather than confirming only that the stale patch level appears on a dashboard. Precondition, and it is the half most often over-claimed: withholding access bounds what a handset stuck below the fix can reach, it does not remove the out-of-bounds write. The packet's attack path is a local, already-privileged process issuing crafted requests to the driver, so the escalation happens entirely on the device — access gating neither prevents it nor evicts code already resident, and a handset suspected of running attacker code belongs on the incident path rather than the patch-level path. The gate also reaches only enrolled devices; an unenrolled or personally-owned Samsung handset touching organizational mail sits outside it entirely. And for a model or carrier variant the update channel never delivers an SMR build to, the packet records no remediation path at all — those handsets are replacement items on a dated schedule, not indefinite exception rows.",
+        "evidence": "The packet records patch_available true, live_patch_available false, patch_required_reboot true, and live_patch_notes stating that remediation requires installing the Samsung Mobile security maintenance release (SMR Mar-2021 Release 1 or later), which reboots the device; affected_versions is 'Samsung mobile devices prior to SMR Mar-2021 Release 1'. The NIS2-Art21-patch-management gap states that MDM update policies could not compel these handsets to update; the AU-Essential-8-Patch gap states the March 2021 fix was not universally deployable within any defined SLA because Samsung mobile firmware patching is gated by OEM/carrier delivery; the ISO-27001-2022-A.8.8 gap states A.8.8 presumes a fix can be scheduled and applied while here fix availability depends on OEM SMR rollout. CISA KEV listed 2023-06-29 with active_exploitation confirmed; RWEP 47, CVSS 6.7, poc_available false. The attack_vector records a local, already-privileged process issuing crafted requests to the DSP driver to corrupt kernel memory and escalate privileges.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-056",
+        "name": "MOBILE-ENDPOINT-MDM-ENFORCED-KEV-SLA",
+        "description": "This is the delivery half of the same problem. The moment the OEM/carrier channel makes a build at or above SMR Mar-2021 Release 1 available for a given Samsung model variant, the management channel drives it on the KEV clock that opened 2023-06-29 rather than leaving it to whenever the handset's user acts on an update prompt, and deferral of the restart is disallowed by policy rather than left to the user. The restart is the load-bearing step and the one most often deferred: the packet records no live-patch mechanism for the DSP driver and an update that reboots the device, so a handset that has downloaded the SMR package and not restarted is still running the vulnerable driver, and a fleet report counting it as updated has recorded the exposure rather than removed it. Enforcement must therefore read the patch level the handset reports after restart, not the deployment state in the management console. The system-security gap on this entry is what makes this the whole of the remediation rather than one control among several: the packet states that no user-space hardening constrains a flaw inside the kernel-mode DSP driver and that only the Samsung SMR patch removes the out-of-bounds memory access — there is no configuration change, no permission tightening and no on-device setting that narrows this path, so getting the build installed and restarted is the only thing that closes it. Precondition: the management channel can only drive a build the OEM or carrier has actually released for that model variant. Where none has been released the SLA has nothing to enforce and the exposure stays open — that is the case the patch-level access condition has to cover instead, and treating the SLA as satisfied because no update was offered would mark an exposed handset compliant. It also assumes the handset is enrolled; devices outside enrolment are invisible to it.",
+        "evidence": "The packet records CISA KEV listing 2023-06-29 with active_exploitation confirmed, patch_available true, patch_required_reboot true, and live_patch_available false, with live_patch_notes recording no live-patch mechanism for the Samsung DSP kernel driver and remediation requiring the Samsung Mobile security maintenance release SMR Mar-2021 Release 1 or later, which reboots the device. The UK-CAF-B4 gap states that no user-space hardening constrains a flaw inside the kernel-mode DSP driver and that only the Samsung SMR patch removes the out-of-bounds memory access exploited as an LPE. The NIST-800-53-SI-2 gap states that SI-2 assumes timely vendor patch uptake but the SMR Mar-2021 fix reaches devices only through carrier/OEM update pipelines with long tails, leaving devices that never received it exposed long after the 2023-06-29 KEV listing.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "UK-CAF-B4"
+        ]
+      }
+    ]
   },
   "CVE-2023-32434": {
     "name": "Apple Multiple Products Integer Overflow Vulnerability",
@@ -60027,7 +61798,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)",
@@ -60180,7 +61975,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",
@@ -60395,7 +62213,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",
@@ -60670,7 +62510,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",
@@ -62428,7 +64292,29 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management cannot enumerate SOHO routers outside the asset inventory, so the CWE-77 root command injection on the Archer AX21 is an untracked, actively-exploited exposure."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-030",
+        "name": "PERIMETER-DEVICE-ZERODAY-SLA-TIER",
+        "description": "The TP-Link Archer AX21 (AX1800) is the edge gateway for whatever network sits behind it, and the packet's defect is a pre-auth root remote code execution on that gateway: the country parameter of the write operation on /cgi-bin/luci;stok=/locale is passed to popen() without sanitization, so one unauthenticated POST executes commands as root on the device that is the trust boundary. A remediation tier measured in the weeks a general patch SLA allows does not fit that shape, and the packet says why in its own numbers — confirmed mass exploitation by Mirai variants, Condi and AndroxGh0st recruiting the router as root, a public proof of concept, and EPSS around 0.99999. For this device the control means a distinct tier: firmware 1.1.4 Build 20230219 or later deployed on the clock that opened with the 2023-05-01 KEV listing and its 2023-05-22 due date, or the vulnerable interface isolated until it is. Completion is measured per unit on the firmware version the router reports after it comes back up — live_patch_available is false and the packet records that installing 1.1.4 Build 20230219 reboots the device, so a unit that has taken the image but not restarted onto it is still executing the popen() sink and counts as exposed. Scope from what the packet's affected and affected_versions name: Archer AX21 (AX1800) below firmware 1.1.4 Build 20230219; widen only where a verified source identifies another model carrying the same vulnerable handler. Precondition on the isolation alternative, which is where this control is most often over-claimed: the vulnerable parameter sits on the router's web administration surface, so disabling WAN-side administration bounds who can reach it from the internet — but the packet records exploitation over the adjacent network as well as through an exposed web interface, and every client on the network this router exists to serve reaches that surface from the inside. For a unit serving a general user or household network there is no segment that removes the path, only isolation of that network from anything that matters, so isolation is a holding measure for the window before the firmware lands and not a closure. That is also why the enterprise-side expression of this tier is a reachability and firmware-version question asked of remote-work gateways, not a ticket that closes when a central console reports the push.",
+        "evidence": "Packet: CWE-77, vector states the country parameter of the write operation on the /cgi-bin/luci;stok=/locale endpoint 'was not sanitized before being used in a call to popen(), allowing an unauthenticated attacker to inject commands, which would be run as root, with a simple POST request'. affected_versions: TP-Link Archer AX21 (AX1800) firmware < 1.1.4 Build 20230219. cisa_kev true, kev_date 2023-05-01 with due 2023-05-22; active_exploitation confirmed, active_exploitation_notes record 'mass exploitation by multiple botnets (Mirai variants, Condi, AndroxGh0st) that recruit the router as root; EPSS ~0.99999' and that 'Exploitation over the adjacent/management network or an exposed web interface begins within days of PoC availability'. poc_available true, CVSS 8.8, RWEP 76. patch_available true, patch_required_reboot true, live_patch_available false, live_patch_notes 'No live-patch mechanism for the router firmware; remediation requires installing firmware 1.1.4 Build 20230219 or later, which reboots the device.' The AU-Essential-8-Patch gap records that the internet-facing patch SLA 'cannot be met on unmanaged home routers'; the UK-CAF-B4 gap records that the hardening baseline 'leaves a preauth root-RCE path open'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "AU-Essential-8-Patch",
+          "UK-CAF-B4"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The outcome the packet records for the Archer AX21 is command execution as root, and confirmed recruitment of the device into botnets — Mirai variants, Condi and AndroxGh0st — at an EPSS of roughly 0.99999. That combination is what makes patch-in-place the wrong default here. Installing firmware 1.1.4 Build 20230219 closes the popen() injection and reboots the unit, but the update is applied on top of a device an attacker held as root: the stored configuration and the administrative credential are carried across the upgrade, and root command execution was sufficient to alter either. For this router the control means a unit whose administration surface was reachable by an untrusted client or from the internet during the exposure window is handled as an incident case rather than a patch ticket — after the firmware update, reset it to factory defaults and rebuild the configuration from a known-good baseline instead of restoring the saved configuration file, set a new administrative credential, and rotate credentials and keys belonging to the network behind it. Preconditions and limits, stated because this control is the half that is easy to overstate: it does not close the injection — the firmware level and the reboot do that, and a rebuilt unit still running a pre-1.1.4 image is fully exploitable again on the next request. It applies to units that were exposed; a unit whose administration surface was never reachable by an untrusted party during the window is an ordinary patch item, and the packet gives no basis for treating every Archer AX21 as compromised. And a factory reset recovers nothing already exfiltrated and closes no session already intercepted, which is why the credential rotation rather than the reset is the load-bearing step. Scope to the model the packet names, Archer AX21 (AX1800) below firmware 1.1.4 Build 20230219, and widen only where a verified source identifies another model carrying the same handler.",
+        "evidence": "Packet: attack_vector 'An unauthenticated attacker sends a POST to /cgi-bin/luci;stok=/locale (country write operation); the country parameter is passed to popen() unsanitized, executing injected commands as root.' active_exploitation confirmed; active_exploitation_notes record 'Confirmed mass exploitation by multiple botnets (Mirai variants, Condi, AndroxGh0st) that recruit the router as root; EPSS ~0.99999 reflects near-certain ongoing exploitation.' poc_available true. patch_available true with live_patch_available false and live_patch_notes 'remediation requires installing firmware 1.1.4 Build 20230219 or later, which reboots the device'. The NIST-800-53-SI-2 gap records that the injection 'stayed exploitable across the fleet during the botnet surge that followed the 2023-05-01 KEV listing' — the population this control addresses. RWEP 76, CVSS 8.8, kev_date 2023-05-01.",
+        "gap_closes": [
+          "NIST-800-53-SI-2"
+        ]
+      }
+    ]
   },
   "CVE-2021-45046": {
     "name": "Apache Log4j2 Deserialization of Untrusted Data Vulnerability",
@@ -63410,7 +65296,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",
@@ -63555,7 +65476,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",
@@ -63700,7 +65643,21 @@
         "adequate": false,
         "gap": "Technical vulnerability management must prioritize local-privilege-escalation CVEs used by ransomware; scoring this 7.8 LPE below internet-facing RCEs leaves the SYSTEM-escalation path open across the endpoint fleet."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-145",
+        "name": "ACTIVELY-EXPLOITED-OS-LPE-REMEDIATION-WINDOW-ENFORCEMENT",
+        "description": "The packet places this in the Windows UAC certificate/consent dialog, which fails to enforce user privileges when a standard user views a publisher certificate, and the path it documents is entirely user-interface: trigger a consent dialog, open the publisher-certificate details, follow the certificate hyperlink to launch a browser as NT AUTHORITY\\\\SYSTEM, and spawn a SYSTEM shell from that browser, escalating without any exploit code. For this CVE the control means the November 2019 (or later) Windows cumulative security update is driven across the whole affected population the packet names — Windows 7, 8.1, 10 and Windows Server 2008, 2012, 2016 and 2019 — on the clock that opened with the 2023-04-07 KEV listing rather than folded into an ordinary monthly rollup, with completion measured by each host's installed build against the fixed build for its SKU rather than by 'approved' or 'downloaded' in the management console. The packet records no Microsoft hotpatch for this class and a remediation that requires that cumulative update and a reboot, so a host that has taken the update but has not restarted still presents the vulnerable dialog and must be counted as exposed. The second half of the control is the load-bearing one here: the escalation runs from an ordinary standard-user session through a dialog the operating system itself presents, so tightening account privilege does not contain it — which is exactly why the least-privilege gap cited on this entry can pass its attestation while the flaw stays fully exploitable, and why an endpoint baseline that treats UAC as the boundary is measuring something the packet says does not hold. Priority follows the packet rather than the CVSS band: a public PoC, confirmed exploitation, and a KEV ransomware:Known flag with documented post-compromise use to reach SYSTEM before payload deployment make this a containment step inside a ransomware chain, not a routine 7.8 endpoint item. Because the flaw requires local interactive access and is not remotely exploitable on its own, the population to enumerate first is hosts where non-administrative users log on interactively, since there the precondition the escalation needs is the normal operating state rather than an anomaly.",
+        "evidence": "Packet fields for this entry: CWE-269; CVSS 7.8; RWEP 68; poc_available true; active_exploitation confirmed; cisa_kev true with kev_date 2023-04-07. active_exploitation_notes: 'Added to CISA KEV on 2023-04-07 and flagged ransomware:Known. Used post-compromise by ransomware operators to escalate from a low-privileged foothold to SYSTEM before deploying payloads. Requires local interactive access; not remotely exploitable on its own.' patch_available true; patch_required_reboot true; live_patch_available false; live_patch_notes: 'No Microsoft hotpatch for this class at the time; remediation requires the November 2019 (or later) Windows cumulative security update and a reboot.' affected_versions: 'Windows 7 / 8.1 / 10 and Windows Server 2008/2012/2016/2019 without the November 2019 cumulative update'. attack_vector describes the standard user following the certificate hyperlink to launch a browser as NT AUTHORITY\\\\SYSTEM and spawning a SYSTEM-level shell 'without any exploit code'. The NIST-800-53-AC-6 gap records that least-privilege enforcement 'assumes the UAC boundary holds'; the UK-CAF-B4 gap records that Microsoft treats UAC as not a security boundary; the ISO-27001-2022-A.8.8 gap records that scoring this 7.8 LPE below internet-facing RCEs leaves the SYSTEM-escalation path open across the endpoint fleet.",
+        "gap_closes": [
+          "NIST-800-53-AC-6",
+          "AU-Essential-8-Patch",
+          "NIS2-Art21-patch-management",
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2023-26083": {
     "name": "Arm Mali GPU Kernel Driver Information Disclosure Vulnerability",
@@ -63847,7 +65804,29 @@
         "adequate": false,
         "gap": "A.8.8 technical vulnerability management had a fix available (Patch 24), but the ongoing TA473 campaign shows the real exposure was the gap between the released patch and its application on internet-facing webmail."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "This Zimbra entry is a case where CVSS-keyed and KEV-keyed prioritization give opposite answers. The base score is 6.1 — a reflected XSS, the shape of finding that lands in a quarterly web-application queue — while the packet records Winter Vivern / TA473 using it across 2022 and 2023 against European government and military Zimbra webmail to steal credentials and mailbox contents, with CISA listing it on 2023-04-03. Bound to this product, the control means the clock on an internet-facing Zimbra Collaboration Suite instance starts at the KEV listing or patch availability, whichever is later, and stops when the mailbox service is actually running 9.0.0 Patch 24 or later — not when a change ticket is raised or a package is staged. The packet is precise about what running means here and it is easy to get wrong in both directions: patch_required_reboot is false, so no host reboot is being coordinated, but the recorded remediation is a mailbox-service restart, so an instance where the package was applied and the mailbox service never restarted is still reflecting the parameter unsanitized and is not remediated. Scope to what the packet names — Zimbra Collaboration Suite 9.0 prior to 9.0.0 Patch 24 — rather than to webmail generally. The two patch-window gaps on this entry say the same thing from different sides: the fix existed and the exposure was the interval before it was applied on internet-facing webmail. The application-hardening gap matters here as an exclusion — it rules out the control a framework would otherwise reach for, since browser and webmail hardening does not stop script the server itself reflects from the trusted origin, which is why the response clock rather than endpoint hardening is the control that carries this entry. Precondition: nothing available to the operator short of Patch 24 removes the unsanitized reflection, so this SLA governs how fast the estate gets there and offers nothing during the window before it does. And because exploitation is confirmed and the payload runs inside the victim's own authenticated session, an instance that was internet-reachable while unpatched is not closed by the upgrade — the packet records credential and mailbox theft as the outcome, so session invalidation, credential rotation for users who could have followed such a link, and a review of what those mailboxes held belong inside remediation rather than being deferred to a separate incident question.",
+        "evidence": "The packet records CVSS 6.1 against RWEP 61, CISA KEV 2023-04-03, active_exploitation confirmed and poc_available true; active_exploitation_notes record Winter Vivern / TA473 using the reflected XSS through 2022-2023 against unpatched Zimbra webmail at European government and military organizations, sending targeted emails whose links ran JavaScript to steal webmail credentials and messages. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes recording remediation as updating to Zimbra Collaboration Suite 9.0.0 Patch 24 or later — a mailbox-service restart, not a host reboot; affected_versions is Zimbra Collaboration Suite 9.0 prior to 9.0.0 Patch 24. The AU-Essential-8-App-Hardening gap states application hardening does not stop server-reflected XSS delivered from the trusted webmail origin and that only the Zimbra patch removes the unsanitized reflection; the ISO-27001-2022-A.8.8 gap states the real exposure was the gap between the released patch and its application on internet-facing webmail; the NIS2-Art21-patch-management gap states the XSS was exploited against European government Zimbra instances that stayed unpatched after 9.0.0 Patch 24 shipped.",
+        "gap_closes": [
+          "AU-Essential-8-App-Hardening",
+          "ISO-27001-2022-A.8.8",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-040",
+        "name": "OWA-PER-REQUEST-SIEM-INGESTION",
+        "description": "This control's name comes from Exchange but its subject is webmail per-request telemetry, and the Zimbra campaign in this packet is the same shape it was written against. The packet describes a logged-in user following a link to their own Zimbra /public/launchNewWindow.jsp, the server reflecting the script into the trusted origin, and attacker JavaScript then reading and exfiltrating mail inside that user's existing session. None of that generates an authentication event — the user logged in normally, and everything afterwards is that user's own session issuing ordinary webmail requests — so an estate whose Zimbra logging is authentication-only holds no record of the intrusion at all. The requirement is that the Zimbra webmail tier forward per-request access logs, not just authentication events, to a collector off the mail server, with retention spanning a campaign the packet records as running across 2022 and 2023. What to key on is what the packet actually describes: requests to /public/launchNewWindow.jsp carrying script in their parameters, paired with the mailbox reads and message retrieval that follow in the same session from the same source. Both halves are needed. A script-shaped parameter on that endpoint alone may be a scanner probing it, and mailbox reads alone are what webmail does all day; it is the pairing inside one session that matches the path the packet documents. Note what will not see this: the request arrives over a valid session and no login anomaly, no malware artifact and no server-side process change accompanies it, so authentication-event alerting and host anti-malware have nothing to match, and a rule written against failed logins or unusual sign-in geography would miss an attempt behaving exactly as the packet describes. Precondition: this is detection, not prevention — it does not stop the script executing and does not recover mail already exfiltrated. It also depends on the telemetry having been collected and shipped off the mail server before the campaign arrived; a rule authored afterwards against logs nobody retained produces nothing. It bounds the window to alert-and-response time during the interval before 9.0.0 Patch 24 and its mailbox-service restart land, and complements reaching that build rather than substituting for it.",
+        "evidence": "The packet's attack_vector records an attacker sending a logged-in webmail user a link to their own Zimbra /public/launchNewWindow.jsp with a script payload in the parameters, the server reflecting it unsanitized into the trusted origin, and the attacker's JavaScript stealing credentials and mailbox contents; the affected field places the unsanitized reflection at /public/launchNewWindow.jsp and describes the result as unauthenticated reflected XSS in the webmail origin. active_exploitation_notes record TA473 running this against European government and military organizations through 2022-2023 to steal webmail credentials and messages, with poc_available true and CISA KEV listing 2023-04-03. The ISO-27001-2022-A.8.8 gap states the real exposure was the gap between the released patch and its application on internet-facing webmail. live_patch_notes record remediation as Zimbra Collaboration Suite 9.0.0 Patch 24 or later with a mailbox-service restart.",
+        "gap_closes": [
+          "ISO-27001-2022-A.8.8"
+        ]
+      }
+    ]
   },
   "CVE-2013-3163": {
     "name": "Microsoft Internet Explorer Memory Corruption Vulnerability",
@@ -63908,7 +65887,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",
@@ -64114,7 +66117,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",
@@ -64175,7 +66201,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)",
@@ -64504,7 +66553,28 @@
         "adequate": false,
         "gap": "A.8.8 technical-vulnerability management often leaves aging ColdFusion deployments off the actively-tracked inventory, so this known-exploited deserialization RCE could sit unpatched on a public server past the KEV due date."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For Adobe ColdFusion the two clocks a normal remediation process keeps apart collapsed onto one day: the packet records CISA adding this to KEV on 2023-03-15, the same day Adobe shipped the fix, and notes that this indicates exploitation was already underway. A response measured in hours from that day is the only patch-side clock that had any window at all, and it is precisely what the cited routine cadences do not carry. Bound to this product, completion means the fixed update is the code actually running: ColdFusion 2018 Update 16 for instances at or below 2018 Update 15, and ColdFusion 2021 Update 6 for instances at or below 2021 Update 5, with the ColdFusion service restarted afterwards. Read patch_required_reboot carefully here — it is false, which means no host reboot is needed, not that the fix is live on install. The packet's own remediation note requires restarting the ColdFusion service, and live_patch_available is false, so there is no path that avoids that restart; an instance that installed the update and left the service running is still executing the pre-fix code and must be counted exposed until the restart. Measure per ColdFusion installation rather than per site: a host serving several applications through one ColdFusion instance is one remediation, and an application inventory that tracks web properties rather than ColdFusion installations will miss instances on both the 2018 and 2021 tracks, which update independently. Scope from what the packet's affected and affected_versions name — ColdFusion 2018 at or below Update 15 and ColdFusion 2021 at or below Update 5 — and widen only where a verified source identifies another product carrying the same code path. Residual to state plainly rather than let the SLA imply otherwise: this compresses the post-patch window only. The packet records exploitation preceding the fix, so even a same-day clock from 2023-03-15 covers nothing before it, and an internet-facing instance that was reachable before that date is a compromise-assessment case rather than a clean patch record.",
+        "evidence": "Packet: CWE-284, vector 'Adobe ColdFusion versions 2018 Update 15 (and earlier) and 2021 Update 5 (and earlier) are affected by an Improper Access Control vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue does not require user interaction.' affected_versions: 'Adobe ColdFusion 2018 <= Update 15 (fixed in Update 16)', 'Adobe ColdFusion 2021 <= Update 5 (fixed in Update 6)'. cisa_kev true, kev_date 2023-03-15; active_exploitation_notes state the entry was 'Added to CISA KEV 2023-03-15, the same day as the Adobe fix, indicating exploitation was already underway.' patch_available true, patch_required_reboot false, live_patch_available false, live_patch_notes 'No live-patch mechanism; remediation requires applying Adobe ColdFusion 2018 Update 16 or 2021 Update 6 and restarting the ColdFusion service.' CVSS 8.6, RWEP 72, poc_available true. The NIST-800-53-SI-2 gap records that a routine cadence 'was too slow' and that 'any multi-week patch SLA left an internet-facing ColdFusion server open to unauthenticated RCE'; the NIS2-Art21-patch-management gap records that routine patch management 'does not force emergency patching of legacy web-application servers... warranting out-of-band action the routine process omits'.",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIS2-Art21-patch-management"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-032",
+        "name": "PERIMETER-COMPROMISE-REBUILD-NOT-PATCH",
+        "description": "The packet records that CISA documented a federal agency's public-facing ColdFusion servers compromised through this flaw, and it names both halves of the primitive: unauthenticated arbitrary code execution and arbitrary file read in the ColdFusion service context. Both halves determine what remediation has to mean. The execution half is what leaves a persistent artifact written through a path the application legitimately exposes; the read half hands over datasource credentials, configuration and any key material the ColdFusion service account can read, and nothing about applying an update reverses a read. Applying ColdFusion 2018 Update 16 or 2021 Update 6 and restarting the service closes the improper-access-control path to the deserialization sink, and removes nothing already written through it. So for an internet-facing ColdFusion instance that was reachable during the pre-patch window — which on this entry's own timeline is a broad population, since the KEV listing and the vendor fix landed together on 2023-03-15 with exploitation already underway — the default response is a compromise assessment and rebuild rather than patch-in-place: inventory the files under the web root and the ColdFusion installation against what a deployment accounts for, rebuild from a known-good image where one exists, and rotate every credential the service account could read, including datasource passwords. Preconditions and limits. This does not close the flaw; the update plus the service restart does, and the packet records no live-patch path, so an instance assessed but left on 2018 Update 15 or 2021 Update 5 is exploitable again immediately. It applies to instances that were internet-facing or otherwise reachable by an untrusted caller during the window, not to every ColdFusion installation in the estate. And the assessment has to be a file-inventory-against-deployment exercise rather than a scan: an artifact written through a legitimate application path is bespoke, so signature-based anti-malware and authentication logging have nothing to match, and an authentication log is silent by construction for a flaw whose whole point is that no authentication took place.",
+        "evidence": "Packet: affected records 'an improper-access-control flaw permits deserialization of untrusted data, allowing unauthenticated arbitrary code execution and arbitrary file read in the ColdFusion service context'; attack_vector repeats the unauthenticated deserialization path 'yielding arbitrary code execution and file read in the service context'. active_exploitation confirmed; active_exploitation_notes state 'CISA later documented (in a June 2023 advisory) that a federal agency's public-facing ColdFusion servers were compromised via this flaw' and that the KEV listing on 2023-03-15 landed the same day as the Adobe fix, indicating exploitation was already underway. poc_available true, CVSS 8.6, RWEP 72. patch_available true, live_patch_available false, live_patch_notes 'remediation requires applying Adobe ColdFusion 2018 Update 16 or 2021 Update 6 and restarting the ColdFusion service'. The AU-Essential-8-Patch gap records that the 48-hour window 'was already breached on release: exploitation preceded the fix, so patch-timeliness alone could not protect exposed ColdFusion servers by the 2023-03-15 KEV date.'",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-23397": {
     "name": "Microsoft Office Outlook Privilege Escalation Vulnerability",
@@ -64565,7 +66635,30 @@
         "adequate": false,
         "gap": "A.8.22 network segregation would have isolated user endpoints so a coerced SMB connection could not exit to an attacker server, but flat networks allow the outbound authentication; without segregation and SMB egress control, A.8.8 patching alone left the forced-auth leak reachable on unpatched clients."
       }
-    }
+    },
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-001",
+        "name": "CISA-KEV-RESPONSE-SLA",
+        "description": "For this CVE the mitigation the clock runs against is not one artifact. The KEV listing and the Microsoft March 2023 Outlook security update arrived together, so the patch arm is available from hour zero — but the packet's remediation note pairs that update with three named mitigations (block outbound TCP 445, add users to the Protected Users group, enforce SMB signing), and this control is what makes those the deployable alternative for any client that cannot take the update inside the clock. Scope is the Outlook for Windows estate the packet's affected_versions name — Microsoft 365 Apps and Office 2013, 2016, 2019 and LTSC 2021 below the March 2023 build — not Microsoft 365 Apps alone, since an estate standardised on a perpetual Office release is affected at its own pre-update build. Completion must be measured on Outlook itself: patch_required_reboot false means no machine reboot, and the packet states the Office update requires restarting Outlook, so a workstation that installed it while Outlook stayed open is still running the vulnerable reminder-processing path and is not remediated. Preconditions on the compensating half, which is where this gets recorded as done while the path stays open: blocking outbound TCP 445 stops the coerced authentication reaching an SMB server on the internet, but the UNC path in the reminder can name any destination the client can route to, so an attacker with an interior foothold still collects the hash — that internal case is the segregation problem, not something the egress rule covers. Protected Users membership removes NTLM only for the accounts placed in it, so the general user population keeps leaking Net-NTLMv2 until the update lands or SMB signing is enforced on the services that would accept the relay. And none of the three, nor the update, recovers a hash captured before they were in place.",
+        "evidence": "Packet: cisa_kev true with kev_date 2023-03-14, active_exploitation confirmed, CVSS 9.8, RWEP 65, poc_available true. patch_available true, patch_required_reboot false, live_patch_available false, with live_patch_notes stating 'No live-patch mechanism; remediation requires the Microsoft March 2023 Outlook security update, plus recommended mitigations (block outbound TCP 445, add users to Protected Users group, enforce SMB signing). Applying the Office update requires restarting Outlook but not the host.' affected_versions: 'Microsoft Outlook for Windows (Microsoft 365 Apps, Office 2013/2016/2019/LTSC 2021) before the March 2023 security update'. attack_vector: a crafted reminder with a UNC path in PidLidReminderFileParameter forces the client to send the user's Net-NTLMv2 hash to an attacker SMB server with no interaction. The NIST-800-53-SC-7 gap records that blocking outbound SMB (TCP 445) is Microsoft's primary mitigation but that default enterprise egress rules rarely deny 445; the UK-CAF-B2 gap records that B2 cannot distinguish the relayed session from the legitimate user without disabling NTLM or enforcing MFA/signing.",
+        "gap_closes": [
+          "AU-Essential-8-Patch",
+          "NIST-800-53-SC-7",
+          "NIS2-Art21-network-security",
+          "UK-CAF-B2"
+        ]
+      },
+      {
+        "id": "NEW-CTRL-043",
+        "name": "NATION-STATE-INITIAL-ACCESS-IR-ESCALATION",
+        "description": "The packet's attribution is the trigger this control names by actor: confirmed in-the-wild zero-day exploitation from as early as April 2022 by APT28 (Fancy Bear / Forest Blizzard) against government, military, energy and transportation targets in Europe — roughly eleven months of collection before the KEV listing on 2023-03-14. Bound to Outlook, that changes what remediation means: the flaw's output is the user's Net-NTLMv2 hash delivered to an attacker-controlled SMB server with no interaction and then relayed to impersonate the victim, so what survives the March 2023 update is authentication material already taken, not a code path still open. The runbook must therefore treat a mailbox that received a message whose reminder carried a UNC path in PidLidReminderFileParameter during the exposure window as an intrusion lead rather than a patch-compliance exception: rotate credentials for the affected accounts, and hunt for authentication that arrived by relay rather than from the user's own workstation. Escalating under the nation-state path rather than a commodity-malware path is the packet's own justification — a state-aligned espionage group operating against those sectors uses a relayed session to move, so the commodity path's expectation of a malware artifact to find produces a clean result on a compromised estate. Preconditions: this is the response half and it prevents nothing — further leaks stop only when the update and the packet's named mitigations land. It also depends on mail retention covering the exposure window and on authentication telemetry that was already being collected when the relay happened; where neither survives, the honest output is that the exposure cannot be bounded, which is the finding rather than an all-clear.",
+        "evidence": "Packet: active_exploitation confirmed, with active_exploitation_notes stating exploitation in the wild as a zero-day from as early as April 2022 by the Russia-aligned APT28 (Fancy Bear / Forest Blizzard) against government, military, energy and transportation targets in Europe, CISA KEV addition 2023-03-14, and PoCs released immediately (poc_available true). attack_vector: the hash is relayed to impersonate the victim. The AU-Essential-8-Patch gap states that even the March 2023 patch does not retroactively protect credentials leaked before it; the NIS2-Art21-network-security gap states that a patch-only response around the KEV 2023-03-14 date misses the credentials already captured by APT28.",
+        "gap_closes": [
+          "AU-Essential-8-Patch"
+        ]
+      }
+    ]
   },
   "CVE-2023-24880": {
     "name": "Microsoft Windows SmartScreen Security Feature Bypass Vulnerability (CVE-2023-24880)",