Luka bezpieczeństwa zidentyfikowana jako CVE-2026-15067 otrzymała ocenę 8.8 w skali CVSS (Common Vulnerability Scoring System – skala 0-10 oceniająca powagę luki). Dotyczy ona kilku podatności w popularnym narzędziu do automatyzacji infrastruktury chmurowej. Problem występuje w wersjach Snowflake Terraform Provider starszych niż 2.18.0 1. Narzędzia tego typu są często wykorzystywane w polskich firmach technologicznych i startupach do zarządzania hurtowniami danych, co czyni tę lukę istotną dla lokalnego rynku.

TL;DR

  • Produkt: Snowflake Terraform Provider, wersje starsze niż 2.18.0 1.
  • Wektor: SQL Injection 2 oraz DDL Injection 3.
  • Identyfikator: CVE-2026-15067.
  • Wpływ: Zdalne wykonanie kodu SQL 4, eksfiltracja danych 5, tworzenie kont z poświadczeniami kontrolowanymi przez atakującego 6.
  • Kogo dotyczy: Zespoły DevOps i data engineering w firmach używających Terraform do zarządzania infrastrukturą Snowflake. W Polsce dotyczy to zwłaszcza sektora finansowego i e-commerce, gdzie Snowflake to popularne rozwiązanie.
  • Pierwszy ruch: Identyfikacja używanych wersji providera i natychmiastowa, ręczna aktualizacja do wersji 2.18.0 lub nowszej 7 8.

Wektor ataku

Analiza wskazuje na dwa główne wektory ataku, bazujące na wstrzyknięciu złośliwego kodu do zapytań wykonywanych na platformie Snowflake.

Pierwszy wektor to klasyczny SQL Injection (wstrzyknięcie SQL). Luka powstaje przez brak odpowiedniego filtrowania danych wejściowych pochodzących ze źródła danych 2. Jeśli atakujący może wpłynąć na zawartość zmiennej w środowisku CI/CD (Continuous Integration/Continuous Deployment), gdzie uruchamiany jest Terraform, może wstrzyknąć dowolny kod SQL 9. Kod ten zostanie wykonany w kontekście uprzywilejowanej sesji, z której korzysta provider Terraform 4. Konsekwencje mogą być poważne: od eksfiltracji wrażliwych danych 5 po tworzenie długotrwałych poświadczeń dostępowych 10. Dla polskiej firmy oznacza to ryzyko naruszenia RODO (Rozporządzenia o Ochronie Danych Osobowych) i wysokich kar finansowych.

Drugi wektor to DDL Injection. DDL (Data Definition Language) to podzbiór SQL służący do zarządzania strukturą bazy danych, w tym do tworzenia i modyfikowania użytkowników. W tym przypadku, nieprawidłowa neutralizacja identyfikatorów w zasobach użytkownika może pozwolić na wstrzyknięcie poleceń DDL do instrukcji zarządzających kontami 3. W praktyce atakujący może w ten sposób tworzyć nowe konta użytkowników z poświadczeniami, które sam kontroluje 6. Co istotne, konta te mogą być tworzone z pominięciem standardowych polityk i kontroli bezpieczeństwa skonfigurowanych przez administratora 11. Daje to atakującemu cichy i trwały dostęp do środowiska danych.

Wskaźniki kompromitacji

Źródło opisujące lukę nie dostarcza gotowych wskaźników kompromitacji (IoC – Indicators of Compromise), takich jak adresy IP czy hashe plików. Jest to typowe dla alertów o podatnościach, a nie aktywnych kampanii. Zalecamy proaktywne poszukiwanie anomalii w logach Snowflake.

Należy zwrócić uwagę na:

  • Niespodziewane lub nietypowe zapytania SQL pochodzące z konta serwisowego używanego przez Terraform.
  • Próby tworzenia nowych użytkowników lub ról poza standardowymi procesami i oknami serwisowymi.
  • Nowo utworzone konta użytkowników z nietypowymi nazwami lub uprawnieniami, zwłaszcza te, które nie przeszły przez wewnętrzny proces onboardingu.

Co zrobić w 24-48h

Zalecane podejście zakłada natychmiastowe działanie w celu mitygacji ryzyka. Poniższe kroki nie zastępują pełnej analizy incydentu, lecz stanowią pierwszą linię obrony.

  1. Audyt zależności: Zidentyfikuj wszystkie projekty i potoki CI/CD w organizacji, które wykorzystują Snowflake Terraform Provider. Sprawdź pliki terraform.lock.hcl lub logi z wykonania terraform init w celu znalezienia używanej wersji.

  2. Pilna aktualizacja: Dla każdego zidentyfikowanego projektu, zaktualizuj provider do wersji 2.18.0 lub nowszej 7. Proces ten musi być wykonany ręcznie 8. W pliku konfiguracyjnym Terraform (.tf) należy zaktualizować wymaganie wersji:

    terraform {
  required_providers {
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = ">= 2.18.0"
    }
  }
}

    Następnie należy uruchomić terraform init -upgrade.

  3. Przegląd logów: Przeprowadź audyt logów dostępowych i zapytań w Snowflake z ostatnich 30-90 dni. Poszukaj anomalii opisanych w sekcji „Wskaźniki kompromitacji”. Zwróć szczególną uwagę na aktywność konta serwisowego używanego przez Terraform.

  4. Weryfikacja uprawnień: Ogranicz uprawnienia konta serwisowego Terraform do absolutnego minimum wymaganego do jego działania (zasada najmniejszych uprawnień). To działanie może ograniczyć potencjalne szkody w przypadku przyszłych luk.

  5. Zabezpieczenie potoków CI/CD: Przeanalizuj, kto i w jaki sposób może modyfikować zmienne środowiskowe w potokach wdrażających infrastrukturę. Dostęp do modyfikacji tych zmiennych jest warunkiem koniecznym do wykorzystania luki SQL Injection 9.

Źródła

Zobacz też

Przypisy

  1. Wersje Snowflake Terraform Provider starsze niż 2.18.0 zawierają kilka luk bezpieczeństwa. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  2. Jedną z luk jest SQL injection poprzez niesprawdzony input źródła danych. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  3. Nieprawidłowa neutralizacja zawartości identyfikatora w danych wejściowych zasobów użytkownika może pozwolić na DDL injection do instrukcji zarządzania użytkownikami. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  4. SQL injection może prowadzić do wykonania dowolnego kodu SQL w ramach uprzywilejowanej sesji Snowflake dostawcy. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  5. Może to potencjalnie umożliwić eksfiltrację wrażliwych danych. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  6. DDL injection może potencjalnie spowodować tworzenie kont z poświadczeniami kontrolowanymi przez atakującego. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  7. Poprawka jest dostępna w wersji 2.18.0 Snowflake Terraform Provider. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  8. Użytkownicy muszą ręcznie zaktualizować oprogramowanie. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  9. Wykorzystanie tej luki wymaga, aby atakujący mógł wpływać na zmienną obszaru roboczego w potoku, gdzie to źródło danych było włączone. — nvd.nist.gov › CVE 2026 15067 ↩ ↩2

  10. Może to również umożliwić tworzenie długotrwałych poświadczeń dostępu. — nvd.nist.gov › CVE 2026 15067 ↩

  11. Konta te mogą być tworzone bez kontroli bezpieczeństwa skonfigurowanych przez operatora. — nvd.nist.gov › CVE 2026 15067 ↩