Agent TARS CLI: unauthenticated access to the local agent server

Upgrade to 0.3.1 (released 2026-10-08). It includes #1975 and #2026 and binds the server to 127.0.0.1 by default.

1. Upgrade the CLI: npm i -g @agent-tars/cli@latest (or pin 0.3.1).
2. If you need to reach the server from another machine, pass --host together with a long --auth-token (or TARKO_AUTH_TOKEN), and list your hostname in TARKO_ALLOWED_HOSTS. See the 0.3.1 release notes.
3. Until you upgrade, do not run 0.3.0 on an untrusted network, block inbound connections to port 8888 at the host firewall, and 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.

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). Fixed in 0.3.1 (2026-10-08). 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. This is now merged: #1975 for @tarko/agent-server-next and #2026 for @tarko/agent-server, which also requires a token for non-loopback access.
• 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.
9. 2026-09-24Maintainer merges #1975 and #2026 (Host validation on both servers) into main.
10. 2026-10-08Agent TARS CLI 0.3.1 released with both fixes; the server now binds to 127.0.0.1 by default and needs a token off loopback.

Finder: Aaron Elijah Mars of Aeon. Tool: Aeon.

• Fix PRs (merged 2026-09-24): bytedance/UI-TARS-desktop#1975, bytedance/UI-TARS-desktop#2026
• Fixed release: Agent TARS CLI 0.3.1
• 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