CVE-2026-94134 in Airflow SSH Provider
Summary
by MITRE • 10/16/2026
The Apache Airflow SSH provider hook disables SSH host-key verification by default: unless `host_key` is configured or `no_host_key_check` is explicitly set to false, it accepts any server key. This affects SSH and SFTP connections that rely on the default. An attacker in a machine-in-the-middle position between the worker and the SSH or SFTP server can impersonate the server and capture the credentials or data a task sends.
Users of apache-airflow-providers-ssh and apache-airflow-providers-sftp are recommended to upgrade to apache-airflow-providers-ssh 7.0.0 and apache-airflow-providers-sftp 7.0.0 or later. The deferrable SFTP code paths had the same default and are covered separately by CVE-2026-94135; apache-airflow-providers-sftp 7.0.0 fixes both.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The Apache Airflow SSH provider hook contains a critical security misconfiguration that disables Secure Shell host-key verification by default, creating a significant vulnerability for organizations relying on remote server connections. In standard secure communications protocols such as SSH and SFTP, the client must verify the identity of the remote server to ensure it is communicating with the intended entity rather than an imposter. This process typically involves checking the server's public key against a known list of trusted keys or accepting them interactively upon first connection. However, in versions prior to 7.0.0 of apache-airflow-providers-ssh and apache-airflow-providers-sftp, the hook defaults to accepting any host key presented by the remote server unless specific configuration parameters are explicitly set to enforce verification. This default behavior effectively nullifies one of the primary defenses against identity spoofing in network communications, leaving the integrity of the connection entirely dependent on user diligence rather than enforced security controls.
This architectural flaw exposes users to severe machine-in-the-middle attacks where an adversary positioned between the Airflow worker and the target SSH or SFTP server can intercept and manipulate traffic without detection. By presenting a fraudulent host key that matches no pre-existing trust anchor, the attacker can successfully impersonate the legitimate server. Once this deception is established, all data transmitted during the session, including sensitive credentials, authentication tokens, and proprietary business logic executed by Airflow tasks, becomes visible to the adversary. The attacker can also inject malicious commands or alter output data before it reaches the worker node, compromising both confidentiality and integrity of the pipeline execution environment. This risk applies broadly to any workflow that utilizes these providers for remote file transfers or command execution without explicit hardening configurations.
The vulnerability is categorized under CWE-295 Improper Certificate Validation, as the system fails to properly validate the authenticity of the server's cryptographic identity. From a tactical perspective aligned with MITRE ATT&CK techniques, this flaw facilitates Man-in-the-Middle attacks (T1048) and allows for Credential Access through interception of unencrypted or improperly authenticated sessions. The impact is particularly acute in automated environments where interactive prompts are not available to alert operators to certificate changes, meaning the connection proceeds silently despite being compromised. This lack of automatic verification means that even well-intentioned administrators may inadvertently deploy insecure configurations if they do not explicitly override the default settings, leading to widespread exposure across enterprise data pipelines.
To mitigate this risk, organizations must immediately upgrade apache-airflow-providers-ssh and apache-airflow-providers-sftp to version 7.0.0 or later, which corrects these defaults by enforcing stricter host-key verification policies out of the box. For environments that cannot yet upgrade, administrators should manually configure the hooks to require specific known hosts keys via the host_key parameter or explicitly set no_host_key_check to false if using older versions where such options are available but disabled by default. It is also recommended to implement network-level controls such as firewalls and intrusion detection systems to limit exposure to internal threats that could exploit this vulnerability. Additionally, reviewing existing DAGs for any hardcoded SSH connections ensures that all operational workflows adhere to the principle of least privilege and secure defaults before deploying new changes.