Faille dans PHP (PHP2Shell) : que vérifier et que demander à l’hébergeur

Le 21 octobre 2026, les créateurs de PHP ont publié des correctifs d’urgence pour deux failles critiques dans PHP lui-même, baptisées PHP2Shell. WordPress, WooCommerce, PrestaShop et de nombreux sites développés sur mesure tournent sous PHP. Si votre site utilise l’un d’eux, l’affaire vous concerne aussi. Bonne nouvelle : le correctif est prêt, et vérifier si vous l’avez prend quelques minutes.

Dans ce guide, vous trouverez : ce qui s’est passé, comment vérifier la version de PHP sans développeur, que faire aujourd’hui et que confier à l’hébergeur ou au prestataire du site. Je décris l’état des connaissances au 30 octobre 2026. Les versions corrigées peuvent encore changer : avant la mise à jour, vérifiez-les donc dans l’annonce de sécurité sur php.net.

Ce qui s’est passé

Deux erreurs de gestion de la mémoire ont été découvertes dans PHP : CVE-2026-109618 et CVE-2026-109619. Une requête spécialement préparée envoyée au site peut amener le serveur à exécuter le code d’un tiers. L’attaquant n’a pas besoin de se connecter ni de connaître un mot de passe. Il suffit que le site tourne sur une version vulnérable de PHP.

L’équipe de PHP a évalué les deux failles à 9,2 sur l’échelle CVSS de 0 à 10, c’est-à-dire comme critiques. La société Patchstack a fait état de signalements d’attaques transmis par des hébergeurs quelques heures avant même la publication des correctifs, et le 26 octobre l’agence américaine CISA a inscrit les deux failles dans son catalogue des vulnérabilités exploitées lors d’attaques (KEV). CERT Polska (l’équipe nationale polonaise de réponse aux incidents informatiques) a publié une annonce à ce sujet.

Pas de raison de paniquer, mais une bonne raison de vérifier le site dès aujourd’hui.

Qui est concerné par la faille dans PHP

La faille se trouve dans PHP lui-même, et non dans une extension ou un thème. Elle concerne donc tout site qui tourne sous PHP :

• WordPress et WooCommerce, quels que soient les extensions et le thème,
• PrestaShop, Joomla et les autres systèmes de sites et de boutiques écrits en PHP,
• les scripts et formulaires maison en PHP, y compris sur des sites simples,
• les outils installés sur le serveur, comme phpMyAdmin.

Selon l’annonce de PHP, toutes les installations de PHP qui servent des sites sont menacées, quel que soit leur mode d’exécution sur le serveur. Important : ni la mise à jour de WordPress ni celle des extensions ne corrigera cela. Le correctif doit être installé dans PHP sur le serveur, et sur un hébergement classique, c’est le fournisseur qui s’en charge.

Les versions 8.1 et plus anciennes ne reçoivent plus de publications des créateurs de PHP. Face à des failles aussi graves, l’équipe de PHP a préparé pour 7.4, 8.0 et 8.1 uniquement des correctifs minimaux destinés aux personnes qui compilent PHP elles-mêmes. Sur un hébergement classique, n’y comptez pas : l’issue sûre est le passage à 8.3 ou 8.4.

Comment vérifier si votre site est exposé

Ce qui compte, c’est le numéro de version complet, avec le troisième nombre à la fin. « 8.3 » seul ne suffit pas : la version 8.3.35 est vulnérable, la 8.3.36 ne l’est plus.

WordPress : sans se connecter au serveur

1. Connectez-vous à l’administration de WordPress.
2. Allez dans Outils → Santé du site et ouvrez l’onglet Infos.
3. Dépliez la section Serveur. À la ligne « Version de PHP », vous verrez le numéro complet, par exemple 8.3.36.

Dans PrestaShop, vous trouverez la version de PHP dans les paramètres avancés, parmi les informations sur la configuration de la boutique.

Le panneau de l’hébergeur

Dans le panneau de l’hébergeur, dans les paramètres PHP, on ne voit généralement que « 8.3 » ou « 8.4 », sans le troisième nombre. Cela suffit pour vérifier que le site ne tourne pas sur une version sans support (8.1 ou plus ancienne). Demandez le numéro complet et le correctif à l’hébergeur ; un message tout prêt se trouve plus bas. Je décris où changer de version dans les panneaux d’OVHcloud, home.pl et nazwa.pl dans le guide sur la fin du support de PHP 8.2.

Un fichier de test, juste un instant

Si vous avez accès au serveur par FTP, téléversez un fichier version.php avec ce contenu :

<?php
echo PHP_VERSION;

Ouvrez-le dans le navigateur, notez le résultat et supprimez aussitôt le fichier. Ne laissez pas non plus sur le serveur de fichier contenant phpinfo() : c’est un aide-mémoire tout prêt pour quiconque cherche des points faibles.

Attention aux serveurs sous Ubuntu

Sur les serveurs VPS où PHP provient des paquets du système, le numéro peut être trompeur. Ubuntu intègre le correctif dans une version plus ancienne et conserve son numéro principal. Sous Ubuntu 24.04, le paquet corrigé porte le numéro 8.3.6-0ubuntu0.24.04.13, et non 8.3.36. Dans ce cas, interrogez l’administrateur du serveur ou le prestataire du site sur l’état du correctif.

Que faire aujourd’hui

1. Vérifiez la version de PHP par l’une des méthodes ci-dessus et comparez-la avec le tableau.
2. Si la version est inférieure à celle du tableau, écrivez à l’hébergeur. Sur un hébergement mutualisé, c’est le fournisseur qui met PHP à jour, pas vous.
3. Si vous avez PHP 8.1 ou plus ancien, passez à 8.3 ou 8.4 au plus vite : sauvegarde, test sur une copie du site, changement dans le panneau. Ce n’est pas un simple clic, car d’anciennes extensions peuvent cesser de fonctionner. La CISA recommande de désactiver ces sites d’ici là, sauf si l’hébergeur confirme un correctif pour votre version dans le paquet du système.
4. Si vous avez PHP 8.2, la version 8.2.35 ferme ces failles, mais le support de la 8.2 prend fin le 31 décembre 2026. C’est le bon moment pour passer directement à une version plus récente.
5. Faites une sauvegarde récente des fichiers et de la base de données et conservez-la hors du serveur.
6. Profitez-en pour mettre à jour WordPress, le thème et les extensions en suivant le guide de mise à jour en toute sécurité. Cela ne corrigera pas PHP, mais fermera d’autres portes d’entrée.
7. N’installez pas d’« extensions qui corrigent PHP2Shell » ni de scripts trouvés sur des forums. Une extension ne changera pas PHP sur le serveur, et un code inconnu peut contenir un logiciel malveillant.

Message à l’hébergeur, à copier :

Bonjour, Mon site [adresse du site] est hébergé chez vous (compte : [identifiant ou numéro client]). Pourriez-vous me confirmer que PHP sur mon compte intègre déjà les correctifs des failles PHP2Shell (CVE-2026-109618 et CVE-2026-109619), c’est-à-dire au moins la version 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou un paquet du système contenant ce correctif, et que les processus PHP ont été redémarrés après la mise à jour ? Pourriez-vous également m’indiquer si les journaux du serveur montrent des tentatives d’attaque contre mon site depuis le 20 octobre ? Merci.

Si l’hébergeur ne confirme pas la mise à jour au bout de quelques jours et que le panneau ne propose même pas les versions 8.3 ou 8.4, c’est le signe qu’il faut changer de fournisseur. Dans le cadre du service domaine et hébergement (à partir de 390 PLN HT par an), je migre le site vers un serveur en Pologne ou dans l’UE avec un PHP à jour.

Que confier au prestataire du site ou à l’administrateur du serveur

Si le site tourne sur un serveur VPS, dans un conteneur ou sur le serveur du prestataire, PHP est mis à jour par la personne qui gère ce serveur. Voici la liste pour elle :

• Mise à jour de PHP vers une version du tableau ou vers le paquet corrigé de la distribution (Ubuntu : USN-8948-1, Debian 13 : DSA-6574-1, Debian 12 : DLA-4848-1).
• Redémarrage de tous les processus PHP (PHP-FPM, Apache avec mod_php). Sans redémarrage, l’ancienne version continue de tourner en mémoire.
• D’abord Apache avec mod_php. Selon l’équipe de PHP, c’est là que le risque est le plus élevé.
• Les images Docker avec PHP doivent être reconstruites sur la nouvelle version et redéployées.
• Un pare-feu applicatif (WAF) peut, selon la CISA, limiter en partie le risque en attendant la mise à jour, mais ne la remplace pas.
• Serveurs sous Windows : le 26 octobre, PHP a publié des paquets reconstruits 8.5.12-1, 8.4.27-1, 8.3.36-1 et 8.2.35-1 avec une bibliothèque Brotli corrigée (CVE-2026-111497). J’écris sur cette faille dans le guide Faille Node.js et Brotli (Node2Shell).

Si la mise à jour doit attendre, l’annonce de PHP indique un réglage provisoire. Il faut l’inscrire dans php.ini ou dans la configuration du pool PHP-FPM (et non via ini_set() ni un fichier .user.ini), puis redémarrer les processus PHP :

session.upload_progress.enabled = 0

Ce n’est qu’une protection partielle. Selon l’équipe de PHP, ce réglage bloque les voies d’attaque confirmées passant par la session, mais pas toutes les variantes, et selon Tanium il ne protège pas contre CVE-2026-109618. Seule la mise à jour offre une protection complète.

La troisième faille : CVE-2026-115560

Le 23 octobre, l’équipe de PHP a décrit une nouvelle faille, elle aussi liée à la progression de l’envoi de fichiers dans la session. Les versions du 21 octobre ne la corrigent pas. Selon PHP, elle ne représente une menace qu’avec une combinaison inhabituelle de réglages du serveur et de code de l’application : le correctif arrivera donc dans la prochaine version régulière, et non dans une version d’urgence.

D’ici là, PHP recommande le réglage session.upload_progress.enabled = 0, le même que ci-dessus. Si ce réglage est déjà actif sur le serveur, laissez-le aussi après la mise à jour. Après le changement, vérifiez les formulaires dans lesquels les clients envoient des fichiers. Le jour où je termine ce guide, le correctif n’existe pas encore : consultez donc les actualités sur php.net.

Quelqu’un a-t-il déjà pu s’introduire sur le site ?

Les premières tentatives d’attaque ont été relevées avant même la publication des correctifs. Après la mise à jour, il vaut donc la peine de vérifier que personne n’a eu le temps de se ménager une porte dérobée. Signaux d’alerte :

• de nouveaux comptes administrateurs que personne dans l’entreprise n’a créés,
• des fichiers inconnus sur le serveur, en particulier des fichiers .php dans le répertoire des images,
• des redirections vers des sites inconnus ou des pages étranges dans les résultats de Google,
• des messages de l’hébergeur sur un logiciel malveillant ou une hausse soudaine de la charge du serveur.

Demandez à l’hébergeur ou au prestataire de passer en revue les journaux depuis le 20 octobre. La CISA attire notamment l’attention sur les processus PHP qui lancent un shell système ou téléchargent des outils. Si vous trouvez des traces d’intrusion, changez les mots de passe, restaurez une sauvegarde saine et signalez l’incident à CERT Polska via le formulaire sur incydent.cert.pl. Je décrirai un plan d’action étape par étape dans un guide séparé, « Faille sur un site d’entreprise : que faire dans les 24 premières heures ».

Je montre comment vérifier les versions de PHP, du CMS et des extensions de votre site dans le guide Comment vérifier la version de PHP et sur quoi tourne votre site.

En résumé

PHP2Shell, ce sont deux failles critiques dans PHP lui-même, et non dans WordPress ou les extensions. Vérifiez le numéro complet de la version de PHP, comparez-le avec le tableau et demandez à l’hébergeur de confirmer le correctif. Les réglages de remplacement ne font que réduire le risque ; seule la mise à jour offre une protection complète.

Si vous ne voulez pas surveiller cela vous-même, dans le cadre de la maintenance technique, je surveille le site, je fais les sauvegardes et j’installe les mises à jour de sécurité, les urgentes sous 2 jours. Le forfait Veille coûte à partir de 149 PLN HT par mois, et Standard (à partir de 349 PLN) et Pro (à partir de 749 PLN) offrent une réaction plus rapide et des heures de travail chaque mois. Si vous voulez vérifier comment le site est protégé au-delà de PHP lui-même, commandez un audit de sécurité ou tout simplement écrivez-moi. Je réponds sous 24 heures, et les nouveaux clients bénéficient de 20 % de remise sur leur première commande.