Dynatrace MCP Server versions before 2.0.0 accepted unauthenticated JSON-RPC tool calls when started with the --http flag, allowing network attackers to read Grail logs, security events, and user sessions or create notebooks under the server’s credentials. The flaw carried a CVSS score of 7.5 and was fixed in version 2.0.0 released on June 16, 2026.
Quick Take
- What: Dynatrace MCP Server in HTTP mode performed no authentication, session validation, or origin checks before dispatching MCP tool calls.
- Who is affected: Operators running versions before 2.0.0 with the
--httpflag, especially those binding to 0.0.0.0 or exposing the server on a network. - Impact: Network attackers could invoke
execute_dqlto read arbitrary Grail data (logs, security events, user sessions) orcreate_dynatrace_notebookto write notebooks to the tenant. - Fixed version: 2.0.0
- What to do: Upgrade to version 2.0.0 or later and set the
MCP_BEARER_TOKENenvironment variable when running in HTTP mode.
In plain English
Dynatrace MCP Server is a tool that lets AI assistants query Dynatrace observability data. When you ran it with the --http flag, it started a web server that accepted commands from anyone on the network without checking a password. An attacker could send a command to read your logs, security events, or user session data, or create notebooks in your Dynatrace account. Version 2.0.0 fixes this by requiring a bearer token and checking the Host header. If you use this tool, upgrade to 2.0.0 and set a strong token in the MCP_BEARER_TOKEN environment variable. If you do not use Dynatrace MCP Server, you can ignore this issue.
What happened
The Dynatrace MCP Server is an open-source Model Context Protocol server that connects AI assistants to Dynatrace observability data. When started with the --http flag, the server created an HTTP endpoint that accepted JSON-RPC tools/call requests without any authentication, session validation, or Host or Origin header checks.
Any network-reachable attacker could send a raw JSON-RPC request to invoke MCP tools directly under the victim server’s Dynatrace credentials. Two high-impact tools were confirmed reachable without authentication:
- execute_dql: Allowed an attacker to run arbitrary DQL queries and read logs, security events, user sessions, and metrics from the Dynatrace Grail data lake.
- create_dynatrace_notebook: Allowed an attacker to create notebooks visible in the victim’s Dynatrace tenant.
The advisory notes that the send_event tool was not exploitable via this vector because it included a requestHumanApproval gate that blocked unauthenticated HTTP callers.
The vulnerability was assigned CVE-2026-123811 and received a CVSS score of 7.5. The advisory was published on June 9, 2026, and the fix was released in version 2.0.0 on June 16, 2026.
What you should do
Upgrade to version 2.0.0 or later:
npx -y @dynatrace-oss/dynatrace-mcp-server@2.0.0When running in HTTP mode, set a strong bearer token:
export MCP_BEARER_TOKEN=$(openssl rand -base64 32)
npx -y @dynatrace-oss/dynatrace-mcp-server@latest --httpConfigure your MCP client to send the token in the Authorization header:
{
"mcpServers": {
"dynatrace-http": {
"url": "http://localhost:3000",
"transport": "http",
"headers": {
"Authorization": "Bearer your-token"
}
}
}
}Version 2.0.0 also changes the default host binding from 0.0.0.0 to 127.0.0.1. If you need to expose the server on all interfaces (for example, in a container), you must now pass --host 0.0.0.0 explicitly.
What it means
This vulnerability demonstrates the risks of exposing MCP servers over HTTP without authentication. The Dynatrace MCP Server was designed primarily for local stdio transport, where the AI assistant and the server run on the same machine. The HTTP mode was added for remote access but initially lacked the authentication and origin checks necessary for network exposure.
The fix introduces three layers of defense:
1. Bearer token authentication: Version 2.0.0 enforces a bearer token check using constant-time comparison to resist timing attacks. If MCP_BEARER_TOKEN is not set, the server prints a warning but still starts (authentication is enforced only when the token is set).
2. Host binding default: The default host binding changed from 0.0.0.0 to 127.0.0.1, preventing accidental exposure on all network interfaces.
3. DNS rebinding protection: The server now restricts accepted Host headers to the configured server address and localhost aliases, blocking cross-origin POST requests from malicious web pages on the same network.
The advisory also includes a proof-of-concept Docker setup and curl command demonstrating unauthenticated tool invocation. Operators who ran the server with --http and --host 0.0.0.0 on a shared network or in a container with exposed ports were at highest risk.
