CVE-2026-78205: BentoML SSRF — MEDIUM

CISO Take

BentoML's outbound connection guardrail blocks private, loopback, and link-local addresses but misses the RFC 6598 shared address space (100.64.0.0/10), the CGNAT range widely used inside Kubernetes overlays and cloud VPCs to number internal services. An unauthenticated attacker can exploit this simply by pointing a multipart file upload or a JSON request field at a 100.64.x.x address, forcing the BentoML server to make outbound requests on their behalf — a classic SSRF with no login required and low attack complexity (CVSS 5.8, AC:L/PR:N/UI:N). There's no CISA KEV listing, no known public exploit, and no EPSS data yet, so mass exploitation isn't imminent, but this is the second time this exact safeguard has failed (it's an incomplete fix for CVE-2025-54381), which signals the allowlist/denylist approach itself is fragile. Any BentoML deployment on versions 1.4.19–1.4.39 that's internet-facing or reachable from untrusted tenants should upgrade past 1.4.39 immediately; where patching is delayed, enforce egress filtering at the network layer (deny outbound to 100.64.0.0/10 from the BentoML host/pod) rather than relying solely on the application-level check. Detection teams should watch for BentoML server processes initiating outbound connections to 100.64.0.0/10 destinations, which should never be legitimate application traffic.

Sources:NVDGitHub AdvisoryVulnCheckATLAS

What is the risk?

Medium-severity, low-complexity, unauthenticated SSRF. Exploitability is high in principle (no auth, no user interaction, network-reachable) but real-world impact depends on what sits behind the CGNAT range in the victim's environment — in Kubernetes/cloud-native deployments this space often carries pod-to-pod traffic, internal load balancers, or metadata-adjacent services. No KEV listing, no public PoC/nuclei template, and no EPSS score currently, so opportunistic mass exploitation is not yet evident. The bigger risk signal is architectural: this is a second bypass of the same SSRF guardrail (following CVE-2025-54381), suggesting the fix pattern (denylist of IP ranges) is incomplete by design rather than a one-off oversight, which raises the odds of further bypasses being found.

How does the attack unfold?

Initial Access

Unauthenticated attacker submits a multipart file upload or JSON payload containing a URL pointing to a 100.64.0.0/10 (CGNAT) address to a public-facing BentoML endpoint.

AML.T0049

SSRF Bypass

BentoML's make_safe_connect safeguard fails to reject the CGNAT range, allowing the crafted outbound request to pass validation.

Impact

The BentoML server issues the outbound connection on the attacker's behalf, enabling reconnaissance or interaction with internal hosts on the CGNAT network that should be unreachable from the public internet.

AML.T0075

Initial Access

Unauthenticated attacker submits a multipart file upload or JSON payload containing a URL pointing to a 100.64.0.0/10 (CGNAT) address to a public-facing BentoML endpoint.

AML.T0049

SSRF Bypass

BentoML's make_safe_connect safeguard fails to reject the CGNAT range, allowing the crafted outbound request to pass validation.

Impact

The BentoML server issues the outbound connection on the attacker's behalf, enabling reconnaissance or interaction with internal hosts on the CGNAT network that should be unreachable from the public internet.

AML.T0075

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
BentoML	pip	—	No patch
8.9KOpenSSF 6.423 dependentsPushed 4d ago50% patched~14d to patchFull package profile →

Do you use BentoML? You're affected.

How severe is it?

CVSS 3.1

5.8 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 35% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○Public PoC indexed (trickest/cve)

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

CLow

INone

ANone

What should I do?

1 step

1) Upgrade BentoML to a version beyond 1.4.39 where the RFC 6598 range is included in the outbound connection denylist (verify the patched uri.py against the referenced GitHub line range). 2) Until patched, add network-layer egress controls (firewall/NetworkPolicy) on the BentoML host or pod denying outbound connections to 100.64.0.0/10, don't rely on the application-level check alone. 3) Audit all endpoints that accept file uploads or JSON with URL/URI fields (MultipartSerde.ensure_file, JSONSerde.parse_request) for unnecessary internal reachability. 4) Monitor egress logs/NetFlow for BentoML server processes connecting to 100.64.0.0/10 destinations as a detection signal. 5) Apply defense-in-depth: run inference services in a network segment with no route to sensitive internal services regardless of application-layer filtering.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableYes

Technical Impactpartial

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

How is it classified?

Data LeakageAuth BypassInferenceFrameworkAML.T0049- Exploit Public-Facing Application AML.T0075- Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MAP 5.1-Risks and benefits of third-party AI components are identified

OWASP LLM Top 10

LLM03-Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-78205?

BentoML's outbound connection guardrail blocks private, loopback, and link-local addresses but misses the RFC 6598 shared address space (100.64.0.0/10), the CGNAT range widely used inside Kubernetes overlays and cloud VPCs to number internal services. An unauthenticated attacker can exploit this simply by pointing a multipart file upload or a JSON request field at a 100.64.x.x address, forcing the BentoML server to make outbound requests on their behalf — a classic SSRF with no login required and low attack complexity (CVSS 5.8, AC:L/PR:N/UI:N). There's no CISA KEV listing, no known public exploit, and no EPSS data yet, so mass exploitation isn't imminent, but this is the second time this exact safeguard has failed (it's an incomplete fix for CVE-2025-54381), which signals the allowlist/denylist approach itself is fragile. Any BentoML deployment on versions 1.4.19–1.4.39 that's internet-facing or reachable from untrusted tenants should upgrade past 1.4.39 immediately; where patching is delayed, enforce egress filtering at the network layer (deny outbound to 100.64.0.0/10 from the BentoML host/pod) rather than relying solely on the application-level check. Detection teams should watch for BentoML server processes initiating outbound connections to 100.64.0.0/10 destinations, which should never be legitimate application traffic.

Is CVE-2026-78205 actively exploited?

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

How to fix CVE-2026-78205?

1) Upgrade BentoML to a version beyond 1.4.39 where the RFC 6598 range is included in the outbound connection denylist (verify the patched uri.py against the referenced GitHub line range). 2) Until patched, add network-layer egress controls (firewall/NetworkPolicy) on the BentoML host or pod denying outbound connections to 100.64.0.0/10, don't rely on the application-level check alone. 3) Audit all endpoints that accept file uploads or JSON with URL/URI fields (MultipartSerde.ensure_file, JSONSerde.parse_request) for unnecessary internal reachability. 4) Monitor egress logs/NetFlow for BentoML server processes connecting to 100.64.0.0/10 destinations as a detection signal. 5) Apply defense-in-depth: run inference services in a network segment with no route to sensitive internal services regardless of application-layer filtering.

What systems are affected by CVE-2026-78205?

This vulnerability affects the following AI/ML architecture patterns: model serving, ml_ops pipelines.

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

CVE-2026-78205 has a CVSS v3.1 base score of 5.8 (MEDIUM). The EPSS exploitation probability is 0.41%.

What is the AI security impact?

Affected AI Architectures

model servingml_ops pipelines

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0075Cloud Service Discovery

Compliance Controls Affected

NIST AI RMF: MAP 5.1

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker with no credentials sends a multipart file-upload request (or a JSON payload) to a public-facing BentoML inference endpoint, embedding a URL that points to a host in 100.64.0.0/10 — for example an internal service the organization numbers within its CGNAT-addressed Kubernetes overlay. Because make_safe_connect only checks against private/loopback/link-local ranges, the request passes validation and BentoML's server issues the outbound connection on the attacker's behalf. The attacker can now use the BentoML server as a blind proxy to probe or interact with internal-only services, potentially discovering internal APIs, dashboards, or other endpoints that were never intended to be reachable from the public internet, laying groundwork for further lateral movement or data exposure.

Weaknesses (CWE)

CWE-918Server-Side Request ForgeryPrimary CWE-918Server-Side Request Forgery

CWE-918 — Server-Side Request Forgery: 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.