CVE-2026-78205, published on 24 August at 01:16 UTC, is a server-side request forgery in BentoML's outbound connection safeguard, affecting versions 1.4.19 through 1.4.39. It is explicitly an incomplete remediation of an earlier vulnerability from 2025.
The gap, and why it is easy to miss
The guard function rejects private, loopback and link-local addresses. It does not reject the RFC 6598 shared address space, 100.64.0.0/10 — the range used for carrier-grade NAT. The reason is instructive: Python's standard ipaddress module does not classify that block as private, so a check written in terms of "is this address private" passes it through. The developer wrote a plausible test and the library answered accurately; the definition simply does not match the threat model. An attacker supplies a URL through multipart file handling or JSON parsing and reaches internal hosts on CGNAT networks.
What the common framing gets wrong
An incomplete fix is not the same class of event as a fresh discovery, and the distinction cuts against the vendor rather than for it. The original vulnerability was reported, accepted and patched; the patch was then treated as closing the matter. What published this week is evidence that the remediation was tested against the reported case rather than against the category. The relevant question for anyone running an affected version is not whether they applied the 2025 fix — they may well have — but whether applying it left them believing they were covered.
The timeline
The reporter states the issue was sent by email on 2 June with no response since. A public issue was opened on 30 June and remains open. That is roughly 83 days from private report to public CVE with, by the reporter's account, no acknowledgement in between — which is how a coordinated disclosure turns into an uncoordinated one.
The pattern across the night
This landed within two hours of two llama.cpp RPC vulnerabilities. All three are AI-serving infrastructure, and in all three cases the maintainers had already been told.