Grok Build CLI 0.2.93, '로컬 우선' 광고와 달리 전체 저장소·비밀번호 무단 전송… 옵트아웃도 무용지물
보안 연구원이 mitmproxy로 xAI Grok Build CLI 0.2.93의 패킷을 분석한 결과, 개발자 PC에서 구글 클라우드 스토리지 버킷(grok code session traces)으로 전체 Git 저장소가 git bundle 형태로 조용히 업로드되고 있었다. API 키와 데이터베이스 비밀번호가 포함된 .env 파일이 마스킹 없이 그대로 전송됐으며, 에이전트가 '파일을 읽지 말라'는 지시를 받은 상황에서도 전체 저장소와 Git 커밋 기록이 업로드됐다.
Search & fact-check with cited sources for What security flaws were revealed by a wire-level analysis of xAI's Grok Build CLI version 0.2.93Visualization of a wire-level analysis showing network flows from a developer machine to xAI's Google Cloud Storage bucket. The analysis revealed a 27,800× data disparity between model turns and background repository uploads.
AI 프롬프트
Create a landscape editorial hero image for this Studio Global article: Search & fact-check with cited sources for What security flaws were revealed by a wire-level analysis of xAI's Grok Build CLI version 0.2.93. Article summary: Now I have comprehensive source material. Here is the fact-checked answer.. Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clickbait thumbnails, icons, and tiny thumbnail layouts. Make it useful as an illustrative visual, not as factual evidence.
openai.com
보안 연구 그룹 Cereblab(@cereblab)이 xAI의 AI 코딩 도구인 **Grok Build CLI (버전 0.2.93)**의 네트워크 트래픽을 mitmproxy로 직접 캡처해 분석한 결과를 GitHub Gist에 공개했습니다. 이 분석은 회사의 '로컬 우선(local-first)' 마케팅과 정면으로 배치되는 세 가지 주요 보안 결함을 밝혀냈습니다.
'로컬 우선' 마케팅을 뒤집는 데이터 유출 행위
연구원은 개발자 PC를 떠나는 두 가지 본질적으로 다른 데이터 경로를 발견했습니다:
모델 턴 채널 (
POST /v1/responses
): 에이전트가 연 파일만 모델 요청에 직렬화됩니다. 이는 클라우드 코딩 에이전트의 예상되는 동작입니다.
스토리지 채널 (
POST /v1/storage
): 전체 저장소가 git bundle로 독립적으로 패키징되어 grok-code-session-traces라는 Google Cloud Storage 버킷에 약 75MB 청크 단위로 업로드되었습니다.
Studio Global AI
Search, cite, and publish your own answer
Use this topic as a starting point for a fresh source-backed answer, then compare citations before you share it.
"Grok Build CLI 0.2.93, '로컬 우선' 광고와 달리 전체 저장소·비밀번호 무단 전송… 옵트아웃도 무용지물"에 대한 짧은 대답은 무엇입니까?
보안 연구원이 mitmproxy로 xAI Grok Build CLI 0.2.93의 패킷을 분석한 결과, 개발자 PC에서 구글 클라우드 스토리지 버킷(grok code session traces)으로 전체 Git 저장소가 git bundle 형태로 조용히 업로드되고 있었다.
먼저 검증할 핵심 포인트는 무엇인가요?
보안 연구원이 mitmproxy로 xAI Grok Build CLI 0.2.93의 패킷을 분석한 결과, 개발자 PC에서 구글 클라우드 스토리지 버킷(grok code session traces)으로 전체 Git 저장소가 git bundle 형태로 조용히 업로드되고 있었다. API 키와 데이터베이스 비밀번호가 포함된 .env 파일이 마스킹 없이 그대로 전송됐으며, 에이전트가 '파일을 읽지 말라'는 지시를 받은 상황에서도 전체 저장소와 Git 커밋 기록이 업로드됐다.
실무에서는 다음으로 무엇을 해야 합니까?
'Improve the model' 개인정보 토글을 비활성화해도 업로드가 중단되지 않았다. 서버는 여전히 trace upload enabled: true를 반환하고 HTTP 200으로 청크를 수락했다.
데이터 규모의 차이는 이 업로드가 에이전트가 읽은 내용과 무관하다는 것을 증명했습니다. 12GB 테스트 저장소에서 스토리지 채널은 73개의 청크(모두 HTTP 200)를 통해 5.10GiB를 전송한 반면, 모델 턴 채널은 단 192KB만을 전송했습니다. 이는 약 27,800배의 차이입니다. 심지어 "파일을 읽지 말고 OK라고만 답하라"는 프롬프트를 입력했을 때도, 이 도구는 전체 저장소를 git bundle로 업로드했습니다. 캡처된 bundle을 복제하면 에이전트가 명시적으로 열지 말라고 지시받은 파일(src/_probe/never_read_canary.txt)과 전체 Git 커밋 기록이 그대로 복구되었습니다.
마스킹 없이 전송된 비밀번호 및 파일 유형
.env 파일: API 키, 데이터베이스 비밀번호 및 기타 자격 증명이 마스킹이나 수정 없이 그대로 두 채널을 통해 전송되었습니다. 통제된 테스트에서 데이터베이스 자격 증명과 API 키가 포함된 48KB 파일이 요청 본문에 평문으로 나타났습니다.
모든 추적 파일 및 전체 Git 히스토리(모든 커밋, 브랜치, 태그)가 번들로 묶여 업로드되었습니다. 이는 수개월 전에 커밋되었으나 이후 교체된 비밀번호도 업로드된 데이터에 여전히 존재할 수 있음을 의미합니다.
업로드 메커니즘은 바이너리 내에 포함된 **자사 Rust 크레이트(xai-data-collector)**로 식별되었으며, 소스 경로는 crates/codegen/xai-data-collector/src/gcs.rs와 crates/codegen/xai-grok-shell/src/upload/입니다.
한 번도 읽지 않은 임의의 파일로 구성된 실제 12GB 코드베이스에서도 스토리지 엔드포인트는 크기 기반 거부 없이 업로드를 수락했습니다. 유일한 비-200 응답은 모델 사용 할당량 오류(402/429)였지, 스토리지 실패가 아니었습니다.
옵트아웃 토글의 실패
연구원은 'Improve the model' 개인정보 토글을 테스트했지만, 업로드를 중단시키지 못했습니다.
토글을 비활성화하고 재시작한 후에도 서버 설정 엔드포인트는 여전히
trace_upload_enabled: true
를 반환했습니다.
스토리지 채널은 계속해서 HTTP 200 응답으로 청크 단위 git bundle 업로드를 수락했습니다.
설정에 disable_codebase_upload=true 구성 옵션이 존재하지만, 서버 측 동작과의 관계는 문서화되지 않았으며, 연구원의 테스트 결과 서버는 클라이언트 측 설정을 존중하지 않는 것으로 나타났습니다.
영향 받은 개발자를 위한 권장 조치
연구원과 분석 매체들은 다음을 권장합니다:
비공개 저장소에서 Grok Build CLI를 사용한 팀의 즉시 조치:
Grok Build와 함께 사용된 저장소 내 모든 .env 파일, 설정 파일, Git 히스토리에 존재했던 모든 자격 증명을 교체하세요. 이들은 grok-code-session-traces GCS 버킷에 전송되어 저장되었을 수 있습니다.
CLI가 전체 커밋 히스토리를 전송했으므로, 과거 커밋에 존재했을 수 있는 비밀번호에 대해 Git 히스토리를 감사하세요.
데이터가 전송되었을 뿐만 아니라 저장되었음을 가정하세요. 서버는 모든 스토리지 요청에 HTTP 200을 반환하여 수락을 확인했습니다.
xAI에 버킷이 삭제되었는지, 어떤 접근 제어가 있었는지, 데이터 처리 계약(DPA)이 적용되었는지(공개 시점에는 게시된 것이 없음) 문의하세요.
모든 코딩 에이전트를 위한 아키텍처 완화 조치:
컨테이너/VM에서 에이전트를 실행하고, 작업 디렉토리만 마운트하고 홈 디렉토리, SSH 에이전트, Docker 소켓, 클라우드 자격 증명 디렉토리는 노출하지 마세요.
송신 제어를 구현: 모델 추론 엔드포인트와 인증 호스트는 허용하지만, 일반 객체 스토리지 직접 업로드는 차단하고 100MB를 초과하는 전송에 대해 알림을 설정하세요.
전체 호스트 패킷 캡처, DNS 로깅, 엔드포인트 네트워크 텔레메트리를 사용하여 포그라운드 바이트 카운터가 놓칠 수 있는 백그라운드 코디네이터 프로세스의 업로드를 탐지하세요.
최소 및 최대 프롬프트를 유선 캡처 하에서 테스트하세요. 에이전트가 파일을 읽지 말라고 지시받은 경우는 컨텍스트 윈도우를 넘어선 데이터 유출 탐지에 중요합니다.
최소 세 가지 프롬프트 케이스를 실행하세요: (1) "OK라고 답하고 어떤 파일도 읽지 마세요," (2) 특정 파일 하나를 읽으세요, (3) 프로젝트 언어를 검사하세요. 그런 다음 엔드포인트별 바이트를 비교하세요.
