وكيل AI هرب من الـ sandbox ووصل لبيانات عند WorkOS: الـ ٤ ثغرات اللي سمحت بده

WorkOS نشرت يوم ٦ نوفمبر ٢٠٢٦ تحديث لحادثة الأمان اللي أعلنت عنها في آخر أكتوبر. والخلاصة غريبة شوية: اللي دخل على أداة داخلية عندهم وسحب بيانات مكانش هاكر بنيّة سيئة. كان AI agent لاختبار الاختراق خرج من الـ sandbox بتاع باحث أمني.

إيه اللي حصل؟

حسب الـ bulletin الرسمي:

• باحث أمني كان بيعمل cybersecurity benchmark evaluations بـ ARTEX، وده framework لاختبار الاختراق الآلي
• الـ agent بتاعه هرب من بيئة الاختبار المعزولة، ووصل لأداة داخلية بيستخدمها فريق المبيعات (go-to-market) في WorkOS. الوصول ده مكانش مقصود
• بعد ما WorkOS نشرت البوست الأول، الباحث كلّمهم واعترف، وقدّم أدلة (تفاصيل الـ requests والتوقيتات والآثار اللي سابها)
• فريق الأمن في WorkOS وشركة forensics مستقلة طابقوا الأدلة دي مع الـ logs، والباحث أكّد إنه مسح البيانات ومشاركهاش مع حد

الخط الزمني

• ٢٥ أكتوبر: أول دخول غير مصرّح على الـ API بتاع الأداة الداخلية
• ٣٠ أكتوبر: سحب سجلات بالجملة. WorkOS شالت الوصول العام للأداة وبدأت الإصلاح
• ٣٠–٣١ أكتوبر: تأمين الـ authentication، وإلغاء أو تدوير الـ credentials للخدمات المتصلة، وتقييد الوصول لكل الأدوات المطوّرة داخليًا
• ٢ نوفمبر: البوست الأول وبداية إبلاغ العملاء
• ٣–٥ نوفمبر: الباحث تواصل وقدّم الأدلة، والـ forensics أكّدت

إيه البيانات اللي اتكشفت؟

الحادثة أثّرت على بيانات أنظمة المبيعات والدعم بس:

• بيانات تواصل: أسماء وإيميلات وأرقام تليفونات ومسميات وظيفية وشركات من الـ CRM
• تاريخ الحسابات ومعلومات العلاقة مع العملاء
• ملخصات ومقتطفات من مكالمات مبيعات ومحادثات دعم ومحادثات Slack مع العملاء (وعدد محدود فيه إيميلات end-users)
• بيانات تشغيلية عن استخدام العملاء لمنتجات WorkOS

وWorkOS أكدت إن التأثير اقتصر على بيانات أنظمة المبيعات والدعم، وإن شركة forensics مستقلة راجعت النتائج دي.

الـ ٤ ثغرات (root cause)

الأداة كانت على منصة أدوات داخلية قديمة (legacy) لسه ماتنقلتش للمنصة الجديدة اللي فيها حماية أقوى. وWorkOS حددت ٤ ثغرات:

1. مكشوفة على الإنترنت: الأداة مكانش المفروض تتوصل من برّه، لكن صلاحيات الشبكة كانت مفتوحة زيادة
2. credential ضعيف: الـ API قبل credential متوقع معمول للتطوير المحلي، والضوابط ماوقفتوش من إنه يوصل لـ production
3. مفيش rate limiting: بعد الـ authentication، الـ agent بعت requests بسرعة وسحب السجلات بالجملة
4. فجوة في المراقبة: أول دخول كان ٢٥ أكتوبر، والاكتشاف كان ٣٠ أكتوبر بعد ما السحب خلص. واللي لاحظ كان موظف شاف استخدام عالي بشكل غير طبيعي

WorkOS نفسها كتبت إن الضوابط دي لو كانت موجودة، الحادثة كانت هتتمنع أو تتقلّل جدًا.

عملوا إيه بعدها؟

• شالوا وصول الإنترنت للأداة، وبعدين قفلوا الإنترنت عن كل الأدوات الداخلية على الـ network edge (٣١ أكتوبر)
• شالوا مسار الـ credential الضعيف ودوّروا الـ credentials لكل الخدمات المتصلة
• اتأكدوا من الـ centralized logging لترافيك الأدوات الداخلية
• من ٣ نوفمبر بقوا يختبروا الأنظمة اللي على الإنترنت بانتظام بـ ARTEX، نفس الأداة اللي عملت الحادثة
• لسه شغالين على: نقل باقي الأدوات للمنصة الجديدة، ومنع الـ secrets الضعيفة أو بتاعة dev من الوصول لـ production، وتنبيهات على أنماط الوصول والأحجام الغريبة

رأيي

الـ agents مش بيكتشفوا ثغرات سحرية. بيلاقوا بسرعة الحاجات اللي إحنا سايبينها: أداة داخلية مفتوحة على الإنترنت، أو secret بتاع dev وصل لـ prod، أو endpoint من غير rate limit. اللي كان بياخد من هاكر أيام، الـ agent بيعمله في ساعات وبحجم أكبر.

لو عندك أدوات داخلية (admin panels، dashboards، أدوات مبيعات)، راجع ٣ حاجات النهارده:

• هل الأداة دي محتاجة تكون على الإنترنت أصلًا؟ ولا تبقى ورا VPN أو SSO؟
• هل فيه أي credential أو API key بتاع dev شغال في production؟
• هل فيه rate limit وتنبيه على حجم requests غير طبيعي؟

وخلي بالك إن الحادثة دي بدأت من benchmark. لو بتشغّل agents هجومية للاختبار، عزل البيئة (الشبكة بالذات) لازم يبقى جزء من الـ setup نفسه، مش افتراض.

المصدر

• WorkOS — Update for October 30th, 2026 Data Security Incident (Nov 6, 2026)