#Homelab · 5 Min. Lesezeit · Tim Rinkel

FRIST LÄUFT HEUTE AB! Fünf Buchstaben in der URL machen Fremde zum Root — Krypto-Miner inklusive

FRIST LÄUFT HEUTE AB! Fünf Buchstaben in der URL machen Fremde zum Root — Krypto-Miner inklusive

Manchmal ist der Unterschied zwischen sicher und sperrangelweit offen ein einziges Wort im Quellcode. Bei der Workflow-Engine Kestra heißt dieses Wort endsWith — und es hat eine Lücke mit dem Höchstwert CVSS 10.0 aufgerissen.

Noch unangenehmer: Die US-Cyberbehörde CISA hat die Schwachstelle am 2. September auf ihre Alarmliste gesetzt. Die Frist für Bundesbehörden läuft heute ab. Wenn du Kestra im Homelab oder in der Firma betreibst, ist dein Zeitfenster damit ebenfalls zu.

FÜNF BUCHSTABEN, DIE ALLES AUFMACHEN

Kestra hat einen öffentlichen Konfigurations-Endpunkt, der bewusst ohne Anmeldung erreichbar sein soll. Damit das funktioniert, prüft der AuthenticationFilter, ob der angefragte Pfad auf /configs endet — und lässt ihn dann an der Passwortabfrage vorbei.

Das Problem: Die Prüfung ist ein Endungsvergleich, kein exakter Pfadvergleich. Es reicht also, wenn irgendein API-Pfad als letztes Segment configs trägt. Wer die richtige URL zusammenbaut, spaziert an der Anmeldung vorbei — ohne Zugangsdaten, ohne Token, ohne alles.

Und dahinter wartet keine harmlose Statusseite, sondern die volle API einer Workflow-Engine. Ein Angreifer kann eigene Workflows anlegen und ausführen — und Workflows dürfen bei Kestra Befehle ausführen. Das Ergebnis ist Codeausführung als root im Worker-Container, ganz ohne Anmeldung.

GEFAHR! Die Angriffe laufen seit Ende Juni

Das ist keine Papierlücke. Microsoft hat einen Angriff dokumentiert, bei dem die Schwachstelle bereits Ende Juni 2026 ausgenutzt wurde — mit einem Ablauf, den man aus vielen Container-Einbrüchen kennt:

  • Aufbau einer Reverse Shell zurück zum Angreifer
  • Erkundung der Docker-Umgebung von innen heraus
  • Maßnahmen zur Tarnung gegen Erkennung
  • Installation eines Krypto-Miners
  • Absaugen von Daten aus der Umgebung

Der Krypto-Miner ist dabei der harmlosere Teil — er macht sich immerhin bemerkbar, weil dein Server plötzlich unter Volllast läuft. Der gefährliche Teil ist Schritt zwei: Wer in einem Worker-Container Root-Rechte hat, sieht die Zugangsdaten aller Workflows. Datenbank-Passwörter, API-Schlüssel, Cloud-Tokens — alles, was deine Automatisierung zum Arbeiten braucht.

SO REPARIERST DU DAS JETZT

Die Fixes sind veröffentlicht:

  • 1.0.45 für den älteren 1.0er-Zweig
  • 1.3.21 für den aktuellen Zweig

Betroffen sind alle Stände davor, also alles bis einschließlich 1.3.20. Bei einer Docker-Compose-Installation genügt in der Regel:

  1. Das Image-Tag in deiner docker-compose.yml auf die gepatchte Version setzen.
  2. docker compose pull und anschließend docker compose up -d ausführen.
  3. In der Oberfläche unter „Version“ gegenprüfen, dass wirklich der neue Stand läuft.

Und dann kommt der Teil, den viele auslassen: Schau in die Ausführungs-Historie. Suche nach Workflows, die du nicht angelegt hast, nach Läufen zu absurden Uhrzeiten, nach unbekannten Namespaces. Prüfe die CPU-Auslastung der letzten Wochen — ein Miner hinterlässt dort eine sehr deutliche Spur.

EXTRA-TIPP: Warum Kestra nie am offenen Internet hängen sollte

Diese Lücke ist ein Musterbeispiel dafür, warum Verwaltungsoberflächen nichts im offenen Internet zu suchen haben. Kestra ist eine Automatisierungszentrale — sie kennt naturgemäß die Zugangsdaten zu allem, was sie steuert. Genau solche Dienste gehören hinter einen VPN-Tunnel oder ein Reverse-Proxy-Setup mit vorgelagerter Anmeldung.

Mit dieser Absicherung wäre CVSS 10.0 für dich zu einem Update geworden, das du in Ruhe am Wochenende einspielst — statt zu einem Rennen gegen automatisierte Scanner.

FAZIT: Heute updaten, dann nachschauen

Ein Endungsvergleich statt eines exakten Vergleichs, und eine ganze Automatisierungsplattform steht offen. Update einspielen, Historie prüfen, Zugangsdaten rotieren, wenn irgendetwas komisch aussieht. In dieser Reihenfolge.

Häufige Fragen

Welche Kestra-Versionen sind betroffen?
Verwundbar sind alle Ausgaben von Kestra OSS bis einschließlich 1.3.20 sowie die älteren Stände des 1.0er-Zweigs. Behoben ist die Lücke in 1.0.45 und 1.3.21. Deine laufende Version findest du in der Weboberfläche im Bereich „Version“ oder über das Image-Tag in deiner Docker-Compose-Datei.
Wie merke ich, ob mein System angegriffen wurde?
Prüfe die Ausführungs-Historie auf Workflows, Namespaces oder Läufe, die du nicht angelegt hast. Ein zweites deutliches Signal ist eine ungewöhnlich hohe CPU-Auslastung über längere Zeiträume — das typische Zeichen eines Krypto-Miners. Auffällige ausgehende Netzwerkverbindungen aus dem Worker-Container gehören ebenfalls auf die Liste.
Wie behebe ich das Problem konkret?
Setze das Image-Tag auf 1.0.45 beziehungsweise 1.3.21, führe docker compose pull und docker compose up -d aus und prüfe anschließend die Versionsanzeige. Wenn du Anzeichen für einen Einbruch findest, wechsle danach alle Zugangsdaten, die in deinen Workflows hinterlegt sind — Datenbank-Passwörter, API-Schlüssel und Cloud-Tokens.
Gab es schon aktive Angriffe?
Ja. Microsoft dokumentierte einen Fall aus Ende Juni 2026, bei dem Angreifer über die Lücke eine Reverse Shell aufbauten, die Docker-Umgebung erkundeten, Erkennungsmechanismen umgingen, einen Krypto-Miner installierten und Daten absaugten. Die CISA nahm die Schwachstelle am 2. September in ihren Katalog aktiv ausgenutzter Lücken auf.
Was macht die Lücke so schwerwiegend?
Sie erfordert keinerlei Vorwissen und keine Zugangsdaten, ist über das Netz erreichbar und führt direkt zu Codeausführung mit Root-Rechten im Worker-Container. Genau diese Kombination ergibt den maximal möglichen CVSS-Wert von 10.0. Weil Kestra als Automatisierungsplattform die Zugangsdaten aller angebundenen Systeme kennt, reicht die Wirkung weit über den Container hinaus.

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert