@blamejs/exceptd-skills 0.13.113 → 0.13.115

package/data/framework-control-gaps.json

@@ -52,6 +52,7 @@
       "CVE-2024-11393",
       "CVE-2024-11394",
       "CVE-2024-12366",
+      "CVE-2024-12776",
       "CVE-2024-13059",
       "CVE-2024-1561",
       "CVE-2024-21575",
@@ -73,6 +74,7 @@
       "CVE-2024-9526",
       "CVE-2025-1550",
       "CVE-2025-1753",
+      "CVE-2025-1796",
       "CVE-2025-23254",
       "CVE-2025-23266",
       "CVE-2025-25297",
@@ -112,6 +114,8 @@
       "CVE-2026-33017",
       "CVE-2026-34159",
       "CVE-2026-40933",
+      "CVE-2026-41947",
+      "CVE-2026-41950",
       "CVE-2026-45829"
     ],
     "atlas_refs": [
@@ -2219,6 +2223,8 @@
       "CVE-2023-47117",
       "CVE-2025-14847",
       "CVE-2025-22226",
+      "CVE-2026-41947",
+      "CVE-2026-41950",
       "CVE-2026-43284"
     ],
     "atlas_refs": [],
@@ -3875,12 +3881,16 @@
       "CVE-2023-48022",
       "CVE-2023-6019",
       "CVE-2023-6021",
+      "CVE-2024-12776",
       "CVE-2024-4889",
       "CVE-2024-6587",
+      "CVE-2025-1796",
       "CVE-2025-64513",
       "CVE-2026-24206",
       "CVE-2026-24207",
-      "CVE-2026-26190"
+      "CVE-2026-26190",
+      "CVE-2026-41947",
+      "CVE-2026-41950"
     ],
     "atlas_refs": [
       "AML.T0010",
@@ -5114,6 +5124,7 @@
       "CVE-2024-11393",
       "CVE-2024-11394",
       "CVE-2024-12366",
+      "CVE-2024-12776",
       "CVE-2024-13059",
       "CVE-2024-1561",
       "CVE-2024-21513",
@@ -5137,6 +5148,7 @@
       "CVE-2024-9526",
       "CVE-2025-1550",
       "CVE-2025-1753",
+      "CVE-2025-1796",
       "CVE-2025-23254",
       "CVE-2025-23266",
       "CVE-2025-25297",
@@ -5181,6 +5193,8 @@
       "CVE-2026-34926",
       "CVE-2026-40933",
       "CVE-2026-41091",
+      "CVE-2026-41947",
+      "CVE-2026-41950",
       "CVE-2026-42897",
       "CVE-2026-42945",
       "CVE-2026-45498",
@@ -5225,13 +5239,17 @@
       "CVE-2023-43791",
       "CVE-2023-47117",
       "CVE-2023-6038",
+      "CVE-2024-12776",
       "CVE-2024-1709",
+      "CVE-2025-1796",
       "CVE-2025-25297",
       "CVE-2025-3248",
       "CVE-2025-3466",
       "CVE-2025-56520",
       "CVE-2026-33017",
       "CVE-2026-39987",
+      "CVE-2026-41947",
+      "CVE-2026-41950",
       "CVE-2026-7482"
     ],
     "atlas_refs": [
@@ -5489,6 +5507,8 @@
       "CVE-2026-3909",
       "CVE-2026-3910",
       "CVE-2026-41940",
+      "CVE-2026-41947",
+      "CVE-2026-41950",
       "CVE-2026-6973"
     ],
     "atlas_refs": [],
@@ -5526,8 +5546,12 @@
       "CVE-2023-47117",
       "CVE-2023-6016",
       "CVE-2023-6038",
+      "CVE-2024-12776",
+      "CVE-2025-1796",
       "CVE-2025-3248",
       "CVE-2026-33017",
+      "CVE-2026-41947",
+      "CVE-2026-41950",
       "CVE-2026-6973"
     ],
     "atlas_refs": [],
@@ -5815,6 +5839,7 @@
       "CVE-2024-11393",
       "CVE-2024-11394",
       "CVE-2024-12366",
+      "CVE-2024-12776",
       "CVE-2024-13059",
       "CVE-2024-1561",
       "CVE-2024-21513",
@@ -5838,6 +5863,7 @@
       "CVE-2024-9526",
       "CVE-2025-1550",
       "CVE-2025-1753",
+      "CVE-2025-1796",
       "CVE-2025-23254",
       "CVE-2025-23266",
       "CVE-2025-25297",
@@ -5880,6 +5906,8 @@
       "CVE-2026-34926",
       "CVE-2026-40933",
       "CVE-2026-41091",
+      "CVE-2026-41947",
+      "CVE-2026-41950",
       "CVE-2026-45498",
       "CVE-2026-45829",
       "CVE-2026-46300",
@@ -6097,11 +6125,15 @@
       "CVE-2023-47117",
       "CVE-2023-48022",
       "CVE-2023-6038",
+      "CVE-2024-12776",
+      "CVE-2025-1796",
       "CVE-2025-3248",
       "CVE-2025-55241",
       "CVE-2026-24206",
       "CVE-2026-24207",
-      "CVE-2026-33017"
+      "CVE-2026-33017",
+      "CVE-2026-41947",
+      "CVE-2026-41950"
     ],
     "atlas_refs": [],
     "attack_refs": [
@@ -6173,10 +6205,12 @@
       "CVE-2023-6019",
       "CVE-2023-6021",
       "CVE-2023-6038",
+      "CVE-2024-12776",
       "CVE-2024-1709",
       "CVE-2024-2912",
       "CVE-2024-4889",
       "CVE-2024-6587",
+      "CVE-2025-1796",
       "CVE-2025-27520",
       "CVE-2025-3248",
       "CVE-2025-64513",

package/data/zeroday-lessons.json

@@ -4811,6 +4811,206 @@
     "_auto_imported": false,
     "_intake_method": "manual-verified-curation"
   },
+  "CVE-2025-1796": {
+    "name": "Dify Weak-PRNG Password Reset Account Takeover",
+    "lesson_date": "2026-05-26",
+    "attack_vector": {
+      "description": "Dify generates password-reset codes with a weak PRNG (random.randint) rather than a cryptographically secure RNG, so an attacker predicts the reset code and takes over any account, including administrators.",
+      "privileges_required": "low (an account to trigger the predictable reset; takeover reaches admin)",
+      "complexity": "low",
+      "ai_factor": "The abused surface is Dify, a low-code LLM application-development platform. The lesson: an AI app's password-recovery flow is an authentication-integrity control - the predictable reset-code half of a takeover chain that ends in full admin control; reset tokens must be CSPRNG-generated AND verified server-side."
+    },
+    "framework_coverage": {
+      "NIST-800-53-IA-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The LLM app's password-recovery flow lets an attacker authenticate as any user, including admin."
+      },
+      "NIST-800-53-AC-3": {
+        "covered": true,
+        "adequate": false,
+        "gap": "A predictable reset code grants control of any account."
+      },
+      "ALL-AI-PIPELINE-INTEGRITY": {
+        "covered": false,
+        "adequate": false,
+        "gap": "No framework treats an LLM app platform's password-recovery flow as an authentication-integrity control whose failure yields full account takeover."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 82,
+      "basis": "LLM app platforms ship self-service password recovery; reset-token generation and verification are rarely audited, and weak PRNG / missing verification persist.",
+      "theater_pattern": "ai_app_weak_password_recovery"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-108",
+        "name": "AI-APP-PASSWORD-RECOVERY-INTEGRITY",
+        "description": "An AI application's password-reset / account-recovery flow must (1) generate reset tokens with a cryptographically secure RNG (e.g. secrets / os.urandom - never random.randint or another predictable PRNG), making them long, single-use, and short-lived; and (2) verify the reset token server-side, bound to the requesting account, before accepting a new password - the reset endpoint must never perform a reset without a valid, matching, unexpired token. Rate-limit reset attempts. The distinguishing test: on a staging instance, request a reset and confirm the code is unpredictable across requests, and confirm POSTing to the reset endpoint with a wrong/absent code is rejected - an AI app whose recovery flow uses a weak PRNG or skips token verification permits takeover of any account, including administrators.",
+        "evidence": "https://github.com/advisories/GHSA-cvg9-334x-w586",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "NIST-800-53-AC-3",
+          "ALL-AI-PIPELINE-INTEGRITY"
+        ]
+      }
+    ],
+    "_auto_imported": false,
+    "_intake_method": "manual-verified-curation"
+  },
+  "CVE-2026-41947": {
+    "name": "Dify Trace-Config Cross-Tenant Authorization Bypass",
+    "lesson_date": "2026-05-26",
+    "attack_vector": {
+      "description": "Dify's trace-configuration endpoints do not verify tenant ownership, so an authenticated editor user configures trace settings for any application and can redirect victim trace data to an attacker-controlled provider.",
+      "privileges_required": "low (an authenticated editor account)",
+      "complexity": "low",
+      "ai_factor": "The abused surface is Dify, a low-code LLM application-development platform. The lesson: an LLM app platform's API must enforce object-level authorization (ownership of the tenant/application/file referenced by a caller-supplied key) on every request - here a user-controlled key bypassed it for cross-tenant trace-config tampering / data redirect."
+    },
+    "framework_coverage": {
+      "NIST-800-53-AC-3": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Access enforcement does not verify ownership of the object referenced by a caller-supplied key (CWE-639)."
+      },
+      "NIST-800-53-SC-28": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Data is reachable cross-tenant/cross-user via a user-controlled key without an ownership check."
+      },
+      "ALL-AI-PIPELINE-INTEGRITY": {
+        "covered": false,
+        "adequate": false,
+        "gap": "No framework treats an LLM app platform's object-level authorization as an integrity control whose absence yields cross-tenant/user access."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 80,
+      "basis": "Multi-tenant LLM app platforms expose rich object-referencing APIs; ownership checks on user-controlled keys (tenant/app/file ids) are frequently missing and rarely audited.",
+      "theater_pattern": "ai_app_broken_object_authorization"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-106",
+        "name": "AI-APP-API-OBJECT-AUTHORIZATION-AND-FIELD-EXPOSURE",
+        "description": "An AI data-platform API (data-labeling, annotation, dataset/registry services) must enforce object-level authorization on every read and must never expose sensitive fields - secrets, session-signing keys, auth tokens, password hashes - through API responses, serializers, or user-controlled query/filter expressions. Use serializer field allowlists (never blanket model serialization), reject ORM/filter inputs that reference fields the caller is not authorized to read, scope every query to the caller's own objects, and store credentials so a read leak is not directly replayable (and rotate exposed secrets). The distinguishing test: as a low-privilege user, craft a filter/query that references another account's password hash or token, and confirm the API refuses it - a platform whose filter/serializer leaks sensitive fields lets an attacker chain disclosure into account impersonation and privilege escalation.",
+        "evidence": "https://github.com/advisories/GHSA-6hjj-gq77-j4qw",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "NIST-800-53-SC-28",
+          "ALL-AI-PIPELINE-INTEGRITY"
+        ]
+      }
+    ],
+    "_auto_imported": false,
+    "_intake_method": "manual-verified-curation"
+  },
+  "CVE-2026-41950": {
+    "name": "Dify Chat-Messages Arbitrary File-UUID Cross-User File Read",
+    "lesson_date": "2026-05-26",
+    "attack_vector": {
+      "description": "Dify accepts a caller-supplied file UUID in a chat-messages request without verifying ownership, so an authenticated user reads files uploaded by other users in the same tenant (IDOR).",
+      "privileges_required": "low (an authenticated tenant user)",
+      "complexity": "low",
+      "ai_factor": "The abused surface is Dify, a low-code LLM application-development platform. The lesson: an LLM app platform's API must enforce object-level authorization (ownership of the tenant/application/file referenced by a caller-supplied key) on every request - here a user-controlled key bypassed it for cross-user file disclosure."
+    },
+    "framework_coverage": {
+      "NIST-800-53-AC-3": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Access enforcement does not verify ownership of the object referenced by a caller-supplied key (CWE-639)."
+      },
+      "NIST-800-53-SC-28": {
+        "covered": true,
+        "adequate": false,
+        "gap": "Data is reachable cross-tenant/cross-user via a user-controlled key without an ownership check."
+      },
+      "ALL-AI-PIPELINE-INTEGRITY": {
+        "covered": false,
+        "adequate": false,
+        "gap": "No framework treats an LLM app platform's object-level authorization as an integrity control whose absence yields cross-tenant/user access."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 80,
+      "basis": "Multi-tenant LLM app platforms expose rich object-referencing APIs; ownership checks on user-controlled keys (tenant/app/file ids) are frequently missing and rarely audited.",
+      "theater_pattern": "ai_app_broken_object_authorization"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-106",
+        "name": "AI-APP-API-OBJECT-AUTHORIZATION-AND-FIELD-EXPOSURE",
+        "description": "An AI data-platform API (data-labeling, annotation, dataset/registry services) must enforce object-level authorization on every read and must never expose sensitive fields - secrets, session-signing keys, auth tokens, password hashes - through API responses, serializers, or user-controlled query/filter expressions. Use serializer field allowlists (never blanket model serialization), reject ORM/filter inputs that reference fields the caller is not authorized to read, scope every query to the caller's own objects, and store credentials so a read leak is not directly replayable (and rotate exposed secrets). The distinguishing test: as a low-privilege user, craft a filter/query that references another account's password hash or token, and confirm the API refuses it - a platform whose filter/serializer leaks sensitive fields lets an attacker chain disclosure into account impersonation and privilege escalation.",
+        "evidence": "https://github.com/advisories/GHSA-6hjj-gq77-j4qw",
+        "gap_closes": [
+          "NIST-800-53-AC-3",
+          "NIST-800-53-SC-28",
+          "ALL-AI-PIPELINE-INTEGRITY"
+        ]
+      }
+    ],
+    "_auto_imported": false,
+    "_intake_method": "manual-verified-curation"
+  },
+  "CVE-2024-12776": {
+    "name": "Dify Unverified Password-Reset Endpoint Account Takeover",
+    "lesson_date": "2026-05-26",
+    "attack_vector": {
+      "description": "Dify's /forgot-password/resets endpoint does not verify the reset code before allowing a password reset, so an attacker resets any user's password (including admin) without a valid code.",
+      "privileges_required": "none (unauthenticated reset of any account)",
+      "complexity": "high",
+      "ai_factor": "The abused surface is Dify, a low-code LLM application-development platform. The lesson: an AI app's password-recovery flow is an authentication-integrity control - the unverified-reset-endpoint half of a takeover chain that ends in full admin control; reset tokens must be CSPRNG-generated AND verified server-side."
+    },
+    "framework_coverage": {
+      "NIST-800-53-IA-2": {
+        "covered": true,
+        "adequate": false,
+        "gap": "The LLM app's password-recovery flow lets an attacker authenticate as any user, including admin."
+      },
+      "NIST-800-53-AC-3": {
+        "covered": true,
+        "adequate": false,
+        "gap": "An unverified reset endpoint grants control of any account."
+      },
+      "ALL-AI-PIPELINE-INTEGRITY": {
+        "covered": false,
+        "adequate": false,
+        "gap": "No framework treats an LLM app platform's password-recovery flow as an authentication-integrity control whose failure yields full account takeover."
+      }
+    },
+    "compliance_exposure_score": {
+      "percent_audit_passing_orgs_still_exposed": 82,
+      "basis": "LLM app platforms ship self-service password recovery; reset-token generation and verification are rarely audited, and weak PRNG / missing verification persist.",
+      "theater_pattern": "ai_app_weak_password_recovery"
+    },
+    "ai_discovered_zeroday": false,
+    "ai_discovery_source": "human_researcher",
+    "ai_assist_factor": "none",
+    "new_control_requirements": [
+      {
+        "id": "NEW-CTRL-108",
+        "name": "AI-APP-PASSWORD-RECOVERY-INTEGRITY",
+        "description": "An AI application's password-reset / account-recovery flow must (1) generate reset tokens with a cryptographically secure RNG (e.g. secrets / os.urandom - never random.randint or another predictable PRNG), making them long, single-use, and short-lived; and (2) verify the reset token server-side, bound to the requesting account, before accepting a new password - the reset endpoint must never perform a reset without a valid, matching, unexpired token. Rate-limit reset attempts. The distinguishing test: on a staging instance, request a reset and confirm the code is unpredictable across requests, and confirm POSTing to the reset endpoint with a wrong/absent code is rejected - an AI app whose recovery flow uses a weak PRNG or skips token verification permits takeover of any account, including administrators.",
+        "evidence": "https://github.com/advisories/GHSA-g394-qpx6-x7rr",
+        "gap_closes": [
+          "NIST-800-53-IA-2",
+          "NIST-800-53-AC-3",
+          "ALL-AI-PIPELINE-INTEGRITY"
+        ]
+      }
+    ],
+    "_auto_imported": false,
+    "_intake_method": "manual-verified-curation"
+  },
   "CVE-2025-56520": {
     "name": "Dify Remote File Upload Server-Side Request Forgery",
     "lesson_date": "2026-05-26",