Token Jira Snowflake'a: wada, którą Copilot współsygnował, a człowiek, który według GitHuba ją napisał

23 czerwca 2026 r. Red Agent, autonomiczny agent bezpieczeństwa stworzony przez Wiz, otworzył zgłoszenie w publicznym repozytorium GitHub należącym do Snowflake i uzyskał poświadczenie. Repozytorium to snowflakedb/snowflake-connector-net, a wadliwy workflow, .github/workflows/jira_issue.yml, ma za zadanie tworzyć zgłoszenie Jira za każdym razem, gdy ktoś otwiera zgłoszenie — tytuł zgłoszenia był wbudowywany w polecenie powłoki zamiast przekazywany przez zmienną środowiskową, przez co spreparowany tytuł wykonał się jako kod na runnerze GitHub Actions. Token odzyskany przez Red Agent uwierzytelniał się jako qa@snowflake.net wobec snowflakecomputing.atlassian.net i zapewniał dostęp do odczytu do projektów Jira Snowflake dotyczących inżynierii, zgodności bezpieczeństwa i bug bounty. Wada pozostawała aktywna przez pięć dni. Wiz opublikował pełną analizę 17 sierpnia 2026 r. Ten incydent skatalogowano jako rekord 2026-08-17-snowflake-jira-zhao-dao-can w Orca AI Incident Archive, który zawiera pełny zestaw rekordów wraz z ocenami pewności i cytowanymi źródłami.

Interpolacja i zabezpieczenie, które nigdy nie zadziałało

Przepływ pracy był wyzwalany zdarzeniem GitHub „issues: opened”. Każdy posiadający konto GitHub mógł go uruchomić, otwierając zgłoszenie w publicznym repozytorium — bez zaproszenia, bez roli opiekuna, bez forka. Podatny krok odczytywał tytuł zgłoszenia do zmiennej powłoki: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...), z dwoma filtrami, które miały escapować podwójne i pojedyncze cudzysłowy, zanim ciąg został złożony.

Problem nie tkwi w escapowaniu, lecz w kolejności operacji. GitHub podstawia zawartość wyrażenia do tekstu skryptu, zanim bash w ogóle go przeanalizuje, więc pojedynczy cudzysłów w tytule zgłoszenia zamyka ujęty w cudzysłowy ciąg, który echo utrzymuje otwarty. Dwa filtry sed działają w tym samym skrypcie, po podstawieniu, i nie mogą naprawić cytowania, które już zmieniło sposób analizowania wiersza. W opracowaniu Wiz wyraźnie stwierdzono, że escapowanie następuje zbyt późno, by zapobiec przełamaniu, a tytuł spreparowany z cudzysłowem zamykającym i średnikiem dołącza wybrane przez atakującego polecenia do kroku run.

Drugi mechanizm kontrolny miał zawęzić grupę odbiorców, ale tego nie zrobił. Zadanie zawierało warunek if porównujący github.event.pull_request.user.login z loginem bota whitesource-for-github-com, najwyraźniej po to, by powstrzymać automatyczne pull requesty dotyczące zależności przed zgłaszaniem zgłoszeń. W przypadku zdarzenia issues nie ma w ogóle obiektu pull request, więc porównanie odbywa się z właściwością null. Dokumentacja samego GitHuba, cytowana przez The Hacker News, stwierdza, że odwołanie do nieistniejącej właściwości daje w wyniku pusty ciąg znaków; analiza Wiz dochodzi do tego samego wniosku poprzez wartość null. Tak czy inaczej warunek dawał wartość prawdziwą dla każdego użytkownika, a wyjątek dla bota stał się przepustką dla całego internetu.

O tym, że wstrzyknięcie było warte zgłoszenia, a nie rutynowe, decydowało otoczenie, w jakim wystąpiło. Ten sam krok przechowywał JIRA_BASE_URL, JIRA_USER_EMAIL i JIRA_API_TOKEN jako zmienne środowiskowe, dlatego dowolne wykonanie polecenia na runnerze miało poświadczenie w zasięgu, a nie pusty substrat. Nie zidentyfikowano żadnego wydania Snowflake Connector for .NET jako dotkniętego: słabość tkwiła w automatyzacji CI/CD repozytorium, a nie w dostarczanym kodzie łącznika.

Co zabrał Red Agent i co twierdzi, że wyrzucił

Relacja Wiz dotycząca wykorzystania jest tym elementem, który odróżnia to od wyniku skanera. Pierwszy ładunek używał znaku #, który zakomentował nawias zamykający przypisania TITLE=$(...), powodując błąd składni bash zamiast wywołania zwrotnego. Agent przeczytał błąd i zmodyfikował ładunek, aby zamknąć blok powłoki średnikiem oraz nowym cudzysłowem echo, a następnie otrzymał wywołanie poza pasmem. Ładunek użył curl, aby połączyć się z subdomeną oast.me, przekazując zakodowane w base64 wartości trzech zmiennych poświadczeń, a wywołanie zwrotne przyszło z adresu IP Azure 20.106.182.197, który Wiz przypisuje runnerowi GitHub Actions.

Token, który zwrócono, był tokenem API Jira dla qa@snowflake.net, a Wiz opisuje swój zasięg jako dostęp do odczytu obejmujący projekty inżynieryjne, dotyczące zgodności bezpieczeństwa i śledzenia bug bounty w chmurowym wystąpieniu Atlassian Snowflake. To jest szkoda, którą odnotowuje archiwum: nie pięciodniowe wykonanie kodu na maszynie budującej, ale poświadczenie, które mogło odczytywać kolejki zgłoszeń, w których trafiają nienaprawione błędy inżynieryjne i bezpieczeństwa — w tym, zgodnie z opisem Wiz, tracker bug bounty.

Wiz twierdzi, że bezpiecznie usunął wszystko, do czego uzyskał dostęp podczas proof of concept. Snowflake w oświadczeniu dla CSO Online stwierdził, że raport „został natychmiast zbadany i naprawiony” oraz że „nasze dochodzenie nie wykazało żadnych dowodów na nieuprawniony dostęp”; blog Wiz dodaje, że Snowflake przeanalizował dzienniki audytu obejmujące pięciodniowy okres i nie stwierdził użycia przez podmioty trzecie poza własnymi adresami testowymi Wiz. Snowflake nie opublikował tych dzienników, dlatego ustalenie o braku innych podmiotów opiera się na relacji Snowflake i streszczeniu tej relacji przez Wiz, a nie na dokumentach, które mógłby przeczytać ktokolwiek spoza obu organizacji.

Kto napisał podatną linię

To pytanie zaowocowało drugą, większą historią. PR #1218 zatytułowany „SNOW-2069227: Zaktualizuj przepływy pracy Jira” został scalony metodą squash 18 czerwca 2026 r. jako commit 4a1b8ce, a wśród współautorów tego commita squash wymieniono Copilot Autofix powered by AI. Pierwotny nagłówek Wiz opierał się dokładnie na tym, opisując lukę jako znajdującą się w pull requestcie wspieranym przez GitHub Copilot, a wczesne doniesienia branżowe podążały za tą samą narracją — nagłówek SC Media brzmiał: „Agent Wiz znajduje lukę w repozytorium Snowflake w kodzie współtworzonym przez GitHub Copilot Autofix”.

Stanowisko GitHub, opisane przez The Next Web i podsumowane w notatce badawczej Cloud Security Alliance, jest takie, że jego wewnętrzny przegląd wykazał, iż „wkład, który doprowadził do podatności, napisał człowiek”, oraz że Copilot Autofix „nie dokonał ich przeglądu ani nie wniósł do nich wkładu”. Techniczna podstawa tego odparcia znajduje się w historii git. Scalanie squash sprowadza pull request do pojedynczego commita i zachowuje każdy trailer współautora, niezależnie od tego, których wierszy ten autor dotknął, więc wiersz współautora odnotowuje udział w pull requeście, a nie autorstwo konkretnego hunk. Współtworzony przez Copilot commit w tym samym pull requeście, {{1}}6d0e2fa{{/1}}, zmienił {{2}}jira_close.yml{{/2}} — inny workflow niż podatny {{3}}jira_issue.yml{{/3}}. Niebezpieczną interpolację przypisuje się commitowi {{4}}094038e{{/4}} z 25 sierpnia 2025 r., który GitHub przypisuje inżynierowi Snowflake, {{5}}sfc-ghpathak{{/5}}; PR {{6}}#1218{{/6}} wprowadził ten wzorzec do gałęzi domyślnej w czerwcu 2026 r.

Wiz nie wycofał tego ustalenia i w dniu publikacji zmienił sposób przedstawienia sprawy. Na jego blogu znajduje się aktualizacja opublikowana 17 sierpnia o 19:57 UTC, w której Copilot opisano jako „współautora, który sprawdził zmergowany PR i zmianę w kodzie”, a ten „uznał ją za wolną od zagrożeń”, nie zauważywszy luk w zabezpieczeniach, oraz przyznano, że „nie jest jasne, czy zmiana w kodzie była wspomagana przez AI”. W tej relacji porażka AI dotyczy przeglądu, a nie autorstwa: zmergowany pull request miał współpodpis Copilota, a wstrzyknięcie kodu to przetrwało. CSO Online cytuje Amiego Luttwaka, CTO Wiz, według którego jednoznaczne przypisanie autorstwa między ludźmi a AI „staje się nieco trudniejsze do ustalenia” oraz „samo patrzenie na współautorów PR nie wystarcza”.

To, co łączy oba opisy, warto oddzielić od tego, co jest między nimi sporne. Obie strony zgadzają się, że commit squash zawiera trailer współautora Copilot Autofix oraz że workflow był podatny na wykorzystanie. Żadna nie kwestionuje, że GitHub Advanced Security przeskanował końcową wersję pull requesta, wyodrębnił jira_issue.yml i nie oznaczył wstrzyknięcia — Wiz zgłasza to jako przeoczenie, a replika GitHuba dotyczy autorstwa, a nie skanu. Nierozstrzygnięte pozostaje, czy Copilot w ogóle przejrzał podatne linie: Wiz twierdzi, że przegląd został przeprowadzony i je przepuścił, GitHub twierdzi, że narzędzie nie miało w nich żadnej roli, a logi, które mogłyby to rozstrzygnąć, znajdują się u jednej z tych dwóch firm. Zapis przedstawia oba opisy zamiast dokonywać wyboru.

Pięć dni, a co zmieniło się później

Naprawa przebiegła szybko, gdy tylko zgłoszenie dotarło. Wiz zgłosił sprawę za pośrednictwem programu HackerOne Snowflake jako zgłoszenie #3819931 w dniu 23 czerwca, a tego samego dnia powiadomił zespół bezpieczeństwa Snowflake przez Slacka; Snowflake scalił PR #1402, commit 1dc7766, który zastąpił bezpośrednie rozwijanie wyrażeń zmiennymi środowiskowymi przekazywanymi do jq jako argumenty. Harmonogram Wiza umieszcza rotację tokena Jira na 24 czerwca i The Hacker News podaje ten sam podział dat. Natomiast wstęp samego Wiza mówi, że Snowflake naprawił podatność i dokonał rotacji poświadczenia „tego samego dnia” — rozbieżność wewnątrz źródła pierwotnego, której zapis nie powinien tuszować. Poprawka trafiła 23 czerwca; rotacja jest datowana na 24 czerwca w tabeli Wiza.

Ujawnienie przebiegało według zegara Snowflake: Wiz wyznacza termin publicznego ujawnienia na 25 lipca 2026 r. — trzydzieści dni po rozstrzygnięciu z 25 czerwca zgodnie z polityką programu — a analizę opublikował 17 sierpnia. W oświadczeniu dla CSO Online Snowflake podał, że firma „docenia odpowiedzialne zgłaszanie przez Wiz” i że współpracuje z Wiz, aby dzielić się wnioskami z branżą. Ani analiza Wiz, ani raport The Hacker News nie zawierają identyfikatora CVE, wyniku CVSS ani wpisu w prowadzonym przez CISA katalogu znanych podatności wykorzystywanych w atakach; błąd dotyczył konfiguracji przepływu pracy w publicznym repozytorium, a nie dostarczanej biblioteki, więc nigdy nie trafił do bazy podatności w zwykły sposób.

Co ustala dokumentacja, a czego nie ustala

Archiwum klasyfikuje to jako ustalenie badawcze, a nie zdarzenie wdrożeniowe, z wysoką wagą, oceną pewności A, potwierdzonym udziałem AI i odnotowaną rzeczywistą szkodą; data 17 sierpnia 2026 r. to dzień publikacji Wiz, a sam incydent obejmuje okres od 18 do 23 czerwca. Ustalony rdzeń jest wąski i weryfikowalny: publiczny przepływ pracy wstawił tekst kontrolowany przez atakującego do polecenia powłoki, jego warunek zabezpieczający porównywał z właściwością, która w tym zdarzeniu ma wartość null, token Jira znajdował się w tym samym kroku, autonomiczny agent to wykorzystał, a Snowflake scalił poprawkę i w ciągu dnia dokonał rotacji danych uwierzytelniających.

Części, które są wywnioskowaniem, a nie udokumentowanym zapisem, to właśnie te, które swobodne relacje zwykle spłaszczają. Copilot Autofix jest udokumentowany jako współautor pull requesta, a nie jako autor podatnych wierszy; ujęcie „AI kontra AI”, które napędzało pierwszy cykl doniesień, zostało częściowo wycofane przez organizację dziennikarską w ciągu kilku godzin i odparte przez GitHub. Czy przegląd AI scalonego pull requesta obejmował jira_issue.yml, pozostaje wciąż otwartym pytaniem faktycznym, a nie kwestią rozstrzygniętą. A zakres dostępu, choć szczegółowo opisany przez Wiz, nie został niezależnie zaudytowany: nie upubliczniono żadnych uprawnień Jira, uruchomień workflow ani zapisów audytu.

Wzorzec poprawki to ten, który własne wytyczne GitHuba zalecały od lipca 2025 r. — przekazywać dane niezaufanego zgłoszenia do zmiennej środowiskowej i podawać je jq jako argument, zamiast rozwijać je wewnątrz bloku run. Scalony commit Snowflake robi dokładnie to, a poprawiona obsługa pozostaje na gałęzi domyślnej. Dla każdego, kto czyta ten zapis jako precedens, trwałe ustalenie dotyczy atrybucji, a nie wstrzyknięcia: gdy pull request obejmuje kilka osób i kilka agentów, trailer współautora nie pozwala stwierdzić, kto napisał daną linię, i zarówno Wiz, jak i GitHub ostatecznie powiedziały to samo innymi słowami.