CVE-2026-10804: Streamlit weak hash enables cache

Q: Is CVE-2026-10804 actively exploited?

No confirmed active exploitation of CVE-2026-10804 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-10804?

1. Upgrade Streamlit beyond 1.53.0 once the fix in PR #14635 (https://github.com/streamlit/streamlit/pull/14635) is merged and released — monitor the repository for the patched release. 2. Until patched, disable caching decorators in security-sensitive or multi-user workflows by setting TTL=0 or removing @st.cache_data/@st.cache_resource where user-data isolation is critical. 3. Restrict local system access to Streamlit-hosting servers to authorized users — directly mitigates the local AV requirement. 4. In shared deployment environments, consider running separate Streamlit instances per user or workload to eliminate shared cache state. 5. Audit existing cached data in production Streamlit deployments for unexpected cross-user contamination if the application serves multiple principals.

Q: What systems are affected by CVE-2026-10804?

This vulnerability affects the following AI/ML architecture patterns: ML UI dashboards (Streamlit-based), Shared data science environments, Model inference demos, Training result visualization pipelines.

Q: What is the CVSS score for CVE-2026-10804?

CVE-2026-10804 has a CVSS v3.1 base score of 4.7 (MEDIUM). The EPSS exploitation probability is 0.08%.

CISO Take

Streamlit versions up to 1.53.0 use a cryptographically weak hash algorithm in the caching subsystem's hashing.py Palette Handler, potentially allowing a local attacker to engineer hash collisions that cause the application to serve incorrect cached outputs — including stale or manipulated ML model results — for legitimate queries. The CVSS 3.6 Low score accurately reflects the significant exploitation constraints: local system access is required, attack complexity is rated High, and the attacker must hold low privileges, collectively ruling out opportunistic or remote exploitation. No active exploitation is observed — this CVE is absent from CISA KEV, no public exploit code exists, and no Nuclei scanner template is available. Teams running shared Streamlit deployments for model demos or internal dashboards should track the pending fix in PR #14635 and plan an upgrade beyond 1.53.0 upon release, prioritizing environments where multiple users share a Streamlit instance and cache isolation is assumed.

Sources: NVD ATLAS GitHub Advisory

What is the risk?

Low risk in practice. The local attack vector and high complexity requirement severely limit the threat surface — this is not remotely exploitable and demands significant attacker knowledge of Streamlit's internal hashing logic to manufacture a valid collision. The CVSS impact scope is narrow: no confidentiality breach is possible (C:N), with only low integrity and availability degradation. In AI/ML contexts, the primary concern is incorrect cached model outputs being returned in shared multi-user Streamlit deployments, which could silently undermine result reproducibility or data isolation assumptions. Not a candidate for emergency patching; include in next scheduled Streamlit upgrade cycle.

How does the attack unfold?

Local Access

Attacker with low privileges gains shell or process access on a shared server hosting a Streamlit application with caching enabled.

AML.T0037

Hash Collision Engineering

Attacker reverse-engineers Streamlit's weak hashing algorithm in hashing.py and crafts function arguments designed to collide with another user's cached computation key.

AML.T0010.001

Cache Integrity Compromise

Attacker submits crafted inputs to the Streamlit application; the weak hash falsely matches a legitimate user's cached entry, causing the wrong cached ML results to be returned.

AML.T0031

Impact: Integrity Degradation

Incorrect model outputs or another user's cached computation results are silently served, undermining data isolation, result reproducibility, and trust in the Streamlit-hosted AI application.

AML.T0048.001

Local Access

Attacker with low privileges gains shell or process access on a shared server hosting a Streamlit application with caching enabled.

AML.T0037

Hash Collision Engineering

Attacker reverse-engineers Streamlit's weak hashing algorithm in hashing.py and crafts function arguments designed to collide with another user's cached computation key.

AML.T0010.001

Cache Integrity Compromise

Attacker submits crafted inputs to the Streamlit application; the weak hash falsely matches a legitimate user's cached entry, causing the wrong cached ML results to be returned.

AML.T0031

Impact: Integrity Degradation

Incorrect model outputs or another user's cached computation results are silently served, undermining data isolation, result reproducibility, and trust in the Streamlit-hosted AI application.

AML.T0048.001

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Streamlit	pip	< 1.53.1	`1.53.1`
45.4K OpenSSF 7.5 3.0K dependents Pushed 6d ago 14% patched ~21d to patch Full package profile →

Do you use Streamlit? You're affected.

How severe is it?

CVSS 3.1

4.7 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 0% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Advanced

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC High

PR Low

UI None

S Unchanged

C None

I High

A None

What should I do?

5 steps

Upgrade Streamlit beyond 1.53.0 once the fix in PR #14635 (https://github.com/streamlit/streamlit/pull/14635) is merged and released — monitor the repository for the patched release.
Until patched, disable caching decorators in security-sensitive or multi-user workflows by setting TTL=0 or removing @st.cache_data/@st.cache_resource where user-data isolation is critical.
Restrict local system access to Streamlit-hosting servers to authorized users — directly mitigates the local AV requirement.
In shared deployment environments, consider running separate Streamlit instances per user or workload to eliminate shared cache state.
Audit existing cached data in production Streamlit deployments for unexpected cross-user contamination if the application serves multiple principals.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Supply Chain DoS Framework Inference AML.T0010.001 - AI Software AML.T0031 - Erode AI Model Integrity AML.T0037 - Data from Local System

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.2 - Cryptographic controls

NIST AI RMF

GOVERN 1.7 - Processes for AI risk management include cybersecurity

Frequently Asked Questions

What is CVE-2026-10804?

Streamlit versions up to 1.53.0 use a cryptographically weak hash algorithm in the caching subsystem's hashing.py Palette Handler, potentially allowing a local attacker to engineer hash collisions that cause the application to serve incorrect cached outputs — including stale or manipulated ML model results — for legitimate queries. The CVSS 3.6 Low score accurately reflects the significant exploitation constraints: local system access is required, attack complexity is rated High, and the attacker must hold low privileges, collectively ruling out opportunistic or remote exploitation. No active exploitation is observed — this CVE is absent from CISA KEV, no public exploit code exists, and no Nuclei scanner template is available. Teams running shared Streamlit deployments for model demos or internal dashboards should track the pending fix in PR #14635 and plan an upgrade beyond 1.53.0 upon release, prioritizing environments where multiple users share a Streamlit instance and cache isolation is assumed.

Is CVE-2026-10804 actively exploited?

No confirmed active exploitation of CVE-2026-10804 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-10804?

1. Upgrade Streamlit beyond 1.53.0 once the fix in PR #14635 (https://github.com/streamlit/streamlit/pull/14635) is merged and released — monitor the repository for the patched release. 2. Until patched, disable caching decorators in security-sensitive or multi-user workflows by setting TTL=0 or removing @st.cache_data/@st.cache_resource where user-data isolation is critical. 3. Restrict local system access to Streamlit-hosting servers to authorized users — directly mitigates the local AV requirement. 4. In shared deployment environments, consider running separate Streamlit instances per user or workload to eliminate shared cache state. 5. Audit existing cached data in production Streamlit deployments for unexpected cross-user contamination if the application serves multiple principals.

What systems are affected by CVE-2026-10804?

This vulnerability affects the following AI/ML architecture patterns: ML UI dashboards (Streamlit-based), Shared data science environments, Model inference demos, Training result visualization pipelines.

What is the CVSS score for CVE-2026-10804?

CVE-2026-10804 has a CVSS v3.1 base score of 4.7 (MEDIUM). The EPSS exploitation probability is 0.08%.

What is the AI security impact?

Affected AI Architectures

ML UI dashboards (Streamlit-based)Shared data science environmentsModel inference demosTraining result visualization pipelines

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0031 Erode AI Model Integrity

AML.T0037 Data from Local System

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2

NIST AI RMF: GOVERN 1.7

What are the technical details?

Original Advisory

A vulnerability has been found in Streamlit up to 1.53.0. Impacted is an unknown function in the library lib/streamlit/runtime/caching/hashing.py of the component Palette Handler. Such manipulation leads to use of weak hash. Local access is required to approach this attack. The attack requires a high level of complexity. The exploitability is considered difficult. The exploit has been disclosed to the public and may be used. The pull request to fix this issue awaits acceptance.

Exploitation Scenario

A low-privileged local user on a shared data science server running Streamlit up to 1.53.0 — such as a multi-tenant JupyterHub or internal ML platform — studies Streamlit's weak hashing algorithm in hashing.py to identify the collision space. The attacker then engineers a function call with specific arguments that produce the same hash value as a legitimate researcher's prior cached model inference computation. When Streamlit's Palette Handler performs its cache lookup for the attacker's crafted input, it returns the legitimate user's cached result as a false positive — potentially exposing intermediate model outputs, predictions, or processed datasets from the other user's session. The high attack complexity means this requires insider knowledge of Streamlit internals and deliberate input crafting, making it most realistic as a targeted insider threat rather than opportunistic exploitation.

Weaknesses (CWE)

CWE-327 Use of a Broken or Risky Cryptographic Algorithm Primary 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.