Answer in brief
CVE-2026-123809 records a Medium severity (CVSS 4.2) vulnerability in Dynatrace MCP Server: Workflow template injection via create_workflow_for_notification. The current sources do not mark it as known exploited. The current feed maps dynatrace-oss/dynatrace-mcp (generic), @dynatrace-oss/dynatrace-mcp-server (npm), @dynatrace-oss/dynatrace-mcp-server (npm). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 4.2. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps dynatrace-oss/dynatrace-mcp (generic), @dynatrace-oss/dynatrace-mcp-server (npm), @dynatrace-oss/dynatrace-mcp-server (npm). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| dynatrace-oss/dynatrace-mcpgeneric | <2.0.0 | 2.0.0 |
| @dynatrace-oss/dynatrace-mcp-servernpm | <2.0.0 | 2.0.0 |
| @dynatrace-oss/dynatrace-mcp-servernpm | <2.0.0 | 2.0.0 |
Published upstream
Nov 9, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 9, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 2, 2026
Dynatrace MCP Server is an MCP server for Dynatrace Observability. Prior to 2.0.0, the create_workflow_for_notification tool inserts the caller-controlled teamName, problemType, and channel values into a Dynatrace workflow without neutralizing Jinja2 expressions. A caller can place template expressions such as event() in those values, and the workflow engine evaluates them when the persistent workflow runs. When the workflow has a valid Slack connector, the resulting Slack action can disclose event or tenant metadata to an attacker-selected channel; the shipped placeholder connection does not deliver messages by itself. The workflow remains in the tenant after the MCP session and credentials are gone. The isPrivate option defaults to false, making the created workflow tenant-visible unless the caller changes it. Exploitation requires either an MCP prompt-injection path or an operator approving a prompt that displays the template fragment literally. This issue is fixed in version 2.0.0.
Quoted source text, attributed separately from HOL analysis.