CVE-2026-41017: Apache Airflow JWT Cookie Secure Flag Bypass

Technical summary

The JWTRefreshMiddleware in Apache Airflow creates authentication cookies without setting the Secure flag, which instructs browsers to only transmit the cookie over encrypted channels. In deployments where TLS termination occurs at a front-end proxy (nginx, Envoy, AWS ALB, etc.) with plaintext HTTP forwarding to the backend Airflow service, the middleware's cookie handling becomes the session integrity boundary. An attacker positioned to observe network traffic—such as on a Wi-Fi network or within an ISP/datacenter lateral segment—can trick a logged-in user's browser into making an unencrypted HTTP request to the Airflow hostname (via DNS spoofing, ARP injection, or browser-based redirects), capture the session JWT in that request, and use it to authenticate subsequent API calls. The impact is bounded to confidentiality; the attacker can read API data but cannot modify it via this vector alone.

Business impact

Session hijacking of Airflow users could allow unauthorized access to orchestration metadata, task history, variable secrets, and potential lateral movement into connected systems if Airflow's service account is broadly permissioned. The risk is heightened in organizations where Airflow coordinates sensitive data pipelines or has cross-cloud/multi-tenant access. Compliance frameworks (SOC 2, HIPAA, PCI-DSS) expect session cookies to be Secure-flagged in web applications; this gap could surface in audit findings. For organizations already using end-to-end encryption or non-proxy Airflow deployments, the practical risk is low, but teams should verify their architecture matches one of the safe patterns before dismissing the vulnerability.

Affected systems

Apache Airflow versions prior to 3.2.2. The vulnerability is active only when the Airflow API server is accessed through a TLS-terminating reverse proxy that forwards requests as plaintext HTTP to Airflow—the de facto standard topology in Kubernetes, AWS ECS, and other cloud-native environments. Self-hosted Airflow instances without a proxy, or those with end-to-end TLS between proxy and API server, are unaffected. The vulnerability affects the Airflow API server; Airflow schedulers, workers, and web UIs are not directly targeted.

Exploitability

Exploitation requires network-layer positioning (Wi-Fi MITM, compromised corporate network, or ISP visibility) and relies on inducing a user to make an unencrypted HTTP request to the Airflow domain. Practical exploitation is non-trivial for an attacker without pre-existing network presence, but the threat model is realistic in public Wi-Fi, shared hosting, and zero-trust network microsegmentation scenarios. The CVSS score of 5.9 (Medium) reflects the requirement for both network access and specific deployment topology; organizations in air-gapped or tightly segmented networks face lower practical risk.

Remediation

Upgrade Apache Airflow to version 3.2.2 or later, which patches the JWTRefreshMiddleware to set the Secure flag on all authentication cookies. For teams unable to patch immediately, mitigations include enforcing HTTPS-only access at the reverse proxy level (reject plaintext HTTP), implementing HSTS headers, and ensuring DNS security (DNSSEC/DNS pinning) to reduce the surface for inducing HTTP requests. These controls do not address the root cause but reduce exploitability.

Patch guidance

Apply Apache Airflow 3.2.2 or later to all API server instances. The patch is backward-compatible; no configuration changes are required. After patching, verify that the `Set-Cookie` header in API responses includes `Secure` and `HttpOnly` flags via browser developer tools or HTTP traffic inspection. Consider rolling updates in a canary pattern if Airflow is part of a critical workflow, though the patch is low-risk.

Detection guidance

Monitor for HTTP requests (not HTTPS) to Airflow API endpoints; legitimate traffic should be HTTPS-only behind a properly configured reverse proxy. Log analysis of reverse proxy access logs can reveal non-HTTPS requests to the API path. If SIEM integration is in place, create rules for successful API authentication attempts immediately preceded by HTTP requests to the same hostname. Network visibility tools (packet capture, flow analytics) can detect DNS redirections or ARP spoofing attempts that might precede exploitation, though these are also indicators of broader network compromise.

Why prioritize this

This is a Medium-severity vulnerability with a context-dependent risk profile. Organizations using cloud-native reverse proxy topologies (the majority) should prioritize patching, but teams with alternate architectures can deprioritize after confirming their setup. It does not appear on the CISA Known Exploited Vulnerabilities (KEV) list, indicating no widespread active exploitation as of the last update. Patch in the next standard maintenance window; do not treat as a critical emergency unless you confirm your deployment uses a TLS-terminating proxy.

Risk score, explained

The CVSS 3.1 score of 5.9 (Medium, vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) balances a high-confidentiality impact (H) with a high attack complexity (H) due to the requirement for network positioning and a specific deployment topology. No user interaction is needed (UI:N) and the attack is network-reachable (AV:N), but the combination of AC:H and the architectural prerequisite prevents a higher rating. Organizations not using the affected topology can lower the effective score for their environment.

Frequently asked questions