CVE-2026-41017: Apache Airflow Auth Bypass Vulnerability

CVE-2026-41017 Overview

CVE-2026-41017 affects Apache Airflow's JWTRefreshMiddleware, which sets the JSON Web Token (JWT) authentication cookie without the Secure flag. Deployments running the Airflow API server behind a TLS-terminating reverse proxy (nginx, Envoy, or managed load balancer) replay the user's session JWT over any cleartext HTTP request to the same host. A network-positioned attacker on hostile Wi-Fi, a shared LAN, or a captive-portal proxy can trigger a logged-in user's browser to issue an HTTP request to the deployment hostname and capture the cookie. The attacker then replays the token against the authenticated API. The issue is tracked under CWE-614 (Sensitive Cookie Without Secure Attribute).

Critical Impact
Session JWT cookies can be intercepted over cleartext HTTP and replayed to fully impersonate authenticated Airflow users against the API.

Affected Products

Apache Airflow versions prior to 3.2.2
Cloud-native Airflow deployments behind TLS-terminating reverse proxies (nginx, Envoy)
Managed Airflow services where load balancers terminate TLS and forward plaintext HTTP to the API server

Discovery Timeline

2026-06-01 - CVE-2026-41017 published to NVD
2026-06-02 - Last updated in NVD database

Technical Details for CVE-2026-41017

Vulnerability Analysis

Apache Airflow's API server issues a JWT through the JWTRefreshMiddleware component. The middleware sets the authentication cookie without the Secure attribute. The browser therefore attaches the cookie to any request matching the host and path scope, regardless of whether the scheme is HTTPS or HTTP.

In production topologies, a TLS-terminating proxy decrypts client traffic and forwards plaintext HTTP to the Airflow API server. The application has no signal that the front-end transport was encrypted, and it does not enforce the Secure flag to compensate. As a result, the secure-by-default cookie protection that normally prevents transport downgrade is absent.

An attacker who can observe network traffic between a victim browser and the deployment hostname can read the JWT verbatim. Possession of the JWT grants full API access at the privilege level of the targeted user until the token expires.

Root Cause

The root cause is a missing cookie attribute. The JWTRefreshMiddleware constructs the Set-Cookie response header without including Secure, violating CWE-614. The middleware also does not detect HTTPS via standard forwarded headers (X-Forwarded-Proto) to set the attribute conditionally.

Attack Vector

Exploitation requires a network-positioned adversary and a logged-in victim. The attacker induces the victim's browser to issue an HTTP request to the Airflow hostname, for example through an http:// image tag, redirect, or captive portal injection. The browser attaches the JWT cookie to the cleartext request. The attacker captures the request on the wire and replays the bearer token against the authenticated API endpoints.

The vulnerability mechanism is described in the Apache mailing list advisory and addressed in the upstream pull request #65348. No public proof-of-concept exploit is currently available.

Detection Methods for CVE-2026-41017

Indicators of Compromise

Authenticated Airflow API requests originating from IP addresses or User-Agent strings that do not match the legitimate user's session history
Repeated use of the same JWT from multiple geographic source IPs within the token's validity window
HTTP (port 80) requests reaching the deployment hostname carrying Cookie headers with Airflow JWT values
API activity outside normal user working hours or against DAGs the user does not typically interact with

Detection Strategies

Inspect proxy access logs for plaintext HTTP requests to the Airflow hostname that include session cookies in the request headers
Correlate JWT identifiers (jti claim) with source IP addresses to identify token reuse across distinct network origins
Audit reverse proxy configuration to confirm whether HTTP listeners exist on the same hostname as the HTTPS-terminated Airflow API

Monitoring Recommendations

Forward nginx, Envoy, or load balancer access logs to a centralized analytics platform and alert on any HTTP traffic to the Airflow virtual host
Track Airflow audit events for sensitive operations (DAG triggers, connection edits, variable changes) and baseline them per user
Enable HTTP Strict Transport Security (HSTS) and monitor browsers' compliance through Content Security Policy reporting endpoints

How to Mitigate CVE-2026-41017

Immediate Actions Required

Upgrade apache-airflow to version 3.2.2 or later, which sets the Secure flag on the JWT cookie
Force HTTPS at the reverse proxy by redirecting all port 80 traffic to port 443 and enabling HSTS with a long max-age
Invalidate existing JWT sessions after upgrade so that any tokens previously transmitted over downgrade-capable channels cannot be replayed
Rotate any service credentials or connection secrets accessed during the exposure window

Patch Information

The fix is delivered in Apache Airflow 3.2.2. The change adds the Secure attribute to the Set-Cookie header produced by JWTRefreshMiddleware. Review the upstream pull request #65348 and the Apache security thread for commit-level detail. Additional context is available in the OpenWall OSS-Security update.

Workarounds

Configure the reverse proxy to strip or block any inbound cleartext HTTP requests to the Airflow hostname before they reach a browser
Add HSTS headers with includeSubDomains and preload so compliant browsers refuse to send cookies over HTTP
Restrict the Airflow API server to listen only on internal interfaces and require client traffic to traverse the TLS-terminating proxy
If upgrade is not immediately possible, deploy a proxy rewrite rule that appends Secure to outbound Set-Cookie headers for the JWT cookie

bash

# nginx workaround: enforce HSTS and append Secure to JWT cookies
server {
    listen 443 ssl http2;
    server_name airflow.example.com;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    proxy_cookie_flags _airflow_session secure samesite=lax;
    proxy_cookie_flags jwt_refresh secure samesite=lax;

    location / {
        proxy_pass http://airflow-api-upstream;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host $host;
    }
}

server {
    listen 80;
    server_name airflow.example.com;
    return 301 https://$host$request_uri;
}