GHSA-xrmj-5g4g-8987

### 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` +