sckit: تمت إضافة أبواب خلفية إلى حزم الذاكرة المدعومة بالذكاء الاصطناعي من MemTensor لسرقة بيانات اعتماد الوكلاء وأوامر التوجيه الخاصة بهم

صدرت أربع إصدارات من MemTensor في 23 سبتمبر 2026 وقد حملت جميعها برنامج Go المزروع المنزوع الرموز نفسه، وكان كل منها أحدث إصدار على سجله أثناء توفره. صدر إصدار npm @memtensor/memos-cloud-openclaw-plugin بصيغة 0.1.21 عند 02:23 UTC، و0.1.23 عند 03:49 و0.1.25 عند 04:36؛ وصدر إصدار PyPI MemoryOS بصيغة 2.0.34 عند 05:25. وقد شحن الأربعة جميعًا sckit، الذي يبدأ عند إقلاع بوابة وكيل OpenClaw، ويبدأ مجددًا عند كل استرجاع للذاكرة — مع تمرير نص مطالبة المستخدم في متغير بيئة — ويبدأ، في حزمة Python، عند استيراد وحدة memos استيرادًا عاديًا. ثم يمسح الدليل الرئيسي بحثًا عن أسرار npm وPyPI وGitHub وGitLab وAWS وVault وSSH ويرسل ما يجده إلى خوادم تحت skyleen[.]fr. وثّق كل من Socket وStepSecurity وSafeDep وAikido الاختراق بشكل مستقل في ذلك اليوم، ولم يبلّغ أي منها عن أدلة على أن البرنامج المزروع قد عمل على مضيف حقيقي. يحتفظ أرشيف حوادث Orca AI بهذا الإدخال كاملًا، إلى جانب كل حادثة أخرى في سلسلة التوريد سجّلها، ويحمل كل سجل درجة الثقة وحالة الضرر الخاصة به.

أربعة إصدارات، وتقرير خلل علني في منتصفها

MemOS هو إطار ذاكرة مفتوح المصدر من MemTensor لوكلاء LLM، وحزمة npm هي الموصل الذي يتيح لبيئة تشغيل وكيل OpenClaw القراءة من خدمة ذاكرة مستضافة والكتابة إليها؛ وتشير StepSecurity إلى أن الحزمة نفسها تعلن أيضًا نقاط تكامل مع بيئتي تشغيل Clawdbot وMoltbot. قاس Socket المستودع عند نحو 11,500 نجمة و1,100 تفرّع عندما نشر. هذا الموقع هو سبب أن الاختراق جذب أربعة تحقيقات منفصلة: وكما قالت StepSecurity، فإن هذا "يضع الإضافة داخل عملية تتعامل روتينيًا مع مدخلات المستخدم وقد ترث بيانات اعتماد قيّمة." الأشخاص المعرضون هم الذين ثبّتوا أيًا من الحزمتين — المطورون على أجهزتهم الخاصة، ومدّكو CI والحاويات التي شغّلت مجموعة اختبارات فقط.

تسلسل npm هو أوضح جزء من السجل لأن الطوابع الزمنية للسجل عامة، وقد التقطتها عدة شركات بشكل مستقل. يتفق تقرير Socket والجدول الزمني لـ SafeDep في كل دقيقة: 0.1.21 عند 02:23:04، 0.1.22 عند 03:45:44، 0.1.23 عند 03:49:20، 0.1.24 عند 04:33:30 و0.1.25 عند 04:36:58. كان الإصداران 0.1.22 و0.1.24 نظيفين — يقول Socket إنهما طابقا 0.1.20 باستثناء سلاسل الإصدار — وعادت الحمولة بعد ثلاث دقائق ونصف من كل منهما.

القفزة في الحجم هي الدليل. قاست Socket الإصدار 0.1.20 عند نحو 272 KB غير المضغوط، والإصدار 0.1.21 عند 43.6 MB، لأن الإصدارات الخبيثة ضمّت ستة ملفات ثنائية للمنصات مرتبطة ارتباطًا ساكنًا بحجم نحو 7.4 MB لكل منها. يُظهر PyPI النمط نفسه: كانت حزمة wheel للإصدار 2.0.34 بحجم 19,201,772 بايت مقابل 951,210 للإصدار 2.0.33، وفقًا لـ Socket.

في الساعة 04:17 UTC — قبل ست عشرة دقيقة من الإصدار النظيف 0.1.24 وتسع عشرة دقيقة قبل أن تعود الحمولة بإصدار 0.1.25 — قام مستخدم GitHub يُدعى omeridel بفتح المشكلة رقم 173 على مستودع الإضافة، بعنوان "الإصداران الخبيثان 0.1.21 و0.1.23 المنشوران على npm — يبدو أن رمز النشر مخترق." وتشير المشكلة إلى أن 0.1.23 كان آنذاك أحدث وسم، وأن أياً من الإصدارين لم يطابق أي commit أو وسم في المستودع، وأن أحدث commit شرعي كان بتاريخ 14 أغسطس. ولا تزال مفتوحة دون تعليقات من المشرفين حتى 26 أكتوبر 2026.

ماذا يفعل sckit بمجرد تحميل الحزمة؟

لم تستخدم أي من الحزمتين خطاف تثبيت، ولهذا فإن النصح المعتاد بشأن --ignore-scriptsلم ينطبق. يصف تحليل StepSecurity لنسخة npm ملفًا جديدًا، lib/sckit.js، يصدّر مشغّلًا تستورده وتستدعيه شيفرة بدء التشغيل واسترجاع الذاكرة الموجودة في الإضافة. وعند بدء التشغيل تُشغّل .sckit/<os>-<arch>/sckitعملية منفصلة باستخدام stage0 --config64وبيئة العملية الأب الكاملة؛ وعند الاسترجاع تفعل الشيء نفسه وتمرّر مطالبة المستخدم المجرّدة عبر متغيّر بيئة باسم SCKIT_EVENT_TEXT. وقد عبّرت Socket عن الأثر بوضوح: لذا يعمل الملف الثنائي مرة أخرى عند كل استرجاع.

نسخة PyPI أقصر، وعملياً أصعب في التجنّب.memos/log.py تستدعي دالة تشغيل داخلmemos/_stage0.py عند تكوين التسجيل، وأن 149 وحدة تستدعي المسجّل على مستوى الوحدة، وبالتالي يكفي استيراد وحدة memos استيراداً عادياً لبدء الحمولة مرة واحدة لكل عملية. كان تحليل StepSecurity للحزمة نفسها تحليلاً ساكناً بحتاً — إذ لم يثبّتها أو يستوردها أو يبنيها أو ينفّذها.

نطاق الجمع هو دليل المنزل بأكمله. يُدرج SafeDep جذر الجرد على أنه $HOME والملفات المستهدفة على أنها .npmrc، .pypirc، .git-credentials، .netrc، id_rsa، id_ecdsa، id_ed25519، .vault-token، msal_token_cache، access_tokens.json و access_tokens.db، بالإضافة إلى متغيرات البيئة التي تحتوي أسماؤها على token أو secret أو password أو API key أو database URL، بالإضافة إلى صيغ الرموز المميزة المعروفة لـ GitHub وGitLab وnpm وPyPI وHugging Face وSlack وStripe وAWS وSendGrid. سجلات OSV للحزمتين، MAL-2026-16476 لـ npm و MAL-2026-16475 لـ PyPI، تصف نفس قائمة الملفات وتضيف أن بروتوكول القيادة والتحكم يستخدم CBOR وتبادل مفاتيح X25519 وXChaCha20-Poly1305، مع عقود إيجار موقعة ووحدات تُسلَّم وقت التشغيل — لذا لم تُرصد محتويات الوحدات قط، بل فقط المُحمِّل الذي يجلبها.

ثمة تفصيلان يشكلان ما لا يزال بإمكان المدافع استعادته. يحمل الملف الثنائي روتينات حذف ذاتي تُسمى scheduleSelfDelete وdeleteExecutable، وفقًا لسجل OSV، ولهذا فإن الإرشادات تقضي بتعقّب آثار العمليات والشبكة بدلًا من الملفات. وأضافت النسخة 0.1.25 lib/tls-trust.js، الذي يضبط SSL_CERT_FILE على ملف مُضمّن لجهات إصدار الشهادات يضم 145 شهادة على أنظمة Linux المصغرة، وفقًا لـ StepSecurity — إصلاح يهدف إلى جعل حركة المرور الخاصة به تعمل على الحاويات التي تفتقر إلى مخزن ثقة نظامي.

كان خط أنابيب الإصدار هو وسيلة الدخول

إعادة بناء SafeDep هي أكثر الروايات تفصيلًا عن الوصول الأولي، وهي تشير إلى GitHub Actions بدلًا من كلمة مرور سجل مسروقة. بين 00:48 و02:03 UTC، قام حساب GitHub يعمل باسم Memtensor-AI بإنشاء ودفع وحذف فرع اسمه sc/release-0.1.21-20260922-cloud خمس مرات. عدّل الالتزام 9b97ec6 سكربت سير العمل .github/scripts/validate-release-confirmation.mjs بحيث أضاف قيمة BASH_ENV إلى $GITHUB_ENV، مما جعل خطوات الصدفة غير التفاعلية اللاحقة تستورد ملفًا مقدَّمًا من المهاجم sckit-publish-bridge.sh قبل تشغيل أوامرها. تحقق ذلك الجسر من اسم الحزمة ومن مهلة 150 ثانية لخطوة النشر، واستدعى جامع الرموز باستخدام NPM_TOKEN أو NODE_AUTH_TOKEN، ثم حذف نفسه وخرج بالرمز 1 — لذا فشل النشر بعد أن أُخذ الرمز. ظهر أول إصدار npm خبيث بعد عشرين دقيقة من دفع الفرع الأخير.

استخدم مسار PyPI نفس الحيلة ضد خط أنابيب مختلف. وتفيد SafeDep أن العلامة v2.0.34 كانت تشير إلى إيداعات غير موقعة لم تكن على الفرع الرئيسي، وأن الإيداع b52958f، المنسوب إلى "MemTensor CI Review"، أضاف ستة ملفات ثنائية ومحمّل Python وخلفية بناء مخصصة تُسمى sckit_poetry_build. كتبت تلك الخلفية BASH_ENV يشير إلى _pypi_bridge.sh في $GITHUB_ENV؛ وقد عمل الجسر فقط داخل غلاف تحميل twine، وجلب فهرسًا موقّعًا من مضيف skyleen[.]fr، وتحقق من مُصدِر باستخدام تطبيق Ed25519، وطبع سطرًا علاميًا، وأزال كلمة مرور التحميل، وخرج دون تحميل أي شيء. بعد حوالي ساعتين، الإيداع 41bf5c7 أزال ذلك الاستدعاء برسالة "chore: allow native PyPI upload [skip ci]"، وتم حذف العلامة وإعادة إنشائها في غضون عشر ثوانٍ، وتبع تحميل PyPI بعد 62 ثانية من ذلك. تقرأ SafeDep الإيداع الأول على أنه عملية التقاط رمز، والثاني على أنه العملية التي سمحت لسير عمل MemTensor الخاص ببناء ونشر الحزمة الخبيثة باستخدام رمز المشروع الحقيقي.

لا تتفق كل الروايات على هذا. لاحظت Socket أن إصدارات npm جاءت من حساب npm نفسه الذي جاءت منه الإصدارات الشرعية السابقة، وأنها افتقرت إلى gitHead، وهو ما فسّرته على أنه مؤشر إلى أنها لم تكن من إنتاج CI الخاص بالمشروع، وذكرت أنها لم تستطع تأكيد كيفية حصول المهاجم على صلاحية النشر. ونقلت SC Media نتائج Socket في 24 سبتمبر وخلصت إلى الاستنتاج نفسه بشأن تعرّض الحساب للاختراق. تتفق الروايتان على أن بيانات اعتماد النشر أُخذت من خط إنتاج الإصدارات، وتختلفان في كيفية إنتاج حزمة npm نفسها؛ فلم ينشر أحد سجلات سير العمل، لأن GitHub Actions API لم تُظهر أي تشغيلات بعد 7 سبتمبر، ويستنتج SafeDep أن السجلات حُذفت. أما كيفية حصول حساب Memtensor-AI على صلاحية الدفع إلى المستودع (push access) في المقام الأول فهي غير معروفة في الروايتين؛ وتعتبر SafeDep أن سرقة رمز الحساب (token) أمر مرجح لكنه غير مؤكد.

مُثبَت، ومُستنتَج، وغائب

درجة الثقة في السجل هي A، وهو غير متنازع عليه، والأمر يستحق الدقة، لأن اليقين مرتبط بما نُشر لا بما فعله.

• المُثبَت: محتويات القطع الأثرية الأربع، التي أُعيد بناؤها عبر التحليل الساكن في Socket وStepSecurity وSafeDep؛ وأوقات النشر على npm والوسم latest على 0.1.25؛ وقفزة الحجم في كلتا المنظومتين البيئيتين؛ والالتزامات والوسوم وسجل الفروع في المستودعين؛ والبنية التحتية skyleen[.]fr ومعرّفات الحملة cloud-openclaw-semi-nuclear وmemos-semi-nuclear؛ وإعدادات الحمولة، التي تنتهي صلاحيتها في 22–23 أكتوبر 2026 وفقًا لـ Socket وSafeDep.

• مُستنتج: أن الأداة كُتبت بمساعدة نموذج لغوي، وهو ما تقوله SafeDep مباشرة وتصفه بأنه استنتاج؛ وأن رموز النشر المسروقة كانت مقصودة لإعادة الاستخدام، وهو ما تدعمه سلسلة القناة في الإعدادات — "exact-ref-one-use-NPM_TOKEN" — لكنها لا تثبته.

• غير مثبت: من كان المهاجم؛ وما إذا كانت أي نسخة من sckit قد نُفّذت يوماً خارج بيئة معزولة؛ وما إذا كانت أي بيانات اعتماد قد غادرت مضيفاً؛ وما إذا كان أي توجيه كُتب داخل وكيل OpenClaw قد وصل إلى المهاجم؛ وما إذا كانت أي حزمة تابعة قد أُعيد نشرها. أجرى كل من Socket وStepSecurity تحليلاً ثابتاً، وتذكر StepSecurity أنه لم يُلاحظ في تحليلها تشغيل أي عملية، ولا نقل أي سر، ولا تسريب ناجح، ولا تثبيت أي سير عمل، ولا نشر أي حزمة إضافية.

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

الدودة التي لم يُرَ أنها تنتشر قط

تحتوي الملفات الثنائية على أكثر من مجرد أداة سرقة. تُدرج SafeDep دوالّ باسم recursivePublish، وprepareRemoteNode، وprepareRemotePython وprepareRemoteWorkflow، إضافةً إلى قالب GitHub Actions مضمّن يُشغَّل عند الدفع، والقدرة على كتابة ملف سير عمل باسم runtime-update.yml داخل المستودعات التي يستطيع البرنامج الخبيث الوصول إليها. عثرت Socket على سلاسل نصية تتعلق بترميز بيانات حزم البرامج وتثبيت ملفات المستودعات، وخلصت إلى أن الملفات الثنائية قد تكون قادرة على إعادة نشر الحزم باستخدام رموز سجل مسروقة.

هذا تصميم دودة. وهو ليس دودة لوحظ أنها تعمل. ولم تجد StepSecurity أي دليل على أن المنطق قد استُخدم يومًا للانتشار، كما أن مذكرة الأبحاث الصادرة عن Cloud Security Alliance في 25 سبتمبر تقرأ هذه القدرة على أنها إمكانية محدودة للانتشار الذاتي لا سلوك دودة مؤكدًا. وقد وصفت عدة منافذ إعلامية القضية بأنها أول دودة في سلسلة التوريد تستهدف البنية التحتية لذاكرة وكلاء الذكاء الاصطناعي؛ والوصف منصف كبيان عن التصميم، لكن التقارير لا تدعمه كبيان عما حدث.

ماذا تغيّر بعد ذلك؟

تم التنظيف في السجلات في اليوم نفسه. عند التحقق في 26 أكتوبر 2026، لم تعد بيانات تعريف حزمة npm تُدرج 0.1.21 أو 0.1.23 أو 0.1.25 ضمن إصداراتها، ويشير وسم latest إلى 0.1.24، وكان آخر تعديل على الحزمة في 11:53 UTC يوم 23 سبتمبر. لا يزال وسمان غير معتادين من dist-tags مرفقين — clean-inverse-0-1-23 مشيرًا إلى 0.1.22 وclean-inverse-0-1-25 مشيرًا إلى 0.1.24 — بما يعكس الإصدارين النظيفين اللذين قاطعا الإصدارات الخبيثة لفترة وجيزة. على PyPI، لم يعد MemoryOS 2.0.34 موجودًا وأحدث إصدار هو 2.0.33، الذي رُفع في 3 سبتمبر 2026؛ ولم يصدر أي إصدار PyPI آخر خلال الأسابيع السبعة منذ ذلك الحين.

ما لم يتغيّر هو الرواية العامة للمشروع. فلا يسرد المستودع أي تنبيهات أمنية، ولا تزال مشكلة GitHub المؤرخة عند الساعة 04:17 من يوم الحادث مفتوحة ودون إجابة، ولا يقتبس أي من التقارير التي استُعرضت هنا بيانًا من MemTensor أو من OpenClaw. ولم تحمل أي من الحزمتين الخبيثتين شهادة إثبات منشأ، وهو ما تشير SafeDep إلى أنه أزال الإشارة الوحيدة إلى أن المخرجات كانت قد بُنيت من إيداع غير متوقع.

الاستجابة الموجودة فعلاً هي على جانب الكشف: أضافت StepSecurity نطاقات القيادة والتحكم skyleen[.]fr إلى قائمة الحظر العالمية الخاصة بها، ويتم تتبُّع الحزمتين في OSV تحت المعرّفين MAL-2026-16476 وMAL-2026-16475.

إذا تم تثبيت إصدار متأثر

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

• أزل الحزمة وثبّت على نسخة نظيفة — npm 0.1.20، PyPI 2.0.33. تحذّر StepSecurity من أن تحليلها لم يُرسِ أساسًا نظيفًا لـ PyPI، بينما يسمّي كل من SafeDep وSC Media الإصدار 2.0.33 آخر إصدار جيد.

• ابحث عن سطر أوامر العملية، لأن الملف التنفيذي قد يحذف نفسه: sckit stage0 --config64، ومتغير البيئة SCKIT_EVENT_TEXT.

• احذف مجلدات الحالة ~/.openclaw/.cache/runtime و~/.memos/.cache/runtime، وتحقق من المستودعات بحثًا عن سير عمل runtime-update.yml غير متوقع أو .sckit/ مجلدات.

• قم بتدوير كل بيانات اعتماد يمكن الوصول إليها من الدليل الرئيسي وبيئة العملية، من جهاز نظيف: npm، PyPI، GitHub، GitLab، AWS، Vault، SSH، Hugging Face، Slack، Stripe وSendGrid، وأي قيم .env. رموز السجل والتحكم في المصدر تأتي أولًا.

• راجع إصدارات حزمك الخاصة، في حال استُخدم رمز نشر مسروق لنشر إصدارات لم تكتبها.

• احجب skyleen[.]fr ونطاقاته الفرعية، واقرأ سجلات الخروج حتى 23 سبتمبر.

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