Faille critique PHP (CVE-2026-109618) : que faire dès maintenant

Le 21 octobre 2026, l’équipe de PHP a publié des correctifs pour deux failles critiques du langage lui-même : CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 sur 10. Elles permettent à un attaquant d’exécuter du code sur un serveur à distance, sans avoir besoin de se connecter. Comme la faille est dans PHP et non dans un CMS, elle concerne WordPress, Joomla, PrestaShop, Laravel et toutes les applications sur mesure. Voici ce qu’il faut savoir, et surtout quoi faire, selon votre situation.

Ce qui s’est passé

• Les détails des failles ont fuité en ligne le 20 octobre, avant la publication des correctifs. Un code d’attaque circule, et plusieurs acteurs (dont Cloudflare) ont signalé des premières tentatives d’attaque.
• Pour la première faille, PHP manque de mémoire en pleine préparation d’une requête, puis traite des données à moitié initialisées comme valides. Pour la seconde, un état interne survit après la libération de sa mémoire et peut être réutilisé par la requête suivante.
• Selon l’avis officiel, toutes les installations qui servent des pages web sont concernées (PHP-FPM, Apache avec mod_php, php-cgi, LiteSpeed, FrankenPHP). Le mode mod_php est le plus exposé : une seule requête non authentifiée peut suffire, avant même que le code de votre site ne s’exécute.
• Le CERT-EU a publié une alerte officielle (avis 2026-018).

Les versions corrigées de PHP

Pour savoir où vous en êtes, regardez la version PHP indiquée dans l’espace de votre hébergeur (cPanel, Plesk, OVH, Infomaniak…), ou dans Outils → Santé du site → Infos sur WordPress. Le calendrier complet est dans l’article sur les versions de PHP supportées.

La règle numéro un : mettre PHP à jour

La faille est dans PHP. Mettre à jour WordPress, un plugin ou un thème ne la corrige pas. Tout le reste de cet article, Cloudflare, réglages, filtres, ne fait que réduire le risque en attendant. Les développeurs de PHP le disent clairement.

• Hébergement mutualisé : c’est votre hébergeur qui gère PHP. Vérifiez son annonce de sécurité et, si vous avez le choix de la version, passez en PHP 8.3 ou 8.4 dès que votre site le supporte. Si votre version n’est plus proposée à jour, demandez-lui par écrit s’il a appliqué le correctif.
• Site WordPress : il fonctionne en général très bien en PHP 8.3 ou 8.4, sous réserve de vérifier les plugins et le thème. Voir la compatibilité WordPress et PHP.
• Joomla, PrestaShop, application ancienne : c’est là que ça se complique, car le CMS lui-même peut refuser de fonctionner sur une version récente de PHP. C’est expliqué plus bas.

Cloudflare peut-il protéger mon site ?

En partie, et à une condition : que votre domaine passe par Cloudflare. Cloudflare a activé le 21 octobre, automatiquement et sur tous les plans y compris gratuit, des règles de pare-feu (WAF) qui bloquent les méthodes d’attaque connues, ainsi qu’une règle qui peut bloquer une réponse suspecte avant qu’elle n’atteigne l’attaquant. Il n’y a rien à activer si votre site est déjà derrière Cloudflare.

Comment mettre un site derrière Cloudflare

1. Créer un compte gratuit sur cloudflare.com et ajouter votre domaine.
2. Cloudflare importe vos enregistrements DNS : vérifiez qu’ils sont tous présents, puis remplacez chez votre registrar (le service où vous avez acheté le nom de domaine) les serveurs de noms par les deux que Cloudflare indique.
3. Sur les enregistrements du site (le domaine et www), vérifiez que le nuage est orange (mode « proxifié »). Les visiteurs, et donc les attaquants, passent alors par Cloudflare avant d’atteindre votre serveur.
4. Laissez les enregistrements de messagerie (MX) en gris : ils ne peuvent pas être proxifiés.

Ce que Cloudflare ne fait pas

• Il ne corrige pas PHP. Il filtre les attaques connues. Cloudflare indique d’ailleurs que les pirates modifient déjà leurs attaques pour contourner les règles, qu’il faut donc mettre à jour en continu.
• Il ne protège que le trafic qui passe par lui. Si quelqu’un attaque directement l’adresse IP de votre serveur, le filtre est contourné. Sur un VPS ou un serveur dédié, il faut donc autoriser dans le pare-feu uniquement les adresses IP de Cloudflare sur les ports 80 et 443. Et ne laissez pas traîner l’IP du serveur : un sous-domaine non proxifié ou un enregistrement de messagerie peut la révéler.
• Pour vérifier qu’il travaille : Sécurité → Analyses → Événements dans le tableau de bord Cloudflare.

Site sous PHP 7.4 ou une version abandonnée : les gestes d’urgence

Soyons honnêtes : tant que le site reste sur une version de PHP sans correctif, il n’existe pas de réglage qui le protège vraiment. Ce qui suit réduit la surface d’attaque, dans l’attente d’une migration.

1. Passer derrière Cloudflare (voir plus haut) : c’est le geste le plus efficace en quelques minutes.
2. Désactiver le suivi de progression des envois de fichiers, utilisé par l’une des deux failles. Selon votre hébergement :
   • PHP en mode Apache (mod_php) : ajouter dans le fichier .htaccess à la racine du site la ligne php_flag session.upload_progress.enabled off.
   • PHP en mode FPM ou CGI (le cas de la plupart des hébergeurs actuels) : les lignes php_flag du .htaccess provoquent alors une erreur 500. Créer plutôt un fichier .user.ini à la racine, contenant session.upload_progress.enabled = 0. Il est pris en compte en quelques minutes.
   • Si vous avez accès au php.ini ou à la configuration du pool PHP-FPM, le plus fiable est d’y mettre le réglage, puis de redémarrer PHP.
3. Limiter la taille des requêtes : la faille de mémoire s’exploite plus facilement avec de grosses requêtes. Sur Apache, LimitRequestBody 8388608 dans le .htaccess (8 Mo, si votre hébergeur l’autorise) ; réglez aussi post_max_size et upload_max_filesize à des valeurs raisonnables si votre hébergeur le permet.
4. Supprimer les formulaires d’envoi de fichiers qui ne servent à rien, et les scripts oubliés sur le serveur (anciens tests, info.php, sauvegardes en .zip).
5. Faire une sauvegarde complète maintenant, stockée hors du serveur, pour pouvoir restaurer en cas de problème.
6. Surveiller : fichiers PHP récents ou inconnus dans le dossier du site, nouveaux comptes administrateurs, tâches planifiées (cron) inconnues, pic de trafic ou d’erreurs 500.

Ces réglages ne rendent pas le site sûr : ils compliquent seulement certaines attaques. Les responsables de PHP les décrivent eux-mêmes comme une atténuation partielle. Considérez-les comme un pansement pour les jours qui viennent, pas comme une solution.

Vous avez un VPS ou un serveur dédié

Vous êtes le seul à pouvoir corriger : personne ne le fera à votre place. Dans l’ordre :

1. Identifier chaque version de PHP installée (php -v en ligne de commande, mais aussi la version utilisée par le serveur web, qui peut différer) et chaque site qui en dépend.
2. Appliquer les mises à jour de votre distribution (apt update && apt upgrade sur Debian et Ubuntu, dnf update sur AlmaLinux ou Rocky Linux), puis redémarrer PHP-FPM ou Apache. Les distributions et les fournisseurs de support à long terme ont reçu les correctifs en avance : vérifiez dans leur bulletin de sécurité que la version installée est bien corrigée. Si vous utilisez un dépôt tiers (Remi, Sury…), contrôlez qu’il a publié la mise à jour : le dépôt Remi n’avait pas encore de correctif au moment de la publication.
3. Si votre version est ancienne (PHP 7.4, 8.0 ou 8.1) : la solution durable est de migrer vers PHP 8.3 ou 8.4, ce qui demande de tester le site. En attendant, deux options : un paquet corrigé par un fournisseur de support à long terme (Ubuntu Pro, TuxCare, CloudLinux…), ou compiler PHP avec le correctif minimal publié par l’équipe de PHP. Aucune des deux n’est idéale sur la durée.
4. Abandonner mod_php si vous l’utilisez, au profit de PHP-FPM : c’est le mode le plus exposé.
5. Fermer ce qui n’a pas à être public : pare-feu fermé sauf 80, 443 et SSH (limité à vos adresses), phpMyAdmin et panneaux d’administration derrière un VPN ou une liste d’adresses autorisées, et Cloudflare devant les sites avec l’IP du serveur verrouillée.
6. Chercher une compromission si le serveur est resté exposé ces derniers jours : processus PHP qui lancent des commandes (sh, curl, wget), fichiers récents dans les dossiers web, tâches cron et comptes ajoutés, connexions sortantes inhabituelles. Si vous trouvez quelque chose, isolez le serveur et conservez les journaux avant de nettoyer.

Si ces étapes ne vous sont pas familières, je peux m’en charger : voir dépannage serveur et VPS.

Migrer le CMS vers une version compatible avec PHP 8.3, 8.4 ou 8.5

Pour beaucoup de sites, le vrai problème est là : le CMS est trop ancien pour fonctionner sur une version de PHP encore corrigée. Mettre PHP à jour en laissant le CMS tel quel fait tomber le site. La seule issue durable est de migrer le CMS vers sa dernière version, ce qui règle d’un seul coup la faille du jour et les failles connues des vieilles versions.

• Joomla 3 (et 4) : passage à Joomla 6, qui demande PHP 8.3 au minimum. Template et extensions à adapter. La méthode est détaillée dans migrer Joomla 3 vers Joomla 6, et je propose la mise à jour Joomla.
• PrestaShop 1.6 et 1.7 : ces versions ne fonctionnent pas avec les versions récentes de PHP. Le passage à PrestaShop 9 passe par un thème et des modules à vérifier. Voir mise à jour PrestaShop 9 et le service de mise à jour PrestaShop.
• WordPress : généralement une simple montée de version de PHP après contrôle des plugins et du thème.
• Application PHP sur mesure ou CakePHP, CodeIgniter : audit de compatibilité, puis corrections du code, comme décrit dans passer de PHP 7 à PHP 8.

Je suis développeur indépendant et je réalise ces migrations depuis des années, toujours sur une copie du site : le site en ligne continue de fonctionner, la bascule n’a lieu que lorsque tout est validé. Vu l’urgence, je traite ces demandes en priorité, avec un prix annoncé avant de commencer.

Questions fréquentes

Mon site est-il forcément piraté si je n’ai pas mis à jour ?

Non. La faille est connue depuis peu et les premières attaques commencent. Mais le risque est réel et il augmentera : les robots de piratage scannent le web en permanence, surtout quand un code d’attaque circule. Mieux vaut agir aujourd’hui.

Est-ce que WordPress, Joomla ou PrestaShop sont plus touchés que les autres ?

Non, la faille est dans PHP : tout site PHP est concerné, quel que soit le CMS. La différence est ailleurs : un CMS récent peut tourner sur un PHP corrigé, un CMS ancien parfois non.

Cloudflare gratuit suffit-il ?

C’est une très bonne protection en attendant, et elle est active sans rien configurer sur les sites déjà proxifiés. Mais elle ne remplace pas la mise à jour de PHP et ne protège pas si l’adresse du serveur est accessible directement.

Que faire si mon hébergeur ne propose pas de PHP corrigé ?

Demandez-lui par écrit sa position et sa date de correction. S’il n’en donne pas, c’est le bon moment pour envisager un autre hébergement : je peux aussi m’occuper de la migration d’hébergeur.

Combien de temps prend une migration en urgence ?

Pour un site WordPress, quelques heures. Pour un site Joomla ou une boutique PrestaShop, de quelques jours à une ou deux semaines selon les extensions et le thème. Décrivez-moi votre site : je vous réponds sous 12h avec le délai et le prix ferme.

Sources

• CERT-EU, avis de sécurité 2026-018
• php.net, annonce de sécurité du 21 octobre 2026
• Cloudflare, protections WAF contre ces failles
• Huntress, analyse et recommandations