Apache Airflow Providers Teradata
Monthly
SQL injection in the Apache Airflow Teradata provider's compute-cluster example DAG lets an authenticated Airflow user who holds only permission to trigger that DAG - a lower-trust role needing no Teradata credentials of its own - inject SQL fragments through unvalidated DAG Params that are templated directly into Teradata DDL, executing under whatever connection the task runs as and, because the connection id was itself a free-text Param, redirecting the task to any other connection defined in the deployment. Only deployments that actually run the shipped example DAG or a DAG copied from it are exposed; the provider's operator code is unchanged, and versions before 3.7.0 are affected. No KEV entry, EPSS score, or public exploit code was identified at time of analysis, and the vendor/reporter rating is 'low', though the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) reflects high confidentiality, integrity, and availability impact when the preconditions are met.
Credential disclosure in the Apache Airflow Teradata provider (apache-airflow-providers-teradata before 3.7.0) causes cloud storage secrets to be written into SQL text that is then logged and executed, leaking those secrets to two sinks outside Airflow's control. Deployments using S3ToTeradataOperator or AzureBlobStorageToTeradataOperator against a private bucket or container with no teradata_authorization_name configured - the default credential path for both operators - are affected; S3ToTeradataOperator's runtime AWS credentials and STS session token land in the Airflow task log, readable by any user with log-view permission on the Dag, while both operators write credentials into Teradata's DBQL query logs and live monitoring views, where Airflow masking never applies and the values persist for Teradata's log retention period. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, i.e. remote but requiring an already-privileged party with log-read access, and no public exploit identified at time of analysis; impact is information disclosure only, with no integrity or availability effect.
SQL injection in the Apache Airflow Teradata provider's compute-cluster example DAG lets an authenticated Airflow user who holds only permission to trigger that DAG - a lower-trust role needing no Teradata credentials of its own - inject SQL fragments through unvalidated DAG Params that are templated directly into Teradata DDL, executing under whatever connection the task runs as and, because the connection id was itself a free-text Param, redirecting the task to any other connection defined in the deployment. Only deployments that actually run the shipped example DAG or a DAG copied from it are exposed; the provider's operator code is unchanged, and versions before 3.7.0 are affected. No KEV entry, EPSS score, or public exploit code was identified at time of analysis, and the vendor/reporter rating is 'low', though the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) reflects high confidentiality, integrity, and availability impact when the preconditions are met.
Credential disclosure in the Apache Airflow Teradata provider (apache-airflow-providers-teradata before 3.7.0) causes cloud storage secrets to be written into SQL text that is then logged and executed, leaking those secrets to two sinks outside Airflow's control. Deployments using S3ToTeradataOperator or AzureBlobStorageToTeradataOperator against a private bucket or container with no teradata_authorization_name configured - the default credential path for both operators - are affected; S3ToTeradataOperator's runtime AWS credentials and STS session token land in the Airflow task log, readable by any user with log-view permission on the Dag, while both operators write credentials into Teradata's DBQL query logs and live monitoring views, where Airflow masking never applies and the values persist for Teradata's log retention period. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, i.e. remote but requiring an already-privileged party with log-read access, and no public exploit identified at time of analysis; impact is information disclosure only, with no integrity or availability effect.