CVE-2026-49296: 
Apache Airflow vulnerability analysis and mitigation

CVE-2026-49296 is an authorization bypass vulnerability in Apache Airflow that allows an authenticated user with read access to one DAG to disclose the source code of other DAGs co-located in the same source file. The flaw affects Apache Airflow versions 3.0.0 through 3.2.x (all versions before 3.3.0); single-DAG-per-file deployments are not affected. It was discovered by Matteo Panzeri (Università di Pavia, GitHub @matte1782) and publicly disclosed on July 7, 2026, with a patch released in Apache Airflow 3.3.0. The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) (Apache Advisory, GitHub Advisory).

The root cause is classified as CWE-639 (Authorization Bypass Through User-Controlled Key): the GET /api/v2/dagSources/{dag_id} API endpoint — and its equivalent UI view — returned the entire source file associated with the requested DAG ID without checking whether the caller was authorized to read all DAGs defined within that file (OSS-Sec). Because a single Python file can define multiple DAGs, an attacker who holds DagAccessEntity.CODE read permission on any one DAG in the file could supply that DAG's ID as the key and receive the full file contents, including source code for co-located DAGs they were explicitly denied access to. The fix, implemented in PR #67662, enumerates all DAGs sharing the same (relative_fileloc, bundle_name) as the requested DAG, intersects that set with the caller's readable DAG set, and redacts the response with a placeholder message if any co-located DAG is not readable by the caller (GitHub PR).

Successful exploitation results in unauthorized disclosure of DAG source code, which may contain sensitive business logic, credentials, connection strings, or infrastructure details embedded in workflow definitions. The confidentiality impact is rated High, while integrity and availability are unaffected. Deployments that co-locate multiple DAGs with different access control requirements in a single file and rely on per-DAG access control for source isolation are the primary risk group; organizations using single-DAG-per-file layouts are not affected (GitHub Advisory, OSS-Sec).

1. Reconnaissance: Identify an Apache Airflow instance running a version between 3.0.0 and 3.2.x. Confirm that the deployment co-locates multiple DAGs in shared source files (common in organizations that group related workflows).
2. Authenticate: Log in to the Airflow instance using any valid account that has been granted DagAccessEntity.CODE (read) permission on at least one DAG.
3. Identify a target DAG ID: Browse the Airflow UI or query GET /api/v2/dags to enumerate DAG IDs visible to the authenticated account, including DAGs the user is authorized to read.
4. Request DAG source: Send a crafted HTTP GET request to GET /api/v2/dagSources/{dag_id} using the ID of a DAG the attacker is authorized to read.
5. Receive full file contents: The endpoint returns the entire source file without redaction, exposing source code for all co-located DAGs — including those the caller is not authorized to access — revealing sensitive logic, credentials, or configuration embedded in those DAGs (GitHub PR, OSS-Sec).

• Network/API Logs: Repeated or systematic GET /api/v2/dagSources/{dag_id} requests from a single authenticated user account, especially targeting multiple different DAG IDs in rapid succession.
• Logs: Airflow API access logs showing a low-privilege user account querying DAG source endpoints for DAGs outside their normal operational scope; cross-reference with authorization audit logs to identify mismatches between DAG access grants and source retrieval activity.
• Behavioral: A user account with read access to only a subset of DAGs making source retrieval calls for DAG IDs that belong to files containing restricted DAGs — prior to patching, these calls would succeed and return full file contents.

The primary remediation is to upgrade Apache Airflow to version 3.3.0 or later, which applies per-file authorization to the dagSources endpoint (Apache Advisory, GitHub PR). If immediate patching is not feasible, organizations should restructure DAG files to place each DAG in its own dedicated source file, eliminating the co-location condition that enables the bypass. Additionally, administrators should audit and restrict DagAccessEntity.CODE permissions to minimize the number of users who can access DAG source endpoints, and review existing DAG file organization to identify files that mix DAGs with different access control requirements.

The vulnerability was disclosed via the Apache security mailing list and the oss-security list on July 7, 2026, with the reporter credited as Matteo Panzeri of Università di Pavia (OSS-Sec). The advisory was noted on social platforms including Bluesky by CVE tracking accounts shortly after disclosure. Community reaction has been measured given the Medium severity rating and the limited scope (only multi-DAG-per-file deployments with per-DAG access controls are affected).