Airflow Teradata Provider CVE-2026-81862

Requires a deployment running S3ToTeradataOperator or AzureBlobStorageToTeradataOperator against a private S3 bucket or Azure container with NO teradata_authorization_name (AUTHORIZATION object) configured - which is the default credential path for both operators. Exposure is realized only for a party with read access to one of two log sinks: Airflow task logs (needs log-view permission on the Dag; primary channel for S3ToTeradataOperator's runtime AWS credentials and STS token, which the secrets masker does not cover) or Teradata's DBQL query logs and monitoring views (affects both operators and is never masked, persisting for Teradata's log retention). Limiting factors: not remotely exploitable without existing log-read privileges, does not apply when an AUTHORIZATION object is used, and Azure's storage-account key is usually masked in the Airflow task log (leaving its Teradata-side exposure).

This is an information-disclosure weakness (credential exposure via logs, CWE-532/CWE-312 class) rated moderate by the Apache Airflow project. No CVSS vector, EPSS score, or SSVC data was supplied, and there is no CISA KEV listing and no public exploit - the issue was found by an automated tool (Claude Security Scans) and fixed by an Airflow maintainer, not surfaced through observed attacks. Exploitation is passive and requires pre-existing access: an Airflow user with log-view permission on the affected Dag can read runtime AWS credentials (including the unmasked STS session token from instance-profile/IRSA) that S3ToTeradataOperator inlines into task logs, or anyone with access to Teradata's DBQL query logs and monitoring views can read the inlined credentials for either operator. This is therefore a real but bounded insider/lateral-movement risk rather than a mass-exploitable network flaw: the value is high (working cloud storage credentials), but it is gated behind existing log-read privileges on either Airflow or Teradata and behind a specific operator/configuration combination. No signals are contradictory here - the absence of EPSS/KEV/POC is consistent with a quietly-fixed low-noise disclosure bug. Priority is low-to-medium: prioritize where these operators run against private buckets without an AUTHORIZATION object and where log-viewer or DBQL access is broadly granted.

An analyst or contractor holding read-only log-view permission on a Dag opens the task log for an S3ToTeradataOperator run against a private bucket and finds live AWS access key, secret, and STS session token inlined in the CREATE MULTISET TABLE ... LOCATION statement, then uses them to access the S3 bucket directly. Alternatively, a Teradata database user with access to DBQL query logs harvests the same (or Azure storage-account) credentials, which Airflow's masker cannot redact. No public exploit code exists; the flaw was identified by an automated scanning tool and requires only routine log-read access, not a crafted payload.