Description
Apache Airflow's Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket's credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured — which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator's control.

The two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow's secrets masker — and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata's DBQL query logs and live monitoring views, where Airflow's masking never applies and the values persist for that system's log retention period.

Affects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata's query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path.
Published: 2026-09-29
Score: n/a
EPSS: n/a
KEV: No
Impact: Credential Exposure
Action: Immediate Patch
AI Analysis

Impact

Apache Airflow’s Teradata provider can embed cloud storage credentials directly into SQL statements when using S3ToTeradataOperator or AzureBlobStorageToTeradataOperator. This flaw causes credentials to appear in the task log and, more critically, in Teradata’s DBQL query logs and monitoring views. As a result, any user with access to Airflow logs or Teradata monitoring can obtain the credentials, leading to unauthorized access to cloud storage buckets or containers.

Affected Systems

The vulnerability affects deployments of Apache Airflow using the Teradata provider where the operator is configured to transfer data to a private Teradata table and the supplier does not supply a teradata_authorization_name. Specifically, it applies to the S3ToTeradataOperator and AzureBlobStorageToTeradataOperator in versions prior to the 3.7.0 upgrade of apache-airflow-providers-teradata.

Risk and Exploitability

The flaw is identified as CWE‑532 (Information Exposure Through Log Files). No CVSS score is available, but the lack of necessary credentials in an authorization object and the default inline embedding pattern suggest a high potential impact. The EPSS score is not available, making it difficult to gauge current exploitation likelihood, yet the exposure of sensitive credentials typically carries substantial risk. The problem is not currently listed in the CISA KEV catalog, but it remains a critical concern due to the clear path for credential leakage.

Generated by OpenCVE AI on September 29, 2026 at 17:26 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade apache-airflow-providers-teradata to version 3.7.0 or newer, which removes credentials from the Airflow task log.
  • Configure teradata_authorization_name with a Teradata AUTHORIZATION object so that credentials are referenced rather than inlined.
  • Rotate any credentials that may have been exposed through the legacy inline method before the upgrade.
  • Ensure Airflow secret masking is configured to redact any remaining credential strings in logs, and restrict log‑view permissions to trusted users.

Generated by OpenCVE AI on September 29, 2026 at 17:26 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 29 Sep 2026 13:15:00 +0000

Type Values Removed Values Added
Description Apache Airflow's Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket's credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured — which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator's control. The two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow's secrets masker — and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata's DBQL query logs and live monitoring views, where Airflow's masking never applies and the values persist for that system's log retention period. Affects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata's query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path.
Title Apache Airflow Teradata provider: Teradata transfer operators embed cloud storage credentials in SQL text, task logs and Teradata query logs
Weaknesses CWE-532
References

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-09-29T20:04:41.683Z

Reserved: 2026-08-27T16:50:11.575Z

Link: CVE-2026-81862

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-09-29T10:17:12.367

Modified: 2026-09-29T15:53:48.653

Link: CVE-2026-81862

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-29T17:30:17Z

Weaknesses
  • CWE-532

    Insertion of Sensitive Information into Log File