Wprowadzenie do problemu / definicja
W publicznym repozytorium powiązanym ze Snowflake ujawniono podatność typu workflow injection w GitHub Actions, która pozwalała na uruchamianie poleceń systemowych za pomocą odpowiednio spreparowanego zgłoszenia typu issue. Problem nie dotyczył bezpośrednio produktu Snowflake, lecz procesu automatyzacji CI/CD, jednak z perspektywy bezpieczeństwa łańcucha dostaw miał istotne znaczenie.
Źródłem ryzyka było przetwarzanie danych pochodzących od niezaufanego użytkownika w tym samym kroku workflow, który dysponował poufnymi danymi uwierzytelniającymi do Jira. Taki układ tworzył warunki do przejęcia sekretów oraz wykonania nieautoryzowanych działań w środowisku runnera.
W skrócie
Badacze bezpieczeństwa wykazali, że publiczne zgłoszenie w repozytorium mogło doprowadzić do command injection w zadaniu GitHub Actions. Bezpośrednią przyczyną było osadzanie kontrolowanych przez użytkownika pól tytułu i treści zgłoszenia bezpośrednio w bloku wykonywanym przez powłokę.
W praktyce umożliwiało to wykonanie poleceń na runnerze oraz pozyskanie tokenu API Jira używanego przez workflow. Luka została zgłoszona 23 czerwca 2026 roku i usunięta tego samego dnia, a ujawniony token następnie zrotowano. Nie opublikowano dowodów wskazujących na nadużycie poza autoryzowanym testem badawczym.
Kontekst / historia
Incydent dotyczył workflow uruchamianego po otwarciu publicznego issue w repozytorium. Automatyzacja była związana z integracją z Jira i działała w kontekście, w którym dostępne były dane wrażliwe potrzebne do obsługi zgłoszeń.
Luka pojawiła się po zmianach wprowadzonych do domyślnej gałęzi 18 czerwca 2026 roku, co oznacza, że ekspozycja trwała około pięciu dni. Choć nie była to podatność w bibliotece Snowflake Connector for .NET ani w samej platformie Snowflake, przypadek wpisuje się w szerszy problem bezpieczeństwa pipeline’ów deweloperskich i błędów w logice workflow.
Tego typu incydenty są szczególnie ważne, ponieważ procesy CI/CD mają często dostęp do sekretów, systemów zgłoszeniowych, rejestrów artefaktów i narzędzi publikacyjnych. Błąd w automatyzacji może więc stać się punktem wejścia do dalszych działań ofensywnych.
Analiza techniczna
Sedno podatności polegało na tym, że workflow pobierał dane z publicznego zgłoszenia GitHub, takie jak tytuł i treść issue, a następnie umieszczał je bezpośrednio w instrukcji wykonywanej przez shell w bloku run. W takim modelu niezaufane dane wejściowe mogą zostać zinterpretowane nie jako tekst, lecz jako fragment polecenia systemowego.
Dodatkowym błędem był warunek logiczny odnoszący się do właściwości github.event.pull_request.user.login, mimo że workflow reagował na zdarzenie typu issue. Odwołanie do nieistniejącego pola sprawiło, że mechanizm ochronny nie działał zgodnie z założeniami i nie blokował wykonania zadania dla publicznego zgłoszenia.
Badacze przeprowadzili autoryzowany test bezpieczeństwa, w którym potwierdzili możliwość wykonania poleceń na runnerze GitHub Actions poprzez odpowiednio spreparowany payload. Następnie uzyskali dostęp do tokenu API Jira obecnego w zmiennych środowiskowych tego samego kroku. Według opisu token zapewniał dostęp odczytowy do wybranych projektów związanych między innymi z inżynierią, zgodnością bezpieczeństwa oraz obsługą zgłoszeń bug bounty.
Naprawa polegała na odejściu od bezpośredniego rozwijania danych użytkownika w treści poleceń shellowych. Zamiast tego wejście zaczęto przekazywać za pośrednictwem zmiennych środowiskowych i bezpieczniejszych argumentów, co ogranicza ryzyko interpretacji danych jako kodu.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją tej klasy błędów jest możliwość przejścia od publicznie dostępnego wejścia do wykonania kodu w środowisku automatyzacji. Jeżeli runner ma dostęp do sekretów, tokenów API, narzędzi chmurowych lub systemów wewnętrznych, nawet pojedynczy błąd w workflow może prowadzić do poważnego incydentu bezpieczeństwa.
- wyciek poświadczeń Jira,
- dostęp do danych projektowych i operacyjnych,
- możliwość rekonesansu procesów wewnętrznych,
- potencjalne wykorzystanie zdobytych informacji w dalszych etapach ataku,
- zwiększone ryzyko naruszenia bezpieczeństwa łańcucha dostaw.
Nie ma publicznych dowodów na kompromitację klientów ani na wykorzystanie podatności poza kontrolowanym testem. Mimo to przypadek pokazuje, że workflow obsługujące publiczne zdarzenia GitHub należy traktować jak granicę zaufania i projektować z zachowaniem ścisłej separacji między danymi użytkownika a sekretami.
Rekomendacje
Organizacje utrzymujące publiczne repozytoria powinny przeprowadzić przegląd wszystkich workflow GitHub Actions pod kątem wzorców command injection oraz niewłaściwego zarządzania sekretami. Szczególną uwagę należy zwrócić na zadania uruchamiane przez publiczne zgłoszenia, komentarze i pull requesty.
- Nie osadzać bezpośrednio danych z
issue,pull_requestanicommentwewnątrz blokówrun. - Przekazywać dane wejściowe przez zmienne środowiskowe lub argumenty z odpowiednim cytowaniem i walidacją.
- Rozdzielać workflow obsługujące niezaufane zdarzenia od tych, które korzystają z sekretów.
- Ograniczać uprawnienia tokenów i kont technicznych zgodnie z zasadą najmniejszych uprawnień.
- Rotować sekrety po każdym potwierdzonym lub potencjalnym wycieku.
- Wdrażać przeglądy bezpieczeństwa zmian w katalogu
.github/workflows. - Stosować skanowanie statyczne pod kątem niebezpiecznych konstrukcji shellowych.
- Testować warunki logiczne workflow w zależności od typu zdarzenia.
- Monitorować połączenia wychodzące z runnerów i wykrywać nietypowe callbacki sieciowe.
- Audytować wszystkie sekrety dostępne w jobach uruchamianych na publicznych triggerach.
Dla zespołów DevSecOps to także przypomnienie, że automatyzacja tworzona lub wspierana przez narzędzia AI powinna przechodzić standardowy proces code review i walidacji bezpieczeństwa. Odpowiedzialność za bezpieczne wzorce implementacyjne zawsze pozostaje po stronie organizacji.
Podsumowanie
Ujawniona luka w GitHub Actions w publicznym repozytorium powiązanym ze Snowflake to wyraźny przykład ryzyka wynikającego z mieszania niezaufanych danych wejściowych z wykonywaniem poleceń oraz dostępem do sekretów. Choć podatność nie dotyczyła bezpośrednio końcowego produktu i została szybko usunięta, jej znaczenie dla bezpieczeństwa CI/CD oraz łańcucha dostaw oprogramowania jest duże.
Najważniejszy wniosek jest prosty: publiczne zdarzenia muszą być traktowane jako nieufne, a sekrety nie powinny być dostępne w tym samym kontekście wykonania. Workflow automatyzacji wymagają dziś takiego samego poziomu rygoru bezpieczeństwa jak kod aplikacyjny i infrastruktura produkcyjna.
Źródła
- https://thehackernews.com/2026/08/snowflake-github-actions-flaw-lets_0330881554.html
- https://docs.github.com/en/actions/reference/workflows-and-actions/expressions
- https://github.blog/security/application-security/how-to-secure-github-actions-workflows-with-codeql/
- https://www.wiz.io/
- https://github.com/snowflakedb/snowflake-connector-net