يوم 21 أكتوبر 2026 نزلت تحديثات أمنية لمنصتين من أكثر منصات الويب استخداماً: فريق PHP أصدر تصحيحات طارئة لثغرتين حرجتين تتيحان تنفيذ شيفرة عن بُعد دون أي تسجيل دخول، أما Node.js فأصلح عشر ثغرات، إحداها عالية الخطورة في فك ضغط Brotli. إذا كان موقعك أو واجهتك الخلفية تعمل على أيٍّ منهما، فلا تؤجل القراءة.
الخلاصة السريعة: الذي يحتاج التحديث هو وقت التشغيل نفسه، أي PHP أو Node.js، ثم تعيد تشغيل الخدمات. تحديث WordPress أو Laravel أو الحزم وحده لن يكفي.
الجزء الأول: PHP2Shell
ماذا حدث بالضبط؟
الخلل هنا في محرك PHP نفسه، لا في تطبيقك. الثغرتان تحملان المعرّفين CVE-2026-109618 و CVE-2026-109619، وتصنيفهما 9.2 على مقياس CVSS v4.0، وأطلقت عليهما مواقع أخبار الأمن اسم php2shell. وكلتاهما تدور حول طريقة التعامل مع الذاكرة أثناء معالجة الطلب:
- CVE-2026-109618: إذا نفدت الذاكرة في لحظة سيئة، قد تتوقف PHP والبيانات الداخلية للطلب لم تكتمل تهيئتها بعد. ثم تأتي عملية التنظيف فتتعامل مع هذه البيانات الناقصة كأنها سليمة.
- CVE-2026-109619: بعض بيانات الحالة الداخلية تظل حية بعد أن تزول الذاكرة التي كانت تسندها.
اكتشف الثغرتين باحثون من Wiz و Calif وفريق Codex Security في OpenAI. الكود المعيب موجود في PHP منذ أكثر من عشر سنوات، ويمتد التأثر تقريباً من الإصدار 5.4 فما بعده، وتقول التقارير إن الباحثين استعانوا بنماذج الذكاء الاصطناعي ليحوّلوا هذه الثغرات القديمة إلى استغلال يعمل فعلاً، وفي وقت قصير جداً.
من هو في مرمى الخطر؟
أي تثبيت PHP يستقبل طلبات ويب: PHP-FPM و Apache mod_php و php-cgi و FrankenPHP و LiteSpeed. حتى صفحة «Hello World» بسيطة لا تسلم، لأن الخلل يقع تحت شيفرتك أصلاً. وأخطر الحالات Apache mod_php: أظهر استغلال تجريبي أن طلباً واحداً دون مصادقة يكفي لإطلاق الهجوم قبل أن يعمل أي كود من تطبيقك. وهناك ما يقلق أيضاً، فقد يتمكن المهاجم من قراءة ذاكرة عملية PHP، وقد تحتوي كلمات مرور ورموزاً ومفاتيح API.
رصدت Cloudflare و watchTowr محاولات استغلال نشطة، لكن لم يؤكد أي مصدر وقت صدور التقرير أن خادماً بعينه اخترق بنجاح. وفي 26 أكتوبر أدرجت CISA الثغرتين في كتالوج الثغرات المستغلة المعروفة (KEV).
طريقة الإصلاح
| فرع PHP | الإصدار الذي يجب أن تكون عليه |
|---|---|
| 8.5 | 8.5.12 أو أحدث |
| 8.4 | 8.4.27 أو أحدث |
| 8.3 | 8.3.36 أو أحدث |
| 8.2 | 8.2.35 أو أحدث (ينتهي دعمه 31 ديسمبر 2026) |
PHP 8.1 وما قبله لم يعد يحصل على تحديثات من المشروع. صحيح أن الفريق الأمني نشر تصحيحات مصدرية لـ 7.4 و 8.0 و 8.1، لكنها تنفع من يبني PHP من المصدر فقط، والأسلم أن تنتقل إلى فرع مدعوم.
ماذا تفعل، بالترتيب:
- ابدأ بمعرفة الإصدار الذي يخدم الويب فعلاً، لأنه قد يختلف عن الإصدار الظاهر في سطر الأوامر (الأمر الأول أدناه).
- حدّث الحزمة عبر نظام التشغيل أو المضيف أو صورة الحاوية، وانتبه إلى أن في توزيعات لينكس قد يبدو رقم الإصدار «قديماً» مع أن الإصلاح موجود فيه، فالأفضل أن تبحث في سجل التغييرات عن المعرّف نفسه (الأمر الثاني أدناه).
- أعد تشغيل Apache و PHP-FPM وأي عمال PHP طويلة العمر.
- ألقِ نظرة جديدة على
memory_limitوpost_max_sizeبعد التحديث، فالإصلاح يضيف حداً صلباً للذاكرة: متى بلغته العملية انتهت فوراً دون تشغيل معالجات الإغلاق. - وإن كنت تعمل بحاويات Docker فأعد بناء الصورة مع سحب الأساس (
--pull)، وتأكد أن الوسم يحمل فعلاً الإصدار المصحح.
php -v
php-fpm -v # إن كنت تستخدم FPM
apt changelog php8.3-cli | grep CVE-2026-109618
لا تستطيع التحديث الآن؟ التحديث هو الحل الكامل الوحيد، وما يلي لا يغلق إلا مسارات هجوم محددة، بحسب إرشادات PHP كما نقلتها The Hacker News. بالنسبة لـ CVE-2026-109619 عطّل session.upload_progress.enabled=0 وأعد تشغيل العمال (وعلى PHP 8.5 اضبط كذلك fatal_error_backtraces=0)، وبالنسبة للثغرة الأولى اضبط حدود حجم الطلب في خادم الويب أو الوكيل العكسي. اقرأ الإشعار الرسمي على php.net قبل أن تطبق أي شيء، ولا تجعل هذه الإعدادات بديلاً عن التحديث.
ماذا تبحث عنه في السجلات: طلبات multipart غريبة يعقبها خطأ تجاوز الذاكرة أو سلسلة من أخطاء HTTP 500، وكوكي PHPSESSID يبدو كبيراً على غير العادة في الاستجابات، وعمال PHP يُعاد تشغيلهم دون سبب تستطيع تفسيره.
الجزء الثاني: Node.js
ما الذي أُصلح؟
أصدر مشروع Node.js تحديثات لخطوط 26.x و 24.x و 22.x، وهي تعالج عشر ثغرات بينها أربع عالية الخطورة. هذه أهمها:
- CVE-2026-111497 (Brotli): كتابة خارج حدود المخزن في مفكك Brotli المضمن، ويكفي أن تصله بيانات مضغوطة مشوهة حتى تتلف ذاكرة العملية، وقد ينتهي الأمر بانهيار أو تسريب ذاكرة أو تنفيذ شيفرة عن بُعد. ويتأثر كل كود يفك ضغط بيانات غير موثوقة عبر
node:zlib. وقد سمّتها مصادر أمنية Node2Shell. - CVE-2026-105482: دوال
dns.resolve*()تقتطع أسماء المضيفين التي تحتوي بايت NUL، فيتحقق تطبيقك من اسم ثم يحل اسماً آخر. - CVE-2026-105483 و CVE-2026-106069: يمكن تجاوز التحقق من شهادات TLS إذا كُتب عنوان IP بصيغة غير معتادة، مثل الأرقام العريضة أو الأصفار البادئة.
- وهناك ثغرات متوسطة ومنخفضة الخطورة في الطلبات المتواصلة (keep-alive)، وفي توليد الأرقام العشوائية داخل اللقطات (snapshots)، وفي نموذج الصلاحيات.
ترقية Node.js
الإصدارات الآمنة هي Node.js 26.12.1 و 24.22.1 و 22.23.4. أما الإصدارات المنتهية الدعم (EOL)، ومنها Node.js 20، فتُعدّ متأثرة دائماً مع أي إصدار أمني.
- اعرف إصدارك الحالي، ثم حدّثه عبر مدير الإصدارات أو الحزمة أو صورة الحاوية (الأوامر أدناه).
- أعد بناء صور Docker وانشرها من جديد، وأعد تشغيل خدمات PM2 أو systemd.
- شغّل
npm auditوحدّث الاعتماديات، ثم ثبّت ملف القفل، ولا تستخدم إلا وقت تشغيل مدعوماً (26 أو 24 أو 22). - تخفيف مؤقت (احتياط معقول وليس بديلاً): امتنع عن فك ضغط Brotli القادم من مصدر غير موثوق، وإن كنت لا تحتاج ترميز
brفي أجسام الطلبات الواردة فارفضه. - قبل استدعاء
dns.resolve*()نظّف اسم المضيف من المحارف غير المتوقعة (مثل NUL) ثم تحقق منه. - اتصل بالخدمات الداخلية بأسمائها أو بعناوين IP القياسية، وابتعد عن الصيغ الغريبة.
node -v
nvm install 24 && nvm use 24
npm audit
قائمة تحقق سريعة
- [ ] أعرف إصدار PHP و Node.js الذي يعمل فعلاً على كل خادم وحاوية.
- [ ] انتقلت إلى الإصدارات المصححة وأعدت تشغيل كل العمال.
- [ ] فتشت السجلات بحثاً عن الأنماط المشبوهة المذكورة أعلاه.
- [ ] تأكدت من المضيف المشترك أو المزود أنه حدّث المحرك. التحديث ليس بيدك على الاستضافة المشتركة، لكن السؤال مسؤوليتك.
- [ ] وضعت خطة للتخلص من الفروع المنتهية الدعم.
وإذا كنت تريد أدوات لمتابعة الثغرات وإدارة الاعتماديات، فابدأ بتصفح المنصات الرقمية في ديجيتال دليل.



