Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2026-32794 — CVE-2026-32794: TLS Certificate Verification Bypass in Apache Airflow Databricks Provider | Kitploit
Tools/GitHubGitHub/snailsploit/cve-2026-32794
Vulnerability AnalysisCloud SecuritySupply Chain SecurityPapers & ResearchMisconfigurationLearning & Education
GitHubsnailsploit/cve-2026-32794

CVE-2026-32794

CVE-2026-32794: TLS Certificate Verification Bypass in Apache Airflow Databricks Provider

View Repository
54 months agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

CVE-2026-32794: TLS Certificate Verification Bypass in Apache Airflow Databricks Provider

CVE Platform CWE

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


Table of Contents

  • Overview
  • Vulnerability Details
  • Technical Analysis
  • Attack Chain
  • Impact
  • Remediation
  • Timeline
  • References
  • Contact
  • Disclaimer

Overview

The apache-airflow-providers-databricks 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

FieldValue
CVECVE-2026-32794
CWECWE-295: Improper Certificate Validation
Packageapache-airflow-providers-databricks (pip)
Affected VersionsAll versions with K8s token exchange
Patched VersionPending (PR #63704)
Componentproviders/databricks/src/airflow/providers/databricks/hooks/databricks_base.py

Technical Analysis

Vulnerable Code

Line 699 (sync path) - _get_k8s_token_request_api():

root@kitploit:~
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():

root@kitploit:~
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

root@kitploit:~
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

root@kitploit:~
+----------------------------------------------------------+
|  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

AspectDescription
Direct ImpactMITM interception of K8s JWT and Databricks OAuth tokens
Attack SurfaceAny pod within the same cluster network
Credential TheftBoth K8s service account and Databricks tokens exposed
Lateral MovementStolen tokens enable access to both K8s API and Databricks workspace
Affected UsersAny Airflow deployment using Databricks provider with K8s token exchange

Remediation

Fix PR: apache/airflow#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

DateEvent
2026-03-15Vulnerability reported to [email protected]
2026-03-15Jarek Potiuk (Airflow committer) acknowledged the report
2026-03-16CVE-2026-32794 allocated; fix PR #63704 opened

References

  • CVE-2026-32794
  • Fix PR: apache/airflow#63704
  • CWE-295: Improper Certificate Validation
  • Apache Airflow Security Policy

Contact

  • Website: snailsploit.com
  • GitHub: @SnailSploit
  • LinkedIn: /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.


📚 Documentation & Author

This project's full writeup, methodology, and related research lives at:

https://snailsploit.com/cves

Created by Kai Aizen — independent offensive security researcher.

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

Same attack. Different substrate.

Download Tool