CVE-2026-67260

This CVE exposes a structural flaw in Apache Airflow's deserialization security model. Version 3.3.0 introduced the `awaiting_input` state—a scheduler-swept path for human-in-the-loop tasks that avoids the operational overhead of a persistent triggerer process. That feature added a new deserialization entry point into the scheduler that simply wasn't covered by the `allowed_deserialization_classes` allow-list mechanism that guards deserialization elsewhere in the codebase. The vulnerability isn't that the security control doesn't exist; it's that the new code path was added without extending the control to cover it. This is a pattern vulnerability: feature development outpaced security boundary mapping. The relationship to CVE-2026-58076 is analytically significant. That earlier CVE patched an unguarded deserialization path through exception nodes—a different call site reaching the same underlying function. The existence of two separate CVEs covering adjacent code paths reveals that security review of the deserialization surface was reactive and path-specific rather than systematic. The version control history is damning: when `awaiting_input` was added as greenfield code, the new deserialization handler simply didn't reference the existing `allowed_deserialization_classes` mechanism. A diff-based security review at commit time would have caught this in seconds. The 15-second scheduler sweep amplifies the risk significantly. Every task instance in `awaiting_input` state continuously exercises this path—hundreds of times per hour per instance—rather than a one-shot exploitation. The scheduler also runs at higher privilege than task workers, so successful exploitation enables privilege escalation within the Airflow architecture, not just arbitrary code execution in an individual task context. The two-CVE-in-sequence pattern strongly predicts more unguarded entry points exist. The underlying condition—a guardrail applied locally rather than enforced architecturally—hasn't been fixed, only patched for these two call sites. The upgrade to 3.3.1 addresses both paths, but any new feature added without explicitly referencing the allow-list mechanism will likely produce another CVE. Organizations running 3.3.0 should treat the gap between CVE-2026-58076 and this CVE as a period of overlapping exposure: the first patch created a false assurance window during which this adjacent vulnerability was already live in deployments. For defenders, prioritize the 3.3.1 upgrade. In multi-tenant or sandboxed deployments where task execution isolation is the primary trust boundary, this warrants higher urgency than in single-tenant environments where DAG authors are already fully trusted. The most effective audit strategy is static analysis identifying all `next_kwargs` access points that don't pass through the allow-list check—methodology that found these two will find more.

Reviewed through automated stages and approved by a human before publication.