أمن المواقع · تحديث أكتوبر 2026
ثغرات PHP 2026 هي مجموعة ثغرات أُعلنت في موجتين خلال يوليو 2026، أخطرها ثغرة قد تُسقط PHP-FPM بالكامل وثغرة حقن SQL في إضافة PostgreSQL. موقعك في خطر إذا كان يعمل على إصدار أقدم من 8.2.33 أو 8.3.33 أو 8.4.24 أو 8.5.9، أو على PHP 8.1 وما قبله الذي توقف دعمه نهائيًا.
لا داعي للهلع، لكن لا مجال للتأجيل أيضًا. في هذا الدليل نشرح كل ثغرة بلغة يفهمها صاحب الموقع لا المبرمج فقط، ونوضح مواعيد انتهاء الدعم، ومن المتأثر فعلًا، وكيف تعرف إصدار PHP في موقعك خلال دقيقة، ثم خطوات التحديث والحماية على Hostinger وcPanel والخوادم الخاصة.
ما هي ثغرات PHP 2026 باختصار؟
لغة PHP هي المحرك الذي يشغّل أغلب مواقع الإنترنت، ومنها كل مواقع ووردبريس ومعظم مشاريع Laravel والمتاجر والأنظمة المبرمجة خصيصًا. وكأي برنامج كبير، يكتشف الباحثون فيها بين حين وآخر أخطاء برمجية يمكن استغلالها، فيصدر فريق PHP نسخًا تصحيحية تسدّها. ما يميز عام 2026 أن التصحيحات جاءت في موجتين متقاربتين خلال شهر واحد، وأن ذلك تزامن مع اقتراب نهاية دعم فرع 8.2 وبعد أشهر قليلة من موت فرع 8.1.
ما هي الثغرات بالتفصيل وماذا تعني لموقعك؟
الجدول التالي يلخص الثغرات الست التي تهم أصحاب المواقع، ثم نشرح كل واحدة بلغة بسيطة بعيدًا عن المصطلحات الثقيلة.
| الثغرة | الخطورة | أين تقع | الإصدارات المصححة |
|---|---|---|---|
| CVE-2026-12184 | عالية (CVSS v4: 8.2) | غلاف HTTP عند فشل إعداد TLS، ويؤدي إلى انهيار PHP-FPM | 8.3.32 و8.4.21 و8.5.6 |
| CVE-2026-14355 | متوسطة (CVSS 3.1: 5.6) | خوارزمية AES-WRAP-PAD في إضافة OpenSSL (فيضان ذاكرة heap) | 8.2.32 و8.3.32 و8.4.23 و8.5.8 |
| CVE-2026-17543 | عالية | حقن SQL في إضافة ext-pgsql الخاصة بـ PostgreSQL | 8.2.33 و8.3.33 و8.4.24 و8.5.9 |
| CVE-2026-7260 | حجب خدمة | إضافة Phar عند معالجة روابط رمزية دائرية | نسخ 30 يوليو 2026 |
| CVE-2026-9672 | تحديث مكتبة | مكتبة الصور libgd المضمّنة | نسخ 30 يوليو 2026 |
| CVE-2026-17544 | كتابة خارج الحدود | الدالة bccomp() في BCMath (فرعا 8.4 و8.5 فقط) | 8.4.24 و8.5.9 |
ثغرة PHP-FPM (CVE-2026-12184): الموقع يتوقف دفعة واحدة
هذه أهم ثغرة لأغلب أصحاب المواقع. حين يطلب موقعك صفحة أو ملفًا من خادم آخر عبر HTTPS باستخدام دوال مثل file_get_contents() أو دوال التدفق (streams)، وفشل إعداد اتصال TLS في ظروف معينة، كان بإمكان مهاجم عن بُعد أن يتسبب في انهيار عملية PHP-FPM بكاملها مع كل العمال التابعين لها. النتيجة العملية: الموقع كله يتوقف عن الرد حتى تُعاد تشغيل الخدمة. ليس هناك سرقة بيانات في وصف هذه الثغرة، لكن توقف متجر أو موقع عيادة لساعات خسارة حقيقية. تتأثر بها الفروع 8.3.0 حتى 8.3.31، و8.4.0 حتى 8.4.20، و8.5.0 حتى 8.5.5، والخطر أكبر للتطبيقات التي ترسل طلبات HTTPS خارجية، خصوصًا عبر خادم وسيط (proxy).
ثغرة OpenSSL (CVE-2026-14355): خطأ في حساب حجم الذاكرة
عند استخدام نمط التشفير AES-WRAP-PAD داخل إضافة OpenSSL، كانت PHP تحجز مساحة ذاكرة بحجم خاطئ للنتيجة، فيحدث تلف في الذاكرة يؤدي إلى توقف العملية. خطورتها متوسطة، وتمسّ الفروع 8.2 و8.3 و8.4 و8.5 قبل النسخ المصححة المذكورة في الجدول. اللافت هنا أن الفروع المنتهية مثل 7.x و8.1 متأثرة أيضًا ولن يصدر لها تصحيح رسمي، وهذا مثال واضح على معنى «انتهاء الدعم».
حقن SQL في PostgreSQL (CVE-2026-17543): لمن يستخدم PostgreSQL فقط
إضافة ext-pgsql توفر دوال جاهزة مثل pg_insert وpg_update وpg_select وpg_delete. بسبب خطأ في تهريب رمز الشرطة المائلة العكسية (\)، كان يمكن تمرير أوامر SQL غير مقصودة إلى قاعدة البيانات. هذه ثغرة عالية الخطورة، لكنها لا تمسّ إلا المواقع التي تتصل بقاعدة PostgreSQL عبر هذه الإضافة. معظم مواقع ووردبريس تعمل على MySQL أو MariaDB فلا تتأثر بها مباشرة، أما مشاريع Laravel والأنظمة الخاصة المبنية على PostgreSQL فيجب أن تتحقق فورًا.
ثغرات Phar وlibgd وBCMath: إصلاحات مرافقة
ثغرة Phar (CVE-2026-7260) تسمح بإيقاف الخدمة عبر أرشيف phar يحتوي روابط رمزية متكررة أو دائرية. وتحديث libgd (CVE-2026-9672) يسد مشكلات في المكتبة المستخدمة لمعالجة الصور، وهي حاضرة في كثير من مواقع ووردبريس التي تقصّ الصور وتصغرها. أما CVE-2026-17544 فهي كتابة خارج حدود الذاكرة في الدالة bccomp() وتخص فرعي 8.4 و8.5 فقط. كل هذه الإصلاحات تصلك تلقائيًا بمجرد الانتقال إلى نسخ 30 يوليو أو ما بعدها.
متى ينتهي دعم PHP 8.2 وما الإصدار الآمن في 2026؟
تمر كل نسخة رئيسية من PHP بمرحلتين: دعم نشط تُضاف فيه الإصلاحات العامة، ثم دعم أمني تُسد فيه الثغرات فقط، وبعدها تصبح النسخة «ميتة» لا يصلها أي تصحيح. هذا الجدول يوضح الوضع الحالي حسب موقع php.net:
| الإصدار | الحالة اليوم | نهاية الدعم الأمني | توصيتنا |
|---|---|---|---|
| 7.4 و8.0 وما قبلها | منتهية منذ زمن (7.4 انتهى في 28 نوفمبر 2022) | انتهى | ترقية عاجلة |
| PHP 8.1 | منتهي | 31 ديسمبر 2025 | ترقية عاجلة |
| PHP 8.2 | إصلاحات أمنية فقط | 31 ديسمبر 2026 | خطط للانتقال الآن |
| PHP 8.3 | إصلاحات أمنية | 31 ديسمبر 2027 | خيار آمن ومستقر |
| PHP 8.4 | دعم نشط حتى 31 ديسمبر 2026 | 31 ديسمبر 2028 | خيار ممتاز |
| PHP 8.5 | دعم نشط حتى 31 ديسمبر 2027 (صدر في 20 نوفمبر 2025) | 31 ديسمبر 2029 | بعد التأكد من توافق الإضافات |
| PHP 8.6 | مرحلة الإصدار المرشح (RC3 في 6 أكتوبر 2026) | غير مستقر بعد | لا تستخدمه في موقع حي |
إذن، إصدار PHP الآمن اليوم ليس رقمًا واحدًا، بل أي نسخة من فرع مدعوم مع آخر تصحيح: 8.2.33 أو 8.3.33 أو 8.4.24 أو 8.5.9 أو أحدث. ومع أن 8.2.33 آمن حاليًا، فإن انتهاء دعم PHP 8.2 بعد شهرين يجعل الانتقال إليه الآن عملًا مزدوجًا، لذلك ننصح بالقفز مباشرة إلى 8.3 أو 8.4.
من المتأثر بثغرات PHP 2026: ووردبريس أم Laravel أم المواقع المبرمجة خصيصًا؟
الجواب المختصر: كل موقع يعمل بـ PHP معني بالأمر، لكن درجة التأثر تختلف حسب الإصدار المستخدم، ونوع قاعدة البيانات، وما إذا كان الموقع يتصل بخدمات خارجية. والأهم أن الإصدار يُحدَّد لكل موقع على حدة، فقد يكون لديك موقعان على الحساب نفسه أحدهما محدّث والآخر قديم دون أن تنتبه.
إذا كان موقعك مثلًا يجلب أسعار عملات أو خلاصات RSS أو بيانات من واجهة برمجية خارجية، فهو يرسل طلبات HTTPS باستمرار، وهذا بالضبط نوع الاستخدام الذي تمسه ثغرة PHP-FPM. وكذلك الحال في أنظمة إدارة العملاء التي تتكامل مع خدمات خارجية، كما شرحنا في مقال أفضل برنامج CRM.
كيف تعرف إصدار PHP في موقعك؟
قبل أي خطوة، اعرف أين تقف. هذه أسهل الطرق:
- من لوحة ووردبريس: الأدوات ← صحة الموقع ← معلومات ← الخادم، وستجد سطر «إصدار PHP».
- من لوحة الاستضافة: في Hostinger افتح إعدادات PHP للموقع، وفي cPanel افتح MultiPHP Manager، وستظهر النسخة الحالية لكل نطاق.
- من سطر الأوامر على الخادم: نفّذ الأمر
php -v، مع الانتباه إلى أن نسخة سطر الأوامر قد تختلف عن النسخة التي يستخدمها الموقع عبر PHP-FPM. - عبر صفحة phpinfo: أنشئ ملفًا مؤقتًا يحتوي
<?php phpinfo();وافتحه في المتصفح، ثم احذفه فورًا لأنه يكشف معلومات حساسة.
ما علامات الخطر التي تدل على أن موقعك يحتاج تحديثًا فوريًا؟
- إصدار PHP يبدأ بـ 7 أو 8.0 أو 8.1.
- أداة صحة الموقع في ووردبريس تحذرك من إصدار PHP قديم.
- توقف الموقع فجأة برسالة 502 أو 503 ثم عودته بعد إعادة تشغيل الخدمة.
- سجلات الخادم تُظهر انهيارات متكررة لعمليات PHP-FPM.
- موقعك مبرمج قبل سنوات ولم يُحدّث منذ ذلك الوقت.
- تستخدم PostgreSQL ولا تعرف إصدار PHP الحالي.
كيف تحدّث PHP خطوة بخطوة دون أن يتعطل موقعك؟
عملية تحديث PHP سهلة تقنيًا، لكن الخطأ الشائع هو القيام بها مباشرة على الموقع الحي دون تحضير. اتبع الترتيب التالي:
- خذ نسخة احتياطية كاملةالملفات وقاعدة البيانات معًا، واحفظها خارج الخادم. هذه شبكة الأمان إن احتجت إلى التراجع.
- حدّث الإضافات والقوالب أولًافي ووردبريس، حدّث كل الإضافات والقوالب والنواة قبل تغيير PHP، لأن الإضافات القديمة هي السبب الأول للأعطال بعد الترقية. احذف ما لا تستخدمه.
- جرّب في بيئة تجريبية أو موقع تجريبيانسخ الموقع إلى بيئة staging أو جرّب الترقية على موقع أقل أهمية أولًا، وتصفح الصفحات الأساسية ونماذج الاتصال وسلة الشراء.
- على استضافة Hostinger (لوحة hPanel)افتح المواقع ← إدارة ← متقدم ← إعدادات PHP، واختر الإصدار الجديد ثم اضغط تحديث، وتستغرق العملية دقيقة إلى دقيقتين. انتبه: Hostinger لا يغيّر الإصدار القديم تلقائيًا، ولا يمكن الرجوع إلى إصدار أقدم بعد الترقية إلا داخل الجلسة نفسها، كما أن تغيير الإصدار يعيد إضافات PHP إلى الوضع الافتراضي، فأعد تفعيل ما تحتاجه مثل ionCube.
- على استضافة cPanelمن قسم البرامج افتح MultiPHP Manager، أو «Select PHP Version» في خوادم CloudLinux، ثم اختر النطاق والإصدار الجديد واحفظ.
- على خادم VPS مع CloudPanelافتح المواقع ← إدارة ← الإعدادات ← إعدادات PHP ← إصدار PHP، ثم اختر الفرع الجديد واحفظ.
- على خادم أوبونتو عادينفّذ
sudo apt update && sudo apt upgradeلجلب الحزم المصححة، ولتثبيت فرع أحدث نفّذsudo apt install php8.3-fpm(مع مستودع ondrej/php للفروع الأحدث)، ثم اربط خادم الويب أو حوض FPM بالإصدار الجديد. - أعد تشغيل الخدماتهذه الخطوة يُغفلها كثيرون: التحديث لا يسري حتى يُعاد تشغيل PHP-FPM وخادم الويب، مثل
sudo systemctl restart php8.3-fpm nginx، أو إعادة بناء الحاويات إن كنت تستخدم Docker. - تحقق من النتيجةتأكد عبر
php -vأو صفحة phpinfo أو أداة صحة الموقع في ووردبريس، ثم راقب سجلات الأخطاء خلال الساعات الأولى.
كيف تحمي موقع ووردبريس وأي موقع PHP بعد التحديث؟
التحديث يسد الثغرات المعروفة اليوم، لكن حماية موقع ووردبريس أو أي موقع PHP عادة مستمرة لا مهمة لمرة واحدة. هذه قائمة التحقق التي نعتمدها:
- نسخ احتياطية تلقائية يومية أو أسبوعية، تُحفظ في مكان منفصل وتُختبر استعادتها دوريًا.
- بيئة اختبار لكل تحديث كبير قبل نقله إلى الموقع الحي.
- تحديث الإضافات والقوالب قبل PHP دائمًا، وحذف غير المستخدم منها.
- جدار حماية تطبيقات الويب (WAF) مثل Cloudflare أو جدار الاستضافة لصد الطلبات المشبوهة قبل وصولها إلى PHP.
- تعطيل إضافات PHP غير المستخدمة مثل pgsql أو phar إن لم يحتجها موقعك، فكل إضافة معطلة سطح هجوم أقل.
- مبدأ أقل الصلاحيات: مستخدم قاعدة بيانات بصلاحيات محدودة، وحسابات إدارة قليلة بكلمات مرور قوية وتحقق ثنائي.
- مراقبة مستمرة لتوفر الموقع وسجلات الأخطاء لاكتشاف أي توقف مبكرًا.
- تفعيل التحديثات الأمنية التلقائية للحزم على الخوادم الخاصة.
- إعادة تشغيل PHP-FPM بعد كل تحديث للحزم، حتى لا تبقى النسخة القديمة محمّلة في الذاكرة.
وإذا كان موقعك عربيًا وتلاحظ روابط مشوهة بعد النقل أو الترقية، فراجع دليلنا حول تصحيح الرابط العربي.
ماذا تعلمنا من تدقيق 75 موقعًا في يوم واحد؟
للاطلاع على النسخة التقنية المفصلة من هذا الدليل، اقرأ مقالنا على موقع ITC: تحديث PHP وحماية الموقع، وللقراء بالإنجليزية تتوفر PHP Vulnerability 2026 Update Guide.
ما أهم النقاط التي يجب أن تتذكرها؟
هل تريد من يتولى التحديث عنك بأمان؟
يفحص فريق ITC – مركز التكنولوجيا الدولي إصدار PHP في مواقعك، ويختبر الترقية ثم ينفذها دون انقطاع، مع خطة حماية ونسخ احتياطي.
وإذا كان موقعك يعمل جيدًا تقنيًا لكنك تريد زيادة ظهوره في نتائج البحث، فاطلع على خدمات تحسين محركات البحث SEO، أو راسلنا مباشرة عبر صفحة التواصل.
الأسئلة الشائعة حول ثغرات PHP 2026
ما هي ثغرات PHP 2026؟
هي ثغرات أمنية أُعلنت وسُدت في إصدارات 2–3 يوليو و30 يوليو 2026، أبرزها CVE-2026-12184 التي قد توقف PHP-FPM بالكامل، وCVE-2026-17543 لحقن SQL في PostgreSQL، إضافة إلى ثغرات في OpenSSL وPhar وBCMath ومكتبة libgd.
ما هو إصدار PHP الآمن حاليًا؟
أي نسخة من فرع مدعوم بآخر تصحيح: 8.2.33 أو 8.3.33 أو 8.4.24 أو 8.5.9 أو أحدث. ونوصي بفرع 8.3 أو 8.4 لأن دعم 8.2 ينتهي في 31 ديسمبر 2026.
متى ينتهي دعم PHP 8.2؟
ينتهي الدعم الأمني لـ PHP 8.2 في 31 ديسمبر 2026، وبعدها لن تصله أي تصحيحات أمنية رسمية.
هل ما زال PHP 8.1 آمنًا؟
لا. انتهى دعم PHP 8.1 في 31 ديسمبر 2025، وثغرة OpenSSL الأخيرة مثلًا تمسه دون تصحيح رسمي، لذا يجب الترقية في أقرب وقت.
ما هي ثغرة PHP-FPM ومن يتأثر بها؟
هي الثغرة CVE-2026-12184 في غلاف HTTP، وتسمح لمهاجم عن بُعد بإسقاط عملية PHP-FPM وكل عمالها عند فشل إعداد TLS، فيتوقف الموقع حتى إعادة التشغيل. تمس الفروع 8.3 و8.4 و8.5 قبل 8.3.32 و8.4.21 و8.5.6، خصوصًا التطبيقات التي ترسل طلبات HTTPS خارجية.
هل يتأثر موقع ووردبريس بهذه الثغرات؟
نعم إن كان الخادم يعمل بإصدار PHP غير مصحح، لأن ووردبريس يعمل فوق PHP. أما ثغرة PostgreSQL فلا تمس أغلب مواقع ووردبريس لأنها تعمل على MySQL أو MariaDB.
كيف أعرف إصدار PHP في موقعي؟
في ووردبريس من الأدوات ثم صحة الموقع ثم معلومات ثم الخادم، أو من لوحة الاستضافة، أو بالأمر php -v على الخادم، أو عبر صفحة phpinfo مؤقتة تحذفها بعد الاطلاع.
هل تحدّث Hostinger إصدار PHP تلقائيًا؟
لا. تخفي Hostinger الإصدارات القديمة من قائمة الاختيار، لكنها لا تغيّر الإصدار القديم المفعّل لديك تلقائيًا، لذلك يجب تغييره يدويًا من إعدادات PHP لكل موقع.
لماذا يجب إعادة تشغيل PHP-FPM بعد التحديث؟
لأن العمليات العاملة تبقى محمّلة بالنسخة القديمة في الذاكرة. إعادة تشغيل PHP-FPM وخادم الويب أو الحاويات تضمن أن النسخة المصححة هي التي تعمل فعلًا.
هل أنتقل إلى PHP 8.6؟
ليس الآن. PHP 8.6 ما زال في مرحلة الإصدار المرشح (RC3 في 6 أكتوبر 2026) ولم يصدر بنسخة مستقرة، فلا يُنصح باستخدامه في المواقع الحية.
