A missing approval check in the Dynatrace MCP server lets any caller — an unauthenticated network client over HTTP, or a prompt-injected LLM in stdio mode — create persistent, tenant-visible notebooks containing arbitrary embedded DQL, while every other write-capable tool in the same server (Slack messages, emails, workflows) correctly gates on human approval before acting. The blast radius is real: the package has 2,949 downstream dependents and an OpenSSF Scorecard of just 5.8/10, and the vendor's own end-to-end PoC confirms the bypass works against a live tenant with zero elicitation prompt sent to the operator. There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template, and the CVSS 3.7 (low) reflects that confidentiality and availability aren't touched directly — but the design flaw is a textbook excessive-agency gap, since the notebook's DQL executes under the permissions of whichever tenant user later opens it, crossing identity boundaries inside the tenant. Upgrade to dynatrace-mcp-server >=1.8.7 now (the fix simply adds the missing requestHumanApproval() call); until then, treat any HTTP-exposed deployment of this MCP server without an added authentication layer as high risk and audit the Notebooks app for entries no one approved.
What is the risk?
CVSS 3.1 rates this low (3.7) because it doesn't directly touch confidentiality or availability, but that score understates the architectural risk in agentic deployments: it silently breaks the human-in-the-loop control the rest of the codebase relies on for every other write action. Exploitation is trivial — a single unauthenticated POST, as the PoC shows — but there's no evidence of active exploitation, no CISA KEV entry, no EPSS score, and no public exploit or Nuclei template, so opportunistic mass exploitation is unlikely in the near term. The realistic risk is targeted: orgs running this MCP server in HTTP mode without an additional auth layer, or exposing it to untrusted/ingested content that could carry an indirect prompt injection, are exposed to silent unauthorized document creation and stored cross-user DQL execution.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Jupyter Notebook | npm | < 1.8.7 | 1.8.7 |
Do you use Jupyter Notebook? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade to dynatrace-mcp-server >=1.8.7, which adds the missing
requestHumanApproval()call to this tool. If immediate upgrade isn't possible: don't expose the MCP server's HTTP transport without a separate authentication/authorization layer in front of it; scope the platform token todocument:documents:writerather than the broadallRequiredScopesset the tool currently requests; monitor the Notebooks app / Dynatrace audit log for notebook-creation events not tied to a known, approved workflow; and treat any notebook you didn't knowingly request as suspicious before opening it, since its embedded DQL executes under your own identity.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-pc2w-4mq8-32qw?
A missing approval check in the Dynatrace MCP server lets any caller — an unauthenticated network client over HTTP, or a prompt-injected LLM in stdio mode — create persistent, tenant-visible notebooks containing arbitrary embedded DQL, while every other write-capable tool in the same server (Slack messages, emails, workflows) correctly gates on human approval before acting. The blast radius is real: the package has 2,949 downstream dependents and an OpenSSF Scorecard of just 5.8/10, and the vendor's own end-to-end PoC confirms the bypass works against a live tenant with zero elicitation prompt sent to the operator. There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template, and the CVSS 3.7 (low) reflects that confidentiality and availability aren't touched directly — but the design flaw is a textbook excessive-agency gap, since the notebook's DQL executes under the permissions of whichever tenant user later opens it, crossing identity boundaries inside the tenant. Upgrade to dynatrace-mcp-server >=1.8.7 now (the fix simply adds the missing requestHumanApproval() call); until then, treat any HTTP-exposed deployment of this MCP server without an added authentication layer as high risk and audit the Notebooks app for entries no one approved.
Is GHSA-pc2w-4mq8-32qw actively exploited?
No confirmed active exploitation of GHSA-pc2w-4mq8-32qw has been reported, but organizations should still patch proactively.
How to fix GHSA-pc2w-4mq8-32qw?
Upgrade to dynatrace-mcp-server >=1.8.7, which adds the missing `requestHumanApproval()` call to this tool. If immediate upgrade isn't possible: don't expose the MCP server's HTTP transport without a separate authentication/authorization layer in front of it; scope the platform token to `document:documents:write` rather than the broad `allRequiredScopes` set the tool currently requests; monitor the Notebooks app / Dynatrace audit log for notebook-creation events not tied to a known, approved workflow; and treat any notebook you didn't knowingly request as suspicious before opening it, since its embedded DQL executes under your own identity.
What systems are affected by GHSA-pc2w-4mq8-32qw?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP tool servers.
What is the CVSS score for GHSA-pc2w-4mq8-32qw?
GHSA-pc2w-4mq8-32qw has a CVSS v3.1 base score of 3.7 (LOW).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0051.001 Indirect AML.T0053 AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary A missing human-approval gate on the `create_dynatrace_notebook` tool allows a caller to create persistent tenant-visible documents containing arbitrary content (including embedded DQL that other users execute when opening the notebook) without operator consent. ### Details `dynatrace-mcp-server` registers six write tools: `send_slack_message`, `send_email`, `send_event`, `create_workflow_for_notification`, `make_workflow_public`, and `create_dynatrace_notebook`. Five of these call `requestHumanApproval()` before executing the side-effect, which elicits the operator's explicit consent through the MCP elicitation protocol. The CHANGELOG explicitly states these approval gates were added "to ensure user consent and prevent unintended actions." `create_dynatrace_notebook` does not call `requestHumanApproval()`. The tool was introduced in a separate release from the approval-gate retrofit and was left ungated. As a result, a caller can create persistent, tenant-visible Dynatrace notebooks containing arbitrary content with no operator confirmation. Notebooks can include embedded DQL queries that later execute under the permissions of any tenant user who opens them. The vulnerable code is in `src/index.ts`, lines 1563-1601: ```typescript tool( 'create_dynatrace_notebook', 'Create Dynatrace Notebook', 'Create a new notebook in the Dynatrace platform ...', { name: z.string().describe(/* ... */), description: z.string().optional().describe(/* ... */), content: z.array(z.object({ type: z.enum(['dql', 'markdown']), text: z.string(), })).describe(/* ... */), }, { readOnlyHint: false, }, async ({ name, content, description }) => { const dtClient = await createAuthenticatedHttpClient(allRequiredScopes); const data = await createDynatraceNotebook(dtClient, name, content, description); // No requestHumanApproval() call. // No destructiveHint annotation. // Scopes requested are allRequiredScopes (the broadest possible set) // even though only document:documents:write is needed. return data ? `Document created successfully: ${dtEnvironment}/ui/apps/dynatrace.notebooks/notebook/${data.id}` : 'document creation failed'; }, ); ``` By comparison, every other write tool calls `requestHumanApproval()` as its first action: - `send_email` (line 1274): `const approved = await requestHumanApproval(...);` - `send_slack_message` (line 652): `const approved = await requestHumanApproval(...);` - `send_event` (line 1367): `const approved = await requestHumanApproval(...);` - `create_workflow_for_notification` (line 1069): `const approved = await requestHumanApproval(...);` - `make_workflow_public` (line 1118): `const approved = await requestHumanApproval(...);` ### PoC Tested end-to-end against a real Dynatrace tenant. The MCP server was started in HTTP mode with the operator's Platform Token: ```bash export DT_ENVIRONMENT=https://<tenant>.apps.dynatrace.com export DT_PLATFORM_TOKEN=dt0s16.... npx -y @dynatrace-oss/dynatrace-mcp-server@1.8.5 --http --port 3000 ``` A single unauthenticated POST from a process with no Dynatrace credentials of its own: ```bash curl -sS http://127.0.0.1:3000/ \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "create_dynatrace_notebook", "arguments": { "name": "Unapproved notebook", "description": "Created without operator approval.", "content": [ {"type": "markdown", "text": "# This notebook was created without approval"}, {"type": "dql", "text": "fetch logs | limit 10"} ] } } }' ``` The response: ``` event: message data: {"result":{"content":[{"type":"text","text":"Document created successfully: https://<tenant>.apps.dynatrace.com/ui/apps/dynatrace.notebooks/notebook/<uuid>"}]}, "jsonrpc":"2.0","id":1} ``` The notebook is visible in the operator's Notebooks app within seconds. No elicitation prompt was sent to any operator client. By contrast, the same harness invoking `send_email` or `send_slack_message` returns: ``` "Operation cancelled: Human approval was not granted for sending this email." ``` The gate logic exists and is wired up for all other write tools - it is simply missing on `create_dynatrace_notebook`. ### Impact - A caller (an unauthenticated network attacker over the HTTP transport when authentication is missing, or a prompt-injected LLM in stdio mode) can silently create persistent tenant-visible documents. - The notebook content is attacker-controlled. Embedded DQL queries execute under the permissions of any tenant user who later opens the notebook - a stored-DQL pattern that crosses identity boundaries within the tenant.
Exploitation Scenario
An attacker with network access to an HTTP-mode deployment of the MCP server (or, in stdio mode, an attacker who successfully prompt-injects the LLM the server is wired into) sends a single `tools/call` request for `create_dynatrace_notebook` with attacker-authored markdown and an embedded DQL query. Because this tool never calls `requestHumanApproval()`, the notebook is created and made tenant-visible within seconds, with no elicitation prompt reaching the operator — unlike a call to `send_email` or `send_slack_message`, which would be blocked. A legitimate, higher-privileged tenant user later opens the notebook out of routine curiosity; the embedded DQL executes under their session, letting the attacker read data or trigger actions outside their own original access level, all while looking like a normal, self-created document.
Weaknesses (CWE)
CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N References
- github.com/advisories/GHSA-pc2w-4mq8-32qw
- github.com/dynatrace-oss/dynatrace-mcp/commit/2851d3ce29d834c93b67f0db903c10e0b488e7ac
- github.com/dynatrace-oss/dynatrace-mcp/pull/529
- github.com/dynatrace-oss/dynatrace-mcp/releases/tag/v1.8.7
- github.com/dynatrace-oss/dynatrace-mcp/security/advisories/GHSA-pc2w-4mq8-32qw
Timeline
Related Vulnerabilities
CVE-2026-72811 10.0 SiYuan: SQL injection enables cross-notebook DB access
Same package: notebook CVE-2026-69085 10.0 SiYuan: SQL injection in searchDocs allows DB tampering
Same package: notebook CVE-2026-69084 10.0 SiYuan: SQL injection in search endpoint exposes notebooks
Same package: notebook CVE-2026-69083 10.0 SiYuan: unauthenticated SQLi in full-text search endpoint
Same package: notebook CVE-2026-92938 9.9 Analysis pending
Same package: notebook