CVE-2026-15605: wandb: weak hash weakens artifact integrity check
LOW PoC AVAILABLEThis is a low-severity weakness in wandb's artifact download path where ArtifactManifestEntry.download relies on a cryptographically weak hash (CWE-327/328) to verify artifact integrity instead of a collision-resistant algorithm. For a CISO, the practical risk is limited: exploitation requires network access plus low privileges, high attack complexity, and no user interaction, and the EPSS score of 0.00151 places this firmly in the long tail of CVEs unlikely to see real-world exploitation — there is no public exploit, no Nuclei template, and it is not in CISA KEV. The blast radius matters more in principle than in practice: any pipeline that trusts wandb artifact hashes as a tamper-detection control (model checkpoints, datasets pulled from shared or multi-tenant W&B projects) could theoretically accept a maliciously substituted artifact that collides with the weak hash. Given the low CVSS (3.1) and high exploitation difficulty, this does not warrant emergency action — track the upstream pull request (wandb/wandb#12031) and apply the fix once merged; in the interim, don't rely on wandb's built-in hash as your sole integrity control for artifacts sourced from untrusted or shared projects.
What is the risk?
Overall risk is LOW. CVSS 3.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects a network-reachable but hard-to-exploit flaw with only limited confidentiality impact and no integrity or availability impact recorded in the vector — despite the underlying weakness being about integrity validation, the scored impact is narrow. High attack complexity (crafting a hash collision or preimage against the weak algorithm) and the requirement for low-level privileges substantially raise the bar for a practical attack. EPSS of 0.00151 is very low, no public exploit or scanner template exists, and the fix is still an open pull request awaiting maintainer acceptance, so there's no urgency signal from active exploitation data.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Weights & Biases | pip | — | No patch |
Do you use Weights & Biases? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Track wandb/wandb PR #12031 and upgrade to the patched release once merged and published. Until then: restrict who can write to shared W&B artifact stores/projects (least privilege), treat artifacts pulled from external or multi-tenant projects as untrusted and apply independent integrity checks (e.g., sign artifacts separately or verify via a stronger hash such as SHA-256 computed and compared out-of-band). Monitor wandb release notes for the fix and pin to the patched version in CI/CD and training environments. No workaround-level configuration change is documented upstream; the fix must come from the library update.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-15605?
This is a low-severity weakness in wandb's artifact download path where ArtifactManifestEntry.download relies on a cryptographically weak hash (CWE-327/328) to verify artifact integrity instead of a collision-resistant algorithm. For a CISO, the practical risk is limited: exploitation requires network access plus low privileges, high attack complexity, and no user interaction, and the EPSS score of 0.00151 places this firmly in the long tail of CVEs unlikely to see real-world exploitation — there is no public exploit, no Nuclei template, and it is not in CISA KEV. The blast radius matters more in principle than in practice: any pipeline that trusts wandb artifact hashes as a tamper-detection control (model checkpoints, datasets pulled from shared or multi-tenant W&B projects) could theoretically accept a maliciously substituted artifact that collides with the weak hash. Given the low CVSS (3.1) and high exploitation difficulty, this does not warrant emergency action — track the upstream pull request (wandb/wandb#12031) and apply the fix once merged; in the interim, don't rely on wandb's built-in hash as your sole integrity control for artifacts sourced from untrusted or shared projects.
Is CVE-2026-15605 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-15605, increasing the risk of exploitation.
How to fix CVE-2026-15605?
Track wandb/wandb PR #12031 and upgrade to the patched release once merged and published. Until then: restrict who can write to shared W&B artifact stores/projects (least privilege), treat artifacts pulled from external or multi-tenant projects as untrusted and apply independent integrity checks (e.g., sign artifacts separately or verify via a stronger hash such as SHA-256 computed and compared out-of-band). Monitor wandb release notes for the fix and pin to the patched version in CI/CD and training environments. No workaround-level configuration change is documented upstream; the fix must come from the library update.
What systems are affected by CVE-2026-15605?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, MLOps artifact management, experiment tracking pipelines, model registries.
What is the CVSS score for CVE-2026-15605?
CVE-2026-15605 has a CVSS v3.1 base score of 3.1 (LOW). The EPSS exploitation probability is 0.23%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001 AI Software AML.T0010.003 Model Compliance Controls Affected
What are the technical details?
Original Advisory
A security vulnerability has been detected in wandb 0.25.2.dev1. Affected is the function ArtifactManifestEntry.download in the library wandb/sdk/lib/hashutil.py of the component Artifact Integrity Validation. The manipulation leads to use of weak hash. The attack may be initiated remotely. A high degree of complexity is needed for the attack. The exploitability is told to be difficult. The pull request to fix this issue awaits acceptance.
Exploitation Scenario
An adversary with low-level write access to a shared W&B project (e.g., a malicious insider, a compromised CI credential, or an attacker who compromises the artifact backend) crafts a modified dataset or model checkpoint whose content collides with the weak hash recorded in the artifact manifest. When a downstream user or automated training job calls ArtifactManifestEntry.download, the weak-hash integrity check passes despite the content being tampered with, allowing the substituted artifact — potentially a poisoned training dataset or backdoored model checkpoint — to be silently pulled into the ML pipeline and used for further training or deployment.
Weaknesses (CWE)
CWE-327 Use of a Broken or Risky Cryptographic Algorithm
Primary
CWE-328 Use of Weak Hash
Primary
CWE-327 Use of a Broken or Risky Cryptographic Algorithm CWE-328 Use of Weak Hash CWE-327 — Use of a Broken or Risky Cryptographic Algorithm: The product uses a broken or risky cryptographic algorithm or protocol.
- [Architecture and Design] When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267
- [Architecture and Design] Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N References
Timeline
Related Vulnerabilities
CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply Chain CVE-2024-2912 10.0 BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply Chain CVE-2025-5120 10.0 smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Supply Chain CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same attack type: Supply Chain GHSA-vvpj-8cmc-gx39 10.0 picklescan: security flaw enables exploitation
Same attack type: Supply Chain