CVE-2026-46678

The real vulnerability in CVE-2026-46678 isn't the IPv6 bypass technique—it's the existence of force_download='allow-local' as a shipped escape hatch that fundamentally cannot be secured across all address encoding forms. The vendor knew this. Their response was telling: Agent.to_web, claiweb, VercelAIAdapter, and AGUIAdapter all explicitly block force_download from propagating into external data fetches. They contained the blast radius at the integration layer rather than fix the base API, which tells you everything about the underlying design problem. The pattern is familiar from three decades of SSRF filter bypasses: blocklist-based controls degrade over time because the attack surface—every possible encoding, translation, and resolution form of an IP address—is effectively infinite. Blocking 169.254.169.254 in IPv4 doesn't stop ::ffff:169.254.169.254 or the IPv6 equivalents. The fix for CVE-2026-25580 was always incomplete, not because of developer negligence, but because the design assumption itself was flawed: an escape hatch that says 'disable the blocklist' cannot simultaneously expect the blocklist to protect you. What you should do: audit any custom pipeline that accepts untrusted URLs and passes them through PydanticAI's fetch mechanism with force_download='allow-local'. If your pipeline doesn't use one of the bundled integrations (which contain the risk), you're holding the exposed surface. Consider whether your use case actually requires this parameter, or whether local file access can be served through a separate API surface that was never unsafe to begin with. The vendor chose to keep the escape hatch for backward compatibility—they contained it, they didn't remove it. That means every future developer on your team will encounter an API that looks safe but carries a known architectural weakness. Document that constraint in your codebase, because the CVE record won't preserve it.

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