CVE-2025-49655: Keras Deserialization enables RCE

Q: Is CVE-2025-49655 actively exploited?

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

Q: How to fix CVE-2025-49655?

1) PATCH IMMEDIATELY: upgrade all Keras installations to 3.11.3 — this is the only complete fix. Run `pip show keras` across your ML infrastructure to identify affected versions. 2) AUDIT model loading: catalog every place your code calls `keras.models.load_model()` or equivalent and identify the trust level of the source file. 3) DO NOT rely on safe_mode=True as a security control on any Keras version until you've confirmed 3.11.3 is deployed. 4) IMPLEMENT model provenance controls: cryptographic signing and hash verification of model files before loading, even from internal registries. 5) ISOLATE model loading: run model deserialization in sandboxed environments (containers with no network, read-only filesystems, minimal privileges) as a defense-in-depth measure. 6) DETECT: monitor for unexpected process spawning from Python/ML processes, outbound connections from training/inference nodes, and anomalous file access patterns post-model-load. 7) CHECK shared model stores: audit any Keras model files pulled from external sources (HuggingFace, S3, third parties) since Keras 3.11.0 was released (October 2025).

Q: What systems are affected by CVE-2025-49655?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, model registries, MLOps platforms, collaborative AI development environments.

Q: What is the CVSS score for CVE-2025-49655?

CVE-2025-49655 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.71%.

CISO Take

A critical deserialization RCE in Keras 3.11.0–3.11.2 bypasses safe mode entirely — the protection your ML engineers may have been trusting is worthless on affected versions. Any pipeline that loads Keras model files from external or user-supplied sources is fully compromised on impact. Patch to 3.11.3 now and treat any model loading from untrusted sources as an uncontrolled code execution path until verified.

What is the risk?

CVSS 9.8 with network vector, no privileges, no user interaction — maximum exploitability on paper. The EPSS of 0.00034 indicates no observed in-the-wild exploitation at time of publication, but this will not hold: the attack primitive (malicious model file → RCE) is well-understood and tooling exists. The safe mode bypass elevates severity significantly: organizations that implemented safe mode as a compensating control are fully exposed. AI/ML teams routinely load models from HuggingFace, internal registries, and third-party sources, making the attack surface broad across any organization with an ML practice.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Keras	pip	>= 3.11.0, < 3.11.3	`3.11.3`
64.1K OpenSSF 7.1 1.6K dependents Pushed 5d ago 48% patched ~32d to patch Full package profile →

Do you use Keras? You're affected.

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 49% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

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 Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

1) PATCH IMMEDIATELY: upgrade all Keras installations to 3.11.3 — this is the only complete fix. Run pip show keras across your ML infrastructure to identify affected versions. 2) AUDIT model loading: catalog every place your code calls keras.models.load_model() or equivalent and identify the trust level of the source file. 3) DO NOT rely on safe_mode=True as a security control on any Keras version until you've confirmed 3.11.3 is deployed. 4) IMPLEMENT model provenance controls: cryptographic signing and hash verification of model files before loading, even from internal registries. 5) ISOLATE model loading: run model deserialization in sandboxed environments (containers with no network, read-only filesystems, minimal privileges) as a defense-in-depth measure. 6) DETECT: monitor for unexpected process spawning from Python/ML processes, outbound connections from training/inference nodes, and anomalous file access patterns post-model-load. 7) CHECK shared model stores: audit any Keras model files pulled from external sources (HuggingFace, S3, third parties) since Keras 3.11.0 was released (October 2025).

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable Yes

Technical Impact total

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

How is it classified?

Code Execution Supply Chain Framework Model AML.T0010.001 - AI Software AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware AML.T0058 - Publish Poisoned Models

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system

ISO 42001

A.6.2.6 - AI system components and data provenance A.9.3 - AI system testing and validation

NIST AI RMF

GOVERN-6.2 - Policies and procedures are in place for AI supply chain risk management MANAGE-2.2 - Mechanisms are in place to respond to risks from AI system components

OWASP LLM Top 10

LLM05:2025 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2025-49655?

A critical deserialization RCE in Keras 3.11.0–3.11.2 bypasses safe mode entirely — the protection your ML engineers may have been trusting is worthless on affected versions. Any pipeline that loads Keras model files from external or user-supplied sources is fully compromised on impact. Patch to 3.11.3 now and treat any model loading from untrusted sources as an uncontrolled code execution path until verified.

Is CVE-2025-49655 actively exploited?

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

How to fix CVE-2025-49655?

1) PATCH IMMEDIATELY: upgrade all Keras installations to 3.11.3 — this is the only complete fix. Run `pip show keras` across your ML infrastructure to identify affected versions. 2) AUDIT model loading: catalog every place your code calls `keras.models.load_model()` or equivalent and identify the trust level of the source file. 3) DO NOT rely on safe_mode=True as a security control on any Keras version until you've confirmed 3.11.3 is deployed. 4) IMPLEMENT model provenance controls: cryptographic signing and hash verification of model files before loading, even from internal registries. 5) ISOLATE model loading: run model deserialization in sandboxed environments (containers with no network, read-only filesystems, minimal privileges) as a defense-in-depth measure. 6) DETECT: monitor for unexpected process spawning from Python/ML processes, outbound connections from training/inference nodes, and anomalous file access patterns post-model-load. 7) CHECK shared model stores: audit any Keras model files pulled from external sources (HuggingFace, S3, third parties) since Keras 3.11.0 was released (October 2025).

What systems are affected by CVE-2025-49655?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, model registries, MLOps platforms, collaborative AI development environments.

What is the CVSS score for CVE-2025-49655?

CVE-2025-49655 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.71%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingmodel registriesMLOps platformscollaborative AI development environments

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

AML.T0058 Publish Poisoned Models

Compliance Controls Affected

EU AI Act: Article 15, Article 9

ISO 42001: A.6.2.6, A.9.3

NIST AI RMF: GOVERN-6.2, MANAGE-2.2

OWASP LLM Top 10: LLM05:2025

What are the technical details?

Original Advisory

Deserialization of untrusted data can occur in versions of the Keras framework running versions 3.11.0 up to but not including 3.11.3, enabling a maliciously uploaded Keras file containing a TorchModuleWrapper class to run arbitrary code on an end user’s system when loaded despite safe mode being enabled. The vulnerability can be triggered through both local and remote files.

Exploitation Scenario

Adversary identifies a target organization using Keras for model serving or fine-tuning workflows. They craft a malicious .keras model file embedding executable Python code within a serialized TorchModuleWrapper class payload. The file is uploaded to a shared model registry (internal or public like HuggingFace), submitted as a 'fine-tuned' model via a partner API, or delivered through a compromised ML data pipeline. When an ML engineer or automated serving system calls `keras.models.load_model('malicious.keras', safe=True)` on an affected version, the deserialization triggers arbitrary code execution — establishing persistence, exfiltrating training data and credentials, or pivoting to adjacent GPU/compute infrastructure. The safe_mode=True call gives false confidence and introduces no actual barrier.

Weaknesses (CWE)

CWE-502 Deserialization of Untrusted Data Primary CWE-502 Deserialization of Untrusted Data

CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

[Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
[Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Source: MITRE CWE corpus.