Kurzfassung

Apache Airflow weist mit CVE-2026-86473 eine kritische Schwachstelle im Logout-Verhalten der Core API auf. Der CVSS-Basiswert liegt bei 9.1 und damit im kritischen Bereich: Bei API-Zugriffen per Bearer-Token wird ein Logout zwar bestätigt, das verwendete Token aber nicht tatsächlich widerrufen. Betroffen sind vor allem automatisierte Clients und Integrationen; empfohlen wird ein Update auf Apache Airflow 3.3.2 oder neuer.

Was ist passiert?

Der Fehler steckt im Logout-Endpunkt der Core API von Apache Airflow. Airflow widerruft dort nur ein Sitzungstoken, das als Cookie mit dem Namen _token übermittelt wird. Meldet sich ein Client dagegen mit einem Bearer-Token im Authorization-Header ab, liefert die API zwar die übliche Logout-Antwort zurück, entzieht dem Token aber nicht die Gültigkeit.

Das hat praktische Folgen: Wer bereits eine Kopie eines gültigen Tokens besitzt, kann den Zugriff weiter nutzen, obwohl sich das eigentliche Opfer abgemeldet hat und von einem beendeten Zugriff ausgeht. Nach Herstellerangaben beträgt die Standardlaufzeit eines solchen Tokens 24 Stunden; sie lässt sich konfigurieren.

Technische Details

CVE-2026-86473 ist mit CVSS 3.1 und 9.1 Punkten bewertet, Vektor: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Das bedeutet: Ein Angriff ist über das Netzwerk möglich, mit geringer Komplexität, ohne vorherige Anmeldung und ohne Mitwirkung des Opfers; der Wert beschreibt die technische Schwere der Schwachstelle, nicht automatisch eine bereits beobachtete Ausnutzung in freier Wildbahn.

In der Sache handelt es sich nicht um einen klassischen Token-Diebstahl, sondern um einen Fehler beim Entzug der Gültigkeit. Voraussetzung für einen Missbrauch ist, dass ein Angreifer bereits im Besitz eines gültigen Bearer-Tokens ist. Die Schwachstelle selbst verschafft dieses Token nicht und erweitert auch keine Rechte über das Berechtigungsniveau des betroffenen Nutzers hinaus. Kritisch ist sie trotzdem, weil sie ein zentrales Sicherheitsversprechen des Logout-Prozesses unterläuft.

Nicht betroffen ist nach der Beschreibung das normale Abmelden über das Browser-Cookie, sofern die Sitzung über den _token-Cookie geführt wird. Das Problem betrifft gezielt API-Clients, die sich per Bearer-Token authentifizieren.

Wer ist betroffen?

Betroffen sind Airflow-Umgebungen, in denen die Core API mit Bearer-Tokens genutzt wird. Das ist vor allem in Integrationen mit internen Tools, Automatisierungsplattformen, CI/CD-Strecken, Data-Engineering-Workflows und eigenen Skripten relevant.

Für viele Unternehmen im DACH-Raum ist das Risiko vor allem dort hoch, wo Airflow nicht nur intern von Administratoren bedient wird, sondern API-Zugänge an Dienste, Entwicklerteams oder externe Prozesse vergeben wurden. Weniger relevant ist die Schwachstelle in Installationen, die ausschließlich über Browser-Sitzungen arbeiten und keine Bearer-Token für API-Zugriffe einsetzen.

Als behobene Version nennt Apache Airflow 3.3.2 oder neuer. Ob ältere Wartungszweige ebenfalls Korrekturen erhalten, ist nicht mitgeteilt.

Empfohlene Maßnahmen

Erstens: Aktualisieren Sie Apache Airflow zeitnah auf Version 3.3.2 oder neuer. Das ist die zentrale Abhilfemaßnahme.

Zweitens: Prüfen Sie, ob in Ihrer Umgebung überhaupt Bearer-Tokens für die Core API im Einsatz sind. Inventarisieren Sie dazu Integrationen, Service-Konten, Skripte und externe Clients, die den Authorization-Header verwenden.

Drittens: Behandeln Sie bereits ausgegebene Tokens als potenziell weiter gültig, auch wenn sich Nutzer abgemeldet haben. Wo organisatorisch möglich, sollten Sie betroffene Tokens neu ausstellen oder rotieren und verdächtige Sitzungen serverseitig beenden.

Viertens: Verkürzen Sie die Token-Laufzeit, falls Ihre Betriebsprozesse das zulassen. Da die Standardlaufzeit 24 Stunden beträgt, senkt ein kürzeres Zeitfenster das Missbrauchsrisiko deutlich.

Fünftens: Überwachen Sie API-Zugriffe auf ungewöhnliche Nutzung nach Logout-Ereignissen. Besonders relevant sind fortgesetzte Requests mit bereits bekannten Bearer-Tokens aus neuen Quelladressen, abweichenden Zeiten oder ungewohnten Arbeitsabläufen.

Sechstens: Überprüfen Sie, wie Bearer-Tokens in Ihrer Umgebung gespeichert und verteilt werden. Die Schwachstelle setzt einen bereits erfolgten Token-Abfluss voraus. Logs, Debug-Ausgaben, Proxy-Systeme, Chat-Nachrichten, Ticket-Systeme oder ungeschützte Secrets-Stores sind typische Fundstellen für unbeabsichtigte Offenlegung.

Einschätzung von CyberSecurity-News.de

Die CVSS-Bewertung von 9.1 wirkt auf den ersten Blick drastisch, muss hier aber sauber eingeordnet werden. Für einen erfolgreichen Missbrauch braucht ein Angreifer bereits ein gültiges Token. Das reduziert die praktische Angriffsfläche gegenüber Schwachstellen, die ohne weitere Vorbedingungen direkt zur Übernahme führen.

Trotzdem ist das Problem für produktive Airflow-Installationen keineswegs harmlos. In modernen Datenplattformen laufen viele automatisierte API-Zugriffe, Service-Konten und Skripte. Genau dort fällt ein fehlerhafter Logout oft spät auf, weil niemand aktiv bemerkt, dass ein Token nach einer vermeintlichen Abmeldung weiter funktioniert.

Die Informationslage ist insgesamt brauchbar: Betroffene Nutzung, Standardlaufzeit und behobene Version sind benannt. Was fehlt, sind weitergehende Angaben zu eventuell zusätzlich abgesicherten Workarounds für Umgebungen, die nicht sofort auf 3.3.2 aktualisieren können. Für Unternehmen zählt deshalb vor allem die eigene Betriebsrealität: Wer Bearer-Tokens breit einsetzt, sollte priorisiert handeln; reine Browser-Nutzung ist deutlich weniger kritisch.

Fazit

Wenn Sie Apache Airflow mit Bearer-Token-Zugriffen auf die Core API betreiben, sollten Sie das Update auf 3.3.2 oder neuer kurzfristig einplanen. Parallel lohnt sich eine Prüfung aller ausgegebenen Tokens und ihrer Laufzeiten. Ohne Bearer-Token-Einsatz ist die Relevanz für die meisten Leser dagegen begrenzt.

Quellenangabe

Weiterführende Informationen: NVD-Eintrag zu CVE-2026-86473