CodeWhale fetch_url tool vulnerable to DNS-pinning TOCTOU bypass, enabling SSRF (fixed in 0.8.64)

A security advisory (GHSA-6v2g-fpxh-pmmh, tracked as CVE-2026-75856) discloses a server-side request forgery (SSRF) bypass in CodeWhale's fetch_url tool, affecting the deepseek-tui / codewhale-tui / codewhale packages. CodeWhale maintainers have validated the report; the fix ships in version 0.8.64 (commit 26de44a8). CVSS is scored at 8.6, and a working proof-of-concept is publicly available.

What was reported

According to the advisory, CodeWhale's DNS-pinning defense against SSRF has a time-of-check/time-of-use (TOCTOU) flaw. The tool is designed to resolve a domain once and reuse that resolved IP for the actual request, preventing an attacker-controlled DNS server from re-pointing a domain to an internal address between the check and the fetch. The researcher found that if the first DNS lookup(s) are made to fail (e.g., via a malicious DNS server that returns NXDOMAIN), CodeWhale's pinning logic treats the failure as expected and allows a later retry to proceed unpinned. On that later attempt, the attacker's DNS server can resolve the domain to a loopback or internal address (e.g., 127.0.0.1), and CodeWhale fetches content from that address instead of the intended public host — fully bypassing the SSRF mitigation. The PoC demonstrates this against the tool's fetch_url implementation using a custom DNS server that fails the initial A/AAAA queries before resolving to a local IP on a subsequent request.

Why it matters for defenders

Tools like CodeWhale that let an LLM agent fetch arbitrary URLs are a common SSRF attack surface, and DNS pinning is a standard mitigation for exactly this class of bug — so a bypass here defeats a control many teams assume is solid. Per the advisory, successful exploitation can expose services bound to localhost or other private/internal addresses, internal network resources, and cloud metadata/credential endpoints reachable from the host running the agent. Anyone running CodeWhale/deepseek-tui in an environment with network access to sensitive internal services or cloud instance metadata should treat this as high-impact, particularly since agentic fetch tools are frequently invoked with attacker-influenced or user-supplied URLs.

What defenders should watch for or do now

• Upgrade CodeWhale/deepseek-tui/codewhale-tui to 0.8.64 or later as soon as feasible.
• Until patched, treat any environment running the affected fetch_url tool as having a live SSRF exposure — restrict outbound network access from hosts running the agent (egress filtering, network segmentation) rather than relying solely on application-level DNS pinning.
• Block or tightly control cloud metadata endpoint access (e.g., 169.254.169.254) at the network layer for any host running this tooling, since app-layer SSRF defenses are exactly what this bug defeats.
• Hunt for anomalous DNS query patterns — repeated failed lookups (NXDOMAIN/SERVFAIL) for a domain immediately followed by a successful resolution to a private/loopback address — which mirrors the TOCTOU pattern described in the PoC.
• Review logs from hosts running CodeWhale for outbound requests to internal IP ranges or localhost following URL-fetch tool invocations.

Developing intel

This is a same-day advisory and detail here reflects only what the maintainers and reporter have published so far; further analysis or downstream advisories may add context. See the original GitHub Security Advisory for full technical details and the proof-of-concept: GHSA-6v2g-fpxh-pmmh.