High

AgentAPI DNS Rebinding Localhost Access

A malicious web page can trick a browser into treating a locally-running AgentAPI service as if it belonged to the attacker's website, then use that trust to read out private message history, secret keys, and file contents. This works against older AgentAPI versions (0.3.3 and below) that run over plain HTTP without protections against this technique.

How the attack works

AgentAPI listens on localhost, so it normally only receives requests from the same machine. An attacker gets a victim to visit a malicious web page, which first resolves a DNS name to the victim's own machine (or briefly to an external server, then rebinds it to localhost). The browser, believing the page's origin now includes localhost, is allowed to issue requests to AgentAPI's /messages endpoint despite same-origin restrictions. The rule confirms this by seeing the AgentAPI control plane reached through a DNS name instead of the loopback address, at the same time as normal loopback traffic to the same host — proving the rebinding happened rather than a coincidental public service. Repeated fetches of the rebound name, or a follow-up request to an unrelated external host, indicate the attacker is actually pulling data out rather than just probing.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID
7b3f1c94-2a6e-4d51-9c0f-8e42d5a1b6f3
Severity
High

Why it matters

An attacker can silently harvest a user's local AgentAPI message history, embedded secret keys, and any file content the API exposes, all without needing credentials or network access beyond getting the victim to load a web page.

What you can do

  • →Upgrade AgentAPI past 0.3.3 or apply any available fix that validates the Host header and rejects non-loopback names.
  • →Bind AgentAPI strictly to 127.0.0.1 and reject requests whose Host or Origin header doesn't match a loopback literal.
  • →Avoid exposing AgentAPI through dev tunnels (ngrok, IDE port forwarding) or public DNS names, even temporarily.
  • →Serve AgentAPI over HTTPS with a pinned certificate where possible, and review /etc/hosts entries that map custom domains to 127.0.0.1 on developer machines.

Known benign look-alikes

  • Developer maps a project-specific hostname to 127.0.0.1 in /etc/hosts and drives AgentAPI through that name over plain HTTP; anchor A fires legitimately.
  • Dev tunnelling or port-forwarding tools (ngrok-style tunnels, IDE port forwarding) publish the local AgentAPI under a public DNS name during a demo, so the agent reaches /messages through that name while also polling loopback.
  • An internal self-hosted chat or queue service exposes /messages over plain HTTP on a corporate DNS name while the same workstation runs an unrelated loopback HTTP dev server, producing both stages without any rebinding.
  • IDE webviews, browser extensions and local dashboards legitimately send an Origin or Referer header when calling the localhost API, which satisfies anchor B.
  • In replay, header_* meta keys are not stored in snapshots, so anchors B and C can never fire there; only anchor A is reproducible offline.

References