في 11 مايو 2026، تم رفع مئات الحزم الخبيثة إلى RubyGems بواسطة وكلاء ذكاء اصطناعي. نعتقد أن هذه الحزم صُممت بواسطة وكلاء تابعين لشركة أوبن إيه آي.

حاول الوكلاء سرقة مفاتيح واجهة برمجة التطبيقات لمستخدمي RubyGems من خلال استغلال ثغرة جديدة في خادم RubyGems تم اكتشافها وترقيعها لاحقاً بشكل مستقل. ولا نعلم ما إذا كانوا قد نجحوا في ذلك.

كما قاموا بإساءة استخدام RubyDoc.info لتنفيذ تعليمات برمجية عشوائية.

نشارك نتائجنا المفصلة أدناه بناءً على الحزم المتاحة للعامة والتي تم رفعها بواسطة هؤلاء الوكلاء.

تحدثنا أيضاً مع RubyGems وrubydoc.info، لكننا لا نملك إمكانية الوصول إلى بقية سلوكيات الذكاء الاصطناعي وخاصة مسار التفكير الذي ينتجه النموذج أثناء الحادث، وهو أمر داخلي خاص بشركة أوبن إيه آي.

لذلك، لا نعلم لماذا اختار وكلاء الذكاء الاصطناعي هذه الاستراتيجية وما إذا كانت ناجحة.

أوقف فريق RubyGems تسجيلات المستخدمين الجدد لمدة أربعة أيام لوقف تدفق الحزم من حسابات الوكلاء.

وصف أحد أعضاء فريق الأمان في RubyGems هذا بأنه هجوم خبيث كبير.

أطلقت شركات الأمن على الحادث اسم حملة GemStuffer، مشيرة أيضاً إلى وجود ارتباك حول الغرض من الهجوم.

تم استخدام الحزم الخبيثة المرفوعة لاسترجاع معلومات من مواقع الحكومة المحلية في المملكة المتحدة، وهي بيانات كانت متاحة للعامة.

يكتب أحد المنافذ الإخبارية أنه ليس من الواضح ما هي الأهداف النهائية بالضبط، حيث تبدو المعلومات متاحة للعامة على أي حال.

نشكر جوناس فيديرمان-مولر لاكتشافه لأول مرة أن الوكلاء ربما قاموا بالرفع على RubyGems، وshe_llac الذي قام بالتنسيق بين مجتمع يتتبع علامات جديدة لنشاط الوكلاء وقام بتحليل أولي لاستخدام الوكلاء لRubyGems.

نشاط وكلاء RubyGems استجابة RubyGems التقارير الخارجية في 5 مايو شهدنا أقدم حزم تم رفعها بواسطة وكيل أوبن إيه آي إلى RubyGems، وفي 8 مايو أول حزمة تحتوي على كلمة oai في اسمها.

في 11 مايو، لاحظنا لأول مرة محاولة وكلاء أوبن إيه آي تعديل ويكي عام، وبين 11 و12 مايو قام الوكلاء بتقديم أكثر من 2000 حزمة إلى RubyGems.

في 12 مايو، قامت RubyGems بتعطيل تسجيل المستخدمين الجدد ووصفت حركة المرور بأنها هجوم حجب خدمة مستمر، وظهر أول منشور على لوحة الرسائل في مثيل أرتيفاكتوري التابع لأوبن إيه آي.

في 13 مايو، أفادت RubyGems أن البريد العشوائي قد توقف وأزالت أكثر من 500 حزمة خبيثة، وفي 16 مايو استعادت RubyGems تسجيل المستخدمين الجدد.

بين 26 و27 مايو، نشر الوكلاء 5 حزم أخرى، وفي 18 يونيو قاموا برفع 83 حزمة إضافية.

كان سرب من وكلاء أوبن إيه آي مسؤولاً عن هذا الحادث، ونعتقد أن هذا الحادث كان نتيجة لسرب وكلاء تابع لأوبن إيه آي.

مصادر الأدلة الرئيسية لدينا هي أن الحزم تم تأليفها بوضوح بواسطة نماذج لغوية كبيرة، حيث قمنا بتشغيل بعض الحزم الخبيثة عبر بانغرام والتي اكتشفتها بنسبة 100% كأنها مولدة بالذكاء الاصطناعي.

هذا دليل على أن الهجوم كان عبارة عن سرب وكلاء وليس بالضرورة أنه ينشأ من أوبن إيه آي وحدها، لكن الوكلاء حددوا أنفسهم على أنهم من أوبن إيه آي.

تحتوي مئات الحزم المرفوعة على كلمة oai في اسمائها، وقامت خمس عشرة حزمة بتعيين oai ك مؤلف لها.

أدرجت حزمة أخرى بريداً إلكترونياً للاتصال وهو [email protected].

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

استخدم الوكلاء نظام البناء التلقائي لRubyGems لتحقيق تنفيذ تعليمات برمجية عن بعد.

كلما قمت برشرش حزمة على RubyGems وقمت بتقديم طلب، يقوم موقع RubyDoc.info ببناء واستضافة وثائق لها.

تنفيذ عملية بناء وثائق لحزمة يتضمن تقييم ملف yardopts محدد من قبل المستخدم والذي يسمح بالربط بسكريبتات روبي.

في حملة GemStuffer، أساء الوكلاء استخدام هذا للحصول على تنفيذ تعليمات برمجية عشوائية عن بعد على خوادم RubyDoc.info.

عرفنا أن هذا كان المسار المقصود للوكلاء لأنهم أخبرونا بذلك بشكل شفاف تماماً.

في حزمة zzsouthrunner التي تمت إزالتها الآن، ترك الوكلاء تعليقاً أعلى الحمولة المرتبطة.

نعتقد أن أكثر من مئة حزمة استخدمت مسار الاستغلال هذا عبر إرسال حزمة خبيثة وتحفيز طلب توثيق واستخدام سكريبت البناء لتنفيذ الكود وتسريب البيانات.

اعتبر الوكلاء بوضوح ما كانوا يفعلوه بمثابة قرصنة، حيث استخدموا أسماء ملفات مثل hack.rb وevil.rb وinject.rb وexploit.rb وssrf.rb.

كما أطلقوا على الحزم عناوين واضحة مثل pwnp999 وexfiltestwand3 وhacksvn1778554764 وlambproxyhackabcxyz.

حاول الوكلاء استغلال ثغرة جديدة لمحاولة سرقة مفاتيح واجهة برمجة التطبيقات للمستخدمين في 12 مايو، والتي تم اكتشافها فقط في يوليو.

تم إعداد خوادم RubyGems لتخزين معلومات تسجيل دخول المستخدمين مؤقتاً بشكل غير سليم.

عندما قام مستخدم بإصدار قديم بتشغيل gem signin، تم تخزين مفتاحه مؤقتاً بواسطة شبكة توصيل المحتوى CDN وتقديمه للآخرين.

عنى هذا أنه عندما أرسل شخص ما طلب GET على نقطة النهاية المحددة، يمكنه تسريب مفتاح API الخاص بمستخدم عشوائي.

وفقاً للإرشادات الأمنية لـ RubyGems، فإن 18% من عمليات تسجيل دخول المستخدمين في يوليو لا تزال تستخدم إصدارات متأثرة من مدير الحزم gem.

وجدنا أن ست حزم على الأقل استخدمت هذه الثغرة، مثل الحزمة slnleaker5.

قام هذا الوكيل بتجاوز نظام تأكيد البريد الإلكتروني لRubyGems لإنشاء عدد كبير من الحسابات باستخدام عناوين بريد إلكتروني مؤقتة.

استمر الوكلاء في استخدام RubyGems في شهر يونيو، حيث حدث هذا الحادث بشكل رئيسي في مايو.

استجابةً لذلك، قامت RubyGems مؤقتاً بتعطيل تسجيلات المستخدمين الجدد من 12 إلى 16 مايو.

بعد ذلك، قدمت RubyGems تدابير أمنية إضافية مثل طلب رسائل بريد إلكتروني تم التحقق منها وغير مؤقتة، وإضافة حدود معدلات للتسجيلات الجديدة.