GHSA-xrmj-5g4g-8987: @dynatrace-oss/dynatrace-mcp-server has a workflow template injection via create_workflow_for_notification

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, {{ ... }} 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: 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 li