Vulnerability Details
CVE-2026-94134 – SSH hook default, both providers
CVE-2026-94135 – Async SFTP path
Severity: High – CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-322 (Key Exchange without Entity Authentication)
Affected packages: apache-airflow-providers-ssh and apache-airflow-providers-sftp – both through version 6.0.1
Fixed in: apache-airflow-providers-ssh 7.0.0 (CVE-2026-94134), apache-airflow-providers-sftp 7.0.0 (CVE-2026-94135)
Overview
OX Security Research discovered that Apache Airflow disables SSH host key verification by default in its SSH and SFTP providers, leaving connections vulnerable to man-in-the-middle (MITM) attacks.
The issue affects both synchronous SSH/SFTP connections and Airflow’s asynchronous SFTP path and has been assigned two High-severity CVEs: CVE-2026-94134 and CVE-2026-94135.
With Airflow’s default configuration, an attacker positioned between an Airflow worker and the target server can present their own key and have the connection accepted without error. The attacker can then intercept the session, capture credentials, inject command output, modify transferred files, or redirect data to attacker-controlled storage.
The problem is the default. Users do not have to disable host key verification to become vulnerable. Unless they explicitly configure Airflow otherwise, verification is already disabled.
What Is Apache Airflow
Apache Airflow is the standard open-source workflow orchestration platform. Data engineering teams use it to schedule and run pipelines that move data between databases, cloud storage, APIs, and remote servers. That is often hundreds of jobs per day.
The SSH and SFTP providers sit at the center of how Airflow reaches remote systems: SSHOperator runs shell commands on production servers, while SFTPOperator transfers files in ETL pipelines. Compromising one of these connections is not limited to what Airflow itself can do; it gives an attacker a position inside every data flow that connection participates in.
The Vulnerability
SSH server authentication works by storing a server’s public key the first time you connect, then comparing it on every future connection. If the keys differ, the connection is rejected. That’s how MITM attacks are caught. Without this check, an attacker who intercepts the TCP connection can present their own key, decrypt everything, and forward it transparently.
Paramiko (Python’s SSH library, used by Airflow) provides three host-key policies: RejectPolicy (secure, matches OpenSSH defaults), WarningPolicy (insecure but leaves a trace), and AutoAddPolicy (accepts any key silently). Airflow defaults to AutoAddPolicy.
SSH: Host Key Verification Disabled by Default
apache-airflow-providers-ssh – SSHHook.__init__ hardcodes no_host_key_check = True before reading any connection config. In get_conn(), this triggers AutoAddPolicy and writes a warning to the task log after the connection is already open:
The # nosec B507 comment suppresses Bandit’s MITM warning without fixing the behavior.
apache-airflow-providers-sftp – SFTPHook resolves no_host_key_check from the connection Extra field.
When the field is absent (the default for any new SFTP connection), the expression True if nhkc_raw is None evaluates to True, setting known_hosts = “none”, which disables all verification:
The only signal in both cases is a log warning written after the insecure connection is established, invisible to anyone not actively reading task logs.
CVE-2026-94135 – Async SFTP Path (apache-airflow-providers-sftp): SFTPHookAsync, SFTPTrigger, and SFTPClientPool use asyncssh rather than paramiko, but share the same insecure default.
When no_host_key_check is not explicitly set, these classes pass known_hosts=None to asyncssh, which disables all host key verification on the async code path.
Deferrable SFTP operators that trigger async execution are affected independently of the sync hook issue covered by CVE-2026-94134.
Attack Flow
- An Airflow pipeline task triggers an SSH or SFTP connection with default configuration.
- An attacker positioned on the network path between the Airflow worker and the target server intercepts the TCP connection. Realistic positions include ARP spoofing on a shared subnet, a compromised network device, cloud VPC routing manipulation, or BGP hijacking for internet-facing targets.
- The attacker presents their own RSA key pair instead of the legitimate server’s key.
- SSHHook calls paramiko.AutoAddPolicy() – or SFTPHook sets known_hosts=”none” – and the connection succeeds without error. No alert appears in the Airflow UI.
- The attacker now controls both sides of the session and can read credentials, inject command output, modify transferred files, or redirect data to attacker-controlled storage. Captured credentials (passwords or private keys stored in Airflow connections) can be used directly against the target server, independent of Airflow.
Proof of Concept
The PoC starts a fake SSH server with a freshly generated RSA key and connects using AutoAddPolicy – the exact policy SSHHook applies by default. The connection succeeds with no error.
Requirements: pip install paramiko
See the POC in this GitHub repository.
Expected output:
The SFTP-specific condition that disables verification requires no dependencies:
Impact
SSH and SFTP connections in Airflow typically carry service account credentials with shell access to production servers. A MITM attacker who intercepts one session captures those credentials and can use them directly – independent of Airflow – to access the target server.
For SFTP pipelines feeding databases or data warehouses, an attacker can inject modified file content into a transfer. The tainted data propagates downstream before any anomaly is detected, if it ever is.
The severity is compounded by how invisible the default behavior is. The Airflow connection form gives no indication that host key checking is disabled. The only signal is a log warning written after the insecure connection is already open, in a task log that most operators never read. Organizations running Airflow at scale with dozens or hundreds of SSH and SFTP connections are almost certainly running all of them with verification disabled.
Remediation
Upgrade to the fixed versions:
pip install “apache-airflow-providers-ssh>=7.0.0”
pip install “apache-airflow-providers-sftp>=7.0.0”
Interim mitigation – Explicitly opt into secure behavior on every existing SSH and SFTP connection. In the Airflow UI, edit each connection’s Extra field:
Get the correct host_key value:
Setting no_host_key_check=false without providing host_key will cause connections to fail. This is the correct secure behavior.
Detect affected connections – Search task logs for the warning string that marks every connection running with verification disabled:
Post-compromise – If interception is suspected: rotate all credentials in affected connections, audit target server access logs for unexpected sessions, and review SFTP-transferred files for unexpected modifications.
References
- Fix PR: apache/airflow#73419 – Verify SSH host keys by default
- apache-airflow-providers-ssh on PyPI
- apache-airflow-providers-sftp on PyPI
- Apache Airflow Security Policy
- CWE-322: Key Exchange without Entity Authentication
- paramiko AutoAddPolicy documentation
- CVE-2026-94134, CVE-2026-94135 – reserved, publishes with the advisory
