CVE-2026-81862 json
Apache Airflow Teradata provider: Teradata transfer operators embed cloud storage credentials in SQL text, task logs and Teradata query logs
published last mo. modified last mo. also EUVD-2026-88695
- cvss
- 6.5
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.4%
- EPSS 0.4% chance of exploitation in 30 days, percentile 34%
- public exploits
- 0
- none known
Summary
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.
Patch / fix
- Apache Software Foundation Apache Airflow Teradata provider 3.7.0
- github.com/apache/airflow#72176 pull request
Is CVE-2026-81862 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCISA SSVC
- Exploitation
- none
- Automatable
- no
- Technical impact
- partial
- Assessed
- last mo.
Exploit prediction
0.40% chance of exploitation in the next 30 days, higher than 34% of all scored CVEs (FIRST EPSS, 2026-11-11).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CISA ADP | 3.1 | 6.5 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N |
| CNA | 3.1 | 6.5 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N |
Affected products
- Apache Software Foundation Apache Airflow Teradata provider
Classification
- Weakness
-
- CWE-532 Insertion of Sensitive Information into Log File
References
-
github.com
/apache/airflow/pull/72176
patch, issue-tracking
-
lists.apache.org
/thread/0vfpoh6l8gz0dpbc9z50dmkc3z07o83l
vendor-advisory, mailing-list
-
openwall.com
/lists/oss-security/2026/09/29/11
mailing-list, third-party-advisory
Sources
- CVE List CVE-2026-81862
- NVD CVE-2026-81862
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.