CVE-2026-78205

The CVE-2026-78205 gap in BentoML's URI safeguard is not a simple oversight. It is evidence that blocklist-based SSRF mitigations are structurally incapable of providing complete protection—and the 'incomplete fix' framing obscures a deeper architectural problem that analysts must confront. CVE-2025-54381 addressed the obvious private ranges (10.x, 172.16.x, 192.168.x) and passed most security scanners. But RFC 6598 space (100.64.0.0/10) has been documented as SSRF-adjacent since 2012—IETF RFC 6598 Section 4 explicitly states that shared address space addresses 'MUST NOT be used as global identifiers,' flagging this range for internal NAT use. A thorough security review of a URI allowlist should have caught this. The question is whether BentoML's original fix was a minimal patch reacting to a reported CVE, or whether a comprehensive threat model of their multipart and JSON parsing paths was ever performed. The shared utility being exploitable at both MultipartSerde.ensure_file and JSONSerde.parse_request entry points reveals a critical architectural gap: the URI validation layer is not centrally audited as security-critical infrastructure. It is treated as 'solved' after each CVE closure, which erodes institutional memory between patches. This pattern—SSRF blocklist failure followed by incomplete fix followed by a new CIDR gap—has repeated for over a decade across vendors. The underlying validation logic remains unchanged in structure, only narrowed in scope. Every future code path that touches URI parsing inherits the same assumption: that the blocklist is complete. This is worse in BentoML than a typical web framework. ML serving platforms run with elevated IAM roles, cloud credentials, and network access to model registries, training data buckets, and feature stores. An SSRF reaching CGNAT space doesn't just hit a config server—it may reach the data pipelines and cloud metadata that power the entire ML workflow. The false sense of coverage from CVE-2025-54381 compounds this: organizations running 1.4.19 through 1.4.39 with untrusted URL input have likely built trust in the platform precisely because of its cloud integrations, meaning the blast radius includes those surfaces. Analysts should treat the entire 1.4.x release line as untrusted for any deployment handling untrusted URL input, not because the CGNAT vector is necessarily exploitable in every environment, but because the architecture that missed it is still running. The fix path forward is not adding more CIDR blocks to a blocklist—it is demanding a single, versioned, centrally-audited URI validation module with explicit threat model boundaries documented and maintained. Without that, every future Serde variant will inherit this vulnerability class.

Reviewed through automated stages and approved by a human before publication.