GHSA-PC2W-4MQ8-32QW: Missing Human-Approval Gate in create_dynatrace_notebook
Vulnerability ID: GHSA-PC2W-4MQ8-32QW
CVSS Score: 6.5
Published: 2026-07-29
A logic vulnerability exists in @dynatrace-oss/dynatrace-mcp-server prior to version 1.8.7. The create_dynatrace_notebook tool lacks a human-approval gate, allowing an attacker to exploit indirect prompt injection to force the underlying LLM client to create persistent Dynatrace notebooks without the operator's consent.
TL;DR
@dynatrace-oss/dynatrace-mcp-server prior to 1.8.7 lacks a human-approval gate for create_dynatrace_notebook, enabling silent notebook creation via prompt injection.
⚠️ Exploit Status: POC
Technical Details
- CWE ID: CWE-862
- Attack Vector: Network (Indirect Prompt Injection)
- CVSS Score: 6.5 (Qualitative Medium-to-High)
- Impact: Unauthorized Creation of Dynatrace Notebooks
- Exploit Status: Proof-of-Concept / Analytical
- KEV Status: Not Listed
Affected Systems
- @dynatrace-oss/dynatrace-mcp-server
-
@dynatrace-oss/dynatrace-mcp-server: < 1.8.7 (Fixed in:
1.8.7)
Code Analysis
Commit: 2851d3c
feat: add human approval gate to create_dynatrace_notebook tool
Mitigation Strategies
- Upgrade the @dynatrace-oss/dynatrace-mcp-server package to version 1.8.7 or later.
- Strip notebooks.write permissions from the API tokens used by the MCP server as a temporary workaround.
- Configure client-side orchestrators to block or filter the create_dynatrace_notebook tool until patched.
Remediation Steps:
- Run 'npm install @dynatrace-oss/dynatrace-mcp-server@latest' to update the package.
- Verify that the installed version in package.json is 1.8.7 or higher.
- Restart the MCP server and host orchestrator clients to apply the new tool configuration.
- Test execution to verify that a manual confirmation prompt is triggered before notebook creation.
References
Read the full report for GHSA-PC2W-4MQ8-32QW on our website for more details including interactive diagrams and full exploit analysis.
Top comments (1)
The missing human-approval gate in
create_dynatrace_notebookprior to version 1.8.7 is a significant vulnerability, as it allows for indirect prompt injection to create persistent Dynatrace notebooks without operator consent. I've worked with similar large language models (LLMs) and can appreciate the importance of implementing robust validation and approval mechanisms to prevent such exploits. The proposed mitigation strategies, such as upgrading to version 1.8.7 or later and stripping notebooks.write permissions from API tokens, seem effective in addressing this vulnerability. Have you considered implementing additional safeguards, like monitoring notebook creation activity or integrating with existing security information and event management (SIEM) systems to detect potential exploits?