เจาะลึกจุดอ่อนความปลอดภัยของ Grok Build CLI 0.2.93: อัปโหลดทั้ง repo อย่างเงียบเชียบ ไม่ปิดบังรหัสผ่าน และปิดการใช้งาน opt-out ไม่ได้ผล

ความแตกต่างของขนาดข้อมูลพิสูจน์ว่าการอัปโหลดไม่ได้เป็นผลมาจากสิ่งที่ agent อ่าน ในการทดสอบกับ repository ขนาด 12 GB ช่องทาง storage ส่งข้อมูล 5.10 GiB ใน 73 chunks (ทั้งหมด HTTP 200) ในขณะที่ช่องทาง model-turn ส่งเพียง 192 KB ซึ่งเป็นสัดส่วน ~27,800 เท่า แม้จะให้คำสั่ง 'ตอบ OK อย่าอ่านไฟล์ใดๆ' เครื่องมือก็ยังอัปโหลดทั้ง repo เป็น git bundle การ clone bundle ที่ดักจับได้จะกู้คืนไฟล์ (src/_probe/never_read_canary.txt) ที่ agent ได้รับคำสั่งห้ามเปิดอ่าน พร้อมกับประวัติการ commit ทั้งหมด

ประเภทของความลับและไฟล์ที่ถูกส่งโดยไม่ปิดบัง

• ไฟล์ .env ที่มี API keys, รหัสผ่านฐานข้อมูล และข้อมูลรับรองอื่นๆ ถูกส่ง ตามตัวอักษร โดยไม่มีการปกปิดหรือซ่อน ผ่านทั้งสองช่องทาง ในการทดสอบที่ควบคุม ไฟล์ 48 KB ที่มีข้อมูลรับรองฐานข้อมูลและ API keys ปรากฏในรูปแบบข้อความธรรมดาใน request body
• ทุกไฟล์ที่ถูกติดตาม (tracked file) ใน repository รวมถึง ประวัติ git ทั้งหมด (ทุก commit, branch, tag) ถูกบรรจุและอัปโหลด ซึ่งหมายความว่าความลับที่ถูกลบไปเมื่อหลายเดือนก่อนแต่ถูกหมุนเวียนแล้วอาจยังคงอยู่ในข้อมูลที่อัปโหลด
• กลไกการอัปโหลดถูกระบุว่าเป็น first-party Rust crate (xai-data-collector) ที่อยู่ใน binary โดยมี source paths เช่น crates/codegen/xai-data-collector/src/gcs.rs และ crates/codegen/xai-grok-shell/src/upload/
• ใน codebase จริงขนาด 12 GB ของไฟล์สุ่มที่ไม่เคยถูกอ่าน endpoint storage ยังคงยอมรับการอัปโหลดโดยไม่มีการปฏิเสธตามขนาด การตอบกลับที่ไม่ใช่ 200 เพียงอย่างเดียวคือข้อผิดพลาดโควตาการใช้โมเดล (402/429) ไม่ใช่ความล้มเหลวในการจัดเก็บ

ความล้มเหลวของปิดการใช้งาน Opt-Out

นักวิจัยทดสอบสวิตช์ความเป็นส่วนตัว 'Improve the model' และพบว่า ไม่สามารถหยุดการอัปโหลดได้

• หลังจากปิดสวิตช์และรีสตาร์ท endpoint การตั้งค่าเซิร์ฟเวอร์ยังคงส่งกลับ

  trace_upload_enabled: true

• ช่องทาง storage ยังคงรับ git-bundle chunks ด้วยการตอบกลับ HTTP 200
• มีตัวเลือก disable_codebase_upload=true ในการตั้งค่า harness แต่ความสัมพันธ์กับพฤติกรรมฝั่งเซิร์ฟเวอร์นั้นไม่มีเอกสาร และการทดสอบของนักวิจัยแสดงให้เห็นว่าเซิร์ฟเวอร์ไม่เคารพการตั้งค่าฝั่งไคลเอ็นต์

คำแนะนำการป้องกันสำหรับนักพัฒนาที่ได้รับผลกระทบ

นักวิจัยต้นทางและแหล่งวิเคราะห์อื่นๆ แนะนำดังต่อไปนี้ :

การดำเนินการทันทีสำหรับทีมที่ใช้ Grok Build CLI กับ private repos:

• หมุนเวียน credentials ทั้งหมด ที่เคยอยู่ในไฟล์ .env ใดๆ, ไฟล์กำหนดค่า หรือ git history ภายใน repositories ที่ใช้กับ Grok Build เนื่องจากข้อมูลเหล่านี้อาจถูกส่งและจัดเก็บใน GCS bucket grok-code-session-traces
• ตรวจสอบ git history หาความลับที่อาจมีอยู่ใน commit ใดๆ ในอดีต เนื่องจาก CLI ส่งประวัติการ commit ทั้งหมด
• สันนิษฐานว่าข้อมูลถูกจัดเก็บ ไม่ใช่แค่ส่งผ่าน — เซิร์ฟเวอร์ส่งคืน HTTP 200 ในการร้องขอการจัดเก็บทั้งหมด ยืนยันการยอมรับ
• ถาม xAI ว่า bucket ถูกลบไปหรือไม่, มีการควบคุมการเข้าถึงอะไรบ้าง และมี Data Processing Agreement ครอบคลุมหรือไม่ (ไม่มีเผยแพร่ในขณะที่เปิดเผยข้อมูล)

การป้องกันเชิงสถาปัตยกรรมสำหรับ coding agent ใดๆ:

• รัน agent ใน containers/VMs โดย mount เฉพาะ task directory, ไม่มี home directory, ไม่มี SSH agent, ไม่มี Docker socket และไม่เปิดเผยไดเรกทอรี credentials บนคลาวด์
• ใช้การควบคุม egress: อนุญาตเฉพาะ endpoints การอนุมานโมเดลและโฮสต์สำหรับยืนยันตัวตน แต่ปฏิเสธการอัปโหลดไปยัง object-storage แบบทั่วไปโดยตรง แจ้งเตือนหากมีการถ่ายโอนเกิน 100 MB
• ใช้ packet capture เต็มรูปแบบ, DNS logging และ endpoint network telemetry เพื่อตรวจจับการอัปโหลดโดยกระบวนการ coordinator ที่ทำงานในพื้นหลังซึ่ง byte counters ที่มองเห็นอาจมองไม่เห็น
• ทดสอบ prompts ขั้นต่ำและสูงสุด ภายใต้การดักจับแพ็กเก็ต — กรณีที่ agent ได้รับคำสั่งไม่ให้อ่านไฟล์เป็นสิ่งสำคัญสำหรับการตรวจจับการขโมยข้อมูลที่เกิน context window
• รัน prompt อย่างน้อยสามกรณี: (1) 'ตอบ OK อย่าอ่านไฟล์ใดๆ' (2) อ่านไฟล์เฉพาะหนึ่งไฟล์ (3) ตรวจสอบภาษาโปรเจกต์ — แล้วเปรียบเทียบไบต์ต่อ endpoint