ZCode spakował 42 411 plików do archiwum, które tylko Zhipu mógł otworzyć

18 września 2026 r. programista publikujący pod pseudonimem ferstar opublikował analizę rozbiórkową ZCode, desktopowego agenta AI do kodowania stworzonego przez chińskiego dewelopera modeli Zhipu AI, po tym jak zauważył, że ukryty folder w jego katalogu domowym urósł do ponad 700 MB. W jego wnętrzu znalazł zaszyfrowane archiwum o rozmiarze 313 MB zawierające 42 411 plików pochodzących z 345-megabajtowego obszaru roboczego, w 86,6% stanowiących historię Git, spakowane przez klienta i przygotowane do przesłania do obiektowego magazynu danych Alibaba Cloud. Archiwum było zabezpieczone kluczem, który mogły odszyfrować wyłącznie serwery Zhipu, a klient nie oferował żadnego przełącznika, który powstrzymałby jego tworzenie. Zhipu przeprosiło tego samego wieczoru. Pełny zapis, wraz z własną oceną pewności i statusem szkody archiwum, znajduje się w Orca AI Incident Archive, który rejestruje każdy udokumentowany incydent AI wraz z cytowanymi źródłami.

ZCode to desktopowy agent kodujący Zhipu: odczytuje projekt, uruchamia polecenia powłoki i pisze kod. Firma jest notowana w Hongkongu pod symbolem 2513.HK, a swoją międzynarodową część markuje jako Z.ai — nazwę, która pojawia się na serwerach ZCode, które sprawdzał ferstar. The Paper, szanghajski serwis informacyjny, który później przeprowadził wywiad z nim i kilkoma innymi deweloperami, podaje, że jego post miał w przybliżeniu tytuł „Uchylając kurtynę nad cichym przesyłaniem przez ZCode pełnej historii Git” i że w ciągu kilku godzin od publikacji rozprzestrzenił się w chińskich grupach deweloperskich.

Co było w ukrytym folderze?

Liczby podane przez samego Ferstara są trzonem tej sprawy i były konsekwentnie przytaczane przez The Next Web, InfoQ oraz redakcję finansową China National Radio. Archiwum w jego katalogu punktów kontrolnych ZCode miało 313 MB. Sąsiadujący plik statusu wskazywał obszar roboczy o rozmiarze około 345 MB i 42 411 plików. .git odpowiadał za 86,6% zawartości: 196,1 MB pamięci podręcznej Git do przechowywania dużych plików, 102,2 MB obiektów Git zawierających pełną historię commitów oraz niewielki fragment reflogu. Rzeczywisty kod źródłowy i dokumentacja stanowiły około 13,4%.

Ta różnica ma znaczenie, ponieważ historia Git to miejsce, w którym zwykle przetrwa materiał usunięty z bieżącego drzewa. Relacja The Paper wskazuje na to wprost: tego rodzaju archiwum może zawierać historię zmian projektu od pierwszego commita, usuniętą zawartość, niezatwierdzone szkice i starsze pliki konfiguracyjne, w tym poświadczenia, które dawno temu usunięto z kodu, ale pozostają we wcześniejszych commitach i w pamięci podręcznej dużych plików.

Własne archiwum Ferstara o rozmiarze 313 MB nigdy nie opuściło jego maszyny. Jego dziennik stanu pokazywał 564 nieudane próby przesłania, a ono utknęło w stanie oczekiwania, przekraczając limit rozmiaru. Aby sprawdzić, czy pipeline w ogóle działa, wypróbował małe publiczne repozytorium liczące 538 plików; ten zrzut po skompresowaniu i zaszyfrowaniu miał około 15 KB i został zaakceptowany przez serwer. To właśnie ten transfer został w zapisie potwierdzony jako ukończony od początku do końca i to on sprawia, że odkrycie przestaje być ćwiczeniem z czytania kodu, a staje się eksfiltracją z wykazaną stroną odbierającą.

Przechwytywanie nie było powiązane z żadną czynnością, którą użytkownik rozpoznałby jako „przesłanie mojego repozytorium”. Według rekonstrukcji ferstara jeden wyzwalacz uruchamiał się przed każdym monitem przesłanym do modelu, a inny działał jako zadanie aktualizacji Repo Wiki. Usunięcie oczekującego archiwum nie zatrzymało tego: publikacja w społeczności deweloperskiej Tencent Cloud odnotowuje, że pakiet został odbudowany w ciągu 30 minut, a licznik niepowodzeń wzrósł z 564 do 565. Jedynym niezawodnym sposobem zatrzymania, jaki znalazł ten autor, było uczynienie katalogu punktów kontrolnych niezapisywalnym, tak aby przechwytywanie nie powiodło się przy zapisie na dysk — kosztem utraty wycofywania do punktów kontrolnych i interfejsu osi czasu.

Klucz, którego mógł użyć wyłącznie dostawca

Szyfrowanie było podręcznikowym szyfrowaniem kopertowym i to była ta część, której użytkownicy nie mogli obejść. Rekonstrukcja InfoQ, oparta na inżynierii odwrotnej ferstar, opisuje, jak klient pobiera identyfikator snapshotu, klucz publiczny RSA oraz dane uwierzytelniające do przesyłania do Alibaba Cloud OSS z zcode.z.ai, lokalnie pakuje i szyfruje obszar roboczy, a następnie wysyła szyfrogram bezpośrednio do OSS. Treść była szyfrowana algorytmem AES-256-CTR; klucz symetryczny był opakowywany za pomocą RSA-OAEP-SHA256 przy użyciu klucza publicznego serwera, którego połowa prywatna pozostawała w chmurze Zhipu.

Routing jest równie istotny jak kryptografia. Ponieważ klient przesyłał pliki bezpośrednio do Alibaba Cloud, a nie przez własne serwery aplikacji Zhipu, ruch nie przechodził przez usługę Zhipu, która mogłaby go rejestrować lub filtrować, więc żadna usługa Zhipu nie znajdowała się na ścieżce, by rejestrować lub filtrować to, co wychodziło. A ponieważ klucz prywatny nigdy nie znajdował się na urządzeniu, ferstar nie mógł otworzyć własnego archiwum: The Next Web donosi, że wypróbował każdy klucz prywatny na swoim komputerze i mu się nie udało. W swoim poście opisał to rozwiązanie jako klucz, którego może używać tylko serwer i który ma jeden cel.

Dwa ustawienia w kliencie wyglądały tak, jakby powinny były to powstrzymać, i żadne z nich tego nie zrobiło. Przełącznik „optymalizuj środowisko” określał, czy dane mogą być wykorzystywane do trenowania modeli; przełącznik „indeksowanie migawek repozytorium” określał, czy serwer buduje indeks migawek, które już dotarły. Oba działają na etapie późniejszym niż przechwytywanie. Ferstar odkrył, że przechwytywanie działa bezwarunkowo, a The Next Web donosi, że jego lektura polityki prywatności wykazała, iż opisuje ona zbieranie tekstu rozmów i plików, ale nie mówi nic o automatycznych migawkach obszaru roboczego zawierających pełną historię Git.

Wyjaśnienie, którego udzieliło Zhipu, oraz cztery dni po nim

Zhipu odpowiedziało tego samego dnia, przez oficjalną grupę użytkowników ZCode, a nie w drodze komunikatu prasowego. Jak podała Global Times, a przedrukował Security Inside, firma przypisała to zachowanie funkcji o nazwie codebase indexing, która obsługuje lokalne indeksowanie, przywracanie punktów kontrolnych sesji, wycofywanie wersji i generowanie Repo Wiki, i stwierdziła, że to etap Repo Wiki wywołał przesyłanie repozytoriów do chmury. Funkcja była domyślnie włączona od momentu uruchomienia. Zhipu podało, że przesłane dane były wykorzystywane wyłącznie do wygenerowania strony Repo Wiki i natychmiast po tym niszczone, że nie były przechowywane ani wykorzystywane do trenowania, oraz przeprosiło poszkodowanych użytkowników. Obiecało udostępnić kod źródłowy ZCode, zaprosić do zewnętrznej weryfikacji i opublikować jej wyniki, a jako rekompensatę zaoferowało każdemu użytkownikowi ZCode jedno dodatkowe cotygodniowe odnowienie limitu.

Poprawka pojawiła się następnego dnia. The Paper donosi, że ZCode 3.14.0 ukazał się 19 września z wpisem w changelogu o treści „naprawiono nieprawidłowy problem z przesyłaniem wiki repozytorium”, a ferstar tego samego dnia potwierdził, że łańcuch przesyłania i jego endpoint zniknęły. 20 września platforma MaaS firmy Zhipu ogłosiła zbliżającą się opcję zerowego przechowywania, w ramach której dane wejściowe i wyjściowe nie byłyby przechowywane statycznie; The Paper zauważa, że jest ona włączana na wniosek, wyklucza Batch API i File API oraz nadal dopuszcza przechowywanie przez 30 dni lub dłużej, gdy wymagają tego przepisy prawa lub dochodzenie w sprawie nadużyć. 21 września kod źródłowy klienta został udostępniony publicznie na GitHubie na licencji Apache 2.0, obejmując aplikację desktopową, klienta webowego, backend, CLI agenta i środowisko uruchomieniowe agenta.

Zlecono dwa audyty, a ich wnioski opublikowano w formie streszczeń. Chińska Akademia Technologii Informacyjno-Komunikacyjnych stwierdziła, że bucket OSS zcode-prod w Alibaba Cloud znajduje się w stanie, który Zhipu nazywa stanem zerowych danych. Firma bezpieczeństwa NSFOCUS poinformowała, że usunięto każdy obiekt danych oraz sam bucket, a także że nie znalazła żadnej pozostałej ścieżki w ZCode 3.14.0, która mogłaby wyzwolić lokalną migawkę repozytorium lub wysłać pliki na zewnątrz. Pełny raport z oceny się nie ukazał, a The Next Web podaje, że Zhipu nie wyznaczyło dla niego żadnej daty.

Klient, który twierdził więcej, po czym to wycofał.

Najpoważniejsze roszczenie dotyczące rzeczywistej szkody nie wyszło od ferstar. 19 września, według China National Radio, Taiyuan Chengming Technology wysłała do Zhipu pismo prawne o numerze Chengming [2026] Legal Letter No. 1, którego treść szczegółowo przytoczył ChainCatcher. Firma podała, że bez zgody przesłano sześć jej przestrzeni roboczych do kodowania — 34 500 plików i około 425 MB w postaci niezaszyfrowanej — i wymieniła kompletny kod źródłowy, architekturę systemu, historię wersji, hasła do baz danych, dane dostępowe do chmury oraz dane osobowe pracowników. Podała też, że siódma przestrzeń robocza obejmująca 1947 plików i około 144 MB została spakowana i zaszyfrowana, ale 32 próby ponownego przesłania zakończyły się niepowodzeniem. Zauważyła również, że jej aplikacja kliencka zaktualizowała się do wersji 3.12.3 16 września, a mimo to przesyłanie nadal wykryto o 00:28 18 września — w poranek, gdy Zhipu przeprosiło.

W liście postawiono pytanie, na które audyty nie odpowiadają: czy dane opuściły kraj. Chengming stwierdził, że żądania sieciowe ZCode wskazywały na podmiot z Singapuru, podczas gdy umowa o świadczenie usług została podpisana z Beijing Zhipu Huazhang, i zażądał od Zhipu wskazania, która strona jest odpowiedzialna oraz czy doszło do jakiegokolwiek transferu lub przechowywania poza Chinami kontynentalnymi. W liście przedstawiono dwanaście żądań, w tym usunięcie wszystkich przesłanych danych wraz z ich pochodnymi, pamięciami podręcznymi i kopiami zapasowymi oraz wydanie pisemnego zaświadczenia; wyjaśnienie, dokąd trafiły dane i czy udostępniono je stronom trzecim lub wykorzystano do trenowania; opisanie, w jaki sposób przechowywany jest klucz prywatny, i przedstawienie logów dostępu; określenie dokładnego zakresu twierdzenia o „zniszczeniu”; oraz pisemne zobowiązanie się do nigdy więcej nieprzesyłania danych. Wyznaczono Zhipu termin do 10 października na pisemną odpowiedź i zastrzeżono sobie prawo do dochodzenia odszkodowania oraz złożenia skargi do regulatorów. Caixin Global podaje, że Zhipu nazwał te zarzuty nieprawdziwymi.

Dwa dni później Chengming je wycofał. Dział finansowy Chińskiego Radia Narodowego podaje, że 21 września firma wydała sprostowanie, stwierdzając, że jej wcześniejsze oświadczenia opierały się na błędnych dowodach, nieprecyzyjnym opisie i przesadnych sformułowaniach, że zaszkodziły reputacji Zhipu oraz że zaprzestanie kontaktów z mediami. Według The Next Web Reuters również poinformował o wycofaniu. Wpis archiwalny dotyczący tego incydentu jest datowany na 18 września, dzień odkrycia; list, jego termin 10 października i sprostowanie pojawiły się dopiero po tej dacie. Według publicznych zapisów na późny październik żadna wymieniona z nazwy firma nie stoi za twierdzeniem, że jej tajemnice zostały ujawnione.

Wydanie open source z wymazaną historią

Udostępnienie klienta jako open source było remedium, na którym Zhipu oparło się najmocniej, ale wiązało się z luką. The Paper podaje, że opublikowane repozytorium zawiera dwa commity: pusty początkowy commit oraz pojedynczy commit dodający około 6973 plików i 1,03 mln linii, przy zablokowanych pull requestach i zamkniętych issues. To, jak wyglądał pipeline przesyłania w momencie wydania i które wydania go zawierały, nie figuruje w historii, którą można teraz odczytać.

Późniejsza odpowiedź samego Ferstara jasno wskazuje ten limit. Potwierdził on, że potok przesyłania zniknął, a pozostały mechanizm punktów kontrolnych wykonuje wyłącznie lokalne operacje Git, po czym wskazał, co audyt zasobnika mógłby, a czego nie mógłby wykazać: wyczyszczenie i usunięcie zasobnika to właściwe działanie ograniczające straty, ale kontrola strony trzeciej przeprowadzona po 20 września może jedynie ustalić, że w tym momencie zasobnik był pusty. Nie może odtworzyć, co przechodziło przez niego przed 18 września, czy cokolwiek odszyfrowano, skopiowano lub zapisano w kopii zapasowej ani jak długo potok działał. Twierdzenie o usunięciu nadal w znacznym stopniu opiera się na słowach strony, która dokonała usunięcia.

Analiza InfoQ wymienia pytania, które pozostają otwarte, w tych samych kategoriach: ile migawek repozytoriów udało się przesłać i przez ilu użytkowników, jak długo przechowywano obiekty, które systemy po stronie serwera lub którzy pracownicy mogli je odszyfrować, czy istnieje pełny dziennik dostępu oraz czy usunięcie objęło kopie zapasowe i inne kopie. Odnotowuje również, czym ZCode pozostaje po poprawce. Własny plik NOTICE projektu ostrzega, że współdzielone środowisko uruchomieniowe agenta domyślnie nie zapewnia piaskownicy na poziomie systemu operacyjnego, a klient zachowuje powierzchnie powłoki, terminala, Git, MCP, wtyczek i wbudowanej przeglądarki, które mogą odczytywać pliki, uruchamiać procesy i uzyskiwać dostęp do sieci w ramach uprawnień konta użytkownika.

Co jest ustalone, a na co żadne źródło nie odpowiada

Mechanizm nie jest kwestionowany. Własne oświadczenia Zhipu przyznają, że dane repozytoriów zostały przesłane, że funkcja była domyślnie włączona oraz że dane trafiły do zasobnika chmurowego kontrolowanego przez firmę. Pomiary Ferstar, przeprosiny dostawcy, dwa zlecone audyty i wydanie otwartoźródłowe opisują ten sam łańcuch. Nic w materiale dowodowym nie podważa, że przestrzenie robocze opuszczały maszyny bez działającego mechanizmu rezygnacji. Szkoda odnotowana w materiale jest rzeczywista, a nie hipotetyczna: transfery miały miejsce, a osoby, których kod się w nich znajdował, nie mogły im zapobiec ani ich skontrolować.

Sporne – albo po prostu nieznane – są skala i konsekwencje. Żadne źródło nie podaje, ilu użytkowników korzystało z objętych problemem ustawień domyślnych, jak długo potok działał przed 18 września ani czy jakikolwiek przesłany obiekt został kiedykolwiek odszyfrowany. Zapewnienie Zhipu, że dane zostały zniszczone po wygenerowaniu wiki i nigdy nie wykorzystano ich do trenowania, jest oświadczeniem samej firmy; ustalenia CAICT i NSFOCUS opisują stan zasobnika po naprawie, a nie to, co przez niego przepłynęło. Archiwum przyznaje rekordowi ocenę A za dokumentację, a dokumentacja jest mocna w kwestii mechanizmu, lecz uboga w zakres.

Co się zmieniło, a co nie

Koszt komercyjny był natychmiastowy. China National Radio podaje, że akcje Zhipu notowane w Hongkongu spadły o 1,79% 21 września, o 6,55% 22 września i o 12,4% 23 września, co oznacza łączny spadek o ponad 16% w ciągu trzech sesji handlowych, oraz że Zhipu nie odniósł się do tego, ilu użytkowników zostało dotkniętych ani czy dane historyczne zostały odszyfrowane lub objęte kopią zapasową.

Co użytkownik ZCode faktycznie otrzymał w ciągu czterech dni po odkryciu:

• 18 września: publiczne przeprosiny wskazujące indeksowanie kodu źródłowego jako przyczynę, obietnica udostępnienia klienta jako open source i zlecenia przeglądu przez stronę trzecią oraz jedno dodatkowe cotygodniowe resetowanie limitu na użytkownika.

• 19 września: ZCode 3.14.0 — usunięto Repo Wiki oraz odcięto ścieżkę lokalnego generowania i przesyłania snapshotów. Ferstar potwierdził następnego dnia, że łańcuch przesyłania zniknął.

• 20 września: ogłoszona opcja zerowej retencji dla platformy MaaS Zhipu, wymagająca włączenia (opt-in), z wyłączeniem Batch API i File API, i nadal podlegająca prawnej retencji przez 30 dni lub dłużej.

• 21 września: ZCode opublikowany na licencji Apache 2.0 bez przedincydentowej historii commitów; podsumowania CAICT i NSFOCUS informują, że zasobnik pamięci był pusty, a ścieżka wyjściowa nieobecna.

Nic z tego nie działa wstecz. Konkretne pytania podniesione przez Chengminga — dokąd trafiły dane, kto mógł je odszyfrować, czy opuściły kraj i co obejmowało „zniszczone” — zostały spisane na piśmie z terminem do 10 października, a następnie wycofane wraz z firmą, która je zadała. Zhipu obiecał pełny raport z oceny zewnętrznej bez wskazania daty. Dopóki taki się nie pojawi, jedynym publicznym opisem tego, co potok zrobił z otrzymanymi danymi, jest relacja firmy, która go zbudowała, a jedynym niezależnie mierzalnym artefaktem jest plik o rozmiarze 313 MB, któremu 564 razy nie udało się opuścić laptopa jednego dewelopera.