CVE-2026-58065 in Airflow
Summary
by MITRE • 07/13/2026
The Apache Airflow Git provider runs its git-over-SSH operations with `StrictHostKeyChecking=no` by default, disabling SSH host-key verification. An attacker who can intercept the network path between an Airflow worker and the Git server can impersonate the server (man-in-the-middle), capturing the SSH deploy key or injecting malicious repository content. Deployments that use the Git DAG bundle or Git provider to clone over SSH with a deploy key are affected. The fix changes the default to verify host keys; upgrade to apache-airflow-providers-git `0.4.1` or later and configure a `known_hosts` file.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/13/2026
The vulnerability in Apache Airflow's Git provider stems from a critical security misconfiguration that disables SSH host key verification during git-over-SSH operations. This flaw exists in the default configuration where the `StrictHostKeyChecking=no` parameter is enabled, effectively removing the cryptographic verification mechanism that ensures the SSH connection is established with the legitimate server. The vulnerability falls under CWE-310, specifically addressing cryptographic weakness in host key validation, and represents a significant risk in environments where network traffic interception is possible. When an attacker can position themselves between the Airflow worker and the Git server, they can execute man-in-the-middle attacks by presenting forged SSH host keys that match the expected fingerprints, thereby compromising the integrity of the deployment pipeline.
The technical implementation of this vulnerability occurs within the Git provider component of Apache Airflow where SSH connections are established using default parameters that prioritize convenience over security. The absence of host key verification creates a scenario where any network traffic between the worker node and the Git server can be intercepted and manipulated by an attacker with network access capabilities. This configuration allows attackers to capture sensitive deployment keys used for authentication, potentially gaining unauthorized access to repositories or injecting malicious code into the DAG files that Airflow executes. The impact is particularly severe for deployments using Git DAG bundles or Git provider functionality with deploy keys, where the compromised SSH connection directly affects the integrity and authenticity of the source code being pulled into the Airflow environment.
The operational consequences of this vulnerability extend beyond simple credential theft to encompass complete supply chain compromise of the Airflow deployment infrastructure. When attackers successfully impersonate Git servers through man-in-the-middle techniques, they can inject malicious code into DAG files that will execute within the Airflow worker processes, potentially leading to data exfiltration, system compromise, or disruption of business operations. The attack vector leverages standard network interception capabilities and aligns with ATT&CK technique T1566 for initial access through spearphishing attachments or links, though in this case the attack occurs at the network layer during legitimate Git operations. Organizations using Airflow with Git provider functionality are particularly vulnerable because the default configuration assumes a trusted network environment, which is often not the case in modern distributed deployments.
Mitigation of this vulnerability requires immediate action to upgrade the apache-airflow-providers-git package to version 0.4.1 or later, which implements proper host key verification by default. The recommended approach involves configuring a proper `known_hosts` file that contains the expected SSH host keys for all Git servers that Airflow connects to, ensuring that only legitimate servers can be authenticated during SSH operations. This fix addresses the root cause by implementing cryptographic verification mechanisms that align with industry best practices for SSH security. Organizations should also implement network-level protections such as SSH key pinning and regular audit of known hosts files to maintain the security posture. The solution adheres to security frameworks that emphasize defense in depth, requiring both configuration changes at the application level and proper network security controls to prevent similar vulnerabilities from occurring in other components of the deployment pipeline.