---
title: "PHP2Shell: ثغرتين بقلب PHP، وليش تحديث WordPress لحاله ما بيحميك"
description: "ثغرتين PHP2Shell بـ PHP نفسه، مش بـ WordPress. الحل PHP على 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35 أو أحدث، أو حزمة توزيعة فيها الإصلاح. حدّثه أو اطلبه من الاستضافة اليوم."
url: https://ihsanalapsi.dev/articles/php2shell-php-rce
lang: ar
date: 2026-10-21
updated: 2026-10-21
tags: ["أمن التطبيقات", "PHP", "WordPress"]
author: Ihsan Alapsi (إحسان العبسي)
---
# PHP2Shell: ثغرتين بقلب PHP، وليش تحديث WordPress لحاله ما بيحميك

فريق <span dir="ltr">PHP</span> نزّل يوم 21 تشرين الأول 2026 تحديث أمني طارئ لثغرتين ممكن يسمحوا لمهاجم يشغّل كود على السيرفر بلا ما يسجّل دخول. إذا موقعك على <span dir="ltr">WordPress</span> أو <span dir="ltr">Laravel</span> أو أي شي مبني بـ <span dir="ltr">PHP</span>، أول شي بدك تعرفه رقم نسخة <span dir="ltr">PHP</span> عندك، بعدين شو تبعت للاستضافة، وشو تعمل إذا نسختك ما عاد إلها تحديثات.

## شو هي ثغرة <span dir="ltr">PHP2Shell</span>؟

<span dir="ltr">PHP2Shell</span> اسم لثغرتين بـ <span dir="ltr">PHP</span> نفسه، <span dir="ltr">CVE-2026-109618</span> و<span dir="ltr">CVE-2026-109619</span>، ممكن يخلّوا مهاجم ما سجّل دخول يشغّل كود على السيرفر. فريق <span dir="ltr">PHP</span> قيّم الثنتين 9.2 من 10 على مقياس <span dir="ltr">CVSS v4.0</span>.

هالنوع من الثغرات اسمه <span dir="ltr">RCE</span>، يعني تنفيذ كود عن بعد: المهاجم بيبعت طلب للموقع، والسيرفر بينفّذ أوامره بصلاحيات <span dir="ltr">PHP</span>. المشكلة بالثنتين، حسب [الإعلان الأمني على <span dir="ltr">php.net</span>](https://www.php.net/archive/2026.php#2026-10-21-5)، بكيف <span dir="ltr">PHP</span> بيتعامل مع الذاكرة لما الطلب يفشل بالنص:


| الثغرة                                             | شو بيصير جوّا <span dir="ltr">PHP</span>                                                                         | شو عرض الباحثين                                                                                                                                                 |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <span dir="ltr">CVE-2026-109618</span> | الذاكرة بتخلص والطلب لسا نص مجهّز، وتنظيف الطلب بيتعامل مع البيانات الناقصة كأنها سليمة                                      | تنفيذ كود بلا تسجيل دخول على <span dir="ltr">WordPress</span> و<span dir="ltr">Drupal</span> و<span dir="ltr">Joomla</span> |
| <span dir="ltr">CVE-2026-109619</span> | بيانات تبع طلب بتضل عايشة بعد ما تنمسح ذاكرتها، وطلب جاي على نفس الـ <span dir="ltr">worker</span> ممكن يستعملها | تنفيذ كود بلا تسجيل دخول على <span dir="ltr">WordPress</span> و<span dir="ltr">Drupal</span>                                            |


الباحثين نشروا يلي عرضوه على [موقع الكشف <span dir="ltr">php2shell.com</span>](https://www.php2shell.com/)، وهو موقع تبع <span dir="ltr">Wiz</span>. ومن يلي عرضوه كمان تسريب لذاكرة الـ <span dir="ltr">worker</span> بأي تطبيق <span dir="ltr">PHP</span>، بلا ما يشغّلوا كود. وحسبهن تقريباً كل نسخة <span dir="ltr">PHP</span> لحد <span dir="ltr">PHP 5.4</span> فيها وحدة من الثغرتين على الأقل، والخطر بيختلف حسب النسخة والإعدادات.

حسب [<span dir="ltr">PHP Foundation</span>](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/)، أول مين بلّغ فريق <span dir="ltr">PHP</span> كان <span dir="ltr">Calif</span> وفريق <span dir="ltr">Codex Security</span> تبع <span dir="ltr">OpenAI</span>، بنفس اليوم 11 آب 2026، وبعدهن <span dir="ltr">Wiz Research</span> يوم 24 آب. وأول علامات مشكلة الذاكرة لقاها مطوّر من فريق <span dir="ltr">PHP</span> سنة 2024، وقت التدقيق الأمني يلي عملته <span dir="ltr">Quarkslab</span> لـ <span dir="ltr">PHP</span>. و<span dir="ltr">Wiz</span> بتقول إنها [استعملت نماذج الـ <span dir="ltr">AI</span> طول البحث](https://www.wiz.io/blog/php2shell-php-rce)، من إيجاد الثغرة لحد كتابة الاستغلال.

## ليش تحديث <span dir="ltr">WordPress</span> والإضافات ما بيكفي؟

تحديث <span dir="ltr">WordPress</span> والإضافات ما بيكفي لأنو الثغرتين بـ <span dir="ltr">PHP</span>، البرنامج يلي بيشغّل <span dir="ltr">WordPress</span>، مش بكود الموقع. يعني كودك ممكن يكون نضيف ومحدّث، والسيرفر مكشوف.

حسب <span dir="ltr">Wiz</span>، الاستغلال ما بيحتاج غلط بكود التطبيق، وحتى صفحة <span dir="ltr">"Hello World"</span> على نسخة متأثرة ممكن تنضرب. وحسب موقع الكشف، تحديث التطبيق ما بيحدّث الـ <span dir="ltr">PHP</span> يلي تحته. تحديث الإضافات هون متل ما تغيّر أقفال الغرف، والبوابة الرئيسية للبناية مكسورة.

مين بالخطر، حسب <span dir="ltr">PHP</span>:

- كل تثبيت <span dir="ltr">PHP</span> بيخدم طلبات ويب: <span dir="ltr">PHP-FPM</span> و<span dir="ltr">Apache</span> مع <span dir="ltr">mod\_php</span> و<span dir="ltr">php-cgi</span> و<span dir="ltr">FrankenPHP</span> و<span dir="ltr">LiteSpeed</span>.
- الخطر أعلى شي على <span dir="ltr">mod\_php</span>، لأنو في استغلال انعرض عليه بيشتغل بطلب من حدا ما سجّل دخول، قبل ما يشتغل أي سطر من كود التطبيق.
- الباحثين جرّبوا على <span dir="ltr">WordPress</span> و<span dir="ltr">Drupal</span> و<span dir="ltr">Joomla</span> كأمثلة، وقالوا إنو الاستغلال ما بيحتاج واحد منهن. <span dir="ltr">Laravel</span> و<span dir="ltr">Symfony</span> و<span dir="ltr">Moodle</span> و<span dir="ltr">Nextcloud</span> كمان شغّالين على <span dir="ltr">PHP</span>.

أما الموقع المبني بلا <span dir="ltr">PHP</span>، متل مشاريع <span dir="ltr">Next.js</span> يلي بتلاقي أمثلة عنها بـ [صفحة المشاريع](/work)، فالثغرتين ما بيلمسوه، إلا إذا في <span dir="ltr">PHP</span> شغّال جنبه على نفس السيرفر: <span dir="ltr">phpMyAdmin</span> مثلاً، أو مدونة <span dir="ltr">WordPress</span> على دومين فرعي.

## كيف بعرف إذا موقعي متأثر؟

موقعك متأثر إذا نسخة <span dir="ltr">PHP</span> يلي بتخدمه أقدم من أول نسخة مصلّحة بفرعها (مثلاً أي 8.3 قبل 8.3.36)، إلا إذا <span dir="ltr">PHP</span> جاي من حزم التوزيعة وفيها الإصلاح، وهاد بتفحصه تحت. بدك الرقم الكامل بتلات خانات، لأنو الإصلاح بآخر خانة.


| الفرع     | أول نسخة مصلّحة                                          | الدعم الأمني لحد    |
| --------- | -------------------------------------------------------- | ------------------- |
| 8.5       | 8.5.12                                                   | 31 كانون الأول 2029 |
| 8.4       | 8.4.27                                                   | 31 كانون الأول 2028 |
| 8.3       | 8.3.36                                                   | 31 كانون الأول 2027 |
| 8.2       | 8.2.35                                                   | 31 كانون الأول 2026 |
| 8.1 وأقدم | ما في إصدار رسمي (في إصلاحات مصدرية لـ 7.4 و8.0 و8.1 بس) | خلص                 |


مواعيد الدعم من [جدول النسخ المدعومة على <span dir="ltr">php.net</span>](https://www.php.net/supported-versions.php). لحتى تعرف الرقم عندك، اختار الطريقة يلي بتناسبك:

- بـ <span dir="ltr">WordPress</span>، افتح <span dir="ltr">Tools</span>، وبعدين <span dir="ltr">Site Health</span>، وبعدين تبويب <span dir="ltr">Info</span>، ووسّع قسم <span dir="ltr">Server</span>. سطر <span dir="ltr">PHP version</span> بيعطيك النسخة يلي شغّالة على موقعك.
- بلوحة <span dir="ltr">cPanel</span>، أداة <span dir="ltr">MultiPHP Manager</span> بتورجيك نسخة <span dir="ltr">PHP</span> لكل دومين. إذا طلعلك الفرع بس (8.3 مثلاً)، كمّل بالطريقة الجاية لحتى تعرف الرقم الكامل.
- لأدق رقم، اعمل ملف بالمجلد الرئيسي للموقع باسم صعب ينحزر، حط فيه السطر تحت، وافتحه بالمتصفح. بيطلعلك رقم النسخة لحاله. احذف الملف أول ما تشوف الرقم.
  ```
  <?php echo phpversion();
  ```

  إذا استعملت `phpinfo()` بدالو، احذفه كمان: الصفحة بتعرض إعدادات السيرفر ومتغيرات البيئة والـ &lt;span dir="ltr"&gt;headers&lt;/span&gt;، وهي معلومات بتفيد المهاجم.
- على سيرفر إلك، `php -v` بيعطيك نسخة سطر الأوامر، وهي ممكن تختلف عن النسخة يلي بتشغّل الموقع عن طريق &lt;span dir="ltr"&gt;PHP-FPM&lt;/span&gt;. [&lt;span dir="ltr"&gt;Sansec&lt;/span&gt;](https://sansec.io/research/php2shell) بتنصح تتأكد من إعدادات &lt;span dir="ltr"&gt;PHP-FPM&lt;/span&gt; بطلب بيمرق عليه، مش من سطر الأوامر. ورقم النسخة كمان: الملف المؤقت أدق من `php -v`.

إذا السيرفر بياخد &lt;span dir="ltr"&gt;PHP&lt;/span&gt; من مستودع التوزيعة (&lt;span dir="ltr"&gt;Ubuntu&lt;/span&gt; أو &lt;span dir="ltr"&gt;Debian&lt;/span&gt; مثلاً)، الرقم ممكن يضل شكله قديم والإصلاح جوّاه، حسب [&lt;span dir="ltr"&gt;The Hacker News&lt;/span&gt;](https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html). دوّر على رقم الثغرة بسجل تغييرات الحزمة (اسم الحزمة بيختلف حسب نسختك):

```bash
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'
```

## شو لازم أعمل هلق؟

حدّث &lt;span dir="ltr"&gt;PHP&lt;/span&gt; لأول نسخة مصلّحة بفرعك، وأعد تشغيل كل شي بيشغّل &lt;span dir="ltr"&gt;PHP&lt;/span&gt;. على استضافة مشتركة، الاستضافة بتحدّث وإنت بتطلب منها؛ وعلى سيرفر إلك، إنت بتحدّث.

### على استضافة مشتركة

هون ما فيك تركّب التحديث بنفسك، هاد شغل الاستضافة. بس إذا لوحتك &lt;span dir="ltr"&gt;cPanel&lt;/span&gt; ونسختك 8.1 أو أقدم، أداة &lt;span dir="ltr"&gt;MultiPHP Manager&lt;/span&gt; [بتخليك تنقل الدومين](https://docs.cpanel.net/cpanel/software/multiphp-manager-for-cpanel/) لفرع أحدث من النسخ يلي مركّبتها الاستضافة.

وإذا الاستضافة هي يلي بتدير &lt;span dir="ltr"&gt;PHP&lt;/span&gt;، &lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt; بتنصح تطلب منها تطبّق التحديث. ابعت هالرسالة لفريق الدعم اليوم، وإذا الدعم عندهم بالعربي ترجمها بنفس النقاط:

```
Subject: PHP2Shell (CVE-2026-109618, CVE-2026-109619): please confirm the PHP patch

Hello,

PHP released security fixes on 21 October 2026 for CVE-2026-109618 and
CVE-2026-109619 (PHP2Shell, unauthenticated remote code execution).

For my account and the domain [your domain], please confirm:
1. Which PHP version serves my site, with the full number (for example 8.3.36).
2. When you will update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or confirm
   that your PHP package includes the fixes for both CVEs), and restart
   PHP-FPM / Apache after the update.
3. If my site runs PHP 8.1 or older: whether you apply a backported fix,
   or which supported version I can move to.

Thank you.
```

لما يردّوا، افحص الرقم بنفسك بوحدة من الطرق فوق.

### على سيرفر إلك

1. اعمل لستة بكل مكان فيه &lt;span dir="ltr"&gt;PHP&lt;/span&gt; عندك، مش بس الموقع. &lt;span dir="ltr"&gt;Huntress&lt;/span&gt; بتنبّه إنو &lt;span dir="ltr"&gt;PHP&lt;/span&gt; ممكن يكون مخبّى جوّا برامج جاهزة: لوحات متل &lt;span dir="ltr"&gt;cPanel&lt;/span&gt; و&lt;span dir="ltr"&gt;Plesk&lt;/span&gt;، وبرامج &lt;span dir="ltr"&gt;Windows&lt;/span&gt; فيها `php.exe` أو `php-cgi.exe`. بآخر هالخطوة بتعرف شو لازم يتحدّث.
2. حدّث من مستودع التوزيعة أو ابني من المصدر. &lt;span dir="ltr"&gt;PHP&lt;/span&gt; بتقول إنو التوزيعات وشركات الـ &lt;span dir="ltr"&gt;LTS&lt;/span&gt; وصلها الإصلاح قبل الإعلان، فشغّل أمر التحديث العادي، وإذا ما نزلت حزم جديدة تابع صفحة الأمان تبع توزيعتك.
3. إذا بتاخد &lt;span dir="ltr"&gt;PHP&lt;/span&gt; من مستودع &lt;span dir="ltr"&gt;Remi&lt;/span&gt; (&lt;span dir="ltr"&gt;rpms.remirepo.net&lt;/span&gt;)، انتقل لحزم التوزيعة أو ابني من المصدر: &lt;span dir="ltr"&gt;PHP&lt;/span&gt; نصحت بهالشي لأنو المستودع ما كان عنده تحديث يوم 21 تشرين الأول.
4. أعد تشغيل &lt;span dir="ltr"&gt;PHP-FPM&lt;/span&gt; و&lt;span dir="ltr"&gt;Apache&lt;/span&gt; وأي &lt;span dir="ltr"&gt;worker&lt;/span&gt; بيضل شغّال لفترة طويلة، متل ما بيطلب موقع الكشف.
5. إذا عندك &lt;span dir="ltr"&gt;PHP&lt;/span&gt; جوّا صور &lt;span dir="ltr"&gt;Docker&lt;/span&gt;، ابني الصور من جديد على صورة أساس فيها النسخة المصلّحة، وانشرها.
6. تأكد من الرقم بطلب ويب (الملف المؤقت فوق)، مش بـ `php -v` لحاله.
7. راجع `memory_limit` بعد التحديث: الإصلاح بيضيف حد ذاكرة صارم، ولما العملية توصله بتنقتل وما بيشتغل الـ &lt;span dir="ltr"&gt;shutdown handlers&lt;/span&gt; تبعها. إذا عندك سكربتات بتاكل ذاكرة كتير، جرّبها. وإذا حطيت `memory_limit=-1` كإجراء مؤقت (تحت)، رجّعه لقيمة محددة بعد التحديث: بـ `-1` طلب واحد ممكن ياكل كل ذاكرة السيرفر، حسب &lt;span dir="ltr"&gt;Sansec&lt;/span&gt;.

### إذا نسختك 8.1 أو أقدم

8.1 والنسخ الأقدم منها ما عاد ياخدوا تحديثات من مشروع &lt;span dir="ltr"&gt;PHP&lt;/span&gt;. فريق &lt;span dir="ltr"&gt;PHP&lt;/span&gt; نشر إصلاحات مصدرية صغيرة (&lt;span dir="ltr"&gt;backports&lt;/span&gt;) لـ 7.4 و8.0 و8.1، بس هي لمين بيبني &lt;span dir="ltr"&gt;PHP&lt;/span&gt; من المصدر أو ما عنده شركة &lt;span dir="ltr"&gt;LTS&lt;/span&gt;. وبعض التوزيعات وشركات الـ &lt;span dir="ltr"&gt;LTS&lt;/span&gt; عندها إصلاحات منقولة، فاسأل مزوّدك.

الحل يلي بيدوم هو النقل لفرع مدعوم. والـ 8.2 كمان بيخلص دعمه 31 كانون الأول 2026، فإذا رح تنقل هلق، روح على 8.3 أو أحدث لحتى ما تعيد النقل بعد شهرين. جرّب الموقع على نسخة تجريبية قبل ما تبدّل، لأنو إضافة قديمة ممكن ما تشتغل على فرع أحدث. ولحد ما تنقل، [&lt;span dir="ltr"&gt;Huntress&lt;/span&gt;](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities) بتنصح تعزل أي &lt;span dir="ltr"&gt;PHP&lt;/span&gt; منتهي دعمه عن الإنترنت.

## هل الإعدادات المؤقتة و&lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt; بيحموني لحد ما حدّث؟

الإعدادات المؤقتة وقواعد &lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt; بيخففوا الخطر، بس ما بيسكّروا الثغرة. التحديث هو الحل الكامل الوحيد، حسب الإعلان الأمني تبع &lt;span dir="ltr"&gt;PHP&lt;/span&gt;:

> &lt;span dir="ltr"&gt;"While only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe."&lt;/span&gt;

بالعربي: هالإجراءات بتسكّر طرق هجوم محددة بس، والتثبيت بيضل مش آمن. إذا ما فيك تحدّث اليوم وعندك وصول لإعدادات السيرفر، هاي الإعدادات يلي نشرتها &lt;span dir="ltr"&gt;PHP&lt;/span&gt;:

- `memory_limit=-1` بطريقة ما بيقدر التطبيق يغيّرها، متل `php_admin_value` بإعدادات الـ &lt;span dir="ltr"&gt;pool&lt;/span&gt; أو &lt;span dir="ltr"&gt;Apache&lt;/span&gt;، ورجّعه لقيمة محددة بعد ما تحدّث.
- `post_max_size` منخفض: `8M` إذا موقعك ما فيه رفع ملفات، و`32M` إذا فيه.
- `session.upload_progress.enabled=0` بـ `php.ini` أو إعدادات الـ &lt;span dir="ltr"&gt;pool&lt;/span&gt;، مع إعادة تشغيل كل الـ &lt;span dir="ltr"&gt;workers&lt;/span&gt;. `ini_set()` و`.user.ini` ما بيمشوا هون.
- على 8.5 بس: `fatal_error_backtraces=0`، مع إعادة تشغيل.

[موقع الكشف](https://www.php2shell.com/) بينبّه إنو بعض هالإعدادات ممكن تأثّر على شغل التطبيق أو ثباته، فجرّبها قبل ما تعتمدها.

أما &lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt;، فنزّلت [قواعد &lt;span dir="ltr"&gt;WAF&lt;/span&gt; للثغرتين](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)، والخطة المجانية بتاخدها لحالها بلا ما تعمل شي. وعلى الخطط المدفوعة (&lt;span dir="ltr"&gt;Pro&lt;/span&gt; و&lt;span dir="ltr"&gt;Business&lt;/span&gt; و&lt;span dir="ltr"&gt;Enterprise&lt;/span&gt;)، تأكد إنو الـ &lt;span dir="ltr"&gt;Managed Ruleset&lt;/span&gt; شغّال على وضع &lt;span dir="ltr"&gt;block&lt;/span&gt;. بس &lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt; نفسها بتقول لازم تحدّث &lt;span dir="ltr"&gt;PHP&lt;/span&gt; حتى مع هالقواعد، لأنها طبقة حماية زيادة مش إصلاح. وهي شافت المهاجمين عم يغيّروا شكل طلبات الهجوم لحتى يتجاوزوا قواعدها. والقواعد بتشتغل بس على الطلبات يلي بتمرق من &lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt;: إذا سجل الـ &lt;span dir="ltr"&gt;DNS&lt;/span&gt; لموقعك على وضع &lt;span dir="ltr"&gt;DNS only&lt;/span&gt;، الطلبات [بتروح مباشرة للسيرفر](https://developers.cloudflare.com/dns/proxy-status/) و&lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt; ما بتحميها.

## هل في حدا عم يستغل الثغرة هلق؟

إي، في محاولات استغلال، بس لحد الساعة 17:27 &lt;span dir="ltr"&gt;UTC&lt;/span&gt; يوم 21 تشرين الأول 2026 ما في مصدر أكّد اختراق سيرفر محدد، حسب &lt;span dir="ltr"&gt;The Hacker News&lt;/span&gt;. &lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt; و&lt;span dir="ltr"&gt;watchTowr&lt;/span&gt; شافوا هجمات، والثغرتين لسا مش بقائمة &lt;span dir="ltr"&gt;CISA&lt;/span&gt; للثغرات المستغلة.


| الوقت (&lt;span dir="ltr"&gt;UTC&lt;/span&gt;، 21 تشرين الأول) | المصدر                                                                                                                                                                                   | شو قال                                                                                                       |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| 07:43                                                          | &lt;span dir="ltr"&gt;Cloudflare&lt;/span&gt; (حسب &lt;span dir="ltr"&gt;Sansec&lt;/span&gt;)                                                                                            | بلّغت عن هجمات أولية على مواقع &lt;span dir="ltr"&gt;PHP&lt;/span&gt; قبل نزول التحديث                       |
| 11:26                                                          | &lt;span dir="ltr"&gt;watchTowr&lt;/span&gt; (حسب &lt;span dir="ltr"&gt;The Hacker News&lt;/span&gt;)                                                                                    | ما شافت استغلال على الإنترنت                                                                                 |
| وقت الإعلان                                                    | فريق أمان &lt;span dir="ltr"&gt;PHP&lt;/span&gt; (حسب &lt;span dir="ltr"&gt;PHP Foundation&lt;/span&gt;)                                                                                 | فحص أكواد إثبات المفهوم (&lt;span dir="ltr"&gt;PoC&lt;/span&gt;) يلي انتشرت بعد التسريب، وما لقى وحدة شغّالة |
| حوالي 14:00                                                    | &lt;span dir="ltr"&gt;Huntress&lt;/span&gt;                                                                                                                                              | ما شافت استغلال عند زباينها                                                                                  |
| 14:19                                                          | &lt;span dir="ltr"&gt;watchTowr&lt;/span&gt; (حسب &lt;span dir="ltr"&gt;The Hacker News&lt;/span&gt; و[صفحة الأسئلة تبعها](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/)) | صارت تشوف محاولات استغلال للثغرتين بسيرفرات الفخ (&lt;span dir="ltr"&gt;honeypots&lt;/span&gt;) تبعها        |
| 17:27                                                          | [قائمة &lt;span dir="ltr"&gt;CISA KEV&lt;/span&gt;](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)                                                                        | الثغرتين مش فيها (نسخة القائمة 2026.10.21)                                                                   |


ما تستنى تأكيد الاستغلال لحتى تحدّث. حسب &lt;span dir="ltr"&gt;PHP Foundation&lt;/span&gt;، فيديو بيورجي استغلال شغّال انتشر بالغلط مسا 20 تشرين الأول وسرّع شغل الناس على الاستغلال، و&lt;span dir="ltr"&gt;Sansec&lt;/span&gt; بتقول إنو الشروحات التقنية وأداة استغلال صاروا منشورين.

## شو بعمل إذا خايف إنو حدا دخل قبل التحديث؟

حدّث أول، بعدين دوّر بسجلات السيرفر على العلامات يلي نشرتها &lt;span dir="ltr"&gt;Wiz&lt;/span&gt;. هالعلامات لحالها ما بتثبت إنو صار اختراق، بس بتقلك وين تدوّر:

- طلبات &lt;span dir="ltr"&gt;multipart&lt;/span&gt; غريبة، وبعدها أخطاء حد الذاكرة.
- أخطاء &lt;span dir="ltr"&gt;HTTP 500&lt;/span&gt; متكررة.
- كوكي &lt;span dir="ltr"&gt;PHPSESSID&lt;/span&gt; كبيرة أو مشوّهة بالردود.
- &lt;span dir="ltr"&gt;workers&lt;/span&gt; تبع &lt;span dir="ltr"&gt;PHP&lt;/span&gt; عم توقف وترجع بلا سبب واضح.

و&lt;span dir="ltr"&gt;Huntress&lt;/span&gt; بتزيد علامة: عمليات &lt;span dir="ltr"&gt;PHP&lt;/span&gt; عم تشغّل &lt;span dir="ltr"&gt;shell&lt;/span&gt; أو أدوات تحميل، وهاد شي ما بيعمله موقع عادي.

دوّر بسجلات الـ &lt;span dir="ltr"&gt;web server&lt;/span&gt; و&lt;span dir="ltr"&gt;PHP-FPM&lt;/span&gt;، لأنو الهجوم بيصير تحت التطبيق، وسجلات &lt;span dir="ltr"&gt;WordPress&lt;/span&gt; أو &lt;span dir="ltr"&gt;Laravel&lt;/span&gt; ممكن ما تورجي شي. وإذا ما لقيت شي، هاد ما بيعني إنك سليم: حسب موقع الكشف، الذاكرة ممكن تتسرّب بلا تنفيذ كود، وغياب العلامات ما بيثبت إنو السيرفر مش متأثر. والذاكرة يلي بتتسرّب ممكن يكون فيها كلمات سر و&lt;span dir="ltr"&gt;tokens&lt;/span&gt; ومفاتيح &lt;span dir="ltr"&gt;API&lt;/span&gt; تبع طلبات تانية.

إذا لقيت علامة، &lt;span dir="ltr"&gt;Huntress&lt;/span&gt; بتنصح بهالخطوات:

1. اعزل السيرفر عن الإنترنت، واحفظ نسخة من سجلات الـ &lt;span dir="ltr"&gt;web server&lt;/span&gt; و&lt;span dir="ltr"&gt;PHP&lt;/span&gt; قبل ما تمسح أو تعيد تثبيت شي. هيك بيضل عندك أثر الهجوم لحتى تفهم شو صار.
2. دوّر بالمجلد الرئيسي للموقع على ملفات جديدة ما بتعرفها، خصوصاً الـ &lt;span dir="ltr"&gt;webshells&lt;/span&gt;: ملفات بيزرعها المهاجم لحتى يرجع يشغّل أوامر منها، وبتضل مكانها بعد تحديث &lt;span dir="ltr"&gt;PHP&lt;/span&gt;.
3. افحص إذا انزادت مهام مجدولة (&lt;span dir="ltr"&gt;cron jobs&lt;/span&gt;) أو حسابات جديدة على السيرفر.

بعدها غيّر مفاتيح الـ &lt;span dir="ltr"&gt;API&lt;/span&gt; وكلمات السر يلي على السيرفر. وهالخطوة بتلزم حتى لو ما لقيت علامة، إذا السيرفر ضل على نسخة متأثرة بعد ما انتشر خبر الثغرتين يوم 20 تشرين الأول، لأنو التسريب ممكن ما يترك أثر. وإذا موقعك على استضافة مشتركة، ابعت للاستضافة العلامة يلي لقيتها: هي يلي بتقدر تعزل السيرفر وتفحصه.

تحديث &lt;span dir="ltr"&gt;PHP&lt;/span&gt; بيسكّر هالثغرتين بس. ثغرات كودك إنت، متل الصلاحيات و&lt;span dir="ltr"&gt;IDOR&lt;/span&gt;، بدها مراجعة لحالها: بـ [قسم مهارات الـ &lt;span dir="ltr"&gt;AI&lt;/span&gt;](/products/c/ai-skills) في «حزمة المهارات الأمنية» (قريباً) لمراجعة الكود قبل النشر. وإذا منصتك فيها بيانات زباين أو دفع وبدك حدا يجرّبها متل ما بيجرّبها مهاجم، هاد شغل [مُحَصَّن: فحص اختراق وتحصين أمني](/muhassan).

افتح لوحة الاستضافة هلق: شو رقم &lt;span dir="ltr"&gt;PHP&lt;/span&gt; يلي طالع عندك؟

## FAQ

**هل PHP2Shell هي نفسها ثغرة wp2shell تبع WordPress؟**

لأ. wp2shell اسم لثغرتين بكود WordPress نفسه انصلحوا بـ WordPress 7.0.2 و6.9.5 و6.8.6 بتموز 2026. PHP2Shell بـ PHP، وتحديث WordPress ما بيصلّحها.

**إذا موقعي مبني بـ Next.js أو Node.js، هل هو متأثر؟**

لأ، الثغرتين بـ PHP بس. إلا إذا في PHP شغّال على نفس السيرفر، متل phpMyAdmin أو مدونة WordPress على دومين فرعي، فهاد لازم يتحدّث.

**رقم PHP عندي على Ubuntu أو Debian شكله قديم، يعني موقعي متأثر؟**

مش أكيد. حزم التوزيعة ممكن تحمل الإصلاح برقم نسخة شكله قديم. دوّر على CVE-2026-109618 وCVE-2026-109619 بسجل تغييرات حزمة PHP: إذا الرقمين موجودين، الإصلاح عندك.

**شو يعني CVSS 9.2، وليش شفت رقم 10.0 بالسوشيال ميديا؟**

CVSS مقياس لخطورة الثغرة من 0 لـ 10. فريق PHP قيّم الثغرتين 9.2 على CVSS v4.0، ورقم 10.0 انتشر مع التسريب يوم 20 تشرين الأول 2026 وما إجا من PHP.

**لازم أعيد تشغيل PHP بعد التحديث؟**

إي: Apache وPHP-FPM وأي worker بيضل شغّال لفترة طويلة، حسب موقع الكشف php2shell.com. ما لازم تعيد تشغيل الجهاز كله.

**هل الثغرة بتسرّب بيانات حتى لو المهاجم ما شغّل كود؟**

إي. الباحثين عرضوا تسريب لذاكرة الـ worker بأي تطبيق PHP بلا تنفيذ كود، والذاكرة ممكن يكون فيها كلمات سر وtokens ومفاتيح API تبع طلبات تانية.