Between 16 September and 15 October 2026, Apache Airflow published advisories for four provider packages that most data teams run: SSH and SFTP, Apache Kafka, Snowflake and Teradata. None of them is a classic internet-facing bug. They all hinge on what a connection record is allowed to do, and who can edit it.
If your Airflow has a small group of trusted admins, several of these are low risk. If connections are editable by many users, read on.
What's affected
| CVE | Package | Affected | Fixed in | NVD score |
|---|---|---|---|---|
| CVE-2026-94134 | providers-ssh, providers-sftp | Hooks that rely on the default host key setting | ssh 7.0.0, sftp 7.0.0 | 9.1 |
| CVE-2026-94135 | providers-sftp | Deferrable SFTP triggers and async hook | sftp 7.0.0 | 4.3 |
| CVE-2026-86792 | providers-apache-kafka | 1.15.0 before 2.0.0, event producer enabled | 2.0.0 | 8.8 |
| CVE-2026-81930 | providers-snowflake | account and region not validated | 6.18.0 | 6.3 |
| CVE-2026-81862 | providers-teradata | S3 and Azure Blob to Teradata operators | 3.7.0 | 6.5 |
SSH and SFTP. Per the advisory, the SSH hook disables host key verification unless host_key is set or no_host_key_check is explicitly false. An attacker between the worker and the server can impersonate it and capture credentials or data. The deferrable SFTP paths had the same default, so sftp 7.0.0 fixes both CVEs.
Kafka. The provider turns dotted path strings in a connection's extra field into Python callables with import_string and no allowlist. When the Kafka event producer is enabled (dag_run_events_enabled or task_instance_events_enabled, both off by default), the client is built inside the scheduler. A user who can only edit connections then gets code execution in the control plane. The advisory says Google Managed Kafka is not affected, while plain brokers and Amazon MSK are.
Snowflake. An account value containing a slash, question mark or hash changes the host of the SQL API request. The request carries a bearer token minted from the connection's credentials. A user who can edit the connection but not read its secrets can get a valid token sent to a host they control.
Teradata. Without a teradata_authorization_name, the two transfer operators inline cloud storage credentials into the SQL statement. For S3, runtime credentials land in the Airflow task log. For both operators, they also land in Teradata's DBQL query logs.
How to check if you're exposed
List the provider versions and look at your connections:
pip list 2>/dev/null | grep -E "apache-airflow-providers-(ssh|sftp|apache-kafka|snowflake|teradata)"
airflow connections list | grep -Ei "ssh|sftp|kafka|snowflake|teradata"
For SSH and SFTP, open each connection and look for no_host_key_check in the extra field. If it is missing, you are on the default.
For Kafka, check whether the event producer is on:
grep -rnE "dag_run_events_enabled|task_instance_events_enabled" "$AIRFLOW_HOME/airflow.cfg"
env | grep -E "DAG_RUN_EVENTS_ENABLED|TASK_INSTANCE_EVENTS_ENABLED"
If neither setting is turned on anywhere, you are on the defaults, and the scheduler route in CVE-2026-86792 is closed. Also check who holds the permission to edit connections, because that is the attacker's only requirement.
For Teradata, search task logs for CREATE MULTISET TABLE statements that contain a key or token.
What to do now
- Upgrade the five packages to the fixed versions above. All are provider packages, so no Airflow core upgrade is needed for these.
- Set host_key on every SSH and SFTP connection, or set no_host_key_check to false, so you are not relying on the default even after the upgrade.
- Restrict who can edit connections. Treat that permission as equivalent to code execution until Kafka and Snowflake are patched.
- For Teradata, create an AUTHORIZATION object and set teradata_authorization_name. The advisory says upgrading does not remove credentials already written to Teradata query logs, so rotate any credentials used through the inline path.
- Clear or restrict old task logs from the Teradata operators.
Why it matters
Airflow's security model gives connection editors less power than DAG authors. The Kafka bug breaks that boundary: connection settings crossed into the scheduler process. The Snowflake bug does the same for secrets, since write-only access to a connection should not let someone obtain its token.
The SSH case is a reminder that insecure defaults outlive their authors. Host key checking off by default means every pipeline that never set it was open to a machine in the middle.
Quick check
Your scheduler has both Kafka event settings off. Does CVE-2026-86792 give code execution in the scheduler?
Not through this route. The advisory ties scheduler execution to the event producer settings being enabled. Upgrade anyway, and keep connection edit rights narrow.
