Faille PHP (PHP2Shell) : que faire pour protéger votre site web

Si votre site tourne sur PHP (WordPress, PrestaShop, Joomla, Drupal…), deux failles jugées critiques par l'équipe PHP viennent d'être corrigées. Dans l'ordre : vérifiez la version de PHP utilisée par votre serveur, passez à PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou au paquet corrigé de votre hébergeur), puis redémarrez les processus PHP. En hébergement mutualisé, vous ne pouvez pas appliquer le correctif vous-même : écrivez à votre hébergeur dès aujourd'hui (modèle plus bas). Mettre à jour WordPress ou ses extensions ne suffit pas : la faille est dans PHP, pas dans votre site.

Ce qui se passe

PHP est le langage dans lequel sont écrits WordPress, PrestaShop, Joomla, Drupal, les applications Symfony ou Laravel et beaucoup de sites sur mesure. Les deux failles se trouvent dans le cœur de PHP, dans la gestion de la mémoire et des erreurs. Dans certaines configurations, un attaquant peut s'en servir pour exécuter ses propres commandes sur le serveur, sans avoir besoin d'identifiants.

Le risque le plus élevé concerne les serveurs Apache avec le module mod_php : l'équipe PHP y a démontré une attaque qui fonctionne avant même que le code du site ne s'exécute. Les autres modes de fonctionnement (PHP-FPM, php-cgi, FrankenPHP, LiteSpeed) sont aussi concernés.

Faille PHP et ANSSI : ce que dit l'alerte CERT-FR CERTFR-2026-ALE-014

Le CERT-FR a publié l'alerte CERTFR-2026-ALE-014 le 21 octobre 2026, mise à jour le 22 octobre. Trois points à retenir :

• Versions touchées : toutes les versions 5.x, 7.x, 8.0.x et 8.1.x, et les branches 8.2 à 8.5 avant 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
• Exploitation : le CERT-FR a connaissance de preuves de concept pour des déploiements spécifiques de PHP. Le CERT-EU note que ces preuves de concept commencent à circuler, ce qui rend une exploitation plus probable.
• Recommandation : isoler les équipements affectés, puis migrer vers une version maintenue avec les derniers correctifs de sécurité.

Le bon réflexe est donc de corriger maintenant, sans attendre une vague d'attaques.

Mon site est-il concerné ?

Si votre site utilise WordPress, PrestaShop, Joomla, Drupal, Symfony, Laravel ou un développement en PHP, il est concerné tant que la version de PHP du serveur n'est pas corrigée. Le point qui prête à confusion : la faille n'est ni dans WordPress, ni dans un thème, ni dans une extension. Elle est dans le moteur PHP installé sur le serveur. Mettre à jour WordPress reste une bonne pratique, mais ne corrige pas cette faille-là.

C'est vrai pour un site vitrine comme pour une boutique en ligne, un extranet ou un outil métier accessible par internet. Dès qu'un serveur PHP répond à des visiteurs, il est concerné.

Faille PHP : que faire maintenant, en 5 étapes

1. Trouvez la version de PHP réellement utilisée. Sous WordPress : Outils → Santé du site → onglet Informations → section Serveur, ligne « Version de PHP ». Sinon, le panneau de votre hébergeur (cPanel, Plesk ou console maison) affiche la version PHP de chaque site. Attention : chez certains hébergeurs et sur les distributions Linux (Debian, Ubuntu, Red Hat…), le correctif est intégré à un paquet qui garde son propre numéro de version. Un numéro « ancien » n'est donc pas forcément vulnérable, et l'inverse est vrai aussi : seule la note de l'hébergeur ou le journal des modifications du paquet fait foi. En cas de doute, posez la question par écrit.

2. En hébergement mutualisé, écrivez à votre hébergeur. C'est lui qui gère PHP, pas vous. Message type à copier :

Bonjour,

Suite aux alertes du CERT-FR sur les failles PHP CVE-2026-109618 et CVE-2026-109619 (« PHP2Shell »), pouvez-vous me confirmer :

1. la version exacte de PHP utilisée aujourd'hui par mon site ;
2. la date à laquelle il passera en PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou une version de votre distribution qui intègre ces correctifs) ;
3. les mesures de protection en place d'ici là.

Merci.

3. Sur serveur dédié, VPS ou conteneur : mettez à jour, redémarrez, vérifiez (étape pour votre prestataire technique). Installez la version corrigée de votre branche (8.2.35, 8.3.36, 8.4.27 ou 8.5.12) ou le paquet corrigé de votre distribution. Redémarrez ensuite PHP-FPM ou Apache, et les processus PHP qui tournent en continu (files d'attente, workers, démons) : ils gardent l'ancienne version tant qu'ils n'ont pas redémarré. Avec Docker, reconstruisez et redéployez vos images. Vérifiez enfin la version réellement servie par le site web, pas seulement celle affichée en ligne de commande.

4. En PHP 8.1 ou plus ancien : isolez, puis migrez. Ces versions n'ont plus de version officielle. L'équipe PHP a fourni des correctifs minimaux pour 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes, et certaines distributions proposent des correctifs rétroportés : renseignez-vous auprès de votre fournisseur. Le CERT-FR recommande d'isoler ces serveurs puis de migrer vers une version maintenue. À noter : PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026.

5. Si vous ne pouvez pas mettre à jour aujourd'hui : réduisez l'exposition (étape pour votre prestataire technique). Ces mesures, publiées par php.net et le CERT-FR, réduisent le risque mais ne remplacent pas la mise à jour ; le CERT-FR précise qu'il ne les a pas qualifiées :

• désactiver session.upload_progress.enabled dans php.ini ou la configuration du pool PHP-FPM (pas via ini_set() ni .user.ini), puis redémarrer tous les processus PHP. Cette mesure ne réduit la surface d'attaque que pour CVE-2026-109619 ;
• fixer une post_max_size basse : 8M si le site n'accepte pas de fichiers, 32M sinon ;
• faire bloquer, ou au minimum surveiller, les requêtes HTTP de type multipart (envois de formulaires et de fichiers) au niveau du pare-feu applicatif, ou WAF, le filtre placé devant le site.

Avec PHP-FPM, le CERT-FR indique de forcer aussi le réglage dans la configuration du pool :

php_admin_flag[session.upload_progress.enabled] = off

Quand la correction n'est pas possible, le CERT-EU recommande d'envisager d'isoler d'internet les applications exposées jusqu'à ce que le correctif soit appliqué et vérifié.

Mise à jour PHP chez OVHcloud, o2switch, Infomaniak ou sous WordPress

En hébergement mutualisé, deux choses différentes se cachent derrière « mettre à jour PHP » : choisir la branche (8.2, 8.3, 8.4…), ce que vous faites dans votre espace client, et appliquer le correctif de sécurité dans cette branche, ce que fait l'hébergeur sur ses serveurs. Pour changer de branche, voici les guides publics des hébergeurs les plus courants :

• OVHcloud : configuration de l'hébergement dans l'espace client, ou fichier .ovhconfig (guide OVHcloud).
• o2switch : outil « Sélectionner une version de PHP » dans cPanel (guide o2switch).
• Infomaniak : gestion du site dans le Manager, « Plus d'informations » puis « Modifier » (guide Infomaniak).
• WordPress : la page « Mettre à jour PHP » de WordPress.org explique comment vérifier la compatibilité du site avant de changer de version.

Avant de changer de branche, vérifiez que votre CMS, votre thème et vos extensions la supportent, et faites une sauvegarde. Pour savoir si le correctif PHP2Shell est appliqué, ne vous fiez pas au seul numéro de branche : posez la question à l'hébergeur (message type plus haut).

Mon hébergeur dit que je suis protégé : est-ce suffisant ?

Si votre hébergeur vous annonce que vous êtes protégé, deux situations très différentes peuvent se cacher derrière ce message : soit PHP a été mis à jour, soit une règle de filtrage (WAF) bloque les attaques connues. Le filtrage est utile, mais ce n'est pas un correctif : une variante de l'attaque peut passer. Seule une version de PHP corrigée supprime la faille.

Posez donc une seule question : « Quelle version de PHP mon site utilise-t-il aujourd'hui ? » Puis : « Cette version, ou le paquet installé, intègre-t-elle les correctifs des CVE-2026-109618 et CVE-2026-109619 ? » Si la réponse est non, votre protection repose sur du filtrage.

Et si mon site avait déjà été piraté ?

Mettre PHP à jour ferme la porte. Cela ne fait pas sortir quelqu'un qui serait déjà entré. Si un attaquant a exploité la faille avant la correction, il a pu déposer un accès caché qui reste actif après la mise à jour.

Signes qui doivent alerter : des fichiers récents que personne n'a ajoutés dans le dossier du site, un compte administrateur inconnu, des pages modifiées sans intervention de votre part, des redirections étranges, un hébergeur qui signale une activité anormale. Dans ce cas, ne vous contentez pas de mettre à jour : conservez les journaux, ne réinstallez pas tout dans l'urgence et faites appel à une équipe de réponse à incident pour comprendre ce qui a été touché.

Ce que cette faille rappelle sur la sécurité de votre site

Trois réflexes valent toute l'année, au-delà de PHP2Shell :

1. Savoir ce qui tourne. Quelle version de PHP, quel CMS, chez quel hébergeur, et qui a la main pour mettre à jour. Si personne ne peut répondre en cinq minutes, c'est le premier chantier.
2. Ne pas laisser vieillir. Une version qui ne reçoit plus de correctifs reste exposée à chaque nouvelle faille. Planifiez la migration de PHP 8.2 avant la fin de 2026.
3. Limiter ce qui est visible sur internet. Pages d'administration, anciens sous-domaines, sites de test oubliés : chaque élément exposé est une porte possible. C'est aussi vrai pour vos équipements réseau (voir les vulnérabilités les plus fréquentes dans les PME et notre point sur la mise à jour FortiGate d'octobre 2026).

Un audit de sécurité de votre site et de vos API dresse cette carte et vérifie les failles connues. Pour une vue d'ensemble de l'entreprise, l'audit cybersécurité 360 part du même principe.

Questions fréquentes

Que faire en priorité face à la faille PHP ?

Vérifiez la version de PHP utilisée par votre site, installez la version corrigée de votre branche (8.2.35, 8.3.36, 8.4.27 ou 8.5.12) ou le paquet corrigé de votre hébergeur, puis redémarrez tous les processus PHP. En hébergement mutualisé, c'est l'hébergeur qui agit : demandez-lui par écrit la version utilisée et la date de correction.

Quel correctif pour la faille PHP, et quelle version installer ?

Le correctif est une mise à jour du moteur PHP : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, publiées le 21 octobre 2026, corrigent CVE-2026-109618 et CVE-2026-109619. Si votre hébergeur ou votre distribution Linux fournit ses propres paquets, le numéro affiché peut rester le même : seule sa note de sécurité fait foi. PHP 8.1 et plus ancien n'ont pas de version officielle corrigée.

Que disent l'ANSSI et le CERT-FR sur la faille PHP ?

Le CERT-FR, rattaché à l'ANSSI, a publié l'alerte CERTFR-2026-ALE-014 le 21 octobre 2026, mise à jour le 22 octobre. Il indique avoir connaissance de preuves de concept pour certains déploiements de PHP, recommande d'isoler les équipements affectés puis de migrer vers une version maintenue et corrigée, et propose des contournements provisoires qu'il précise ne pas avoir qualifiés.

Est-ce que mettre à jour WordPress suffit ?

Non. La faille est dans le moteur PHP du serveur, pas dans WordPress ni dans ses extensions. Mettre à jour WordPress reste utile, mais seule une version de PHP corrigée, ou un paquet corrigé de votre hébergeur ou de votre distribution, supprime cette vulnérabilité.

Comment faire la mise à jour PHP chez OVHcloud, o2switch ou Infomaniak ?

En hébergement mutualisé, le choix de la branche PHP se fait dans l'espace client : chez OVHcloud dans la configuration de l'hébergement ou le fichier .ovhconfig, chez o2switch avec l'outil « Sélectionner une version de PHP » de cPanel, chez Infomaniak dans la gestion du site sur le Manager. Les correctifs eux-mêmes sont appliqués par l'hébergeur : demandez-lui confirmation par écrit.

Faut-il redémarrer après la mise à jour ?

Oui. Selon les outils, la mise à jour redémarre PHP-FPM automatiquement ou non, mais les processus PHP qui tournent en continu (files d'attente, workers, démons) gardent l'ancienne version jusqu'à leur redémarrage. Après un changement de configuration provisoire, php.net demande aussi de redémarrer tous les processus.

La faille PHP est-elle exploitée ?

Le CERT-FR indique avoir connaissance de preuves de concept pour certains déploiements, et le CERT-EU signale qu'elles commencent à circuler. Au 23 octobre 2026, date de notre vérification, ces deux failles ne figurent pas au catalogue américain CISA des vulnérabilités exploitées. Ce n'est pas une raison pour attendre : corrigez maintenant.

PHP 7.4 ou 8.1 : que faire ?

Il n'y a pas de version officielle corrigée. L'équipe PHP a publié des correctifs minimaux pour qui compile PHP lui-même, et certaines distributions ou hébergeurs les intègrent : demandez-leur. Le CERT-FR recommande d'isoler ces serveurs puis de migrer vers une version maintenue, en sachant que PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026.

Mon pare-feu FortiGate est-il touché par PHP2Shell ?

Non. Dans son avis FG-IR-26-186 (mis à jour le 23 octobre 2026), Fortinet indique que FortiOS, FortiGate Cloud, FortiManager, FortiAnalyzer, FortiWeb, FortiMail et FortiAuthenticator ne sont pas concernés ; quelques produits restent à l'étude. Fortinet a en revanche publié des mises à jour de sécurité distinctes pour FortiOS le 22 octobre : voir notre point sur la mise à jour FortiGate.

Qui peut vérifier mon site ?

Votre hébergeur pour la version de PHP, votre agence ou votre prestataire pour le site. Pour un regard extérieur, un audit de sécurité web contrôle les failles connues et la configuration, et un test d'intrusion mesure ce qu'un attaquant pourrait réellement faire.

Sources

• php.net, avis de sécurité et versions 8.5.12, 8.4.27, 8.3.36, 8.2.35 (21 oct. 2026).
• PHP, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) et GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• NVD, CVE-2026-109618 et CVE-2026-109619.
• CERT-FR, alerte CERTFR-2026-ALE-014 (21 oct., mise à jour 22 oct. 2026) et avis CERTFR-2026-AVI-1359 (21 oct. 2026).
• CERT-EU, avis 2026-018 (21 oct. 2026).
• Cybermalveillance.gouv.fr, AlerteCyber sur les failles PHP (22 oct. 2026).
• Wiz Research, « PHP2Shell » (21 oct. 2026).
• Laravel Forge, mise à jour de sécurité PHP et processus longs.
• Fortinet PSIRT, FG-IR-26-186 (21 oct., mis à jour 23 oct. 2026).
• CISA, catalogue des vulnérabilités exploitées (KEV), version 2026.10.21.
• Guides hébergeurs : OVHcloud, o2switch, Infomaniak ; WordPress.org.

Sources consultées le 23 octobre 2026. Cet article sera mis à jour si le statut d'exploitation de ces failles évolue.