{
  "containers": {
    "cna": {
      "providerMetadata": {
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09"
      },
      "title": "Cross-team authorization bypass in the asset materialization and dag-run result endpoints",
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "CWE-862: Missing Authorization",
              "lang": "en",
              "cweId": "CWE-862",
              "type": "CWE"
            }
          ]
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "affected": [
        {
          "vendor": "Apache Software Foundation",
          "product": "Apache Airflow",
          "collectionURL": "https://pypi.python.org",
          "packageName": "apache-airflow",
          "versions": [
            {
              "status": "affected",
              "version": "0",
              "lessThan": "3.3.1",
              "versionType": "semver"
            }
          ],
          "defaultStatus": "unaffected"
        }
      ],
      "descriptions": [
        {
          "value": "Apache Airflow's asset materialization endpoint (`POST /api/v2/assets/{asset_id}/materialize`) and the XCom result check on `wait_dag_run_until_finished` authorized the target Dag without its team, unlike every other authorization site. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the `DAG` resource instead of `DAG:<team>` -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own `dag_run_id` and `conf`, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag's team at both sites.",
          "lang": "en",
          "supportingMedia": [
            {
              "type": "text/html",
              "base64": false,
              "value": "Apache Airflow&#x27;s asset materialization endpoint (`POST /api/v2/assets/{asset_id}/materialize`) and the XCom result check on `wait_dag_run_until_finished` authorized the target Dag without its team, unlike every other authorization site. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the `DAG` resource instead of `DAG:&lt;team&gt;` -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own `dag_run_id` and `conf`, and could read another team&#x27;s XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag&#x27;s team at both sites."
            }
          ]
        }
      ],
      "references": [
        {
          "url": "https://github.com/apache/airflow/pull/70893",
          "tags": [
            "patch"
          ]
        },
        {
          "url": "https://lists.apache.org/thread/kfxqqwgojdjdnt6bxg3ord4y41y334fo",
          "tags": [
            "vendor-advisory"
          ]
        }
      ],
      "metrics": [
        {
          "other": {
            "type": "Textual description of severity",
            "content": {
              "text": "moderate"
            }
          }
        }
      ],
      "credits": [
        {
          "lang": "en",
          "value": "@haoxucu",
          "type": "finder"
        },
        {
          "lang": "en",
          "value": "Jarek Potiuk",
          "type": "remediation developer"
        }
      ],
      "x_generator": {
        "engine": "airflow-s/generate_cve_json.py"
      }
    }
  },
  "cveMetadata": {
    "cveId": "CVE-2026-68971",
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "serial": 1,
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}