Dynatrace-oss Dynatrace-mcp: Template-Injection (CVE-2026-123809)

Zusammenfassung

Eine Vorlageninjektions-Schwachstelle im Tool create_workflow_for_notification ermöglicht es einem Aufrufer, Jinja2-Ausdrücke einzubetten, die von der Dynatrace-Workflow-Motoren zur Laufzeit ausgewertet werden. Dadurch können Ereignisdaten an von Angreifern kontrollierte Ziele abgeleitet werden, indem ein Workflow erstellt wird, der im Mandanten nach dem Ende der MCP-Sitzung bestehen bleibt.

Details

Das Tool create_workflow_for_notification interpoliert drei vom Aufrufer bereitgestellte Parameter (teamName, problemType, channel) direkt in eine Dynatrace-Workflow-Definition. Dynatrace Workflows verwenden Jinja2-Vorlagen: laut offizieller Dokumentation werden Ausdrücke der Form {{ ... }} in den Eingaben von Aktionen zur Laufzeit des Workflows ausgewertet, mit Ausnahme der Aktion Run Javascript, die speziell ausgenommen ist, um Code-Injektion zu vermeiden. Ein Aufrufer kann daher beispielsweise teamName = "{{ event() }}" angeben und den Workflow-Motor auffordern, diesen Ausdruck zur Laufzeit auszuwerten, wodurch das vollständige Ereignisobjekt in die Nachrichtenkörper übertragen wird, die an den Slack-Kanal geliefert werden.

Der verwundbare Code befindet sich in src/capabilities/create-workflow-for-problem-notification.ts, Zeilen 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,
    },
  },
};

Die verwendete Aktion ist dynatrace.slack:slack-send-message, die nicht in der dokumentierten Ausnahmeliste für Jinja-Ausdrücke enthalten ist. Ihre Eingaben werden zur Laufzeit des Workflows ausgewertet.

Das Schema in src/index.ts:1052-1070 registriert teamName, problemType und channel als z.string().optional() ohne Musterüberprüfung. Das Parameter isPrivate hat .default(false), sodass erstellte Workflows für den gesamten Mandanten sichtbar sind, es sei denn, der Aufrufer setzt ihn explizit.

Die Genehmigungsaufforderung in src/index.ts:1069-1072:

const approved = await requestHumanApproval(
  `Create a workflow for notifying team ${teamName} via ${channel} about ${problemType} problems`,
);

Rendert {{ event() }} wörtlich an den Operator ohne Hinweis darauf, dass es vorverarbeitet wird, und zeigt nicht die Sichtbarkeit des Workflows an.

Der Workflow ist persistent: er bleibt im Mandanten bestehen, nachdem die MCP-Sitzung endet, nachdem die MCP-Anmeldeinformationen des Operators widerrufen wurden, und nachdem der MCP-Server deinstalliert wurde. Er wird bei jedem passenden Problem ausgelöst, bis er manuell aus der Workflows-App gelöscht wird. Der channel-Parameter ist besonders gefährlich, weil er in einen bestehenden Ausdruckszusammenhang {{ "..." }} interpoliert wird - schließe die Zeichenkette mit " ab und du kannst beliebige Jinja-Ausdrücke im Ziel selbst ausführen.

PoC

End-to-End getestet gegen einen realen Dynatrace-Mandanten. Der MCP-Server wurde in stdio-Modus mit dem Plattform-Token des Operators ausgeführt. Ein tools/call create_workflow_for_notification wurde gesendet mit:

{
  "teamName":    "{{ event() }}",
  "problemType": "ERROR",
  "channel":     "#mcp-sec-poc",
  "isPrivate":   true
}

Der Operator genehmigte die Aufforderung (die lautete: "Create a workflow for notifying team {{ event() }} via #mcp-sec-poc about ERROR problems"). Der MCP gab eine Workflow-ID zurück. Das Abrufen des gespeicherten Workflow-Körpers über die Dynatrace Automation API (GET /platform/automation/v1/workflows/<id>) zeigte den eingebetteten Ausdruck wortwörtlich:

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"

Der Workflow wurde dann manuell über die Funktion "Workflow ausführen" in der Dynatrace Workflows App ausgelöst, mit einem synthetischen Ereignis-Payload {"display_id":"P-123","event.status":"OPEN","event.id":"abc-123"}. Der Ausführungsprotokoll für die Aufgabe send_notification zeigt, dass der Workflow-Motor die eingebetteten Ausdrücke zur Laufzeit ausgewertet hat. Die Eingabetabelle für die ausgeführte Aktion enthält:

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
         <https://<tenant>.apps.dynatrace.com/ui/apps/.../problem/abc-123|Click here for details>

Der eingebettete Ausdruck {{ event() }} wurde auf das tatsächliche Ereignisobjekt vor dem Aufruf der Slack-Aktion aufgelöst. Die Slack-Aktion schlug nur fehl, weil der Workflow einen harten Platzhalter connectionId: 'slack-connection-id' verwendet, der nicht zu einer realen Verbindung auflöst. Wenn ein echter Slack-Connector konfiguriert worden wäre, hätte die Nachricht mit den serialisierten Ereignisdaten anstelle von {{ event() }} geliefert werden.

Dies ist eine end-to-end Bestätigung der Jinja-Auswertungskette.

Auswirkungen

Ein Workflow, erstellt mit einem bösartigen Vorlagen-Payload, dient als persistenter Abflusskanal:

• Er wird bei jedem passenden Problem unbegrenzt ausgelöst.
• Der eingebettete Vorlagenausdruck wird zur Laufzeit ausgewertet und löst sich in das Ergebnis der Jinja-Funktion auf (event() gibt das vollständige Ereignisobjekt zurück, environment() gibt Mandantenmetadaten zurück, plus andere verfügbare Funktionen laut Dynatrace Workflows Dokumentation).
• Die aufgelöste Ausgabe wird an ein von Angreifern kontrolliertes Ziel geliefert (der Parameter channel ist ebenfalls vorverarbeitet und noch gefährlicher, weil er in einen bestehenden Ausdruckszusammenhang {{ "..." }} interpoliert wird).
• Der Workflow bleibt im Mandanten bestehen, nachdem die MCP-Sitzung, die Anmeldeinformationen des Operators und der MCP-Server entfernt wurden.
• Mit isPrivate=false (Standard) ist der Workflow für alle Mandantenbenutzer sichtbar.

Die Ausnutzung erfordert entweder eine Aufforderungs-Injektion (ein LLM unter Kontrolle des MCP-Servers liest von Angreifern kontrollierte Daten und folgt einer Injektion, die create_workflow_for_notification mit den bösartigen Argumenten aufruft) oder Operator-Unachtsamkeit (die Genehmigungsaufforderung zeigt den wörtlichen Teamnamen an und der Operator klickt auf Approve ohne zu erkennen, dass {{ event() }} ein Vorlagenfragment ist). Beides ist in der Praxis realistisch.