---
title: "PHP2Shell: دليل الأسباب والعلاج"
description: "فهم عيوب دورة حياة PHP2Shell، وترقيات وقت التشغيل، وعمليات التخفيف المؤقتة، واختيار التصحيح، والتحقق من خلال مسار طلب Web المباشر."
language: "ar"
url: "https://keendigit.com/ar/insights/php2shell-remediation-guide"
author: "KeenDigit"
published: "2026-10-22"
---

# PHP2Shell: دليل الأسباب والعلاج

فهم عيوب دورة حياة PHP2Shell، وترقيات وقت التشغيل، وعمليات التخفيف المؤقتة، واختيار التصحيح، والتحقق من خلال مسار طلب Web المباشر.

**تم فحص المصادر اعتبارًا من 22 أكتوبر 2026.** **الجمهور: مشغلو التطبيقات والمستجيبون الأمنيون والمهندسون PHP الذين يقومون بصيانة إصدارات PHP المخصصة.**

يلخص هذا المقال السبب ونطاق التأثير وعملية الإصلاح الرسمية وإجراءات التخفيف المؤقتة وتنفيذ التصحيح الرسمي لثغرة PHP2Shell. يتم الاستشهاد بالنص الرئيسي باستخدام أرقام مثل [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)؛ يتم سرد جميع روابط المصدر في الملحق في نهاية النص. جزء التكوين عبارة عن قالب نشر يحتاج إلى تعديل استنادًا إلى الإصدار الفعلي وقدرة العمل وعلاقة توريث التكوين.

## TL;DR: خطوات الإصلاح والاقتراحات

1. **ترقية وقت التشغيل PHP**: قم بترقية الفرع ذي الصلة إلى **8.2.35 أو 8.3.36 أو 8.4.27 أو 8.5.12** على الأقل. بالنسبة لحزم التوزيع، استخدم إصدار الحزمة الكاملة الذي يؤكد البائع أنه يعمل على إصلاح كل من التهديدات المشتركة. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S10](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-10)
2. **استبدال كافة العمليات القديمة**: أعد تشغيل أو تجاوز كل PHP worker وخدمة الاستضافة والحاوية بعد الترقية، وتأكد من خروج المثيلات القديمة.
3. **تحقق من خلال مسار طلب Web الفعلي**: تحقق من Web SAPI وإصدار الحزمة الكاملة والمثيل قيد التشغيل. التحقق من `php -v` وحده لا يثبت أن الخدمة المباشرة ثابتة.
4. **قم بتشغيل عمليات التحقق من انحدار الأعمال واستعادة ميزانيات الموارد العادية**: اختبار تسجيل الدخول ومعالجة الجلسة والتحميلات والاستيراد ومعالجة الأخطاء. إذا تمت إزالة حد الذاكرة PHP مؤقتًا، فقم باستعادة ميزانية محدودة مناسبة بعد التصحيح.
5. **إذا كانت الترقية الفورية مستحيلة**: قم بتقييد حركة المرور غير الموثوق بها قبل أن تصل إلى PHP. قم بتقييم تعطيل تقدم التحميل والتتبعات الخلفية القاتلة PHP 8.5 كما هو موضح في القسم 5. تتمتع عمليات تخفيف التكوين وقواعد WAF بتغطية محدودة ولا يمكن أن تحل محل الترقية. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

## 1. نظرة عامة على الضعف والحكم على المخاطر

يشير PHP2Shell في هذه المقالة إلى اثنتين من الثغرات الأمنية على مستوى Critical التي تم الكشف عنها رسميًا بواسطة PHP في 21 أكتوبر 2026. وكلاهما مرتبطان بالذاكرة وإدارة دورة حياة الطلب لمحرك PHP، مما يشكل خطر تنفيذ تعليمات برمجية عن بعد غير مصادق عليها. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

| مشروع                 | CVE-2026-109618                                                                                | CVE-2026-109619                                                        |
| --------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| الاسم الرسمي          | RCE via OOM corruption                                                                         | RCE via stale global state                                             |
| القضايا الأساسية      | تؤدي الذاكرة غير الكافية إلى حدوث قفزة غير طبيعية، مما يؤدي إلى ترك حالة لم تكتمل التهيئة بعد. | تشير الحالة العامة المتبقية في العامل إلى ذاكرة الطلب التي تم إصدارها. |
| وقت حدوث نموذجي       | عملية التهيئة أو التنفيذ أو التنظيف للطلب الحالي                                               | يترك الطلب السابق الحالة، وتستهلكها الطلبات اللاحقة مقدمًا.            |
| هل OOM شرط ضروري؟     | ينتمي إلى آلية إثارة الثغرة الأمنية الأساسية                                                   | لا؛ قد تكون هناك أيضًا أخطاء قاتلة أخرى وعمليات تنظيف ما بعد التشخيص   |
| اتجاه الإصلاح الأساسي | التعامل بأمان مع حالات فشل التخصيص وطلب الإنهاء                                                | إصلاح ملكية الدولة وتوقيت التنظيف والتهيئة المبكرة                     |
| متطلبات التخلص        | يجب إصلاحه                                                                                     | يجب إصلاحه في نفس الوقت                                                |

الأساس: نشرتان أمنيتان رسميتان وتقديمات الإصلاح. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-4)

### 1.1 فهم عمليات النشر المتأثرة

تعتبر PHP رسميًا أن عمليات نشر **all PHP التي تعالج طلبات Web** معرضة للخطر، بما في ذلك PHP-FPM، وApache mod\_php، وphp-cgi، وFrankenPHP، و LiteSpeed. يمكن أن يحدث هجوم mod\_php الموضح قبل تشغيل كود التطبيق، لذلك لا يمكن لعمليات التحقق من تسجيل الدخول والبرمجيات الوسيطة لإطار العمل والتحقق من صحة تحميل التطبيق تغطية هذا المسار. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)

من الضروري التمييز بين "يجب إصلاح النشر" و"تم إثبات سلسلة هجمات معينة بشكل كامل". إعلان CVE-2026-109618: سيخرج FPM من العملية الفرعية بعد فشل بدء تشغيل الطلب، ويمنع مسار التنظيف المقابل لـ mod\_php بعد فشل بدء التشغيل؛ ومع ذلك، فإن مسار OOM بعد بدء التشغيل الناجح لا يزال معرضًا للخطر. يشير الإعلان أيضًا إلى أن استغلال FPM الكامل لهذا CVE لم يتم عرضه بعد. لا يمكن استخدام هذا التقييد لاستنتاج أن FPM آمن، ولا يمكن تجاهل CVE-2026-109619 بشكل خاص. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

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

لا تحتوي البرامج النصية العادية CLI لمرة واحدة على نفس إدخال HTTP؛ ولكن العمليات التي تتعامل مع المهام الخارجية لفترة طويلة في CLI أو الوضع المضمن يجب أن تظل مدرجة في وقت التشغيل ومخزون دورة الحياة. يتم تحديث تبعيات CMS أو إطار العمل أو Composer فقط ولا يتم استبدال محرك PHP الأساسي تلقائيًا.

## 2. تحليل السبب

### 2.1 افهم أولاً دورتي الحياة

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

لذلك، يجب أن يحافظ المحرك على قيدين:

- **قيد التهيئة**: يجب أن تكون البيانات المرئية للرموز الأخرى في حالة يمكن قراءتها واجتيازها وتدميرها بأمان.
- **قيد دورة الحياة**: بمجرد تحرير ذاكرة الطلب، يجب ألا تستمر الحقول ذات العمر الأطول في التعامل مع العناوين الموجودة في تلك الذاكرة كحالة صالحة.

يتوافق هذان القيدان مع أوضاع الفشل الرئيسية لمجموعتي نقاط الضعف. العملية التالية عبارة عن وصف للآلية التي تجمع بين الإعلانات وتجميع التصحيحات. وهذا لا يعني أن كل عملية نشر لها نفس المسار الذي يمكن الوصول إليه بالضبط. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

### 2.2 CVE-2026-109618: قام OOM بمقاطعة تحديث الحالة غير المكتمل

يستخدم التطبيق القديم قفزة غير محلية من النوع `longjmp()` للتعامل مع OOM، ويخرج المسار المرتبط من سياق التنفيذ الحالي من خلال `zend_bailout()`. يكمن الخطر في أن جزءًا من كود C ربما نشر كائنًا أو مصفوفة أو حالة طلب جديدة إلى كود آخر، لكنه لم يكمل بعد تهيئة الحقل بالكامل؛ في هذا الوقت، قد يؤدي أي فشل في التخصيص في الوقت المناسب إلى تخطي خطوات الإغلاق العادية. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)

يمكن تقسيم عملية الفشل إلى أربع خطوات:

1. إنشاء أو تحديث البنية الداخلية للطلب وإتاحتها.
2. يفشل تخصيص الذاكرة اللاحق ويتم تشغيل OOM.
3. يقفز تدفق التنفيذ بعيدًا عن الوظيفة الحالية، ولا يتم تنفيذ التعليمات البرمجية المستخدمة في الأصل لإكمال التهيئة أو استعادة الحالة.
4. يستمر طلب التنظيف في معالجة هذه الهياكل ويتعامل مع المحتويات غير الصالحة كحقول أو عناوين صالحة.

لا تكمن المشكلة في أن نفاد الذاكرة يتسبب دائمًا في ظهور RCE. بدلاً من ذلك، يؤدي استنفاد الذاكرة **إلى تغيير تدفق التحكم وينتهك افتراضات المحرك حول الهياكل الصالحة**. لا يلزم أن يتضمن التخصيص الفاشل البنية التي تمت قراءتها بشكل غير صحيح في النهاية. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)

#### لماذا قد تنفد الذاكرة أيضًا من الطلبات الصغيرة؟

عدد البايتات في نص الطلب واستخدام الكومة بعد التحليل ليسا نفس الشيء. قد يتوافق حقل A مع سلاسل متعددة وعناصر مصفوفة وكائنات بيانات التعريف داخل PHP؛ سيؤثر التعقيد الهيكلي للمدخلات على درجة تضخيم الذاكرة.

تتضمن مشكلات الأجزاء المتعددة المدرجة في الإعلان الرسمي ما يلي: فجوة التحقق من الحجم الأولي عندما يكون طول الإعلان المتاح مفقودًا، وعدد الرؤوس لجزء واحد ليس محدودًا بما فيه الكفاية، ولا تزال عناصر التحكم في الملفات الفارغة تنتج بيانات تعريفية، مع زيادة الأسماء المتداخلة في عبء عمل المصفوفة. قد يكون أيضًا تفكيك التطبيق أو فك تشفيره أو إعادة تعيينه مصدرًا لـ OOM. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)

ويمكن استخلاص استنتاجين وقائيين من هذا:

- يجب تنفيذ قيود نص الطلب قدر الإمكان قبل إدخال PHP، ويجب مراعاة طول القراءة الفعلي والتعقيد الهيكلي.
- لا يمكن أن يؤدي تحديد حجم الملف أو عدد الملفات أو إغلاق بوابة تحميل واحدة بشكل فردي إلى تغطية جميع مصادر OOM.

#### لماذا قد تكون مصادقة التطبيق متأخرة جدًا؟

في mod\_php، قد يتم تحليل نص الطلب تلقائيًا أثناء مرحلة تهيئة الطلب؛ حتى في حالة فشل بدء التشغيل، سيتم تنفيذ عملية تنظيف الطلب ذات الصلة. وبالتالي يمكن أن تحدث مسارات الهجوم المؤكدة قبل رمز التطبيق. لتقليل التعرض في هذه المرحلة، يجب وضع القيود على الوكيل العكسي أو خادم Web أو أي حدود أخرى تسبق معالجة طلب PHP. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)

### 2.3 CVE-2026-109619: تم تحرير ذاكرة الطلب، ولا يزال المرجع العالمي على قيد الحياة

تتضمن هذه المشكلة حالة خطأ أو جلسة عمل أو كائن أو ملحق: يتم تخزين الحقل في موقع وصول طويل المدى للعامل، ولكن البيانات المشار إليها بواسطة الحقل تنتمي إلى طلب واحد. طالما لم يتم تنظيف المرجع بشكل صحيح قبل تحرير كومة الطلب، فقد تواجه الطلبات اللاحقة حالة متدلية، وتشكل استخدامًا بعد الاستخدام مجانًا. [S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

ويقسم التحليل الرسمي ظروف الاستغلال إلى "منتجين" و"مستهلكين":

| الدور أو الحالة      | معنى                                                                                  | الآثار المترتبة على الحماية                                                 |
| -------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| منتج الدولة          | ضع الحالة المملوكة لهذا الطلب في موقع لا يزال من الممكن الوصول إليه لاحقًا            | للتحقق مما إذا كانت عملية التنظيف المقابلة قد اكتملت بعد الخروج غير الطبيعي |
| تبقى الحالة          | لم تتم تطهيره، أو تم تطهيره ثم إعادة تعبئته بعملية متأخرة.                            | قد لا يكون مجرد المسح مرة واحدة في مرحلة إيقاف التشغيل السابقة كافيًا       |
| إعادة استخدام العمال | يستمر نفس العامل في معالجة الطلبات اللاحقة                                            | يعد تعدد العمال مجرد اختلاف في الجدولة، وليس ضمانًا لسلامة الذاكرة          |
| تقدم المستهلك        | قم بقراءة القيمة المتبقية أو تحريرها أو تحديدها قبل تهيئة الحالة المقابلة بشكل طبيعي. | يجب التحقق من INI والجلسة والمسارات الأخرى قبل التهيئة                      |

ويجب استيفاء هذه الشروط مجتمعة؛ أي سجل أخطاء في حد ذاته لا يثبت أنه تم استغلال الثغرة الأمنية بنجاح. [S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

#### لا يتطلب OOM كشرط أساسي ضروري

يمكن أن تؤدي الأخطاء الفادحة إلى مقاطعة نشر الحالة المقترنة واستعادتها. يمكن أن تؤدي حالات فشل التجميع أو التحليل، والأخطاء التي لم يتم اكتشافها، وحالات فشل `require`، ومهلات التنفيذ إلى ترك حالات معينة وراءها. يمكن أيضًا للتشخيصات غير القاتلة في وقت متأخر من عملية التنظيف إعادة ملء معلومات الخطأ التي تم مسحها بالفعل. [S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

ولذلك، فإن تغيير `memory_limit` إلى غير محدود لا يغطي هذه المجموعة من الثغرات الأمنية.

#### يجب معالجة "قبل التهيئة" بشكل منفصل

يختلف توقيت النوعين من المستهلكين المؤكدين:

- تشخيصات **Early INI**: قد تصل بعض التكوينات المطبقة عند الطلب إلى حالة التحذير أو الإشعار أو الإهمال قبل تهيئة المنفذ العادي ومعالجة التشخيص إلى حالة الخطأ القديمة.
- **تقدم تحميل الجلسة**: قد تتم معالجة الجلسة مسبقًا أثناء عملية تحليل نص الطلب، لكن الوحدة العادية `RINIT` لم تكتمل بعد؛ لا يمكن استنتاج أن المسار غير موجود لأن التطبيق لا يستدعي `session_start()` بشكل صريح. [S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

ليست كل تكوينات INI لها نفس توقيت المخاطر. يجب تمييز التكوين على مستوى الدليل لـ mod\_php و`PHP_VALUE` / `PHP_ADMIN_VALUE` الذي تم تمريره بواسطة الواجهة الأمامية FPM عن تكوينات بدء التشغيل `php.ini` العادية وFPM pool وFPM `.user.ini`. تتميز الأخيرة بتوقيت تكوين مختلف ولا يمكن تسميتها بشكل جماعي بنفس المستهلكين الأوائل. [S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

إن إيقاف تشغيل `display_errors`، أو `log_errors`، أو تقليل `error_reporting`، أو استخدام `@` يؤثر فقط على رؤية التشخيص؛ ربما تم الوصول إلى الحالة الداخلية ذات الصلة قبل اتخاذ قرار بشأن إخراج السجل أم لا. [S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

## 3. إصلاح الإصدار واختيار التصحيح

### 3.1 خط الأساس الرسمي لإصلاح المنبع

| فرع PHP الحالي         | الإصدار الأول الذي يتضمن هذا الإصلاح الرسمي | اقتراحات                                                                                              |
| ---------------------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| 8.2                    | 8.2.35                                      | قم بالترقية إلى هذا الإصدار أو إصدار لاحق يحتوي على نفس الإصلاحات                                     |
| 8.3                    | 8.3.36                                      | نفس ما ورد أعلاه                                                                                      |
| 8.4                    | 8.4.27                                      | نفس ما ورد أعلاه                                                                                      |
| 8.5                    | 8.5.12                                      | نفس ما ورد أعلاه                                                                                      |
| 8.1 والإصدارات السابقة | لقد انتهى الدعم العام للمنبع                | إعطاء الأولوية للانتقال إلى الفروع المدعومة؛ إصدار شيك قصير الأجل أو المنفذ الخلفي للشركة المصنعة LTS |

يعتمد الإصدار وحالة الدعم على الإعلان الرسمي عن PHP، وخط الأساس الزمني هو 22 أكتوبر 2026. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)

هذه هي **عتبات الإصلاح الخاصة بالفرع**. ولا يمكن استبدالها ببيان مفاده أن كل إصدار أدنى من 8.5.12 معرض للخطر: الإصدارات مثل 8.2.35 و8.4.27 في الفروع الأخرى تحتوي بالفعل على الإصلاحات.

### 3.2 التحقق من إصدار حزمة التوزيع الكاملة

غالبًا ما تضيف التوزيعات إصلاحات أمنية استنادًا إلى الإصدارات الأولية الأقدم. يجب أن يتحقق القبول أيضًا من إصدار الإصدار ومصدر المستودع وإصدار الحزمة الكاملة ونشرة الأمان.

على سبيل المثال، إصدار حزمة الإصلاح Ubuntu 24.04 LTS المدرج لـ Ubuntu USN-8948-1 هو:

```text
8.3.6-0ubuntu0.24.04.13
```

لا يزال الجزء الأولي الخاص به هو `8.3.6`، ولكن تم تضمين إصدار الحزمة الكاملة لهذا التوزيع في إعلان الإصلاح هذا. ينطبق هذا الاستنتاج فقط على مصدر التوزيع والحزمة المقابل، ولا يمكن تعميمه على أي إصدار يعرض أيضًا `8.3.6`. [S10](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-10)

### 3.3 اختيار التصحيح الصحيح

| المشهد                                         | خطة الأولوية                                                                               | النقاط الرئيسية للقبول                                                     |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| باستخدام حزمة التوزيع PHP                      | قم بتثبيت التحديثات الأمنية الصادرة عن الشركة المصنعة                                      | يغطي الإعلان كلا من CVE؛ إصدار الحزمة الكامل صحيح                          |
| استخدم حاوية PHP الرسمية أو الصورة ذاتية الصنع | قم بتحديث وقت التشغيل الأساسي وإعادة البناء والنشر                                         | يستخدم المثيل قيد التشغيل الصورة الجديدة؛ يتم الخروج من كافة النسخ القديمة |
| الفروع المدعومة ذاتية التجميع                  | استخدم إصدار الأمان الرسمي لهذا الفرع أو مجموعة التصحيح الرسمية الكاملة                    | مطابقة الفروع وإكمال التبعية وتوافق الامتداد وتمرير الانحدار               |
| تخضع لـ 7.4، 8.0، 8.1                          | إعطاء الأولوية للواجهة الخلفية للمورد؛ قم بتقييم فرع كود مصدر الطوارئ الرسمي إذا لزم الأمر | تحديد التغييرات السلوكية وجدولة الترحيل إلى الإصدارات المدعومة             |

لقد تم إصدار التصحيحات الرسمية، ويجب أن تبدأ الإصلاحات الفعلية من هذه التصحيحات. تهدف مقتطفات التعليمات البرمجية الموجودة في القسم 6 إلى توضيح أبرز ميزات التصميم والمراجعة ولا تشكل تصحيحًا كاملاً يمكن تطبيقه بشكل مستقل. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-6)

## 4. عملية الإصلاح الرسمية

### 4.1 جرد وقت التشغيل الذي يعالج الطلبات فعليًا

يوصى بتكوين دفتر أستاذ مختصر لتسجيل ما يلي على الأقل:

- اسم مجال الإدخال أو الخدمة، الواجهة الخلفية للوكيل العكسي، PHP SAPI.
- فرع PHP، إصدار الحزمة الكاملة أو ملخص الصورة، بناء المصدر.
- FPM pool، وحدة الخدمة الفعلية، الحاوية أو Pod، عدد النسخ المتماثلة.
- تم تحميل الامتدادات والتكوين الرئيسي وملفات التكوين الإضافية.
- هل هناك إصدارات أخرى من PHP أو نسخ نشر قديمة أو بوابات أصل يمكن الوصول إليها مباشرة؟

هذه هي اقتراحات التنفيذ بحيث يمكن أن تتوافق "الترقية" مع كل إدخال فعلي لحركة المرور. تحقق بشكل خاص مما إذا كان سطر الأوامر PHP وWeb PHP يستخدمان إصدارات مختلفة، أو تم إنشاء الصورة ولكن الحاوية القديمة لا تزال قيد التشغيل، أو لم يتم استبدال جزء من التجمع أو النسخة، وما إلى ذلك.

### 4.2 حدد التحديث الصحيح وقم بنشره

قم بتأكيد إصدار الإصلاح وفقًا للقسم 3، ويفضل استخدام مصدر حزمة موثوق به موجود أو سلسلة إنشاء خاضعة للتحكم. يجب أن يتضمن نطاق التحديث المكون الذي يستضيف الطلب بالفعل، مثل حزمة FPM، أو الوحدة النمطية Apache PHP، أو الثنائي CGI، أو إصدار الخدمة الذي تم تضمين PHP فيه.

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

### 4.3 إعادة تشغيل المثيلات قيد التشغيل أو تمريرها

إن تثبيت ملف وتحميل تعليمات برمجية جديدة في العملية هما شيئان مختلفان. يجب إعادة تشغيل الخدمة المقابلة، أو يجب إكمال الاستبدال المتداول، ويجب التأكد من خروج العامل القديم والحاوية القديمة.

بالنسبة إلى mod\_php، أعد تشغيل عملية Apache التي تستضيف الوحدة النمطية. تحتاج الخدمات التي تتضمن PHP إلى استبدال عملية الاستضافة الخاصة بها. بالنسبة لـ FPM، لا يحل مسح OPcache محل تحديث وقت التشغيل وتقاعد العمال القدامى.

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

### 4.4 تحقق من خلال طلبات Web الحقيقية

يوصى بدمج الأدلة التالية بدلاً من الاعتماد فقط على أمر إصدار واحد:

| الأدلة                                                    | ما يمكن إثباته                          | لا يمكن إثبات أي شيء بمفرده                 |
| --------------------------------------------------------- | --------------------------------------- | ------------------------------------------- |
| مدير الحزم أو البيانات الوصفية للصورة                     | مصادر التثبيت والبنيات الكاملة          | لقد تم تحويل حركة المرور إلى هذه الحالة     |
| حالة العملية والنشر                                       | العامل أو الحاوية يكمل الاستبدال        | يجب توجيه المدخل الخارجي إليه               |
| يتم الوصول إلى نتائج التشخيص المقيدة عبر البوابة الحقيقية | Web SAPI الفعلي وتكوين التشغيل          | ما إذا كان الإصدار الخلفي يغطي اثنين من CVE |
| إعلان البائع أو سجل التصحيح الكامل                        | تم تضمين إصلاح الخلل هذا في هذا الإصدار | يتم نشر كافة النسخ المتماثلة                |

يمكن التحقق من `PHP_VERSION`، و`PHP_SAPI`، وملفات التكوين المحملة، وتكوينات الطوارئ من خلال إمكانيات التشخيص الداخلية الموجودة، أو بوابات التشخيص المؤقتة والتي يمكن التحكم في الوصول إليها. تأكد من عدم إرجاع الطلب مباشرة بواسطة CDN أو ذاكرة التخزين المؤقت للصفحة؛ قم بإزالة الإدخال التشخيصي المؤقت عند الانتهاء.

يشير `php -v` عادةً إلى الثنائي CLI المحدد حاليًا بواسطة الصدفة؛ أوامر مثل `php-fpm -i` لا تعادل التحقق من العامل الموجود الذي يتلقى حركة المرور. لا تعرض صفحة `phpinfo()` الكاملة للشبكة العامة لفترة طويلة.

### 4.5 فحص انحدار الأعمال وإزالة إعدادات الطوارئ

تحقق من تسجيل الدخول العادي، وقراءة الجلسة وكتابتها، والنموذج والتحميل، والاستيراد، ومعالجة الأخطاء واستقرار العامل حول الوظائف المتأثرة بهذا التغيير. تحقق مما إذا كان معدل الخطأ وتأخير الاستجابة وذروة الذاكرة وخروج العملية وتكرار إعادة البناء غير طبيعي.

إذا تم تعيين `memory_limit=-1` مؤقتًا، فستتم استعادة الميزانية المحدودة المطابقة لقدرة الأعمال بعد سريان التصحيح الرسمي؛ إذا تم تعيين `pm.max_requests=1`، فستتم استعادة تكوين دورة الحياة المقيَّمة للقدرة بعد تأكيد الإصلاح. يمكن الاحتفاظ بحدود حجم الإدخال وعناصر التحكم في الوصول إلى المصدر حسب ما تمليه احتياجات العمل.

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

## 5. تدابير التخفيف عندما لا يكون الترقية الفورية ممكنة

يهدف هذا القسم إلى تقليل التعرض على المدى القصير أو تحسين التوافر. يغطي كل إجراء مسارًا محددًا فقط، ولا يعادل الجمع بين عدة إجراءات إصلاحًا كاملاً. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

### 5.1 إعطاء الأولوية لضوابط حركة المرور قبل PHP

إذا كانت الخدمة تسمح بذلك، فقم بتقييد نقاط النهاية الحساسة مؤقتًا على المصادر الموثوقة أو فرض التحكم في الوصول قبل PHP. لتحميل أحمال العمل، قم بتحديد حجم نص الطلب، وعدد الحقول، وعدد الأجزاء، والرؤوس لكل جزء، وعمق التداخل. يمكن للخدمات التي لا تحتاج إلى أجزاء متعددة أن ترفضها في الواجهة الأمامية. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)

تهدف هذه القيود إلى تغطية كافة المداخل إلى PHP. سيؤدي اعتراض URL المسمى "تحميل" فقط إلى تفويت الإدخالات الأخرى التي لا يزال يتم تحليلها تلقائيًا بواسطة PHP في نص الطلب. بالنسبة لحالات مثل عمليات النقل المقسمة، وعدم توفر الطول المعلن، وما إلى ذلك، يجب أن يعتمد الحد على حجم القراءة الفعلي؛ يجب أن يكون للتطبيق أيضًا ميزانية حجم الإخراج الخاصة به عند فك ضغط المحتوى أو توسيعه مرة أخرى.

### قالب التكوين 5.2 FPM pool

ضع الإعدادات التالية في قسم التكوين **FPM pool الذي يخدم بالفعل الطلبات**، وليس حرفيًا في `php.ini`. تعتبر قيم 8M و4M أمثلة لضبط حجم العمل. اترك مساحة لحقول النموذج والحدود متعددة الأجزاء عند تحديد طلب POST بالكامل. [S11](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-12)

```ini
; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off
```

**PHP 8.5** فقط، بالإضافة إلى:

```ini
php_admin_flag[fatal_error_backtraces] = off
```

وظائف وحدود كل منها هي كما يلي:

| التكوين                               | التأثير المتوقع                                          | وصف القيود التي يجب الاحتفاظ بها                                                                            |
| ------------------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| `memory_limit=-1`                     | قم بإزالة حالة تشغيل الحد الأعلى لذاكرة طلب PHP المتوقعة | ولا يمنع فشل التخصيص الأساسي؛ قد يؤدي إلغاء الميزانية الأصلية إلى زيادة خطر استنفاد الذاكرة وانقطاع الخدمة. |
| أصغر `post_max_size`                  | تقليل حجم البيانات التي تدخل في عملية التحليل            | المحلل اللغوي غير المثبت لديه فجوة معروفة؛ لا يمكن منع تضخيم الذاكرة بشكل مستقل                             |
| `upload_max_filesize < post_max_size` | تحديد حجم ملف واحد وحجز المساحة العامة للطلب             | لا يقيد جميع الحقول أو البيانات التعريفية أو التخصيصات داخل التطبيق                                         |
| إغلاق تقدم التحميل                    | قم بحظر المسار المؤكد المتعلق بالجلسة                    | لا يغطي متغيرات الحالة العالمية الأخرى                                                                      |
| PHP 8.5 يغلق أثرًا خلفيًا مميتًا      | حظر منتجي الحالة ذات الصلة المؤكدة                       | لا يغطي مسارات أخرى مثل الجلسة                                                                              |

حدود القياس تأتي من الإعلان الرسمي؛ للتعرف على بناء جملة التجمع ودلالات التكوين على مستوى الإدارة، راجع دليل PHP. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-11)

لا يمكن تجاوز إعدادات `php_admin_*` على مستوى الإدارة بواسطة التطبيقات عبر `ini_set()`. لا يزال يتعين مراجعة جميع التكوينات الواردة على مستوى الدليل والواجهة الأمامية للتأكد من أن القيم في الطلبات الفعلية كما هو متوقع. بعد التعديل، قم بإعادة بناء كل العامل لمنع العمليات الموجودة من الاستمرار في الاحتفاظ بالحالة القديمة.

إذا اخترت تعديل `php.ini` مباشرة، فيجب تغيير بناء الجملة إلى:

```ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off
```

على عكس `php_admin_value` في التجمع، فإن مجرد تعيين `memory_limit=-1` في `php.ini` لا يمنع التطبيق من تعديله مرة أخرى. يجب التحقق من إطار العمل ورمز التطبيق والتكوينات الأخرى لمعرفة ما إذا كانوا قد قاموا بإعادة تعيين القيمة المحدودة؛ عندما يكون التنفيذ مطلوبًا، استخدم إعدادات مستوى الإدارة المناسبة لـ SAPI الحالي وتحقق من القيمة الفعالة الفعلية. [S11](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-12)

قم بإضافة `fatal_error_backtraces = Off` فقط لـ PHP 8.5. لا تستخدم `ini_set()` على مستوى التطبيق كحل بديل لتعطيل تقدم التحميل، ولا تعتمد على FPM `.user.ini` لجعله فعالاً قبل تحليل الطلب. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)

### 5.3 إدارة تكلفة إزالة حدود الذاكرة PHP

يعد `memory_limit=-1` بمثابة تخفيف مؤقت للمسار للبيئات غير الثابتة ويجب ألا يتم نسخه كتكوين افتراضي طويل المدى. عندما يخرج تطبيق أو طلب عن السيطرة، فإنه يمكن أن يستخدم المزيد من ذاكرة المضيف. لذلك، قبل الاستخدام، يجب عليك تقييم عدد التزامنات وذروة العامل الفردي وإجمالي سعة الخدمة ونشر حدود إدخال الواجهة الأمامية. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)

يمكن أن توفر حدود ذاكرة الحاوية أو مجموعة cgroup حدود التوفر ولكنها لا تضمن عدم فشل التخصيصات أبدًا؛ قد يتم أيضًا إنهاء الحاوية بأكملها والرئيسية وكل العاملين عند تشغيل الحد. يجب تقييم دقة العزل واستراتيجيات الإنهاء جنبًا إلى جنب مع النشر ولا يمكن تسميتها بالحماية الكاملة لهاتين CVE. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)

لا تستبدل الاستراتيجيات المذكورة أعلاه بـ `RLIMIT_AS` أو `RLIMIT_DATA` أو قيود مساحة عنوان العملية المقابلة؛ فقد تتسبب بشكل مباشر في فشل التخصيص الأساسي في مسار OOM الذي لا يزال يمثل مشكلة. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)

### مثال لتكوين 5.4 Nginx

ينطبق على النشر حيث يقوم Nginx بإعادة توجيه الطلبات إلى PHP-FPM. يمكن ضبطه على مستوى التكوين لخدمة الاستضافة الفعلية:

```nginx
client_max_body_size 8m;
fastcgi_request_buffering on;
```

`client_max_body_size` يحد من حجم نص الطلب؛ يتيح `fastcgi_request_buffering on` لـ Nginx قراءة نص الطلب الكامل أولاً ثم إرساله إلى الواجهة الخلفية لـ FastCGI. ما إذا كان سيتم تفعيله في `server` أو `location` معين، فيجب التحقق منه جنبًا إلى جنب مع علاقات الميراث والتغطية الحالية. [S13](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-14)

**فقط عندما لا تحتاج الشركة إلى أجزاء متعددة**، يمكنك إضافة قاعدة رفض إلى مدخل الخدمة المقابل:

```nginx
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}
```

هذا قالب بسيط لتقييد الإدخال يستخدم `if` و`return`، وليس قاعدة تصفية عامة لثغرات المحلل اللغوي. تحقق من بناء جملة التكوين والطلبات العادية قبل النشر، وتحقق مما إذا كان `error_page` المخصص يعيد توجيه 403 طلبات إلى PHP. لا توفر مطابقة السلسلة ضمانات كاملة لجميع اختلافات التحليل. [S15](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-15)

بالإضافة إلى ذلك، لا تحد هذه التكوينات تلقائيًا من كمية البيانات أو عدد الحقول أو عدد كائنات PHP التي يمكن فك ضغطها بواسطة التطبيق؛ يجب على الشركات التي تحتاج إلى التحميل استخدام قيود إضافية تفهم بنية طلباتها.

### 5.5 التخفيف الاختياري: طلب واحد لكل عامل FPM

بالنسبة لعمليات نشر FPM التي يمكنها تحمل النفقات العامة، يمكن تقييم عمليات الإعداد قصيرة المدى:

```ini
pm.max_requests = 1
```

وإعادة بناء العامل الموجود. فهو يحظر سلسلة الطلبات المشتركة الموصوفة على مستوى إعادة استخدام العامل، ولكنه سيزيد من تكلفة إنشاء العملية والتهيئة؛ وفي الوقت نفسه، لا يمكنه إصلاح نفس الطلب OOM ومشكلات التنظيف الخاصة بـ CVE-2026-109618. عندما تكون القيمة أصغر ولكن أكبر من 1، لا تزال هناك نافذة لإعادة استخدام الطلب. [S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-11)

### حدود التغطية 5.6 WAF وCloudflare

أعلنت Cloudflare عن ترتيبات النشر للحماية من PHP2Shell، بما في ذلك خطة Free. عند استخدام خدماته، يجب عليك التحقق مما إذا كانت حركة المرور الفعلية تمر عبر الوكيل، وما إذا كانت قواعد الحماية سارية، وما إذا كان من الممكن تجاوز الموقع الأصلي مباشرة؛ بالنسبة للخطط المدفوعة، تحتاج أيضًا إلى التحقق من التكوين والاستثناءات الخاصة بالقواعد المُدارة المقابلة. [S16](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-16)

تستخدم بعض عمليات الاكتشاف التي وصفها البائع إشارات الاستجابة، لذلك لا يمكن تفسير جميع عمليات الحماية على أنها "يتم حظر كل هجوم قبل الوصول إلى PHP". يمكن أن يساعد WAF في تقليل التعرض وتوفير معلومات المراقبة، لكن الترقيات المستمرة إلى PHP لا تزال ضرورية. [S16](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-16)

### 5.7 لماذا التدابير المشتركة غير كافية؟

| التدابير أو الأحكام                                        | أوجه القصور                                                                                               |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| أغلق فقط `file_uploads`                                    | لا يمكن تغطية جميع عمليات المعالجة متعددة الأجزاء وتطبيق مسار OOM الخاص به                                |
| إعداد `enable_post_data_reading=Off`                       | تغيير سلوك ملء POST/FILES تلقائيًا؛ لا يزال من الممكن قراءة نص الطلب بواسطة التطبيق وقد يعطل العمل العادي |
| قم بإيقاف تشغيل عرض الأخطاء أو تسجيل الدخول أو استخدام `@` | قد تستمر المعالجة التشخيصية الداخلية في الوصول إلى الحالة المتدلية                                        |
| زيادة كمية العامل                                          | لا تقم بإنشاء آلية آمنة لتنظيف الحالة، ولا تمنع إعادة استخدام عامل واحد                                   |
| قم بتكوين `disable_functions` أو `open_basedir` فقط        | لا تعمل هذه القيود على إصلاح تلف ذاكرة طبقة المحرك C                                                      |
| تحقق فقط من الإصدار أو نسخة واحدة مرة واحدة                | لا يمكن إثبات أنه تم استبدال كافة المداخل والمثيلات قيد التشغيل                                           |
| لا يتم رؤية أية سجلات استثناء                              | ولا يمكن إثبات عدم وجود الثغرة الأمنية أو أنه لم يتم استغلالها من قبل.                                    |

من بينها، يمكن العثور على أساس آلية التكوين والضعف لـ PHP في [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-12)؛ وتستند الأحكام المتعلقة بحدود التغطية والقبول والإذن إلى اقتراحات التنفيذ التي تطرحها هذه الآليات.

## 6. تنفيذ أفكار ومراجعة نقاط التصحيح الرسمي

### 6.1 استخدم الإصلاحات الكاملة للفرع الصحيح

التقديم الرسمي التمثيلي لـ PHP 8.5 هو:

```text
31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout
```

يقوم الالتزام بشكل صريح بربط اثنين من CVEs، وذلك لضبط آلية الخروج OOM ولإصلاح الحالة العامة التي يمكن الوصول إليها أثناء مرحلة التهيئة. قم بإرسال الصفحة مع الفرق الكامل، راجع [S4](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5). يجب على الفروع الأخرى استخدام إصدارات الأمان الرسمية الخاصة بها أو التصحيحات المطابقة، ولا يمكن افتراض أن التغييرات التي تم إجراؤها على 8.5 يمكن تطبيقها مباشرة على أي إصدار أقدم.

### إصلاح 6.2 OOM: استعادة الحالة القابلة للمعالجة أولاً، ثم إنهاء الطلب

يقدم التنفيذ الرسمي مستويين من معالجة OOM الناعمة والصعبة: عند الوصول إلى الحد الناعم، يتم تسجيل الحالة المعلقة، ويتم تنفيذ خروج متحكم فيه في مكان آمن مثل VM؛ تسمح واجهة التخصيص الفاشلة للمتصل بمعالجة الفشل بشكل صريح. بالنسبة للتخصيصات التي لا يمكنها إرجاع الفشل بشكل مباشر، إذا كان من المتوقع تجاوز حد ثابت أعلى، فسيتم إنهاء العملية مباشرة لتجنب الاستمرار في معالجة الطلبات في حالة متوسطة غير آمنة. [S2](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

ما يلي هو مقتطف من رمز المفتاح في فرق 8.5 المستخدم لوضع علامة على OOM المعلقة:

```c
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);
```

معالجة المقاطعة VM والمواقع الآمنة الأخرى تتصل لاحقًا بـ `zend_handle_delayed_oom()`. يستخدم سياق تنفيذ تعليمات برمجية المستخدم الخاص به مسارًا للاسترخاء يمكن التحكم فيه؛ يستدعي المسار الثابت OOM `_exit(137)`. [S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

من منظور التصميم، التغييرات المهمة هي: **يتجنب عبور مكدس استدعاءات C بشكل تعسفي عندما تكون البنية في حالة متوسطة، ويضع المخرج في موقع** الذي يمكنه الحفاظ على قيود الحالة. بعد تشغيل الحد الناعم، قد تكون هناك حاجة إلى ذاكرة إضافية لإكمال العملية، لذلك لا يمكن فهم العتبة الناعمة الجديدة على أنها حد أعلى مطلق للذاكرة الإجمالية للعملية.

ولا يمكن تلخيصها على النحو التالي: "لقد قام PHP بحذف كافة `zend_bailout()`". لا يزال التصحيح يستخدم الآليات ذات الصلة في سياقات محددة؛ ما تم إصلاحه هو توقيت الخروج الخطير وإدارة الدولة المصاحبة له. [S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

### 6.3 تحديث استدعاءات التخصيص والتحليل متعدد الأجزاء معًا

إذا قمت فقط بتغيير وظيفة التخصيص إلى "إرجاع NULL عند الفشل" وما زال المتصل الأصلي يفترض أنه يتم إرجاع مؤشر صالح دائمًا، فسوف تقدم وصولاً جديدًا للمؤشر الفارغ أو تنظيفًا غير كامل. يجب مراجعة واجهة التخصيص الفاشلة في التصحيح مع التحقق من المتصل ونشر الاستثناء. [S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

تتضمن الإصلاحات ذات الصلة متعددة الأجزاء أيضًا إجراء فحوصات تراكمية استنادًا إلى حجم القراءة الفعلي، وتقليل معالجة الرؤوس غير المفيدة أو المكررة، واعتماد منطق الخروج والتنظيف المتسق عندما يكون OOM معلقًا. تقلل هذه التغييرات من تضخيم الموارد وتجعل المحلل اللغوي متوافقًا مع بروتوكول OOM الجديد. [S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

بالنسبة للفرق التي تحتفظ بفروعها الخاصة، يوصى بأن تكون المشكلات التالية هي محور مراجعة التعليمات البرمجية:

- هل الحالة مرئية للعالم الخارجي قبل تهيئتها بالكامل؟
- بعد فشل التخصيص أو استثناء رد الاتصال، هل تظل الملكية فريدة ولا لبس فيها؟
- هل يمكنك الوصول إلى مخرج التنظيف الموحد إذا فشلت في منتصف الطريق؟
- هل يمكن لوظيفة التنظيف التعرف على الحقول غير المهيأة أو المحررة؟
- هل تعتمد ميزانية التحليل على حجم المعالجة الفعلي، وليس فقط على مطالبات طلبات الثقة؟
- هل تمت معالجة قيمة إرجاع الفشل الجديدة من قبل جميع المتصلين؟

هذه أسئلة مراجعة تم تلخيصها استنادًا إلى آلية الإصلاح، وليست نتيجة للتدقيق الذي تم إكماله لقاعدة تعليمات برمجية غير متوفرة.

### إصلاح الطلب المتبادل 6.4: التهيئة مسبقًا، والتنظيف النهائي لاحقًا

بالتوافق مع CVE-2026-109619، يقوم التصحيح بضبط حدود دورة الحياة المتعددة في نفس الوقت. الملفات والعمليات المذكورة أدناه تأخذ الفرق الرسمي PHP 8.5 كمثال. [S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

| الموقع                         | تغيير الاتجاه                                                                      | تم حل المشكلة                                                                       |
| ------------------------------ | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `Zend/zend_execute_API.c` الخ. | إعادة تعيين حالة المنفذ مثل الأخطاء والاستثناءات والمعالجات والكائنات وما إلى ذلك. | وبعد انتهاء الطلب، لا تزال هناك مراجع قديمة يمكن الوصول إليها عن طريق الطلب التالي. |
| مسار بدء تشغيل `main/main.c`   | اتصل بـ `php_basic_early_rinit()` قبل تنشيط SAPI                                   | عند حدوث مستهلك مبكر، لم تتم بعد تهيئة الحالة الأساسية ذات الصلة.                   |
| إغلاق المسار `main/main.c`     | قم بتدمير HTTP globals ووضع علامة عليه على أنه غير محدد                            | لا تزال القيمة التي تم إصدارها تعتبر كائنًا صالحًا                                  |
| قبل تحرير كومة الطلب أخيرًا    | قم بتنظيف رسالة الخطأ الأخيرة مرة أخرى                                             | تقوم تشخيصات التنظيف المتأخرة بإعادة ملء حالة الخطأ                                 |
| `ext/session/session.c`        | تقدم التحميل تتم تهيئة المسار المبكر للجلسة الأولى                                 | الوحدة العادية RINIT وصلت سابقًا إلى الحالة القديمة                                 |
| الكود المتعلق بالتسلسل         | الحد من تحليل الفئة وعمليات رد اتصال المستخدم في المعالجة المبكرة                  | قم بتنفيذ رمز مستخدم إضافي عند عدم اكتمال التهيئة                                   |

على سبيل المثال، يتضمن تسلسل بدء التشغيل ما يلي:

```c
zend_activate();
php_basic_early_rinit();
sapi_activate();
```

بعد تدمير HTTP globals، أضف علامة فشل الحالة:

```c
zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);
```

توضح هذه المقتطفات مبدأين: **initialize قبل أقرب مستخدم ممكن، وإجراء التنظيف النهائي بعد العملية الأخيرة التي قد تعيد إنشاء الحالة.** قد تؤدي إعادة تعيين المؤشر فقط أثناء RINIT العادي أو مرحلة إيقاف التشغيل السابقة إلى تفويت عمليات الوصول السابقة أو اللاحقة. [S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

### 6.5 لماذا لا يُنصح بإجراء "إصلاح سطر واحد" خاص بك؟

إن استبدال كل `zend_bailout()` بـ `_exit()`، أو مجرد إضافة فحص مؤشر فارغ عند إدخال معين، من شأنه أن يمتد إلى عدد كبير من سياقات التنفيذ المختلفة. قد يحذفون حقول الحالة الأخرى، أو قد يغيرون التدمير، وعمليات الاسترجاعات الموسعة، ومعالجة الاستضافة، وطلب دلالات النهاية.

بالنسبة للإصدارات المدعومة، تكون الأولوية للإصلاحات الكاملة التي تم إصدارها بالفعل. يجب أن يسجل ترحيل الفروع الخاصة مصدر التصحيحات وخطوط الأساس القابلة للتطبيق ومعالجة التعارض وتغييرات السلوك، واستخدام حالات استخدام الانحدار الأولي المقابلة والتحقق من عملية الأعمال هذه. تأتي الاقتراحات هنا من تحليل نطاق التصحيح عبر المخصص، VM، والجلسة وتغييرات دورة حياة الطلب. [S4](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-5)

## 7. المنفذ الخلفي للطوارئ PHP 7.4، 8.0، 8.1

يوفر PHP رسميًا الحد الأدنى من المنفذ الخلفي للكود المصدري لثلاثة فروع قديمة بناءً على مدى خطورته. أسماء الفروع هي:

```text
PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619
```

للحصول على روابط الفروع، راجع [S7](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-9). هذه عمليات تسليم طارئة لهذه الثغرة الأمنية ولا تمثل عودة إلى الدعم الأولي المنتظم للفرع القديم، كما أنها لا تحل محل التحديثات الأمنية الأخرى. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)

### 7.1 خذ المنفذ الخلفي PHP 8.1 كمثال

التقديمات ذات الصلة بـ PHP 8.1 هي:

```text
1d7dec178a094e6e75b229ce22754045f8c6070a
```

تفضل استراتيجيتها الفشل السريع: استدعاء `_exit(1)` بعد إخراج التشخيصات في مسار OOM المقابل، بما في ذلك الحالة العالمية والتصحيحات الأخرى ذات الصلة؛ أثناء التعطيل الداخلي للمعالجة المقابلة لتقدم تحميل الجلسة. للحصول على كود المصدر ذي الصلة، راجع [S6](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-6).

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

### 7.2 السعر الذي يتعين عليك قبوله عند النشر

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

لذلك، يجب على مستخدمي الإصدارات الأقدم مراعاة ما يلي:

1. قم بالترحيل إلى فرع PHP المدعوم وإصداره الثابت.
2. استخدم إصدارًا يغطي بشكل صريح كلاً من CVE أو تحديث الشركة المصنعة LTS.
3. إذا كان خاضعًا بالفعل للإصدار القديم من كود المصدر، فاستخدم المنفذ الخلفي الرسمي للطوارئ للإصدار المطابق للتحقق من التغييرات الكاملة والتوافق، وترتيب الترحيل اللاحق.

يصف "الحد الأدنى من المنفذ الخلفي" هنا نطاق التوافق والتنفيذ الذي اختاره المسؤول، ولا ينبغي تفسيره تلقائيًا على أنه "إصلاحات غير كاملة معروفة للثغرات الأمنية". يجب عليك الحكم بناءً على الكود المصدري للفرع المقابل وإعلان الشركة المصنعة، ولا تحذف التغييرات الداعمة بنفسك. [S1](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/ar/insights/php2shell-remediation-guide#source-6)

## 8. معايير القبول ومتابعة عمليات التفتيش

يوصى باستخدام النتائج التالية كأساس لاستكمال هذا الإصلاح:

| بنود القبول                | معايير الإنجاز                                                                                                        |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| تغطية الضعف                | يعمل إعلان البناء أو البائع بشكل صريح على إصلاح CVE-2026-109618 وCVE-2026-109619                                      |
| تغطية النشر                | تستخدم جميع البوابات والتجمع والخدمات والنسخ المتماثلة وقت التشغيل الذي تم إصلاحه                                     |
| تصبح العملية سارية المفعول | يخرج كل من العامل القديم وعملية المضيف القديمة والحاوية القديمة                                                       |
| التحقق من صحة الطلب        | تم تأكيد SAPI، وتم إنشاؤه وتكوينه باستخدام رابط Web الفعلي لإزالة التوجيه الخاطئ لذاكرة التخزين المؤقت                |
| توافر الأعمال              | لقد عادت الوظائف الأساسية مثل الجلسة والتحميل والاستيراد ومعالجة الأخطاء بشكل طبيعي.                                  |
| إنهاء التدابير المؤقتة     | تمت استعادة الذاكرة غير المحدودة وتكوينات إعادة التدوير القصوى للعمال وفقًا لخطة السعة أو لديها سبب واضح للاحتفاظ بها |
| دليل على التغيير           | قم بتسجيل إصدار الحزمة أو ملخص الصورة ونطاق التحديث ووقت الانتهاء ونتائج التحقق                                       |

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

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

## ملحق: المصادر والروابط المذكورة

يتم جمع كافة الروابط المصدر أدناه. تعكس التحذيرات والتصحيحات وإرشادات البائع عمليات التحقق اعتبارًا من **22 أكتوبر 2026**؛ يجب أن تتحقق عمليات النشر اللاحقة من تحديثات البائع. تشير الاستشهادات المرقمة في النص إلى هذه الإدخالات.

### S1 - نشرة الأمان الرسمية وإصدار الإصلاح PHP

- المصدر: مشروع PHP، 21 أكتوبر 2026.
- الغرض: نطاق المخاطر، وأربعة إصدارات إصلاح رسمية، وإجراءات مؤقتة رسمية، وتعليمات الطوارئ للفروع القديمة.
- المرجع: [PHP 2026 This security bulletin](https://www.php.net/archive/2026.php#2026-10-21-5) موجود في أرشيف النشرة السنوية

### S2 — النشرة الفنية الرسمية CVE-2026-109618

- المصدر: php/php-src GitHub Security Advisory، 21 أكتوبر 2026.
- تحديد الهوية: GHSA-w8hw-w9fx-j79w.
- الغرض: حدود التغطية لـ OOM، والتضخيم متعدد الأجزاء، والفرق والتخفيف من SAPI.
- المرجع: [RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

### S3 — النشرة الفنية الرسمية CVE-2026-109619

- المصدر: php/php-src GitHub Security Advisory، 21 أكتوبر 2026.
- تحديد الهوية: GHSA-6wmf-4rv5-p3rp.
- الغرض: الحالة المتدلية للطلبات المتبادلة، المنتجون والمستهلكون، التهيئة المبكرة، تخفيف التكوين.
- المرجع: [RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)

### S4 — تقديم الإصلاح الرسمي لـ PHP 8.5

- المصدر: php/php-src.
- إرسال: `31c0ea7d7ff1d1fccb6492e52dab544011628065`.
- الغرض: تأكيد التقديم الرسمي لإصلاح اثنتين من نقاط الضعف في نفس الوقت، وشرح اتجاه التغيير العام.
- المرجع: [Avoid state corruption via bailout](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065)

### S5 — PHP 8.5 تمت استعادته رسميًا وإكمال الفرق

- المصدر: يختلف عن نفس التقديم الرسمي.
- الغرض: التحقق من التنفيذ المحدد للمخصص وVM وHTTP globals والجلسة والتسلسل ودورة حياة الطلب.
- المرجع: [official complete diff](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff)

### S6 — تقديم التقرير الخلفي الرسمي للطوارئ PHP 8.1

- المصدر: php/php-src.
- إرسال: `1d7dec178a094e6e75b229ce22754045f8c6070a`.
- الغرض: التحقق من الخروج السريع للفروع القديمة وتحميل تغييرات سلوك التقدم.
- المرجع: [PHP 8.1 Emergency backport submission](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a)
- المرجع: [corresponds to complete diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff)

### S7 — فرع الطوارئ الرسمي PHP 7.4

- المصدر: php/php-src، PHP فروع كود المصدر المدرجة في النشرة الأمنية الرسمية.
- المرجع: [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619)

### S8 — فرع الطوارئ الرسمي PHP 8.0

- المصدر: php/php-src، PHP فروع كود المصدر المدرجة في النشرة الأمنية الرسمية.
- المرجع: [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619)

### S9 — فرع الطوارئ الرسمي PHP 8.1

- المصدر: php/php-src، PHP فروع كود المصدر المدرجة في النشرة الأمنية الرسمية.
- المرجع: [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619)

### S10 — النشرة الأمنية Ubuntu USN-8948-1

- المصدر: Canonical / Ubuntu، 21 أكتوبر 2026.
- الغرض: إصدار backport وأمثلة إصدار الحزمة الكاملة.
- المرجع: [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1)

### S11 - دليل PHP-FPM Configuration

- المصدر: الوثيقة الرسمية PHP.
- الغرض: دلالات التكوين مثل `php_admin_value`، `php_admin_flag`، `pm.max_requests`، إلخ.
- المرجع: [PHP-FPM Configuration](https://www.php.net/manual/en/install.fpm.configuration.php)

### S12 - دليل التكوين PHP الأساسي INI

- المصدر: الوثيقة الرسمية PHP.
- الغرض: تعريف ونطاق نص الطلب والتحميل والذاكرة وتكوين قراءة POST التلقائي.
- المرجع: [Description of core php.ini directives](https://www.php.net/manual/en/ini.core.php)

### S13 — Nginx يطلب حدًا لحجم الجسم

- المصدر: الوثيقة الرسمية Nginx.
- الغرض: معنى `client_max_body_size` ومستويات التكوين المتاحة.
- المرجع: [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)

### S14 - المخزن المؤقت للطلب Nginx FastCGI

- المصدر: الوثيقة الرسمية Nginx.
- الغرض: تسلسل المعالجة ووظيفة `fastcgi_request_buffering`.
- المرجع: [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering)

### S15 — Nginx تعليمات الحالة والإرجاع

- المصدر: الوثيقة الرسمية Nginx.
- الغرض: بناء جملة التكوين لـ `if` و`return`.
- المرجع: [ngx\_http\_rewrite\_module](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if)

### S16 — تعليمات الحماية Cloudflare PHP2Shell

- المصدر: المدونة الرسمية Cloudflare.
- الغرض: وصف نطاق نشر WAF وترتيب خطة Free وآلية الكشف.
- المرجع: [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)

## استشارة صيانة الأمن

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

[مناقشة التحديثات الأمنية](<https://keendigit.com/ar/contact?service=security-remediation#form>)

[الصفحة الأصلية](<https://keendigit.com/ar/insights/php2shell-remediation-guide>) · [فهرس المحتوى](<https://keendigit.com/ar/llms.txt>)

KeenDigit LLC · معرف الايداع وايومنغ: 2026-002106155

[تحقق مع وزير خارجية وايومنغ](<https://wyobiz.wyo.gov/Business/filingSearch.aspx>)

© 2026 KeenDigit LLC · شيريدان، وايومنغ، الولايات المتحدة الأمريكية · جميع الحقوق محفوظة.