dynatrace-mcp-server Unauthenticated HTTP MCP Tool Invocation
Any attacker who can reach the server's HTTP port can invoke powerful Dynatrace tools, including arbitrary log queries, without supplying any credentials, because the HTTP transport mode performs no…

The problem
Versions up to and including 1.8.7 of @dynatrace-oss/dynatrace-mcp-server expose an HTTP transport mode via the --http flag. When started in this mode, the server creates a StreamableHTTPServerTransport with sessionIdGenerator: undefined and zero authentication checks on every inbound request.
Any network-reachable caller can send a raw JSON-RPC tools/call request with no Authorization header and have it executed using the victim server's configured Dynatrace credentials. The two highest-impact tools reachable this way are execute_dql (reads logs, security events, user sessions, and metrics from Grail) and create_dynatrace_notebook (writes documents to the tenant).
Deployments using --host 0.0.0.0 require no user interaction, raising the effective CVSS to 9.3.
Proof of concept
A working proof-of-concept for this issue in @dynatrace-oss/dynatrace-mcp-server, with the exact payload below.
curl -sS -N -X POST http://<server>:3000/ \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'Mcp-Protocol-Version: 2025-03-26' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "execute_dql",
"arguments": {
"query": "fetch logs | limit 10"
}
}
}'The root cause (CWE-306) is straightforward: the HTTP request handler in src/index.ts calls httpTransport.handleRequest(req, res, body) after doing nothing but JSON-parsing the body. No bearer-token check, no session validation, no Host or Origin allowlist is applied.
The patch (PR #536, commit 8f12972) adds three layers. First, HTTP mode now requires a token via --http-auth-token or the DT_MCP_HTTP_AUTH_TOKEN env var, and the process exits at startup if neither is set. Second, every request is checked with a timing-safe comparison against that token; missing or wrong tokens receive an immediate HTTP 401 with a WWW-Authenticate: Bearer header.
Third, the transport is hardened with enableDnsRebindingProtection: true and an explicit allowedHosts list, closing the DNS rebinding vector that put localhost-only deployments at reduced but non-zero risk.
The fix
Upgrade to @dynatrace-oss/dynatrace-mcp-server 2.0.0. After upgrading, HTTP mode requires a bearer token: set --http-auth-token <token> at startup or export DT_MCP_HTTP_AUTH_TOKEN=<token>. The server will refuse to start in HTTP mode without one. Also review your deployment's --host binding; the new default is 127.0.0.1 rather than 0.0.0.0.
Related research
- high · 8.8CVE-2026-54504CVE-2026-54504: @andrea9293/mcp-documentation-server Unauthenticated Network API Exposure
- critical · 109router: Unauthenticated CRUD on Provider API and Full API Key Leak
- highCVE-2026-49357CVE-2026-49357: line-desktop-mcp Unauthenticated MCP Tool Access via Streamable HTTP
- highCVE-2026-54729CVE-2026-54729: dssrf SSRF Bypass via DNS NXDOMAIN on 1.1.1.1