Quick Take
- What: CVE-2026-123809 is a Jinja2 template injection vulnerability in the Dynatrace MCP Server’s create_workflow_for_notification tool that allows attackers to embed expressions evaluated at workflow runtime.
- Who is affected: Users of Dynatrace MCP Server versions up to and including 1.8.5 who use the create_workflow_for_notification tool.
- Severity: Medium (CVSS 4.2).
- Fixed in: Version 2.0.0, which removes the vulnerable create_workflow_for_notification and make_workflow_public tools entirely.
- What to do: Upgrade to version 2.0.0 or later, and manually delete any workflows created by the vulnerable tool from your Dynatrace tenant.
In plain English
The Dynatrace MCP Server is a tool that connects AI assistants to Dynatrace monitoring systems. A security flaw in one of its features allowed attackers to sneak malicious code into automated workflows. When these workflows ran, they could send sensitive monitoring data to channels controlled by the attacker. The dangerous part is that these workflows stayed active in the system even after the original session ended, continuing to leak data until someone manually deleted them. The company fixed this by removing the vulnerable feature entirely in version 2.0.0.
What you should do: If you use this tool, you should upgrade and check your Dynatrace account for any suspicious workflows that might still be running.
What happened
The create_workflow_for_notification tool in Dynatrace MCP Server inserted caller-controlled values for teamName, problemType, and channel directly into Dynatrace workflow definitions without sanitizing Jinja2 template expressions. According to the GitHub security advisory, a caller could place template expressions such as {{ event() }} in those values, and the Dynatrace workflow engine would evaluate them at runtime.
The vulnerable code was located in src/capabilities/create-workflow-for-problem-notification.ts, lines 82–99, where the tool interpolated three caller-supplied parameters directly into a WorkflowCreate object. The action used was dynatrace.slack:slack-send-message, which evaluates Jinja2 expressions in its inputs at workflow runtime.
The advisory includes a proof-of-concept demonstration against a real Dynatrace tenant. When a workflow was created with teamName: "{{ event() }}", the workflow engine evaluated the injected expression at runtime. The execution log showed the Input tab contained the actual event object in place of the template expression. The Slack action failed only because the workflow used a hardcoded placeholder connectionId that did not resolve to any real connection. With a valid Slack connector, the message would have been delivered with serialized event data.
The workflows created by this tool were persistent, remaining in the tenant after the MCP session ended, after the operator’s credentials were revoked, and after the MCP server was uninstalled. They fired on every matching problem until manually deleted from the Workflows app. The isPrivate parameter defaulted to false, making created workflows visible tenant-wide unless explicitly set otherwise.
The approval prompt rendered template expressions literally to the operator with no indication they would be evaluated, and did not surface the workflow’s visibility setting.
What you should do
Upgrade to Dynatrace MCP Server version 2.0.0 or later. The fix removes the create_workflow_for_notification and make_workflow_public tools entirely.
Manually review and delete any workflows in your Dynatrace tenant that were created by the vulnerable tool. These workflows persist after upgrade and will continue to fire on matching problems until manually removed. The advisory states that workflows remain active after the MCP session ends, after credentials are revoked, and after the MCP server is uninstalled.
If you relied on the removed tool, the changelog recommends creating Dynatrace workflows manually via the Dynatrace UI, dtctl, or the Automations API.
What it means
This vulnerability demonstrates the risks of template injection in AI agent tooling. The Dynatrace MCP Server is an MCP (Model Context Protocol) server that provides AI assistants with tools to interact with Dynatrace observability data. The create_workflow_for_notification tool was designed to automate the creation of notification workflows, but its lack of input sanitization allowed attackers to inject code that would execute in a different security context.
The persistence of the malicious workflows is particularly concerning. Unlike typical injection attacks that end when a session closes, these workflows remained active indefinitely, creating a long-lived exfiltration channel. The default visibility setting (tenant-wide) amplified the impact.
The CVSS score of 4.2 reflects the fact that exploitation requires the attacker to have MCP access and the operator to approve the workflow creation, but the potential for data exfiltration and the persistence of the attack vector make this a significant security issue for affected deployments.
Dynatrace’s response was to remove the vulnerable functionality entirely rather than attempt to sanitize inputs, which is a conservative approach that eliminates the attack surface. Users who need similar functionality are directed to more robust alternatives like dtctl or the Automations API.
