CVE-2026-32794: Umgehung der TLS-Zertifikatsprüfung im Apache Airflow Databricks Provider

Keywords: TLS, certificate verification, MITM, Kubernetes, Databricks, OAuth, CWE-295, Apache Airflow

Inhaltsverzeichnis

• Übersicht
• Schwachstellendetails
• Technische Analyse
• Angriffskette
• Auswirkungen
• Abhilfe
• Zeitplan
• Referenzen
• Kontakt
• Haftungsausschluss

Übersicht

Das Paket apache-airflow-providers-databricks deaktiviert die TLS-Zertifikatsprüfung bei der Kommunikation mit dem Kubernetes-API-Server während des föderierten Token-Austauschs. Sowohl der synchrone als auch der asynchrone Codepfad verwenden verify=False / ssl=False, sodass jeder Angreifer mit Netzwerkzugriff innerhalb des K8s-Clusters die Verbindung MITM-angreifen und sowohl das In-Cluster-Servicekonto-JWT als auch das Databricks-OAuth-Token stehlen kann.

Die Code-Kommentare behaupten: "K8s in-cluster uses self-signed certs", aber das ist falsch. Kubernetes stellt ein CA-Bundle unter /var/run/secrets/kubernetes.io/serviceaccount/ca.crt speziell für diesen Zweck bereit.

Schwachstellendetails

Technische Analyse

Anfälliger Code

Zeile 699 (synchroner Pfad) - _get_k8s_token_request_api():

resp = requests.post(
    token_request_url,
    headers={
        "Authorization": f"Bearer {in_cluster_token}",
        "Content-Type": "application/json",
    },
    json=self._build_k8s_token_request_payload(audience, expiration_seconds),
    verify=False,  # K8s in-cluster uses self-signed certs
    timeout=self.token_timeout_seconds,
)

Zeile 764 (asynchroner Pfad) - _a_get_k8s_token_request_api():

async with self._session.post(
    token_request_url,
    ...
    ssl=False,  # K8s in-cluster uses self-signed certs
)

Das Kernproblem

Der Kommentar besagt: "K8s in-cluster uses self-signed certs", aber Kubernetes stellt ein vertrauenswürdiges CA-Bundle unter einem bekannten Pfad bereit. Der korrekte Ansatz ist, dieses CA-Bundle zur Verifizierung zu verwenden, anstatt TLS vollständig zu deaktivieren.

Sicheres Muster

K8S_CA_CERT_PATH = "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"

# Synchron
resp = requests.post(token_request_url, ..., verify=K8S_CA_CERT_PATH)

# Asynchron
ssl_ctx = ssl.create_default_context(cafile=K8S_CA_CERT_PATH)
async with self._session.post(token_request_url, ..., ssl=ssl_ctx)

Angriffskette

+----------------------------------------------------------+
|  1. ATTACKER GAINS POD ACCESS                            |
|     Compromised container or network namespace access     |
+---------------------------+------------------------------+
                            |
                            v
+----------------------------------------------------------+
|  2. MITM THE TOKEN EXCHANGE                              |
|     ARP spoof / DNS hijack within cluster network         |
|     Serve self-signed cert (accepted due to verify=False) |
+---------------------------+------------------------------+
                            |
                            v
+----------------------------------------------------------+
|  3. INTERCEPT CREDENTIALS                                |
|     - K8s service account JWT (Authorization header)      |
|     - Databricks OAuth token (response body)              |
+---------------------------+------------------------------+
                            |
                            v
+----------------------------------------------------------+
|  4. LATERAL MOVEMENT                                     |
|     Use stolen tokens for K8s API + Databricks access     |
+----------------------------------------------------------+

Auswirkungen

Abhilfe

Fix-PR: apache/airflow#63704

Der Fix ersetzt verify=False durch verify=K8S_CA_CERT_PATH unter Verwendung des standardmäßigen Kubernetes-In-Cluster-CA-Bundles und ersetzt ssl=False durch einen ordnungsgemäß konfigurierten SSL-Kontext.

Zeitplan

Referenzen

• CVE-2026-32794
• Fix-PR: apache/airflow#63704
• CWE-295: Unzureichende Zertifikatsvalidierung
• Apache Airflow Sicherheitsrichtlinie

Kontakt

• Webseite: snailsploit.com
• GitHub: @SnailSploit
• LinkedIn: /in/kaiaizen

Haftungsausschluss

Dieses Advisory wird zu Bildungs- und Verteidigungszwecken im Rahmen der Grundsätze der verantwortungsvollen Offenlegung veröffentlicht. Die bereitgestellten Informationen sollen Entwickler und Sicherheitsteams dabei unterstützen, die Schwachstelle zu verstehen und zu beheben. Verwenden Sie diese Informationen nicht für unbefugte Tests oder schädliche Zwecke.

📚 Dokumentation & Autor

Die vollständige Dokumentation, Methodik und verwandte Forschung zu diesem Projekt finden Sie unter:

https://snailsploit.com/cves

Erstellt von Kai Aizen — unabhängiger Offensiv-Sicherheitsforscher.

snailsploit.com · Research · Frameworks · GitHub · LinkedIn · ResearchGate · X/Twitter

Gleicher Angriff. Anderes Substrat.