--- title: Your WordPress dashboard can show all green while the PHP under your store is unpatched title_ar: كل شيء محدّث في لوحة ⁨WordPress⁩، وقد يبقى ⁨PHP⁩ الذي يشغّل متجرك دون الإصلاح الأمني url: "https://www.aiwithmo.com/prompts/php-update-wordpress-host" canonical: "https://www.aiwithmo.com/prompts/php-update-wordpress-host" published: 2026-10-23 updated: 2026-10-23 category: ai-tools languages: [ar, en] author: Mohamed Khair site: aiwithmo --- # Your WordPress dashboard can show all green while the PHP under your store is unpatched ## كل شيء محدّث في لوحة ⁨WordPress⁩، وقد يبقى ⁨PHP⁩ الذي يشغّل متجرك دون الإصلاح الأمني Source: https://www.aiwithmo.com/prompts/php-update-wordpress-host · Author: Mohamed Khair (محمد خير), aiwithmo · Published in Arabic and English. ## English If you sell through WordPress or WooCommerce, the green checks on your Updates screen cover WordPress and everything installed on it. PHP, the language your server uses to run all of it, never appears on that screen, and PHP is where the two flaws fixed on 21 October 2026 sit. The PHP project rated both flaws 9.2 out of 10 and says they can allow unauthenticated remote code execution: someone with no account on your site running their own code on your server. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, per the [php.net advisory](https://www.php.net/archive/2026.php). PHP lives on the server, so the fix arrives through whoever runs the server: your hosting company, or you, if you rent a VPS and manage it yourself. An attempt to exploit the flaws reached Amazon's honeypot servers on 17 October, four days before the fix was public. Amazon reports broad attempts since then and says it is unclear whether any of them would have succeeded against real systems, per its [threat intelligence post](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/). AI tools helped researchers find at least one of these flaws. [Wiz](https://www.wiz.io/blog/php2shell-php-rce) says Gemini 4 Argon "made an invaluable contribution to finding the vulnerability", and [Calif](https://calif.io/php2shell/), the team that first reported one of them, says its AI agent ran with no special harness, on models available to everyone. The [PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) thanks OpenAI and Anthropic for access to their tools and says "a person makes every call and works on every patch". The check takes two minutes in WordPress, and the message to your host is ready to copy at the bottom of this page. Follow for more: - https://www.instagram.com/ai.with.mo/ Course Registration: https://halaqa.app/enrollment?course=start-with-ai ## العربية تفتح صفحة التحديثات في لوحة تحكم متجرك، فتجد أن ⁨WordPress⁩ وكل إضافاته على أحدث إصدار، ولا شيء ينتظر التحديث. هذه الصفحة تطمئنك على جزء من المتجر فقط. الإصلاح المطلوب يخص جزءًا آخر اسمه ⁨PHP⁩، وهو اللغة التي يعمل بها المتجر كله، ويُثبَّت على الخادم لدى شركة الاستضافة، لا داخل ⁨WordPress⁩. في ⁨21⁩ أكتوبر ⁨2026⁩ أصدر [مشروع ⁨PHP⁩](https://www.php.net/archive/2026.php) تحديثًا أمنيًا عاجلًا لثغرتين تُعرفان معًا باسم ⁨PHP2Shell⁩. قد تسمح الثغرتان لشخص لا يملك حسابًا ولا كلمة مرور بأن يشغّل أوامر برمجية على الخادم، وتبلغ درجة خطورة كل منهما ⁨9.2⁩ من ⁨10⁩ على مقياس ⁨CVSS⁩. الإصلاح موجود في الإصدارات ⁨8.5.12⁩ و⁨8.4.27⁩ و⁨8.3.36⁩ و⁨8.2.35⁩، ولا يثبّته إلا من يدير الخادم: شركة الاستضافة إن كانت استضافتك مشتركة أو مُدارة، أو أنت أو مطوّرك إن كان متجرك على ⁨VPS⁩ تديره بنفسك. رصدت [⁨Amazon⁩](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) يوم ⁨17⁩ أكتوبر ⁨2026⁩، أي قبل نشر الإصلاح بأربعة أيام، محاولةً لاستغلال الثغرتين على خوادم وهمية تنشرها عمدًا لاستدراج المهاجمين، ثم كثرت المحاولات بعد الإعلان. ولا تجزم ⁨Amazon⁩ بأن أيًّا من هذه المحاولات كان سينجح على مواقع حقيقية، وتنصح من يراجع سجلات خادمه بأن يبدأ من ⁨17⁩ أكتوبر. ساعدت أدوات الذكاء الاصطناعي الباحثين في العثور على إحدى الثغرتين على الأقل. تقول [⁨Wiz⁩](https://www.wiz.io/blog/php2shell-php-rce) إن نموذج ⁨Gemini 4 Argon⁩ أفادها كثيرًا في اكتشاف الثغرة، واستعان فريق [⁨Calif⁩](https://calif.io/php2shell/)، أول من أبلغ عن إحداهما، بنموذج لغوي متاح للجميع، استخدمه كما هو دون أي إعداد خاص. وتقول [مؤسسة ⁨PHP⁩](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) إن البشر هم من يتخذون كل قرار ويعملون على كل إصلاح. معرفة إصدار ⁨PHP⁩ تستغرق دقيقتين من لوحة ⁨WordPress⁩ نفسها، والرسالة الجاهزة لشركة الاستضافة موجودة بالعربية في القسم الثالث، وبالإنجليزية في مربع النسخ أسفل الصفحة. تابعني على ⁨Instagram⁩: - https://www.instagram.com/ai.with.mo/ التسجيل في الدورة: https://halaqa.app/enrollment?course=start-with-ai ## Steps ### 1. Updating WordPress cannot reach the PHP under your store *The flaws sit in the language the server runs, which loads before WordPress and every plugin.* Think of a WooCommerce store as layers. WooCommerce is a plugin, it runs inside WordPress, WordPress is written in PHP, and PHP is installed on the server your host gives you. The Updates screen in wp-admin manages the upper layers: WordPress itself, themes, plugins and translations. It has no button for PHP, because PHP belongs to the server. Automattic, the company behind WordPress.com, says it directly in its [note to site owners](https://automattic.com/2026/10/21/your-sites-are-protected-against-the-php2shell-vulnerabilities/): "This is a runtime fix, so updating WordPress, your theme, or your plugins will not protect you on its own." Security plugins do not close the gap either. Meow Apps explains in its [guide for WordPress owners](https://meowapps.com/php2shell-wordpress/) that the attack happens inside PHP before WordPress and its plugins start, so security and firewall plugins never see it. The PHP project's advisory puts every PHP installation that serves web requests at risk, whichever way the host runs PHP. It lists configuration changes for servers that cannot update at once and says they reduce exposure without making an installation safe. Only an update to PHP is a complete solution. ### 2. Site Health shows your PHP version, and your host confirms the rest *Some hosts install the fix without changing the version number, so a number at or above the fixed release proves the fix, and a lower one proves nothing yet.* Log in to wp-admin as an administrator and open Tools, then Site Health, then the Info tab. Expand the Server section and find the line labelled PHP version. This is the standard path in self-hosted WordPress, and the [WordPress documentation](https://wordpress.org/documentation/article/site-health-screen/) describes the screen. Read the first two numbers as the branch and the last one as the release. On 8.3 the fixed release is 8.3.36. On 8.4 it is 8.4.27, on 8.5 it is 8.5.12, and on 8.2 it is 8.2.35. Compare the last number as a whole number: 8.2.4 is lower than 8.2.35, because 4 is lower than 35. If Site Health shows the fixed release for your branch or a later one, PHP on your server has the fix. If the number is lower, ask your host before you conclude anything. Some hosts and Linux systems add the fix without changing the version number, as Meow Apps notes, and Hostinger says the same about its managed plans in its [update](https://www.hostinger.com/blog/protecting-php2shell/): "the version number may not change." If the line starts with 8.1, 8.0 or 7, read the last section first. ### 3. Who runs PHP on your server decides what you do next *On managed hosting you ask in writing. On a VPS you manage, you or your developer install the update.* Two companies have said publicly that customers on their managed plans need to do nothing. Automattic lists WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr as already protected: "There is nothing you need to do." Hostinger finished patching on 22 October 2026 at 06:44 UTC and says every plan except VPS needs no action. On Hostinger you can check it yourself: in its dashboard, open Websites, then Dashboard, then PHP Info. A Build Date of 21 October 2026 or later means the fix is in. On any other managed or shared host, open a support ticket or send an email, so the answer is written down: > Hello. I want to confirm one security point for my website on this account. Has the PHP security update released on 21 October 2026 (CVE-2026-109618 and CVE-2026-109619) been installed on the server my site runs on? Please confirm in writing, and tell me which PHP version my site runs on. If the update is not installed yet, when will it be? On a VPS you manage, nobody patches PHP for you. Hostinger says so for its own VPS customers: "you manage PHP yourself, so our server-level protections don't apply." Update PHP through the server's package manager or its control panel to the fixed release for your branch, or install your Linux distribution's security update for CVE-2026-109618 and CVE-2026-109619 (its version number can look older), then restart PHP so the new build is the one serving your pages. The PHP project says Linux distributions received the patches in advance, so their updated packages are the normal route. If a developer set the server up, the copy block has a message for them. Amazon advises that any review of server logs start from 17 October, the date of the earliest attempt it recorded. ### 4. PHP 8.1 and older get no new release from the PHP project, so plan the upgrade *A host's own patched build can fix an old version, and a firewall can reduce the risk for a while. The PHP project itself no longer releases updates for it.* The PHP project's advisory says PHP 8.1 and older no longer receive updates from it, and 8.1 reached end of life on 31 December 2025, per the [end of life table](https://www.php.net/eol.php). The project did publish minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux distributions and long-term support vendors ship their own backported fixes. Some hosts also patched old versions in their own builds: Hostinger deployed patched builds for every version from 5.2 to 8.5 on its Web, Cloud and cPanel hosting. If your site runs an old version with another host, ask in the same written message whether they installed a backported fix for it. Either way, plan the move. PHP 8.2 gets security fixes only until 31 December 2026, so aim for 8.3 or newer: 8.3 is supported until 31 December 2027, 8.4 until the end of 2028 and 8.5 until the end of 2029, per the [supported versions page](https://www.php.net/supported-versions.php). Ask your host or developer to test the store on a staging copy first, since your theme and every plugin have to work on the new version. If your site already runs behind Cloudflare, Cloudflare's WAF rules for these flaws were switched on by default at 03:02 UTC on 21 October for every plan with the WAF, Free included, per [Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/). Free plans need no setup; on a paid plan, Cloudflare asks you to confirm in your Managed Ruleset that the rules run in block mode. Cloudflare has seen attackers change their requests to try to get past the rules, and says to patch PHP even with those rules in place. ## الخطوات ### 1. تحديث ⁨WordPress⁩ وإضافاته لا يصل إلى ⁨PHP⁩ *الإصلاح يُثبَّت على الخادم وحده، وإضافات الأمان في ⁨WordPress⁩ لا تغني عنه* متجرك يقوم على إضافة اسمها ⁨WooCommerce⁩، وهي تعمل داخل ⁨WordPress⁩، و⁨WordPress⁩ نفسه مكتوب بلغة ⁨PHP⁩، و⁨PHP⁩ برنامج مثبّت على الخادم. صفحة «التحديثات» في لوحة التحكم ليس فيها زرّ لتحديث ⁨PHP⁩. وتقول [⁨Automattic⁩](https://automattic.com/2026/10/21/your-sites-are-protected-against-the-php2shell-vulnerabilities/)، الشركة التي تدير ⁨WordPress.com⁩، إن الإصلاح يخص ⁨PHP⁩ نفسه، وإن تحديث ⁨WordPress⁩ أو القالب أو الإضافات لا يحمي موقعك وحده. ويشرح موقع [⁨Meow Apps⁩](https://meowapps.com/php2shell-wordpress/) السبب: استغلال الخلل يحدث داخل ⁨PHP⁩ قبل أن يبدأ ⁨WordPress⁩ وإضافاته في العمل، فلا تراه هذه الإضافات أصلًا. لهذا لن تفيدك إضافة أمان جديدة، ولا إضافة ⁨firewall⁩ تثبّتها من داخل ⁨WordPress⁩. ويقول مشروع ⁨PHP⁩ في تحذيره إن كل خادم يعمل عليه ⁨PHP⁩ غير محدَّث ويخدم موقعًا على الإنترنت معرّض للخطر، أيًّا كانت الطريقة التي تشغّله بها شركة الاستضافة. ويذكر المشروع إعدادات تقلل الخطر على الخوادم التي لا يمكن تحديثها فورًا، ثم يوضح أنها لا تجعل الخادم آمنًا، وأن التحديث وحده هو الحل الكامل. ### 2. صفحة «صحّة الموقع» تكشف إصدار ⁨PHP⁩ الذي يعمل عليه متجرك *لكل فرع من ⁨PHP⁩ إصدار مصحَّح خاص به، فقارن رقمك بإصدار فرعك فقط* من لوحة التحكم افتح «أدوات»، ثم «صحّة الموقع» (⁨Site Health⁩)، ثم تبويب «معلومات»، ثم قسم «الخادم»، وابحث عن سطر «إصدار ⁨PHP⁩». وإن كانت لوحتك بالإنجليزية فالمسار هو ⁨Tools > Site Health > Info > Server > PHP version⁩. ويشرح [توثيق ⁨WordPress⁩](https://wordpress.org/documentation/article/site-health-screen/) هذه الشاشة وأقسامها. يتألف الرقم الذي تراه من ثلاثة أجزاء. في ⁨8.3.36⁩ مثلًا، الجزءان الأولان (⁨8.3⁩) هما الفرع، والجزء الأخير (⁨36⁩) رقم التحديث داخل هذا الفرع. الإصدارات التي تحمل الإصلاح هي ⁨8.5.12⁩ للفرع ⁨8.5⁩، و⁨8.4.27⁩ للفرع ⁨8.4⁩، و⁨8.3.36⁩ للفرع ⁨8.3⁩، و⁨8.2.35⁩ للفرع ⁨8.2⁩. إذا كان رقمك يساوي الإصدار المصحَّح في فرعه أو يزيد عليه، فالإصلاح موجود. وقارن الجزء الأخير عددًا كاملًا: ⁨8.2.4⁩ أقل من ⁨8.2.35⁩ لأن ⁨4⁩ أقل من ⁨35⁩. وإن كان الرقم أقل، فهذا لا يعني بالضرورة أن الإصلاح غير مثبّت. يذكر ⁨Meow Apps⁩ أن بعض شركات الاستضافة وبعض توزيعات ⁨Linux⁩ تضيف الإصلاح دون أن يتغيّر رقم الإصدار، وتقول [⁨Hostinger⁩](https://www.hostinger.com/blog/protecting-php2shell/) إن الرقم على استضافتها المُدارة قد لا يتغيّر. في هذه الحالة فالجواب عند من يدير الخادم، والرسالة الجاهزة لشركة الاستضافة في القسم التالي. وإن كان فرعك ⁨8.1⁩ أو أقدم، فابدأ بالقسم الرابع. ### 3. الخطوة التالية يحددها من يدير ⁨PHP⁩ على الخادم *في الاستضافة المشتركة أو المُدارة يكفيك ردّ مكتوب من الشركة، أما على ⁨VPS⁩ تديره بنفسك فالتحديث مسؤوليتك أو مسؤولية مطوّرك* إن كان متجرك على ⁨WordPress.com⁩ أو ⁨WordPress VIP⁩ أو ⁨WP Cloud⁩ أو ⁨Pressable⁩، فقد أعلنت ⁨Automattic⁩ في ⁨21⁩ أكتوبر ⁨2026⁩ أن هذه المواقع محمية، فلا يُطلب منك شيء. وأنهت ⁨Hostinger⁩ تثبيت الإصلاح يوم ⁨22⁩ أكتوبر الساعة ⁨06:44⁩ بتوقيت ⁨UTC⁩ على كل خططها ما عدا ⁨VPS⁩. وإن كنت على ⁨Hostinger⁩ وأردت التأكد، فافتح لوحة التحكم واذهب إلى ⁨Websites > Dashboard > PHP Info⁩، فإن كان تاريخ ⁨Build Date⁩ هو ⁨21⁩ أكتوبر ⁨2026⁩ أو بعده فالإصلاح مثبّت. هذا الفحص نشرته ⁨Hostinger⁩ لعملائها، فلا تعتمده قاعدةً عند شركة استضافة أخرى. إن كانت استضافتك عند شركة أخرى، مشتركة كانت أو مُدارة، فلا تفترض أنها ثبّتت الإصلاح، واطلب من فريق الدعم ردًّا مكتوبًا. هذه رسالة يمكنك نسخها كما هي، وإن كانوا يتعاملون بالإنجليزية فستجد ترجمتها في مربع النسخ أسفل الصفحة: > مرحبًا، > > أودّ التأكد من أمر يخص أمان الموقع المستضاف على هذا الحساب. هل ثبّتّم على الخادم الذي يعمل عليه موقعي تحديث ⁨PHP⁩ الأمني الصادر في ⁨21⁩ أكتوبر ⁨2026⁩، الخاص بالثغرتين ⁨CVE-2026-109618⁩ و⁨CVE-2026-109619⁩؟ > > أرجو أن تؤكدوا لي ذلك كتابيًا، وأن تذكروا إصدار ⁨PHP⁩ الذي يعمل عليه الموقع. وإن لم يُثبَّت التحديث بعد، فمتى تتوقعون تثبيته؟ > > شكرًا لكم. على ⁨VPS⁩ تديره بنفسك لا أحد يحدّث ⁨PHP⁩ نيابة عنك. تقول ⁨Hostinger⁩ لعملاء ⁨VPS⁩ إنهم يديرون ⁨PHP⁩ بأنفسهم، وإن الحماية التي ثبّتتها على خوادمها لا تشملهم. المطلوب أن تحدّث أنت أو مطوّرك ⁨PHP⁩ إلى الإصدار المصحَّح لفرعه، عبر أمر التحديث في نظام تشغيل الخادم أو من لوحة إدارته، ثم يُعاد تشغيل ⁨PHP⁩. وبحسب مشروع ⁨PHP⁩ وصلت الإصلاحات إلى توزيعات ⁨Linux⁩ قبل الإعلان، فإن كان ⁨PHP⁩ على خادمك مثبّتًا من حزم التوزيعة، فالطريق المعتاد هو تثبيت تحديثها الأمني الخاص بالثغرتين ⁨CVE-2026-109618⁩ و⁨CVE-2026-109619⁩، حتى لو بدا رقم الإصدار بعده أقدم من الأرقام السابقة. رسالة جاهزة لمطوّرك تجدها بالإنجليزية في مربع النسخ، وفيها طلب مراجعة سجلات الخادم ابتداءً من ⁨17⁩ أكتوبر ⁨2026⁩، وهو التاريخ الذي تنصح ⁨Amazon⁩ بالبدء منه. ### 4. لا إصدار جديد من مشروع ⁨PHP⁩ للفرع ⁨8.1⁩ وما قبله، فخطّط للترقية *قد تضيف شركة الاستضافة الإصلاح إلى إصدارك القديم، والترقية تبدأ بنسخة تجريبية من المتجر* انتهى دعم ⁨PHP 8.1⁩ في ⁨31⁩ ديسمبر ⁨2025⁩ بحسب [صفحة الإصدارات المتوقفة عن الدعم](https://www.php.net/eol.php)، ولذلك لم يُصدر المشروع إصدارًا جديدًا لهذا الفرع ولا لما قبله. اكتفى بنشر تعديلات برمجية (⁨patches⁩) للفروع ⁨7.4⁩ و⁨8.0⁩ و⁨8.1⁩، وهي موجّهة إلى من يجمّع ⁨PHP⁩ من شيفرته المصدرية بنفسه. وأضافت بعض توزيعات ⁨Linux⁩ والشركات التي تبيع دعمًا طويل الأمد الإصلاحَ إلى الإصدارات القديمة التي توفّرها، ومن شركات الاستضافة من فعل الشيء نفسه: تقول ⁨Hostinger⁩ إنها ثبّتت نسخًا مصحّحة لكل الإصدارات من ⁨5.2⁩ إلى ⁨8.5⁩ على استضافات ⁨Web⁩ و⁨Cloud⁩ و⁨cPanel⁩. اسأل شركة استضافتك كتابيًا إن كانت فعلت ذلك للإصدار الذي يعمل عليه متجرك. وحتى لو وصلك هذا الإصلاح، فلن يُصدر المشروع تحديثًا لفرعك إن اكتُشفت ثغرة جديدة لاحقًا، لذلك خطّط للانتقال إلى ⁨8.3⁩ أو أحدث. بحسب [جدول الإصدارات المدعومة](https://www.php.net/supported-versions.php) ينتهي الدعم الأمني للفرع ⁨8.2⁩ في ⁨31⁩ ديسمبر ⁨2026⁩، وللفرع ⁨8.3⁩ في ⁨31⁩ ديسمبر ⁨2027⁩، وللفرع ⁨8.4⁩ في ⁨31⁩ ديسمبر ⁨2028⁩، وللفرع ⁨8.5⁩ في ⁨31⁩ ديسمبر ⁨2029⁩. جرّب الترقية أولًا على نسخة تجريبية من المتجر (⁨staging⁩)، لتتأكد أن القالب وكل الإضافات تعمل على الإصدار الجديد قبل أن تطبّقه على المتجر الذي يشتري منه زبائنك. وإلى أن تنتهي الترقية، إن كان موقعك يمرّ بالفعل عبر ⁨Cloudflare⁩، فقد فعّلت [⁨Cloudflare⁩](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) قواعد ⁨WAF⁩ خاصة بهاتين الثغرتين يوم ⁨21⁩ أكتوبر ⁨2026⁩ الساعة ⁨03:02⁩ بتوقيت ⁨UTC⁩، في كل الخطط التي تتضمن ⁨WAF⁩ بما فيها المجانية. ولا يحتاج أصحاب الخطة المجانية إلى أي إعداد، أما على الخطط المدفوعة فتطلب ⁨Cloudflare⁩ التأكد من أن هذه القواعد تعمل في وضع الحظر (⁨block⁩). تفحص هذه القواعد الطلبات قبل وصولها إلى خادمك، لكنها لا تغني عن التحديث: تقول ⁨Cloudflare⁩ إنها رصدت مهاجمين يعدّلون طلباتهم في محاولة لتجاوز هذه القواعد، وتطلب من عملائها تحديث ⁨PHP⁩ رغم وجودها. ## Prompt (البرومبت) ```text # PHP SECURITY UPDATE CHECK FOR A WORDPRESS OR WOOCOMMERCE SITE # For the two PHP flaws fixed on 21 October 2026 # (CVE-2026-109618 and CVE-2026-109619). # Updating WordPress, your theme or your plugins does not install this fix. # Security and firewall plugins do not cover it either. # ─── 1. READ YOUR PHP VERSION ─── # wp-admin > Tools > Site Health > Info tab > Server > "PHP version" # Fixed release per branch (that release or a later one has the fix): # 8.5: 8.5.12 8.4: 8.4.27 8.3: 8.3.36 8.2: 8.2.35 # Compare the last number as a whole number: 8.2.4 is lower than 8.2.35. # A lower number does not prove the fix is missing: some hosts patch # without changing the version number. Only the host can confirm. # 8.1, 8.0 or 7.x: go to section 4. # ─── 2. MANAGED OR SHARED HOSTING: SEND THIS TO SUPPORT ─── # Copy the paragraph below into a support ticket or an email: Hello. I want to confirm one security point for my website on this account. Has the PHP security update released on 21 October 2026 (CVE-2026-109618 and CVE-2026-109619) been installed on the server my site runs on? Please confirm in writing, and tell me which PHP version my site runs on. If the update is not installed yet, when will it be? # Already stated publicly, no action needed: # Automattic: WordPress.com, WordPress VIP, WP Cloud, Pressable, Tumblr # Hostinger: every plan except VPS. Check: Websites > Dashboard > # PHP Info, Build Date 21 October 2026 or later. # ─── 3. A VPS YOU MANAGE: YOU OR YOUR DEVELOPER UPDATE PHP ─── # Host-level protection does not cover a server you manage yourself. # Update PHP through the package manager or control panel to the fixed # release for your branch, or install the Linux distribution's security # update for both CVEs (its version number can look older). # Then restart PHP. # Message for your developer: Please update PHP on our server to the 21 October 2026 security release for our branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the distribution's patched package for CVE-2026-109618 and CVE-2026-109619), restart PHP, and tell me which PHP version and package now serve the site. Please also review the server logs from 17 October 2026 onward. # ─── 4. PHP 8.1 OR OLDER ─── # The PHP project no longer releases updates for these versions # (source-only backports exist for 7.4, 8.0 and 8.1, for people who # build PHP themselves). # Ask your host, in writing, whether it installed a backported fix. # Plan the move to PHP 8.3 or newer (8.2 security fixes end 31 Dec 2026). # Test the store on a staging copy first: theme and plugins must # support the new version. # ─── 5. STOPGAPS ─── # A Cloudflare WAF in front of the site helps until PHP is updated. # On a paid Cloudflare plan, confirm the rules run in block mode. # Cloudflare itself says to patch PHP anyway. # Configuration tweaks reduce some paths only. php.net: only an update # is a complete solution. ``` --- More free bilingual AI guides: https://www.aiwithmo.com/prompts · One to one AI mentorship by application: https://www.aiwithmo.com/mentorship