CVE-2026-81862: CWE-532: Insertion of Sensitive Information into Log File in Apache Software Foundation Apache Airflow Teradata provider
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.
AI Analysis
Technical Summary
The vulnerability (CVE-2026-81862) in Apache Airflow's Teradata provider involves insertion of sensitive cloud storage credentials into SQL statements that are logged both in Airflow task logs and Teradata's DBQL query logs. Specifically, the S3ToTeradataOperator interpolates AWS credentials as plain string literals in SQL statements, which appear in Airflow logs readable by users with log access. The AzureBlobStorageToTeradataOperator similarly exposes Azure storage account keys in Teradata logs. The default configuration without a Teradata AUTHORIZATION object causes credentials to be embedded and logged. The issue is fixed in apache-airflow-providers-teradata version 3.7.0 by removing credentials from Airflow logs, but Teradata logs still retain credentials unless authorization is configured. Credential rotation is recommended for previously exposed secrets.
Potential Impact
Sensitive cloud storage credentials (AWS runtime credentials and Azure storage keys) are exposed in Airflow task logs and Teradata query logs. This exposure allows any user with Airflow log-view permission to access AWS credentials and Teradata administrators to access both AWS and Azure credentials via Teradata logs. This could lead to unauthorized access to cloud storage resources if credentials are compromised. The exposure persists in Teradata logs unless mitigated by configuration changes.
Mitigation Recommendations
Upgrade to apache-airflow-providers-teradata version 3.7.0 or later to prevent credentials from appearing in Airflow task logs. Additionally, configure the Teradata AUTHORIZATION object via the 'teradata_authorization_name' parameter to avoid embedding credentials in SQL statements and Teradata logs. Rotate any credentials that were previously exposed through this vulnerability. Note that Airflow cannot redact credentials from Teradata logs; proper configuration and credential rotation are essential.
CVE-2026-81862: CWE-532: Insertion of Sensitive Information into Log File in Apache Software Foundation Apache Airflow Teradata provider
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.
Affected software
Apache Software Foundation
Apache Airflow Teradata provider
pkg:pypi/apache-airflow-providers-teradataRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability (CVE-2026-81862) in Apache Airflow's Teradata provider involves insertion of sensitive cloud storage credentials into SQL statements that are logged both in Airflow task logs and Teradata's DBQL query logs. Specifically, the S3ToTeradataOperator interpolates AWS credentials as plain string literals in SQL statements, which appear in Airflow logs readable by users with log access. The AzureBlobStorageToTeradataOperator similarly exposes Azure storage account keys in Teradata logs. The default configuration without a Teradata AUTHORIZATION object causes credentials to be embedded and logged. The issue is fixed in apache-airflow-providers-teradata version 3.7.0 by removing credentials from Airflow logs, but Teradata logs still retain credentials unless authorization is configured. Credential rotation is recommended for previously exposed secrets.
Potential Impact
Sensitive cloud storage credentials (AWS runtime credentials and Azure storage keys) are exposed in Airflow task logs and Teradata query logs. This exposure allows any user with Airflow log-view permission to access AWS credentials and Teradata administrators to access both AWS and Azure credentials via Teradata logs. This could lead to unauthorized access to cloud storage resources if credentials are compromised. The exposure persists in Teradata logs unless mitigated by configuration changes.
Mitigation Recommendations
Upgrade to apache-airflow-providers-teradata version 3.7.0 or later to prevent credentials from appearing in Airflow task logs. Additionally, configure the Teradata AUTHORIZATION object via the 'teradata_authorization_name' parameter to avoid embedding credentials in SQL statements and Teradata logs. Rotate any credentials that were previously exposed through this vulnerability. Note that Airflow cannot redact credentials from Teradata logs; proper configuration and credential rotation are essential.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- apache
- Date Reserved
- 2026-08-27T16:50:11.575Z
- State
- PUBLISHED
- Is Cloud Service
- true
Threat ID: 6abb9075f7a7c54106366dda
Added to database: 09/29/2026, 10:18:29 UTC
Last enriched: 09/29/2026, 10:33:10 UTC
Last updated: 09/29/2026, 18:20:13 UTC
Views: 14
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.