CVE-2026-67425

This vulnerability isn't really an SSRF vulnerability — it's a credential routing vulnerability with an SSRF exploit path. The core issue: Flyto2 allows callers to specify a base_url for LLM requests, then forwards the operator's API keys to whatever endpoint the caller names. The SSRF guard exists as a downstream patch on an upstream design flaw. When your architecture requires credentials to travel through attacker-controlled destinations, the SSRF guard becomes the only thing between your API keys and exfiltration — and SSRF guards are notoriously brittle because they must exhaustively validate an infinite input space. The fix in 2.26.6 needs to be evaluated on a specific criterion: does it remove the credential-forwarding capability entirely, or does it add another validation layer operating on the same trust model? If base_url still accepts arbitrary strings but the code now checks an allowlist or rejects non-HTTPS, that's still a guard — brittle, as the SSRF history demonstrates. The genuine architectural fix is whether the code that transmitted credentials to caller-specified URLs is gone entirely, replaced with internal routing the caller cannot influence. Multi-tenant deployments need additional scrutiny. The CVE references 'the operator's API key,' but in shared infrastructure there's a critical distinction between operator-level keys (the SaaS provider's infrastructure credentials) and per-tenant keys (each customer's model API tokens). If Flyto2's original pattern meant any workflow's caller-specified base_url could receive any tenant's API key, the vulnerability isn't just credential theft — it's a complete bypass of tenant isolation with horizontal exposure across the entire user base. Verify your deployment: check whether 2.26.6 eliminates the base_url parameter or removes the code path that forwards credentials to caller-specified endpoints. If you're running multi-tenant infrastructure, confirm the new architecture segregates credentials by caller context — don't assume tenant isolation is enforced just because external exfiltration is blocked. The temporal dimension matters here: infrastructure-level vulnerabilities in automation tooling have systematically longer patching windows than application flaws, and the exploitation clock started when this CVE went public.

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