📄 Apache Airflow Databricks Provider Certificate Verification Bypass

# CVE-2026-32794: TLS Certificate Verification Bypass in Apache Airflow Databricks Provider
    
    [![CVE](https://img.shields.io/badge/CVE--2026--32794-orange)](https://www.cve.org/CVERecord?id=CVE-2026-32794)
    [![Platform](https://img.shields.io/badge/Platform-pip-blue)](https://pypi.org/project/apache-airflow-providers-databricks/)
    [![CWE](https://img.shields.io/badge/CWE--295-Improper%20Certificate%20Validation-purple)](https://cwe.mitre.org/data/definitions/295.html)
    
    **Keywords:** TLS, certificate verification, MITM, Kubernetes, Databricks, OAuth, CWE-295, Apache Airflow
    
    ---
    
    ## Table of Contents
    
    - [Overview](#overview)
    - [Vulnerability Details](#vulnerability-details)
    - [Technical Analysis](#technical-analysis)
    - [Attack Chain](#attack-chain)
    - [Impact](#impact)
    - [Remediation](#remediation)
    - [Timeline](#timeline)
    - [References](#references)
    - [Contact](#contact)
    - [Disclaimer](#disclaimer)
    
    ---
    
    ## Overview
    
    The [apache-airflow-providers-databricks](https://github.com/apache/airflow) package disables TLS certificate verification when communicating with the Kubernetes API server during federated token exchange. Both the synchronous and asynchronous code paths use `verify=False` / `ssl=False`, allowing any attacker with network access within the K8s cluster to MITM the connection and steal both the in-cluster service account JWT and the Databricks OAuth token.
    
    The code comments claim "K8s in-cluster uses self-signed certs," but this is incorrect. Kubernetes provides a CA bundle at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` specifically for this purpose.
    
    ---
    
    ## Vulnerability Details
    
    | Field | Value |
    |-------|-------|
    | **CVE** | [CVE-2026-32794](https://www.cve.org/CVERecord?id=CVE-2026-32794) |
    | **CWE** | [CWE-295: Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) |
    | **Package** | apache-airflow-providers-databricks (pip) |
    | **Affected Versions** | All versions with K8s token exchange |
    | **Patched Version** | Pending ([PR #63704](https://github.com/apache/airflow/pull/63704)) |
    | **Component** | `providers/databricks/src/airflow/providers/databricks/hooks/databricks_base.py` |
    
    ---
    
    ## Technical Analysis
    
    ### Vulnerable Code
    
    **Line 699 (sync path) - `_get_k8s_token_request_api()`:**
    
    ```python
    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,
    )
    ```
    
    **Line 764 (async path) - `_a_get_k8s_token_request_api()`:**
    
    ```python
    async with self._session.post(
        token_request_url,
        ...
        ssl=False,  # K8s in-cluster uses self-signed certs
    )
    ```
    
    ### The Core Issue
    
    The comment says "K8s in-cluster uses self-signed certs" but Kubernetes provides a trusted CA bundle at a well-known path. The correct approach is to use that CA bundle for verification rather than disabling TLS entirely.
    
    ### Secure Pattern
    
    ```python
    K8S_CA_CERT_PATH = "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
    
    # Sync
    resp = requests.post(token_request_url, ..., verify=K8S_CA_CERT_PATH)
    
    # Async
    ssl_ctx = ssl.create_default_context(cafile=K8S_CA_CERT_PATH)
    async with self._session.post(token_request_url, ..., ssl=ssl_ctx)
    ```
    
    ---
    
    ## Attack Chain
    
    ```
    +----------------------------------------------------------+
    |  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     |
    +----------------------------------------------------------+
    ```
    
    ---
    
    ## Impact
    
    | Aspect | Description |
    |--------|-------------|
    | **Direct Impact** | MITM interception of K8s JWT and Databricks OAuth tokens |
    | **Attack Surface** | Any pod within the same cluster network |
    | **Credential Theft** | Both K8s service account and Databricks tokens exposed |
    | **Lateral Movement** | Stolen tokens enable access to both K8s API and Databricks workspace |
    | **Affected Users** | Any Airflow deployment using Databricks provider with K8s token exchange |
    
    ---
    
    ## Remediation
    
    **Fix PR:** [apache/airflow#63704](https://github.com/apache/airflow/pull/63704)
    
    The fix replaces `verify=False` with `verify=K8S_CA_CERT_PATH` using the standard Kubernetes in-cluster CA bundle, and replaces `ssl=False` with a properly configured SSL context.
    
    ---
    
    ## Timeline
    
    | Date | Event |
    |------|-------|
    | 2026-03-15 | Vulnerability reported to [email protected] |
    | 2026-03-15 | Jarek Potiuk (Airflow committer) acknowledged the report |
    | 2026-03-16 | CVE-2026-32794 allocated; fix PR #63704 opened |
    
    ---
    
    ## References
    
    - [CVE-2026-32794](https://www.cve.org/CVERecord?id=CVE-2026-32794)
    - [Fix PR: apache/airflow#63704](https://github.com/apache/airflow/pull/63704)
    - [CWE-295: Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html)
    - [Apache Airflow Security Policy](https://github.com/apache/airflow/security/policy)
    
    ---
    
    ## Contact
    
    - **Website:** [snailsploit.com](https://snailsploit.com)
    - **GitHub:** [@SnailSploit](https://github.com/SnailSploit)
    - **LinkedIn:** [/in/kaiaizen](https://linkedin.com/in/kaiaizen)
    
    ---
    
    ## Disclaimer
    
    This advisory is published for educational and defensive purposes under responsible disclosure principles. The information provided is intended to help developers and security teams understand and remediate the vulnerability. Do not use this information for unauthorized testing or malicious purposes.
    
    <!-- snailsploit-backlink:start -->
    
    ---
    
    ## 📚 Documentation & Author
    
    This project's full writeup, methodology, and related research lives at:
    
    **[https://snailsploit.com/cves](https://snailsploit.com/cves)**
    
    Created by **Kai Aizen** — independent offensive security researcher.
    
    [snailsploit.com](https://snailsploit.com) · [Research](https://snailsploit.com/research) · [Frameworks](https://snailsploit.com/frameworks) · [GitHub](https://github.com/SnailSploit) · [LinkedIn](https://linkedin.com/in/kaiaizen) · [ResearchGate](https://www.researchgate.net/profile/Kai-Aizen-2) · [X/Twitter](https://x.com/SnailSploit)
    
    > *Same attack. Different substrate.*
    
    <!-- snailsploit-backlink:end -->