### Summary A 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. ### Details The `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. The vulnerable code is in `src/capabilities/create-workflow-for-problem-notification.ts`, lines 82-99: ```typescript let notificationWorkflow: WorkflowCreate = { title: `[MCP POC] Notify team ${teamName} on problem of type ${problemType}`, description: `Automatically created workflow to notify team ${teamName} on problems of type ${problemType} - ...`, 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}\" }}`, // <-- channel sits inside {{ }} message: `🚨 Alert for Team ${teamName}\n*Problem Type*: ${problemType}\n` + `*Problem ID*: {{ event()["display_id"] }}\n*Status*: {{ event()["event.status"] }}\n` + `<{{ environment().url }}/ui/apps/.../problem/{{ event()["event.id"] }}|Click here>`, }, active: true, }, }, }; ``` The 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. The 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. The approval prompt at `src/index.ts:1069-1072`: ```typescript const approved = await requestHumanApproval( `Create a workflow for notifying team ${teamName} via ${channel} about ${problemType} problems`, ); ``` Renders `{{ event() }}` literally to the operator with no indication that it will be templated, and does not surface the workflow's visibility. The 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. ### PoC Tested 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: ```json { "teamName": "{{ event() }}", "problemType": "ERROR", "channel": "#mcp-sec-poc", "isPrivate": true } ``` The 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: ``` title: "[MCP POC] Notify team {{ event() }} on problem of type ERROR" message: "🚨 Alert for Team {{ event() }}\n*Problem Type*: ERROR\n*Problem ID*: {{ event()[\"display_id\"] }}\n..." channel: '{{ "#mcp-sec-poc" }}' action: "dynatrace.slack:slack-send-message" ``` The 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: ``` channel: #mcp-sec-poc message: Alert for Team {'display_id': 'P-123', 'event.status': 'OPEN', 'event.id': 'abc-123'} *Problem Type*: ERROR *Problem ID*: P-123 *Status*: OPEN <ht