CVE-2026-81862: Apache Airflow Teradata Provider Exposure

CVE-2026-81862 Overview

CVE-2026-81862 affects the Apache Airflow Teradata provider. The S3ToTeradataOperator and AzureBlobStorageToTeradataOperator embed cloud storage credentials directly into CREATE MULTISET TABLE ... LOCATION SQL statements. This occurs when the source bucket is private and no teradata_authorization_name is configured, which is the default path for both operators. The credential-bearing statement is then logged and executed, exposing secrets in two locations outside the operator's control: the Airflow task log and Teradata's DBQL query logs and monitoring views [CWE-532].

Critical Impact
Runtime AWS credentials from instance profiles or IRSA, along with Azure storage account keys, can be exposed in task logs and Teradata query logs where Airflow's secrets masking does not apply.

Affected Products

apache-airflow-providers-teradata versions prior to 3.7.0
Deployments using S3ToTeradataOperator against a private S3 bucket without a Teradata AUTHORIZATION object
Deployments using AzureBlobStorageToTeradataOperator against a private Azure container without a Teradata AUTHORIZATION object

Discovery Timeline

2026-09-29 - CVE-2026-81862 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-81862

Vulnerability Analysis

The flaw is an information exposure through log files [CWE-532]. Both operators build the Teradata CREATE MULTISET TABLE ... LOCATION statement by interpolating source-bucket credentials as plain string literals when no teradata_authorization_name is set. Airflow then logs and executes the finished statement, so the credential values leave the operator through two channels the operator does not control.

The two operators expose credentials from different sources. S3ToTeradataOperator reads values from s3_hook.get_credentials(). Under an EC2 instance profile or IRSA, that call returns runtime AWS credentials, including an STS session token that Airflow's secrets masker never registered. Those unmasked values appear in the Airflow task log and are readable by any user with log-view permission on the DAG. AzureBlobStorageToTeradataOperator reads its storage account key from the Airflow connection, so the masker usually redacts the task-log copy.

Both operators write credentials into Teradata's DBQL query logs and live monitoring views. Airflow's masking cannot reach those artifacts, and the credentials persist there for the retention period configured on the Teradata system.

Root Cause

The operators build SQL by string interpolation of secrets rather than referencing a Teradata AUTHORIZATION object. The s3_hook.get_credentials() code path also returns runtime STS tokens that were never handed to Airflow's secrets masker, defeating masker-based redaction even when an AWS connection exists.

Attack Vector

An authenticated Airflow user with log-view permission on an affected DAG can read AWS runtime credentials directly from the task log. A database user or operator with access to Teradata's DBQL query logs or monitoring views can read both AWS and Azure credentials for the retention window of the Teradata system. Refer to the GitHub Pull Request for Airflow and the Apache Mailing List Thread for implementation details.

// No verified proof-of-concept code is published for this issue.
// See the linked pull request for the code path and the applied fix.

Detection Methods for CVE-2026-81862

Indicators of Compromise

Airflow task logs containing CREATE MULTISET TABLE statements with inline ACCESS_ID, ACCESS_KEY, or SESSION_TOKEN values from S3 transfers
Teradata DBQL query log entries containing LOCATION clauses with embedded cloud storage credentials
Historical DAG runs of S3ToTeradataOperator or AzureBlobStorageToTeradataOperator executed without teradata_authorization_name

Detection Strategies

Scan Airflow task log storage for regular expressions matching AWS access key IDs (AKIA[0-9A-Z]{16}), STS session tokens, or Azure storage account key patterns near CREATE MULTISET TABLE text
Query Teradata DBC.DBQLogTbl and equivalent monitoring views for LOCATION clauses that include credential material
Audit provider versions across all Airflow deployments to identify installations running apache-airflow-providers-teradata earlier than 3.7.0

Monitoring Recommendations

Alert on any read access to task logs of DAGs that use the affected operators until credentials are rotated
Monitor cloud provider audit logs (AWS CloudTrail, Azure Activity Log) for unusual use of the exposed credentials from unexpected principals or IP ranges
Track configuration drift on Airflow deployments to confirm continued use of teradata_authorization_name

How to Mitigate CVE-2026-81862

Immediate Actions Required

Upgrade apache-airflow-providers-teradata to 3.7.0 or later on all Airflow deployments
Rotate any AWS and Azure credentials that were previously used through the inline credential path
Configure teradata_authorization_name on both operators to reference a Teradata AUTHORIZATION object so credentials are never inlined
Purge existing Airflow task logs that contain exposed credentials, subject to retention policy

Patch Information

The fix is available in apache-airflow-providers-teradata version 3.7.0. The patched provider keeps the credential-bearing statement out of the Airflow task log. Upgrading alone does not remove credentials already recorded in Teradata's DBQL query logs and monitoring views. Details are available in the GitHub Pull Request for Airflow and the OpenWall OSS Security Update.

Workarounds

Create a Teradata AUTHORIZATION object for each source bucket or container and set teradata_authorization_name on the operator so credentials are resolved server-side
Restrict Airflow log-view permissions on DAGs that use the affected operators to a minimum set of trusted operators
Reduce DBQL retention on the Teradata system, or purge query log rows that contain credential material, in line with local change control

bash

# Upgrade the provider and reference a Teradata AUTHORIZATION object
pip install --upgrade 'apache-airflow-providers-teradata>=3.7.0'

# Operator configuration example (Python)
# S3ToTeradataOperator(
#     task_id="load_from_s3",
#     s3_source_key="s3://private-bucket/path/",
#     teradata_table="target_table",
#     teradata_authorization_name="MyS3Authorization",
# )