CVE-2026-81862 Apache Airflow Teradata 凭据泄露漏洞
影响云存储凭据泄露至任务日志和数据库
Apache Airflow 的 Teradata provider 中，S3ToTeradataOperator 与 AzureBlobStorageToTeradataOperator 在源存储桶为私有且未配置 teradata_authorization_name 时，会把云存储凭据以明文字符串形式拼接进 CREATE MULTISET TABLE ... LOCATION 语句。该语句随后被记录日志并执行，导致凭据脱离 operator 控制范围。
影响范围
受影响组件为 Apache Airflow 的 Teradata provider，涉及 S3ToTeradataOperator 和 AzureBlobStorageToTeradataOperator 两个算子；具体受影响版本范围暂无公开信息。
漏洞详情
漏洞属于敏感信息明文嵌入与日志泄露问题。当使用默认凭据路径时，算子会把 S3 或 Azure Blob 存储的访问凭据直接拼入 SQL 语句，而非使用授权名称引用。该 SQL 既会被写入 Airflow 任务日志，也会被发送到 Teradata 执行，使凭据暴露在日志和数据库两个位置。
利用条件与风险
利用前提是攻击者具备该 Dag 的日志查看权限，或能访问 Teradata 侧执行的 SQL 记录。S3 场景下通过实例配置文件或 IRSA 获取的运行时凭据及 STS 会话令牌不会被 Airflow 密钥掩码器遮蔽，实战中日志读取权限即可导致凭据泄露。
修复建议
建议升级到修复该问题的 Teradata provider 版本，具体版本号暂无公开信息。临时缓解措施包括为相关算子配置 teradata_authorization_name 以使用授权引用而非内联凭据，并限制 Dag 日志的查看权限。
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.