Insertion of Sensitive Information into Log File Affecting apache-airflow-providers-teradata package, versions [0,3.7.0rc1)
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsSnyk Learn
Learn about Insertion of Sensitive Information into Log File vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-PYTHON-APACHEAIRFLOWPROVIDERSTERADATA-20257417
- published29 Sept 2026
- disclosed29 Sept 2026
Introduced: 29 Sep 2026
NewCVE-2026-81862 (opens in a new tab)How to fix?
Upgrade apache-airflow-providers-teradata to version 3.7.0rc1 or higher.
Overview
apache-airflow-providers-teradata is a Provider package apache-airflow-providers-teradata for Apache Airflow
Affected versions of this package are vulnerable to Insertion of Sensitive Information into Log File via the execute method in azure_blob_to_teradata.py and s3_to_teradata.py, when no teradata_authorization_name is configured and the object store is private. Both AzureBlobStorageToTeradataOperator and S3ToTeradataOperator embed object store credentials directly inside the CREATE TABLE SQL statement, and DbApiHook logs every statement it executes, causing the plaintext credentials to be written to the Airflow task log on each run. For S3ToTeradataOperator, credentials obtained via s3_hook.get_credentials() under an instance profile or IRSA are runtime AWS credentials that were never registered with Airflow's secrets masker, meaning the STS session token is unmasked even when an AWS connection is configured. Additionally, Teradata records the statement in its own query logs (DBQL) and monitoring views, which Airflow cannot redact, exposing the credentials to anyone with access to those logs.
Note: This is only exploitable when teradata_authorization_name is not set and the object store bucket is private.