End-to-end reproduction and cross-layer detection of CVE-2026-53576, the unauthenticated RCE in Kestra - taken past the base PoC to show how a common Docker-socket misconfiguration turns container-root into full host compromise.
Kestra, eine Open-Source-Plattform zur Workflow-Orchestrierung, lieferte einen Authentifizierungsfilter aus, der anhand der Prüfung, ob die URL mit /configs endet, entschied, ob eine Anfrage Anmeldedaten benötigte - eine Prüfung, die eigentlich nur einen harmlosen öffentlichen Endpunkt freigeben sollte.
Da die Prüfung nur das Ende der Zeichenkette betrachtete, übersprang jede Anfrage, deren URL zufällig so endete, die Authentifizierung vollständig - einschließlich Endpunkten, die beliebigen Code erstellen und ausführen. Das Ergebnis: Jeder, der eine verwundbare Kestra-Instanz über das Netzwerk erreichen kann, kann Befehle als root ohne jegliche Anmeldedaten ausführen - kein Phishing, kein Erraten von Passwörtern, kein Schritt zur Rechteausweitung erforderlich.
In dieser Übung wurde diese einzelne Lücke durchgängig gegen eine selbst gehostete Lab-Instanz geführt:
Jede Phase wurde gegen defensive Telemetrie erfasst (Netzwerk-IDS, Host-Runtime-Sicherheit, Linux-Audit und Systemprotokolle).
Geschäftliche Auswirkung bei Nicht-Patchen: vollständige Kompromittierung des Hosts, auf dem Kestra läuft, nicht nur der Anwendung - und damit einhergehend alles andere, was von diesem Host aus erreichbar ist.
Behebung: Upgrade auf Kestra 1.0.45 / 1.3.21 oder später (der Patch allein schließt die primäre Schwachstelle; die Eskalations- und Persistenzphasen erfordern eine separate, unabhängige Behebung - den Docker-Socket nicht in Anwendungscontainer einbinden, siehe Abschnitt 8).
Dieser Bericht dokumentiert CVE-2026-53576, eine unauthentifizierte Remote-Code-Execution-Schwachstelle mit CVSS 10.0 in Kestra ≤1.3.20, verursacht durch einen Path-Suffix-Authentifizierungs-Bypass (AuthenticationFilter.java, endsWith("/configs")).
Ein Angreifer, der den Namespace und die ID eines Workflows configs nennt, kann beliebige Shell-Befehle ohne Anmeldedaten als root innerhalb des Kestra-Containers erstellen und ausführen. Behoben in 1.0.45 und 1.3.21. Derselbe Fehler wurde auch unabhängig unter CVE-2026-49869 gemeldet, der im CISA KEV aufgeführten Nummer, die mit realer Ausnutzung in freier Wildbahn verbunden ist. Beide sollten zusammen zitiert werden, da öffentliche Quellen und Scanner auf eine der beiden verweisen können.
| Verwundbar | Kestra ≤ 1.3.20 (und vor 1.0.45 auf der 1.0.x-Linie) |
| Behoben | 1.0.45 / 1.3.21+ |
| CVE | CVE-2026-53576 |
| Zwillingshinweis | CVE-2026-49869 - derselbe Fehler, im CISA KEV aufgeführt (in freier Wildbahn) |
| Datum | Ereignis |
|---|---|
| 2026-06-02 | Kestra 1.3.21 veröffentlicht; Changelog verweist auf einen "potenziellen Authentifizierungs-Bypass im Authentifizierungsfilter" |
| 2026-06-03 | Kestra 1.0.45 auf der 1.0.x-Linie veröffentlicht |
| 2026-09-02 | CVE-2026-49869 (der Zwillingshinweis) zum CISA KEV-Katalog hinzugefügt |
| 2026-09-22 bis 09-24 | Diese Lab-Reproduktion, der Detection-Aufbau und die schichtübergreifende Validierung |
Selbst gehostetes Homelab:
- Debian-Host (Hostname docker, Kernel 6.12.107+deb13-amd64),
- Docker Engine 29.8.1.
- Kestra bereitgestellt als offizielles kestra/kestra:v1.3.20-Image, erreichbar über einen Caddy-Reverse-Proxy unter kestra.int.atlasvec.com.
- Telemetrie-Stack unter Test: Falco (Runtime/eBPF, Host-Ebene),
- Suricata 8.0.3 IDS (passiver SPAN-Mirror), Weiterleitung an Splunk.
Bevor ich irgendetwas anfasste, bestätigte ich, dass das Ziel tatsächlich verwundbar war und der Telemetrie-Stack aktiv war. Ich erstellte außerdem einen Snapshot des Zustands vor dem Angriff, damit ich nach Abschluss zurückrollen konnte.
Kestra mit der verwundbaren Version:
Der Container selbst, aktiv und erreichbar:
Falcos Units auf dem Host geladen:
Falco sendet aktiv Ereignisse (moderner eBPF-Modus):
Suricatas Dienst aktiv:
Und seine eve.json, die Live-Ereignisse schreibt:
Hier treffen zwei Fehler aufeinander, nicht einer.
Erstens entscheidet der Authentifizierungsfilter, ob eine Anfrage die Authentifizierung überspringen kann, indem er das Ende des Anfragepfads abgleicht:```java // AuthenticationFilter.java — the vulnerable check, confirmed against the self-hosted v1.3.20 source if (path.endsWith("/configs")) { // treated as a public, unauthenticated path }
Diese Prüfung existiert, um einen einzigen harmlosen Endpunkt offenzulegen, die öffentliche Instanzkonfiguration. Da `endsWith` nur das Ende des Strings liest, kann es einen sicheren Pfad nicht von jedem anderen Pfad unterscheiden, der zufällig gleich endet.