Cảnh báo bảo mật: Công cụ CLI của xAI Grok tự động tải toàn bộ mã nguồn và lịch sử Git lên máy chủ

Những gì xAI Grok Build CLI thực sự gửi đến xAI - phân tích ở cấp độ đường truyền (grok 0.2.93)

Một cuộc phân tích kỹ thuật có đo lường và có thể tái lập. Các phát hiện được hỗ trợ bởi các bằng chứng thu thập được (endpoint, phương thức HTTP, mã trạng thái, kích thước byte, máy chủ) và các lệnh tái lập; trong trường hợp quan sát trực tiếp nhưng không lưu lại thành tệp, mục §7 sẽ nêu rõ điều đó. Mục 8 là phụ lục bằng chứng với các mã SHA-256 và danh sách "những gì chúng tôi chưa chứng minh được". Tất cả dữ liệu thu thập đều từ lưu lượng truy cập trên máy tính cá nhân của tôi, sử dụng một kho lưu trữ dùng một lần chứa các bí mật "canary" giả — không có thông tin xác thực thực tế nào bị lộ.

0. Tóm tắt

CLI lập trình Grok Build chính thức của xAI (grok), khi đăng nhập bằng tài khoản người dùng thông thường, thực hiện ba việc đáng được ghi lại chính xác:

Không có điều nào trong số này chứng minh xAI huấn luyện trên dữ liệu đó — đó là một câu hỏi về chính sách được giải quyết trong §6. Điều đã được chứng minh là việc truyền tải, chấp nhận và lưu trữ dữ liệu.

1. Đối tượng thử nghiệm (nguồn gốc)

Định danh tệp nhị phân (tái lập: file $(readlink -f ~/.grok/bin/grok); ~/.grok/bin/grok --version; shasum -a 256 $(readlink -f ~/.grok/bin/grok)):

Cơ chế tải lên là một Rust crate chính chủ. Lệnh strings trên tệp nhị phân cho ra các đường dẫn nguồn và hằng số sau (tái lập: strings <binary> | grep -E 'xai-data-collector|grok-code-session-traces|storage.googleapis'):

2. Phương pháp (có thể tái lập)

Môi trường: macOS, Apple Silicon, grok 0.2.93, tháng 7 năm 2026.

Kho lưu trữ Canary: mỗi tệp mang một dấu hiệu nhận dạng duy nhất để bất kỳ dữ liệu nào xuất hiện trong lưu lượng truy cập được ghi lại đều có thể truy xuất nguồn gốc rõ ràng đến tệp đó. Tệp bí mật secrets.env /.env:

3. Phát hiện 1 — Nội dung tệp, bao gồm cả tệp bí mật, đều được truyền tải và chấp nhận (200)

Khẳng định: khi Grok đọc một tệp, nội dung của nó được truyền đến xAI — được tuần tự hóa vào phần thân của model-turn POST /v1/responses, và được đóng gói vào một tệp lưu trữ session_state, sau đó được tải lên và chấp nhận (HTTP 200) qua POST /v1/storage — mà không có bất kỳ sự che giấu (redaction) nào đối với nội dung tệp. Một tệp.env được gửi đi giống như bất kỳ tệp nào khác.

Bằng chứng đường truyền — một phần thân yêu cầu POST cli-chat-proxy.grok.com/v1/responses đã giải mã, dung lượng 48.070 byte (có thể xác định là một model turn nhờ đoạn JSON "messages":[…]"model":"grok-4.5" được nhúng bên trong). Nó chứa tệp bí mật nguyên văn (phụ lục: secrets_responses_body.bin, secret_verbatim.txt):

Tái lập: grep -a "CANARY7F3A9-DBPASS" secrets_responses_body.bin → khớp. Tất cả sáu dấu hiệu tệp (nguồn, logic, README, JS lồng nhau, khóa API, mật khẩu DB) đều có thể khôi phục từ các phần thân /v1/responses đã giải mã. (Bằng chứng này xác nhận bí mật đã được truyền đến endpoint /v1/responses; tệp thân thô không chứa trạng thái phản hồi, vì vậy khẳng định về việc chấp nhận (200) được xác lập dựa trên kênh /v1/storage ngay bên dưới, vốn được ánh xạ trạng thái trong wire_12gb.log.)

Kênh thứ hai — được lưu trữ vào Google Cloud Storage. Cùng nội dung đó được đóng gói vào một tệp lưu trữ session_state và tải lên qua POST /v1/storage. Được chứng minh bằng cách giải nén tệp bằng chứng trước khi nó bị xóa (phụ lục: secrets_session_state.tar.gz):

Như vậy, bí mật không chỉ được xử lý trong quá trình truyền tải; nó còn được ghi vào một tệp lưu trữ dành cho việc lưu trữ lâu dài.

Phủ đầu lập luận "bạn đã yêu cầu nó đọc các bí mật". Một lần chạy kiểm soát với một tệp mà tác nhân được yêu cầu không mở (untouched_secret.txt) cùng với câu lệnh "Reply exactly OK, do not read any files" (Chỉ trả lời OK, không đọc bất kỳ tệp nào) cho thấy không có dấu hiệu nào của tệp đó xuất hiện trong bất kỳ phần thân nào được ghi lại. Do đó, việc rò rỉ chỉ giới hạn ở các tệp mà Grok thực sự đọc — nhưng nó đọc một cách tùy tiện (bất kỳ tệp nào liên quan đến tác vụ, bao gồm cả.env) và không áp dụng bất kỳ sự che giấu nào đối với nội dung tệp đó. Lỗi nằm ở việc tệp bí mật đã được truyền đi mà không bị che giấu, chứ không phải ở hành động đọc tệp. Làm rõ phạm vi quan trọng: kiểm soát này cho thấy tệp không được đọc không xuất hiện trong các phần thân /v1/responses — đó là Kênh A (các tệp tác nhân đọc). Nó không loại trừ ảnh chụp nhanh toàn bộ kho lưu trữ /v1/storage trong §4 (Kênh B), vốn — theo bằng chứng về khối lượng dữ liệu ở đó — có quét cả những tệp chưa bao giờ được đọc; tôi không thể giải nén khối mã nguồn /v1/storage để kiểm tra tệp cụ thể này. Vì vậy, "tệp không đọc không bị tải lên" chỉ đúng với kênh model-turn, không đúng với ảnh chụp nhanh mã nguồn. (Hai lưu ý phạm vi bổ sung: (i) trong các lần chạy của tôi, tệp.env/secrets.env được theo dõi bởi git; tôi chưa kiểm tra riêng liệu một tệp bị gitignore có bị tải lên hay không, nên tôi không đưa ra khẳng định về gitignore — cơ chế này dựa trên việc đọc theo crate file_access_tracker, nhưng trường hợp cụ thể đó chưa được kiểm tra. (ii) Các giá trị canary nằm trong các khóa API_KEY=/DB_PASSWORD= bên trong tệp.env/secrets.env nhưng không phải là các token có độ entropy cao theo định dạng thực; tôi đã chứng minh tệp.env này được truyền đi mà không bị che giấu, chứ không phải là không có cơ chế che giấu nào cho, ví dụ, một khóa có định dạng sk-….)

4. Phát hiện 2 — Toàn bộ kho lưu trữ được tải lên ở quy mô nhiều GB; giới hạn duy nhất là hạn mức của mô hình, không phải dung lượng lưu trữ

Khẳng định: Grok tải lên một ảnh chụp nhanh toàn bộ kho lưu trữ mà không có giới hạn dung lượng lưu trữ trong phạm vi thử nghiệm. Khi kho lưu trữ lớn dần, nó chuyển đổi chiến lược tải lên và tiếp tục trả về mã 200; trên một kho lưu trữ 12 GB, 73 khối dữ liệu khoảng 75,0 MB (5,10 GiB) đã được tải lên mà không có lỗi nào trước khi quá trình ghi lại bị ngắt giữa chừng.

Quét kích thước qua đường truyền (nội dung không thể nén nên tệp tar không thể thu nhỏ; mỗi bước là một phiên mới). Chỉ hàng 12 GB được lưu lại thành tệp (wire_12gb.log); các hàng nhỏ hơn được quan sát trực tiếp trong quá trình quét nhưng nhật ký của chúng không được lưu (xem §7):

Bằng chứng được bảo tồn: wire_12gb.log (phụ lục). Nó chứa 83 phản hồi 200 từ /v1/storage*: 82 yêu cầu POST tải lên nội dung …/v1/storage — trong đó 73 là các khối khoảng 75,0 MB mỗi khối (kích thước byte tối thiểu 75.014.811 / tối đa 75.014.871, tổng cộng 5.476.083.317 B = 5,10 GiB / 5,48 GB) cộng với 9 yêu cầu POST nhỏ hơn — và 1 kiểm tra trùng lặp /v1/storage/batch_exists. Tổng số byte yêu cầu /v1/storage* là 5.476.228.005 B. Không có yêu cầu lưu trữ nào thất bại. Quá trình ghi lại bị dừng trong khi việc tải lên vẫn đang diễn ra (dòng cuối cùng là một khối ~75 MB khác → 200), vì vậy điều này chứng minh ít nhất 5,1 GiB đã được tải lên và vẫn đang tăng khi bị ngắt — không phải là toàn bộ 12 GB đã hoàn tất. Tái lập (ba lệnh grep để không có số liệu nào gây mơ hồ): grep 'cli-chat-proxy.grok.com/v1/storage' wire_12gb.log | grep -c '> 200' → 83 (tất cả /v1/storage*); grep 'POST cli-chat-proxy.grok.com/v1/storage ' wire_12gb.log | grep -c '> 200' → 82 (chỉ các POST nội dung); grep req=75014 wire_12gb.log | grep -c '> 200' → 73 (các khối ~75 MB).

Phạm vi — đây là toàn bộ kho lưu trữ, không chỉ các tệp tác nhân đã đọc. Kênh A (§3, /v1/responses) mang các tệp tác nhân mở. Việc tải lên ở §4 này là Kênh B riêng biệt: một ảnh chụp nhanh của toàn bộ không gian làm việc. Hai dòng bằng chứng:

(Lưu ý về câu lệnh: phiên 12 GB là tương tác và tôi không ghi lại câu lệnh nguyên văn của nó, nhưng tổng 192 KB của Kênh A là bằng chứng quyết định rằng không có việc đọc hàng loạt nào xảy ra bất kể câu lệnh là gì; một lần chạy kiểm soát không đầu riêng biệt đã sử dụng câu lệnh rõ ràng "Reply exactly OK, do not read any files" và xác nhận rằng một tệp không được đọc không xuất hiện trong Kênh A.)

("Khoảng trống" trước đó hiện đã được lấp đầy bởi bằng chứng (d): một lần chạy SuperGrok duy nhất nơi nội dung của một tệp cụ thể chưa bao giờ được đọc được khôi phục từ một tệp tải lên git-bundle có trạng thái 200 được ghi lại qua đường truyền. Lần chạy 12 GB vẫn là bằng chứng cho thấy điều này có thể mở rộng lên quy mô GB.)

Không có yêu cầu lưu trữ/tải lên nào thất bại — tất cả 82 cuộc gọi /v1/storage đều trả về 200. Những phản hồi không phải 200 duy nhất trong toàn bộ quá trình ghi lại là ở endpoint mô hình cộng với một cuộc gọi quản lý phiên (tập hợp đầy đủ từ wire_12gb.log; các dòng /v1/responses cũng có trong model_limit.txt):

và cuối cùng, dưới dạng văn bản thuần trên stdout:

Các mã 402/429 là hạn mức sử dụng mô hình; mã 404 duy nhất không liên quan đến lưu trữ. Đáng chú ý là các lần tải lên lưu trữ vẫn tiếp tục trả về 200 sau khi lượt mô hình bị giới hạn tốc độ (76 phản hồi 200 từ /v1/storage xảy ra tại hoặc sau mã 429 đầu tiên) — việc tải lên mã nguồn độc lập với việc mô hình có trả lời hay không.

Phủ đầu lập luận "bạn đang nhầm lẫn bộ nhớ đệm đĩa cục bộ với việc tải lên." Khẳng định này dựa hoàn toàn vào các lần tải lên có trạng thái 200 được ghi lại qua đường truyền của các byte tệp rời khỏi máy (phần thân yêu cầu /v1/storage từ 7,5–75 MB trong tệp wire_12gb.log được bảo tồn; các yêu cầu PUT 3 GB 50 MB đến storage.googleapis.com cũng được nhìn thấy trên đường truyền, nhưng nhật ký đó không được lưu lại — §7). Nó không dựa vào việc ~/.grok/upload_queue cạn kiệt — việc cạn kiệt hàng đợi là mơ hồ (nó trống cả khi thành công và khi bị hủy) và không được sử dụng làm bằng chứng ở đây. (Một bản thảo trước đó suy luận việc tải lên từ việc hàng đợi cạn kiệt là sai và đã được rút lại; xem §7.)

5. Phát hiện 3 — Điểm đến, đo từ xa và những gì không được hiển thị trong tài liệu

6. Sự đồng ý và chính sách — được nêu trung thực

7. Những gì chúng tôi CHƯA chứng minh được (trung thực trí tuệ)

8. Phụ lục bằng chứng

Tất cả các bằng chứng và mã SHA-256 (MANIFEST.sha256). SHA-256 của tệp nhị phân: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c.

Tái lập (tóm tắt):

Tính toàn vẹn: tất cả các lần ghi lại đều là lưu lượng truy cập của chính tôi trên máy tính của tôi; các "bí mật" là các chuỗi canary giả; không có thông tin xác thực thực tế nào bị lộ. Các phát hiện chỉ áp dụng cho phiên bản grok 0.2.93 (tháng 7 năm 2026); xAI có thể thay đổi hành vi bất cứ lúc nào.