CVE-2026-33264: Verified Repro With Script Download

Apache Airflow before 3.3.0 deserializes attacker-controlled serialized DAG fields with BaseSerialization.deserialize() without sufficiently constraining class-path imports. In the reproduced path, a malicious serialized DAG contains a __type="base_trigger" value whose class path points to an attacker-controlled module. When the real Airflow API server handles a UI endpoint that loads the serialized DAG (/ui/grid/structure/{dag_id}), Airflow 3.2.2 reaches SerializedDagModel.dag -> DagSerialization.from_dict -> BaseSerialization.deserialize() and calls import_string() on that class path, executing module-level code inside the API server process. Airflow 3.3.0 no longer imports the same base_trigger payload and fails closed without executing the attacker module.

• Package/component affected: apache-airflow, specifically serialized DAG deserialization in airflow.serialization.serialized_objects.BaseSerialization as reached by API server/UI serialized DAG loading.
• Affected versions: Apache Airflow before 3.3.0, reproduced here with Airflow 3.2.2.
• Fixed version: Apache Airflow 3.3.0.
• Risk level and consequences: critical/important security-boundary violation. A DAG author who can cause malicious serialized DAG data to be loaded can execute Python code in the Scheduler/API Server process, not merely in an isolated task execution context. This can expose scheduler/API credentials, metadata database access, local files, and any privileges available to those Airflow control-plane processes.

Impact Parity

• Disclosed/claimed maximum impact: code execution in Scheduler/API Server through unrestricted class-path import during serialized DAG deserialization.
• Reproduced impact from this run: code execution in the real Airflow API server process. The proof module writes api_server_rce_marker.txt at import time and records the API server PID. The vulnerable endpoint returns HTTP 200 after deserializing the DAG, and the marker content shows it was written by the API server process.
• Parity: full.
• Not demonstrated: the proof stops at controlled file creation rather than running a shell command or exfiltrating secrets. This is sufficient to demonstrate arbitrary Python module import-time code execution, but no post-exploitation chain was attempted.

Root Cause

In Airflow 3.2.2, BaseSerialization.deserialize() contains a DAT.BASE_TRIGGER case that deserializes (trigger_class_path, kwargs), calls import_string(trigger_class_path), and instantiates the returned class. The serialized class path is attacker-controlled serialized DAG data. When a server-side process such as the API server loads serialized DAG rows from the metadata database, decorated DAG fields are passed through BaseSerialization.deserialize(), allowing the import to occur in the API server process.

The reproduction stores a malicious serialized DAG with dag.default_args = {"__type": "base_trigger", "__var": ["evil_trigger_module.EvilTrigger", ...]}. Airflow 3.2.2 accepts this type and imports evil_trigger_module, whose module-level code writes a marker file. Airflow 3.3.0 rejects the historical base_trigger type during deserialization and therefore does not import the attacker module.

Known fix references from the advisory:

• https://github.com/apache/airflow/pull/66002
• https://github.com/apache/airflow/pull/68528

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh.
2. The script:
   • Reuses the prepared project cache at <project_cache_dir>/repo when available.
   • Uses/reuses an Airflow 3.2.2 virtualenv for the vulnerable product and an Airflow 3.3.0 virtualenv for the fixed control.
   • For each attempt, initializes a fresh Airflow metadata database, creates an attacker-controlled module in the DAG folder, and seeds a serialized DAG row containing a malicious base_trigger serialized value.
   • Starts the real airflow api-server on localhost, waits for /api/v2/monitor/health, then sends an HTTP request to /ui/grid/structure/{dag_id}?offset=0&limit=100.
   • Runs two vulnerable attempts and two fixed attempts.
3. Expected evidence of reproduction:
   • Airflow 3.2.2 attempts: HTTP endpoint is reached, returns 200, and api_server_rce_marker.txt is created with import-time code execution in Airflow API server; pid=<api-server-pid>.
   • Airflow 3.3.0 attempts: HTTP endpoint is reached but returns a deserialization error (HTTP 500) and no marker file is created.

Evidence

Primary runtime evidence is written under bundle/logs/ and bundle/artifacts/ by bundle/repro/reproduction_steps.sh.

Key files:

• bundle/logs/reproduction_steps.log — full script output, including both clean successful runs in this session.
• bundle/logs/attempt_3.2.2_1.json and bundle/logs/attempt_3.2.2_2.json — vulnerable product attempts.
• bundle/logs/attempt_3.3.0_1.json and bundle/logs/attempt_3.3.0_2.json — fixed product attempts.
• bundle/artifacts/airflow_api_3.2.2_1/api_server_rce_marker.txt and bundle/artifacts/airflow_api_3.2.2_2/api_server_rce_marker.txt — vulnerable API-server import-time execution markers.
• bundle/artifacts/airflow_api_*/airflow_api_server.log — API server startup and HTTP access logs.
• bundle/artifacts/airflow_api_*/endpoint_headers.txt and bundle/artifacts/airflow_api_*/endpoint_response.json — captured HTTP endpoint responses.
• bundle/repro/runtime_manifest.json — structured runtime evidence manifest.
• bundle/repro/validation_verdict.json — structured verdict.

Representative vulnerable evidence from the second verified run:

• attempt_3.2.2_1.json: service_started=true, healthcheck_passed=true, target_reached=true, http_status="200", import_side_effect_observed=true.
• Marker content: import-time code execution in Airflow API server; pid=17188.
• API server access log shows method=GET path=/ui/grid/structure/cve_2026_33264_probe_3_2_2_1 ... status_code=200.

Representative fixed-control evidence:

• attempt_3.3.0_1.json and attempt_3.3.0_2.json: service_started=true, healthcheck_passed=true, target_reached=true, http_status="500", import_side_effect_observed=false.
• Fixed response excerpt: An error occurred while trying to deserialize Dag, with no api_server_rce_marker.txt created.

Environment details captured:

• Vulnerable Airflow: 3.2.2 loaded from <project_cache_dir>/repo/airflow_product_venv.
• Fixed Airflow: 3.3.0 loaded from <project_cache_dir>/repo/airflow_3.3.0_cve_2026_33264_venv.
• Product entrypoint: airflow api-server (uvicorn) reached over localhost HTTP.

Recommendations / Next Steps

• Upgrade apache-airflow to 3.3.0 or later.
• Keep [core] allowed_deserialization_classes restricted to a narrow allowlist as defense in depth, especially in deployments where DAG authors are not fully trusted.
• Add regression tests that insert or load serialized DAG payloads containing historical/unknown serialized types such as base_trigger and assert that API server and scheduler code reject them without importing user-controlled modules.
• Audit other serialized DAG fields that call generic deserialization helpers to ensure no other user-controlled class path reaches import_string() in control-plane processes.

Additional Notes

• Idempotency confirmation: bundle/repro/reproduction_steps.sh was executed twice consecutively and completed successfully both times after the fixed-control payload-generation correction.
• The proof uses a local HTTP API server and a local SQLite metadata database, but it exercises the real Airflow API server product path and a real HTTP endpoint rather than calling BaseSerialization.deserialize() directly.
• The seeded malicious serialized DAG row represents the advisory scenario: attacker-controlled serialized DAG data containing a class path is loaded by the API server. The exploit module is placed on the API server's DAG-folder PYTHONPATH, matching deployments where control-plane processes can import DAG-bundle modules.

A distinct bypass was confirmed against the fixed/latest Apache Airflow 3.3.0 release. The parent reproduction used serialized DAG data with __type="base_trigger"; Airflow 3.3.0 removes that DAT.BASE_TRIGGER deserialization branch. However, BaseSerialization.deserialize() still accepts __type="airflow_exc_ser" and still calls import_string() on attacker-controlled exc_cls_name. By placing an AIRFLOW_EXC_SER object in the serialized DAG's dag.default_args field and loading the DAG through the real API-server UI endpoint, the fixed Airflow 3.3.0 API server imported an attacker-controlled module and executed import-time Python code.

Fix Coverage / Assumptions

The original fix appears to rely on the invariant that removing the historical BASE_TRIGGER case closes the dangerous serialized-DAG class-path import path. The fix explicitly covers the parent trigger path:

• Parent path in 3.2.2: SerializedDagModel.dag -> DagSerialization.from_dict -> BaseSerialization.deserialize() -> DAT.BASE_TRIGGER -> import_string(trigger_class_path).
• Fixed behavior in 3.3.0: DAT.BASE_TRIGGER is no longer handled by BaseSerialization.deserialize(), so the parent base_trigger payload fails closed before importing the attacker module.

The fix does not cover all class-path imports reachable from serialized DAG fields. In both Airflow 3.2.2 and 3.3.0, BaseSerialization.deserialize() keeps this branch:

• DAT.AIRFLOW_EXC_SER / DAT.BASE_EXC_SER deserializes a dict containing exc_cls_name, args, and kwargs.
• For DAT.AIRFLOW_EXC_SER, it calls import_string(exc_cls_name) directly.
• No allowlist, namespace check, or fixed exception-class map is applied before importing.

The target's documented security model was reviewed. Airflow states that DAG authors can execute arbitrary code on workers, the Dag File Processor, and the Triggerer; such execution alone is expected behavior and not a vulnerability. The same security model separately says deployment managers may isolate Scheduler/API Server from DAG-author code and that no DAG-author provided code should execute in those processes except through selected entrypoint mechanisms. The variant uses the same security boundary as the parent advisory: attacker-controlled serialized DAG data causes import-time code execution inside the API Server process, not merely inside a task, Dag File Processor, or Triggerer.

Variant / Alternate Trigger

The bypass uses a different serialized object type and field path from the parent:

• Parent trigger: dag.default_args = {"__type": "base_trigger", "__var": ["evil_trigger_module.EvilTrigger", ...]}.
• Variant trigger: dag.default_args = {"__type": "airflow_exc_ser", "__var": {"__type": "dict", "__var": {"exc_cls_name": "evil_exception_module.EvilException", "args": [], "kwargs": ...}}}.

Exact runtime entry point:

• HTTP endpoint: GET /ui/grid/structure/{dag_id}?offset=0&limit=100 on airflow api-server.
• Product path: API server route loads SerializedDagModel.dag, DagSerialization.from_dict walks serialized DAG fields, and BaseSerialization.deserialize() processes AIRFLOW_EXC_SER in dag.default_args.
• Sink: airflow/serialization/serialized_objects.py, BaseSerialization.deserialize(), DAT.AIRFLOW_EXC_SER branch, import_string(exc_cls_name).

The variant is materially distinct because it does not use the removed BASE_TRIGGER branch. It uses the still-present exception-serialization branch in fixed 3.3.0.

• Package/component affected: apache-airflow / apache-airflow-core, serialized DAG deserialization in airflow.serialization.serialized_objects.BaseSerialization as reached by the API Server.
• Affected versions tested: Airflow 3.2.2 and fixed/latest Airflow 3.3.0. PyPI reported 3.3.0 as both the installed fixed version and latest available release during this run.
• Risk level and consequences: the same security-boundary violation as the parent. A DAG author or actor who can cause malicious serialized DAG data to be loaded can execute Python code in the API Server process. This may expose API-server process privileges, local files, secrets, configuration, and metadata-database access available to that process.

Impact Parity

• Disclosed/claimed maximum impact for the parent: code execution in Scheduler/API Server through unrestricted class-path import during serialized DAG deserialization.
• Reproduced impact from this variant run: code execution in the real Airflow API Server process on fixed/latest Airflow 3.3.0. The imported module writes api_server_airflow_exc_marker.txt at import time and records the API-server PID.
• Parity: full.
• Not demonstrated: the proof writes a marker file only. It does not run a shell command, persist a backdoor, exfiltrate secrets, or attempt post-exploitation.

Root Cause

The same underlying root cause remains: BaseSerialization.deserialize() treats serialized DAG data as trusted enough to control Python import paths. Airflow 3.3.0 removes the BASE_TRIGGER import sink, but leaves the AIRFLOW_EXC_SER import sink reachable from arbitrary serialized fields in a DAG object. When dag.default_args contains an AIRFLOW_EXC_SER object, the recursive deserializer reaches:

elif type_ == DAT.AIRFLOW_EXC_SER or type_ == DAT.BASE_EXC_SER:
    deser = cls.deserialize(var)
    exc_cls_name = deser["exc_cls_name"]
    ...
    if type_ == DAT.AIRFLOW_EXC_SER:
        exc_cls = import_string(exc_cls_name)

The tested fixed tag resolution for Airflow 3.3.0 was refs/tags/3.3.0^{} = 1438ea3587031417cc85d74323235cf087a058fb. The vulnerable comparison tag resolution for Airflow 3.2.2 was refs/tags/3.2.2^{} = cde4885818be51a6cdcfdf9275e100bf070025de. Known advisory fix references are GitHub PRs apache/airflow#66002 and apache/airflow#68528; the local package comparison shows the relevant effective change for the parent path is removal of the DAT.BASE_TRIGGER branch from BaseSerialization.deserialize().

Reproduction Steps

1. Run bundle/vuln_variant/reproduction_steps.sh.
2. The script:
   • Reuses prepared Airflow virtualenvs when available, or installs apache-airflow==3.2.2 and apache-airflow==3.3.0 into stage-local virtualenvs.
   • Creates a fresh Airflow home and SQLite metadata DB for each version.
   • Places evil_exception_module.py in the DAG folder; the module writes a marker file at import time.
   • Seeds a serialized DAG row containing an AIRFLOW_EXC_SER object in dag.default_args with exc_cls_name="evil_exception_module.EvilException".
   • Starts the real airflow api-server, waits for /api/v2/monitor/health, then requests /ui/grid/structure/{dag_id}?offset=0&limit=100.
   • Runs the same variant against vulnerable 3.2.2 and fixed/latest 3.3.0 side by side.
3. Expected evidence:
   • Both versions return HTTP 200 from the UI endpoint.
   • Both versions create api_server_airflow_exc_marker.txt containing AIRFLOW_EXC_SER import-time code execution in Airflow API server; pid=<api-server-pid>.
   • The script exits 0 only when the fixed/latest version also reproduces the import-time execution, i.e. a bypass is confirmed.

Evidence

Primary evidence files:

• bundle/logs/vuln_variant/reproduction_steps.log — full output from the stage-specific reproduction script. The script was executed twice successfully and confirmed idempotency.
• bundle/logs/vuln_variant/airflow_exc_3.2.2_variant.json — vulnerable-version attempt.
• bundle/logs/vuln_variant/airflow_exc_3.3.0_variant.json — fixed/latest-version attempt.
• bundle/vuln_variant/artifacts/airflow_exc_3.2.2_variant/api_server_airflow_exc_marker.txt — vulnerable API-server marker.
• bundle/vuln_variant/artifacts/airflow_exc_3.3.0_variant/api_server_airflow_exc_marker.txt — fixed/latest API-server marker.
• bundle/logs/vuln_variant/base_deserialize_diff.txt — captured source excerpts showing 3.3.0 removed BASE_TRIGGER but retained AIRFLOW_EXC_SER import.
• bundle/logs/vuln_variant/fixed_version.txt and bundle/logs/vuln_variant/latest_version.txt — tested release identity and PyPI/latest checks.
• bundle/vuln_variant/runtime_manifest.json — structured runtime evidence manifest.

Key evidence from the verified second run:

• Airflow 3.3.0 attempt JSON: service_started=true, healthcheck_passed=true, target_reached=true, http_status="200", and import_side_effect_observed=true.
• Fixed/latest marker content: AIRFLOW_EXC_SER import-time code execution in Airflow API server; pid=17602.
• API-server access log tail in the 3.3.0 attempt shows method=GET path=/ui/grid/structure/ghsa_2943_airflow_exc_variant_3_3_0 ... status_code=200.
• Script verdict: RESULT: CONFIRMED BYPASS - Airflow 3.3.0 still imports attacker-controlled AIRFLOW_EXC_SER exc_cls_name during serialized DAG deserialization.

Recommendations / Next Steps

• Treat serialized DAG deserialization as untrusted input whenever it is loaded in Scheduler/API Server contexts.
• Extend the fix beyond BASE_TRIGGER: remove or constrain the AIRFLOW_EXC_SER class-path import path.
• If exception deserialization must remain, use a fixed map of built-in/Airflow exception classes or a strict allowlist that cannot include DAG-bundle modules by default.
• Apply the same policy consistently to all BaseSerialization.deserialize() branches that can import or instantiate classes from serialized data.
• Consider rejecting AIRFLOW_EXC_SER in DAG fields where exception objects are not semantically expected, such as dag.default_args, or validating serialized DAG schemas before recursive object deserialization.
• As defense in depth, deployments should keep Scheduler/API Server unable to import DAG-author-controlled modules and set [core] allowed_deserialization_classes narrowly, but the code fix should not rely on deployment hardening alone.

Additional Notes

The reproduction script was run twice in this stage and completed successfully both times with exit code 0, confirming idempotency. The proof uses a local API-server instance, SQLite metadata database, and localhost HTTP requests. The exploit precondition matches the parent reproduction: the attacker-controlled class path resolves in the API Server process. The test does not claim that ordinary DAG author code execution in workers, Dag File Processor, or Triggerer is itself a vulnerability; the finding is specifically code execution in API Server during serialized DAG deserialization.