CVE-2026-49487: Apache Airflow REST API Exposes Deferred Task Secrets

Technical summary

CVE-2026-49487 is an information disclosure vulnerability in Apache Airflow versions prior to 3.3.0. When a task enters deferred state (a pattern where operators pause execution and resume via an async trigger), the REST API endpoints for task-instance detail and list operations returned the trigger's kwargs dictionary without applying Airflow's standard secret-masking logic. Since trigger kwargs often contain credentials passed by the operator to facilitate async work (database passwords, API tokens, cloud provider keys), these values were readable in the response body to any user with DAG-scoped task-instance read permissions. The vulnerability does not require special API privileges—authenticated users with standard task-read access could exploit it. Airflow 3.3.0 remediated this by ensuring that the same masking rules applied to other API responses are now applied to trigger kwargs before serialization.

Business impact

The exposure of credentials embedded in trigger kwargs could enable lateral movement, unauthorized API access, and account takeover within your data orchestration environment. If your Airflow instance orchestrates cloud infrastructure, data warehouses, or third-party SaaS platforms, compromised credentials could grant attackers equivalent access. Multi-team deployments are especially vulnerable because users managing one DAG can pivot to systems accessed by unrelated DAGs. The blast radius depends on your DAG design: if many operators reuse the same credential objects for efficiency, a single exposure could compromise multiple downstream systems. Regulatory implications apply if those credentials protect regulated data (PII, financial records, health information).

Affected systems

Apache Airflow versions before 3.3.0 are vulnerable. This includes all 2.x releases and early 3.0.x and 3.1.x and 3.2.x releases. Self-managed Airflow deployments on-premises or in cloud VMs are at risk; managed services (such as Cloud Composer or MWAA) depend on their vendor's update cadence. The vulnerability only manifests if you use deferred operators—standard synchronous operators are unaffected. Common affected use cases include Airflow with async sensors, async hooks from community providers, or custom deferred operators that handle external system authentication.

Exploitability

Exploitability is moderate. An attacker must be an authenticated Airflow user with at least DAG-scoped task-instance read permissions—meaning they need valid credentials to your Airflow webserver or API. No special network access or prior knowledge is required; the API endpoint is part of standard Airflow deployment. The attack is trivial to execute: a simple HTTP GET to the task-instance detail endpoint while a task is deferred will return the unmasked kwargs. The CVSS score of 6.5 (Medium) reflects the need for authentication and the limitation to confidentiality (no integrity or availability impact), but the ease of exploitation and sensitivity of exposed data make this a practical risk in real deployments.

Remediation

Upgrade to Apache Airflow 3.3.0 or later as soon as feasible. Before upgrading, implement compensating controls: restrict DAG-scoped task-instance read permissions to only those users who require it, audit Airflow access logs for suspicious API queries, and consider rotating credentials that were exposed during deferred task execution (particularly if any were logged or cached). If immediate upgrade is not possible, consider using a reverse proxy to filter or redact API responses for sensitive endpoints, though this is a temporary measure.

Patch guidance

Upgrade to Apache Airflow 3.3.0 or later. Verify the release notes and changelog to confirm that trigger kwargs masking is included. If you use a managed Airflow service (Cloud Composer, MWAA, etc.), check with your vendor for their release timeline; they may auto-upgrade or require manual action. After patching, verify that sensitive values in trigger kwargs are no longer visible in API responses by testing a deferred task and querying the task-instance endpoint. Also rotate any credentials that were exposed prior to the upgrade.

Detection guidance

Monitor Airflow REST API logs for task-instance detail and list endpoint access (typically GET /api/v1/dags/{dag_id}/tasks/{task_id}/instances or /api/v1/dags/{dag_id}/taskInstances). Look for patterns where the same user repeatedly queries deferred tasks, especially across multiple DAGs. Inspect API response payloads (if logging verbosity permits) for plaintext secrets in trigger kwargs—these often match known patterns (AWS_SECRET_ACCESS_KEY, api_key, token, password, etc.). Check Airflow audit logs for users with task-instance read access who may have leveraged their permissions beyond their typical responsibilities. Search for evidence of credential use immediately following API queries.

Why prioritize this

Prioritize this vulnerability for medium-to-large Airflow deployments with multi-team environments. If your Airflow instance manages sensitive infrastructure (data pipelines, cloud API access, database connections) and is accessed by users with varying trust levels, this is a near-term remediation target. Smaller single-team deployments with restrictive access controls face lower risk. Factor in your current Airflow version and how many deferred operators you employ; if you use mostly synchronous operators, risk is lower. Managed Airflow services may lower urgency if your vendor is already patching.

Risk score, explained

The CVSS 3.1 score of 6.5 (Medium) is driven by: Network accessibility (unauthenticated attacks would be higher, but this requires valid Airflow user credentials, lowering attack vector); complete loss of confidentiality (secrets are fully readable), but no impact on integrity or availability; and the requirement for prior authentication and specific DAG access grant (reducing likelihood). In context, the practical risk is elevated if: (1) your Airflow instance is accessed by many users with heterogeneous trust levels, (2) you store high-value secrets in trigger kwargs, or (3) you lack compensating controls like credential rotation. Consider it a 7.5–8.0 for sensitive multi-tenant environments and a 5.5–6.0 for restricted, single-team setups.

Frequently asked questions