Cloud credential leak in Apache Airflow Teradata provider
CVSS 3.1
6.5medium
EPSS
—
Published
()
Modified
AI analysis
Apache Airflow's Teradata provider embeds cloud storage credentials as plain string literals in the CREATE MULTISET TABLE ... LOCATION statement issued by S3ToTeradataOperator and AzureBlobStorageToTeradataOperator whenever the source is private and teradata_authorization_name is unset, which is the default. The statement is both executed and logged: S3 credentials from s3_hook.get_credentials(), including unmasked runtime instance-profile or IRSA session tokens, appear in the Airflow task log readable by any user with Dag log-view permission, while both operators write AWS or Azure credentials into Teradata DBQL query logs and live monitoring views that Airflow cannot mask and that persist for Teradata's log retention. Anyone who can read those logs can recover reusable cloud storage credentials. Only deployments that use either operator against a private bucket or container without a Teradata AUTHORIZATION object are affected. No public proof-of-concept is known, and the issue is not listed in CISA KEV.
What to do: Upgrade apache-airflow-providers-teradata to 3.7.0 or later so the credential-bearing statement is kept out of the Airflow task log. Configure teradata_authorization_name with a Teradata AUTHORIZATION object so credentials are never inlined, rotate any credentials previously used on the default inline path, and review Airflow task logs plus Teradata DBQL and monitoring views for leftover secrets, which the upgrade does not remove.
Affected
Apache Software Foundation apache-airflow-providers-teradata
before 3.7.0 (S3ToTeradataOperator and AzureBlobStorageToTeradataOperator)
Estimated exposure
nicheNo basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
Apache Airflow Teradata provider before 3.7.0 embeds cloud storage credentials in SQL and logs (CVE-2026-81862).
CVE-2026-81862, rated moderate, affects the Apache Airflow Teradata provider before version 3.7.0. S3ToTeradataOperator and AzureBlobStorageToTeradataOperator interpolate private source-bucket credentials as plain string literals into the CREATE MULTISET TABLE ... LOCATION statement. Those secrets can appear in the SQL text, Airflow task logs, and Teradata query logs. The disclosure does not report active exploitation.