ثغرة خطيرة في PHP تهدد ملايين المواقع: الإصدارات المتأثرة وطريقة الحماية

ما الثغرتان وما سبب خطورتهما؟

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

أما CVE-2026-109619 فتتعلق ببقاء حالة داخلية مرتبطة بطلب سابق بعد تحرير الذاكرة التي كانت تخزنها. إذا أعاد العامل نفسه معالجة طلب لاحق قبل تصفير الحالة القديمة، فقد يستخدم بيانات لم تعد صالحة. تُعرف هذه الفئة عادةً باسم Use-After-Free، أي استخدام الذاكرة بعد تحريرها. وهي مشكلة منخفضة المستوى في وقت التشغيل، وليست بالضرورة خطأً في كود التطبيق الذي كتبه المطور.

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

من المتأثر؟ وما الإصدارات الآمنة؟

أعلن مشروع PHP عن إصلاحات للفروع المدعومة التالية: PHP 8.5.12، وPHP 8.4.27، وPHP 8.3.36، وPHP 8.2.35. وتُعد الإصدارات الأقدم من رقم الإصلاح في الفرع نفسه معرضة للخطر وفق الإرشادات المنشورة. أما PHP 8.1 والإصدارات الأقدم فقد انتهى دعمها upstream؛ وقد توفر بعض توزيعات Linux أو مزودي الدعم طويل الأجل إصلاحات backport، لذا يجب التحقق من حزمة النظام نفسها بدل افتراض أن رقم الإصدار وحده يحسم الأمر.

تشمل البيئات المعنية PHP-FPM وApache مع mod_php وphp-cgi وLiteSpeed وFrankenPHP. وتشير الإرشادات الرسمية إلى أن المخاطر الأعلى لوحظت في mod_php بسبب مسار استغلال مثبت قبل تشغيل كود التطبيق. كما قد تتضمن بعض المنتجات الجاهزة أو الحاويات نسخة PHP لا يلاحظها مدير الموقع عند فحص إعداداته المعتادة.

لا يكفي أن ترى PHP حديثًا في الطرفية أو في إصدار محلي على جهازك؛ المطلوب هو التحقق من النسخة التي تستخدمها طلبات الويب في بيئة الإنتاج. فقد تختلف نسخة CLI عن نسخة FPM أو Apache، وقد تكون هناك عدة مواقع أو حاويات تعمل بإصدارات مختلفة.

خطوات عاجلة لتحديث الموقع بأمان

1. احصر الأنظمة: سجّل كل موقع وتطبيق وخادم وحاوية تستخدم PHP، بما في ذلك المواقع القديمة واللوحات الداخلية والمهام المجدولة.
2. تحقق من نسخة الويب: استخدم لوحة الاستضافة أو معلومات الخادم في التطبيق، ثم قارنها بنسخة CLI. لا تترك ملف phpinfo.php مكشوفًا للعامة؛ إن احتجته للتشخيص فاحمه واحذفه بعد الانتهاء.
3. خذ نسخة احتياطية قابلة للاستعادة: احفظ قاعدة البيانات والملفات وملفات الإعداد، واختبر إمكانية الاستعادة. النسخة الاحتياطية غير المختبرة ليست خطة تعافٍ مؤكدة.
4. حدّث إلى إصدار مصحح: اختر أحدث إصدار أمني متاح ومدعوم في فرعك، أو اطلب من شركة الاستضافة تأكيدًا مكتوبًا بالإصدار الذي تم تثبيته. لا تفترض أن تحديث WordPress أو Laravel وحده يصلح PHP.
5. اختبر بعد التحديث: راجع صفحات تسجيل الدخول، ورفع الملفات، والمهام الخلفية، والاتصالات بقاعدة البيانات، والسجلات. أعد تشغيل أو تدوير عمال PHP-FPM والخدمات ذات الصلة حتى لا تبقى عمليات قديمة.
6. تحقق من كل بيئة: راجع الإنتاج والاختبار والتطوير والحاويات وصور النشر وخوادم النسخ الاحتياطي التي قد تستقبل طلبات شبكة.

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

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

هل توجد حلول مؤقتة قبل التحديث؟

نشر فريق PHP بعض إجراءات تقليل التعرض لمسارات استغلال محددة، لكنها ليست بديلًا عن تثبيت الإصلاح. من بينها مراجعة إعدادات حدود الذاكرة وأحجام POST والرفع، وتعطيل session.upload_progress.enabled على مستوى الخادم أو FPM ثم إعادة تشغيل العمال، ومراجعة إعدادات fatal_error_backtraces على PHP 8.5. يجب تطبيق هذه التدابير وفق الإرشادات الرسمية وبالتنسيق مع مسؤول النظام، لأنها قد تؤثر في وظائف رفع الملفات أو التشخيص.

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

كيف تتحقق من نجاح التحديث؟

بعد تثبيت الإصلاح، لا تعتمد على رسالة نجاح واحدة. راجع رقم الإصدار الذي يعرضه إعداد PHP في لوحة الاستضافة، ثم تحقق من الخدمة التي تعالج الطلبات الفعلية. في الخادم الذي تديره بنفسك، قد تحتاج إلى مراجعة php -v ونسخة php-fpm أو وحدة Apache وحزم النظام، مع الانتباه إلى أن هذه الأوامر قد تعرض نسخًا مختلفة. إذا كان لديك أكثر من إصدار مثبت، فحدد المسار الذي يستخدمه كل موقع بدل الاكتفاء بأول نتيجة.

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

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

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

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

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

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

أخطاء شائعة ينبغي تجنبها

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

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

الخلاصة: لا تنتظر حتى تظهر علامات الهجوم

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

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

قائمة مراجعة سريعة لمدير الموقع

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

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

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

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

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

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

What Are the Two Vulnerabilities, and Why Are They Serious?

CVE-2026-109618 concerns PHP's handling of out-of-memory conditions while processing requests. Under certain circumstances, initialization of internal request data can be interrupted before it is complete. Cleanup code may then treat partially initialized data as valid. Memory-management failures of this kind can produce unexpected behavior and, in this case, may lead to remote code execution.

CVE-2026-109619 involves internal request state surviving after the memory backing it has been freed. If the same worker handles another request before the old state is reset, it may access data that is no longer valid. This class of flaw is commonly called use-after-free. It is a runtime-level problem, not necessarily a bug in the application code written by a developer.

The key point is that an attacker may not need a user account or password to target the server. The vulnerable path can occur before normal application logic runs, limiting what a developer can accomplish by changing a page or adding validation in Laravel or WordPress. That does not mean every attempt will succeed: exploitability depends partly on the PHP deployment model and server configuration. Still, the official severity rating makes this an urgent maintenance issue.

Who Is Affected, and Which Versions Are Fixed?

The PHP project released fixes for these supported branches: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36, and PHP 8.2.35. Earlier releases within each branch are considered vulnerable according to the published guidance. PHP 8.1 and older have reached upstream end of life; some Linux distributions or long-term-support vendors may provide backported fixes, so verify the actual system package instead of assuming the version number alone tells the whole story.

Relevant deployment models include PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed, and FrankenPHP. Official guidance identifies mod_php as the highest-risk configuration because a demonstrated exploit can reach the vulnerable path before application code executes. Bundled products and containers may also include a PHP runtime that is not obvious from a site's usual settings.

Seeing a recent PHP version in your terminal or on a development computer is not enough. You need to confirm the runtime that actually handles production web requests. CLI, FPM, and Apache may use different versions, and several websites or containers may be running separate runtimes.

Urgent Steps to Update a Website Safely

1. Inventory systems: List every site, application, server, and container using PHP, including legacy sites, internal dashboards, and scheduled jobs.
2. Verify the web runtime: Check the hosting panel or application server information and compare it with the CLI version. Never leave a public phpinfo.php file exposed; if needed for diagnosis, restrict access and remove it afterward.
3. Take a restorable backup: Back up databases, files, and configuration, then test restoration. An untested backup is not a proven recovery plan.
4. Install a fixed release: Choose the latest supported security release in your branch, or ask the host to confirm the exact version installed. Updating WordPress or Laravel alone does not patch PHP itself.
5. Test after the update: Check login, file uploads, background jobs, database connectivity, and logs. Restart or recycle PHP-FPM workers and related services so old worker processes do not remain in service.
6. Check every environment: Review production, staging, development, containers, deployment images, and backup servers that may accept network requests.

On shared hosting, customers may not have permission to update the PHP runtime directly. Open an urgent support ticket, cite the two CVEs and the current version, and request confirmation of the patched release. If the control panel lets you select PHP versions, verify that the change applies to the correct domain and that subdomains use the intended setting.

For self-managed servers, update through the operating system's package manager or an official container image. Do not manually mix PHP binaries from untrusted sources. In containerized environments, rebuild and redeploy the image; updating only the host does not fix an old image that is still running.

Are There Temporary Mitigations Before Patching?

The PHP team published measures that reduce exposure to specific exploit paths, but these are not substitutes for installing the fix. They include reviewing memory and POST/upload limits, disabling session.upload_progress.enabled at the server or FPM level and restarting workers, and reviewing fatal_error_backtraces on PHP 8.5. Apply these measures according to the official guidance and with the system administrator's help, since they can affect uploads or diagnostics.

Do not change memory_limit to unlimited indiscriminately without understanding resource implications; the official recommendation addresses a particular path and does not guarantee protection against every allocation failure. Hiding error messages with display_errors or error_reporting does not repair the underlying flaw. A patched release is the complete fix, and any temporary mitigation should be short-lived and documented.

How to Verify That the Update Worked

Do not rely on a single success message after patching. Check the PHP version reported by the hosting panel, then verify the service that actually handles requests. On a self-managed server, you may need to inspect php -v, the PHP-FPM service or Apache module, and the operating-system packages. These can report different versions. If multiple releases are installed, identify the runtime used by each website instead of trusting the first result.

Test a normal page, an authenticated page, and a file upload if the application supports uploads. Monitor web-server, PHP, and application logs for new errors or repeated worker restarts. Confirm that scheduled jobs and queue workers use the intended runtime too; CLI tasks may continue using a different version from the web service.

For automated deployments, update the build configuration or container image, rebuild, and redeploy while recording the new version. If you use a load balancer or several servers, verify every node rather than updating just one. Keep a rollback plan for functional regressions, but do not roll back to a vulnerable PHP release as an acceptable fix. If compatibility problems appear, isolate the affected service and resolve them while maintaining the required security level.

What If You Suspect a Compromise?

Patching closes the vulnerability but does not prove that a server was never exploited before the update. Unexpected processes, newly created PHP files in upload directories, unknown administrator accounts, or unexplained outbound connections should be treated as possible incident indicators. Preserve logs and evidence before deleting files or rebuilding the server; hurried cleanup can destroy information needed to understand how access occurred.

Review access, error, and authentication logs, looking for unusual requests, suspicious timing, and changes to application files or scheduled tasks. Compare deployed files with a trusted source or known-good build. Review SSH keys, hosting-panel accounts, and credentials that may have been exposed. If there are credible signs of compromise, isolate the server according to your incident-response plan and involve an incident-response specialist instead of merely changing one password.

After containment, rotate potentially exposed secrets and passwords, revoke sessions and tokens where appropriate, and redeploy from a clean source. Do not restore executable files or backups from the suspected compromise period without examining them. Document what happened and what was fixed, then add monitoring to prevent recurrence. These are general precautions; they do not mean every site running a vulnerable version has already been compromised.

Common Mistakes to Avoid

• Assuming a framework update automatically patches the PHP runtime.
• Checking the local development version instead of the production runtime.
• Updating the primary server but forgetting an old container or subdomain.
• Relying on a web application firewall alone; it may block some requests but cannot repair a memory flaw in PHP itself.
• Delaying because the website appears to work normally; many vulnerabilities have no visible symptoms.
• Installing binaries from random links or disabling other security controls to work around compatibility problems.

Monitoring, request-size limits, and reducing exposed services can lower risk, but they are not substitutes for the patch. Treat temporary mitigations as controls for specific attack paths, not as a guarantee of complete protection.

Conclusion: Do Not Wait for Signs of an Attack

The PHP vulnerabilities disclosed on October 21, 2026, are serious because they may enable unauthenticated remote code execution in a runtime used by many applications. Inventory affected environments, install the appropriate fixed release, restart services, verify the web runtime, and monitor logs. If immediate patching is impossible, contact the hosting provider and reduce exposure using official guidance, treating those measures as temporary only.

Primary references include the official PHP website and national cybersecurity advisories. For a broader operational approach, see our cybersecurity guide to protecting data, accounts, and networks and the guide to evaluating software updates before production.

A Quick Checklist for Website Owners

Turn the security alert into a task with a named owner and deadline. Start with internet-facing sites that handle sensitive data, payments, or user accounts. Record each server, PHP deployment model, current version, target fixed version, patch time, and test result. For a large estate, use a central inventory rather than relying on each developer's memory.

Before patching, notify support teams if service impact is possible and schedule a maintenance window when needed. After the update, test critical user journeys and check logs for new errors. Record the fixed version in the change log and update server templates so new environments are not built from an outdated image.

Do not treat this alert as a one-time task. Make security-release review part of routine operations: subscribe to PHP, operating-system, and hosting-provider advisories, track end-of-life dates, and test routine security updates in a short-lived staging environment when the risk allows. For critical flaws, testing must be fast and proportionate to the threat, not a reason for an indefinite delay.

Finally, keep the official advisory as your reference rather than relying on reposts. Confirm that the fixed version matches the branch you run, since patch numbers differ across branches. If your provider manages PHP for you, ask them to confirm that the web runtime—not only the CLI installation—has been updated.

Keep the package name, build identifier, and service restart time in the change log so the team can later verify what changed. If a legacy dependency prevents an immediate upgrade, document the exception, owner, deadline, and isolation plan rather than leaving the risk open-ended.