Wiz wykrył lukę w GitHub Actions Snowflake’a. Red Agent wykorzystał ją pięć dni po wdrożeniu

Incydent Snowflake’a nie był podatnością w kodzie uruchamianym przez klientów wraz z konektorem .NET. Błąd znajdował się w workflow GitHub Actions w publicznym repozytorium snowflakedb/snowflake-connector-net. Zmiana scalona 18 czerwca 2026 roku umieściła kontrolowany przez użytkownika tytuł zgłoszenia GitHub bezpośrednio w poleceniu powłoki. Pięć dni później autonomiczny Red Agent firmy Wiz wykrył lukę i wykorzystał ją podczas autoryzowanego testu prowadzonego przez program HackerOne Snowflake’a.

Jak powstała luka

Podatny kod znajdował się w pliku .github/workflows/jira_issue.yml, uruchamianym po otwarciu zgłoszenia w repozytorium. Pull request nr 1218, zatytułowany „SNOW-2069227: Update Jira workflows”, zastąpił bezpieczniejszy mechanizm — przekazywanie tytułu przez zmienną środowiskową i budowanie JSON-a za pomocą jq — bezpośrednim wstawieniem

${{ github.event.issue.title }}

Miało to kluczowe znaczenie. GitHub rozwija takie wyrażenie, zanim polecenie trafi do powłoki. Tytuł zawierający pojedynczy cudzysłów mógł więc zamknąć pierwotny łańcuch tekstowy i dodać własne polecenia. Późniejsze oczyszczanie wartości za pomocą sed nie mogło już cofnąć interpretacji, do której doszło wcześniej.

Workflow reagował na zdarzenie

issues: opened

Commit wskazywał „Copilot Autofix powered by AI” jako współautora, a wspomagany przez AI przegląd nie wykrył problemu. Nie ma jednak wystarczających dowodów, by stwierdzić, że Copilot wygenerował niebezpieczną zmianę albo że był jej autorem w ścisłym sensie. Najostrożniejszy wniosek brzmi: narzędzie było powiązane ze zmianą i nie wykryło w niej podatności.

Jak Red Agent znalazł i wykorzystał problem

Red Agent skanował publiczną organizację GitHub Snowflake’a pod kątem ryzykownych wzorców w potokach CI/CD. Zidentyfikował workflow Jira, w którym niezaufane dane ze zgłoszenia trafiały do bloku run:, i wywnioskował, że odpowiednio spreparowany tytuł publicznego zgłoszenia może doprowadzić do wykonania dowolnych poleceń na runnerze GitHub Actions.

23 czerwca — pięć dni po scaleniu podatnej zmiany — agent otworzył specjalnie przygotowane zgłoszenie w ramach programu ujawniania podatności HackerOne Snowflake’a. Tytuł wydostał się z łańcucha powłoki, a workflow wysłał dane uwierzytelniające Jira do kontrolowanego przez badaczy, pozapasmowego punktu zwrotnego (out-of-band callback), użytego w autoryzowanym dowodzie koncepcji.

Nie był to niekontrolowany włamanie, lecz usankcjonowany test bezpieczeństwa. Sama luka była jednak rzeczywista: każdy, kto mógł otworzyć publiczne zgłoszenie, mógł doprowadzić do wykonania poleceń w kroku workflow obsługującym dane uwierzytelniające.

Jaki dostęp uzyskano

Uruchomiony workflow miał dostęp do konfiguracji wewnętrznego Jira Snowflake’a, w tym adresu usługi, adresu e-mail użytkownika oraz tokena API. Odzyskany token był powiązany z kontem qa@snowflake.net. Wiz użył go do uwierzytelnienia w wewnętrznym portalu Jira i oceny potencjalnego zasięgu dostępu.

Z opisów wynika, że token zapewniał dostęp odczytu do projektów Jira związanych z inżynierią, zgodnością bezpieczeństwa oraz programem bug bounty. Dostępne materiały nie określają jednak pełnego zestawu uprawnień tokena ani nie zawierają kompletnej listy rekordów, które można było otworzyć. Najpewniejszy wniosek jest więc taki, że token umożliwiał dostęp do wrażliwych wewnętrznych treści Jira, a nie nieograniczony dostęp do systemów Snowflake’a.

Podatnym elementem była automatyzacja CI/CD repozytorium. Nie zgłoszono podatnej wydanej wersji Snowflake Connector for .NET, ponieważ problem znajdował się w workflow GitHub Actions, a nie w kodzie wykonywanym przez sam konektor.

Reakcja Snowflake’a

Wiz zgłosił problem 23 czerwca. Snowflake naprawił workflow tego samego dnia, a następnego dnia obrócił ujawnione dane uwierzytelniające Jira.

Firma przeanalizowała logi audytowe i ustaliła, że w czasie ekspozycji jedynym aktorem był Wiz. Wiz poinformował również, że bezpiecznie usunął dane wykorzystane w dowodzie koncepcji.

Nie zgłoszono nieautoryzowanego dostępu osób trzecich, nie przypisano podatności numeru CVE i nie wskazano żadnej podatnej wersji konektora. Te ograniczenia opisują potwierdzony wpływ incydentu, ale nie oznaczają, że pierwotny projekt workflow był bezpieczny. Tytuł publicznego zgłoszenia nie powinien trafiać bezpośrednio do polecenia powłoki w workflow, który korzysta z wewnętrznych danych uwierzytelniających.

Lekcja dla zespołów CI/CD

Przypadek Snowflake’a pokazuje problem szerszy niż samo Copilot Autofix. Tytuły zgłoszeń i pull requestów, nazwy gałęzi oraz komentarze należy traktować jako potencjalnie wrogie dane za każdym razem, gdy trafiają do polecenia powłoki.

Bezpieczniejszy projekt workflow obejmuje:

• przekazywanie niezaufanych wartości przez zmienne środowiskowe zamiast bezpośredniego wstawiania ich do skryptów run:;
• korzystanie z narzędzi strukturalnych, takich jak jq, do tworzenia JSON-a zamiast składania łańcuchów powłoki;
• odpowiednie cytowanie i walidowanie danych na granicy między workflow a powłoką;
• unikanie udostępniania danych uwierzytelniających krokom przetwarzającym treści kontrolowane przez użytkownika;
• sprawdzanie zmian wygenerowanych przez AI z taką samą starannością jak kod napisany przez człowieka.

To zwięzły przykład nowego wyścigu automatyzacji: jedno narzędzie AI może przeoczyć niebezpieczną zmianę w CI/CD, a autonomiczny agent ofensywny może znaleźć i zweryfikować ją w ciągu kilku dni. Automatyzacja przyspiesza zarówno wykrywanie i naprawę luk, jak i ich wykorzystanie — nie zastępuje jednak niezależnego przeglądu bezpieczeństwa.