wp2shell: ثغرة تنفيذ أوامر عن بُعد (RCE) في WordPress قياسي، اكتُشفت خلال عشر ساعات مقابل 25 دولارًا

في 17 يوليو 2026، نشرت Searchlight Cyber سلسلة wp2shell، وهي سلسلة تنفيذ شيفرة عن بُعد قبل المصادقة في نواة WordPress لا تحتاج إلى أي إضافة أو قالب أو تسجيل دخول. ويكفي طلب مجهول الهوية ضد تثبيت قياسي: "ليس للهجوم أي شروط مسبقة ويمكن أن يستغله مستخدم مجهول الهوية في تثبيت قياسي من WordPress بلا إضافات"، حسبما تذكر استشارة الشركة. وتجمع السلسلة بين ثغرتين — CVE-2026-63030، وهو خلل التباس في المسارات ضمن نقطة نهاية الدفعات في WordPress REST API، وتصفه استشارة المشروع بالحرج، وCVE-2026-60137، وهو حقن SQL في author__not_in معامل WP_Query وتصفه استشارة المشروع بالمتوسط. أصدر WordPress الإصدار WordPress 7.0.2 في اليوم نفسه، وتُدرج استشارات المشروع كلاً من WordPress 6.9.5 وWordPress 6.8.6 وWordPress 7.1 beta2 على أنها تحمل الإصلاحات نفسها. وتستشهد Searchlight بتقديرات تفيد بوجود أكثر من 500 مليون موقع WordPress. ويقول الباحث وراء السلسلة، Adam Kues، إنها جاءت من تشغيل GPT-5.6 Sol Ultra بُني على مطالبة نشرتها OpenAI لمسألة رياضيات: بما يصل إلى أربعة وكلاء، وست ساعات على الأقل في البحث ونحو أربع ساعات إضافية في التصعيد، بما يقارب 25 دولارًا من استخدام النموذج. وتُسجَّل الواقعة كنتيجة بحثية — خطورة عالية وفق مقياس الأرشيف نفسه، وثقة من الدرجة A، ولا ضرر واقعي مسجل، ومؤرخة ليوم واحد — وthe Orca AI Incident Archive يوردها مع الوثائق الأولية المرتبطة أسفلها.

كان الإفصاح منسّقًا. امتنعت Searchlight عن نشر تفاصيل الآلية في {{1}}17 يوليو{{/1}} ومنحت المدافعين عطلة نهاية الأسبوع للترقية؛ ونشر Kues التقرير التقني الكامل في {{2}}20 يوليو{{/2}}. وبحلول ذلك الحين، كان الاستغلال المتسلسل قد أُعيد إنتاجه بشكل مستقل بالفعل: تقول Searchlight إن Calif وHacktron أعادا بناء السلسلة الكاملة قبل أن تظهر إثباتات مفهوم أخرى على GitHub. وتذكر استشارتا WordPress الأمنيتان نفس الإصدارات المُصلحة، وأضافت CISA كلتا الثغرتين المعنيتين بـCVE إلى كتالوجها Known Exploited Vulnerabilities في {{3}}21 يوليو{{/3}}.

خطأان برمجيان، والمصفوفات التي تخرج عن التزامن

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

تُقسّم واجهة برمجة التطبيقات للدفعات خط المعالجة إلى مرحلتين، فتُتحقق من كل طلب فرعي في حلقة واحدة وتُنفّذه في حلقة ثانية، وتحتفظ بمصفوفتين، $matches و$validation، يُفترض أن تتطابق عناصرهما عنصرًا بعنصر حسب الفهرس. في class-wp-rest-server.php، كما يصفه Kues، يُضاف الطلب الفرعي الذي هو نفسه خطأ WordPress إلى $validation ثم يصطدم بـ continue، متجاوزًا السطر الذي يضيف إلى $matches. من تلك النقطة، تنزاح كل مطابقة موضعًا واحدًا إلى الخلف. تقرن حلقة التنفيذ الطلب الفرعي عند فهرس ما بالتحقق المسجّل عند ذلك الفهرس، لكن المعالج المطابق يكون لمسار مختلف — لذا يُفحص المعامل وفق قواعد نقطة نهاية واحدة ثم يُنفّذه رمز نقطة نهاية أخرى.

هذا ما يحوّل معامل قائمة يبدو عاديًا إلى حقن. تربط مسار مجموعة المقالات معاملَه العام author_exclude بـ author__not_in. عندما تكون القيمة مصفوفة، يشغّل WordPress absint على كل عنصر ويرتبها؛ وعندما تكون القيمة مفردة، تُدمج كما هي دون معالجة في جزء SQL الذي يصبح NOT IN ($author__not_in). لذلك يستقر نص مثل 0) OR 1=1 -- في نص الاستعلام. عند الاستدعاء العادي كان المسار سيرفضه، لأن author_exclude يجب أن يكون مصفوفة من الأعداد الصحيحة؛ أما استدعاء الدفعة غير المتزامن فهو ما يسمح بمرور نص.

بقيت عقبتان، وحُلّت كلتاهما بتعشيش الحيلة. ترفض واجهة برمجة تطبيقات الدُفعات طلبات GET، ويقع الحقن في مسار GET؛ كما أن التحقق من طريقة الطلب نفسه مُنفَّذ كتحقق من المعاملات، وهو ما يمكن لنفس اختلال التزامن تجاوزه. ترسل الحمولة المنشورة لـ Kues طلبًا فرعيًا خارجيًا مشوَّهًا لإحداث اختلال في تزامن فحص الطريقة، ثم دفعة داخلية تحمل طلبها الفرعي الثاني القيمة الخبيثة author_exclude ضد معالج لا يتحقق منها، ثم طلب GET الذي ينفّذ ذلك. ويعيد حقن قائم على UNION قيمًا اعتباطية من قاعدة البيانات داخل صفوف على هيئة منشورات عادية.

تشغيل النموذج: مطالبة رياضية، موجّهة إلى قاعدة شيفرة

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

كان الإعداد ضيّقًا عمدًا. استنسخ أحدث إصدار مستقر من WordPress إلى دليل يُسمى main/ وحذف دليله .git، وأخبر النموذج ألا يستخدم سجلات التغييرات أو تاريخ git أو الإنترنت المفتوح لمقارنة الكود بنسخة مصحّحة — وكان سببه المعلن أن الرجوع إلى التاريخ أو الويب عند اكتشاف ثغرات جديدة إهدار للتوكنات. وقُدِّم دليل third_party/ فارغًا حتى يتمكن النموذج من استنساخ تبعيات مثل مصدر PHP أو MySQL إذا رأى أن السلسلة تحتاج إلى ثغرات في المكتبات الواقعة أسفل WordPress. حُدِّدت المهمة بأنها RCE قبل المصادقة في بيئة إنتاج نموذجية على MySQL، مع ما يصل إلى أربعة وكلاء وست ساعات على الأقل. كتب Kues أنه يصرّح بمتطلب الإعداد لأن النماذج بخلاف ذلك "تغش" — باختيار خيارات إعداد غير مرجحة للغاية، أو باختلاق شروط مسبقة لا يستطيع مهاجم تحقيقها أبدًا.

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

تقديره الخاص للتكلفة: 50% من حصة استخدام أسبوعية، قدّرها بنحو 25 دولارًا بالتناسب على اشتراك بقيمة 200 دولار، مقابل استغلال أُنتج في ما يزيد قليلًا على عشر ساعات. ولم يكن الجانب البشري مجانيًا — فقد أمضى Kues اليوم التالي في تفكيك ما فعله النموذج، وكتب أن عمل ما بعد الاستغلال استغرق منه وقتًا أطول بكثير لفهمه مما استغرقه توليده. وحكمه صريح على نحو غير معتاد ومحدود النطاق: "لا أقدم أي ادعاءات عامة، لكنني أستطيع أن أقول بثقة تامة إنه ما كان لأي باحث أمني أن يعثر على سلسلة الاستغلال هذه ويكملها في 10 ساعات دون الذكاء الاصطناعي."

من SELECT للقراءة فقط إلى مسؤول

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

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

ثانيًا، حوّل المنشورات الملفّقة إلى صفوف حقيقية. تخزّن ميزة التضمين في WordPress التضمينات المحلولة مؤقتًا في قاعدة البيانات كمنشورات من النوع oembed_cache. إن تضمين منشور محلي عبر مسار نسبي، كما في [embed]/?p=S[/embed]، يجعل WordPress يتخطّى جلب HTTP ولا يتحقق أبدًا من وجود المنشور المشار إليه، لذا يُنشأ صف. ثلاثة تضمينات كهذه برموز مختلفة في سلسلة الاستعلام تنتج ثلاث تجزئات تخزين مؤقت مختلفة، وهكذا يحصل المهاجم على عدة صفوف للعمل بها.

ثالثًا، الالتفاف حول الحقل الوحيد الذي يبقى ثابتًا. عندما تختلف نسختا المنشور في الذاكرة وقاعدة البيانات، يوائم WordPress بينهما عبر استدعاء يعيّن صراحةً post_content من ناتج التضمين. كل ما يتعلق بالمنشور يتحكم فيه المهاجم باستثناء محتواه، وهو بالتحديد الحقل الذي customize_changesetيستخدمه لتخزين JSON الخاص بتغييرات القالب والموقع المعلّقة.

رابعًا، أداة الحلقة.لل منشورات آباء، ويرفض ووردبريس الحلقات: wp_insert_post_parent عامل التصفية يصعد في الشجرة، وعند العثور على حلقة، يستدعي تحديثًا يضبط post_parent على صفر. لا يستبدل ذلك الاستدعاء post_content، لذا تنجو النسخة المُصنّعة في الذاكرة من المطابقة — مجموعة تغييرات، مع بقاء JSON الخاص بها سليمًا، مدعومة بصف حقيقي.

خامسًا، استعارة سلطة المسؤول. تُطبَّق فورًا مجموعة تغييرات تقول حالتها إنها مجدولة للمستقبل لكن تاريخها في الماضي. كل إدخال في JSON الخاص بها يسمّي user_id، ويسمّي الإدخال في سلسلة Kues user_id 1، وهو المسؤول، لذا يتبنّى WordPress تلك الهوية مؤقتًا لتطبيق التغيير. التغيير الأول هو تحديث يبدو بريئًا لـ nav_menus_created_posts.

سادسًا، أعد إرسال الطلب بهذه الهوية. يؤدي نشر منشور إلى إطلاق إجراء يحمل اسمًا ديناميكيًا، {status}_{post_type}. ولأن المنشور مُلفَّق، يمكن أن تكون تلك الحالة والنوع أي شيء — بما في ذلك parse وrequest، مما يُنتج خطاف parse_request ويعيد تشغيل خط أنابيب الطلب من البداية بينما لا تزال هوية المسؤول المستعارة سارية. احتوى طلب الدفعة الأصلي على طلب فرعي يُنشئ مسؤولًا جديدًا؛ فشل في المرور الأول بصفته ضيفًا ونجح عند الإعادة. ومن هناك، يسجّل المهاجم الدخول بهذا الحساب الجديد ويرفع إضافة باب خلفي من ملف ZIP، وهو ما يعني تنفيذ التعليمات البرمجية.

تتعلق بهذه التقنية حالةٌ مشروطة. وقد ذكرت Hacker News، نقلًا عن Cloudflare، أن CVE-2026-63030 لا يُفضي إلى تنفيذ شيفرة عن بُعد إلا عندما لا تكون ذاكرة تخزين مؤقت دائمة للكائنات قيد الاستخدام؛ فالحقن نفسه موجود منذ WordPress 6.8، بينما تحتاج السلسلة الكاملة إلى 6.9 أو إصدار أحدث. ولا يتضمن التثبيت الافتراضي ذاكرة تخزين مؤقت دائمة للكائنات، ولهذا فإن عبارة Searchlight «بلا شروط مسبقة» وتقييد Cloudflare يصفان الحالة الافتراضية نفسها من زاويتين مختلفتين.

ما تُثبته الوثائق الأساسية

تُعدّ النشرات الأمنية الصادرة عن WordPress نفسها أقوى تأكيد، لأنها تمثّل اعتراف المورّد بآلية المشكلة وإصداره للإصلاح. تصف GHSA-ff9f-jf42-662q، المصنّفة بالحرجة، ضعفًا يتمثل في الارتباك في مسار الدفعات عبر REST API في WordPress 6.9 وما فوق، ويتحد مع ثغرة الحقن للوصول إلى تنفيذ الشيفرة، وتنسبه إلى Adam Kues في Assetnote وSearchlight Cyber. تصف GHSA-fpp7-x2x2-2mjf، المصنّفة متوسطة، ثغرة الحقن author__not_in في WordPress 6.8 وما فوق، وتذكر أن كلتا المشكلتين تم إصلاحهما في WordPress 7.0.2 وWordPress 6.9.5 وWordPress 6.8.6 وWordPress 7.1 beta2. تحمل سجلات NVD للثغرتين، وقد قيّمها WPScan بصفته CNA وليس NIST، الدرجة 9.8 لـ CVE-2026-63030 مع المتجه AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H، والدرجة 5.9 لـ CVE-2026-60137 مع AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — ثغرة يمكن الوصول إليها عبر الشبكة ولا تتطلب صلاحيات في الحالة الأولى، وثغرة تتطلب تعقيدًا عاليًا في الهجوم ولا ينتج عنها سوى تأثير على السرية في الحالة الثانية. يشير حقل الخطورة الخاص بهذا المدخل في الأرشيف إلى «عالية» بينما تصنّف WordPress ثغرة الدفعات بأنها «حرجة»؛ وهما مقياسان منفصلان يُطبّقان على سلسلة كاملة وعلى مكوّن واحد، وليسا خلافًا حول الثغرات نفسها.

أُضيفت إدخالات كتالوج CISA، كما هي منعكسة في حقول إثراء NVD، في 21 يوليو 2026، مع مواعيد نهائية للمعالجة هي 24 يوليو لـ CVE-2026-63030 و4 أغسطس لـ CVE-2026-60137. وتسمّي CISA الأولى «WordPress Core Interpretation Conflict Vulnerability» والثانية «WordPress Core SQL Injection Vulnerability». كما نشرت Searchlight أداة فحص عامة على wp2shell.com كي يتمكن المشغّلون من اختبار نسخة ما دون انتظار توقيع ماسح ضوئي.

إن إعادة الإنتاج المستقلة موثّقة من Searchlight نفسها، ومن ثم فهي ادعاء يخص أطرافًا ثالثة لا رواية من طرف ثالث: فقد أعاد Calif وHacktron بناء السلسلة الكاملة قبل ظهور نماذج إثبات مفهوم أخرى على GitHub، وفقًا لتقرير 20 يوليو. وما يمكن التحقق منه بشكل مستقل هو الأثر — نماذج إثبات المفهوم وحركة الاستغلال وبيانات التليمترية الخاصة بالمورّد خلال أيام، الواردة أدناه.

ما الذي يُزعم لكنه غير مُثبت؟

لا يمكن التوفيق بين نسبتَي الفضل لحقن واحد في السجل العام. ينص الإشعار الأمني لـ WordPress بشأن CVE-2026-60137 على أن العيب «اكتُشف وأُفصح عنه بمسؤولية كفريق من قبل TF1T وdtro وhaongo». وتعرض رواية Searchlight الحقن نفسه قبل المصادقة بوصفه ما أظهره تشغيل نموذجها، ولا تذكر ذلك الفريق؛ بينما ينسب إشعار WordPress إلى Kues الفضل فقط في الخلط المرتبط بمسار الدفعات، ولا يذكر أي نموذج. ولا تفسر أي من الوثيقتين هذا التداخل، ولا شيء مما عثر عليه هذا المقال يحسم الأمر — فاحتمال أن يكون الاثنان اكتشافين مستقلين للعيب نفسه غير مستبعد، واحتمال أن يكون أحد التقريرين إعادة اكتشاف لاحقة غير مثبت أيضًا. ولا يحسم السجل الأمر، ولا يحسمه هذا المقال.

الرقم الوارد في عنوان منشور Searchlight بتاريخ 20 يوليو لا يدعمه متن المقال نفسه. وهو يقول: «يدفع وسطاء استغلال الثغرات 500,000 دولار مقابل ثغرة RCE في WordPress. وجدت واحدة باستخدام GPT5.6 Sol Ultra مقابل 25 دولارًا». يوثّق متن المقال مبلغ 25 دولارًا والعشر ساعات بعبارات محددة؛ ولا يتضمن أسماء وسطاء، ولا عروضًا، ولا مراسلات، ولا مصدرًا لرقم 500,000 دولار. ولم يُعثر على أي تقرير مستقل خاص بهذا المقال يؤكد سعرًا دُفع أو عُرض مقابل wp2shell. اقرأ مبلغ 500,000 دولار على أنه تأطير العنوان، لا كسعر سوقي مستقر.

نطاق إدخال الأرشيف نفسه أضيق من القصة المحيطة به. فهو يسجّل نتيجة بحث في يوم الإفصاح، ولا يشير إلى أي ضرر في العالم الواقعي، ومؤرّخ ليوم واحد، 17 يوليو 2026. وهذا ليس ادعاءً بأن شيئًا لم يحدث بعده: فقد أُبلغ عن حركة استغلال خلال ساعات من التنبيه الأمني، وأدرجت CISA كلا الثغرتين CVE بعد أربعة أيام. ويغطي المؤشر ما يصفه الإدخال — الاكتشاف والإفصاح المنسّق — بينما يوثّق أطراف آخرون الاستغلال اللاحق بأدلتهم الخاصة، أدناه.

الاستغلال بعد النشرة الأمنية

قال جيك نوت، الباحث الأمني الرئيسي في watchTowr، لـ The Hacker News إنه "بحلول الساعات الأولى من صباح يوم السبت (UTC)، كان الاستغلال الناجح قد بدأ بالفعل على قدم وساق، إذ استُخدمت في البداية شيفرة استغلال متاحة للعموم لتسريب بيانات اعتماد مُجزأة، ثم تلا ذلك تنفيذ شيفرة عن بُعد بعد أن أصبحت تفاصيل إضافية متاحة للعموم". ويستشهد التقرير نفسه ببيانات القياس عن بُعد من KEVIntel التي تربط 13 عنوان IP فريدًا، من سويسرا وألمانيا والمملكة المتحدة وإندونيسيا وليتوانيا وهولندا وسنغافورة، باستغلال CVE-2026-63030، وينقل عن مؤسس KEVIntel، ريان ديوهرست، قوله إن الطلبات طابقت نماذج إثبات مفهوم متاحة للعموم، وإنه استُخدمت جميعًا حمولات عمياء وحمولات قائمة على UNION وحمولات قائمة على القيم المنطقية.

قدّم باحثا Wiz شاهار دورفمان وجيلي تيكوتشينسكي، في مقال نُشر في 20 يوليو، أرقامًا تُظهر حجم ذلك: إذ كان لدى 60% من المؤسسات التي تستخدم WordPress نسخة واحدة على الأقل قابلة للاستغلال عند نشر ثغرات CVEs، وكانت 25% منها تعرّض خادمًا قابلًا للاستغلال للإنترنت، ثم انخفضت النسبتان إلى 50% و10% خلال 24 ساعة مع بدء الترقيع. وقد سجّلوا عمليات رفع إضافات خبيثة عبر مثبّت لوحة الإدارة، وتعداد المستخدمين ضد نقطة نهاية users، ومحاولات تضمين ملفات محلية ضد wp-config، ووصولًا إلى لوحة الإدارة يعيد HTTP 200 — وهو بصمة تسجيل دخول ناجح لا مجرد فحص. أما البرمجيات الخبيثة التي وجدوها فامتدت من باب خلفي PHP بسيط من سطر واحد إلى webshell بحجم 150 KB متنكّر في هيئة إضافة أمان شرعية لـ WordPress تُسمى CMSmap، مع وحدات لإدارة الملفات والوصول إلى قواعد البيانات ومسح المنافذ وتصعيد الصلاحيات.

سجّلت Wiz أيضًا حدًا لما يمكن استنتاجه. كان الفحص عالي الحجم دون مرحلة ما بعد الاستغلال أمرًا شائعًا، بما يتسق مع الفحص الجماعي الانتهازي ومع الفحص الأمني المشروع، وذكرت الشركة أنها لم تحدد حركة جانبية أو تسريبًا للبيانات. وهذا بيان عمّا أظهرته بيانات القياس عن بُعد لدى أحد الموردين، وليس استنتاجًا بعدم أخذ أي شيء.

ما الذي تغيّر بعد ذلك، وما الذي بقي مفتوحًا؟

بالنسبة إلى المشغّلين، كان مسار الاستجابة قصيرًا. يكمن الحل في التحديث إلى WordPress 7.0.2 أو WordPress 6.9.5 أو WordPress 6.8.6. أما البدائل الطارئة التي طرحتها Searchlight للمواقع التي لم تتمكن من التحديث فورًا، فتمثلت في حظر الوصول المجهول إلى واجهة برمجة تطبيقات الدفعات — إما بتثبيت إضافة تحظر الوصول المجهول إلى REST API بالكامل، أو عبر حظر /wp-json/batch/v1 و?rest_route=/batch/v1 على جدار حماية تطبيقات الويب. وحذّرت الشركة من أن كلاهما قد يؤثر في الاستخدام المشروع للموقع، وينبغي التعامل معهما كتدبيرين مؤقتين إلى حين تطبيق التحديث. ويختبر الفاحص العام على wp2shell.com مثيلًا مباشرةً. وأضافت إدخالات كتالوج CISA مهلة امتثال: المعالجة بحلول 24 يوليو لـ CVE-2026-63030 وبحلول 4 أغسطس لـ CVE-2026-60137.

بالنسبة لسؤال البحث، فإن الجزء الذي لم يُحسم هو ما ساهم به النموذج فعليًا مقارنةً بمشغّله. كان كوس دقيقًا بشأن هذا التقسيم: فقد أنتج النموذج السلسلة في نحو عشر ساعات،而在 فهمها استغرق منه وقتًا أطول مما استغرقه توليدها. وهو يرفض الادعاءات العامة ويقول فقط إن نتيجة العشر ساعات لم يكن في متناول إنسان دون مساعدة. الموجّه نفسه ليس سرًا — فهو مستمد من موجّه نشرته OpenAI، وقد أعادت Searchlight إنتاج بنيته في التقرير، بما في ذلك تعليمات تجاهل سجل الإصدارات وشرط أن يعمل الاستغلال في إعداد إنتاجي نموذجي. أما ما إذا كانت هذه الوصفة تنتقل إلى قواعد برمجية أخرى، فهو بالضبط السؤال الذي يقول كوس إنه لا يجيب عنه، ولم يُنشر تشغيل ثانٍ.

إن ما يتركه السجل دون إثبات هو مسألة ضيقة النطاق لكنها ذات تبعات: أيّهما اكتشف الحقن أولاً من بين الطرفين اللذين نُسب إليهما الفضل، وهل دفع أي وسيط يوماً المبلغ الوارد في العنوان، وما الذي أخذته فعلاً، إن أخذت شيئاً، قواقع الويب (webshells) التي رصدتها Wiz من المواقع التي حطّت عليها. وفي ما يخص النقطة الأخيرة، فإن البيان العلني الوحيد هو بيان Wiz، مفاده أنها لم ترصد أي حركة جانبية أو تسريب للبيانات — وهو غياب للدليل من نقطة رصد واحدة، قُدِّم بوصفه كذلك.