Apache Airflow

Secret exposure in Apache Airflow's Rendered Templates UI allows any authenticated user with task-level view access to read plaintext credential values that should have been masked. The secrets masker's `isinstance(str)` guard silently skips dict-typed Python objects, meaning JSON Variables accessed via `var.json` and containing dict payloads (e.g., database credentials, API keys stored as structured JSON) are rendered in cleartext rather than redacted. No public exploit is identified at time of analysis; however, the disclosure requires nothing more than standard UI navigation by a legitimately authenticated user.

Unsafe deserialization in Apache Airflow 3.0.0 through 3.3.0 allows any DAG author to achieve arbitrary code execution in the Scheduler and API server by placing a crafted value in an operator's executor_config field. The serialization layer reconstructed exception nodes by calling import_string() on an attacker-controlled class name with no allowlist, enabling import and invocation of arbitrary callables such as subprocess.check_output or builtins.eval. Both affected components hold the metadata database credentials and JWT signing secret, making full infrastructure compromise a realistic outcome. No public exploit has been identified at time of analysis, but no non-default configuration is required. This is a distinct sink from CVE-2026-33264, meaning deployments that already patched that earlier advisory remain fully vulnerable and must upgrade again to apache-airflow 3.3.1.

Unsafe deserialization in Apache Airflow's XCom REST API allows an authenticated user with XCom write-and-read access to instantiate arbitrary `airflow.*` classes on the API server by smuggling reserved serialization keys inside JSON string literals. The `_check_forbidden_xcom_keys` guard inspected `dict`, `list`, and `tuple` types but did not attempt to JSON-decode `str` values, so a payload like `json.dumps({"__classname__": "airflow.sdk.definitions.connection.Connection"})` passed the write-time check and was later reconstructed into a live Python object when read back via `?deserialize=true`. No public exploit has been identified at time of analysis; vendor-released patch is available in apache-airflow 3.3.1.

Sensitive values stored as deeply nested lists, tuples, or sets in Apache Airflow Variables are displayed unmasked in the Variables UI due to a recursion-depth logic error in the secrets masker. This is an incomplete-fix follow-up to CVE-2026-42358: that prior fix made dictionary traversal unbounded but left list/tuple/set structures subject to the depth cutoff, allowing values beyond that depth to appear in plaintext on screen. The practical impact is narrow - any authenticated user who can see the Variable in the UI already has read access to the full value through the Variables REST API - making this a shoulder-surfing defense gap rather than an access-control bypass. No public exploit has been identified at time of analysis.

Remote code execution and scheduler-process disruption in Apache Airflow 3.3.0 stems from unguarded deserialization of task instance `next_kwargs` during the scheduler's unconditional `awaiting_input` sweep, a code path introduced as part of the 3.3.0 human-in-the-loop task rewrite. Any authenticated DAG author who can influence task state through the task execution API can supply a crafted payload that causes arbitrary module import and object instantiation inside the scheduler process, or terminate the scheduler job entirely. No public exploit has been identified at time of analysis, but a vendor-released patch exists in 3.3.1; deployments that previously patched CVE-2026-58076 are still vulnerable through this distinct code path and must upgrade.

Unsafe deserialization in Apache Airflow 3.3.0's Task SDK allows an authenticated DAG author to cause arbitrary module imports inside the scheduler process. By controlling a task instance's `next_kwargs` via the task execution API, an attacker can inject a crafted callback path that the scheduler's unconditional `awaiting_input` timeout sweep deserializes by re-running the `SyncCallback` constructor - triggering an import of the named module in the scheduler's process space. Because `SyncCallback` is itself an Airflow class, it bypasses the `allowed_deserialization_classes` allow-list, making tightening that setting ineffective. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS score of 8.8 reflects the severity of the potential scheduler process compromise.

Sensitive credential exposure in Apache Airflow 3.3.0 allows an authenticated Viewer with configuration-read access to retrieve team-scoped sensitive options - including Celery broker URLs with embedded credentials - in cleartext via the Config API. The secrets masker evaluated sensitivity against raw section names without resolving team-prefixed sections (e.g., [team_a=celery]) back to their registered base section, so team-scoped overrides silently bypassed masking while equivalent global options were correctly redacted. This is a third distinct masker bypass variant following CVE-2026-48828 and CVE-2026-48892, meaning deployments that already upgraded to 3.3.0 to remediate those issues remain exposed. No public exploit identified at time of analysis.

Authorization bypass in Apache Airflow's Backfill API (all versions prior to 3.3.1) allows any authenticated user holding edit permission on a single DAG to read, pause, cancel, and fail backfills belonging to any other DAG. The flaw is a type-parsing mismatch in FastAPI's dependency resolution layer: the authorization dependency parsed the `backfill_id` path parameter with Python's `int()` while the route handler declared `NonNegativeInt` via Pydantic, which in lax mode coerces inputs like `'42.0'` that `int()` rejects-causing the two components to authorize and act on different DAGs. Backfill IDs are sequential, making cross-DAG enumeration trivial; no public exploit code has been identified at time of analysis, though the technique is directly reproducible from the published patch diff.

Cleartext secret exposure in Apache Airflow's audit log affects all versions before 3.3.1, allowing any authenticated user with audit-log read access to recover Variable values and Connection `extra` credentials verbatim - without holding Variables or Connections read permissions. The bulk API endpoints (`PATCH /api/v2/variables`, `PATCH /api/v2/connections`) bypassed audit-log masking because the masker inspected only top-level request fields while bulk payloads nest entities two levels deep under `actions[].entities[]`. The Airflow UI's Import Variables action posts to this same bulk endpoint, meaning a routine operator import silently writes every secret in the uploaded file to the unmasked audit log. No public exploit is identified at time of analysis, but the vulnerability is fully exploitable by any authenticated user with log access, and deployments that upgraded to 3.3.0 in response to the related CVE-2026-50204 remain vulnerable and must upgrade again.

Cleartext exposure of list-shaped Variable secrets in Apache Airflow Task SDK (all versions before 3.3.1) allows any authenticated Airflow user to recover sensitive values directly from task execution logs and the Rendered Templates UI. The masking logic in _mask_and_deserialize_variable correctly handled string- and dict-typed JSON Variable values but contained no branch for the list type, so arrays - which may hold passwords, API tokens, or connection strings - were returned unredacted. No public exploit has been identified at time of analysis; however, organizations that patched CVE-2026-59244 remain fully exposed because that fix addressed only the dict case, and must upgrade again to 3.3.1.

Cross-team DAG authorization bypass in Apache Airflow versions prior to 3.3.1 allows authenticated users in one team to trigger DAG runs and read XCom values belonging to other teams. The asset materialization endpoint (POST /api/v2/assets/{asset_id}/materialize) and the XCom check in wait_dag_run_until_finished both passed DagDetails without resolving the DAG's team_name, causing team-aware auth managers (e.g., Keycloak) to evaluate the permission against the global DAG resource instead of the team-scoped DAG:<team> resource. This is a missing authorization flaw (CWE-862) affecting only deployments running multi-team mode with a team-aware auth manager; FAB auth manager deployments are explicitly unaffected. No public exploit code or CISA KEV listing has been identified at time of analysis.

Cross-team credential access in Apache Airflow before 3.3.1 allows authenticated members of one team to invoke another team's Connection credentials through the POST /api/v2/connections/test API endpoint, exploiting a broken namespace-isolation guard in the environment-variable secrets backend. The flaw-confirmed by Apache with patches in PRs #70736 and #70902-combines a guard that only triggered on unscoped (global) requests with a regex incapable of matching team names containing underscores, even though underscores are explicitly permitted in Airflow team name validation. Exploitation requires a precise configuration alignment of multi_team mode, an explicitly enabled test_connection endpoint, and environment-variable-provisioned team secrets; no public exploit has been identified at time of analysis.

Remote code execution in Apache Airflow before 3.3.0 lets a DAG author embed a malicious trigger whose attacker-controlled class path is loaded via an unrestricted import_string() when the Scheduler or API Server deserializes the serialized DAG, executing arbitrary code in those privileged processes and breaking the core Airflow boundary that DAG-author code must never run in the Scheduler/API Server. Reported by Apache with a fix in 3.3.0, it currently has no public exploit identified and a low EPSS of 0.69% (48th percentile), and it is not listed in CISA KEV. The practical severity depends heavily on how much a deployment trusts its DAG authors, since exploitation requires the ability to submit a DAG.

Apache Airflow REST API exposes provider secrets in plaintext through the task-instance detail and list endpoints when tasks are in a deferred state. Any authenticated user holding DAG-scoped task-instance read access - a permission commonly granted to non-admin roles - can retrieve API keys, passwords, or other secrets passed by deferred operators into trigger kwargs. Fixed in Apache Airflow 3.3.0; no public exploit code identified at time of analysis, though exploitation is trivially achievable by any authenticated user with the requisite read permission.

Sensitive credential exposure in Apache Airflow's Bulk Variables API allows authenticated users with bulk Variable read permission to retrieve plaintext values from JSON-typed variables whose key names use secret-suffixed conventions such as `*_password`, `*_token`, or `*_secret`. The redactor function was invoked without passing the variable key, so the `should_hide_value_for_key` check - which is responsible for masking secrets based on key-name patterns - could never fire for JSON-decodable variable values. This affects all deployments prior to 3.3.0 that store sensitive credentials in JSON-typed Airflow Variables under secret-suffixed key names; no public exploit has been identified at time of analysis, and exploitation is bounded by the requirement for authenticated access with a specific permission grant.

Unauthorized source code disclosure in Apache Airflow before 3.3.0 allows authenticated users to read the source of DAGs they are not authorized to, when multiple DAGs are co-located in a single source file. This bypasses per-DAG access control via the REST API endpoint GET /api/v2/dagSources/{dag_id} and the equivalent UI view. No public exploit identified, and EPSS probability is low (0.20%), mitigating immediate risk for most deployments.

Incomplete authorization filtering in Apache Airflow's `/ui/dependencies` scheduling graph endpoint exposes restricted DAG identifiers to authenticated users who lack read permission on those DAGs. The endpoint correctly filters top-level serialized DAG keys against the caller's ACL but leaks referenced DAG IDs through `dep.source` and `dep.target` fields of trigger and sensor dependency entries, enabling cross-team DAG enumeration in multi-tenant deployments. This is a residual gap from an incomplete fix for CVE-2026-28563; no public exploit has been identified at time of analysis, and a vendor patch is available in apache-airflow 3.3.0.

Apache Airflow's Config API leaks plaintext secrets-backend credentials to authenticated users with Config read permission, because per-key environment variable overrides (e.g., AIRFLOW__SECRETS__BACKEND_KWARG__SECRET_ID) generate synthetic config entries whose names are absent from the sensitive_config_values masking list. Affected deployments are those that configure secrets backends such as HashiCorp Vault via these per-key environment variable patterns, exposing credentials like Vault role_id and secret_id through normal API responses. No public exploit has been identified at the time of analysis; the vendor-released fix is apache-airflow 3.3.0.

Information disclosure in Apache Airflow's GET /api/v2/connections/{connection_id} endpoint allows authenticated users with Connection-read permission to retrieve plaintext secrets from the extra JSON blob because the redaction allowlist omitted critical field names such as webhook_url, bearer, and service_key. No active exploitation or public PoC code was identified at the time of analysis; EPSS indicates very low exploitation probability (0.02%). Users should upgrade to apache-airflow 3.2.2 or later.

Command injection in Apache Airflow's BashOperator documentation example allows authenticated attackers to escalate privileges from UI user to worker-level code execution. Affects all Airflow versions before 3.2.0. The vulnerability stems from documentation suggesting unsafe handling of dag_run.conf parameters, which organizations may have replicated in production DAGs. EPSS score of 0.03% indicates low observed exploitation probability, though the upstream fix (PR #64129) demonstrates vendor acknowledgment and remediation.

Apache Airflow 3.0.x prior to 3.2.0 allows remote unauthenticated attackers to trigger unauthorized DAG (Directed Acyclic Graph) execution via the UI or API, bypassing asset materialize permission checks. Despite CVSS 7.5 HIGH, the CVSS vector (PR:N) contradicts the description's requirement for 'UI/API user with asset materialize permission', suggesting authentication IS required-a critical discrepancy that demands verification. EPSS of 0.01% (3rd percentile) indicates minimal observed exploitation activity. Vendor-released patch available in Airflow 3.2.0 per Apache advisory.

Apache Airflow 3.0.0 through 3.1.x exposes JWT authentication tokens in application logs, allowing any authenticated UI user with log access to escalate privileges and impersonate DAG Authors. CVSS rates this 7.5 HIGH for confidentiality impact, though the EPSS score of 0.02% (5th percentile) suggests minimal observed exploitation attempts. No active exploitation is confirmed; vendor patch available in version 3.2.0 released April 2026.

2-3 sentence plain-language synthesis. Not copy description. Start with impact, product, etc. Mention actively exploited? KEV? None. POC? Not mentioned, so

We need to produce a JSON object per the instructions. Let's analyze each field. First, product_name: "1-3 words ONLY. The specific product or service name affected." CVE affects Apache Airflow example documentation. However, the vulnerability is in the documentation example that users might have copied. The product is Apache Airflow, specific component: documentation/examples. But the description says "It does not affect Airflow release". The vulnerable pattern is in the documentation, and users who followed it may have vulnerable code. So the primary product is Apache Airflow? The CPE: apache:airflow.* So product_name: "Apache Airflow" fits. Possibly "Apache Airflow documentation" but not typical. Product name should be the software. It says "1-3 words ONLY", so "Apache Airflow" is two words. That is good. summary: "2-3 sentence plain-language summary for security professionals. CRITICAL: Do NOT copy or paraphrase Description — write an original synthesis... Start with the specific impact verb and product, e.g. 'Remote code execution in Apache Tomcat 9.x allows...'. Explain WHAT the vulnerability is, WHO is affected (specific product/version), and WHAT an attacker can do. Mention if actively exploited (KEV), if POC exists, and EPSS risk if notable." From the description: The example_xcom example in Airflow documentation implemented an unsafe pattern of reading XCom values, which could allow a UI user who can modify XComs to execute arbitrary code on the worker. It's a code injection via unsafe pattern, but only if the user replicated the pattern. The vulnerability is not in the product itself but in the example. The CVSS is 8.1, which seems high for something that requires the user to copy a bad pattern. But it's rated Low severity. EPSS is 0.03%, very low. No KEV mentioned. Patch: documentation updated in Airflow 3.2.0. So we need to synthesize: "Code injection in Apache Airflow's example_xcom documentation that, if followed by users, allows UI users with XCom modification privileges to execute arbitrary code on the worker. Affects users who implemented the documented unsafe pattern; Airflow 3.2.0 documentation provides a safer alternative." Mention EPSS 0.03%, no known active exploitation, no public POC? Actually, there is no mention of POC apart from the CVE itself being published, but the description suggests it's just a pattern. Not a POC exploit. So "no public exploit identified". We'll say "not actively exploited" and "EPSS score 0.03% suggesting minimal exploitation likelihood". So summary: "Code injection in Apache Airflow's example_xcom documentation allows UI users who can modify XComs to execute arbitrary code on the worker. This risk exists only for deployments that replicated the unsafe pattern from the documentation. Airflow 3.2.0 updated documentation to recommend a safe pattern, and EPSS data indicates a very low exploitation probability (0.03%)." That's 2-3 sentences. No copy. technical_context: Explain underlying technology/library/protocol. CWE-94: Code Injection. XCom (cross-communication) in Apache Airflow is a mechanism for tasks to exchange data. The example showed directly templating XCom values into a bash command string without proper escaping or validation, enabling command injection. The CPE confirms affected product Apache Airflow all versions before 3.2.0 (since the documentation existed before that version). The root cause: improper neutralization of special elements in a command (CWE-94). So we can explain that. risk_assessment: "Assess real-world risk using ALL available signals: CVSS vector (attack vector, complexity, privileges), EPSS exploitation probability, KEV status, POC availability, SSVC decision framework (exploitation status, automatable, technical impact). Compare and contrast these signals. Is this a real priority or just a high-CVSS-but-low-real-risk issue? If any key data is missing or conflicting, STATE IT EXPLICITLY." CVSS 8.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. That's high, but EPSS 0.03% is very low. SSVC: Exploitation: none, Automatable: no, Technical Impact: total. So exploitation is not active, not automatable, but total impact if exploited. That suggests high impact but low likelihood because it requires a user to have copied a specific pattern from documentation. The vulnerability is not in the core product but in user implementations. So it's a documentation issue, not a product vulnerability. Many users might not have enabled example dags or copied that pattern. So high CVSS but low real risk. Conflicting: CVSS indicates network attack vector, low privileges, no user interaction, but in practice, the attacker must be an UI user with XCom modification rights, which is authenticated. That matches PR:L. AV:N is plausible if the Airflow UI is network accessible. AC:L because the pattern is easy to exploit if the vulnerable code exists. So it's a high-severity issue if the user has the vulnerable code, but the footprint is likely tiny. So prioritize low. We'll state that. affected_products: Write a concise paragraph listing affected products with versions. "Apache Airflow documentation versions prior to 3.2.0 contain the unsafe pattern in example_xcom.py. Users who implemented the example pattern in their DAG code are affected regardless of Airflow version. Airflow 3.2.0 documentation includes the corrected safe pattern. CPE: cpe:2.3:a:apache_software_foundation:apache_airflow:*:*:*:*:*:*:*:*. EUVD lists affected versions: Apache Airflow 0 <3.2.0." Note: the patch is a documentation update, not a code fix. So affected products are Airflow documentation versions before 3.2.0, and downstream users' custom code. So we can state that. remediation: "Write a concise paragraph with actionable remediation steps. Start with the primary fix (patch/upgrade with exact version), then mention workarounds if relevant. Include advisory URLs... If no patch is available, suggest SPECIFIC compensating controls." The advisory says: Documentation of Airflow 3.2.0 contains improved version. So users should review their code and adopt the safe pattern shown in the updated example (using environment variables instead of direct templating). No code patch needed because the vulnerability is in user code. So remediation: "Review any custom DAG code that uses XCom value to construct bash commands, and refactor to use the safe pattern from Airflow 3.2.0 documentation: pass XCom values as environment variables and reference them via $VAR in the command." We can refer to the PR and advisory. Also, as a general measure, restrict XCom modification permissions to trusted UI users. But that's already indicated: UI users already highly trusted. So no need. So the primary remediation is to change user code. The advisory URL: https://lists.apache.org/thread/3mf4cfx070ofsnf9qy0s2v5gqb5sc2g1 exploit_scenario: "Brief realistic attack scenario in 2-3 sentences. If POC exists, note that. Factor in attack vector and complexity from CVSS." An attacker with Airflow UI access (low privilege, XCom modification rights) could replace an XCom value with a malicious command payload. When a DAG task uses the unsafe pattern to read that XCom and execute it in bash, the malicious command runs on the worker node. This could lead to data exfiltration or further compromise. No public POC, but the pattern is straightforward. exploitation_conditions: CRITICAL FIELD. Need specific, concrete prerequisites. From description: "UI user who had access to modify XComs" and "users following the example could replicate the bad pattern". So conditions: 1) The Airflow deployment must contain a DAG that directly templates XCom values into a bash command (the unsafe pattern). 2) The attacker must have UI access with permission to modify XCom values (i.e., at least read/write on the target XCom). 3) The DAG must be triggered, and the task that reads the XCom and executes the command must run after the XCom value is poisoned. So the exploitation conditions: "The target environment must contain a DAG task that unsafely constructs a bash command using XCom values (as shown in the affected example). An attacker must be an authenticated Airflow UI user with privileges to modify the XComs used by that DAG. The attacker then triggers the DAG, causing the injected command to execute on the worker." Also note: No special configuration per se, but the presence of the vulnerable pattern is required. I'll phrase it carefully. attack_chain: "3-7 short steps separated by ' → ' (arrow). Must be grounded in actual CVE data." Kill chain phases. Potential steps: Authenticate as UI user with XCom write permissions → Poison target XCom with malicious shell command → Trigger DAG run that reads the poisoned XCom → DAG task templates XCom into bash command without sanitization → Bash executes the payload → Achieve code execution on worker node. So chain: "Authenticate to Airflow UI as user with XCom write access → Locate target DAG that uses unsafe XCom pattern → Inject malicious command into XCom variable → Trigger DAG run that reads the XCom → BashOperator executes crafted command → Gain arbitrary code execution on worker". That's 6 steps. Use arrow. confidence_notes: "1-3 sentences about data completeness and confidence. State what is CONFIRMED, what is INFERRED, what is UNKNOWN." Confirmed: The unsafe pattern existed in example documentation before 3.2.0 (confirmed by GitHub diff). The vulnerability description confirmed by Apache advisory. The patch is documentation update, not code change. CVSS vector provided by NVD. EPSS low. No active exploitation. Unknown: exact number of users who copied the pattern, but likely low. So confidence: "Vulnerability confirmed by Apache advisory and GitHub PR. The CVSS vector is from NVD. No active exploitation detected, EPSS extremely low. The number of affected deployments replicating the example is unknown but likely minimal." prevalence: ONE word only: low? Airflow is widely used enterprise scheduler, but the vulnerability is not in the default installation; it's only if someone copied that specific pattern. So the product itself (Apache Airflow) is high prevalence, but the vulnerable code pattern is not ubiquitous. The prevalence field is about "REAL-WORLD deployment footprint of the affected product". The affected product as defined in product_name is Apache Airflow. But the vulnerability is in the documentation example, not the product itself. However, the question asks: "Estimate the REAL-WORLD deployment footprint of the affected product — how widely it is actually deployed in production." So Airflow is widely deployed. But the CVE description says "It does not affect Airflow release - example_dags are not supposed to be enabled in production environment, however users following the example could replicate the bad pattern." So the affected product is actually the documentation and the users' custom code. The product is Apache Airflow, but the vulnerability is not in the released software. So the deployment footprint of Apache Airflow is high, but the vulnerable scenario is rare because it requires manual copying of an example. So the prevalence of the actual vulnerable condition is low. But the field asks for "prevalence" of the affected product. It says "ubiquitous | high | medium | low | rare | unknown". The product is Apache Airflow. That could be "high" because Airflow is widely used in data engineering. But then the vulnerability itself is low prevalence. However, I think it's meant to be the product, not the vulnerability. The guidelines: "Estimate the REAL-WORLD deployment footprint of the affected product — how widely it is actually deployed in production. This is INDEPENDENT of severity (a CRITICAL flaw in a rare product is still rare)." So if the product is Apache Airflow, it's high. But then the vulnerability is just a documentation issue, and it's not in the product itself, but the CVE is tied to the product. I'll decide: product is Apache Airflow, so prevalence should be high because many enterprises use it. But the description says "It does not affect Airflow release", so maybe they don't consider the product as vulnerable. Yet the CPE lists Apache Airflow as affected. The affected product string often includes the software that has the flaw, even if it's just documentation. So I'll set prevalence to high, because Apache Airflow is a widely-deployed enterprise scheduler. Prevalence basis: "widely-deployed enterprise workflow scheduler". However, given that the actual flaw is in user code and not default, maybe the prevalence of the vulnerable code pattern is low, but the product prevalence is high. The instruction says: "the affected product — how widely it is actually deployed in production." The affected product is Apache Airflow, so high. I'll go with high. prevalence_basis: "core data pipeline tool,

Information disclosure in Apache Airflow 3.0.0 through 3.1.x stems from incomplete secret masking and under-documented workload-isolation and JWT-authentication assumptions, allowing sensitive credentials to surface in task logs and role boundaries to be weaker than a Deployment Manager might assume. The fix in 3.2.0 hardens the secrets masker (PR #58662) and formalizes the security model, JWT token authentication, and workload isolation guidance. No public exploit is identified and EPSS is very low (0.04%), making this a hardening/hygiene issue rather than an urgent exploited flaw.

CVE-2026-28563 is a security vulnerability (CVSS 4.3) that allows an authenticated user with only dag dependencies permission. Remediation should follow standard vulnerability management procedures. Vendor patch is available.

CVE-2026-26929 is a security vulnerability (CVSS 6.5). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

CVE-2026-30911 is a security vulnerability (CVSS 8.1) that allows any authenticated task instance. High severity vulnerability requiring prompt remediation. Vendor patch is available.

CVE-2026-28779 is a security vulnerability (CVSS 7.5) that allows any application co-hosted under the same domain. High severity vulnerability requiring prompt remediation. Vendor patch is available.