GHSA-xrmj-5g4g-8987: Workflow Template Injection in @dynatrace-oss/dynatrace-mcp-server

The Model Context Protocol (MCP) server for Dynatrace, distributed via the npm registry as @dynatrace-oss/dynatrace-mcp-server, acts as a bridge enabling Large Language Models (LLMs) to interact with Dynatrace APIs and perform automated operations.

One of the capabilities exposed by this MCP server is the create_workflow_for_notification tool. This tool allows users or automated agents to generate alert routing workflows inside a Dynatrace tenant, specifying details such as the target team, the class of problem, and the communication channel.

In versions of the server prior to 2.0.0, the tool accepts parameter inputs without proper validation or escaping, and interpolates them directly into a Dynatrace Workflow definition template. This workflow template utilizes the Jinja2 rendering engine at runtime, introducing a template injection surface (CWE-1336) that exposes the underlying Dynatrace tenant data to exfiltration.

The fundamental flaw resides within the handler implementation found at src/capabilities/create-workflow-for-problem-notification.ts. The handler accepts user-controlled properties, including teamName, problemType, and channel, via an incoming MCP JSON-RPC call.

These variables are processed as raw string variables and concatenated directly into the properties of a WorkflowCreate structure. Specifically, the channel parameter is wrapped in a Jinja2 execution syntax block: {{ "${channel}" }}. Because the implementation relies on simple ES6 template literals rather than structured, parameter-aware builders, characters like quotes and brackets remain intact.

Furthermore, the validation schema declared in src/index.ts relies on basic Zod string constraints (z.string().optional()) that enforce zero pattern verification or character blocklists. Consequently, any string containing template tags ({{ and }}) is parsed without validation, allowing the injection payload to reach the platform configuration unchanged.

An inspection of the vulnerable source code highlights how the payloads were constructed:

// Vulnerable: src/capabilities/create-workflow-for-problem-notification.ts
let notificationWorkflow: WorkflowCreate = {
  title: `[MCP POC] Notify team ${teamName} on problem of type ${problemType}`,
  description: `Automatically created workflow to notify team ${teamName}...`,
  isPrivate: isPrivate,
  type: 'SIMPLE',
  tasks: {
    send_notification: {
      name: 'Send notification',
      action: 'dynatrace.slack:slack-send-message',
      description: 'Sends a notification to a Slack channel',
      input: {
        connectionId: 'slack-connection-id',
        channel: `{{ "${channel}" }}`,
        message: `🚨 Alert for Team ${teamName}\n*Problem Type*: ${problemType}\n` +
                 `*Problem ID*: {{ event()["display_id"] }}\n` +
                 `*Status*: {{ event()["event.status"] }}\n`
      },
      active: true,
    },
  },
};

The logical execution flow of this exploit moves from the user/agent interface to the internal templating engine as shown below:

The channel context is particularly vulnerable. By injecting #channel" }} into the parameter, an attacker breaks out of the string boundary defined in the generated template structure, giving them direct access to the outer Jinja2 processing context.

To execute this attack, a malicious actor must trigger the create_workflow_for_notification tool. This can occur either through direct administrative access to the MCP client interface or via an indirect prompt injection attack, where an LLM is manipulated into executing the tool on behalf of an operator.

A verified proof-of-concept payload submits the following arguments during the tool execution request:

{
  "teamName": "{{ event() }}",
  "problemType": "ERROR",
  "channel": "#mcp-sec-poc",
  "isPrivate": true
}

When this workflow is saved to the Dynatrace platform and subsequently triggered by an incident event, the underlying Jinja2 execution layer evaluates the payload. Instead of outputting the literal string {{ event() }}, the execution layer interprets the function call, which dumps the entire current event dictionary—including active operational data, status markers, and system metadata—into the outgoing communication block.

The core risk of this vulnerability is the persistent execution state of Dynatrace workflows. Unlike typical web-application vulnerabilities where the exploitation lifecycle is ephemeral, a workflow template injection creates a long-lived configuration object within the tenant.

Once the workflow is saved, it continues to run within the Dynatrace platform infrastructure. It remains active even if the operator closes their session, has their personal access credentials revoked, or completely uninstalls the MCP server. This establishes a highly reliable and silent persistence channel.

Furthermore, because the templates run within the security context of the Dynatrace automation execution environment, they can access platform utility functions like environment(). An attacker can use this access to map out internal tenant URLs, architecture settings, and directory metadata, then exfiltrate this information through configured notification actions.

Rather than attempting to build sanitization routines to sanitize complex nested Jinja2 brackets, the development team decided to completely remove the vulnerable code path to eliminate the attack surface.

In version 2.0.0, both the create_workflow_for_notification and make_workflow_public tools were removed. Users needing workflow creation capabilities are instructed to use official channels, such as the dtctl command-line utility, the native Dynatrace User Interface, or the raw Dynatrace Automation API directly.

To remediate this vulnerability, operators must upgrade @dynatrace-oss/dynatrace-mcp-server to version 2.0.0 or higher. Note that upgrading the server does not purge previously generated workflows; an incident response audit must be executed inside the Dynatrace console to discover and manually delete any workflows created under the prefix [MCP POC].