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: 6.5 Medium
EPSS: < 1% Very Low
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 the 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, enabling unauthorized access to cloud storage buckets or containers.

Affected Systems

The vulnerability affects deployments of Apache Airflow using the Teradata provider where either operator is configured to transfer data to a private Teradata table and no teradata_authorization_name is supplied. This applies to both S3ToTeradataOperator and AzureBlobStorageToTeradataOperator in apache-airflow-providers-teradata versions earlier than 3.7.0.

Risk and Exploitability

The CVSS score for this vulnerability is 6.5, reflecting moderate severity. The EPSS score is not available, so the current exploitation likelihood is uncertain. This issue is not listed in the CISA KEV catalog. The vulnerability, classed as CWE-532, exposes credentials in logs, allowing an adversary with access to Airflow task logs or Teradata DBQL logs to harvest the credentials and potentially compromise the associated cloud storage resources.

Generated by OpenCVE AI on September 30, 2026 at 11:04 UTC.

Remediation

No solution or workaround provided in the CVE record.

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.

Generated by OpenCVE AI on September 30, 2026 at 11:04 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 07 Oct 2026 20:15:00 +0000

Type Values Removed Values Added
First Time appeared Apache apache-airflow-providers-teradata
CPEs cpe:2.3:a:apache:apache-airflow-providers-teradata:*:*:*:*:*:*:*:*
Vendors & Products Apache apache-airflow-providers-teradata

Wed, 30 Sep 2026 21:00:00 +0000

Type Values Removed Values Added
First Time appeared Apache
Apache airflow Teradata Provider
Vendors & Products Apache
Apache airflow Teradata Provider

Tue, 29 Sep 2026 21:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N'}

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

Apache Airflow Teradata Provider Apache-airflow-providers-teradata
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 : Analyzed

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

Modified: 2026-10-07T20:05:46.770

Link: CVE-2026-81862

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-30T20:42:42Z

Weaknesses
  • CWE-532

    Insertion of Sensitive Information into Log File