[{"data":1,"prerenderedAt":237},["ShallowReactive",2],{"seo-verification":3,"blog-php-openssl-cve-2026-91767-91769-تحديث-php-openssl-ar":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-php-openssl-cve-2026-91767-91769-تحديث-php-openssl-ar",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":158,"ctaBody":159,"ctaButton":160,"ctaUrl":161,"relatedPosts":162},562,"php-openssl-cve-2026-91767-91769-تحديث-php-openssl",{"fr":12,"en":13,"ar":10,"es":14},"php-openssl-cve-2026-91767-91769-verification-hote-tls-mettre-a-jour","php-openssl-cve-2026-91767-91769-tls-hostname-verification-update","php-openssl-cve-2026-91767-91769-verificacion-host-tls-actualizar","PHP: إصلاح CVE-2026-91767 وCVE-2026-91769 في OpenSSL","ثغرتان متوسطتان في PHP تمسّان التحقق من اسم المضيف في TLS. الإصدارات المصحَّحة لكل فرع، وأوامر Debian وRHEL وcPanel وDocker، وحالة الفروع المنتهية الدعم.",13,0,false,"2026-11-02T00:00:00+00:00","2026-11-03T01:01:41+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"الأمان والمراقبة","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fphp-openssl-cve-2026-91767-91769-verification-hote-tls-mettre-a-jour-poster.svg","في 24 سبتمبر 2026 نشر مشروع PHP تنبيهين أمنيين يخصان امتداد OpenSSL: CVE-2026-91769، وهي تحقق متساهل أكثر مما ينبغي من اسم مضيف TLS، وCVE-2026-91767، وهي قراءة خارج حدود الذاكرة المؤقتة أثناء الفحص نفسه. صُنّفتا متوسطتين وتصلحهما الإصدارات PHP 8.2.34 و8.3.35 و8.4.26 و8.5.11. لا تُقارنان بـ PHP2Shell، لكنهما تخصان كل كود PHP يفتح اتصال TLS صادرًا. نبيّن هنا هل مواقعكم معنية، وأي إصدار تثبّتون على Debian وUbuntu وRHEL وAlmaLinux وcPanel وDocker، وماذا تفعلون مع فرع بلا إصلاح.",[35,39,50,53,56,72,100,121,124,128,131,134,143],{"type":36,"title":37,"body":38},"h2","ما الذي يصلحه هذان التنبيهان","يستهدف التنبيهان `ext\u002Fopenssl`، الامتداد المسؤول عن تشفير TLS في تدفقات PHP. لا يتعلق الأمر بزوار موقعكم، بل بالاتصالات التي يفتحها كود PHP لديكم نحو الخارج، مثل `file_get_contents('https:\u002F\u002F…')` أو `fopen` على رابط https أو `stream_socket_client` على `tls:\u002F\u002F`.\n\nفي هذه الحالات تتحقق PHP من أن الشهادة التي يقدّمها الخادم البعيد تطابق اسم المضيف المطلوب. هذا هو الخيار `verify_peer_name`، وهو مفعّل افتراضيًا. تقع الثغرتان معًا في هذا الفحص. يصف تنبيه CVE-2026-91769 (\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fphp\u002Fphp-src\u002Fsecurity\u002Fadvisories\u002FGHSA-vvx9-73fr-5jjx\">GHSA-vvx9-73fr-5jjx\u003C\u002Fa>) تحققًا متساهلًا أكثر مما ينبغي، ويصف تنبيه CVE-2026-91767 (\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fphp\u002Fphp-src\u002Fsecurity\u002Fadvisories\u002FGHSA-xr7j-rvgx-xq5p\">GHSA-xr7j-rvgx-xq5p\u003C\u002Fa>) قراءة خارج حدود الذاكرة المؤقتة عند مقارنة الأسماء ذات حرف البدل. نُشر التنبيهان في اليوم نفسه، 24 سبتمبر 2026، وتصلحهما الإصدارات نفسها.",{"type":40,"title":41,"items":42},"ul","الخلاصة في سبع نقاط",[43,44,45,46,47,48,49],"**CVE-2026-91769** — خطورة متوسطة، درجة CVSS 3.1 تساوي 4.3. يفحص التحقق من اسم النظير حقول `subjectAltName` أولًا، ثم يعود إلى الاسم الشائع (Common Name) حتى حين تعرض الشهادة SAN من نوع DNS لا يطابق الاسم المطلوب.","**CVE-2026-91767** — خطورة متوسطة، درجة CVSS 3.1 تساوي 6.5 (CWE-122). في الدالة `php_openssl_matches_wildcard_name()` يؤدي نقص في الطول يُمرَّر إلى `memchr()` إلى قراءة خارج حدود الذاكرة المؤقتة حين يحتوي اسم حرف البدل في الشهادة على أحرف حرفية أكثر من المضيف الذي يجري التحقق منه.","**الإصدارات المصحَّحة** — PHP 8.2.34 و8.3.35 و8.4.26 و8.5.11 للثغرتين معًا. يظهر الإصداران 8.4.26 و8.5.11 في سجل تغييرات PHP بتاريخ 24 سبتمبر 2026.","**من المعني** — العملاء الذين يعتمدون على القيمة الافتراضية للخيار `verify_peer_name` عبر `file_get_contents()` و`fopen()` و`stream_socket_client()` على `https:\u002F\u002F` و`tls:\u002F\u002F`.","**الحل المؤقت** — لا يذكر التنبيه أي حل. تعطيل التحقق ليس حلًا، بل ثغرة إضافية.","**الفروع 8.1 وما قبلها** — منتهية الدعم ولا يوجد إصلاح من المشروع. قد توجد إصلاحات من التوزيعة أو backports من أطراف ثالثة: تحققوا حزمة بحزمة.","**الاستغلال** — لم نجد في المصادر التي رجعنا إليها أي استغلال مرصود لهاتين الثغرتين.",{"type":36,"title":51,"body":52},"ما تتيحه هاتان الثغرتان وما لا تتيحه","**تتيح CVE-2026-91769 انتحال مضيف.** يمكن لشهادة يعتمدها عميلكم لمضيف ما أن تُستعمل للتظاهر بمضيف آخر إذا كان اسمها الشائع (CN) يتضمن الاسم المستهدف. تنص RFC 6125 على تجاهل CN عند وجود SAN من نوع DNS، ولم تكن PHP تفعل ذلك. يرى التنبيه أن الحالة تهم خصوصًا البنية المفتاحية الخاصة (PKI)، أي سلطة داخلية تصدر شهادات لخدمات كثيرة.\n\n**تتيح CVE-2026-91767 إسقاط عميل PHP.** يستطيع خادم خبيث، أو خادم بسلطة موثوقة، إحداث القراءة خارج الحدود أثناء التحقق، وهذا حجب للخدمة. يوضح التنبيه أن النتيجة لا تؤثر إلا في قرار القبول أو الرفض ولا تُرجع أي محتوى من الكومة. تحفظ صريح: يُقدّر متجه CVSS السرية بدرجة عالية والإتاحة بلا تأثير، وهذا لا ينسجم مع نص الأثر. نشير إلى ذلك دون أن نحسمه.\n\n**ما لا تتيحانه.** لا يصف التنبيه أي تنفيذ للكود. ولا تُفعَّل أي منهما بطلب من زائر يصل إلى موقعكم. المتجهان كلاهما من نوع الشبكة المجاورة (AV:A): يجب أن يكون المهاجم قريبًا من الاتصال، لا في أي مكان على الإنترنت.",{"type":36,"title":54,"body":55},"مصنّفتان متوسطتين: هل الأمر عاجل؟","جواب صريح: لا شيء في المصادر التي رجعنا إليها يدل على أن هاتين الثغرتين تُستغلان. ولا نؤكد أكثر من ذلك. لا تُقارنان بـ PHP2Shell (CVE-2026-109618 وCVE-2026-109619) التي تستهدف المفسِّر نفسه وتُفعَّل بطلب HTTP مجهول. نعالج تلك الثغرة على حدة في \u003Ca href=\"\u002Far\u002Fالمدونة\u002Fphp2shell-cve-2026-109618-109619-تحديث-php\">مقالنا عن PHP2Shell\u003C\u002Fa>؛ وآخر إصدار من فرعكم، وهو ما يطلب منكم ذلك المقال تثبيته، يتضمن هذه الإصلاحات أيضًا.\n\nفالاستعجال متدرج. إنه حقيقي إذا كان الكود لديكم يستدعي عناوين خارجية عبر تدفقات PHP (واجهات الدفع، وwebhooks الصادرة، واستيراد الخلاصات، والتحقق من التراخيص) أو خدمات داخلية تأتي شهاداتها من PKI خاصة. وهو أقل بكثير لموقع تعريفي لا يجري أي استدعاء صادر. وفي الحالتين يبقى الإصلاح ضمن الفرع نفسه: أدرجوه في أقرب نافذة صيانة بدل تأجيله دون تاريخ.",{"type":57,"title":58,"steps":59},"steps","قياس تعرضكم في أربع خطوات",[60,63,66,69],{"title":61,"body":62},"اقرؤوا إصدار PHP الذي يُقدَّم فعليًا","على الخادم، نفّذوا `php -r 'echo PHP_VERSION, PHP_EOL;'`. لا تعتمدوا على `OPENSSL_VERSION_TEXT`: فالمُصحَّح ليس مكتبة OpenSSL الخاصة بالنظام بل كود الامتداد، أي إصدار PHP. انتبهوا، فقد يختلف سطر الأوامر عما تقدمه مواقعكم: على خادم يستضيف عدة فروع، اقرؤوا أيضًا إصدار كل مجمّع PHP-FPM (خطوة التحقق أدناه). في cPanel يُقرأ الإصدار لكل نطاق، انظروا \u003Ca href=\"\u002Far\u002Fالمدونة\u002Fتغيير-إصدار-php-للموقع-في-cpanel\">دليلنا عن محدد إصدار PHP\u003C\u002Fa>.",{"title":64,"body":65},"ابحثوا عن الاستدعاءات التي تمر عبر تدفقات PHP","اعرضوا الاستدعاءات الصادرة التي تحمل رابطًا مكتوبًا في الكود: `grep -rnE \"(file_get_contents|fopen)\\(\\s*['\\\"]https?:\u002F\u002F|stream_socket_client\\(\\s*['\\\"]tls:\u002F\u002F\" \u002Fvar\u002Fwww --include='*.php'`. في استضافة cPanel استبدلوا `\u002Fvar\u002Fwww` بـ `\u002Fhome`. أكملوا بالاستدعاءات التي يأتي رابطها من متغير: `grep -rnE \"(file_get_contents|fopen|stream_socket_client)\\(\\s*\\$\" \u002Fvar\u002Fwww --include='*.php'`. فكّروا في إضافات WordPress ومجلد `vendor`: كثيرًا ما تختبئ الاستدعاءات الصادرة هناك.",{"title":67,"body":68},"حدّدوا حالات التحقق المعطَّل أصلًا","نفّذوا `grep -rn \"verify_peer_name\" \u002Fvar\u002Fwww --include='*.php'`. القيمة `false` تعني أنه لا يُتحقق من أي اسم مضيف: هذا الكود معرّض لأكثر بكثير من هذين التنبيهين، أيًّا كان إصدار PHP. أصلحوه قبل كل شيء.",{"title":70,"body":71},"صنّفوا مواقعكم","يكون الموقع أولوية إذا اجتمع فيه فرع دون الحد الأدنى في الجدول التالي واستدعاءات صادرة عبر التدفقات. لا يذكر التنبيه الاستدعاءات المنفذة عبر امتداد cURL، فهو يعدّد تدفقات PHP. يستعمل WordPress ومعظم مكتبات HTTP عادةً cURL عند توفره، لكنها تعود إلى التدفقات في غيابه: لا تستبعدوها دون تحقق.",{"type":73,"title":74,"headers":75,"rows":79},"comparison","أي إصدار تثبّتون بحسب فرعكم",[76,77,78],"فرع PHP","الحد الأدنى المصحَّح","الحالة",[80,84,88,92,96],[81,82,83],"8.5","8.5.11","مصحَّح. ثبّتوا آخر إصدار متاح من 8.5.",[85,86,87],"8.4","8.4.26","مصحَّح. ثبّتوا آخر إصدار متاح من 8.4.",[89,90,91],"8.3","8.3.35","مصحَّح. ثبّتوا آخر إصدار متاح من 8.3.",[93,94,95],"8.2","8.2.34","مصحَّح. خطّطوا للخروج من هذا الفرع، انظروا قائمة التحقق المرتبطة في آخر المقال.",[97,98,99],"8.1 وما قبله (من 5.6 إلى 8.1)","لا يوجد إصدار من المشروع","منتهي الدعم. إصلاح من التوزيعة أو backport من طرف ثالث يجب التحقق منه، وإلا فالترحيل.",{"type":57,"title":101,"steps":102},"تطبيق الإصلاح بحسب بيئتكم",[103,106,109,112,115,118],{"title":104,"body":105},"Debian وUbuntu","حدّثوا الفهرس بـ `sudo apt update`، ثم حزم فرعكم بـ `sudo apt install --only-upgrade 'php8.3*'` (استبدلوا 8.3 بفرعكم). لمعرفة المعلّق: `apt list --upgradable 2>\u002Fdev\u002Fnull | grep -i php`. كثيرًا ما تصلح التوزيعات عبر backport دون تغيير رقم المشروع: اقرؤوا سجل الحزمة بـ `apt changelog php8.3-cli | grep -i CVE-2026-91769`. مع مستودع طرف ثالث مثل Sury تنطبق الأوامر نفسها.",{"title":107,"body":108},"RHEL وAlmaLinux وRocky Linux","نفّذوا `sudo dnf update 'php*'`. إذا كنتم تستعملون تدفق وحدات فالفرع يتبع الوحدة المفعّلة: يعرضها `dnf module list --enabled php`. ثم تحققوا من السجل بـ `rpm -q --changelog php-cli | grep -i CVE-2026-91769`. مع مستودع طرف ثالث تتغير أسماء الحزم: كيّفوا النمط مع ما يعيده `rpm -qa 'php*'`.",{"title":110,"body":111},"cPanel: EasyApache 4 ومحدد PHP","فروع EasyApache 4 حزم باسم `ea-php83` و`ea-php84` وهكذا. إذا كان لديكم صلاحية root فاعرضوها بـ `rpm -qa 'ea-php*' | sort` ثم حدّثوها بـ `sudo dnf update 'ea-php*'`. اقرؤوا السجل بـ `rpm -qa --changelog 'ea-php83*' | grep -i CVE-2026-91769` والإصدار الفعلي بـ `\u002Fopt\u002Fcpanel\u002Fea-php83\u002Froot\u002Fusr\u002Fbin\u002Fphp -v`. في الاستضافة المشتركة يتولى المضيف التحديث: دوركم أن تتحققوا، في محدد PHP بـ cPanel (MultiPHP Manager أو Select PHP Version على CloudLinux)، من أن كل نطاق يعمل على فرع مصحَّح.",{"title":113,"body":114},"Docker","لا تُصلَح الصورة في مكانها: أعيدوا بناءها مع سحب القاعدة المحدَّثة بـ `docker build --pull --no-cache -t your-image .`، أو `docker compose build --pull --no-cache` مع Compose، ثم أعيدوا التشغيل بـ `docker compose up -d`. تحققوا من النتيجة داخل الحاوية بـ `docker run --rm your-image php -v`. لا تتقدم وسمة عائمة مثل `php:8.4-fpm` إلا إذا أُعيد بناء الصورة الأصلية: الرقم المعروض هو المرجع لا اسم الوسم.",{"title":116,"body":117},"أعيدوا تشغيل خدمات PHP","يحتفظ PHP-FPM وApache بالكود القديم في الذاكرة ما لم يُعاد تحميلهما. على Debian أو Ubuntu: `sudo systemctl restart php8.3-fpm` (كيّفوا الفرع)، و`sudo systemctl restart apache2` إذا كنتم تستعملون `mod_php`. على RHEL أو AlmaLinux: `sudo systemctl restart httpd`. على cPanel مع PHP-FPM يعطي `systemctl list-units 'ea-php*'` الاسم الدقيق للخدمة المطلوب إعادة تشغيلها.",{"title":119,"body":120},"تحققوا من الإصدار الذي يُقدَّم فعليًا","سطر الأوامر ليس خدمة الويب. استعلموا من ملف FPM التنفيذي: `php-fpm8.3 -v` على Debian وUbuntu، و`php-fpm -v` على RHEL ومشتقاته، أو إصدار النطاق في cPanel. يجب أن يبلغ الرقم الحد الأدنى لفرعكم، أو أن يذكر سجله CVE-2026-91769. اختموا باستدعاء صادر تجريبي: `php -r 'echo strlen(file_get_contents(\"https:\u002F\u002Fyour-domain.com\u002F\")), PHP_EOL;'`.",{"type":36,"title":122,"body":123},"إذا كان فرعكم منتهي الدعم (8.1 وما قبله)","بحسب \u003Ca href=\"https:\u002F\u002Fwww.herodevs.com\u002Fvulnerability-directory\u002Fcve-2026-91767\">HeroDevs\u003C\u002Fa>، فإن فروع PHP من 5.6 إلى 8.1 منتهية الدعم ولا تتلقى إصلاحًا من المشروع لهاتين الثغرتين. لا تفترضوا شيئًا في أي اتجاه. ربما نقلت توزيعتكم الإصلاح إلى حزمتها: هذا ممكن وغير مضمون، ويُتحقق منه حزمة بحزمة عبر سجل التغييرات (`apt changelog` و`rpm -q --changelog`) وتتبّع الأمان الخاص بالتوزيعة. كما يقدّم ناشرون من أطراف ثالثة backports للإصدارات المهجورة.\n\nفي غياب إصلاح مؤكد لديكم ثلاث وسائل. الأولى الترحيل إلى فرع مدعوم، 8.3 أو 8.4 بعد اختبار موقعكم: الطريقة في \u003Ca href=\"\u002Far\u002Fالمدونة\u002Fنهاية-دعم-php-82-دليل-الترحيل\">قائمة التحقق الخاصة بترحيل PHP\u003C\u002Fa>. الثانية حصر الاستدعاءات الصادرة من ذلك الكود في مضيفين تتحكمون في شهاداتهم. الثالثة تقييد حركة الخادم الصادرة في جدار الحماية. الأخيرتان تقلّلان التعرض ولا تصلحان شيئًا.",{"type":125,"title":126,"body":127},"tip","لا تضبطوا verify_peer_name على false أبدًا","أمام خطأ في الشهادة يغري الأمر بإضافة `verify_peer_name => false` في `stream_context_create`. هذا أسوأ من الثغرة: لم يعد يُتحقق من أي اسم مضيف، فتصلح أي شهادة معتمدة لأي مضيف. لا يذكر التنبيه أي حل مؤقت، وهذا الخيار ليس واحدًا منها. حين يفشل اتصال بعد التحديث، أصلحوا الشهادة.",{"type":36,"title":129,"body":130},"إصلاح ثالث في OpenSSL خلال الربع نفسه","CVE-2026-14355 ثغرة مستقلة: تلف في الذاكرة داخل `openssl_encrypt()` مع الخوارزمية AES-WRAP-PAD (GH-22187). بحسب سجل تغييرات PHP (\u003Ca href=\"https:\u002F\u002Fwww.php.net\u002FChangeLog-8.php\">https:\u002F\u002Fwww.php.net\u002FChangeLog-8.php\u003C\u002Fa>) فقد صُحّحت في PHP 8.4.23 بتاريخ 3 يوليو 2026 وفي PHP 8.5.8 بتاريخ 2 يوليو 2026. تمس التشفير لا التحقق من TLS: فلا تغيّر شيئًا في اختبار التعرض أعلاه.\n\nإذا ثبّتم 8.4.26 أو 8.5.11 أو ما بعدهما فلديكم هذا الإصلاح أصلًا. أما الفرعان 8.2 و8.3 فلا نذكر لهما إصدارًا لأننا لم نتحقق منه: اقرؤوا سجل حزمتكم لمعرفة هل ترد فيه CVE-2026-14355.",{"type":36,"title":132,"body":133},"حل المشكلات بعد التحديث","يشدّد الإصلاح فحصًا قائمًا. لذلك قد تفشل الآن بعض الاستدعاءات التي كانت تمر سابقًا، وهذه نتيجة متوقعة للإصلاح لا تراجعًا. الحالة التي تُختبر أولًا هي خدمة داخلية تأتي شهادتها من سلطة خاصة. هذه رسائل حقيقية قد تصادفونها مع العلاج المناسب.",{"type":40,"title":135,"items":136},"الأخطاء المصادَفة وعلاجها",[137,138,139,140,141,142],"**`SSL operation failed with code 1` ثم `certificate verify failed`** — الرسالة الكاملة المعتادة: `stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:0A000086:SSL routines::certificate verify failed`. السبب المرجّح: الشهادة تعرض SAN من نوع DNS لا يتضمن المضيف المطلوب، بينما يتضمنه CN. كان الفحص القديم يقبلها بالعودة إلى CN، والجديد يرفضها. اقرؤوا الشهادة بـ `openssl s_client -connect interne.your-domain.com:443 -servername interne.your-domain.com \u003C\u002Fdev\u002Fnull 2>\u002Fdev\u002Fnull | openssl x509 -noout -subject -ext subjectAltName`. العلاج: إعادة إصدار الشهادة بـ SAN من نوع DNS صحيح لكل اسم مستعمل، وليس تعطيل التحقق أبدًا.","**`file_get_contents(): Failed to enable crypto`** — تحذير يرافق الخطأ السابق. اقرؤوا الرسالة الكاملة التي تليه: بحسب الإصدار قد تجدون أيضًا `Peer certificate CN=… did not match expected CN=…`. السبب نفسه والعلاج نفسه.","**شهادة بلا أي SAN، بـ CN فقط، تفشل مع ذلك** — يُبقي الإصلاح العودة إلى CN للشهادات التي لا تحمل معرّف خدمة. فالسبب إذن في مكان آخر: سلطة لا يعتمدها العميل، أو مضيف مستدعى بكنية أو بعنوان IP غير موجود في الشهادة، أو شهادة منتهية الصلاحية. العلاج: إضافة السلطة الداخلية إلى `cafile` في سياق التدفق، وإعادة إصدار الشهادة بـ SAN.","**`child exited on signal 11 (SIGSEGV)` في سجل PHP-FPM** — انهيار عامل أثناء استدعاء صادر عبر TLS يتوافق مع CVE-2026-91767. لا تستنتجوا من هذه القرينة وحدها: تحققوا من الإصدار وحدّثوا وانظروا هل يختفي النمط.","**`php -v` ما زال يعرض الإصدار القديم** — خدمة لم تُعد تشغيلها، أو سطر أوامر وFPM على فرعين مختلفين، أو صورة Docker أُعيد بناؤها دون `--pull`، أو إصدار النطاق لم يتغير في cPanel. ارجعوا إلى خطوة التحقق.","**سجل التوزيعة لا يذكر الثغرة** — غيابها لا يثبت أن الإصلاح موجود ولا أنه مفقود. راجعوا تتبّع الأمان الخاص بالتوزيعة، وإلا فقارنوا رقم المشروع بالحد الأدنى في الجدول.",{"type":57,"title":144,"steps":145},"تثبيت التحديث ضمن روتينكم",[146,149,152,155],{"title":147,"body":148},"دوّنوا الحد الأدنى في جردكم","أضيفوا إلى جرد أسطولكم عمودًا باسم \"الإصدار الأدنى\" لكل فرع، بقيم الجدول. فيصبح أي إصدار دون الحد الأدنى ظاهرًا دون بحث.",{"title":150,"body":151},"خطّطوا لتحديثات PHP","الإصلاح الأمني في PHP تحديث ثانوي ضمن الفرع نفسه: خصّصوا نافذة منتظمة بدل ورشة عند كل تنبيه، مع إعادة تشغيل الخدمات والتحقق من الإصدار المُقدَّم.",{"title":153,"body":154},"اختبروا استدعاءً صادرًا بعد كل تحديث","أعيدوا `php -r 'echo strlen(file_get_contents(\"https:\u002F\u002Fyour-domain.com\u002F\")), PHP_EOL;'` من كل خادم، واستدعاءً إلى خدماتكم الداخلية. يظهر خطأ الشهادة حينها فورًا، لا عند عميل.",{"title":156,"body":157},"اربطوا هذا الإصلاح ببقية مراقبتكم","لطريقة جرد الأسطول اقرؤوا \u003Ca href=\"\u002Far\u002Fالمدونة\u002Fجرد-إصدارات-php-لمواقع-العملاء-منهج-للوكالات\">جرد إصدارات PHP لأسطول العملاء\u003C\u002Fa>. وللثغرة الأخطر في الوقت الحالي انظروا \u003Ca href=\"\u002Far\u002Fالمدونة\u002Fphp2shell-cve-2026-109618-109619-تحديث-php\">PHP2Shell\u003C\u002Fa>. ولتغيير إصدار موقع اتبعوا \u003Ca href=\"\u002Far\u002Fالمدونة\u002Fتغيير-إصدار-php-للموقع-في-cpanel\">دليل محدد PHP في cPanel\u003C\u002Fa>. ولفرع يوشك أن ينتهي عودوا إلى \u003Ca href=\"\u002Far\u002Fالمدونة\u002Fنهاية-دعم-php-82-دليل-الترحيل\">قائمة التحقق لترحيل PHP 8.2\u003C\u002Fa>.","اختاروا إصدار PHP لكل موقع","في استضافة ويب ServOrbit.com تختارون إصدار PHP لكل نطاق من cPanel، وتنتقلون إلى فرع ما زال مصحَّحًا بعد اختبار موقعكم.","اكتشفوا استضافة الويب","\u002Fhebergement-web",[163,180,196,216],{"id":164,"slug":165,"slugs":166,"title":170,"excerpt":171,"readTime":172,"views":173,"isPinned":19,"publishedAt":174,"updatedAt":175,"category":176,"categories":177,"featuredImage":30,"bgImage":31,"posterImage":179,"relatedSolution":30},489,"php2shell-cve-2026-109618-109619-تحديث-php",{"fr":167,"en":168,"ar":165,"es":169},"php2shell-cve-2026-109618-109619-mettre-a-jour-php","php2shell-cve-2026-109618-109619-patch-php","php2shell-cve-2026-109618-109619-actualizar-php","PHP2Shell: إصلاح CVE-2026-109618 وCVE-2026-109619","PHP2Shell: ثغرتان حرجتان في PHP قابلتان للاستغلال دون حساب. الإصدارات المصحَّحة، وأوامر التحديث لكل نظام، والحلول المؤقتة.",16,1,"2026-10-22T00:00:00+00:00","2026-10-27T23:58:43+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[178],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fphp2shell-cve-2026-109618-109619-mettre-a-jour-php-poster.svg",{"id":181,"slug":182,"slugs":183,"title":187,"excerpt":188,"readTime":189,"views":18,"isPinned":19,"publishedAt":190,"updatedAt":191,"category":192,"categories":193,"featuredImage":30,"bgImage":31,"posterImage":195,"relatedSolution":30},508,"جرد-إصدارات-php-لمواقع-العملاء-منهج-للوكالات",{"fr":184,"en":185,"ar":182,"es":186},"inventaire-versions-php-parc-sites-clients-agence","php-version-inventory-for-client-sites-an-agency-method","inventario-de-versiones-php-de-sitios-cliente-metodo-de-agencia","جرد إصدارات PHP لمواقع العملاء: منهج للوكالات","سجل لإصدار PHP الذي يخدمه كل موقع عميل لدى عدة مستضيفين: مستويات الوصول، سكربتات دفعية، أولويات، رسالة للعميل وإثبات مؤرخ للتصحيح.",11,"2026-10-27T00:00:00+00:00","2026-10-27T23:58:39+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[194],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Finventaire-versions-php-parc-sites-clients-agence-poster.svg",{"id":197,"slug":198,"slugs":199,"title":203,"excerpt":204,"readTime":205,"views":173,"isPinned":19,"publishedAt":206,"updatedAt":207,"category":208,"categories":213,"featuredImage":30,"bgImage":31,"posterImage":215,"relatedSolution":30},503,"تغيير-إصدار-php-للموقع-في-cpanel",{"fr":200,"en":201,"ar":198,"es":202},"changer-version-php-site-cpanel","change-php-version-site-cpanel","cambiar-version-php-sitio-cpanel","تغيير إصدار PHP لموقعك في cPanel","اختر إصدار PHP لموقعك في cPanel: افتح صفحة الموقع ثم تبويب الإعدادات، وحدّد الإصدار المطلوب من القائمة.",3,"2026-10-23T00:00:00+00:00","2026-10-24T03:34:36+00:00",{"id":209,"name":210,"slug":211,"color":212,"icon":211},12,"أدلة","guides","bg-emerald-500\u002F10 text-emerald-400",[214],{"id":209,"name":210,"slug":211,"color":212,"icon":211},"\u002Fblog\u002Fcovers\u002Fchanger-version-php-site-cpanel-poster.svg",{"id":217,"slug":218,"slugs":219,"title":223,"excerpt":224,"readTime":189,"views":225,"isPinned":19,"publishedAt":226,"updatedAt":227,"category":228,"categories":234,"featuredImage":30,"bgImage":31,"posterImage":236,"relatedSolution":30},206,"نهاية-دعم-php-82-دليل-الترحيل",{"fr":220,"en":221,"ar":218,"es":222},"php-82-fin-de-vie-checklist-migration","php-82-end-of-life-planning-your-migration","php-82-fin-de-vida-planificar-la-migracion","نهاية دعم PHP 8.2 : قائمة التحقق للترحيل","يبلغ PHP 8.2 نهاية دورة حياته في 31 ديسمبر 2026. جرد بيئاتك، قارن الإصدارات، واتبع قائمة تحقق مفصّلة للترحيل إلى PHP 8.3 أو 8.4.",7,"2026-08-01T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":229,"name":230,"slug":231,"color":232,"icon":233},4,"التطوير","developpement","bg-warning\u002F10 text-warning","dev",[235],{"id":229,"name":230,"slug":231,"color":232,"icon":233},"\u002Fblog\u002Fcovers\u002Fphp-82-fin-de-vie-checklist-migration-poster.svg",1793758238527]