CVE-2026-81862: Apache Airflow Teradata provider: Teradata transfer operators embed cloud storage credentials in SQL text, task logs and Teradata query logs
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 teradataauthorizationname 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 s3hook.getcredentials(), 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 teradataauthorizationname with a Teradata AUTHORIZATION object so that credentials are never inlined, and should rotate any credentials previously used through the inline path.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
apache-airflow-providers-teradatato a version that resolves this vulnerability.Fixed in 3.7.0 - Configuration
Configure teradata_authorization_name with a Teradata AUTHORIZATION object so cloud storage credentials are not inlined in the SQL statement.
Apache Airflow Teradata transfer operators teradata_authorization_name = Teradata AUTHORIZATION object - Operational
Rotate any cloud storage credentials previously used through the inline credential path.
Event History
Frequently Asked Questions
Which configurations take the credential-exposing path?
Both operators do so when their cloud storage source is private and no teradata_authorization_name is configured. This is described as the default credential path for both operators.
Who can retrieve exposed AWS credentials from Airflow logs?
For S3ToTeradataOperator, any user with permission to view the DAG's task logs can read the runtime AWS credentials. This especially affects instance-profile and IRSA deployments, because those credentials were not registered with Airflow's secrets masker and the runtime-generated STS token is unmasked.
What can be changed if patching is not immediately possible?
Configure a teradata_authorization_name for private cloud storage sources. The credential interpolation described occurs when that authorization name is absent.
Where should teams look for evidence of prior exposure?
Review Airflow task logs and Teradata query logs for CREATE MULTISET TABLE ... LOCATION statements generated by these operators. The SQL statement is logged and executed, placing credentials in those logging locations.