Apache Software Foundation Apache Airflow · Public exploit code

PoC published for Apache Airflow scheduler deserialization flaw

Nov 10, 2026 · 1 min read

The Apache Airflow scheduler fully deserializes XCom values written by task code when evaluating task dependencies (CVE-2026-86829). A DAG author therefore controls data deserialized inside the scheduler process, a context the Airflow security model reserves for trusted code. With a PoC published, review who can author DAGs in your environment and watch for a vendor fix.

By HIFY Radar newsroom Updated 11/10/2026 11:29 AM Get this every day →← Back to the feed 1 source

HighVulnerabilityPublic exploit codeFix unconfirmed

In 30 seconds

Observed

A proof of concept has surfaced for CVE-2026-86829, a flaw in Apache Airflow, the open source platform teams use to schedule and orchestrate data pipelines. The security feed ptdbugs announced that a PoC or exploit has been discovered, and a public GitHub repository now hosts code for the bug, tracked internally as PT-2026-140320.

Alleged

According to the advisory text circulated with the report, Airflow's scheduler fully deserializes XCom values, the small data objects tasks use to pass information to each other, while it evaluates task dependencies. That hands a DAG author, meaning anyone allowed to write workflow definitions, control over data deserialized inside the scheduler process, a zone the Airflow security model reserves for trusted code. The stated remedy is an upgrade to Airflow 3.4.0 or later.

What happened

Observed

The paper trail in this batch starts with a vulnerability entry on the dbu.gs tracker, PT-2026-140320, covering a deserialization flaw in Apache Airflow from the Apache Software Foundation and mapped to CVE-2026-86829.

Observed

Alongside that entry, ptdbugs posted on X that a PoC or exploit for the CVE had been discovered and linked to a public repository, googlesky/cve-2026-86829 on GitHub, which hosts code for the bug. The advisory text distributed in the same post explains the mechanics: the scheduler fully deserializes XCom values written by task code during dependency evaluation, so a DAG author controls data deserialized in the scheduler process, a context the Airflow security model reserves for code installed by the Deployment Manager.

Why it matters

Inferred

The core problem is a trust boundary collapse. Airflow's security model assumes two distinct roles: the Deployment Manager, who installs trusted code on the scheduler, and DAG authors, whose capabilities are documented as scoped to workers. By writing to XCom, a DAG author effectively reaches into the scheduler's own process, a privilege the model never intended them to have.

Alleged

A public PoC turns that theoretical boundary violation into a concrete attack path to study or abuse. The advisory text notes two conditions must line up for impact: the deployment must treat DAG authors as less trusted than Deployment Managers, a common arrangement on multi-team data platforms, and the scheduler must be evaluating a task dependency that reads a task-written XCom value.

What to do

Observed

The advisory's recommendation is direct: upgrade to apache-airflow 3.4.0 or later. That version restricts dependency evaluation to primitive XCom values, plain data like strings and numbers rather than arbitrary objects, which closes the channel the flaw relies on.

Inferred

If an immediate upgrade is not feasible, the next best lever is permission review: check who can author DAGs in your environment and whether that trust level matches what the deployment actually assumes. The advisory frames DAG authorship as the permission to scrutinize in affected setups.

Confirmed and still uncertain

Observed

What is established in this batch: the flaw description, the affected product (Apache Airflow), the CVE identifier (CVE-2026-86829), the tracking ID (PT-2026-140320), the fix version (3.4.0), and the existence of a public PoC repository.

Inferred

What remains unverified: whether the PoC code actually executes against a live scheduler, whether anyone has exploited the flaw in the wild, and exactly which Airflow versions before 3.4.0 are vulnerable, since the advisory text available here does not spell out an affected version range. Those gaps should be closed against Apache's own advisory before operational decisions.

What people are saying

Observed

Commentary is thin so far and centers on ptdbugs, a bug tracking feed on X, which announced the PoC and circulated the full advisory text. Its post states plainly that a PoC or exploit has been discovered for CVE-2026-86829 and recommends upgrading to version 3.4.0 or later.

Observed

The PoC itself sits in a GitHub repository under the account googlesky, with no accompanying commentary or claims from the repository publisher captured in this batch, so the advisory language from ptdbugs is the only narrative voice on record.

Evolution

Inferred

The batch reads as a single snapshot rather than a timeline: the dbu.gs tracker entry, the GitHub PoC repository, and the ptdbugs announcement all appear in the same evidence window, meaning the transition from private disclosure to public exploit code cannot be dated from this data alone.

Inferred

One detail suggests the disclosure was already mature when the PoC surfaced: the fix, version 3.4.0 with dependency evaluation restricted to primitive XCom values, was available and recommended at the time of the announcement.

Reach

Observed

2 independent groups, 1 updates, and 1 engagements.

Technical detail

Alleged

The technical root, per the advisory: Airflow tasks exchange data through XCom, and when the scheduler evaluates task dependencies it fully deserializes XCom values that task code wrote. A DAG author controls what a task writes to XCom, and therefore controls the data deserialized inside the scheduler process, a context the security model reserves for code installed by the Deployment Manager, above the worker-scoped capability DAG authors are documented to have.

Inferred

The fix in 3.4.0 restricts dependency evaluation to primitive XCom values, removing arbitrary objects from the scheduler's deserialization path. Exploitation requires the scheduler to be evaluating a dependency that reads a task-written XCom value, and the issue matters where DAG authors are treated as less trusted than Deployment Managers. Note that the advisory text does not name the exact deserialization sink or the impact, so any remote code execution framing is inference, not documented fact.

Sources and evidence

Observed

This story rests on three artifacts: the dbu.gs vulnerability entry for PT-2026-140320 (primary), the GitHub repository googlesky/cve-2026-86829 hosting the PoC (primary), and a post from ptdbugs on X (discussion) that carries the full advisory text quoted throughout this report. The two RSS entries arrived without body text, so every advisory detail here traces back to the ptdbugs post.

Inferred

Because the advisory text reaches us through a third-party feed rather than Apache's own advisory page, version-specific details beyond the 3.4.0 fix recommendation should be rechecked against the upstream source before being used for patching or risk decisions.