atlasvector/kestra-cve-2026-53576End-to-End-Reproduktion und Cross-Layer-Erkennung von CVE-2026-53576, der unauthentifizierten RCE in Kestra — über den Basis-PoC hinausgeführt, um zu zeigen, wie eine häufige Docker-Socket-Fehlkonfiguration Container-Root in eine vollständige Host-Kompromittierung verwandelt.
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 |
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.
Zweitens leitet Kestras Router diese ähnlich aussehenden Pfade weiterhin an ihre echten, sensiblen Handler weiter. `/api/v1/main/flows/configs` erreicht den Flow-Create-Handler. `/api/v1/main/executions/configs/configs` erreicht den Execution-Handler. Der Filter winkt beide als öffentlich durch, und der Router führt sie trotzdem aus. Benenne den Namespace und die ID eines Flows `configs`, und ein code-ausführender Endpunkt endet nun auf `/configs`, sodass er den Freifahrtschein des öffentlichen Pfads erbt.
Das aufgezeichnete Request-Paar zeigt es deutlich. `GET /api/v1/main/flows/search` ohne Credentials liefert `401`. `POST /api/v1/main/flows/configs` mit demselben leeren Auth-Header liefert `200` und speichert den Flow (siehe §5.1).
## 5. Angriffssimulation
> Jeder Schritt unten ist mit einem eigenen Screenshot festgehalten. Alles läuft in meinem eigenen isolierten Homelab gegen eine selbst gehostete Kestra-Instanz hinter dem Reverse Proxy.
### 5.1 Stage 1 - Auth-Bypass -> root im Kestra-Container
**Kontrolle :** `GET /api/v1/main/flows/search` ohne Credentials → `401 Unauthorized`.
Bestätigt, dass die Authentifizierung auf einer normalen Route erzwungen wird.
_____
**Platzieren :** Senden von `POST /api/v1/main/flows/configs` ohne Auth-Header. Der Body ist ein Flow-YAML, dessen `namespace` und `flow id` beide `configs` sind und das eine Commands-Task enthält, die den Process-Task-Runner verwendet. Der Server gibt `200 OK` zurück und speichert den Flow. Das `/configs`-Suffix auf einer ansonsten geschützten Route ist das, was den Bypass auslöst **(siehe Abschnitt 4).**
**Lauschen & Warten** : Starten eines einfachen Listeners mit nc zu Testzwecken, damit wir die Reverse Shell abfangen.
**Auslösen / Ausführen** `POST /api/v1/main/executions/configs/configs`, kein Auth-Header → `200 OK`, neue Execution erstellt.
**BaaaaM :** Wir haben die Shell geknackt, aber denk daran - wir sind "isoliert", `root` **ABER** innerhalb des Kestra-Docker-Containers, also "sollten" wir von hier nicht entkommen können. "**Nun, das dachte ich zumindest**"
Der Befehl der Task läuft als direktes Kind des Kestra-JVM-Prozesses, bestätigt über den hostseitigen Prozessbaum, und wird gemäß Kestras eigenem Execution-Log erfolgreich abgeschlossen.
**Kestras Logs-Dashboard**
**Kestras Prozessbaum**
**Ergebnis:** nicht authentifizierte Remote-Code-Ausführung als root, innerhalb des Kestra-Containers. Dies ist der vollständige, in sich geschlossene Beweis für **CVE-2026-53576**.
### 5.2 Stage 2 - Eskalation über exponierten Docker-Socket (homelab-spezifisch, nicht Teil der CVE selbst)
Aus der Stage-1-Shell wurde festgestellt, dass `/var/run/docker.sock` in den Container gemountet war - ein Docker-outside-of-Docker-(DooD)-Muster, das häufig vorkommt, wenn Kestras eigener `Docker`-Task-Runner konfiguriert ist, da dieser einen Daemon zum Ansprechen benötigt.
Diesen Socket überhaupt zu erreichen ist gleichbedeutend mit Host-**root**: Die Docker-API erlaubt es einem Client, beliebige Host-Bind-Mounts sowie Host-PID-/Netzwerk-Namespaces für Container zu konfigurieren, die er startet, und der Daemon hinter dem Socket läuft bereits als root auf dem Host.
Dies ist kein Kernel- oder Container-Escape-Exploit - es ist die Docker-API, die tut, wofür sie entworfen wurde, erreicht von einem Ort, von dem aus sie nicht hätte erreichbar sein sollen.
Mithilfe des Sockets erstellte ich einen Schwester-Container mit eingebundenem Host-Dateisystem sowie Host-PID- und Netzwerk-Namespaces und startete ihn dann.
**Hinweis:** Eine zweite, leisere Variante kam während des Tests ebenfalls auf, obwohl ich sie nicht separat per Screenshot festgehalten habe. Statt immer einen neuen Schwester-Container zu erstellen, erlaubt derselbe Socket-Zugriff, `POST /containers/{id}/exec` gegen einen bereits laufenden Container auszuführen, sodass überhaupt kein Container-Create-Event entsteht. Auf diesem Docker-Host habe ich sowohl Kestra als auch Portainer, von denen ich jedes für denselben Escape verwenden könnte. Das ist wichtig für die Erkennung: Jede Regel, die auf die Erstellung eines neuen privilegierten Containers abzielt, verpasst diese Variante.
Bestätigen von root und Auffinden des Sockets, der dort ohne jegliche Einschränkung liegt:
Prüfen, ob der Docker-Daemon über den Socket tatsächlich erreichbar ist:
Auflisten, welche Images bereits lokal vorhanden sind, damit ich nichts pullen muss:
Erster Versuch: ein privilegierter Container mit eingebundenem Host-Dateisystem:
Zweiter Versuch, diesmal mit Host-PID- und Netzwerk-Namespaces:
Dritter Versuch, direktes chroot in das gemountete Host-Dateisystem:
Listener läuft und wartet auf den Port, an den die Escape-Shell zurückrufen wird:
Starten des Containers:
**Root, aber diesmal ist es der Host, nicht der Container:**
Kernel-Version entspricht dem echten Host, nicht der isolierten Sicht eines Containers:
Upgrade auf eine ordentliche interaktive Shell für den Rest der Session:
### 5.3 Stage 3 - Persistenz, bestätigt ausgelöst
Aus der Host-Root-Shell richtete ich zwei unabhängige Persistenzmechanismen ein,
**Erstens**, einen SSH-Key. Ich prüfte, wer bereits Zugriff hatte :
Dann prüfte ich sshds eigene Konfiguration auf alles, was einen neuen Key blockieren würde:
Erzeugte ein Schlüsselpaar auf der Angreifer-Box:
Bestätigte, dass sshd tatsächlich lauschte:
Legte den öffentlichen Schlüssel in roots `authorized_keys` ab:
Und meldete mich mit dem passenden privaten Schlüssel an:
**PS:** Das ist Root-Zugriff unabhängig von der ursprünglichen RCE-Kette. Selbst wenn Kestra gepatcht wird, funktioniert dieser Schlüssel weiterhin.
**Zweitens**, ein Cron-Beacon. Ich legte einen Root-Level-Callback ab, der in einem Intervall laufen sollte, und testete dann mit einem frischen Listener, ob er tatsächlich planmäßig ausgelöst wird:
**Er wurde ausgelöst. Ein zweiter Standfuß auf dem Host, unabhängig sowohl von der RCE als auch vom SSH-Key.**
### 5.4 Verifizierte Kill-Chain-Timeline.
Die folgende Timeline ist anders: Sie ist vollständig aus unabhängiger verteidigerseitiger Telemetrie rekonstruiert (Network IDS + Host Runtime Security), live gegen echte Splunk-Daten abgerufen und validiert.
**Primäre RCE - Netzwerk erkennt die Auslieferung, Host bestätigt die Ausführung, 103 Sekunden Abstand:**
| Zeit (EDT) | Ebene | Ereignis |
| ------------ | ------------------ | -------------------------------------------------------------------------------------------- |
| 02:46:09.778 | Netzwerk (Suricata) | Öffentliche ET-Signatur für genau diese CVE wird ausgelöst |
| 02:47:52.277 | Host (Falco) | Reverse Shell im Kestra-Container bestätigt, exakter Befehl und Container-ID erfasst |
**Eskalation - Netzwerk und Host bestätigen jeweils unabhängig einen anderen Teil desselben Ereignisses:**
| Zeit (EDT) | Ebene | Ereignis |
| ------------ | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| 03:48:55.503 | Host (Falco) | Reverse Shell aus dem Eskalations-Container |
| 03:51:57.360 | Netzwerk (Suricata) | TCP-Flow **und** ein inhaltsbasierter Alert - der wörtliche String `uid=0(root)` wurde beim Verlassen des Hosts im Klartext gesehen, als `id` ausgeführt wurde |
## 6. Detection Engineering
Ich baute die Detections gegen echte erfasste Telemetrie und testete dann jede einzelne gegen ein Replay. Die Matrix zeigt, wo vor meinem Beginn Abdeckung existierte und wo nicht.
### 6.0 Detection-Coverage-Matrix
| Stage | Netzwerk (Suricata) | Host (Falco) | Host (auditd/journald) | Status |
| --- | --- | --- | --- | --- |
| Initiale Exploit-Anfrage | Öffentliche ET-Signatur wird ausgelöst | Keine App-Layer-Sichtbarkeit | - | Abgedeckt (bereits vorhanden) |
| RCE-Ausführung | - | Native Regel, T1059-getaggt | - | Abgedeckt (bereits vorhanden) |
| Docker-Socket-Eskalation (die Technik) | - | Lücke: erfasst nur die resultierende Shell, nicht die Socket-Missbrauchs-API-Aufrufe | EXECVE-Datensätze erfassen die exakten `curl --unix-socket`-Aufrufe | Lücke gefunden, geschlossen mit auditd + einer benutzerdefinierten Falco-Regel |
| Bestätigung der Eskalationsauswirkung | Content-Alert auf die geleakte `id`-Ausgabe | Dieselbe generische Shell-Regel | - | Abgedeckt (bereits vorhanden, ebenenübergreifend) |
| SSH-Persistenz | - | - | journald: vollständiger PAM-Lebenszyklus plus Key-Fingerprint | Abgedeckt (nur Host) |
| Cron-Persistenz | - | - | journald und linux_audit, zwei Quellen, exakte 5-Minuten-Kadenz | Abgedeckt (nur Host) |
Die Lücke ist die Docker-Socket-Eskalation. Falcos Standardregeln erfassen die Shell, die ein kompromittierter Container startet, aber nichts im stabilen Standard-Set markiert einen Prozess, der `/var/run/docker.sock` erreicht, um die Docker-API direkt anzusteuern. Die Regeln, die privilegierte Container-Starts betreffen würden, `Launch Privileged Container` und `Launch Sensitive Mount Container`, werden mit `incubating`- und `sandbox`-Reifegrad ausgeliefert, sodass das Standard-Regelset sie ebenfalls nicht lädt. Ich schloss die Lücke mit einer auditd-Korrelationssuche (Detection 03) und einer benutzerdefinierten Falco-Regel (§6.3).
### 6.1 Splunk - fünf Korrelationssuchen, bereitgestellt und geplant
Alle fünf laufen live in Splunk (`*/5 * * * *`, Alert-Tracking aktiviert, Throttling pro Feld), nicht nur geschrieben und als Text belassen. Vollständiges SPL, exakte FP-Hinweise, Severity, MITRE-Tags und Response-Runbooks für jede einzelne sind in `detections/splunk/*.spl`. Die Status-Tabelle unten ist das live getestete Ergebnis für jede, einschließlich eines echten Bugs, den ich gefunden und behoben habe.
| # | Detection | MITRE | Status |
| --- | ---------------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| 01 | Netzwerk-Exploit-Signatur (konsumiert den Suricata-ET-Alert) | T1190 | **Ausgelöst** - historisches Replay bestätigt, seitdem keine neuen Events (außerhalb des aktuellen Lookback) |
| 02 | Host-RCE-Ausführung (Falco-Redirect-to-Network-Regel) | T1059 | **Ausgelöst** - historisches Replay bestätigt |
| 03 | Docker-Socket-Missbrauch (auditd, der Lückenschließer) | T1610, T1611 | **Ausgelöst auf dem Live-Scheduler selbst** - `triggered_alert_count: 1` bestätigt beim echten `*/5 * * * *`-Lauf, nicht nur bei einem manuellen Test |
| 04 | SSH-Root-Login-Persistenz | T1098.004, T1021.004 | **Ausgelöst** - historisches Replay bestätigt |
| 05 | Cron-Beacon-Persistenz | T1053.003 | **Bereitgestellt mit einem Bug, den ich gefunden und live behoben habe.** Das `-10m`-Dispatch-Fenster enthielt nur zwei der drei 5-Minuten-Buckets, die der `distinct_intervals >= 3`-Schwellenwert benötigt, sodass es niemals auslösen konnte, obwohl der Beacon in echten Daten weiterhin lief. Erweiterte es auf `-30m` und stellte es erneut bereit - und der Scheduler hat es seitdem 53 Mal ausgelöst, die Korrektur hält also. |
Die Arbeitsteilung von Detection 03 ist bewusst gewählt: Statt Suricatas eigene Signaturlogik in SPL neu zu implementieren oder zu versuchen, Falco eine Socket-Level-Technik erfassen zu lassen, für die es nicht gebaut wurde, konsumiert die SIEM-Ebene hier auditds EXECVE-Datensatz der exakten `curl --unix-socket`-Aufrufe - die Telemetriequelle, die sich für diese spezifische Technik als am zuverlässigsten erwiesen hat.
1. **Detection 01** - ET-Signatur wird ausgelöst (`suricata:eve`-Alert):```spl
index=main sourcetype=suricata:eve event_type=alert
alert.signature="ET WEB_SPECIFIC_APPS Kestra Unauthenticated Remote Code Execution (CVE-2026-53576)"
| stats count min(_time) as first_seen max(_time) as last_seen
values(src_ip) as source_ips
by dest_ip dest_port
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S")
| eval last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
Detection 02 – Falcos Redirect-to-Network-Regel, aufgeschlüsselt pro Container. Die Quell-IP verschiebt sich von der Bridge-Adresse des Kestra-Containers (172.17.0.3, primäre RCE auf Port 4489) zum Host selbst (172.66.66.67, Eskalation auf Port 4491) – die Container-zu-Host-Eskalation wird sichtbar – während das Ziel konstant bleibt: der Listener des Angreifers unter 172.66.66.125:
Detection 03 – auditd-EXECVE-Datensätze von curl --unix-socket docker.sock:
Detection 04 – journald-Root-SSH-Login, Schlüsselfingerabdruck erfasst:
Detection 05 – der Cron-Beacon als versteckte Dotfile (/usr/local/bin/.sysmon), der als root in exakt 5-Minuten-Intervallen läuft: 79 verschiedene Intervalle über ~6,5 Stunden (04:30–11:00 EDT). Die Schwelle distinct_intervals >= 3 ist es, die einen periodischen Beacon von einem einmaligen Cron-Job unterscheidet:
Alle fünf als geplante gespeicherte Suchen (*/5 * * * *) bereitgestellt:
Der Beweis, dass der Cron-Scheduler diese tatsächlich ausführt und nicht nur, dass sie existieren: Alle fünf wurden 54-mal ausgeführt. Detection 03 schlug einmal an (der Docker-Socket-Missbrauch, 06:35 EDT) und Detection 05 schlug 53-mal an (der weiterhin aktive Cron-Beacon). Detections 01/02/04 zeigen 0 Treffer, da es sich um einmalige historische Ereignisse handelt (Exploit-Request, RCE, SSH-Login), die aus dem -10m-Lookback-Fenster herausgefallen sind, während eine aktive oder wiederkehrende Instanz weiterhin alarmieren würde:
Das /dev/tcp/-Reverse-Shell-Muster – verwendet sowohl in der primären RCE als auch im Eskalations-Callback. SigmaHQ liefert dafür eine Regel: „Suspicious Reverse Shell Command Line" (ID 738d9bcf-6999-4fdb-b4ac-3033037db8ab, von Florian Roth bei Nextron Systems), und eines ihrer Schlüsselwörter ist bash -i >& /dev/tcp/ – genau das, was in unserer Aufzeichnung auftauchte.
Also habe ich diese Regel unverändert übernommen (detections/sigma/lnx_shell_susp_rev_shells.yml) und ihr Schlüsselwort gegen dasselbe Falco-Ereignis geprüft, das Detection 02 bereits erfasst hat. Sigma „feuert" nicht von selbst – es ist eine portable Signatur, keine laufende Engine –, aber ich kann zeigen, wie ihr Schlüsselwort auf echte Telemetrie aus diesem Lauf trifft statt auf ein Lehrbuchbeispiel.
Öffentliche SigmaHQ-Regel „Suspicious Reverse Shell Command Line" – ihr Schlüsselwort bash -i >& /dev/tcp/ gegen dasselbe reale Ereignis wie Detection 02:
detections/falco/docker_socket_abuse.yaml – auf der Live-Falco-Instanz bereitgestellt und mit Auslösung bei einem echten Replay bestätigt, 2026-09-24T10:27:29Z.
Das Standard-Regelset von Falco deckt dies nicht ab. Einen Prozess zu erkennen, der auf /var/run/docker.sock zugreift, ist keine neue Idee – Sysdigs eigene Falco-Beispiele tun dies, indem sie auf open_write auf dem Socket-Pfad achten –, aber es gibt keine solche Regel im mitgelieferten/Standard-Set (das Projekt hat eine offene Anfrage dafür, falcosecurity/falco #2940), und die eine angrenzende Standardregel erfasst nur die docker/kubectl-CLIs, nicht ein rohes curl --unix-socket.
Der Haken: Der standardmäßige open_write-auf-dem-Socket-Ansatz löste in diesem Setup nicht aus – mit modern_bpf und einem passiven Mirror wird der Socket über connect() erreicht, nicht über open(). Also matche ich stattdessen auf die Prozess-Kommandozeile beim Spawn (spawned_process + proc.cmdline contains "docker.sock"), dieselbe Ereignisklasse, die Falco hier bereits zuverlässig verarbeitet. Sie feuert zweimal pro Aufruf – der Shell-Wrapper und das curl-Blatt – mit vollem Kontext:```
priority=Critical, container_id=d417e027d444, image=kestra/kestra:v1.3.20, user=root, cmdline="curl -s --unix-socket /var/run/docker.sock http://localhost/version", tags=[T1610, T1611]
Benutzerdefinierte Falco-Regel, die ausgelöst wurde – „Unexpected Process Accessing Docker Socket" (T1610/T1611):
Standard-Falco-Regeln, die ausgelöst wurden – das Standard-Set enthält keine docker-socket-Regel, was die Lücke darstellt:
### 6.4 Suricata – bestehende öffentliche Abdeckung, benutzerdefinierte Regel zurückgestellt
Die Netzwerkschicht für den primären Exploit ist bereits durch eine öffentliche Emerging-Threats-Signatur abgedeckt, `ET WEB_SPECIFIC_APPS Kestra Unauthenticated Remote Code Execution (CVE-2026-53576)`, die während Phase 2 bei echtem Datenverkehr ausgelöst wurde.
Unten ist derselbe Bypass auf der Netzwerkschicht zu sehen, und ich habe die Abfrage aus dem Schwachstellenmuster erstellt. Jede Anfrage, deren Pfad auf einem `flows`- oder `executions`-Endpunkt mit `/configs` endet, kam mit `200` zurück, während eine normale Route (`/flows/search`) die erwartete `401` zurückgab.
Die Spalte `Attacker IP (XFF)` ist der echte HTTP-Ursprung, gelesen aus dem `X-Forwarded-For`-Header: `10.10.10.106`, mein Mac, auf dem Burp läuft. Suricatas eigenes `src_ip` sieht nur den Reverse-Proxy-Hop (`172.66.66.1`). Das ist eine andere Maschine als die `172.66.66.125`-Kali-Box, die später die Reverse Shells abfing und den SSH-Login durchführte, sodass der HTTP-Exploit und die Callbacks von getrennten Hosts kamen.
### 6.5 Dashboard
`cve_2026_53576_kill_chain` ist in Splunk bereitgestellt und enthält: Headline-KPIs (Erkennungsschichten, ATT&CK-Techniken, bereitgestellte Erkennungen, Persistenzmechanismen), ein Säulendiagramm der Angriffs-Timeline, eingefärbt nach Telemetrieschicht, eine MITRE-ATT&CK-Kill-Chain-Karte mit einer Live-Evidenzzahl pro Phase, die netzwerk- und hostkorrelierte Timeline aus §5.4, Erkennungsabdeckung nach geplanter gespeicherter Suche, die Aufschlüsselung der docker-socket-Technik und eine Live aus den Logs gezogene Tabelle mit Kompromittierungsindikatoren.
- KPIs, das Angriffs-Timeline-Diagramm und der Beginn der ATT&CK-Karte:
- Der Rest der ATT&CK-Karte, die korrelierte Kill-Chain, die Erkennungsabdeckung neben der docker-socket-Aufschlüsselung und die IOC-Tabelle:
## 7. ATT&CK-Mapping
| Taktik | Technik | Evidenz |
| -------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Initial Access | T1190 - Exploit Public-Facing Application | Control/plant/execute-Anfragen (§5.1); Suricata-ET-Signatur löst aus, §5.4 |
| Execution | T1059.004 - Command and Scripting Interpreter: Unix Shell | Kestra-`Commands`-Task, Host-Prozessbaum (`07-kestra-process-tree.png`); Falco-Regel, §6.1 Erkennung 02 |
| Command and Control | T1095 - Non-Application Layer Protocol | Rohe `/dev/tcp/`-TCP-Reverse-Shell – keine Application-Layer-C2-Framing verwendet |
| Discovery | T1613 - Container and Resource Discovery | Docker-Image-Enumeration über den Socket (`10-docker-images-enum.png`) |
| Privilege Escalation | T1610 - Deploy Container | Sibling-Container-Erstellung/-Start über die Docker-API (`11`–`15`); auditd-EXECVE-Datensätze, §6.1 Erkennung 03 |
| Privilege Escalation | T1611 - Escape to Host | Host-Root-Bestätigung, Hostname/Kernel-Übereinstimmung (`16`, `17`) |
| Persistence | T1098.004 - Account Manipulation: SSH Authorized Keys | Key-Implantat in `/root/.ssh/authorized_keys` (`23`) |
| Lateral Movement | T1021.004 - Remote Services: SSH | Erfolgreicher schlüsselbasierter Root-Login (`24`); journald, §6.1 Erkennung 04 |
| Persistence | T1053.003 - Scheduled Task/Job: Cron | Cron-Beacon, bestätigte planmäßige Auslösung (`25`); §6.1 Erkennung 05 |
## 8. Behebung & Härtung
**Primäre Lösung.** Upgrade auf Kestra 1.0.45 (1.0.x-Zweig) oder 1.3.21+ (1.3.x-Zweig). Allein dies schließt den Auth-Bypass – Phase 1 dieser Übung – und ist
die einzige Lösung, die nach Anwendung keine weiteren kompensierenden Kontrollen erfordert. Siehe [GHSA-2q47-568g-9h4f](https://github.com/kestra-io/kestra/security/advisories/GHSA-2q47-568g-9h4f).
**Falls ein sofortiges Patchen nicht möglich ist**, kompensierende Kontrollen, nach Wirkung geordnet:
1. **Durchsetzung am Reverse-Proxy** – da der verwundbare Filter nur beim rohen Pfad-Suffix fehlschlägt, kann ein Reverse-Proxy vor Kestra (in diesem Lab Caddy) unabhängig davon die Authentifizierung für jeden Pfad erzwingen, der auf `/api/v1/*/(flows|executions)/.*` passt, unabhängig davon, womit er endet, und schließt so den Bypass auf einer Ebene, die der Anwendungsfehler nicht erreichen kann.
2. **Docker-Socket-Mount einschränken** – dies schließt die Phasen 2–3 vollständig, unabhängig vom Kestra-Patch. Binden Sie `/var/run/docker.sock` nicht per Bind-Mount in den Kestra-Container ein. Wenn der `Docker`-Task-Runner wirklich erforderlich ist, verwenden Sie einen eingeschränkten Socket-Proxy (z. B. `docker-socket-proxy`), der bestimmte API-Aufrufe auf eine Allowlist setzt, anstatt vollen Daemon-Zugriff zu gewähren – voller Zugriff auf den Socket entspricht Host-Root, wie in §5.2 gezeigt.
3. **SSH-Härtung** – der erste Mechanismus der Persistenzkette hing überhaupt davon ab, dass Root per schlüsselbasiertem SSH erreichbar war. `PermitRootLogin no` (oder die Anforderung eines Bastion/MFA für Root) hätte diesen spezifischen Persistenzpfad unabhängig von der anfänglichen RCE blockiert – lohnenswert unabhängig von dieser CVE.
4. **Vorläufige Erkennungsabdeckung** – die Splunk-Korrelationssuchen und die benutzerdefinierte Falco-Regel, alle während dieser Übung bereitgestellt und verifiziert, bieten die vorläufige Abdeckung für die Phasen dieser spezifischen Kette, während das Patchen geplant wird.
**Hygiene nach dem Vorfall**, falls dieses Muster bereits ausgenutzt vorgefunden wird: Behandeln Sie es als vollständige Host-Kompromittierung, nicht nur als Anwendungskompromittierung – rotieren Sie sämtliche Anmeldedaten und Geheimnisse, auf die die Kestra-Instanz Zugriff hatte (KV-Store-Einträge, Verbindungsanmeldedaten für nachgelagerte Systeme), nicht nur Kestras eigenen Zugriff.
**Status in freier Wildbahn.** `CVE-2026-49869`, der Zwillings-Hinweis für denselben Fehler, ist in CISA's KEV-Katalog aufgeführt und mit beobachteten Krypto-Mining- und Cloud-Credential-Diebstahl-Kampagnen verbunden. `CVE-2026-53576` (dieser Bericht) hat keine eigene KEV-Auflistung, ist aber dieselbe Schwachstelle. Schwachstellenmanagement-Tools, die nur eine der beiden CVE-Nummern verfolgen, melden die Exposition möglicherweise zu niedrig.
## 9. Referenzen
- Kestra Security Advisory – [GHSA-2q47-568g-9h4f](https://github.com/kestra-io/kestra/security/advisories/GHSA-2q47-568g-9h4f) (CVE-2026-53576, primäre Quelle dieses Berichts)
- Zwillings-Hinweis – [GHSA-5vc5-wxxq-3fjx](https://github.com/kestra-io/kestra/security/advisories/GHSA-5vc5-wxxq-3fjx) (CVE-2026-49869, identischer Fehler, in CISA KEV aufgeführt)
- CVE.org – [CVE-2026-53576](https://www.cve.org/CVERecord?id=CVE-2026-53576), [CVE-2026-49869](https://www.cve.org/CVERecord?id=CVE-2026-49869)
- CISA Known Exploited Vulnerabilities Catalog – https://www.cisa.gov/known-exploited-vulnerabilities-catalog (Eintrag CVE-2026-49869, hinzugefügt am 02.09.2026)
- Behobene Releases, beide bestätigt vorhanden und getaggt – [v1.3.21](https://github.com/kestra-io/kestra/releases/tag/v1.3.21) (02.06.2026, Changelog verweist explizit auf „potential authentication bypass in the authentication filter"), [v1.0.45](https://github.com/kestra-io/kestra/releases/tag/v1.0.45) (03.06.2026)
- Docker-Socket-Eskalationstechnik (§5.2) – [HackTricks: Docker Breakout / Privilege Escalation](https://hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html), [Trail of Bits: Understanding Docker Container Escapes](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/), [MindPatch: Docker Escape](https://www.mindpatch.net/posts/docker-escape/)
- Sigma-Regel (§6.2) – die öffentliche Regel, die ich verwendet habe, anstatt eine eigene zu schreiben: [SigmaHQ "Suspicious Reverse Shell Command Line"](https://github.com/SigmaHQ/sigma/blob/master/rules/linux/builtin/lnx_shell_susp_rev_shells.yml) (id `738d9bcf-6999-4fdb-b4ac-3033037db8ab`, Florian Roth / Nextron Systems), verwendet unter der [Detection Rule License 1.1](https://github.com/SigmaHQ/sigma/blob/master/LICENSE.Detection.Rules.md)
- Falco-Regel (§6.3) – die docker-socket-Lücke ist ein offener Upstream-Request ([falcosecurity/falco #2940](https://github.com/falcosecurity/falco/issues/2940)); die benutzerdefinierte Regel folgt dem Muster in [Sysdig's Docker + Falco examples](https://www.sysdig.com/blog/docker-falco-security)
| 2026-09-22 bis 09-24 | Diese Lab-Reproduktion, der Detection-Aufbau und die schichtübergreifende Validierung |