ثغرة wp2shell في ووردبريس: تنفيذ أوامر عن بُعد بدون أي مصادقة

نظرة عامة

ملاحظة على درجة CVSS: هو مقياس معياري من 0 إلى 10 يقيس خطورة أي ثغرة أمنية بناءً على عوامل مثل سهولة الاستغلال وحجم الضرر المحتمل. أي رقم فوق 9 يصنَّف “حرج” (Critical) وهو أعلى تصنيف موجود.

آخر التحديثات

تحديث 21 تموز/يوليو 2026: تصاعد الاستغلال الفعلي للثغرة بشكل واسع بعد نشر كود الاستغلال العلني.

• شركة WatchTowr رصدت عبر أنظمة الفخ (Honeypots) الخاصة بها عشرات آلاف من محاولات الاستغلال، بدأت أغلبها باستهداف سرقة بيانات الاعتماد قبل التصعيد لتنفيذ أوامر كامل.
• بيانات استخباراتية من KEVIntel حدّدت 13 عنوان IP فريد من سويسرا، ألمانيا، بريطانيا، إندونيسيا، ليتوانيا، هولندا، وسنغافورة، مرتبطة تحديدًا باستغلال CVE-2026-63030.
• شركة Wiz (المملوكة لجوجل) أفادت إنه عند بداية رصد الثغرة، كان لدى 60% من المؤسسات المستخدمة لووردبريس نسخة واحدة معرَّضة على الأقل، وكان 25% منها يعرّض خادمًا معرَّضًا مباشرة على الإنترنت. هذه النسب انخفضت تدريجيًا مع تطبيق التحديثات.
• نشاط ما بعد الاستغلال الموثَّق يشمل: رفع إضافات (Plugins) خبيثة، تعداد حسابات المدراء، هجمات تضمين ملفات محلية (LFI) لسرقة بيانات اعتماد قاعدة البيانات، وويب شل بحجم 150 كيلوبايت متنكّر بشكل إضافة أمان اسمها CMSmap.
• وثّقت التحقيقات أكثر من 100 حساب مدير خلفي (Backdoor Admin Account) أُنشئت على مواقع مخترَقة، ومحاولة تثبيت أداة تحكم عن بُعد (RAT) تُدعى Overlord بحالة واحدة على الأقل.

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

ما القصة؟

في 17 تموز/يوليو 2026 أصدر فريق ووردبريس تصحيحًا عاجلًا لسلسلة من ثغرتين تحملان الرقمين CVE-2026-60137 وCVE-2026-63030. بمفردها، كل ثغرة محدودة الأثر نسبيًا. لكن مجتمعتين، تتحولان إلى تنفيذ أوامر عن بُعد لأي زائر لموقعك — بدون تسجيل دخول، وبدون أي صلاحيات على الإطلاق.

هذا النوع من الثغرات يستحق انتباهك حتى لو لم تكن تتعامل مباشرة مع كود ووردبريس، لأنه يوضح نمطًا شائعًا جدًا في عالم أمن التطبيقات: خطأ صغير وبسيط في معالجة نوع بيانات واحد (نص “string” بدل مصفوفة “array”) يمكن أن يفتح الباب أمام ثغرة أخرى غير مرتبطة به ظاهريًا، ليتشكّل معًا خطر أكبر بكثير من مجموع الجزأين.

الثغرة الأولى: حقن SQL في WP_Query

المشكلة موجودة في معامل author__not_in بكلاس WP_Query، وهو الكلاس المسؤول داخل ووردبريس عن بناء استعلامات قاعدة البيانات (أي الأسئلة التي يرسلها الموقع لقاعدة بياناته لجلب المحتوى). الكود يفترض أن القيمة الممرَّرة لهذا المعامل دائمًا مصفوفة (array) — أي قائمة من القيم — ويشغّل تحققًا أمنيًا مبنيًا بالكامل على هذا الافتراض.

المشكلة: إذا مرّرت له نصًا (string) عاديًا بدل مصفوفة، يتم تخطي ذلك التحقق بالكامل، وتدخل القيمة الخام يدًا بيد مباشرة إلى الاستعلام. حسب وصف الباحثين الأصليين:

“Hand it a string instead of an array and the check that expects an array is skipped, dropping the raw value into the query.” (مرّر له نصًا بدل مصفوفة، والتحقق الذي يتوقع مصفوفة يُتخطّى، فتسقط القيمة الخام مباشرة داخل الاستعلام.)

هذا هو التعريف الكلاسيكي لحقن SQL: بيانات مُدخَلة من المستخدم، دون أي تنقية أو تصفية، تصل إلى قاعدة البيانات كجزء حرفي من الاستعلام نفسه — ما يسمح لمهاجم بكتابة أوامر SQL خاصة به بدل البيانات المتوقعة.

الثغرة الثانية: التباس بمسارات REST API الدفعية

REST API هي الواجهة البرمجية التي يستخدمها ووردبريس (وأي موقع حديث تقريبًا) للسماح لتطبيقات وسكربتات خارجية بالتواصل معه — مثلًا تطبيق الجوال الذي يقرأ مقالاتك، أو إضافة تزامن تنشر محتوى تلقائيًا. نقطة النهاية (endpoint) الخاصة بهذه الثغرة هي /wp-json/batch/v1، وهي مصممة خصيصًا لتنفيذ عدة طلبات فرعية دفعة واحدة بدل إرسال كل طلب لوحده، وتعالج تلك الطلبات كمصفوفات متوازية (parallel arrays) داخليًا.

المشكلة هنا: إذا فشل أحد الطلبات الفرعية داخل الدفعة لأي سبب، تنزاح المصفوفات المتوازية عن بعضها بموضع واحد بالضبط. النتيجة، كما وصفها الباحثون:

“An error in one sub-request knocks the arrays out of step by one, so a request runs under a different request’s handler.” (خطأ في طلب فرعي واحد يُخرج المصفوفات عن التزامن بموضع واحد، فينتهي الأمر بطلب يُنفَّذ تحت معالج طلب آخر تمامًا.)

كيف تتحدان لتكوين RCE؟

هنا يكمن الخطر الفعلي. عبر تركيب طلب دفعي (batch request) بعناية بحيث يفشل أحد أجزائه عمدًا، يستطيع المهاجم استغلال ذلك الانزياح بالضبط لتجاوز قائمة السماح (allow-list) الخاصة بنقطة النهاية — وهي قائمة القيم المسموح بها عادة كخط دفاع أول. الباحثون وصفوا الأمر بدقة:

“Nested, that confusion walks past the endpoint’s allow-list and lands the attacker’s input in the vulnerable query, unauthenticated.” (متداخلةً، هذه الالتباسة تتجاوز قائمة السماح الخاصة بنقطة النهاية، وتُسقط مدخلات المهاجم داخل الاستعلام الضعيف، دون أي مصادقة.)

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

الهجوم يعمل على أي تنصيب افتراضي لووردبريس لا يستخدم تخزينًا مؤقتًا دائمًا للكائنات (persistent object caching) — وهي تقنية تُستخدم لتسريع المواقع الكبيرة عبر حفظ نتائج الاستعلامات المتكررة في الذاكرة بدل إعادة حسابها في كل مرة؛ أغلب مواقع ووردبريس الصغيرة والمتوسطة لا تفعّلها أصلًا، ما يعني أنها معرَّضة بشكل مباشر.

الإصدارات المتأثرة والإصلاح

أصدرت ووردبريس التصحيحات 6.9.5 و7.0.2 يوم الجمعة 17 تموز/يوليو 2026، وفعّلت آلية التحديث التلقائي الإجباري (forced auto-update) عبر نظام التحديثات المدمج بووردبريس. هذا يعني أن أغلب المواقع ستتصحح تلقائيًا خلال وقت قصير دون أي تدخل من مالكها — لكن لا تعتمد على ذلك وحده: بعض المواقع تعطّل التحديثات التلقائية عمدًا، وبعض الاستضافات تؤخّر تطبيقها. تحقق من إصدار موقعك يدويًا إن استطعت.

هل توجد أداة استغلال متاحة؟

نعم. اعتبارًا من 18 تموز/يوليو 2026، ظهر كود إثبات مفهوم (Proof-of-Concept) علني على GitHub. وكما لخّص الباحثون الوضع:

“The patch is public, and other researchers read it.” (التصحيح أصبح علنيًا، وباحثون آخرون قرأوه.)

هذه إشارة لظاهرة معروفة في عالم الثغرات تُسمّى استخراج ثغرات “1-day”: بمجرد نشر تصحيح رسمي لثغرة، يستطيع أي باحث (أو مهاجم) مقارنة الكود قبل وبعد التصحيح (diffing) لمعرفة بالضبط أين كانت المشكلة وكيف تُستغل — حتى لو لم يُنشر أي تفصيل تقني عن الثغرة نفسها في البداية. لهذا السبب فجوة الوقت بين نشر التصحيح وتطبيقه فعليًا على موقعك هي الفترة الأخطر.

بما أن كود الاستغلال أصبح متاحًا للعموم، يجب اعتبار خطر الاستغلال الفعلي مرتفعًا جدًا لأي موقع لم يُحدَّث بعد. لا يوجد حتى تاريخ نشر هذا المقال أي استغلال مؤكد مُدرَج في قائمة CISA KEV (قائمة الثغرات المستغَلة فعليًا والمعروفة لدى وكالة الأمن السيبراني الأمريكية).

كيف تحمي موقعك؟

إذا كان تحديث ووردبريس فورًا غير ممكن لأي سبب (توافق إضافات، قالب مخصص، إلخ)، هذه إجراءات مؤقتة يمكنك تطبيقها ريثما تُحدِّث:

• حجب /wp-json/batch/v1 (وكذلك أي طلب بصيغة rest_route=/batch/v1) على مستوى جدار الحماية (WAF).
• تعطيل REST API بالكامل إذا كان موقعك لا يعتمد عليه فعليًا لأي تطبيق أو إضافة خارجية.
• نشر إضافة صغيرة (drop-in plugin) ترفض أي طلب دفعي (batch request) غير مصادَق قبل وصوله لكود ووردبريس نفسه.

لكن هذه كلها حلول مؤقتة تقلّل المخاطرة، وليست بديلًا عن التحديث. الحل الحقيقي والوحيد الكامل هو التحديث لأحدث إصدار مصحَّح — 6.9.5 أو 7.0.2 حسب الفرع الذي تستخدمه — في أقرب فرصة ممكنة.

ملاحظات

• الخبر الأصلي نشرته الصحفية Swati Khandelwal على موقع The Hacker News بتاريخ 17 تموز/يوليو 2026، وحُدِّث بتاريخ 18 تموز/يوليو 2026 بعد ظهور كود الاستغلال العلني.
• قسم “آخر التحديثات” أعلاه أُضيف بتاريخ 21 تموز/يوليو 2026 بناءً على تقرير متابعة كتبه الصحفي Ravie Lakshmanan يوثّق تصاعد الاستغلال الفعلي — راجع رابط “تحديث الاستغلال” أسفل المصدر.
• الثغرة تصيب فقط النواة الأساسية لووردبريس (WordPress Core) — لا علاقة لها بإضافة أو قالب معيّن، وهذا ما يجعلها خطيرة على نطاق واسع جدًا يشمل كل المواقع التي تستخدم الإصدارات المذكورة، بغض النظر عن الإضافات المثبَّتة.
• فقط المواقع على الفرعين 6.9 و7.0 معرَّضة للسلسلة الكاملة (RCE). المواقع على الفرع 6.8 معرَّضة لحقن SQL فقط دون أن تتحول تلقائيًا إلى تنفيذ أوامر — لكنها تبقى تستحق التصحيح فورًا.

المصدر

المقال الأصلي: New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code

تحديث الاستغلال: WordPress wp2shell Exploitation Grows as Public Exploit Fuels Mass Scanning