al-ice.ai

Your Agent Is Listening on 0.0.0.0 and Your Workflow URLs Phone Home: fast-agent CVE-2026-102610 and Agenta CVE-2026-123786

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Two CVE records for AI agent platforms arrived in NVD within hours of each other on 6 November 2026 — and they tell the same story from opposite ends of the stack. CVE-2026-102610 (CVSS 6.4) records that fast-agent serve exposes an agent over MCP on HTTP bound to 0.0.0.0:8000 with no authentication by default, so that starting the server with the documented --shell flag turns any network-adjacent stranger into a remote shell. CVE-2026-123786 (CVSS 8.5) records that Agenta before 0.122.5 let a low-privilege workspace member point a workflow revision at an arbitrary URL that the server then fetched itself — following redirects while forwarding a minted secret token, which an attacker could capture to read provider secrets out of the vault API or reach internal and cloud-metadata addresses. One flaw points the network at your agent; the other points your platform at the attacker. Both fixes are already shipped (fast-agent 0.7.21, Agenta 0.122.5) — the CVE publication is what makes the exposure checkable, and both records are worth reading as deployment guidance, not just patch notes.

fast-agent: the quickstart flag that opens a shell to the network

The fast-agent advisory (GHSA-9vhv-g5hf-m7m7, reported by novice-22, CWE-78 plus CWE-306) is brutally simple. fast-agent serve uses HTTP transport bound to 0.0.0.0 on port 8000 with auth=None — the only opt-out is an OAuth provider via FAST_AGENT_SERVE_OAUTH — and prints no warning. Any host that can reach the port completes MCP initialize and tools/list with no credentials and can call the exposed agent tool. The detonation condition is the --shell flag (short form -x), which is the flag used in the project’s own README quickstart: with it, the agent carries a local execute shell tool, and the reporter verified live against 0.7.20 that a single plain-language message asking the agent to run a command via its shell tool made the model — a real production model, gpt-4o-mini — autonomously call execute and return the output (process identity as root, hostname, file contents) to the unauthenticated caller. A key-free deterministic reproduction with the passthrough model confirmed the server side never gates this: the permission prompt does not intervene in non-interactive serve mode. Without --shell the outcome is still bad — unauthenticated consumption of the operator’s LLM subscription and of every tool on the agent’s configured MCP servers. Note the score’s honesty: CVSS 6.4 with AV:N/AC:H/PR:H/UI:R bakes the serve-plus-shell preconditions into the number rather than pretending every install is remotely rootable. The fix range is <= 0.7.20, patched in 0.7.21 (upstream PR #828, commit ba99f89), and the reporter’s remediation asks remain the right default posture for any agent server: bind loopback unless explicitly told otherwise, and scream loudly when binding a non-loopback interface without authentication.

Agenta: the revision URL that took your vault token with it

The Agenta flaw (VulnCheck advisory dated 6 November 2026, credit to William Goodfellow, Syed Anas Mohiuddin, and Bandana of HackWitHer / APIsec Research Labs, CWE-918) is the subtler and more severe of the pair. A workflow or evaluator revision url supplied by a user holding only workflow-edit rights was validated by a helper that checked scheme and netloc only — http://169.254.169.254/ and http://127.0.0.1/ sail through — and then POSTed server-side by an HTTP client built with follow_redirects=True, with a freshly minted Agenta Secret token attached in the Authorization header. That combination is the whole attack: SSRF to internal and link-local targets on the first request, and credential exfiltration on the redirect hop, after which the captured token’s secret-resolve grant opens the vault API and the provider secrets inside it. The advisory’s most damning detail is the asymmetry it documents: the webhook path in the same codebase was already hardened with a real validator that DNS-resolves and blocks private, loopback, and metadata addresses — the workflow path simply never got the same treatment, reachable on the open-source build through the evaluation-start endpoint. The 0.122.5 patch (upstream PR #7530, commit 95fedd7, released 12 October 2026) applies exactly the lesson the codebase already knew: run credentials minted for foreign workflow URLs no longer carry the secret-resolve grant (reserved for the operator’s own service URL), outbound workflow calls pass an egress check that refuses private, loopback, link-local, and metadata addresses with the connection pinned to the checked address, and workflow service calls no longer follow redirects. Self-hosters running custom workflows on private networks over plain HTTP get a deliberate friction point — an explicit allowlist or insecure-egress flag — which is the correct price. This is the same server-fetches-attacker-URL class as our November CrewAI parser-differential SSRF coverage and the Chainlit allowed-URLs SSRF — except the leaked credential here upgrades every SSRF probe into a secrets-theft primitive.

What to actually do

  1. Upgrade to fast-agent 0.7.21+ and Agenta 0.122.5+, then rotate what the flaws could have touched: on Agenta, every provider secret readable through the vault API and every minted service credential on pre-fix installs; on fast-agent serve hosts, the operator’s LLM API keys and any credential reachable through the agent’s configured MCP servers. The Agenta token-forwarding means secrets must be treated as already exposed, not merely at risk.
  2. Never serve an agent on 0.0.0.0 without authentication. Bind fast-agent (and any MCP server you run) to loopback, put authentication in front before exposing it further, and treat README quickstart flags such as -x/--shell as capability grants — convenient on localhost, remote code execution everywhere else. Our November MCP OAuth resource-confusion coverage shows the surrounding protocol is still earning its authentication the hard way.
  3. Egress-check every URL your platform fetches server-side — resolve, block private/loopback/link-local/metadata, pin the connection, do not follow redirects to unchecked hosts, and never forward credentials to non-allowlisted destinations. If your codebase already has a hardened validator on one path (as Agenta did for webhooks), grep for every sibling path that skipped it.
  4. For builders: scope minted credentials to the narrowest grant and destination at mint time. The Agenta fix’s split — secret-resolve only for the operator’s own service URL — is a pattern worth copying into any system where user-supplied URLs meet server-side fetches with ambient authority.

Our verification was read-only. We read the NVD 2.0 API records first-hand for both CVEs (CVE-2026-102610 published 6 November 2026 ~21:17 UTC, CVSS 3.1 6.4 AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H; CVE-2026-123786 published 6 November 2026 ~15:17 UTC, CVSS 3.1 8.5 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N; both in Received state at read time, so affected-range and score detail is carried from the vendor advisories below and stated openly here), the complete GitHub security-advisory records via API (GHSA-9vhv-g5hf-m7m7 with reporter credit, CWE-78/CWE-306, affected <= 0.7.20 and 0.7.21 patch range plus the live-verification transcript and PoC; GHSA-pr74-8wxx-gj2h with the scheme-plus-netloc validation gap, the redirect-forwarding sink, the webhook-path asymmetry, and the 0.122.5 patch behavior), the VulnCheck advisory page for CVE-2026-123786 (severity high, CVSS 4.0 8.4, APIsec Research Labs credit, PR #7530 and v0.122.5 references), and both fix release tags via the GitHub API (v0.7.21, v0.122.5 released 12 October 2026). We ran no server, sent no request to any MCP endpoint, set no revision URL, minted no token, cloned no repo, and contacted no vendor. Brave Search was used for discovery only.

Sources: