GHSA-xrmj-5g4g-8987: @dynatrace oss/dynatrace mcp server @dynatrace-oss/dynatrace-mcp-server Has A Workflow Template Vulnerability
MODERATEGHSA-xrmj-5g4g-8987 is a MODERATE (CVSS 4.2) @dynatrace-oss/dynatrace-mcp-server has a workflow template vulnerability (CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine) affecting @dynatrace oss/dynatrace mcp server libraries in the npm ecosystem. The issue involves @dynatrace-oss/dynatrace-mcp-server has a workflow template injection via create_workflow_for_notification. Remediation is available by upgrading affected packages to version 2.0.0.
GHSA-xrmj-5g4g-8987 at a Glance
Security Impact
CVSS: 4.2
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N).
How to Fix GHSA-xrmj-5g4g-8987
To remediate this vulnerability, upgrade all affected @dynatrace oss/dynatrace mcp server dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
npm install @dynatrace-oss/dynatrace-mcp-server@2.0.0
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
npm ls @dynatrace-oss/dynatrace-mcp-server
How to Check if You Are Affected
To determine whether your Node.js application is affected by GHSA-xrmj-5g4g-8987, inspect your project dependencies using npm:
npm ls @dynatrace-oss/dynatrace-mcp-server
Analyze the terminal output to locate any version of @dynatrace oss/dynatrace mcp server in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.0.0), your application is affected.
Note: The npm ls @dynatrace-oss/dynatrace-mcp-server command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine, where the product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine. In @dynatrace oss/dynatrace mcp server, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
GHSA-xrmj-5g4g-8987 Affected @dynatrace oss/dynatrace mcp server Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
@dynatrace-oss/dynatrace-mcp-server
|
npm |
< 2.0.0
|
2.0.0
|
References
Frequently Asked Questions
What is GHSA-xrmj-5g4g-8987?
Which @dynatrace oss/dynatrace mcp server versions are affected?
What version fixes GHSA-xrmj-5g4g-8987?
Is @dynatrace-oss/dynatrace-mcp-server affected?
What is the CVSS score of GHSA-xrmj-5g4g-8987?
What CWE is associated with GHSA-xrmj-5g4g-8987?
How can I check npm dependencies for GHSA-xrmj-5g4g-8987?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-xrmj-5g4g-8987",
"modified" : "2026-07-31T16:01:07Z",
"published" : "2026-07-31T16:01:07Z",
"aliases" : [ ],
"summary" : "@dynatrace-oss/dynatrace-mcp-server has a workflow template injection via create_workflow_for_notification",
"details" : "### Summary\nA template injection vulnerability in the `create_workflow_for_notification` tool lets a caller embed Jinja2 expressions that the Dynatrace workflow engine evaluates at runtime, exfiltrating event data to attacker-controlled destinations through a workflow that persists in the tenant after the MCP session ends.\n\n### Details\nThe `create_workflow_for_notification` tool interpolates three caller-supplied parameters (`teamName`, `problemType`, `channel`) directly into a Dynatrace Workflow definition. Dynatrace Workflows use Jinja2 templating: per the [official documentation](https://docs.dynatrace.com/docs/analyze-explore-automate/workflows/reference), `{{ ... }}` expressions in action inputs are evaluated at workflow runtime for every action except `Run Javascript` (which is carved out specifically to avoid code injection). A caller can therefore supply, for example, `teamName = \"{{ event() }}\"` and have the workflow engine evaluate that expression at runtime, serialising the full event object into the message body delivered to the Slack channel.\n\nThe vulnerable code is in `src/capabilities/create-workflow-for-problem-notification.ts`, lines 82-99:\n\n```typescript\nlet notificationWorkflow: WorkflowCreate = {\n title: `[MCP POC] Notify team ${teamName} on problem of type ${problemType}`,\n description: `Automatically created workflow to notify team ${teamName} on problems of type ${problemType} - ...`,\n isPrivate: isPrivate,\n type: 'SIMPLE',\n tasks: {\n send_notification: {\n name: 'Send notification',\n action: 'dynatrace.slack:slack-send-message',\n description: 'Sends a notification to a Slack channel',\n input: {\n connectionId: 'slack-connection-id',\n channel: `{{ \\\"${channel}\\\" }}`, // <-- channel sits inside {{ }}\n message: `🚨 Alert for Team ${teamName}\\n*Problem Type*: ${problemType}\\n` +\n `*Problem ID*: {{ event()[\"display_id\"] }}\\n*Status*: {{ event()[\"event.status\"] }}\\n` +\n `<{{ environment().url }}/ui/apps/.../problem/{{ event()[\"event.id\"] }}|Click here>`,\n },\n active: true,\n },\n },\n};\n```\n\nThe action used is `dynatrace.slack:slack-send-message`, which is not in the documented Jinja-expression exception list. Its inputs are evaluated at workflow runtime.\n\nThe schema in `src/index.ts:1052-1070` registers `teamName`, `problemType`, and `channel` as `z.string().optional()` with no pattern validation. The `isPrivate` parameter has `.default(false)`, so created workflows are visible tenant-wide unless the caller explicitly sets it.\n\nThe approval prompt at `src/index.ts:1069-1072`:\n\n```typescript\nconst approved = await requestHumanApproval(\n `Create a workflow for notifying team ${teamName} via ${channel} about ${problemType} problems`,\n);\n```\n\nRenders `{{ event() }}` literally to the operator with no indication that it will be templated, and does not surface the workflow's visibility.\n\nThe workflow is persistent: it remains in the tenant after the MCP session ends, after the operator's MCP credentials are revoked, and after the MCP server is uninstalled. It fires on every matching problem until manually deleted from the Workflows app. The `channel` parameter is uniquely dangerous because it is interpolated inside an existing `{{ \"...\" }}` expression context - close the string with `\"` and you can run arbitrary Jinja expressions in the destination field itself.\n\n\n### PoC\n\nTested end-to-end against a real Dynatrace tenant. The MCP server was run in stdio mode with the operator's Platform Token. A `tools/call create_workflow_for_notification` was sent with:\n\n```json\n{\n \"teamName\": \"{{ event() }}\",\n \"problemType\": \"ERROR\",\n \"channel\": \"#mcp-sec-poc\",\n \"isPrivate\": true\n}\n```\n\nThe operator approved the prompt (which read: `\"Create a workflow for notifying team {{ event() }} via #mcp-sec-poc about ERROR problems\"`). The MCP returned a workflow ID. Fetching the stored workflow body via the Dynatrace Automation API (`GET /platform/automation/v1/workflows/<id>`) showed the injected expression stored verbatim:\n\n```\ntitle: \"[MCP POC] Notify team {{ event() }} on problem of type ERROR\"\nmessage: \"🚨 Alert for Team {{ event() }}\\n*Problem Type*: ERROR\\n*Problem ID*: {{ event()[\\\"display_id\\\"] }}\\n...\"\nchannel: '{{ \"#mcp-sec-poc\" }}'\naction: \"dynatrace.slack:slack-send-message\"\n```\n\nThe workflow was then triggered manually via the \"Run workflow\" feature in the Dynatrace Workflows app, with a synthetic event payload `{\"display_id\":\"P-123\",\"event.status\":\"OPEN\",\"event.id\":\"abc-123\"}`. The execution log for the `send_notification` task shows the workflow engine evaluated the injected expressions at runtime. The \"Input\" tab for the executed action contains:\n\n```\nchannel: #mcp-sec-poc\nmessage: Alert for Team\n {'display_id': 'P-123',\n 'event.status': 'OPEN',\n 'event.id': 'abc-123'}\n *Problem Type*: ERROR\n *Problem ID*: P-123\n *Status*: OPEN\n <https://<tenant>.apps.dynatrace.com/ui/apps/.../problem/abc-123|Click here for details>\n```\n\nThe injected `{{ event() }}` resolved to the actual event object before the Slack action was called. The Slack action then failed only because the workflow uses a hardcoded placeholder `connectionId: 'slack-connection-id'` that does not resolve to any real connection. If a real Slack connector had been configured, the message would have been delivered with the serialized event data in place of `{{ event() }}`.\n\nThis is end-to-end confirmation of the Jinja-evaluation chain.\n\n### Impact\nA workflow created with a malicious template payload acts as a persistent exfiltration channel:\n\n- It fires on every matching problem indefinitely.\n- The injected template is evaluated at runtime and resolves to whatever the Jinja function returns (`event()` gives the full event object, `environment()` gives tenant metadata, plus other available functions per the Dynatrace Workflows documentation).\n- The resolved output is delivered to a destination the attacker controls (the `channel` parameter is also templated, and is even more dangerous because it is interpolated inside an existing `{{ \"...\" }}` expression context).\n- The workflow persists in the tenant after the MCP session, operator credentials, and MCP server are gone.\n- With `isPrivate=false` (the default), the workflow is visible to all tenant users.\n\nExploitation requires either prompt injection (an LLM under the MCP server's control is reading attacker-controlled data and follows an injection that calls `create_workflow_for_notification` with the malicious arguments) or operator carelessness (the approval prompt shows the raw team name literal and the operator clicks Approve without recognising `{{ event() }}` as a template fragment). Both are realistic in practice.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "npm",
"name" : "@dynatrace-oss/dynatrace-mcp-server"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "2.0.0"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/dynatrace-oss/dynatrace-mcp/security/advisories/GHSA-xrmj-5g4g-8987"
}, {
"type" : "WEB",
"url" : "https://github.com/dynatrace-oss/dynatrace-mcp/pull/547"
}, {
"type" : "WEB",
"url" : "https://github.com/dynatrace-oss/dynatrace-mcp/commit/64dfcb1095823d0fb43013635446288a6ff60e29"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/dynatrace-oss/dynatrace-mcp"
}, {
"type" : "WEB",
"url" : "https://github.com/dynatrace-oss/dynatrace-mcp/releases/tag/v2.0.0"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-1336" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-07-31T16:01:07Z",
"nvd_published_at" : null
}
}