SSRF Vulnerability in Koda-core web_fetch Tool Allows Redirects to Internal Endpoints, Cloud Metadata
A Server-Side Request Forgery vulnerability has been identified in the `web_fetch` tool within the Koda-core project, specifically in `src/tools/web_fetch.rs`. The flaw stems from a disconnect between the tool's initial URL validation logic and its actual HTTP request handling. The code validates the first URL via `is_safe_url` and a DNS pre-check, but then issues the request through a shared HTTP client that does not override reqwest's default redirect policy. By default, reqwest follows redirects automatically—up to 10 hops—meaning the initial safe check becomes irrelevant once a redirect chain begins.
The vulnerability allows an attacker to supply a publicly accessible URL that immediately redirects to internal or restricted infrastructure. Potential targets include localhost and IPv6 loopback ranges (`127.0.0.1`, `[::1]`), RFC1918 private address space (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`), link-local ranges, and critically, the cloud metadata endpoint at `169.254.169.254`. That endpoint is the standard gateway for credential and instance metadata on GCP, AWS, and other major cloud providers—a high-value target for service-side credential exfiltration. The documentation for the function even explicitly states it "follows redirects (up to 10 hops)," acknowledging the behavior without mitigating its security implications.
The issue surfaced during architecture review #1265 and has been classified as a Tier 1 security item, carrying P0/P1 priority. The attack surface is narrow but the impact, if exploited, could be severe—particularly in environments where the tool runs with network access to cloud metadata services. Mitigation would require implementing a custom redirect policy that re-validates each hop or blocks non-public destinations outright. The incident highlights a common but dangerous pattern: validation performed at request initiation that does not persist through subsequent redirect hops.