GPU VulnDB

Database/AI/ML frameworks & serving

BentoML: SSRF filter misses 100.64.0.0/10, so serving pods fetch from internal CGNAT hosts

CVE-2026-78205AI/ML frameworks & servingcurated

Impact

BentoML's outbound-connection guard in _internal/utils/uri.py rejects private, loopback and link-local addresses but not the RFC 6598 shared range, so an unauthenticated caller who supplies a URL through multipart file handling (MultipartSerde.ensure_file) or JSON request parsing (JSONSerde.parse_request) makes the serving process issue requests into 100.64.0.0/10. That range is not exotic on this kind of fleet: Kubernetes installs frequently carve pod and service CIDRs out of 100.64/10, and CGNAT-addressed management endpoints exist in several cloud and colocation networks. The result is a model-serving endpoint - usually the most broadly exposed thing on a GPU node - acting as a probe or proxy into the cluster's own address space. This is an incomplete fix for CVE-2025-54381, so a deployment that patched for that one is still exposed.

Who can reach it

Network, unauthenticated. Anyone who can POST to a BentoML service endpoint that accepts a file or a JSON body. No credentials and no tenancy on the cluster are required.

What to do

Versions 1.4.19 through 1.4.39 are affected and the record names no fixed release - the upstream issue is open - so this is mitigate-only today. Deny egress from serving pods to 100.64.0.0/10 (and to everything else not explicitly required) with a NetworkPolicy or egress firewall, and reject user-supplied URLs at the gateway rather than relying on the in-process allowlist. When a fixed version ships, adopting it is a rolling restart of the serving deployment, not a node drain.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.