Agent TARS CLI: unauthenticated access to the local agent server

There is no fixed release yet.

1. Do not run the Agent TARS CLI (agent-tars) or any other @tarko/agent-server based server on an untrusted network (cafe, conference, shared office Wi-Fi).
2. Block inbound connections to port 8888 (or the port the CLI printed at startup; it moves up if 8888 is busy) at the host firewall, so only localhost can reach it. The server has no option to bind to localhost only.
3. Stop the server when you are not using it.
4. In Chrome 142 or later, keep the Local Network Access prompt on and deny it for sites you do not expect to talk to local services. Do not rely on other browsers to block this; we have not verified them.
5. Watch bytedance/UI-TARS-desktop#1975 and upgrade as soon as a release includes a fix.

When you run the Agent TARS CLI, it starts a local HTTP server (default port 8888) that drives an agent with shell and filesystem tools. The agent runs those tools without asking for confirmation. The server has no authentication and listens on all network interfaces. How exposed it is depends on the version.

The Agent TARS CLI (@agent-tars/cli -> @tarko/agent-cli -> @tarko/agent-server) from bytedance/UI-TARS-desktop: the published npm 0.3.0 (latest release, 2025-11-04) and main through c2ad42e (2026-07-01). No fixed version at time of writing. The UI-TARS Desktop Electron app is not affected. @tarko/agent-server-next has the same flaws, but no shipped product uses it (the only consumer in the repo is examples/bootstrap.ts).

• (a) Published npm 0.3.0. The server sends Access-Control-Allow-Origin: *, allows the Content-Type header, and has no CSRF check. Any web page the user visits while the server runs can send POST /api/v1/oneshot/query and read the reply. No DNS rebinding is needed. Because the agent has a shell tool (@agent-infra/mcp-server-commands) and filesystem tools, this is drive-by command execution as the user.
• (b) main since #1853 (2026-03-27, unreleased). #1853 added an origin allowlist and CSRF tokens, but the allowlist lets through any request that has no Origin header, and nothing checks the Host header. Browsers do not send Origin on same-origin GET requests, and a page whose hostname has been DNS-rebound to 127.0.0.1 is "same origin" with the local server. So a rebound page can read the API: session list and full session details and events (prompts, model outputs, tool calls, file paths, anything pasted into the agent), runtime settings, the sanitized agent configuration (model providers, base URLs), and a fresh CSRF token. POSTs from the rebound page do carry Origin, and the Express server rejects them, so on main the browser route is read-only.
• (c) Both versions. server.listen(port) is called with no host, so the server is reachable from the local network. A client there (no browser involved) can omit Origin, get a CSRF token from the global GET /api/v1/csrf-token, and send POST /api/v1/oneshot/query. That runs unauthenticated agent tasks, including shell commands.

Browser mitigation. Chrome 142 and later ask the user for Local Network Access permission before a public web page can reach a local address, and this also covers requests after DNS rebinding. If the user denies the prompt, (a) and (b) are blocked in Chrome. We have not verified other browsers. (c) does not involve a browser.

Library note. @tarko/agent-server-next (Hono) has the same missing-Origin pass and no Host check, and its CORS hook does not reject a disallowed origin, so a rebound POST with a harvested CSRF token also goes through. It skips auth when tenantConfig.auth is false. No shipped product uses it; only examples/bootstrap.ts does.

Permalinks at c2ad42e; npm lines from the published @tarko/agent-server@0.3.0 tarball.

• 0.3.0 CORS origin: '*', Content-Type allowed, no CSRF middleware: @tarko/agent-server@0.3.0 dist/index.js lines ~52050-52067 (getDefaultCorsOptions, setupAPI)
• 0.3.0 listen with no host: dist/index.js line 52170
• Default port 8888: agent-cli/src/core/options.ts#L12
• Shell and filesystem tools given to the agent: agent-tars/core/src/environments/local/index.ts#L175-L178
• One-shot query route: agent-server/src/api/routes/oneshot.ts#L16
• Missing-Origin pass on main: agent-server/src/api/index.ts#L13-L17
• Middleware order with no Host check (security headers, CORS, JSON, CSRF token route, CSRF check, routes): agent-server/src/api/index.ts#L85-L133
• CSRF safe-method exemption: agent-server/src/api/middleware/csrf-protection.ts#L46-L57
• Listen with no host on main: agent-server/src/server.ts#L258-L263
• Library note, agent-server-next CORS hook and serve call: agent-server-next/src/hooks/builtInHooks.ts#L79-L104 and agent-server-next/src/server.ts#L348-L352

A search of multimodal/tarko/ at this commit finds no Host header check of any kind.

• Bind to 127.0.0.1 by default, with an explicit option to listen on other interfaces. This is the only fix for (c): a non-browser client can put any value in Host.
• Ship a release that includes #1853, so published users stop sending Access-Control-Allow-Origin: * and get CSRF checks (fixes (a)).
• Check the inbound Host header against loopback host:port pairs (localhost, 127.0.0.1, [::1], [::ffff:127.0.0.1] on the server port, case-insensitive), return 403 otherwise, and run it before CORS (fixes (b)). An environment variable such as TARKO_ALLOWED_HOSTS can cover reverse-proxy setups. A patch for this part, with tests, is in bytedance/UI-TARS-desktop#1975.
• Consider a local auth token for the API and a confirmation step before shell commands started through the HTTP API.

Look for requests to the agent server on port 8888 (or the port it printed) that come from a non-loopback address (case c), that carry an Origin of a site the user did not open on purpose (case a, 0.3.0), or that have no Origin and a Host naming a non-loopback hostname (case b). Unexpected POST /api/v1/oneshot/query calls and unexpected shell commands in session history are the clearest signs. A working exploit is withheld.

1. 2025-11-04npm 0.3.0 published (@agent-tars/cli, @tarko/agent-server), with Access-Control-Allow-Origin: *.
2. 2026-03-27#1853 adds the CORS allowlist and CSRF protection on main (not released).
3. 2026-05-12Reported privately via GitHub PVR (GHSA-x4q8-2g66-789p), with a suggested fix.
4. 2026-07-20Follow-up on the advisory; no response.
5. 2026-08-27Follow-up with dated notice: public disclosure on 2026-09-26.
6. 2026-08-30Escalation email to ByteDance SRC (src@bytedance.com) with the same date; no response.
7. 2026-09-17Follow-up repeating the date; public fix PR #1975 opened.
8. 2026-09-23Public disclosure, three days ahead of the announced 2026-09-26 date, after 134 days without a vendor response; CVE requested from the ByteDance CNA.

Aaron Elijah Mars (aeonframework).

• Fix PR (open, pending review): bytedance/UI-TARS-desktop#1975
• GitHub advisory: GHSA-x4q8-2g66-789p (private; not yet published by the vendor)
• CVE: pending (requested via ByteDance SRC, the ByteDance CNA)
• Affected repository: bytedance/UI-TARS-desktop