Description

BentoML's outbound connection safeguard (make_safe_connect in _internal/utils/uri.py) blocks private, loopback, and link-local IP addresses but fails to reject the RFC 6598 shared address space (100.64.0.0/10, CGNAT). In versions 1.4.19 through 1.4.39, an unauthenticated attacker can supply URLs pointing to that range via multipart file handling (MultipartSerde.ensure_file) or JSON request parsing (JSONSerde.parse_request), causing the server to make outbound requests to internal hosts on CGNAT networks (Server-Side Request Forgery). This is an incomplete fix for CVE-2025-54381.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.8",
  "pubDate": "2026-08-24T01:16:57.823Z",
  "pubdate": "2026-08-24T01:16:57.823Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in BentoML versions 1.4.19 through 1.4.39, representing an incomplete fix for CVE-2025-54381.\nThe vulnerability resides within the outbound connection safeguard mechanism implemented via make_safe_connect in _internal/utils/uri.py.\nWhile the safeguard successfully blocks standard private, loopback, and link-local IP addresses, it fails to reject the RFC 6598 shared address space (100.64.0.0/10, Carrier-Grade NAT).\nUnauthenticated attackers can exploit this flaw by supplying specially crafted URLs pointing to the unblocked CGNAT range via multipart file handling through MultipartSerde.ensure_file or JSON request parsing through JSONSerde.parse_request.\nSuccessful exploitation forces the BentoML server to initiate unauthorized outbound requests to internal hosts residing on Carrier-Grade NAT networks, potentially leading to internal service discovery and unauthorized interactions within the internal network perimeter.\nThe risk implication involves bypassing network segmentation controls through application-layer request forgery, requiring network accessibility to the vulnerable BentoML application without prior authentication.",
  "technicalDetails": "The vulnerability stems from an incomplete IP address validation blacklist within the outbound connection safeguard mechanism, specifically the make_safe_connect function located in _internal/utils/uri.py.\nThe affected components responsible for processing attacker-supplied inputs are MultipartSerde.ensure_file during multipart file handling and JSONSerde.parse_request during JSON request parsing.\nThe affected product is BentoML, specifically version ranges 1.4.19 through 1.4.39.\nThe authentication requirement is unauthenticated, and the privilege requirement is none, as the exposed endpoints accept untrusted external inputs.\nThe network exposure includes any deployment where BentoML handles external HTTP requests and parses multipart or JSON payloads containing URIs.\nThe root cause is the omission of the RFC 6598 shared address space (100.64.0.0/10, CGNAT) from the IP restriction validation logic, which allows IP addresses within this range to bypass the validation checks designed to restrict internal network access.\nThe attack flow proceeds as follows: First, an unauthenticated attacker crafts an HTTP request containing a malicious payload delivered via either a multipart file upload or a JSON body parse operation.\nSecond, the payload incorporates a URL targeting an internal resource mapped within the RFC 6598 shared address space (100.64.0.0/10).\nThird, the BentoML application processes the request using MultipartSerde.ensure_file or JSONSerde.parse_request and passes the target URI to the connection utility.\nFourth, the make_safe_connect function evaluates the IP address against its blacklist, which incorrectly permits the CGNAT range because it fails to recognize 100.64.0.0/10 as a restricted internal boundary.\nFifth, the server establishes an outbound connection to the targeted internal host, executing the Server-Side Request Forgery and enabling the attacker to interact with internal services that rely on CGNAT addressing."
}