ZCode đã đóng gói 42.411 tệp vào một kho lưu trữ mà chỉ Zhipu mới có thể mở

Ngày 18 tháng 9 năm 2026, một nhà phát triển viết dưới tên ferstar đã công bố bản mổ xẻ về ZCode, tác nhân lập trình AI trên máy tính để bàn do nhà phát triển mô hình Trung Quốc Zhipu AI tạo ra, sau khi nhận thấy một thư mục ẩn trong thư mục chính của mình đã tăng vượt quá 700 MB. Bên trong đó, anh ấy tìm thấy một kho lưu trữ mã hóa 313 MB chứa 42.411 tệp lấy từ một không gian làm việc 345 MB, 86,6% trong đó là lịch sử Git, được ứng dụng khách đóng gói và chuẩn bị để tải lên bộ lưu trữ đối tượng Alibaba Cloud. Kho lưu trữ được niêm phong bằng một khóa mà chỉ máy chủ của Zhipu mới có thể mở, và ứng dụng khách không cung cấp công tắc nào để ngăn nó được tạo. Zhipu đã xin lỗi vào cùng buổi tối hôm đó. Toàn bộ hồ sơ, cùng với mức độ tin cậy và trạng thái tổn hại của chính kho lưu trữ, nằm trong Orca AI Incident Archive, nơi ghi lại từng sự cố AI được ghi nhận kèm các nguồn được trích dẫn.

ZCode là agent lập trình trên máy tính để bàn của Zhipu: nó đọc dự án, chạy các lệnh shell và viết mã. Công ty giao dịch tại Hồng Kông với mã 2513.HK và đặt thương hiệu cho nhánh quốc tế của mình là Z.ai, tên xuất hiện trên các máy chủ ZCode mà ferstar đã kiểm tra. The Paper, hãng tin Thượng Hải đã phỏng vấn anh và một số nhà phát triển khác sau đó, đưa tin rằng bài đăng của anh có tiêu đề đại ý là “Vén bức màn về việc ZCode âm thầm tải lên toàn bộ lịch sử Git”, và rằng nó lan truyền khắp các nhóm nhà phát triển Trung Quốc trong vòng vài giờ sau khi xuất bản.

Bên trong thư mục ẩn có gì?

Những con số của chính Ferstar là xương sống của vụ việc, và chúng đã được The Next Web, InfoQ và ban tài chính của China National Radio tái hiện một cách nhất quán. Tệp lưu trữ trong thư mục checkpoints ZCode của anh ta có dung lượng 313 MB. Tệp trạng thái bên cạnh ghi nhận một không gian làm việc khoảng 345 MB với 42.411 tệp. Thư mục .git chiếm 86,6% khối dữ liệu: 196,1 MB bộ nhớ đệm lưu trữ tệp lớn của Git, 102,2 MB đối tượng Git chứa toàn bộ lịch sử commit, và một phần nhỏ của reflog. Mã nguồn và tài liệu thực tế chiếm khoảng 13,4%.

Sự phân biệt này quan trọng vì lịch sử Git là nơi những tài liệu đã bị xóa khỏi cây hiện tại thường vẫn tồn tại. Bài viết của The Paper nêu trực tiếp luận điểm này: một kho lưu trữ kiểu này có thể mang theo lịch sử chỉnh sửa của một dự án từ lần commit đầu tiên, nội dung đã bị xóa, các bản nháp chưa được commit và những tệp cấu hình cũ hơn, bao gồm cả thông tin xác thực đã bị loại bỏ khỏi mã từ lâu nhưng vẫn còn trong các commit trước đó và trong bộ nhớ đệm tệp lớn.

Kho lưu trữ 313 MB của chính Ferstar chưa từng rời khỏi máy của anh ta. Nhật ký trạng thái của nó cho thấy 564 lần thử tải lên thất bại, và nó đã bị kẹt ở trạng thái chờ xử lý, vượt quá giới hạn kích thước. Để kiểm tra xem pipeline có hoạt động chút nào không, anh ta đã thử một kho lưu trữ công khai nhỏ gồm 538 tệp; bản chụp nhanh đó đã được nén và mã hóa xuống còn khoảng 15 KB và được máy chủ chấp nhận. Lần truyền đó là lần được ghi nhận xác nhận đã hoàn tất từ đầu đến cuối, và chính nó biến phát hiện này từ một bài tập đọc mã thành một vụ tuồn dữ liệu ra ngoài với đầu nhận đã được chứng minh.

Việc thu thập không gắn với bất kỳ hành động nào mà người dùng sẽ nhận ra là "tải lên kho lưu trữ của tôi." Theo bản dựng lại của ferstar, một trigger kích hoạt trước mỗi prompt được gửi đến mô hình, và một trigger khác chạy dưới dạng tác vụ cập nhật Repo Wiki. Việc xóa gói lưu trữ đang chờ xử lý không ngăn được nó: một bài viết trên cộng đồng nhà phát triển của Tencent Cloud ghi lại rằng gói đã được dựng lại trong vòng 30 phút và bộ đếm lỗi tăng từ 564 lên 565. Cách dừng đáng tin cậy duy nhất mà tác giả tìm ra là làm cho thư mục checkpoint không thể ghi, khiến việc thu thập thất bại ở bước ghi đĩa, với cái giá là mất khả năng rollback checkpoint và giao diện dòng thời gian.

Một khóa mà chỉ nhà cung cấp mới có thể sử dụng

Việc mã hóa là mã hóa phong bì đúng chuẩn, và đó chính là phần mà người dùng không thể lách qua. Bản tái dựng của InfoQ, dựa trên quá trình dịch ngược của ferstar, mô tả việc máy khách truy xuất một snapshot ID, một khóa công khai RSA và thông tin xác thực tải lên Alibaba Cloud OSS từ zcode.z.ai, đóng gói và mã hóa không gian làm việc cục bộ, rồi gửi trực tiếp bản mã đến OSS. Nội dung được mã hóa bằng AES-256-CTR; khóa đối xứng được bọc bằng RSA-OAEP-SHA256 dưới khóa công khai của máy chủ, mà phần khóa riêng tư của nó vẫn nằm trong đám mây của Zhipu.

Việc định tuyến quan trọng không kém gì mật mã. Bởi vì ứng dụng khách đã tải trực tiếp lên Alibaba Cloud thay vì qua các máy chủ ứng dụng riêng của Zhipu, lưu lượng không đi qua dịch vụ Zhipu nào có thể ghi nhật ký hoặc lọc nó, nên không có dịch vụ Zhipu nào nằm trên đường đi để ghi nhật ký hoặc lọc những gì đã rời đi. Và bởi vì khóa riêng chưa bao giờ nằm trên thiết bị, ferstar không thể mở kho lưu trữ của chính mình: The Next Web đưa tin rằng anh ấy đã thử mọi khóa riêng trên máy của mình và thất bại. Anh ấy mô tả cách sắp đặt trong bài đăng của mình như một khóa mà chỉ máy chủ có thể sử dụng, thứ chỉ có một mục đích.

Hai cài đặt trong ứng dụng khách trông như lẽ ra phải ngăn chặn điều này, nhưng cả hai đều không. Công tắc "tối ưu trải nghiệm" quy định liệu dữ liệu có thể được dùng để huấn luyện mô hình hay không; công tắc "lập chỉ mục ảnh chụp kho lưu trữ" quy định liệu máy chủ có xây dựng chỉ mục trên các ảnh chụp đã đến hay không. Cả hai đều tác động ở phía sau khâu thu thập. Ferstar phát hiện việc thu thập diễn ra vô điều kiện, và The Next Web đưa tin rằng khi đọc chính sách quyền riêng tư, ông nhận thấy chính sách mô tả việc thu thập văn bản hội thoại và tệp nhưng không nói gì về các ảnh chụp không gian làm việc tự động mang theo toàn bộ lịch sử Git.

Lời giải thích mà Zhipu đưa ra, và bốn ngày sau đó

Zhipu đã phản hồi ngay trong ngày, thông qua nhóm người dùng chính thức của ZCode thay vì thông cáo báo chí. Theo đưa tin của Global Times và được Security Inside đăng lại, công ty cho rằng hành vi này xuất phát từ một tính năng có tên đánh chỉ mục cơ sở mã, tính năng này hỗ trợ lập chỉ mục cục bộ, khôi phục điểm kiểm tra phiên, quay lui phiên bản và tạo Repo Wiki, và cho biết bước Repo Wiki chính là thứ đã kích hoạt việc tải kho mã lên đám mây. Tính năng này đã được bật mặc định từ khi ra mắt. Zhipu cho biết dữ liệu được tải lên chỉ được dùng để tạo trang Repo Wiki và bị xóa ngay sau đó, rằng dữ liệu không được lưu trữ và không được dùng để huấn luyện, đồng thời xin lỗi những người dùng bị ảnh hưởng. Công ty cam kết mở mã nguồn cơ sở mã ZCode, mời bên thứ ba đánh giá và công bố kết quả, đồng thời tặng mỗi người dùng ZCode thêm một lần đặt lại hạn mức hàng tuần như khoản bồi thường.

Bản sửa lỗi đã có vào ngày hôm sau. The Paper đưa tin rằng ZCode 3.14.0 đã phát hành vào ngày 19 tháng 9 với một mục trong nhật ký thay đổi ghi rằng “sửa vấn đề tải lên bất thường của wiki kho lưu trữ”, và ferstar đã xác nhận cùng ngày rằng chuỗi tải lên cùng điểm cuối của nó đã biến mất. Vào ngày 20 tháng 9, nền tảng MaaS của Zhipu công bố một tùy chọn không lưu trữ sắp ra mắt, theo đó đầu vào và đầu ra sẽ không được lưu trữ tĩnh; The Paper lưu ý rằng tùy chọn này được đăng ký tham gia theo đơn, loại trừ Batch API và File API, và vẫn cho phép lưu trữ từ 30 ngày trở lên khi pháp luật hoặc điều tra lạm dụng yêu cầu. Vào ngày 21 tháng 9, mã nguồn của ứng dụng khách đã được công khai trên GitHub theo giấy phép Apache 2.0, bao gồm ứng dụng máy tính để bàn, ứng dụng khách web, phần phụ trợ, CLI tác nhân và môi trường chạy tác nhân.

Hai cuộc kiểm toán đã được ủy thác và kết luận của chúng được công bố dưới dạng tóm tắt. Học viện Công nghệ Thông tin và Truyền thông Trung Quốc phát hiện bucket Alibaba Cloud OSS zcode-prod ở trạng thái mà Zhipu gọi là không có dữ liệu. Công ty bảo mật NSFOCUS báo cáo rằng mọi đối tượng dữ liệu và chính bucket đã bị xóa, đồng thời họ không tìm thấy đường dẫn nào còn lại trong ZCode 3.14.0 có thể kích hoạt bản chụp kho lưu trữ cục bộ hoặc gửi tệp ra bên ngoài. Báo cáo đánh giá đầy đủ vẫn chưa xuất hiện, và The Next Web đưa tin Zhipu chưa ấn định ngày cho báo cáo này.

Vị khách hàng đã cáo buộc nhiều hơn, rồi sau đó rút lại điều đó.

Cáo buộc nghiêm trọng nhất về tổn thất thực tế không đến từ ferstar. Ngày 19 tháng 9, theo China National Radio, Taiyuan Chengming Technology đã gửi cho Zhipu một thư pháp lý mang số Chengming [2026] Legal Letter No. 1, được ChainCatcher đăng lại chi tiết. Công ty cho biết sáu không gian làm việc lập trình của mình đã bị tải lên mà không có sự đồng ý — 34.500 tệp và khoảng 425 MB ở dạng văn bản thuần — và liệt kê mã nguồn đầy đủ, kiến trúc hệ thống, lịch sử phiên bản, mật khẩu cơ sở dữ liệu, thông tin xác thực đám mây và thông tin cá nhân của nhân viên. Công ty cho biết không gian làm việc thứ bảy gồm 1.947 tệp và khoảng 144 MB đã được đóng gói và mã hóa nhưng thất bại sau 32 lần thử tải lên. Công ty cũng lưu ý rằng ứng dụng khách của mình đã cập nhật lên phiên bản 3.12.3 vào ngày 16 tháng 9, vậy mà các lần tải lên vẫn bị phát hiện lúc 00:28 ngày 18 tháng 9, buổi sáng Zhipu đưa ra lời xin lỗi.

Lá thư đặt ra một câu hỏi mà các cuộc kiểm toán không trả lời: liệu dữ liệu có rời khỏi đất nước hay không. Chengming cho biết các yêu cầu mạng của ZCode trỏ tới một pháp nhân Singapore trong khi thỏa thuận dịch vụ của nó được ký với Beijing Zhipu Huazhang, và đề nghị Zhipu xác định bên nào chịu trách nhiệm cũng như liệu có bất kỳ việc chuyển giao hoặc lưu trữ nào diễn ra bên ngoài Trung Quốc đại lục hay không. Lá thư nêu mười hai yêu cầu, bao gồm xóa toàn bộ dữ liệu đã tải lên cùng dữ liệu phái sinh, bộ nhớ đệm và bản sao lưu của nó kèm giấy chứng nhận bằng văn bản; giải thích dữ liệu đã đi đâu và liệu dữ liệu có được chia sẻ với bên thứ ba hoặc dùng để huấn luyện hay không; mô tả cách lưu giữ khóa riêng và cung cấp nhật ký truy cập; xác định phạm vi chính xác của tuyên bố "đã bị hủy"; và cam kết bằng văn bản sẽ không bao giờ tải lên lại. Lá thư cho Zhipu thời hạn đến ngày 10 tháng 10 để trả lời bằng văn bản và bảo lưu quyền yêu cầu bồi thường thiệt hại và khiếu nại lên các cơ quan quản lý. Caixin Global đưa tin rằng Zhipu gọi các cáo buộc là không đúng sự thật.

Hai ngày sau, Chengming đã rút lại các tuyên bố đó. Bộ phận tài chính của China National Radio đưa tin rằng vào ngày 21 tháng 9, công ty đã ra thông cáo rút lại, nói rằng các tuyên bố trước đó dựa trên bằng chứng sai lệch, mô tả không chính xác và cách diễn đạt phóng đại, rằng chúng đã làm tổn hại danh tiếng của Zhipu, và rằng công ty sẽ ngừng phát ngôn với truyền thông. Reuters cũng đưa tin về việc rút lại này, theo The Next Web. Mục lưu trữ về sự việc này được ghi ngày 18 tháng 9, ngày phát hiện ra sự việc; bức thư, thời hạn 10 tháng 10 trong đó và thông cáo rút lại đều xuất hiện sau ngày đó. Theo hồ sơ công khai tính đến cuối tháng 10, không có công ty nào được nêu tên đứng sau tuyên bố rằng bí mật của mình đã bị lộ.

Một bản phát hành mã nguồn mở với lịch sử đã bị xóa bỏ

Việc mở mã nguồn client là biện pháp khắc phục mà Zhipu dựa vào nhiều nhất, và nó đi kèm với một lỗ hổng. The Paper đưa tin rằng kho lưu trữ đã công bố chứa hai commit: một commit khởi tạo rỗng và một commit duy nhất thêm khoảng 6.973 tệp và 1,03 triệu dòng, với các pull request bị khóa và các issue bị đóng. Dù pipeline tải lên trông như thế nào khi nó được phát hành, và bất kể bản phát hành nào chứa nó, thì điều đó không nằm trong lịch sử mà bất kỳ ai hiện nay có thể đọc.

Việc theo dõi tiếp theo của chính Ferstar làm rõ giới hạn. Ông xác nhận đường ống tải lên đã không còn và rằng cơ chế điểm kiểm tra còn lại chỉ thực hiện công việc Git cục bộ, sau đó chỉ ra những gì một cuộc kiểm toán bucket có thể và không thể cho thấy: dọn sạch và xóa bucket là hành động cắt lỗ đúng đắn, nhưng một cuộc kiểm tra của bên thứ ba được thực hiện sau ngày 20 tháng 9 chỉ có thể xác lập rằng bucket đã trống tại thời điểm đó. Nó không thể tái dựng những gì đã đi qua trước ngày 18 tháng 9, liệu có bất cứ thứ gì đã được giải mã, sao chép hoặc sao lưu hay không, hoặc đường ống đã chạy trong bao lâu. Một tuyên bố xóa vẫn phần lớn dựa vào lời của bên đã xóa.

Phân tích của InfoQ liệt kê những câu hỏi vẫn còn bỏ ngỏ bằng cùng cách diễn đạt: đã tải lên thành công bao nhiêu ảnh chụp nhanh kho lưu trữ và bởi bao nhiêu người dùng, các đối tượng được lưu giữ trong bao lâu, những hệ thống phía máy chủ hoặc nhân sự nào có thể giải mã chúng, liệu có tồn tại nhật ký truy cập đầy đủ hay không, và liệu việc xóa có bao gồm các bản sao lưu và những bản sao khác hay không. Bài viết cũng nêu rõ ZCode vẫn là gì sau khi khắc phục. NOTICE của chính dự án cảnh báo rằng môi trường chạy tác nhân dùng chung không cung cấp hộp cát cấp hệ điều hành theo mặc định, và ứng dụng khách vẫn giữ các bề mặt shell, terminal, Git, MCP, plugin và trình duyệt nhúng có thể đọc tệp, khởi chạy tiến trình và truy cập mạng trong phạm vi quyền của tài khoản người dùng.

Những gì đã được xác lập, và những gì không nguồn nào trả lời được

Cơ chế này không có gì phải tranh cãi. Chính các tuyên bố của Zhipu thừa nhận rằng dữ liệu kho lưu trữ đã được tải lên, rằng tính năng này mặc định được bật và rằng dữ liệu đã được đưa tới một bucket trên đám mây do công ty kiểm soát. Các đo đạc của Ferstar, lời xin lỗi của nhà cung cấp, hai cuộc kiểm toán được ủy thác và bản phát hành mã nguồn mở đều mô tả cùng một chuỗi. Không có gì trong hồ sơ tranh cãi rằng các không gian làm việc đã rời khỏi máy mà không có cơ chế từ chối tham gia khả thi. Tổn hại mà hồ sơ ghi lại là đã xảy ra thật chứ không phải giả định: các lần chuyển dữ liệu đã diễn ra, và những người có mã nằm trong đó không thể ngăn chặn cũng như không thể kiểm tra chúng.

Điều đang gây tranh cãi, hoặc đơn giản là chưa biết, là quy mô và hậu quả. Không nguồn nào nêu rõ có bao nhiêu người dùng đã chạy các cấu hình mặc định bị ảnh hưởng, quy trình đã hoạt động bao lâu trước ngày 18 tháng 9, hoặc liệu có đối tượng nào đã tải lên từng bị giải mã hay chưa. Cam kết của Zhipu rằng dữ liệu đã bị hủy sau khi tạo wiki và chưa từng được dùng để huấn luyện là tuyên bố của chính công ty; các phát hiện của CAICT và NSFOCUS mô tả trạng thái của bucket sau khi khắc phục, chứ không phải những gì đã đi qua nó. Hồ sơ lưu trữ chấm điểm bản ghi là A về tài liệu, và tài liệu thì mạnh về cơ chế nhưng mỏng về phạm vi.

Điều gì đã thay đổi, và điều gì thì không.

Chi phí thương mại đã đến ngay lập tức. Đài Phát thanh Quốc gia Trung Quốc đưa tin rằng cổ phiếu niêm yết tại Hồng Kông của Zhipu đã giảm 1,79% vào ngày 21 tháng 9, 6,55% vào ngày 22 tháng 9 và 12,4% vào ngày 23 tháng 9, tức mức giảm lũy kế hơn 16% qua ba phiên giao dịch, và rằng Zhipu đã không đề cập đến việc có bao nhiêu người dùng bị ảnh hưởng hoặc liệu dữ liệu lịch sử đã bị giải mã hay đã được sao lưu hay chưa.

Một người dùng ZCode thực sự đã nhận được gì trong bốn ngày sau khi phát hiện:

• Ngày 18 tháng 9: lời xin lỗi công khai nêu rõ việc lập chỉ mục mã nguồn là nguyên nhân, cam kết mã nguồn mở ứng dụng khách và thuê đánh giá của bên thứ ba, cùng một lần đặt lại hạn mức hàng tuần bổ sung cho mỗi người dùng.

• 19 tháng 9: ZCode 3.14.0, với Repo Wiki bị loại bỏ và đường dẫn tạo ảnh chụp nhanh cục bộ cùng tải lên đã bị cắt bỏ. Ferstar xác nhận chuỗi tải lên đã biến mất vào ngày hôm sau.

• 20 tháng 9: tùy chọn không lưu trữ đã được công bố cho nền tảng MaaS của Zhipu, theo hình thức tự nguyện chọn tham gia, loại trừ Batch API và File API, và vẫn phải tuân theo thời hạn lưu trữ pháp lý từ 30 ngày trở lên.

• 21 tháng 9: ZCode được phát hành theo Apache 2.0 mà không kèm lịch sử commit trước sự cố của nó; các bản tóm tắt của CAICT và NSFOCUS báo cáo rằng bucket lưu trữ trống và đường ra không tồn tại.

Không điều nào trong số đó có hiệu lực hồi tố. Những câu hỏi cụ thể mà Chengming nêu ra — dữ liệu đã đi đâu, ai có thể giải mã nó, liệu nó có rời khỏi đất nước hay không, và cụm “bị phá hủy” bao trùm những gì — đã được gửi bằng văn bản với thời hạn 10 tháng 10, rồi sau đó bị rút lại cùng với công ty đã đặt ra chúng. Zhipu đã hứa có một báo cáo đánh giá đầy đủ của bên thứ ba nhưng không ấn định ngày. Cho đến khi báo cáo đó xuất hiện, lời kể công khai duy nhất về những gì quy trình xử lý đã làm với dữ liệu mà nó nhận được là lời kể của công ty đã xây dựng nên nó, và bằng chứng duy nhất có thể đo lường một cách độc lập là một tệp 313 MB đã thất bại 564 lần khi cố rời khỏi máy tính xách tay của một lập trình viên.