https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 11 Nov 2026 17:34:51 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-123809 <p>Dynatrace MCP Server is an MCP server for Dynatrace Observability. Prior to 2.0.0, the create_workflow_for_notification tool inserts the caller-controlled teamName, problemType, and channel values into a Dynatrace workflow without neutralizing Jinja2 expressions. A caller can place template expressions such as event() in those values, and the workflow engine evaluates them when the persistent workflow runs. When the workflow has a valid Slack connector, the resulting Slack action can disclose event or tenant metadata to an attacker-selected channel; the shipped placeholder connection does not deliver messages by itself. The workflow remains in the tenant after the MCP session and credentials are gone. The isPrivate option defaults to false, making the created workflow tenant-visible unless the caller changes it. Exploitation requires either an MCP prompt-injection path or an operator approving a prompt that displays the template fragment literally. This issue is fixed in version 2.0.0.</p> <p>Dynatrace MCP Server is an MCP server for Dynatrace Observability. Prior to 2.0.0, the create_workflow_for_notification tool inserts the caller-controlled teamName, problemType, and channel values into a Dynatrace workflow without neutralizing Jinja2 expressions. A caller can place template expressions such as event() in those values, and the workflow engine evaluates them when the persistent workflow runs. When the workflow has a valid Slack connector, the resulting Slack action can disclose event or tenant metadata to an attacker-selected channel; the shipped placeholder connection does not deliver messages by itself. The workflow remains in the tenant after the MCP session and credentials are gone. The isPrivate option defaults to false, making the created workflow tenant-visible unless the caller changes it. Exploitation requires either an MCP prompt-injection path or an operator approving a prompt that displays the template fragment literally. This issue is fixed in version 2.0.0.</p> https://db.gcve.eu/vuln/fkie_cve-2026-123809 https://db.gcve.eu/vuln/ghsa-xrmj-5g4g-8987 <p><strong>Affected:</strong> npm: @dynatrace-oss/dynatrace-mcp-server</p> <p>### 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.</p> <p>### 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 = &#34;{{ event() }}&#34;` and have the workflow engine evaluate that expression at runtime, serialising the full event object into the message body delivered to the Slack channel.</p> <p>The vulnerable code is in `src/capabilities/create-workflow-for-problem-notification.ts`, lines 82-99:</p> <p>```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: &#39;SIMPLE&#39;, tasks: { send_noti…</p> <p><strong>Affected:</strong> npm: @dynatrace-oss/dynatrace-mcp-server</p> <p>### 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.</p> <p>### 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 = &#34;{{ event() }}&#34;` and have the workflow engine evaluate that expression at runtime, serialising the full event object into the message body delivered to the Slack channel.</p> <p>The vulnerable code is in `src/capabilities/create-workflow-for-problem-notification.ts`, lines 82-99:</p> <p>```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: &#39;SIMPLE&#39;, tasks: { send_noti…</p> https://db.gcve.eu/vuln/ghsa-xrmj-5g4g-8987