Faille PHP2Shell : pourquoi les sites sur une ancienne version de PHP doivent agir maintenant

Le 21 octobre 2026, l'équipe PHP a publié un correctif pour deux failles critiques baptisées PHP2Shell (CVE-2026-109618 et CVE-2026-109619). Elles permettent à un attaquant de prendre le contrôle d'un serveur à distance, sans identifiant, avec une simple requête web. Leur score de gravité atteint 9,2 sur 10.

Pour la majorité des sites, la réponse tient en une ligne : mettre PHP à jour. Mais une partie importante du web ne peut pas simplement appliquer ce correctif. Si votre site tourne sur une version de PHP antérieure à 8.2, il n'existe pas de version officielle corrigée. La vraie solution est une migration plus profonde.

Ce qui s'est passé

• 20 octobre : des informations sur les deux failles circulent sur Internet avant leur publication officielle. L'équipe sécurité de PHP publie une alerte qui annonce une version corrective pour le lendemain.
• 21 octobre, 14h UTC : publication des versions corrigées PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Dans les heures qui suivent : Cloudflare signale les premières attaques et déploie des règles de pare-feu temporaires. La société Sansec anticipait des attaques de masse dans les quinze minutes suivant la publication.

Les failles ont été découvertes par la société Wiz. Selon l'équipe PHP, elles touchent toutes les installations PHP qui servent des pages web. Wiz indique de son côté que les versions remontant jusqu'à PHP 5.4 (2012) sont vulnérables. PHP faisant tourner WordPress, WooCommerce, Magento, PrestaShop, Drupal ou Sulu, l'immense majorité des sites vitrines, boutiques en ligne et espaces clients est concernée.

Que permettent ces failles ?

Un attaquant peut exécuter le code de son choix sur votre serveur. Concrètement, cela signifie le vol de données clients, l'installation d'un logiciel malveillant, la modification de vos pages ou l'utilisation de votre serveur pour attaquer d'autres cibles.

L'équipe PHP est claire : il n'existe pas de protection complète par la configuration. La mise à jour est la seule solution sûre.

Comment régler le problème ?

Si votre site tourne sur PHP 8.2 ou une version plus récente (8.3, 8.4 ou 8.5), la solution existe déjà : le correctif est sorti le 21 octobre. Il suffit de passer à la dernière version de votre branche (8.2.35, 8.3.36, 8.4.27 ou 8.5.12).

Cette mise à jour ne se fait pas depuis l'administration de votre site : elle se fait sur le serveur. Rapprochez-vous dès maintenant de votre hébergeur ou de votre prestataire web pour qu'il l'applique et vérifie que tout fonctionne. Sur un hébergement mutualisé, c'est généralement l'hébergeur qui s'en charge. Sur un serveur dédié ou géré par votre agence, c'est elle qui intervient. L'opération est rapide et n'a pas d'impact sur le contenu de votre site.

Le vrai sujet : les versions de PHP sans correctif officiel

PHP ne maintient que les quatre dernières branches : 8.2, 8.3, 8.4 et 8.5. Tout ce qui est plus ancien est en fin de vie et ne reçoit plus de version officielle de sécurité.

Vu la gravité des failles, l'équipe sécurité de PHP a fait une exception : elle a publié des correctifs minimaux pour PHP 7.4, 8.0 et 8.1, sous forme de code source. Certaines distributions Linux et certains éditeurs de support long terme proposent aussi des correctifs adaptés. Ces solutions dépannent à court terme, mais elles dépendent de votre hébergeur et ne rendent pas une version obsolète sûre dans la durée.

Point important : « PHP 8 » ne veut pas dire « PHP à jour ». Un site en PHP 8.0 ou 8.1 sans correctif rétroporté est aussi exposé qu'un site en PHP 7.4.

Pourquoi la migration est plus lourde qu'une simple mise à jour

Passer de 8.3.35 à 8.3.36 prend quelques minutes et ne change rien au fonctionnement du site. Passer de PHP 7.x à PHP 8.3 est un autre projet :

• Le code n'est plus compatible. PHP 8 a supprimé ou modifié de nombreuses fonctions. Un site développé pour PHP 7 affiche souvent une erreur 500 dès le changement de version.
• Le CMS doit suivre. Une ancienne version de WordPress, PrestaShop 1.6 ou 1.7, Magento 1 ou un vieux Drupal ne fonctionne pas sur PHP 8.2 et plus. Il faut d'abord mettre à jour le CMS, parfois changer de version majeure.
• Les extensions et thèmes aussi. Les modules, plugins et développements sur mesure doivent être vérifiés un par un. Certains ne sont plus maintenus et doivent être remplacés.
• Il faut tester. Formulaires, paiement, moteur de réservation, connexion client, envois d'e-mails : chaque parcours critique doit être vérifié avant la mise en ligne.

Selon l'âge du site, on parle de quelques jours à plusieurs semaines de travail. Et pendant ce temps, le site reste exposé.

PHP 8.2 : corrigé, mais pas pour longtemps

Les sites en PHP 8.2 reçoivent le correctif, mais cette branche arrive en fin de vie le 31 décembre 2026. La prochaine faille ne sera plus corrigée. Si vous devez de toute façon planifier une montée de version, autant viser directement PHP 8.4 ou 8.5.

Les enjeux pour votre entreprise

La sécurité de vos données clients. Une faille de ce type donne accès à tout ce que contient le serveur : bases clients, commandes, réservations, formulaires de contact.

Vos obligations légales. En Suisse, la nLPD impose d'annoncer au PFPDT, dans les meilleurs délais, toute violation de la sécurité des données qui entraîne un risque élevé pour les personnes concernées. Dans l'Union européenne, le RGPD prévoit une notification sous 72 heures. Laisser tourner un site sur une version connue comme vulnérable rend difficile de démontrer que des mesures de sécurité appropriées étaient en place.

Votre visibilité. Un site compromis peut être signalé comme dangereux par Google et les navigateurs, injecté de liens indésirables ou redirigé vers d'autres sites. Le trafic, le référencement et la confiance des visiteurs en pâtissent durablement.

La continuité de votre activité. Le CERT-EU recommande d'isoler du réseau public les applications qui ne peuvent pas être corrigées. Pour un site en PHP 7, cela peut signifier le mettre hors ligne le temps de la migration.

Comment vérifier si je suis concerné ?

Deux questions suffisent : votre site utilise-t-il PHP ? Si oui, en quelle version ?

Votre site utilise-t-il PHP ? C'est le cas si votre site tourne sur WordPress, WooCommerce, PrestaShop, Magento, Drupal, Joomla, Sulu, Symfony ou Laravel. En cas de doute, posez la question à votre agence ou à votre hébergeur. Un site statique ou hébergé sur une plateforme comme Shopify ou Wix n'est pas concerné directement : la mise à jour relève alors de la plateforme.

Quelle version de PHP ? Plusieurs façons de le savoir, de la plus simple à la plus technique :

• Depuis votre CMS : WordPress (Outils > Santé du site > Infos > Serveur), PrestaShop (Paramètres avancés > Informations), Drupal (Rapports > Rapport d'état), Magento 2 (la version n'apparaît pas dans l'administration, passez par l'hébergeur).
• Depuis l'espace client de votre hébergeur. La version de PHP est généralement affichée dans la gestion du site ou de l'hébergement (rubrique « PHP », « Configuration » ou « Version PHP »). Si vous avez plusieurs sites, vérifiez-les un par un : chacun peut avoir sa propre version.
• En demandant à votre prestataire. Votre agence ou votre hébergeur peut vous donner la version exacte en quelques minutes, pour tous vos environnements.

Lisez ensuite le numéro complet. Le dernier chiffre compte autant que les deux premiers :

• 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou plus récent : vous êtes protégé contre PHP2Shell.
• 8.2, 8.3, 8.4 ou 8.5 avec un numéro inférieur : vous êtes vulnérable, mais le correctif existe. Il faut l'appliquer.
• 8.1, 8.0 ou 7.4 : il n'existe pas de version officielle corrigée. Demandez à votre hébergeur si un correctif rétroporté a été appliqué et planifiez une migration.
• 7.3 ou plus ancien : vous êtes vulnérable et aucun correctif ne viendra. Une migration est nécessaire.

Deux pièges à éviter :

• La version affichée en ligne de commande (php -v) n'est pas forcément celle du site. Un serveur peut faire tourner plusieurs versions de PHP en parallèle. Vérifiez celle utilisée par le site web lui-même.
• N'oubliez pas les sites secondaires. Préproduction, sous-domaines, ancien site encore en ligne, landing page de campagne : chacun est une porte d'entrée possible.

Que faire dès maintenant

1. Vérifiez votre version de PHP avec la méthode ci-dessus, pour chacun de vos sites.
2. Si vous êtes en PHP 8.2 ou plus : demandez à votre hébergeur ou à votre prestataire d'appliquer le correctif sans attendre et de redémarrer les services PHP.
3. Si vous êtes en dessous de PHP 8.2 : demandez à votre hébergeur si un correctif rétroporté est disponible et faites de la migration une priorité. En attendant, demandez à votre prestataire de mettre en place les mesures d'atténuation possibles (pare-feu applicatif, blocage des envois de fichiers, désactivation de certaines options de PHP). Elles réduisent le risque sans le supprimer.
4. Faites une sauvegarde complète de vos fichiers et de votre base de données. Gardez-en une copie hors du serveur.
5. Surveillez les signaux d'alerte : fichiers modifiés, nouveaux comptes administrateur, pages ou redirections inconnues, hausse soudaine de la consommation du serveur.
6. Vérifiez tous vos environnements, pas seulement le site principal : préproduction, sous-domaines, anciennes versions de site encore en ligne, conteneurs Docker (à reconstruire à partir d'images corrigées).

Une alerte qui rappelle une règle simple

PHP2Shell ne sera pas la dernière faille critique. La différence entre un site qui se corrige en dix minutes et un site qui doit être mis hors ligne tient à une seule chose : la version de PHP sur laquelle il tourne. Maintenir son site sur une branche supportée n'est pas un luxe technique. C'est ce qui permet de réagir à temps.

Votre site tourne sur une ancienne version de PHP ? Notre équipe vérifie votre configuration, évalue l'ampleur de la migration et vous accompagne jusqu'à la remise en ligne sécurisée. Contactez-nous.

Sources : php.net, Tenable, ma.ttias.be, Journal du Coin, Cyberial, Forget About IT, Wikipedia.