GPU VulnDB

Database/Control plane, storage & DevOps

Airflow FTP provider: FTPS data channel sent in cleartext because PROT P was never issued

CVSS 7.5CVE-2026-49486Control plane, storage & DevOpscurated

Impact

FTPSHook.get_conn() built an ftplib.FTP_TLS connection but never called prot_p(), so only the control channel was encrypted and every byte of file data crossed the network in the clear. Any DAG using FTPSHook or FTPSFileTransmitOperator therefore exposed file contents and in-transit credentials to anyone able to observe the data connection. On a GPU fleet Airflow is commonly the mover of datasets and model artifacts, so this is passive disclosure of whatever those DAGs transfer, to an attacker who only needs a position on the path. Integrity of the transfer is not affected per the vendor's scoring - the issue is confidentiality.

Who can reach it

A network attacker able to observe the FTPS data connection between the Airflow worker and the FTP server. No authentication to Airflow is required; the attacker needs a vantage point on the traffic path.

What to do

Upgrade apache-airflow-providers-ftp to 3.15.1 or later, which issues PROT P, and restart the Airflow workers and scheduler so the new provider is loaded. Treat any credentials carried over these transfers as exposed and rotate them.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.