Airflow Git Provider CVE-2026-58065
HIGHSeverity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
On-path MITM position gives AC:H; no auth or interaction needed (PR:N/UI:N); stolen deploy key and injected DAG code yield full C/I/A impact.
Primary rating from Vendor (apache).
CVSS VectorNVD
Lifecycle Timeline
6DescriptionNVD
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.
AnalysisAI
Man-in-the-middle interception of Apache Airflow's Git provider (apache-airflow-providers-git before 0.4.1) is possible because git-over-SSH operations run with StrictHostKeyChecking=no by default, so no SSH host-key verification occurs. An attacker positioned on the network path between an Airflow worker and its Git server can impersonate the server to steal the SSH deploy key or inject malicious DAG content, leading to code execution on workers. No public exploit identified at time of analysis, and it is not listed in CISA KEV; CVSS is 8.1 (High) driven by high attack complexity (AC:H) requiring an on-path position.
Technical ContextAI
The affected component is the Git provider/Git DAG bundle in Apache Airflow, which clones repositories over SSH using a configured deploy key to source DAG definitions. The GitHook set the SSH option strict_host_key_checking to 'no' by default, disabling the client's known_hosts verification so any presented host key is accepted. This is a CWE-322 (Key Exchange Without Entity Authentication) weakness: because the endpoint's identity is never authenticated, the SSH client cannot distinguish the legitimate Git server from an impersonator. CPE cpe:2.3:a:apache_software_foundation:apache_airflow_git_provider identifies the provider package as the affected product. The PR (apache/airflow#69103) changes the default to 'accept-new' (trust-on-first-use with pinning thereafter), adds support for 'yes'/'accept-new'/'off'/'ask', emits a deprecation warning when the default is relied upon over SSH, and signals a future major release will default to 'yes'.
RemediationAI
Vendor-released patch: upgrade to apache-airflow-providers-git 0.4.1 or later, which changes the default strict_host_key_checking to 'accept-new'. As a hardening step, configure a known_hosts_file and set strict_host_key_checking explicitly to 'yes' in the Git connection extra so the Git server's host key must be pre-provisioned and verified up front (the strongest setting, though it requires managing known_hosts and will break clones if the server key legitimately rotates without an update). If you cannot upgrade immediately, set strict_host_key_checking to 'accept-new' or 'yes' in the connection extra and supply a known_hosts_file entry for your Git host as a compensating control, and additionally restrict/segment the network path between Airflow workers and the Git server so an attacker cannot occupy an on-path position. Details are in the Apache advisory (https://lists.apache.org/thread/fjmclngfksz2kp7llpcjxzdz568h0zhc) and PR https://github.com/apache/airflow/pull/69103.
Same weakness CWE-322 – Key Exchange without Entity Authentication
View allSame technique Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today