قام ZCode بحزم 42,411 ملفًا في أرشيف لا يمكن فتحه إلا بواسطة Zhipu

في 18 سبتمبر 2026، نشر مطوّر يكتب تحت اسم ferstar تحليلًا تفكيكيًا لـ ZCode، وكيل البرمجة بالذكاء الاصطناعي المكتبي الذي تطوّره شركة النماذج الصينية Zhipu AI، بعد أن لاحظ أن مجلدًا مخفيًا في دليل منزله تجاوز 700 ميغابايت. وجد داخله أرشيفًا مشفّرًا بحجم 313 ميغابايت يضم 42,411 ملفًا مأخوذة من مساحة عمل بحجم 345 ميغابايت، 86.6% منه تاريخ Git، حزمه العميل وجهّزه للرفع إلى تخزين الكائنات في Alibaba Cloud. كان الأرشيف مختومًا بمفتاح لا تستطيع فكّه إلا خوادم Zhipu، ولم يوفّر العميل أي خيار يوقف بنائه. اعتذرت Zhipu في المساء نفسه. يوجد السجل الكامل، مع درجة الثقة وحالة الضرر الخاصتين بالأرشيف، في Orca AI Incident Archive، الذي يسجّل كل حادث ذكاء اصطناعي موثّق مقابل مصادره المذكورة.

ZCode هو وكيل البرمجة المكتبي من Zhipu: يقرأ المشروع، وينفّذ أوامر الصدفة، ويكتب الشيفرة. وتُتداول الشركة في هونغ كونغ تحت رمز 2513.HK، وتُسوّق ذراعها الدولية باسم Z.ai، وهو الاسم الظاهر على خوادم ZCode التي فحصها ferstar. وذكرت The Paper، المنفذ الإخباري في شنغهاي الذي أجرى معه ومع عدة مطورين آخرين مقابلات بعد ذلك، أن منشوره كان بعنوان، على وجه التقريب، "كشف الستار عن الرفع الصامت الذي أجراه ZCode لتاريخ Git الكامل"، وأنه انتشر في مجموعات المطورين الصينية خلال ساعات من نشره.

ماذا كان داخل المجلد المخفي؟

أرقام فيرستار نفسه هي العمود الفقري للقضية، وقد أُعيد نشرها بثبات من قبل The Next Web وInfoQ والمكتب المالي لإذاعة الصين الوطنية. كان الأرشيف في دليل نقاط التحفّظ ZCode الخاص به بحجم 313 ميغابايت. وسجّل ملف الحالة المجاور له مساحة عمل تبلغ نحو 345 ميغابايت و42,411 ملفًا. .gitاستحوذ دليل .git على 86.6٪ من الحمولة: 196.1 ميغابايت من ذاكرة التخزين المؤقت للملفات الكبيرة في Git، و102.2 ميغابايت من كائنات Git التي تحمل سجلّ الالتزامات الكامل، وشريحة رقيقة من سجل الإعادة (reflog). أما الشيفرة المصدرية والوثائق الفعلية فقد بلغت نحو 13.4٪.

لهذا التمييز أهمية لأن تاريخ Git هو المكان الذي يميل فيه المحتوى الذي أُزيل من الشجرة الحالية إلى البقاء. ويوضح ما يورده The Paper هذه النقطة مباشرة: يمكن لأرشيف من هذا النوع أن يحمل سجل تعديلات المشروع منذ أول إيداع له، والمحتوى المحذوف، والمسودات غير المُودَعة، وملفات الإعدادات الأقدم، بما في ذلك بيانات الاعتماد التي جُردت من الشيفرة منذ زمن طويل لكنها تبقى في الإيداعات السابقة وفي ذاكرة التخزين المؤقت للملفات الكبيرة.

لم يغادر جهاز Ferstar قط أرشيفه الخاص البالغ 313 MB. أظهر سجل حالته 564 محاولة رفع فاشلة، وكان قد توقف في حالة معلّقة بسبب تجاوزه حد الحجم. ولاختبار ما إذا كان خط المعالجة يعمل على الإطلاق، جرّب مستودعًا عامًا صغيرًا يضم 538 ملفًا؛ فضُغطت تلك اللقطة وشُفّرت إلى نحو 15 KB وقُبلت من الخادم. ذلك النقل هو النقل الوحيد في السجل المؤكد أنه اكتمل من البداية إلى النهاية، وهو ما يحوّل هذا الاكتشاف من تمرين على قراءة الشيفرة إلى عملية تسريب ذات طرف استقبال مُثبت.

لم يكن الالتقاط مرتبطًا بأي إجراء يتعرّف عليه المستخدم بوصفه «رفع مستودعي». ووفقًا لإعادة بناء ferstar، كان أحد المحفّزات يُطلَق قبل كل طلب يُرسَل إلى النموذج، وآخر يعمل كمهمة تحديث في Repo Wiki. ولم يؤدِّ حذف الأرشيف المعلّق إلى إيقافه: إذ يسجّل مقال على مجتمع مطوّري Tencent Cloud أن الحزمة أُعيد بناؤها خلال 30 دقيقة، وأن عدّاد الإخفاقات ارتفع من 564 إلى 565. والطريقة الوحيدة الموثوقة للإيقاف التي وجدها ذلك الكاتب تمثّلت في جعل دليل نقاط التحقق غير قابل للكتابة بحيث يفشل الالتقاط عند الكتابة على القرص، وذلك على حساب فقدان التراجع إلى نقاط التحقق وواجهة الخط الزمني.

مفتاح لا يمكن أن يستخدمه سوى المورّد

كان التشفير تشفير مظروف نموذجيًا، وهو الجزء الذي لم يستطع المستخدمون التحايل عليه. تصف إعادة بناء InfoQ، المستندة إلى الهندسة العكسية التي أجراها ferstar، قيام العميل بجلب معرّف لقطة (snapshot ID) ومفتاح عام RSA وبيانات اعتماد رفع إلى Alibaba Cloud OSS من zcode.z.ai، ثم تجميع مساحة العمل وتشفيرها محليًا، ثم إرسال النص المشفّر مباشرة إلى OSS. وقد شُفّر المحتوى باستخدام AES-256-CTR؛ وتم تغليف المفتاح المتماثل باستخدام RSA-OAEP-SHA256 تحت المفتاح العام للخادم، الذي بقي نصفه الخاص في سحابة Zhipu.

لا يقلّ التوجيه أهمية عن التشفير. ولأن العميل رفع الملفات مباشرة إلى Alibaba Cloud بدلًا من رفعها عبر خوادم تطبيقات Zhipu نفسها، لم تمرّ حركة البيانات عبر أي خدمة من Zhipu يمكنها تسجيلها أو تصفيتها، لذا لم تكن أي خدمة من Zhipu في المسار لتسجيل ما خرج أو تصفيته. ولأن المفتاح الخاص لم يكن على الجهاز قط، لم يستطع ferstar فتح أرشيفه الخاص: إذ يذكر The Next Web أنه جرّب كل مفتاح خاص على جهازه وفشل. وقد وصف في منشوره هذا الترتيب بأنه مفتاح لا يستطيع استخدامه سوى الخادم، وله غرض واحد.

كان هناك إعدادان في العميل يبدو أنهما كانا يجب أن يوقفا هذا، لكن أياً منهما لم يفعل. كان مفتاح "تحسين التجربة" يحدد ما إذا كان يمكن استخدام البيانات لتدريب النماذج؛ وكان مفتاح "فهرسة لقطات المستودع" يحدد ما إذا كان الخادم يبني فهرساً على اللقطات التي وصلت بالفعل. وكلاهما يعمل بعد مرحلة الالتقاط. وجد Ferstar أن الالتقاط يعمل دون قيد أو شرط، وتُفيد The Next Web بأن قراءته لسياسة الخصوصية وجدتها تصف جمع نص المحادثات والملفات لكنها لا تقول شيئاً عن لقطات مساحة العمل التلقائية التي تحمل سجل Git الكامل.

التوضيح الذي قدّمته Zhipu، والأيام الأربعة التي أعقبته

ردّت Zhipu في اليوم نفسه، عبر مجموعة المستخدمين الرسمية لـZCode بدلاً من بيان صحفي. وكما أفادت Global Times وأعادت Security Inside نشره، أرجعَت الشركة السلوك إلى ميزة تُسمى فهرسة قاعدة الشيفرة، تدعم الفهرسة المحلية واستعادة نقاط التحقق للجلسات والتراجع عن الإصدارات وإنشاء Repo Wiki، وقالت إن خطوة Repo Wiki هي ما تسبّب في رفع المستودعات إلى السحابة. وكانت الميزة مفعّلة افتراضيًا منذ الإطلاق. وقالت Zhipu إن البيانات المرفوعة استُخدمت فقط لإنشاء صفحة Repo Wiki وجرى إتلافها فورًا بعد ذلك، وإنها لم تُخزَّن ولم تُستخدم للتدريب، واعتذرت للمستخدمين المتأثرين. ووعدت بجعل شيفرة ZCode مفتوحة المصدر، ودعوة طرف ثالث للمراجعة ونشر النتائج، وعرضت على كل مستخدم من ZCode إعادة تعيين إضافية واحدة للحصة الأسبوعية كتعويض.

وصل الإصلاح في اليوم التالي. وتذكر The Paper أن ZCode 3.14.0 صدر في 19 سبتمبر مع مدخل في سجل التغييرات نصه "إصلاح مشكلة الرفع غير الطبيعية الخاصة بويكي المستودع"، وأن ferstar أكد في اليوم نفسه أن سلسلة الرفع ونقطة النهاية الخاصة بها اختفتا. وفي 20 سبتمبر، أعلنت منصة MaaS التابعة لـ Zhipu عن خيار مرتقب لعدم الاحتفاظ بالبيانات، لن تُخزَّن بموجبه المدخلات والمخرجات تخزينًا ثابتًا؛ وتشير The Paper إلى أنه يُفعَّل عند الطلب، ويستبعد Batch API وFile API، ولا يزال يسمح بالاحتفاظ لمدة 30 يومًا أو أكثر حيثما يقتضي القانون أو التحقيق في إساءة الاستخدام ذلك. وفي 21 سبتمبر، أصبحت الشيفرة المصدرية للعميل متاحة للعموم على GitHub بموجب رخصة Apache 2.0، وتغطي تطبيق سطح المكتب وعميل الويب والواجهة الخلفية وواجهة سطر الأوامر للوكيل وبيئة تشغيل الوكيل.

تم تكليف جهتَين بإجراء تدقيقين، ونُشرت استنتاجاتهما في صورة ملخّصات. فقد وجدت الأكاديمية الصينية لتقنية المعلومات والاتصالات أن حاوية {{zcode-prod}} في Alibaba Cloud OSS في ما تسمّيه 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 نشره بالتفصيل. وقالت الشركة إن ستًا من مساحات العمل البرمجية الخاصة بها رُفعت دون موافقة — 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 وصف المزاعم بأنها غير صحيحة.

بعد يومين، سحبت Chengming تلك التصريحات. ويُفيد مكتب الشؤون المالية في الإذاعة الوطنية الصينية بأن الشركة أصدرت في 21 سبتمبر/أيلول تراجعًا قالت فيه إن تصريحاتها السابقة استندت إلى أدلة خاطئة ووصف غير دقيق وصياغة مبالغ فيها، وإنها أضرّت بسمعة Zhipu، وإنها ستتوقف عن التحدث إلى وسائل الإعلام. وذكرت رويترز أيضًا هذا التراجع، وفقًا لـ The Next Web. تاريخ مدخل الأرشيف الخاص بهذه الحادثة هو 18 سبتمبر/أيلول، وهو يوم الاكتشاف؛ أما الرسالة وموعدها النهائي في 10 أكتوبر/تشرين الأول والتراجع فقد جاءت جميعها بعد ذلك التاريخ. ووفقًا للسجل العام حتى أواخر أكتوبر/تشرين الأول، لا توجد شركة مُسمّاة تقف وراء ادعاء بأن أسرارها قد كُشفت.

إصدار مفتوح المصدر تم محو تاريخه

كان فتح المصدر للعميل هو العلاج الذي اعتمدت عليه Zhipu بأشد قوة، وقد جاء مصحوبًا بثغرة. إذ يذكر The Paper أن المستودع المنشور يحتوي على إيداعين (commits): إيداع أولي فارغ، وإيداع واحد يضيف نحو 6,973 ملفًا و1.03 مليون سطر، مع تعطيل طلبات السحب (pull requests) وإغلاق المشكلات (issues). وأيًا كان شكل خط أنابيب الرفع عند إطلاقه، وأيًا كانت الإصدارات التي احتوته، فإن ذلك غير موجود في السجل الذي يمكن لأي أحد قراءته الآن.

إن متابعة Ferstar الخاصة تجعل هذا القيد صريحًا. فقد أكد أن خط أنابيب الرفع قد زال، وأن آلية نقاط التحقق المتبقية لا تقوم إلا بعمليات Git محلية، ثم أشار إلى ما يمكن أن يُظهره تدقيق الحاوية وما لا يمكنه إظهاره: إن إفراغ الحاوية وحذفها هو إجراء وقف الخسائر الصحيح، لكن فحصًا من طرف ثالث يُجرى بعد 20 سبتمبر لا يمكنه أن يثبت سوى أن الحاوية كانت فارغة عند تلك النقطة. ولا يمكنه إعادة بناء ما مرّ قبل 18 سبتمبر، أو ما إذا كان قد جرى فك تشفير أي شيء أو نسخه أو نسخه احتياطيًا، أو المدة التي كان خط الأنابيب يعمل خلالها. ولا يزال ادعاء الحذف يعتمد اعتمادًا كبيرًا على قول الطرف الذي قام بالحذف.

يسرد تحليل InfoQ الأسئلة التي لا تزال مفتوحة بالصيغة نفسها: كم عدد لقطات المستودعات التي رُفعت بنجاح، وبواسطة كم من المستخدمين، وكم استمر الاحتفاظ بالكائنات، وأي الأنظمة أو الموظفين في جانب الخادم كان بإمكانهم فك تشفيرها، وما إذا كان سجل وصول كامل موجودًا، وما إذا كان الحذف قد شمل النسخ الاحتياطية والنسخ الأخرى. كما يذكر ما لا يزال ZCode عليه بعد الإصلاح. ويحذّر ملف NOTICE الخاص بالمشروع من أن بيئة تشغيل الوكيل المشتركة لا توفر افتراضيًا عزلًا على مستوى نظام التشغيل، وأن العميل يحتفظ بواجهات shell وterminal وGit وMCP والإضافات والمتصفح المضمّن التي يمكنها قراءة الملفات وبدء العمليات والوصول إلى الشبكة ضمن أذونات حساب المستخدم.

ما هو مُثبت، وما لا يُجيب عنه أي مصدر.

الآلية ليست محل نزاع. تعترف تصريحات زيبو نفسها بأن بيانات المستودعات قد رُفعت، وأن الميزة كانت مفعّلة افتراضيًا، وأن البيانات ذهبت إلى حاوية سحابية كانت الشركة تتحكم فيها. وتصف قياسات فيرستار، واعتذار البائع، ومراجعتان مكلّفتان، والإصدار مفتوح المصدر، السلسلة نفسها. ولا شيء في السجل ينازع في أن مساحات العمل غادرت الأجهزة دون خيار تعطيل عملي. والضرر الذي يسجّله السجل واقع لا افتراضي: فقد حدثت عمليات النقل، ولم يكن بوسع الأشخاص الذين كانت أكوادهم داخلها منعها ولا فحصها.

ما هو محل خلاف، أو ببساطة غير معروف، هو الحجم والعواقب. لا يذكر أي مصدر عدد المستخدمين الذين شغّلوا الإعدادات الافتراضية المتأثرة، ولا المدة التي عملت فيها خطوة المعالجة قبل 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 سبتمبر: خيار مُعلن لعدم الاحتفاظ بالبيانات على منصة MaaS التابعة لـ Zhipu، يُفعَّل اختياريًا، ويستثني Batch API وFile API، ولا يزال خاضعًا لمتطلبات الاحتفاظ القانوني لمدة 30 يومًا أو أكثر.

• 21 سبتمبر: نُشر ZCode بموجب ترخيص Apache 2.0 دون سجلّ التزاماته السابق للحادث؛ وتُفيد ملخّصات CAICT وNSFOCUS بأن حاوية التخزين فارغة وأن مسار الخروج غير موجود.

لا شيء من ذلك يمتد إلى الماضي. الأسئلة المحددة التي طرحها تشنغ مينغ — أين ذهبت البيانات، ومن كان بوسعه فك تشفيرها، وهل غادرت البلاد، وما الذي شمله «الإتلاف» — كُتبت رسميًا مع مهلة تنتهي في 10 أكتوبر، ثم جرى سحبها هي والشركة التي طرحتها معًا. وعدت Zhipu بتقرير تقييم كامل من طرف ثالث دون تحديد تاريخ. وإلى أن يظهر أحدها، فإن الحساب العلني الوحيد لما فعلته خطّ المعالجة بالبيانات التي تلقّاها هو حساب الشركة التي بنته، والأثر الوحيد القابل للقياس بشكل مستقل هو ملف بحجم 313 ميغابايت فشل 564 مرة في مغادرة الحاسوب المحمول لأحد المطورين.