Odebrany

CVE-2026-81862

opublikowano: 29.09.2026, 12:17

modyfikacja: 29.09.2026, 23:19

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

Dostawca Teradata Apache Airflow osadził dane uwierzytelniające magazynu w chmurze bezpośrednio w instrukcjach SQL. Funkcje `S3ToTeradataOperator` i `AzureBlobStorageToTeradataOperator` interpolują poświadczenia zasobnika źródłowego jako zwykłe literały ciągu do instrukcji `CREATE MULTISET TABLE ... LOCATION` za każdym razem, gdy zasobnik jest prywatny i nie skonfigurowano `teradata_authorization_name` — która jest domyślną ścieżką poświadczeń dla obu operatorów. Instrukcja jest następnie rejestrowana i wykonywana, dzięki czemu dane uwierzytelniające docierają do dwóch miejsc poza kontrolą operatora.

Obaj operatorzy udostępniają różne poświadczenia za pośrednictwem różnych kanałów, a wdrożenia powinny sprawdzać oba. `S3ToTeradataOperator` pobiera swoje wartości z `s3_hook.get_credentials()`, które w profilu instancji lub IRSA zwraca poświadczenia AWS środowiska wykonawczego, które nigdy nie były zarejestrowane za pomocą maski sekretów Airflow — a token sesji STS jest generowany przez środowisko wykonawcze i dlatego jest demaskowany nawet wtedy, gdy skonfigurowane jest połączenie AWS. Te dane uwierzytelniające pojawiają się **w dzienniku zadań Airflow** i mogą być odczytane przez każdego użytkownika z uprawnieniami do przeglądania dziennika na Dagu. `AzureBlobStorageToTeradataOperator` pobiera klucz konta magazynu z połączenia, więc masker zwykle redaguje kopię dziennika zadań; jego ekspozycja to strona Teradata. **Obydwaj** operatorzy zapisują dane uwierzytelniające w dziennikach zapytań DBQL firmy Teradata i w widokach monitorowania na żywo, gdzie maskowanie Airflow nigdy nie ma zastosowania, a wartości pozostają niezmienne przez okres przechowywania dzienników systemu.

Ma wpływ na wdrożenia przy użyciu dowolnego operatora w prywatnym zasobniku lub kontenerze bez obiektu „AUTHORIZATION” Teradata. Użytkownikom zaleca się aktualizację do wersji `apache-airflow-providers-teradata` `3.7.0` lub nowszej, dzięki czemu instrukcja zawierająca dane uwierzytelniające nie będzie widoczna w dzienniku zadań Airflow. Aktualizacja nie usuwa poświadczeń z dzienników zapytań Teradata i widoków monitorowania, których Airflow nie może zredagować: użytkownicy powinni skonfigurować `teradata_authorization_name` z obiektem Teradata `AUTHORIZATION`, tak aby poświadczenia nigdy nie były wstawione, i powinni zmienić wszelkie poświadczenia używane wcześniej w ścieżce wbudowanej.

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.

>_ Słabości (CWE)

CWE-532

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve