External risk intelligence

Apache Airflow SSH Provider Defaults to Insecure Host Key Verification

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-94134

The vulnerability exists in a backend workflow provider component used for SSH/SFTP connections initiated by orchestration tasks. While network-reachable during task execution, these connections typically occur between internal infrastructure components (e.g., workers and internal servers) rather than being directly exposed to or originating from the public internet.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security issue has been identified in the SSH provider for Apache Airflow, which by default accepts any server key for SSH and SFTP connections. This could allow an attacker to impersonate servers and intercept credentials or data transmitted through these connections.

Default SSH connections can be impersonated.
Protects sensitive data in transit over SSH.
Verify provider configurations for SSH/SFTP.

Attack Path

How an attacker could exploit the issue

An attacker positioned between an Apache Airflow worker and an SSH or SFTP server can impersonate the server. This is possible because the SSH provider hook, by default, does not verify the server's host key. This allows the attacker to intercept sensitive information or credentials transmitted during task execution.

Network access required.
SSH/SFTP connection is intercepted.
Credentials and data can be stolen.

Live Threat

Current exploitation, exposure, and threat context

When the SSH provider hook's default host-key verification is left unchanged, an attacker in a man-in-the-middle position could impersonate the SSH or SFTP server. This could lead to the interception of credentials or data transmitted by tasks.

Task credentials and data could be at risk.
Man-in-the-middle attackers could impersonate servers.
Interception of sensitive information may occur.

Operational Fix

Recommended remediation, mitigation, and detection steps

Real-world remediation likely falls to the platform or infrastructure teams managing Apache Airflow, with coordination from application owners who utilize the affected SSH/SFTP connections. The immediate first step is to inventory where the Airflow SSH and SFTP providers are deployed and to determine if these connections are exposed externally or used for critical internal processes. Once identified, the accountable owner should be confirmed, followed by a risk-based remediation plan that may involve upgrades during scheduled maintenance or temporary compensating controls.

Platform and application owners should lead.
Verify SSH/SFTP connection exposure and criticality.
Plan upgrades or implement security controls.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Apache Airflow SSH provider?

The SSH provider is a component within Apache Airflow, an open-source platform used to programmatically author, schedule, and monitor workflows. This specific provider allows Airflow tasks to connect to remote systems via SSH or SFTP to execute commands or transfer files as part of automated data pipelines.

What is the vulnerability in CVE-2026-94134?

This vulnerability involves a weakness categorized as CWE-322: Key Exchange without Authentication. Essentially, the software defaults to trusting any server it connects to, skipping the crucial security check that verifies the remote server's identity. This allows an attacker to intercept the connection.

How can an attacker trigger this vulnerability?

An attacker must be positioned in the network path between the Airflow worker and the destination SSH or SFTP server. If the connection is not configured to manually verify keys, the attacker can impersonate the target server. Simply using the default provider settings triggers the risk, whereas explicitly configuring a host key or setting the verification flag prevents it.

Do I need to worry if my Airflow instance is internal?

Halo Surface Signal indicates that while the vulnerability is network-reachable, these connections typically occur between internal infrastructure components. If your Airflow workers only talk to trusted internal servers, the risk is lower than if they connect across untrusted network segments, though secure internal practices are still vital.

How do I secure my environment against this?

Begin by inventorying all workflows that utilize the SSH or SFTP providers to identify where these connections exist. The most effective step is to upgrade to version 7.0.0 or later of the apache-airflow-providers-ssh and apache-airflow-providers-sftp packages to receive the patched defaults.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.