فاحص ثغرات PHP2Shell عبر الإنترنت

أدخل عنوان موقع تملكه أو لديك إذن لاختباره. راجع مؤشرات PHP والإصدار واستجابات النماذج خطوة بخطوة لتقييم التعرض لـ PHP2Shell وتحديد إجراءات المعالجة.

2

ثغرات في نواة PHP

9.2

درجة CVSS v4.0 (حرجة)

4

الفروع الأصلية المصححة من 8.2 إلى 8.5

نظرة عامة على الثغرات

ما هو PHP2Shell ولماذا يتطلب فحصًا عاجلًا؟

يشير PHP2Shell إلى ثغرتين في أمان ذاكرة نواة PHP هما CVE-2026-109618 وCVE-2026-109619، بتقييم CVSS v4.0 يبلغ 9.2 لكل منهما. قد تسمحان بتنفيذ تعليمات برمجية عن بُعد دون مصادقة، ويتوقف التأثير على الإصدار وطريقة النشر ومسار الهجوم.

اقرأ نشرة PHP الرسمية

المشكلة في محرك PHP نفسه وليست في تطبيق بعينه

راجع PHP-FPM وApache mod_php وphp-cgi وFrankenPHP وLiteSpeed وغيرها من بيئات PHP التي تخدم طلبات الويب. تصنف PHP إعداد mod_php على أنه الأعلى خطورة، وقد ثبت إمكان الاستغلال قبل تشغيل كود التطبيق. بساطة الصفحات أو سلامة التطبيق لا تنفي التعرض.

تحقق من بيئة التشغيل إلى جانب برنامج الموقع

تحديث WordPress أوDrupal أو إطار العمل أو الإضافات لا يعني تحديث PHP المستخدم. افحص إصدار كل موقع ومجموعات FPM وصور الحاويات والعقد وPHP المضمّن في اللوحات والأجهزة. صدرت الإصدارات الرسمية المصححة في 21 أكتوبر 2026.

ما الذي يفحصه المدقق

راجع مؤشرات PHP والاستجابات وحالة التصحيحات

كيف تساعد الطلبات السبعة في الفحص؟

ابدأ بطلب GET مرجعي، ثم أرسل نموذجًا بترميز URL وآخر multipart لكل من الطرق الثلاث. راجع كل استجابة قبل الطلب التالي. هذه طلبات عادية لمقارنة السلوك ولا تتضمن حمولات لتنفيذ التعليمات البرمجية أو استنزاف الذاكرة.

سبعة طلبات HTTP لفحص PHP2Shell
الترتيب الطريقة محتوى الطلب ما يجب ملاحظته
01GETبلا جسم طلبإمكانية الوصول والتحويلات وإصدار PHP المعلن وترويسات الاستجابة.
02POSTapplication/x-www-form-urlencodedحقل نصي عادي واحد كطلب POST مرجعي.
03POSTmultipart/form-dataحقل نصي واحد للمقارنة مع POST المرجعي، دون أجزاء ملفات أو حقول تقدم الرفع.
04PUTapplication/x-www-form-urlencodedحقل نصي عادي واحد لملاحظة معالجة PUT في هذا المسار.
05PUTmultipart/form-dataقارن مع نموذج PUT بترميز URL لرصد اختلافات نوع المحتوى.
06PATCHapplication/x-www-form-urlencodedحقل نصي عادي واحد كطلب PATCH مرجعي.
07PATCHmultipart/form-dataقارن مع PATCH المرجعي بدل استنتاج سلوك جميع الطرق من POST وحده.

علامات PHP في X-Powered-By أو Server وملفات تعريف الارتباط مثل PHPSESSID ليست سوى مؤشرات لبيئة التشغيل. قد تُخفى أو تُعدّل أو تُخصّص. وجود ملف تعريف ارتباط لا يثبت أن PHP حلل جسم الطلب.

تغطي الفحوص عنوان URL والمسار المدخلين فقط. قد تختلف استجابة المسارات الأخرى وقواعد CDN وخوادم الأصل المتاحة مباشرة. لا تعمم نتيجة الصفحة الرئيسية على الموقع كله. افحص فقط المسارات المصرح بها والمناسبة لطلبات النماذج.

كيفية تفسير النتائج

ميّز مؤشرات التعرض عن الإصلاحات المؤكدة

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

تعرّف على أخطاء التقييم الشائعة

رُصد مؤشر لإصدار مصحح

وصول الإصدار المعلن إلى حد الإصلاح في فرعه أو تجاوزه مؤشر مفيد، لكن الوكيل قد يغيّر الترويسات. تأكد على الخادم أن كل نسخة تشغيل حمّلت الكود المصحح.

رُصد خطر مرتبط بإصدار قديم

أعط الأولوية للإصدارات الأقل من حد الإصلاح الأصلي، مع التحقق من تصحيحات التوزيعة أو مورّد LTS. إذا كانت حالتها مجهولة فسجّلها بحاجة إلى تحقق، ولا تدّعِ إثبات تنفيذ تعليمات برمجية عن بُعد.

رُفضت الطلبات أو اختلفت الاستجابات

نجاح النموذج المرجعي مع إرجاع multipart لرمز 4xx قد يعكس قيود نوع المحتوى. وإرجاع 405 لكليهما قد يعني فقط أن الطريقة غير مدعومة. رموز الحالة وحدها لا تحدد ما إذا كان الرفض من CDN أو خادم الويب أو التطبيق.

لا مؤشرات PHP أو لا استجابة قابلة للاستخدام

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

خطوات الفحص

ابدأ بعنوان URL وراجع الأدلة

1

أدخل عنوان URL الهدف

أدخل عنوان موقع تملكه أو لديك إذن لاختباره، بما في ذلك المسار المراد فحصه.

2

راجع كل استجابة عند اكتمالها

ابدأ بطلب GET المرجعي، ثم قارن استجابات النماذج بترميز URL وmultipart لطرق POST وPUT وPATCH، طلبًا تلو الآخر.

3

راجع النتائج وإرشادات المعالجة

فسّر رموز الحالة ومؤشرات الإصدار، ثم تحقق من التصحيحات وفق بيئة PHP الفعلية ونشرات المورّد.

التحقق على الخادم

كيف تتأكد أن الموقع يعمل بإصدار PHP مصحح؟

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

1. حدد بيئة PHP التي تعالج الطلبات فعليًا

تحقق من PHP المخصص للموقع ووحدة خادم الويب أو مجموعة FPM. احصر الإصدارات المتعددة والمواقع والحاويات وعقد موازنة الحمل كلًا على حدة. يعرض php -v إصدار CLI الحالي فقط وقد يختلف عن إصدار الويب. لا تنشر صفحة phpinfo للعامة لهذا الغرض.

php -v

2. تحقق من إصدار الحزمة الكامل والنشرة الأمنية

استعلم عن الحزمة المستخدمة وقارن إصدارها الكامل بنشرة التوزيعة. تتضمن حزمة Ubuntu 24.04 ذات الإصدار 8.3.6-0ubuntu0.24.04.13 الإصلاح بالفعل؛ أما PHP 8.3.6 وحده فلا يوضح هذا التصحيح المنقول. اختر المثال المناسب وعدّل اسم الحزمة.

dpkg-query -W php8.3-fpm
rpm -q php-fpm
راجع قائمة حزم Ubuntu الرسمية

3. طبّق إصدارًا مصححًا من الفرع المناسب

استخدم إصدارًا أصليًا مصححًا أو إصدارًا أمنيًا أحدث من الفرع نفسه أو تصحيحًا منقولًا أكده المورّد. حدّث PHP المضمّن في اللوحات والأجهزة والحاويات عبر مورّديها. خرج PHP 8.1 وما قبله من الدعم الأصلي المعتاد؛ تحقق من تصحيحات LTS أو انتقل لإصدار مدعوم. وفرت PHP أيضًا تصحيحات مصدرية محدودة للفروع 7.4 و8.0 و8.1.

4. أعد التشغيل وتحقق من كل نسخة تشغيل

تأكد من إعادة تشغيل PHP-FPM أوApache أو غيرها من عمليات العامل واستبدال الحاويات والعقد عند الحاجة. تحديث الملفات على القرص لا يضمن استبدال العمليات القديمة. تفيد الطلبات غير المعتادة ونفاد الذاكرة وتعطل العامل في التحقيق، لكن غيابها لا يثبت أن النظام لم يتأثر.

افحص بنفسك: سبعة اختبارات باستخدام curl

يرسل النص طلب GET واحدًا ثم نماذج URL-encoded وmultipart عبر POST وPUT وPATCH، طلبًا تلو الآخر. يستخدم حقولًا نصية فقط دون ملفات أو حقول تتبّع تقدم الرفع. شغّله فقط على مسارات مصرح بها ومناسبة للنماذج الاختبارية؛ فالطلبات العادية قد تشغّل إجراءات التطبيق أيضًا.

Bash / curl
#!/usr/bin/env bash
# PHP2Shell HTTP observations: 7 sequential requests, no exploit payload.
set -u

URL="${1:-https://example.com/}"
case "$URL" in
  http://*|https://*) ;;
  *) printf 'ERROR=HTTP(S)_URL_REQUIRED\n' >&2; exit 2 ;;
esac

if ! command -v curl >/dev/null 2>&1 || ! command -v awk >/dev/null 2>&1; then
  printf 'ERROR=CURL_AND_AWK_REQUIRED\n' >&2
  exit 127
fi

probe() {
  printf '\n[%s/7] %s %s\n' "$1" "$2" "$3"
  local method="$2"
  shift 3
  curl -q --globoff --proto '=http,https' --silent --show-error \
    --connect-timeout 5 --max-time 15 --request "$method" \
    --dump-header - --output /dev/null \
    --write-out '\nHTTP_CODE=%{http_code} TOTAL_SECONDS=%{time_total}\n' \
    "$@" --url "$URL" |
  awk '{
    sub(/\r$/, "")
    line = tolower($0)
    if ($0 ~ /^HTTP\// || line ~ /^(server|x-powered-by|content-type):/ || $0 ~ /^HTTP_CODE=/) {
      print
    } else if (line ~ /^set-cookie:[ \t]*phpsessid[ \t]*=/) {
      print "PHPSESSID=present; value hidden"
    }
  }'
  local curl_status="${PIPESTATUS[0]}"
  if [ "$curl_status" -ne 0 ]; then
    printf 'CURL_EXIT=%s\n' "$curl_status"
    FAILED=1
  fi
}

FAILED=0
probe 1 GET baseline
probe 2 POST urlencoded --data-raw 'php2shell_check=1'
probe 3 POST multipart --form-string 'php2shell_check=1'
probe 4 PUT urlencoded --data-raw 'php2shell_check=1'
probe 5 PUT multipart --form-string 'php2shell_check=1'
probe 6 PATCH urlencoded --data-raw 'php2shell_check=1'
probe 7 PATCH multipart --form-string 'php2shell_check=1'
exit "$FAILED"

استخدم Bash على Linux/macOS أو WSL أو Git Bash على Windows. احفظه باسم php2shell-self-check.sh ونفّذ الأمر أدناه باستخدام رابط اختبار مصرح به. لا تلصق نص Bash مباشرة في PowerShell.

bash php2shell-self-check.sh https://example.com/test.php

مهلة الاتصال 5 ثوانٍ والحد الإجمالي لكل طلب 15 ثانية. يتجاهل النص إعدادات curl الشخصية ويتحقق من TLS ولا يتبع التحويلات أو يعيد المحاولة. عند تلقي 3xx، تأكد أن الرابط النهائي مصرح به قبل إعادة الفحص عليه. يظهر PHPSESSID كمؤشر وجود فقط، دون قيم ملفات الارتباط أو محتوى الاستجابة.

يمثل HTTP_CODE حالة الاستجابة وTOTAL_SECONDS المدة الإجمالية. تشير قيمة CURL_EXIT غير الصفرية إلى فشل النقل، مع استمرار بقية الاختبارات. يشير خروج النص بقيمة غير صفرية إلى مشكلة في المدخلات أو المتطلبات أو النقل. تُسجّل استجابات HTTP 4xx/5xx طبيعيًا؛ ولا يحدد رمز الخروج وجود الثغرة أو حالة التصحيح.

كيفية تفسير مخرجات الطرفية

ترويسات الإصدار مؤشرات فقط

قد تكون Server أو X-Powered-By مخفية أو قديمة. تحقّق من PHP الذي يشغّل الموقع فعليًا: أول الإصدارات الرسمية المصححة للفروع المعنية هي 8.2.35 و8.3.36 و8.4.27 و8.5.12. أكّد التصحيحات المنقولة من المورّد بالرجوع إلى إصدار الحزمة الكامل والنشرة الأمنية.

قارن الترميزين للطريقة نفسها

إذا أعاد urlencoded رمز 2xx أو3xx بينما أعاد multipart رمز 403 أو406 للطريقة نفسها، فهذا يثبت اختلاف الاستجابة فقط. ولا يؤكد حجب WAF أو رفض الطلب قبل وصوله إلى PHP.

نجاح الاستجابة لا يثبت تحليل PHP

يعني رد multipart برمز 2xx أو3xx استلام استجابة نجاح أو تحويل فقط. ولا يثبت وصول الجسم إلى PHP وتحليله، ولا يحدد وجود الثغرة من عدمه.

405 ومؤشرات PHP لا تكفي وحدها للحكم

لا تثبت استجابات 405 لجميع الاختبارات تطبيق الإصلاح. وغياب مؤشرات PHP لا يثبت عدم استخدامه. كما أن ظهور ملف تعريف ارتباط PHPSESSID لا يحدد ما إذا جرى تحليل multipart أو أي طبقة أنشأت الاستجابة.

عرض الإصدارات الرسمية المصححة وإرشادات التحديث
ماذا تحقق التدابير المؤقتة إلى حين التحديث؟

تؤكد PHP أن التحديث هو الإصلاح الكامل. تقلل الإعدادات التالية التعرض لمسارات معروفة محددة لكنها لا تجعل بيئة غير مصححة آمنة. قيّم متطلبات التطبيق والإرشادات الرسمية قبل التعديل.

  • عطّل session.upload_progress.enabled وأعد تشغيل كل عمليات العامل. يجب تطبيق الإعداد قبل تحليل الطلب عبر php.ini أو مجموعة FPM أو إعداد الخادم، لا عبر ini_set() أو .user.ini في FPM. يحجب هذا مسارات الجلسة المؤكدة فقط.
  • تتضمن إرشادات PHP 8.5 تعطيل fatal_error_backtraces وإعادة تشغيل العامل. يغطي هذا مسار التتبع الخلفي للخطأ الفادح المؤكد فقط ولا يغطي المتغيرات الأخرى.
  • راجع حدود حجم الجسم وعدد الحقول وأجزاء multipart في خادم الويب أو الوكيل، وتحقق من إمكان الوصول إلى الأصل دون CDN. إخفاء الأخطاء أو حجب طريقة واحدة أو فحص مسار واحد لا يحل محل الإصلاح.

الإصدارات الرسمية المصححة

تحقق من حدود الإصدارات المصححة لفروع PHP 8.2–8.5

قارن الإصدارات داخل كل فرع: حد 8.3 لا يحدد حالة 8.4. لا تفترض أن الإصدارات التجريبية أو الفروع المجهولة مصححة. تحقق من التصحيحات المنقولة والبناء المخصص بمراجعة إصدار الحزمة الكامل وسجلات البناء ونشرات المورّد.

اقرأ إرشادات التحديث الرسمية

هل تستخدم لوحة BaoTa؟ حدّث PHP من متجر البرامج

وفقًا لإعلان BaoTa بتاريخ 2026-10-21، تتوفر بعض إصدارات PHP المصححة أمنيًا في اللوحة. تحقق من متجر البرامج في لوحتك لمعرفة الإصدارات المتاحة حاليًا.

اقرأ إعلان التحديث من BaoTa

انسخ موقعك وقواعد البيانات والإعدادات ذات الصلة احتياطيًا قبل التحديث، واختر وقتًا مناسبًا للصيانة.

  1. حدد إصدار PHP الذي يستخدمه موقعك فعليًا

    سجّل الدخول إلى لوحة BaoTa، ثم افتح متجر البرامج ← المثبّتة، وحدد إصدار PHP المستخدم فعليًا لموقعك وافتح صفحة إدارته.

  2. ثبّت الإصدار الأمني للفرع المطابق

    تحقق من التحديثات المتاحة في صفحة إدارة PHP واتبع التعليمات لتثبيت الإصدار المصحح المذكور أعلاه للفرع نفسه، أو إصدار أمني لاحق من الفرع ذاته.

  3. أعد تشغيل PHP وتحقق من موقعك

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

إذا كانت عدة إصدارات PHP مثبتة، فتحقق من كل إصدار ما زال مستخدمًا. وإذا ثبّتّ إصدارًا آخر، فتأكد أيضًا من تحويل الموقع إلى بيئة PHP المصححة.

الأسئلة الشائعة

أسئلة شائعة حول كشف PHP2Shell وتصحيحه

افهم الفرق بين مؤشرات الإصدار ورموز الحالة والتصحيحات المنقولة لتجنب المبالغة في تفسير النتائج.

ما هو PHP2Shell وما المواقع التي تحتاج إلى فحص؟

يشير PHP2Shell إلى ثغرتي نواة PHP، ‏CVE-2026-109618 وCVE-2026-109619، اللتين قد تسمحان بتنفيذ تعليمات برمجية عن بُعد دون مصادقة. افحص كل بيئات PHP غير المصححة التي تعالج طلبات الويب، حتى إن كان كود التطبيق آمنًا.

هل تثبت الاستجابة 403 أو405 أو413 وجود حماية؟

لا. قد تنتج هذه الرموز عن المصادقة أو طرق غير مدعومة أو حدود الحجم أو الوكلاء. رفض multipart يصف سلوك المسار الحالي فقط ولا يثبت تصحيح PHP أو حجب جميع مسارات الهجوم.

هل غياب ترويسات PHP يعني أن الموقع غير متأثر؟

ليس بالضرورة. قد يكون كشف الإصدار معطّلًا، وقد تخفي CDN أو الوكيل العكسي أو الصفحة الرئيسية الثابتة التقنية الخلفية. غياب المؤشرات يعني نقص المعلومات، لذا تحقق من بيئة الخادم الفعلية.

ما الإصدارات التي تتضمن الإصلاح وهل القديمة غير مصححة دائمًا؟

تتوفر الإصلاحات الأصلية في PHP 8.2.35 و8.3.36 و8.4.27 و8.5.12. استخدم إصدارًا مصححًا أو أمنيًا أحدث في الفرع المناسب. قد تحتوي الإصدارات القديمة على تصحيحات منقولة، لذا طابق إصدار الحزمة الكامل مع نشرة المورّد. انتهى الدعم الأصلي المعتاد لـ PHP 8.1 وما قبله. أعد تشغيل العامل بعد التحديث.

لماذا نفحص PUT وPATCH إلى جانب POST؟

قد تمر الطرق بمسارات وقواعد ترشيح مختلفة. منذ PHP 8.4 تستطيع التطبيقات استخدام request_parse_body() لتحليل multipart بطرق غير POST. لا يعني ذلك أن كل التطبيقات تحلل PUT أوPATCH تلقائيًا. سلوك POST وحده لا يثبت حماية الطرق أو المسارات الأخرى.

كيف نفسر POST برمز 200 وPUT/PATCH برمز 405 مع غياب مؤشرات PHP؟

سجّل بيئة PHP وحالة التصحيح على أنهما غير مؤكدتين. يدل POST 200 على استجابة فقط، و405 على رفض الطريقة في طبقة ما. قد تعطي الصفحات الثابتة وبيئات أخرى وPHP المخفي النمط نفسه. تحقق من بيئة التشغيل على الخادم بدل الجزم بالأمان أو بثغرة مثبتة.

تمت مراجعة مراجع الثغرات والمعالجة في 2026-10-22. للمراقبة الخارجية حدود؛ اتبع نشرات PHP والمورّد الحالية لاتخاذ الإجراءات العملية.

احصل على رؤية أوضح لتعرض موقعك لـ PHP2Shell

راجع الاستجابات العامة فحصًا بعد آخر، وفسّر الأدلة، ثم تحقق من التصحيحات وفق بيئة الخادم الفعلية.

استكشف عناصر الفحص