Deux vulnérabilités critiques découvertes dans PHP peuvent permettre l’exécution de code à distance sans authentification. WordPress, WooCommerce, PrestaShop et de nombreuses applications métier reposent sur PHP : leur présence suffit donc à justifier une vérification. Mais installer la dernière mise à jour du CMS n’est pas la réponse. Il faut savoir quelle version de PHP exécute réellement le site, qui en assure la maintenance et comment la mettre à jour sans provoquer une panne.

Sommaire

1. Que s’est-il passé avec PHP ?
2. Une RCE sans authentification, qu’est-ce que cela signifie ?
3. WordPress, WooCommerce et PrestaShop sont-ils concernés ?
4. Quelles versions de PHP faut-il utiliser ?
5. Comment connaître la version PHP de son site ?
6. Qui doit mettre PHP à jour ?
7. Comment mettre PHP à jour sans casser son site ?
8. Cloudflare protège-t-il contre ces vulnérabilités ?
9. Je gère un WordPress ou PrestaShop : que faire aujourd’hui ?
10. Et si mon agence ou mon hébergeur ne m’a rien dit ?
11. Que retenir ?

Que s’est-il passé avec PHP ?

Le 21 octobre 2026, l’équipe PHP a publié en urgence quatre nouvelles versions de PHP :

Branche	Version corrigée
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Elles corrigent deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, toutes deux évaluées à 9,2/10 selon CVSS v4.0 par le projet PHP.

Ce niveau est critique.

Mais le mot « critique » mérite d’être expliqué plutôt que simplement affiché en rouge.

Les deux vulnérabilités se trouvent dans PHP lui-même, plus précisément dans sa gestion de la mémoire lors du traitement de certaines requêtes HTTP.

Pour CVE-2026-109618, PHP peut se retrouver à court de mémoire alors que certaines données internes ne sont encore que partiellement initialisées. Le nettoyage effectué après l’erreur peut alors considérer ces données invalides comme légitimes.

CVE-2026-109619 repose sur un mécanisme différent : certaines informations internes liées à une requête peuvent subsister alors que la mémoire correspondante a déjà été libérée. Une requête suivante traitée par le même processus PHP peut alors réutiliser cet état devenu invalide.

Dans les deux cas, cette corruption de l’état interne peut avoir des conséquences allant du plantage du processus à l’exposition de données et, dans certaines conditions, à l’exécution de code à distance. (PHP)

PHP considère comme à risque les installations traitant des requêtes Web, qu’elles utilisent notamment PHP-FPM, mod_php, php-cgi, FrankenPHP ou LiteSpeed. Le projet PHP considère actuellement le risque comme particulièrement élevé avec mod_php, pour lequel une exploitation a été démontrée avant même l’exécution du code de l’application. (PHP)

C’est un détail important.

La vulnérabilité n’est pas une faille WordPress ou PrestaShop. Elle se situe sous le CMS, dans le moteur qui exécute son code.

Une exécution de code à distance sans authentification, qu’est-ce que cela signifie ?

RCE signifie Remote Code Execution, ou exécution de code à distance.

Dans le pire scénario, une vulnérabilité RCE permet à un attaquant d’amener le serveur à exécuter du code qu’il n’était évidemment pas censé exécuter.

« Sans authentification » ajoute une caractéristique importante : l’attaquant n’a pas nécessairement besoin d’un compte administrateur, d’un accès au back-office ou d’identifiants préalablement volés pour tenter l’exploitation.

Cela ne veut toutefois pas dire :

« N’importe qui peut instantanément prendre le contrôle de n’importe quel site PHP. »

Trois notions doivent rester distinctes.

La vulnérabilité existe dans PHP.

L’exposition potentielle dépend de la version utilisée, de la manière dont PHP est exécuté, de la configuration du serveur et des requêtes pouvant atteindre celui-ci.

L’exploitation effective signifie qu’un attaquant a réellement réussi à exploiter la vulnérabilité contre un système donné.

Au 21 octobre, Cloudflare indiquait avoir observé du trafic d’attaque visant ses clients et des attaquants faisant varier leurs requêtes pour contourner les protections. Cela prouve que la vulnérabilité intéresse déjà les attaquants et fait l’objet de tentatives. Cela ne signifie pas que chaque tentative a abouti ni que tous les serveurs ciblés ont été compromis. (Cloudflare Blog)

WordPress, WooCommerce et PrestaShop sont-ils concernés ?

Potentiellement, oui.

Parce qu’ils fonctionnent avec PHP.

Mais cette phrase mérite immédiatement son complément : ce n’est pas une vulnérabilité spécifique de WordPress, WooCommerce ou PrestaShop.

Un WordPress parfaitement à jour peut être exécuté par une version vulnérable de PHP.

Même chose pour une boutique PrestaShop.

Et même chose pour une application Symfony, Laravel ou un développement PHP sur mesure.

C’est précisément ce qui rend cet incident intéressant pour les entreprises : le tableau de bord du CMS peut afficher fièrement « aucune mise à jour disponible » alors que la couche PHP située juste en dessous nécessite une intervention.

Cloudflare résume clairement le problème : ces failles affectent le runtime PHP lui-même. Mettre à jour le code du site ou ses plugins ne suffit donc pas à les corriger. (Cloudflare Blog)

Mettre WordPress à jour ne met pas PHP à jour

Prenons une architecture très simplifiée :

WordPress / PrestaShop → PHP → serveur Web → système d’exploitation

Les mises à jour WordPress corrigent WordPress.

Les mises à jour d’un plugin corrigent ce plugin.

Les mises à jour PrestaShop corrigent PrestaShop.

Aucune de ces opérations ne garantit que le moteur PHP installé ou sélectionné sur l’hébergement a été mis à jour.

C’est un peu comme mettre à jour toutes les applications d’un ordinateur en oubliant son système d’exploitation.

Quelles versions de PHP faut-il utiliser aujourd’hui ?

Pour les branches actuellement prises en charge par le projet PHP, la réponse immédiate est claire :

PHP 8.2 → au minimum 8.2.35
PHP 8.3 → au minimum 8.3.36
PHP 8.4 → au minimum 8.4.27
PHP 8.5 → au minimum 8.5.12

PHP indique qu’il n’existe pas de mitigation complète remplaçant ces correctifs. La mise à jour reste donc la solution recommandée. (PHP)

Mais une entreprise sous PHP 8.2 doit déjà regarder un peu plus loin.

PHP 8.2 est corrigé… mais bientôt en fin de vie

Au 22 octobre 2026, le calendrier officiel PHP est le suivant :

Branche	Support de sécurité PHP jusqu’au
PHP 8.2	31 décembre 2026
PHP 8.3	31 décembre 2027
PHP 8.4	31 décembre 2028
PHP 8.5	31 décembre 2029

PHP 8.2.35 constitue donc un correctif parfaitement légitime pour traiter l’urgence.

Mais rester durablement en PHP 8.2 revient à corriger le problème d’octobre tout en sachant qu’à partir du 31 décembre, le projet PHP ne fournira plus de nouveaux correctifs de sécurité pour cette branche. (PHP)

La bonne stratégie peut donc être en deux temps :

urgence : installer PHP 8.2.35 si migrer immédiatement vers une branche supérieure présente trop de risques ;

dette technique : préparer rapidement la compatibilité du site avec PHP 8.3, 8.4 ou 8.5 selon le CMS et ses extensions.

Et PHP 8.1, 8.0 ou 7.4 ?

Là, le problème est plus structurel.

Selon le calendrier officiel :

• PHP 8.1 est hors support depuis le 31 décembre 2025 ;
• PHP 8.0 depuis le 26 novembre 2023 ;
• PHP 7.4 depuis le 28 novembre 2022.

Le projet PHP ne publie donc plus de correctifs officiels pour ces branches. (PHP)

Certains systèmes Linux ou fournisseurs de support longue durée peuvent rétroporter des correctifs dans leurs propres paquets. PHP le mentionne explicitement : dans ce cas, il faut vérifier la situation auprès du fournisseur concerné. (PHP)

Mais « notre serveur utilise toujours PHP 7.4 parce que le site fonctionne bien comme ça » n’est plus une stratégie de maintenance.

C’est une dette technique.

Et cette actualité permet justement de la rendre visible.

Comment connaître la version PHP utilisée par son site ?

Pour un dirigeant ou responsable marketing, la meilleure méthode n’est pas forcément d’aller créer un fichier phpinfo.php sur le serveur.

Commencez plus simplement.

Demandez à votre hébergeur ou à votre agence

La question peut tenir en une ligne :

« Quelle version exacte de PHP exécute actuellement notre site en production, et intègre-t-elle les correctifs du 21 octobre 2026 ? »

Demandez bien la version exacte.

« PHP 8.3 » n’est pas une réponse suffisante.

8.3.35 et 8.3.36 appartiennent toutes deux à PHP 8.3, mais seule la seconde contient le correctif publié le 21 octobre.

Regardez votre panneau d’hébergement

Sur de nombreux hébergements mutualisés, cPanel, Plesk ou l’interface propriétaire de l’hébergeur affiche la version PHP sélectionnée pour chaque domaine.

Attention toutefois : la version proposée dans l’interface et celle réellement utilisée par le site doivent correspondre.

Sur des infrastructures plus complexes, plusieurs versions de PHP peuvent cohabiter.

WordPress peut donner une première indication

Dans WordPress, Outils > Santé du site > Informations > Serveur permet généralement d’identifier la version PHP.

C’est un bon premier contrôle.

Pour PrestaShop, l’information peut également être accessible depuis les informations système du back-office selon la version.

Sur un site professionnel, la vérification définitive reste cependant du ressort de la personne administrant réellement l’hébergement ou le serveur.

Qui doit mettre PHP à jour ?

C’est probablement la question la plus importante après le numéro de version.

Car PHP se trouve précisément dans une zone où les responsabilités sont souvent floues.

Le CMS

WordPress ou PrestaShop définit les versions PHP avec lesquelles il est compatible.

Mais le CMS ne gère généralement pas lui-même le runtime PHP du serveur.

L’hébergeur

Sur un hébergement managé ou mutualisé, l’hébergeur fournit et maintient généralement les versions de PHP disponibles.

Selon son fonctionnement, il peut appliquer automatiquement certains correctifs ou laisser au client le choix de la branche PHP utilisée.

Il faut donc distinguer :

« l’hébergeur propose PHP 8.4.27 »

et

« votre site utilise PHP 8.4.27 ».

Ce n’est pas nécessairement la même chose.

L’agence ou le prestataire de maintenance

Tout dépend du contrat.

Une maintenance comprenant la supervision technique, les mises à jour, la compatibilité serveur et la sécurité devrait logiquement inclure au minimum l’identification de ce type d’alerte, la vérification de l’environnement et une recommandation d’action.

Mais certains contrats ne couvrent que WordPress, PrestaShop, les thèmes et les extensions.

Le périmètre doit être explicite.

L’entreprise propriétaire du site

Elle n’a pas à devenir experte de PHP.

Elle doit en revanche savoir qui est responsable de cette couche.

Si personne ne peut répondre à la question « qui maintient PHP ? », le problème dépasse largement ces deux CVE.

Comment mettre PHP à jour sans casser son site ?

Sur un petit site récent, passer d’une version corrective à la suivante peut être quasiment transparent.

Sur une boutique ancienne utilisant quinze modules, un thème personnalisé, un connecteur ERP et quelques développements réalisés en 2019, changer de branche PHP sans vérification préalable peut produire une tout autre expérience.

La sécurité ne consiste pas à choisir entre :

ne rien mettre à jour

et

cliquer immédiatement sur PHP 8.5 en production.

Il existe une troisième voie : faire correctement la mise à jour.

1. Sauvegarder

Avant l’intervention, disposer d’une sauvegarde exploitable :

• fichiers ;
• base de données ;
• configuration ;
• idéalement possibilité de restauration rapide.

Une sauvegarde dont personne n’a jamais vérifié la restauration n’est qu’une promesse.

2. Reproduire le site en préproduction

Pour un site à enjeu commercial, le changement de branche PHP devrait être testé sur un environnement de staging ou préproduction aussi proche que possible de la production.

3. Vérifier les compatibilités

Il faut contrôler :

• version du CMS ;
• thème ;
• plugins ou modules ;
• développements spécifiques ;
• connecteurs ERP/CRM/PIM ;
• scripts et tâches CRON ;
• bibliothèques installées via Composer le cas échéant.

Le point sensible n’est souvent pas WordPress ou PrestaShop lui-même.

C’est le vieux module abandonné depuis cinq ans dont personne ne se souvenait.

4. Changer PHP sur la préproduction

On applique ensuite la version corrigée choisie.

Si le site utilise déjà une branche supportée, passer à la version corrective de cette même branche limite généralement les changements.

Une migration de PHP 7.4 vers PHP 8.4, en revanche, constitue un véritable changement de socle et doit être traitée comme tel.

5. Faire une vraie recette

« La page d’accueil s’affiche » n’est pas une recette.

Sur un WordPress classique, vérifiez au minimum administration, formulaires, recherche, authentification et fonctionnalités métier.

Sur WooCommerce ou PrestaShop, ajoutez :

fiche produit → déclinaison → panier → compte client → adresse → transporteur → paiement → création de commande → email transactionnel.

Testez également les tâches qui ne passent pas par le navigateur : imports, exports, synchronisations et CRON.

6. Contrôler les logs

Une incompatibilité PHP ne provoque pas toujours une page blanche immédiatement.

Warnings, deprecated notices et erreurs peuvent apparaître uniquement sur certains parcours.

Les logs PHP, serveur et applicatifs doivent donc être contrôlés pendant et après la recette.

7. Déployer et surveiller

Une fois la production basculée :

• vider les caches si nécessaire ;
• refaire les parcours critiques ;
• contrôler les erreurs HTTP ;
• vérifier les logs ;
• surveiller les paiements, formulaires et commandes ;
• conserver une procédure de retour arrière pendant la période de surveillance.

Le but n’est pas seulement que le site « revienne en ligne ».

Il faut vérifier que le métier fonctionne toujours.

Cloudflare protège-t-il contre ces vulnérabilités ?

C’est ici que l’incident devient particulièrement intéressant.

Cloudflare a annoncé avoir développé et déployé plusieurs protections WAF contre ces vulnérabilités avant leur divulgation publique.

Selon l’entreprise, les protections étaient activées par défaut pour ses clients utilisant le WAF, y compris sur l’offre gratuite, à partir du 21 octobre à 03:02 UTC, environ neuf heures avant la divulgation publique. (Cloudflare Blog)

Cloudflare indique également avoir observé des attaquants faire évoluer leurs requêtes pour tenter de contourner les protections. (Cloudflare Blog)

C’est précisément le rôle intéressant d’un WAF.

Une requête arrive :

Internet → Cloudflare → serveur → PHP → application

Cloudflare peut reconnaître certaines caractéristiques d’une tentative d’exploitation et la bloquer avant qu’elle n’atteigne le serveur.

Mais il y a une limite fondamentale.

Le serveur derrière Cloudflare reste vulnérable.

Un contournement du WAF, un accès direct à l’origine ou une variation non détectée peut remettre cette vulnérabilité au premier plan.

Cloudflare recommande donc lui-même d’installer le correctif PHP même lorsque ses protections sont actives. (Cloudflare Blog)

Full Transaction Detection : « l’attaque ressemble-t-elle à une attaque ? » ne suffit plus

Cloudflare a profité de cet incident pour dévoiler une évolution intéressante de son WAF : Full Transaction Detection.

Un WAF traditionnel analyse principalement la requête entrante.

Il tente de répondre à une question :

« Cette requête ressemble-t-elle à une attaque ? »

Mais imaginons qu’une requête soit ambiguë.

Elle peut sembler suspecte sans que l’on sache si elle a réellement déclenché quelque chose.

Cloudflare peut désormais mettre en relation la requête et la réponse renvoyée par le serveur.

La question devient alors :

« Cette requête semblait suspecte. Qu’a fait l’application lorsqu’elle l’a reçue ? »

Une réponse contenant certains signaux peut apporter davantage d’indices qu’une exploitation a potentiellement réussi.

Cloudflare peut alors bloquer cette réponse avant qu’elle ne revienne à l’attaquant. (Cloudflare Blog)

C’est une évolution importante pour distinguer une tentative d’exploitation d’indices suggérant que cette tentative a réellement produit un résultat.

Mais elle possède elle aussi une limite essentielle : Cloudflare précise qu’une règle intervenant sur la réponse ne peut pas annuler ce qui s’est déjà produit sur le serveur d’origine. (Cloudflare Blog)

Autrement dit :

détecter une exploitation n’est pas réparer la vulnérabilité.

Et bloquer sa réponse ne garantit pas que l’action exécutée côté serveur n’a pas déjà eu d’effet.

Le WAF reste donc exactement ce qu’il doit être : une couche supplémentaire de défense.

Pas une excuse pour conserver un runtime vulnérable.

Je gère un site WordPress ou PrestaShop : que dois-je faire aujourd’hui ?

Vous n’avez pas besoin de comprendre le fonctionnement interne de PHP pour piloter correctement la situation.

Voici la checklist.

☐ 1. Identifier la version PHP exacte utilisée en production

Demandez par exemple : 8.3.36, et pas simplement « PHP 8 ».

☐ 2. Vérifier qu’elle contient le correctif

Au 22 octobre 2026 :

• 8.2 → 8.2.35 minimum
• 8.3 → 8.3.36 minimum
• 8.4 → 8.4.27 minimum
• 8.5 → 8.5.12 minimum

☐ 3. Si vous êtes en PHP 8.1, 8.0, 7.4 ou inférieur, demander un plan de migration

Ces branches ne sont plus maintenues par le projet PHP.

☐ 4. Si vous êtes en PHP 8.2, appliquer le correctif mais planifier également la suite

PHP 8.2 arrive en fin de support le 31 décembre 2026.

☐ 5. Ne pas changer brutalement de branche PHP sur une boutique critique

Demandez une sauvegarde et, lorsque l’environnement le justifie, un test en préproduction.

☐ 6. Faire tester les fonctions qui rapportent de l’argent ou génèrent des leads

Panier, checkout, paiement, formulaires, comptes clients, emails, imports, API et CRON.

☐ 7. Si Cloudflare protège le site, vérifier que le WAF est effectivement actif

Cloudflare a déployé des protections spécifiques, mais leur présence ne dispense pas du patch.

☐ 8. Demander une confirmation après intervention

La réponse attendue n’est pas simplement :

« C’est fait. »

Elle devrait pouvoir préciser au minimum :

version PHP avant → version PHP après → tests effectués → anomalies éventuelles.

C’est cela qui permet de vérifier que le travail a réellement été réalisé.

Et si mon agence ou mon hébergeur ne m’a rien dit ?

L’absence de message n’est pas automatiquement la preuve d’une mauvaise maintenance.

Un hébergeur peut avoir appliqué le correctif automatiquement.

Une agence peut être en train de vérifier son parc avant de contacter les clients concernés.

Et un contrat de maintenance peut ne pas couvrir l’administration du serveur.

Il faut donc commencer par vérifier plutôt que conclure.

En revanche, pour un site professionnel sous maintenance, il est raisonnable d’attendre que quelqu’un soit capable de répondre rapidement à quatre questions :

Quelle version de PHP utilisons-nous ?

Est-elle corrigée ?

Qui est responsable de sa mise à jour ?

Comment vérifions-nous que le site fonctionne toujours après l’intervention ?

C’est là que se mesure la différence entre « mettre à jour un CMS » et maintenir réellement un système Web.

Un contrat de maintenance sérieux devrait définir son périmètre : CMS, extensions, thème, PHP, hébergement, sauvegardes, supervision, sécurité, intervention en cas d’alerte critique.

Tout ne doit pas nécessairement être inclus.

Mais tout devrait avoir un responsable identifié.

Car lorsqu’une vulnérabilité touche une couche située sous WordPress ou PrestaShop, découvrir que l’agence pensait que l’hébergeur s’en occupait pendant que l’hébergeur considérait que le choix de version appartenait au client est exactement le scénario que l’on souhaite éviter.

Que retenir ?

• CVE-2026-109618 et CVE-2026-109619 sont deux vulnérabilités critiques de PHP, évaluées à 9,2/10 en CVSS v4.0.
• Elles peuvent permettre une exécution de code à distance sans authentification dans certaines conditions.
• Elles concernent PHP lui-même, pas spécifiquement WordPress ou PrestaShop.
• Un CMS parfaitement à jour peut donc fonctionner sur un PHP vulnérable.
• Les versions correctives publiées le 21 octobre sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
• PHP 8.1, 8.0 et 7.4 sont déjà hors support du projet PHP.
• PHP 8.2 est corrigé, mais atteindra sa fin de support le 31 décembre 2026.
• Une migration PHP doit être testée, particulièrement sur un e-commerce ou une application disposant de modules et développements spécifiques.
• Cloudflare a déployé des protections WAF contre ces vulnérabilités et observe déjà du trafic d’attaque.
• Son nouveau Full Transaction Detection peut corréler une requête suspecte avec la réponse de l’application afin d’obtenir davantage d’indices sur le résultat de la tentative.
• Un WAF réduit le risque. Il ne corrige pas PHP.
• Pour une entreprise, la question la plus importante n’est finalement pas « connais-je ces CVE ? », mais « qui est responsable de mon runtime PHP et comment me prouve-t-il qu’il est correctement maintenu ? »

FAQ

Mon WordPress est à jour : suis-je protégé contre CVE-2026-109618 et CVE-2026-109619 ?

Pas nécessairement. Ces vulnérabilités concernent PHP et non WordPress. Votre WordPress peut être parfaitement à jour tout en fonctionnant sur une version vulnérable de PHP. Il faut contrôler les deux séparément.

Mon PrestaShop fonctionne sous PHP 8.2 : dois-je faire quelque chose ?

Oui, vérifiez la version corrective exacte. PHP 8.2 doit être au minimum en 8.2.35 pour intégrer les correctifs publiés le 21 octobre 2026. Il faut également anticiper une migration vers une branche plus récente puisque PHP 8.2 atteindra sa fin de support le 31 décembre 2026.

Puis-je directement passer de PHP 7.4 à PHP 8.5 ?

Techniquement, cela dépend de votre application. Opérationnellement, faire ce changement directement en production sans test est déconseillé. CMS, thème, plugins, modules et développements spécifiques doivent être vérifiés sur une préproduction avant la bascule.

Cloudflare suffit-il pour protéger mon site ?

Non. Cloudflare a déployé des protections spécifiques et celles-ci constituent une défense supplémentaire intéressante. Mais Cloudflare recommande lui-même d’appliquer le correctif PHP. Le WAF protège devant la vulnérabilité ; la mise à jour supprime la vulnérabilité connue à sa source.

Comment savoir si mon site a déjà été attaqué ?

La présence d’une version vulnérable ne prouve pas qu’elle a été exploitée. Il faut analyser les logs Web, PHP, système et éventuellement ceux du WAF ou des outils de supervision. Chez Cloudflare, les événements correspondant aux règles déployées peuvent notamment être examinés dans Security Analytics / Security Events. Une tentative bloquée n’est pas synonyme de compromission.

Est-ce à mon hébergeur ou à mon agence de mettre PHP à jour ?

Cela dépend de votre infrastructure et de votre contrat. L’hébergeur peut maintenir les paquets PHP tandis que l’agence choisit la version utilisée par le site et vérifie sa compatibilité. L’essentiel est qu’un responsable soit clairement identifié pour chacune de ces opérations.

Pourquoi ne pas rester sur PHP 8.2.35 puisqu’il corrige les failles ?

C’est possible pour traiter immédiatement les vulnérabilités. Mais PHP 8.2 atteindra sa fin de support le 31 décembre 2026. Le correctif règle donc l’urgence actuelle sans régler la dette technique à moyen terme.

Sources

PHP — Security advisory: Critical remote code execution vulnerabilities, update now — 21 octobre 2026.
Annonce officielle des vulnérabilités, versions corrigées, environnements concernés et recommandations. (PHP)

PHP — Supported Versions — consulté le 22 octobre 2026.
Calendrier officiel de support de PHP 8.2, 8.3, 8.4 et 8.5. (PHP)

PHP — Unsupported Branches — consulté le 22 octobre 2026.
Dates de fin de vie de PHP 8.1, 8.0, 7.4 et branches antérieures. (PHP)

Cloudflare — Cloudflare deploys protections against php2shell vulnerability — 21 octobre 2026.
Protections WAF déployées, trafic d’attaque observé et recommandations de patching. (Cloudflare Blog)

Cloudflare — Introducing full transaction detection for Cloudflare WAF — 21 octobre 2026.
Fonctionnement de Full Transaction Detection et des règles intervenant sur les réponses HTTP. (Cloudflare Blog)

ENISA / Commission européenne / CERT-EU / Europol / CSIRTs network — Joint statement on critical PHP vulnerabilities — 21 octobre 2026.
Recommandation coordonnée d’identifier les applications PHP exposées à Internet et d’appliquer les mises à jour. (ENISA)

Canadian Centre for Cyber Security — Critical vulnerabilities impacting PHP — 21 octobre 2026.
État de la menace et recommandations de remédiation. (Canadian Centre for Cyber Security)