Updated November 11, 2026. Lab run in an isolated network namespace with no external network: fast-agent-mcp 0.7.20, 0.7.21, and 0.10.54, passthrough model, no API keys.
A fast-agent vulnerability tracked as CVE-2026-102610 let any client that could reach fast-agent serve run shell commands on the host without logging in. fast-agent is an open source Python framework from evalstate for building, running, and evaluating AI agents with Model Context Protocol (MCP) support, with about 4,000 GitHub stars and 108,163 PyPI downloads in the last month. The GitHub Advisory Database published the reviewed advisory on November 9, 2026, three days after the CVE reached the National Vulnerability Database (NVD).
The fix shipped nearly five months earlier, in version 0.7.21 on June 19, 2026, and it changes less than most write-ups imply. In our November 11 lab, 0.7.21 and the current 0.10.54 bound to 127.0.0.1 by default, but an unauthenticated client on the same machine still ran a shell command, and adding --host 0.0.0.0 restored full remote access with only a printed warning. Upgrading is enough for a single-user laptop that keeps the default host. It is not enough for containers, shared virtual machines, or any deployment that passes --host 0.0.0.0 with --shell.
TL;DR
- CVE-2026-102610 (GHSA-9vhv-g5hf-m7m7) affects fast-agent-mcp 0.7.20 and earlier: fast-agent serve listened on 0.0.0.0:8000 with no authentication and no warning.
- With the
--shellflag, an unauthenticated MCP client could make the served agent run operating system commands as the user who started the server. - Version 0.7.21, released June 19, 2026, moved the default host to 127.0.0.1 and added warnings for remote binds; it did not add token authentication.
- In our lab, fast-agent 0.7.21 and 0.10.54 ran an unauthenticated shell command from loopback, and both returned full remote access when started with
--host 0.0.0.0. - Every version we tested answered an MCP initialize request carrying a foreign Host and Origin header with HTTP 200, although the MCP specification requires Origin validation.
What CVE-2026-102610 Says About fast-agent serve
CVE-2026-102610 says fast-agent serve in fast-agent-mcp 0.7.20 and earlier exposed the agent over MCP on all network interfaces, port 8000, with authentication set to none. Any host that could reach the port could call the exposed agent tool, and with --shell that tool could run operating system commands.
fast-agent serve turns a configured agent into an MCP server, so other MCP clients can call it as a tool over Streamable HTTP or stdio. The --shell flag, short form -x, gives that agent a local shell tool. The reporter, GitHub user novice-22, reproduced the attack on 0.7.20 in a python:3.13-slim Docker container with both gpt-4o-mini and the key-free passthrough model, and wrote that the server-side permission prompt did not block commands in non-interactive serve mode.
The advisory carries a CVSS 3.1 score of 6.4 with the vector AV:N/AC:H/PR:H/UI:R, meaning high privileges and user interaction required. Armis argues that the score is inconsistent with a flaw that needs no authentication, and recommends treating it as critical wherever the serve port is reachable and --shell is on. The 6.4 rating reflects the preconditions, serve mode plus the shell flag, more than the impact once both are present.
| Field | Value |
|---|---|
| Identifiers | CVE-2026-102610, GHSA-9vhv-g5hf-m7m7 |
| Package | fast-agent-mcp on PyPI |
| Affected | 0.7.20 and earlier |
| Patched | 0.7.21 (June 19, 2026); latest is 0.10.54 (November 10, 2026) |
| Severity | Moderate, CVSS 3.1 6.4 (AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H) |
| Weaknesses | CWE-306 missing authentication, CWE-78 OS command injection |
| Fix | Commit ba99f89 in pull request 828: default host 127.0.0.1, warnings for remote binds |
What Changed in fast-agent 0.7.21
fast-agent 0.7.21 changed the default bind address and added warnings, and it left authentication as it was. The release commit ba99f89, merged as pull request 828, switched the --host default from 0.0.0.0 to 127.0.0.1 in the serve command, the agent server, the FastAgent constructor, and the prompt server.
The same commit added a _serve_security_warning_messages check that prints a yellow warning when HTTP serving binds to a non-loopback address, and a red warning when --shell is also on. The 0.7.21 release notes list new models, Skills over MCP, and plugin changes, and they do not mention the security fix, so teams reading changelogs had no prompt to upgrade for this reason in June.
The only built-in way to require authentication on fast-agent serve is still Hugging Face OAuth, switched on with FAST_AGENT_SERVE_OAUTH=huggingface and aimed at Hugging Face Spaces. We confirmed that in the 0.7.20, 0.7.21, and 0.10.54 source. The fast-agent server documentation now tells operators to bind to a non-loopback address only when remote clients should connect, and to prefer request-scoped instances for public or multi-user servers.
--shell, captured November 11, 2026. Image: fast-agent.ai.What Our Lab Found in 0.7.20, 0.7.21, and 0.10.54
Our lab found that every tested version ran a shell command for a client that sent no credentials, and that the fix only changes who can reach the port by default. We ran each version with fast-agent serve --model passthrough --shell in a Linux network namespace with only a loopback interface, using the official MCP Python client.
--shell. Image: AgentStack.fast-agent 0.7.20 bound to 0.0.0.0:8000 with no flag at all and printed nothing. The client completed initialize, listed one tool named agent, and sent the passthrough directive ***CALL_TOOL execute with a harmless command that printed a marker string. The server returned the command output and the line “process exit code was 0”.
fast-agent 0.7.21 bound to 127.0.0.1:8000 by default, which closes the remote path on a host where nothing else forwards the port. The same unauthenticated request from loopback still ran the command. Starting 0.7.21 with --host 0.0.0.0 printed both warnings and then behaved exactly like 0.7.20.
fast-agent 0.10.54, the current release, renamed the shell tool. Calling execute returned “Tool 'execute' is not available. Available tools: bash, edit_file, process, read_text_file, write_text_file.” {HL(“In fast-agent 0.10.54, the --shell flag gives the served agent file write and edit tools as well as a shell, so an unauthenticated caller reaches more than command execution.”)} The bash call ran our command, and 0.10.54 printed a shell warning even on the loopback default.
The command reported user ID 0 because our sandbox ran the server as root inside an unprivileged user namespace. On a real host, commands run as whichever account started fast-agent serve, which in a default Docker container is often root, as the reporter’s own test showed.
Is a Loopback-Only fast-agent Server Safe?
A loopback-only fast-agent server is safer than one on 0.0.0.0, and it is still reachable by every process and user on the same machine. In our lab, it also accepted requests that claimed to come from another website, which is the condition DNS rebinding attacks need.
DNS rebinding is a browser attack in which a malicious site makes its own domain resolve to 127.0.0.1, so scripts on the page can send requests to a local server as if they were same-origin. The MCP transport specification says servers must validate the Origin header on all incoming connections for this reason, should bind only to localhost when running locally, and should authenticate all connections.
We sent an MCP initialize request to each version with Host: attacker.example and Origin: http://attacker.example. All three versions answered HTTP 200. We did not run a full browser rebinding attack, so this is a missing control rather than a demonstrated exploit, but a developer who leaves fast-agent serve --shell running while browsing has no Origin check between a hostile page and that shell.
Why the Fix Took Nearly Five Months to Reach Scanners
The fix reached scanners nearly five months late because the advisory sat at repository level for 107 days before a CVE was published. evalstate published GHSA-9vhv-g5hf-m7m7 on the fast-agent repository on July 22, 2026, NVD published CVE-2026-102610 on November 6, and GitHub added its reviewed copy to the global advisory database on November 9.
This fast-agent vulnerability shows how a quiet fix can outrun its own disclosure. Dependency scanners that rely on NVD, OSV, or the GitHub Advisory Database could not flag fast-agent-mcp 0.7.20 during that gap. Teams that pinned an older release in June or July, for example in a Dockerfile or a uv.lock, would have seen a clean scan until this week. Some coverage published November 10 describes the two remediation steps as proposals; both shipped in 0.7.21 in June.
What fast-agent Users Should Do Now
fast-agent users should upgrade to 0.7.21 or later and then treat any --host 0.0.0.0 deployment as unauthenticated until something in front of it checks credentials. The upgrade fixes the default, and it does not stop an operator, a container template, or a tutorial from passing the wide bind back in.
- Run
pip show fast-agent-mcpor check your lock file, and upgrade anything at 0.7.20 or earlier to the current 0.10.54. - Search start scripts, Dockerfiles, and compose files for
servecombined with--host 0.0.0.0, and remove--shellor-xfrom any served agent that does not need it, or pass--no-shell. - Publish container ports to loopback only, for example
docker run -p 127.0.0.1:8000:8000, when the server must bind 0.0.0.0 inside the container. - Put remote fast-agent servers behind an authenticating reverse proxy or MCP gateway that also rejects unexpected
HostandOriginheaders, or use Hugging Face OAuth on Spaces. - Rotate the model provider API keys and any MCP server credentials configured for an agent that ran a vulnerable version on a reachable port, since the advisory says callers could use them.
Choose the plain upgrade when fast-agent serve runs on a single-user workstation with the default host, because 0.7.21 and later keep the port on loopback. Choose an authenticating proxy or gateway as well when the server runs in a container, on a shared virtual machine, or for other teams, because those setups need --host 0.0.0.0 and fast-agent adds no token check there. Neither step helps if the agent already ran on an exposed port, so review that host first. Agents served over stdio are outside this issue.
Where fast-agent Fits in MCP Server Security
CVE-2026-102610 is one more MCP server that trusted the network by default. MCP servers that wrap an agent with shell access are the highest-impact case, because the tool call is itself the command execution, and authentication defaults decide who can make that call.
Our AgentScope MCP workspace flaw coverage showed another agent framework running arbitrary MCP commands, and the FastMCP security advisories covered the FastMCP library that fast-agent builds on. On the client side, the MCP redirect vulnerability in mcp-go showed credentials leaking the other way, and the MCP Inspector 2.14.0 security fixes covered a local developer tool.
Teams comparing frameworks can see where fast-agent sits in our open source AI agent frameworks guide, and the Skills over MCP feature that shipped in the same 0.7.21 release is covered in our Skills over MCP test. For controls in front of servers like this one, see the MCP gateways roundup, the MCP security tools guide, and the AI agent security tools guide.
fast-agent is not the only MCP server this week where a default did the damage. On November 11, 2026, the MCP project fixed GHSA-6hqx-gqrx-c5r2 in mcp-server-git, where a read-only git_status call ran a program named in the repository’s own Git configuration. Our mcp-server-git vulnerability test checks seven such settings against the fix.
FAQ
Which fast-agent versions are affected by CVE-2026-102610?
fast-agent-mcp 0.7.20 and earlier are affected, according to the GitHub advisory and NVD. Version 0.7.21, released June 19, 2026, is the first patched release, and 0.10.54 is current as of November 11, 2026. Patched versions still run unauthenticated if you start them with --host 0.0.0.0.
Does fast-agent serve support authentication?
fast-agent serve supports authentication only through Hugging Face OAuth. Setting FAST_AGENT_SERVE_OAUTH=huggingface turns on an OAuth provider meant for Hugging Face Spaces, and we found no other built-in token option in 0.7.20, 0.7.21, or 0.10.54. Other deployments need an authenticating reverse proxy or MCP gateway in front of the server.
Is fast-agent safe without the --shell flag?
fast-agent serve without --shell is safer but still open. Without the flag, the advisory says an unauthenticated caller can still use the operator’s model and any MCP servers configured for the agent, which can run up provider bills or reach internal tools. Keep the default loopback host or add authentication even when the shell is off.
Why is CVE-2026-102610 rated only Moderate?
The CVSS 3.1 vector marks high privileges and user interaction as required, which gives 6.4. Those values reflect the preconditions of serve mode plus the shell flag. Armis argues the rating understates the risk because no authentication is needed, and recommends treating exposed servers with --shell as critical.
Does Docker change the risk for fast-agent serve?
Docker usually raises the risk for fast-agent serve. A server inside a container usually has to bind 0.0.0.0 to accept traffic, so the 0.7.21 loopback default does not help there. Publishing the port with docker run -p 127.0.0.1:8000:8000 keeps it on the host’s loopback, and anything wider needs authentication in front.