CVE-2025-68613: Authenticated Expression-Injection RCE in n8n (CWE-913) - Was ist betroffen, was muss gepatcht werden, und wie kann man es eindämmen

Was CVE-2025-68613 tatsächlich ist

CVE-2025-68613 betrifft n8neine Open-Source-Plattform zur Automatisierung von Arbeitsabläufen. Die Schwachstelle ist eine Remote-Code-Ausführung (RCE) Ausgabe in n8n's Workflow-Auswertungssystem: unter bestimmten Bedingungen, Ausdrücke, die von authentifizierte Benutzer während der Workflow-Konfiguration in einem Ausführungskontext ausgewertet werden können, der nicht ausreichend isoliert von der zugrunde liegenden Laufzeit. Ein Angreifer kann dieses Verhalten missbrauchen, um beliebigen Code mit den Rechten des n8n-Prozesses auszuführen, was zu einer vollständigen Kompromittierung der Instanz führen kann (Datenzugriff, Änderung von Arbeitsabläufen, Operationen auf Systemebene). (NVD)

Der Eintrag in der National Vulnerability Database (NVD) zeigt derzeit, dass die NVD noch keine eigene Scoring-Anreicherung anbietet, aber sie zeigt die CNA-Bewertung von GitHub, Inc. an.: CVSS v3.1 Basiswert 9.9 (KRITISCH) mit Vektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. (NVD)

Dieser Vektor ist aus betrieblicher Sicht von Bedeutung: Das Problem ist über das Netzwerk erreichbar, wenig komplex, erfordert nur geringe Berechtigungen, keine Benutzerinteraktion und hat den Umfang geändert - genau das Muster, das dazu führt, dass aus einem "Anwendungsfehler" eine "Kompromittierung der Umgebung" wird, wenn der Dienst mit internen Systemen verbunden ist.

Die Schwachstellenabbildung lautet CWE-913. MITRE definiert CWE-913 als unsachgemäße Kontrolle über dynamisch verwaltete Code-Ressourcen (Variablen, Objekte, Klassen, Attribute, Funktionen, ausführbare Anweisungen/Statements), was mit der "Ausdrucksauswertung, die der beabsichtigten Isolierung entgeht" dieses Problems übereinstimmt. (cwe.mitre.org)

Eine Tabelle, die Sie in eine Sicherheitsempfehlung einfügen können

Warum "erfordert Authentifizierung" immer noch eine Notfallbehandlung verdient

Dies als "weniger dringend, weil authentifiziert" zu behandeln, ist eine häufige Fehlerart. In n8n sind authentifizierte Benutzer oft nicht nur Administratoren, sondern können auch Automatisierungsersteller, Integrationsoperatoren oder Dienstkonten sein. Sobald die Grenze der Ausdrucksauswertung durchbrochen ist, ist der Angreifer nicht auf Anwendungsaktionen beschränkt - NVD weist ausdrücklich auf die Ausführung von beliebigem Code mit den Rechten des n8n-Prozesses und die Möglichkeit der vollständigen Kompromittierung der Instanz hin. (NVD)

In der Praxis konzentrieren sich Workflow-Plattformen auf drei Dinge, die Angreifer lieben: breite Konnektivität, Geheimnisse und Logikausführung. Aus diesem Grund sollten Sie Ihren Reaktionsplan am CVSS-Vektor (PR:L + S:C + C/I/A:H) ausrichten und nicht an Ihrer Intuition bezüglich "Anmeldung erforderlich". (NVD)

Patch-Strategie, die nicht im Chaos versinkt

Ihr "richtiger" Endzustand ist einfach: Führen Sie eine korrigierte Version aus. NVD listet das Problem als behoben in 1.120.4, 1.121.1 und 1.122.0. (NVD)

Der n8n/GitHub-Hinweistext hebt hervor, dass das Problem in folgenden Punkten behoben wurde v1.122.0 und empfiehlt ein Upgrade auf 1.122.0 oder höher weil sie "zusätzliche Sicherheitsvorkehrungen zur Einschränkung der Bewertung von Ausdrücken" vorsieht. (GitHub)

In der Praxis bedeutet dies eine einfache Regel:

Wenn Sie sicher vorankommen können, nähern Sie sich 1.122.0+Wenn Sie auf einen bestimmten Zug festgelegt sind, landen Sie auf den vom NVD angegebenen Mindestversionen, während Sie so schnell wie möglich einen weiteren Zug planen. (NVD)

Hier ist ein Nur für Audits Versionsüberprüfung, die Sie in CI, auf Hosts oder in einem Flottenauftrag ausführen können (keine Exploit-Logik, nur Versions-/Risikomarkierung):

#!/usr/bin/env bash
# CVE-2025-68613 n8n-Versionsprüfung (keine Ausnutzung)

set -euo pipefail

if befehl -v n8n >/dev/null 2>&1; dann
  VER="$(n8n --version | tr -d 'v' | head -n1)"
sonst
  VER="${N8N_VERSION:-unknown}"
fi

echo "n8n-Version erkannt: $VER"

# Betroffener Bereich laut GitHub-Beratung: >=0.211.0 <1.120.4
# Behobene Versionen laut NVD: 1.120.4, 1.121.1, 1.122.0
if [[ "$VER" != "unknown" ]] && \\
   [[ "$(printf '%s\\n' "0.211.0" "$VER" | sort -V | head -n1)" == "0.211.0" ]] && \\
   [[ "$(printf '%s\\n' "$VER" "1.120.4" | sort -V | head -n1)" == "$VER" ]] && \\
   [[ "$VER" != "1.120.4" ]]; then
  echo "FLAG: Möglicherweise betroffen von CVE-2025-68613. Aktualisieren Sie gemäß NVD/GitHub-Anleitung."
  exit 2
fi

echo "Diese Schnellüberprüfung ergab kein Flag. Überprüfen Sie anhand der offiziellen Empfehlung und Ihrer genauen Einsatzdetails."

Kurzfristige Abhilfemaßnahmen

Sowohl NVD als auch der GitHub-Hinweis bieten dieselben kurzfristigen Abhilfemaßnahmen: Beschränkung der Rechte zur Erstellung/Bearbeitung von Workflows auf voll vertrauenswürdige Benutzerund setzen n8n in einem gehärtete Umgebung mit eingeschränkten Betriebssystemprivilegien und Netzwerkzugriff, um die Auswirkungen zu verringern, wobei ausdrücklich darauf hingewiesen wird, dass diese Abhilfemaßnahmen das Risiko nicht vollständig beseitigen. (NVD)

Wenn Sie wollen, dass dies durchsetzbar ist, sollte "gehärtete Umgebung" in Laufzeitkontrollen umgesetzt werden. Hier ist eine konservative Skizze zur Container-Härtung, um die Ausnutzung nach der Ausbeutung zu reduzieren (Defense-in-Depth):

Dienstleistungen:
  n8n:
    Bild: n8nio/n8n:1.122.0
    read_only: wahr
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    user: "1000:1000"
    Umgebung:
      - N8N_LOG_LEVEL=info
    # Pair mit Netzwerkrichtlinie/Firewall:
    # verweigert standardmäßig Egress, erlaubt nur erforderliche Ziele

Erkennung und Bedrohungsjagd: Verhalten gegenüber fragilen Signaturen

Da es sich bei dem auslösenden Mechanismus um "Ausdrücke während der Workflow-Konfiguration handelt, die in einem unzureichend isolierten Kontext ausgewertet werden", können Sie eine nützliche Erkennung um wer die Arbeitsabläufe bearbeitet, wie oftund was die Laufzeitumgebung danach tut. (NVD)

Ein praktischer Ansatz, der die Unterschiede in der Umsetzung übersteht, ist die Korrelation:

Ungewöhnliche Workflow-Bearbeitungen durch Benutzer mit geringen Rechten (oder Dienstkonten) + verdächtige Prozessausführung/ausgehende Verbindungen von der n8n-Laufzeitumgebung. Dies deckt sich mit der Aussage von NVD, dass eine erfolgreiche Ausnutzung zu Operationen auf Systemebene führen kann, die mit den Privilegien des n8n-Prozesses ausgeführt werden. (NVD)

Beispiel für eine auditd-Idee (Anpassung an Ihr Umfeld):

-a immer,exit -F arch=b64 -S execve -F comm=node -k n8n_exec
-a immer,exit -F arch=b64 -S connect -F comm=node -k n8n_net

Benachbarte hochwirksame n8n CVEs, die Sie überprüfen sollten

Wenn Ihr Unternehmen auf n8n angewiesen ist, sollte CVE-2025-68613 nicht als einmalige Angelegenheit behandelt werden. Zwei nebenstehende Beispiele veranschaulichen ein wiederkehrendes Thema in Workflow-Plattformen: Funktionen, die die Grenze zwischen Konfiguration und Ausführung verwischen.

CVE-2025-65964 ist ein separates n8n-Problem, das den Git-Knoten betrifft: NVD beschreibt, dass die Versionen 0.123.1 bis 1.119.1 nicht ausreichend geschützt waren, um RCE durch Git-Hooks zu verhindern, wo Workflow-Aktionen die Git-Konfiguration (z.B. core.hooksPath) beeinflussen und die Ausführung von Hooks verursachen konnten; das Problem wurde in 1.119.2. (NVD)

CVE-2025-57749 ist eine Symlink-Traversal-Schwachstelle im Read/Write File-Knoten von n8n vor 1.106.0, bei dem Verzeichnisbeschränkungen durch symbolische Links umgangen werden konnten, was den Zugriff auf ansonsten beschränkte Pfade ermöglichte. (NVD)

Es handelt sich um unterschiedliche Fehler, aber um dieselbe Lektion: Workflow-Engines befinden sich in gefährlicher Nähe zu "Code- und Systemfähigkeiten", so dass Isolierung, Leitplanken auf Knotenebene und strenge Berechtigungsgrenzen nicht optional sind. Die CWE-913-Definition von MITRE fasst zusammen, warum diese Probleme wieder auftauchen, wenn dynamische Code-Ressourcen unerwartet beeinflusst werden können. (cwe.mitre.org)

Wenn Ihr Ziel ein geschlossener technischer Kreislauf ist - Erkennung von Assets, Versionsvalidierung, Patch-Verifizierung und beweiskräftige Berichte - dann kann eine KI-gesteuerte Sicherheits-Workflow-Plattform wie Penligent ganz natürlich in die Phase "Verifizierung von Fixes und Regressionen" passen. Wenn Ihr einziges Ziel die sofortige Verringerung des Produktionsrisikos ist, bleibt die wirksamste Maßnahme: Aktualisieren Sie auf die korrigierten Versionen und wenden Sie die kurzfristigen Abhilfemaßnahmen des Herstellers an, bis Sie dazu in der Lage sind. (NVD)

https://nvd.nist.gov/vuln/detail/CVE-2025-68613
https://github.com/n8n-io/n8n/security/advisories/GHSA-v98v-ff95-f3cp
https://cwe.mitre.org/data/definitions/913.html
https://docs.n8n.io/release-notes/
https://nvd.nist.gov/vuln/detail/CVE-2025-65964
https://github.com/n8n-io/n8n/security/advisories/GHSA-wpqc-h9wp-chmq
https://nvd.nist.gov/vuln/detail/CVE-2025-57749