تحديث 27 أكتوبر: CISA تدرج PHP2Shell ضمن الثغرات المستغَلّة
في 26 أكتوبر 2026، أضافت CISA، وهي الوكالة الأمريكية للأمن السيبراني، الثغرتين معًا (CVE-2026-109618 وCVE-2026-109619) إلى كتالوج الثغرات المستغَلّة المعروفة KEV (Known Exploited Vulnerabilities). لا يُدرَج أي بند في هذا الكتالوج إلا بعد ثبوت استغلال فعلي: وحتى الآن كان هذا الثبوت قائمًا على مصائد watchTowr الشبكية، أما اليوم فمصدره جهة عامة.
حدّدت CISA الموعد النهائي في 29 أكتوبر 2026، أي بعد ثلاثة أيام من الإدراج. لا يُلزم هذا الموعد سوى الوكالات الفيدرالية الأمريكية، لكنه يعطي حجم الاستعجال الذي تنسبه جهة عامة إلى هاتين الثغرتين: بضعة أيام، لا نافذة الصيانة الشهرية القادمة.
ما يقوله بند كتالوج KEV
- تاريخ الإدراج: 26 أكتوبر 2026، لكلٍّ من CVE-2026-109618 («PHP Memory Corruption Vulnerability») وCVE-2026-109619 («PHP Stale Internal Request-State Vulnerability»).
- الموعد النهائي: 29 أكتوبر 2026 لكلتيهما.
- الإجراء المطلوب: تطبيق إجراءات التخفيف الصادرة عن المورّد وفق التوجيه BOD 26-04 (Prioritizing Security Updates Based on Risk)، أو التوقف عن استخدام المنتج إذا لم يتوافر أي إجراء.
- الفرز الجنائي: يحيل البند إلى «Forensics Triage Requirements» الصادرة عن CISA. التصحيح وحده لا يكفي: يجب أيضًا البحث عن اختراق وقع قبل التصحيح.
- برمجيات الفدية: يُذكر استخدامهما في حملة فدية على أنه «غير معروف» حتى الآن.
ما الذي يتغيّر بالنسبة إليك
لا شيء في الإجراءات: الإصدارات المصحَّحة والأوامر هي نفسها الواردة في هذه المقالة. الذي يتغيّر هو الأولوية. قبل 26 أكتوبر كان بالإمكان المفاضلة بين «فورًا» و«في نافذة الصيانة القادمة»؛ لم يعد ذلك مقبولًا. تأتي الخوادم المكشوفة على الإنترنت أولًا. ولم يعد السؤال «هل أنا محمي؟» فحسب، بل «هل أُصبتُ بين 21 أكتوبر ولحظة التصحيح؟»: وقد أُكملت قائمة الفحص أدناه بما يخدم هذا السؤال.
PHP2Shell باختصار
ليست PHP2Shell ثغرة في WordPress أو Laravel أو في إضافة ما: المشكلة في محرّك PHP نفسه. لذا فإن كل تطبيق PHP يستجيب لطلبات الويب معنيّ بها، أيًّا كانت شيفرته. ويذكر التنبيه الأمني كلًّا من PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP وLiteSpeed.
تشترك الثغرتان في آلية واحدة. فعندما يقطع PHP طلبًا بشكل مفاجئ (نفاد الذاكرة، خطأ فادح)، قد يترك خلفه حالة داخلية مهيّأة جزئيًّا أو محرَّرة مسبقًا. ثم يعيد طلب لاحق، يعالجه عملية PHP نفسها، استخدام تلك الحالة: وهذا ما يفتح الباب أمام تنفيذ شيفرة عن بُعد.
ما يجب تذكّره
- CVE-2026-109618 — تلف في الذاكرة عند تجاوز
memory_limit: بيانات طلب مهيّأة جزئيًّا تُعامَل لاحقًا على أنها صالحة أثناء التنظيف. - CVE-2026-109619 — حالة عامة منتهية الصلاحية: حالة خاصة بطلب ما تبقى بعد تحرير ذاكرته، ويمكن أن يقرأها الطلب التالي على العملية نفسها.
- الدرجة: 9.2 من 10 وفق CVSS 4.0 لكل منهما، دون الحاجة إلى مصادقة أو تفاعل من المستخدم.
- الإصدارات المصحَّحة: PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35. لم يعد المشروع ينشر إصدارات للفرع 8.1 والفروع الأقدم.
- الاستغلال: تفيد watchTowr برصد محاولات استغلال في مصائدها الشبكية منذ 21 أكتوبر 2026.
- النطاق: وفقًا لقاعدة NVD، تمسّ CVE-2026-109619 جميع الإصدارات منذ PHP 5.4.0، وتمسّ CVE-2026-109618 جميع الإصدارات منذ PHP 7.3.0.
لماذا تشكّل هاتان الثغرتان خطرًا كبيرًا
تتطلب معظم ثغرات الويب نموذجًا محددًا أو حسابًا أو إضافة معرّضة للخطر. أما PHP2Shell فلا تحتاج إلى أي من ذلك: المحفّز الأكثر شيوعًا هو معالجة إرسال من نوع multipart/form-data مع تتبّع تقدّم الجلسات (session.upload_progress)، وهي آلية يفعّلها PHP افتراضيًّا وتُنفَّذ قبل أول بايت من تطبيقك. لذلك فإن جدار حماية تطبيقات مدمجًا في شيفرتك، أو إضافة أمان لـ WordPress، أو middleware في Laravel، كلها تصل بعد فوات الأوان.
العامل الثاني هو نموذج التنفيذ نفسه. إذ يعيد PHP-FPM وApache استخدام العملية نفسها لمئات الطلبات المتتالية: وهذا تحديدًا ما يسمح لطلب مفخّخ بأن يلوّث الطلب الذي يليه. ووفقًا لـ Imperva، تتراوح التقنيات المنشورة بين إسقاط العملية وقراءة ملفات عشوائية عبر ذاكرة OPcache المؤقتة، مرورًا بتسريب نحو 67 كيلوبايت من ذاكرة العملية داخل ملف تعريف ارتباط PHPSESSID متضخّم. وقد تحتوي هذه الذاكرة على كلمات مرور قاعدة البيانات أو مفاتيح API.
أي إصدار تثبّت حسب فرعك
مرّر الجدول أفقيًا
| فرع PHP | الإصدار المصحَّح | ما العمل |
|---|---|---|
| 8.5 | 8.5.12 | التحديث ثم إعادة تشغيل PHP |
| 8.4 | 8.4.27 | التحديث ثم إعادة تشغيل PHP |
| 8.3 | 8.3.36 | التحديث ثم إعادة تشغيل PHP |
| 8.2 | 8.2.35 | التحديث، ثم التخطيط للانتقال إلى 8.3 أو 8.4 |
| 8.1، 8.0، 7.4 | لا يوجد إصدار رسمي | حزمة مصحَّحة من توزيعتك، أو نقل عكسي للتصحيح من المصدر، وإلا فالانتقال |
| 7.3 وما قبلها، 5.x | لم يُنشر أي تصحيح | الانتقال إلى فرع مدعوم |
تحقّق مما إذا كانت خوادمك مكشوفة
احذر فخًّا شائعًا: الإصدار الذي يعرضه الأمر php -v في سطر الأوامر ليس بالضرورة الإصدار الذي يخدم مواقعك. فقد يحتوي الخادم على عدة إصدارات من PHP-FPM مثبّتة جنبًا إلى جنب، وقد يشير كل موقع إلى إصدار مختلف. لذا يجب التحقق من الإصدار الذي يخدمه الويب فعليًّا، موقعًا تلو الآخر.
جرد إصدارات PHP المخدومة
اعرض الإصدارات المثبّتة
على Debian أو Ubuntu:
dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'php*' | awk '$1=="ii"' | grep -E 'php[0-9.]+-(fpm|cli|common)|libapache2-mod-php'على RHEL أو AlmaLinux أو Rocky Linux:
rpm -qa 'php*' 'ea-php*' 'alt-php*' | sortحدّد عمليات PHP قيد التشغيل
systemctl list-units --type=service --state=running | grep -E 'php|apache2|httpd|lsws'كل خدمة
phpX.Y-fpmنشطة هي إصدار يجب التحقق منه وتصحيحه.اقرأ الإصدار الذي يخدم موقعًا ما
ضع ملفًا مؤقتًا في جذر الموقع، واستعلم عنه، ثم احذفه فورًا:
echo '<?php echo PHP_VERSION, " ", PHP_SAPI;' > /var/www/monsite/v-check.php curl -s https://monsite.example/v-check.php rm /var/www/monsite/v-check.phpتشير نتيجة مثل
8.3.36 fpm-fcgiإلى إصدار مصحَّح يخدمه PHP-FPM.افحص حاويات Docker
docker ps --format '{{.Names}}' | while read c; do echo "$c: $(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null)"; doneالحاوية التي لا تحتوي على PHP لا تعرض شيئًا بعد اسمها.
طبّق التصحيح
تلقّت توزيعات Linux ومزوّدو الدعم الممتد التصحيحات قبل النشر. لذلك لا تحمل الحزمة المصحَّحة في توزيعتك بالضرورة الرقم 8.3.36: فمثلًا تُصلح Ubuntu 24.04 إصدارها 8.3.6 ضمن الحزمة 8.3.6-0ubuntu0.24.04.13. اعتمد على التنبيه الأمني الخاص بتوزيعتك بدلًا من رقم إصدار PHP وحده. وفي جميع الأحوال، إعادة التشغيل ضرورية: فما دامت العمليات القديمة تعمل، فإن الشيفرة القديمة هي التي تستجيب.
حدّث PHP حسب بيئتك
Debian وUbuntu
sudo apt update sudo apt install --only-upgrade $(dpkg-query -W -f='${db:Status-Abbrev} ${Package}\n' 'php*' | awk '$1=="ii"{print $2}') sudo systemctl restart 'php*-fpm' sudo systemctl restart apache2 # if you use mod_phpإذا كانت إصداراتك تأتي من مستودع خارجي (مثل PPA
ondrej/php)، فتحقّق من أن الإصدار المثبّت بعد التحديث هو فعلًا إصدار مصحَّح.RHEL وAlmaLinux وRocky Linux
sudo dnf upgrade 'php*' sudo systemctl restart php-fpm sudo systemctl restart httpdنشرت AlmaLinux حزمها المصحَّحة في 21 أكتوبر 2026. أما مستودع Remi المجتمعي فقد نشر الإصدارات 8.2.35 و8.3.36 و8.4.27 و8.5.12 في 22 أكتوبر 2026: إذا كنت تعتمد عليه، فتحقّق من الإصدار المثبّت بعد ذلك.
خادم cPanel (EasyApache 4 أو CloudLinux)
sudo dnf upgrade 'ea-php*' 'alt-php*' /scripts/restartsrv_apache_php_fpm /scripts/restartsrv_httpdعلى خادم أقدم، استبدل
dnfبـyum. ثم افحص كل إصدار في WHM › MultiPHP Manager: يجب نقل أي حساب مضبوط على 7.3 أو ما قبله، دون تصحيح من cPanel، إلى إصدار مدعوم؛ أما 7.4 و8.0 و8.1 فمصحَّحة بالتصدير العكسي لكنها منتهية العمر (انظر أدناه).حاويات Docker
docker compose pull docker compose up -d --force-recreate docker compose exec app php -r 'echo PHP_VERSION;'إذا كان ملف
Dockerfileالخاص بك ينطلق من صورةphp:8.3-fpm، فأعد بناء الصورة باستخدامdocker compose build --pull: فبدون--pullيعيد Docker استخدام الصورة الأساسية القديمة المخزّنة مؤقتًا.تحقّق من النتيجة
أعد تشغيل فحص الخطوة السابقة على كل موقع. لا يُعدّ التصحيح مطبَّقًا إلا إذا كان الإصدار الذي يخدمه الويب مصحَّحًا، لا الإصدار المثبّت على القرص فحسب.
cPanel وEasyApache 4: رقم الإصدار الذي لم يتغيّر لا يعني «غير مصحَّح»
يغطي سجل تغييرات EasyApache 4 (EA4) بتاريخ 21 أكتوبر 2026، الإصدار 25.91، سبعة فروع من PHP. في الفروع المدعومة يرتفع الرقم: تنتقل ea-php82 من 8.2.34 إلى 8.2.35، وea-php83 من 8.3.35 إلى 8.3.36، وea-php84 من 8.4.26 إلى 8.4.27، وea-php85 من 8.5.11 إلى 8.5.12. أما ea-php74 وea-php80 وea-php81، التي أعلنت cPanel نهاية عمرها، فيُنقَل إليها التصحيح بالتصدير العكسي: لا يتغيّر رقم إصدار PHP، وتتغيّر فقط مراجعة الحزمة.
هنا الفخ: يعرض php -v حينئذٍ إصدارًا «قديمًا» مع أن الشيفرة مصحَّحة، وتبقى أي حزمة قديمة لا يذكر سجل تغييراتها الثغرتين معرَّضة للخطر. وحده قراءة سجل تغييرات الحزمة يحسم الأمر. كما أعاد الإصدار 25.92، الصادر في اليوم نفسه، بناء الحزم الوصفية حتى يذكر سجل تغييراتها التصدير العكسي أيضًا.
EasyApache 4 25.91: ما نشرته cPanel، حزمةً حزمةً
مرّر الجدول أفقيًا
| الحزمة | ما الذي تغيّر | كيف تتحقق |
|---|---|---|
| ea-php85 | من 8.5.11 إلى 8.5.12 | إصدار الحزمة |
| ea-php84 | من 8.4.26 إلى 8.4.27 | إصدار الحزمة |
| ea-php83 | من 8.3.35 إلى 8.3.36 | إصدار الحزمة |
| ea-php82 | من 8.2.34 إلى 8.2.35 | إصدار الحزمة |
| ea-php81 وea-php80 وea-php74 | تصحيح بالتصدير العكسي، ورقم PHP دون تغيير | سجل تغييرات RPM: ابحث عن الثغرتين |
| ea-php73 وما قبلها | لا بند في سجل 25.91 | انتقل إلى فرع مدعوم، أو راجع CloudLinux أدناه |
تحقّق من أن حزمة مصدَّرة عكسيًّا مصحَّحة فعلًا
اقرأ سجل تغييرات حزمة EasyApache
rpm -qa 'ea-php*-php-cli' rpm -q --changelog ea-php81-php-cli | grep -E 'CVE-2026-(109618|109619)'يعرض الأمر الأول الفروع المثبَّتة، ويُعاد الثاني لكل فرع. سطر يذكر الثغرتين يؤكد التصحيح. وإن لم يظهر أي سطر فالحزمة غير مصحَّحة، أيًّا كان رقم إصدارها.
افعل الشيء نفسه مع حزم alt-php
على خادم CloudLinux، الإصدارات المختارة في Select PHP Version هي حزم
alt-php:rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'راجع الحسابات واحدًا واحدًا
في WHM › MultiPHP Manager، يجب أن يشير كل نطاق إلى فرع اجتازت حزمته هذا الفحص. تبقى الفروع 7.4 و8.0 و8.1 المصحَّحة بالتصدير العكسي منتهية العمر: فهي موضع انتظار، لا وجهة نهائية.
CloudLinux: التصحيح نفسه، متأخرًا يومًا أو يومين بحسب المنتج
تنشر CloudLinux حزمها الخاصة، ولا تصل في وقت وصول حزم cPanel نفسه. وبحسب نشرتها، انتقلت حزم ea-php (من 5.2 إلى 8.5) إلى المستقر في 21 أكتوبر، وحزم alt-php في 22 أكتوبر على CloudLinux 7 و8 و9، وPHP الأصلي للنظام في 22 أكتوبر في ساعة متأخرة (UTC)، والحزم المرقَّمة مثل PHP.net في 23 أكتوبر.
وهذه أيضًا تصحيحات مصدَّرة عكسيًّا: فتبقى ea-php84 مثلًا على 8.4.26 مع مراجعة خاصة بـ CloudLinux (8.4.26-2) وهي مصحَّحة. وثمة نقطتا حذر: ففي 21 أكتوبر كانت حزم alt-php المعلَن نشرها موجودة في الواقع في مستودع TuxCare ELS لا في مستودعات CloudLinux؛ أما النصيحة بتعطيل مستودع php-els الصادرة في 22 أكتوبر فقد صُحِّحت مساء 23 أكتوبر: أبقِه مفعَّلًا. وأخيرًا نشرت Imunify360 قواعد WAF منذ 21 أكتوبر (مجموعة القواعد 8.83)، وأصبح الإصدار 8.88 مستقرًا منذ 23 أكتوبر: وهي تحجب مسارات هجوم معروفة ولا تغني عن التحديث.
PHP الداخلي في cPanel/WHM وRoundcube: نسخة PHP أخرى يجب تحديثها
يتحكم MultiPHP وEasyApache في PHP الخاص بمواقعك. أما واجهات cPanel وWHM وبريد Roundcube فتعمل على PHP داخلي يُسلَّم مع cPanel نفسها، ولا يؤثر فيه اختيار إصدار في MultiPHP Manager. في 21 أكتوبر 2026 نشرت cPanel تحديثًا أمنيًّا لهذا PHP الداخلي، مبيّنةً أنه «يؤثر في PHP داخل واجهات cPanel، بما فيها بريد Roundcube».
يحمل التحديث PHP 8.4.27 في cPanel وWHM بالإصدارات 138.0.18 و136.0.50 و134.0.66، وتصحيحات مصدَّرة عكسيًّا لـ PHP 8.1.34 في الإصدار 110.0.153. هذه الواجهات مفتوحة لاتصالات عملائك، وبالتالي كثيرًا ما تكون متاحة من الإنترنت: فهي أهداف مفضّلة. اقرأ إصدارك بالأمر /usr/local/cpanel/cpanel -V (أو من شريط WHM) وقارنه بهذه الأرقام. وإن لم تكن سلسلتك مذكورة فلا تفترض أنها مصحَّحة: راجع ملاحظات إصدار cPanel وانتقل إلى سلسلة مصحَّحة.
بعد التصحيح، عطّل مع ذلك تتبّع تقدّم الرفع
في 23 أكتوبر 2026 نشر PHP تنبيهًا إعلاميًّا تكميليًّا: يوصي بإبقاء session.upload_progress.enabled=0 إلى حين صدور إصدار الإصلاح الاعتيادي القادم، للوقاية من مسار لتنفيذ الشيفرة يراه غير مرجّح. يستهدف التنبيه التطبيقات التي تضبط session.serialize_handler على php_binary أو php_serialize ثم تعيده إلى php أثناء التنفيذ عبر ini_set() قبل session_start(). ويعلن PHP عن تنبيه كامل لـ CVE-2026-115560 مع الإصدار القادم. لا يمسّ هذا الإعداد سوى شريط تقدّم رفع الملفات.
إذا لم تتمكن من التحديث فورًا
يقترح التنبيه الرسمي لـ PHP إعدادات تقلّل من التعرّض دون أن تجعل التثبيت آمنًا. فهي تفيد في كسب بضع ساعات، لا في الاستغناء عن التصحيح. ويجب وضعها في php.ini أو في مجمّع PHP-FPM أو في إعدادات خادم الويب، وليس أبدًا عبر ini_set() أو ملف .user.ini: فهذان يُقرآن بعد فوات الأوان، بعد تحليل الطلب.
في مواجهة CVE-2026-109619، عطّل تتبّع تقدّم عمليات الرفع. وعلى PHP 8.5، عطّل أيضًا تتبّعات الأخطاء الفادحة:
; in the FPM pool, e.g. /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 only:
php_admin_flag[fatal_error_backtraces] = offوفي مواجهة CVE-2026-109618، يوصي التنبيه بفرض memory_limit = -1 عبر php_admin_value، حتى لا يتمكن أي تطبيق من إعادة تعريفه، وبتحديد حجم الطلب (post_max_size = 8M، أو 32M إذا كنت تحتاج إلى رفع الملفات). وفي المقابل، يجب وضع سقف للذاكرة في مكان آخر، عبر حدّ للحاوية أو لـ cgroup. لا تستخدم RLIMIT_AS ولا RLIMIT_DATA: فهما يتسبّبان تحديدًا في فشل التخصيص المعرَّض للثغرة.
أعد بعد ذلك تشغيل جميع عمليات PHP حتى تُطبَّق الإعدادات.
أضف حاجزًا أمام PHP
حدّد حجم الطلبات على مستوى خادم الويب، قبل أن تصل إلى PHP: client_max_body_size 8m; في nginx، وLimitRequestBody 8388608 في Apache. وإذا كان موقعك يمرّ عبر Cloudflare في الوضع الوكيل (proxied)، فقد نُشرت قواعد WAF تستهدف نواقل PHP2Shell المعروفة لجميع الحسابات، بما فيها الخطة المجانية. هذه شبكات أمان فقط: وحده تحديث PHP يغلق الثغرة.
ابحث عن آثار الاستغلال
تترك المحاولات المنشورة آثارًا مميّزة: عمليات PHP تنهار، وتجاوزات متلاحقة للذاكرة، وعمليات إرسال multipart كبيرة الحجم على نحو غير طبيعي. إذا كان خادمك مكشوفًا قبل التحديث، فخصّص عشر دقائق للتحقق.
فحوص يجب إجراؤها بعد التصحيح
ابحث عن عمليات PHP-FPM المُنهاة
sudo grep -E 'exited on signal (11|6)' /var/log/php*-fpm.log | tail -20إن إنهاء عمليات بالإشارة 11 (SIGSEGV) بشكل متكرر منذ 21 أكتوبر علامة تحذير.
ابحث عن تجاوزات الذاكرة
sudo grep -rh 'Allowed memory size' /var/log/php* /var/log/nginx /var/log/apache2 2>/dev/null | tail -20حدّد ملفات PHP المُنشأة حديثًا
sudo find /var/www /home -name '*.php' -newermt '2026-10-20' -not -path '*/vendor/*' -not -path '*/cache/*' -lsأي ملف مجهول باسم عام، في مجلد رفع أو في
/tmp، يجب فحصه قبل أي حذف.عند الشك، تعامل مع الخادم على أنه مخترق
اعزل الجهاز، واحتفظ بنسخة من السجلات، ثم جدّد كلمات مرور قاعدة البيانات ومفاتيح API والأسرار الموجودة في ملفات
.env: فتسريب الذاكرة قد يكون كشفها دون أن يترك أي أثر آخر.
علامات إضافية يجب البحث عنها، وفق المصادر الأولية
- طلبات
multipartضخمة أو شديدة التداخل بشكل غير معتاد في سجلات خادم الويب (watchTowr). - عمليات PHP التي تتعطل أو تبلغ حدّ ذاكرتها (watchTowr).
- ملفات مكتوبة في جذور الويب واتصالات صادرة من عمليات PHP لا تعرف تفسيرًا لها (watchTowr).
- أبواب خلفية جديدة (web shells) ومهام cron غير متوقعة وحسابات أُنشئت حديثًا مرتبطة بعمليات PHP (watchTowr).
- احتفظ قبل أن تنظّف: سجلات PHP وخادم الويب ولقطات الإعدادات والملفات المشبوهة، قبل تعديل أي شيء (watchTowr). وتربط CISA ببندها في KEV متطلبات فرز جنائي.
- لا يُنشر أي مؤشر رقمي: حتى 27 أكتوبر، لا تقدّم watchTowr ولا PHP ولا تنبيه GitHub الخاص بـ CVE-2026-109618 أي عنوان IP أو بصمة أو اسم ملف أو توقيع طلب. احذر من قوائم المؤشرات بلا مصدر: غياب عنوان ما عن سجلاتك لا يثبت شيئًا.
على الاستضافة المشتركة
على الاستضافة المشتركة، لست أنت من يحدّث PHP: بل مزوّد الاستضافة هو من يصون الإصدارات المعروضة. ويتمثّل دورك في التحقق من أن موقعك يستخدم فرعًا لا يزال يتلقى التصحيحات. في cPanel، تُظهر أداة اختيار الإصدار (MultiPHP Manager، أو Select PHP Version على خادم CloudLinux) الإصدار النشط لكل نطاق. إذا كان موقعك لا يزال يعمل على 7.4 أو 8.0 أو 8.1، فهذه الفروع لم تعد تتلقى إصدارات رسمية من PHP: انتقل إلى 8.3 أو 8.4 بعد اختبار موقعك، باتباع قائمة التحقق الخاصة بنا للانتقال بين إصدارات PHP.
التوثيق الرسمي
نُشرت التفاصيل التقنية وإعدادات الالتفاف في التنبيه الأمني لـ PHP وفي تنبيهات GitHub GHSA-w8hw-w9fx-j79w (CVE-2026-109618) وGHSA-6wmf-4rv5-p3rp (CVE-2026-109619). وبالنسبة إلى حزم التوزيعات، راجع إعلان Ubuntu وإعلان AlmaLinux. ولمتابعة الموضوع: كتالوج KEV لدى CISA وسجل تغييرات EasyApache 4 وملاحظات إصدار cPanel وWHM ونشرة CloudLinux والأسئلة الشائعة لدى watchTowr.
