Introduction
Attackers can force AI infrastructure to request sensitive internal resources by submitting a crafted file upload request. That is the impact of CVE-2025-54381, a critical Server-Side Request Forgery (SSRF) vulnerability in BentoML, a Python library widely used for deploying and serving machine learning models. The flaw affects versions 1.4.0 through 1.4.19 and can be exploited without authentication, so any exposed BentoML deployment is at significant risk.
About BentoML: BentoML is an open-source Python framework for deploying and serving machine learning models. Organizations from startups to large enterprises use it to run AI workloads in production. Because it is popular in AI infrastructure, a vulnerability in BentoML can have broad consequences for organizations that rely on it for automated model inference and serving.
Technical Information
CVE-2025-54381 comes from how BentoML processes file uploads in its multipart form data and JSON request handlers. In affected versions (1.4.0 through 1.4.19), both handlers accept user-supplied URLs and download files from them automatically. There is no robust validation to check whether a URL resolves to an internal network address, a cloud metadata endpoint, or another protected resource.
- Multipart Handler: This code path does almost no validation. The server fetches any URL the user provides, whether it points to an internal service, localhost, or a cloud metadata endpoint.
- JSON Handler: This path has some basic scheme checks (such as requiring
httporhttps), but they are not enough. Attackers can bypass them with encoding tricks, redirects, or gaps in the validation logic.
The flaw is more dangerous because the official BentoML documentation promoted this URL-based upload feature, which made SSRF exposure a default risk for every deployment on these versions. Attackers can craft requests that make the BentoML server reach internal APIs, cloud provider metadata endpoints (such as AWS 169.254.169.254), or other sensitive resources. The result can be information disclosure, lateral movement, or further compromise of the infrastructure.
Patch Information
The BentoML development team fixed the SSRF vulnerability in the file upload processing system in version 1.4.19. The patch adds validation that stops file uploads from being used to reach the internal network without authorization. It changes three things:
-
The patch processes only URLs with explicitly allowed schemes (e.g.,
http,https) and blocks other schemes that could be abused for SSRF attacks. -
The patch checks the destination IP address of each provided URL. If a URL resolves to an internal IP address (such as one in the
10.0.0.0/8,172.16.0.0/12, or192.168.0.0/16ranges), the upload is denied, so the application cannot be used as a conduit to internal services. -
The deserialization handlers for multipart form data and JSON requests now run these checks, so every file upload path is protected against SSRF.
Code Implementation:
import ipaddress import urllib.parse ALLOWED_SCHEMES = {"http", "https"} INTERNAL_IP_RANGES = [ ipaddress.ip_network("10.0.0.0/8"), ipaddress.ip_network("172.16.0.0/12"), ipaddress.ip_network("192.168.0.0/16"), ipaddress.ip_network("127.0.0.0/8"), ipaddress.ip_network("::1/128"), ] def is_internal_address(url): parsed_url = urllib.parse.urlparse(url) if parsed_url.scheme not in ALLOWED_SCHEMES: return True try: host_ip = ipaddress.ip_address(socket.gethostbyname(parsed_url.hostname)) return any(host_ip in net for net in INTERNAL_IP_RANGES) except ValueError: return True return False # Usage in file upload handling if is_internal_address(user_provided_url): raise ValueError("Access to internal addresses is not allowed.")
With these checks in place, BentoML rejects uploads that point at disallowed schemes or internal addresses, which reduces the risk of SSRF attacks. Users should upgrade to version 1.4.19 to get these fixes.
References:
Detection Methods
Finding SSRF vulnerabilities like the one in BentoML's file upload processing system takes both proactive and reactive measures. The methods below help you identify and monitor for SSRF exploits.
1. Code Review and Static Analysis:
Start with a thorough review of your codebase, focusing on places where the application processes external input, especially URL handling. Static analysis tools can flag insecure coding patterns that lead to SSRF, such as functions or methods that make HTTP requests from user input without proper validation.
2. Input Validation and Whitelisting:
Define a whitelist of acceptable URL schemes and domains, so the application only sends requests to trusted, predefined destinations. For BentoML, make sure the serialization/deserialization handlers for multipart form data and JSON requests do not automatically download files from untrusted sources without proper validation.
3. Dynamic Application Security Testing (DAST):
DAST tools simulate real-world attacks on your application. They can find SSRF vulnerabilities by trying to exploit weaknesses in how the application handles external requests. Running these tests regularly catches vulnerabilities that static analysis might miss.
4. Monitoring and Logging:
Log every outgoing HTTP request the server makes. Watch these logs for unusual patterns, such as requests to internal network addresses, cloud metadata endpoints, or localhost services, because these can indicate SSRF attempts. Alerts that fire when the logs show a suspicious request give you real-time awareness of potential exploits.
5. Network Segmentation and Firewall Rules:
Use network segmentation to stop the server from reaching internal resources that should not be accessible externally, and add firewall rules that block the server from opening connections to sensitive internal services. This gives you another layer of defense against SSRF attacks.
6. Regular Security Audits and Penetration Testing:
Run regular security audits and penetration tests to find and fix SSRF vulnerabilities. Security professionals doing in-depth testing can uncover complex vulnerabilities that automated tools might miss.
References:
Affected Systems and Versions
- Product: BentoML (Python library for AI model serving)
- Affected Versions: 1.4.0 through 1.4.19 (inclusive)
- Vulnerable Configurations: Any deployment on these versions that uses the file upload feature to process user-supplied URLs through the multipart form data or JSON handlers
Vendor Security History
BentoML has had multiple critical vulnerabilities in recent releases:
- CVE-2025-27520: Remote code execution via insecure deserialization (a previously patched issue that was reintroduced)
- CVE-2025-32375: Remote code execution in the runner server component
- Recurring issues with insecure network request handling and insufficient validation
The vendor has released timely patches, but the recurring critical flaws suggest that its secure development and regression testing practices need improvement.
