Apache Airflow Google Provider CVE-2026-45361

Exploitation requires (1) the victim to use ComputeEngineSSHHook from apache-airflow-providers-google < 22.0.0 to SSH from an Airflow worker into a Compute Engine VM, (2) the hook to be running with its default AutoAddPolicy host-key behavior (which is the shipped default and remains the default even after the 22.0.0 upgrade unless host_key_policy="reject" is explicitly set), and (3) the attacker to hold an in-path/MitM position on the network path between the worker and the GCE instance - captured by CVSS AC:H. No authentication to Airflow or GCP is required of the attacker (PR:N, UI:N), but exploitation is bounded to deployments whose worker→VM SSH traffic traverses a network the attacker can intercept; purely intra-VPC paths inside a trusted Google network are substantially harder to target.

Signals are mixed and lean toward elevated but not urgent risk. CVSS 8.1 (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H) reflects high confidentiality, integrity, and availability impact with no authentication needed, but AC:H correctly captures that the attacker must already hold an in-path network position between Airflow worker and the GCE VM - a non-trivial prerequisite. EPSS is 0.02% (4th percentile) and SSVC marks Exploitation as none and Automatable as no, while Technical Impact is total; this points to a vulnerability that is severe when exploited but unlikely to be opportunistically attacked at scale. There is no CISA KEV listing and no public exploit identified at time of analysis. The realistic priority is moderate: organizations running Airflow workers on hostile or shared networks, hybrid-cloud egress paths, or environments where GCP traffic transits third-party infrastructure should treat it as urgent, while purely intra-VPC deployments face lower exposure.

An attacker who controls a network hop between the Airflow worker subnet and the Compute Engine target - for example via a compromised on-prem-to-GCP VPN appliance, a malicious peer in a shared transit network, or DNS/ARP poisoning on a co-located worker network - answers the SSH connection, presents their own host key (which Airflow silently accepts via AutoAddPolicy), and proxies the session to the real VM. They can then capture any credentials or secrets pushed by DAG tasks, alter command output, or inject commands executed on the GCE instance. No public proof-of-concept is documented, but the attack is conceptually equivalent to any standard SSH MitM against a client with disabled host-key checking.