osbytes

Search

Find posts, projects, and members.

← back to blog

Airflow's May 31 CVE batch: patch-path holes in the 3.2 line

2026-05-31by@osbytes7 min read
#security #apache #airflow #cve #coordinated-disclosure #rbac #python

TL;DR

  • oss-security on 2026-05-31 carries sixteen new Apache Airflow advisories (plus one unrelated ActiveMQ item). Floor for fixes: apache-airflow 3.2.2 (PyPI, release tag from 2026-05-29).
  • Treat 3.2.0 and 3.2.1 as the danger band unless you are already on 3.2.2+ and have redeployed API, scheduler, triggerer, and workers together.
  • Highest-signal items for operators: CVE-2026-45360 (scheduler-side arbitrary import from DAG-serialized deadline references) and CVE-2026-42359 (authenticated XCom PATCH bypass that can reach the triggerer).
  • Recurring pattern: earlier CVEs got a POST-path or shallow-depth fix; today's IDs call out the leftover route (PATCH, deep JSON nesting, log JWT checks, partitioned UI endpoints).

What landed today

Rahul Vats posted a coordinated Airflow advisory set to oss-security this morning (UTC). The messages are individual CVE records, not a single rollup page, but they share one remediation line: upgrade to apache-airflow 3.2.2 or later.

If you upgraded to 3.2.2 when it hit PyPI on May 29 because of SMTP STARTTLS behavior or triggerer deadlock fixes, you may already have the code. Today's batch is still worth reading: it names which 3.2.x assumptions were wrong and which earlier fixes were incomplete.

Airflow 3.2.0 shipped JWT auth docs, multi-team isolation, and a stricter API default-deny story. The May 31 list is mostly proof that authorization and redaction were still route-specific in ways a deployment manager cannot infer from the marketing release notes alone.

Fix bypasses, not a fresh bug class

Several advisories say explicitly that an earlier patch did not cover every entry point.

CVE-2026-42359 (medium) is the clearest example. A prior fix for reserved XCom keys (CVE-2026-33858) added FORBIDDEN_XCOM_KEYS validation on the POST/set path only. The PATCH endpoint PATCH /api/v2/xcomEntries/{key} skipped the same validator. An authenticated user with XCom write permission on a DAG could still write under reserved keys (for example return_value) and supply serialized shapes the triggerer treats as code, leading to RCE on the triggerer when a deferred task resumes. The advisory scopes this to deployments where untrusted users have XCom write on Dags that defer.

CVE-2026-42358 and CVE-2026-42360 extend the same theme for secrets in Variables and rendered templates: nested password / token / api_key fields can leak when masking hits a depth limit or when [core] max_templated_field_length forces stringify-before-redact. Both reference earlier masking CVEs (CVE-2026-32690, CVE-2025-68438) and say the deep-nesting or truncation path was still open until 3.2.2.

If your runbook only said "we took the 3.2.0 security release," these are the receipts that partial upgrades leave partial exposure.

Scheduler trust: DAG author is not a guest

CVE-2026-45360 (high) is the other headline. SerializedCustomReference.deserialize_reference on the scheduler would import_string(...) any class path embedded in DAG-author-controlled serialized state, with a live SQLAlchemy session attached. On typical single-host layouts where the scheduler imports the DAG bundle, a DAG author who is "just writing workflows" can instantiate attacker-chosen code in the scheduler process.

3.2.2 also changes product behavior here: custom DeadlineReference subclasses must register through AirflowPlugin.deadline_references (release notes), matching how custom timetables are gated. That is the structural fix behind the CVE.

RBAC and logs: small functions, wrong semantics

A cluster of low-severity IDs are still worth a permission audit:

  • CVE-2026-45426: log-server JWT checks used Python str.lstrip() on DAG id path segments. lstrip strips any leading character from a set, not a prefix, so a JWT issued for dag_a could authorize logs for names like aaaa_target that share the character class {d,a,g,_}. The 3.2.2 changelog lists removeprefix for log path extraction (#66749).
  • CVE-2026-41014, CVE-2026-40963, CVE-2026-41084: UI/API routes that enforced asset-level or bulk mutation checks without per-DAG scoping, so a user with broad Asset read or a narrow write primitive could see or change other teams' DAG data.
  • CVE-2026-40861: symlink following in FileTaskHandler when worker log dirs are shared with the API server (read arbitrary files readable to the API process, or write outside base_log_folder via .. in task_id).

CVE-2026-42252 is documentation-driven: the official "pass conf into BashOperator" example lacked shell-quoting guidance, so multi-team deployments that grant Dag.can_trigger copied a pattern where dag_run.conf becomes shell metacharacters on the worker. The fix is corrected docs in 3.2.2 (#64129); you still need to grep your DAGs for the old pattern.

What to do on a real deployment

  1. Upgrade every Airflow component to 3.2.2+ (API, scheduler, triggerer, workers, dag processor). Split-version fleets are how PATCH-path and triggerer bugs survive "we patched the chart."
  2. Re-read trust boundaries for 3.2.x multi-team: who can trigger Dags, write XCom, import chatflows, or author deadline references? If DAG authors are semi-trusted, CVE-2026-45360 is not a low-priority item.
  3. Separate worker and API log volumes if you cannot upgrade immediately (CVE-2026-40861 defense in depth).
  4. Audit shared-worker log JWT exposure after upgrade; pre-fix cross-DAG log read via CVE-2026-45426 may have left task output in attacker-visible logs.

Same mailing-list day also published CVE-2026-49270 for Apache ActiveMQ (unauthenticated durable-subscription metadata leak when syncDurableSubs is enabled on a network connector). Different product, same "check the oss-security index" reminder.

Sources