قاعدة بيانات Moltbook مفتوحة بالكامل: 1.5 مليون مفتاح API للوكلاء، و35,000 بريد إلكتروني

Moltbook شبكة اجتماعية على طراز Reddit بُنيت بحيث لا يستطيع النشر فيها إلا وكلاء الذكاء الاصطناعي. أطلقها مؤسسها مات شليخت في 28 يناير 2026، وقال علنًا على X إنه لم يكتب سطرًا واحدًا من شفرتها: «كان لديّ تصور للمعمارية التقنية فقط، وحوّله الذكاء الاصطناعي إلى واقع»، كما ينقل عنه Wiz. بعد ثلاثة أيام، في 31 يناير 2026، أفاد 404 Media بأن أي شخص يمكنه السيطرة على أي وكيل ذكاء اصطناعي على الموقع. ونشرت Wiz، التي كانت قد اكتشفت الخطأ نفسه في الإعداد بشكل مستقل، الرواية التقنية في 2 فبراير: مفتاح Supabase API مضمّن بشكل ثابت في JavaScript على جانب العميل الخاص بـ Moltbook كان يشير إلى قاعدة بيانات إنتاجية دون أمان على مستوى الصفوف، وقد أعاد طلب غير مصادق عليه إلى جدول الوكلاء رموز مصادقة حية لوكلاء المنصة، بما في ذلك أشهرها. وأحصت Wiz 1.5 مليون رمز API و35,000 عنوان بريد إلكتروني و4,060 محادثة خاصة بين الوكلاء قابلة للقراءة بهذه الطريقة، وأكدت أنها تستطيع أيضًا إعادة كتابة منشورات مباشرة. وتصنف الحادثة كحادثة بيانات اعتماد بالغة الخطورة بتاريخ محدد بدقة اليوم هو 31 يناير 2026، ودرجة ثقة A، وضرر فعلي موثق، إلى جانب بقية سجلات البنية التحتية للوكلاء في Orca AI Incident Archive.

لم يكن المفتاح هو السر قط

Supabase هي خدمة Postgres مستضافة مزوّدة بواجهة REST API يصفها Wiz بأنها شائعة لدى التطبيقات المبرمجة بأسلوب vibe-coded لأن إعدادها سهل. صُمم مفتاحها القابل للنشر ليكون موجودًا في الشيفرة على جانب العميل: فهو يحدد المشروع، ومن المفترض أن يأتي التحكم في الوصول من سياسات Row Level Security على الجداول التي تقف خلفه. ويؤكد Gal Nagli من Wiz هذه النقطة صراحةً في التقرير: إن كشف المفتاح "لا يشير تلقائيًا إلى وجود خلل أمني"، وعندما تُضبط RLS بشكل صحيح فإن "مفتاح API العام آمن للكشف عنه - فهو يعمل مثل معرّف المشروع". وفي تطبيق Moltbook، يكتب Wiz: "كان هذا الخط الدفاعي الحاسم غائبًا".

كانت الآلية عبارة عن حزمة. ووفقًا لـ Wiz، احتوى ملف JavaScript الإنتاجي على moltbook.com/_next/static/chunks/18e24eafc444b2b9.js على عنوان مشروع Supabase، ehxbxtjliybbloantpwq.supabase.co، والمفتاح، sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. ثم أرسل Wiz طلبًا إلى جدول agents يطلب ثلاثة أسماء ومفاتيح API، وهو استعلام كان ينبغي أن يعيد مصفوفة فارغة أو خطأ تفويض. لكنه أعاد صفوفًا بدلًا من ذلك، بما في ذلك رموز المصادقة الخاصة بأكثر وكلاء المنصة شعبية. ومن هناك، رسم Wiz المخطط باستخدام رسائل خطأ PostgREST واستبطان GraphQL، وأحصى نحو 4.75 مليون سجل مكشوف.

يقول ملخص الأرشيف إن Moltbook «لم تُفعّل قط» Row Level Security، لكن المصادر أقل حسمًا من ذلك. لا يُظهر أيٌّ منهما سجل إعدادات، لذا فالمُوثَّق هو أن RLS لم تكن سارية أثناء المراجعة: فقد وجد Wiz الجداول مفتوحة، ويكتب Implicator.ai، نقلًا عن رواية مَن اكتشف الأمر، أن Moltbook «لم تُشغّل RLS قط. أو إن فعلت، فلم تُهيَّأ أي سياسات». إن كون الإعداد لم يُفعّل قط أو فُعّل دون وجود سياسات ليس مما تثبته أيٌّ من الروايتين، والنتيجة العملية واحدة.

ما الذي كان موجودًا فعليًا في الجداول

يذكر Wiz أسماء الجداول ومحتوياتها. كان جدول agents يحتوي، في كل صف، على api_key الذي كان يصادق على الوكيل، وclaim_token المستخدم للمطالبة بملكيته، وverification_code الصادر عند التسجيل، وعدّي الكارما والمتابعين الخاصين بالوكيل. هذه عدة كاملة لاختطاف الحساب وليست تسريبًا للبيانات: فباستخدام أحد تلك المفاتيح، يمكن لطلب أن ينشر ويرسل رسائل ويتصرف بطرق أخرى بصفته ذلك الوكيل، ويلاحظ Wiz أن هذا شمل حسابات ذات كارما عالية ووكلاء شخصيات معروفين.

احتوى جدول owners على معلومات شخصية لأكثر من 17,000 مستخدم، بما في ذلك عناوين البريد الإلكتروني ومعرّف X واسم العرض الخاص بكل وكيل. واحتوى جدول آخر اكتشفته Wiz لاحقًا عبر نقطة نهاية GraphQL، يُسمى observers، على 29,631 عنوان بريد إلكتروني إضافي تخص التسجيلات ذات الوصول المبكر إلى منتج Moltbook المخطط "Build Apps for AI Agents". واحتوى جدول agent_messages على 4,060 محادثة مباشرة خاصة بين الوكلاء، مخزنة دون تشفير أو ضوابط وصول، وتفيد Wiz بأن بعضها احتوى على بيانات اعتماد جهات خارجية بنص صريح، بما في ذلك مفاتيح OpenAI API التي تشاركها الوكلاء مع بعضهم البعض.

النسبة بين الوكلاء والبشر هي الجزء الذي قوّض الرواية العامة للمنصة. تُبلغ Wiz عن 1.5 مليون وكيل مسجل مقابل نحو 17,000 مالك بشري، أي نحو 88 وكيلًا لكل شخص، وتعزو هذه الفجوة إلى غياب تحديد معدل الطلبات أو التحقق من الهوية: فقد كان بإمكان أي شخص تسجيل وكلاء في حلقة تكرار، وكان بإمكان إنسان أن ينشر بصفته "وكيلًا" عبر طلب POST أساسي. استنتاج Wiz صريح - "شبكة التواصل الاجتماعي الثورية للذكاء الاصطناعي كانت في الغالب بشرًا يشغّلون أساطيل من الروبوتات."

عدد عناوين البريد الإلكتروني لا يتطابق بشكل نظيف، ولا يوضح Wiz السبب. رقمه الرئيسي هو 35,000 عنوان بريد إلكتروني؛ أما أعداد الجداول الخاصة به فهي أكثر من 17,000 بريد إلكتروني للمالكين و29,631 بريدًا إلكترونيًا للمراقبين، وهما يجمعان إلى نحو 46,600. كلا الرقمين مأخوذان من Wiz، ولم يحدد هذا المقال كيف جرى اشتقاق 35,000 - سواء عبر إزالة التكرار بين الجدولين أو من لقطة سُجلت قبل العثور على جدول المراقبين.

النصف الخاص بالكتابة من التعرض

لم تكن قراءة البيانات هي كامل الاكتشاف. تُفيد Wiz أنه حتى بعد أن حجبت الجولة الأولى من الإصلاحات وصول القراءة إلى الجداول الحساسة، ظل وصول الكتابة إلى الجداول العامة مفتوحًا. اختبرت ذلك بإرسال طلب PATCH إلى منشور مباشر واستبدال عنوانه ونصه بالسلسلة "@galnagli - responsible disclosure test"، ثم تأكدت من أن التعديل كان مرئيًا على الموقع. بعد تطبيق قيد الكتابة، لم تعد Wiz قادرة على التراجع عن منشور الاختبار الخاص بها؛ وتكتب Wiz أن فريق Moltbook حذف المحتوى بعد بضع ساعات، وشكر الباحثين على التقرير.

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

ثلاث ساعات واثنتا عشرة دقيقة، وأربعة إصلاحات منفصلة

يبدأ الجدول الزمني لإفصاح Wiz عند الساعة 21:48 UTC من يوم 31 يناير 2026، بcontact أولي مع مشرف Moltbook عبر رسالة مباشرة على X، وينتهي عند الساعة 01:00 UTC من يوم 1 فبراير، عندما تم تأمين آخر الجداول المكشوفة. وبعد ذلك الاتصال الأول، يسجّل سبع خطوات إضافية: التقرير عند 22:06، وإصلاح أول عند 23:29 يغطي جداول agents وowners وsite_admins، وإصلاح ثانٍ عند 00:13 يغطي agent_messages وnotifications وvotes وfollows، واكتشاف مسار الكتابة عند 00:31، والإصلاح الثالث الذي يغلقه عند 00:44، واكتشاف جداول observers وidentity_verifications وdeveloper_apps عند 00:50، والإصلاح النهائي عند 01:00.

هذا الجدول الزمني هو أقوى حجة ضد أبسط نسخة من هذه القصة. يصف Implicator.ai الإصلاح بعبارتَي SQL - ويكتب أن "الإصلاح تطلب عبارتَي SQL. لم تكونا موجودتين"، ويحمل ملخص الأرشيف نفس صياغة "سطرَي SQL". ربما كان الإصلاح الأساسي لانكشاف القراءة بهذا الصغر: تمكين RLS وإضافة سياسات على الجداول. لكن سجل Wiz نفسه يُظهر أربعة إصلاحات على مدى ثلاث ساعات، وثغرة وصول كتابة ثانية منفصلة لم يسدّها إصلاح القراءة، وثلاثة جداول أخرى - بما فيها عناوين المراقبين البالغة 29,631 - لم تظهر إلا بعد الجولتين الأوليين. درس Wiz الختامي هو أنه "عمل مع الفريق عبر جولات متعددة من المعالجة، مع كشف كل تكرار عن أسطح مكشوفة إضافية." تصف نسخة السطرين تغيير التكوين، لا المعالجة.

اكتشافان، واختلاف في السجل

يُنسب هذا الاكتشاف عادةً إلى جيميسون أو رايلي، مؤسس شركة الأمن الأسترالية Dvuln، الذي عرض الاستيلاء على الحساب على 404 Media؛ ويذكر Implicator.ai أن 404 Media تحققت من القدرة عبر تحديث حساب أو رايلي نفسه على Moltbook بإذنه. منشور Wiz بقلم غال ناغلي ويتضمن ملاحظة في نهايته تُنسب الفضل إلى أو رايلي: "اكتشف الباحث الأمني جيمسون أو رايلي أيضًا سوء التكوين الكامن في Supabase، وقد أوردت ذلك 404 Media." وتضيف الملاحظة أن منشور Wiz يشارك اكتشافًا مستقلًا للمشكلة نفسها.

يصف ملخص الأرشيف كليهما بأنهما باحثان في Wiz. أما منشور Wiz نفسه فلا: إذ يسمّي Nagli مؤلفًا له، ويصف O'Reilly بأنه باحث مستقل نقل 404 Media اكتشافه، وتنسب Implicator.ai O'Reilly إلى Dvuln. كما أن التهجئة غير مستقرة بين المصادر - فـWiz تكتب "Jameson"، بينما يدرج موقع Dvuln نفسه مؤسسه باسم "Jamieson" - وقد استخدم هذا المقال التهجئة التي يستخدمها ذلك الموقع. وما لا خلاف عليه هو أنه كان هناك اكتشافان مستقلان لنفس سوء التكوين خلال أيام.

يختلف سرد الرد باختلاف المصدر، والاختلاف جدير بالإبلاغ لا بالحسم. فوفق سرد O'Reilly، الذي نقله Implicator.ai، توجه إلى شليخت مباشرة وعرض المساعدة في ترقيع العيب؛ وكان الرد: "سأسلّم كل شيء للذكاء الاصطناعي. لذا أرسل لي كل ما لديك." ثم مرّ يوم كامل دون متابعة، وفق ذلك السرد، ولم يرد شليخت على طلب 404 Media للتعليق. أما Wiz، التي تواصلت مع المشرف بشكل منفصل، فتسجّل تقريرها المقدّم عند 22:06 UTC وآخر إصلاح من أربعة عند 01:00 UTC، أي بعد ثلاث ساعات واثنتي عشرة دقيقة من أول تواصل. يجري الجدولان الزمنيان عبر قناتين مختلفتين، ولا يقول أي من المصدرين ما إذا كان أحدهما قد حفّز الآخر؛ ويمكن أن يكون كلاهما دقيقًا.

ما يثبته السجل، وما لا يثبته

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

ما لم يثبت يبدأ بالوصول المسبق. وتؤكد Wiz أن جميع البيانات التي جرى الوصول إليها أثناء بحثها والتحقق من الإصلاح قد حُذفت، وهذا لا يقول شيئًا عن أي شخص آخر. ويضع Implicator.ai الفجوة بوضوح: لا أحد يستطيع أن يحدد ما إذا كان شخص ما قد وجد قاعدة البيانات قبل O'Reilly، أو كم من المنشورات التي انتشرت خلال أسبوع انتشار المنصة الواسع كانت مخرجات أصلية للوكيل وكم منها جاء من مفتاح مسروق. لا يذكر أي مصدر قُرئ من أجل هذا المقال إساءة استخدام مؤكدة لأي بيانات اعتماد مكشوفة، ولا يذكر أي منها عدد الحسابات التي جرى الاستيلاء عليها فعليًا. إن علامة real_harm في الأرشيف صحيحة لأن البيانات الشخصية وبيانات الاعتماد الحية لجهات خارجية كانت قابلة للقراءة فعليًا من قبل أي شخص، وليس لأن إساءة استخدام محددة قد سُجلت.

تختلف أعداد الوكلاء أيضًا، ويتماشى هذا الاختلاف مع نمو المنصة لا مع وقائع التعرض. يصف Implicator.ai، في مقال كُتب في 1 فبراير من حساب المكتشف، "أكثر من 32,000" وكيل مسجل — في مقال يقول أيضًا إن الموقع تجاوز 37,000 في أسبوعه الأول — و1.49 مليون سجل مكشوف. وأحصى Wiz، عند مراجعته في 2 فبراير، 1.5 مليون وكيل وما يقرب من 4.75 مليون سجل. ويسجل ملخص الأرشيف أن المنصة جمعت في النهاية 1.7 مليون وكيل مسجل وما يقرب من 7 ملايين تعليق؛ ولم يتحقق هذا المقال بشكل مستقل من أي من الإجماليين النهائيين. الرقم الوحيد الذي تدعمه جميع الروايات هو شكل الأمر: وكلاء أكثر بكثير من البشر، ولا توجد آلية يمكنها التمييز بينهم.

ما الذي تغيّر، وما الذي لم يُصلحه الإعداد

ما تغيّر محدود وموثّق: سياسات RLS على الجداول الحساسة، وقيود على الكتابة في الجداول العامة، وحذف منشور الاختبار الخاص بالباحثين، ووفقًا لـ Wiz، منصة جرى ترقيعها بالكامل بحلول الساعة 01:00 بالتوقيت العالمي المنسق في 1 فبراير. ولا يصف أي شيء في المصادر التي قرأتُها لهذا المقال أن Moltbook أضافت تحديدًا لمعدل الطلبات، أو التحقق من هوية الوكلاء، أو تدقيقًا للمحتوى المكتوب خلال تلك الفترة. وتوصيات Wiz موجّهة إلى الأدوات لا إلى المنصة - فمساعدات الذكاء الاصطناعي التي تولّد الواجهات الخلفية لـ Supabase يمكنها تفعيل RLS افتراضيًا، ويمكن لمنصات النشر فحص بيانات الاعتماد المكشوفة والإعدادات غير الآمنة.

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