Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
153 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Airflow versions before 2.11.1 have a vulnerability that allows authenticated users with audit log access to see sensitive values in audit logs which they should not see. When sensitive connection parameters were set via airflow CLI, values of those variables appeared in the audit log and were stored unencrypted in the Airflow database. While this risk is limited to users with audit log access, it is recommended to upgrade to Airflow 2.11.1 or a later version, which addresses this issue. Users who previously used the CLI to set connections should manually delete entries with those connection sensitive values from the log table. This is similar but not the same issue as CVE-2024-50378
Recommended action: Upgrade to 2.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DAG Author (who already has quite a lot of permissions) could manipulate database of Airflow 2 in the way to execute arbitrary code in the web-server context, which they should normally not be able to do, leading to potentially remote code execution in the context of web-server (server-side) as a result of a user viewing historical task information. The functionality responsible for that (log template history) has been disabled by default in 2.11.1 and users should upgrade to Airflow 3 if they want to continue to use log template history. They can also manually modify historical log file names if they want to see historical logs that were generated before the last log template change.
Recommended action: Upgrade to 2.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a DAG failed during parsing, Airflow’s error-reporting in the UI could include the full kwargs passed to the operators. If those kwargs contained sensitive values (such as secrets), they might be exposed in the UI tracebacks to authenticated users who had permission to view that DAG. The issue has been fixed in Airflow 3.1.5rc1 and 2.11.1, and users are strongly advised to upgrade to prevent potential disclosure of sensitive information.
Recommended action: Upgrade to 3.1.5rc1 (pre-release) or 2.11.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Overview An authorization bypass vulnerability exists in Apache Airflow that allows authenticated users to access task execution logs without the required permissions. The Flaw The vulnerability affects environments using custom roles or granular permission settings. Normally, Airflow allows administrators to separate "Task" access (viewing the task state) from "Task Log" access (viewing the console output/logs). In affected versions, the permission check for retrieving logs is insufficient. An authenticated user who has been granted access to view Tasks can successfully request and view Task Logs, even if they do not have the specific canread permission for Logs. Impact - Confidentiality Loss: Task logs often contain sensitive operational data, debugging information, or potentially leaked secrets (environment variables, connection strings) that should not be visible to all users with basic task access. - Broken Access Control: This bypasses the intended security model…
Recommended action: Upgrade to 3.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Exposure of Sensitive Information: An information disclosure vulnerability exists in the Apache Airflow UI that allows authenticated users to view Import Errors for DAGs they are not authorized to access. In affected versions, the Import Errors view does not correctly filter errors based on granular DAG permissions. This means a user with access to only DAGA can view import errors generated by DAGB, DAGC, or system-level DAGs. These error logs often contain file paths, code snippets, or stack traces that reveal the internal structure and logic of restricted DAGs. Patches Users should upgrade to Apache Airflow 3.1.7 or later. This version strictly enforces DAG-level permissions on the Import Errors view. Workarounds There are no known workarounds other than upgrading. Resources CVE-2026-24098 Pull Request #60801 Mailing List Announcement
Recommended action: Upgrade to 3.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Airflow versions before 3.1.6, when rendered template fields in a Dag exceed [core] maxtemplatedfieldlength, sensitive values could be exposed in cleartext in the Rendered Templates UI. This occurred because serialization of those fields used a secrets masker instance that did not include user-registered masksecret() patterns, so secrets were not reliably masked before truncation and display. Users are recommended to upgrade to 3.1.6 or later, which fixes this issue
Recommended action: Upgrade to 3.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Airflow versions before 3.1.6, and 2.11.1 the proxies and proxy fields within a Connection may include proxy URLs containing embedded authentication information. These fields were not treated as sensitive by default and therefore were not automatically masked in log output. As a result, when such connections are rendered or printed to logs, proxy credentials embedded in these fields could be exposed. Users are recommended to upgrade to 3.1.6 or later for Airflow 3, and 2.11.1 or later for Airflow 2 which fixes this issue.
Recommended action: Upgrade to 3.1.6 or 2.11.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Edge3 Worker RPC RCE on Airflow 2. This issue affects Apache Airflow Providers Edge3: before 2.0.0 - and only if projects installed and configured it on Airflow 2. The Edge3 provider support in Airflow 2 has been always development-only and not officially released, however if projects installed and configured Edge3 provider in Airflow 2, it implicitly enabled non-public (normally) API which was used to test Edge Provider in Airflow 2 during the development. This API allowed Dag author to perform Remote Code Execution in the webserver context, which Dag Author was not supposed to be able to do. If projects installed and configured Edge3 provider for Airflow 2, they should uninstall it and migrate to Airflow 3. The new Edge3 provider versions (>=2.0.0) has a minimum version of Airflow set to 3 and the RCE-prone Airflow 2 code is removed, so it should no longer be possible to use the Edge3 provider 2.0.0+ on Airflow 2. If projects used Edge Provider in Airflow 3, you they are not…
Recommended action: Upgrade to 2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Apache Airflow allowed authenticated UI users to view secret values in rendered templates due to secrets not being properly redacted, potentially exposing secrets to users without the appropriate authorization. Users are recommended to upgrade to version 3.1.4, which fixes this issue.
Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
User with CREATE and no UPDATE privilege for Pools, Connections, Variables could update existing records via bulk create API with overwrite action.
Recommended action: Upgrade to 3.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An example dag exampledagdecorator had non-validated parameter that allowed the UI user to redirect the example to a malicious server and execute code on worker. This however required that the example dags are enabled in production (not default) or the example dag code copied to build your own similar dag. If you used the exampledagdecorator please review it and apply the changes implemented in Airflow 3.0.5 accordingly.
Recommended action: Upgrade to 3.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
API users via /api/v2/dagReports could perform Dag code execution in the context of the api-server if the api-server was deployed in the environment where Dag files were available.
Recommended action: Upgrade to 3.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow 3 introduced a change to the handling of sensitive information in Connections. The intent was to restrict access to sensitive connection fields to Connection Editing Users, effectively applying a "write-only" model for sensitive values. In Airflow 3.0.3, this model was unintentionally violated: sensitive connection information could be viewed by users with READ permissions through both the API and the UI. This behavior also bypassed the AIRFLOWCOREHIDESENSITIVEVARCONNFIELDS configuration option. This issue does not affect Airflow 2.x, where exposing sensitive information to connection editors was the intended and documented behavior. Users of Airflow 3.0.3 are advised to upgrade Airflow to =3.0.4.
Recommended action: Upgrade to 3.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow versions before 2.10.3 contain a vulnerability that could expose sensitive configuration variables in task logs. This vulnerability allows DAG authors to unintentionally or intentionally log sensitive configuration variables. Unauthorized users could access these logs, potentially exposing critical data that could be exploited to compromise the security of the Airflow deployment. In version 2.10.3, secrets are now masked in task logs to prevent sensitive configuration variables from being exposed in the logging output. Users should upgrade to Airflow 2.10.3 or the latest version to eliminate this vulnerability. If you suspect that DAG authors could have logged the secret values to the logs and that your logs are not additionally protected, it is also recommended that you update those secrets.
Recommended action: Upgrade to 2.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Airflow versions before 2.10.3 have a vulnerability that allows authenticated users with audit log access to see sensitive values in audit logs which they should not see. When sensitive variables were set via airflow CLI, values of those variables appeared in the audit log and were stored unencrypted in the Airflow database. While this risk is limited to users with audit log access, it is recommended to upgrade to Airflow 2.10.3 or a later version, which addresses this issue. Users who previously used the CLI to set secret variables should manually delete entries with those variables from the log table.
Recommended action: Upgrade to 2.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Example DAG: exampleinleteventextra.py shipped with Apache Airflow version 2.10.0 has a vulnerability that allows an authenticated attacker with only DAG trigger permission to execute arbitrary commands. If you used that example as the base of your DAGs - please review if you have not copied the dangerous example; see https://github.com/apache/airflow/pull/41873 for more information. We recommend against exposing the example DAGs in your deployment. If you must expose the example DAGs, upgrade Airflow to version 2.10.1 or later.
Recommended action: Upgrade to 2.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow versions before 2.10.1 have a vulnerability that allows DAG authors to add local settings to the DAG folder and get it executed by the scheduler, where the scheduler is not supposed to execute code submitted by the DAG author. Users are advised to upgrade to version 2.10.1 or later, which has fixed the vulnerability.
Recommended action: Upgrade to 2.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow, versions before 2.10.0, have a vulnerability that allows the developer of a malicious provider to execute a cross-site scripting attack when clicking on a provider documentation link. This would require the provider to be installed on the web server and the user to click the provider link. Users should upgrade to 2.10.0 or later, which fixes this vulnerability.
Recommended action: Upgrade to 2.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow 2.4.0, and versions before 2.9.3, has a vulnerability that allows authenticated DAG authors to craft a docmd parameter in a way that could execute arbitrary code in the scheduler context, which should be forbidden according to the Airflow Security model. Users should upgrade to version 2.9.3 or later which has removed the vulnerability.
Recommended action: Upgrade to 2.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow versions before 2.9.3 have a vulnerability that allows an authenticated attacker to inject a malicious link when installing a provider. Users are recommended to upgrade to version 2.9.3, which fixes this issue.
Recommended action: Upgrade to 2.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Use of Web Browser Cache Containing Sensitive Information vulnerability in Apache Airflow. Airflow did not return "Cache-Control" header for dynamic content, which in case of some browsers could result in potentially storing sensitive data in local cache of the browser. This issue affects Apache Airflow: before 2.9.2. Users are recommended to upgrade to version 2.9.2, which fixes the issue.
Recommended action: Upgrade to 2.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow version 2.9.0 has a vulnerability that allows an authenticated attacker to inject malicious data into the task instance logs. Users are recommended to upgrade to version 2.9.1, which fixes this issue.
Recommended action: Upgrade to 2.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Airflow versions 2.7.0 through 2.8.4 have a vulnerability that allows an authenticated user to see sensitive provider configuration via the "configuration" UI page when "non-sensitive-only" was set as "webserver.exposeconfig" configuration (The celery provider is the only community provider currently that has sensitive configurations). You should migrate to Airflow 2.9 or change your "exposeconfig" configuration to False as a workaround. This is similar, but different to CVE-2023-46288 https://github.com/advisories/GHSA-9qqg-mh7c-chfq which concerned API, not UI configuration page.
Recommended action: Upgrade to 2.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Improper Preservation of Permissions vulnerability in Apache Airflow. This issue affects Apache Airflow from 2.8.2 through 2.8.3. Airflow's local file task handler in Airflow incorrectly set permissions for all parent folders of log folder, in default configuration adding write access to Unix group of the folders. In the case Airflow is run with the root user (not recommended) it added group write permission to all folders up to the root of the filesystem. If your log files are stored in the home directory, these permission changes might impact your ability to run SSH operations after your home directory becomes group-writeable. This issue does not affect users who use or extend Airflow using Official Airflow Docker reference images ( https://hub.docker.com/r/apache/airflow/ ) - those images require to have group write permission set anyway. You are affected only if you install Airflow using local installation / virtualenv or other Docker images, but the issue has no impact if docker…
Recommended action: Upgrade to 2.8.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Airflow, versions 2.8.0 through 2.8.2, has a vulnerability that allows an authenticated user with limited permissions to access resources such as variables, connections, etc from the UI which they do not have permission to access. Users of Apache Airflow are recommended to upgrade to version 2.8.3 or newer to mitigate the risk associated with this vulnerability
Recommended action: Upgrade to 2.8.3rc1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.