Die Kurzfassung
CVE-2026-49869 ist ein Authentifizierungs-Bypass mit CVSS 10.0 in Kestra OSS, der einem nicht angemeldeten Angreifer Remote Code Execution als root verschafft. Die Freigabe des öffentlichen Konfigurations-Endpunkts prüft nur das Pfadende – endsWith("/configs") –, daher überspringt jeder Request, dessen Pfad auf configs endet, die Basic Auth. Danach kann ein Angreifer im Worker-Container einen Workflow mit Shell- oder Python-Tasks anlegen und starten. Die CISA hat die Lücke am 2. September 2026 in den KEV-Katalog aufgenommen.
Wenn Kestra irgendwo in Ihrer Datenpipeline läuft: jetzt auf 1.3.21 oder 1.0.45 aktualisieren und jede öffentlich erreichbare Instanz aus dem Internet nehmen. Orchestrierungs-Hosts sind besonders attraktive Ziele, weil sie die Schlüssel zu allem halten, was sie automatisieren – das gehört in dieselbe Dringlichkeitsstufe wie Ihr Incident Response im Bereich Cloud und DevOps.
Worin die Lücke genau besteht
Kestra ist ein ereignisgesteuerter Open-Source-Orchestrator, mit dem Teams Datenpipelines und Automatisierungs-Workflows bauen und planen – ein Werkzeug, das unauffällig in der Mitte einer Datenplattform sitzt und alles andere anstößt. Wie viele solcher Tools wird es mit aktivierter Basic Auth ausgeliefert und mit genau einem öffentlichen Endpunkt, der Instanzkonfiguration, die ohne Login erreichbar sein soll. Der Fehler liegt darin, wie diese Ausnahme durchgesetzt wird.
Der AuthenticationFilter entscheidet über die Anmeldepflicht mit request.getPath().endsWith("/configs"). Das ist ein Suffix-Vergleich, kein exakter Pfadabgleich: Ausgenommen ist nicht nur der vorgesehene Endpunkt /configs, sondern jeder API-Pfad, dessen letztes Segment configs lautet. Ein Angreifer muss dieses Segment nur an eine geschützte Route anhängen und ist an der Authentifizierung vorbei. Anschließend kann er einen Kestra-Flow mit Script-Tasks – Shell, Python, Node, Bash – anlegen und ausführen; diese Tasks laufen als root im Linux-Worker-Container. Das ist Remote Code Execution auf dem Orchestrierungs-Host ohne Zugangsdaten und ohne Nutzerinteraktion.
Das Advisory beschreibt außerdem eine Server-Side Request Forgery: Die Funktion http() der Template-Engine Pebble filtert keine URIs, ein präpariertes Template kann also interne Dienste oder den Metadaten-Endpunkt des Cloud-Anbieters aufrufen. Auf einer Cloud-Instanz ist das der direkte Weg zu Instanz-Credentials und lateraler Bewegung. Die Schlagzeile ist der Auth-Bypass mit CVSS 10.0 – aber erst die SSRF macht aus einem kompromittierten Host eine kompromittierte Umgebung.
Warum es immer wieder Orchestrierungsplattformen trifft
Das ist kein isoliertes Kestra-Problem, sondern der jüngste Fall in einer Serie kritischer Lücken in Workflow- und Automatisierungsplattformen. n8n, Langflow, MLflow und ähnliche Tools hatten im vergangenen Jahr allesamt RCE-Fehler ohne Anmeldung oder mit Auth-Bypass. Das Muster ist strukturell: Orchestrierungsplattformen sind dafür gebaut, beliebigen Code auszuführen und alles zu erreichen, was sie automatisieren. Sie sammeln daher zwangsläufig Datenbank-Zugangsdaten, Cloud-Schlüssel, API-Tokens und Zugriff aufs interne Netz. Eine einzige Authentifizierungslücke auf so einem Host bedeutet nicht einen kompromittierten Server, sondern einen Brückenkopf zu den Pipelines, Data Warehouses und Cloud-Konten dahinter.
Außerdem bleiben sie leicht offen stehen. Solche Tools starten als interne Hilfe, bekommen für eine schnelle Demo oder einen Kollegen im Homeoffice eine öffentliche URL und bleiben dann einfach erreichbar. „Führt per Design Code aus“, „hält jedes Secret“ und „manchmal im offenen Internet“ – genau nach diesem Profil scannen Angreifer. Wer eine Datenplattform betreibt, besonders Teams, die schnell Daten- und ML-Pipelines aufbauen, sollte jeden Orchestrator und Automatisierungsserver als Tier-1-Infrastruktur behandeln – denn genau so behandeln ihn Angreifer.
Was das für Teams in der DACH-Region bedeutet
Die unmittelbare Folge ist operativ: Ein KEV-Eintrag mit öffentlichem Proof of Concept heißt, dass die Ausnutzung nicht hypothetisch ist; ungepatchte, aus dem Internet erreichbare Instanzen gelten als kompromittiert. Die CISA-Frist bindet nur US-Bundesbehörden, das Signal „wird jetzt in Angriffen genutzt“ gilt aber für alle. Wer nicht belegen kann, dass die Kestra-Instanz gepatcht war, bevor sie erreichbar wurde, braucht Incident Response statt nur eines Updates: Secrets rotieren und Logs prüfen.
Für regulierte Unternehmen kommt die Compliance-Ebene hinzu. Unter NIS2 und seiner nationalen Umsetzung, unter DORA für Finanzinstitute (Aufsicht durch die BaFin) und in ISO-27001-Audits ist eine bekanntermaßen ausgenutzte Schwachstelle auf einem System mit Zugriff auf Produktionsdaten genau der Befund, dessen Behebung Prüfer in definierter Frist erwarten. Werden über eine kompromittierte Instanz personenbezogene Daten abgegriffen, greift zudem die 72-Stunden-Meldepflicht nach Art. 33 DSGVO gegenüber der zuständigen Datenschutzaufsicht. Gut aus der Sache kommt, wer Inventar, Patch-Nachweis und Protokoll der Credential-Rotation vorlegen kann – nicht, wer Wochen später erst merkt, dass das Tool überhaupt im Bestand war.
Die übergeordnete Lehre betrifft die Lieferkette. Die meisten Teams haben Kestra nicht selbst geschrieben, tragen aber das Risiko des Betriebs. Selbst gehostete Open-Source-Infrastruktur tauscht Vendor-Lock-in gegen die Pflicht, Advisories zu verfolgen und schnell zu patchen. Das ist ein echter Aufwand und gehört ins Budget: Jemand muss das Inventar dessen verantworten, was Sie selbst hosten, die Sicherheitsmeldungen abonnieren und binnen Stunden patchen können, wenn ein CVSS-10.0-Fall auf der KEV-Liste landet.
Was jetzt zu tun ist
Wenn Kestra irgendwo in Ihrem Stack läuft, ist die Reihenfolge wichtiger als die einzelnen Schritte.
- Klären, ob und in welcher Version Kestra läuft. Container-Images, Helm-Charts und selbst gehostete Deployments prüfen; betroffen sind Releases bis einschließlich 1.3.20.
- Sofort aktualisieren. Auf 1.3.21, 1.0.45 oder ein Release ab 1.4.0 wechseln. Einen dauerhaften Workaround, der eine betroffene Version offen lässt, gibt es nicht.
- Aus dem öffentlichen Internet nehmen. Jede erreichbare Instanz hinter VPN oder in ein privates Netz; ein Orchestrator sollte fast nie direkt im Internet stehen.
- Jedes erreichbare Secret rotieren. Datenbank-Zugangsdaten, Cloud-Schlüssel und API-Tokens, die die Instanz erreichen konnte, als kompromittiert behandeln und erneuern – wegen der SSRF auf Cloud-Hosts nicht optional.
- Nach Missbrauch suchen. Logs auf unerwartetes Anlegen oder Ausführen von Flows sowie ausgehende Requests an Metadaten-Endpunkte prüfen, rund um und vor dem Patch-Datum.
- In die Advisory-Überwachung aufnehmen. Diese und alle anderen selbst gehosteten Plattformen in einen beobachteten Feed aufnehmen, damit der nächste KEV-Eintrag nicht überrascht.
Das ist keine Rechtsberatung, und die konkrete Exposition hängt davon ab, wie Kestra bei Ihnen betrieben wird. Die Richtung ist aber eindeutig: Ein Auth-Bypass mit CVSS 10.0 auf einem Host, der Code ausführt und Secrets hält und jetzt auf der KEV-Liste steht, ist ein Heute-patchen-Ereignis – und Teams, die wissen, was sie selbst hosten, schließen ihn in Stunden statt in Wochen.
Häufige Fragen
Was ist CVE-2026-49869 in Kestra?
Ein Authentifizierungs-Bypass mit CVSS 10.0 in Kestra OSS. Der AuthenticationFilter gibt den öffentlichen Konfigurations-Endpunkt per Suffix-Prüfung frei, request.getPath().endsWith("/configs"), statt per exaktem Abgleich. Jeder API-Pfad, dessen letztes Segment configs lautet, umgeht damit die Basic Auth – ein nicht angemeldeter Angreifer erreicht geschützte Endpunkte, legt einen Workflow mit Script-Tasks an und führt ihn als root im Worker-Container aus.
Welche Kestra-Versionen sind betroffen, welche enthalten den Fix?
Betroffen sind Kestra-OSS-Releases bis einschließlich 1.3.20 mit aktivierter Basic Auth, also der Standardkonfiguration. Behoben ist die Lücke in 1.0.45, 1.3.21 und allen Releases ab 1.4.0. Das Update ist die primäre Maßnahme; einen sicheren Workaround, der eine betroffene Version offen lässt, gibt es nicht.
Wird CVE-2026-49869 aktiv ausgenutzt?
Die CISA hat die Lücke am 2. September 2026 in den KEV-Katalog aufgenommen – ihr Signal, dass belastbare Hinweise auf aktive Ausnutzung vorliegen –, mit Frist 5. September für US-Bundesbehörden. Ein öffentlicher Proof of Concept und ein Scanner existieren, daher sollte jede ungepatchte, aus dem Internet erreichbare Instanz bis zum Beweis des Gegenteils als kompromittiert gelten.
Was kann ein Angreifer nach der Ausnutzung tun?
Kestra-Workflows mit Shell-, Python-, Node- oder Bash-Tasks anlegen und ausführen, die als root im Worker-Container laufen – vollständige Remote Code Execution auf dem Orchestrierungs-Host. Über eine zusätzliche SSRF in der Pebble-Funktion http(), die keine URIs filtert, lassen sich Cloud-Metadaten und interne Dienste ansprechen, um Zugangsdaten zu stehlen und sich lateral zu bewegen.
Welche Meldepflichten können in der DACH-Region greifen?
Werden über eine kompromittierte Instanz personenbezogene Daten abgegriffen, ist nach Art. 33 DSGVO binnen 72 Stunden die zuständige Datenschutzaufsicht zu informieren. Für Einrichtungen im Anwendungsbereich von NIS2 kommen Meldepflichten für erhebliche Sicherheitsvorfälle hinzu, für Finanzunternehmen die Vorgaben von DORA. Welche Pflicht konkret greift, hängt von Sektor, Größe und den betroffenen Daten ab.
Was sollten Teams mit Kestra jetzt tun?
Sofort auf 1.3.21, 1.0.45 oder 1.4.0+ aktualisieren. Jede aus dem Internet erreichbare Instanz hinter ein VPN nehmen. Zugangsdaten, Cloud-Schlüssel und Secrets rotieren, die die Instanz erreichen konnte. Danach die Logs auf unerwartetes Anlegen oder Ausführen von Workflows rund um und vor dem Patch-Datum prüfen.
Quellen
Kestra — Offizielles Security Advisory GHSA-5vc5-wxxq-3fjx, CVE-2026-49869 (Primärquelle)
CISA — Known Exploited Vulnerabilities Catalog (Primärquelle)
LinuxSecurity — Kestra critical Linux container RCE flaw exploited, CISA warns