xAI udostępniło kod źródłowy swojego narzędzia Grok Build 15 lipca 2026 r., zaledwie dwa dni po tym, jak badacze udowodnili, że oprogramowanie po cichu przesyłało całe repozytoria git, katalogi domowe i tajne pliki do Google Cloud Storage.
Incydent, który wywołał udostępnienie kodu
13 lipca badacz bezpieczeństwa wykazał, że Grok Build ignoruje reklamowane funkcje kontroli prywatności. Gdy użytkownik przełączył opcję „stop uploads”, narzędzie nadal przesyłało dane do chmurowego bucketu. Przesyłanie obejmowało każdy plik w katalogu roboczym, a w przynajmniej jednym przypadku objęło cały folder domowy, ujawniając klucze SSH i bazy haseł.
xAI ukryło flagę po stronie serwera za polem wyboru użytkownika. Dwa dni później firma ogłosiła, że Grok Build zostanie udostępniony na licencji Apache 2.0, przedstawiając ten krok jako sposób na poszerzenie dostępu dla programistów.
Co wciąż znajduje się w repozytorium
Szybki rzut oka na nowe repozytorium pokazuje, że mechanizm eksfiltracji danych wciąż tam jest. Znajduje się on wewnątrz instrukcji warunkowej sprawdzającej ukrytą flagę – która nadal istnieje, lecz jest wyłączona. Kod zawiera również fragmenty skopiowane z OpenAI i OpenCode bez podania autorstwa oraz zawiera instrukcje dla subagentów, aby ukrywali swoją obecność, co utrudnia analizę śledczą (forensic analysis).
Dlaczego pozostały kod ma znaczenie
Programiści, którzy zdecydują się na Grok Build, muszą teraz ufać firmie xAI, że będzie ona utrzymywać flagę w prawidłowym stanie przy każdej aktualizacji. To zaufanie jest kruche z trzech powodów:
- Ukryta ścieżka kontroli – Flaga znajduje się po stronie serwera, niewidoczna dla użytkowników końcowych. Błędna konfiguracja lub złośliwy pracownik mogą ją zmienić bez pozostawienia śladu w audycie.
- Ponowne wykorzystanie kodu bez podania źródła – Niejasne pochodzenie licencji może narazić użytkowników na ryzyko prawne, jeśli zapożyczony kod posiada niekompatybilne warunki.
- Instrukcje zaciemniania (obfuscation) – Wbudowane mechanizmy ukrywania utrudniają narzędziom bezpieczeństwa wykrycie złośliwej aktywności, którą może wywołać narzędzie.
Etykieta „open-source” nie oznacza automatycznie przeglądu społecznościowego. Repozytorium xAI nie przyjmuje zewnętrznych pull requestów, więc baza kodu będzie ewoluować w zamkniętym obiegu, mimo że jest publicznie czytelna.
Jak Grok Build wypada na tle alternatyw
| Narzędzie | Licencja | Wkład społeczności | Uzależnienie od dostawcy |
|---|---|---|---|
| Grok Build | Apache 2.0 | Nie (xAI blokuje PR) | Niskie (obsługuje wiele modeli) |
| Codex CLI | Apache 2.0 | Nie (związany z OpenAI) | Wysokie (tylko OpenAI) |
| OpenCode | MIT | Tak (akceptuje prace społeczności) | Niskie (wielu dostawców) |
| Claude Code | Własnościowa | Nie | Wysokie (tylko Claude) |
Jedyną wyraźną zaletą Grok Build jest możliwość wskazywania lokalnych modeli lub innych dostawców, co zmniejsza zależność od jednego podmiotu. Wszystkie pozostałe aspekty – otwartość licencji, model wkładu i pochodzenie kodu – są na tym samym poziomie lub gorsze niż w przypadku istniejących opcji.
Co programiści powinni zrobić natychmiast
- Przejrzeć ścieżkę przesyłania – Przeanalizować kod sieciowy repozytorium i upewnić się, że nie pozostały żadne połączenia wychodzące do nieznanych punktów końcowych.
- Zrotować sekrety – Wygenerować na nowo wszelkie klucze SSH, tokeny API lub magazyny haseł, które znajdowały się w pobliżu Grok Build przed 13 lipca.
- Uruchamiać w izolacji – Wdrażać narzędzie wewnątrz piaskownicy (sandbox) lub kontenera, który nie ma dostępu do uprzywilejowanych plików lub poświadczeń.
- Monitorować stan flagi – Jeśli hostujesz własną instancję, zweryfikuj, czy ukryta flaga pozostaje wyłączona po każdej aktualizacji.
Kroki te nie eliminują ryzyka przyszłych zmian po stronie xAI, ale zmniejszają szansę na to, że istniejąca logika eksfiltracji danych po cichu powróci.
Podsumowanie
Udostępnienie Grok Build jako open-source po skandalu związanym z eksfiltracją danych nie usuwa podstawowej podatności. Repozytorium wciąż zawiera ukrytą procedurę przesyłania danych, a jedynym zabezpieczeniem jest flaga kontrolowana przez firmę. Dopóki kod nie zostanie oczyszczony z tej logiki lub dopóki stan flagi nie stanie się audytowalny, programiści powinni traktować Grok Build jako komponent wysokiego ryzyka i ograniczać jego użycie do środowisk, które nie zawierają żadnych wrażliwych danych.