CVE-2025-54381: BentoML: unauthenticated SSRF via file upload URLs

Q: Is CVE-2025-54381 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2025-54381, increasing the risk of exploitation.

Q: How to fix CVE-2025-54381?

1. PATCH: Upgrade BentoML to 1.4.19 immediately — this is the only complete fix. 2. DETECT: Review access logs for POST requests to file upload endpoints containing URLs pointing to RFC1918 ranges (10.x, 172.16-31.x, 192.168.x), link-local (169.254.x.x), or internal hostnames. 3. CONTAIN: If immediate patching is blocked, apply egress network policy restricting outbound HTTP from BentoML containers to known external endpoints only — deny all to 169.254.0.0/16 and internal subnets at the network layer. 4. CLOUD HARDENING: Enforce IMDSv2 (token-required, PUT-based) on all EC2 instances running BentoML to significantly raise SSRF exploitation difficulty. Apply equivalent controls on GCP (disable legacy metadata) and Azure (use IMDS v2 endpoints). 5. AUDIT: Query CloudTrail for GetCallerIdentity and metadata endpoint calls (169.254.169.254) from BentoML service IPs since version 1.4.0 deployment date. Review IAM roles assigned to BentoML instances for excessive permissions.

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

This vulnerability affects the following AI/ML architecture patterns: model serving, inference API endpoints, MLOps pipelines, cloud-deployed AI services, multi-model serving platforms.

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

CVE-2025-54381 has a CVSS v3.1 base score of 9.9 (CRITICAL). The EPSS exploitation probability is 13.18%.

GHSA-mrmq-3q62-6cc8CRITICALPoC AVAILABLECISA: TRACK*

Published July 29, 2025

CISO Take

Any BentoML deployment on versions 1.4.0–1.4.18 is exploitable by unauthenticated external attackers to reach cloud metadata endpoints (AWS IMDSv1, GCP, Azure IMDS) and steal IAM credentials in a single request. Patch to 1.4.19 immediately and audit CloudTrail/GCP Audit Logs for metadata endpoint calls during the exposure window. The flaw was documented as an intended feature, meaning it has been present and exploitable since 1.4.0 with zero barrier to exploitation.

What is the risk?

Critical. CVSS 9.9 reflects no-auth, low-complexity exploitation with changed scope — meaning a compromise of BentoML can cascade to systems beyond the application itself. In cloud-native deployments, this is effectively a one-step path to full cloud account compromise: BentoML instances typically run with IAM roles granting broad access to S3 buckets, model registries, GPU instances, and MLflow/SageMaker resources. EPSS at 0.5% is currently low but expects upward pressure once PoC tooling circulates — the attack pattern is well-understood and trivially reproducible. The 'intended design' classification means no exploit development is needed; the documented API is the exploit.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
BentoML	pip	—	No patch
8.9KOpenSSF 6.423 dependentsPushed 7d ago50% patched~14d to patchFull package profile →
BentoML	pip	>= 1.4.0, < 1.4.19	`1.4.19`
8.9KOpenSSF 6.423 dependentsPushed 7d ago50% patched~14d to patchFull package profile →

How severe is it?

CVSS 3.1

9.9 / 10

EPSS

13.2%

chance of exploitation in 30 days

Higher than 96% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

○EPSS exploit prediction: 13%

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?

AVNetwork

ACLow

PRNone

UINone

SChanged

CHigh

ILow

ALow

What should I do?

5 steps

PATCH
Upgrade BentoML to 1.4.19 immediately — this is the only complete fix.
DETECT
Review access logs for POST requests to file upload endpoints containing URLs pointing to RFC1918 ranges (10.x, 172.16-31.x, 192.168.x), link-local (169.254.x.x), or internal hostnames.
CONTAIN
If immediate patching is blocked, apply egress network policy restricting outbound HTTP from BentoML containers to known external endpoints only — deny all to 169.254.0.0/16 and internal subnets at the network layer.
CLOUD HARDENING
Enforce IMDSv2 (token-required, PUT-based) on all EC2 instances running BentoML to significantly raise SSRF exploitation difficulty. Apply equivalent controls on GCP (disable legacy metadata) and Azure (use IMDS v2 endpoints).
AUDIT
Query CloudTrail for GetCallerIdentity and metadata endpoint calls (169.254.169.254) from BentoML service IPs since version 1.4.0 deployment date. Review IAM roles assigned to BentoML instances for excessive permissions.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableYes

Technical Impactpartial

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

How is it classified?

Supply ChainData ExtractionAuth BypassFrameworkInferenceAPIAML.T0010.001- AI Software AML.T0025- Exfiltration via Cyber Means AML.T0040- AI Model Inference API Access AML.T0049- Exploit Public-Facing Application AML.T0075- Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.15-Accuracy, Robustness and Cybersecurity

ISO 42001

A.10.2-Information security for AI systems

NIST AI RMF

MANAGE 2.4-Risk Response — Vulnerability Management

OWASP LLM Top 10

LLM03:2025-Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-54381?

Is CVE-2025-54381 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2025-54381, increasing the risk of exploitation.

How to fix CVE-2025-54381?

1. PATCH: Upgrade BentoML to 1.4.19 immediately — this is the only complete fix. 2. DETECT: Review access logs for POST requests to file upload endpoints containing URLs pointing to RFC1918 ranges (10.x, 172.16-31.x, 192.168.x), link-local (169.254.x.x), or internal hostnames. 3. CONTAIN: If immediate patching is blocked, apply egress network policy restricting outbound HTTP from BentoML containers to known external endpoints only — deny all to 169.254.0.0/16 and internal subnets at the network layer. 4. CLOUD HARDENING: Enforce IMDSv2 (token-required, PUT-based) on all EC2 instances running BentoML to significantly raise SSRF exploitation difficulty. Apply equivalent controls on GCP (disable legacy metadata) and Azure (use IMDS v2 endpoints). 5. AUDIT: Query CloudTrail for GetCallerIdentity and metadata endpoint calls (169.254.169.254) from BentoML service IPs since version 1.4.0 deployment date. Review IAM roles assigned to BentoML instances for excessive permissions.

What systems are affected by CVE-2025-54381?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference API endpoints, MLOps pipelines, cloud-deployed AI services, multi-model serving platforms.

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

CVE-2025-54381 has a CVSS v3.1 base score of 9.9 (CRITICAL). The EPSS exploitation probability is 13.18%.

What is the AI security impact?

Affected AI Architectures

model servinginference API endpointsMLOps pipelinescloud-deployed AI servicesmulti-model serving platforms

MITRE ATLAS Techniques

AML.T0010.001AI Software

AML.T0025Exfiltration via Cyber Means

AML.T0040AI Model Inference API Access

AML.T0049Exploit Public-Facing Application

AML.T0075Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Art.15

ISO 42001: A.10.2

NIST AI RMF: MANAGE 2.4

OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. In versions 1.4.0 until 1.4.19, the file upload processing system contains an SSRF vulnerability that allows unauthenticated remote attackers to force the server to make arbitrary HTTP requests. The vulnerability stems from the multipart form data and JSON request handlers, which automatically download files from user-provided URLs without validating whether those URLs point to internal network addresses, cloud metadata endpoints, or other restricted resources. The documentation explicitly promotes this URL-based file upload feature, making it an intended design that exposes all deployed services to SSRF attacks by default. Version 1.4.19 contains a patch for the issue.

Exploitation Scenario

An adversary identifies a public BentoML model inference API (discoverable via Shodan, GitHub, or API documentation). They craft a multipart form POST with a file_url parameter set to 'http://169.254.169.254/latest/meta-data/iam/security-credentials/'. BentoML's upload handler fetches the URL server-side without validation, returning the EC2 instance's IAM role name. A follow-up request to the role-specific metadata URL returns temporary AWS credentials (AccessKeyId, SecretAccessKey, SessionToken). The attacker uses these credentials to enumerate S3 buckets containing training data and model weights, access SageMaker endpoints, and pivot laterally into the broader AWS environment. Total exploitation time: under 5 minutes. No ML knowledge, no authentication, and no prior access required.

Weaknesses (CWE)

CWE-918Server-Side Request Forgery (SSRF)Primary CWE-918Server-Side Request Forgery

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.