Clinejection: كيف وصل عنوان مشكلة إلى رمز npm الخاص بـ Cline

في 9 فبراير 2026، نشر الباحث الأمني عدنان خان سردًا لثغرة كان قد أبلغ بها Cline بشكل خاص في 1 يناير: كان مساعد البرمجة بالذكاء الاصطناعي مفتوح المصدر قد وصّل فرّازًا آليًا للمشكلات، مبنيًا على إجراء GitHub المسمى claude-code-action التابع لـ Anthropic، بموجّه نصي كان يلصق أي عنوان لمشكلة واردة على GitHub مباشرةً داخل تعليمات النموذج. كان بإمكان أي حساب على GitHub تحفيزه بفتح مشكلة، وفي إعادة إنتاج خان جعل عنوان مصاغ على هيئة تعليمات الوكيل ينفّذ أمر shell داخل سير العمل. ثم تتبّع المسار من نقطة الارتكاز تلك، عبر تسميم ذاكرة التخزين المؤقت في GitHub Actions، وصولًا إلى بيانات اعتماد الإصدار الخاصة بـ VS Code Marketplace وOpenVSX وnpm. بعد ثمانية أيام من إصلاح Cline لسير العمل، استُخدم رمز نشر على npm كان Cline يعتقد أنه قد دوّره لنشر cline 2.3.0، الذي ثبّت OpenClaw على كل جهاز ثبّت الحزمة. يقع المدخل الكامل، مع درجات الخطورة والثقة الخاصة به، في أرشيف حوادث Orca AI، إلى جانب سجلات سلسلة التوريد المجاورة من الفترة نفسها.

تاريخان، وليس تاريخًا واحدًا

يؤرخ الأرشيف هذا السجل في 9 فبراير 2026، بدقة تصل إلى اليوم، وذلك هو اليوم الذي نشر فيه خان تقريره على adnanthekhan.com. وهو ليس اليوم الذي ظهرت فيه الحزمة الخبيثة. أُدخلت الثغرة نفسها في 21 ديسمبر 2025، في commit أضاف سير عمل الفرز إلى مستودع cline/cline، وظلت قائمة حتى حذف Cline سير العمل في 9 فبراير. وجاء النشر غير المصرح به على npm في 17 فبراير، أي بعد ثمانية أيام من الإصلاح وسبعة وأربعين يومًا من أول تقرير خاص من خان.

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

السلسلة: من عنوان مشكلة إلى رمز إصدار

كان الملف المعرّض للخطر هو .github/workflows/claude-issue-triage.yml، الذي كان يعمل عند حدث issues ويستدعي anthropics/claude-code-action@v1 مع Claude Opus 4.5، المثبّت في سير العمل باسم claude-opus-4-5-20251101. ويقتبس Khan إعدادات سير العمل: كان allowed_non_write_users مضبوطًا على wildcard "*"، لذا كان بإمكان أي حساب GitHub تشغيل الوكيل بمجرد فتح issue، وكان claude_args يمرّر --allowedTools مع Bash وRead وWrite وEdit وGlob وGrep وWebFetch وWebSearch. وكان Bash هو الأهم. فقد منح النموذج تنفيذ shell داخل سير عمل كان يعمل في سياق الفرع الافتراضي.

أدرج الموجّه عنوان المشكلة دون تعقيمه. استخدم إثبات المفهوم الخاص بخان عنوانًا يبدأ بـ "Tool error." ويستمر بتعليمات لتثبيت حزمة مساعدة من commit محدد قبل متابعة الفرز. أشار مرجع الـ commit إلى fork يحمل ملف package.json الخاص به سكربت preinstall، شغّل أمر curl ضد نقطة نهاية يتحكم بها المهاجم قبل أن ينتهي npm من تثبيت أي شيء. ولأن التثبيت جرى عبر أداة Bash، لم يفحص النموذج ما الذي نُفّذ. أعاد خان إنتاج ذلك على نسخة مرآة من مستودع Cline ويُفيد بأن الوكيل نفّذ الحمولة في كل محاولة.

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

مدخلات ذاكرة التخزين المؤقت غير قابلة للتغيير، لذا لا يستطيع المهاجم ببساطة الكتابة فوق المدخل الذي ستستعيده مهمة إصدار. كان مسار خان للالتفاف على ذلك هو استغلال تغيير في سياسة GitHub بتاريخ 20 نوفمبر 2025، جعل الخدمة تُخرج مدخلات ذاكرة التخزين المؤقت فورًا بمجرد تجاوز ذاكرة التخزين المؤقت لمستودع ما 10 GB، وفق ترتيب الأقل استخدامًا مؤخرًا. أغرِق ذاكرة التخزين المؤقت بما يتجاوز 10 GB، وستتقادم المدخلات الشرعية وتخرج؛ واستحوذ على المفاتيح التي أُخليت بمحتوى مسموم، وستشغّل المهمة التالية التي تستعيدها شيفرة المهاجم. تؤتمت Cacheract التسلسل بأكمله داخل تشغيل سير عمل واحد، وتستديم ذلك عبر الكتابة فوق action.yml الخاص بـ actions/checkout بحيث تنفّذ خطوة ما بعد الإجراء حمولة في نهاية كل مهمة.

الحلقة الأخيرة في السلسلة هي المهمة الليلية، التي تعمل عند نحو الساعة 2 صباحًا بتوقيت UTC، وتستعيد node_modules الملوثة، ثم تنفجر. وما يخرج منها هو VSCE_PAT وOVSX_PAT وNPM_RELEASE_TOKEN، وهي بيانات الاعتماد الخاصة بـ VS Code Marketplace وOpenVSX وnpm على الترتيب. أما ما إذا كانت كل حلقة قد شُغّلت على مستودع Cline نفسه وفي ذلك الترتيب، فهي مسألة منفصلة نتناولها أدناه.

لماذا كانت بيانات الاعتماد الليلية هي بيانات اعتماد الإنتاج

الاعتراض الواضح هو أنه ينبغي أن تحتفظ الإصدارات الليلية وإصدارات الإنتاج بأسرار مختلفة. إجابة خان هي أن الفصل كان اسميًا. تربط OpenVSX وVS Code Marketplace رمز النشر بهوية ناشر، لا بامتداد فردي، وقد نُشرت إضافتا Cline المستقرة والليلية تحت الهوية نفسها، التي يحددها خان على OpenVSX باسم saoudrizwan. على npm، يرتبط نموذج الرمز المميز دقيق التحديد بالحزمة، وقد نشرت Cline نسختي CLI المستقرة والليلية إلى حزمة cline نفسها. لذلك كان يمكن لرمز صادر لمهمة الإصدار الليلي أن ينشر منتج الإنتاج، وهو بالضبط ما حدث بعد ثمانية أيام.

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

ما الذي نُشر فعليًا، وما الذي فعله

كان المنتج المنشور هو cline 2.3.0، وكان صغير الحجم. وتضع الطوابع الزمنية الخاصة بسجل npm نفسه الإصدار 2.3.0 عند 11:26:51 UTC في 17 فبراير 2026، والإصدار 2.4.0 النظيف عند 19:23:08 UTC في اليوم نفسه، وهي فترة تعرض يقدّرها التنبيه الأمني الصادر عن Cline بنحو ثماني ساعات، إلى أن أُهمل الإصدار 2.3.0 عند الساعة 11:30 صباحًا بتوقيت المحيط الهادئ. واحتوى ملف package.json الخاص بالحزمة على سطر واحد مضاف، وهو سكربت postinstall نصّه npm install -g openclaw@latest. ويذكر التنبيه الأمني الصادر عن Cline، GHSA-9ppg-jx86-fqw7، أنه لم تُعدَّل أي ملفات أخرى في الحزمة، وأن dist/cli.mjs مطابق بايتًا ببايت لبناء 2.2.3 الشرعي.

‏OpenClaw إطار عمل حقيقي مفتوح المصدر لوكلاء الذكاء الاصطناعي، وليس برمجية خبيثة، وتنبيه Cline يقول ذلك صراحةً: فهو مشروع شرعي، لكن تثبيته لم يكن مصرَّحًا به أو مقصودًا. وقد قيَّمت Endor Labs، التي حلَّلت حزمة tarball، التأثير الإجمالي بأنه منخفض لأن التثبيت لم يشغِّل خادم Gateway الخفي الخاص بـ OpenClaw. أما تقرير StepSecurity فيقيس الجانب الآخر من المسألة: فالتثبيت العام يترك إطار العمل على القرص بما لدى المستخدم القائم بالتثبيت من بيانات اعتماد ووصول إلى الملفات، ويجعل تصميم OpenClaw، أي بوابة محلية دائمة مع واجهة برمجة تطبيقات للمشغّل، شيئًا عالي القيمة يمكن العثور عليه هناك. والتقييمان لا يتناقضان. فأحدهما يصف ما جرى خلال النافذة الزمنية؛ ويصف الآخر ما تُرك بعد ذلك.

الحجم هو الرقم الوحيد الذي يجب التعامل معه بحذر. أفادت StepSecurity بأن النسخة المخترقة نُزّلت نحو 4,000 مرة قبل سحبها، وكررت The Register هذا الرقم. ووضعت Endor Labs عدد التنزيلات الشهرية لـ cline للفترة من 19 يناير إلى 17 فبراير عند 418,545، وهو ما يصف حركة التنزيلات المعتادة للحزمة وليس البناء الخبيث. ولا يعكس أي من الرقمين عدد الأجهزة: فعدد التنزيلات ليس عدد المطورين المتأثرين، ولم ينشر أي طرف رقمًا لقاعدة التثبيت الخاصة بـ 2.3.0. وقال فريق Threat Intelligence التابع لـ Microsoft على X إنه لاحظ "ارتفاعًا طفيفًا لكنه ملحوظ" في عمليات تثبيت OpenClaw في 17 فبراير ناشئًا عن سكربت التثبيت الخاص بـ Cline، وفقًا لما أوردته The Hacker News.

لا يحمل سجل الاستشارة الخاص بـ GitHub بشأن GHSA-9ppg-jx86-fqw7 أي CVE أو CWE، ودرجة خطورته منخفضة. وتتعلق هذه الدرجة بالحمولة الحميدة، لا بسرقة بيانات الاعتماد، وهي تبدو غريبة إلى جانب التصنيف الحرج الذي منحه الأرشيف للحادثة نفسها. ويسجّل الاستشاري الإصدار 2.3.0 بوصفه الإصدار المتأثر، والإصدار 2.4.0 بوصفه الإصلاح.

الإفصاح الذي لم يُجب عنه Cline

الجدول الزمني لما قبل النشر الخاص بخان هو الجزء من السجل الأقل ارتباطًا بالنموذج والأكثر ارتباطًا بالعملية. فقد قدّم GHSA عبر الإبلاغ الخاص عن الثغرات في GitHub في 1 يناير 2026، وأرسل بريدًا إلكترونيًا إلى جهة اتصال الأمان المدرجة في صفحة الثقة الخاصة بـ Cline في اليوم نفسه. وأرسل متابعة إلى أحد مطوري Cline في 8 يناير. وحاول إرسال رسالة مباشرة إلى الرئيس التنفيذي لـ Cline على X في 18 يناير. وكتب مجددًا في 7 فبراير ولم يتلقَّ سوى رقم تذكرة آلي. ونشر في 9 فبراير.

دمج Cline الإصلاح، طلب السحب 9211، بعد نحو ثلاثين دقيقة إلى ساعة. يحذف طلب السحب ثلاثة ملفات سير عمل، هي claude-issue-triage.yml وclaude-pr-review.yml وcline-pr-review.yml، ويزيل التخزين المؤقت من publish.yml وpublish-nightly.yml وnpm-nightly.yaml وnpm-main.yaml، أي سبعة ملفات إجمالًا، مع جعل خطوات التثبيت غير مشروطة الآن بعد عدم وجود إصابة في التخزين المؤقت يمكن الاعتماد عليها.

قبِل ردّ Cline العلني في 10 فبراير، كما اقتُبس في منشور Khan، النتيجةَ، وأورد تدابير تخفيف فورية: إزالة سيرَي عمل مراجعة البوت للمشكلات وطلبات السحب (PR)، وإزالة actions/cache من سير عمل النشر التي تتعامل مع بيانات اعتماد الإصدار، وتدوير بيانات الاعتماد ذات الصلة بما في ذلك رموز البوت والمزوّد والنشر. كما أقرّ بطريقة التعامل قائلاً: «نقرّ بأن مدة استجابتنا لتقريرك الأولي كانت غير مقبولة. كان ينبغي ألا يحتاج تقرير قُدّم في 1 يناير إلى كشف علني في 9 فبراير حتى تتم معالجته.»

في 11 فبراير، قالت Cline إنها أكملت تدويرًا كاملًا لـ VSCE_PAT وOVSX_PAT وNPM_RELEASE_TOKEN، وإن تدقيقًا لكل إصدار على قنوات التوزيع الثلاث بين 21 ديسمبر 2025 و9 فبراير 2026 وجد أن كل نسخة في Marketplace وOpenVSX مرتبطة بإصدار GitHub موسوم، وأن جميع إصدارات npm الـ41 كانت متسقة مع المصدر. وخلصت إلى أنه لم يُنشر أي إصدار غير مصرّح به «خلال نافذة التعرّض المزعومة». وبعد ستة أيام صحّحت السجل، في الرسالة المقتبسة أعلاه: لم يكن رمز npm قد أُبطل، وقد نُشر الإصدار 2.3.0 باستخدامه.

مُثبت، منسوب، غير محلول

مُثبت. إعداد سير العمل علني ونُشر قبل الإصلاح. أعاد Khan إنتاج حقن المطالبات على مرآة للمستودع. دمج Cline المعالجة وأصدر تنبيهًا أمنيًا يؤكد نشر 2.3.0، وإضافة سطر postinstall، وعدم تغيير الملف الثنائي لـ CLI، ونافذة الثماني ساعات، وفشل الرمز المميز. تتطابق الطوابع الزمنية لـ npm الخاصة بـ 2.3.0 و2.4.0 مع أوقات التنبيه. يصنّف الأرشيف السجل بدرجة حرج، عند ثقة A، مع تسجيل ضرر فعلي ودون علامة نزاع.

• منسوب، لا مُثبت. مَن نشر 2.3.0 يبقى إسنادًا مفتوحًا. التقرير الجنائي الذي نشره Michael Bargury وأداة تحقيق آلية تُسمى Raptor في 19 فبراير يذكر حساب GitHub باسم glthub-actions، ويفيد بثقة عالية بأن هذا الحساب أنشأ نسخة متفرعة من cline/cline، وفتح issue 8904 في 28 يناير 2026 الساعة 03:51 UTC بعنوان مُحقن، واستخدم commit في النسخة المتفرعة لتشغيل payload من gist. أكّد Khan أن الحسابين gcbrun وDev11940518 له، وأن glthub-actions ليس له. كان الحساب قد حُذف أو عُلّق بالفعل عندما نُشر التقرير، ولم يسمِّ Cline أحدًا. تعامل مع الهوية على أنها نتيجة طرف ثالث.

• محلّ خلاف من حيث الطابع، لا من حيث الوقائع. يقيّم Bargury الحادثة على أنها متسقة مع عرض توضيحي لبحث أمني لا مع حملة خبيثة، مستشهدًا بالحمولة غير الضارة وسجل الفاعل ضد مستودع أتمتة New Relic. يصفها Cline بأنها نشر غير مصرّح به، ويكتب Khan إن الفاعل الذي نشر 2.3.0 هو "على الأرجح" نفسه الذي سمّم ذاكرات التخزين المؤقت. لم يُظهر أحد نية لإلحاق الضرر، ولم يُظهر أحد أنه لم تكن هناك نية.

• لم يُحسم الأمر. ملاحظة خان التي سبقت النشر تُبدي حرصًا بشأن نقطة كثيرًا ما تُسطّحها التقارير اللاحقة: بين 31 يناير و3 فبراير 2026، فشلت عدة عمليات تشغيل ليلية بسبب خطوة Post Checkout لم تُنتج أي مخرجات، وهي مؤشر الاختراق لدى Cacheract، ويُعد سير عمل الفرز المسار الأكثر وضوحًا، لكن لم يثبت أنه كان نقطة الدخول لذلك النشاط. كما لم ينشر أي طرف أدلة على استخدام رموز Marketplace أو OpenVSX؛ والأثر الوحيد الذي أنتجه أي طرف هو بناء npm.

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

جاءت المعالجة على عدة طبقات في آن واحد، ومن الجدير تسمية كل منها لأنها تعالج أجزاءً مختلفة من الإخفاق. فقد حُذف سير العمل الذي كان يمكن لشخص خارجي الوصول إليه بدلاً من تضييقه. وأُزيل التخزين المؤقت من مهام سير العمل الأربع الخاصة بالإصدار التي تحتفظ بأسرار النشر، لا من المستودع بأكمله، وهو التغيير الذي يكسر نقطة التحول. وتم تدوير بيانات الاعتماد، وبعد تصحيح 17 فبراير أُبطل رمز npm الصحيح. وتذكر النشرة الإرشادية الصادرة عن Cline أن النشر عبر npm يستخدم الآن إثبات المنشأ عبر OIDC من خلال GitHub Actions، ويُظهر تحليل البيانات الوصفية الذي أجرته StepSecurity سبب أهمية ذلك: فقد كانت الإصدارات الشرعية تحمل بالفعل شهادات إثبات المنشأ، وكان 2.3.0 هو الشاذ الذي نُشر بواسطة حساب بشري. وكانت الفجوة أن مسار الرمز طويل العمر ظل مفتوحًا إلى جانب النشر الموثوق، وهو الأمر المحدد الذي يرى Endor Labs أنه ينبغي على المشرفين إغلاقه. ونشرت Cline GHSA-9ppg-jx86-fqw7، وأعلنت إهمال 2.3.0 برسالة مفادها أنه لا ينبغي تثبيته، ووجهت المستخدمين إلى 2.4.0 أو أحدث.

تذهب توصيات خان الهيكلية إلى أبعد مما تم تنفيذه، ويستحق تسجيلها باسمه لا باسم Cline: أزِل Bash وWrite وEdit من أي سير عمل فرز، واترك له قراءة الملفات واستدعاءات GitHub CLI المحددة التي يحتاجها؛ ولا تستعِد أبدًا ذاكرة تخزين مؤقت في مهمة تحمل أسرار نشر الإنتاج؛ وامنح الإصدارات الليلية مساحة أسماء خاصة بها في السجل وهوية نشر مخصصة غير إنتاجية، بحيث لا يستطيع رمز مميز مسروق للإصدارات الليلية نشر إصدار مستقر على الإطلاق.

الفجوة التي استمرت ثمانية أيام بين الإصلاح والنشر الخبيث هي التفصيل الذي يجعل هذا السجل جديرًا بالاحتفاظ به. كانت كل خطوة في السلسلة تقنية معروفة؛ فقد كان Khan قد نشر أداة تسميم ذاكرة التخزين المؤقت، ووثّق بحث PromptPwnd من Aikido Security في ديسمبر 2025 النمط نفسه من سوء تكوين الفرز. وما جمّعها في حادث سلسلة توريد هو سير عمل أتاح لنص شخص غريب الوصول إلى shell، وذاكرة تخزين مؤقت مشتركة مع مهام كانت تحمل مفاتيح إصدار، وتدوير رموز أغفل بيانات اعتماد واحدة. كان كل إصلاح من الإصلاحات الثلاثة سيكسر السلسلة بمفرده؛ لكن الثالث وصل متأخرًا ثمانية أيام.