Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Attacker needs an on-path or passive position to observe the data channel, so AC:H; confidentiality-only impact (files and credentials), with no integrity or availability effect.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
6DescriptionCVE.org
The Apache Airflow FTP provider's FTPSHook.get_conn() created an ftplib.FTP_TLS connection but never called prot_p(), so although the control channel was TLS-protected the data channel was transmitted in cleartext. Any deployment using FTPSHook or FTPSFileTransmitOperator to move files over FTPS exposed file contents and credentials-in-transit to a network attacker able to observe the data connection. Upgrade apache-airflow-providers-ftp to 3.15.1 or later, which issues PROT P to encrypt the data channel.
Articles & Coverage 1
AnalysisAI
Cleartext data-channel exposure in the Apache Airflow FTP provider (apache-airflow-providers-ftp before 3.15.1) lets a network attacker positioned on the data path read file contents and credentials moved over FTPS. The FTPSHook.get_conn() method established an ftplib.FTP_TLS control connection but never issued PROT P, so payloads transferred via FTPSHook or FTPSFileTransmitOperator traveled in plaintext despite the TLS-protected control channel. There is no public exploit identified at time of analysis, EPSS is very low (0.10%, 1st percentile), and it is not on CISA KEV.
Technical ContextAI
The flaw lives in Python's ftplib FTPS workflow. FTP_TLS protects the control connection automatically, but the separate data connection (used for actual file transfers and directory listings) remains in cleartext until the client explicitly calls prot_p(), which sends the PROT P command to negotiate data-channel encryption. The Airflow FTP provider's FTPSHook.get_conn() omitted this call, leaving every data transfer unencrypted. This is a textbook CWE-319 (Cleartext Transmission of Sensitive Information) root cause, confirmed by the PR diff (apache/airflow#67946) which adds self.conn.prot_p() plus a regression test asserting prot_p is called exactly once. The single affected component is cpe:2.3:a:apache_software_foundation:apache_airflow_ftp_provider.
RemediationAI
Vendor-released patch: 3.15.1 - upgrade apache-airflow-providers-ftp to 3.15.1 or later, which issues PROT P to encrypt the data channel (fix in https://github.com/apache/airflow/pull/67946 ; advisory https://lists.apache.org/thread/gwnsxlt9hfj5pc543wxtogbnjdn04xj1 ). If immediate upgrade is not possible, restrict FTPS transfers to trusted, segmented network paths (for example a private VLAN or a VPN tunnel between the Airflow worker and the FTPS server) so the cleartext data connection cannot be observed, accepting the operational overhead of maintaining those network controls; alternatively migrate the affected DAGs to SFTP via SSHHook/SFTPOperator, which encrypts the full session, noting this requires reconfiguring connections and that the remote endpoint must support SSH. Avoid moving sensitive files over FTPS until patched.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-39627
GHSA-fgch-86x8-fv43