ZCode อัดไฟล์ 42,411 ไฟล์ลงในไฟล์ архив ที่มีเพียง Zhipu เท่านั้นที่เปิดได้

เมื่อวันที่ 18 กันยายน 2026 นักพัฒนาที่เขียนภายใต้นามแฝง ferstar ได้เผยแพร่การชำแหละ ZCode ซึ่งเป็นเอเจนต์เขียนโค้ดด้วย AI สำหรับเดสก์ท็อปที่พัฒนาโดยผู้พัฒนาโมเดลสัญชาติจีนอย่าง Zhipu AI หลังจากสังเกตว่าโฟลเดอร์ที่ซ่อนอยู่ในไดเรกทอรีบ้านของเขาโตเกิน 700 MB ภายในนั้นเขาพบไฟล์เก็บถาวรแบบเข้ารหัสขนาด 313 MB ซึ่งบรรจุไฟล์ 42,411 ไฟล์ที่ดึงมาจากเวิร์กสเปซขนาด 345 MB โดย 86.6% เป็นประวัติ Git ถูกแพ็กโดยไคลเอนต์และจัดเตรียมไว้สำหรับอัปโหลดไปยัง Alibaba Cloud object storage ไฟล์เก็บถาวรถูกผนึกด้วยคีย์ที่เฉพาะเซิร์ฟเวอร์ของ Zhipu เท่านั้นที่แกะได้ และไคลเอนต์ไม่มีสวิตช์ใดที่หยุดการสร้างมันได้ Zhipu ขอโทษในเย็นวันเดียวกัน บันทึกฉบับเต็ม พร้อมระดับความเชื่อมั่นและสถานะความเสียหายของไฟล์เก็บถาวรเอง อยู่ใน Orca AI Incident Archive ซึ่งบันทึกเหตุการณ์ AI ที่มีเอกสารยืนยันแต่ละเหตุการณ์เทียบกับแหล่งอ้างอิงที่ระบุไว้

ZCode คือ coding agent สำหรับเดสก์ท็อปของ Zhipu: มันอ่านโปรเจกต์ รันคำสั่งเชลล์ และเขียนโค้ด บริษัทซื้อขายในฮ่องกงภายใต้ชื่อย่อ 2513.HK และใช้ชื่อ Z.ai เป็นแบรนด์สำหรับต่างประเทศ ซึ่งเป็นชื่อที่ปรากฏบนเซิร์ฟเวอร์ ZCode ที่ ferstar ตรวจสอบ The Paper สื่อข่าวจากเซี่ยงไฮ้ที่สัมภาษณ์เขาและนักพัฒนาอีกหลายคนในภายหลัง รายงานว่าโพสต์ของเขามีหัวข้อประมาณว่า “เปิดม่านเบื้องหลังการอัปโหลดประวัติ Git ทั้งหมดของ ZCode อย่างเงียบ ๆ” และมันแพร่กระจายไปในกลุ่มนักพัฒนาจีนภายในไม่กี่ชั่วโมงหลังเผยแพร่

มีอะไรอยู่ข้างในโฟลเดอร์ที่ซ่อนอยู่

ตัวเลขของ Ferstar เองคือแกนหลักของกรณีนี้ และถูกรายงานซ้ำอย่างสม่ำเสมอโดย The Next Web, InfoQ และแผนกข่าวการเงินของ China National Radio ไฟล์เก็บถาวรในไดเรกทอรี ZCode checkpoints ของเขามีขนาด 313 MB ไฟล์สถานะที่อยู่ข้าง ๆ บันทึกเวิร์กสเปซขนาดประมาณ 345 MB และไฟล์ 42,411 ไฟล์ ไดเรกทอรี .git คิดเป็น 86.6% ของปริมาณข้อมูล: แคช Git large-file-storage ขนาด 196.1 MB, อ็อบเจกต์ Git ขนาด 102.2 MB ที่บรรจุประวัติคอมมิตทั้งหมด และ reflog อีกส่วนเล็ก ๆ ซอร์สโค้ดและเอกสารจริงมีสัดส่วนประมาณ 13.4%

ความแตกต่างนี้สำคัญ เพราะประวัติ Git คือที่ซึ่งเนื้อหาที่ถูกลบออกจาก tree ปัจจุบันมักยังคงอยู่ บทความของ The Paper ชี้ประเด็นนี้โดยตรง: คลังเก็บข้อมูลประเภทนี้อาจเก็บประวัติการแก้ไขของโปรเจกต์ตั้งแต่ commit แรก เนื้อหาที่ถูกลบ แบบร่างที่ยังไม่ commit และไฟล์กำหนดค่าที่เก่ากว่า รวมถึงข้อมูลรับรองที่ถูกถอดออกจากโค้ดนานแล้วแต่ยังคงอยู่ใน commit ก่อนหน้าและในแคชไฟล์ขนาดใหญ่

อาร์ไคฟ์ขนาด 313 MB ของ Ferstar เองไม่เคยออกจากเครื่องของเขา บันทึกสถานะของมันแสดงความพยายามอัปโหลดที่ล้มเหลว 564 ครั้ง และมันค้างอยู่ในสถานะรอดำเนินการเนื่องจากเกินขีดจำกัดขนาด เพื่อทดสอบว่าไปป์ไลน์ทำงานได้จริงหรือไม่ เขาจึงลองใช้คลังสาธารณะขนาดเล็กที่มี 538 ไฟล์ สแนปชอตนั้นถูกบีบอัดและเข้ารหัสเหลือประมาณ 15 KB และเซิร์ฟเวอร์ยอมรับการอัปโหลด การถ่ายโอนนั้นคือรายการเดียวในบันทึกที่ได้รับการยืนยันว่าเสร็จสมบูรณ์ตั้งแต่ต้นจนจบ และเป็นสิ่งที่เปลี่ยนการค้นพบนี้จากการฝึกอ่านโค้ดให้กลายเป็นการขโมยข้อมูลออกที่มีปลายทางรับข้อมูลซึ่งพิสูจน์ให้เห็นได้

การเก็บข้อมูลไม่ได้ผูกกับการกระทำใดที่ผู้ใช้จะรู้จักในชื่อ "อัปโหลดรีโพซิทอรีของฉัน" จากการสร้างเหตุการณ์ขึ้นใหม่ของ ferstar ตัวกระตุ้นตัวหนึ่งทำงานก่อนทุกพรอมต์ที่ส่งไปยังโมเดล และอีกตัวหนึ่งทำงานเป็นงานอัปเดต Repo Wiki การลบไฟล์เก็บถาวรที่รอดำเนินการไม่ได้หยุดมันไว้: บทความในชุมชนนักพัฒนาของ Tencent Cloud บันทึกว่าแพ็กเกจถูกสร้างใหม่ภายใน 30 นาที และตัวนับความล้มเหลวเพิ่มจาก 564 เป็น 565 สิ่งเดียวที่หยุดได้อย่างเชื่อถือได้ซึ่งผู้เขียนพบคือการทำให้ไดเรกทอรี checkpoint เขียนไม่ได้ เพื่อให้การเก็บข้อมูลล้มเหลวตอนเขียนลงดิสก์ โดยแลกกับการสูญเสียการย้อนกลับ checkpoint และอินเทอร์เฟซไทม์ไลน์

คีย์ที่ผู้ขายเท่านั้นสามารถใช้ได้

การเข้ารหัสเป็นการทำ envelope encryption แบบตามตำรา และนั่นคือส่วนที่ผู้ใช้ไม่สามารถหลบเลี่ยงได้ การสร้างภาพเหตุการณ์ขึ้นใหม่ของ InfoQ ซึ่งอ้างอิงจากการ reverse engineering ของ ferstar อธิบายว่าไคลเอนต์ดึง snapshot ID, RSA public key และข้อมูลรับรองการอัปโหลด Alibaba Cloud OSS จาก zcode.z.ai จากนั้นแพ็กและเข้ารหัส workspace ในเครื่อง แล้วส่ง ciphertext ไปยัง OSS โดยตรง เนื้อหาถูกเข้ารหัสด้วย AES-256-CTR; symmetric key ถูกห่อด้วย RSA-OAEP-SHA256 ภายใต้ public key ของเซิร์ฟเวอร์ ซึ่งครึ่งที่เป็น private key ยังคงอยู่ในคลาวด์ของ Zhipu

การกำหนดเส้นทางมีความสำคัญไม่แพ้การเข้ารหัสลับ เพราะไคลเอนต์อัปโหลดตรงไปยัง Alibaba Cloud แทนที่จะผ่านเซิร์ฟเวอร์แอปพลิเคชันของ Zhipu เอง ทราฟฟิกจึงไม่ได้ผ่านบริการของ Zhipu ที่สามารถบันทึกหรือกรองข้อมูลได้ ดังนั้นจึงไม่มีบริการของ Zhipu อยู่ในเส้นทางเพื่อบันทึกหรือกรองสิ่งที่ออกไป และเนื่องจากคีย์ส่วนตัวไม่เคยอยู่บนอุปกรณ์ ferstar จึงไม่สามารถเปิดไฟล์เก็บถาวรของตนเองได้: The Next Web รายงานว่าเขาลองใช้คีย์ส่วนตัวทุกตัวบนเครื่องของเขาแล้วแต่ไม่สำเร็จ เขาอธิบายการจัดวางนี้ในโพสต์ของเขาว่าเป็นคีย์ที่เซิร์ฟเวอร์เท่านั้นสามารถใช้ได้ ซึ่งมีจุดประสงค์เดียว

การตั้งค่าสองรายการในไคลเอนต์ดูเหมือนควรจะหยุดเรื่องนี้ได้ แต่ก็ไม่หยุดทั้งคู่ คีย์สลับ "optimise experience" ควบคุมว่าข้อมูลจะถูกนำไปใช้สำหรับการฝึกโมเดลได้หรือไม่ ส่วนคีย์สลับ "repository snapshot indexing" ควบคุมว่าเซิร์ฟเวอร์จะสร้างดัชนีบนสแนปช็อตที่มาถึงแล้วหรือไม่ ทั้งสองทำงานอยู่ปลายน้ำของขั้นตอนการเก็บข้อมูล Ferstar พบว่าการเก็บข้อมูลนั้นทำงานตลอดโดยไม่มีเงื่อนไข และ The Next Web รายงานว่าการตีความนโยบายความเป็นส่วนตัวของเขาพบว่ามีการอธิบายถึงการเก็บข้อความบทสนทนาและไฟล์ แต่ไม่ได้กล่าวถึงสแนปช็อตเวิร์กสเปซอัตโนมัติที่พกประวัติ Git ทั้งหมดไปด้วยเลย

คำอธิบายที่ Zhipu ให้มา และสี่วันหลังจากนั้น

Zhipu ตอบกลับในวันเดียวกัน ผ่านกลุ่มผู้ใช้อย่างเป็นทางการของ ZCode แทนที่จะเป็นข่าวประชาสัมพันธ์ ตามรายงานของ Global Times ซึ่งถูกพิมพ์ซ้ำโดย Security Inside บริษัทได้อ้างว่าพฤติกรรมดังกล่าวเกิดจากฟีเจอร์ที่เรียกว่า codebase indexing ซึ่งรองรับการจัดทำดัชนีในเครื่อง การกู้คืนจุดตรวจสอบของเซสชัน การย้อนกลับเวอร์ชัน และการสร้าง Repo Wiki และระบุว่าขั้นตอน Repo Wiki นั้นเป็นสิ่งที่กระตุ้นให้เกิดการอัปโหลดที่เก็บโค้ดขึ้นสู่คลาวด์ ฟีเจอร์นี้เปิดใช้งานเป็นค่าเริ่มต้นตั้งแต่เปิดตัว Zhipu กล่าวว่าข้อมูลที่อัปโหลดถูกใช้เพียงเพื่อสร้างหน้า Repo Wiki เท่านั้น และถูกทำลายทันทีหลังจากนั้น ว่าไม่ได้ถูกจัดเก็บและไม่ได้นำไปใช้ในการฝึกโมเดล และขอโทษผู้ใช้ที่ได้รับผลกระทบ พร้อมสัญญาว่าจะเปิดซอร์สโค้ดของ ZCode เชิญให้มีการตรวจสอบจากบุคคลที่สาม และเผยแพร่ผลลัพธ์ ตลอดจนเสนอการรีเซ็ตโควต้ารายสัปดาห์เพิ่มอีกหนึ่งครั้งให้กับผู้ใช้ ZCode ทุกคนเป็นการชดเชย

การแก้ไขมาถึงในวันถัดไป The Paper รายงานว่า ZCode 3.14.0 เปิดตัวเมื่อวันที่ 19 กันยายน พร้อมบันทึกการเปลี่ยนแปลงที่ระบุว่า "แก้ไขปัญหาการอัปโหลดผิดปกติของวิกิของรีโพซิทอรี" และ ferstar ยืนยันในวันเดียวกันว่าห่วงโซ่การอัปโหลดและเอนด์พอยต์ของมันหายไปแล้ว เมื่อวันที่ 20 กันยายน แพลตฟอร์ม MaaS ของ Zhipu ประกาศตัวเลือก zero-retention ที่จะเปิดให้ใช้ในอนาคต ซึ่งข้อมูลนำเข้าและผลลัพธ์จะไม่ถูกจัดเก็บแบบสถิต The Paper ระบุว่าตัวเลือกนี้ต้องเลือกเปิดใช้เป็นรายแอปพลิเคชัน ไม่รวม Batch API และ File API และยังอนุญาตให้เก็บข้อมูลได้ 30 วันหรือนานกว่านั้นเมื่อกฎหมายหรือการสอบสวนการใช้งานในทางที่ผิดกำหนดให้ต้องทำเช่นนั้น เมื่อวันที่ 21 กันยายน ซอร์สโค้ดไคลเอนต์เปิดเผยต่อสาธารณะบน GitHub ภายใต้สัญญาอนุญาต Apache 2.0 ครอบคลุมแอปเดสก์ท็อป ไคลเอนต์เว็บ แบ็กเอนด์ agent CLI และ agent runtime

มีการว่าจ้างการตรวจสอบสองครั้ง และเผยแพร่ข้อสรุปออกมาในรูปแบบบทสรุป สถาบัน China Academy of Information and Communications Technology พบว่าบักเก็ต OSS ของ Alibaba Cloud ชื่อ zcode-prod อยู่ในสภาวะที่ Zhipu เรียกว่าสถานะข้อมูลเป็นศูนย์ บริษัทด้านความปลอดภัย NSFOCUS รายงานว่าวัตถุข้อมูลทุกชิ้นและตัวบักเก็ตเองถูกลบไปแล้ว และไม่พบเส้นทางที่เหลืออยู่ใน ZCode 3.14.0 ซึ่งจะกระตุ้นการสร้างสแนปช็อตของคลังเก็บข้อมูลภายในเครื่องหรือส่งไฟล์ออกไปได้ รายงานการประเมินฉบับเต็มยังไม่ปรากฏ และ The Next Web รายงานว่า Zhipu ไม่ได้ระบุวันที่สำหรับรายงานดังกล่าว

ลูกค้าที่กล่าวอ้างเพิ่มเติม แล้วภายหลังถอนคำกล่าวอ้างนั้น

ข้อกล่าวอ้างเรื่องความเสียหายจริงที่ร้ายแรงที่สุดไม่ได้มาจาก ferstar เมื่อวันที่ 19 กันยายน ตามรายงานของ China National Radio บริษัท Taiyuan Chengming Technology ได้ส่งจดหมายทางกฎหมายถึง Zhipu โดยมีหมายเลข Chengming [2026] Legal Letter No. 1 ซึ่ง ChainCatcher นำมาเผยแพร่ซ้ำโดยละเอียด บริษัทกล่าวว่าพื้นที่ทำงานเขียนโค้ด (coding workspace) หกแห่งของตนถูกอัปโหลดโดยไม่ได้รับความยินยอม — ไฟล์ 34,500 ไฟล์ และขนาดประมาณ 425 MB ในรูปแบบข้อความธรรมดา — และระบุรายการซอร์สโค้ดทั้งหมด สถาปัตยกรรมระบบ ประวัติเวอร์ชัน รหัสผ่านฐานข้อมูล ข้อมูลรับรองคลาวด์ และข้อมูลส่วนบุคคลของพนักงาน บริษัทกล่าวว่าพื้นที่ทำงานแห่งที่เจ็ดซึ่งมี 1,947 ไฟล์ และขนาดประมาณ 144 MB ถูกจัดแพ็กและเข้ารหัสแล้ว แต่ล้มเหลวหลังจากลองอัปโหลดใหม่ 32 ครั้ง บริษัทยังตั้งข้อสังเกตว่าลูกค้าของตนได้อัปเดตเป็นเวอร์ชัน 3.12.3 เมื่อวันที่ 16 กันยายน แต่ก็ยังตรวจพบการอัปโหลดเมื่อเวลา 00:28 ของวันที่ 18 กันยายน ซึ่งเป็นเช้าที่ Zhipu ขอโทษ

จดหมายฉบับนี้ถามคำถามที่การตรวจสอบไม่ได้ให้คำตอบ นั่นคือ ข้อมูลออกนอกประเทศหรือไม่ เฉิงหมิงกล่าวว่า คำขอเชื่อมต่อเครือข่ายของ ZCode ชี้ไปที่นิติบุคคลในสิงคโปร์ ขณะที่ข้อตกลงการให้บริการลงนามกับ Beijing Zhipu Huazhang และได้ขอให้ Zhipu ระบุว่าฝ่ายใดรับผิดชอบ และมีการถ่ายโอนหรือจัดเก็บข้อมูลใด ๆ นอกจีนแผ่นดินใหญ่หรือไม่ จดหมายได้กำหนดข้อเรียกร้องไว้สิบสองข้อ รวมถึงการลบข้อมูลที่อัปโหลดทั้งหมดและข้อมูลอนุพันธ์ แคช และข้อมูลสำรอง พร้อมหนังสือรับรองเป็นลายลักษณ์อักษร การอธิบายว่าข้อมูลไปอยู่ที่ใดและถูกแบ่งปันให้บุคคลภายนอกหรือใช้สำหรับการฝึกอบรมหรือไม่ การอธิบายว่าคีย์ส่วนตัวถูกเก็บรักษาอย่างไร และการส่งมอบบันทึกการเข้าถึง การกำหนดขอบเขตที่แน่ชัดของข้ออ้างว่า "ถูกทำลาย" และการให้คำมั่นเป็นลายลักษณ์อักษรว่าจะไม่อัปโหลดอีก จดหมายกำหนดให้ Zhipu ตอบเป็นลายลักษณ์อักษรภายในวันที่ 10 ตุลาคม และสงวนสิทธิ์ในการเรียกร้องค่าเสียหายและร้องเรียนต่อหน่วยงานกำกับดูแล Caixin Global รายงานว่า Zhipu กล่าวว่าข้อกล่าวหาดังกล่าวไม่เป็นความจริง

สองวันต่อมา เฉิงหมิงได้ถอนข้อความเหล่านั้นออก กองข่าวการเงินของ China National Radio รายงานว่าเมื่อวันที่ 21 กันยายน บริษัทได้ออกแถลงการณ์ถอนคำกล่าวอ้าง โดยระบุว่าถ้อยแถลงก่อนหน้านี้อ้างอิงหลักฐานที่ผิดพลาด คำบรรยายที่ไม่แม่นยำ และถ้อยคำที่เกินจริง ว่าได้สร้างความเสียหายต่อชื่อเสียงของ Zhipu และจะหยุดให้สัมภาษณ์กับสื่อ Reuters ก็รายงานการถอนข้อความดังกล่าวเช่นกัน ตามรายงานของ The Next Web บันทึกในคลังข้อมูลสำหรับเหตุการณ์นี้ลงวันที่ 18 กันยายน ซึ่งเป็นวันที่ค้นพบ จดหมาย กำหนดเส้นตายวันที่ 10 ตุลาคมของจดหมาย และการถอนข้อความ ล้วนเกิดขึ้นหลังจากวันดังกล่าว ในบันทึกสาธารณะ ณ ปลายเดือนตุลาคม ไม่มีบริษัทใดที่ระบุชื่อออกมายืนยันข้อกล่าวอ้างว่าความลับของตนถูกเปิดเผย

รีลีสโอเพนซอร์สที่ประวัติถูกลบไป

การเปิดซอร์สไคลเอนต์เป็นวิธีแก้ปัญหาที่ Zhipu พึ่งพามากที่สุด และมันมาพร้อมช่องโหว่ The Paper รายงานว่า repository ที่เผยแพร่นั้นมีสองคอมมิต ได้แก่ คอมมิตเริ่มต้นที่ว่างเปล่า และคอมมิตเดียวที่เพิ่มไฟล์ราว 6,973 ไฟล์กับ 1.03 ล้านบรรทัด โดย pull request ถูกล็อกและ issue ถูกปิด สภาพของไปป์ไลน์การอัปโหลดตอนที่มันถูกส่งมอบ และรีลีสใดบ้างที่บรรจุมันไว้ ไม่ปรากฏอยู่ในประวัติที่ใครก็ตามสามารถอ่านได้ในตอนนี้

การติดตามผลของ Ferstar เองทำให้ข้อจำกัดนี้ชัดเจนขึ้น เขายืนยันว่า upload pipeline ได้ถูกนำออกไปแล้ว และกลไก checkpoint ที่เหลืออยู่ทำงานกับ Git ภายในเครื่องเท่านั้น จากนั้นชี้ให้เห็นว่าการตรวจสอบ bucket ทำอะไรได้และทำอะไรไม่ได้ การล้างและลบ bucket เป็นมาตรการหยุดความเสียหายที่ถูกต้อง แต่การตรวจสอบโดยบุคคลที่สามที่ทำหลังวันที่ 20 กันยายนยืนยันได้เพียงว่า ณ จุดนั้น bucket ว่างเท่านั้น ไม่สามารถสร้างภาพย้อนหลังได้ว่ามีอะไรผ่านเข้ามาก่อนวันที่ 18 กันยายน มีสิ่งใดถูกถอดรหัส คัดลอก หรือสำรองข้อมูลไว้หรือไม่ หรือ pipeline ทำงานมานานเท่าใด ข้ออ้างเรื่องการลบยังคงพึ่งพาคำกล่าวของฝ่ายที่ทำการลบเป็นหลักอย่างมีนัยสำคัญ

บทวิเคราะห์ของ InfoQ ระบุคำถามที่ยังคงค้างอยู่ด้วยถ้อยคำเดียวกัน ได้แก่ มีการอัปโหลดสแนปช็อตของรีโพซิทอรีสำเร็จกี่ชุดและโดยผู้ใช้กี่คน วัตถุถูกเก็บไว้นานเท่าใด ระบบฝั่งเซิร์ฟเวอร์หรือเจ้าหน้าที่ส่วนใดสามารถถอดรหัสวัตถุเหล่านั้นได้ มีบันทึกการเข้าถึงที่สมบูรณ์หรือไม่ และการลบครอบคลุมข้อมูลสำรองและสำเนาอื่น ๆ หรือไม่ บทวิเคราะห์ยังระบุด้วยว่า ZCode ยังคงเป็นอะไรอยู่หลังการแก้ไข NOTICE ของโครงการเองเตือนว่า runtime ของเอเจนต์แบบใช้ร่วมกันไม่ได้มีแซนด์บ็อกซ์ระดับระบบปฏิบัติการโดยค่าเริ่มต้น และไคลเอนต์ยังคงมีพื้นผิวการทำงานอย่างเชลล์ เทอร์มินัล Git MCP ปลั๊กอิน และเบราว์เซอร์ฝังตัว ซึ่งสามารถอ่านไฟล์ เริ่มกระบวนการ และเข้าถึงเครือข่ายได้ภายใต้สิทธิ์ของบัญชีผู้ใช้

สิ่งใดได้รับการยืนยัน และสิ่งใดที่ไม่มีแหล่งข้อมูลใดตอบ

กลไกนี้ไม่ได้เป็นที่โต้แย้ง คำแถลงของ Zhipu เองยอมรับว่าข้อมูลจากรีโพซิทอรีถูกอัปโหลด ว่าฟีเจอร์นี้เปิดเป็นค่าเริ่มต้น และว่าข้อมูลไปยังบัคเก็ตคลาวด์ที่บริษัทควบคุม การวัดของ Ferstar คำขอโทษจากผู้จำหน่าย การตรวจสอบที่ว่าจ้างสองครั้ง และการเผยแพร่แบบโอเพนซอร์ส ล้วนอธิบายห่วงโซ่เดียวกัน ไม่มีสิ่งใดในบันทึกที่โต้แย้งว่าเวิร์กสเปซออกจากเครื่องโดยไม่มีทางเลือกปิดใช้งานที่ใช้ได้จริง ความเสียหายที่บันทึกไว้เกิดขึ้นจริง而非สมมติ การถ่ายโอนเกิดขึ้นแล้ว และผู้ที่โค้ดอยู่ภายในนั้นไม่สามารถป้องกันหรือตรวจสอบได้

สิ่งที่ยังเป็นข้อโต้แย้ง หรือเพียงแต่ยังไม่เป็นที่ทราบ คือขนาดและผลกระทบ ไม่มีแหล่งข้อมูลใดระบุว่ามีผู้ใช้จำนวนเท่าใดที่ใช้ค่าเริ่มต้นซึ่งได้รับผลกระทบ ไปป์ไลน์ทำงานนานเท่าใดก่อนวันที่ 18 กันยายน หรือมีอ็อบเจ็กต์ที่อัปโหลดใดถูกถอดรหัสหรือไม่ คำรับรองของ Zhipu ว่าข้อมูลถูกทำลายหลังการสร้างวิกิและไม่เคยถูกนำไปใช้สำหรับการฝึกอบรม เป็นถ้อยแถลงของบริษัทเอง ส่วนผลการตรวจสอบของ CAICT และ NSFOCUS อธิบายสภาพของบักเก็ตหลังจากมีการแก้ไข ไม่ใช่สิ่งที่ผ่านเข้ามาในบักเก็ตนั้น คลังเก็บข้อมูลให้เกรด A แก่บันทึกดังกล่าวในด้านเอกสาร และเอกสารนั้นแข็งแกร่งในเรื่องกลไกแต่บางเบาในเรื่องขอบเขต

อะไรเปลี่ยนไป และอะไรไม่เปลี่ยน

ต้นทุนเชิงพาณิชย์เกิดขึ้นในทันที China National Radio รายงานว่าหุ้นของ Zhipu ที่จดทะเบียนในฮ่องกงลดลง 1.79% เมื่อวันที่ 21 กันยายน 6.55% เมื่อวันที่ 22 กันยายน และ 12.4% เมื่อวันที่ 23 กันยายน คิดเป็นการลดลงสะสมมากกว่า 16% ในช่วงสามวันทำการ และ Zhipu ไม่ได้ชี้แจงว่ามีผู้ใช้ได้รับผลกระทบจำนวนเท่าใด หรือข้อมูลในอดีตถูกถอดรหัสหรือสำรองข้อมูลไว้หรือไม่

สิ่งที่ผู้ใช้ ZCode ได้รับจริง ๆ ในช่วงสี่วันหลังการค้นพบ:

• 18 กันยายน: คำขอโทษต่อสาธารณะโดยระบุว่าการทำดัชนีฐานโค้ดเป็นสาเหตุ พร้อมคำมั่นที่จะเปิดซอร์สไคลเอนต์และมอบหมายให้มีการตรวจสอบโดยบุคคลที่สาม และการรีเซ็ตโควต้ารายสัปดาห์เพิ่มอีกหนึ่งครั้งต่อผู้ใช้

• 19 กันยายน: ZCode 3.14.0 โดยนำ Repo Wiki ออก และตัดเส้นทางการสร้างสแนปช็อตภายในเครื่องและการอัปโหลดออก Ferstar ยืนยันว่าห่วงโซ่การอัปโหลดหายไปในวันถัดมา

• 20 กันยายน: มีการประกาศตัวเลือกแบบไม่เก็บข้อมูล (zero-retention) สำหรับแพลตฟอร์ม MaaS ของ Zhipu โดยผู้ใช้ต้องเลือกเปิดใช้เอง ไม่รวม Batch API และ File API และยังคงต้องอยู่ภายใต้ข้อกำหนดทางกฎหมายให้เก็บข้อมูลไว้ 30 วันหรือนานกว่านั้น

• 21 กันยายน: ZCode ถูกเผยแพร่ภายใต้สัญญาอนุญาต Apache 2.0 โดยไม่มีประวัติคอมมิตก่อนเกิดเหตุ; บทสรุปของ CAICT และ NSFOCUS รายงานว่าถังจัดเก็บข้อมูลว่างเปล่าและไม่มีเส้นทางขาออก

ไม่มีสิ่งใดในนั้นย้อนกลับไปจัดการสิ่งที่เกิดขึ้นแล้วได้ คำถามเฉพาะเจาะจงที่เฉิงหมิงยกขึ้นมา — ข้อมูลไปอยู่ที่ไหน ใครสามารถถอดรหัสได้ ข้อมูลออกนอกประเทศหรือไม่ และคำว่า "ถูกทำลาย" ครอบคลุมถึงอะไร — ถูกจัดทำเป็นลายลักษณ์อักษรพร้อมกำหนดเส้นตายวันที่ 10 ตุลาคม และจากนั้นก็ถูกถอนออกไปพร้อมกับบริษัทที่ตั้งคำถามเหล่านั้น Zhipu สัญญาว่าจะมีรายงานการประเมินโดยบุคคลที่สามฉบับเต็ม โดยไม่ระบุวันที่ จนกว่ารายงานนั้นจะปรากฏขึ้น บัญชีสาธารณะเพียงฉบับเดียวเกี่ยวกับสิ่งที่ไปป์ไลน์ทำกับข้อมูลที่ได้รับคือคำบอกเล่าของบริษัทที่สร้างมันขึ้นมา และอาร์ติแฟกต์เพียงอย่างเดียวที่วัดได้อย่างอิสระคือไฟล์ขนาด 313 MB ที่พยายามออกจากแล็ปท็อปของนักพัฒนาคนหนึ่งแล้วล้มเหลว 564 ครั้ง