@blamejs/exceptd-skills 0.13.81 → 0.13.83

package/data/framework-control-gaps.json

@@ -35,14 +35,18 @@
     "opened_date": "2026-01-01",
     "evidence_cves": [
       "CVE-2023-48022",
+      "CVE-2024-0132",
       "CVE-2024-50050",
+      "CVE-2025-1550",
       "CVE-2025-23254",
+      "CVE-2025-23266",
       "CVE-2025-30165",
       "CVE-2025-34291",
       "CVE-2025-49596",
       "CVE-2025-54136",
       "CVE-2025-60455",
       "CVE-2025-64496",
+      "CVE-2025-8747",
       "CVE-2026-0766",
       "CVE-2026-22252",
       "CVE-2026-22688",
@@ -1185,7 +1189,9 @@
     "status": "open",
     "opened_date": "2026-05-17",
     "evidence_cves": [
-      "CVE-2024-21626"
+      "CVE-2024-0132",
+      "CVE-2024-21626",
+      "CVE-2025-23266"
     ],
     "atlas_refs": [],
     "attack_refs": [
@@ -1381,6 +1387,7 @@
       "CVE-2025-14174",
       "CVE-2025-14611",
       "CVE-2025-14733",
+      "CVE-2025-1550",
       "CVE-2025-15556",
       "CVE-2025-20281",
       "CVE-2025-20333",
@@ -1507,6 +1514,7 @@
       "CVE-2025-7775",
       "CVE-2025-8088",
       "CVE-2025-8110",
+      "CVE-2025-8747",
       "CVE-2025-8875",
       "CVE-2025-8876",
       "CVE-2025-9242",
@@ -1754,11 +1762,14 @@
     "opened_date": "2026-03-15",
     "evidence_cves": [
       "CVE-2023-48022",
+      "CVE-2024-0132",
       "CVE-2024-50050",
       "CVE-2025-10585",
       "CVE-2025-1094",
       "CVE-2025-14174",
+      "CVE-2025-1550",
       "CVE-2025-23254",
+      "CVE-2025-23266",
       "CVE-2025-30165",
       "CVE-2025-34291",
       "CVE-2025-38352",
@@ -1767,6 +1778,7 @@
       "CVE-2025-54136",
       "CVE-2025-60455",
       "CVE-2025-64496",
+      "CVE-2025-8747",
       "CVE-2026-0766",
       "CVE-2026-22252",
       "CVE-2026-22688",
@@ -2112,7 +2124,9 @@
     "opened_date": "2026-05-01",
     "evidence_cves": [
       "CVE-2023-48022",
+      "CVE-2024-0132",
       "CVE-2024-40635",
+      "CVE-2025-23266",
       "CVE-2025-53767",
       "CVE-2026-42897"
     ],
@@ -2184,11 +2198,13 @@
       "CVE-2024-50050",
       "CVE-2025-0133",
       "CVE-2025-1094",
+      "CVE-2025-1550",
       "CVE-2025-23254",
       "CVE-2025-30165",
       "CVE-2025-60455",
       "CVE-2025-64496",
       "CVE-2025-6965",
+      "CVE-2025-8747",
       "CVE-2026-0766",
       "CVE-2026-39884",
       "CVE-2026-42208",
@@ -2325,6 +2341,7 @@
       "CVE-2023-43000",
       "CVE-2023-50224",
       "CVE-2023-52163",
+      "CVE-2024-0132",
       "CVE-2024-0769",
       "CVE-2024-11182",
       "CVE-2024-12987",
@@ -2354,6 +2371,7 @@
       "CVE-2025-14174",
       "CVE-2025-14611",
       "CVE-2025-14733",
+      "CVE-2025-1550",
       "CVE-2025-15556",
       "CVE-2025-20281",
       "CVE-2025-20333",
@@ -2366,6 +2384,7 @@
       "CVE-2025-21479",
       "CVE-2025-21480",
       "CVE-2025-23254",
+      "CVE-2025-23266",
       "CVE-2025-24016",
       "CVE-2025-24201",
       "CVE-2025-24893",
@@ -2484,6 +2503,7 @@
       "CVE-2025-7775",
       "CVE-2025-8088",
       "CVE-2025-8110",
+      "CVE-2025-8747",
       "CVE-2025-8875",
       "CVE-2025-8876",
       "CVE-2025-9242",
@@ -4799,15 +4819,19 @@
     "opened_date": "2026-05-15",
     "evidence_cves": [
       "CVE-2023-48022",
+      "CVE-2024-0132",
       "CVE-2024-21762",
       "CVE-2024-50050",
+      "CVE-2025-1550",
       "CVE-2025-23254",
+      "CVE-2025-23266",
       "CVE-2025-30165",
       "CVE-2025-34291",
       "CVE-2025-49596",
       "CVE-2025-54136",
       "CVE-2025-60455",
       "CVE-2025-64496",
+      "CVE-2025-8747",
       "CVE-2026-0300",
       "CVE-2026-0766",
       "CVE-2026-20182",
@@ -5315,15 +5339,19 @@
     "status": "open",
     "opened_date": "2026-05-17",
     "evidence_cves": [
+      "CVE-2024-0132",
       "CVE-2024-21762",
       "CVE-2024-50050",
+      "CVE-2025-1550",
       "CVE-2025-23254",
+      "CVE-2025-23266",
       "CVE-2025-30165",
       "CVE-2025-34291",
       "CVE-2025-49596",
       "CVE-2025-54136",
       "CVE-2025-60455",
       "CVE-2025-64496",
+      "CVE-2025-8747",
       "CVE-2026-0766",
       "CVE-2026-22252",
       "CVE-2026-22688",
@@ -5372,15 +5400,19 @@
     "opened_date": "2026-05-17",
     "evidence_cves": [
       "CVE-2023-48022",
+      "CVE-2024-0132",
       "CVE-2024-21762",
       "CVE-2024-50050",
+      "CVE-2025-1550",
       "CVE-2025-23254",
+      "CVE-2025-23266",
       "CVE-2025-30165",
       "CVE-2025-34291",
       "CVE-2025-49596",
       "CVE-2025-54136",
       "CVE-2025-60455",
       "CVE-2025-64496",
+      "CVE-2025-8747",
       "CVE-2026-0766",
       "CVE-2026-22252",
       "CVE-2026-22688",

package/data/zeroday-lessons.json

@@ -6983,6 +6983,206 @@
     "_auto_imported": false,
     "_intake_method": "manual-verified-curation"
   },
+  "CVE-2024-0132": {
+    "name": "NVIDIA Container Toolkit TOCTOU Container Escape",
+    "lesson_date": "2026-05-25",
+    "attack_vector": {
+      "description": "NVIDIA Container Toolkit (CWE-367 TOCTOU race) lets a crafted container image escape its container and execute code on the host, crossing the tenant boundary on shared GPU infrastructure. Disclosed by Wiz Research.",
+      "privileges_required": "ability to run or schedule a crafted container image on a GPU node",
+      "complexity": "low (a crafted image / short Dockerfile is sufficient)",
+      "ai_factor": "The GPU container runtime underpins essentially all containerized AI/ML GPU workloads. A single escape on a shared GPU host crosses the tenant boundary and exposes co-tenant models, training data, and cloud credentials. The lesson: the GPU container runtime is an AI-pipeline trust boundary that must be patched and hardened like any isolation control, not assumed safe."
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Does not track the GPU container runtime as managed, escape-bearing software under every AI/ML GPU workload."
+      },
+      "NIST-800-53-SC-7": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Boundary protection assumes the container is the tenant boundary; a runtime escape crosses it on shared GPU infrastructure."
+      },
+      "ALL-AI-PIPELINE-INTEGRITY": {
+        "covered": false,
+        "adequate": false,
+        "gap": "No framework treats the GPU container runtime as an AI-pipeline trust boundary whose escape exposes co-tenant AI assets."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 70,
+      "basis": "Organizations treat container isolation as a given and do not track the GPU container runtime version; shared GPU clouds run mixed-tenant workloads on the same hosts.",
+      "theater_pattern": "container_isolation_assumed"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-090",
+        "name": "AI-GPU-CONTAINER-RUNTIME-ISOLATION",
+        "description": "Treat the GPU container runtime (NVIDIA Container Toolkit / GPU Operator) as a patch-prioritized isolation boundary: keep it current (upgrade to 1.16.2+), do not run untrusted or mixed-tenant container images on the same GPU host, restrict who can schedule GPU workloads, and run workloads least-privilege. The distinguishing test: on a staging GPU node, run a crafted image that manipulates init hooks / mounts and confirm it cannot read host paths or load host-side code outside its container.",
+        "evidence": "https://nvidia.custhelp.com/app/answers/detail/a_id/5582",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "ALL-AI-PIPELINE-INTEGRITY"
+        ]
+      }
+    ],
+    "_auto_imported": false,
+    "_intake_method": "manual-verified-curation"
+  },
+  "CVE-2025-23266": {
+    "name": "NVIDIA Container Toolkit Init-Hook Untrusted Search Path Container Escape (NVIDIAScape)",
+    "lesson_date": "2026-05-25",
+    "attack_vector": {
+      "description": "NVIDIA Container Toolkit (CWE-426 untrusted search path in init hooks) lets a crafted container image escape its container and execute code on the host, crossing the tenant boundary on shared GPU infrastructure. Disclosed by Wiz Research.",
+      "privileges_required": "ability to run or schedule a crafted container image on a GPU node",
+      "complexity": "low (a crafted image / short Dockerfile is sufficient)",
+      "ai_factor": "The GPU container runtime underpins essentially all containerized AI/ML GPU workloads. A single escape on a shared GPU host crosses the tenant boundary and exposes co-tenant models, training data, and cloud credentials. The lesson: the GPU container runtime is an AI-pipeline trust boundary that must be patched and hardened like any isolation control, not assumed safe."
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Does not track the GPU container runtime as managed, escape-bearing software under every AI/ML GPU workload."
+      },
+      "NIST-800-53-SC-7": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Boundary protection assumes the container is the tenant boundary; a runtime escape crosses it on shared GPU infrastructure."
+      },
+      "ALL-AI-PIPELINE-INTEGRITY": {
+        "covered": false,
+        "adequate": false,
+        "gap": "No framework treats the GPU container runtime as an AI-pipeline trust boundary whose escape exposes co-tenant AI assets."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 70,
+      "basis": "Organizations treat container isolation as a given and do not track the GPU container runtime version; shared GPU clouds run mixed-tenant workloads on the same hosts.",
+      "theater_pattern": "container_isolation_assumed"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-090",
+        "name": "AI-GPU-CONTAINER-RUNTIME-ISOLATION",
+        "description": "Treat the GPU container runtime (NVIDIA Container Toolkit / GPU Operator) as a patch-prioritized isolation boundary: keep it current (Container Toolkit 1.17.8+ / GPU Operator 25.3.1+), do not run untrusted or mixed-tenant container images on the same GPU host, restrict who can schedule GPU workloads, and run workloads least-privilege. The distinguishing test: on a staging GPU node, run a crafted image that manipulates init hooks / mounts and confirm it cannot read host paths or load host-side code outside its container.",
+        "evidence": "https://nvidia.custhelp.com/app/answers/detail/a_id/5659",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SC-7",
+          "ALL-AI-PIPELINE-INTEGRITY"
+        ]
+      }
+    ],
+    "_auto_imported": false,
+    "_intake_method": "manual-verified-curation"
+  },
+  "CVE-2025-1550": {
+    "name": "Keras .keras Model Deserialization Arbitrary Code Execution",
+    "lesson_date": "2026-05-25",
+    "attack_vector": {
+      "description": "Keras's .keras model parser uses importlib on names from the model archive, so a crafted model executes arbitrary Python at load time (CWE-94) — no Lambda layer or custom object, no need to call the model.",
+      "privileges_required": "none beyond getting a victim to load an untrusted .keras model",
+      "complexity": "low",
+      "ai_factor": "The abused surface is the ML model file format itself — the canonical AI supply-chain risk: an untrusted model artifact is executable code at load time. The lesson, sharpened by the CVE-2025-1550 -> CVE-2025-8747 sequence, is that model artifacts must be treated as untrusted code (provenance, scanning, safe formats like safetensors), and a partial mitigation such as safe_mode is necessary-but-insufficient when it can be bypassed."
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Does not track ML frameworks' model-loading paths as RCE-bearing, nor that the first fix (safe_mode) was bypassable."
+      },
+      "NIST-800-53-SI-10": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Model artifacts are treated as data, but Keras executes code while parsing them; no validation is applied to the artifact."
+      },
+      "ALL-AI-PIPELINE-INTEGRITY": {
+        "covered": false,
+        "adequate": false,
+        "gap": "No framework treats an ML model file as untrusted executable input; loading one from an untrusted source is RCE."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 72,
+      "basis": "ML pipelines pull models from hubs and user uploads and treat them as data; safe_mode is assumed sufficient despite the documented bypass.",
+      "theater_pattern": "model_artifact_trust"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-091",
+        "name": "UNTRUSTED-MODEL-ARTIFACT-LOADING",
+        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. Upgrade Keras to the fixed release (>= 3.8.0 for CVE-2025-1550; past 3.10.0 for the CVE-2025-8747 safe_mode bypass) and do not rely on safe_mode alone — it was bypassable. The distinguishing test: load an attacker-crafted .keras archive with safe_mode enabled on a sandboxed instance and confirm no code executes.",
+        "evidence": "https://nvd.nist.gov/vuln/detail/CVE-2025-1550",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SI-10",
+          "ALL-AI-PIPELINE-INTEGRITY"
+        ]
+      }
+    ],
+    "_auto_imported": false,
+    "_intake_method": "manual-verified-curation"
+  },
+  "CVE-2025-8747": {
+    "name": "Keras safe_mode Bypass Model Deserialization Code Execution",
+    "lesson_date": "2026-05-25",
+    "attack_vector": {
+      "description": "The safe_mode mitigation added for CVE-2025-1550 is bypassable through Keras 3.10.0: Model.load_model still lets a crafted .keras archive execute code via arguments to built-in modules (CWE-502), even with safe_mode enabled.",
+      "privileges_required": "none beyond getting a victim to load an untrusted .keras model",
+      "complexity": "low",
+      "ai_factor": "The abused surface is the ML model file format itself — the canonical AI supply-chain risk: an untrusted model artifact is executable code at load time. The lesson, sharpened by the CVE-2025-1550 -> CVE-2025-8747 sequence, is that model artifacts must be treated as untrusted code (provenance, scanning, safe formats like safetensors), and a partial mitigation such as safe_mode is necessary-but-insufficient when it can be bypassed."
+    },
+    "framework_coverage": {
+      "NIST-800-53-SI-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Does not track ML frameworks' model-loading paths as RCE-bearing, nor that the first fix (safe_mode) was bypassable."
+      },
+      "NIST-800-53-SI-10": {
+        "covered": true,
+        "adequate": false,
+        "gap": "A mitigation (safe_mode) is asserted as the control, but it is bypassable; the artifact is still deserialized unsafely."
+      },
+      "ALL-AI-PIPELINE-INTEGRITY": {
+        "covered": false,
+        "adequate": false,
+        "gap": "No framework treats an ML model file as untrusted executable input; loading one from an untrusted source is RCE."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 74,
+      "basis": "ML pipelines pull models from hubs and user uploads and treat them as data; safe_mode is assumed sufficient despite the documented bypass.",
+      "theater_pattern": "incomplete_fix_assumed_complete"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-091",
+        "name": "UNTRUSTED-MODEL-ARTIFACT-LOADING",
+        "description": "Treat ML model artifacts as untrusted code: never load .keras / pickle-based models from untrusted sources, verify provenance, prefer safe formats (e.g. safetensors), and load untrusted models only in a sandboxed, network-isolated, least-privilege environment. Upgrade Keras to the fixed release (>= 3.8.0 for CVE-2025-1550; past 3.10.0 for the CVE-2025-8747 safe_mode bypass) and do not rely on safe_mode alone — it was bypassable. The distinguishing test: load an attacker-crafted .keras archive with safe_mode enabled on a sandboxed instance and confirm no code executes.",
+        "evidence": "https://github.com/advisories/GHSA-c9rc-mg46-23w3",
+        "gap_closes": [
+          "NIST-800-53-SI-2",
+          "NIST-800-53-SI-10",
+          "ALL-AI-PIPELINE-INTEGRITY"
+        ]
+      }
+    ],
+    "_auto_imported": false,
+    "_intake_method": "manual-verified-curation"
+  },
   "CVE-2025-34291": {
     "name": "Langflow Account Takeover + RCE (CORS / refresh-token chain)",
     "lesson_date": "2026-05-24",