Grok Build laddade upp hela din kodbas – inklusive lösenord och Git-historik

Bakgrundslagringsvägen var det mer alarmerande fyndet. Oberoende av vilka filer agenten faktiskt öppnade, paketerade CLI:n hela Git-repot – inklusive full commit-historik – och laddade upp det till en Google Cloud Storage-bucket med namnet grok-code-session-trace via en

POST /v1/save-session

Säkerhetsforskaren Hari bekräftade detta oberoende genom reverse engineering och rapporterade att Grok Build laddade upp hela användarkataloger utan uttryckligt tillstånd . I ett test med ett 11,2 GiB stort repository fångades minst 5,1 GiB data som lämnade via lagringsvägen, medan den faktiska kodningsuppgiften endast krävde cirka 192 KB . Uppladdningarna innehöll full Git-historik, .env-hemligheter och alla repositoryfiler – inte bara den delmängd som behövdes för kodningsuppgiften .

Hur Elon Musk och xAI svarade

Elon Musk bekräftade problemet offentligt på X och inledde sitt svar med ”True” . Han lovade sedan: ”Som en försiktighetsåtgärd kommer alla tidigare uppladdade användardata till SpaceXAI att raderas fullständigt och noggrant. Ingenting, vad det än må vara, kommer att finnas kvar” .

xAI utfärdade ett offentligt uttalande där man sa att man tar användarnas integritet på allvar och noterade att företagskunder som använder Zero Data Retention (ZDR) aldrig hade fått sin kod eller träningsdata använd . Företaget implementerade också en server-sidig ändring som inaktiverade /v1/save-session-ändpunkten, vilket stoppade bakgrundsuppladdningarna av repositories . Uppladdningarna upphörde den 13 juli 2026 .

Kvarstående farhågor trots åtgärden

Även om xAI:s svar stoppade den aktiva dataexfiltreringen kvarstår flera problem.

1. Åtgärden var server-sidig, inte klient-sidig. Forskaren noterade att Grok Build CLI-klienten (version 0.2.93) själv aldrig uppdaterades – xAI stängde helt enkelt av den mottagande ändpunkten på sina servrar . Detta innebär att klientkoden fortfarande har förmågan att ladda upp hela repositories; beteendet skulle kunna återupptas om ändpunkten återaktiveras.

2. xAI:s integritetsinställning stoppade inte uppladdningarna. Forskaren testade ”integritetsläget” eller kommandot för att välja bort datalagring och fann att det inte förhindrade bakgrundsuppladdningen av hela repot . Forskaren uttryckte uttryckligen: ”xAI:s integritetskommando var inte det som åtgärdade dem” . Istället sattes en dold server-sidig flagga som heter disable_codebase_upload till true .

3. Ingen offentlig kommunikation om ändringen. xAI inaktiverade uppladdningsfunktionen utan att meddela användare eller utfärda en ändringslogg .

4. Ingen bekräftelse på att data faktiskt raderades. Trots Musks löfte om radering fanns vid tidpunkten för publiceringen ingen oberoende verifiering av att tidigare uppladdad användardata i grok-code-session-trace-bucketen hade rensats .

5. Data som redan läckt kan inte återkallas. Alla känsliga uppgifter, proprietär kod eller hemligheter som överfördes före åtgärden lagrades redan på xAI:s molninfrastruktur . Forskaren fångade uppladdningar och kunde klona Git-paketet och återställa filer som agenten uttryckligen hade blivit tillsagd att inte läsa .

Sammanfattning av viktiga fakta

Vad detta innebär för utvecklare

Grok Build-incidenten belyser en växande risk för utvecklare som använder AI-drivna kodningsassistenter. Många sådana verktyg skickar kod till molnservrar för bearbetning, men omfattningen av vad som överförs och lagras är ofta otydlig. I detta fall skickade verktyget mycket mer än vad som var nödvändigt – och det gjorde det även när användare uttryckligen försökte förhindra det.

Tills xAI släpper en klientuppdatering och tillhandahåller oberoende verifiering av radering, bör utvecklare som använt Grok Build anta att eventuella inloggningsuppgifter, proprietär kod eller känslig information som funnits i deras repositories kan ha överförts till xAI:s molninfrastruktur.