CVE-2026-49486: Apache Airflow FTP Provider Disclosure Flaw

CVE-2026-49486 Overview

CVE-2026-49486 affects the Apache Airflow FTP provider, where FTPSHook.get_conn() establishes an ftplib.FTP_TLS connection but never invokes prot_p(). The control channel is encrypted with Transport Layer Security (TLS), but the data channel transmits in cleartext. Any deployment using FTPSHook or FTPSFileTransmitOperator to transfer files over FTPS exposes file contents and credentials-in-transit to network attackers observing the data connection. The issue is tracked under [CWE-319: Cleartext Transmission of Sensitive Information].

Critical Impact
Files and credentials transferred through FTPSFileTransmitOperator traverse the network in cleartext, allowing a passive attacker on the data path to capture sensitive payloads.

Affected Products

apache-airflow-providers-ftp versions prior to 3.15.1
Airflow deployments using FTPSHook for FTPS transfers
Airflow DAGs invoking FTPSFileTransmitOperator

Discovery Timeline

2026-06-26 - CVE-2026-49486 published to NVD
2026-06-26 - Last updated in NVD database

Technical Details for CVE-2026-49486

Vulnerability Analysis

The Apache Airflow FTP provider implements FTPS support through the FTPSHook class. When get_conn() runs, it instantiates an ftplib.FTP_TLS object and completes the TLS handshake for the control channel. FTPS requires an explicit PROT P command to negotiate protection for the data channel. The provider omitted this call, leaving PROT C (clear) in effect for all subsequent data transfers.

An attacker positioned between the Airflow worker and the FTPS server can read every byte of the data channel. Uploaded files, downloaded datasets, and any credentials embedded in transferred content become visible to passive network observers. The control channel remains TLS-protected, so authentication exchanges over the control channel are not directly exposed.

Root Cause

The defect resides in FTPSHook.get_conn(). The method configures TLS for command traffic but never issues prot_p(), which internally sends PROT P to the server. Without that command, ftplib.FTP_TLS defaults to unprotected data connections even after the TLS handshake succeeds on port 21 or the configured control port.

Attack Vector

Exploitation requires network visibility into the data connection between the Airflow worker and the FTPS server. This includes shared network segments, compromised intermediate routers, on-path devices in cloud environments, or misconfigured VPN routes. No authentication or user interaction is required. The attacker performs passive capture of the data channel, then reassembles transferred file contents from the plaintext TCP stream.

The vulnerability mechanism is described in the Apache Mailing List Thread and the corrective GitHub Pull Request.

Detection Methods for CVE-2026-49486

Indicators of Compromise

FTPS data connections from Airflow worker hosts that carry readable ASCII or file magic bytes rather than TLS record headers.
Absence of PROT P commands in FTPS control channel logs captured from Airflow worker sessions.
Installed apache-airflow-providers-ftp package versions earlier than 3.15.1 on scheduler and worker nodes.

Detection Strategies

Inventory Python packages across Airflow environments and flag hosts running apache-airflow-providers-ftp below 3.15.1.
Inspect DAG source code for imports of FTPSHook or references to FTPSFileTransmitOperator to identify exposed workflows.
Capture traffic on egress from Airflow workers to FTPS destinations and verify data channels present TLS handshakes.

Monitoring Recommendations

Alert on FTPS sessions where the data port carries unencrypted payload patterns after a successful control-channel TLS negotiation.
Track outbound connections from Airflow worker IP ranges to FTPS ports (typically 990 or ephemeral PASV ports) and correlate with DAG execution logs.
Log package upgrade events for apache-airflow-providers-ftp in configuration management systems to confirm remediation coverage.

How to Mitigate CVE-2026-49486

Immediate Actions Required

Upgrade apache-airflow-providers-ftp to 3.15.1 or later on every Airflow scheduler, worker, and triggerer node.
Rotate any credentials or API tokens that were transferred through FTPSHook or FTPSFileTransmitOperator while the vulnerable version was deployed.
Audit historical DAG runs to determine which files and secrets traversed the cleartext data channel.

Patch Information

Apache released the fix in apache-airflow-providers-ftp version 3.15.1. The patch modifies FTPSHook.get_conn() to invoke prot_p() after the TLS handshake, forcing PROT P negotiation and encrypting the data channel. Details are available in the GitHub Pull Request and the Openwall OSS Security Post.

Workarounds

Route FTPS traffic through an encrypted tunnel such as an IPsec or WireGuard link between the worker and the FTPS server until the patch is applied.
Replace FTPS transfers with SFTP using the Airflow SSH or SFTP providers where feasible.
Restrict Airflow worker egress to FTPS destinations reachable only over trusted network paths pending upgrade.

bash

# Upgrade the provider package to the fixed release
pip install --upgrade 'apache-airflow-providers-ftp>=3.15.1'

# Verify the installed version
pip show apache-airflow-providers-ftp | grep -i version