CVE-2026-81862None▾ SunlitApache 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…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-86843NoneThe Apache Airflow Teradata provider's compute-cluster example Dag declared every one of its Dag Params as unconstrained free text and templated them straight into the compute-cluster operators, which interpolate those values into Terada…
CVE-2026-87779High· 7.5Insertion of sensitive information into log file vulnerability in Apache Syncope. When AES key of non-standard length (not 16/24/32 bytes) is configured, Syncope will pad the provided value with random characters
CVE-2026-82434Medium· 6.5Description When ZooKeeper authentication is configured, Storm deliberately retains `storm.zookeeper.topology.auth.payload` in the topology configuration, because workers need it
CVE-2025-66236High· 7.5Apache Airflow: Secrets from Airflow config file logged in plain text in DAG run logs UI
CVE-2026-81930NoneApache Airflow's Snowflake provider did not validate the connection's `account` and `region` fields before interpolating them into request URLs
CVE-2026-81914NoneApache Airflow's Google provider built Google Drive search expressions by interpolating file and folder names directly into single-quoted string literals, without escaping the quote character that delimits them