Skip to content
PERMISSION/PROTOCOL
Back to incident tracker

2026-07-22

HighPrimary

Unauthenticated MCP Requests Could Make a fast-agent Model Execute Shell Commands

A primary advisory demonstrates a real model executing shell commands for an unauthenticated MCP caller in fast-agent 0.7.20. Controlled-test limits explained.

fast-agent-mcp 0.7.20Tool execution / MCPControlled demonstration of unauthenticated agent-driven shell executionfast-agent-mcp 0.7.20 in Docker with HTTP serve and --shell enabled

What happened

The real model selected and invoked the execute tool in response to an unauthenticated caller's message, and command output was returned to that caller.

Why it matters

Demonstrated command execution as root within the test container and disclosure of process identity, hostname and /etc/passwd lines. No production breach, host compromise or credential theft is verified.

Missing authorization check

Authenticated caller authority bound to the exact shell operation, independently enforced before execution even without an interactive approval UI.

Would PP block it?

A gate must mediate the actual shell sink and fail closed when no approver is present. It could bind the caller, exact command and execution environment; it does not authenticate the exposed MCP transport by itself.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-07-22

    Vendor-hosted advisory published the controlled reproduction for fast-agent-mcp 0.7.20 and lists 0.7.21 as patched.

Technical breakdown

  • Default serve configuration exposed HTTP on all interfaces without authentication unless configured otherwise.
  • The Docker test enabled --shell and used gpt-4o-mini; a plain-language remote request resulted in an autonomous execute call.
  • The response included the container process identity, hostname and /etc/passwd lines; the non-interactive permission prompt did not stop execution.
  • The passthrough-model test was deterministic and is distinct from the real-model demonstration.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
The server-side execute shell sink before creating a process, conditional on independent integration
Still needs
PP does not supply network authentication, correct bind defaults or container isolation. A tool path bypassing the gate remains unprotected; root in this container is not evidence of a host escape.
Receipt required for
The exact shell command, authenticated requester and authorized execution environment

An independently integrated execution gate could reject a shell action lacking caller-bound authority, but no PP integration was evaluated in the reproduction.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop